- ipv6-wg - mailman.ripe.net

RE: address-policy-wg (ipv6-wg digest, Vol 1 #271 - 11 msgs)
by peter.sherbin＠bell.ca 25 Nov '05

25 Nov '05

>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(a)ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of ipv6- >wg-request(a)ripe.net >Sent: November/25/ 2005 06:00 >To: ipv6-wg(a)ripe.net >Subject: ipv6-wg digest, Vol 1 #271 - 11 msgs > >Send ipv6-wg mailing list submissions to > ipv6-wg(a)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(a)ripe.net > >You can reach the person managing the list at > ipv6-wg-admin(a)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 <fw(a)deneb.enyo.de> >To: Roger Jorgensen <rogerj(a)jorgensen.no> >Cc: Lea Roberts <lea.roberts(a)stanford.edu>, address-policy-wg(a)ripe.net, ipv6- >wg(a)ripe.net, roger(a)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" <oliver(a)bartels.de> >To: "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net>, > "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net>, > "Roger Jorgensen" <rogerj(a)jorgensen.no> >Date: Thu, 24 Nov 2005 19:22:24 +0100 >Reply-To: "Oliver Bartels" <oliver(a)bartels.de> >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(a)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 <rogerj(a)jorgensen.no> >To: ipv6-wg(a)ripe.net, address-policy-wg(a)ripe.net >cc: roger(a)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(a)stud.cs.uit.no | - IPv6 is The Key! >http://www.jorgensen.no | roger(a)jorgensen.no >------------------------------------------------------- > > >--__--__-- > >Message: 4 >Date: Fri, 25 Nov 2005 10:36:25 +0100 (CET) >From: Roger Jorgensen <rogerj(a)jorgensen.no> >To: Florian Weimer <fw(a)deneb.enyo.de> >cc: address-policy-wg(a)ripe.net, ipv6-wg(a)ripe.net, roger(a)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(a)stud.cs.uit.no | - IPv6 is The Key! >http://www.jorgensen.no | roger(a)jorgensen.no >------------------------------------------------------- > > >--__--__-- > >Message: 5 >Date: Fri, 25 Nov 2005 10:55:54 +0100 (CET) >From: Roger Jorgensen <rogerj(a)jorgensen.no> >To: Oliver Bartels <oliver(a)bartels.de> >cc: "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net>, > "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net>, > roger(a)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: ><snip> >> 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. > > > ><snip> >> >> 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(a)stud.cs.uit.no | - IPv6 is The Key! >http://www.jorgensen.no | roger(a)jorgensen.no >------------------------------------------------------- > > >--__--__-- > >Message: 6 >Date: Fri, 25 Nov 2005 10:58:43 +0100 >From: Andre Oppermann <oppermann(a)networx.ch> >To: Roger Jorgensen <rogerj(a)jorgensen.no> >CC: Florian Weimer <fw(a)deneb.enyo.de>, address-policy-wg(a)ripe.net, > ipv6-wg(a)ripe.net, roger(a)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 <oppermann(a)networx.ch> >To: Roger Jorgensen <rogerj(a)jorgensen.no> >CC: Oliver Bartels <oliver(a)bartels.de>, > "ipv6-wg(a)ripe.net" <ipv6-wg(a)ripe.net>, > "address-policy-wg(a)ripe.net" <address-policy-wg(a)ripe.net>, > roger(a)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: >> <snip> >> > 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. > >> <snip> >> > >> > 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 <gert(a)space.net> >To: Roger Jorgensen <rogerj(a)jorgensen.no> >Cc: ipv6-wg(a)ripe.net, address-policy-wg(a)ripe.net, roger(a)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(a)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 <rogerj(a)jorgensen.no> >To: Gert Doering <gert(a)space.net> >cc: ipv6-wg(a)ripe.net, address-policy-wg(a)ripe.net, roger(a)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(a)stud.cs.uit.no | - IPv6 is The Key! >http://www.jorgensen.no | roger(a)jorgensen.no >------------------------------------------------------- > > >--__--__-- > >Message: 10 >Date: Fri, 25 Nov 2005 11:38:44 +0100 >From: Gert Doering <gert(a)space.net> >To: Roger Jorgensen <rogerj(a)jorgensen.no> >Cc: Gert Doering <gert(a)space.net>, ipv6-wg(a)ripe.net, > address-policy-wg(a)ripe.net, roger(a)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(a)Space.Net >Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 >D- 80807 Muenchen Fax : +49-89-32356-234 > > > > >End of ipv6-wg Digest

2 1

RE: [address-policy-wg] Re: [ipv6-wg] IPv6 micro allocation or so mething else?
by Koepp, Karsten 23 Nov '05

23 Nov '05

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@nic.fr] > Sent: Thursday, November 17, 2005 11:51 AM > To: Florian Weimer > Cc: address-policy-wg(a)ripe.net; ipv6-wg(a)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. > >

6 5

Re: [ipv6-wg] Re: 200 customer requirements for IPv6
by Thomas Narten 18 Nov '05

18 Nov '05

Daniel Roesen <dr(a)cluenet.de> 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

3 2

Draft Minutes (v1) of IPv6 WG session RIPE51
by David Kessens 22 Oct '05

22 Oct '05

Please see enclosed the first version of the minutes of our session at RIPE51. I plan to declare the minutes final if I don't receive any comments for significant changes by November 4th 2005. I would like to thank Timothy Lowe from the RIPE NCC for taking the minutes. David Kessens --- Minutes IPv6 Working Group session Amsterdam, 12 Oct, 2005 Chair: David Kessens Scribe: Timothy Lowe # of attendees: 95 ACTION 51.1 - Ask the RIPE NCC to revise the acronym list in the registration package to remove obsolete terms as TLA & NLA (David Kessens) Status: Completed ACTION 51.2 - Create a link from the IPv6 WG page to the APNIC events page: http://apnic.net/info/calendar/index.html (RIPE NCC) Status: To be done ACTION 51.3 - Provide traffic reports on ipv6 usage during the RIPE meetings. If available, data from earlier meetings will be made available as well. (RIPE NCC) A. Administrative stuff Appointment of scribe: Timothy Lowe Agenda bashing: No additions to agenda Action point 51.1 was decided. B. Quick update from the RIPE NCC regarding ipv6 services (RIPE NCC) No news from the RIPE NCC C. IPv6 events calendar on the ipv6 working group page (proposed by Timothy Lowe) It was decided that similar event pages already exist and that we can simply provide a link to the APNIC event pages. (See action point D. Discussion on: Global IPv6 routing table status (Gert Doering, Spacenet) Discussion on filtering: Gert Doering: The RIPE Whois database is the only one allowing route6 object creation. Iljitsch Van Beijnum: What is the gain of filtering less specific ? Geoff Huston: What problem are you trying to solve ? Gert Doering: Trying to prevent accident, less maintenance if the documentation is in the database then it will be more stable. Conclusion: as we cannot force people to filter, we will see more specifics anyways (David Kessens) E. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? - http://www.sixxs.net/misc/traffic/ (Jeroen Massar) Pointer to Jeroen's website was provided, but content was not discussed. Pim van Pelt offered to do some work to provide more data on his Sixxs ipv6 service but it was decided that the amount of work was probably not worth the effort. Discussed whether any ipv6 usage data from the RIPE meetings itself was available. This discussion resulted in a request and an action point for the RIPE NCC to provide us such data in the future (Action point 51.3) F. The end of the 6bone address space is in sight (Jeroen Massar) Discussion: - what are people going to do with 6bone address space as - per 6/6/6 ? - filter it? - keep it going? - warn people? - what to do with the 6bone registry ? Iljisch v B.: DNS is not auto-configurable in IPv6 like it is in IPv4 so I would like to use 6bone to get an ipv6 assignment for an experiment for well-known ipv6 DNS resolver addresses. Geoff H. : IANA has released a statment that 6bone dies on 06/06/2006. Gerd D.: exactly, what will people do when this happens? No uniform policy on what to do with 6bone prefixes. Some people will start filtering while others won't bother. In general, people advised David Kessens who maintains the 6bone registry to stop accepting registry changes by the close date but to keep the data online for some time to come with proper warning message when information is accessed. G. Developments/initiatives regarding IPv6 in the RIPE region and beyond - 6DISS (Bernard Tuy) Presentation will be available on the RIPE website as soon as Bernard Tuy provides the slides No questions. H. Input for the RIPE NCC Activity Plan (no input from the audience) Z. AOB Peter Koch drew attention to a presentation in the DNS working group regarding the deprecation of IP6.int. ----

2 1

Re: [6bone] RIPE and IPv6 ASN
by marko ramljak 07 Oct '05

07 Oct '05

On Tue, 15 Oct 2002, Arien Vijn wrote: > On 15-10-2002 17:00PM, "Nicolas DEFFAYET" <nicolas.deffayet@localhost > wrote: > > > On Tue, 2002-10-15 at 16:33, Bill Manning wrote: > >> % My company created the first french > >> % IPv6 Internet Exchange, FNIX6 (http://www.fnix6.net) but my company > >> % can't peer on FNIX6 becase we don't have public ASN. > >> > >> this is not the first v6 enabled exchange in France. > >> there are three other exchanges which are v6 enabled. > >> > > > > This other Internet Exchange in France are IPv4 and IPv6 Internet > > Exchange (dualstack). > > IPv6 Internet Exchange = IPv6 only > > Why? Is what we are doing not IPv6? > > Arien IPv6 only = Purely IPv6 (no IPv4 legacy stuff!) I've understood it as a marketing issue... :-) Nicolas, about the problem: If you get LIR Status you'll probably get your ASN quickly. Regards, ./Carlos "Networking is fun!"

2 1

Draft Agenda (v2) for ipv6 wg RIPE51
by David Kessens 04 Oct '05

04 Oct '05

Please see below for the draft agenda (v2) of the ipv6 working group. We still have some room in the agenda so let me know if there is anything that you would like to discuss. As mentioned before, I would also like to draw your attention to the plenary part of the meeting that has various interesting ipv6 presentations on the agenda (see below). David Kessens --- Draft Agenda (v2) for the IPv6 Working Group Meeting RIPE51 When: Wednesday, October 12, 2005, 17:00-18:00 Where: Grand Ballroom, Hotel Krasnapolsky, Amsterdam A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Quick update from the RIPE NCC regarding ipv6 services (RIPE NCC) C. IPv6 events calendar on the ipv6 working group page (proposed by Timothy Lowe) D. Discussion on: Global IPv6 routing table status (Gert Doering) routing policy: - is it mandatory to register route6's and inet6num's or is it just 'being nice' ? - is the trend going to be that >/32's will be announced as separate /32's? what is the correct plan for shorter than /32 prefixes ? E. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? - http://www.sixxs.net/misc/traffic/ (Jeroen Massar) - ... (input from the audience) F. The end of the 6bone address space is in sight (Jeroen Massar) Discussion: - what are people going to do with 6bone address space as per 6/6/6 ? - filter it? - keep it going? - warn people? - what to do with the 6bone registry ? G. Developments/initiatives regarding IPv6 in the RIPE region and beyond - 6DISS (Bernard Tuy) - ... (input from the audience) H. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB --- Interesting topics in the plenary section: TUESDAY 09:00 - 10:30 6. IPv6 Routing Update. Gert Doering. Spacenet (20 min) Update on observations on the state of the IPv6 default free routing table. 7. IPv6 Multihoming Status. Kurtis Lindqvist. Netnod (30 min) An up-to-date status report on the progress towards scalable IPv6 multihoming. 8. IPv6 Address Allocation --An Alternative Algorithm for the Sparse Allocation Process. Mae Wang (30 min) IP address allocation policies significantly impact the Internet infrastructure, affecting many parties such as router manufacturers, ISPs, and end users. An address allocation policy can also directly affect the performance of the Internet. For example, address fragmentation, a key problem in IPv4, degrades address lookup performance in routers. Thus, a well-designed address allocation policy needs to minimise fragmentation while using the address space efficiently. This paper attempts to quantify the performance of address allocation policies by modelling key features that lead to fragmentation and inefficient address space usage. Our main contributions are: (i) we identify a drawback of the current IPv6 address allocation policy, which treats all entities uniformly, (ii) we propose a scheme that takes future growth rate into account for allocations, and (iii) an analytical model for measuring the efficiency of allocation schemes, allowing us to quantify the improvement our proposal offers over the current scheme. We believe that a quantitative study of allocation policies is timely since IPv6 address allocation is just beginning in earnest.

1 0

RE: [ipv6-wg] Draft Agenda (v1) for ipv6 wg RIPE51
by Mattias.Lignell＠teliasonera.com 03 Oct '05

03 Oct '05

Hello again, I will have a second look at this and discuss the issue internally. I sure hope we can remove the /32's. /// Mattias > -----Original Message----- > From: Jeroen Massar [mailto:jeroen@unfix.org] > Sent: Monday, October 03, 2005 7:15 PM > To: Lignell, Mattias E. > Cc: gert(a)space.net; david.kessens(a)nokia.com; eva(a)telia.net; > Lind, Mikael E.; amar(a)telia.net; ipv6-wg(a)ripe.net > Subject: RE: [ipv6-wg] Draft Agenda (v1) for ipv6 wg RIPE51 > > On Mon, 2005-10-03 at 18:59 +0200, Mattias.Lignell(a)teliasonera.com > wrote: > > Hello all, > > > > About the /32's; they are announced on purpose. The reason > is that we > > have had problems with some ISP's BGP filters that are set to a > > maximum size of /32. As a result did not our IPv6 customers get > > connectivity via ISP's using the /32 size filters. Maybe this is a > > problem only we run in to being one of the first using a very large > > prefix. However, the BGP filters may be updated by now so > we can stop announcing the /32's. > > Thanks for the response, the prefix filtering is not too good > to hear and has been seen before; I know that Daniel Roesen > has been very busy trying to get C&W's /20 available to ISP's > using, amongst others, the output from: > http://www.sixxs.net/tools/grh/compare/?a=2001:5000::/21&b=200 > 1:650::/32 > At the moment apparently Cisco doesn't see the /21... > > This can be easily applied to Telia's /20: > http://www.sixxs.net/tools/grh/compare/?a=2001:2000::/20&b=200 > 1:2040::/32 > > This compares 2001:2000::/20 with 2001:2040::/32. > Taking a quick look it looks quite good, ignoring the light > orange which is there because of the added ASN. There are > only few ISP's who report different paths: > AS 6435 - LavaNet (us / Hawaii) > AS 9264 - Academic Services Network (tw) > AS21155 - Proserve (nl) > AS28788 - Unilogic (nl) {using same upstreams as AS21155) > > You might want to contact these ISP's to ask them + upstreams > to fix their filtering, clearly something is being filtered, > otherwise the paths where the same. > > Greets, > Jeroen > >

1 0

RE: [ipv6-wg] Draft Agenda (v1) for ipv6 wg RIPE51
by Mattias.Lignell＠teliasonera.com 03 Oct '05

03 Oct '05

Hello all, About the /32's; they are announced on purpose. The reason is that we have had problems with some ISP's BGP filters that are set to a maximum size of /32. As a result did not our IPv6 customers get connectivity via ISP's using the /32 size filters. Maybe this is a problem only we run in to being one of the first using a very large prefix. However, the BGP filters may be updated by now so we can stop announcing the /32's. Please note that this has been a temporary work around to maintain connectivity for our customers. We also have old prefixes that we are about to return to RIPE (2001:06C0::/35), but not yet had time to shout down (affects many customers and links). It is of-cause the policy of the TeliaSonera group to normally only announce one prefix. Any comments to this are most welcome. Best regards /// Mattias Lignell -------------------------------------------------------------- Mattias Lignell TeliaSonera Sweden, IP-Networks Phone: +46 8 713 3706 Mobile: +46 70 595 9068 Fax: +46 70 615 6245 Email: mattias.lignell(a)teliasonera.com Address: Vitsandsgatan 9, House-D, 123 86 Farsta, SWEDEN ICQ UIN: 18690075 -------------------------------------------------------------- > ------------------------------------------------------------- > ----- Original Message ----- > From: "Jeroen Massar" <jeroen(a)unfix.org> > To: "Gert Doering" <gert(a)space.net>; "David Kessens" > <david.kessens(a)nokia.com> > Cc: "Amar Andersson" <amar(a)telia.net>; <ipv6-wg(a)ripe.net> > Sent: Friday, September 30, 2005 3:06 PM > Subject: Re: [ipv6-wg] Draft Agenda (v1) for ipv6 wg RIPE51 > > On Thu, 2005-09-29 at 20:46 -0700, David Kessens wrote: One discussion point you might want to raise: - what are people going to do with 6bone address space as per 6/6/6 ? - filter it? - keep it going? - warn people? In january I will send out a note to all the folks still announcing 6bone prefixes to remind them that they should be shutting it down per 6/6/6. There doesn't seem to be a large movement in doing so yet... > C. Discussion on: > Global IPv6 routing table status > (Gert Doering) Maybe something related might be noted here, in the global routing tables I've seen for instance, just a 'random' targetted pick. http://www.sixxs.net/tools/grh/lg/?find=2001:2000::/20 [Notez bien: the question here is about what is going to become the common policy and what is going to happen to the ipv6 routing, it is not to 'attack' or critize an ISP on what they are doing] 2001:2000::/20 announced by AS1299 (TELIANET) 2001:2040::/32 AS3301 (TELIA-SWEDEN) 2001:2060::/32 AS1759 (SONERA-TRANSIT-AS) No route6 for these 3 prefixes and no inet6nums exist for the the two /32's. Which leads me to a couple of questions: - is it mandatory to register route6's and inet6num's or is it just 'being nice' - is the trend going to be that >/32's will be announced as separate /32's? This of course means that the ISP can be found under one block but still affects the number of routes in the routing table. One could filter the smaller ones if the parent route is present. The idea of minimizing routing table size (yes that is not an issue now, but behold the future) is totally gone when ISP's will do this. I do understand why: to make the branches independant and attract the traffic as local as possible. On the otherside there are also ISP's simply requesting multiple separate /32's from the various RIR's. eg UUNet: 2001:0600::/32 - Europe 2001:4440::/32 - Hongkong 2001:4441::/32 - Australia 2001:4442::/32 - Japan 2001:0588::/32 - South Africa (I am ignoring the 6bone block they still have, with 1 other already returned, as that one will disappear anyway) The question in case of this setup is, why didn't they get 1 block? The generic question: what is the correct plan for these setups? > D. Report(s) about *actual* v6 traffic volume as compared to v4? > *what's real* out there, not what's on powerpoint? > (input from the audience) http://www.sixxs.net/misc/traffic/ :) Not much, but it is a bit and for the moment declining a bit weirdly enough. <SNIP> > For example, address fragmentation, a key problem in IPv4, degrades > address lookup performance in routers. Thus, a well-designed > address allocation policy needs to minimise fragmentation while > using the address space efficiently. See my related note above. Greets, Jeroen

2 1

Draft Agenda (v1) for ipv6 wg RIPE51
by David Kessens 30 Sep '05

30 Sep '05

Hi, Please see below for the draft agenda (v1) of the ipv6 working group. This is the first version of the agenda so we are still looking for agenda topics and contributions for the various standard sections of the agenda. Please let me know if there is anything that you would like to discuss. I would also like to draw your attention to the plenary part of the meeting that has various interesting ipv6 presentations on the agenda (see below). David Kessens --- Draft Agenda (v1) for the IPv6 Working Group Meeting RIPE51 When: Wednesday, October 12, 2005, 17:00-18:00 Where: Grand Ballroom, Hotel Krasnapolsky, Amsterdam A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Quick update from the RIPE NCC regarding ipv6 services (RIPE NCC) C. Discussion on: Global IPv6 routing table status (Gert Doering) D. Report(s) about *actual* v6 traffic volume as compared to v4? *what's real* out there, not what's on powerpoint? (input from the audience) E. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) F. Input for the RIPE NCC Activity Plan (input from the audience) Z. AOB --- Interesting topics in the plenary section: TUESDAY 09:00 - 10:30 6. IPv6 Routing Update. Gert Doering. Spacenet (20 min) Update on observations on the state of the IPv6 default free routing table. 7. IPv6 Multihoming Status. Kurtis Lindqvist. Netnod (30 min) An up-to-date status report on the progress towards scalable IPv6 multihoming. 8. IPv6 Address Allocation --An Alternative Algorithm for the Sparse Allocation Process. Mae Wang (30 min) IP address allocation policies significantly impact the Internet infrastructure, affecting many parties such as router manufacturers, ISPs, and end users. An address allocation policy can also directly affect the performance of the Internet. For example, address fragmentation, a key problem in IPv4, degrades address lookup performance in routers. Thus, a well-designed address allocation policy needs to minimise fragmentation while using the address space efficiently. This paper attempts to quantify the performance of address allocation policies by modelling key features that lead to fragmentation and inefficient address space usage. Our main contributions are: (i) we identify a drawback of the current IPv6 address allocation policy, which treats all entities uniformly, (ii) we propose a scheme that takes future growth rate into account for allocations, and (iii) an analytical model for measuring the efficiency of allocation schemes, allowing us to quantify the improvement our proposal offers over the current scheme. We believe that a quantitative study of allocation policies is timely since IPv6 address allocation is just beginning in earnest. ------

3 2

RIPE Policy Development Process
by Paul Rendek 01 Sep '05

01 Sep '05

Dear Colleagues We are pleased to announce that Rob Blokzijl, RIPE Chair, has published a new RIPE Document, "Policy Development Process in RIPE", (ripe-350). This document formally describes the policy development process. The updated process is operational from today, 1 September 2005. A new RIPE web page describes all the active policy proposals and their status. Each proposal has a page showing its history, status and all supporting documentation. This page can be found at: http://www.ripe.net/ripe/policies/proposals/index.html A new mailing list <policy-announce(a)ripe.net> has been created for announcing policy proposals and tracking them through the policy development process. This is not a discussion list; discussions will continue to take place on relevant RIPE Working Group lists and at RIPE Meetings. You can subscribe to the policy-announce list at: http://www.ripe.net/mailman/listinfo/policy-announce List archives are available at: http://www.ripe.net/ripe/maillists/archives/policy-announce/ Kind regards Paul Rendek Head of Member Services and Communications RIPE NCC

1 0