From pekkas at netcore.fi Tue Nov 1 12:20:48 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 1 Nov 2005 13:20:48 +0200 (EET) Subject: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051014122508.G77157@mignon.ki.iif.hu> References: <20051010124501.S40670@mignon.ki.iif.hu> <20051014122508.G77157@mignon.ki.iif.hu> Message-ID: On Fri, 14 Oct 2005, Mohacsi Janos wrote: > Dear All, > I did not see any answers except one from Bill Manning - who was > supporting the 4. options. FWIW, I do not see a problem with option 3 -- the .hu servers would not need to get addresses from each an every ISP, two or three of them should be enough. I would be opposed to option 4. > So this means this is the accepted and RIPE reccomended method. > Basically allow allocating portable IPv6 address: > * root domain name system (DNS) server; > * global top level domain (gTLD) nameservers; > * country code TLD (ccTLDs) nameservers; > > When the RIPE policy will reflect this changes? > > Thanks Regards, > > Janos Mohacsi > Network Engineer, Research Associate > NIIF/HUNGARNET, HUNGARY > Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 > > > On Mon, 10 Oct 2005, Mohacsi Janos wrote: > >> Dear All, >> I have a question regarding the IPv6 address assignment to >> cc level DNS server. >> >> If you don't have answer to this question please forward it to an >> appropriate working group - sorry for cross-posting this mail to two wg. >> >> We have here in Hungary a dilemma: >> >> - Traditionally, the IPv4 address of the primary cc level DNS server in of >> belonged to NIIF/HUNGARNET. >> >> - The DNS registration service a while ago was delegated to Council of >> Hungarian Internet Providers (ISZT) who is also operating the biggest >> Internet Exchange of Hungary (BIX). All big ISPs in Hungary (including >> NIIF/HUNGARNET) has right to do the registration via a special interface. >> >> - The IPv4 address of the primary cc level DNS server announced by >> NIIF/HUNGARNET. But ISZT is reorganizing its infrastructure to allocate >> address from a new PI type IPv4 address space to DNS servers. >> >> - The primary hu DNS server is connected to BIX - to be well connected. >> >> >> What IPv6 address space should we allocate to hu primary DNS server? >> >> 1. Assign IPv6 address from /32 address space of NIIF/HUNGARNET? >> - not very optimal since the only transit to hu primary will be >> NIIF/HUNGARNET >> - not ISP neutral - easy, no problem from point of view of NIIF/HUNGARNET >> >> >> 2. Assign IPv6 address space from /48 allocated to BIX (based on ripe-256 >> and ripe-310)? >> - According to the RIPE documents: "Networks assigned under this policy may >> not be globally routable" - which problematical since primary DNS servers >> should be globally reachable. >> >> 3. Allocate multiple /48 from IPv6 providers in HUNGARY to primary hu DNS >> server? >> - This can be problematical since the answers to DNS queries might be quite >> big. >> >> 4. Allocate /48 to primary hu DNS server that is globally routable? >> Are there similar to /48 from 2001:0500::/30 in RIPE region? >> >> - I think this is the cleanest solution. >> >> Can we discuss this issue on the working group or mailing lists? >> >> I saw a proposal: http://www.ripe.net/ripe/policies/proposals/2005-2.html >> >> In my opinion this can solve the problem.... >> >> Best Regards, >> >> >> Janos Mohacsi >> Network Engineer, Research Associate >> NIIF/HUNGARNET, HUNGARY >> Key 00F9AF98: 8645 1312 D249 471B DBAE 21A2 9F52 0D1F 00F9 AF98 >> >> > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From baess at denic.de Tue Nov 1 16:53:37 2005 From: baess at denic.de (Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?=) Date: Tue, 1 Nov 2005 16:53:37 +0100 Subject: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: Message-ID: Dear Pekka, I have not seen you on the last RIPE meeting when we had a short update on my policy proposal for anycasted TLD nameservers which is referenced later as the 4th option for the hungarian nameservers. > I would be opposed to option 4. > > >> 4. Allocate /48 to primary hu DNS server that is globally routable? > >> Are there similar to /48 from 2001:0500::/30 in RIPE region? > >> > >> - I think this is the cleanest solution. > >> > >> Can we discuss this issue on the working group or mailing lists? > >> > >> I saw a proposal: http://www.ripe.net/ripe/policies/proposals/2005-2.html > >> > >> In my opinion this can solve the problem.... I have not seen any discussions that think it is a bad idea to assign several network resources to TLD administrators which will enable them to operate their nameservers according to RFC3258. When we have reviewed the discussions we felt that your objection against the proposal was because of the size of the assignment. I'm planning to submit revised proposal with a reduced prefix length which better fits with other assignment policies. If you are opposing to the new proposal I would be glad to know as soon as it is submitted. If you are suggesting that .hu should start using IPv6 addresses from carriers to start deploying V6 with some of their nameservers and renumber them later as the V6 infrastructure matures I would agree. Looking at the query rates on V6 interfaces the impact of loosing one nameserver in the V6 cloud is not as crucial as in the V4 world at the moment. However this might change faster than sone people think at the moment making V6 anycasting of TLD nameservers a top priority for their administrators. Regards Andreas Baess -- DENIC e.G. Phone :+49 69 27235 120 Wiesenhuettenplatz 26 Fax :+49 69 27235 235 D-60329 Frankfurt Mail : baess at denic.de From pekkas at netcore.fi Tue Nov 8 02:43:59 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 8 Nov 2005 03:43:59 +0200 (EET) Subject: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: References: Message-ID: On Tue, 1 Nov 2005, Andreas B??/Denic wrote: >>>> 4. Allocate /48 to primary hu DNS server that is globally routable? >>>> Are there similar to /48 from 2001:0500::/30 in RIPE region? >>>> >>>> - I think this is the cleanest solution. >>>> >>>> Can we discuss this issue on the working group or mailing lists? >>>> >>>> I saw a proposal: http://www.ripe.net/ripe/policies/proposals/2005-2.html >>>> >>>> In my opinion this can solve the problem.... > > I have not seen any discussions that think it is a bad idea to > assign several network resources to TLD administrators which will > enable them to operate their nameservers according to RFC3258. > > When we have reviewed the discussions we felt that your objection > against the proposal was because of the size of the assignment. I'm > planning to submit revised proposal with a reduced prefix length > which better fits with other assignment policies. If you are > opposing to the new proposal I would be glad to know as soon as it > is submitted. Yes. Let me clarify my objections: 1) special policy for ccTLDs (if they do not anycast) is not IMHO needed as assignments from (some of the) transits should be enough; 2) special policy for any arbitrary service, if anycast, does not seem justified because it's too open-ended; 3) ccTLD combined with requirement to anycast it appears to be suitably well justified operationally and technically. In addition, a) we have enough address space that allocating a (v6) /32 is not waste. b) I'm strongly opposed to creating any special micro-allocation blocks which is just waiting for getting the worms out hence a). So, I'd say that if the policy proposal is 3) with a (v6) /32, I shouldn't have a problem with it. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From baess at denic.de Thu Nov 10 10:46:48 2005 From: baess at denic.de (Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?=) Date: Thu, 10 Nov 2005 10:46:48 +0100 Subject: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: Message-ID: Dear Pekka, > Yes. Let me clarify my objections: > 1) special policy for ccTLDs (if they do not anycast) is not > IMHO needed as assignments from (some of the) transits should be > enough; I agree that if a DNS operator is below a certain limit of DNS servers he does not have the need for anycast at all. But once you grow your farm beyond a limit anycast is the current best solution. DENIC for example had 11 different NS before we have started to deploy anycast to further enhance network diversity and capacity and simultaniously introducing AAAA records for our nameservers. > 2) special policy for any arbitrary service, if anycast, does not > seem justified because it's too open-ended; In my first presentation I have voted for a more open policy. However I have seen no acceptance to this approach as the process of defining a network critical resource would take too long while I felt consensus that TLD nameservers are critical enough to justify special treatment. So I wrote a policy proposal that is only applicable for TLD nameservers. Why do you think this is open ended? > 3) ccTLD combined with requirement to anycast it appears to be > suitably well justified operationally and technically. I have not limited my proposal to ccTLDs but includes any TLD. > In addition, > a) we have enough address space that allocating a (v6) /32 is not > waste. If you have seen the updated version of my proposal I hope you will not see any problem iwth a /48 prefix. > b) I'm strongly opposed to creating any special micro-allocation > blocks which is just waiting for getting the worms out hence a). I don't see why you think that it is a bad idea to do the assignments for anycasted nameservers from a bigger block. Can you explain what makes the difference from spreading them all over the address range. Sounds like a security through obscurity approach to me. I haven't made a suggestion on how RIPE should manage their microallocation assignments. From my personal experience I would be an favour of a microallocation block as this bundles the efforts to eliminate routing problems that might exist. > So, I'd say that if the policy proposal is 3) with a (v6) /32, I > shouldn't have a problem with it. As said before, it is a superset of 3. with /48 V6 prefixes. Maybe it's best to take a quick look at the current proposal. Regards Andreas Baess From jorgen at hovland.cx Thu Nov 10 12:28:10 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Thu, 10 Nov 2005 12:28:10 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: Message-ID: <200511101128.jAABSApQ007741@mail03.hipercom.no> Hi, I would like to comment on this topic. --- From: Andreas B??/Denic Date: Mon, 4 Apr 2005 18:18:22 +0200 >1. Is there a need for anycasting at all ? > >I was surprised to see this question on the list. >I think that anycasted nameservers are an accepted standard and there >is no need to discuss pros and cons anymore. If anycasting involves creating special prefix allocation policies, then I am 100% against anycast. We are currently running anycast on our own nameservers, but we don't require our own v4 or v6 prefix just for that. I don't see why you can't do the same with your already 11 nameservers (on 11 networks?), but maybe that's just me. Furthermore, nameservers should not be specially treated. It is impossible to define what is important and what is not (like defining what spam is). The only anycast service at all I would be willing to exempt is root nameservers and give them their own prefix if needed. Nothing, and by nothing I mean any service (dns, web, mail etc), is justified for their own anycast prefix unless you can implement it with standard allocation policies. Microallocations might be a standard allocation policy. What I don't want to see is that RIRs hand out microallocations for the sole purpose of running anycast. Then I would probably be asking for at least 50 microallocations just for myself, oh pretty please. I am therefore against any proposal about anycast prefix allocations no matter whom and what it concerns. Do whatever you want between your peers if your agreement permits; just don?t put the prefix in the dfz. I don't think it belongs there. Thank you, Joergen Hovland -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Andreas B??/Denic Dear Pekka, > Yes. Let me clarify my objections: > 1) special policy for ccTLDs (if they do not anycast) is not > IMHO needed as assignments from (some of the) transits should be > enough; I agree that if a DNS operator is below a certain limit of DNS servers he does not have the need for anycast at all. But once you grow your farm beyond a limit anycast is the current best solution. DENIC for example had 11 different NS before we have started to deploy anycast to further enhance network diversity and capacity and simultaniously introducing AAAA records for our nameservers. > 2) special policy for any arbitrary service, if anycast, does not > seem justified because it's too open-ended; In my first presentation I have voted for a more open policy. However I have seen no acceptance to this approach as the process of defining a network critical resource would take too long while I felt consensus that TLD nameservers are critical enough to justify special treatment. So I wrote a policy proposal that is only applicable for TLD nameservers. Why do you think this is open ended? > 3) ccTLD combined with requirement to anycast it appears to be > suitably well justified operationally and technically. I have not limited my proposal to ccTLDs but includes any TLD. > In addition, > a) we have enough address space that allocating a (v6) /32 is not > waste. If you have seen the updated version of my proposal I hope you will not see any problem iwth a /48 prefix. > b) I'm strongly opposed to creating any special micro-allocation > blocks which is just waiting for getting the worms out hence a). I don't see why you think that it is a bad idea to do the assignments for anycasted nameservers from a bigger block. Can you explain what makes the difference from spreading them all over the address range. Sounds like a security through obscurity approach to me. I haven't made a suggestion on how RIPE should manage their microallocation assignments. From my personal experience I would be an favour of a microallocation block as this bundles the efforts to eliminate routing problems that might exist. > So, I'd say that if the policy proposal is 3) with a (v6) /32, I > shouldn't have a problem with it. As said before, it is a superset of 3. with /48 V6 prefixes. Maybe it's best to take a quick look at the current proposal. Regards Andreas Baess From he at uninett.no Thu Nov 10 15:53:25 2005 From: he at uninett.no (Havard Eidnes) Date: Thu, 10 Nov 2005 15:53:25 +0100 (CET) Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <200511101128.jAABSApQ007741@mail03.hipercom.no> References: <200511101128.jAABSApQ007741@mail03.hipercom.no> Message-ID: <20051110.155325.51808449.he@uninett.no> > [...] > I am therefore against any proposal about anycast prefix > allocations no matter whom and what it concerns. Do whatever > you want between your peers if your agreement permits; just > don't put the prefix in the dfz. I don't think it belongs > there. Hear, hear! Concisely put. Regards, - H?vard From Michael.Dillon at btradianz.com Fri Nov 11 15:09:30 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 11 Nov 2005 14:09:30 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <200511101128.jAABSApQ007741@mail03.hipercom.no> Message-ID: > I am therefore against any proposal about anycast prefix allocations no > matter whom and what it concerns. Do whatever you want between your peers > if your agreement permits; just don?t put the prefix in the dfz. I don't > think it belongs there. I think that some anycast prefixes *DO* belong in the dfz. However, I think that it is wrong to give out anycast prefix allocations to organizations whose only intent is to run their own internal services. The .de TLD is proposing that they should get a prefix just for their own anycast services. Instead, I think that RIPE and other RIRs should give out a small number of prefix allocations to "network operators" who intend to run anycast network services for their customers. Does anyone see the parallel with Internet access network operators who run networks to provide Internet access to their customers? In theory, an anycast operator will sell anycast services to other organizations. Those organizations will place their servers in facilities where the anycast operator has some kind of presence, i.e. a router and a rack. The organizations such as DENIC, will receive a *SUBSET* of the anycast prefix for their servers but that subset will not be visible outside of the anycast operator's network. If customers, such as DENIC, do not feel that a single anycast network operator can supply the coverage that they require then they can buy services from more than one anycast network operator. It is interesting to note that domain hosting uses the DNS protocol which allows for a server to have up to 13 unique IP addresses. Theoretically a domain hosting company like DENIC could use the services of 13 different anycast operators. If a company like DENIC was willing to sign an undertaking with RIPE that they would offer the use of their own anycast architecture commercially to other organizations, then DENIC should also be able to qualify for an anycast prefix allocation. --Michael Dillon From jorgen at hovland.cx Fri Nov 11 17:20:44 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Fri, 11 Nov 2005 17:20:44 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: Message-ID: <30507014-1131726357@hovland.cx> -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Michael.Dillon at btradianz.com Sent: 11. november 2005 15:10 >> I am therefore against any proposal about anycast prefix allocations no >> matter whom and what it concerns. Do whatever you want between your >>peers >> if your agreement permits; just don?t put the prefix in the dfz. I don't >> think it belongs there. > >I think that some anycast prefixes *DO* belong in the dfz. >However, I think that it is wrong to give out anycast >prefix allocations to organizations whose only intent >is to run their own internal services. The .de TLD is >proposing that they should get a prefix just for their >own anycast services. We are probably thinking the same but have two different solutions for it. If you have a medium/large international network you can implement anycast without using prefixes assigned to you by the RIR for anycast usage. If you do not have a medium/large international network then you can contact someone who has. If this is a question about money then I am sure some network operator eventually will lower their prices to meet your satisfaction. Company X/DENIC may contact company Y/MCI. MCI may place 500 DENIC servers around the world at their collocation facilities. MCI may then assign DENIC one /64 prefix from their /32 prefix which will be routed to the closest DENIC server in MCIs network. Would this be a suitable solution? This /32 has not been given to MCI by the RIR explicit for anycast purposes. The other solution is that DENIC builds their own international network and do the same - as long as the prefix has not been given to DENIC by the RIR solely for anycast purposes. Cheers, Joergen Hovland From gert at space.net Fri Nov 11 19:01:46 2005 From: gert at space.net (Gert Doering) Date: Fri, 11 Nov 2005 19:01:46 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <30507014-1131726357@hovland.cx> References: <30507014-1131726357@hovland.cx> Message-ID: <20051111180146.GG69925@Space.Net> Hi, On Fri, Nov 11, 2005 at 05:20:44PM +0100, J?rgen Hovland wrote: > Company X/DENIC may contact company Y/MCI. MCI may place 500 DENIC servers > around the world at their collocation facilities. MCI may then assign DENIC > one /64 prefix from their /32 prefix which will be routed to the closest > DENIC server in MCIs network. > Would this be a suitable solution? This /32 has not been given to > MCI by the RIR explicit for anycast purposes. I'm not sure whether you understand what this is all about. DENIC is providing a public service (namely: DNS for the .de TLD) - and *the whole world* wants to reach their DNS servers. (No different to .com and other large TLDs) Due to the fact that DNS has packet size limits (the DNS WG says so, and it's not the address policy WG's job to know DNS better than the DNS WG), anycast is a necessary workaround if a DNS operator wants to increase reliability and reachability for their DNS servers - after they have exhausted all other options (like "using very short server names" and so on). So where's the benefit if DENIC sets up something inside MCI's network that only MCI customers can see? And *if* the route is leaked outside, what is gained, except people will have to maintain explicit white-lists ("hey, this /64 is DENIC-anycast, so we permit it, while not permitting other /64s")? I don't really understand what you are worrying about, and why, and how this "solution" is going to help anyone. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From jorgen at hovland.cx Fri Nov 11 20:01:36 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Fri, 11 Nov 2005 20:01:36 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051111180146.GG69925@Space.Net> Message-ID: <33177606-1131736010@hovland.cx> -----Original Message----- From: Gert Doering [mailto:gert at space.net] Sent: 11. november 2005 19:02 >So where's the benefit if DENIC sets up something inside MCI's network >that only MCI customers can see? And *if* the route is leaked outside, >what is gained, except people will have to maintain explicit white-lists >("hey, this /64 is DENIC-anycast, so we permit it, while not permitting >other /64s")? I will try to explain more detailed: A large network provider can have hundreds/thousands of peers. These peers receive the same /32 prefix. A large network provider has housing facilities many places in many countries. * Put your server in some or all of these housing facilities. * Give every server the same IP address. * Tell large network provider to use the closest path and make a route to this IP address where you have your servers (use a routing protocol or whatever) * The peers of large network provider will be routed to the closest DENIC server in large network providers network. * If a server is down, the next closest DENIC server will get the traffic. * There is no single point of failure here. * You are using anycast. * You have a multiple failover solution. I hope this was clear enough. Cheers, Joergen Hovland From jorgen at hovland.cx Fri Nov 11 20:01:36 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Fri, 11 Nov 2005 20:01:36 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051111180146.GG69925@Space.Net> Message-ID: <33177606-1131736010@hovland.cx> -----Original Message----- From: Gert Doering [mailto:gert at space.net] Sent: 11. november 2005 19:02 >So where's the benefit if DENIC sets up something inside MCI's network >that only MCI customers can see? And *if* the route is leaked outside, >what is gained, except people will have to maintain explicit white-lists >("hey, this /64 is DENIC-anycast, so we permit it, while not permitting >other /64s")? I will try to explain more detailed: A large network provider can have hundreds/thousands of peers. These peers receive the same /32 prefix. A large network provider has housing facilities many places in many countries. * Put your server in some or all of these housing facilities. * Give every server the same IP address. * Tell large network provider to use the closest path and make a route to this IP address where you have your servers (use a routing protocol or whatever) * The peers of large network provider will be routed to the closest DENIC server in large network providers network. * If a server is down, the next closest DENIC server will get the traffic. * There is no single point of failure here. * You are using anycast. * You have a multiple failover solution. I hope this was clear enough. Cheers, Joergen Hovland From gert at space.net Fri Nov 11 22:06:06 2005 From: gert at space.net (Gert Doering) Date: Fri, 11 Nov 2005 22:06:06 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <17268.59536.75539.506928@roam.psg.com> References: <30507014-1131726357@hovland.cx> <20051111180146.GG69925@Space.Net> <17268.59536.75539.506928@roam.psg.com> Message-ID: <20051111210606.GH69925@Space.Net> Hi, On Fri, Nov 11, 2005 at 08:53:04AM -1000, Randy Bush wrote: > > DENIC is providing a public service (namely: DNS for the .de TLD) - and > > *the whole world* wants to reach their DNS servers. (No different > > to .com and other large TLDs) > > or anywhere else in the dns tree, tends of thousands of servers Yes. I think we can agree that there are lots of domain service providers that have 2, 3, maybe 5 name servers in their NS set (and those can grow without anycasting), and that there are some that really use up all that you can fit in those small packets, and want to provide even *more* resiliency. Looking at DNS, I see "lots of nameservers" primarily for root, and some gTLD/ccTLD zones. Haven't seen that for "further down" stuff (.co.uk is "sort of ccTLD" stuff). And really - I don't care who they are and what they do, but if they think it's a good thing to have more than 11 different primary name servers for whatever they are hosting, it must be important to them, and at leat to whoever is providing the funding. > but i am sure denic is very important The second largest DNS zone in the world *does* sound somewhat important to me. I don't have query numbers to compare .com and .de requests/second (which would be more useful than sheer zone size), but I'd assume that there are also plenty of request for .de domains. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From jorgen at hovland.cx Fri Nov 11 23:44:40 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Fri, 11 Nov 2005 23:44:40 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051111210606.GH69925@Space.Net> Message-ID: <200511112244.jABMiYpQ011727@mail03.hipercom.no> Some final comments from me, -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Gert Doering Sent: 11. november 2005 22:06 >Yes. I think we can agree that there are lots of domain service >providers that have 2, 3, maybe 5 name servers in their NS set (and those >can grow without anycasting), and that there are some that really use >up all that you can fit in those small packets, and want to provide >even *more* resiliency. Looking at DNS, I see "lots of nameservers" >primarily for root, and some gTLD/ccTLD zones. Haven't seen that for >"further down" stuff (.co.uk is "sort of ccTLD" stuff). Gert, you can configure 1000 anycast servers, all with the same IP address, in your own network no matter how small/large your network is. You can place them next to each other on the same rack or you can place 500 of them in your Frankfurt serverhall and 500 in D?sseldorf as long as they are in your network. You do _not_ need an anycast prefix from your RIR for this. Your growth problem is now solved. The next problem is that you want better redundancy(?). Then buy more connectivity. If you for some reason can't afford better connectivity, please look at my MCI example and put your servers elsewhere. >And really - I don't care who they are and what they do, but if they >think it's a good thing to have more than 11 different primary name >servers for whatever they are hosting, it must be important to them, >and at least to whoever is providing the funding. > >The second largest DNS zone in the world *does* sound somewhat important >to me. I don't have query numbers to compare .com and .de requests/second >(which would be more useful than sheer zone size), but I'd assume that >there are also plenty of request for .de domains. If it wasn't for the fact that I do business in Germany I couldn't care less if .de was dead or not. You can only decide what is important to you, not for the rest of the crowd. If you try you will find out that everything is important. To cover everyones needs we would need 42 billion prefixes in the global routing table. Most of it wouldn't make sense anyway, just like this anycast discussion is starting to get. Cheers, Joergen Hovland From gert at space.net Sat Nov 12 08:43:23 2005 From: gert at space.net (Gert Doering) Date: Sat, 12 Nov 2005 08:43:23 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <200511112244.jABMiYpQ011727@mail03.hipercom.no> References: <20051111210606.GH69925@Space.Net> <200511112244.jABMiYpQ011727@mail03.hipercom.no> Message-ID: <20051112074323.GL69925@Space.Net> Hi, On Fri, Nov 11, 2005 at 11:44:40PM +0100, J?rgen Hovland wrote: > >Yes. I think we can agree that there are lots of domain service > >providers that have 2, 3, maybe 5 name servers in their NS set (and those > >can grow without anycasting), and that there are some that really use > >up all that you can fit in those small packets, and want to provide > >even *more* resiliency. Looking at DNS, I see "lots of nameservers" > >primarily for root, and some gTLD/ccTLD zones. Haven't seen that for > >"further down" stuff (.co.uk is "sort of ccTLD" stuff). > > Gert, you can configure 1000 anycast servers, all with the same IP address, > in your own network no matter how small/large your network is. That's the point. DENIC isn't doing this for themselves. They do this for *you* (and for me, and even for Randy). So putting up the anycast servers somewhere where half of the internet might not see them is not useful. For maximum resiliency (against DoS and outages), one wants to spread the anycast servers over as many different (!) networks as possible. And this cannot be done without a dedicated prefix for it. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Sat Nov 12 09:26:21 2005 From: gert at space.net (Gert Doering) Date: Sat, 12 Nov 2005 09:26:21 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <17269.40789.639973.680372@roam.psg.com> References: <20051111210606.GH69925@Space.Net> <200511112244.jABMiYpQ011727@mail03.hipercom.no> <20051112074323.GL69925@Space.Net> <17269.40789.639973.680372@roam.psg.com> Message-ID: <20051112082621.GM69925@Space.Net> Hi, On Fri, Nov 11, 2005 at 09:52:53PM -1000, Randy Bush wrote: > > That's the point. DENIC isn't doing this for themselves. They > > do this for *you* > > in a peer2peer or client/server world, this statement is fatuous So we abandon DNS, because it's a model from the last century? (Now that would be a policy proposal for the DNS WG, not for address policy -- but I'm all for it, this whole hassle with "finding a free domain name" and "going to court with name right holders" and so on is really annoying) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From hph at oslo.net Sun Nov 13 00:29:53 2005 From: hph at oslo.net (Hans Petter Holen) Date: Sun, 13 Nov 2005 00:29:53 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <200511112244.jABMiYpQ011727@mail03.hipercom.no> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> Message-ID: <43767AF1.4000302@oslo.net> J?rgen Hovland wrote: > The next problem is that you want better redundancy(?). Then buy more > connectivity. If you for some reason can't afford better connectivity, > please look at my MCI example and put your servers elsewhere. > > What if I want to plan for more disasters than that ? Like MCI going out of business? I guess I could agree with MCI to place some servers with their IP addresses outside their network and agree with other providers to carry my more specific routes. In order to have universal access and plan for any network failure I would have to sign such agreement with all ISPs. This could be a business idea for somebody: to set up an "anycast registry" - sign agreement with all the major ISPs to not aggregate my addresses. Then I could offer a guaranteed minimum routability for thoose prefixes. What we are discussing is really to make this mechanism available by addressing policy. Traditionally the RIRs does not set routing policy. Hans Petter From jorgen at hovland.cx Sun Nov 13 15:20:31 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Sun, 13 Nov 2005 15:20:31 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <43767AF1.4000302@oslo.net> Message-ID: <200511131420.jADEKNpQ013501@mail03.hipercom.no> -----Original Message----- From: Hans Petter Holen [mailto:hph at oslo.net] Sent: 13. november 2005 00:30 >What if I want to plan for more disasters than that ? Like MCI going out >of business? Hi, If you honestly believe that all 11 internet service providers which you are running your nameservers with (these 11 also run anycast and have multiple servers each) at the exact same time will go bankrupt and shutdown their network at around the same time then I don't think it is the nameservers we should worry about but the internet itself. >I guess I could agree with MCI to place some servers with their IP >addresses outside their network and agree with other providers to carry >my more specific routes. In order to have universal access and plan for >any network failure I would have to sign such agreement with all ISPs. > Will it not satisfy your needs placing 200 servers at 100 (numbers randomly selected) MCI locations world wide using IP space assigned by MCIs /32? Or is this discussion simply about the fact that the /32 prefix is not yours and you want to use your "own"? Take the following: 1 server at ISP x in London. /32 announced by ISP x's ASN. Your ip is assigned from this /32. 1 server at ISP x in Amsterdam. /32 announced by ISP x's ASN. Your ip is assigned from this /32. and 1 server at ISP g in London. /32 announced by your ASN through ISP g. It is your /32 1 server at ISP k in Amsterdam. /32 announced by your ASN through ISP k. It is your /32 What is really the difference here? Yes, ISP x, g or k can go bankrupt so you loose that redundancy in the first scenario. Any others? I can't think of any. Either way, there is no difference here network wise? You get exactly the same reachability/redundancy. So, should we alter the address policy because ISP x can go bankrupt and we need redundancy for that? You still have 10 more ISPs you have placed your servers at if you use all 11 IPs. >This could be a business idea for somebody: to set up an "anycast >registry" - sign agreement with all the major ISPs to not aggregate my >addresses. Then I could offer a guaranteed minimum routability for >thoose prefixes. > For medium/large operators that wouldn't make any sense at all since they already have a global network and can do fully redundant anycasting anytime with any IP address. For smaller ones it might. Conclusion: I am against a policy that would let LIRs receive prefixes from RIRs when the intention is to use the prefix for anycast. I have hopefully shown that you don't need a dedicated prefix for that. It is a bad hack to the existing solution and as I see it, would give the same benefits. This bad hack is one thing. I am sure everyone can agree on that it is impossible to decide whom and what services should be granted anycast prefixes if it was accepted. The only solution would be to permit everyone or have some rule saying "you must have more than N anycast servers at Y locations" which basically again means that everyone can and will get a prefix. I am not against 42 billion prefixes in dfz. I am sure we will get there eventually:) I am however against the ones that don't make any sense. Cheers, Joergen Hovland From kurtis at kurtis.pp.se Sun Nov 13 15:32:24 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Sun, 13 Nov 2005 15:32:24 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <200511131420.jADEKNpQ013501@mail03.hipercom.no> References: <200511131420.jADEKNpQ013501@mail03.hipercom.no> Message-ID: <80F7DFEA-67E6-46B1-9D8D-EF6864FC3728@kurtis.pp.se> On 13 nov 2005, at 15.20, J?rgen Hovland wrote: > Take the following: > > 1 server at ISP x in London. /32 announced by ISP x's ASN. Your ip is > assigned from this /32. > 1 server at ISP x in Amsterdam. /32 announced by ISP x's ASN. Your > ip is > assigned from this /32. > > and > > 1 server at ISP g in London. /32 announced by your ASN through ISP > g. It is > your /32 > 1 server at ISP k in Amsterdam. /32 announced by your ASN through > ISP k. It > is your /32 > > > What is really the difference here? Yes, ISP x, g or k can go > bankrupt so > you loose that redundancy in the first scenario. Any others? I > can't think > of any. Either way, there is no difference here network wise? You get > exactly the same reachability/redundancy. So, should we alter the > address > policy because ISP x can go bankrupt and we need redundancy for > that? You > still have 10 more ISPs you have placed your servers at if you use > all 11 > IPs. In the first scenario you are forced to the routing policies of ISP x and only to the locations of ISP x. In the second example you can co- locate, connect to and IXP and do your own routing decisions as well as be present at locations you choose (without "vasting" or even having to go to 11 servers). - kurtis - From jorgen at hovland.cx Sun Nov 13 16:47:14 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Sun, 13 Nov 2005 16:47:14 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <80F7DFEA-67E6-46B1-9D8D-EF6864FC3728@kurtis.pp.se> Message-ID: <200511131547.jADFl5pQ015856@mail03.hipercom.no> Hi, -----Original Message----- From: Kurt Erik Lindqvist [mailto:kurtis at kurtis.pp.se] Sent: 13. november 2005 15:32 >In the first scenario you are forced to the routing policies of ISP x >and only to the locations of ISP x. In the second example you can co- >locate, connect to and IXP and do your own routing decisions as well >as be present at locations you choose (without "vasting" or even >having to go to 11 servers). You will always be forced to obey the rules of whatever provider you are using, ISP or IXP. I get the impression that you believe ISP x's routing policies will always be insufficient for you. Nameservers are not the only anycast service so it would be tricky to discuss this in general. But you want your nameserver to be reachable, that I know. Both scenarios will accomplish that with the same amount of redundancy. What kind of routing policies do you mean? Do you want to restrict your reachability? Joergen Hovland From jorgen at hovland.cx Sun Nov 13 17:22:37 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Sun, 13 Nov 2005 17:22:37 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <43775E10.3020604@cc.univie.ac.at> Message-ID: <200511131622.jADGMSpQ016583@mail03.hipercom.no> -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Wilfried Woeber, UniVie/ACOnet Hi Wilfried, >From that perspective I seem to see 2 aspects in the recent discussion: > >- you shall not receive address space for builing a service, you are to > buy that from some "big-folk". > > This is an intersting point of view, and taken to the extreme will > make us end up with a _very small_ number of _very big_ entities. > > Traditionally these things were called monopolies. Nothing I would be > too happy to see coming back ;-) > >- there has been th discussion regarding "anycast" but isnt this just > a special(?) case of th PI-topic? You are right; the differences between PI and anycast are few. Perhaps it would be a (good?) idea to merge the anycast and PI discussion into a single discussion instead. > This is an intersting point of view, and taken to the extreme will > make us end up with a _very small_ number of _very big_ entities. Strictly speaking; All you need to do is to create a network and ask for address space. The "anycasters" won't even do that. They want the address space without the network. That is what I don't support. Joergen Hovland From kurtis at kurtis.pp.se Sun Nov 13 18:34:06 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Sun, 13 Nov 2005 18:34:06 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <200511131547.jADFl5pQ015856@mail03.hipercom.no> References: <200511131547.jADFl5pQ015856@mail03.hipercom.no> Message-ID: On 13 nov 2005, at 16.47, J?rgen Hovland wrote: > From: Kurt Erik Lindqvist [mailto:kurtis at kurtis.pp.se] > Sent: 13. november 2005 15:32 > > >> In the first scenario you are forced to the routing policies of ISP x >> and only to the locations of ISP x. In the second example you can co- >> locate, connect to and IXP and do your own routing decisions as well >> as be present at locations you choose (without "vasting" or even >> having to go to 11 servers). >> > > You will always be forced to obey the rules of whatever provider > you are > using, ISP or IXP. I get the impression that you believe ISP x's > routing > policies will always be insufficient for you. Nameservers are not > the only > anycast service so it would be tricky to discuss this in general. > But you want your nameserver to be reachable, that I know. Both > scenarios > will accomplish that with the same amount of redundancy. What kind of > routing policies do you mean? Do you want to restrict your > reachability? If you are connected to the IXP with your own peerings, you will have control of the routing policies. If you host with ISP x, you will have to follow ISP x peerings and depeerings. You claimed the two cases to be equal. I just pointed out that they are not. - kurtis - From elmi at 4ever.de Fri Nov 11 19:27:38 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Fri, 11 Nov 2005 19:27:38 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <30507014-1131726357@hovland.cx> References: <30507014-1131726357@hovland.cx> Message-ID: <20051111182738.GC22271@new.detebe.org> jorgen at hovland.cx (J?rgen Hovland) wrote: > Company X/DENIC may contact company Y/MCI. MCI may place 500 DENIC servers > around the world at their collocation facilities. MCI may then assign DENIC > one /64 prefix from their /32 prefix which will be routed to the closest > DENIC server in MCIs network. > Would this be a suitable solution? This /32 has not been given to > MCI by the RIR explicit for anycast purposes. Vendor/ISP dependence has never been a solution for better availability. Michael and you are somewhat off the track IMHO. Read Gert's comment, too. Yours, Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From randy at psg.com Fri Nov 11 19:53:04 2005 From: randy at psg.com (Randy Bush) Date: Fri, 11 Nov 2005 08:53:04 -1000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? References: <30507014-1131726357@hovland.cx> <20051111180146.GG69925@Space.Net> Message-ID: <17268.59536.75539.506928@roam.psg.com> > DENIC is providing a public service (namely: DNS for the .de TLD) - and > *the whole world* wants to reach their DNS servers. (No different > to .com and other large TLDs) or anywhere else in the dns tree, tends of thousands of servers but i am sure denic is very important randy From randy at psg.com Sat Nov 12 08:52:53 2005 From: randy at psg.com (Randy Bush) Date: Fri, 11 Nov 2005 21:52:53 -1000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? References: <20051111210606.GH69925@Space.Net> <200511112244.jABMiYpQ011727@mail03.hipercom.no> <20051112074323.GL69925@Space.Net> Message-ID: <17269.40789.639973.680372@roam.psg.com> > That's the point. DENIC isn't doing this for themselves. They > do this for *you* in a peer2peer or client/server world, this statement is fatuous randy From randy at psg.com Sat Nov 12 14:12:47 2005 From: randy at psg.com (Randy Bush) Date: Sat, 12 Nov 2005 03:12:47 -1000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? References: <20051111210606.GH69925@Space.Net> <200511112244.jABMiYpQ011727@mail03.hipercom.no> <20051112074323.GL69925@Space.Net> <17269.40789.639973.680372@roam.psg.com> <20051112082621.GM69925@Space.Net> Message-ID: <17269.59983.585022.797869@roam.psg.com> >>> That's the point. DENIC isn't doing this for themselves. They >>> do this for *you* >> in a peer2peer or client/server world, this statement is fatuous > So we abandon DNS, because it's a model from the last century? you can if you want to. i did not suggest doing so, so i guess you would like to. whatever rocks your boat. my point was simple, aside from the total end user (ones not running edonkey or having bought sony cds), most hosts provide to others, certainly all interesting hosts. while folk who need to look up in the de namespace appreciate what denic does, i don't think they do it for free. so we'll withold the gold medals if you don't mind. randy From woeber at cc.univie.ac.at Sun Nov 13 16:38:56 2005 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Sun, 13 Nov 2005 15:38:56 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <43767AF1.4000302@oslo.net> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> Message-ID: <43775E10.3020604@cc.univie.ac.at> Having listened for a while 'cause I am neither an expert in anycasting nor in running name services for a large zone, I'd like to step back a couple of yards/meters/. >From that perspective I seem to see 2 aspects in the recent discussion: - you shall not receive address space for builing a service, you are to buy that from some "big-folk". This is an intersting point of view, and taken to the extreme will make us end up with a _very small_ number of _very big_ entities. Traditionally these things were called monopolies. Nothing I would be too happy to see coming back ;-) - there has been th discussion regarding "anycast" but isnt this just a special(?) case of th PI-topic? I might easily have overlooked something, pls. see my initial disclaimer. Wilfried. Hans Petter Holen wrote: > J?rgen Hovland wrote: > >>The next problem is that you want better redundancy(?). Then buy more >>connectivity. If you for some reason can't afford better connectivity, >>please look at my MCI example and put your servers elsewhere. >> >> > > What if I want to plan for more disasters than that ? Like MCI going out > of business? > > I guess I could agree with MCI to place some servers with their IP > addresses outside their network and agree with other providers to carry > my more specific routes. In order to have universal access and plan for > any network failure I would have to sign such agreement with all ISPs. > > This could be a business idea for somebody: to set up an "anycast > registry" - sign agreement with all the major ISPs to not aggregate my > addresses. Then I could offer a guaranteed minimum routability for > thoose prefixes. > > What we are discussing is really to make this mechanism available by > addressing policy. Traditionally the RIRs does not set routing policy. > > Hans Petter > > _______________________________________________ > ipv6 mailing list > ipv6 at ls.aco.net > http://noc.aco.net/mailman/listinfo/ipv6 > From jorgen at hovland.cx Mon Nov 14 10:51:58 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Mon, 14 Nov 2005 10:51:58 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051114083147.GG96756@new.detebe.org> Message-ID: <200511140951.jAE9pwpQ007320@mail03.hipercom.no> -----Original Message----- From: Elmar K. Bins [mailto:elmi at 4ever.de] > Hello J?rgen, Hello >> Will it not satisfy your needs placing 200 servers at 100 (numbers randomly >> selected) MCI locations world wide using IP space assigned by MCIs /32? > >Certainly not - why should one be satisfied with such a pseudo-solution? Because that?s what everybody else are doing? That?s why we currently have 600 routes in dfz and not one per server on the internet? Should DNS be excused only because the protocol itself supports a finite amount of IP addresses? >A service provider (we _are_ talking about Internet infrastructure service >providers currently, keep that in mind) that has come to the conclusion >they want to "anycast" (aka shared unicast) their services, surely has >thought about going to a big ISP before and decided that that' not what >they want. Ok, but I would still like to hear from people who have tried that but had to reject the solution for valid reasons where the ISP offered you this service. Anyone? >> Either way, there is no difference here network wise? You get >> exactly the same reachability/redundancy. > >Only if you limit your thoughts to a very small world. Sorry, but >the fallacy of your argument is so obvious that the words fail me here. Could you be more specific? I am sure there are ISPs that are not willing to sell anycast services, but if you have buyers then the sellers will always show up eventually. >> I am against a policy that would let LIRs receive prefixes from RIRs when >> the intention is to use the prefix for anycast. I have hopefully shown that >> you don't need a dedicated prefix for that. > > No. You have shown that _you_ don't need that. Obviously some people have different needs. It is good that we try to figure those out. > You try to decide here how > other people run their services. No, I am trying to prevent excessive defragmentation of the routing table. I am trying to prevent a special case of PI where you are not even required to have your own network. The requirement to this special PI case is so low that anyone would be able to apply for it - and anyone _will_ apply for it. In order to prevent that we only permit DNS? Are there any other services that should be permitted? > I honestly believe that's none of your > business, but up to the respective service provider. You can give them > good advice, of course. But you must be open to accepting arguments for > the way they intend to do it. So far we have two reasons why anycast prefixes, "anycast PI", should be permitted: * Bankruptcy * Routing policies >> Nameservers are not the only >> anycast service so it would be tricky to discuss this in general. > >DNS is a special service (UDP packet size stuff) and needs a special >solution - unfortunately. I disagree. DNS is certainly not a special service. The importance of it is however perhaps greater than many others - many, but far from all. The packet size thing is a general design problem. As far as I know, there are currently two methods to solve it: * EDNS0 * TC flag If you are going to use the packet size problem as an argument to use anycast, then I think it would be a good idea to hear reasons why none of these solutions would be suitable (also because I don't really know it myself) and perhaps if there are any other solutions that would help solving the problem? > >From that perspective I seem to see 2 aspects in the recent discussion: > > > >- you shall not receive address space for builing a service, you are to > > buy that from some "big-folk". > > > > This is an intersting point of view, and taken to the extreme will > > make us end up with a _very small_ number of _very big_ entities. > > > > Traditionally these things were called monopolies. Nothing I would be > > too happy to see coming back ;-) > > You did not comment on this part. Why? I was probably just a bit unclear. "All you need to do is to create a network and ask for address space.." There is no monopoly threat as long as you follow the requirements. If the requirements are too strict, then it would become a problem. Currently, I think they are not. Joergen Hovland From jorgen at hovland.cx Mon Nov 14 12:19:05 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Mon, 14 Nov 2005 12:19:05 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051114101211.GK96756@new.detebe.org> Message-ID: <200511141119.jAEBJ5pQ011498@mail03.hipercom.no> -----Original Message----- From: Elmar K. Bins [mailto:elmi at 4ever.de] >But you're trying to lure us away from the proposal we're discussing which >states a special case of DNS for _ccTLDs... > >The requirements for v6 space in the RIPE region includes having transit >customers (at all, the 200 is just an arbitrary number). No ccTLD registry >that's not also conducting other business may receive an allocation. That's >the entire point of the special case being made. ccTLDs cannot deliver >services in v6 like in v4. This - IMHO - is a v6 showstopper. So we are back at the beginning; I say no to anycast PI for TLDs/ccTLDs. I don't believe it is a special case so it doesn't need a special policy. TLDs/ccTLDs could/should however be used as an argument to allow v6 PI prefixes in general. V6 PI compared to v4 surely is a showstopper for many, or at least for some. Cheers, Joergen Hovland From elmi at 4ever.de Mon Nov 14 09:31:47 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Mon, 14 Nov 2005 09:31:47 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <200511131622.jADGMSpQ016583@mail03.hipercom.no> <200511131547.jADFl5pQ015856@mail03.hipercom.no> <200511131420.jADEKNpQ013501@mail03.hipercom.no> References: <43775E10.3020604@cc.univie.ac.at> <200511131622.jADGMSpQ016583@mail03.hipercom.no> <80F7DFEA-67E6-46B1-9D8D-EF6864FC3728@kurtis.pp.se> <200511131547.jADFl5pQ015856@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <200511131420.jADEKNpQ013501@mail03.hipercom.no> Message-ID: <20051114083147.GG96756@new.detebe.org> Hello J?rgen, my responses to three emails from you to the lists, jorgen at hovland.cx (J?rgen Hovland) wrote: > Will it not satisfy your needs placing 200 servers at 100 (numbers randomly > selected) MCI locations world wide using IP space assigned by MCIs /32? Certainly not - why should one be satisfied with such a pseudo-solution? A service provider (we _are_ talking about Internet infrastructure service providers currently, keep that in mind) that has come to the conclusion they want to "anycast" (aka shared unicast) their services, surely has thought about going to a big ISP before and decided that that' not what they want. > Or is this discussion simply about the fact that the /32 prefix is not yours > and you want to use your "own"? It is - currently, talking DNS providers - about the fact that you cannot accumulate too many server addresses in a DNS UDP packet. > Either way, there is no difference here network wise? You get > exactly the same reachability/redundancy. Only if you limit your thoughts to a very small world. Sorry, but the fallacy of your argument is so obvious that the words fail me here. > I am against a policy that would let LIRs receive prefixes from RIRs when > the intention is to use the prefix for anycast. I have hopefully shown that > you don't need a dedicated prefix for that. No. You have shown that _you_ don't need that. You try to decide here how other people run their services. I honestly believe that's none of your business, but up to the respective service provider. You can give them good advice, of course. But you must be open to accepting arguments for the way they intend to do it. jorgen at hovland.cx (J?rgen Hovland) wrote: > You will always be forced to obey the rules of whatever provider you are > using, ISP or IXP. I get the impression that you believe ISP x's routing > policies will always be insufficient for you. The problem arises when the sole ISP's routing policies are insufficient at _any_ point in time. > Nameservers are not the only > anycast service so it would be tricky to discuss this in general. DNS is a special service (UDP packet size stuff) and needs a special solution - unfortunately. jorgen at hovland.cx (J?rgen Hovland) wrote: > Hi, > > -----Original Message----- > From: Kurt Erik Lindqvist [mailto:kurtis at kurtis.pp.se] > Sent: 13. november 2005 15:32 > > >In the first scenario you are forced to the routing policies of ISP x > >and only to the locations of ISP x. In the second example you can co- > >locate, connect to and IXP and do your own routing decisions as well > >as be present at locations you choose (without "vasting" or even > >having to go to 11 servers). > > You will always be forced to obey the rules of whatever provider you are > using, ISP or IXP. I get the impression that you believe ISP x's routing > policies will always be insufficient for you. Nameservers are not the only > anycast service so it would be tricky to discuss this in general. > But you want your nameserver to be reachable, that I know. Both scenarios > will accomplish that with the same amount of redundancy. What kind of > routing policies do you mean? Do you want to restrict your reachability? > > > Joergen Hovland > > jorgen at hovland.cx (J?rgen Hovland) wrote: > >From that perspective I seem to see 2 aspects in the recent discussion: > > > >- you shall not receive address space for builing a service, you are to > > buy that from some "big-folk". > > > > This is an intersting point of view, and taken to the extreme will > > make us end up with a _very small_ number of _very big_ entities. > > > > Traditionally these things were called monopolies. Nothing I would be > > too happy to see coming back ;-) You did not comment on this part. Why? From elmi at 4ever.de Mon Nov 14 11:12:12 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Mon, 14 Nov 2005 11:12:12 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <200511140951.jAE9pwpQ007320@mail03.hipercom.no> References: <20051114083147.GG96756@new.detebe.org> <200511140951.jAE9pwpQ007320@mail03.hipercom.no> Message-ID: <20051114101211.GK96756@new.detebe.org> jorgen at hovland.cx (J?rgen Hovland) wrote: > >Certainly not - why should one be satisfied with such a pseudo-solution? > > Because that?s what everybody else are doing? That?s why we currently have > 600 routes in dfz and not one per server on the internet? > Should DNS be excused only because the protocol itself supports a finite > amount of IP addresses? Should SPs be forbidden valid, redundant, Tier-whatever independent, autonomous solutions because we don't want an arbitrary number (prefixes in the DFZ) to change? As much as I don't like a big DFZ, as much I'm obliged to let the service provider decide on how they want to conduct business. > >Only if you limit your thoughts to a very small world. Sorry, but > >the fallacy of your argument is so obvious that the words fail me here. > > Could you be more specific? I am sure there are ISPs that are not willing to > sell anycast services, but if you have buyers then the sellers will always > show up eventually. I'll try to be a bit more specific. I think about those big ISPs and how they are present in some regions, but not in others - tough luck if you chose them - should have chosen another, so renumber your ccTLD server. I think of this big ISP not peering with regional ISPs, Tier-3+ etc.; well, you should have chosen a Tier-2 or -3 then. But again, they are not present, where you need it. I think of connecting directly to regional communities at IXes. I think of delivering special services to special target audiences. I can think of some more things, all of which can be solved by making a compromise here and there. But everything taken together, (a) the compromises you have to make don't make a coherent picture (some cancel each other out) and (b) there's maybe still things left over you cannot cover. > > No. You have shown that _you_ don't need that. > > Obviously some people have different needs. It is good that we try to figure > those out. I'm still not sure why we are talking about how businesses should provide their services here - it's not our concern, really. We are not the judges of other people's decisions (sometimes I'd like to, yeah...). > > You try to decide here how > > other people run their services. > > No, I am trying to prevent excessive defragmentation of the routing table. I can see what you're trying to do, and that is a good thing in itself. It nonetheless needs tampering with other people's decisions, and that's nothing you can do freely. And that's why I'm saying that you're trying to take over the service provider's engineering and operations departments. > I > am trying to prevent a special case of PI where you are not even required to > have your own network. The requirement to this special PI case is so low > that anyone would be able to apply for it - and anyone _will_ apply for it. Well, in the least, anycasting a service costs money (setup aside, operations costs money, too, transit line cost money, etc). So it is pretty unlikely "anyone" would apply for it. Well, maybe anyone, but not everyone. But you're trying to lure us away from the proposal we're discussing which states a special case of DNS for _ccTLDs_, which some people may consider Internet infrastructure (I mentioned this in my previous email). So back to the topic - I have no problem with _all_ ccTLDs and gTLDs applying for five prefixes each. > The packet size thing is a general design problem. As far as I know, there > are currently two methods to solve it: > > * EDNS0 > * TC flag Which are fine for any non-TLD provider to presume. TLD operators need to find a way to service all the folks, even those with broken resolvers. > > > Traditionally these things were called monopolies. Nothing I would be > > > too happy to see coming back ;-) > > > > You did not comment on this part. Why? > > I was probably just a bit unclear. "All you need to do is to create a > network and ask for address space.." There is no monopoly threat as long as > you follow the requirements. If the requirements are too strict, then it > would become a problem. Currently, I think they are not. The requirements for v6 space in the RIPE region includes having transit customers (at all, the 200 is just an arbitrary number). No ccTLD registry that's not also conducting other business may receive an allocation. That's the entire point of the special case being made. ccTLDs cannot deliver services in v6 like in v4. This - IMHO - is a v6 showstopper. Yours, Elmar. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From gert at space.net Mon Nov 14 18:01:46 2005 From: gert at space.net (Gert Doering) Date: Mon, 14 Nov 2005 18:01:46 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <200511140951.jAE9pwpQ007320@mail03.hipercom.no> References: <20051114083147.GG96756@new.detebe.org> <200511140951.jAE9pwpQ007320@mail03.hipercom.no> Message-ID: <20051114170146.GZ69925@Space.Net> Hi, On Mon, Nov 14, 2005 at 10:51:58AM +0100, J?rgen Hovland wrote: > > You try to decide here how > > other people run their services. > > No, I am trying to prevent excessive defragmentation of the routing table. I > am trying to prevent a special case of PI where you are not even required to > have your own network. The requirement to this special PI case is so low > that anyone would be able to apply for it - and anyone _will_ apply for it. > In order to prevent that we only permit DNS? Are there any other services > that should be permitted? This is the type of argument that I love most - "if we permit this to you, everybody will want it, too!!!". I read into this that you are afraid that the initial criteria are not strict enough. As far as I can see, the criteria are pretty explicit, and verificable. [..] > >DNS is a special service (UDP packet size stuff) and needs a special > >solution - unfortunately. > > I disagree. DNS is certainly not a special service. The importance of it is > however perhaps greater than many others - many, but far from all. > The packet size thing is a general design problem. As far as I know, there > are currently two methods to solve it: > > * EDNS0 > * TC flag > > If you are going to use the packet size problem as an argument to use > anycast, then I think it would be a good idea to hear reasons why none of > these solutions would be suitable (also because I don't really know it > myself) and perhaps if there are any other solutions that would help solving > the problem? Please. We have been through this part of the discussion half a year ago, and we've asked those that know (the DNS WG) and they tell us "we can't rely on EDNS0, and truncation is bad". It would be very helpful if you could do us the favour and read up on old arguments in the archives. To repeat myself: it's not the AP WG's job to tell the DNS WG how DNS works. We're making policy, (partly) based on the expertise of other working groups. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Mon Nov 14 23:46:11 2005 From: gert at space.net (Gert Doering) Date: Mon, 14 Nov 2005 23:46:11 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051114.233144.79281105.he@uninett.no> References: <20051114083147.GG96756@new.detebe.org> <200511140951.jAE9pwpQ007320@mail03.hipercom.no> <20051114170146.GZ69925@Space.Net> <20051114.233144.79281105.he@uninett.no> Message-ID: <20051114224611.GD69925@Space.Net> Hi, On Mon, Nov 14, 2005 at 11:31:44PM +0100, Havard Eidnes wrote: > > Please. We have been through this part of the discussion half a year ago, > > and we've asked those that know (the DNS WG) and they tell us "we can't > > rely on EDNS0, and truncation is bad". It would be very helpful if you > > could do us the favour and read up on old arguments in the archives. > > Really? I always got the sense of earlier comments (not here, though > -- I seem to recall this from IETF circles) saying that if you're > running so newfangled software that you speak IPv6 you would be > expected to also implement EDNS0. I don't see the connection. The set of NS records returned by the root name servers for ".de" needs to be small enough so that the results fit into a non-EDNS0-UDP response packets, no matter whether the client can do IPv6 or not - even very old clients should get a complete answer. OTOH, I am way out of my technical league here - I refer to the DNS WG, and they said "don't do this". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From jorgen at hovland.cx Mon Nov 14 23:49:00 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Mon, 14 Nov 2005 23:49:00 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051114170146.GZ69925@Space.Net> Message-ID: <200511142249.jAEMn9pQ003111@mail03.hipercom.no> -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Gert Doering >I read into this that you are afraid that the initial criteria are not >strict enough. As far as I can see, the criteria are pretty explicit, >and verificable. If you mean afraid of a large routing table, then the answer is no. From the archives you might see that I say "who cares, it's the vendors problem". Anyway, as I said in the email after the one you replied to; I don't think there is anything special about DNS (it's just another protocol) so it would be better to discuss general PI allocations instead of specific cases of PI which is after my opinion a waste of time (but this discussion was not). >Please. We have been through this part of the discussion half a year ago, >and we've asked those that know (the DNS WG) and they tell us "we can't >rely on EDNS0, and truncation is bad". It would be very helpful if you >could do us the favour and read up on old arguments in the archives. It would be very helpful if you didn't assume I don't know what I am talking about. >To repeat myself: it's not the AP WG's job to tell the DNS WG how DNS >works. We're making policy, (partly) based on the expertise of other >working >groups. Ok, since I am with the DNS WG maybe it would be okay anyway to mention slightly off-topic but related material? EDNS0 works, just like any other working protocol. The problem is deploying it, also just like any other protocol - like IPv6. Since there is no critical problem today with IPv4, or DNS, there will always be problems deploying the next versions of it when the first people screams "hey this is not working!!!!". We could wait for it to happen. We could use it as an excuse to find temporary workarounds. We can even make special address policies for special cases that would give us more time, but sooner or later it is going to happen - because the protocol itself is not sufficient and that is your axiom. Please do give me comments, but I think I have finished discussing this topic now. Joergen Hovland From lists at complx.LF.net Tue Nov 15 08:30:08 2005 From: lists at complx.LF.net (Kurt Jaeger) Date: Tue, 15 Nov 2005 08:30:08 +0100 Subject: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <200511140951.jAE9pwpQ007320@mail03.hipercom.no> References: <20051114083147.GG96756@new.detebe.org> <200511140951.jAE9pwpQ007320@mail03.hipercom.no> Message-ID: <20051115073008.GB683@complx.LF.net> Hello, > So far we have two reasons why anycast prefixes, "anycast PI", should be > permitted: > * Bankruptcy > * Routing policies For ccTLDs, there's a third: Autonomy from ICANN decisions to change IP addresses of DNS servers in the root zone if some IP is no longer servicable. That's a national security issue for some countries. -- MfG/Best regards, Kurt Jaeger 15 years to go ! LF.net GmbH fon +49 711 90074-23 pi at LF.net Ruppmannstr. 27 fax +49 711 90074-33 D-70565 Stuttgart mob +49 171 3101372 From tim.streater at dante.org.uk Mon Nov 14 14:41:48 2005 From: tim.streater at dante.org.uk (Tim Streater) Date: Mon, 14 Nov 2005 13:41:48 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <200511141119.jAEBJ5pQ011498@mail03.hipercom.no> References: <20051114101211.GK96756@new.detebe.org> <200511141119.jAEBJ5pQ011498@mail03.hipercom.no> Message-ID: <6.2.3.4.2.20051114134048.04e37a00@mail.dante.org.uk> At 11:19 14/11/2005, J?rgen Hovland wrote: >So we are back at the beginning; >I say no to anycast PI for TLDs/ccTLDs. I don't believe it is a special case >so it doesn't need a special policy. TLDs/ccTLDs could/should however be >used as an argument to allow v6 PI prefixes in general. >V6 PI compared to v4 surely is a showstopper for many, or at least for some. It's a showstopper for us on one of the networks we manage. We can't get V6 PI for it like we could v4 PI. -- Tim From he at uninett.no Mon Nov 14 23:31:44 2005 From: he at uninett.no (Havard Eidnes) Date: Mon, 14 Nov 2005 23:31:44 +0100 (CET) Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051114170146.GZ69925@Space.Net> References: <20051114083147.GG96756@new.detebe.org> <200511140951.jAE9pwpQ007320@mail03.hipercom.no> <20051114170146.GZ69925@Space.Net> Message-ID: <20051114.233144.79281105.he@uninett.no> > Please. We have been through this part of the discussion half a year ago, > and we've asked those that know (the DNS WG) and they tell us "we can't > rely on EDNS0, and truncation is bad". It would be very helpful if you > could do us the favour and read up on old arguments in the archives. Really? I always got the sense of earlier comments (not here, though -- I seem to recall this from IETF circles) saying that if you're running so newfangled software that you speak IPv6 you would be expected to also implement EDNS0. Regards, - H?vard From Michael.Dillon at btradianz.com Tue Nov 15 11:53:04 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 15 Nov 2005 10:53:04 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051111180146.GG69925@Space.Net> Message-ID: > DENIC is providing a public service (namely: DNS for the .de TLD) - and > *the whole world* wants to reach their DNS servers. (No different > to .com and other large TLDs) OK, DENIC is providing a public service. But DENIC's network is still only serving DENIC itself. RIRs give out address allocations to network operators whose networks are serving many organizations. If DENIC's newtork was serving many organizations and allowing .FR, .SK, .RU and .PE to provide their public services over the DENIC global anycast network, then RIPE should give you addresses to run your anycast network. But if DENIC is not going to serve other organizations then RIPE should not give you the addresses but should tell you to go and find a global anycast network operator to assist you. --Michael Dillon From Michael.Dillon at btradianz.com Tue Nov 15 12:02:07 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 15 Nov 2005 11:02:07 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051112074323.GL69925@Space.Net> Message-ID: > That's the point. DENIC isn't doing this for themselves. They do this > for *you* (and for me, and even for Randy). The Red Cross Society is also doing it for *you* and for me and even for Randy. But that doesn't make their network special. If DENIC really wants to build a special network then they should share that special network with other TLD operators. Then I would be happy to support their requests for IP addresses. But if they are not going to share their network then there is nothing special and they must buy service on the open market. I really do want DENIC to build their anycast network. But I want them to share it so that all the other important TLDs don't have to build their own separate networks all doing the same thing as DENIC. In fact, now that DENIC is selling resilient domain name hosting around the world, I would be interested in having them host my second level domains as well. > So putting up the anycast servers somewhere where half of the internet > might not see them is not useful. For maximum resiliency (against > DoS and outages), one wants to spread the anycast servers over as many > different (!) networks as possible. And this cannot be done without > a dedicated prefix for it. I agree with you Gert but this is such a good idea that every TLD will want to do the same. You need to either outsource this to a company that specializes in anycast hosting or you need to separate DENIC into a hosting network business and the .DE name registry business. --Michael Dillon From fw at deneb.enyo.de Wed Nov 16 19:35:52 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 16 Nov 2005 19:35:52 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051112074323.GL69925@Space.Net> (Gert Doering's message of "Sat, 12 Nov 2005 08:43:23 +0100") References: <20051111210606.GH69925@Space.Net> <200511112244.jABMiYpQ011727@mail03.hipercom.no> <20051112074323.GL69925@Space.Net> Message-ID: <87ek5gv3sn.fsf@mid.deneb.enyo.de> * Gert Doering: >> Gert, you can configure 1000 anycast servers, all with the same IP address, >> in your own network no matter how small/large your network is. > > That's the point. DENIC isn't doing this for themselves. They do this > for *you* (and for me, and even for Randy). >From a technical perspective, there is no reason to give DENIC special treatment. I would even say that DENIC (or even DNS) is merely a red herring. Has it already been decided that it's a good idea to port the IPv4 anycasting scheme to IPv6? Wouldn't it be better to start over with something which is more sound from a technical perspective? Just because addressing tweaks can solve a perceived problem, it doesn't follow that a solution based on addressing is the best one. This might be simply one of those "IPv6 will really take off when you do X" things. But given that IPv6 among DNS servers is rather widespread (in relative terms, of course), I'm not sure if this move is really necessary. From fw at deneb.enyo.de Wed Nov 16 19:44:48 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 16 Nov 2005 19:44:48 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <43767AF1.4000302@oslo.net> (Hans Petter Holen's message of "Sun, 13 Nov 2005 00:29:53 +0100") References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> Message-ID: <877jb8v3dr.fsf@mid.deneb.enyo.de> * Hans Petter Holen: > What if I want to plan for more disasters than that ? Like MCI going out > of business? Or operator error destroys the zone beyond easy recovery. If DNS operators really cared about the availability of their data, they would allow the general public to mirror it. However, some of them seem to think that such a precaution against disaster would negatively impact their current business model. From fw at deneb.enyo.de Wed Nov 16 19:55:56 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 16 Nov 2005 19:55:56 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <43775E10.3020604@cc.univie.ac.at> (Wilfried Woeber's message of "Sun, 13 Nov 2005 15:38:56 +0000") References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <43775E10.3020604@cc.univie.ac.at> Message-ID: <87y83otoar.fsf@mid.deneb.enyo.de> * Wilfried Woeber: >>From that perspective I seem to see 2 aspects in the recent discussion: > > - you shall not receive address space for builing a service, you are to > buy that from some "big-folk". > > This is an intersting point of view, and taken to the extreme will > make us end up with a _very small_ number of _very big_ entities. > > Traditionally these things were called monopolies. Nothing I would be > too happy to see coming back ;-) Oligopolies is the term, I think. IPv6 addressing policy seems to be geared towards that. We know from the IPv4 experience that 20,000+ indepedent entities in the global routing table can be handled easily. So why not try to duplicate this success? > - there has been th discussion regarding "anycast" but isnt this just > a special(?) case of th PI-topic? It depends on the PI criteria. If slots in the global routing tables are kept in short supply *and* you get at most one if you aren't an ISP *and* you need to do IPv6 anycast, you might have a problem because you need two globally visible prefixes (one for your production network, one for anycast). But I think you are right that it makes sense to resolve the PI first, either negatively or positively. From Mohsen.Souissi at nic.fr Thu Nov 17 11:50:32 2005 From: Mohsen.Souissi at nic.fr (Mohsen Souissi) Date: Thu, 17 Nov 2005 11:50:32 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <87y83otoar.fsf@mid.deneb.enyo.de> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <43775E10.3020604@cc.univie.ac.at> <87y83otoar.fsf@mid.deneb.enyo.de> Message-ID: <20051117105032.GO99793@kerkenna.nic.fr> Florian & all, On 16 Nov, Florian Weimer wrote: [...] | It depends on the PI criteria. If slots in the global routing tables | are kept in short supply *and* you get at most one if you aren't an | ISP *and* you need to do IPv6 anycast, you might have a problem | because you need two globally visible prefixes (one for your | production network, one for anycast). | | But I think you are right that it makes sense to resolve the PI first, | either negatively or positively. ==> This is just amazing! I have been follwing this topic for more than two years and I have the feeling that we are making again and again the history! I remember that when the IPv6 "PI" issue was first raised in the IPv6/LIR wgs ("LIR" was the old name for "AP" at that time), the answer was "PI is out of scope of this wg". Then came the first draft proposel of Andreas in the AP wg asking for a /32 for ccTLDs wishing to deploy anycast. At that time, the wg said "let's not talk about "PI", which is still out of scope of this wg. Let's rather talk about specific needs of TLDs wishing to do anycast and see what we can do for them in termes of (micro-)allocation." Now, I'm surprised that we are going back to the original issue and asking to first solve the PI problem... If that's to be done and while we ar at it, we can see again how RIPE is the only RIR not considering TLD networks as "critical infrastructure" while an appropriate policy has been already implemented in all other existing RIRs for a long while (please revisit the comparative matrix of RIR policies at http://www.ripe.net/info/resource-admin/rir-comp-matrix-rev.html and see how RIPE is lagging behind in this matter. Some of this mailing-list member would say: "that was our choice!"). Isn't it a European speciality to discuss over again and again issues without coming to any solution? Some people on RIPE mailing-lists are now used to coming after a consensus is almost reached and try to break everything just for the sake of building CLEAN solutions... (cc)TLD need an allocation (whether it is a /32 or whatever "routable prefix") because they need to do anycast, full stop. To recall only a few of the arguments for deploying anycast for a TLD, I would say: Redundance & Resilience against DDoS attacks, better global time response, a greater flexibility in adding and removing name servers without notifying IANA! Btw, I'd like to remind some of this mailing-list readers that the request of DENIC is not isolated since AFNIC asked even before Adndreas first draft for a constency between all RIRs in the way IPv6 allocation were made for "critical infrastructure". AFNIC has then strongly supported Andreas proposal from the beginning and hoped that the solution would come rapidly because AFNIC is still needing such a solution to start deploying anycast in IPv4 AND in IPv6 in a consistent way! I still hope this debate will lead to a concrete solution within the coming 3 years! Good luck :-) Mohsen. From Michael.Dillon at btradianz.com Thu Nov 17 12:01:08 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 17 Nov 2005 11:01:08 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051117105032.GO99793@kerkenna.nic.fr> Message-ID: > Btw, I'd like to remind some of this mailing-list readers that the > request of DENIC is not isolated since AFNIC asked even before > Adndreas first draft for a constency between all RIRs in the way IPv6 > allocation were made for "critical infrastructure". AFNIC has then > strongly supported Andreas proposal from the beginning and hoped that > the solution would come rapidly because AFNIC is still needing such a > solution to start deploying anycast in IPv4 AND in IPv6 in a > consistent way! This reinforces the position that RIPE should not give out address allocations to TLD operators to use for their anycast deployments. There is nothing special about DENIC. If AFNIC and DENIC form a consortium to operate anycast deployments for TLD operators, then that is a different question entirely. I think it would be right for RIPE to allocate addresses to such a consortium just like we now do with other network operators. --Michael Dillon From jeroen at unfix.org Thu Nov 17 12:26:40 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 17 Nov 2005 12:26:40 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051117105032.GO99793@kerkenna.nic.fr> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <43775E10.3020604@cc.univie.ac.at> <87y83otoar.fsf@mid.deneb.enyo.de> <20051117105032.GO99793@kerkenna.nic.fr> Message-ID: <437C68F0.7080709@unfix.org> Mohsen Souissi wrote: > Now, I'm surprised that we are going back to the original issue and > asking to first solve the PI problem... > (cc)TLD need an allocation (whether it is a /32 or whatever "routable > prefix") because they need to do anycast, full stop. "example.net DNS servers needs an allocation (whether it is a /32 or whatever "routable prefix") because they need to do anycast, full stop." What makes .de more important then example.net DNS servers? I am quite sure that a large part of the world can live perfectly without complete *.de (especially older french people :) but would hate it when google.com (they have already a /32) or ebay.com or say cnn.com (the latter who don't have an allocation yet), are not reachable. These kind of sites also require what you want with 'anycast', a server as close as possible to the enduser for resiliency, latency, DDoS etc... For that matter .com/.net/.org don't have it (yet) either. My points for this, which are mostly also reflected in the proposal: - Special policy only for accredited ccTLD's - Give them a /32 (bigger is only filtering nightmare already) (in another message) Michael Dillon wrote: > If AFNIC and DENIC form a consortium to operate anycast > deployments for TLD operators, then that is a different > question entirely. I think it would be right for RIPE to > allocate addresses to such a consortium just like we now > do with other network operators. You mean clustering up all ccTLD's into 1 prefix? Then why not have a single /32 with a caching recursive DNS server which answers to all queries, see section 4 of: http://unfix.org/~jeroen/archive/drafts/draft-massar-dnsop-service-00.txt But proposing that gets one into 4 holy wars I understood, especially the 'anycast' part seems to be very hurting to a number of people... Note also that clustering them together causes loss of diversity. Thus a /32 per ccTLD seems appropriate here. > I still hope this debate will lead to a concrete solution within the > coming 3 years! Only 3? :) If you really want to get over all of this use the current policy: just define DENIC and anything else as being an LIR (just pay some cash), providing end connectivity to 200+ *planned* sites. Those 200 sites consist out of: - 13 /48's for the anycasted PoPs - 1 /48 for the main office - X /48's for branch offices. - 100+ VPN connections to endsites (for management, employee 'dailin' etc). Done. Please read through: http://www.sixxs.net/tools/grh/dfp/all/ and see what kind of organisations have already got an allocation. Then go over to your favourite colo facility and see what equipment they have. I am quite sure that quite many don't have a lot of equipment (or customers). But they have planned it... and back to everybodies normal schedule.... Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From Karsten.Koepp at lambdanet.net Thu Nov 17 13:36:08 2005 From: Karsten.Koepp at lambdanet.net (Koepp, Karsten) Date: Thu, 17 Nov 2005 13:36:08 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or so mething else? Message-ID: <39F27E3F569FD4119EF200508BAF85B9067A6C8C@CCGNT30> Hi all, I also followed the discussion, not stepping in here because of no background in TLD operations. Getting a bit frustrated as I see NO movement here. Unlike others, I do see dns being _critical_ to the infrastructure. No other protocol is that much subject of political discussions. As an operator being dependent on TLD operations I want to see a stable operations of the dns tree. Consequently I support giving the TLD operators the tools they need to make it a stable service. I have read an _expressed need_ of the tld community for anycast where I have not seen any constructive proposal against. Hence I have to ACCEPT that large TLDs need it. It brings us no step further towards a stable dns chain if we deny this. What is the impact onto my network if I accept to grant special resources to this need? I can see hardly any besides at most 200 prefixes polluting the DFZ. I can question whether the anycast allocations should be /32 or /48 or something else. It doesn't make a difference in terms of resources stressing my network provided I have a finite number of objects here. Operationally I believe /32 assignments are more stable, so I tend handing out /32 to TLD operators. Current policy does not allow to allocate routeable blocks to TLDs, so we have to change the policy. Before you start flaming I do not regard this opening the flooding gates, as I don't see the flood. TLD operators are being defined as critical infrastructure. It can be decided case by case to allow further infrastructure - by the RIPE members, but I haven't seen such case yet. Let it be xyz.com, have they ever claimed a need for themselves? regards Karsten > -----Original Message----- > From: Mohsen Souissi [mailto:Mohsen.Souissi at nic.fr] > Sent: Thursday, November 17, 2005 11:51 AM > To: Florian Weimer > Cc: address-policy-wg at ripe.net; ipv6-wg at ripe.net > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 micro > allocation or > something else? > > > Florian & all, > > On 16 Nov, Florian Weimer wrote: > [...] > | It depends on the PI criteria. If slots in the global > routing tables > | are kept in short supply *and* you get at most one if you aren't an > | ISP *and* you need to do IPv6 anycast, you might have a problem > | because you need two globally visible prefixes (one for your > | production network, one for anycast). > | > | But I think you are right that it makes sense to resolve > the PI first, > | either negatively or positively. > > ==> This is just amazing! I have been follwing this topic for more > than two years and I have the feeling that we are making again and > again the history! I remember that when the IPv6 "PI" issue was first > raised in the IPv6/LIR wgs ("LIR" was the old name for "AP" at that > time), the answer was "PI is out of scope of this wg". Then came the > first draft proposel of Andreas in the AP wg asking for a /32 for > ccTLDs wishing to deploy anycast. At that time, the wg said "let's not > talk about "PI", which is still out of scope of this wg. Let's rather > talk about specific needs of TLDs wishing to do anycast and see what > we can do for them in termes of (micro-)allocation." > > Now, I'm surprised that we are going back to the original issue and > asking to first solve the PI problem... > > If that's to be done and while we ar at it, we can see again how RIPE > is the only RIR not considering TLD networks as "critical > infrastructure" while an appropriate policy has been already > implemented in all other existing RIRs for a long while (please > revisit the comparative matrix of RIR policies at > http://www.ripe.net/info/resource-admin/rir-comp-matrix-rev.html and > see how RIPE is lagging behind in this matter. Some of this > mailing-list member would say: "that was our choice!"). Isn't it a > European speciality to discuss over again and again issues without > coming to any solution? Some people on RIPE mailing-lists are now > used to coming after a consensus is almost reached and try to break > everything just for the sake of building CLEAN solutions... > > (cc)TLD need an allocation (whether it is a /32 or whatever "routable > prefix") because they need to do anycast, full stop. To recall only a > few of the arguments for deploying anycast for a TLD, I would say: > Redundance & Resilience against DDoS attacks, better global time > response, a greater flexibility in adding and removing name servers > without notifying IANA! > > Btw, I'd like to remind some of this mailing-list readers that the > request of DENIC is not isolated since AFNIC asked even before > Adndreas first draft for a constency between all RIRs in the way IPv6 > allocation were made for "critical infrastructure". AFNIC has then > strongly supported Andreas proposal from the beginning and hoped that > the solution would come rapidly because AFNIC is still needing such a > solution to start deploying anycast in IPv4 AND in IPv6 in a > consistent way! > > I still hope this debate will lead to a concrete solution within the > coming 3 years! > > Good luck :-) > > Mohsen. > > From Michael.Dillon at btradianz.com Thu Nov 17 12:43:21 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 17 Nov 2005 11:43:21 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <437C68F0.7080709@unfix.org> Message-ID: > Note also that clustering them together causes loss of diversity. > Thus a /32 per ccTLD seems appropriate here. I didn't suggest clustering all TLD servers together. I suggested that two TLD server operators could cooperate in operating a joint anycast deployment and offer the use of this to other TLD operators. I expect that some other organizations will see this as a business opportunity and will also operate separate anycast deployments. Then, TLDs which are concerned about diversity will use two or more of these anycast network operators. I believe that a network operator should be able to justify a portable prefix of normal size and an AS number. But I don't think that an end user like DENIC should be able to claim that they are "special" and get the same address prefix. I also don't believe there should be any microallocations at all. > If you really want to get over all of this use the current policy: just > define DENIC and anything else as being an LIR (just pay some cash), > providing end connectivity to 200+ *planned* sites. Combine AFNIC's servers and a couple of other TLDs and you will easily meet that number of anycasted DNS servers. --Michael Dillon From randy at psg.com Thu Nov 17 15:18:08 2005 From: randy at psg.com (Randy Bush) Date: Thu, 17 Nov 2005 06:18:08 -0800 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or so mething else? References: <39F27E3F569FD4119EF200508BAF85B9067A6C8C@CCGNT30> Message-ID: <17276.37152.757181.203339@roam.psg.com> > Unlike others, I do see dns being _critical_ to the infrastructure. i think most folk think of dns as critical infrastructure > No other protocol is that much subject of political discussions. and this says what about the dns, other than the need to taks a shower often? > As an operator being dependent on TLD operations I want to see > a stable operations of the dns tree. as am i. as do i. > Consequently I support giving the TLD operators the tools they > need to make it a stable service. yes. and how do you go from here to special address allocations? do we also need special computers? special electricity? special racks? randy From Michael.Dillon at btradianz.com Thu Nov 17 16:12:11 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 17 Nov 2005 15:12:11 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or so mething else? In-Reply-To: <17276.37152.757181.203339@roam.psg.com> Message-ID: > > Consequently I support giving the TLD operators the tools they > > need to make it a stable service. > > yes. and how do you go from here to special address allocations? > do we also need special computers? special electricity? special > racks? I also agree that DNS is part of the Internet's critical infrastructure and that TLD's are more critical than the average end user domain. That is why I am opposed to DENIC's application to change policy and impose a bureaucratic process around building anycast deployments. There is no barrier preventing DENIC and AFNIC and others from deploying global anycast to serve the domains that they host from their TLD registries. Many, many companies in Europe are happily operating hosting facilities that host all sorts of applications using a wide range of protocols including the DNS protocol that is used in DENIC's hosting service. But DENIC's customers should be asking themselves why DENIC is wasting their time in this political process to change RIPE policy instead of building their anycast infrastructure. If they don't move quickly, then someone else will build that anycast infrastructure and both DENIC and AFNIC will be reduced to being customers instead of network operators. As long as they keep running the critical DNS infrastructure I am happy. Whether they outsource the anycast network entirely or participate in building their own, it doesn't matter much. --Michael Dillon From dr at cluenet.de Fri Nov 18 00:31:37 2005 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 18 Nov 2005 00:31:37 +0100 Subject: [ipv6-wg] Re: 200 customer requirements for IPv6 In-Reply-To: References: <200511171715.05767.marc.van.selm@nc3a.nato.int> Message-ID: <20051117233137.GA24229@srv01.cluenet.de> On Thu, Nov 17, 2005 at 05:26:20PM +0100, JORDI PALET MARTINEZ wrote: > There are lots of similar examples as the NATO one. It make no sense > at all Not issueing PI for multihomed entities makes no sense at all, in face of the complete lack of a full replacement. I'm still waiting for the heads to come out of the sand, but I'm waiting since long and don't see _any_ light at the end of the tunnel (don't anybody dare to say "shim6" if he/she doesn't want to disqualify her/himself immediately). The folks all having their own /32 already allocated to them and trying to limit independent address space to "service providers" (or those who manage to pretend being it, which seems to be easy) are still arguing for "not for them!" paradigm - easy position with having their own dishes already done. Until we have a clear full replacement (that means a solution which does NOT ignore real requirements like shim6 does) there should be a very simple PI policy which issues a /48 or whatever to end sites at a nominal small fee, paid directly to the RIR. An initial setup fee and a yearly renewal fee, paid by credit card or something equally simple. No payment => assignment withdrawn. The initial fee covering the cost of evaluation of the request, doing the assignment and setting up the billing account and DNS reverse. The yearly fee covering the maintenance of the entries in the database and DNS rev NS RRset and the yearly recurring fee invoicing/billing. Done. Too simple, too scary, too much independence again to the endsites, eh? I think it's ridiculous to have folks become LIR (and pretend/lie being ISPish) just to get the PI space they need and having them pay the same money every *real* LIR (you remember what LIR means? Local Internet REGISTRY) which happens to open tickets with the hostmasters every now and then (or much more often). Setting aside my disbelieve in the FUD about the scalability problem of real BGP multihoming (noone yet has shown that the relative amount of multihomers does or will explode), I'm quite sure that we'd need a real locator/ID split which is NOT shim6 but something going farther than that. And we won't have it soon, if at all for IPv6. But keeping on ignoring user's needs for further years and waiting for the magically appearing 100% ideal solution is not the way forward. My 0.02EUR Regards, Daniel (having renumbered his IPv6 network already three times completely and hoping not having to do it a fourth time anytime soon, and not being able to properly multihome like I can do in IPv4 because I'm not a commercial ISP, nor can afford the thousands of EUR for LIR which usually finance MUCH more than just a one-time PI assignment and some DB slots) -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From slz at baycix.de Fri Nov 18 12:33:01 2005 From: slz at baycix.de (Sascha Lenz) Date: Fri, 18 Nov 2005 12:33:01 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <20051117233137.GA24229@srv01.cluenet.de> References: <200511171715.05767.marc.van.selm@nc3a.nato.int> <20051117233137.GA24229@srv01.cluenet.de> Message-ID: <437DBBED.1080605@baycix.de> Hi, Daniel Roesen wrote: > On Thu, Nov 17, 2005 at 05:26:20PM +0100, JORDI PALET MARTINEZ wrote: >>There are lots of similar examples as the NATO one. It make no sense >>at all > > Not issueing PI for multihomed entities makes no sense at all, in face > of the complete lack of a full replacement. I'm still waiting for the > heads to come out of the sand, but I'm waiting since long and don't see > _any_ light at the end of the tunnel (don't anybody dare to say "shim6" > if he/she doesn't want to disqualify her/himself immediately). The folks > all having their own /32 already allocated to them and trying to limit > independent address space to "service providers" (or those who manage to > pretend being it, which seems to be easy) are still arguing for "not for > them!" paradigm - easy position with having their own dishes already > done. ok, *handraise* That's not entirely true - while i have "my" /32, i'm still arguing against this current no-PI situation every this and then (i stopped getting involed in _every_ IPv6-PI-related flamewa^Wthread long ago though...) But indeed, that's still the main problem, that people don't get their head out of the sand, largely due to just not seeing this problem as an issue for themselves. > Until we have a clear full replacement (that means a solution which does > NOT ignore real requirements like shim6 does) there should be a very > simple PI policy which issues a /48 or whatever to end sites at a > nominal small fee, paid directly to the RIR. An initial setup fee and a > yearly renewal fee, paid by credit card or something equally simple. > No payment => assignment withdrawn. The initial fee covering the cost of > evaluation of the request, doing the assignment and setting up the > billing account and DNS reverse. The yearly fee covering the maintenance > of the entries in the database and DNS rev NS RRset and the yearly > recurring fee invoicing/billing. Done. > > Too simple, too scary, too much independence again to the endsites, eh? I think, the main argument against IPv6-PI _still_ is the routing table size, contradicting any reasonable predictions nowerdays (IMHO!). At least that was my own argument against(!) PI in first place, but times have changed since the last millenium. In particular, noone came up with an equal solution to BGP Multihoming with "PI"-space, which i hoped for back then. I can't even see any solution rising in the FAR future, so the only way to keep IPv6 from being completely useless is, go for allowing PI Space for organisations who really want that geniune kind of multihoming and are sure they don't want any workaround solution. A setup+renewal fee does not do much against the routing table size or so, but at least should stop having the IPv4-situation with swamp space(s) and unused, unowned or "joke" Prefixes floating in the databases. I wouldn't like to have anyone to get a Prefix without reasonable need just for the fun of it, like with el-chepo Domain-Names and Hostname ect.. One should know what he does. Of course the issuing organisation should point to alternative solutions and have the requesting one to check out on them if they might be sufficent for their needs (the famous "Did you consider using RfC1918?"-alike-question in the request form should do it with some pointers to good FAQs on alternatives). > I think it's ridiculous to have folks become LIR (and pretend/lie being > ISPish) just to get the PI space they need and having them pay the same > money every *real* LIR (you remember what LIR means? Local Internet > REGISTRY) which happens to open tickets with the hostmasters every now > and then (or much more often). ACK. That's ridiculous. Additionaly, some might not NEED a /32 and don't want to pay for services they don't need (Registry servies, voting at RIPE-meetings, Training Courses... whatver) > Setting aside my disbelieve in the FUD about the scalability problem of > real BGP multihoming (noone yet has shown that the relative amount of > multihomers does or will explode), I'm quite sure that we'd need a real > locator/ID split which is NOT shim6 but something going farther than > that. And we won't have it soon, if at all for IPv6. But keeping on > ignoring user's needs for further years and waiting for the magically > appearing 100% ideal solution is not the way forward. Well, if i say "there is no scalability" problem, that would be considered ignorant by most people, so i don't do that now. But i can't see any problems with BGP routing table size either, it will be significantly smaller than in the IPv4 world by design (one - or few - prefixes per AS), and even when it's growing again from PI-prefixes, probably beyond the current IPv4 table size, what's the problem? Nowerdays routers actually can handle that with >=1GB RAM and fast ASICs. ... and it will take YEARS if at all to raise above nowerdays size. Now let alone the fact that you need to carry on with the IPv4 table for decades anyways, so no relief in sight for the routers... But i'm not saying, there won't be a problem in 50years. > My 0.02EUR I add another 0.02EUR > Regards, > Daniel (having renumbered his IPv6 network already three times > completely and hoping not having to do it a fourth time anytime soon, > and not being able to properly multihome like I can do in IPv4 because > I'm not a commercial ISP, nor can afford the thousands of EUR for LIR > which usually finance MUCH more than just a one-time PI assignment > and some DB slots) > ...i rather invest in redundant Uplinks and routers than in becoming LIR for no apparent reason (i.e. not ASSIGNING Address space as primary purpose), hence i currently go for IPv4-PI for my non-profit organisation(s), utilizing a /40 Suballocation in the IPv6 world from "my" (commercial) LIR. Better than nothing but i'd prefer a completely independant IPv6-PI space and someone doing something against this /32-/35-filter-madness. "My" LIR is not very active in the ISP business lately, and i don't want to know how to deal with a CLOSE of the LIR with my more private, non-profit Address Space either. Am i allowed to keep the Suballocation when RIPE reclaims the LIR's /32? Can i announce the whole /32 when i can't reach some locations with the /40 Suballocation announcement? Can i have the whole /32 for free then not being a LIR? Do i ultimately have to renumber, too? How often? How do i maintain my multihoming properly? ...and so on...(NOTE: rethorical questions, i know the current procedures on the paper) Idependency is one of the basic things in the internet, i don't like people who want to tell me how much independency i need. I know that best for myself. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From narten at us.ibm.com Fri Nov 18 15:16:42 2005 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 18 Nov 2005 09:16:42 -0500 Subject: [ipv6-wg] Re: 200 customer requirements for IPv6 In-Reply-To: Message from Daniel Roesen of "Fri, 18 Nov 2005 00:31:37 +0100." <20051117233137.GA24229@srv01.cluenet.de> Message-ID: <200511181416.jAIEGga6013092@cichlid.raleigh.ibm.com> Daniel Roesen writes: > The folks all having their own /32 already allocated to them and > trying to limit independent address space to "service providers" (or > those who manage to pretend being it, which seems to be easy) are > still arguing for "not for them!" paradigm - easy position with > having their own dishes already done. With all due respect, these sorts of comments are not helpful. They imply bad motivations on some, that IMO, are simply false. There are (IMO) valid reasons for not giving out /32s to everyone. The original (and still compelling, IMO) rational behind the current policy is to ensure good aggregation for the long term, in order to keep the number of distinct prefixes in the DFZ manageable. Hence, the current policy is oriented not towards _all_ ISPs, but those who will (hopefully) have _many_ customers that they assign addresses too. That is, they aggregate addresses for _many_ customers. That is where the "plan for 200 customers" wording originally came from. The presumption is that an ISP/LIR that realistically expects to have 200 customers will be aggregating _many_ customer addresses. If an ISP will have (say) only 100 customers long term, its not at all clear that they will be aggregating significant amounts of address space. Note, I'm not defending the the "200 customer" rule per se; I understand that it is viewed as problematic. But I think the motivation that led to it is still valid, and when folk say "get rid of this requirement," I object to "forgetting" about the original concern when coming up with a replacement policy. > Until we have a clear full replacement (that means a solution which does > NOT ignore real requirements like shim6 does) there should be a very > simple PI policy which issues a /48 or whatever to end sites at a > nominal small fee, paid directly to the RIR. An initial setup fee and a > yearly renewal fee, paid by credit card or something equally simple. > No payment => assignment withdrawn. The initial fee covering the cost of > evaluation of the request, doing the assignment and setting up the > billing account and DNS reverse. The yearly fee covering the maintenance > of the entries in the database and DNS rev NS RRset and the yearly > recurring fee invoicing/billing. Done. Note that ARIN has been and continues to have discussions about how to give out PI space to end sites, but in a way that doesn't explode the routing tables going forward. I think there is (very strong) support for the idea of giving out more PI space, the difficulty has been in coming up with details that people are comfortable won't explode the routing tables going forward. I.e., that in five years we look back and say "oops, we should not have done that, now what do we do" > Setting aside my disbelieve in the FUD about the scalability problem of > real BGP multihoming (noone yet has shown that the relative amount of > multihomers does or will explode), Um, do the math. How many end sites do you think will want to multihome ten years from now? Can you honestly/realistically say it won't be a million? Can the routing infrastructure handle that? (Enough people say "not sure" that IMO it would be foolish to just assume we can do this). Thomas From Michael.Dillon at btradianz.com Fri Nov 18 15:29:51 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 18 Nov 2005 14:29:51 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <200511181416.jAIEGga6013092@cichlid.raleigh.ibm.com> Message-ID: > Note that ARIN has been and continues to have discussions about how to > give out PI space to end sites, but in a way that doesn't explode the > routing tables going forward. I think there is (very strong) support > for the idea of giving out more PI space, the difficulty has been in > coming up with details that people are comfortable won't explode the > routing tables going forward. I.e., that in five years we look back > and say "oops, we should not have done that, now what do we do" On the ARIN Public Policy mailing list, I have suggested that we open up another chunk of the IPv6 address space to use for geotopological addresses that will enable aggregation at the city level and allow small and mid-size companies to multihome using BGP without adding to the global routing table. If these companies are using geotopological addresses then their detailled routes are only visible inside one city. In the rest of the world there is only a single city prefix, or, if we can create a second regional level that groups cities within a continent, then there would be even fewer routes visible globally. This reduces pressure on the global routing table so that people who cannot feasibly use geotopological addresses have more room to work with. If you go to the ARIN site and look at the PPML archives for November sorted by author, http://lists.arin.net/pipermail/ppml/2005-November/author.html then you can read the 11 messages that I posted, describing geotopological addressing and answering various questions about it. Feel free to continue the discussion on address-policy-wg at ripe.net if you wish. It doesn't really belong on the ipv6-wg list because it is a question of policy whether or not to allocate these addresses and which allocation rules to use. --Michael Dillon From peter.juul at uni-c.dk Fri Nov 18 15:40:11 2005 From: peter.juul at uni-c.dk (Peter B. Juul) Date: Fri, 18 Nov 2005 15:40:11 +0100 Subject: [ipv6-wg] Re: 200 customer requirements for IPv6 In-Reply-To: <200511181416.jAIEGga6013092@cichlid.raleigh.ibm.com> References: <20051117233137.GA24229@srv01.cluenet.de> <200511181416.jAIEGga6013092@cichlid.raleigh.ibm.com> Message-ID: <20051118144010.GS6829@uni-c.dk> On Fri, Nov 18, 2005 at 09:16:42AM -0500, Thomas Narten wrote: > The original (and still compelling, IMO) rational behind the current > policy is to ensure good aggregation for the long term, in order to > keep the number of distinct prefixes in the DFZ manageable. Hence, the > current policy is oriented not towards _all_ ISPs, but those who will > (hopefully) have _many_ customers that they assign addresses too. That > is, they aggregate addresses for _many_ customers. And then we can discuss the definition of "many" for hours. I "do" the backbone at the danish NREN. We have no upstream provider from whom to ask for IP addresses and we almost completely employ two /16s and one /17 of IPv4 space. There's a certain pressure on NRENs to get going on IPv6, we were involved in the EU 6net project and now run IPv6 on the backbone, exerting what little pressure we can to get services running around the country. We have a bit more than 100 institutions. About six of those are major universities with a large number of institutes. We planned (and still plan) to get everybody running IPv6 and by setting a policy that every institute should have a /48, we were able to claim without exactly lying that we were planning at least 200 /48s. Of course, what makes sense is for a university to get a /48 and then let them subdivide that for institutes, but that would effectively make Forskningsnettet (the danish research network) incapable of obtaining IPv6 at all. Executive summary: I believe that the 200 customers demand halts IPv6 development rather than help it. If we really wanted to be cautious, we should forget about /32s and go /36 or /40 instead. A /40 would be plenty for Forskningsnettet. Now we have /32 and a completely absurd subassignment policy instead. Peter B. Juul, Uni?C (PBJ255-RIPE) From ripe-wgs.cs at schiefner.de Fri Nov 18 16:27:03 2005 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Fri, 18 Nov 2005 16:27:03 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <877jb8v3dr.fsf@mid.deneb.enyo.de> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <877jb8v3dr.fsf@mid.deneb.enyo.de> Message-ID: <437DF2C7.903@schiefner.de> Florian, Florian Weimer wrote: > If DNS operators really cared about the availability of their data, > they would allow the general public to mirror it. However, some of > them seem to think that such a precaution against disaster would > negatively impact their current business model. of course, I can't speak for every DNS operator, but DENIC denying the transfer of the .de zone has no other reason than data protection, ie. making the harvesting of contact data of some 9 million plus domain name holders by just piping the zone through the whois impossible. Best regards, Carsten From ripe-wgs.cs at schiefner.de Fri Nov 18 16:28:17 2005 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Fri, 18 Nov 2005 16:28:17 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: References: Message-ID: <437DF311.7020203@schiefner.de> Michael, Michael.Dillon at btradianz.com wrote: > [...] > If they don't move quickly, then someone else will build that > anycast infrastructure and both DENIC and AFNIC will be reduced > to being customers instead of network operators. why would that be? Best regards, Carsten From ripe-wgs.cs at schiefner.de Fri Nov 18 17:51:56 2005 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Fri, 18 Nov 2005 17:51:56 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <87hdaavu3v.fsf@mid.deneb.enyo.de> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <877jb8v3dr.fsf@mid.deneb.enyo.de> <437DF2C7.903@schiefner.de> <87hdaavu3v.fsf@mid.deneb.enyo.de> Message-ID: <437E06AC.5090606@schiefner.de> Florian, Florian Weimer wrote: >>of course, I can't speak for every DNS operator, but DENIC denying the >>transfer of the .de zone has no other reason than data protection, ie. >>making the harvesting of contact data of some 9 million plus domain name >>holders by just piping the zone through the whois impossible. > > Your claim is absurd. The real privacy issue comes form forced > publication of WHOIS data. As a member of the DENIC executive board, > you certainly know that, so please stop spreading such misinformation. it's interesting that you appear to know what I "certainly" know... What I indeed know is that DENIC's whois policy is well balanced between the interests of the individual domain name holder and the general public: bulk access to whois data is not possible, but only on a per-domain-name basis - ie. you need to have the domain name at hand to get the appropriate whois data. And besides that there is no other means (aka. 'key' - eg. last name, city of residence etc.) to access that data. This policy, BTW, is in full accordance with the relevant data protection bodies. But may I suggest that we have that discussion off this list - as RIPE's address policy and IPv6 WGs are IMHO the wrong fora to discuss DENIC's whois policy - and moved to a place of your choice? Best, Carsten From gert at space.net Sat Nov 19 16:16:44 2005 From: gert at space.net (Gert Doering) Date: Sat, 19 Nov 2005 16:16:44 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051117105032.GO99793@kerkenna.nic.fr> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <43775E10.3020604@cc.univie.ac.at> <87y83otoar.fsf@mid.deneb.enyo.de> <20051117105032.GO99793@kerkenna.nic.fr> Message-ID: <20051119151644.GB15782@Space.Net> Hi, On Thu, Nov 17, 2005 at 11:50:32AM +0100, Mohsen Souissi wrote: > ==> This is just amazing! I have been follwing this topic for more > than two years and I have the feeling that we are making again and > again the history! I remember that when the IPv6 "PI" issue was first > raised in the IPv6/LIR wgs ("LIR" was the old name for "AP" at that > time), the answer was "PI is out of scope of this wg". I'm not sure which WG you are talking about (IPv6 WG or LIR WG?), but it's certainly in scope for the address policy WG. The topic of PI space for IPv6 just has been avoided like the plague so far - nobody seems to be able to define proper criteria for IPv6 PI, and I'm fairly sure we will not be able to reach consensus for IPv4-style PI ("come and ask for it, and that's all you need to do"). Personally, I've seen some doomsayers so far ("IPv6 will die if we have no PI!"), but I can't remember having seen a proposal for rules that let "those that we all agree should have it" have PI, and "those that we all agree should not have it" not have it. Which reflects on the problem - there are many readers here that have good arguments against any sort of PI (that is not needed for DNS purposes, due to protocol constraints [brokenness]), and others see any possible alternative as "this is just not going to work" (read "I'm politically opposing this, and because it isn't PI, it is not acceptable")... so getting consensus will be tough. > Now, I'm surprised that we are going back to the original issue and > asking to first solve the PI problem... "We" aren't. These are just some comments by some of the participants. But of course "we" will, if someone formulates a specific policy proposal how to make PI work. > If that's to be done and while we ar at it, we can see again how RIPE > is the only RIR not considering TLD networks as "critical > infrastructure" while an appropriate policy has been already > implemented in all other existing RIRs for a long while (please > revisit the comparative matrix of RIR policies at > http://www.ripe.net/info/resource-admin/rir-comp-matrix-rev.html and > see how RIPE is lagging behind in this matter. Some of this > mailing-list member would say: "that was our choice!"). Isn't it a > European speciality to discuss over again and again issues without > coming to any solution? It certainly is an European speciality to bring up the same discussion again and again without any new facts that might affect the outcome. DNS is special, in that the protocol is fairly broken, but too widespread to re-do over night. This warrants special cases for the root, and maybe special cases for *anycast* - but nobody is asking for special cases for normal unicast DNS servers. That's what glue records are for, and they work fairly well. DNS is critical infrastructure, but nobody has explained properly yet why "critical infrastructure" (in itself) requires a different way to get IP addresses. Even so, Google is likely more critical to more people than some of the ccTLDs out there... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Sun Nov 20 17:28:27 2005 From: gert at space.net (Gert Doering) Date: Sun, 20 Nov 2005 17:28:27 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051120111903.GI96756@new.detebe.org> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <43775E10.3020604@cc.univie.ac.at> <87y83otoar.fsf@mid.deneb.enyo.de> <20051117105032.GO99793@kerkenna.nic.fr> <20051119151644.GB15782@Space.Net> <20051120111903.GI96756@new.detebe.org> Message-ID: <20051120162827.GF15782@Space.Net> Hi, On Sun, Nov 20, 2005 at 12:19:03PM +0100, Elmar K. Bins wrote: > Just to get the thing rolling again with something new :-) Which is not so new. Pekka wrote a draft about that, some years ago. > gert at space.net (Gert Doering) wrote: > > > Personally, I've seen some doomsayers so far ("IPv6 will die if we have > > no PI!"), but I can't remember having seen a proposal for rules that let > > "those that we all agree should have it" have PI, and "those that we > > all agree should not have it" not have it. > > How about: Every ASN is entitled to an IPv6 block. Full stop. > Then you can tie it to independency of routing and to the rules for ASNs. > > Anyone else think along these lines? This will change the question "who is worthy to receive an IPv6 block" into "who is worthy to receive an AS number" - which is today defined on a pure technical basis, with the "hurdle" being the address acquisition, not the AS number. If you tie it to the *routing* policy thing ("verifiable dual upstreams" or such), it will indeed solve some parts of "the PI problem", without opening the flood gates to "everyone". OTOHO, it might make "everyone" want to get an AS number - and BGP "multihoming" isn't so hard to achieve, if it only serves the purpose of qualifying for an AS number... Now if the future would not be so cloudy today... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Sun Nov 20 17:29:07 2005 From: gert at space.net (Gert Doering) Date: Sun, 20 Nov 2005 17:29:07 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <43805CAD.5040104@netegral.co.uk> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <43775E10.3020604@cc.univie.ac.at> <87y83otoar.fsf@mid.deneb.enyo.de> <20051117105032.GO99793@kerkenna.nic.fr> <20051119151644.GB15782@Space.Net> <20051120111903.GI96756@new.detebe.org> <43805CAD.5040104@netegral.co.uk> Message-ID: <20051120162907.GG15782@Space.Net> Hi, On Sun, Nov 20, 2005 at 11:23:25AM +0000, Cameron C. Gray wrote: > I think even the routing-table purists will agree that 64K routes > maximum size will be fine. AS numbers are not really limited to 16 bits... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From fw at deneb.enyo.de Fri Nov 18 16:44:20 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 18 Nov 2005 16:44:20 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <437DF2C7.903@schiefner.de> (Carsten Schiefner's message of "Fri, 18 Nov 2005 16:27:03 +0100") References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <877jb8v3dr.fsf@mid.deneb.enyo.de> <437DF2C7.903@schiefner.de> Message-ID: <87hdaavu3v.fsf@mid.deneb.enyo.de> * Carsten Schiefner: > of course, I can't speak for every DNS operator, but DENIC denying the > transfer of the .de zone has no other reason than data protection, ie. > making the harvesting of contact data of some 9 million plus domain name > holders by just piping the zone through the whois impossible. Your claim is absurd. The real privacy issue comes form forced publication of WHOIS data. As a member of the DENIC executive board, you certainly know that, so please stop spreading such misinformation. From bmanning at vacation.karoshi.com Fri Nov 18 17:20:15 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 18 Nov 2005 16:20:15 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <437DF311.7020203@schiefner.de> References: <437DF311.7020203@schiefner.de> Message-ID: <20051118162015.GA16936@vacation.karoshi.com.> On Fri, Nov 18, 2005 at 04:28:17PM +0100, Carsten Schiefner wrote: > Michael, > > Michael.Dillon at btradianz.com wrote: > >[...] > >If they don't move quickly, then someone else will build that > >anycast infrastructure and both DENIC and AFNIC will be reduced > >to being customers instead of network operators. > > why would that be? > > Best regards, > > Carsten because, apparently, customers aka service operators are inferior to network operators aka plumbers. a $DEITY forbid that an TLD operator ego be brused by not being considered in the same class as plumbers. tongue partly in cheek. perhaps there is the consideration that TLD ops are "special" in some unique way that preclueds them from fate-sharing with a plumber when the pipes break. e.g. they have not taken steps to distribute their service or content so that it is available over different carriers, on alternate power grids, in other countries. ... and perhaps ... using a variety of publishers ... instead of trying to run all that infrastructure in addition to operating the TLD. OR... why do tld operators have to have all the servers under infrastructure they run? when did this change? example: DEnic could have CNnic, BRnic, and CAnic run slave servers for them in their areas. Why is this a bad thing? --bill From elmi at 4ever.de Sun Nov 20 12:19:03 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Sun, 20 Nov 2005 12:19:03 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051119151644.GB15782@Space.Net> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <43775E10.3020604@cc.univie.ac.at> <87y83otoar.fsf@mid.deneb.enyo.de> <20051117105032.GO99793@kerkenna.nic.fr> <20051119151644.GB15782@Space.Net> Message-ID: <20051120111903.GI96756@new.detebe.org> Just to get the thing rolling again with something new :-) gert at space.net (Gert Doering) wrote: > Personally, I've seen some doomsayers so far ("IPv6 will die if we have > no PI!"), but I can't remember having seen a proposal for rules that let > "those that we all agree should have it" have PI, and "those that we > all agree should not have it" not have it. How about: Every ASN is entitled to an IPv6 block. Full stop. Then you can tie it to independency of routing and to the rules for ASNs. Anyone else think along these lines? Elmi. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From cgray at netegral.co.uk Sun Nov 20 12:23:25 2005 From: cgray at netegral.co.uk (Cameron C. Gray) Date: Sun, 20 Nov 2005 11:23:25 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051120111903.GI96756@new.detebe.org> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <43775E10.3020604@cc.univie.ac.at> <87y83otoar.fsf@mid.deneb.enyo.de> <20051117105032.GO99793@kerkenna.nic.fr> <20051119151644.GB15782@Space.Net> <20051120111903.GI96756@new.detebe.org> Message-ID: <43805CAD.5040104@netegral.co.uk> Elmar K. Bins wrote: >How about: Every ASN is entitled to an IPv6 block. Full stop. >Then you can tie it to independency of routing and to the rules for ASNs. > >Anyone else think along these lines? > Elmi. > > Hear! Hear! I think even the routing-table purists will agree that 64K routes maximum size will be fine. I'm for this approach. -- Best regards, Cameron Gray Director Netegral Limited Registry: uk.netegral From elmi at 4ever.de Sun Nov 20 12:49:49 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Sun, 20 Nov 2005 12:49:49 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <43805CAD.5040104@netegral.co.uk> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <43775E10.3020604@cc.univie.ac.at> <87y83otoar.fsf@mid.deneb.enyo.de> <20051117105032.GO99793@kerkenna.nic.fr> <20051119151644.GB15782@Space.Net> <20051120111903.GI96756@new.detebe.org> <43805CAD.5040104@netegral.co.uk> Message-ID: <20051120114949.GK96756@new.detebe.org> cgray at netegral.co.uk (Cameron C. Gray) wrote: > I think even the routing-table purists will agree that 64K routes > maximum size will be fine. In IPv6 it might just work ;-) Address space handout policies were deliberately tuned to be able to give every (valid) requestor a block that would fit their needs indefinitely. Some exceptions will of course exist... Elmar. PS: Don't bet on the 64K... -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From fw at deneb.enyo.de Mon Nov 21 09:28:08 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 21 Nov 2005 09:28:08 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <437E06AC.5090606@schiefner.de> (Carsten Schiefner's message of "Fri, 18 Nov 2005 17:51:56 +0100") References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <877jb8v3dr.fsf@mid.deneb.enyo.de> <437DF2C7.903@schiefner.de> <87hdaavu3v.fsf@mid.deneb.enyo.de> <437E06AC.5090606@schiefner.de> Message-ID: <87zmnyjtgn.fsf@mid.deneb.enyo.de> * Carsten Schiefner: > Florian, > > Florian Weimer wrote: >>> of course, I can't speak for every DNS operator, but DENIC denying >>> the transfer of the .de zone has no other reason than data >>> protection, ie. making the harvesting of contact data of some 9 >>> million plus domain name holders by just piping the zone through >>> the whois impossible. >> Your claim is absurd. The real privacy issue comes form forced >> publication of WHOIS data. As a member of the DENIC executive board, >> you certainly know that, so please stop spreading such misinformation. > > it's interesting that you appear to know what I "certainly" know... Don't tell me you haven't been briefed on such issues. 8-/ Anyway, I have moved the discussion to a more appropriate list. Just to make myself clear, I understand that publishing zones in a ready-to-process manner might not be in the best interest of everyone. For example, if an ISP A suffers a significant outage, a competing ISP B might sift through zone data, enumerate all domains served by ISP A's name servers. When that ISP is back again, ISP B uses the imprints for said domains (that is. if there is a web server) to gather postal addresses of ISP A's customers, making them an offer to switch (by snail mail, of course, otherwise it would be spam). Incidentally this is one of the reasons why I don't publish all the zone data I've recovered, but this is not really related to privacy concerns. From lea.roberts at stanford.edu Mon Nov 21 16:12:45 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Mon, 21 Nov 2005 07:12:45 -0800 (PST) Subject: [ipv6-wg] IPv6 PI In-Reply-To: <20051120111903.GI96756@new.detebe.org> Message-ID: as long as it's "something new", let's get a fresh subject line... :-) On Sun, 20 Nov 2005, Elmar K. Bins wrote: > Just to get the thing rolling again with something new :-) > > > gert at space.net (Gert Doering) wrote: > > > Personally, I've seen some doomsayers so far ("IPv6 will die if we have > > no PI!"), but I can't remember having seen a proposal for rules that let > > "those that we all agree should have it" have PI, and "those that we > > all agree should not have it" not have it. > > How about: Every ASN is entitled to an IPv6 block. Full stop. > Then you can tie it to independency of routing and to the rules for ASNs. > > Anyone else think along these lines? > Elmi. this was the original ARIN proposal 2005-1, which could not reach consensus. The last time around it was re-worked to add more restrictions and again failed because other folks felt it was too restrictive. There are actually two issues: 1) the high cost of renumbering in a large organization 2) multi-homing for network reliability and resiliency the problem with using ASNs is that when you think over the projected lifetime of IPv6, there will be *lots* of ASNs. Note that the 4-byte ASN draft is entering the standards track in IETF. Don't think that tying PI to ASNs is anything more that passing the problem to the next generation (if that long... :-) It would seem obvious that as network connectivity becomes essential for doing business, it must be reliable. It is unwise to carry forward the IPv4 multi-homing model for network resilience with just faith that the system will be able to scale to an ever larger number of routes. IPv6 has so far failed to deliver on its original promise of seamless renumbering and multi-homing using multiple prefixes. The hard problems still need to be solved in a way that can scale for decades to come. regards, /Lea From lea.roberts at stanford.edu Mon Nov 21 18:41:04 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Mon, 21 Nov 2005 09:41:04 -0800 (PST) Subject: [ipv6-wg] IPv6 PI In-Reply-To: Message-ID: On Mon, 21 Nov 2005, Roger Jorgensen wrote: > On Mon, 21 Nov 2005, Lea Roberts wrote: > > > the problem with using ASNs is that when you think over the projected > > lifetime of IPv6, there will be *lots* of ASNs. Note that the 4-byte ASN > > draft is entering the standards track in IETF. Don't think that tying PI > > to ASNs is anything more that passing the problem to the next generation > > (if that long... :-) > > > > It would seem obvious that as network connectivity becomes essential for > > doing business, it must be reliable. It is unwise to carry forward the > > IPv4 multi-homing model for network resilience with just faith that the > > system will be able to scale to an ever larger number of routes. IPv6 has > > so far failed to deliver on its original promise of seamless renumbering > > and multi-homing using multiple prefixes. The hard problems still need to > > be solved in a way that can scale for decades to come. > > Can't we all just drop using the word multihoming and IPv6 PI? > They all reflect back to how thing was done with IPv4 and those ways are > doomed to fail with IPv6 simply due to the size of the IP space. Well said. From rogerj at jorgensen.no Mon Nov 21 17:10:10 2005 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Mon, 21 Nov 2005 17:10:10 +0100 (CET) Subject: [ipv6-wg] IPv6 PI In-Reply-To: References: Message-ID: On Mon, 21 Nov 2005, Lea Roberts wrote: > the problem with using ASNs is that when you think over the projected > lifetime of IPv6, there will be *lots* of ASNs. Note that the 4-byte ASN > draft is entering the standards track in IETF. Don't think that tying PI > to ASNs is anything more that passing the problem to the next generation > (if that long... :-) > > It would seem obvious that as network connectivity becomes essential for > doing business, it must be reliable. It is unwise to carry forward the > IPv4 multi-homing model for network resilience with just faith that the > system will be able to scale to an ever larger number of routes. IPv6 has > so far failed to deliver on its original promise of seamless renumbering > and multi-homing using multiple prefixes. The hard problems still need to > be solved in a way that can scale for decades to come. Can't we all just drop using the word multihoming and IPv6 PI? They all reflect back to how thing was done with IPv4 and those ways are doomed to fail with IPv6 simply due to the size of the IP space. Last I checked around there were some promissing new proposal on the way for how to solve this very basic problem. And in the meantime, drop the thought about multihoming and PI space, start to think about other ways to use the possibility IPv6 give us. Just to mention maybe the biggest advantage, we have that extended header part of IPv6, it give us endless possibilities. and yes I do have some idea about how it can be done but no one really bother to consider geo-based IP's either so... :) Not to forget it quite likely will undermine the entire business case for how ISP's today operate. -- ------------------------------ Roger Jorgensen | rogerj at stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no ------------------------------------------------------- From elmi at 4ever.de Mon Nov 21 17:27:02 2005 From: elmi at 4ever.de (Elmar K. Bins) Date: Mon, 21 Nov 2005 17:27:02 +0100 Subject: [ipv6-wg] Re: IPv6 PI In-Reply-To: References: <20051120111903.GI96756@new.detebe.org> Message-ID: <20051121162702.GE96756@new.detebe.org> lea.roberts at stanford.edu (Lea Roberts) wrote: > this was the original ARIN proposal 2005-1, which could not reach > consensus. The last time around it was re-worked to add more restrictions > and again failed because other folks felt it was too restrictive. There > are actually two issues: > > 1) the high cost of renumbering in a large organization Why should they renumber, if it's their own block? > 2) multi-homing for network reliability and resiliency Where's the problem here? Someone who can afford and establish a case for _real_ multihoming can get an ASN and thus an assignment. Like was already said - loosening the ASN handout rules needs changes in assignment rules, too. But that's for years to come. Yours, Elmi. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, ) --------------------------------------------------------------[ ELMI-RIPE ]--- From randy at psg.com Mon Nov 21 20:05:02 2005 From: randy at psg.com (Randy Bush) Date: Mon, 21 Nov 2005 09:05:02 -1000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI References: Message-ID: <17282.6750.71566.966599@roam.psg.com> >> Can't we all just drop using the word multihoming and IPv6 PI? >> They all reflect back to how thing was done with IPv4 and those ways are >> doomed to fail with IPv6 simply due to the size of the IP space. > Well said. indeed. since, by this argument, we can now assume v6 sites will not multi-home, there is no need for PI space at all. randy From ripe-wgs.cs at schiefner.de Tue Nov 22 11:45:49 2005 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Tue, 22 Nov 2005 11:45:49 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <87zmnyjtgn.fsf@mid.deneb.enyo.de> References: <200511112244.jABMiYpQ011727@mail03.hipercom.no> <43767AF1.4000302@oslo.net> <877jb8v3dr.fsf@mid.deneb.enyo.de> <437DF2C7.903@schiefner.de> <87hdaavu3v.fsf@mid.deneb.enyo.de> <437E06AC.5090606@schiefner.de> <87zmnyjtgn.fsf@mid.deneb.enyo.de> Message-ID: <4382F6DD.3010400@schiefner.de> >>>Your claim is absurd. The real privacy issue comes form forced >>>publication of WHOIS data. As a member of the DENIC executive board, >>>you certainly know that, so please stop spreading such misinformation. >> >>it's interesting that you appear to know what I "certainly" know... > > Don't tell me you haven't been briefed on such issues. 8-/ Be assured, I consider myself very well up to speed with regard to DENIC's business. I was actually referring to my alleged knowledge of the absurdity of my "claim" and the existence of "privacy issues". > Anyway, I > have moved the discussion to a more appropriate list. Seen that; EOD here then. Regards, Carsten From simon at limmat.switch.ch Wed Nov 23 14:25:46 2005 From: simon at limmat.switch.ch (Simon Leinen) Date: Wed, 23 Nov 2005 14:25:46 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or something else? In-Reply-To: <20051118162015.GA16936@vacation.karoshi.com.> (bmanning@vacation.karoshi.com's message of "Fri, 18 Nov 2005 16:20:15 +0000") References: <437DF311.7020203@schiefner.de> <20051118162015.GA16936@vacation.karoshi.com.> Message-ID: bmanning writes: > because, apparently, customers aka service operators are > inferior to network operators aka plumbers. a $DEITY forbid > that an TLD operator ego be brused by not being considered in > the same class as plumbers. [...] > > tongue partly in cheek. > > perhaps there is the consideration that TLD ops are "special" > in some unique way that preclueds them from fate-sharing with > a plumber when the pipes break. e.g. they have not taken > steps to distribute their service or content so that it is > available over different carriers, on alternate power grids, > in other countries. ... and perhaps ... using a variety of > publishers ... instead of trying to run all that > infrastructure in addition to operating the TLD. OR... why > do tld operators have to have all the servers under > infrastructure they run? when did this change? Well said, Bill. > example: > DEnic could have CNnic, BRnic, and CAnic run slave servers for > them in their areas. Why is this a bad thing? As Kurt Jaeger aka pi said in a previous posting (although in a different context): > That's a national security issue for some countries. So it's all a matter of control. In a similar vein, see http://www.imconf.net/imc-2005/papers/imc05efiles/ramasubramanian/ramasubramanian.pdf "Perils of Transitive Trust in the Domain Name System", V. Ramasubramanian and E. G?n Sirer, IMC 2005 Personally I don't share the opinion that more centralized control leads to safer systems, but then nobody asks me. -- Simon. Speaking only for himself, but partly getting paid for helping to operate some TLD nameservers. From fw at deneb.enyo.de Thu Nov 24 18:58:04 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 24 Nov 2005 18:58:04 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: (Roger Jorgensen's message of "Mon, 21 Nov 2005 17:10:10 +0100 (CET)") References: Message-ID: <87sltm3p3n.fsf@mid.deneb.enyo.de> * Roger Jorgensen: > Can't we all just drop using the word multihoming and IPv6 PI? > They all reflect back to how thing was done with IPv4 and those ways are > doomed to fail with IPv6 simply due to the size of the IP space. I'm a relative newcomer to this area. Could you give a pointer to some explanation *why* the IPv6 address space size causes this problem? From oliver at bartels.de Thu Nov 24 19:22:24 2005 From: oliver at bartels.de (Oliver Bartels) Date: Thu, 24 Nov 2005 19:22:24 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: Message-ID: <200511241822.jAOIMAfk018658@alpha.bartels.de> On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: >Can't we all just drop using the word multihoming and IPv6 PI? The better solution is the enemy of the good solution. If IPv4 offers PI = provider _independence_ and multihoming and IPv6 doesn't, then IPv4 is obviously the better solution for those who requires this functionallity. Thus they won't use IPv6. Please keep in mind: The _customer_ votes, not you, not me. And as the majority of the large and a significant portion of medium size businesses are obviously not willing to accept an IP protocol not providing this functionallity, IPv6 will remain at it's current status: A technical playground for technically interested people. >They all reflect back to how thing was done with IPv4 and those ways are >doomed to fail with IPv6 simply due to the size of the IP space. Could you please explain this a bit more in detail ? To me this sounds like "engines will never fly". >Last I checked around there were some promissing new proposal on the >way for how to solve this very basic problem. Could you please be a bit more verbose. >And in the meantime, drop >the thought about multihoming and PI space, start to think about other >ways to use the possibility IPv6 give us. Hmm, please let me translate: "Even if the car doesn't drive and the engine doesn't deliver a single horse power at the wheels, drop the thought about driving, start to think about other way to use the possibility this great car gives us." Sound like newspeak: If we _think_ we can't solve the problem, drop discussing the problem. Best Regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From rogerj at jorgensen.no Fri Nov 25 10:12:35 2005 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Fri, 25 Nov 2005 10:12:35 +0100 (CET) Subject: [ipv6-wg] closed network and need for global uniqe IP space In-Reply-To: <200511241822.jAOIMAfk018658@alpha.bartels.de> References: <200511241822.jAOIMAfk018658@alpha.bartels.de> Message-ID: Sorry for cross-posting but not sure where it really belong... ----------- Hi, First, the question is more, what is the correct way of dealing with situation like this? I work for a entity with a big and closed network where security and being closed came first. We're not governement but we have our mandate defined by them. Our only connection to Internet are through several uplinks with few public IP where we run proxy solution for the little traffic that are allowed to hit internet. Are in reality no incoming routes to us, and none out. Internal we use RFC1918 IP space,(private IP) and we for now have enough IP space but we are experience conflicts between IP space when connecting to other big closed network. Not to forget the size, we will probably run out of IP space to... (and I know others have run out of RFC1918 space on their internal network) Most would suggest request a /48 or bigger from your uplink right now and that's not going to work for several reasons: * size, just one of bigger sites connected probably need more than a /48 just for themself, and we have several of them, and alot of smaller sites/network. We're probably talking /32 or more if I have to guess. * scalability, we could of course get /48 and break the /64 boundary, a thought I seriously hate. But that will give us other kind of problems, sites needing a /64 or more due to some equipment or so... * there are other BIGGER network of the same type. * control over who is using what IP and where etc... as said above, security and being closed are probably the two most important factors for us. * need global unique IP's since we're connecting to other network of the same type, and NAT are not really the way we want to go with IPv6 ... and probably more I can't remember right now. The solutions aren't really that tricky but let me mention a few options... * Site local would have solved our problem BUT it's obsolite, quite stupid really. * just take a prefix and use it... this will give us problem in the future due to not being unique. * extensiv usage of NAT, eh do we really want to even consider THAT for IPv6? * become LIR and request the needed IP space. * let one of our uplinks request the IP space for us. I'm in favour of the last two options, any of them... and they are as I see it the really two options as things are now. Any thoughts? comments? -- ------------------------------ Roger Jorgensen | rogerj at stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no ------------------------------------------------------- From rogerj at jorgensen.no Fri Nov 25 10:36:25 2005 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Fri, 25 Nov 2005 10:36:25 +0100 (CET) Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: <87sltm3p3n.fsf@mid.deneb.enyo.de> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> Message-ID: On Thu, 24 Nov 2005, Florian Weimer wrote: > * Roger Jorgensen: > > > Can't we all just drop using the word multihoming and IPv6 PI? > > They all reflect back to how thing was done with IPv4 and those ways are > > doomed to fail with IPv6 simply due to the size of the IP space. > > I'm a relative newcomer to this area. Could you give a pointer to > some explanation *why* the IPv6 address space size causes this > problem? Just do the math yourself and consider all possibilities and how the IPv4 space are used... but some numbers - the address space is 128bit. - we have a 64bits host prefix at the lower end. - the above give us 64bits of network numbers, that's quite a few billions of networks. BUT - the /48 boundary leaving us with a usable globaly network space of 48bit - from the 48bits only a /8 are usable as it is now, the other 7 /8 are reserved for the future. The absolute max global routing table would by this be 40bits, of course the real one are alot smaller. That one is closer to 32bits, and that is STILL A huge number, probably more close to 20bits of entries. a last comment: the entire idea behind /64 and /48 will cause IPv6 to fail as it is now. Odd as it is, we don't have enough IP space in IPv6. Sure it will last 10, maybe 15-20 years, but that did IPv4 to...... -- ------------------------------ Roger Jorgensen | rogerj at stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no ------------------------------------------------------- From rogerj at jorgensen.no Fri Nov 25 10:55:54 2005 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Fri, 25 Nov 2005 10:55:54 +0100 (CET) Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: <200511241822.jAOIMAfk018658@alpha.bartels.de> References: <200511241822.jAOIMAfk018658@alpha.bartels.de> Message-ID: On Thu, 24 Nov 2005, Oliver Bartels wrote: > On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: > If IPv4 offers PI = provider _independence_ and multihoming > and IPv6 doesn't, then IPv4 is obviously the better solution for > those who requires this functionallity. > > Thus they won't use IPv6. > > Please keep in mind: The _customer_ votes, not you, not me. > > And as the majority of the large and a significant portion of medium > size businesses are obviously not willing to accept an IP protocol not > providing this functionallity, IPv6 will remain at it's current status: > > A technical playground for technically interested people. a very true point in one way but that is again as I see it, we're still thinking IPv4 when talking IPv6. Why do they need multihoming and PI? They don't trust the ISP and vendors to deliver them uptime and freedom... isn't this a problem the ISP and vendors should try to solve? Of course, the idea of easy renumbering was suppose to solve this but again, we're thinking IPv4 so it's not easy to understand. Again, we don't need PI space and multihoming, what we need are a way to give the users and GOOD connectivity (uptime, speed etc) and make it easy for them to switch providers as they see fit. > > Hmm, please let me translate: > "Even if the car doesn't drive and the engine doesn't deliver a single > horse power at the wheels, drop the thought about driving, > start to think about other way to use the possibility this great car > gives us." > > Sound like newspeak: > If we _think_ we can't solve the problem, drop discussing the problem. for several years this discussion have been going on, still no real solution. IPv6 give us the freedom todo ALOT of things, USE those possibilities, if we have to change how IP are done, some TCP headers etc, then do it... propose a good idea and prove it. That could give us multihoming. Actually there is a master thesis about howto create connectivity for TCP session even if one of the links went down, the session just used another IP (1)... the user don't notice anything either and it have zero problem working with standard tcp-stacks since it use the extended header of IPv6. That's just ONE of many possible ways... (1) it's a master thesis writting by a student related to University of Troms?? as part of the Pasta project, www.pasta.cs.uit.no -- ------------------------------ Roger Jorgensen | rogerj at stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no ------------------------------------------------------- From oppermann at networx.ch Fri Nov 25 10:58:43 2005 From: oppermann at networx.ch (Andre Oppermann) Date: Fri, 25 Nov 2005 10:58:43 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI References: <87sltm3p3n.fsf@mid.deneb.enyo.de> Message-ID: <4386E053.73B661B3@networx.ch> Roger Jorgensen wrote: > > On Thu, 24 Nov 2005, Florian Weimer wrote: > > * Roger Jorgensen: > > > > > Can't we all just drop using the word multihoming and IPv6 PI? > > > They all reflect back to how thing was done with IPv4 and those ways are > > > doomed to fail with IPv6 simply due to the size of the IP space. > > > > I'm a relative newcomer to this area. Could you give a pointer to > > some explanation *why* the IPv6 address space size causes this > > problem? > > Just do the math yourself and consider all possibilities and how the IPv4 > space are used... but some numbers > > - the address space is 128bit. > - we have a 64bits host prefix at the lower end. > - the above give us 64bits of network numbers, that's quite a few billions > of networks. BUT > - the /48 boundary leaving us with a usable globaly network space of 48bit > - from the 48bits only a /8 are usable as it is now, the other 7 /8 are > reserved for the future. > > The absolute max global routing table would by this be 40bits, of > course the real one are alot smaller. That one is closer to 32bits, and > that is STILL A huge number, probably more close to 20bits of entries. > > a last comment: the entire idea behind /64 and /48 will cause IPv6 to fail > as it is now. Odd as it is, we don't have enough IP space in IPv6. Sure it > will last 10, maybe 15-20 years, but that did IPv4 to...... You post is still pretty content-free. You're waving with your hand but what do you propose exactly? I've posted my proposals under "Andre's guide to fix IPv6". When do you with yours? -- Andre From oppermann at networx.ch Fri Nov 25 11:02:45 2005 From: oppermann at networx.ch (Andre Oppermann) Date: Fri, 25 Nov 2005 11:02:45 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI References: <200511241822.jAOIMAfk018658@alpha.bartels.de> Message-ID: <4386E145.F0748506@networx.ch> Roger Jorgensen wrote: > > On Thu, 24 Nov 2005, Oliver Bartels wrote: > > On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: > > > If IPv4 offers PI = provider _independence_ and multihoming > > and IPv6 doesn't, then IPv4 is obviously the better solution for > > those who requires this functionallity. > > > > Thus they won't use IPv6. > > > > Please keep in mind: The _customer_ votes, not you, not me. > > > > And as the majority of the large and a significant portion of medium > > size businesses are obviously not willing to accept an IP protocol not > > providing this functionallity, IPv6 will remain at it's current status: > > > > A technical playground for technically interested people. > > a very true point in one way but that is again as I see it, we're still > thinking IPv4 when talking IPv6. We're thinking Real World(TM). > Why do they need multihoming and PI? They don't trust the ISP and vendors > to deliver them uptime and freedom... isn't this a problem the ISP and > vendors should try to solve? Of course, the idea of easy renumbering was > suppose to solve this but again, we're thinking IPv4 so it's not easy to > understand. > > Again, we don't need PI space and multihoming, what we need are a way to > give the users and GOOD connectivity (uptime, speed etc) and make it easy > for them to switch providers as they see fit. That's only part of the reasoning. Customers don't want to be locked in to any one ISP. They want to have bargaining power which only comes with the ability to switch ISPs at will. > > > > > Hmm, please let me translate: > > "Even if the car doesn't drive and the engine doesn't deliver a single > > horse power at the wheels, drop the thought about driving, > > start to think about other way to use the possibility this great car > > gives us." > > > > Sound like newspeak: > > If we _think_ we can't solve the problem, drop discussing the problem. > > for several years this discussion have been going on, still no real > solution. IPv6 give us the freedom todo ALOT of things, USE those > possibilities, if we have to change how IP are done, some TCP headers etc, > then do it... propose a good idea and prove it. That could give us > multihoming. Actually there is a master thesis about howto create > connectivity for TCP session even if one of the links went down, the > session just used another IP (1)... the user don't notice anything > either and it have zero problem working with standard tcp-stacks since it > use the extended header of IPv6. Yea, that's known as SCTP. > That's just ONE of many possible ways... You're only handwaiving and saying "no". We are looking for ways to fit IPv6 to the reality of how millions of people and corporations use and want to use the Internet, technically and commercially. -- Andre From gert at space.net Fri Nov 25 11:18:46 2005 From: gert at space.net (Gert Doering) Date: Fri, 25 Nov 2005 11:18:46 +0100 Subject: [ipv6-wg] closed network and need for global uniqe IP space In-Reply-To: References: <200511241822.jAOIMAfk018658@alpha.bartels.de> Message-ID: <20051125101846.GM69925@Space.Net> Hi, On Fri, Nov 25, 2005 at 10:12:35AM +0100, Roger Jorgensen wrote: > The solutions aren't really that tricky but let me mention a few > options... > * Site local would have solved our problem BUT it's obsolite, quite > stupid really. That's why there are ULA ("unique local addresses") now. They should fit your needs pretty well - as much addresses as you want, and the guarantee to be not officially assigned to anyone. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From rogerj at jorgensen.no Fri Nov 25 11:25:07 2005 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Fri, 25 Nov 2005 11:25:07 +0100 (CET) Subject: [address-policy-wg] Re: [ipv6-wg] closed network and need for globa l uniqe IP space In-Reply-To: <20051125101846.GM69925@Space.Net> References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <20051125101846.GM69925@Space.Net> Message-ID: On Fri, 25 Nov 2005, Gert Doering wrote: > Hi, > > On Fri, Nov 25, 2005 at 10:12:35AM +0100, Roger Jorgensen wrote: > > The solutions aren't really that tricky but let me mention a few > > options... > > * Site local would have solved our problem BUT it's obsolite, quite > > stupid really. > > That's why there are ULA ("unique local addresses") now. They should > fit your needs pretty well - as much addresses as you want, and the > guarantee to be not officially assigned to anyone. what about the other part about globaly unique when we connect to other network of the same type? -- ------------------------------ Roger Jorgensen | rogerj at stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no ------------------------------------------------------- From gert at space.net Fri Nov 25 11:38:44 2005 From: gert at space.net (Gert Doering) Date: Fri, 25 Nov 2005 11:38:44 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] closed network and need for globa l uniqe IP space In-Reply-To: References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <20051125101846.GM69925@Space.Net> Message-ID: <20051125103844.GO69925@Space.Net> Hi, On Fri, Nov 25, 2005 at 11:25:07AM +0100, Roger Jorgensen wrote: > > On Fri, Nov 25, 2005 at 10:12:35AM +0100, Roger Jorgensen wrote: > > > The solutions aren't really that tricky but let me mention a few > > > options... > > > * Site local would have solved our problem BUT it's obsolite, quite > > > stupid really. > > > > That's why there are ULA ("unique local addresses") now. They should > > fit your needs pretty well - as much addresses as you want, and the > > guarantee to be not officially assigned to anyone. > > what about the other part about globaly unique when we connect to other > network of the same type? The idea is that ULAs are random-generated in a way that makes it "fairly unlikely" that you end up in an address collision. But there is no guarantee, of course. There is also a second sort of ULAs that are globally unique but still private, but as far as I know, there is no registry yet that will hand them out. So these can't be used yet. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 81421 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From fw at deneb.enyo.de Fri Nov 25 12:10:39 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 25 Nov 2005 12:10:39 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: (Roger Jorgensen's message of "Fri, 25 Nov 2005 10:36:25 +0100 (CET)") References: <87sltm3p3n.fsf@mid.deneb.enyo.de> Message-ID: <87y83dq8y8.fsf@mid.deneb.enyo.de> * Roger Jorgensen: > The absolute max global routing table would by this be 40bits, of > course the real one are alot smaller. That one is closer to 32bits, and > that is STILL A huge number, probably more close to 20bits of entries. Only 20 bits? IPv4 already has more than 17 bits of entries. I still don't see the problem. To the contrary, your numbers suggest that IPv6 is very similar to IPv4 in this regard. From peter.sherbin at bell.ca Fri Nov 25 15:50:52 2005 From: peter.sherbin at bell.ca (peter.sherbin at bell.ca) Date: Fri, 25 Nov 2005 09:50:52 -0500 Subject: [ipv6-wg] RE: address-policy-wg (ipv6-wg digest, Vol 1 #271 - 11 msgs) Message-ID: >Oliver Bartels: >If IPv4 offers PI = provider _independence_ and multihoming >and IPv6 doesn't, then IPv4 is obviously the better solution for >those who requires this functionallity. > >Thus they won't use IPv6. > >Please keep in mind: The _customer_ votes, not you, not me. > >And as the majority of the large and a significant portion of medium >size businesses are obviously not willing to accept an IP protocol not >providing this functionallity, IPv6 will remain at it's current status: > >A technical playground for technically interested people. My project requires a few millions of IPv6 addresses. The application has to: 1. avoid renumbering of the network 2. keep allocated addresses for an extended period of time Current ARIN allocation schema: ARIN -> LIR -> End User does not make much sence because to get addresses I: - either have to become a LIR, which I may not necessarily want, or - the entire application depends on fortunes of a third party (LIR), which is a prohibitive risk factor for the investment On the other side I am willing to "rent" addresses from a registry (ARIN) and return the allocation when it is no longer needed. Now, how do we change the current address allocation policy which kills IPv6 in its cradle? Thank you, Peter Sherbin 416 353-5917 >-----Original Message----- >From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of ipv6- >wg-request at ripe.net >Sent: November/25/ 2005 06:00 >To: ipv6-wg at ripe.net >Subject: ipv6-wg digest, Vol 1 #271 - 11 msgs > >Send ipv6-wg mailing list submissions to > ipv6-wg at ripe.net > >To subscribe or unsubscribe via the World Wide Web, visit > http://www.ripe.net/mailman/listinfo/ipv6-wg >or, via email, send a message with subject or body 'help' to > ipv6-wg-request at ripe.net > >You can reach the person managing the list at > ipv6-wg-admin at ripe.net > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of ipv6-wg digest..." > > >Today's Topics: > > 1. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Florian Weimer) > 2. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Oliver Bartels) > 3. closed network and need for global uniqe IP space (Roger Jorgensen) > 4. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Roger Jorgensen) > 5. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Roger Jorgensen) > 6. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Andre Oppermann) > 7. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Andre Oppermann) > 8. Re: closed network and need for global uniqe IP space (Gert Doering) > 9. Re: [address-policy-wg] Re: [ipv6-wg] closed network and need for > globa l uniqe IP space (Roger Jorgensen) > 10. Re: [address-policy-wg] Re: [ipv6-wg] closed network and need for globa l >uniqe IP space (Gert Doering) > >--__--__-- > >Message: 1 >From: Florian Weimer >To: Roger Jorgensen >Cc: Lea Roberts , address-policy-wg at ripe.net, ipv6- >wg at ripe.net, roger at jorgensen.no >Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI >Date: Thu, 24 Nov 2005 18:58:04 +0100 > >* Roger Jorgensen: > >> Can't we all just drop using the word multihoming and IPv6 PI? >> They all reflect back to how thing was done with IPv4 and those ways are >> doomed to fail with IPv6 simply due to the size of the IP space. > >I'm a relative newcomer to this area. Could you give a pointer to >some explanation *why* the IPv6 address space size causes this >problem? > > >--__--__-- > >Message: 2 >From: "Oliver Bartels" >To: "ipv6-wg at ripe.net" , > "address-policy-wg at ripe.net" , > "Roger Jorgensen" >Date: Thu, 24 Nov 2005 19:22:24 +0100 >Reply-To: "Oliver Bartels" >Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > >On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: >>Can't we all just drop using the word multihoming and IPv6 PI? > >The better solution is the enemy of the good solution. > >If IPv4 offers PI = provider _independence_ and multihoming >and IPv6 doesn't, then IPv4 is obviously the better solution for >those who requires this functionallity. > >Thus they won't use IPv6. > >Please keep in mind: The _customer_ votes, not you, not me. > >And as the majority of the large and a significant portion of medium >size businesses are obviously not willing to accept an IP protocol not >providing this functionallity, IPv6 will remain at it's current status: > >A technical playground for technically interested people. > >>They all reflect back to how thing was done with IPv4 and those ways are >>doomed to fail with IPv6 simply due to the size of the IP space. > >Could you please explain this a bit more in detail ? >To me this sounds like "engines will never fly". > >>Last I checked around there were some promissing new proposal on the >>way for how to solve this very basic problem. > >Could you please be a bit more verbose. > >>And in the meantime, drop >>the thought about multihoming and PI space, start to think about other >>ways to use the possibility IPv6 give us. > >Hmm, please let me translate: >"Even if the car doesn't drive and the engine doesn't deliver a single >horse power at the wheels, drop the thought about driving, >start to think about other way to use the possibility this great car >gives us." > >Sound like newspeak: >If we _think_ we can't solve the problem, drop discussing the problem. > >Best Regards >Oliver > > > >Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany >oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 > > > > > >--__--__-- > >Message: 3 >Date: Fri, 25 Nov 2005 10:12:35 +0100 (CET) >From: Roger Jorgensen >To: ipv6-wg at ripe.net, address-policy-wg at ripe.net >cc: roger at jorgensen.no >Subject: [ipv6-wg] closed network and need for global uniqe IP space > >Sorry for cross-posting but not sure where it really belong... >----------- > >Hi, > >First, the question is more, what is the correct way of dealing with >situation like this? > > > > >I work for a entity with a big and closed network where security and >being closed came first. We're not governement but we have our mandate >defined by them. >Our only connection to Internet are through several uplinks with few >public IP where we run proxy solution for the little traffic that are >allowed to hit internet. Are in reality no incoming routes to us, and none >out. >Internal we use RFC1918 IP space,(private IP) and we for now have enough >IP space but we are experience conflicts between IP space when connecting >to other big closed network. Not to forget the size, we will probably run >out of IP space to... (and I know others have run out of RFC1918 space on >their internal network) > > >Most would suggest request a /48 or bigger from your uplink right now and >that's not going to work for several reasons: >* size, just one of bigger sites connected probably need more than a /48 >just for themself, and we have several of them, and alot of smaller >sites/network. We're probably talking /32 or more if I have to guess. > >* scalability, we could of course get /48 and break the /64 boundary, >a thought I seriously hate. But that will give us other kind of problems, >sites needing a /64 or more due to some equipment or so... > >* there are other BIGGER network of the same type. > >* control over who is using what IP and where etc... as said above, >security and being closed are probably the two most important factors for >us. > >* need global unique IP's since we're connecting to other network of the >same type, and NAT are not really the way we want to go with IPv6 > >... and probably more I can't remember right now. > > >The solutions aren't really that tricky but let me mention a few >options... >* Site local would have solved our problem BUT it's obsolite, quite >stupid really. > >* just take a prefix and use it... this will give us problem in the future >due to not being unique. > >* extensiv usage of NAT, eh do we really want to even consider THAT for >IPv6? > >* become LIR and request the needed IP space. > >* let one of our uplinks request the IP space for us. > > > >I'm in favour of the last two options, any of them... and they are as I >see it the really two options as things are now. Any thoughts? comments? > > > >-- > >------------------------------ >Roger Jorgensen | >rogerj at stud.cs.uit.no | - IPv6 is The Key! >http://www.jorgensen.no | roger at jorgensen.no >------------------------------------------------------- > > >--__--__-- > >Message: 4 >Date: Fri, 25 Nov 2005 10:36:25 +0100 (CET) >From: Roger Jorgensen >To: Florian Weimer >cc: address-policy-wg at ripe.net, ipv6-wg at ripe.net, roger at jorgensen.no >Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > >On Thu, 24 Nov 2005, Florian Weimer wrote: >> * Roger Jorgensen: >> >> > Can't we all just drop using the word multihoming and IPv6 PI? >> > They all reflect back to how thing was done with IPv4 and those ways are >> > doomed to fail with IPv6 simply due to the size of the IP space. >> >> I'm a relative newcomer to this area. Could you give a pointer to >> some explanation *why* the IPv6 address space size causes this >> problem? > >Just do the math yourself and consider all possibilities and how the IPv4 >space are used... but some numbers > >- the address space is 128bit. >- we have a 64bits host prefix at the lower end. >- the above give us 64bits of network numbers, that's quite a few billions >of networks. BUT >- the /48 boundary leaving us with a usable globaly network space of 48bit >- from the 48bits only a /8 are usable as it is now, the other 7 /8 are >reserved for the future. > >The absolute max global routing table would by this be 40bits, of >course the real one are alot smaller. That one is closer to 32bits, and >that is STILL A huge number, probably more close to 20bits of entries. > > > >a last comment: the entire idea behind /64 and /48 will cause IPv6 to fail >as it is now. Odd as it is, we don't have enough IP space in IPv6. Sure it >will last 10, maybe 15-20 years, but that did IPv4 to...... > > > >-- > >------------------------------ >Roger Jorgensen | >rogerj at stud.cs.uit.no | - IPv6 is The Key! >http://www.jorgensen.no | roger at jorgensen.no >------------------------------------------------------- > > >--__--__-- > >Message: 5 >Date: Fri, 25 Nov 2005 10:55:54 +0100 (CET) >From: Roger Jorgensen >To: Oliver Bartels >cc: "ipv6-wg at ripe.net" , > "address-policy-wg at ripe.net" , > roger at jorgensen.no >Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > >On Thu, 24 Nov 2005, Oliver Bartels wrote: >> On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: > >> If IPv4 offers PI = provider _independence_ and multihoming >> and IPv6 doesn't, then IPv4 is obviously the better solution for >> those who requires this functionallity. >> >> Thus they won't use IPv6. >> >> Please keep in mind: The _customer_ votes, not you, not me. >> >> And as the majority of the large and a significant portion of medium >> size businesses are obviously not willing to accept an IP protocol not >> providing this functionallity, IPv6 will remain at it's current status: >> >> A technical playground for technically interested people. > >a very true point in one way but that is again as I see it, we're still >thinking IPv4 when talking IPv6. > >Why do they need multihoming and PI? They don't trust the ISP and vendors >to deliver them uptime and freedom... isn't this a problem the ISP and >vendors should try to solve? Of course, the idea of easy renumbering was >suppose to solve this but again, we're thinking IPv4 so it's not easy to >understand. > >Again, we don't need PI space and multihoming, what we need are a way to >give the users and GOOD connectivity (uptime, speed etc) and make it easy >for them to switch providers as they see fit. > > > > >> >> Hmm, please let me translate: >> "Even if the car doesn't drive and the engine doesn't deliver a single >> horse power at the wheels, drop the thought about driving, >> start to think about other way to use the possibility this great car >> gives us." >> >> Sound like newspeak: >> If we _think_ we can't solve the problem, drop discussing the problem. > >for several years this discussion have been going on, still no real >solution. IPv6 give us the freedom todo ALOT of things, USE those >possibilities, if we have to change how IP are done, some TCP headers etc, >then do it... propose a good idea and prove it. That could give us >multihoming. Actually there is a master thesis about howto create >connectivity for TCP session even if one of the links went down, the >session just used another IP (1)... the user don't notice anything >either and it have zero problem working with standard tcp-stacks since it >use the extended header of IPv6. > >That's just ONE of many possible ways... > > > >(1) it's a master thesis writting by a student related to University of >Troms?? as part of the Pasta project, www.pasta.cs.uit.no > >-- > >------------------------------ >Roger Jorgensen | >rogerj at stud.cs.uit.no | - IPv6 is The Key! >http://www.jorgensen.no | roger at jorgensen.no >------------------------------------------------------- > > >--__--__-- > >Message: 6 >Date: Fri, 25 Nov 2005 10:58:43 +0100 >From: Andre Oppermann >To: Roger Jorgensen >CC: Florian Weimer , address-policy-wg at ripe.net, > ipv6-wg at ripe.net, roger at jorgensen.no >Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > >Roger Jorgensen wrote: >> >> On Thu, 24 Nov 2005, Florian Weimer wrote: >> > * Roger Jorgensen: >> > >> > > Can't we all just drop using the word multihoming and IPv6 PI? >> > > They all reflect back to how thing was done with IPv4 and those ways are >> > > doomed to fail with IPv6 simply due to the size of the IP space. >> > >> > I'm a relative newcomer to this area. Could you give a pointer to >> > some explanation *why* the IPv6 address space size causes this >> > problem? >> >> Just do the math yourself and consider all possibilities and how the IPv4 >> space are used... but some numbers >> >> - the address space is 128bit. >> - we have a 64bits host prefix at the lower end. >> - the above give us 64bits of network numbers, that's quite a few billions >> of networks. BUT >> - the /48 boundary leaving us with a usable globaly network space of 48bit >> - from the 48bits only a /8 are usable as it is now, the other 7 /8 are >> reserved for the future. >> >> The absolute max global routing table would by this be 40bits, of >> course the real one are alot smaller. That one is closer to 32bits, and >> that is STILL A huge number, probably more close to 20bits of entries. >> >> a last comment: the entire idea behind /64 and /48 will cause IPv6 to fail >> as it is now. Odd as it is, we don't have enough IP space in IPv6. Sure it >> will last 10, maybe 15-20 years, but that did IPv4 to...... > >You post is still pretty content-free. You're waving with your hand >but what do you propose exactly? I've posted my proposals under "Andre's >guide to fix IPv6". When do you with yours? > >-- >Andre > > >--__--__-- > >Message: 7 >Date: Fri, 25 Nov 2005 11:02:45 +0100 >From: Andre Oppermann >To: Roger Jorgensen >CC: Oliver Bartels , > "ipv6-wg at ripe.net" , > "address-policy-wg at ripe.net" , > roger at jorgensen.no >Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > >Roger Jorgensen wrote: >> >> On Thu, 24 Nov 2005, Oliver Bartels wrote: >> > On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: >> >> > If IPv4 offers PI = provider _independence_ and multihoming >> > and IPv6 doesn't, then IPv4 is obviously the better solution for >> > those who requires this functionallity. >> > >> > Thus they won't use IPv6. >> > >> > Please keep in mind: The _customer_ votes, not you, not me. >> > >> > And as the majority of the large and a significant portion of medium >> > size businesses are obviously not willing to accept an IP protocol not >> > providing this functionallity, IPv6 will remain at it's current status: >> > >> > A technical playground for technically interested people. >> >> a very true point in one way but that is again as I see it, we're still >> thinking IPv4 when talking IPv6. > >We're thinking Real World(TM). > >> Why do they need multihoming and PI? They don't trust the ISP and vendors >> to deliver them uptime and freedom... isn't this a problem the ISP and >> vendors should try to solve? Of course, the idea of easy renumbering was >> suppose to solve this but again, we're thinking IPv4 so it's not easy to >> understand. >> >> Again, we don't need PI space and multihoming, what we need are a way to >> give the users and GOOD connectivity (uptime, speed etc) and make it easy >> for them to switch providers as they see fit. > >That's only part of the reasoning. Customers don't want to be locked >in to any one ISP. They want to have bargaining power which only comes >with the ability to switch ISPs at will. > >> >> > >> > Hmm, please let me translate: >> > "Even if the car doesn't drive and the engine doesn't deliver a single >> > horse power at the wheels, drop the thought about driving, >> > start to think about other way to use the possibility this great car >> > gives us." >> > >> > Sound like newspeak: >> > If we _think_ we can't solve the problem, drop discussing the problem. >> >> for several years this discussion have been going on, still no real >> solution. IPv6 give us the freedom todo ALOT of things, USE those >> possibilities, if we have to change how IP are done, some TCP headers etc, >> then do it... propose a good idea and prove it. That could give us >> multihoming. Actually there is a master thesis about howto create >> connectivity for TCP session even if one of the links went down, the >> session just used another IP (1)... the user don't notice anything >> either and it have zero problem working with standard tcp-stacks since it >> use the extended header of IPv6. > >Yea, that's known as SCTP. > >> That's just ONE of many possible ways... > >You're only handwaiving and saying "no". We are looking for ways to fit >IPv6 to the reality of how millions of people and corporations use and >want to use the Internet, technically and commercially. > >-- >Andre > > >--__--__-- > >Message: 8 >Date: Fri, 25 Nov 2005 11:18:46 +0100 >From: Gert Doering >To: Roger Jorgensen >Cc: ipv6-wg at ripe.net, address-policy-wg at ripe.net, roger at jorgensen.no >Subject: Re: [ipv6-wg] closed network and need for global uniqe IP space > >Hi, > >On Fri, Nov 25, 2005 at 10:12:35AM +0100, Roger Jorgensen wrote: >> The solutions aren't really that tricky but let me mention a few >> options... >> * Site local would have solved our problem BUT it's obsolite, quite >> stupid really. > >That's why there are ULA ("unique local addresses") now. They should >fit your needs pretty well - as much addresses as you want, and the >guarantee to be not officially assigned to anyone. > >Gert Doering > -- NetMaster >-- >Total number of prefixes smaller than registry allocations: 81421 > >SpaceNet AG Mail: netmaster at Space.Net >Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 >D- 80807 Muenchen Fax : +49-89-32356-234 > > >--__--__-- > >Message: 9 >Date: Fri, 25 Nov 2005 11:25:07 +0100 (CET) >From: Roger Jorgensen >To: Gert Doering >cc: ipv6-wg at ripe.net, address-policy-wg at ripe.net, roger at jorgensen.no >Subject: Re: [address-policy-wg] Re: [ipv6-wg] closed network and need for > globa l uniqe IP space > >On Fri, 25 Nov 2005, Gert Doering wrote: >> Hi, >> >> On Fri, Nov 25, 2005 at 10:12:35AM +0100, Roger Jorgensen wrote: >> > The solutions aren't really that tricky but let me mention a few >> > options... >> > * Site local would have solved our problem BUT it's obsolite, quite >> > stupid really. >> >> That's why there are ULA ("unique local addresses") now. They should >> fit your needs pretty well - as much addresses as you want, and the >> guarantee to be not officially assigned to anyone. > >what about the other part about globaly unique when we connect to other >network of the same type? > > > >-- > > >------------------------------ >Roger Jorgensen | >rogerj at stud.cs.uit.no | - IPv6 is The Key! >http://www.jorgensen.no | roger at jorgensen.no >------------------------------------------------------- > > >--__--__-- > >Message: 10 >Date: Fri, 25 Nov 2005 11:38:44 +0100 >From: Gert Doering >To: Roger Jorgensen >Cc: Gert Doering , ipv6-wg at ripe.net, > address-policy-wg at ripe.net, roger at jorgensen.no >Subject: Re: [address-policy-wg] Re: [ipv6-wg] closed network and need for globa > l uniqe IP space > >Hi, > >On Fri, Nov 25, 2005 at 11:25:07AM +0100, Roger Jorgensen wrote: >> > On Fri, Nov 25, 2005 at 10:12:35AM +0100, Roger Jorgensen wrote: >> > > The solutions aren't really that tricky but let me mention a few >> > > options... >> > > * Site local would have solved our problem BUT it's obsolite, quite >> > > stupid really. >> > >> > That's why there are ULA ("unique local addresses") now. They should >> > fit your needs pretty well - as much addresses as you want, and the >> > guarantee to be not officially assigned to anyone. >> >> what about the other part about globaly unique when we connect to other >> network of the same type? > >The idea is that ULAs are random-generated in a way that makes it "fairly >unlikely" that you end up in an address collision. But there is no >guarantee, of course. > >There is also a second sort of ULAs that are globally unique but still >private, but as far as I know, there is no registry yet that will hand >them out. So these can't be used yet. > >Gert Doering > -- NetMaster >-- >Total number of prefixes smaller than registry allocations: 81421 > >SpaceNet AG Mail: netmaster at Space.Net >Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 >D- 80807 Muenchen Fax : +49-89-32356-234 > > > > >End of ipv6-wg Digest From jeroen at unfix.org Fri Nov 25 19:02:04 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 25 Nov 2005 19:02:04 +0100 Subject: "Special Application Addresses" (Was: Re: [ipv6-wg] RE: address-policy-wg (ipv6-wg digest, Vol 1 #271 - 11 msgs)) In-Reply-To: References: Message-ID: <4387519C.90501@unfix.org> peter.sherbin at bell.ca wrote: > My project requires a few millions of IPv6 addresses. Then a only need single IPv6 /64 (2^64 is more than a 'few million'). No RIR really has any business with you as you are an enduser according to the above description. > The application has to: > 1. avoid renumbering of the network Why? Your application should be able to use renumber easily using a form of management interface. Does this "network" get connected to the internet? > 2. keep allocated addresses for an extended period of time define "extended period of time". > Current ARIN allocation schema: ARIN -> LIR -> End User does not make much sence because to get addresses I: > - either have to become a LIR, which I may not necessarily want, or You say that you need a 'few million' addresses, but for what exact reason.... > - the entire application depends on fortunes of a third party (LIR), which is a prohibitive risk factor for the investment You also depend on the RIR's according to this which also is a risk factor > On the other side I am willing to "rent" addresses from a registry (ARIN) and return the allocation when it is no longer needed. > > Now, how do we change the current address allocation policy Follow the policy process and make a proposal. > which kills IPv6 in its cradle? That it doesn't rock your boat doesn't mean it is doing anything bad. Greets, Jeroen PS: You might want to delete unused parts of emails, sending 27kb of quoted email which you don't reference is useless. Also changing the subject helps identifying what you are actually mailing about. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From jeroen at unfix.org Sat Nov 26 14:16:25 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 26 Nov 2005 14:16:25 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: <4386E145.F0748506@networx.ch> References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <4386E145.F0748506@networx.ch> Message-ID: <43886029.4040601@unfix.org> Andre Oppermann wrote: > Roger Jorgensen wrote: >> for several years this discussion have been going on, still no real >> solution. IPv6 give us the freedom todo ALOT of things, USE those >> possibilities, if we have to change how IP are done, some TCP headers etc, >> then do it... propose a good idea and prove it. That could give us >> multihoming. Actually there is a master thesis about howto create >> connectivity for TCP session even if one of the links went down, the >> session just used another IP (1)... the user don't notice anything >> either and it have zero problem working with standard tcp-stacks since it >> use the extended header of IPv6. > > Yea, that's known as SCTP. I am always wondering why SCTP is not taking off. From the few tests I did it works perfectly well, the location/identifier separation is pretty cleanly handled in DNS and inside the protocol for quick updates. Unfortunately not much software supports it at the moment. One way to fix that is to add a small proxy/BIA tool which changes TCP+UDP into SCTP. This works for server and client side. But nobody wants to do this for some mysterious reason. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From jeroen at unfix.org Sat Nov 26 14:37:13 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 26 Nov 2005 14:37:13 +0100 Subject: [ipv6-wg] Andre's guide to fix IPv6 (Was: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI) In-Reply-To: <4386E053.73B661B3@networx.ch> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> Message-ID: <43886509.6060600@unfix.org> Andre Oppermann wrote: > I've posted my proposals under "Andre's > guide to fix IPv6". When do you with yours? Ripped from: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2005/msg01166.html > 1. Make /32 the only routable entity so we can use perfect match in > the DFZ instead of longest-prefix match. What about the organizations that have say a /19, want them to inject all their more specific /32's? You can currently already do a perfect match on the first 32bits and then check if there are more specifics for this block or not. But I guess that theory is much better known to you than to me ;) > Perfect match scales > better and is way more economically to implement in hard- and soft- > ware. (MPLS is perfect match too.) Beyond /32 use longest-prefix > up to /64. 32 bit in the DFZ give us 4 billion routable entities. > See "Scalability issues in the Internet routing system" thread on > NANOG, starting 18. October 2005. Should indeed work pretty well. This is also one of the many reasons for me to say that when there will be any "IPv6 PI" introduced it should either be of size /32 or come out of a globally single /20 or something large that should accommodate all these prefixes, so that routing engines can be configured to support longer prefixes in that prefix. > 2. Drop the Flow Label and Next Header fields from the IPv6 header. Next Header is required or how else do you know what follows the IPv6 header? Or do you only want to do TCP? What about UDP,SCTP and many other headers (for IPv6 in IPv6, IPv4 in IPv6, IPSEC etc). > They are architectually broken and do not belong to this layer. > Just encapsulate the packet in another layer like MPLS. Then why not drop IP and just route with MPLS? :) > Next Header is broken because it's just source routing again. Dead > for a long time. Nobody in their right mind will allow header > popping through their firewall/network. That is only one of the many possibilities to use Next Header for. I guess what you wanted to state here is that you don't see a need for "Hop by Hop Options" and other such headers so that routers don't have to parse through the next header because they don't have to expect anything there. Next Header in itself is the same as the IPv4 protocol field stating that TCP/UDP/etc is following it. > 3. Reinsert packet fragmentation into the IPv6 header. Path MTU > discovery just ain't cutting it. And then have routers do fragmentation again? Nah. IMHO fragmentations at endhosts was one of the best things introduced in IPv6. Especially for routers. Also Path MTU works perfectly fine, unless somebody of course drops ICMP, well that is then your issue, not mine. > 4. Drop 64 bits from the IPv6 address. The lower 64 bit are just > pointless as host indentifier. Very poor overhead ratio. Maybe you would like to see something like IPv8/IPv16 then, which according to the fortunately vanished mr Fla^Heming used a "StarGate" model. Something like: +----------------------------------------------+ | Ethernet macsrc+dst next=IPv16_SG | +----------------------------------------------+ | IPv16 StarGate = 3ffe::1 next=IPv16_Planet | +----------------------------------------------+ | IPv16 Planet = 4526::1 next=TCP | +----------------------------------------------+ | TCP | +----------------------------------------------+ > 6. Do away with those stupid ':' separators in IPv6 addresses. That is just representation, if you want you can drop those, just don't expect any (afaik) tool to parse it for you. Most human brains will not like you dropping it though, they are quite comfortable reading hex nicely grouped in clusters of 16bits but would not like to read something that is not nicely clustered, YMMV. You can always easily patch your kernel to support it if you want. The whole idea with IP addresses is that you stick them in DNS in the first place, so you would not see them anyway. (Or are you mailing address-policy-wg@...) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From jeroen at unfix.org Sat Nov 26 14:50:39 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 26 Nov 2005 14:50:39 +0100 Subject: "Special Application Addresses" (Was: Re: [ipv6-wg] RE: address-policy-wg (ipv6-wg digest, Vol 1 #271 - 11 msgs)) In-Reply-To: References: Message-ID: <4388682F.3070803@unfix.org> peter.sherbin at bell.ca wrote: > Jeroen, thanks for your response. > >>> The application has to: >>> 1. avoid renumbering of the network >> Why? Your application should be able to use renumber easily using a form >> of management interface. > > I am using addresses to monitor my devices all the way through their > life cycle. In some cases it could be a physical life cycle from a few > weeks to a few years. I may also aggregate individual items to larger > sub groups. That is why I do not want any changes to static addresses > for unspecified time. The solution for the above can easily be solved by using DNS or a myriad of other solutions. Either you give all those devices a DNS label where they can contact their 'report server' or you give those devices the ability to register to that server. There are many possibilities here and none of these require any specific address space. I suggest you check out mail spam bots and viruses. They implement this all too perfectly well. >> PS: You might want to delete unused parts of emails, sending 27kb of >> quoted email which you don't reference is useless. Also changing the >> subject helps identifying what you are actually mailing about. > > It is a learning curve. will do next time. thanks for pointing this out. I suggest you also read the following article: http://www.xs4all.nl/~hanb/documents/quotingguide.html (Lines 80 chars and more are not very readable either) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From fw at deneb.enyo.de Sat Nov 26 16:00:46 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 26 Nov 2005 16:00:46 +0100 Subject: [ipv6-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <43886509.6060600@unfix.org> (Jeroen Massar's message of "Sat, 26 Nov 2005 14:37:13 +0100") References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> Message-ID: <87acfr1mjl.fsf@mid.deneb.enyo.de> * Jeroen Massar: >> 1. Make /32 the only routable entity so we can use perfect match in >> the DFZ instead of longest-prefix match. > > What about the organizations that have say a /19, want them to inject > all their more specific /32's? You can inject a /19 as 8192 /32s. Shouldn't make a difference if the /19 is really used. At this stage, it's probably not too wise to embed the /32--/48--/64 in silicon, but vendors will undoubtedly do this if they can save a few bucks and current policies remain as inflexible as they are. >> 2. Drop the Flow Label and Next Header fields from the IPv6 header. > > Next Header is required or how else do you know what follows the IPv6 > header? Or do you only want to do TCP? What about UDP,SCTP and many > other headers (for IPv6 in IPv6, IPv4 in IPv6, IPSEC etc). IPv6 was designed for ACL-free software forwarding. This is not what we need today. Real routers must be able to access some layer 4 information. A better header would do away with any layer 3 options or option replacement. It would consist of 7 64-bit words. The first word contains the IP protocol version number, a hop counter (not a TTL, because it can be spoofed), and a bidirectional next-layer protocol identifier (protocol number plus some optional data that is indepedent of the direction of the packet flow and constant for a given "connection"). You can include some bits for QoS if you want, but I'm not sure if this makes sense. This is the first word. After that, the source and destination address follow (two words each). The remaining two remaining words are the next-layer source and destination address identifier (think port number, but you can put some additional cookie in there to make blind spoofing harder). In order to create a reflexive ACL entry, a router would zap the header flags and the hop count (which are ignored during matching anyway) and swap the source and destination addresses. No more upgrades so that you can filter still-a-bit=obscure protocols such as SCTP. Of course, a discussion about header layout is a bit pointless. But it is still a bit unfortunate that a protocol header explicitly designed for efficient forwarding does not come anywhere near that goal. >> 3. Reinsert packet fragmentation into the IPv6 header. Path MTU >> discovery just ain't cutting it. > > And then have routers do fragmentation again? Nah. IMHO fragmentations > at endhosts was one of the best things introduced in IPv6. Sure, makes sesnse. But signaling that fragmentation is needed must be completely in-line. What about this: Truncate the packet, set a bit in the header, and forward it to the destination? The destination can request retransmission from the source and specify the exact packet size that went through. > Also Path MTU works perfectly fine, unless somebody of course drops > ICMP, well that is then your issue, not mine. The market has spoken. Dropping ICMP is fine, I'm afraid. >> 4. Drop 64 bits from the IPv6 address. The lower 64 bit are just >> pointless as host indentifier. Very poor overhead ratio. > > Maybe you would like to see something like IPv8/IPv16 then, which > according to the fortunately vanished mr Fla^Heming used a "StarGate" > model. Something like: This is indeed a bit drastic. I'd rather see this attacked from the other angle, wasting less then 64 bits for access networks. The main problem I see with the /64 approach is that the remaining number of bits (< 64, may less than 60) is not sufficient to stuff two unique identifiers into the address (provider identifier and globally unique customer site identifier). From gih at apnic.net Sun Nov 27 22:22:48 2005 From: gih at apnic.net (Geoff Huston) Date: Mon, 28 Nov 2005 08:22:48 +1100 Subject: [address-policy-wg] Re: [ipv6-wg] closed network and need for globa l uniqe IP space In-Reply-To: <20051125103844.GO69925@Space.Net> References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <20051125101846.GM69925@Space.Net> <20051125103844.GO69925@Space.Net> Message-ID: <6.2.0.14.2.20051128075740.02b04d48@kahuna.telstra.net> At 09:38 PM 25/11/2005, Gert Doering wrote: >Hi, > >On Fri, Nov 25, 2005 at 11:25:07AM +0100, Roger Jorgensen wrote: > > > On Fri, Nov 25, 2005 at 10:12:35AM +0100, Roger Jorgensen wrote: > > > > The solutions aren't really that tricky but let me mention a few > > > > options... > > > > * Site local would have solved our problem BUT it's obsolite, quite > > > > stupid really. > > > > > > That's why there are ULA ("unique local addresses") now. They should > > > fit your needs pretty well - as much addresses as you want, and the > > > guarantee to be not officially assigned to anyone. > > > > what about the other part about globaly unique when we connect to other > > network of the same type? > >The idea is that ULAs are random-generated in a way that makes it "fairly >unlikely" that you end up in an address collision. But there is no >guarantee, of course. > >There is also a second sort of ULAs that are globally unique but still >private, but as far as I know, there is no registry yet that will hand >them out. So these can't be used yet. This is an area that has not gone completely dormant. The "unlikeliness" that Gert refers to is the classic birthday problem, and the probability that 2 parties have chosen the same number rises above 0.5 once the candidate population exceeds 1.24 million. So some form of central or coordinated registry action is necessary to ensure that there are no collisions in these numbers. At APNIC we've been looking at how such a system could be supported. Geoff From kurtis at kurtis.pp.se Mon Nov 28 09:04:26 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 28 Nov 2005 09:04:26 +0100 Subject: [ipv6-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <87acfr1mjl.fsf@mid.deneb.enyo.de> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> Message-ID: (deleted address-policy-wg from the cc:) On 26 nov 2005, at 16.00, Florian Weimer wrote: > >>> 2. Drop the Flow Label and Next Header fields from the IPv6 header. >> >> Next Header is required or how else do you know what follows the IPv6 >> header? Or do you only want to do TCP? What about UDP,SCTP and many >> other headers (for IPv6 in IPv6, IPv4 in IPv6, IPSEC etc). > > IPv6 was designed for ACL-free software forwarding. This is not what > we need today. Real routers must be able to access some layer 4 > information. > > A better header would do away with any layer 3 options or option > replacement. It would consist of 7 64-bit words. The first word > contains the IP protocol version number, a hop counter (not a TTL, > because it can be spoofed), and a bidirectional next-layer protocol > identifier (protocol number plus some optional data that is indepedent > of the direction of the packet flow and constant for a given > "connection"). You can include some bits for QoS if you want, but I'm > not sure if this makes sense. This is the first word. > > After that, the source and destination address follow (two words > each). The remaining two remaining words are the next-layer source > and destination address identifier (think port number, but you can put > some additional cookie in there to make blind spoofing harder). > > In order to create a reflexive ACL entry, a router would zap the > header flags and the hop count (which are ignored during matching > anyway) and swap the source and destination addresses. No more > upgrades so that you can filter still-a-bit=obscure protocols such as > SCTP. > > Of course, a discussion about header layout is a bit pointless. But > it is still a bit unfortunate that a protocol header explicitly > designed for efficient forwarding does not come anywhere near that > goal. So AFAIK the state of the art routers does 40G line-rate deep-packet inspection with any pattern matching. So remind me again what the problem is? Price? Sure, that is a question of demand and volume production... When MPLS was new I remember being told by vendors that it was the only way we could forward IPv4 at 10G line-rate. Go figure. - kurtis - From fw at deneb.enyo.de Mon Nov 28 09:19:25 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 28 Nov 2005 09:19:25 +0100 Subject: [ipv6-wg] Re: Andre's guide to fix IPv6 In-Reply-To: (Kurt Erik Lindqvist's message of "Mon, 28 Nov 2005 09:04:26 +0100") References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> Message-ID: <87psol89rm.fsf@mid.deneb.enyo.de> * Kurt Erik Lindqvist: > (deleted address-policy-wg from the cc:) Done. > So AFAIK the state of the art routers does 40G line-rate deep-packet > inspection with any pattern matching. So remind me again what the > problem is? 40G line rate with small packets? Sounds neat. (n times 10G line rate with large packets on a signle router has been possible for quite some time now.) Previous router generations couldn't process packets on the fast path as soon as they contained IP options (IPv4) or extension headers (IPv6). Has this really changed? (The whole issue may not be a real problem, it only shows that the claim that IPv6 has been designed for efficient forwarding is crap.) From kurtis at kurtis.pp.se Mon Nov 28 10:34:14 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 28 Nov 2005 10:34:14 +0100 Subject: [ipv6-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <87psol89rm.fsf@mid.deneb.enyo.de> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <87psol89rm.fsf@mid.deneb.enyo.de> Message-ID: <35AF2B5C-A242-4137-B788-9817D15C1C84@kurtis.pp.se> On 28 nov 2005, at 09.19, Florian Weimer wrote: > >> So AFAIK the state of the art routers does 40G line-rate deep-packet >> inspection with any pattern matching. So remind me again what the >> problem is? > > 40G line rate with small packets? Sounds neat. (n times 10G line > rate with large packets on a signle router has been possible for quite > some time now.) > > Previous router generations couldn't process packets on the fast path > as soon as they contained IP options (IPv4) or extension headers > (IPv6). Has this really changed? Not for previous version no... > (The whole issue may not be a real problem, it only shows that the > claim that IPv6 has been designed for efficient forwarding is crap.) Well...that argument goes both ways. You could also say that the hw vendors didn't follow the development as IPv6 was certainly defined when the current hw was designed. The real issue is the upgrade costs and how willing providers are to upgrade for _just_ ipv6 forwarding capacity. Probably not very as the revenue margin will stay the same. OTOH they will upgrade for faster line-rate over time anyway and the problem over time is non-existing. Personally I don't think v6 gives as much increased forwarding capacity as MPLS - none. OTOH there are v6 claims in the marketing and press that tends to make me more upset :-) The increased security is my favourite :-) - kurtis - From fw at deneb.enyo.de Mon Nov 28 12:25:48 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 28 Nov 2005 12:25:48 +0100 Subject: [ipv6-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <35AF2B5C-A242-4137-B788-9817D15C1C84@kurtis.pp.se> (Kurt Erik Lindqvist's message of "Mon, 28 Nov 2005 10:34:14 +0100") References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <87psol89rm.fsf@mid.deneb.enyo.de> <35AF2B5C-A242-4137-B788-9817D15C1C84@kurtis.pp.se> Message-ID: <87mzjp5803.fsf@mid.deneb.enyo.de> * Kurt Erik Lindqvist: >> Previous router generations couldn't process packets on the fast path >> as soon as they contained IP options (IPv4) or extension headers >> (IPv6). Has this really changed? > > Not for previous version no... What do you mean? Do ASIS exist which can skip over an arbitrary number of IPv6 extension headers, at line rate? >> (The whole issue may not be a real problem, it only shows that the >> claim that IPv6 has been designed for efficient forwarding is crap.) > Well...that argument goes both ways. You could also say that the hw > vendors didn't follow the development as IPv6 was certainly defined > when the current hw was designed. Are you sure? The extension header concept seems to stem from SIPP (1994), which predates ASIC forwarding (flow-based forwarding was state of the art back then) and layer 4 filters: | 4.2 SIPP Options | | SIPP includes an improved option mechanism over IPv4. SIPP options | are placed in separate headers that are located between the SIPP | header and the transport-layer header in a packet. Most SIPP option | headers are not examined or processed by any router along a packet's | delivery path until it arrives at its final destination. This | facilitates a major improvement in router performance for packets | containing options. [...] (RFC 1710) To locate the transport layer header, you must perform limited processing for all options. With a chained header (like the one in SIPP and IPv6) of almost arbitrary length, this task can't really be parallelized in hardware. With IPv4, you can at least skip over all IP options in a single step (violating tons of RFCs, and perhaps your peering contract). > The real issue is the upgrade costs and how willing providers are to > upgrade for _just_ ipv6 forwarding capacity. Probably not very as > the revenue margin will stay the same. OTOH they will upgrade for > faster line-rate over time anyway and the problem over time is > non-existing. I think there is also little demand for high worst-case line rate performance (aka "DoS resistance"), especially for IPv6. > Personally I don't think v6 gives as much increased forwarding > capacity as MPLS - none. But this is a pity because one of the explicit design goals was to use a simpler header format, permitting more efficient forwarding. 8-( > OTOH there are v6 claims in the marketing and press that tends to > make me more upset :-) The increased security is my favourite :-) Yes, this is a very good one, too. 8-) From jorgen at hovland.cx Mon Nov 28 17:37:47 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Mon, 28 Nov 2005 17:37:47 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 References: <87sltm3p3n.fsf@mid.deneb.enyo.de><4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> Message-ID: <002f01c5f43a$12631110$44eea2d5@l> ----- Original Message ----- From: "Florian Weimer" Sent: Saturday, November 26, 2005 4:00 PM >* Jeroen Massar: > >>> 1. Make /32 the only routable entity so we can use perfect match in >>> the DFZ instead of longest-prefix match. >> >> What about the organizations that have say a /19, want them to inject >> all their more specific /32's? > > You can inject a /19 as 8192 /32s. Shouldn't make a difference if the > /19 is really used. > > At this stage, it's probably not too wise to embed the /32--/48--/64 > in silicon, but vendors will undoubtedly do this if they can save a > few bucks and current policies remain as inflexible as they are. > Hi, Perfect match is faster but far from better. What I think perhaps would be interesting to see in the future with regards to IPv6 and PI is the following: 1. No PI. _Only_ network operators get a prefix. 2. Customers of network operators can at any time change provider and take their assigned prefix with them. The new provider will announce it as a more specific overriding the aggregate. If the customer decides to get multiple providers, then the network operator with the /32 could also announce a more specific. In the country I live in I can change telecom provider and take my phone number with me to the new provider. Why shouldn't I be able to do that with internet providers? Yes, it will somehow create millions/billions of prefixes (atleasat with todays routing technology/protocols). Network operators should be able to handle that hence rule #1. Joergen Hovland From kurtis at kurtis.pp.se Mon Nov 28 18:21:04 2005 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Mon, 28 Nov 2005 18:21:04 +0100 Subject: [ipv6-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <87mzjp5803.fsf@mid.deneb.enyo.de> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <87psol89rm.fsf@mid.deneb.enyo.de> <35AF2B5C-A242-4137-B788-9817D15C1C84@kurtis.pp.se> <87mzjp5803.fsf@mid.deneb.enyo.de> Message-ID: <33130B62-215A-49A8-8FE2-D1DCFFD70B0C@kurtis.pp.se> On 28 nov 2005, at 12.25, Florian Weimer wrote: > * Kurt Erik Lindqvist: > >>> Previous router generations couldn't process packets on the fast >>> path >>> as soon as they contained IP options (IPv4) or extension headers >>> (IPv6). Has this really changed? >> >> Not for previous version no... > > What do you mean? That deployed hardware is deployed hardware. It won't get magically upgraded. > Do ASIS exist which can skip over an arbitrary > number of IPv6 extension headers, at line rate? Yes. >>> (The whole issue may not be a real problem, it only shows that the >>> claim that IPv6 has been designed for efficient forwarding is crap.) > >> Well...that argument goes both ways. You could also say that the hw >> vendors didn't follow the development as IPv6 was certainly defined >> when the current hw was designed. > > Are you sure? The extension header concept seems to stem from SIPP > (1994), which predates ASIC forwarding (flow-based forwarding was > state of the art back then) and layer 4 filters: Current hardware was designed in last 1-2 years so given the above my argument still holds. > To locate the transport layer header, you must perform limited > processing for all options. With a chained header (like the one in > SIPP and IPv6) of almost arbitrary length, this task can't really be > parallelized in hardware. > > With IPv4, you can at least skip over all IP options in a single step > (violating tons of RFCs, and perhaps your peering contract). I am certainly not an ASICs designer and will never pretend to be one, but AFAIK we can do deep packet inspection at 40G line rate, at an (extremely) high price. CRS-1 for example seem to claim just this. >> Personally I don't think v6 gives as much increased forwarding >> capacity as MPLS - none. > > But this is a pity because one of the explicit design goals was to use > a simpler header format, permitting more efficient forwarding. 8-( Look, IPv6 is longer (more) addresses. Nothing more nothing less. It' won't give you increased performance over v4, but it won't make it worse either. - kurtis - From hph at oslo.net Mon Nov 28 19:15:40 2005 From: hph at oslo.net (Hans Petter Holen) Date: Mon, 28 Nov 2005 19:15:40 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <002f01c5f43a$12631110$44eea2d5@l> References: <87sltm3p3n.fsf@mid.deneb.enyo.de><4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> Message-ID: <438B494C.4030102@oslo.net> J?rgen Hovland wrote: > - > 1. No PI. _Only_ network operators get a prefix. I am an operator of a network - do I get a prefix ? (we have lots of computers and need lots of IP addresses: currently the 5 PCs, 2 printers, a phone and some PDA and a server online) I guess you need to define the criteria in some other way. Perhaps beeing registered with the national regulator > 2. Customers of network operators can at any time change provider and > take their assigned prefix with them. The new provider will announce > it as a more specific overriding the aggregate. If the customer > decides to get multiple providers, then the network operator with the > /32 could also announce a more specific. > > In the country I live in I can change telecom provider and take my > phone number with me to the new provider. Why shouldn't I be able to > do that with internet providers? Maybe we live in the same country ? The National Reference DataBase NRDB will take care of the routing (http://www.nrdb.no - at some point in time I guess they will move to ENUM - so perhaps jump directly to such a solution. But then it will be more difficult to implement the payment model they have. (It costs the operator more to be connected to this database than to get IP addressess from RIPE in addition there is a quarterly service fee to port numbers and even a per lookup fee) > Yes, it will somehow create millions/billions of prefixes (atleasat > with todays routing technology/protocols). Network operators should be > able to handle that hence rule #1. Why should my last provider carry my traffic after I switch provider ? In POTS this may work because there is elaborate interconnect agreements between the providers - I dont know of too may ISPs doing pr user accounting of transit any more. >From the consumer point of view - this is great - from a routing point of view and ISP interconnect point of view - I am not quite sure... -hph From jorgen at hovland.cx Mon Nov 28 19:59:34 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Mon, 28 Nov 2005 19:59:34 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <438B494C.4030102@oslo.net> Message-ID: <200511281859.jASIxbpQ017235@mail03.hipercom.no> -----Original Message----- From: Hans Petter Holen [mailto:hph at oslo.net] Sent: 28. november 2005 19:16 J?rgen Hovland wrote: >> - >> 1. No PI. _Only_ network operators get a prefix. > >I am an operator of a network - do I get a prefix ? (we have lots of >computers and need lots of IP addresses: currently the 5 PCs, 2 >printers, a phone and some PDA and a server online) > >I guess you need to define the criteria in some other way. Perhaps >beeing registered with the national regulator True. The existing RIPE 200 customer rule for ipv6 PA for instance. > 2. Customers of network operators can at any time change provider and > take their assigned prefix with them. The new provider will announce > it as a more specific overriding the aggregate. If the customer > decides to get multiple providers, then the network operator with the > /32 could also announce a more specific. > > In the country I live in I can change telecom provider and take my > phone number with me to the new provider. Why shouldn't I be able to > do that with internet providers? >Maybe we live in the same country ? We sure do (well at least since a few months ago)! > The National Reference DataBase >NRDB will take care of the routing (http://www.nrdb.no - at some point >in time I guess they will move to ENUM - so perhaps jump directly to >such a solution. But then it will be more difficult to implement the >payment model they have. (It costs the operator more to be connected to >this database than to get IP addressess from RIPE in addition there is >a quarterly service fee to port numbers and even a per lookup fee) > >> Yes, it will somehow create millions/billions of prefixes (atleasat >> with todays routing technology/protocols). Network operators should be >> able to handle that hence rule #1. > >Why should my last provider carry my traffic after I switch provider ? >In POTS this may work because there is elaborate interconnect agreements >between the providers - I dont know of too may ISPs doing pr user >accounting of transit any more. The only thing the last provider has to pay for is the LIR fee for their /32, not the traffic. More specific routes usually get priority unless Andre?s magic 32 constant is implemented. I was talking about putting these prefixes in dfz ? or not. You decide by the amount of interconnections you got. Then you would also probably have to decide a payment model, but it is not my business what you do. >From the consumer point of view - this is great - from a routing point >of view and ISP interconnect point of view - I am not quite sure... Yes that?s a question I wasn?t even sure about myself. Cheers, Joergen Hovland From dogwallah at gmail.com Mon Nov 28 20:01:57 2005 From: dogwallah at gmail.com (McTim) Date: Mon, 28 Nov 2005 22:01:57 +0300 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <002f01c5f43a$12631110$44eea2d5@l> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> Message-ID: HI, On 11/28/05, J?rgen Hovland > Hi, > Perfect match is faster but far from better. What I think perhaps would be > interesting to see in the future with regards to IPv6 and PI is the > following: > > 1. No PI. _Only_ network operators get a prefix. > 2. Customers of network operators can at any time change provider and take > their assigned prefix with them. #2 sounds like PI to me. What have I missed? -- Cheers, McTim $ whois -h whois.afrinic.net mctim From fw at deneb.enyo.de Mon Nov 28 20:18:11 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 28 Nov 2005 20:18:11 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <002f01c5f43a$12631110$44eea2d5@l> (=?iso-8859-1?Q?J=F8rgen?= Hovland's message of "Mon, 28 Nov 2005 17:37:47 +0100") References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> Message-ID: <877jas37kc.fsf@mid.deneb.enyo.de> * J?rgen Hovland: > > 1. No PI. _Only_ network operators get a prefix. > 2. Customers of network operators can at any time change provider and take > their assigned prefix with them. The new provider will announce it as a more > specific overriding the aggregate. If the customer decides to get multiple > providers, then the network operator with the /32 could also announce a more > specific. This would imply that you cannot filter the routing table at prefix lengths less than /48. What's worse, outage of an ISP routes traffic to a now-unrelated ISP, which must discard traffic at its own cost. Better get rid of the aggregates. 8-/ > In the country I live in I can change telecom provider and take my > phone number with me to the new provider. Why shouldn't I be able to > do that with internet providers? PSTN routing is completely different. In Germany, routing is mostly static AFAIK, and there is no expectation that you can reach all phone numbers from every phone (and it doesn't work in some cases). From jorgen at hovland.cx Mon Nov 28 20:23:15 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Mon, 28 Nov 2005 20:23:15 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: Message-ID: <200511281923.jASJNFpQ017677@mail03.hipercom.no> -----Original Message----- From: McTim [mailto:dogwallah at gmail.com] > >#2 sounds like PI to me. What have I missed? Hello McTim, You are correct. That?s why I wrote PI in the email:-). It is an attempt to suggest an alternative idea to the PI discussion. Don't get me wrong. I am for PI. This idea is perhaps a bit more hierarchical instead of the standard flat one. Just making sure we have thought of everything before we reach consensus because this PI discussion is very important to ipv6. Cheers, Joergen Hovland From jorgen at hovland.cx Mon Nov 28 20:29:55 2005 From: jorgen at hovland.cx (=?iso-8859-1?Q?J=F8rgen_Hovland?=) Date: Mon, 28 Nov 2005 20:29:55 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <877jas37kc.fsf@mid.deneb.enyo.de> Message-ID: <200511281930.jASJU0pQ017813@mail03.hipercom.no> -----Original Message----- From: Florian Weimer [mailto:fw at deneb.enyo.de] >This would imply that you cannot filter the routing table at prefix >lengths less than /48. What's worse, outage of an ISP routes traffic >to a now-unrelated ISP, which must discard traffic at its own cost. >Better get rid of the aggregates. 8-/ > >> In the country I live in I can change telecom provider and take my >> phone number with me to the new provider. Why shouldn't I be able to >> do that with internet providers? > >PSTN routing is completely different. In Germany, routing is mostly >static AFAIK, and there is no expectation that you can reach all phone >numbers from every phone (and it doesn't work in some cases). I can agree to that. So unless there are more to discuss in this matter may I suggest that somebody that really needs it, hello DENIC!:-), write a general PI proposal to speed up the process. Then maybe we all can begin using IPv6! That would be great. Cheers, Joergen Hovland From sasad at cisco.com Tue Nov 29 00:55:16 2005 From: sasad at cisco.com (Salman Asadullah) Date: Mon, 28 Nov 2005 15:55:16 -0800 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <200511241822.jAOIMAfk018658@alpha.bartels.de> Message-ID: <4.3.2.7.2.20051128155308.01ee8c58@ce-nfs-1.cisco.com> You seem to be far away from the ground realities. Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real issues for a good reason. Regards, Salman At 10:55 AM 11/25/2005 +0100, Roger Jorgensen wrote: >On Thu, 24 Nov 2005, Oliver Bartels wrote: > > On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: > > > If IPv4 offers PI = provider _independence_ and multihoming > > and IPv6 doesn't, then IPv4 is obviously the better solution for > > those who requires this functionallity. > > > > Thus they won't use IPv6. > > > > Please keep in mind: The _customer_ votes, not you, not me. > > > > And as the majority of the large and a significant portion of medium > > size businesses are obviously not willing to accept an IP protocol not > > providing this functionallity, IPv6 will remain at it's current status: > > > > A technical playground for technically interested people. > >a very true point in one way but that is again as I see it, we're still >thinking IPv4 when talking IPv6. > >Why do they need multihoming and PI? They don't trust the ISP and vendors >to deliver them uptime and freedom... isn't this a problem the ISP and >vendors should try to solve? Of course, the idea of easy renumbering was >suppose to solve this but again, we're thinking IPv4 so it's not easy to >understand. > >Again, we don't need PI space and multihoming, what we need are a way to >give the users and GOOD connectivity (uptime, speed etc) and make it easy >for them to switch providers as they see fit. > > > > > > > > Hmm, please let me translate: > > "Even if the car doesn't drive and the engine doesn't deliver a single > > horse power at the wheels, drop the thought about driving, > > start to think about other way to use the possibility this great car > > gives us." > > > > Sound like newspeak: > > If we _think_ we can't solve the problem, drop discussing the problem. > >for several years this discussion have been going on, still no real >solution. IPv6 give us the freedom todo ALOT of things, USE those >possibilities, if we have to change how IP are done, some TCP headers etc, >then do it... propose a good idea and prove it. That could give us >multihoming. Actually there is a master thesis about howto create >connectivity for TCP session even if one of the links went down, the >session just used another IP (1)... the user don't notice anything >either and it have zero problem working with standard tcp-stacks since it >use the extended header of IPv6. > >That's just ONE of many possible ways... > > > >(1) it's a master thesis writting by a student related to University of >Troms?? as part of the Pasta project, www.pasta.cs.uit.no > >-- > >------------------------------ >Roger Jorgensen | >rogerj at stud.cs.uit.no | - IPv6 is The Key! >http://www.jorgensen.no | roger at jorgensen.no >------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From dogwallah at gmail.com Tue Nov 29 05:19:49 2005 From: dogwallah at gmail.com (McTim) Date: Tue, 29 Nov 2005 07:19:49 +0300 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <200511281923.jASJNFpQ017677@mail03.hipercom.no> References: <200511281923.jASJNFpQ017677@mail03.hipercom.no> Message-ID: hiya, (removed address-policy-wg from the cc:) On 11/28/05, J?rgen Hovland wrote: > > -----Original Message----- > From: McTim [mailto:dogwallah at gmail.com] > > > >#2 sounds like PI to me. What have I missed? > > Hello McTim, > You are correct. That's why I wrote PI in the email:-). I guess I misread the below wrong then ;-) J?rgen Hovland wrote: >> - >> 1. No PI. _Only_ network operators get a prefix. > It is an attempt to suggest an alternative idea to the PI discussion. > Don't get me wrong. I am for PI. This idea is perhaps a bit more > hierarchical instead of the standard flat one. Just making sure we have > thought of everything before we reach consensus I am sure thiat consensus will take a very long tiime on this one! We will probably have to talk about grotopological v6 adressing (as they are doing on the ARIN ppml) and a host of other issues. I reckon we ought to wait for shim6 to do their work as well. > because this PI discussion > is very important to ipv6. v. true. -- Cheers, McTim $ whois -h whois.afrinic.net mctim From gih at apnic.net Tue Nov 29 00:15:27 2005 From: gih at apnic.net (Geoff Huston) Date: Tue, 29 Nov 2005 10:15:27 +1100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <002f01c5f43a$12631110$44eea2d5@l> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> Message-ID: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> At 03:37 AM 29/11/2005, J?rgen Hovland wrote: >----- Original Message ----- From: "Florian Weimer" >Sent: Saturday, November 26, 2005 4:00 PM > > >>* Jeroen Massar: >> >>>>1. Make /32 the only routable entity so we can use perfect match in >>>> the DFZ instead of longest-prefix match. >>> >>>What about the organizations that have say a /19, want them to inject >>>all their more specific /32's? >> >>You can inject a /19 as 8192 /32s. Shouldn't make a difference if the >>/19 is really used. >> >>At this stage, it's probably not too wise to embed the /32--/48--/64 >>in silicon, but vendors will undoubtedly do this if they can save a >>few bucks and current policies remain as inflexible as they are. > >Hi, >Perfect match is faster but far from better. What I think perhaps would be >interesting to see in the future with regards to IPv6 and PI is the following: > >1. No PI. _Only_ network operators get a prefix. >2. Customers of network operators can at any time change provider and take >their assigned prefix with them. The new provider will announce it as a >more specific overriding the aggregate. If the customer decides to get >multiple providers, then the network operator with the /32 could also >announce a more specific. > >In the country I live in I can change telecom provider and take my phone >number with me to the new provider. Why shouldn't I be able to do that >with internet providers? >Yes, it will somehow create millions/billions of prefixes (atleasat with >todays routing technology/protocols). Network operators should be able to >handle that hence rule #1. Interesting - it will work for a while, and then you will get to the limit of deployed capability of routing. Then what? Geoff From randy at psg.com Tue Nov 29 08:49:17 2005 From: randy at psg.com (Randy Bush) Date: Mon, 28 Nov 2005 21:49:17 -1000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <4.3.2.7.2.20051128155308.01ee8c58@ce-nfs-1.cisco.com> Message-ID: <17292.2045.5948.933479@roam.psg.com> > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > issues for a good reason. i gather that the message that leslie daigle was given at the last nanog was not well-transmitted to the ietf. no big surprise. you may want to look at http://nanog.org/mtg-0510/real/ipv6-bof.ram randy From oppermann at networx.ch Tue Nov 29 10:13:39 2005 From: oppermann at networx.ch (Andre Oppermann) Date: Tue, 29 Nov 2005 10:13:39 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <200511241822.jAOIMAfk018658@alpha.bartels.de> <4.3.2.7.2.20051128155308.01ee8c58@ce-nfs-1.cisco.com> Message-ID: <438C1BC3.5A7C7C24@networx.ch> Salman Asadullah wrote: > > You seem to be far away from the ground realities. > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > issues for a good reason. Neither Multi6 nor SHIM6 are even in an draft RFC state yet and to be workable they'd have to be implemented on every end-host out there. That is every operating system in sufficient existence. That puts IPv6 even further in the already distant future considering common OS upgrade and replacement cycles. Second this doesn't solve the renumbering problem. Renumbering is not just giving hosts new IP addresses but alost managing DNS and Firewalls. No even remotely workable and scaleable solution has been presented yet. So nice try but no cookie. -- Andre > Regards, > Salman > > At 10:55 AM 11/25/2005 +0100, Roger Jorgensen wrote: > > > On Thu, 24 Nov 2005, Oliver Bartels wrote: > > > On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: > > > > > If IPv4 offers PI = provider _independence_ and multihoming > > > and IPv6 doesn't, then IPv4 is obviously the better solution for > > > those who requires this functionallity. > > > > > > Thus they won't use IPv6. > > > > > > Please keep in mind: The _customer_ votes, not you, not me. > > > > > > And as the majority of the large and a significant portion of medium > > > size businesses are obviously not willing to accept an IP protocol not > > > providing this functionallity, IPv6 will remain at it's current status: > > > > > > A technical playground for technically interested people. > > > > a very true point in one way but that is again as I see it, we're still > > thinking IPv4 when talking IPv6. > > > > Why do they need multihoming and PI? They don't trust the ISP and vendors > > to deliver them uptime and freedom... isn't this a problem the ISP and > > vendors should try to solve? Of course, the idea of easy renumbering was > > suppose to solve this but again, we're thinking IPv4 so it's not easy to > > understand. > > > > Again, we don't need PI space and multihoming, what we need are a way to > > give the users and GOOD connectivity (uptime, speed etc) and make it easy > > for them to switch providers as they see fit. > > > > > > > > > > > > > > Hmm, please let me translate: > > > "Even if the car doesn't drive and the engine doesn't deliver a single > > > horse power at the wheels, drop the thought about driving, > > > start to think about other way to use the possibility this great car > > > gives us." > > > > > > Sound like newspeak: > > > If we _think_ we can't solve the problem, drop discussing the problem. > > > > for several years this discussion have been going on, still no real > > solution. IPv6 give us the freedom todo ALOT of things, USE those > > possibilities, if we have to change how IP are done, some TCP headers etc, > > then do it... propose a good idea and prove it. That could give us > > multihoming. Actually there is a master thesis about howto create > > connectivity for TCP session even if one of the links went down, the > > session just used another IP (1)... the user don't notice anything > > either and it have zero problem working with standard tcp-stacks since it > > use the extended header of IPv6. > > > > That's just ONE of many possible ways... > > > > > > > > (1) it's a master thesis writting by a student related to University of > > Troms?? as part of the Pasta project, www.pasta.cs.uit.no > > > > -- > > > > ------------------------------ > > Roger Jorgensen | > > rogerj at stud.cs.uit.no | - IPv6 is The Key! > > http://www.jorgensen.no | roger at jorgensen.no > > ------------------------------------------------------- From heldal at eml.cc Tue Nov 29 12:21:52 2005 From: heldal at eml.cc (Per Heldal) Date: Tue, 29 Nov 2005 12:21:52 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: <4.3.2.7.2.20051128155308.01ee8c58@ce-nfs-1.cisco.com> References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <200511241822.jAOIMAfk018658@alpha.bartels.de> <4.3.2.7.2.20051128155308.01ee8c58@ce-nfs-1.cisco.com> Message-ID: <1133263312.2928.248556295@webmail.messagingengine.com> On Mon, 28 Nov 2005 15:55:16 -0800, "Salman Asadullah" said: > You seem to be far away from the ground realities. > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > issues for a good reason. > Regardless of the efforts, from a provider POV it's only "work in progress". Make sure your preferred technology is implemented across all platforms and accompanied by solutions for traffic-engineering, filtering and other issues. Then you may have a viable alternative to present to the operators community. Don't expect anybody to adopt new technologies unless they represent some progress. I'm not saying that shim6 is DOA. It *may become* an alternative, but it *is not*. Unless you can convince content-providers to trust their upstream to provide redundancy and thus eliminate the need for end-site multihoming you have the following realistic short-term alternatives: * Keep ipv6 experimental and postpone operational deployment until there's a good technical solution to the multi-homing problem or a way to eliminate the DFZ and the related concerns about routing- table size. * Adopt a PI policy for v6 similar to the current v4-policy, and hope that moore can keep up with the growth of the routing-table. >From there policies will have to evolve, along with the development of new technology. Evolution is a perpetual process, not a project with a finite deadline. PS! am I missing something, or is IETF/IAB trying to copy the ITU in the way they produce paper-standards? Is that really such a good idea? //per -- Per Heldal heldal at eml.cc From jkuijer at dds.nl Tue Nov 29 12:25:08 2005 From: jkuijer at dds.nl (jkuijer at dds.nl) Date: Tue, 29 Nov 2005 12:25:08 +0100 Subject: [ipv6-wg] unsubscibe jkuijer@dds.nl In-Reply-To: <20051129110002.17431.70360.Mailman@postboy.ripe.net> References: <20051129110002.17431.70360.Mailman@postboy.ripe.net> Message-ID: <1133263508.438c3a944d54b@webmail.dds.nl> Citeren ipv6-wg-request at ripe.net: > Send ipv6-wg mailing list submissions to > ipv6-wg at ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.ripe.net/mailman/listinfo/ipv6-wg > or, via email, send a message with subject or body 'help' to > ipv6-wg-request at ripe.net > > You can reach the person managing the list at > ipv6-wg-admin at ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ipv6-wg digest..." > > > Today's Topics: > > 1. Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (McTim) > 2. Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (Geoff Huston) > 3. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Randy Bush) > 4. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Andre Oppermann) > > --__--__-- > > Message: 1 > Date: Tue, 29 Nov 2005 07:19:49 +0300 > From: McTim > To: =?ISO-8859-1?Q?J=F8rgen_Hovland?= > Subject: Re: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 > Cc: ipv6-wg at ripe.net > > hiya, > > (removed address-policy-wg from the cc:) > > On 11/28/05, J=F8rgen Hovland wrote: > > > > -----Original Message----- > > From: McTim [mailto:dogwallah at gmail.com] > > > > > >#2 sounds like PI to me. What have I missed? > > > > Hello McTim, > > You are correct. That's why I wrote PI in the email:-). > > I guess I misread the below wrong then ;-) > > J=F8rgen Hovland wrote: > > >> - > >> 1. No PI. _Only_ network operators get a prefix. > > > It is an attempt to suggest an alternative idea to the PI discussion. > > Don't get me wrong. I am for PI. This idea is perhaps a bit more > > hierarchical instead of the standard flat one. Just making sure we have > > thought of everything before we reach consensus > > I am sure thiat consensus will take a very long tiime on this one! We > will probably have to talk about grotopological v6 adressing (as they > are doing on the ARIN ppml) and a host of other issues. I reckon we > ought to wait for shim6 to do their work as well. > > > because this PI discussion > > is very important to ipv6. > > v. true. > > -- > Cheers, > > McTim > $ whois -h whois.afrinic.net mctim > > > --__--__-- > > Message: 2 > Date: Tue, 29 Nov 2005 10:15:27 +1100 > To: =?iso-8859-1?Q?J=F8rgen?= Hovland , > , > From: Geoff Huston > Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 > > At 03:37 AM 29/11/2005, J=F8rgen Hovland wrote: > >----- Original Message ----- From: "Florian Weimer" > >Sent: Saturday, November 26, 2005 4:00 PM > > > > > >>* Jeroen Massar: > >> > >>>>1. Make /32 the only routable entity so we can use perfect match in > >>>> the DFZ instead of longest-prefix match. > >>> > >>>What about the organizations that have say a /19, want them to inject > >>>all their more specific /32's? > >> > >>You can inject a /19 as 8192 /32s. Shouldn't make a difference if the > >>/19 is really used. > >> > >>At this stage, it's probably not too wise to embed the /32--/48--/64 > >>in silicon, but vendors will undoubtedly do this if they can save a > >>few bucks and current policies remain as inflexible as they are. > > > >Hi, > >Perfect match is faster but far from better. What I think perhaps would be= > =20 > >interesting to see in the future with regards to IPv6 and PI is the= > following: > > > >1. No PI. _Only_ network operators get a prefix. > >2. Customers of network operators can at any time change provider and take= > =20 > >their assigned prefix with them. The new provider will announce it as a=20 > >more specific overriding the aggregate. If the customer decides to get=20 > >multiple providers, then the network operator with the /32 could also=20 > >announce a more specific. > > > >In the country I live in I can change telecom provider and take my phone=20 > >number with me to the new provider. Why shouldn't I be able to do that=20 > >with internet providers? > >Yes, it will somehow create millions/billions of prefixes (atleasat with=20 > >todays routing technology/protocols). Network operators should be able to= > =20 > >handle that hence rule #1. > > > Interesting - it will work for a while, and then you will get to the limit= > =20 > of deployed capability of routing. > > Then what? > > Geoff > > > > > > --__--__-- > > Message: 3 > From: Randy Bush > Date: Mon, 28 Nov 2005 21:49:17 -1000 > To: Salman Asadullah > Cc: Roger Jorgensen , > Oliver Bartels , > "ipv6-wg at ripe.net" , > "address-policy-wg at ripe.net" , > roger at jorgensen.no > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > > issues for a good reason. > > i gather that the message that leslie daigle was given at the > last nanog was not well-transmitted to the ietf. no big > surprise. > > you may want to look at http://nanog.org/mtg-0510/real/ipv6-bof.ram > > randy > > > --__--__-- > > Message: 4 > Date: Tue, 29 Nov 2005 10:13:39 +0100 > From: Andre Oppermann > To: Salman Asadullah > CC: Roger Jorgensen , > Oliver Bartels , > "ipv6-wg at ripe.net" , > "address-policy-wg at ripe.net" , > roger at jorgensen.no > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > > Salman Asadullah wrote: > > > > You seem to be far away from the ground realities. > > > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > > issues for a good reason. > > Neither Multi6 nor SHIM6 are even in an draft RFC state yet and to be > workable they'd have to be implemented on every end-host out there. > That is every operating system in sufficient existence. That puts IPv6 > even further in the already distant future considering common OS upgrade > and replacement cycles. > > Second this doesn't solve the renumbering problem. Renumbering is not > just giving hosts new IP addresses but alost managing DNS and Firewalls. > No even remotely workable and scaleable solution has been presented yet. > > So nice try but no cookie. > > -- > Andre > > > > Regards, > > Salman > > > > At 10:55 AM 11/25/2005 +0100, Roger Jorgensen wrote: > > > > > On Thu, 24 Nov 2005, Oliver Bartels wrote: > > > > On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: > > > > > > > If IPv4 offers PI = provider _independence_ and multihoming > > > > and IPv6 doesn't, then IPv4 is obviously the better solution for > > > > those who requires this functionallity. > > > > > > > > Thus they won't use IPv6. > > > > > > > > Please keep in mind: The _customer_ votes, not you, not me. > > > > > > > > And as the majority of the large and a significant portion of medium > > > > size businesses are obviously not willing to accept an IP protocol not > > > > providing this functionallity, IPv6 will remain at it's current status: > > > > > > > > A technical playground for technically interested people. > > > > > > a very true point in one way but that is again as I see it, we're still > > > thinking IPv4 when talking IPv6. > > > > > > Why do they need multihoming and PI? They don't trust the ISP and vendors > > > to deliver them uptime and freedom... isn't this a problem the ISP and > > > vendors should try to solve? Of course, the idea of easy renumbering was > > > suppose to solve this but again, we're thinking IPv4 so it's not easy to > > > understand. > > > > > > Again, we don't need PI space and multihoming, what we need are a way to > > > give the users and GOOD connectivity (uptime, speed etc) and make it easy > > > for them to switch providers as they see fit. > > > > > > > > > > > > > > > > > > > > Hmm, please let me translate: > > > > "Even if the car doesn't drive and the engine doesn't deliver a single > > > > horse power at the wheels, drop the thought about driving, > > > > start to think about other way to use the possibility this great car > > > > gives us." > > > > > > > > Sound like newspeak: > > > > If we _think_ we can't solve the problem, drop discussing the problem. > > > > > > for several years this discussion have been going on, still no real > > > solution. IPv6 give us the freedom todo ALOT of things, USE those > > > possibilities, if we have to change how IP are done, some TCP headers > etc, > > > then do it... propose a good idea and prove it. That could give us > > > multihoming. Actually there is a master thesis about howto create > > > connectivity for TCP session even if one of the links went down, the > > > session just used another IP (1)... the user don't notice anything > > > either and it have zero problem working with standard tcp-stacks since it > > > use the extended header of IPv6. > > > > > > That's just ONE of many possible ways... > > > > > > > > > > > > (1) it's a master thesis writting by a student related to University of > > > Troms?? as part of the Pasta project, www.pasta.cs.uit.no > > > > > > -- > > > > > > ------------------------------ > > > Roger Jorgensen | > > > rogerj at stud.cs.uit.no | - IPv6 is The Key! > > > http://www.jorgensen.no | roger at jorgensen.no > > > ------------------------------------------------------- > > > > > End of ipv6-wg Digest > From fw at deneb.enyo.de Tue Nov 29 15:26:53 2005 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 29 Nov 2005 15:26:53 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> (Geoff Huston's message of "Tue, 29 Nov 2005 10:15:27 +1100") References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> Message-ID: <87fypfpm1e.fsf@mid.deneb.enyo.de> * Geoff Huston: > Interesting - it will work for a while, and then you will get to the limit > of deployed capability of routing. > > Then what? You buy new routers. What's next? Do you plan to lobby Hollywood to reduce the number of movies create per year, so that your customers have fewer of them to download, and the capacity of your pipes is not exceeded? From randy at psg.com Tue Nov 29 17:17:54 2005 From: randy at psg.com (Randy Bush) Date: Tue, 29 Nov 2005 06:17:54 -1000 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <4.3.2.7.2.20051128155308.01ee8c58@ce-nfs-1.cisco.com> <1133263312.2928.248556295@webmail.messagingengine.com> Message-ID: <17292.32562.222522.723483@roam.psg.com> >> Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real >> issues for a good reason. > Regardless of the efforts, from a provider POV it's only "work in > progress". one of the key points from the nanog session was that shim6 is the *wrong* work in progress. what is needed is _site_ multi-homing, not host multi-homing. randy From gih at apnic.net Tue Nov 29 19:34:05 2005 From: gih at apnic.net (Geoff Huston) Date: Wed, 30 Nov 2005 05:34:05 +1100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: <17292.32562.222522.723483@roam.psg.com> References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <4.3.2.7.2.20051128155308.01ee8c58@ce-nfs-1.cisco.com> <1133263312.2928.248556295@webmail.messagingengine.com> <17292.32562.222522.723483@roam.psg.com> Message-ID: <6.2.0.14.2.20051130052140.02d34f10@kahuna.telstra.net> At 03:17 AM 30/11/2005, Randy Bush wrote: > >> Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > >> issues for a good reason. > > Regardless of the efforts, from a provider POV it's only "work in > > progress". > >one of the key points from the nanog session was that shim6 is the >*wrong* work in progress. what is needed is _site_ multi-homing, >not host multi-homing. "wrong"? "right"? Usual response - if you believe that there is a better way of doing this work through the issues here, then write up an approach, gather support, get peer review etc etc. As I said at NANOG, part of the problem with distributed models where there is action at a distance is to understand and clearly identify instances of gratuitous packet header rewriting by hostile agents as compared to packet rewriting by agents who believe that they are doing this in a friendly and helpful fashion. This becomes a challenging problem,of course. I don't think any single approach today is the one true right approach at this point, but unless we explore this space with some diligence, allow for experimentation and keep an open mind on this work then you are going to get intractably wedged between the desire for greater flexibility in the use of addresses as a form of semi-persistent endpoint identifiers and the desire for reduced flexibility in the use of addresses as forwarding tokens in order to keep the routing space confined to readily computable dimensions. But of course _all_ this will be solved in MPLS - right? :-) Geoff From gih at apnic.net Tue Nov 29 19:36:11 2005 From: gih at apnic.net (Geoff Huston) Date: Wed, 30 Nov 2005 05:36:11 +1100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <87fypfpm1e.fsf@mid.deneb.enyo.de> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> Message-ID: <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> At 01:26 AM 30/11/2005, Florian Weimer wrote: >* Geoff Huston: > > > Interesting - it will work for a while, and then you will get to the limit > > of deployed capability of routing. > > > > Then what? > >You buy new routers. So what you are saying is that _I_ want address portability and _you_ have to buy new routers. Well that sure works for me! How's the chequebook feeling on your side? (I'm not convinced that you've selected the best of business models, as there does appear to be a significant inconsistency going on in your model in that cost and benefit are not related all that well.) Geoff From gih at apnic.net Tue Nov 29 20:01:56 2005 From: gih at apnic.net (Geoff Huston) Date: Wed, 30 Nov 2005 06:01:56 +1100 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: <438C1BC3.5A7C7C24@networx.ch> References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <200511241822.jAOIMAfk018658@alpha.bartels.de> <4.3.2.7.2.20051128155308.01ee8c58@ce-nfs-1.cisco.com> <438C1BC3.5A7C7C24@networx.ch> Message-ID: <6.2.0.14.2.20051130054611.02d206d8@kahuna.telstra.net> At 08:13 PM 29/11/2005, Andre Oppermann wrote: >Salman Asadullah wrote: > > > > You seem to be far away from the ground realities. > > > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > > issues for a good reason. > >Neither Multi6 nor SHIM6 are even in an draft RFC state yet Multi6 produced 5 WG drafts, all of which have been published as RFCs You can (and probably should) read through RFCs 3582, 4116, 4177, 4219, and 4218 SHIM6 is working on the following drafts - again I would recommend that you read though all of them:... draft-ietf-shim6-app-refer, draft-ietf-shim6-applicability, draft-ietf-shim6-arch, draft-ietf-shim6-failure-detection, draft-ietf-shim6-hba, draft-ietf-shim6-proto, and draft-ietf-shim6-reach-detect. > and to be >workable they'd have to be implemented on every end-host out there. >That is every operating system in sufficient existence. That puts IPv6 >even further in the already distant future considering common OS upgrade >and replacement cycles. yep - any form of locator / identity split is such a basic shift in the architectural model used by IP that changes to the stack are required. This is the case in mobility, nomadism, ad-hoc networking and this form of multi-homing. If you want agile locators and any form of persistence in endpoint identifiers then you are not going to get that without changes to the stack. Now if you are arguing that the deployed base of IPv6 is so large that further changes are impossible in this particular technology due to the inertia of the deployed IPv6 base, then that's certainly an interesting perspective, and not one I've heard all that often so far. If you are saying that this will take time to develop and deploy, then you are probably right, and a model that can use incremental deployment using a conventional initial context followed by a capability exchange to explore if there is mutual support for this form of communication capability, then you may well be onto something interesting. Although I'd hasten to add that this is the approach being taken within the SHIM6 architecture. >Second this doesn't solve the renumbering problem. Renumbering is not >just giving hosts new IP addresses but alost managing DNS and Firewalls. >No even remotely workable and scaleable solution has been presented yet. I'm not sure I agree with you about the DNS and renumbering - its not a clearly defined space, and the implications relating to the DNS are not clearly understood in communication models where feasible locator sets are dynamically exchanged rather than always loaded into third party rendezvous points, as in the DNS model. >So nice try but no cookie. Thank you, Geoff From william at elan.net Wed Nov 30 10:53:49 2005 From: william at elan.net (william(at)elan.net) Date: Wed, 30 Nov 2005 01:53:49 -0800 (PST) Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 PI In-Reply-To: <6.2.0.14.2.20051130052140.02d34f10@kahuna.telstra.net> References: <200511241822.jAOIMAfk018658@alpha.bartels.de> <4.3.2.7.2.20051128155308.01ee8c58@ce-nfs-1.cisco.com> <1133263312.2928.248556295@webmail.messagingengine.com> <17292.32562.222522.723483@roam.psg.com> <6.2.0.14.2.20051130052140.02d34f10@kahuna.telstra.net> Message-ID: On Wed, 30 Nov 2005, Geoff Huston wrote: > At 03:17 AM 30/11/2005, Randy Bush wrote: >> >> Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these >> real >> >> issues for a good reason. >> > Regardless of the efforts, from a provider POV it's only "work in >> > progress". >> >> one of the key points from the nanog session was that shim6 is the >> *wrong* work in progress. what is needed is _site_ multi-homing, >> not host multi-homing. Yes, well if it goes forward, it may well end up being used for setting up site-multihoming: http://www.ietf.org/mail-archive/web/architecture-discuss/current/msg00095.html and will be seen as friendly and right solution (on what "friendly" and "right" can mean seen below). > "wrong"? "right"? > > Usual response - if you believe that there is a better way of doing this > work through the issues here, then write up an approach, gather support, get > peer review etc etc. > > As I said at NANOG, part of the problem with distributed models where there > is action at a distance is to understand and clearly identify instances of > gratuitous packet header rewriting by hostile agents as compared to packet > rewriting by agents who believe that they are doing this in a friendly and > helpful fashion. This becomes a challenging problem,of course. If its hostile or friendly behavior is in the eye of the beholder - but in fact it may not even be only one side or the other for the same person. If I sit under a NAT and it prevents my application from running, I'm hostile to that behavior. But same NAT box may well be protecting my home network from intrusion and allowing me to have multiple computers connected through the same dsl/cable/wireless connection, so I'd view it as a friendly. Since most people don't notice its hostile behavior (due to kind of applications they run) and all notice its friendly behavior it will overall be seen as a friend and "right" solution. So is there better way to do it and without NAT? Of course there is - have real firewall and have block of ips - but NAT is winning as a business case because it can do those several friendly things well for almost everyone and without dependence on network provider and those few users who are inconvenienced and their application are viewed as minor percentage and not a problem in the overall business case. So business case won but IETF end-end tcp/ip architecture broken ... > I don't think any single approach today is the one true right approach at > this point, but unless we explore this space with some diligence, Diligence is the right word. But is it really the size of the routing table that we're being most concerned (considering #of routes in ipv6 will most definitely be smaller then with ipv4 because of less fragmentation - generally one ip block per ASN) or business case of users who do not want to be dependent on IP provider and RIR to be able to multihome? And should due diligence be applied so that proposed solution both makes sense to do for those who will use it (i.e. small businesses in case of shim6) an does not break applications when that is done? -- William Leibzon Elan Networks william at elan.net From president at ukraine.su Wed Nov 30 11:33:52 2005 From: president at ukraine.su (Max Tulyev) Date: Wed, 30 Nov 2005 13:33:52 +0300 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <438B494C.4030102@oslo.net> References: <002f01c5f43a$12631110$44eea2d5@l> <438B494C.4030102@oslo.net> Message-ID: <200511301333.52818.president@ukraine.su> Hi! > > 1. No PI. _Only_ network operators get a prefix. > > I am an operator of a network - do I get a prefix ? (we have lots of > computers and need lots of IP addresses: currently the 5 PCs, 2 > printers, a phone and some PDA and a server online) > > I guess you need to define the criteria in some other way. Perhaps > beeing registered with the national regulator I'm looking at all of that and begin to think that all this discussion about PI vs PA (and only [large] operators can get a prefix) is just for implementing some unfair rules in ISP market. Wise customers wants to have PI because of to be multihoming and have stable and really _provider_independent_ (i.e. not depending on upstream's faults) connection. Small operators wants to have PI because of LIR is often too expensive for them. Large operators do NOT want PI because of they can hold a client with their address space ("if you are going to change ISP - you will have a large trouble with renumbering your network and changing domains" or even "if you do not do ... - we will immediately shut down your connection"). Large operators (can pay for LIR) do NOT want PI because of it makes the extra money barrier to be an operator (LIR cost). See more on. Imagine there is no PI. If somebody really-really-really needs to be multihoming - he will be a LIR and do the LIR initial request (/20 PA for IPv4 instead of /24 PI he really need for years). So in this case we do not conserve one row of route table, but slightly loss in conserving space (/20 instead of /24). Even more. Who is making the most noise about no PI? As I can see, large operators. People who have enough powerful routers to not to think about extra routes there. P.S. And please do not compare IP connectivity with global dynamic routing (it is a really BIG achievement of the Internet!) with PSTN and global static routing where switching routes to certain number plan can take several monthes. Of course, in PSTN we can't ever think about hot backup and upstream reservation (multihoming). -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From jkuijer at dds.nl Wed Nov 30 12:41:36 2005 From: jkuijer at dds.nl (jkuijer at dds.nl) Date: Wed, 30 Nov 2005 12:41:36 +0100 Subject: [ipv6-wg] unsubscribe jkuijer@dds.nl In-Reply-To: <20051130103601.13609.26348.Mailman@postboy.ripe.net> References: <20051130103601.13609.26348.Mailman@postboy.ripe.net> Message-ID: <1133350896.438d8ff0b792b@webmail.dds.nl> Citeren ipv6-wg-request at ripe.net: > Send ipv6-wg mailing list submissions to > ipv6-wg at ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.ripe.net/mailman/listinfo/ipv6-wg > or, via email, send a message with subject or body 'help' to > ipv6-wg-request at ripe.net > > You can reach the person managing the list at > ipv6-wg-admin at ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ipv6-wg digest..." > > > Today's Topics: > > 1. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Per Heldal) > 2. unsubscibe jkuijer at dds.nl (jkuijer at dds.nl) > 3. Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (Florian > Weimer) > 4. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Randy Bush) > 5. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Geoff Huston) > 6. Re: Re: [address-policy-wg] Re: Andre's guide to fix > IPv6 (Geoff Huston) > 7. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Geoff Huston) > 8. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (william(at)elan.net) > 9. Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (Max Tulyev) > > --__--__-- > > Message: 1 > From: "Per Heldal" > To: "Salman Asadullah" > Cc: "ipv6-wg at ripe.net" , "address-policy-wg at ripe.net" > > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > Date: Tue, 29 Nov 2005 12:21:52 +0100 > > > On Mon, 28 Nov 2005 15:55:16 -0800, "Salman Asadullah" > said: > > You seem to be far away from the ground realities. > > > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > > issues for a good reason. > > > > Regardless of the efforts, from a provider POV it's only "work in > progress". Make sure your preferred technology is implemented across all > platforms and accompanied by solutions for traffic-engineering, > filtering and other issues. Then you may have a viable alternative to > present to the operators community. Don't expect anybody to adopt new > technologies unless they represent some progress. > > I'm not saying that shim6 is DOA. It *may become* an alternative, but it > *is not*. Unless you can convince content-providers to trust their > upstream to provide redundancy and thus eliminate the need for end-site > multihoming you have the following realistic short-term alternatives: > > * Keep ipv6 experimental and postpone operational > deployment until there's a good technical solution > to the multi-homing problem or a way to eliminate > the DFZ and the related concerns about routing- > table size. > > * Adopt a PI policy for v6 similar to the current > v4-policy, and hope that moore can keep up with > the growth of the routing-table. > > From there policies will have to evolve, along with the development of > new technology. Evolution is a perpetual process, not a project with a > finite deadline. > > PS! am I missing something, or is IETF/IAB trying to copy the ITU in the > way they produce paper-standards? Is that really such a good idea? > > //per > -- > Per Heldal > heldal at eml.cc > > > --__--__-- > > Message: 2 > Date: Tue, 29 Nov 2005 12:25:08 +0100 > From: jkuijer at dds.nl > To: ipv6-wg at ripe.net > Subject: [ipv6-wg] unsubscibe jkuijer at dds.nl > > Citeren ipv6-wg-request at ripe.net: > > > Send ipv6-wg mailing list submissions to > > ipv6-wg at ripe.net > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://www.ripe.net/mailman/listinfo/ipv6-wg > > or, via email, send a message with subject or body 'help' to > > ipv6-wg-request at ripe.net > > > > You can reach the person managing the list at > > ipv6-wg-admin at ripe.net > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of ipv6-wg digest..." > > > > > > Today's Topics: > > > > 1. Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (McTim) > > 2. Re: [address-policy-wg] Re: Andre's guide to fix IPv6 (Geoff Huston) > > 3. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Randy Bush) > > 4. Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI (Andre Oppermann) > > > > -- __--__-- > > > > Message: 1 > > Date: Tue, 29 Nov 2005 07:19:49 +0300 > > From: McTim > > To: =?ISO-8859-1?Q?J=F8rgen_Hovland?= > > Subject: Re: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix > IPv6 > > Cc: ipv6-wg at ripe.net > > > > hiya, > > > > (removed address-policy-wg from the cc:) > > > > On 11/28/05, J=F8rgen Hovland wrote: > > > > > > -----Original Message----- > > > From: McTim [mailto:dogwallah at gmail.com] > > > > > > > >#2 sounds like PI to me. What have I missed? > > > > > > Hello McTim, > > > You are correct. That's why I wrote PI in the email:-). > > > > I guess I misread the below wrong then ;-) > > > > J=F8rgen Hovland wrote: > > > > >> - > > >> 1. No PI. _Only_ network operators get a prefix. > > > > > It is an attempt to suggest an alternative idea to the PI discussion. > > > Don't get me wrong. I am for PI. This idea is perhaps a bit more > > > hierarchical instead of the standard flat one. Just making sure we have > > > thought of everything before we reach consensus > > > > I am sure thiat consensus will take a very long tiime on this one! We > > will probably have to talk about grotopological v6 adressing (as they > > are doing on the ARIN ppml) and a host of other issues. I reckon we > > ought to wait for shim6 to do their work as well. > > > > > because this PI discussion > > > is very important to ipv6. > > > > v. true. > > > > -- > > Cheers, > > > > McTim > > $ whois -h whois.afrinic.net mctim > > > > > > -- __--__-- > > > > Message: 2 > > Date: Tue, 29 Nov 2005 10:15:27 +1100 > > To: =?iso-8859-1?Q?J=F8rgen?= Hovland , > > , > > From: Geoff Huston > > Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 > > > > At 03:37 AM 29/11/2005, J=F8rgen Hovland wrote: > > >----- Original Message ----- From: "Florian Weimer" > > >Sent: Saturday, November 26, 2005 4:00 PM > > > > > > > > >>* Jeroen Massar: > > >> > > >>>>1. Make /32 the only routable entity so we can use perfect match in > > >>>> the DFZ instead of longest-prefix match. > > >>> > > >>>What about the organizations that have say a /19, want them to inject > > >>>all their more specific /32's? > > >> > > >>You can inject a /19 as 8192 /32s. Shouldn't make a difference if the > > >>/19 is really used. > > >> > > >>At this stage, it's probably not too wise to embed the /32--/48--/64 > > >>in silicon, but vendors will undoubtedly do this if they can save a > > >>few bucks and current policies remain as inflexible as they are. > > > > > >Hi, > > >Perfect match is faster but far from better. What I think perhaps would > be= > > =20 > > >interesting to see in the future with regards to IPv6 and PI is the= > > following: > > > > > >1. No PI. _Only_ network operators get a prefix. > > >2. Customers of network operators can at any time change provider and > take= > > =20 > > >their assigned prefix with them. The new provider will announce it as a=20 > > >more specific overriding the aggregate. If the customer decides to get=20 > > >multiple providers, then the network operator with the /32 could also=20 > > >announce a more specific. > > > > > >In the country I live in I can change telecom provider and take my > phone=20 > > >number with me to the new provider. Why shouldn't I be able to do that=20 > > >with internet providers? > > >Yes, it will somehow create millions/billions of prefixes (atleasat > with=20 > > >todays routing technology/protocols). Network operators should be able to= > > =20 > > >handle that hence rule #1. > > > > > > Interesting - it will work for a while, and then you will get to the limit= > > =20 > > of deployed capability of routing. > > > > Then what? > > > > Geoff > > > > > > > > > > > > -- __--__-- > > > > Message: 3 > > From: Randy Bush > > Date: Mon, 28 Nov 2005 21:49:17 -1000 > > To: Salman Asadullah > > Cc: Roger Jorgensen , > > Oliver Bartels , > > "ipv6-wg at ripe.net" , > > "address-policy-wg at ripe.net" , > > roger at jorgensen.no > > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > > > > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > > > issues for a good reason. > > > > i gather that the message that leslie daigle was given at the > > last nanog was not well-transmitted to the ietf. no big > > surprise. > > > > you may want to look at http://nanog.org/mtg-0510/real/ipv6-bof.ram > > > > randy > > > > > > -- __--__-- > > > > Message: 4 > > Date: Tue, 29 Nov 2005 10:13:39 +0100 > > From: Andre Oppermann > > To: Salman Asadullah > > CC: Roger Jorgensen , > > Oliver Bartels , > > "ipv6-wg at ripe.net" , > > "address-policy-wg at ripe.net" , > > roger at jorgensen.no > > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > > > > Salman Asadullah wrote: > > > > > > You seem to be far away from the ground realities. > > > > > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > > > issues for a good reason. > > > > Neither Multi6 nor SHIM6 are even in an draft RFC state yet and to be > > workable they'd have to be implemented on every end-host out there. > > That is every operating system in sufficient existence. That puts IPv6 > > even further in the already distant future considering common OS upgrade > > and replacement cycles. > > > > Second this doesn't solve the renumbering problem. Renumbering is not > > just giving hosts new IP addresses but alost managing DNS and Firewalls. > > No even remotely workable and scaleable solution has been presented yet. > > > > So nice try but no cookie. > > > > -- > > Andre > > > > > > > Regards, > > > Salman > > > > > > At 10:55 AM 11/25/2005 +0100, Roger Jorgensen wrote: > > > > > > > On Thu, 24 Nov 2005, Oliver Bartels wrote: > > > > > On Mon, 21 Nov 2005 17:10:10 +0100 (CET), Roger Jorgensen wrote: > > > > > > > > > If IPv4 offers PI = provider _independence_ and multihoming > > > > > and IPv6 doesn't, then IPv4 is obviously the better solution for > > > > > those who requires this functionallity. > > > > > > > > > > Thus they won't use IPv6. > > > > > > > > > > Please keep in mind: The _customer_ votes, not you, not me. > > > > > > > > > > And as the majority of the large and a significant portion of medium > > > > > size businesses are obviously not willing to accept an IP protocol > not > > > > > providing this functionallity, IPv6 will remain at it's current > status: > > > > > > > > > > A technical playground for technically interested people. > > > > > > > > a very true point in one way but that is again as I see it, we're still > > > > thinking IPv4 when talking IPv6. > > > > > > > > Why do they need multihoming and PI? They don't trust the ISP and > vendors > > > > to deliver them uptime and freedom... isn't this a problem the ISP and > > > > vendors should try to solve? Of course, the idea of easy renumbering > was > > > > suppose to solve this but again, we're thinking IPv4 so it's not easy > to > > > > understand. > > > > > > > > Again, we don't need PI space and multihoming, what we need are a way > to > > > > give the users and GOOD connectivity (uptime, speed etc) and make it > easy > > > > for them to switch providers as they see fit. > > > > > > > > > > > > > > > > > > > > > > > > > > Hmm, please let me translate: > > > > > "Even if the car doesn't drive and the engine doesn't deliver a > single > > > > > horse power at the wheels, drop the thought about driving, > > > > > start to think about other way to use the possibility this great car > > > > > gives us." > > > > > > > > > > Sound like newspeak: > > > > > If we _think_ we can't solve the problem, drop discussing the > problem. > > > > > > > > for several years this discussion have been going on, still no real > > > > solution. IPv6 give us the freedom todo ALOT of things, USE those > > > > possibilities, if we have to change how IP are done, some TCP headers > > etc, > > > > then do it... propose a good idea and prove it. That could give us > > > > multihoming. Actually there is a master thesis about howto create > > > > connectivity for TCP session even if one of the links went down, the > > > > session just used another IP (1)... the user don't notice anything > > > > either and it have zero problem working with standard tcp-stacks since > it > > > > use the extended header of IPv6. > > > > > > > > That's just ONE of many possible ways... > > > > > > > > > > > > > > > > (1) it's a master thesis writting by a student related to University of > > > > Troms?? as part of the Pasta project, www.pasta.cs.uit.no > > > > > > > > -- > > > > > > > > ------------------------------ > > > > Roger Jorgensen | > > > > rogerj at stud.cs.uit.no | - IPv6 is The Key! > > > > http://www.jorgensen.no | roger at jorgensen.no > > > > ------------------------------------------------------- > > > > > > > > > > End of ipv6-wg Digest > > > > > > > --__--__-- > > Message: 3 > From: Florian Weimer > To: Geoff Huston > Cc: =?iso-8859-1?Q?J=F8rgen?= Hovland , > , > Subject: Re: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 > Date: Tue, 29 Nov 2005 15:26:53 +0100 > > * Geoff Huston: > > > Interesting - it will work for a while, and then you will get to the limit > > of deployed capability of routing. > > > > Then what? > > You buy new routers. > > What's next? Do you plan to lobby Hollywood to reduce the number of > movies create per year, so that your customers have fewer of them to > download, and the capacity of your pipes is not exceeded? > > > --__--__-- > > Message: 4 > From: Randy Bush > Date: Tue, 29 Nov 2005 06:17:54 -1000 > To: Per Heldal > Cc: Salman Asadullah , > ipv6-wg at ripe.net, > address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > > >> Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > >> issues for a good reason. > > Regardless of the efforts, from a provider POV it's only "work in > > progress". > > one of the key points from the nanog session was that shim6 is the > *wrong* work in progress. what is needed is _site_ multi-homing, > not host multi-homing. > > randy > > > --__--__-- > > Message: 5 > Date: Wed, 30 Nov 2005 05:34:05 +1100 > To: Randy Bush , Per Heldal > From: Geoff Huston > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > Cc: Salman Asadullah , ipv6-wg at ripe.net, > address-policy-wg at ripe.net > > At 03:17 AM 30/11/2005, Randy Bush wrote: > > >> Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > > >> issues for a good reason. > > > Regardless of the efforts, from a provider POV it's only "work in > > > progress". > > > >one of the key points from the nanog session was that shim6 is the > >*wrong* work in progress. what is needed is _site_ multi-homing, > >not host multi-homing. > > "wrong"? "right"? > > Usual response - if you believe that there is a better way of doing this > work through the issues here, then write up an approach, gather support, > get peer review etc etc. > > As I said at NANOG, part of the problem with distributed models where there > is action at a distance is to understand and clearly identify instances of > gratuitous packet header rewriting by hostile agents as compared to packet > rewriting by agents who believe that they are doing this in a friendly and > helpful fashion. This becomes a challenging problem,of course. > > I don't think any single approach today is the one true right approach at > this point, but unless we explore this space with some diligence, allow for > experimentation and keep an open mind on this work then you are going to > get intractably wedged between the desire for greater flexibility in the > use of addresses as a form of semi-persistent endpoint identifiers and the > desire for reduced flexibility in the use of addresses as forwarding tokens > in order to keep the routing space confined to readily computable dimensions. > > But of course _all_ this will be solved in MPLS - right? :-) > > Geoff > > > > > > --__--__-- > > Message: 6 > Date: Wed, 30 Nov 2005 05:36:11 +1100 > To: Florian Weimer > From: Geoff Huston > Subject: Re: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix > IPv6 > Cc: =?iso-8859-1?Q?J=F8rgen?= Hovland , > , > > At 01:26 AM 30/11/2005, Florian Weimer wrote: > >* Geoff Huston: > > > > > Interesting - it will work for a while, and then you will get to the > limit > > > of deployed capability of routing. > > > > > > Then what? > > > >You buy new routers. > > > So what you are saying is that _I_ want address portability and _you_ have > to buy new routers. > > > Well that sure works for me! How's the chequebook feeling on your side? > > (I'm not convinced that you've selected the best of business models, as > there does appear to be a significant inconsistency going on in your model > in that cost and benefit are not related all that well.) > > Geoff > > > > --__--__-- > > Message: 7 > Date: Wed, 30 Nov 2005 06:01:56 +1100 > To: Andre Oppermann , Salman Asadullah > > From: Geoff Huston > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > Cc: Roger Jorgensen , Oliver Bartels > , > "ipv6-wg at ripe.net" , > "address-policy-wg at ripe.net" , > roger at jorgensen.no > > At 08:13 PM 29/11/2005, Andre Oppermann wrote: > >Salman Asadullah wrote: > > > > > > You seem to be far away from the ground realities. > > > > > > Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these real > > > issues for a good reason. > > > >Neither Multi6 nor SHIM6 are even in an draft RFC state yet > > Multi6 produced 5 WG drafts, all of which have been published as RFCs You > can (and probably should) read through RFCs 3582, 4116, 4177, 4219, and 4218 > > SHIM6 is working on the following drafts - again I would recommend that you > read though all of them:... > draft-ietf-shim6-app-refer, draft-ietf-shim6-applicability, > draft-ietf-shim6-arch, draft-ietf-shim6-failure-detection, > draft-ietf-shim6-hba, draft-ietf-shim6-proto, > and draft-ietf-shim6-reach-detect. > > > > and to be > >workable they'd have to be implemented on every end-host out there. > >That is every operating system in sufficient existence. That puts IPv6 > >even further in the already distant future considering common OS upgrade > >and replacement cycles. > > yep - any form of locator / identity split is such a basic shift in the > architectural model used by IP that changes to the stack are required. This > is the case in mobility, nomadism, ad-hoc networking and this form of > multi-homing. If you want agile locators and any form of persistence in > endpoint identifiers then you are not going to get that without changes to > the stack. Now if you are arguing that the deployed base of IPv6 is so > large that further changes are impossible in this particular technology due > to the inertia of the deployed IPv6 base, then that's certainly an > interesting perspective, and not one I've heard all that often so far. If > you are saying that this will take time to develop and deploy, then you are > probably right, and a model that can use incremental deployment using a > conventional initial context followed by a capability exchange to explore > if there is mutual support for this form of communication capability, then > you may well be onto something interesting. Although I'd hasten to add that > this is the approach being taken within the SHIM6 architecture. > > >Second this doesn't solve the renumbering problem. Renumbering is not > >just giving hosts new IP addresses but alost managing DNS and Firewalls. > >No even remotely workable and scaleable solution has been presented yet. > > I'm not sure I agree with you about the DNS and renumbering - its not a > clearly defined space, and the implications relating to the DNS are not > clearly understood in communication models where feasible locator sets are > dynamically exchanged rather than always loaded into third party rendezvous > points, as in the DNS model. > > > >So nice try but no cookie. > > Thank you, > > Geoff > > > > > > --__--__-- > > Message: 8 > Date: Wed, 30 Nov 2005 01:53:49 -0800 (PST) > From: "william(at)elan.net" > To: Geoff Huston > cc: Randy Bush , Per Heldal , > Salman Asadullah , ipv6-wg at ripe.net, > address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] Re: [ipv6-wg] IPv6 PI > > > On Wed, 30 Nov 2005, Geoff Huston wrote: > > > At 03:17 AM 30/11/2005, Randy Bush wrote: > >> >> Lots of efforts (Multi6, SHIM6, etc.) are being made to solve these > >> real > >> >> issues for a good reason. > >> > Regardless of the efforts, from a provider POV it's only "work in > >> > progress". > >> > >> one of the key points from the nanog session was that shim6 is the > >> *wrong* work in progress. what is needed is _site_ multi-homing, > >> not host multi-homing. > > Yes, well if it goes forward, it may well end up being used for setting > up site-multihoming: > > http://www.ietf.org/mail-archive/web/architecture- discuss/current/msg00095.html > and will be seen as friendly and right solution (on what "friendly" and > "right" can mean seen below). > > > "wrong"? "right"? > > > > Usual response - if you believe that there is a better way of doing this > > work through the issues here, then write up an approach, gather support, > get > > peer review etc etc. > > > > As I said at NANOG, part of the problem with distributed models where there > > is action at a distance is to understand and clearly identify instances of > > gratuitous packet header rewriting by hostile agents as compared to packet > > rewriting by agents who believe that they are doing this in a friendly and > > helpful fashion. This becomes a challenging problem,of course. > > If its hostile or friendly behavior is in the eye of the beholder - but > in fact it may not even be only one side or the other for the same person. > > If I sit under a NAT and it prevents my application from running, I'm > hostile to that behavior. But same NAT box may well be protecting my > home network from intrusion and allowing me to have multiple computers > connected through the same dsl/cable/wireless connection, so I'd view > it as a friendly. Since most people don't notice its hostile behavior > (due to kind of applications they run) and all notice its friendly > behavior it will overall be seen as a friend and "right" solution. > > So is there better way to do it and without NAT? Of course there is - > have real firewall and have block of ips - but NAT is winning as a > business case because it can do those several friendly things well for > almost everyone and without dependence on network provider and those > few users who are inconvenienced and their application are viewed as > minor percentage and not a problem in the overall business case. > So business case won but IETF end-end tcp/ip architecture broken ... > > > I don't think any single approach today is the one true right approach at > > this point, but unless we explore this space with some diligence, > > Diligence is the right word. But is it really the size of the routing > table that we're being most concerned (considering #of routes in ipv6 > will most definitely be smaller then with ipv4 because of less > fragmentation - generally one ip block per ASN) or business case of > users who do not want to be dependent on IP provider and RIR to be > able to multihome? > > And should due diligence be applied so that proposed solution both > makes sense to do for those who will use it (i.e. small businesses > in case of shim6) an does not break applications when that is done? > > -- > William Leibzon > Elan Networks > william at elan.net > > > --__--__-- > > Message: 9 > From: Max Tulyev > To: ipv6-wg at ripe.net > Subject: Re: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 > Date: Wed, 30 Nov 2005 13:33:52 +0300 > > Hi! > > > > 1. No PI. _Only_ network operators get a prefix. > > > > I am an operator of a network - do I get a prefix ? (we have lots of > > computers and need lots of IP addresses: currently the 5 PCs, 2 > > printers, a phone and some PDA and a server online) > > > > I guess you need to define the criteria in some other way. Perhaps > > beeing registered with the national regulator > > I'm looking at all of that and begin to think that all this discussion about > PI vs PA (and only [large] operators can get a prefix) is just for > implementing some unfair rules in ISP market. > > Wise customers wants to have PI because of to be multihoming and have stable > and really _provider_independent_ (i.e. not depending on upstream's faults) > connection. > Small operators wants to have PI because of LIR is often too expensive for > them. > > Large operators do NOT want PI because of they can hold a client with their > address space ("if you are going to change ISP - you will have a large > trouble with renumbering your network and changing domains" or even "if you > do not do ... - we will immediately shut down your connection"). Large > operators (can pay for LIR) do NOT want PI because of it makes the extra > money barrier to be an operator (LIR cost). > > See more on. Imagine there is no PI. If somebody really-really-really needs > to > be multihoming - he will be a LIR and do the LIR initial request (/20 PA for > IPv4 instead of /24 PI he really need for years). So in this case we do not > conserve one row of route table, but slightly loss in conserving space (/20 > instead of /24). > > Even more. Who is making the most noise about no PI? As I can see, large > operators. People who have enough powerful routers to not to think about > extra routes there. > > P.S. And please do not compare IP connectivity with global dynamic routing > (it > is a really BIG achievement of the Internet!) with PSTN and global static > routing where switching routes to certain number plan can take several > monthes. Of course, in PSTN we can't ever think about hot backup and upstream > reservation (multihoming). > > -- > WBR, > Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) > > > > > End of ipv6-wg Digest > From dr at cluenet.de Wed Nov 30 17:16:47 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 30 Nov 2005 17:16:47 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> Message-ID: <20051130161647.GA12947@srv01.cluenet.de> On Wed, Nov 30, 2005 at 05:36:11AM +1100, Geoff Huston wrote: > >> Interesting - it will work for a while, and then you will get to the > >> limit of deployed capability of routing. > >> > >> Then what? > > > >You buy new routers. > > So what you are saying is that _I_ want address portability and _you_ have > to buy new routers. No, what he's saying is "_you_ want _my_ business, so _you_ have to deliver what _I_ want. If you cannot deliver, there is no business for _you_". ISPs do exist for customers, not customers do exist to feed ISPs in the most convenient way for the ISPs. Some folks seem to forget that, looking at all the discussion trying to ignore the demand for real multihoming (and that includes TE and network-wide routing policy implementation, neither being delivered by things like shim6). HOW the requirements are being delivered is another topic. multi6 has resulted in the decision to ignore many critical requirements. We're just asking for something that delivers on the targets. Wasting time with half-solutions is not productive. Halting any development because the magic bullet wasn't found yet ain't either. IMHO PI can buy us the time to find Something New[tm] which delivers without the associated possible problems. Until then, there are two options: halt IPv6 completely, now, or implement as sensible PI policy (1 PI prefix per ASN, no questions asked) to buy us the time. I don't know which way is the better one. But this whole "go to IPv6 but no cookies^WPI for you" ain't fly, that for sure (IMHO, YMMV). Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From dr at cluenet.de Wed Nov 30 17:21:29 2005 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 30 Nov 2005 17:21:29 +0100 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051130161647.GA12947@srv01.cluenet.de> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> Message-ID: <20051130162129.GB12947@srv01.cluenet.de> On Wed, Nov 30, 2005 at 05:16:47PM +0100, Daniel Roesen wrote: > On Wed, Nov 30, 2005 at 05:36:11AM +1100, Geoff Huston wrote: > > >> Interesting - it will work for a while, and then you will get to the > > >> limit of deployed capability of routing. > > >> > > >> Then what? > > > > > >You buy new routers. > > > > So what you are saying is that _I_ want address portability and _you_ have > > to buy new routers. > > No, what he's saying is "_you_ want _my_ business, so _you_ have to > deliver what _I_ want. If you cannot deliver, there is no business for > _you_". > > ISPs do exist for customers, not customers do exist to feed ISPs in the > most convenient way for the ISPs. Some folks seem to forget that, > looking at all the discussion trying to ignore the demand for real > multihoming (and that includes TE and network-wide routing policy > implementation, neither being delivered by things like shim6). BTW... in Germany, the phone operators were forced to implement phone number portability by law. The regulator didn't care about all the whining from the telcos about that being impossible, uneconomic, the world will explode etc. If they manage to get that imposed on the traditional telcos, I wonder how much easier it will be to do that on the ISPs. Regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From jeroen at unfix.org Wed Nov 30 19:13:42 2005 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 30 Nov 2005 19:13:42 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051130162129.GB12947@srv01.cluenet.de> References: <87sltm3p3n.fsf@mid.deneb.enyo.de> <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> Message-ID: <438DEBD6.1000207@unfix.org> Daniel Roesen wrote: > On Wed, Nov 30, 2005 at 05:16:47PM +0100, Daniel Roesen wrote: >> On Wed, Nov 30, 2005 at 05:36:11AM +1100, Geoff Huston wrote: >>>>> Interesting - it will work for a while, and then you will get to the >>>>> limit of deployed capability of routing. >>>>> >>>>> Then what? >>>> You buy new routers. >>> So what you are saying is that _I_ want address portability and _you_ have >>> to buy new routers. >> No, what he's saying is "_you_ want _my_ business, so _you_ have to >> deliver what _I_ want. If you cannot deliver, there is no business for >> _you_". The 'you' here is a remote site where you have no (direct) business relationship with. For that remote site, especially with those words, there is no reason at all to any business with you. They are not going to invest any cash to upgrade their network for you (the I in the sentence). >> ISPs do exist for customers, not customers do exist to feed ISPs in the >> most convenient way for the ISPs. Some folks seem to forget that, >> looking at all the discussion trying to ignore the demand for real >> multihoming (and that includes TE and network-wide routing policy >> implementation, neither being delivered by things like shim6). But is it PI or a slot in the routing tables you want? The slot can be bought by giving a lot of cash to ISP's so that they accept your prefix. > BTW... in Germany, the phone operators were forced to implement phone > number portability by law. The regulator didn't care about all the > whining from the telcos about that being impossible, uneconomic, the > world will explode etc. If they manage to get that imposed on the > traditional telcos, I wonder how much easier it will be to do that on > the ISPs. Why do you even go near the analogy of a Telco? I, nor any other endsite (who isn't a telco) can't do TE nor network-wide routing policies nor any of the other things that people like so much about in the current IPv4 with telephone systems. Telephone is much more like DNS than IP. If you want telco-style "IP portability" then simply (ahem) change (renumber) the IP's on your servers/firewalls etc and update DNS. As that is how a number is 'ported'. Also telco style means that all incoming traffic gets routed over your old ISP. Andre Opperman had a large explanation on this subject on NANOG a couple of weeks ago. See the thread around: http://www.merit.edu/mail.archives/nanog/2005-10/msg00782.html What you seem to want is "IPv6 PI", exactly the same thing as "IPv4 PI". The worry here: routing table size. As not only you will want this, but it might be that suddenly a million or so others also will want this in the future, 20 years and more maybe even 50. We could make a policy to give out "IPv6 PI" the IPv4 way but then we automatically end up with IPv6 swamp when ISP's start restricting the prefixes they accept because they don't want to buy yet another new routing setup. Also remember that to participate in it, you have to see everything, thus all the small fish (the ones needing "IPv6 PI") will require that big fancy new router, got cash for that? The only solution I see here is somewhat of the lines of: +-------------+ | l3 src | | l3 dst | +-------------+ | shim src | | shim dst | +-------------+ Where the 'shim' addresses are "PI" prefixes given out from a special block (eg a /16) where /40's and /48's come out of for the simple purpose that one doesn't have to renumber, just add links and enable your edge boxes to move the original l3 header to shim, and then adding the l3 addresses from the ISP. When the other side receives it, verify&strip the l3's (which are only used between transit/ISP's) and tada done. It's something you can call double NAT or tunneling and this is as far as I understood an extreme simplification of what shim6 is going to do, first per host, but very easily also per site. Indeed that doesn't allow those nice routing tricks to be defined, but if you want to be able to do that, then don't ask for "provider independent address space" but just say that you want a prefix that can be stuck, and then work, in global bgp/dfz*. Greets, Jeroen * = before the obvious person asks, the routing table that is seen by most ISP's on the "internet". -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 238 bytes Desc: OpenPGP digital signature URL: From bmanning at vacation.karoshi.com Wed Nov 30 18:12:58 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 30 Nov 2005 17:12:58 +0000 Subject: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fix IPv6 In-Reply-To: <20051130162129.GB12947@srv01.cluenet.de> References: <4386E053.73B661B3@networx.ch> <43886509.6060600@unfix.org> <87acfr1mjl.fsf@mid.deneb.enyo.de> <002f01c5f43a$12631110$44eea2d5@l> <6.2.0.14.2.20051129101355.02919160@kahuna.telstra.net> <87fypfpm1e.fsf@mid.deneb.enyo.de> <6.2.0.14.2.20051130053430.02d015d0@kahuna.telstra.net> <20051130161647.GA12947@srv01.cluenet.de> <20051130162129.GB12947@srv01.cluenet.de> Message-ID: <20051130171258.GB6570@vacation.karoshi.com.> > > ISPs do exist for customers, not customers do exist to feed ISPs in the > > most convenient way for the ISPs. Some folks seem to forget that, > > looking at all the discussion trying to ignore the demand for real > > multihoming (and that includes TE and network-wide routing policy > > implementation, neither being delivered by things like shim6). > > BTW... in Germany, the phone operators were forced to implement phone > number portability by law. The regulator didn't care about all the > whining from the telcos about that being impossible, uneconomic, the > world will explode etc. If they manage to get that imposed on the > traditional telcos, I wonder how much easier it will be to do that on > the ISPs. > > > Regards, > Daniel > > -- > CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 why does this remind me of the law passed (in several different jurisdictions, if the urban myths are to be believed) that mandated PI == 3.2. ... legal talent can not change some laws. --bill