From michael.dillon at bt.com Fri Jun 1 05:22:06 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 1 Jun 2007 10:22:06 +0100 Subject: [ppml] rubber/road In-Reply-To: <465F548F.8080005@spaghetti.zurich.ibm.com> References: <465F548F.8080005@spaghetti.zurich.ibm.com> Message-ID: > My magic crystal ball tells me that IPv4 address space will > become pricey, as that is the resource running out, not IPv6 space. Get rid of that crystal ball, it doesn't work. The ARIN fees will not go up because of IPv4 space running out since the fees are based on maintaining the organization so they are more related to the amount of work involved in processing applications than to any characteristic of the number blocks. Also, ARINs fees are not decided through the public policy process. The members of ARIN ultimately set the fees that they pay and the members have their own mailing list to discuss these things. If you are an ARIN member then you can join the list here http://lists.arin.net/mailman/listinfo/arin-discuss . > You can make all kinds of weird assumptions about the future, That is for sure... > one thing is sure: IPv4 address space won't be available > anymore from the RIRs in a couple of years. The blackmarket > will have it for you though. If companies actually NEED the addresses they have been allocated, then it will not be on the black market. If they don't need it and also do not return it to the RIRs for reallocation then they could well be committing fraud which is not a wise thing to do in these days of Sarbannes-Oxley etc. etc. --Michael Dillon From jeroen at unfix.org Fri Jun 1 06:23:36 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 01 Jun 2007 11:23:36 +0100 Subject: [ppml] rubber/road In-Reply-To: References: <465F548F.8080005@spaghetti.zurich.ibm.com> Message-ID: <465FF3A8.6080409@spaghetti.zurich.ibm.com> michael.dillon at bt.com wrote: [..] >> one thing is sure: IPv4 address space won't be available >> anymore from the RIRs in a couple of years. The blackmarket >> will have it for you though. > > If companies actually NEED the addresses they have been allocated, then > it will not be on the black market. If they don't need it and also do > not return it to the RIRs for reallocation then they could well be > committing fraud which is not a wise thing to do in these days of > Sarbannes-Oxley etc. etc. Does SO also cover that, cool, so it has a use. Fortunately for some that I don't play rat ;) Several other people have also already reported that $companyX was trying to buy IPv4 address space from them for rather nice figures of money ;) Good to know that there is at least some form of law against. I do hope though that something like that is also available in the rest of the world. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From leroy at emailsorting.com Fri Jun 1 11:19:41 2007 From: leroy at emailsorting.com (Leroy Ladyzhensky) Date: Fri, 1 Jun 2007 11:19:41 -0400 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks Message-ID: <008801c7a460$46e97870$c80a0a0a@integrated.net> Ted, I think you don't understand... so let me make this more clear... An ASP or MSP who provides an internet service rarely supports or deploys the end user/customers router or firewall. also for an ASP or MSP their majority of customers are small businesses who don't have justification for managing their own solution internally. And since this is case you can see how the customer will have lower end equipment. and no one on staff that is computer savvy (other wise they would not need to out source any services or applications). So thanks you for wonderful insight to the wonderful world of Cisco and their IOS... but its not applicable in this scenario. you also indicate that the real cause is lack-of-planning... wouldn't acquiring address space from ARIN (if possible) be good planning? you also mentioned that using a reliable ISP for upstream connection is needed, and not some "fly by night operator"... Let me give you an example of a NON-fly-by-night ISP... A company had their equipment hosted in a datacenter, and a major provider was in the same building. so an Ethernet connection was run from the NON-fly-by-night ISP up to the datacenter. In a few years the ISP Was bought out by another major NON-fly-by-night ISP and decided that this location is redundant in the area and is no longer needed. If connection was to be maintained then an DS3 or fiber would need to be utilized from the local Telco, and thus the pricing went way up... (I guess the company in the datacenter could have done some better planning to avoid this) needless to say.. if they had their own block of IP's the could have went to another NON-fly-by-night ISP in the same building and got an Ethernet connection from them to save on cost. These situation happen all the time, and there are many more examples of what NON-fly-by-night ISP do and can do.... an no one can argue this.. Leroy Ladyzhensky - CCNA, CCDA, CSE -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.dul at quark.net Fri Jun 1 11:59:57 2007 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Fri, 01 Jun 2007 07:59:57 -0800 Subject: [ppml] Fw: ARIN Reponse to Suggestion 2007.16 Message-ID: <20070601155957.17642.qmail@hoster908.com> While I think this is a perfectly reasonable answer to this suggestion, it seems to me that an "accepted suggestion" should be kept open until it is completed and regular updates should be published on the status of all "accepted suggestions". Andrew > -------Original Message------- > From: Member Services > Subject: ARIN Reponse to Suggestion 2007.16 > Sent: 01 Jun '07 07:30 > > Dear Andrew, > > This is in response to your suggestion noted below and assigned number > 2007.16 upon receipt of your confirmation. > > ARIN is interested in offering improved customer service applications > via a web-based portal. Staff has begun preliminary discussions to > define the scope of this project. Given the large number of features > possible with such an offering, it is likely that we will introduce > components incrementally. > > You can expect to hear a progress report during the ARIN XX meeting in > Albuquerque. Thank you for participating in the ARIN Consultation and > Suggestion Process. Suggestion 2007.16 is now considered closed. > > Regards, > > Raymond A. Plzak > President and CEO > American Registry for Internet Numbers (ARIN) > > > ********************************** > 2007.16 > Submitted 04-24-2007 11:53:32 > Status CONFIRMED > Suggestion > > Implement a web-based portal for resource users to view and change their > resource records. > > Timeframe As soon as possible > > Submitter Information > Name Andrew Dul > Org Name Perkins Coie LLP > E-Mail andrew.dul at quark.net > From heather.schiller at verizonbusiness.com Fri Jun 1 12:12:42 2007 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Fri, 01 Jun 2007 16:12:42 +0000 (GMT) Subject: [ppml] Keeping the story straight In-Reply-To: <00b801c7a3ea$8f29bb20$ad7d3160$@net> References: <009601c7a3bf$fc398ea0$c80a0a0a@integrated.net> <1f8101c7a3c7$9c246a00$d46d3e00$@net> <00b801c7a3ea$8f29bb20$ad7d3160$@net> Message-ID: On Thu, 31 May 2007, Tony Hain wrote: > Heather Schiller wrote: >>> ..... >>> >>> Somebody needs to figure out the real story, then try to keep it >> straight. >>> Tony >>> >> >> I can't tell from your email if you want: >> - ARIN to guarantee routability >> - not make a formal statement on routability (thus implying anything or >> nothing) >> - You want ARIN/RIR's to declare/refine their function/mission >> statement >> - or you just want to ask a bunch of rhetorical questions to get people >> thinking and you may or may not have your own opinion? >> >> (..and I'm not intending to be snide.. it's just that sometimes email >> is a >> lousy method of communication and I really can't tell) > > I was pointing out the difference in attitude, depending on who is arguing > what point. On the one hand people take the high-road and say ARIN does not > talk about routability, while on the other people want to refuse space to ..well it's actually in the formal written policies.. which is why I said, if you want to change what people can argue or quote then you have to change the policy. > people unless it is 'routed in the public Internet'. I would actually prefer > to remove all discussion about routability and just talk about managing the > IPv6 pool. > > People should be able to get a PI block and a ULA-C block, and what they do > with those is not ARIN's concern as long as they maintain their membership. > It really doesn't matter if people don't think they need both, if the > requestor thinks they need it and their membership is current, give it to > them. What happens after that is not an ARIN policy concern. > > The flip-flopping that goes on about routability is what has to stop. If the > majority wants to only worry about routed space, I am fine with that, but > you can't have it both ways like it is now. > Ok.. I think that the 'routability not guaranteed' is a legal CYA on ARIN's part. Their way of saying, you can get space from us, but we have no authority to order anyone to accept the route or the traffic that comes from it. Maybe it doesn't belong in NRPM but the RSA.. don't know if or how that would change things. But I imagine a lot of legal folks at providers wouldn't be happy with a policy that required folks to route RIR allocated space.. the alternative would be removing it altogether, and again I bet that creates some legal problems. --Heather /not a lawyer.. just work with them a lot/ > Tony > > From iljitsch at muada.com Fri Jun 1 12:44:18 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 1 Jun 2007 18:44:18 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <78600.1180542129@sa.vix.com> References: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> <78600.1180542129@sa.vix.com> Message-ID: On 30-mei-2007, at 18:22, Paul_Vixie at isc.org wrote: > first, ARIN does not currently consider routability when allocating > address space. Hm: http://www.arin.net/policy/nrpm.html 6.3.4. Aggregation Wherever possible, address space should be distributed in a hierarchical manner, according to the topology of network infrastructure. This is necessary to permit the aggregation of routing information by ISPs, and to limit the expansion of Internet routing tables. This goal is particularly important in IPv6 addressing, where the size of the total address pool creates significant implications for both internal and external routing. The whole "routing is not guaranteed" thing is obviously in there because of the lawyers since ARIN can't force ISPs to route any given block of address space, not because routability isn't a goal. > non-routable space comes from ietf/iana, not the RIRs. > so, for ARIN to start allocating nonroutable space is a big change. Keeping the RIRs out of the ULA business would nicely avoid any problems resulting from that. Just let the domain sell the ip6.arpa domains in question. > (heck, maybe the old site-local prefix is still available.) http://www.ietf.org/rfc/rfc3879.txt Existing implementations and deployments MAY continue to use this prefix. From paul at vix.com Fri Jun 1 13:00:46 2007 From: paul at vix.com (Paul Vixie) Date: Fri, 01 Jun 2007 17:00:46 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Your message of "Fri, 01 Jun 2007 18:44:18 +0200." References: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> <78600.1180542129@sa.vix.com> Message-ID: <98099.1180717246@sa.vix.com> > The whole "routing is not guaranteed" thing is obviously in there > because of the lawyers since ARIN can't force ISPs to route any given > block of address space, not because routability isn't a goal. yes. but also because of the other part of my text, which you didn't include in your reply so i don't know whether you agreed with it or not: >> ... we would have to define "routable", we could face implied liability for >> routability on "normal address space" (even if we continue to disclaim it >> in the NRPM as we do now), and we would then walk the slippery slope of the >> changing definition "largest" with respect to breidbart's maxim: >> But what *IS* the internet? > It's the largest equivalence class in the reflexive transitive > symmetric closure of the relationship "can be reached by an IP > packet from". --Seth Breidbart in other words, the definition of "routable" depends on who you want to be able to exchange packets with. if three networks are numbered in 10.1/16, 10.2/16, and 10.3/16, and they interconnect, then that address space is "routable" for *some* definition of "routable". i don't think we want to have to define, and then live with the implications of, the word "routable". > > non-routable space comes from ietf/iana, not the RIRs. > > so, for ARIN to start allocating nonroutable space is a big change. > > Keeping the RIRs out of the ULA business would nicely avoid any > problems resulting from that. Just let the domain sell the ip6.arpa > domains in question. see above. dunno why you didn't read it the first time i posted it here but i've posted it again and added some explaination. "universal" or "unique" we know the definition of. "local" and "routable", not so much so. From iljitsch at muada.com Fri Jun 1 18:39:20 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sat, 2 Jun 2007 00:39:20 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <98099.1180717246@sa.vix.com> References: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> <78600.1180542129@sa.vix.com> <98099.1180717246@sa.vix.com> Message-ID: On 1-jun-2007, at 19:00, Paul Vixie wrote: > yes. but also because of the other part of my text, which you didn't > include in your reply so i don't know whether you agreed with it or > not: >>> ... we would have to define "routable", we could face implied >>> liability for >>> routability on "normal address space" (even if we continue to >>> disclaim it >>> in the NRPM as we do now), and we would then walk the slippery >>> slope of the >>> changing definition "largest" with respect to breidbart's maxim: > >> But what *IS* the internet? > > It's the largest equivalence class in the reflexive transitive > > symmetric closure of the relationship "can be reached by an IP > > packet from". --Seth Breidbart > in other words, the definition of "routable" depends on who you > want to be > able to exchange packets with. I'm not sure if I agree that there is a potential liability, but then, I'm not a lawyer, I don't play one on TV and the legal system where I live is quite different from that where ARIN is. The question of what "routability" is is not one that I'm interested in. We know what this means today, massaging the definition to fit a particular purpose can only lead to suboptimal results. > "local" and "routable", not so much so. Ok, if that makes you happy: Routable address space: any block of global unicast address space that when announced through or by an internet service provider, allows the holder to receive packets addressed to the addresses in question from all possible sources connected to the internet without additional effort. ULA fails this test because it falls outside the global unicast block and because announcing it to one ISP isn't enough to receive packets from all over the world because people will filter. From paul at vix.com Fri Jun 1 20:02:07 2007 From: paul at vix.com (Paul Vixie) Date: Sat, 02 Jun 2007 00:02:07 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Your message of "Sat, 02 Jun 2007 00:39:20 +0200." References: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> <78600.1180542129@sa.vix.com> <98099.1180717246@sa.vix.com> Message-ID: <38008.1180742527@sa.vix.com> > > in other words, the definition of "routable" depends on who > > you want to be able to exchange packets with. > > ... The question of what "routability" is is not one that I'm interested > in. We know what this means today, massaging the definition to fit a > particular purpose can only lead to suboptimal results. we do not know, for the purpose of understanding and implementing a ULA policy, what "routability" means today. your lack of interest in it is not going to advance the debate as to whether ULA is a good or bad policy. > > "local" and "routable", not so much so. > > Ok, if that makes you happy: > > Routable address space: any block of global unicast address space that when > announced through or by an internet service provider, allows the holder to > receive packets addressed to the addresses in question from all possible > sources connected to the internet without additional effort. "the internet"? let me quote this again in case you missed it the last two times: >> But what *IS* the internet? > It's the largest equivalence class in the reflexive transitive > symmetric closure of the relationship "can be reached by an IP > packet from". --Seth Breidbart smaller private connectivity domains would only depend on uniqueness among their participants. are you trying to make a definition of "routable" that depends on which connectivity domain the observer is actually in? or would it be enough to say "the connectivity domain that ARIN's members all share"? > ULA fails this test because it falls outside the global unicast block > and because announcing it to one ISP isn't enough to receive packets > from all over the world because people will filter. so the routability of an address block can also depend on filters? (and perhaps on firewalls?) and is an address block that's "routable" today capable of being "unroutable" tomorrow? and if it's "routable" according to network X, can it be "unroutable" according to network Y? i can't imagine how a policy with these dependencies would be implemented. which is precisely the point i'm trying to make. the RIR system can guaranty uniqueness among RIR allocations, but can make no assertions either way as to "routability". since any definition of ULA depends on a definition of "routable", i think this slope is too slippery for us. From christopher.morrow at gmail.com Sat Jun 2 01:29:05 2007 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Sat, 2 Jun 2007 01:29:05 -0400 Subject: [ppml] Keeping the story straight In-Reply-To: <00b801c7a3ea$8f29bb20$ad7d3160$@net> References: <009601c7a3bf$fc398ea0$c80a0a0a@integrated.net> <1f8101c7a3c7$9c246a00$d46d3e00$@net> <00b801c7a3ea$8f29bb20$ad7d3160$@net> Message-ID: <75cb24520706012229g4633cbc8x7faf279512bfab52@mail.gmail.com> On 5/31/07, Tony Hain wrote: > what point. On the one hand people take the high-road and say ARIN does not > talk about routability, while on the other people want to refuse space to > people unless it is 'routed in the public Internet'. I would actually prefer > to remove all discussion about routability and just talk about managing the > IPv6 pool. > > People should be able to get a PI block and a ULA-C block, and what they do > with those is not ARIN's concern as long as they maintain their membership. actually I think ULA/ULA-C are not about routability (atleast not on the public Internet) at all, they are about 'uniqueness' and a backup plan when someone creates a 'unique' space that is the same as your 'unique' space... where that backup plan in ULA-C is: "I registered this properly, go rechoose and this time register..." I think the discussion of 'routability' just confuses the issue, which is really 'uniqueness'. -Chris From packetgrrl at gmail.com Sat Jun 2 10:02:07 2007 From: packetgrrl at gmail.com (cja@daydream.com) Date: Sat, 2 Jun 2007 08:02:07 -0600 Subject: [ppml] Keeping the story straight In-Reply-To: <75cb24520706012229g4633cbc8x7faf279512bfab52@mail.gmail.com> References: <009601c7a3bf$fc398ea0$c80a0a0a@integrated.net> <1f8101c7a3c7$9c246a00$d46d3e00$@net> <00b801c7a3ea$8f29bb20$ad7d3160$@net> <75cb24520706012229g4633cbc8x7faf279512bfab52@mail.gmail.com> Message-ID: Although I have been out of the cable internet business for some time now (someone else who is there now might want to chime in) but we had a huge need for large blocks of unique addresses. RFC1918 space was a huge problem for us for a number of reasons. We had a large number of devices that needed IP addresses but never needed to be reached outside our network. We had cable modems, set-top boxes, etc. The nature of the cable industry is that cable companies are often swapping properties and the like. So we were constantly having to deal with overlapping RFC1918 space. And absolutely EVERYONE started their addressing plan at 10.0.0.0 ! We easily used up all of the RFC1918 space and then had to deal with what to do next. A large unique space that could be used for these activities would have been quite helpful. Of course it is the case that regular routed IPv6 space filtered at the network boundaries would have worked fine too. I almost think that I would prefer that because then I would have the choice of using it on my routed infrastructure as I saw fit. ----Cathy On 6/1/07, Christopher Morrow wrote: > > On 5/31/07, Tony Hain wrote: > > > what point. On the one hand people take the high-road and say ARIN does > not > > talk about routability, while on the other people want to refuse space > to > > people unless it is 'routed in the public Internet'. I would actually > prefer > > to remove all discussion about routability and just talk about managing > the > > IPv6 pool. > > > > People should be able to get a PI block and a ULA-C block, and what they > do > > with those is not ARIN's concern as long as they maintain their > membership. > > actually I think ULA/ULA-C are not about routability (atleast not on > the public Internet) at all, they are about 'uniqueness' and a backup > plan when someone creates a 'unique' space that is the same as your > 'unique' space... where that backup plan in ULA-C is: "I registered > this properly, go rechoose and this time register..." > > I think the discussion of 'routability' just confuses the issue, which > is really 'uniqueness'. > > -Chris > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iljitsch at muada.com Sat Jun 2 11:22:21 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sat, 2 Jun 2007 17:22:21 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070531215244.GA43143@ussenterprise.ufp.org> References: <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529135031.GA57185@ussenterprise.ufp.org> <12093.1180450716@sa.vix.com> <20070529160116.GN5379@shell01.corp.tellme.com> <465C5677.3040607@bogus.com> <30761.1180458872@sa.vix.com> <465DD6DF.10701@bogomips.com> <20070530215313.GA53938@ussenterprise.ufp.org> <20070531215244.GA43143@ussenterprise.ufp.org> Message-ID: On 31-mei-2007, at 23:52, Leo Bicknell wrote: > The IETF did half the work, then bailed > on the other half of the work. What's the other half of the work? > All the good stuff about TCP that > would survive address changes, A6/DNAME, etc, etc etc has been > dropped. Now they want the operational world to clean up the mess. How exactly did you intend to deploy A6? I agree (if that is what you're saying) that it's a shame that all the work on tools that would have made renumbering easier has been abandoned, but I'm not aware of any parts of the operational world asking for easier renumbering, they want to avoid renumbering at pretty much all costs. > I think it's absolutely the right thing to complain to the IETF. Sure, complain about what the IETF is doing wrong TODAY. Complaining about what they did wrong a decade ago isn't going to do all that much good. From iljitsch at muada.com Sat Jun 2 11:35:59 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sat, 2 Jun 2007 17:35:59 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <38008.1180742527@sa.vix.com> References: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> <78600.1180542129@sa.vix.com> <98099.1180717246@sa.vix.com> <38008.1180742527@sa.vix.com> Message-ID: <225E16DB-CB98-4C4C-B6AC-DE9D3CCB7280@muada.com> On 2-jun-2007, at 2:02, Paul Vixie wrote: > smaller private connectivity domains would only depend on > uniqueness among > their participants. are you trying to make a definition of > "routable" that > depends on which connectivity domain the observer is actually in? > or would > it be enough to say "the connectivity domain that ARIN's members > all share"? How did we get from routability tto uniqueness? "uniqueness among their participants" doesn't sound so bad until people start participating in multiple connectivity domains. I don't want to fumble the math so I'll spare you (and myself), but you get in the situation where there is overlap really fast. Also, in computer science there are only three numbers: 0, 1 and many. If we need more than one block of private space to avoid collisions, the obvious choice is to have as many blocks as there are domains. >> ULA fails this test because it falls outside the global unicast block >> and because announcing it to one ISP isn't enough to receive packets >> from all over the world because people will filter. > so the routability of an address block can also depend on filters? > (and > perhaps on firewalls?) and is an address block that's "routable" > today > capable of being "unroutable" tomorrow? and if it's "routable" > according > to network X, can it be "unroutable" according to network Y? Don't pretend this is news to you. Ever tried to cat herd? Herding network operators is even worse. > i can't imagine how a policy with these dependencies would be > implemented. Hence the "routability not guaranteed" disclaimer. > which is precisely the point i'm trying to make. the RIR system can > guaranty uniqueness among RIR allocations, but can make no assertions > either way as to "routability". since any definition of ULA > depends on > a definition of "routable", i think this slope is too slippery for us. As I said before, if ARIN feels it should only give out "hopefully routable" address space like it does today, no problem, let other people give out ULA-C space. But ARINs definition issues don't preclude the usefulness of ULA-C. From paul at vix.com Sat Jun 2 12:30:55 2007 From: paul at vix.com (Paul Vixie) Date: Sat, 02 Jun 2007 16:30:55 +0000 Subject: [ppml] Keeping the story straight In-Reply-To: Your message of "Sat, 02 Jun 2007 08:02:07 CST." References: <009601c7a3bf$fc398ea0$c80a0a0a@integrated.net> <1f8101c7a3c7$9c246a00$d46d3e00$@net> <00b801c7a3ea$8f29bb20$ad7d3160$@net> <75cb24520706012229g4633cbc8x7faf279512bfab52@mail.gmail.com> Message-ID: <39171.1180801855@sa.vix.com> > We easily used up all of the RFC1918 space and then had to deal with what to > do next. A large unique space that could be used for these activities would > have been quite helpful. Of course it is the case that regular routed IPv6 > space filtered at the network boundaries would have worked fine too. I > almost think that I would prefer that because then I would have the choice > of using it on my routed infrastructure as I saw fit. > > ----Cathy i think that is indeed the straightest this story can be told. whether space is routable depends on whether one routes it and/or filters it. IPv6 space is so much bigger than the theoretical maximum routing table size (even at /32's) that there's no reason to allocate from pools intended never to be "routable"; the right RIR goalset is still simply "uniqueness" and perhaps "aggregatable", and questions of "routability" should be answered in the field day by day as conditions warrant. From paul at vix.com Sat Jun 2 12:41:27 2007 From: paul at vix.com (Paul Vixie) Date: Sat, 02 Jun 2007 16:41:27 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Your message of "Sat, 02 Jun 2007 17:35:59 +0200." <225E16DB-CB98-4C4C-B6AC-DE9D3CCB7280@muada.com> References: <027601c7a2c9$5af8f5e0$423816ac@atlanta.polycom.com> <78600.1180542129@sa.vix.com> <98099.1180717246@sa.vix.com> <38008.1180742527@sa.vix.com> <225E16DB-CB98-4C4C-B6AC-DE9D3CCB7280@muada.com> Message-ID: <39552.1180802487@sa.vix.com> > How did we get from routability tto uniqueness? uniqueness is the RIR goal for allocations today. routability is a new idea that would have to be seriously investigated to make ULA allocations possible. > "uniqueness among their participants" doesn't sound so bad until people > start participating in multiple connectivity domains. I don't want to fumble > the math so I'll spare you (and myself), but you get in the situation where > there is overlap really fast. Also, in computer science there are only three > numbers: 0, 1 and many. If we need more than one block of private space to > avoid collisions, the obvious choice is to have as many blocks as there are > domains. to me, the obvious choice, since even after wasting half the address space on EUI64, IPv6 is a really large space compared to distance vector convergence limits, is one block, IPv6:0/0. some parts of this will be routed. some will not be routed. some will be routed some days but not others. all allocations from the RIR system will be unique. > > which is precisely the point i'm trying to make. the RIR system can > > guaranty uniqueness among RIR allocations, but can make no assertions > > either way as to "routability". since any definition of ULA depends on a > > definition of "routable", i think this slope is too slippery for us. > > As I said before, if ARIN feels it should only give out "hopefully routable" > address space like it does today, no problem, let other people give out > ULA-C space. But ARINs definition issues don't preclude the usefulness of > ULA-C. since ULA is designed to conserve something that we can't use all of (IPv6 address space) because of something else we can't get enough of (routing table size), at the expense of constraining the future usability of the allocations (forcing a renumbering event to go from unroutable to routable) and requiring a new system of monitoring and enforcement, which by example RFC 1918 still lacks), i have to say, ULA looks like all-pain no-gain to me. From stephen at sprunk.org Sat Jun 2 15:02:58 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 2 Jun 2007 14:02:58 -0500 Subject: [ppml] Keeping the story straight References: <009601c7a3bf$fc398ea0$c80a0a0a@integrated.net><1f8101c7a3c7$9c246a00$d46d3e00$@net><00b801c7a3ea$8f29bb20$ad7d3160$@net> <75cb24520706012229g4633cbc8x7faf279512bfab52@mail.gmail.com> Message-ID: <00f401c7a548$a8d295b0$6401a8c0@atlanta.polycom.com> Thus spake "Christopher Morrow" > actually I think ULA/ULA-C are not about routability (atleast not > on the public Internet) at all, they are about 'uniqueness' and a > backup plan when someone creates a 'unique' space that is the > same as your 'unique' space... where that backup plan in ULA-C > is: "I registered this properly, go rechoose and this time register..." ULA-C uses a different prefix from ULA-L, so nobody using ULA-C (if it passes and is implemented) should ever collide with anyone people using ULA-L. The only possible collision is between two orgs using ULA-L, and the RFC covers the odds of that happening. OTOH, one participant in this discussion has already created a voluntary system where folks who want to register ULA-L prefixes can do so, and there will be zero collisions between participants in that system. That gets all of the supposed benefits of ULA-C without any additional work by the IETF, IANA, or RIRs and costs no money. Bingo, ULA-C is now even more pointless than it already was. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From jordi.palet at consulintel.es Sat Jun 2 15:27:14 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 02 Jun 2007 21:27:14 +0200 Subject: [ppml] Keeping the story straight In-Reply-To: <00f401c7a548$a8d295b0$6401a8c0@atlanta.polycom.com> Message-ID: Unfortunately volunteers offering a service can't be trusted by organizations, as the service can vanish and then you're in trouble. Sorry, but this ULA-Central need a serious proven and stable service, and the RIRs are already doing so for other kinds of addresses. They are the perfect fit, and the alternative is IANA or a third party organization. As I indicated several times, in my opinion doing so will not be any good for the RIR system. Of course, if the community prefers going that way and have a third party organizations running that registry, I'm fine and all will pay the consequences sooner or later. Regards, Jordi > De: Stephen Sprunk > Responder a: > Fecha: Sat, 2 Jun 2007 14:02:58 -0500 > Para: Christopher Morrow > CC: ARIN PPML > Asunto: Re: [ppml] Keeping the story straight > > Thus spake "Christopher Morrow" >> actually I think ULA/ULA-C are not about routability (atleast not >> on the public Internet) at all, they are about 'uniqueness' and a >> backup plan when someone creates a 'unique' space that is the >> same as your 'unique' space... where that backup plan in ULA-C >> is: "I registered this properly, go rechoose and this time register..." > > ULA-C uses a different prefix from ULA-L, so nobody using ULA-C (if it > passes and is implemented) should ever collide with anyone people using > ULA-L. The only possible collision is between two orgs using ULA-L, and the > RFC covers the odds of that happening. > > OTOH, one participant in this discussion has already created a voluntary > system where folks who want to register ULA-L prefixes can do so, and there > will be zero collisions between participants in that system. That gets all > of the supposed benefits of ULA-C without any additional work by the IETF, > IANA, or RIRs and costs no money. Bingo, ULA-C is now even more pointless > than it already was. > > S > > Stephen Sprunk "Those people who think they know everything > CCIE #3723 are a great annoyance to those of us who do." > K5SSS --Isaac Asimov > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jeroen at unfix.org Sat Jun 2 16:02:26 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 02 Jun 2007 21:02:26 +0100 Subject: [ppml] Keeping the story straight In-Reply-To: References: Message-ID: <4661CCD2.1040508@spaghetti.zurich.ibm.com> JORDI PALET MARTINEZ wrote: > Unfortunately volunteers offering a service can't be trusted by > organizations, as the service can vanish and then you're in trouble. Ehmm. Hold on there for a few seconds. That subject really doesn't match the content, but lets make it match quite a bit more. Are you implying that SixXS can't be trusted!? I am really wondering what you are trying to imply with that statement. Did you notice that http://www.sixxs.net/tools/grh/ula/ contains a list of all the allocations that have been made? (inet6num.txt) Do you realize that that list is VERY easy to mirror. Do you realize that that list is nicely mirrored into Google and various other crawler bots who crawl the web? Claiming that it can 'vanish' is just pathetic. SixXS won't 'vanish', there are too many people very happily using the services that it provides, and actually we are more than enjoying ourselves in providing the various great services that it provides to the community. Neither Pim or I have any intentions of letting the project vanish. As long as people have a need for free help in getting IPv6 going in their organizations we are ready to assist them with the help and experience that we can provide them. I've also stated, but I'll do it again, that if/when one of the RIR/IETF/IANA has a registry for these things that we can provide them with the current list, and redirect the page to that resource. Those are the 'authoritive' places, and we play in that game. Next to that, you are definitely mixing up ULA-C with normal ULA's. Normal ULA's, according to RFC4193 don't have any registered part. ULA-C's are not accepted by the registry we run, which is not so strange as there is no RFC covering fc00::/8. The ULA registry that currently is at http://www.sixxs.net/tools/grh/ula/ allows people merely to register their ULA's so that it might decrease the chance of collisions a little bit more. > Sorry, but this ULA-Central need a serious proven and stable service And are you implying here that SixXS is not a proven and not stable service? I do sincerely hope that you are not trying to insult all the hard work that has gone and more that will go into into this project by a lot of people and several great companies that have been supporting this project for the last couple of years. I feel _very_ insulted by the statements you are making here and I really hope that you are meaning something completely different. What are you going to claim next, that Team Cymru, who also are doing great work, should not maintain bogon lists because they are not a company? > and the RIRs are already doing so for other kinds of addresses.They are the > perfect fit, and the alternative is IANA or a third party organization. How is SixXS not a "third party organization"? > Of course, if the community prefers going that way and have a third party > organizations running that registry, I'm fine and all will pay the > consequences sooner or later. Sorry, but all of this coming from someone who is abusing his "Experimental IPv6 Allocation", thus avoiding paying of LIR fees, so that it can be used to do an "Experimental IPv6 ISP Service" as you described it last week on these lists, sounds really really bad. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From randy at psg.com Sat Jun 2 16:04:55 2007 From: randy at psg.com (Randy Bush) Date: Sat, 02 Jun 2007 13:04:55 -0700 Subject: [ppml] Keeping the story straight In-Reply-To: <4661CCD2.1040508@spaghetti.zurich.ibm.com> References: <4661CCD2.1040508@spaghetti.zurich.ibm.com> Message-ID: <4661CD67.2070402@psg.com> Jeroen Massar wrote: > JORDI PALET MARTINEZ wrote: >> Unfortunately volunteers offering a service can't be trusted by >> organizations, as the service can vanish and then you're in trouble. then stop using root servers From bicknell at ufp.org Sat Jun 2 16:11:28 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 2 Jun 2007 16:11:28 -0400 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: References: <20070529135031.GA57185@ussenterprise.ufp.org> <12093.1180450716@sa.vix.com> <20070529160116.GN5379@shell01.corp.tellme.com> <465C5677.3040607@bogus.com> <30761.1180458872@sa.vix.com> <465DD6DF.10701@bogomips.com> <20070530215313.GA53938@ussenterprise.ufp.org> <20070531215244.GA43143@ussenterprise.ufp.org> Message-ID: <20070602201127.GA43035@ussenterprise.ufp.org> In a message written on Sat, Jun 02, 2007 at 05:22:21PM +0200, Iljitsch van Beijnum wrote: > What's the other half of the work? The transition from IPv4 to IPv6 was supposed to provide the opportunity to introduce new technologies and procedures that could make renumbering easier, make multi-homing scale better, make running a box with multiple IP addresses easier, and I'm sure do a lot of other things. Basically they have all been left by the side of the road. What's left of them seems to be eternally stuck inside the IETF. My point is, if none of these technologies exist, and we run out of IPv4 addresses creating a "mad rush" to IPv6 enable that the RIR's and operators will have no choice but to provide IPv6 PI to anyone who has IPv4 PI today. We're already seeing that happen. Once we have a 200,000 route IPv6 table, and everyone has PI space not only will there be no interest in all of these technologies but there will be active resistance as those with PI already will see it as a step backwards, and those without PI will see it as inequality. Now, considering we have to write code and deploy it, the IETF is all but out of time. If they can't get some of this technology documented and out the door in the next 6-18 months then the IETF should just shut down all work on them, as they all become moot. Does anyone at the IETF understand that, or am I the only one with this view? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From william at elan.net Sat Jun 2 17:36:07 2007 From: william at elan.net (william(at)elan.net) Date: Sat, 2 Jun 2007 14:36:07 -0700 (PDT) Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <20070602201127.GA43035@ussenterprise.ufp.org> References: <20070529135031.GA57185@ussenterprise.ufp.org> <12093.1180450716@sa.vix.com> <20070529160116.GN5379@shell01.corp.tellme.com> <465C5677.3040607@bogus.com> <30761.1180458872@sa.vix.com> <465DD6DF.10701@bogomips.com> <20070530215313.GA53938@ussenterprise.ufp.org> <20070531215244.GA43143@ussenterprise.ufp.org> <20070602201127.GA43035@ussenterprise.ufp.org> Message-ID: First, I totally agree about what IPv6 should have been (easy renumbering, non-bgp multi-homing & mobility, etc) and that it did not happen. See some of my opinion about it below, but generally I have to note what is being deployed is not the best technical solutions proposed, but rather the ones in regards to which there has been the least conflict. On Sat, 2 Jun 2007, Leo Bicknell wrote: > Now, considering we have to write code and deploy it, the IETF is > all but out of time. If they can't get some of this technology > documented and out the door in the next 6-18 months then the IETF > should just shut down all work on them, as they all become moot. 1. We're out of time already. When IPv6 transition needs to happen what we'll have is working ipv6 stack which thankfully has been made available for most OS. But considering how long that took (and its not even available for everything), that is as good as it would be. 2. IETF need not shut anything down, transitions happen and there will be new one later that new internet users & business can take advantage of. At the same time we must have IPv6 PI in order to make it possible for existing IPv4 users to start using IPv6 as that is the way they know how to. So we must be prepared that IPv6 will have both PA and PI blocks and what needs to be done is make it advantageous in the future for new users to use new technologies - and yes, that make take another 20 years to get to. > Does anyone at the IETF understand that, or am I the only one with this > view? There are a lot of very smart folks at IETF that I think know all this. However: 1. IETF is also composed with individuals with their own egos and sometimes rather opposite opinions which technology and direct should be done. Right now it seems IETF decided to let each group 2. IETF also is to large degree controlled/influenced by vendors who sometimes have their own interest not necessarily aligned to best interests of the internet community as a whole. 3. IETF operates though consensus and there is still a lot of debate in regards to IPv6 transition. Especially big problem is lock of clear architectural vision (see #1) and ability to direct this vision through vendors who have their own interest (#2). Of course above is all my personal view and it may well not be correct, somebody with closer ties to inner circles of IETF feel free to correct. -- William Leibzon Elan Networks william at elan.net From jordi.palet at consulintel.es Sat Jun 2 20:42:54 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 03 Jun 2007 02:42:54 +0200 Subject: [ppml] Keeping the story straight In-Reply-To: <4661CCD2.1040508@spaghetti.zurich.ibm.com> Message-ID: Hi Jeroen, Is nothing personal. I can trust you, many people can trust many volunteer services, but for something that big enterprises need to have the security of a 0% collision chances, they will not trust a volunteer service. There is NO warrantee for them that this will keep running forever. Is nothing related to you work, is just the way enterprises work. Is nothing related to you offering this service, it can be another volunteer team, it will be the same. Regards, Jordi > De: Jeroen Massar > Organizaci?n: Unfix > Responder a: > Fecha: Sat, 02 Jun 2007 21:02:26 +0100 > Para: > CC: > Asunto: Re: [ppml] Keeping the story straight > > JORDI PALET MARTINEZ wrote: >> Unfortunately volunteers offering a service can't be trusted by >> organizations, as the service can vanish and then you're in trouble. > > Ehmm. Hold on there for a few seconds. That subject really doesn't > match the content, but lets make it match quite a bit more. > > Are you implying that SixXS can't be trusted!? I am really wondering > what you are trying to imply with that statement. > > Did you notice that http://www.sixxs.net/tools/grh/ula/ contains a > list of all the allocations that have been made? (inet6num.txt) > Do you realize that that list is VERY easy to mirror. > Do you realize that that list is nicely mirrored into Google and > various other crawler bots who crawl the web? > > Claiming that it can 'vanish' is just pathetic. SixXS won't 'vanish', > there are too many people very happily using the services that it > provides, and actually we are more than enjoying ourselves in > providing the various great services that it provides to the > community. Neither Pim or I have any intentions of letting the project > vanish. As long as people have a need for free help in getting IPv6 > going in their organizations we are ready to assist them with the help > and experience that we can provide them. > > I've also stated, but I'll do it again, that if/when one of the > RIR/IETF/IANA has a registry for these things that we can provide them > with the current list, and redirect the page to that resource. > Those are the 'authoritive' places, and we play in that game. > > Next to that, you are definitely mixing up ULA-C with normal ULA's. > Normal ULA's, according to RFC4193 don't have any registered part. > ULA-C's are not accepted by the registry we run, which is not so > strange as there is no RFC covering fc00::/8. The ULA registry that > currently is at http://www.sixxs.net/tools/grh/ula/ allows people > merely to register their ULA's so that it might decrease the chance of > collisions a little bit more. > >> Sorry, but this ULA-Central need a serious proven and stable service > > And are you implying here that SixXS is not a proven and not stable > service? > > I do sincerely hope that you are not trying to insult all the hard > work that has gone and more that will go into into this project by a > lot of people and several great companies that have been supporting > this project for the last couple of years. I feel _very_ insulted by > the statements you are making here and I really hope that you are > meaning something completely different. > > What are you going to claim next, that Team Cymru, who also are doing > great work, should not maintain bogon lists because they are not a > company? > >> and the RIRs are already doing so for other kinds of addresses.They are the >> perfect fit, and the alternative is IANA or a third party organization. > > How is SixXS not a "third party organization"? > >> Of course, if the community prefers going that way and have a third party >> organizations running that registry, I'm fine and all will pay the >> consequences sooner or later. > > Sorry, but all of this coming from someone who is abusing his > "Experimental IPv6 Allocation", thus avoiding paying of LIR fees, so > that it can be used to do an "Experimental IPv6 ISP Service" as you > described it last week on these lists, sounds really really bad. > > Greets, > Jeroen > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From JOHN at egh.com Sat Jun 2 22:50:45 2007 From: JOHN at egh.com (John Santos) Date: Sat, 2 Jun 2007 22:50:45 -0400 Subject: [ppml] Keeping the story straight In-Reply-To: Message-ID: <1070602222550.386B-100000@Ives.egh.com> On Sun, 3 Jun 2007, JORDI PALET MARTINEZ wrote: > Hi Jeroen, > > Is nothing personal. I can trust you, many people can trust many volunteer > services, but for something that big enterprises need to have the security > of a 0% collision chances, they will not trust a volunteer service. There is > NO warrantee for them that this will keep running forever. I don't see why it is necessary that it run forever. If enterprise A and Enterprise B and Enterprise C all register unique addresses with SixXS' server, SixXS could vanish into the great bit bucket 5 seconds later, and there would still never be a collision between A, B or C. If Enterprises D and E created their own ULA addresses and did not register with SixXS, then there is no guarantee there won't be a collision between D and A, B, C or E, or between E and A, B, C or D, whether or not SixXS continues to exist. The only difference if SixXS goes away and A wants to interconnect with D or E, they will have to use other means to verify uniqueness (like ask each other what addresses they are using.) This is exactly the current state of affairs without SixXS. For as long as SixXS continues to exist, D and E would have the option of registering with it, and ensuring uniqueness (but possibly having to renumber if they have already used colliding ULAs.) If SixXS goes away, they would no longer have this option, but this could not suddenly cause A, B or C to collide with each other. Neither Enterprise A nor B nor C needs any promise that SixXS will continue to exist after they register with it to know they are still unique within the set of SixXS' registerees. (Unless of course they want to register *additional* ULA space, which puts them in the same position as D & E with respect to the new space but doesn't affect the existing space.) > > Is nothing related to you work, is just the way enterprises work. > > Is nothing related to you offering this service, it can be another volunteer > team, it will be the same. > > Regards, > Jordi > > > > > > De: Jeroen Massar > > Organizaci?n: Unfix > > Responder a: > > Fecha: Sat, 02 Jun 2007 21:02:26 +0100 > > Para: > > CC: > > Asunto: Re: [ppml] Keeping the story straight > > > > JORDI PALET MARTINEZ wrote: > >> Unfortunately volunteers offering a service can't be trusted by > >> organizations, as the service can vanish and then you're in trouble. > > > > Ehmm. Hold on there for a few seconds. That subject really doesn't > > match the content, but lets make it match quite a bit more. > > > > Are you implying that SixXS can't be trusted!? I am really wondering > > what you are trying to imply with that statement. > > > > Did you notice that http://www.sixxs.net/tools/grh/ula/ contains a > > list of all the allocations that have been made? (inet6num.txt) > > Do you realize that that list is VERY easy to mirror. > > Do you realize that that list is nicely mirrored into Google and > > various other crawler bots who crawl the web? > > > > Claiming that it can 'vanish' is just pathetic. SixXS won't 'vanish', > > there are too many people very happily using the services that it > > provides, and actually we are more than enjoying ourselves in > > providing the various great services that it provides to the > > community. Neither Pim or I have any intentions of letting the project > > vanish. As long as people have a need for free help in getting IPv6 > > going in their organizations we are ready to assist them with the help > > and experience that we can provide them. > > > > I've also stated, but I'll do it again, that if/when one of the > > RIR/IETF/IANA has a registry for these things that we can provide them > > with the current list, and redirect the page to that resource. > > Those are the 'authoritive' places, and we play in that game. > > > > Next to that, you are definitely mixing up ULA-C with normal ULA's. > > Normal ULA's, according to RFC4193 don't have any registered part. > > ULA-C's are not accepted by the registry we run, which is not so > > strange as there is no RFC covering fc00::/8. The ULA registry that > > currently is at http://www.sixxs.net/tools/grh/ula/ allows people > > merely to register their ULA's so that it might decrease the chance of > > collisions a little bit more. > > > >> Sorry, but this ULA-Central need a serious proven and stable service > > > > And are you implying here that SixXS is not a proven and not stable > > service? > > > > I do sincerely hope that you are not trying to insult all the hard > > work that has gone and more that will go into into this project by a > > lot of people and several great companies that have been supporting > > this project for the last couple of years. I feel _very_ insulted by > > the statements you are making here and I really hope that you are > > meaning something completely different. > > > > What are you going to claim next, that Team Cymru, who also are doing > > great work, should not maintain bogon lists because they are not a > > company? > > > >> and the RIRs are already doing so for other kinds of addresses.They are the > >> perfect fit, and the alternative is IANA or a third party organization. > > > > How is SixXS not a "third party organization"? > > > >> Of course, if the community prefers going that way and have a third party > >> organizations running that registry, I'm fine and all will pay the > >> consequences sooner or later. > > > > Sorry, but all of this coming from someone who is abusing his > > "Experimental IPv6 Allocation", thus avoiding paying of LIR fees, so > > that it can be used to do an "Experimental IPv6 ISP Service" as you > > described it last week on these lists, sounds really really bad. > > > > Greets, > > Jeroen > > > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From jordi.palet at consulintel.es Sun Jun 3 04:17:47 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 03 Jun 2007 10:17:47 +0200 Subject: [ppml] Keeping the story straight In-Reply-To: <1070602222550.386B-100000@Ives.egh.com> Message-ID: That's why it is needed ULA-Central, in the sense of a prefix that *requires* registration in a central registry, so never there is a clash. If a company uses ULA-Central w/o going to the registry, in case of a clash that company will be in trouble because did the wrong thing. Having a volunteer registry service for ULA doesn't mandate everyone to register, and thus, nobody is doing wrong: it creates the wrong impression that you're safe, but not really, because it is not part of the "protocol". Regards, Jordi > De: John Santos > Responder a: > Fecha: Sat, 2 Jun 2007 22:50:45 -0400 > Para: JORDI PALET MARTINEZ > CC: > Asunto: Re: [ppml] Keeping the story straight > > On Sun, 3 Jun 2007, JORDI PALET MARTINEZ wrote: > >> Hi Jeroen, >> >> Is nothing personal. I can trust you, many people can trust many volunteer >> services, but for something that big enterprises need to have the security >> of a 0% collision chances, they will not trust a volunteer service. There is >> NO warrantee for them that this will keep running forever. > > I don't see why it is necessary that it run forever. If enterprise A > and Enterprise B and Enterprise C all register unique addresses with > SixXS' server, SixXS could vanish into the great bit bucket 5 > seconds later, and there would still never be a collision between A, > B or C. > > If Enterprises D and E created their own ULA addresses and did not register > with SixXS, then there is no guarantee there won't be a collision between > D and A, B, C or E, or between E and A, B, C or D, whether or not SixXS > continues to exist. The only difference if SixXS goes away and A wants > to interconnect with D or E, they will have to use other means to verify > uniqueness (like ask each other what addresses they are using.) This is > exactly the current state of affairs without SixXS. For as long as SixXS > continues to exist, D and E would have the option of registering with it, > and ensuring uniqueness (but possibly having to renumber if they have > already used colliding ULAs.) If SixXS goes away, they would no longer > have this option, but this could not suddenly cause A, B or C to collide > with each other. > > Neither Enterprise A nor B nor C needs any promise that SixXS will continue > to exist after they register with it to know they are still unique > within the set of SixXS' registerees. (Unless of course they want to > register *additional* ULA space, which puts them in the same position > as D & E with respect to the new space but doesn't affect the existing > space.) > >> >> Is nothing related to you work, is just the way enterprises work. >> >> Is nothing related to you offering this service, it can be another volunteer >> team, it will be the same. >> >> Regards, >> Jordi >> >> >> >> >>> De: Jeroen Massar >>> Organizaci?n: Unfix >>> Responder a: >>> Fecha: Sat, 02 Jun 2007 21:02:26 +0100 >>> Para: >>> CC: >>> Asunto: Re: [ppml] Keeping the story straight >>> >>> JORDI PALET MARTINEZ wrote: >>>> Unfortunately volunteers offering a service can't be trusted by >>>> organizations, as the service can vanish and then you're in trouble. >>> >>> Ehmm. Hold on there for a few seconds. That subject really doesn't >>> match the content, but lets make it match quite a bit more. >>> >>> Are you implying that SixXS can't be trusted!? I am really wondering >>> what you are trying to imply with that statement. >>> >>> Did you notice that http://www.sixxs.net/tools/grh/ula/ contains a >>> list of all the allocations that have been made? (inet6num.txt) >>> Do you realize that that list is VERY easy to mirror. >>> Do you realize that that list is nicely mirrored into Google and >>> various other crawler bots who crawl the web? >>> >>> Claiming that it can 'vanish' is just pathetic. SixXS won't 'vanish', >>> there are too many people very happily using the services that it >>> provides, and actually we are more than enjoying ourselves in >>> providing the various great services that it provides to the >>> community. Neither Pim or I have any intentions of letting the project >>> vanish. As long as people have a need for free help in getting IPv6 >>> going in their organizations we are ready to assist them with the help >>> and experience that we can provide them. >>> >>> I've also stated, but I'll do it again, that if/when one of the >>> RIR/IETF/IANA has a registry for these things that we can provide them >>> with the current list, and redirect the page to that resource. >>> Those are the 'authoritive' places, and we play in that game. >>> >>> Next to that, you are definitely mixing up ULA-C with normal ULA's. >>> Normal ULA's, according to RFC4193 don't have any registered part. >>> ULA-C's are not accepted by the registry we run, which is not so >>> strange as there is no RFC covering fc00::/8. The ULA registry that >>> currently is at http://www.sixxs.net/tools/grh/ula/ allows people >>> merely to register their ULA's so that it might decrease the chance of >>> collisions a little bit more. >>> >>>> Sorry, but this ULA-Central need a serious proven and stable service >>> >>> And are you implying here that SixXS is not a proven and not stable >>> service? >>> >>> I do sincerely hope that you are not trying to insult all the hard >>> work that has gone and more that will go into into this project by a >>> lot of people and several great companies that have been supporting >>> this project for the last couple of years. I feel _very_ insulted by >>> the statements you are making here and I really hope that you are >>> meaning something completely different. >>> >>> What are you going to claim next, that Team Cymru, who also are doing >>> great work, should not maintain bogon lists because they are not a >>> company? >>> >>>> and the RIRs are already doing so for other kinds of addresses.They are the >>>> perfect fit, and the alternative is IANA or a third party organization. >>> >>> How is SixXS not a "third party organization"? >>> >>>> Of course, if the community prefers going that way and have a third party >>>> organizations running that registry, I'm fine and all will pay the >>>> consequences sooner or later. >>> >>> Sorry, but all of this coming from someone who is abusing his >>> "Experimental IPv6 Allocation", thus avoiding paying of LIR fees, so >>> that it can be used to do an "Experimental IPv6 ISP Service" as you >>> described it last week on these lists, sounds really really bad. >>> >>> Greets, >>> Jeroen >>> >> >> >> >> >> ********************************************** >> The IPv6 Portal: http://www.ipv6tf.org >> >> Bye 6Bone. Hi, IPv6 ! >> http://www.ipv6day.org >> >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the use of the >> individual(s) named above. If you are not the intended recipient be aware >> that any disclosure, copying, distribution or use of the contents of this >> information, including attached files, is prohibited. >> >> >> >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml >> >> > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From martin.hannigan at batelnet.bs Sun Jun 3 05:04:36 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Sun, 03 Jun 2007 05:04:36 -0400 Subject: [ppml] Keeping the story straight Message-ID: <46628424.13a.1dac.32130@batelnet.bs> ----- Original Message ----- From: Randy Bush To: Jeroen Massar Cc: ppml at arin.net Subject: Re: [ppml] Keeping the story straight Date: Sat, 02 Jun 2007 13:04:55 -0700 > Jeroen Massar wrote: > > JORDI PALET MARTINEZ wrote: > >> Unfortunately volunteers offering a service can't be > trusted by >> organizations, as the service can vanish and > then you're in trouble. > > then stop using root servers Or better yet, run your own. -M< From Crumb_Anthony_A at cat.com Mon Jun 4 07:08:31 2007 From: Crumb_Anthony_A at cat.com (Anthony A. Crumb) Date: Mon, 4 Jun 2007 06:08:31 -0500 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <12093.1180450716@sa.vix.com> Message-ID: ppml-bounces at arin.net wrote on 05/29/2007 09:58:36 AM: > > > - IPv6 space is not infinite. It's a 64-72 bit address space. That's > > right, subnets with > 256 hosts are very uncommon today, so we've wasted > > 64 bits to number 256 things. That makes the space effectively on the > > long end 72 bits. > > according to , i gave a talk > entitled "DHCPv6 - The Case Against Stateless Autoconfig" at NAV6TF'2005. > > according to , there's > now code in "alpha test release" status to handle DHCPv6. > > imho, the days of EUI64 are numbered. at home i'll probably use a /120 for > each LAN. at work, we might splurge and use /96's. not that a /56 isn't > enough for my house or anything, i just want the sparseful wastitude of the > new address bits in IPV6 to all be at the top end. i'm using a /124 for my > T1, mostly to make the PTR's easy to write and read. I agree that requireing the use of 64 bits for interface identifiers is a monumental waste of address space. Is there a proposal of any type to change the requirement to use EUI64 interface identifiers with globally routable PI address space? > > > But more importantly, we have the T-Shirt from this exercise. > > Back in the 80's we gave out Class A's. It was the right thing > > to do. > > was it? DEC got 16.0.0.0/8 on the basis of having 130000 employees and > something like 10000 offices. they turned in five class B's to get the A. > does anybody here think that DEC needed a class A by ARIN's current > standards? this was a post-subnet, post-CIDR allocation. > > > I predict with the current allocation procedures IPv6 will be > > "used up" in my lifetime. I also predict the groups today getting > > /32's (and larger) will look like the legacy class A holders in > > 20 years time. When your doorknob automatically requests a ULA-C > > /64 when you bring it home, and your house has 2,000 of them as every > > individual system talks to each other we'll be looking at this quite > > differently. > > i include this only so that i can say, i nearly agree. unless we have an > IP architecture that splits EID/RID, those doorknobs will not be globally > reachable. (not that this is a problem for doorknobs but it might be for > microwave ovens or something.) > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lee.Howard at stanleyassociates.com Mon Jun 4 11:32:06 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 4 Jun 2007 11:32:06 -0400 Subject: [ppml] rubber/road In-Reply-To: Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40603935A@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Sent: Thursday, May 31, 2007 8:12 PM > To: Jeroen Massar > Cc: Randy Bush; Public Policy Mailing List > Subject: Re: [ppml] rubber/road > > > > >-----Original Message----- > >From: Jeroen Massar [mailto:jeroen at unfix.org] > >Sent: Thursday, May 31, 2007 4:05 PM > >To: Ted Mittelstaedt > >Cc: Randy Bush; Public Policy Mailing List > >Subject: Re: [ppml] rubber/road > > > > > >Ted Mittelstaedt wrote: > >[..] > >> In 2 years a policy could be submitted and approved that would > >> radically raise prices on the IPv6 block and require you > to pay for > >> both blocks. As long as both allocations > >> (IPv4 and IPv6) are separate, the fear of getting jacked > over in the > >> future is a real possibility. If you fear this, you should nominate, campaign for, and elect Board members who assuage your fear. > Once IPv4 space is no longer needed for routing on the > Internet, if the fees for IPv6 are practically nothing, how > exactly is ARIN going to stay in business? Selling peat? Is that a real fear? I plan to do whatever I legally and ethically can to protect the mission of ARIN. > Ted Lee From Paul_Vixie at isc.org Mon Jun 4 11:44:23 2007 From: Paul_Vixie at isc.org (Paul_Vixie at isc.org) Date: Mon, 04 Jun 2007 15:44:23 +0000 Subject: [ppml] rubber/road In-Reply-To: Your message of "Mon, 04 Jun 2007 11:32:06 -0400." <369EB04A0951824ABE7D8BAC67AF9BB40603935A@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40603935A@CL-S-EX-1.stanleyassociates.com> Message-ID: <90670.1180971863@sa.vix.com> > > >> In 2 years a policy could be submitted and approved that would > > >> radically raise prices on the IPv6 block and require you to pay for > > >> both blocks. As long as both allocations (IPv4 and IPv6) are separate, > > >> the fear of getting jacked over in the future is a real possibility. > > If you fear this, you should nominate, campaign for, and elect > Board members who assuage your fear. will there be a litmus test, then? > > Once IPv4 space is no longer needed for routing on the Internet, if the > > fees for IPv6 are practically nothing, how exactly is ARIN going to stay > > in business? Selling peat? > > Is that a real fear? I plan to do whatever I legally and > ethically can to protect the mission of ARIN. same here. and i don't think that mission ends when the last IPv4 block is handed out, nor when everbody who wants one at the time has their IPv6 block. that banner again, from www.arin.net, reads: Applying the principles of stewardship, ARIN, a nonprofit corporation, allocates Internet Protocol resources; develops consensus-based policies; and facilitates the advancement of the Internet through information and educational outreach. i'm not sure how i can see a path toward that mission that can ever include radical fee hikes on IPv6. (unless you're dividing by zero by failing to take account of the current IPv6 fee waiver.) From paul at vix.com Mon Jun 4 11:56:23 2007 From: paul at vix.com (Paul Vixie) Date: Mon, 04 Jun 2007 15:56:23 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Your message of "Mon, 04 Jun 2007 06:08:31 EST." References: Message-ID: <91451.1180972583@sa.vix.com> > I agree that requireing the use of 64 bits for interface identifiers is a > monumental waste of address space. Is there a proposal of any type to change > the requirement to use EUI64 interface identifiers with globally routable PI > address space? no. but as someone else here has said, "the ietf is whoever shows up at the meetings or joins the mailing lists or writes internet drafts." so anyone here who wanted to propose a /112 DHCPv6 alternative to EUI64 can just do it. (of course, all that will do is expose more definitively that the resource we actually have to watch out for is routing table size, both in the DFZ and in smaller internets, and show the absurdity of arguing /56 vs. /48 for homes.) From randy at psg.com Mon Jun 4 12:08:04 2007 From: randy at psg.com (Randy Bush) Date: Mon, 04 Jun 2007 09:08:04 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <91451.1180972583@sa.vix.com> References: <91451.1180972583@sa.vix.com> Message-ID: <466438E4.8050101@psg.com> > no. but as someone else here has said, "the ietf is whoever shows up at the > meetings or joins the mailing lists or writes internet drafts." so anyone > here who wanted to propose a /112 DHCPv6 alternative to EUI64 can just do it. good luck. i managed to get rid of TLAs etc. get tvtf out of policy, /48, /56, ... but EU164 is infinitely more religious. randy From paul at vix.com Mon Jun 4 12:20:12 2007 From: paul at vix.com (Paul Vixie) Date: Mon, 04 Jun 2007 16:20:12 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Your message of "Mon, 04 Jun 2007 09:08:04 MST." <466438E4.8050101@psg.com> References: <91451.1180972583@sa.vix.com> <466438E4.8050101@psg.com> Message-ID: <93228.1180974012@sa.vix.com> > good luck. i managed to get rid of TLAs etc. get tvtf out of policy, > /48, /56, ... but EU164 is infinitely more religious. TLA's are dead. 8+8 is dead. A6/DNAME is dead. EUI64 can also die. i realized recently that if IPng was going to just be IPv4 with larger addresses, then we didn't need flow labels or any of that other stuff, and we could have reused the IPv4 ethertype and framing, just revved the version number field and defined 128 bit src/dst and been able to implement and deploy it in a year. (and many people suggested this at the time, though none of them said "this is how we ought to do it since it's how we'll end up doing it ever after we define all this other crud.") From jeroen at unfix.org Mon Jun 4 12:53:32 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 04 Jun 2007 17:53:32 +0100 Subject: [ppml] Those pesky EUI-64's causing a shortage of IPv6 space (Was: [address-policy-wg] Those pesky ULAs again) In-Reply-To: <91451.1180972583@sa.vix.com> References: <91451.1180972583@sa.vix.com> Message-ID: <4664438C.7020907@spaghetti.zurich.ibm.com> Paul Vixie wrote: >> I agree that requireing the use of 64 bits for interface identifiers is a >> monumental waste of address space. Is there a proposal of any type to change >> the requirement to use EUI64 interface identifiers with globally routable PI >> address space? > > no. but as someone else here has said, "the ietf is whoever shows up at the > meetings or joins the mailing lists or writes internet drafts." so anyone > here who wanted to propose a /112 DHCPv6 alternative to EUI64 can just do it. [not directed at Paul actually, but already *d* the other message ;) ] But why would anybody want to 'ban' EUI-64 configured addresses? Your own network is exactly that: your own network. There is *NO* requirement at all to use EUI-64. The only semi-requirement that is there for EUI-64 is that the link-local addresses use it. Well, I do sincerely hope that everybody can live with that part. Everything which is on your local network you can specify yourself. Don't want to use RA's? Then don't, your choice. Want to use DHCPv6, then please do! Want to use /112's? Then do it. It is your network, nobody can and will stop you from doing so. As long as when the packet leaves your site it is compliant to the IPv6 standard and has a proper IPv6 source address in your prefix, everything will work fine. How you handle the routing at your end, how you have subnetted everything together, see if anybody else on this planet cares ;) The only real, change I see coming in the IPv6 specs are the /48 boundary. For companies this is fine, it is most likely a fit all for 90%+ of the companies out there and having a single fit is great. But when you have 20m, home, subscribers a /48 will never be filled and a /56 (still 256 /64's of space, which you can still split up to /112's with DHCP or whatever size you might find comfy etc) will be a more adequate size, that is if we are going to consider that it is a waste of space. Then again, on the other side, there are 536870912 (500 million) /32's in 2000::/3 alone. Which will really not easily fit in any routing table of any sort (but please prove me wrong ;) Oh and when 2000::/3 is full, we can always pick one of the other 7 /3's which are not being used yet and 'try again'. Enough for even my kids their kids and their to play with. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From Paul_Vixie at isc.org Mon Jun 4 13:15:47 2007 From: Paul_Vixie at isc.org (Paul_Vixie at isc.org) Date: Mon, 04 Jun 2007 17:15:47 +0000 Subject: [ppml] Those pesky EUI-64's causing a shortage of IPv6 space (Was: [address-policy-wg] Those pesky ULAs again) In-Reply-To: Your message of "Mon, 04 Jun 2007 17:53:32 +0100." <4664438C.7020907@spaghetti.zurich.ibm.com> References: <91451.1180972583@sa.vix.com> <4664438C.7020907@spaghetti.zurich.ibm.com> Message-ID: <1678.1180977347@sa.vix.com> > But why would anybody want to 'ban' EUI-64 configured addresses? because if it remains in the standard, then everybody will have to support it and networks will have to be allocated on /64 boundaries for all of the yet-unborn IPv6 capable SNMP-monitorable door knobs. > Then again, on the other side, there are 536870912 (500 million) /32's in > 2000::/3 alone. Which will really not easily fit in any routing table of any > sort (but please prove me wrong ;) > > Oh and when 2000::/3 is full, we can always pick one of the other 7 /3's > which are not being used yet and 'try again'. Enough for even my kids their > kids and their to play with. agreed, and this is why i consider ULA to be a silly idea. since we have more IPv6 space than we can ever route, why would we mark any allocations unroutable, even if we know what "routable" meant? i can see a need for policy around giving each minimum allocation size its own IPv6 address range, so that those of us who only want to accept TE routes from our peers, can filter them out of our transit tables. but i cannot understand why we would declare that some allocations were never supposed to come into the DFZ (breidbart's "the internet") at all, given that there's no way we could ever route all the /32's we could allocate. From Dan.Thorson at seagate.com Mon Jun 4 13:25:37 2007 From: Dan.Thorson at seagate.com (Dan.Thorson at seagate.com) Date: Mon, 4 Jun 2007 12:25:37 -0500 Subject: [ppml] Those pesky EUI-64's causing a shortage of IPv6 space (Was: [address-policy-wg] Those pesky ULAs again) In-Reply-To: <4664438C.7020907@spaghetti.zurich.ibm.com> Message-ID: Jeroen Massar said: > > But why would anybody want to 'ban' EUI-64 configured addresses? > > Your own network is exactly that: your own network. > > There is *NO* requirement at all to use EUI-64. [snip] OK, here's where I may express my ignorance... but RFC2373 explicitly states: (in section 2.4, just after the table of prefix allocations) (2) The format prefixes 001 through 111, except for Multicast Addresses (1111 1111), are all required to have to have 64-bit interface identifiers in EUI-64 format. See section 2.5.1 for definitions. To me that sounds like there is indeed a requirement to use EUI-64. The issue then becomes if you purchase a device which is RFC-complient then it may not support non-EUI-64 addressing. Right? danT From jeroen at unfix.org Mon Jun 4 13:50:04 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 04 Jun 2007 18:50:04 +0100 Subject: [ppml] Those pesky EUI-64's causing a shortage of IPv6 space (Was: Those pesky ULAs again) In-Reply-To: <1678.1180977347@sa.vix.com> References: <91451.1180972583@sa.vix.com> <4664438C.7020907@spaghetti.zurich.ibm.com> <1678.1180977347@sa.vix.com> Message-ID: <466450CC.901@spaghetti.zurich.ibm.com> [two-reply-in-one-special-bonus-shortcut-message] Paul_Vixie at isc.org wrote: >> But why would anybody want to 'ban' EUI-64 configured addresses? > > because if it remains in the standard, then everybody will have to support > it and networks will have to be allocated on /64 boundaries for all of the > yet-unborn IPv6 capable SNMP-monitorable door knobs. [..rest snipped as we agreed there ;).. ] We are starting to get into an IETF thing here and not policy anymore I guess. Though if a /64 boundary doesn't exist any more, then the HD ratio fails through and we have to revise all the policies and the 1000 odd existing allocations about this. So I understand correctly here that you are afraid that IPv6 enabled sensors in your carpet will only be relying on a /64 RA to be available? Unfortunately there is no RA for non-/64 spaces defined, one could easily generate a shorter address using the same mechanism and cutting it down and doing DAD or using the mechanism used for IPv4 link local addresses (yes, IPv4 has that to nothing special in IPv6 :) A possibly better way to solve that problem is to require the support for DHCPv6 in all nodes, or have at least a sticker on the box "DHCPv6 supported" so that you know what to expect. The DHCPv6 request will go over a /64 LL of course. Also in case you come across such a device you can always special case that subnet and give it a /64 out of the 65k ones you get for a site. Dan.Thorson at seagate.com wrote: > Jeroen Massar said: >> But why would anybody want to 'ban' EUI-64 configured addresses? >> >> Your own network is exactly that: your own network. >> >> There is *NO* requirement at all to use EUI-64. > [snip] > > OK, here's where I may express my ignorance... but RFC2373 > explicitly states: > (in section 2.4, just after the table of prefix allocations) > > (2) The format prefixes 001 through 111, except for Multicast > Addresses (1111 1111), are all required to have to have 64-bit > interface identifiers in EUI-64 format. See section 2.5.1 for > definitions. I always read that "when using a /64 prefix size you have to use EUI-64". One of the main reasons for EUI-64 is that it is more or less collision free. When using RA's, which will be the common case when using a network sized /64 you don't want these collisions. Also I don't see a MUST there so I don't see a real requirement. A bigger question in this are actually is, what space do you save with it? It is indeed a lot of waste when you only have 2 IP addresses (box + gateway) on a link which will never ever have more IP addresses on that link, but does it matter much in the global picture. When you get a /48, you have 65536 of such links. When you get a /32 you get a well, IPv4 space sized amount of of them. So does it really hurt? IMHO using /64's is not a bad thing. If you don't want to use them, then, as said, don't. > To me that sounds like there is indeed a requirement to use EUI-64. > The issue then becomes if you purchase a device which is > RFC-complient then it may not support non-EUI-64 addressing. Right? RFC-compliant is always a fight of interpretation. The standard is the one that everybody uses. At the moment that means that everybody picks for themselves, as such the standard is both. My ISP for instance also gave me a an IPv6 IP for my DSL link out of a /80. This simply for management purposes. They did route a /48 to the endpoint and point DNS for the /48 it to my endpoint though: eth1 Link encap:Ethernet HWaddr 08:00:2B:E7:02:B3 inet addr:213.136.24.43 Mask:255.255.255.0 inet6 addr: 2001:7b8:5:10:74::2/80 Scope:Global inet6 addr: fe80::a00:2bff:fee7:2b3/64 Scope:Link The LinkLocal is a /64 though, and that is used as the nexthop: PING ff02::1(ff02::1) from fe80::a00:2bff:fee7:2b3 eth1: 56 data bytes 64 bytes from fe80::a00:2bff:fee7:2b3: icmp_seq=1 ttl=64 time=0.032 ms 64 bytes from fe80::202:4aff:fe8a:a000: icmp_seq=1 ttl=64 time=18.3 ms (DUP!) Which, if you know how EUI-64 works, shows that at least Vendor C doesn't care about this. Which is at least one very large chunk of deployed routers. And that works like a charm (thank you very much venerate BIT.nl :) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From Paul_Vixie at isc.org Mon Jun 4 14:10:03 2007 From: Paul_Vixie at isc.org (Paul_Vixie at isc.org) Date: Mon, 04 Jun 2007 18:10:03 +0000 Subject: [ppml] Those pesky EUI-64's causing a shortage of IPv6 space (Was: Those pesky ULAs again) In-Reply-To: Your message of "Mon, 04 Jun 2007 18:50:04 +0100." <466450CC.901@spaghetti.zurich.ibm.com> References: <91451.1180972583@sa.vix.com> <4664438C.7020907@spaghetti.zurich.ibm.com> <1678.1180977347@sa.vix.com> <466450CC.901@spaghetti.zurich.ibm.com> Message-ID: <8099.1180980603@sa.vix.com> > We are starting to get into an IETF thing here and not policy anymore ... IETF and ARIN PPML is a lot of the same people. and the relationship between policy and technology is more of a feedback loop than producerish/consumerish. > So I understand correctly here that you are afraid that IPv6 enabled sensors > in your carpet will only be relying on a /64 RA to be available? well, yes, but i'm more concerned about the fact that IETF killed off every other IPv6 addressing paradigm that turned out badly, but didn't kill EUI64 (yet?). i'm not so much bitter about the favouritism as i am concerned that IETF has chosen the wrong (painful) things to have any spinal rigidity about. so if EUI64 isn't going to be killed we all need to know that since a future carpet sensor will need it and ARIN's policies have to assume /64 LANs even though DHCPv6 is going to be more common and doesn't need /64's; or if EUI64 is going to be killed then can it please be killed quickly so that we don't give home users /48's or /56's when /108's would have been quite enough? > A possibly better way to solve that problem is to require the support > for DHCPv6 in all nodes, or have at least a sticker on the box "DHCPv6 > supported" so that you know what to expect. The DHCPv6 request will go > over a /64 LL of course. Also in case you come across such a device > you can always special case that subnet and give it a /64 out of the > 65k ones you get for a site. i love the sound of that plan. be sure to post the I-D URL here :-). > A bigger question in this are actually is, what space do you save with it? address bits on the CAM in wireless routers. > IMHO using /64's is not a bad thing. If you don't want to use them, > then, as said, don't. this is probably the reason why IETF hasn't killed EUI64. "since we're going to have to use it for LL, and we've got way more bits than we could ever route for, there's no reason not to waste this space in this way." > My ISP for instance also gave me a an IPv6 IP for my DSL link out of a > /80. This simply for management purposes. They did route a /48 to the > endpoint and point DNS for the /48 it to my endpoint though: > > eth1 Link encap:Ethernet HWaddr 08:00:2B:E7:02:B3 > inet addr:213.136.24.43 Mask:255.255.255.0 > inet6 addr: 2001:7b8:5:10:74::2/80 Scope:Global > inet6 addr: fe80::a00:2bff:fee7:2b3/64 Scope:Link > > The LinkLocal is a /64 though, and that is used as the nexthop: you raise the interesting possibility that rather than NAT, IPv6 will use some kind of overlay scheme where only LL has broadcast, and everything else uses some RARP-like thing on a /128 per endpoint out of /80 pools. but while this is interesting for lab rats, i don't think it works at home. From jmorrison at bogomips.com Mon Jun 4 15:33:28 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Mon, 04 Jun 2007 12:33:28 -0700 Subject: [ppml] Those pesky EUI-64's causing a shortage of IPv6 space (Was: [address-policy-wg] Those pesky ULAs again) In-Reply-To: <1678.1180977347@sa.vix.com> References: <91451.1180972583@sa.vix.com> <4664438C.7020907@spaghetti.zurich.ibm.com> <1678.1180977347@sa.vix.com> Message-ID: <46646908.7040404@bogomips.com> A good example where EUI64 is needed or at least plausible. Setting manual addresses on your IPv6 door-knobs makes as much sense as setting jumpers and DIP switches for SCSI disk drive numbers. The embedded realm is a huge territory for leveraging IP instead of inventing new protocols. It's also an area where the IP components may not even be visible to the consumer unless you look under the hood. You want DHCP for your IPv6 door knobs? Probably a good feature, but maybe auto-registering with manufacturer installed certificates and well known addresses is better, and the EUI64 happens to be your S/N so you can correlate your asset tags, support contracts and inventory. Similar processes exist for IP phones and lightweight (centrally managed) wireless access points, although are IPv4/DHCP based. But do you also want DHCP (static?) for the IPv6 link between the IPv6 door knob's optical handle rotation sensors and the actuators controlling the latch movement and tactile feedback? Where does it stop? These are "silly" examples, but technology keeps creeping up and making them reality. Paul_Vixie at isc.org wrote: >> But why would anybody want to 'ban' EUI-64 configured addresses? >> > > because if it remains in the standard, then everybody will have to support > it and networks will have to be allocated on /64 boundaries for all of the > yet-unborn IPv6 capable SNMP-monitorable door knobs. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloch at kl.net Mon Jun 4 15:42:51 2007 From: kloch at kl.net (Kevin Loch) Date: Mon, 04 Jun 2007 15:42:51 -0400 Subject: [ppml] Those pesky EUI-64's causing a shortage of IPv6 space (Was: [address-policy-wg] Those pesky ULAs again) In-Reply-To: <46646908.7040404@bogomips.com> References: <91451.1180972583@sa.vix.com> <4664438C.7020907@spaghetti.zurich.ibm.com> <1678.1180977347@sa.vix.com> <46646908.7040404@bogomips.com> Message-ID: <46646B3B.7070400@kl.net> John Paul Morrison wrote: > > You want DHCP for your IPv6 door knobs? Do you care which doorknob you are monitoring/controlling? At some point you have to make the association between doorknob location/function and IP address. While doing that you may also find it convenient to choose a simple integer with lots of leading zeros. I may also need to tell the doorknob what tftp server to download it's configuration from (see: voip phones). So, yes I would want DHCP for my door knobs. - Kevin From jmorrison at bogomips.com Mon Jun 4 16:21:37 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Mon, 04 Jun 2007 13:21:37 -0700 Subject: [ppml] Those pesky EUI-64's causing a shortage of IPv6 space (Was: [address-policy-wg] Those pesky ULAs again) In-Reply-To: <46646B3B.7070400@kl.net> References: <91451.1180972583@sa.vix.com> <4664438C.7020907@spaghetti.zurich.ibm.com> <1678.1180977347@sa.vix.com> <46646908.7040404@bogomips.com> <46646B3B.7070400@kl.net> Message-ID: <46647451.7090905@bogomips.com> You miss the point. Of course you care which door-knob you're monitoring. You know which one you're monitoring because the locksmith told you the MAC address/EUI64 address or Serial number off the cardboard box, or maybe your campus wireless controllers triangulated the door-knob and told you its GPS coordinates. Before he told you, the door-knob registered itself securely (because the manufacturer installed a certificate in it) to a Door-knob Controlller/Management System. Then you logon to the management system, see the knew door-knob in the alerts list or unknown zones, matched it with the serial number (EUI64) where you were then able to type in the meaningful name of the location, security zones etc. That's the direction embedded systems are going. I've seen people complain about their EUI-64 IP address changing because their MAC address changes. Well how about the embedded certificates in that device? Those change too! Were you really going to secure your building based on some static IP addresses? You were really going to repair the "NIC" on your IP door-knob when it failed rather than replace it? DHCP can still hand out tftp addresses without handing out IP addresses, and DHCP isn't the only way to hand out server addresses - there are already well known addresses for IPv6 DNS, an embedded device might also be listening to a multicast/anycast address, or use proprietary methods. Kevin Loch wrote: > John Paul Morrison wrote: > >> You want DHCP for your IPv6 door knobs? >> > > Do you care which doorknob you are monitoring/controlling? At > some point you have to make the association between doorknob > location/function and IP address. While doing that you may > also find it convenient to choose a simple integer with > lots of leading zeros. > > I may also need to tell the doorknob what tftp server to download > it's configuration from (see: voip phones). > > So, yes I would want DHCP for my door knobs. > > - Kevin > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mack at exchange.alphared.com Tue Jun 5 19:15:04 2007 From: mack at exchange.alphared.com (mack) Date: Tue, 5 Jun 2007 18:15:04 -0500 Subject: [ppml] Those pesky EUI-64's causing a shortage of IPv6 Message-ID: <859D2283FD04CA44986CC058E06598F840F8B8F013@exchange4.exchange.alphared.local> EUI64 based on MAC addresses has a very specific format. Effectively it only uses 47 bits. There are 17 bits that are fixed with EUI64. That means you can safely assign subnets in the parallel space. As long as the 'local' bit of EUI64 is cleared, it isn't based on a MAC address. So we only have 127 bits, can't everyone live with that? BTW Vendor C ignores a portion of the IPv6 address in compressed mode. Specifically bits 39:24 are removed. Layer 4 information can only be used for filtering in compressed mode. This is a much bigger issue from a practical standpoint. This is going to limit real subnets to /87s for as long as the current hardware iteration is in place. See the above comment about EUI64 using one bit, otherwise it would be /88s. LR Mack McBride Network Administrator Alpha Red, Inc. From iljitsch at muada.com Wed Jun 6 07:31:41 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 6 Jun 2007 13:31:41 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <93228.1180974012@sa.vix.com> References: <91451.1180972583@sa.vix.com> <466438E4.8050101@psg.com> <93228.1180974012@sa.vix.com> Message-ID: <5D6CE572-92BD-4AC9-8EB0-10AB90597EE0@muada.com> On 4-jun-2007, at 18:20, Paul Vixie wrote: > TLA's are dead. 8+8 is dead. A6/DNAME is dead. EUI64 can also die. > i realized recently that if IPng was going to just be IPv4 with larger > addresses, then we didn't need flow labels or any of that other stuff, > and we could have reused the IPv4 ethertype and framing, just revved > the version number field and defined 128 bit src/dst and been able to > implement and deploy it in a year. Sure, it's the flow labels and the ethertype that people find too difficult to deal with so they're not deploying IPv6. Remind me, when were the DHCPv6 specs finished again? The big thing in IPv6 is the larger address size. All the other stuff is certainly interesting and we can discuss it to death, but if and when desired, it can be bolted onto IPv4 and you can translate between the old and the new IPv4 so no deployability issues (well, except overzealous firewalls, of course). The part that requires upgrading ALL hosts and routers is the increased address size. From jrhett at svcolo.com Wed Jun 6 19:00:36 2007 From: jrhett at svcolo.com (Jo Rhett) Date: Wed, 6 Jun 2007 16:00:36 -0700 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <1070531212803.19291A-100000@Ives.egh.com> References: <1070531212803.19291A-100000@Ives.egh.com> Message-ID: <03AD1790-8019-4384-91DB-30D66C980E51@svcolo.com> On May 31, 2007, at 6:40 PM, John Santos wrote: > All I'm saying is people should be entitled > to permanent IP addresses, for as long as they need them Think about this clearly. Where is this infinite resource coming from? 1. IP address space is limited although inexpensive. 2. Prefix slots in router memory are even more limited, and much more costly. Cost #1 is low and is paid once. Cost #2 is very high, and is paid by *EVERYONE* who is connected. Not together, but each individually. This isn't like raising taxes, where a tiny hike creates a lot of money. This is like asking every citizen to repurchase their home/ car/etc so that someone else can avoid thinking about their business model. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From jrhett at svcolo.com Wed Jun 6 19:11:10 2007 From: jrhett at svcolo.com (Jo Rhett) Date: Wed, 6 Jun 2007 16:11:10 -0700 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <1070531191229.386B-100000@Ives.egh.com> References: <1070531191229.386B-100000@Ives.egh.com> Message-ID: John, I'm a little confused by your math. 2000 customers * cost of changing IP addresses equals... $200 per customer if they have to pay an outside consultant to do it for them, usually less than $20 for inside help... Not a big number. $40,000 <=> $400,000 Cost of upgrading a single big iron box to have more routing table slots > $100,000 Multiply by the number of big iron boxes who can't use a default route, say at least 400? The only difference is who is paying for it, and who is gaining value for it. You want us to pay, so that your business can gain value. You do the math, and tell me again why I should be paying out of my pocket for your customer. You very well could have explicit instructions sent to the customers for IP address changes. You could very well purchase multiple IP ranges from different providers, and thus make the importance of any IP address change negliable. Or you could pay $49/month to get a second uplink and then qualify for PI space based on multi-homing. Every one of those options is trivially cheap and easy to implement. This is why I reject your desire to make our businesses pay hard cash so that your business can avoid building even the most trivial resiliance into your process. On May 31, 2007, at 4:39 PM, John Santos wrote: > It is the 2000 customers who would have to pay the cost. It may be > small for each, but its cumulative, and will certainly generating lots > of support calls back to Leroy's company. > > My company is in a similar situation to Leroy's customers. We have an > external mail filtering service. Our published MX records point to > the service, and they then forward the (filtered for spam, viruses, > RBL, etc.) mail to us, so we have had to open up our firewall to SMTP > from their specific IP addresses. We are certainly *not* going to let > them manage our firewalls for us, nor are we going to willy-nilly > change > our firewall rules on their request without minimally verifying the > origin of the request (a support call to them.) Multiply by several > thousand customers. > > If they were to start changing IP addresses frequently, we would start > looking for a new service provider. > > This is an *extremely* unlevel playing field, since ACME GIANT ASP, > INC. (which is many times the size of Leroy's company), could easily > justify an allocation, and thus could promise their customers that > their IP addresses and firewall rule would never change. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From jrhett at svcolo.com Wed Jun 6 19:16:37 2007 From: jrhett at svcolo.com (Jo Rhett) Date: Wed, 6 Jun 2007 16:16:37 -0700 Subject: [ppml] Revised Policy Proposal Resource Reclamation In-Reply-To: References: Message-ID: <43A27C64-F6BF-4229-8D32-5D27378C0B1C@svcolo.com> I would support this. I would also support dropping the limitations on Point d, such that all allocations are subject to audit. Frankly, I believe that if we invested the resources to audit all allocations, IPv4 exhaustion simply wouldn't occur for a much greater (4-6 year) period. How much money is that worth? On May 31, 2007, at 5:17 PM, Jason Schiller wrote: > Kevin, how about a possible middle ground: > > 2. ARIN may conduct such reviews: > a. when any new resource is requested, > b. whenever ARIN has cause to believe that the > resources had originally been obtained > fraudulently, > c. whenever ARIN has cause to believe that the > justification previously used is no longer > valid, or > d. if an orgization has not requested new > resources > within one year of their last reques, ARIN may > audit only the most recent allocation or > assignment. > > > Point c addresses Kevin's concern about the justification changing. > > Point d returns some of the origional flexibility of the policy to > allow > ARIN to conduct an audit. This can help limit abuse by allowing > followup > for orgizations that will not likely need additional resources. It > also > minamizes the amount of pain placed on large orgizations by > limiting the > audit to only the most recently allocated or assigned block. > > __Jason > > ====================================================================== > ==== > Jason Schiller (703) > 886.6648 > Senior Internet Network Engineer fax:(703) > 886.0512 > Public IP Global Network Engineering > schiller at uu.net > UUNET / Verizon > jason.schiller at verizonbusiness.com > > The good news about having an email address that is twice as long > is that > it increases traffic on the Internet. > > On Mon, 30 Apr 2007, Kevin - Your.Org wrote: > >> Date: Mon, 30 Apr 2007 18:19:03 -0500 >> From: Kevin - Your.Org >> To: Public Policy Mailing List , policy at arin.net >> Subject: Re: [ppml] Revised Policy Proposal Resource Reclamation >> >> >> On Apr 30, 2007, at 3:26 PM, Owen DeLong wrote: >>> 2. ARIN may conduct such reviews: >>> a. when any new resource is requested, >>> b. whenever ARIN has cause to believe that the resources had >>> originally been obtained fraudulently, or >>> c. at any other time without cause unless a prior review has >>> been completed in the preceding 12 months. >> >> >> I'm fine with A and B, but I can't say I support clause C in there as >> it's written. While I don't think anyone at ARIN is malicious or >> would conduct reviews unnecessarily, this strikes me as a blank check >> to get an undefined "audit" every year that would require furnishing >> arbitrary amounts of paperwork to comply. >> >> Getting paperwork and justification materials together when >> requesting additional space is a predictable cost that can be planned >> for in advance, and argued that it's necessary for business expansion >> or whatever. More space = more revenue, so it's an investment. And, >> the worst case that can happen there is you walk away no worse off >> than you started, if the expenses/time required exceed what it's >> worth to you. Especially for a small business where regular >> allocation requests aren't made, these costs can be significant. >> >> A random inspection is at least as much effort, more risk (you risk >> losing what you already have if you're unable to satisfy whatever >> undocumented requirements there are for this) so you're probably >> going to have to invest more time/money in making sure you get it >> right, and a money hole in terms of what you get out of it. >> >> I can only see three reasons why an audit would need to take place. >> You're asking for more space(you initiate this, you're planning for >> it in advance, and you can walk away if you get in over your head), >> you lied on your last application(all you would have to do is prove >> you didn't lie), or whatever justification you used in a previous >> application doesn't apply anymore(you've downsized and you really >> should be giving space back.) Are there any other reasons why an >> audit should take place, other than "because someone felt like it"? >> If not, spell that out. >> >> I'd support: >> >> 2. ARIN may conduct such reviews: >> a. when any new resource is requested, >> b. whenever ARIN has cause to believe that the resources had >> originally been obtained fraudulently, or >> c. whenever ARIN has cause to believe the justification for the >> resources no longer exists. >> >> Along with some kind of definition of exactly what a review entails, >> how much time you have to respond to one, can it be appealed, etc. As >> your proposal stands, it seems like ARIN can request arbitrary >> amounts of paperwork >> >> While I understand that several people's interpretations of the >> existing policy already gives ARIN the right to do this now, if we're >> going to enumerate this policy specifically, don't turn it into the >> ability to audit every organization every year without cause, with no >> definition of what an audit even is, how the procedure is supposed to >> work, or why you can get audited. >> >> -- Kevin >> >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml >> > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From owen at delong.com Wed Jun 6 19:24:37 2007 From: owen at delong.com (Owen DeLong) Date: Wed, 6 Jun 2007 16:24:37 -0700 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: References: <1070531191229.386B-100000@Ives.egh.com> Message-ID: On Jun 6, 2007, at 4:11 PM, Jo Rhett wrote: > John, I'm a little confused by your math. > > 2000 customers * cost of changing IP addresses equals... $200 per > customer if they have to pay an outside consultant to do it for them, > usually less than $20 for inside help... Not a big number. > $40,000 <=> $400,000 > > Cost of upgrading a single big iron box to have more routing table > slots > $100,000 > Multiply by the number of big iron boxes who can't use a default > route, say at least 400? > For $100,000, you get a lot more than 2000 additional customers worth of routing table entries. Further, let's look at the cost of doing that uniquely after we subtract out the cost of upgrades that would be required anyway due to other factors (forwarding plane capacity requirements, routing table growth from other causes such as TE, etc.). > > You do the math, and tell me again why I should be paying out of my > pocket for your customer. You very well could have explicit > instructions sent to the customers for IP address changes. You could > very well purchase multiple IP ranges from different providers, and > thus make the importance of any IP address change negliable. Or you > could pay $49/month to get a second uplink and then qualify for PI > space based on multi-homing. > Yeah, but, once he has done the latter, you're still stuck with the costs of carrying his route, so, I'm not sure why you think that's a gain. The effort, btw, that started this discussion was trying to extend the multihoming policy down to /24 instead of /22. I don't think anyone is advocating (in the v4 world) that we open up additional bits for non-multihomed end users. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From leroy at emailsorting.com Wed Jun 6 21:42:11 2007 From: leroy at emailsorting.com (Leroy Ladyzhensky) Date: Wed, 6 Jun 2007 21:42:11 -0400 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks References: <1070531191229.386B-100000@Ives.egh.com> Message-ID: <119b01c7a8a5$1167bd30$c80a0a0a@integrated.net> The demand on infrastructure router to hold additional routing table information has been mentioned several times on this subject.... but if we look at the reason why proposals were reject by ARIN in the past that discussed this subject... http://lists.arin.net/pipermail/ppml/2007-April/006601.html we see that routing table demands we not in issue raised by ARIN. also if we calculate this mathematically.. you can see this is not a real concern.. for example ... my math is being rounded and is based of memory so it might not be 100% accurate, but I think its close. the last time I checked, a full BGB routing table had about 130,000 routes.... and lets say that ARIN ended up passing out 10,000 /24 address spaces to companies that requested the smaller block... this would only be a 7.5% increase in the routing table size. And if my memory serves me... the current routing table uses about 65megs of router memory for each upstream connection... so this would require about 4 megs of addition router DRAM to handle 10,000 additional routes per upstream. Do core routers like the "Big Iron" not have 12 or 16 megs free of DRAM to hold additional routes? So, do you really think any router in a core network from major ISP's could not handle this? This discussion is to not ONLY hand out 24's... but to give /24's or even /23's to companies who provide internet based services like MSP's and ASP's who would like to own an address space to have the ability to change upstream providers as needed. I really don't buy the idea of stress to the infrastructure of the internet to handle this. (unless my math is terribly off) Leroy L. ----- Original Message ----- From: "Jo Rhett" To: "John Santos" Cc: Sent: Wednesday, June 06, 2007 7:11 PM Subject: Re: [ppml] Suggestion for ARIN to deligate smaller IP blocks > John, I'm a little confused by your math. > > 2000 customers * cost of changing IP addresses equals... $200 per > customer if they have to pay an outside consultant to do it for them, > usually less than $20 for inside help... Not a big number. > $40,000 <=> $400,000 > > Cost of upgrading a single big iron box to have more routing table > slots > $100,000 > Multiply by the number of big iron boxes who can't use a default > route, say at least 400? > > The only difference is who is paying for it, and who is gaining value > for it. You want us to pay, so that your business can gain value. > > You do the math, and tell me again why I should be paying out of my > pocket for your customer. You very well could have explicit > instructions sent to the customers for IP address changes. You could > very well purchase multiple IP ranges from different providers, and > thus make the importance of any IP address change negliable. Or you > could pay $49/month to get a second uplink and then qualify for PI > space based on multi-homing. > > Every one of those options is trivially cheap and easy to implement. > This is why I reject your desire to make our businesses pay hard cash > so that your business can avoid building even the most trivial > resiliance into your process. > > On May 31, 2007, at 4:39 PM, John Santos wrote: >> It is the 2000 customers who would have to pay the cost. It may be >> small for each, but its cumulative, and will certainly generating lots >> of support calls back to Leroy's company. >> >> My company is in a similar situation to Leroy's customers. We have an >> external mail filtering service. Our published MX records point to >> the service, and they then forward the (filtered for spam, viruses, >> RBL, etc.) mail to us, so we have had to open up our firewall to SMTP >> from their specific IP addresses. We are certainly *not* going to let >> them manage our firewalls for us, nor are we going to willy-nilly >> change >> our firewall rules on their request without minimally verifying the >> origin of the request (a support call to them.) Multiply by several >> thousand customers. >> >> If they were to start changing IP addresses frequently, we would start >> looking for a new service provider. >> >> This is an *extremely* unlevel playing field, since ACME GIANT ASP, >> INC. (which is many times the size of Leroy's company), could easily >> justify an allocation, and thus could promise their customers that >> their IP addresses and firewall rule would never change. > > -- > Jo Rhett > senior geek > > Silicon Valley Colocation > Support Phone: 408-400-0550 > > > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From jlewis at lewis.org Wed Jun 6 22:33:37 2007 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 6 Jun 2007 22:33:37 -0400 (EDT) Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <119b01c7a8a5$1167bd30$c80a0a0a@integrated.net> References: <1070531191229.386B-100000@Ives.egh.com> <119b01c7a8a5$1167bd30$c80a0a0a@integrated.net> Message-ID: On Wed, 6 Jun 2007, Leroy Ladyzhensky wrote: > the last time I checked, a full BGB routing table had about 130,000 > routes.... and lets say that ARIN ended up passing out 10,000 /24 address Been a while, has it? The global table is closer to 218,000 routes now. > spaces to companies that requested the smaller block... this would only be a > 7.5% increase in the routing table size. And if my memory serves me... the > current routing table uses about 65megs of router memory for each upstream > connection... so this would require about 4 megs of addition router DRAM to > handle 10,000 additional routes per upstream. Do core routers like the "Big > Iron" not have 12 or 16 megs free of DRAM to hold additional routes? That totally ignores a large installed base of switch based routers (Cisco 6500/7600, many versions of which crap out at somewhat less than 256k routes regardless of the amount of free memory. i.e. on a 6509 with sup2 and 512mb RAM, I have 135MB free. But I'm less than 20k routes away from "really bad things" happening if I don't have several tens of thousands of dollars of hardware upgrades (per router) for new supervisor cards, new power supplies, and new fan trays. > This discussion is to not ONLY hand out 24's... but to give /24's or even > /23's to companies who provide internet based services like MSP's and ASP's > who would like to own an address space to have the ability to change > upstream providers as needed. I haven't been paying full attention. Are we talking about handing out a /24 or shorter prefix to any network that wants one, just to multihomed networks, or just to multihomed service provider networks? If just the multihomed ones, then there's perhaps an argument to be made that doing so doesn't really change the size of the global table...those networks are already announcing PA /24s or shorter networks. Other than the fact that if you really wanted, you could selectively filter such that you ignored those routes (only accepting the parent route), does it really matter if those nets announce PA vs PI /24's? One could even argue that this would conserve IP space...as contrary to ARIN regulations, in my experience it's fairly common for an ISP to automatically assign a multihomed customer a /24 if they want it, even if they already have other PA /24 assignments. I've seen multihomed networks that couldn't get PI space have 3 or more PA /24s...and sometimes even announce them all into the global table. If you're suggesting any ARIN end user who wants ISP independence (not just multihomed networks) get a PI allocation, I'd be very worried about explosive global table growth. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From JOHN at egh.com Thu Jun 7 05:50:32 2007 From: JOHN at egh.com (John Santos) Date: Thu, 7 Jun 2007 05:50:32 -0400 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <03AD1790-8019-4384-91DB-30D66C980E51@svcolo.com> Message-ID: <1070607053910.24656A-100000@Ives.egh.com> On Wed, 6 Jun 2007, Jo Rhett wrote: > On May 31, 2007, at 6:40 PM, John Santos wrote: > > All I'm saying is people should be entitled > > to permanent IP addresses, for as long as they need them > > Think about this clearly. Where is this infinite resource coming from? If 128 bits isn't enough, then maybe its time to start thinking about ipv7! :-) > > 1. IP address space is limited although inexpensive. > > 2. Prefix slots in router memory are even more limited, and much more > costly. > I didn't say anything about routing. I was talking about addresses. Routing only comes into the picture if you want to make the addresses visible off-site. If you want to peer with someone else (i.e. a private network), only the two of you need to put anything in your routing tables, and you only need to add a single route. If you want to peer with a handful of other sites, then you only need a handful of routes. There are lots of uses for addresses that need to be globaly unique, but don't need to be routed. See all the talk about doorknobs for a fairly silly example. > Cost #1 is low and is paid once. > > Cost #2 is very high, and is paid by *EVERYONE* who is connected. > Not together, but each individually. Cost #3 is zero for unrouted addresses. > > This isn't like raising taxes, where a tiny hike creates a lot of > money. This is like asking every citizen to repurchase their home/ > car/etc so that someone else can avoid thinking about their business > model. > Huh? Are you going off again about how people need to be able to renumber at the drop of a hat, and just because you did it once and it was easy, no one else should complain? I could edit all my DNS zone files in 2 minutes with a TECO macro. That isn't renumbering. > -- > Jo Rhett > senior geek > > Silicon Valley Colocation > Support Phone: 408-400-0550 > > > > > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From JOHN at egh.com Thu Jun 7 06:09:17 2007 From: JOHN at egh.com (John Santos) Date: Thu, 7 Jun 2007 06:09:17 -0400 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: Message-ID: <1070607055425.24656B-100000@Ives.egh.com> On Wed, 6 Jun 2007, Jo Rhett wrote: > John, I'm a little confused by your math. > > 2000 customers * cost of changing IP addresses equals... $200 per > customer if they have to pay an outside consultant to do it for them, > usually less than $20 for inside help... Not a big number. > $40,000 <=> $400,000 Maybe $400,000 is noise to your company. My company has to think long and hard before spending $40,000. Your perspective is seriously warped. > > Cost of upgrading a single big iron box to have more routing table > slots > $100,000 > Multiply by the number of big iron boxes who can't use a default > route, say at least 400? Are you talking about the cost of upgrading all the backbone routers in the world to handle /25's vs. /22's? (I forget the size Leroy was originally looking for, but it was about 1/8 the minimum assignment under the current rules.) Aren't all these big boxes going to need to be upgraded anyway to support IPv6? > > The only difference is who is paying for it, and who is gaining value > for it. You want us to pay, so that your business can gain value. Who is "us"? > > You do the math, and tell me again why I should be paying out of my > pocket for your customer. You very well could have explicit > instructions sent to the customers for IP address changes. You could > very well purchase multiple IP ranges from different providers, and > thus make the importance of any IP address change negliable. Or you > could pay $49/month to get a second uplink and then qualify for PI > space based on multi-homing. Don't you need to be able to justify a /22 to get the PI multihoming space? That was the basis of this whole discussion. > > Every one of those options is trivially cheap and easy to implement. > This is why I reject your desire to make our businesses pay hard cash > so that your business can avoid building even the most trivial > resiliance into your process. Why does it cost your business any more if Leroy has a /25 that he is using most of versus if he has a /22 that he doesn't really need? Are you on about routing table size again, or something else? > > On May 31, 2007, at 4:39 PM, John Santos wrote: > > It is the 2000 customers who would have to pay the cost. It may be > > small for each, but its cumulative, and will certainly generating lots > > of support calls back to Leroy's company. > > > > My company is in a similar situation to Leroy's customers. We have an > > external mail filtering service. Our published MX records point to > > the service, and they then forward the (filtered for spam, viruses, > > RBL, etc.) mail to us, so we have had to open up our firewall to SMTP > > from their specific IP addresses. We are certainly *not* going to let > > them manage our firewalls for us, nor are we going to willy-nilly > > change > > our firewall rules on their request without minimally verifying the > > origin of the request (a support call to them.) Multiply by several > > thousand customers. > > > > If they were to start changing IP addresses frequently, we would start > > looking for a new service provider. > > > > This is an *extremely* unlevel playing field, since ACME GIANT ASP, > > INC. (which is many times the size of Leroy's company), could easily > > justify an allocation, and thus could promise their customers that > > their IP addresses and firewall rule would never change. > > -- > Jo Rhett > senior geek > > Silicon Valley Colocation > Support Phone: 408-400-0550 > > > > > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From michael.dillon at bt.com Thu Jun 7 06:21:28 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 7 Jun 2007 11:21:28 +0100 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <1070607055425.24656B-100000@Ives.egh.com> References: <1070607055425.24656B-100000@Ives.egh.com> Message-ID: > Are you talking about the cost of upgrading all the backbone > routers in the world to handle /25's vs. /22's? They don't all need to handle those long prefixes. Providers can filter their incoming announcements and either ignore long prefixes altogether or only accept them on those parts of their network infrastructure where they can handle the larger routing tables. We do not tell network operators how to run their network. > Aren't all these big boxes going to need to be upgraded > anyway to support IPv6? These big boxes have already been upgraded to support IPv6 years ago. The IPv6 capability may not be in use, but the big boxes all support it. At the edge, in little boxes, there is a need to upgrade the boxes if they need to support IPv6 but since nobody is going to turn off IPv4 services for a long, long time, there is no imperative to upgrade. --Michael Dillon From rgaglian at antel.net.uy Thu Jun 7 09:43:57 2007 From: rgaglian at antel.net.uy (Roque Gagliano) Date: Thu, 7 Jun 2007 10:43:57 -0300 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> <465C3FDE.7050708@psg.com> <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> Message-ID: <7C441817-6409-48D2-8599-1EE7A6FAC0F7@antel.net.uy> > > ULAs are not intended to be publically routed by ISPs. While some may > attempt to get ISPs to route them, ISPs will have clear documentation > saying they are not intended to be used that way, and they are free to > filter them. And in fact they SHOULD be filtered. (I'd say MUST, but > since that is not enforceable...) Should ULA-C be published in the Whois database? what about reverse DNS for them, should they be delegated or just reply a NXDOMAIN? Roque ------------------------------------------------------------- Roque Gagliano ANTEL - URUGUAY rgaglian at antel.net.uy -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Thu Jun 7 09:54:15 2007 From: randy at psg.com (Randy Bush) Date: Thu, 07 Jun 2007 06:54:15 -0700 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <7C441817-6409-48D2-8599-1EE7A6FAC0F7@antel.net.uy> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> <465C3FDE.7050708@psg.com> <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> <7C441817-6409-48D2-8599-1EE7A6FAC0F7@antel.net.uy> Message-ID: <46680E07.7030501@psg.com> > Should ULA-C be published in the Whois database? what about reverse DNS > for them, should they be delegated or just reply a NXDOMAIN? let's see. ula-c should be assigned and tracked by rirs. they should have whois and in-addr.arpa. do remind me how they differ from pi space. i keep forgetting. randy From rgaglian at antel.net.uy Thu Jun 7 09:56:32 2007 From: rgaglian at antel.net.uy (Roque Gagliano) Date: Thu, 7 Jun 2007 10:56:32 -0300 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: <46680E07.7030501@psg.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> <465C3FDE.7050708@psg.com> <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> <7C441817-6409-48D2-8599-1EE7A6FAC0F7@antel.net.uy> <46680E07.7030501@psg.com> Message-ID: more "practical" questions: why should they be cheaper than PI block? do they take less administrative work form RIR? do they take less "space" in their databases? in many RIRs you need to pay a "membership" fee and doing so you get the right to vote in their members meetings, if you get an ULA-C allocation, should you be considered a member? would you pay your membership fee to the RIR? again, why should this allocation be cheaper that a PI allocation? Roque On Jun 7, 2007, at 10:54 AM, Randy Bush wrote: >> Should ULA-C be published in the Whois database? what about >> reverse DNS >> for them, should they be delegated or just reply a NXDOMAIN? > > let's see. ula-c should be assigned and tracked by rirs. they should > have whois and in-addr.arpa. do remind me how they differ from pi > space. i keep forgetting. > > randy ------------------------------------------------------------- Roque Gagliano ANTEL - URUGUAY rgaglian at antel.net.uy -------------- next part -------------- An HTML attachment was scrubbed... URL: From kkargel at polartel.com Thu Jun 7 10:16:28 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 7 Jun 2007 09:16:28 -0500 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066706FB1@mail> Wouldn't it be nice if we had a ULA bit or two to play with in the BGP announcements? Then everyone could define their own.. I know this is facetious and not a serious consideration, but it was an interesting thought.. ________________________________ From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Roque Gagliano Sent: Thursday, June 07, 2007 8:57 AM To: Randy Bush Cc: Thomas Narten; ppml at arin.net; address-policy-wg at ripe.net Subject: Re: [ppml] [address-policy-wg] Those pesky ULAs again more "practical" questions: why should they be cheaper than PI block? do they take less administrative work form RIR? do they take less "space" in their databases? in many RIRs you need to pay a "membership" fee and doing so you get the right to vote in their members meetings, if you get an ULA-C allocation, should you be considered a member? would you pay your membership fee to the RIR? again, why should this allocation be cheaper that a PI allocation? Roque On Jun 7, 2007, at 10:54 AM, Randy Bush wrote: Should ULA-C be published in the Whois database? what about reverse DNS for them, should they be delegated or just reply a NXDOMAIN? let's see. ula-c should be assigned and tracked by rirs. they should have whois and in-addr.arpa. do remind me how they differ from pi space. i keep forgetting. randy ------------------------------------------------------------- Roque Gagliano ANTEL - URUGUAY rgaglian at antel.net.uy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu Jun 7 10:21:28 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 07 Jun 2007 16:21:28 +0200 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Message-ID: Hi Roque, This is something that never is defined by the policies. It is up to the board to decide and I'm fine with board decisions on this. If you don't, they you should make sure to select a different board composition next time :-). Regards, Jordi De: Roque Gagliano Responder a: Fecha: Thu, 7 Jun 2007 10:56:32 -0300 Para: Randy Bush CC: Thomas Narten , , Asunto: Re: [ppml] [address-policy-wg] Those pesky ULAs again more "practical" questions: why should they be cheaper than PI block? do they take less?administrative?work form RIR? do they take less "space" in their databases?? in many RIRs you need to pay a "membership" fee and doing so you get the right to vote in their members meetings, if you get an ULA-C allocation, should you be considered a member? would you pay your membership fee to the RIR? again, why should this allocation be cheaper that a PI allocation? Roque On Jun 7, 2007, at 10:54 AM, Randy Bush wrote: >> Should ULA-C be published in the Whois database? what about reverse DNS >> for them, should they be delegated or just reply a NXDOMAIN? >> > > let's see.? ula-c should be assigned and tracked by rirs.? they should > have whois and in-addr.arpa.? do remind me how they differ from pi > space.? i keep forgetting. > > randy > ------------------------------------------------------------- Roque Gagliano ANTEL - URUGUAY rgaglian at antel.net.uy _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owen at delong.com Thu Jun 7 10:28:56 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Jun 2007 07:28:56 -0700 Subject: [ppml] Difference between ULA-C and PI Message-ID: <11FE30C1-C8B7-4242-B379-64CF71882FB2@delong.com> As near as I can tell, the only difference between ULA-C and PI is that ULA-C will potentially have slightly more breakage than PI because some ISPs will filter at least some of it (as they theoretically should). Beyond that, ULA-C is distinguishable from PI only in the minds of the people who imagine it is a good idea. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From paul at vix.com Thu Jun 7 10:31:10 2007 From: paul at vix.com (Paul Vixie) Date: Thu, 07 Jun 2007 14:31:10 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Your message of "Thu, 07 Jun 2007 06:54:15 MST." <46680E07.7030501@psg.com> References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> <465C3FDE.7050708@psg.com> <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> <7C441817-6409-48D2-8599-1EE7A6FAC0F7@antel.net.uy> <46680E07.7030501@psg.com> Message-ID: <51726.1181226670@sa.vix.com> > > Should ULA-C be published in the Whois database? what about reverse DNS > > for them, should they be delegated or just reply a NXDOMAIN? > > let's see. ula-c should be assigned and tracked by rirs. they should > have whois and in-addr.arpa. do remind me how they differ from pi > space. i keep forgetting. while i'm uncomfortable with randy's tone here, i agree with his concern. the difference between pi and ula has been given as "not intended to be routed in the DFZ". this means a pi prefix can be routed privately, as for example among cooperating BGP peers at an IX, or between companies involved in private relationships such as banking or manufacturing, and of course, it will mean that "merge/acquire" no longer implies "renumber the RFC1918's on one or both sides". but since we could never possibly fit all of ipv6 into the DFZ, and since the cost and availability of pi is theoretically manageable by us (the RIR system) to make sure everybody who needs it can get and can afford it, i fail to see the virtue of making some of it cheaper and worth less. this whole argument has helped me understand that there is a policy hole but that "unroutable" isn't it. if the RIR system had multiple high order prefixes (IPv6 /10's or whatever) to allocate from, with a minimum length policy that varied, then global static route-ingress filters could be set that would outlaw TE routes, which are the major source of DFZ bloat, way over the top compared to SMB PI routes. i think i oppose ula simply because there's no way to define "local" in a way that will serve a network's needs throughout its probable life cycle, except in the case where RFC1918 (or IPv6 "site local") would have served. From drc at virtualized.org Thu Jun 7 13:13:36 2007 From: drc at virtualized.org (David Conrad) Date: Thu, 7 Jun 2007 10:13:36 -0700 Subject: [ppml] Difference between ULA-C and PI In-Reply-To: <11FE30C1-C8B7-4242-B379-64CF71882FB2@delong.com> References: <11FE30C1-C8B7-4242-B379-64CF71882FB2@delong.com> Message-ID: <77B56247-A452-4355-8BA1-3B5B1C8608A8@virtualized.org> It looks to me the primary difference is expectation of cost/ allocation restrictions. I gather ULA-C isn't supposed to have any. However, I'm not sure as I'm waiting for a non-expired ULA-C draft. Rgds, -drc On Jun 7, 2007, at 7:28 AM, Owen DeLong wrote: > * PGP Signed by an unverified key: 06/07/07 at 07:28:56 > > As near as I can tell, the only difference between ULA-C and PI > is that ULA-C will potentially have slightly more breakage than PI > because some ISPs will filter at least some of it (as they > theoretically should). > > Beyond that, ULA-C is distinguishable from PI only in the minds > of the people who imagine it is a good idea. > > Owen > > > * Owen DeLong > * Issuer: DeLong Consulting - Unverified > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > > > * PGP Signed by an unverified key: 06/07/07 at 07:28:56 > * text/plain body > * Owen DeLong > * Issuer: DeLong Consulting - Unverified From drc at virtualized.org Thu Jun 7 13:19:02 2007 From: drc at virtualized.org (David Conrad) Date: Thu, 7 Jun 2007 10:19:02 -0700 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <1070607053910.24656A-100000@Ives.egh.com> References: <1070607053910.24656A-100000@Ives.egh.com> Message-ID: On Jun 7, 2007, at 2:50 AM, John Santos wrote: >> On May 31, 2007, at 6:40 PM, John Santos wrote: >>> All I'm saying is people should be entitled >>> to permanent IP addresses, for as long as they need them >> Think about this clearly. Where is this infinite resource coming >> from? > If 128 bits isn't enough, then maybe its time to start thinking about > ipv7! :-) Realistically, it isn't 128 bits. 64 bits off the bottom are used for the EUI. 8 or 16 bits in the middle are used for local topology. 3 bits off the top are used for format specifier. So, it is actually 45 or 53 bits. > I didn't say anything about routing. I was talking about addresses. Generally, the two are intertwined. If you don't care about routing, pick a number at random. They're just integers after all. Rgds, -drc From randy at psg.com Thu Jun 7 13:38:39 2007 From: randy at psg.com (Randy Bush) Date: Thu, 07 Jun 2007 10:38:39 -0700 Subject: [ppml] Difference between ULA-C and PI In-Reply-To: <77B56247-A452-4355-8BA1-3B5B1C8608A8@virtualized.org> References: <11FE30C1-C8B7-4242-B379-64CF71882FB2@delong.com> <77B56247-A452-4355-8BA1-3B5B1C8608A8@virtualized.org> Message-ID: <4668429F.3000605@psg.com> David Conrad wrote: > It looks to me the primary difference is expectation of cost/ > allocation restrictions. I gather ULA-C isn't supposed to have any. but the rirs are being asked to provide full service. what is wrong with this model? randy From drc at virtualized.org Thu Jun 7 14:31:13 2007 From: drc at virtualized.org (David Conrad) Date: Thu, 7 Jun 2007 11:31:13 -0700 Subject: [ppml] Difference between ULA-C and PI In-Reply-To: <4668429F.3000605@psg.com> References: <11FE30C1-C8B7-4242-B379-64CF71882FB2@delong.com> <77B56247-A452-4355-8BA1-3B5B1C8608A8@virtualized.org> <4668429F.3000605@psg.com> Message-ID: On Jun 7, 2007, at 10:38 AM, Randy Bush wrote: > David Conrad wrote: >> It looks to me the primary difference is expectation of cost/ >> allocation restrictions. I gather ULA-C isn't supposed to have any. > but the rirs are being asked to provide full service. what is wrong > with this model? Fits quite well with "from each according to ability, to each according to need"... :-) :-) Doesn't make sense to me, but maybe the new ULA-C draft will explain. Rgds, -drc From michael.dillon at bt.com Thu Jun 7 14:46:59 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 7 Jun 2007 19:46:59 +0100 Subject: [ppml] Difference between ULA-C and PI In-Reply-To: <77B56247-A452-4355-8BA1-3B5B1C8608A8@virtualized.org> References: <11FE30C1-C8B7-4242-B379-64CF71882FB2@delong.com> <77B56247-A452-4355-8BA1-3B5B1C8608A8@virtualized.org> Message-ID: > It looks to me the primary difference is expectation of cost/ > allocation restrictions. I gather ULA-C isn't supposed to have any. > However, I'm not sure as I'm waiting for a non-expired ULA-C draft. And there you have it! The definitive difference between ULA-C and PI addresses. PI exists and ULA-C is nothing but vaporware. We are wasting our time discussing something that does not exist. There is no point in pontificating on ULA-C and PI and BGP and the global routing table because nobody knows what ULA-C is. In fact, if the people with negative views on ULA-C as proposed in Jordi's rambling messages would leave this list and say all the same things in the IPv6 WG, then ULA-C will never exist. Or it will exist in a far different form that resolves some of those issues. In any case, I am strongly opposed to any ARIN policy that deals with ULA-C in any way until the whole controversy has been settled in the IETF. I accept that people like Randy have good reason to be sceptical of an IETF outcome, nevertheless, I do not believe that it is in ARIN's best interests to predict the IETF outcome on this issue. --Michael Dillon From mark at mcsnet.ca Thu Jun 7 15:59:49 2007 From: mark at mcsnet.ca (Mark Beland) Date: Thu, 07 Jun 2007 13:59:49 -0600 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <1070607055425.24656B-100000@Ives.egh.com> References: <1070607055425.24656B-100000@Ives.egh.com> Message-ID: <466863B5.3090305@mcsnet.ca> Folks, I've been watching this thread unwinding and feel I need to pitch in my two bits. I think we're missing the most important elements of the problem here. Arguably, nearly any moderate sized company can justify a /24 ... Your policy change could specify that only ISP's may obtain blocks of /24, but the private business / ISP distinction is one that may well be trivial for most businesses to overcome.... The problem I envision is that when you tell tech savvy small businesses and ISP's that they can be provider agnostic by obtaining an allocation directly from ARIN, there will be a mad rush on the part of these companies to do just that. Multi-homing has always been an option for those who can justify the allocations, but when you reduce the minimum size of the allocation required and you also remove the need for such companies to be multi-homed, I think your opening a pandora's box.. You would see As the most important side-effect: - 1000's of smaller companies, who don't really need a /24, exaggerating their need in order to get an allocation.. after all, its convenient not to have to renumber.... easier than planning ahead. And we would also see: - Significant routing table growth - can't argue this one - rather than seeing a /18(or larger) from big isp, we're seeing /24's - A change in the ISP marketplace where mid/small sized customers all become provider agnostic. This may be good for you if your a small isp or asp, but its bad for the Internet Access business as a whole because it makes it very easy for these companies to change ISP's.. This means that if your a small or mid sized internet service provider providing services to a business who has their own allocation, big telco can come along any day and say here's the same service for half the price, and they can have the client up and running in a matter of moments..... (this as opposed to the current situation where renumbering is often more time consuming an expensive) We were in your shoes a number of years ago, as a small ISP trying to get an allocation, and I appreciate the realities of your situation. But on the other hand, what you are proposing has serious implications for the entire industry, and I for one, would like to keep things exactly the way they are. Regards, Mark Beland John Santos wrote: > On Wed, 6 Jun 2007, Jo Rhett wrote: > > >> John, I'm a little confused by your math. >> >> 2000 customers * cost of changing IP addresses equals... $200 per >> customer if they have to pay an outside consultant to do it for them, >> usually less than $20 for inside help... Not a big number. >> $40,000 <=> $400,000 >> > > Maybe $400,000 is noise to your company. My company has to think > long and hard before spending $40,000. Your perspective is seriously > warped. > > >> Cost of upgrading a single big iron box to have more routing table >> slots > $100,000 >> Multiply by the number of big iron boxes who can't use a default >> route, say at least 400? >> > > Are you talking about the cost of upgrading all the backbone routers > in the world to handle /25's vs. /22's? (I forget the size Leroy > was originally looking for, but it was about 1/8 the minimum > assignment under the current rules.) > > Aren't all these big boxes going to need to be upgraded anyway to > support IPv6? > > >> The only difference is who is paying for it, and who is gaining value >> for it. You want us to pay, so that your business can gain value. >> > > Who is "us"? > > >> You do the math, and tell me again why I should be paying out of my >> pocket for your customer. You very well could have explicit >> instructions sent to the customers for IP address changes. You could >> very well purchase multiple IP ranges from different providers, and >> thus make the importance of any IP address change negliable. Or you >> could pay $49/month to get a second uplink and then qualify for PI >> space based on multi-homing. >> > > Don't you need to be able to justify a /22 to get the PI multihoming > space? That was the basis of this whole discussion. > > >> Every one of those options is trivially cheap and easy to implement. >> This is why I reject your desire to make our businesses pay hard cash >> so that your business can avoid building even the most trivial >> resiliance into your process. >> > > Why does it cost your business any more if Leroy has a /25 that he > is using most of versus if he has a /22 that he doesn't really need? > > Are you on about routing table size again, or something else? > > >> On May 31, 2007, at 4:39 PM, John Santos wrote: >> >>> It is the 2000 customers who would have to pay the cost. It may be >>> small for each, but its cumulative, and will certainly generating lots >>> of support calls back to Leroy's company. >>> >>> My company is in a similar situation to Leroy's customers. We have an >>> external mail filtering service. Our published MX records point to >>> the service, and they then forward the (filtered for spam, viruses, >>> RBL, etc.) mail to us, so we have had to open up our firewall to SMTP >>> from their specific IP addresses. We are certainly *not* going to let >>> them manage our firewalls for us, nor are we going to willy-nilly >>> change >>> our firewall rules on their request without minimally verifying the >>> origin of the request (a support call to them.) Multiply by several >>> thousand customers. >>> >>> If they were to start changing IP addresses frequently, we would start >>> looking for a new service provider. >>> >>> This is an *extremely* unlevel playing field, since ACME GIANT ASP, >>> INC. (which is many times the size of Leroy's company), could easily >>> justify an allocation, and thus could promise their customers that >>> their IP addresses and firewall rule would never change. >>> >> -- >> Jo Rhett >> senior geek >> >> Silicon Valley Colocation >> Support Phone: 408-400-0550 >> >> >> >> >> >> >> > > From owen at delong.com Thu Jun 7 16:21:47 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Jun 2007 13:21:47 -0700 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <466863B5.3090305@mcsnet.ca> References: <1070607055425.24656B-100000@Ives.egh.com> <466863B5.3090305@mcsnet.ca> Message-ID: <700EAF4E-44AD-412B-8BBA-0AE3EB540BE1@delong.com> > > As the most important side-effect: > - 1000's of smaller companies, who don't really need a /24, > exaggerating > their need in order > to get an allocation.. after all, its convenient not to have to > renumber.... easier than > planning ahead. > 1. I don't think so. 2. History with the /22 multihoming policy would imply that to be false. 3. This would only apply to companies willing to spend enough to get a router capable of really multihoming with full BGP, etc., so, I think most small businesses where internet was not a critical infrastructure for their ability to conduct interaction and service to their customers would not find this attractive. > And we would also see: > - Significant routing table growth - can't argue this one - rather > than > seeing a /18(or larger) from big isp, we're seeing /24's > - A change in the ISP marketplace where mid/small sized customers all > become provider agnostic. > This may be good for you if your a small isp or asp, but its bad > for the > Internet Access > business as a whole because it makes it very easy for these > companies to > change ISP's.. This > means that if your a small or mid sized internet service provider > providing services to a business > who has their own allocation, big telco can come along any day and say > here's the same service > for half the price, and they can have the client up and running in a > matter of moments..... (this > as opposed to the current situation where renumbering is often more > time > consuming an expensive) > This is pure FUD. The ability to be provider agnostic is _GREAT_ for the market. The market can decide who they want to buy service from and can hold their providers accountable by leaving if the provider stops providing good service or the price becomes non-competitive. As to the routing table growth, that's FUD, too. The proposed policy only provided for people that have an ASN and are multihoming. Those people are already advertising PA /24s out of their environment, or, will be anyway, so, there's no net change to the routing table. > > We were in your shoes a number of years ago, as a small ISP trying to > get an allocation, and I appreciate > the realities of your situation. But on the other hand, what you are > proposing has serious implications > for the entire industry, and I for one, would like to keep things > exactly the way they are. > The proposed policy does not apply to ISPs. If you are an ISP, you need reassignable space and a /24 won't cut it anyway. Currently, the minimum for an ISP is a /20 based on using at least half of a /21 if memory serves. The proposal in question was aimed at multihomed end user organizations. I'm aware that most mid-size or larger ISPs would like to keep things the way they are. Afterall, as you pointed out, while provider agnosticism is good for the customers, it's potentially uncomfortable for some ISPs because they worry about their customers switching on them. Oh well... That's called a free market. If protectionism is the only argument you have besides FUD in favor of keeping things the way they are, then, I think you have actually made my point. Owen > > Regards, > Mark Beland > > > > > John Santos wrote: >> On Wed, 6 Jun 2007, Jo Rhett wrote: >> >> >>> John, I'm a little confused by your math. >>> >>> 2000 customers * cost of changing IP addresses equals... $200 per >>> customer if they have to pay an outside consultant to do it for >>> them, >>> usually less than $20 for inside help... Not a big number. >>> $40,000 <=> $400,000 >>> >> >> Maybe $400,000 is noise to your company. My company has to think >> long and hard before spending $40,000. Your perspective is seriously >> warped. >> >> >>> Cost of upgrading a single big iron box to have more routing table >>> slots > $100,000 >>> Multiply by the number of big iron boxes who can't use a default >>> route, say at least 400? >>> >> >> Are you talking about the cost of upgrading all the backbone routers >> in the world to handle /25's vs. /22's? (I forget the size Leroy >> was originally looking for, but it was about 1/8 the minimum >> assignment under the current rules.) >> >> Aren't all these big boxes going to need to be upgraded anyway to >> support IPv6? >> >> >>> The only difference is who is paying for it, and who is gaining >>> value >>> for it. You want us to pay, so that your business can gain value. >>> >> >> Who is "us"? >> >> >>> You do the math, and tell me again why I should be paying out of my >>> pocket for your customer. You very well could have explicit >>> instructions sent to the customers for IP address changes. You >>> could >>> very well purchase multiple IP ranges from different providers, and >>> thus make the importance of any IP address change negliable. Or you >>> could pay $49/month to get a second uplink and then qualify for PI >>> space based on multi-homing. >>> >> >> Don't you need to be able to justify a /22 to get the PI multihoming >> space? That was the basis of this whole discussion. >> >> >>> Every one of those options is trivially cheap and easy to implement. >>> This is why I reject your desire to make our businesses pay hard >>> cash >>> so that your business can avoid building even the most trivial >>> resiliance into your process. >>> >> >> Why does it cost your business any more if Leroy has a /25 that he >> is using most of versus if he has a /22 that he doesn't really need? >> >> Are you on about routing table size again, or something else? >> >> >>> On May 31, 2007, at 4:39 PM, John Santos wrote: >>> >>>> It is the 2000 customers who would have to pay the cost. It may be >>>> small for each, but its cumulative, and will certainly >>>> generating lots >>>> of support calls back to Leroy's company. >>>> >>>> My company is in a similar situation to Leroy's customers. We >>>> have an >>>> external mail filtering service. Our published MX records point to >>>> the service, and they then forward the (filtered for spam, viruses, >>>> RBL, etc.) mail to us, so we have had to open up our firewall to >>>> SMTP >>>> from their specific IP addresses. We are certainly *not* going >>>> to let >>>> them manage our firewalls for us, nor are we going to willy-nilly >>>> change >>>> our firewall rules on their request without minimally verifying the >>>> origin of the request (a support call to them.) Multiply by >>>> several >>>> thousand customers. >>>> >>>> If they were to start changing IP addresses frequently, we would >>>> start >>>> looking for a new service provider. >>>> >>>> This is an *extremely* unlevel playing field, since ACME GIANT ASP, >>>> INC. (which is many times the size of Leroy's company), could >>>> easily >>>> justify an allocation, and thus could promise their customers that >>>> their IP addresses and firewall rule would never change. >>>> >>> -- >>> Jo Rhett >>> senior geek >>> >>> Silicon Valley Colocation >>> Support Phone: 408-400-0550 >>> >>> >>> >>> >>> >>> >>> >> >> > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From JOHN at egh.com Thu Jun 7 16:35:05 2007 From: JOHN at egh.com (John Santos) Date: Thu, 7 Jun 2007 16:35:05 -0400 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: Message-ID: <1070607163118.24656A-100000@Ives.egh.com> On Thu, 7 Jun 2007, David Conrad wrote: > On Jun 7, 2007, at 2:50 AM, John Santos wrote: > >> On May 31, 2007, at 6:40 PM, John Santos wrote: > >>> All I'm saying is people should be entitled > >>> to permanent IP addresses, for as long as they need them > >> Think about this clearly. Where is this infinite resource coming > >> from? > > If 128 bits isn't enough, then maybe its time to start thinking about > > ipv7! :-) > > Realistically, it isn't 128 bits. > > 64 bits off the bottom are used for the EUI. > 8 or 16 bits in the middle are used for local topology. > 3 bits off the top are used for format specifier. > > So, it is actually 45 or 53 bits. > > > I didn't say anything about routing. I was talking about addresses. > > Generally, the two are intertwined. If you don't care about routing, > pick a number at random. They're just integers after all. The magic words, "private network", appeared in the next paragraph you snipped, don't remember if I made it clear I was talking about private internets, not intranets. > > Rgds, > -drc > > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From paul at vix.com Thu Jun 7 17:00:33 2007 From: paul at vix.com (Paul Vixie) Date: Thu, 07 Jun 2007 21:00:33 +0000 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: Your message of "Thu, 07 Jun 2007 16:35:05 -0400." <1070607163118.24656A-100000@Ives.egh.com> References: <1070607163118.24656A-100000@Ives.egh.com> Message-ID: <91169.1181250033@sa.vix.com> > The magic words, "private network", appeared in the next paragraph > you snipped, don't remember if I made it clear I was talking about > private internets, not intranets. what's a "private" internet? From jmorrison at bogomips.com Thu Jun 7 17:08:18 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Thu, 07 Jun 2007 14:08:18 -0700 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <466863B5.3090305@mcsnet.ca> References: <1070607055425.24656B-100000@Ives.egh.com> <466863B5.3090305@mcsnet.ca> Message-ID: <466873C2.3000809@bogomips.com> Funny, there never used to be any reason to keep tech savvy small businesses from designing and operating their networks properly (ie. using BGP instead of NAT hacks or proprietary hardware), and not having to renumber. These are just the same sky is falling arguments that whether intentionally or not, have created second class, second tier internet users. You're not big enough to justify a /22? Then the attitude is "so what" or "get lost" - you have to stay with that bad contract, or use a proprietary or ugly NAT hack to stay in business, or you have to renumber. This isn't 1995 any more. We're not running out of IP addresses - every IPv4 /24 allocated is really just one more step to IPv6. Routers are NOT crashing or having to be upgraded because the Internet routing tables are doubling every month. The Internet saw unprecedented growth in the beginning of the Web age because it was new, and we're never going to see the same rate of growth. What we have here is the same old arguments: address depletion and routing table size to create a two tier internet used as a big stick to keep the little guy in his place. We have IPv6 for address space growth, and the IETF saying there's no need for panic on the routing table problem (on top of it we have Moore's law on our side and the fact that the Internet isn't growing at the same rate). BTW, I can *already* get provider aggregatable /24 addresses today if I can justify them, and advertise these with BGP with another carrier. So the next logical step is to have provider independent addresses so I can cut the cord with the upstream ISP if their terms are onerous John Paul Morrison CCIE #8191 Mark Beland wrote: > Arguably, nearly any moderate sized company can justify a /24 ... Your > policy change > could specify that only ISP's may obtain blocks of /24, but the private > business / ISP > distinction is one that may well be trivial for most businesses to > overcome.... The > problem I envision is that when you tell tech savvy small businesses and > ISP's that they > can be provider agnostic by obtaining an allocation directly from ARIN, > there will > be a mad rush on the part of these companies to do just that. > Multi-homing has always > been an option for those who can justify the allocations, but when you > reduce the minimum > size of the allocation required and you also remove the need for such > companies to be > multi-homed, I think your opening a pandora's box.. You would see > > As the most important side-effect: > - 1000's of smaller companies, who don't really need a /24, exaggerating > their need in order > to get an allocation.. after all, its convenient not to have to > renumber.... easier than > planning ahead. > > And we would also see: > - Significant routing table growth - can't argue this one - rather than > seeing a /18(or larger) from big isp, we're seeing /24's > - A change in the ISP marketplace where mid/small sized customers all > become provider agnostic. > This may be good for you if your a small isp or asp, but its bad for the > Internet Access > business as a whole because it makes it very easy for these companies to > change ISP's.. This > means that if your a small or mid sized internet service provider > providing services to a business > who has their own allocation, big telco can come along any day and say > here's the same service > for half the price, and they can have the client up and running in a > matter of moments..... (this > as opposed to the current situation where renumbering is often more time > consuming an expensive) > > > We were in your shoes a number of years ago, as a small ISP trying to > get an allocation, and I appreciate > the realities of your situation. But on the other hand, what you are > proposing has serious implications > for the entire industry, and I for one, would like to keep things > exactly the way they are. > > > Regards, > Mark Beland > > > > > John Santos wrote: > >> On Wed, 6 Jun 2007, Jo Rhett wrote: >> >> >> >>> John, I'm a little confused by your math. >>> >>> 2000 customers * cost of changing IP addresses equals... $200 per >>> customer if they have to pay an outside consultant to do it for them, >>> usually less than $20 for inside help... Not a big number. >>> $40,000 <=> $400,000 >>> >>> >> Maybe $400,000 is noise to your company. My company has to think >> long and hard before spending $40,000. Your perspective is seriously >> warped. >> >> >> >>> Cost of upgrading a single big iron box to have more routing table >>> slots > $100,000 >>> Multiply by the number of big iron boxes who can't use a default >>> route, say at least 400? >>> >>> >> Are you talking about the cost of upgrading all the backbone routers >> in the world to handle /25's vs. /22's? (I forget the size Leroy >> was originally looking for, but it was about 1/8 the minimum >> assignment under the current rules.) >> >> Aren't all these big boxes going to need to be upgraded anyway to >> support IPv6? >> >> >> >>> The only difference is who is paying for it, and who is gaining value >>> for it. You want us to pay, so that your business can gain value. >>> >>> >> Who is "us"? >> >> >> >>> You do the math, and tell me again why I should be paying out of my >>> pocket for your customer. You very well could have explicit >>> instructions sent to the customers for IP address changes. You could >>> very well purchase multiple IP ranges from different providers, and >>> thus make the importance of any IP address change negliable. Or you >>> could pay $49/month to get a second uplink and then qualify for PI >>> space based on multi-homing. >>> >>> >> Don't you need to be able to justify a /22 to get the PI multihoming >> space? That was the basis of this whole discussion. >> >> >> >>> Every one of those options is trivially cheap and easy to implement. >>> This is why I reject your desire to make our businesses pay hard cash >>> so that your business can avoid building even the most trivial >>> resiliance into your process. >>> >>> >> Why does it cost your business any more if Leroy has a /25 that he >> is using most of versus if he has a /22 that he doesn't really need? >> >> Are you on about routing table size again, or something else? >> >> >> >>> On May 31, 2007, at 4:39 PM, John Santos wrote: >>> >>> >>>> It is the 2000 customers who would have to pay the cost. It may be >>>> small for each, but its cumulative, and will certainly generating lots >>>> of support calls back to Leroy's company. >>>> >>>> My company is in a similar situation to Leroy's customers. We have an >>>> external mail filtering service. Our published MX records point to >>>> the service, and they then forward the (filtered for spam, viruses, >>>> RBL, etc.) mail to us, so we have had to open up our firewall to SMTP >>>> from their specific IP addresses. We are certainly *not* going to let >>>> them manage our firewalls for us, nor are we going to willy-nilly >>>> change >>>> our firewall rules on their request without minimally verifying the >>>> origin of the request (a support call to them.) Multiply by several >>>> thousand customers. >>>> >>>> If they were to start changing IP addresses frequently, we would start >>>> looking for a new service provider. >>>> >>>> This is an *extremely* unlevel playing field, since ACME GIANT ASP, >>>> INC. (which is many times the size of Leroy's company), could easily >>>> justify an allocation, and thus could promise their customers that >>>> their IP addresses and firewall rule would never change. >>>> >>>> >>> -- >>> Jo Rhett >>> senior geek >>> >>> Silicon Valley Colocation >>> Support Phone: 408-400-0550 >>> >>> >>> >>> >>> >>> >>> >>> >> >> > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leroy at emailsorting.com Thu Jun 7 17:34:17 2007 From: leroy at emailsorting.com (Leroy Ladyzhensky) Date: Thu, 7 Jun 2007 17:34:17 -0400 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks References: <1070607055425.24656B-100000@Ives.egh.com> <466863B5.3090305@mcsnet.ca> Message-ID: <1e7201c7a94b$9a5d0fe0$c80a0a0a@integrated.net> That's where a good policy comes in.... I am not talking about any SMB that has a tech savvy owner/it guy that runs exchange.... I am talking about "internet based application/solution providers" (ASP's or MSP's) that are multi-homed. Companies that their sole business is providing services/application hosting/to companies via the internet...companies that need to be ISP independent. These are the companies that can serve millions+ of end-users but do this all with only a few IP's (maybe as little as 64)... these companies will most likely never use many IP's. validation needs to be ip place to show that IP change is extremely painful... to the point where an ISP almost cannot be done without business impact. And since when is being trapped into a ISP a good thing? That's thinking is just insane... and will not comment on that anymore!! lets really face it... the routing table issue is a legitimate concern, but doesn't seem to be a concern of ARIN from when a proposal like this was shot downs before... everything else is just fear. If any company can NOT meet the requirements of using 2 /24's to be able to get a /22 (note the 50% waste is acceptable) from ARIN... and that really wants their own IP's... they LIE (I am sure that is shocking news to most of you). now your precious routing tables are full of /22's with 75% to 90% of the address's being wasted... and that's just wonderful. Leroy L. ----- Original Message ----- From: "Mark Beland" To: "John Santos" Cc: Sent: Thursday, June 07, 2007 3:59 PM Subject: Re: [ppml] Suggestion for ARIN to deligate smaller IP blocks > Folks, > I've been watching this thread unwinding and feel I need to pitch in my > two bits. > > I think we're missing the most important elements of the problem here. > > Arguably, nearly any moderate sized company can justify a /24 ... Your > policy change > could specify that only ISP's may obtain blocks of /24, but the private > business / ISP > distinction is one that may well be trivial for most businesses to > overcome.... The > problem I envision is that when you tell tech savvy small businesses and > ISP's that they > can be provider agnostic by obtaining an allocation directly from ARIN, > there will > be a mad rush on the part of these companies to do just that. > Multi-homing has always > been an option for those who can justify the allocations, but when you > reduce the minimum > size of the allocation required and you also remove the need for such > companies to be > multi-homed, I think your opening a pandora's box.. You would see > > As the most important side-effect: > - 1000's of smaller companies, who don't really need a /24, exaggerating > their need in order > to get an allocation.. after all, its convenient not to have to > renumber.... easier than > planning ahead. > > And we would also see: > - Significant routing table growth - can't argue this one - rather than > seeing a /18(or larger) from big isp, we're seeing /24's > - A change in the ISP marketplace where mid/small sized customers all > become provider agnostic. > This may be good for you if your a small isp or asp, but its bad for the > Internet Access > business as a whole because it makes it very easy for these companies to > change ISP's.. This > means that if your a small or mid sized internet service provider > providing services to a business > who has their own allocation, big telco can come along any day and say > here's the same service > for half the price, and they can have the client up and running in a > matter of moments..... (this > as opposed to the current situation where renumbering is often more time > consuming an expensive) > > > We were in your shoes a number of years ago, as a small ISP trying to > get an allocation, and I appreciate > the realities of your situation. But on the other hand, what you are > proposing has serious implications > for the entire industry, and I for one, would like to keep things > exactly the way they are. > > > Regards, > Mark Beland > > > > > John Santos wrote: >> On Wed, 6 Jun 2007, Jo Rhett wrote: >> >> >>> John, I'm a little confused by your math. >>> >>> 2000 customers * cost of changing IP addresses equals... $200 per >>> customer if they have to pay an outside consultant to do it for them, >>> usually less than $20 for inside help... Not a big number. >>> $40,000 <=> $400,000 >>> >> >> Maybe $400,000 is noise to your company. My company has to think >> long and hard before spending $40,000. Your perspective is seriously >> warped. >> >> >>> Cost of upgrading a single big iron box to have more routing table >>> slots > $100,000 >>> Multiply by the number of big iron boxes who can't use a default >>> route, say at least 400? >>> >> >> Are you talking about the cost of upgrading all the backbone routers >> in the world to handle /25's vs. /22's? (I forget the size Leroy >> was originally looking for, but it was about 1/8 the minimum >> assignment under the current rules.) >> >> Aren't all these big boxes going to need to be upgraded anyway to >> support IPv6? >> >> >>> The only difference is who is paying for it, and who is gaining value >>> for it. You want us to pay, so that your business can gain value. >>> >> >> Who is "us"? >> >> >>> You do the math, and tell me again why I should be paying out of my >>> pocket for your customer. You very well could have explicit >>> instructions sent to the customers for IP address changes. You could >>> very well purchase multiple IP ranges from different providers, and >>> thus make the importance of any IP address change negliable. Or you >>> could pay $49/month to get a second uplink and then qualify for PI >>> space based on multi-homing. >>> >> >> Don't you need to be able to justify a /22 to get the PI multihoming >> space? That was the basis of this whole discussion. >> >> >>> Every one of those options is trivially cheap and easy to implement. >>> This is why I reject your desire to make our businesses pay hard cash >>> so that your business can avoid building even the most trivial >>> resiliance into your process. >>> >> >> Why does it cost your business any more if Leroy has a /25 that he >> is using most of versus if he has a /22 that he doesn't really need? >> >> Are you on about routing table size again, or something else? >> >> >>> On May 31, 2007, at 4:39 PM, John Santos wrote: >>> >>>> It is the 2000 customers who would have to pay the cost. It may be >>>> small for each, but its cumulative, and will certainly generating lots >>>> of support calls back to Leroy's company. >>>> >>>> My company is in a similar situation to Leroy's customers. We have an >>>> external mail filtering service. Our published MX records point to >>>> the service, and they then forward the (filtered for spam, viruses, >>>> RBL, etc.) mail to us, so we have had to open up our firewall to SMTP >>>> from their specific IP addresses. We are certainly *not* going to let >>>> them manage our firewalls for us, nor are we going to willy-nilly >>>> change >>>> our firewall rules on their request without minimally verifying the >>>> origin of the request (a support call to them.) Multiply by several >>>> thousand customers. >>>> >>>> If they were to start changing IP addresses frequently, we would start >>>> looking for a new service provider. >>>> >>>> This is an *extremely* unlevel playing field, since ACME GIANT ASP, >>>> INC. (which is many times the size of Leroy's company), could easily >>>> justify an allocation, and thus could promise their customers that >>>> their IP addresses and firewall rule would never change. >>>> >>> -- >>> Jo Rhett >>> senior geek >>> >>> Silicon Valley Colocation >>> Support Phone: 408-400-0550 >>> >>> >>> >>> >>> >>> >>> >> >> > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From jlewis at lewis.org Thu Jun 7 18:54:54 2007 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 7 Jun 2007 18:54:54 -0400 (EDT) Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <700EAF4E-44AD-412B-8BBA-0AE3EB540BE1@delong.com> References: <1070607055425.24656B-100000@Ives.egh.com> <466863B5.3090305@mcsnet.ca> <700EAF4E-44AD-412B-8BBA-0AE3EB540BE1@delong.com> Message-ID: On Thu, 7 Jun 2007, Owen DeLong wrote: > 3. This would only apply to companies willing to spend enough to get > a router capable of really multihoming with full BGP, etc., so, I The flaw there is any router that supports BGP can be used by an end-user network to multihome. Nobody says they have to take more than default routes from each provider. There is no "cost of full BGP router" barrier to entry. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From JOHN at egh.com Thu Jun 7 19:19:13 2007 From: JOHN at egh.com (John Santos) Date: Thu, 7 Jun 2007 19:19:13 -0400 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <91169.1181250033@sa.vix.com> Message-ID: <1070607185443.24656A-100000@Ives.egh.com> On Thu, 7 Jun 2007, Paul Vixie wrote: > > The magic words, "private network", appeared in the next paragraph > > you snipped, don't remember if I made it clear I was talking about > > private internets, not intranets. > > what's a "private" internet? I mean an internet (a network of networks) between different organizations, but not (directly) accessible to the Internet. Connections could be via private lines, VPN tunnels over the public Internet, dialup, or whatever. An "intranet" is a network within an organization, which doesn't necessarily face the same problems. Much has been made of the definition of "the Internet" as the largest set of host defined by the relation "reachable by each other" (as I understand it) in some recent posts. There are many other internets, networks encompassing cooperating entities, which contain hosts that are not reachable from the Internet at large but are reachable by each other, and which have some hosts that are part of "the Internet." They need non-colliding addresses. RFC1918 might work fine, if a single person or group were managing address assignments (and the private internet were small enough), but I'm talking about intERnets, not intRAnets, that is, these networks belong to and are managed by different people, groups, companies, or organizations, so RFC1918 addresses are very likely to collide. Assigning unique addresses to all the involved organizations would prevent the collisions. I realize that given the pending crunch in ipv4 addresses, it may not be possible/practical to assign even /24's to all organizations who might need them, but there is *no excuse* for not allowing for this in ipv6. Whether it is ULA-C or PI is immaterial. > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From bmanning at karoshi.com Thu Jun 7 20:06:00 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Fri, 8 Jun 2007 00:06:00 +0000 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <1070607185443.24656A-100000@Ives.egh.com> References: <91169.1181250033@sa.vix.com> <1070607185443.24656A-100000@Ives.egh.com> Message-ID: <20070608000600.GA18535@vacation.karoshi.com.> On Thu, Jun 07, 2007 at 07:19:13PM -0400, John Santos wrote: > On Thu, 7 Jun 2007, Paul Vixie wrote: > > > > The magic words, "private network", appeared in the next paragraph > > > you snipped, don't remember if I made it clear I was talking about > > > private internets, not intranets. > > > > what's a "private" internet? > > I mean an internet (a network of networks) between different > organizations, but not (directly) accessible to the Internet. > Connections could be via private lines, VPN tunnels over the > public Internet, dialup, or whatever. in this case, where (I)nternet is defined as the network you are on. this "private" (i)nternet is filtered from you and your PERCEPTION of what the (I)nternet is. > Much has been made of the definition of "the Internet" as the largest > set of host defined by the relation "reachable by each other" (as I > understand it) in some recent posts. There are many other internets, > networks encompassing cooperating entities, which contain hosts that > are not reachable from the Internet at large but are reachable by each > other, and which have some hosts that are part of "the Internet." They > need non-colliding addresses. RFC1918 might work fine, if a single person > or group were managing address assignments (and the private internet were > small enough), but I'm talking about intERnets, not intRAnets, that is, > these networks belong to and are managed by different people, groups, > companies, or organizations, so RFC1918 addresses are very likely to > collide. Assigning unique addresses to all the involved organizations > would prevent the collisions. I realize that given the pending crunch > in ipv4 addresses, it may not be possible/practical to assign even /24's > to all organizations who might need them, but there is *no excuse* for > not allowing for this in ipv6. Whether it is ULA-C or PI is immaterial. > > > _______________________________________________ > > This message sent to you through the ARIN Public Policy Mailing List > > (PPML at arin.net). > > Manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml > > > > > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From Paul_Vixie at isc.org Thu Jun 7 21:52:37 2007 From: Paul_Vixie at isc.org (Paul_Vixie at isc.org) Date: Fri, 08 Jun 2007 01:52:37 +0000 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: Your message of "Thu, 07 Jun 2007 19:19:13 -0400." <1070607185443.24656A-100000@Ives.egh.com> References: <1070607185443.24656A-100000@Ives.egh.com> Message-ID: <23712.1181267557@sa.vix.com> > > > The magic words, "private network", appeared in the next paragraph > > > you snipped, don't remember if I made it clear I was talking about > > > private internets, not intranets. > > > > what's a "private" internet? > > I mean an internet (a network of networks) between different > organizations, but not (directly) accessible to the Internet. that's far from definitive. first off, by "the Internet" you seem to mean what some people call the default free zone (DFZ) but you might be using breidbart's definition, which i've quoted a time or two here recently but here it is again: >> But what *IS* the internet? > It's the largest equivalence class in the reflexive transitive > symmetric closure of the relationship "can be reached by an IP > packet from". --Seth Breidbart second and more importantly, if i'm a member of more than one of these "private internets," say one between "different organzations" A,B,C,D and one between "different organizations" D,E,F,G where i am "D", what am i? third and finally, if the rest of the world nukes itself in spam and ddos and "different organizations" A,B,C,D,E,F,G decide to form their own "the internet", or are the last networks standing after the spamocaust such that we qualify under breidbart's definition, then what am i? > Much has been made of the definition of "the Internet" as the largest > set of host defined by the relation "reachable by each other" (as I > understand it) in some recent posts. There are many other internets, > networks encompassing cooperating entities, which contain hosts that > are not reachable from the Internet at large but are reachable by each > other, and which have some hosts that are part of "the Internet." i agree that any network of networks is "an internet". it remains to be seen whether your use of the term "the internet" reaches the same concept in my head as it does in yours. word definitions may not matter if we simply avoid disputes and ambiguity. a network is "private" if it's not connected to most other networks, but clearly it could still be connected to some other networks and still be "private". while the U in ULA ("unique") is clearly beneficial since a network might be less private at some parts of its life cycle than at others, and collisions are painful, the L in ULA ("local") is unclearly unbeneficial since during the times in its life cycle when a network is less private, it might be painful to have someone refuse a third party route on the basis of its policywise L-ness. > They need non-colliding addresses. all RIR allocations (PI or PA) are non-colliding ("unique"), so this part is already handled. > RFC1918 might work fine, if a single person or group were managing address > assignments (and the private internet were small enough), but I'm talking > about intERnets, not intRAnets, that is, these networks belong to and are > managed by different people, groups, companies, or organizations, so RFC1918 > addresses are very likely to collide. i'm not proposing that you use RFC1918 or IPV6 "site local" for this kind of network. > Assigning unique addresses to all the involved organizations would prevent > the collisions. agreed. for example, PI or PA. > I realize that given the pending crunch in ipv4 addresses, it may not be > possible/practical to assign even /24's to all organizations who might need > them, but there is *no excuse* for not allowing for this in ipv6. also agreed. > Whether it is ULA-C or PI is immaterial. here, i disagree. ULA would be a waste of address space, and administrative effort. there's more space available for PA and PI than will ever fit in the DFZ. your argument supports a policy for smaller-size PI allocations which may be cheaper and may be easier to qualify for and may be allocated out of a well known /10 to make them safe from static TE-resistant route filters, but no argument i've seen here supports a policy for "unique local addresses". From JOHN at egh.com Fri Jun 8 03:01:05 2007 From: JOHN at egh.com (John Santos) Date: Fri, 8 Jun 2007 03:01:05 -0400 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <23712.1181267557@sa.vix.com> Message-ID: <1070608021151.24220A-100000@Ives.egh.com> On Fri, 8 Jun 2007 Paul_Vixie at isc.org wrote: > > > > The magic words, "private network", appeared in the next paragraph > > > > you snipped, don't remember if I made it clear I was talking about > > > > private internets, not intranets. > > > > > > what's a "private" internet? > > > > I mean an internet (a network of networks) between different > > organizations, but not (directly) accessible to the Internet. > > that's far from definitive. first off, by "the Internet" you seem to mean > what some people call the default free zone (DFZ) but you might be using > breidbart's definition, which i've quoted a time or two here recently but > here it is again: > > >> But what *IS* the internet? > > It's the largest equivalence class in the reflexive transitive > > symmetric closure of the relationship "can be reached by an IP > > packet from". --Seth Breidbart > Actually, that was what I was trying to summarize in smaller words, but which definition gets used is unimportant. > second and more importantly, if i'm a member of more than one of these > "private internets," say one between "different organzations" A,B,C,D and > one between "different organizations" D,E,F,G where i am "D", what am i? Then you're like me :-) I'm not sure what that makes you, but whatever it is, I'm sure you would like to have a set of IP addresses don't don't collide with any of A, B, C, E, F or G. > > third and finally, if the rest of the world nukes itself in spam and ddos > and "different organizations" A,B,C,D,E,F,G decide to form their own > "the internet", or are the last networks standing after the spamocaust > such that we qualify under breidbart's definition, then what am i? > > > Much has been made of the definition of "the Internet" as the largest > > set of host defined by the relation "reachable by each other" (as I > > understand it) in some recent posts. There are many other internets, > > networks encompassing cooperating entities, which contain hosts that > > are not reachable from the Internet at large but are reachable by each > > other, and which have some hosts that are part of "the Internet." > > i agree that any network of networks is "an internet". it remains to be > seen whether your use of the term "the internet" reaches the same concept > in my head as it does in yours. word definitions may not matter if we > simply avoid disputes and ambiguity. > > a network is "private" if it's not connected to most other networks, but > clearly it could still be connected to some other networks and still be > "private". while the U in ULA ("unique") is clearly beneficial since a > network might be less private at some parts of its life cycle than at > others, and collisions are painful, the L in ULA ("local") is unclearly > unbeneficial since during the times in its life cycle when a network is > less private, it might be painful to have someone refuse a third party > route on the basis of its policywise L-ness. > > > They need non-colliding addresses. > > all RIR allocations (PI or PA) are non-colliding ("unique"), so this part > is already handled. > Yes, but if my network is too small to qualify for a PI or PA under current policy??? > > RFC1918 might work fine, if a single person or group were managing address > > assignments (and the private internet were small enough), but I'm talking > > about intERnets, not intRAnets, that is, these networks belong to and are > > managed by different people, groups, companies, or organizations, so RFC1918 > > addresses are very likely to collide. > > i'm not proposing that you use RFC1918 or IPV6 "site local" for this kind > of network. > > > Assigning unique addresses to all the involved organizations would prevent > > the collisions. > > agreed. for example, PI or PA. > > > I realize that given the pending crunch in ipv4 addresses, it may not be > > possible/practical to assign even /24's to all organizations who might need > > them, but there is *no excuse* for not allowing for this in ipv6. > > also agreed. > > > Whether it is ULA-C or PI is immaterial. > > here, i disagree. ULA would be a waste of address space, and administrative > effort. there's more space available for PA and PI than will ever fit in the > DFZ. your argument supports a policy for smaller-size PI allocations which > may be cheaper and may be easier to qualify for and may be allocated out of > a well known /10 to make them safe from static TE-resistant route filters, > but no argument i've seen here supports a policy for "unique local addresses". Well, I agree with that, but that wasn't my point. My point was I need (in the sense of "would really really really like to have") unique addresses, and whether they are ULA-C or PI or whatever doesn't matter to *me*. If one of these solutions is better than the others from someone else's standpoint, then that's fine with me, as long as I get my unique addresses. Here is my wish-list of what I want/need out of an address policy for ipv6: 1) Globally unique addresses 2) Relatively small number of them (for ipv4, a /24 is plenty. I don't know for ipv6; I haven't messed around with it yet, one of the obstacles is knowing what addresses to use. :-) 3) Relatively cheap 4) Permanent 5) Low-maintenance (I would be making few if any changes, seldom if ever requesting more space, etc., so registry overhead should be very low.) 6) Global routing is not needed. (I would be using these addresses locally or over private networks where the manual one-time effort of setting up routes, firewall filters, etc. would be fine.) I think lots (how many is "lots", I have no idea, but there have been others posting here who seem to be in the same situation) of other people/organizations are in the same situation. And lots more would differ only on point 6, i.e. other people would like or require global routing. Indeed it would be nice to have but for me isn't essential. Maybe someday, someone will solve the routing table scaling problem, and it will become a non-issue. The way I see it, ULA-C has been proposed as a solution to most of these items. To summarize the arguments for and against it, F1) It would be cheaper/easier to administer than PI. (Some dispute this, saying it would be just as much work for ARIN.) F2) It would be easy to filter at the edge routers, since it would all be in a single address block. (But you would have to be able to turn this off if you wanted to use said router within a ULA-C network instead of at the edge of one.) F3) It could be distributed in smaller chunks than PI. (But PI could also be distributed in smaller chunks, too. This is just a matter of Policy. But then backbone people don't want to route the smaller chunks since too many of them would swamp their routers' routing tables, but then again, there is no intention of globally routing ULA-C packets, so the addresses shouldn't end up in the routing tables in the first place.) The arguments against seem to be: A1) It doesn't do anything PI doesn't already do. (See arguments for...) A2) Someday you might want to route the ULA-C addresses, so you'll either have to renumber to PI or convince the world to disable the ULA-C filters mentioned in argument F2. Might just as well start with PI and avoid all this. Did I miss anything? -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From michael.dillon at bt.com Fri Jun 8 04:05:45 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 8 Jun 2007 09:05:45 +0100 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <23712.1181267557@sa.vix.com> References: <1070607185443.24656A-100000@Ives.egh.com> <23712.1181267557@sa.vix.com> Message-ID: > > I mean an internet (a network of networks) between different > > organizations, but not (directly) accessible to the Internet. > > that's far from definitive. first off, by "the Internet" you > seem to mean what some people call the default free zone > (DFZ) but you might be using breidbart's definition, which > i've quoted a time or two here recently but here it is again: > > >> But what *IS* the internet? > > It's the largest equivalence class in the reflexive transitive > > symmetric closure of the relationship "can be reached by an IP > > packet from". --Seth Breidbart I think he is using his own definition, not some witty mathematico-grammatical repartee from someone I've never heard of. Let's stick with John's clear and understandable definition and lose the tortured prose of this Breidbart fellow. > second and more importantly, if i'm a member of more than one > of these "private internets," say one between "different > organzations" A,B,C,D and one between "different > organizations" D,E,F,G where i am "D", what am i? You are a typical enterprise network. In other words, the situation that you describe is rather common. > third and finally, if the rest of the world nukes itself in > spam and ddos and "different organizations" A,B,C,D,E,F,G > decide to form their own "the internet", or are the last > networks standing after the spamocaust such that we qualify > under breidbart's definition, then what am i? Then you are committed to a mental institution after overdosing on a cocktail of drugs. Where else would you get the idea that spam and ddos cause nuclear holocaust. This is a reductio ad absurdum if ever I saw one. > a network is "private" if it's not connected to most other > networks, but clearly it could still be connected to some > other networks and still be "private". Not under the RFC 1918 definition. --Michael Dillon From Paul_Vixie at isc.org Fri Jun 8 09:46:31 2007 From: Paul_Vixie at isc.org (Paul_Vixie at isc.org) Date: Fri, 08 Jun 2007 13:46:31 +0000 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: Your message of "Fri, 08 Jun 2007 03:01:05 -0400." <1070608021151.24220A-100000@Ives.egh.com> References: <1070608021151.24220A-100000@Ives.egh.com> Message-ID: <99507.1181310391@sa.vix.com> > > > They need non-colliding addresses. > > > > all RIR allocations (PI or PA) are non-colliding ("unique"), so this part > > is already handled. > > Yes, but if my network is too small to qualify for a PI or PA under current > policy??? i'd previously written about part of that: > > ... your argument supports a policy for smaller-size PI allocations which > > may be cheaper and may be easier to qualify for and may be allocated out > > of a well known /10 to make them safe from static TE-resistant route > > filters, but no argument i've seen here supports a policy for "unique > > local addresses". it's worth noting that networks might not have a provider and so PA might not be a sensible way to number such networks. i do wonder if a tunnel provider acting as a LIR for the administrative purpose of keeping whois and in-addr up to date could be a business somebody might want to be in. > Well, I agree with that, but that wasn't my point. My point was I need (in > the sense of "would really really really like to have") unique addresses, > and whether they are ULA-C or PI or whatever doesn't matter to *me*. If one > of these solutions is better than the others from someone else's standpoint, > then that's fine with me, as long as I get my unique addresses. to me, this is the best and clearest statement so far of the reason ULA has been proposed. everybody needs unique addresses, even if they're unconnected at present, or if their only connections aren't to the DFZ at present. back in the day, i made decent money as a contractor, building 192.9.200 and/or 192.9.201 (sun's networks, used in sun's documentation) everywhere, and then later i made indecent money renumbering these networks as they got connected. we ought, if possible, to avoid making *another* market for those services. > Here is my wish-list of what I want/need out of an address policy for ipv6: > > 1) Globally unique addresses > 2) Relatively small number of them > (for ipv4, a /24 is plenty. I don't know for ipv6; I haven't messed > around with it yet, one of the obstacles is knowing what addresses to > use. :-) > 3) Relatively cheap > 4) Permanent see below. you're doing great though. > 5) Low-maintenance > (I would be making few if any changes, seldom if ever requesting > more space, etc., so registry overhead should be very low.) > 6) Global routing is not needed. > (I would be using these addresses locally or over private networks > where the manual one-time effort of setting up routes, firewall > filters, etc. would be fine.) regarding (4), nothing is permanent. the pre-RIR legacy allocations for which no contracts exist and many contact information is lost or stale, are an extraordinary and untenable burden on the internet system, for a lot of different reasons. all new allocations are governed and essentially ephemeral -- and one of the reasons for this is so that if a company goes out of existence and stops paying its annual nuisance fee to the RIR, then the address space they were using automatically goes back into the pool. no policy for allocation can afford to leave out this essential element, even if we somehow approve a policy for special allocations for unconnected or not-part-of-DFZ networks. as for (5), there is no basis for suggesting that address space allocated under an "unconnected" policy would need less maintainance than address space allocated otherwise. whois and in-addr are either up to date or not; companies change their addresses or hire new personnel or are merge/acquired or not; etc. but as for (6), it's "the rub". you don't know at the time you create a network what it might eventually want to be connected to. perhaps you'll connect it to your local community wireless network through an IXP or through kc's COMMONS. it still wouldn't have a default route and it still would not be part of the DFZ, but it would no longer be "unconnected". there just isn't a workable definition of "global" or "global routing" that will sit still long enough for us to write policy about it -- and if there were, we'd merely have earned the opportunity to renumber our "partially connected" networks on the day when they finally do connect to the DFZ. > The way I see it, ULA-C has been proposed as a solution to most of > these items. To summarize the arguments for and against it, > > F1) It would be cheaper/easier to administer than PI. > (Some dispute this, saying it would be just as much work for ARIN.) > > F2) It would be easy to filter at the edge routers, since it would > all be in a single address block. (But you would have to be able > to turn this off if you wanted to use said router within a ULA-C > network instead of at the edge of one.) > > F3) It could be distributed in smaller chunks than PI. (But PI > could also be distributed in smaller chunks, too. This is just a > matter of Policy. But then backbone people don't want to route the > smaller chunks since too many of them would swamp their routers' > routing tables, but then again, there is no intention of globally > routing ULA-C packets, so the addresses shouldn't end up in the > routing tables in the first place.) > > The arguments against seem to be: > > A1) It doesn't do anything PI doesn't already do. > (See arguments for...) > > A2) Someday you might want to route the ULA-C addresses, so you'll > either have to renumber to PI or convince the world to disable > the ULA-C filters mentioned in argument F2. Might just as well > start with PI and avoid all this. > > Did I miss anything? yes, two things. in (F2) you're presuming that everyone connected to the DFZ will want to filter this stuff. some networks have a promiscuous peering policy and would be happy to hear these routes. you're also assuming that the intent of the network owners will be "unconnection", whereas i believe that through confusion or malice, many network owners could end up trying very hard to connect these allocated-as-"local" networks. the combination of these two factors spells doom for (F2). and i think you're missing (A3) which is that IPv6 transforms a balanced shortage, where we run out of DVRP capacity and address space at roughly the same time and we just have to argue "minimum allocation size" in order to ensure that we run out of both at the same time, into an unbalanced shortage where we'll hit and remain at the DVRP wall for the lifetime of the system even though vast tracts of address space remain unallocated. so there isn't a digital-economy basis for smaller/cheaper allocations meant for "unconnected" networks. (but there does seem to be one for small-PI, which many DFZ operators would just filter from day 1, if we allocate them with a consistent enough prefix.) From spetty at iconnect-corp.com Fri Jun 8 10:19:12 2007 From: spetty at iconnect-corp.com (Steven E. Petty) Date: Fri, 8 Jun 2007 10:19:12 -0400 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks Message-ID: <428E6440939F654F8BD72C49361E855FB951AD@host252.iconnect-corp.com> One example would be the Automotive Network eXchange (ANX). Though it currently allows addresses to be reachable from the general internet as an option, it was originally supposed to be entirely seperate. Only used by a few small companies.. Ford, Chrysler, GM, their tier 1 suppliers and VANs... http://en.wikipedia.org/wiki/Automotive_Network_Exchange -----Original Message----- From: John Santos [mailto:JOHN at egh.com] Sent: Thursday, June 07, 2007 7:19 PM To: Paul Vixie Cc: Public Policy Mailing List Subject: Re: [ppml] Suggestion for ARIN to deligate smaller IP blocks On Thu, 7 Jun 2007, Paul Vixie wrote: > > The magic words, "private network", appeared in the next paragraph > > you snipped, don't remember if I made it clear I was talking about > > private internets, not intranets. > > what's a "private" internet? I mean an internet (a network of networks) between different organizations, but not (directly) accessible to the Internet. Connections could be via private lines, VPN tunnels over the public Internet, dialup, or whatever. An "intranet" is a network within an organization, which doesn't necessarily face the same problems. Much has been made of the definition of "the Internet" as the largest set of host defined by the relation "reachable by each other" (as I understand it) in some recent posts. There are many other internets, networks encompassing cooperating entities, which contain hosts that are not reachable from the Internet at large but are reachable by each other, and which have some hosts that are part of "the Internet." They need non-colliding addresses. RFC1918 might work fine, if a single person or group were managing address assignments (and the private internet were small enough), but I'm talking about intERnets, not intRAnets, that is, these networks belong to and are managed by different people, groups, companies, or organizations, so RFC1918 addresses are very likely to collide. Assigning unique addresses to all the involved organizations would prevent the collisions. I realize that given the pending crunch in ipv4 addresses, it may not be possible/practical to assign even /24's to all organizations who might need them, but there is *no excuse* for not allowing for this in ipv6. Whether it is ULA-C or PI is immaterial. > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From dave at mvn.net Fri Jun 8 10:21:41 2007 From: dave at mvn.net (David E. Smith) Date: Fri, 08 Jun 2007 09:21:41 -0500 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: References: <1070607055425.24656B-100000@Ives.egh.com> <466863B5.3090305@mcsnet.ca> <700EAF4E-44AD-412B-8BBA-0AE3EB540BE1@delong.com> Message-ID: <466965F5.2090105@mvn.net> Jon Lewis wrote: > The flaw there is any router that supports BGP can be used by an end-user > network to multihome. Nobody says they have to take more than default > routes from each provider. There is no "cost of full BGP router" barrier > to entry. Even if there were, the cost is trivial. I'm running my network (a /19 with full BGP feed) on a $500 PC. And the only reason it cost that much is because the boss wanted something rack-mountable. Anyway, a tangent. My company used to have a /20, but we got to about 80% utilization on that, and I asked for a bit more space (I think I requested an additional /22). I asked for the space I knew I'd need in the next year or so, per the guidelines. ARIN gave me a second /20, quite a bit larger than what I requested. There's a bit of convenience to it, in that they gave me a /20 adjacent to my previous one, so I can aggregate the announcements and only advertise a single /19. Assuming my company keeps growing, the space will eventually get used (though it may be a couple more years). I assume I was given this specific additional allocation because it was adjacent, and to keep me to a meager one BGP announcement. In the meantime, though, I've got a couple thousand IPs that I'm not (presently) using. Is it better to have folks like me potentially sitting on address space that someone else could be using now? Or is it better to try to keep the global routing table from ballooning even more? David Smith MVN.net From Ed.Lewis at neustar.biz Fri Jun 8 11:38:15 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 8 Jun 2007 11:38:15 -0400 Subject: [ppml] Difference between ULA-C and PI In-Reply-To: References: <11FE30C1-C8B7-4242-B379-64CF71882FB2@delong.com> <77B56247-A452-4355-8BA1-3B5B1C8608A8@virtualized.org> Message-ID: I'm not going to compare PI to ULA-C as the latter isn't well defined (no draft) - but - for the sake of seeing if I'm understanding the discussion: Comparing PI and to some addressing scheme that is purported to not be in the DFZ: 1) Both are the same amount of work and benefit to the RIRS. 2) PI puts a route into the DFZ, the other thing doesn't. The latter point makes the non-routed address scheme less "costly" to network operations. OTOH, as both are the same in the registration process I would think that they are the same under all other RIR policies (cost sharing, reporting, whois/in-addr, etc.) At least this is what I have gathered from reading the threads on this. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From randy at psg.com Fri Jun 8 11:42:45 2007 From: randy at psg.com (Randy Bush) Date: Fri, 08 Jun 2007 08:42:45 -0700 Subject: [ppml] Difference between ULA-C and PI In-Reply-To: References: <11FE30C1-C8B7-4242-B379-64CF71882FB2@delong.com> <77B56247-A452-4355-8BA1-3B5B1C8608A8@virtualized.org> Message-ID: <466978F5.30300@psg.com> > 2) PI puts a route into the DFZ, the other thing doesn't. close, but not exactly. PI allows holder to announce to dfz or not, as they choose. and, as smb says, you may think you don't want to connect it to the internet now. but some day you will. randy From Paul_Vixie at isc.org Fri Jun 8 11:45:04 2007 From: Paul_Vixie at isc.org (Paul_Vixie at isc.org) Date: Fri, 08 Jun 2007 15:45:04 +0000 Subject: [ppml] Difference between ULA-C and PI In-Reply-To: Your message of "Fri, 08 Jun 2007 11:38:15 -0400." References: <11FE30C1-C8B7-4242-B379-64CF71882FB2@delong.com> <77B56247-A452-4355-8BA1-3B5B1C8608A8@virtualized.org> Message-ID: <15424.1181317504@sa.vix.com> ed said that the situation wasn't well defined and then: > 2) PI puts a route into the DFZ, the other thing doesn't. maybe PI puts a route into the DFZ, maybe not. maybe it puts zero routes in (fallow) or maybe it puts multiple TE routes in (grazing the commons). maybe the other thing doesn't put a route into the DFZ, but it could still put one into the automotive network exchange, or COMMONS, or elsewhere. > The latter point makes the non-routed address scheme less "costly" to > network operations. maybe. in fact, double-maybe. > At least this is what I have gathered from reading the threads on this. and then again, maybe not. From owen at delong.com Fri Jun 8 12:11:55 2007 From: owen at delong.com (Owen DeLong) Date: Fri, 8 Jun 2007 09:11:55 -0700 Subject: [ppml] Difference between ULA-C and PI In-Reply-To: References: <11FE30C1-C8B7-4242-B379-64CF71882FB2@delong.com> <77B56247-A452-4355-8BA1-3B5B1C8608A8@virtualized.org> Message-ID: <824A7309-B03E-41E8-9B50-2D62A1DDF77A@delong.com> On Jun 8, 2007, at 8:38 AM, Edward Lewis wrote: > I'm not going to compare PI to ULA-C as the latter isn't well defined > (no draft) - but - for the sake of seeing if I'm understanding the > discussion: > > Comparing PI and to some addressing scheme that is purported to not > be in the DFZ: > > 1) Both are the same amount of work and benefit to the RIRS. > > 2) PI puts a route into the DFZ, the other thing doesn't. > Um, no. There is some attempt at muddying the waters by trying to build this illusion into the discussion, but, in actual fact, PI issued to a non-connected network would not likely put a route in the DFZ. The other thing issued to a network that couldn't qualify for connected PI through some less scrutinized process, OTOH, will eventually result in those prefixes showing up in the DFZ for at least some definitions of the DFZ. > The latter point makes the non-routed address scheme less "costly" to > network operations. OTOH, as both are the same in the registration > process I would think that they are the same under all other RIR > policies (cost sharing, reporting, whois/in-addr, etc.) > One would hope, but, the answers to those questions are part of what is not yet clear from the lack of definition/draft. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2105 bytes Desc: not available URL: From jeroen at unfix.org Fri Jun 8 12:59:09 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 08 Jun 2007 17:59:09 +0100 Subject: [ppml] Avoiding Square 0 (IPv4 NAT at endusers) (Was: Difference between ULA-C and PI) In-Reply-To: <466978F5.30300@psg.com> References: <11FE30C1-C8B7-4242-B379-64CF71882FB2@delong.com> <77B56247-A452-4355-8BA1-3B5B1C8608A8@virtualized.org> <466978F5.30300@psg.com> Message-ID: <46698ADD.4010102@spaghetti.zurich.ibm.com> Randy Bush wrote: >> 2) PI puts a route into the DFZ, the other thing doesn't. > > close, but not exactly. PI allows holder to announce to dfz or not, as > they choose. > > and, as smb says, you may think you don't want to connect it to the > internet now. but some day you will. I fully agree with this statement. As such the ONLY "value" that ULA brings is for the dentists-office scenario, where one simply plugs in a couple of boxes on a network, where one of those boxes acts as a router which generates a ULA (not C) and then uses that on the local network. This though will cause only one thing in the end: ISP's will be giving out /128's to endusers and the enduser will use ULAs which are autogenerated anyway, box will NAT and we are back to square 0. As such, as this is the ARIN Policy mailinglist afterall, might I propose the following the following: ARIN (and other RIRs) set up a web-based form where end-users(*1) of PA address space, which they receive from their ISP can complain, if their ISP is not willing to provide them with a /48(*2) but is giving them a /128. This way end-users can report to ARIN that an ISP, even though they are getting the /32 or larger from ARIN with the intention of providing /48's to end-sites is actually not doing so. Then ARIN can nicely contact the ISP and raise this to them that they are not fulfilling their duty, the ones they justified the address space for in the first place. Any ISP who is not willing to provide a /48 to an enduser should not be able to get a /32 or similar allocation in the first place. In the above, 'paying extra for a /48' (and thus cashing in on address space) should not be allowed either. If an ISP want to limit traffic usage*3 then they should set up proper limits and say "you are allowed to transfer X up / Y down of data", this is already common place. *1 = home users: your mom&pops&grannie&you&me, companies etc. *2 = /48's might soon change to /56's, at least there is a proposal in the RIPE region for this, which IMHO is quite acceptable. *3 = Address bits are 'free', ISP's pay their transits for traffic, they don't pay their transit for the amount of address space they are using either, so why should the enduser? Greets, Jeroen Donned in a stylish flexible but thick and fire/water/air/bulletproof kevlar asbestos suite as the above will nicely impact a lot of people's business models who will not like the above ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From Paul_Vixie at isc.org Fri Jun 8 13:51:15 2007 From: Paul_Vixie at isc.org (Paul_Vixie at isc.org) Date: Fri, 08 Jun 2007 17:51:15 +0000 Subject: [ppml] [address-policy-wg] Those pesky ULAs again In-Reply-To: Your message of "Fri, 08 Jun 2007 18:44:04 +0200." References: <2A1C7480-E7C9-4259-B449-188EE6B52F36@muada.com> <000601c7a0b2$8b8f5dc0$7301a8c0@atlanta.polycom.com> <00EEA6ED-DDA2-41F1-B6DF-F927F444F424@muada.com> <28749.83.109.229.46.1180356371.squirrel@webmail.e-konsult.no> <007601c7a1a3$35dc4e00$343816ac@atlanta.polycom.com> <465BA1B9.1060003@psg.com> <031b01c7a1ca$64904270$dc128953@kantoor.computel.nl> <465BE3AB.8040305@psg.com> <20070529091805.GA15655@borg.c-l-i.net> <20070529100000.GA16216@borg.c-l-i.net> <465C3FDE.7050708@psg.com> <200705300249.l4U2ndVH019658@cichlid.raleigh.ibm.com> <7C441817-6409-48D2-8599-1EE7A6FAC0F7@antel.net.uy> <46680E07.7030501@psg.com> <51726.1181226670@sa.vix.com> Message-ID: <38529.1181325075@sa.vix.com> > > but since we could never possibly fit all of ipv6 into the DFZ, and since > > the cost and availability of pi is theoretically manageable by us (the RIR > > system) to make sure everybody who needs it can get and can afford it, i > > fail to see the virtue of making some of it cheaper and worth less. > > Well, I was really in favour of ULA-C but now given some time and after > listning to all of the arguments, and maybe most important I realized one > huge thing that ULA-C maybe can't provide, DNS, which leave it useless for > our usage. > > Without reverse DNS possibility ULA-C is useless. i agree, but i think that the implications of your statement are very telling. if these addresses really did correspond to "private" networks, then reverse dns could be managed with cutouts, much as is done for RFC 1918 in-addrs now. but since we all expect that these "private" networks will be interconnected among private (non-transit) relationships, we know that the entity seeing one of these "private" addresses and needing to know the PTR for it may not have a direct relationship to the owner of the network using the address. that's another way of saying that these addresses are not actually private, or local; the fact that they aren't intended to be carried in the DFZ matters not at all. > On the other hand, why do we need PI? What we need is a policy that make > sure those that could gain from ULA-C can get public routable IP space, and > then they can themself decide if they want to route it or not. It's possible > and upto them. > > If we have to call it PI then so be it... I really dislike the name but I > can live with it. for this discussion, i think we should forget about the distinction between PI and PA, which only make sense when there is a "provider." perhaps the automotive exchange network will be an LIR for assigning network numbers to its members, or perhaps not. the term we've probably been looking for is UA (unique address, or universal address) in comparison to IPv6 "site local" or IPv4 RFC1918 (which are nonunique and nonuniversal; sometimes "ambiguous"). everybody needs UA, whether they have a provider or not. some UA's will be in the DFZ and some not, according to the business needs of the network owner. one of those business needs is "nobody will route PI UA for me" or "the cost of routing PI UA is very high" and so, some UA will be PA UA. that's not a RIR issue per se, other than that it may drive policy toward smaller/cheaper UA allocations which all come from some particular /10 so that draconian DFZ router operators can reject these routes if they don't originate in peers. From jmorrison at bogomips.com Fri Jun 8 14:35:03 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Fri, 08 Jun 2007 11:35:03 -0700 Subject: [ppml] Avoiding Square 0 (IPv4 NAT at endusers) (Was: Difference between ULA-C and PI) In-Reply-To: <46698ADD.4010102@spaghetti.zurich.ibm.com> References: <11FE30C1-C8B7-4242-B379-64CF71882FB2@delong.com> <77B56247-A452-4355-8BA1-3B5B1C8608A8@virtualized.org> <466978F5.30300@psg.com> <46698ADD.4010102@spaghetti.zurich.ibm.com> Message-ID: <4669A157.1000705@bogomips.com> Seconded. IPv4 address space is already abused by service providers to "up-sell" services, there's no reason to think it won't continue with IPv6. IP addresses are not supposed to be property and addresses are supposed to be allocated on need. Except if you're an end user, then you have to step up and pay for them. e.g Basic Service A comes with 4 ip addresses, Enhanced Service B comes with 8 but costs $100 more - which makes the consumer think IP addresses are "assets" or a tangible commodity that the ISP has the right (or even obligation) to charge for, instead of just some arbitrary bits that cost almost nothing to administer. But NAT is not going to disappear unless there's a simple, standard way to receive or register your own IPv6 prefix. Maybe you already do - aren't we overlooking 2002::/16? Everyone with an IPv4 address gets their own /48 already. The RFCs say these can be used for native IPv6, although the primary use is in 6to4 tunnels. Jeroen Massar wrote: > As such, as this is the ARIN Policy mailinglist afterall, might I > propose the following the following: > > ARIN (and other RIRs) set up a web-based form where end-users(*1) > of PA address space, which they receive from their ISP can complain, > if their ISP is not willing to provide them with a /48(*2) but is > giving them a /128. > > This way end-users can report to ARIN that an ISP, even though they are > getting the /32 or larger from ARIN with the intention of providing > /48's to end-sites is actually not doing so. Then ARIN can nicely > contact the ISP and raise this to them that they are not fulfilling > their duty, the ones they justified the address space for in the first > place. > > Any ISP who is not willing to provide a /48 to an enduser should not be > able to get a /32 or similar allocation in the first place. > > In the above, 'paying extra for a /48' (and thus cashing in on address > space) should not be allowed either. If an ISP want to limit traffic > usage*3 then they should set up proper limits and say "you are allowed > to transfer X up / Y down of data", this is already common place. > > > *1 = home users: your mom&pops&grannie&you&me, companies etc. > *2 = /48's might soon change to /56's, at least there is a proposal in > the RIPE region for this, which IMHO is quite acceptable. > *3 = Address bits are 'free', ISP's pay their transits for traffic, they > don't pay their transit for the amount of address space they are using > either, so why should the enduser? > > > From randy at psg.com Fri Jun 8 14:56:32 2007 From: randy at psg.com (Randy Bush) Date: Fri, 08 Jun 2007 11:56:32 -0700 Subject: [ppml] Avoiding Square 0 (IPv4 NAT at endusers) (Was: Difference between ULA-C and PI) In-Reply-To: <4669A157.1000705@bogomips.com> References: <11FE30C1-C8B7-4242-B379-64CF71882FB2@delong.com> <77B56247-A452-4355-8BA1-3B5B1C8608A8@virtualized.org> <466978F5.30300@psg.com> <46698ADD.4010102@spaghetti.zurich.ibm.com> <4669A157.1000705@bogomips.com> Message-ID: <4669A660.3020407@psg.com> > IPv4 address space is already abused by service providers to > "up-sell" services, there's no reason to think it won't continue with > IPv6. IP addresses are not supposed to be property and addresses are > supposed to be allocated on need. they are. anyone is welcome to show need to the regional IR and get what they need. of course, they have to pay there too. oh, you do not want to pay for so big a chunk? well then, add what it costs to allocate, dns, route, configure, ... those little chunks, and expect to pay that to your upstream isp. life is simple randy From jlewis at lewis.org Fri Jun 8 15:15:25 2007 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 8 Jun 2007 15:15:25 -0400 (EDT) Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <466965F5.2090105@mvn.net> References: <1070607055425.24656B-100000@Ives.egh.com> <466863B5.3090305@mcsnet.ca> <700EAF4E-44AD-412B-8BBA-0AE3EB540BE1@delong.com> <466965F5.2090105@mvn.net> Message-ID: On Fri, 8 Jun 2007, David E. Smith wrote: > In the meantime, though, I've got a couple thousand IPs that I'm not > (presently) using. > > Is it better to have folks like me potentially sitting on address space > that someone else could be using now? Or is it better to try to keep the > global routing table from ballooning even more? That depends on how many of "you" there are and on how successfully you grow. Due to changes in core business, our IP usage has always been difficult if not downright impossible to predict. When I've asked ARIN for more space, we've always gotten much more than we actually ended up using in the short term...but we've always grown and eventually filled it. First we went from a /18 to a /17 (much like you went from a /20 to a /19). Then we got an additional /19. We also have a /20 from an ISP we borged, eventually dismantled, and recycled the space. This has happened over the course of 8 years. Was the fact that at times we had thousands of spare IPs worth the tradeoff that we only announce 3 CIDRs from our ASN? Going "by the book" (if our IP usage had been easily predicted) we'd have gotten many more smaller allocations, and be announcing several times the number of routes. Fewer larger routes benefits everyone. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From iljitsch at muada.com Fri Jun 8 15:37:29 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 8 Jun 2007 21:37:29 +0200 Subject: [ppml] Difference between ULA-C and PI In-Reply-To: <11FE30C1-C8B7-4242-B379-64CF71882FB2@delong.com> References: <11FE30C1-C8B7-4242-B379-64CF71882FB2@delong.com> Message-ID: On 7-jun-2007, at 16:28, Owen DeLong wrote: > As near as I can tell, the only difference between ULA-C and PI > is that ULA-C will potentially have slightly more breakage than PI > because some ISPs will filter at least some of it (as they > theoretically should). > Beyond that, ULA-C is distinguishable from PI only in the minds > of the people who imagine it is a good idea. Are you STILL on this?? Even assuming all the other stuff is true (which it isn't), your position is only valid if PI and ULA-C are equally easy/hard to get. And obviously ULA-C must be very easy to get to do its job, while PI is only easy to get for an incredibly tiny percentage of the organizations connected to the internet. From leroy at emailsorting.com Fri Jun 8 15:44:12 2007 From: leroy at emailsorting.com (Leroy Ladyzhensky) Date: Fri, 8 Jun 2007 15:44:12 -0400 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks References: <1070607055425.24656B-100000@Ives.egh.com><466863B5.3090305@mcsnet.ca><700EAF4E-44AD-412B-8BBA-0AE3EB540BE1@delong.com><466965F5.2090105@mvn.net> Message-ID: <004901c7aa05$63a36700$c80a0a0a@integrated.net> jon, please don't take my tone and sarcasm personally it not directed at you, or anyone in particular.. just my frustrations. you say.. "Fewer larger routes benefits everyone" but what you are actually saying is --- the waste of a limited resource is justified because ... "Fewer larger routes benefits everyone" well.. actually only... ISP's and there hardware budget. so let me try to understand... IP space that is limited to the point that once-they-are-gone----there-gone... and wasting them is justified so ISP's don't have to upgrade hardware?? hardware that you are going to have to upgrade some time in the near future anyway!! so lets just waste IP's now to postpone the growth of the size of the routing table... so we can save some money now... and then in 6,8 months or just a year or 2 max... when the routing table size grows to a point where hardware will have to be upgraded based on current policy and growth... and after that is done... we can think.... hey.. since we can all support a much larger routing table now... lets stop wasting addresses... we can pass out smaller blocks... ohhhhhhh.... that's right there (nearly) gone... how can we get a way from this thinking and begin to move forward... and face it... to actually conserve IP's there needs to be an option to allow smaller allocations.... The ONLY thing that needs to be considered is HOW the smaller allocations get handed out... do the go to anyone who asks.. I would think not... what would be the criteria for a company to get a /24 allocation? any input on this would be great. Thanks ----- Original Message ----- From: "Jon Lewis" To: "David E. Smith" Cc: Sent: Friday, June 08, 2007 3:15 PM Subject: Re: [ppml] Suggestion for ARIN to deligate smaller IP blocks > On Fri, 8 Jun 2007, David E. Smith wrote: > >> In the meantime, though, I've got a couple thousand IPs that I'm not >> (presently) using. >> >> Is it better to have folks like me potentially sitting on address space >> that someone else could be using now? Or is it better to try to keep the >> global routing table from ballooning even more? > > That depends on how many of "you" there are and on how successfully you > grow. Due to changes in core business, our IP usage has always been > difficult if not downright impossible to predict. When I've asked ARIN > for more space, we've always gotten much more than we actually ended up > using in the short term...but we've always grown and eventually filled it. > First we went from a /18 to a /17 (much like you went from a /20 to a > /19). Then we got an additional /19. We also have a /20 from an ISP we > borged, eventually dismantled, and recycled the space. This has happened > over the course of 8 years. Was the fact that at times we had thousands > of spare IPs worth the tradeoff that we only announce 3 CIDRs from our > ASN? Going "by the book" (if our IP usage had been easily predicted) we'd > have gotten many more smaller allocations, and be announcing several times > the number of routes. Fewer larger routes benefits everyone. > > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From randy at psg.com Fri Jun 8 15:54:06 2007 From: randy at psg.com (Randy Bush) Date: Fri, 08 Jun 2007 12:54:06 -0700 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <004901c7aa05$63a36700$c80a0a0a@integrated.net> References: <1070607055425.24656B-100000@Ives.egh.com><466863B5.3090305@mcsnet.ca><700EAF4E-44AD-412B-8BBA-0AE3EB540BE1@delong.com><466965F5.2090105@mvn.net> <004901c7aa05$63a36700$c80a0a0a@integrated.net> Message-ID: <4669B3DE.1080405@psg.com> > you say.. "Fewer larger routes benefits everyone" > > but what you are actually saying is --- the waste of a limited resource is > justified because ... "Fewer larger routes benefits everyone" well.. > actually only... ISP's and there hardware budget. and we promise not to pass on the increased costs to our customers. and pigs will fly. can we try to get real here? randy From jlewis at lewis.org Fri Jun 8 16:01:12 2007 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 8 Jun 2007 16:01:12 -0400 (EDT) Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <004901c7aa05$63a36700$c80a0a0a@integrated.net> References: <1070607055425.24656B-100000@Ives.egh.com><466863B5.3090305@mcsnet.ca><700EAF4E-44AD-412B-8BBA-0AE3EB540BE1@delong.com><466965F5.2090105@mvn.net> <004901c7aa05$63a36700$c80a0a0a@integrated.net> Message-ID: On Fri, 8 Jun 2007, Leroy Ladyzhensky wrote: > but what you are actually saying is --- the waste of a limited resource is > justified because ... "Fewer larger routes benefits everyone" well.. > actually only... ISP's and there hardware budget. My point was, if a network continues to grow and eventually does use up what it gets (just not at the expected pace) nothing's been wasted, and global routing table slots have been conserved. > how can we get a way from this thinking and begin to move forward... and face > it... to actually conserve IP's there needs to be an option to allow smaller > allocations.... > > The ONLY thing that needs to be considered is HOW the smaller allocations get > handed out... do the go to anyone who asks.. I would think not... what would > be the criteria for a company to get a /24 allocation? any input on this > would be great. As I've said a couple times recently, I'm not opposed to / am in favor of issuing PI /24s to any multihomed network. If you're multihomed, your PI /24 takes up the same global table routing slot your PA /24 would (less space if you had multiple PA /24s from your various providers which you'd give up to get PI). If you're not multihomed, and not big enough to qualify for PI space under current guidelines, sorry, you get to keep using PA. Otherwise the routing tables really would explode. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From leroy at emailsorting.com Fri Jun 8 16:02:36 2007 From: leroy at emailsorting.com (Leroy Ladyzhensky) Date: Fri, 8 Jun 2007 16:02:36 -0400 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks References: <1070607055425.24656B-100000@Ives.egh.com><466863B5.3090305@mcsnet.ca><700EAF4E-44AD-412B-8BBA-0AE3EB540BE1@delong.com><466965F5.2090105@mvn.net> <004901c7aa05$63a36700$c80a0a0a@integrated.net> <4669B3DE.1080405@psg.com> Message-ID: <006101c7aa07$f5b5e4e0$c80a0a0a@integrated.net> LOL... I currently have been with the same ISP for 5 years.. and during this time I know for a fact that they have upgraded their hardware and have made improvements... but yet my service is still the same price... in reality... you say you will make the end users pay.. but other ISP's will not, and the big ones will not (since they, most likely, don't have to upgrade anyway) so in turn .. to remain competitive... you will not increase your rate that much any way... Lets take a honest look at history... internet speed has increased and cost has come down... and in order to support bandwidth demands. major ISP infrastructures have had to be upgraded to keep up with the demand... but price is down... and so.. what you are saying is if the routing table size went up.. and hardware had to be upgraded... this would cause a cataclysmic shift in internet pricing? can we try to get real here? ----- Original Message ----- From: "Randy Bush" To: "Leroy Ladyzhensky" Cc: "Jon Lewis" ; Sent: Friday, June 08, 2007 3:54 PM Subject: Re: [ppml] Suggestion for ARIN to deligate smaller IP blocks >> you say.. "Fewer larger routes benefits everyone" >> >> but what you are actually saying is --- the waste of a limited resource >> is >> justified because ... "Fewer larger routes benefits everyone" well.. >> actually only... ISP's and there hardware budget. > > and we promise not to pass on the increased costs to our customers. and > pigs will fly. > > can we try to get real here? > > randy > From Paul_Vixie at isc.org Fri Jun 8 16:17:24 2007 From: Paul_Vixie at isc.org (Paul_Vixie at isc.org) Date: Fri, 08 Jun 2007 20:17:24 +0000 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: Your message of "Fri, 08 Jun 2007 16:01:12 -0400." References: <1070607055425.24656B-100000@Ives.egh.com><466863B5.3090305@mcsnet.ca><700EAF4E-44AD-412B-8BBA-0AE3EB540BE1@delong.com><466965F5.2090105@mvn.net> <004901c7aa05$63a36700$c80a0a0a@integrated.net> Message-ID: <58495.1181333844@sa.vix.com> > As I've said a couple times recently, I'm not opposed to / am in favor of > issuing PI /24s to any multihomed network. so, PI /24 for multihomers, but not for TE routes or lockin-avoidance? or, in light of how easy it would be for a TE route spewer or a lockin-avoider to just multihome in order to get a /24, do you really just mean "PI /24 for anybody who asks" ? > If you're multihomed, your PI /24 takes up the same global table routing > slot your PA /24 would (less space if you had multiple PA /24s from your > various providers which you'd give up to get PI). for a PA /24 there's presumably a covering route which makes your addresses "reachable from the DFZ" even from places who don't hear or filter your /24. so, there's a bit of a qualitative difference in the case where a /24 isn't multihomed. i agree that if it's multihomed, PI uses less DFZ DVRP than PA. > If you're not multihomed, and not big enough to qualify for PI space under > current guidelines, sorry, you get to keep using PA. anybody who wants to multihome can do that pretty easily, and if that's all it takes to qualify for a PI /24, then we're more or less throwing open the doors and inviting anybody who really wants a PI /24 to ask for one. (to me this isn't a bad idea since the worst DFZ bloat is from TE not multihoming.) > Otherwise the routing tables really would explode. by any reasonable definition of that word, the DFZ at 220KP has exploded. so when we talk about explosion let's qualify it: "explode again (>1MP)." and after than we'll say "explode yet again (>5MP)." the community's record for preventing these explosions isn't good; for coping with them, slightly better. From leroy at emailsorting.com Fri Jun 8 16:29:53 2007 From: leroy at emailsorting.com (Leroy Ladyzhensky) Date: Fri, 8 Jun 2007 16:29:53 -0400 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks References: <1070607055425.24656B-100000@Ives.egh.com><466863B5.3090305@mcsnet.ca><700EAF4E-44AD-412B-8BBA-0AE3EB540BE1@delong.com><466965F5.2090105@mvn.net> <004901c7aa05$63a36700$c80a0a0a@integrated.net> Message-ID: <009b01c7aa0b$c566cf80$c80a0a0a@integrated.net> Perfect... So one of the requiems to qualify for a /24 from ARIN.. 1. Must be multi-homed. does any one have other requirements to add... ----- Original Message ----- From: "Jon Lewis" To: "Leroy Ladyzhensky" Cc: Sent: Friday, June 08, 2007 4:01 PM Subject: Re: [ppml] Suggestion for ARIN to deligate smaller IP blocks > On Fri, 8 Jun 2007, Leroy Ladyzhensky wrote: > >> but what you are actually saying is --- the waste of a limited resource >> is justified because ... "Fewer larger routes benefits everyone" well.. >> actually only... ISP's and there hardware budget. > > My point was, if a network continues to grow and eventually does use up > what it gets (just not at the expected pace) nothing's been wasted, and > global routing table slots have been conserved. > >> how can we get a way from this thinking and begin to move forward... and >> face it... to actually conserve IP's there needs to be an option to allow >> smaller allocations.... >> >> The ONLY thing that needs to be considered is HOW the smaller allocations >> get handed out... do the go to anyone who asks.. I would think not... >> what would be the criteria for a company to get a /24 allocation? any >> input on this would be great. > > As I've said a couple times recently, I'm not opposed to / am in favor of > issuing PI /24s to any multihomed network. If you're multihomed, your PI > /24 takes up the same global table routing slot your PA /24 would (less > space if you had multiple PA /24s from your various providers which you'd > give up to get PI). > > If you're not multihomed, and not big enough to qualify for PI space under > current guidelines, sorry, you get to keep using PA. Otherwise the > routing tables really would explode. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From sleibrand at internap.com Fri Jun 8 16:42:35 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 08 Jun 2007 13:42:35 -0700 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <009b01c7aa0b$c566cf80$c80a0a0a@integrated.net> References: <1070607055425.24656B-100000@Ives.egh.com><466863B5.3090305@mcsnet.ca><700EAF4E-44AD-412B-8BBA-0AE3EB540BE1@delong.com><466965F5.2090105@mvn.net> <004901c7aa05$63a36700$c80a0a0a@integrated.net> <009b01c7aa0b$c566cf80$c80a0a0a@integrated.net> Message-ID: <4669BF3B.6010309@internap.com> I think the appropriate policy proposal would simply update references to /22 in the NRPM (in 4.2.2.2 and elsewhere) to /24, and add requirements for how much space you must be using to get a /23 or /24 (as there are for /20, /21, and /22). Whether such a change would get consensus I'm not sure, but we haven't exactly seen a run on PI /22's, so I doubt we'll see one for /23 or /24 either. -Scott Leroy Ladyzhensky wrote: > Perfect... > > So one of the requiems to qualify for a /24 from ARIN.. > > 1. Must be multi-homed. > > > does any one have other requirements to add... > > > > > > ----- Original Message ----- > From: "Jon Lewis" > To: "Leroy Ladyzhensky" > Cc: > Sent: Friday, June 08, 2007 4:01 PM > Subject: Re: [ppml] Suggestion for ARIN to deligate smaller IP blocks > > > >> On Fri, 8 Jun 2007, Leroy Ladyzhensky wrote: >> >> >>> but what you are actually saying is --- the waste of a limited resource >>> is justified because ... "Fewer larger routes benefits everyone" well.. >>> actually only... ISP's and there hardware budget. >>> >> My point was, if a network continues to grow and eventually does use up >> what it gets (just not at the expected pace) nothing's been wasted, and >> global routing table slots have been conserved. >> >> >>> how can we get a way from this thinking and begin to move forward... and >>> face it... to actually conserve IP's there needs to be an option to allow >>> smaller allocations.... >>> >>> The ONLY thing that needs to be considered is HOW the smaller allocations >>> get handed out... do the go to anyone who asks.. I would think not... >>> what would be the criteria for a company to get a /24 allocation? any >>> input on this would be great. >>> >> As I've said a couple times recently, I'm not opposed to / am in favor of >> issuing PI /24s to any multihomed network. If you're multihomed, your PI >> /24 takes up the same global table routing slot your PA /24 would (less >> space if you had multiple PA /24s from your various providers which you'd >> give up to get PI). >> >> If you're not multihomed, and not big enough to qualify for PI space under >> current guidelines, sorry, you get to keep using PA. Otherwise the >> routing tables really would explode. >> >> ---------------------------------------------------------------------- >> Jon Lewis | I route >> Senior Network Engineer | therefore you are >> Atlantic Net | >> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ >> >> > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From leroy at emailsorting.com Fri Jun 8 16:47:10 2007 From: leroy at emailsorting.com (Leroy Ladyzhensky) Date: Fri, 8 Jun 2007 16:47:10 -0400 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks References: <1070607055425.24656B-100000@Ives.egh.com><466863B5.3090305@mcsnet.ca><700EAF4E-44AD-412B-8BBA-0AE3EB540BE1@delong.com><466965F5.2090105@mvn.net> <004901c7aa05$63a36700$c80a0a0a@integrated.net> <009b01c7aa0b$c566cf80$c80a0a0a@integrated.net> <4669BF3B.6010309@internap.com> Message-ID: <00b201c7aa0e$2fdb1720$c80a0a0a@integrated.net> Thanks Scott... what can be done to address ARIN's concern on a proposal like this? the proposal can be viewed at http://lists.arin.net/pipermail/ppml/2007-April/006601.html I guess the ones that would need some thought is...1 and 3 A. ARIN Staff 1. There is very little qualification criteria which could lead to policy abuse by spammers. These entities could create many different accounts over time as their existing space gets blacklisted or becomes otherwise unusable. 2. This could significantly increase the number of requests for ARIN services thereby requiring additional Registration Services Department and Financial Services Department staff. 3. Policy applies only to end users which could be perceived as unfair to ISPs. This could also lead to potential abuse of the policy if ISPs apply as end users for single /24 IPv4 address block. 4. It is unclear exactly how an organization can qualify for a /24 IPv4 address block under this policy. It appears that NRPM section 4.3.3, Utilization rate, requires 25% immediate, 50% within 1 year, would be the justification criteria. However, NRPM section 4.2.3.6, Reassignments to multihomed downstream customers, indicates that an ISP can reassign a /24 IPv4 address block without regard to planned host counts as long as the customer is multi-homed. The question here is does this policy allow ARIN to qualify a requestor for a /24 IPv4 address block based solely on multi-homing or should host counts also be taken into account? 5. The policy does not address requests for more than one /24 IPv4 address block for multiple sites. 6. NRPM Section 4.4, Micro-allocation, should remain as is since it is a policy section essential for micro-allocation for critical infrastructure related requests. ----- Original Message ----- From: "Scott Leibrand" To: "Leroy Ladyzhensky" Cc: Sent: Friday, June 08, 2007 4:42 PM Subject: Re: [ppml] Suggestion for ARIN to deligate smaller IP blocks >I think the appropriate policy proposal would simply update references to >/22 in the NRPM (in 4.2.2.2 and elsewhere) to /24, and add requirements for >how much space you must be using to get a /23 or /24 (as there are for /20, >/21, and /22). > > Whether such a change would get consensus I'm not sure, but we haven't > exactly seen a run on PI /22's, so I doubt we'll see one for /23 or /24 > either. > > -Scott > > Leroy Ladyzhensky wrote: >> Perfect... >> >> So one of the requiems to qualify for a /24 from ARIN.. >> >> 1. Must be multi-homed. >> >> >> does any one have other requirements to add... >> >> >> >> >> >> ----- Original Message ----- >> From: "Jon Lewis" >> To: "Leroy Ladyzhensky" >> Cc: >> Sent: Friday, June 08, 2007 4:01 PM >> Subject: Re: [ppml] Suggestion for ARIN to deligate smaller IP blocks >> >> >> >>> On Fri, 8 Jun 2007, Leroy Ladyzhensky wrote: >>> >>> >>>> but what you are actually saying is --- the waste of a limited resource >>>> is justified because ... "Fewer larger routes benefits everyone" >>>> well.. actually only... ISP's and there hardware budget. >>>> >>> My point was, if a network continues to grow and eventually does use up >>> what it gets (just not at the expected pace) nothing's been wasted, and >>> global routing table slots have been conserved. >>> >>> >>>> how can we get a way from this thinking and begin to move forward... >>>> and face it... to actually conserve IP's there needs to be an option to >>>> allow smaller allocations.... >>>> >>>> The ONLY thing that needs to be considered is HOW the smaller >>>> allocations get handed out... do the go to anyone who asks.. I would >>>> think not... what would be the criteria for a company to get a /24 >>>> allocation? any input on this would be great. >>>> >>> As I've said a couple times recently, I'm not opposed to / am in favor >>> of issuing PI /24s to any multihomed network. If you're multihomed, >>> your PI /24 takes up the same global table routing slot your PA /24 >>> would (less space if you had multiple PA /24s from your various >>> providers which you'd give up to get PI). >>> >>> If you're not multihomed, and not big enough to qualify for PI space >>> under current guidelines, sorry, you get to keep using PA. Otherwise >>> the routing tables really would explode. >>> >>> ---------------------------------------------------------------------- >>> Jon Lewis | I route >>> Senior Network Engineer | therefore you are >>> Atlantic Net | >>> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ >>> >>> >> >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml >> > From bicknell at ufp.org Fri Jun 8 16:53:30 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 8 Jun 2007 16:53:30 -0400 Subject: [ppml] IPv6, Vista, and the Popular Press Message-ID: <20070608205329.GA42129@ussenterprise.ufp.org> http://www.networkworld.com/news/2007/060707-microsoft-vista-ipv6-incompatible.html I wonder if the author failed math class or is making a commentary on RIR IPv6 allocation sizes when she states that "IPv6 supports a 128-bit addressing scheme, which lets it support an order-of-magnitude more devices that are directly connected to the Internet than its predecessor, IPv4." However, I want to point out while the board and I think the community are pulling hard to get IPv6 deployed, people deploying real systems seem to often be going in the other direction. From page 2: ] Murphy says he is recommending that his clients remove IPv6 from their ] Vista workstations. As if that wasn't bad enough, some quotes from the comments: ] So why run both is my question and why does vista install both ] automatically? I can see if the IPv4 standard was going away in a year ] but it is not so I recommend to remove IPv6. However, least I think this is poor reporting of an inexperienced sysadmin a mainstream vendor, Symantec has similar advice. They checked out all of Vista's new networking: http://www.symantec.com/enterprise/security_response/weblog/2006/07/post.html In their report, http://www.symantec.com/avcenter/reference/ATR-VistaAttackSurface.pdf, there's a choice quote: ] Firewalls and IDSs will have to consider the presense of new Vista ] machines on their networks. If left unhandled and unchecked, IPv6 ] and it's accompanying transition technologies allow an attacher access ] to hosts on private internal networks outside of the preview of the ] administrator. Unwanted access can be prevented by the analysis of ] IPv6 protocols in the firewall or IDS or by completely blocking all ] IPv6 protocols. With the Board's recent step to get the IPv6 word out, is there anything else the RIR community can do to head off the advice of "just turn it off"? If sysadmins are deinstalling IPv6 support in OS's like Vista then deploying IPv6 is going to be even more difficult. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From dlw+arin at tellme.com Fri Jun 8 17:04:06 2007 From: dlw+arin at tellme.com (David Williamson) Date: Fri, 8 Jun 2007 14:04:06 -0700 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <4669BF3B.6010309@internap.com> References: <004901c7aa05$63a36700$c80a0a0a@integrated.net> <009b01c7aa0b$c566cf80$c80a0a0a@integrated.net> <4669BF3B.6010309@internap.com> Message-ID: <20070608210405.GS6340@shell01.corp.tellme.com> On Fri, Jun 08, 2007 at 01:42:35PM -0700, Scott Leibrand wrote: > I think the appropriate policy proposal would simply update references > to /22 in the NRPM (in 4.2.2.2 and elsewhere) to /24, and add > requirements for how much space you must be using to get a /23 or /24 > (as there are for /20, /21, and /22). > > Whether such a change would get consensus I'm not sure, but we haven't > exactly seen a run on PI /22's, so I doubt we'll see one for /23 or /24 > either. Good luck with that. Have you read 2007-6? I think you just reinvented that proposal verbatim. You might also note its fate. -David From jordi.palet at consulintel.es Fri Jun 8 17:41:37 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 08 Jun 2007 23:41:37 +0200 Subject: [ppml] IPv6, Vista, and the Popular Press In-Reply-To: <20070608205329.GA42129@ussenterprise.ufp.org> Message-ID: My reading on this case, and having tested with customers, is that the fault is not IPv6, but some broken drivers (this case seems a printer driver). Of course, as you say, inexperienced sysadmins make the wrong testing and blame IPv6, instead of blaming other things. The issue is that the printer can stop working by many other reasons not just because IPv6, but is the easier thing to try/say. Also the Symantec statement is a long history and seems to me more a fight with Microsoft than against IPv6, is a pure market thing, they can't sell good IPv6 firewalls yet, and Microsoft has an embedded one, so blame IPv6 instead of blaming yourself for not getting ready in time. There has been also a recent discussion in v6ops because someone from Symantec was raising security concerns about Teredo with a new draft and the conclusion is that he is trying to defend a product that can't manage IPv6, but the worst is that in a managed network, you should not use Teredo, but instead a managed transition mechanism or native IPv6 connectivity itself, so the broken thing is again the lack of good sysadmins that just try to make their life easy instead of doing the work they are expected to do, for example getting ready with IPv6 before it comes. Regards, Jordi > De: Leo Bicknell > Organizaci?n: United Federation of Planets > Responder a: > Fecha: Fri, 8 Jun 2007 16:53:30 -0400 > Para: > Asunto: [ppml] IPv6, Vista, and the Popular Press > > > http://www.networkworld.com/news/2007/060707-microsoft-vista-ipv6-incompatible > .html > > I wonder if the author failed math class or is making a commentary > on RIR IPv6 allocation sizes when she states that "IPv6 supports a > 128-bit addressing scheme, which lets it support an order-of-magnitude > more devices that are directly connected to the Internet than its > predecessor, IPv4." > > However, I want to point out while the board and I think the community > are pulling hard to get IPv6 deployed, people deploying real systems > seem to often be going in the other direction. From page 2: > > ] Murphy says he is recommending that his clients remove IPv6 from their > ] Vista workstations. > > As if that wasn't bad enough, some quotes from the comments: > > ] So why run both is my question and why does vista install both > ] automatically? I can see if the IPv4 standard was going away in a year > ] but it is not so I recommend to remove IPv6. > > However, least I think this is poor reporting of an inexperienced > sysadmin a mainstream vendor, Symantec has similar advice. They checked > out all of Vista's new networking: > http://www.symantec.com/enterprise/security_response/weblog/2006/07/post.html > > In their report, > http://www.symantec.com/avcenter/reference/ATR-VistaAttackSurface.pdf, > there's a choice quote: > > ] Firewalls and IDSs will have to consider the presense of new Vista > ] machines on their networks. If left unhandled and unchecked, IPv6 > ] and it's accompanying transition technologies allow an attacher access > ] to hosts on private internal networks outside of the preview of the > ] administrator. Unwanted access can be prevented by the analysis of > ] IPv6 protocols in the firewall or IDS or by completely blocking all > ] IPv6 protocols. > > With the Board's recent step to get the IPv6 word out, is there > anything else the RIR community can do to head off the advice of > "just turn it off"? If sysadmins are deinstalling IPv6 support in > OS's like Vista then deploying IPv6 is going to be even more > difficult. > > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From stephen at sprunk.org Fri Jun 8 18:10:42 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 8 Jun 2007 17:10:42 -0500 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks References: <1070607055425.24656B-100000@Ives.egh.com><466863B5.3090305@mcsnet.ca><700EAF4E-44AD-412B-8BBA-0AE3EB540BE1@delong.com><466965F5.2090105@mvn.net><004901c7aa05$63a36700$c80a0a0a@integrated.net> <58495.1181333844@sa.vix.com> Message-ID: <011001c7aa1d$19cfc9d0$6701a8c0@atlanta.polycom.com> Thus spake >> As I've said a couple times recently, I'm not opposed to / am >> in favor of issuing PI /24s to any multihomed network. > > so, PI /24 for multihomers, but not for TE routes or lockin- > avoidance? or, in light of how easy it would be for a TE route > spewer or a lockin-avoider to just multihome in order to get a > /24, do you really just mean "PI /24 for anybody who asks" ? If someone is willing to pay for pipes to diverse providers and a BGP-capable router and has enough clue to get BGP working, there is a sizeable* faction that believes they "deserve" a routing slot. Given the number of providers that consume hundreds of routing slots due to TE/incompetence without adding any value to the majority of the 'net, I am not unsympathetic to this view. Why is it that AT&T, Cox, Comcast, et al are allowed to bloat the tables but smaller companies are not? > anybody who wants to multihome can do that pretty easily, and if > that's all it takes to qualify for a PI /24, then we're more or less > throwing open the doors and inviting anybody who really wants > a PI /24 to ask for one. I don't think anyone is saying that you don't need to justify use of a /24. Today you have to justify a /22, and that's not much harder than a /24. It's well known that people fib when making requests, and most of the people getting /22s today could probably only justify a /24 anyways -- if that. The only legitimate complaint I've heard here is that it's easier to lie your way to a /24 than to a /22, but wouldn't we be better served by mandating that ARIN pursue fraud more diligently? The Board said as much in their recent announcement, given the not-so-distant-anymore exhaustion of v4 space. Reclamation, if passed, may also help by enforcing standards on existing blocks. My original intent was ARIN would go after the biggest blocks first (to recover address space), but perhaps they need to go after the smallest ones as well (to recover routing slots). > (to me this isn't a bad idea since the worst DFZ bloat is from TE > not multihoming.) Is it TE? "Do not attribute to malice that which can be adequately explained by stupidity." The top deaggregators have identical paths for all of their bloated routes. If they are doing TE to peers/transits, they should be marking those routes no-export or with some other community that allows them to be filtered beyond the range that they add value. The worst offenders (that we can see) are not, therefore I choose to believe the reason we see 210k routes instead of 140k routes is incompetence, not smart people doing TE. However, given that those worst offenders, with a few notable exceptions, are also the same people that are whining about routing table bloat, one could also support a conclusion of malice, i.e. it's okay for _them_ to bloat the tables since it gives them a reason to block policies that allow their customers to escape provider lock-in. >> Otherwise the routing tables really would explode. > > by any reasonable definition of that word, the DFZ at 220KP > has exploded. so when we talk about explosion let's qualify it: > "explode again (>1MP)." and after than we'll say "explode yet > again (>5MP)." the community's record for preventing these > explosions isn't good; for coping with them, slightly better. Mr. Schiller has presented the best case I've heard for route bloat causing problems, but even he admits that most of the routes he's carrying are from 2547 VPNs, internal routes, etc. and not from the public v4/v6 DFZ. I'm certain** that he's the prime customer for vendors building/selling routers that can handle 1M+ routes. With all due respect, though, should his employer's choice to burn 80% of their routing capacity on non-public prefixes mean that the entire rest of the Internet shouldn't be allowed to use _their_ spare capacity to make the public Internet work better for everyone? S * I don't know if this faction is the majority or not. They're certainly not as vocal as the crybabies. ** I have no inside knowledge, just common sense. Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From jafo at tummy.com Fri Jun 8 18:58:53 2007 From: jafo at tummy.com (Sean Reifschneider) Date: Fri, 8 Jun 2007 16:58:53 -0600 Subject: [ppml] IPv6, Vista, and the Popular Press In-Reply-To: <20070608205329.GA42129@ussenterprise.ufp.org> References: <20070608205329.GA42129@ussenterprise.ufp.org> Message-ID: <20070608225853.GA10403@tummy.com> On Fri, Jun 08, 2007 at 04:53:30PM -0400, Leo Bicknell wrote: >I wonder if the author failed math class or is making a commentary I have heard that a large part of the reason IPv6 is 128 bits of address space instead of 64 is that a significant number of people on the committee didn't fully understand that 64 bits is way way more than twice the number of addresses we have with IPv4. Sean -- Like its politicians and its wars, society has the teenagers it deserves. -- J. B. Priestley Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability From paul at vix.com Fri Jun 8 20:48:21 2007 From: paul at vix.com (Paul Vixie) Date: Sat, 09 Jun 2007 00:48:21 +0000 Subject: [ppml] IPv6, Vista, and the Popular Press In-Reply-To: Your message of "Fri, 08 Jun 2007 16:58:53 CST." <20070608225853.GA10403@tummy.com> References: <20070608205329.GA42129@ussenterprise.ufp.org> <20070608225853.GA10403@tummy.com> Message-ID: <96452.1181350101@sa.vix.com> > I have heard that a large part of the reason IPv6 is 128 bits of address > space instead of 64 is that a significant number of people on the committee > didn't fully understand that 64 bits is way way more than twice the number > of addresses we have with IPv4. that's an urban legend. the people who chose 128 bits were way smart about the math of it. they chose 128 bits as a "stretch goal", as in, enough better than 32 bits to be worth the cost of transition, and enough bits that we'd never run out, but still small enough to build with 1990's hardware. the fact that the EUI64 people immediately wasted half the new bits is a separate problem due to incompetence by separate people than the ones who picked "128". From paul at vix.com Fri Jun 8 20:55:22 2007 From: paul at vix.com (Paul Vixie) Date: Sat, 09 Jun 2007 00:55:22 +0000 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: Your message of "Fri, 08 Jun 2007 17:10:42 EST." <011001c7aa1d$19cfc9d0$6701a8c0@atlanta.polycom.com> References: <1070607055425.24656B-100000@Ives.egh.com><466863B5.3090305@mcsnet.ca><700EAF4E-44AD-412B-8BBA-0AE3EB540BE1@delong.com><466965F5.2090105@mvn.net><004901c7aa05$63a36700$c80a0a0a@integrated.net> <58495.1181333844@sa.vix.com> <011001c7aa1d$19cfc9d0$6701a8c0@atlanta.polycom.com> Message-ID: <96639.1181350522@sa.vix.com> > Reclamation, if passed, may also help by enforcing standards on existing > blocks. My original intent was ARIN would go after the biggest blocks first > (to recover address space), but perhaps they need to go after the smallest > ones as well (to recover routing slots). i don't think there's any reason to open this egg at the big end or little end preferentially. reclaimation of either scarce resource would be good if it meant they can be recycled by somebody who will use them efficiently. > Mr. Schiller has presented the best case I've heard for route bloat causing > problems, but even he admits that most of the routes he's carrying are from > 2547 VPNs, internal routes, etc. and not from the public v4/v6 DFZ. I'm > certain** that he's the prime customer for vendors building/selling routers > that can handle 1M+ routes. With all due respect, though, should his > employer's choice to burn 80% of their routing capacity on non-public > prefixes mean that the entire rest of the Internet shouldn't be allowed to > use _their_ spare capacity to make the public Internet work better for > everyone? no more so than a choice by somebody else to burn 80% of their routing capacity on whatever revenue streams pay the bills. i think that from a policy point of view, the RIR community should assume that 50% of the capacity of three-year-old equipment is what's available to hold the DFZ. From jafo at tummy.com Fri Jun 8 21:01:54 2007 From: jafo at tummy.com (Sean Reifschneider) Date: Fri, 8 Jun 2007 19:01:54 -0600 Subject: [ppml] IPv6, Vista, and the Popular Press In-Reply-To: <96452.1181350101@sa.vix.com> References: <20070608205329.GA42129@ussenterprise.ufp.org> <20070608225853.GA10403@tummy.com> <96452.1181350101@sa.vix.com> Message-ID: <20070609010154.GA15666@tummy.com> On Sat, Jun 09, 2007 at 12:48:21AM +0000, Paul Vixie wrote: >than 32 bits to be worth the cost of transition, and enough bits that we'd >never run out, but still small enough to build with 1990's hardware. the Why have I heard so much about routers not being able to handle IPv6? Is it really not as big a problem as I've heard (I honestly don't know), or was the "can be built with '90s hardware" believe a bit optimistic? Oh, and the urban legend about 64 versus 128 bits I heard from someone who was on the IPv6 working group, though I don't recall who it was now. I'll take your word on it, but it's still the case that a lot of people don't fully understand just how large 64 and 128 bit numbers are. :-) Sean -- Linux: Bring back that "greased weasel" feeling. -- Sean Reifschneider, 1998 Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability From stephen at sprunk.org Fri Jun 8 21:35:41 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 8 Jun 2007 20:35:41 -0500 Subject: [ppml] IPv6, Vista, and the Popular Press References: <20070608205329.GA42129@ussenterprise.ufp.org><20070608225853.GA10403@tummy.com> <96452.1181350101@sa.vix.com> <20070609010154.GA15666@tummy.com> Message-ID: <022f01c7aa37$2263d680$6701a8c0@atlanta.polycom.com> Thus spake "Sean Reifschneider" > On Sat, Jun 09, 2007 at 12:48:21AM +0000, Paul Vixie wrote: >>than 32 bits to be worth the cost of transition, and enough bits >>that we'd never run out, but still small enough to build with >> 1990's hardware. the > > Why have I heard so much about routers not being able to handle > IPv6? Is it really not as big a problem as I've heard (I honestly > don't know), or was the "can be built with '90s hardware" believe > a bit optimistic? [ Putting on my vendor hat for a moment... ] Vendors build what they think* customers will buy. It was _possible_ to build an IPv6 router with 1990s hardware, but like any feature, implementing it adds expense and thus either increases prices or reduces profits. Many hardware routers/linecards were thus designed without hardware to forward IPv6 packets based on the belief (probably true at the time) that customers would not be willing to pay the increased prices necessary to build IPv6-capable devices at "acceptable" profit levels. The result is that many core routers out there can only forward IPv6 in software -- at ~1% of their hardware-based forwarding rate for IPv4. Non-trivial levels of IPv6 traffic scare folks who bought those devices. Software is a somewhat similar matter: do you spend your limited developer budget on writing new IPv4 features that people will throw money at you for, or do you code an IPv6 stack that will go mostly unnoticed? It's gradually gotten done over time at most vendors, and the major difference is that software can be back-ported to existing routers at little per-unit cost, but it's still woefully lacking in CPE devices (Apple's one model aside). S * Some vendors are better than others at guessing what customers will spend money on, and that guessing is an art, not science. In particular, asking your customers what they'd like to see is notoriously unreliable because they'll ask for lots of things that won't actually influence their buying decisions. It takes customers threatening to take their business elsewhere for demand to be believed. Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From michel at arneill-py.sacramento.ca.us Fri Jun 8 23:46:55 2007 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 8 Jun 2007 20:46:55 -0700 Subject: [ppml] IPv6, Vista, and the Popular Press In-Reply-To: <022f01c7aa37$2263d680$6701a8c0@atlanta.polycom.com> References: <20070608205329.GA42129@ussenterprise.ufp.org><20070608225853.GA10403@tummy.com><96452.1181350101@sa.vix.com> <20070609010154.GA15666@tummy.com> <022f01c7aa37$2263d680$6701a8c0@atlanta.polycom.com> Message-ID: > Stephen Sprunk wrote: > Some vendors are better than others at guessing what customers > will spend money on, and that guessing is an art, not science. > In particular, asking your customers what they'd like to see is > notoriously unreliable because they'll ask for lots of things > that won't actually influence their buying decisions. It takes > customers threatening to take their business elsewhere for > demand to be believed. Indeed. Customers ask for IPv6 because it is one of the "checklist items" that they require, not because they want it but because it may save their {job|career|butt|nameit} in case something goes wrong with their project and someone higher in the food chain is looking for a scapegoat in order to save their {job|career|butt|nameit} in case something goes wrong with their project and someone higher in the food chain is looking for a scapegoat in order to save... [stack overflow] Michel. From paul at vix.com Sat Jun 9 02:04:01 2007 From: paul at vix.com (Paul Vixie) Date: Sat, 09 Jun 2007 06:04:01 +0000 Subject: [ppml] IPv6, Vista, and the Popular Press In-Reply-To: Your message of "Fri, 08 Jun 2007 19:01:54 CST." <20070609010154.GA15666@tummy.com> References: <20070608205329.GA42129@ussenterprise.ufp.org> <20070608225853.GA10403@tummy.com> <96452.1181350101@sa.vix.com> <20070609010154.GA15666@tummy.com> Message-ID: <46174.1181369041@sa.vix.com> > Why have I heard so much about routers not being able to handle IPv6? bunch of whiners, prolly. > Is it really not as big a problem as I've heard (I honestly don't know), or > was the "can be built with '90s hardware" believe a bit optimistic? it really isn't a problem. really. > Oh, and the urban legend about 64 versus 128 bits I heard from someone who > was on the IPv6 working group, though I don't recall who it was now. everybody who was anybody was on the ipv6 working group. great big parties, standing room only in the meeting rooms, spilled out into the hallways. > I'll take your word on it, but it's still the case that a lot of people > don't fully understand just how large 64 and 128 bit numbers are. :-) while they're representable as numbers, and drc (whose words are not to be dismissed likely) said here yesterday that they are numbers, to me they are more usefully thought of as bit vectors. when compared to other bit vectors like GPU or VLIW ALU's, 128 bits isn't so much. i was perplexed by the very desperate need to immediately waste half of them on EUI64, as it folks didn't feel safe when surrounded by all that address space and needed to burn some of it off to get down to a size they could comprehend, but, 128 bits isn't really all that large when you consider the 4-bit and 16-bit boundaries imposed by the PTR naming conventions. From howard at leadmon.net Sat Jun 9 17:17:05 2007 From: howard at leadmon.net (Howard Leadmon) Date: Sat, 9 Jun 2007 17:17:05 -0400 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <011001c7aa1d$19cfc9d0$6701a8c0@atlanta.polycom.com> References: <1070607055425.24656B-100000@Ives.egh.com><466863B5.3090305@mcsnet.ca><700EAF4E-44AD-412B-8BBA-0AE3EB540BE1@delong.com><466965F5.2090105@mvn.net><004901c7aa05$63a36700$c80a0a0a@integrated.net><58495.1181333844@sa.vix.com> <011001c7aa1d$19cfc9d0$6701a8c0@atlanta.polycom.com> Message-ID: <008601c7aadb$8b443010$081872cf@Leadmon.local> > If someone is willing to pay for pipes to diverse providers and a > BGP-capable router and has enough clue to get BGP working, there is a > sizeable* faction that believes they "deserve" a routing slot. I would agree, the knowledge required to setup and multihome with BGP is not something that everyone in mass will just know. I have helped many smaller ISP's with BGP issues, as it's just not something that everyone learns. So this alone would keep every joe from a /24, or I would think.. > > anybody who wants to multihome can do that pretty easily, and if > > that's all it takes to qualify for a PI /24, then we're more or less > > throwing open the doors and inviting anybody who really wants > > a PI /24 to ask for one. > > I don't think anyone is saying that you don't need to justify use of a /24. > Today you have to justify a /22, and that's not much harder than a /24. > It's well known that people fib when making requests, and most of the people > getting /22s today could probably only justify a /24 anyways -- if that. > > The only legitimate complaint I've heard here is that it's easier to lie > your way to a /24 than to a /22, but wouldn't we be better served by > mandating that ARIN pursue fraud more diligently? The Board said as much in > their recent announcement, given the not-so-distant-anymore exhaustion of v4 > space. I would have to agree with that, I can't tell you how many times I have seen stuff setup just to fake need for space, just to meet a larger qualification. It's without a doubt not that hard to do, and if they are going to go through the issue of faking a larger layout and getting space anyway, I could see the reasoning behind putting a /24 out there and saving a lot of wasted space. > Reclamation, if passed, may also help by enforcing standards on existing > blocks. My original intent was ARIN would go after the biggest blocks first > (to recover address space), but perhaps they need to go after the smallest > ones as well (to recover routing slots). There is an amazing amount of wasted IP space allocated, as much as many would curse over it, there is a real need to go back and require pre-ARIN allocations to be shown to be used, or justified as what would be reclaimed I am sure would be astounding. I know of /16's that are just totally unused, some that weren't even being announced, and some that were to just show they are out there, but with no intention of actually being used. Heck just the other day I was talking with some about an ISP purchase, and that one of the sellers got the ISP to let him keep one of the /18's personally. I know the guy, he has no place to use it, just knows that IP space costs $$, and as it was a pre-ARIN block from long ago, knew he could just keep hang on to it in case he had a need for it sometime. So there is LOTS of wasted space, without a doubt, and at times a legit person would really use a /24 and has a slim chance of getting it.. > > * I don't know if this faction is the majority or not. They're certainly > not as vocal as the crybabies. > ** I have no inside knowledge, just common sense. > > Stephen Sprunk "Those people who think they know everything > CCIE #3723 are a great annoyance to those of us who do." > K5SSS --Isaac Asimov On a side note not list related, interesting ham call, had to look it up just to see if it was actually real.. WB3FFV here by the way.. *smiles* --- Howard Leadmon From michael.dillon at bt.com Sat Jun 9 18:52:54 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sat, 9 Jun 2007 23:52:54 +0100 Subject: [ppml] IPv6, Vista, and the Popular Press In-Reply-To: <20070608205329.GA42129@ussenterprise.ufp.org> References: <20070608205329.GA42129@ussenterprise.ufp.org> Message-ID: > With the Board's recent step to get the IPv6 word out, is > there anything else the RIR community can do to head off the > advice of "just turn it off"? If sysadmins are deinstalling > IPv6 support in OS's like Vista then deploying IPv6 is going > to be even more difficult. If the board was serious about wanting to warn the public (at least the part of the public that deals with newtorking) then they will issue another press release repeating their warning and specifically addressing comments which recommend turning of IPv6 in MS Vista systems. Of course, the recommendations to disable IPv6 aren't wrong, they just are not based on a clear understanding of how close IPv4 exhaustion is. The board's duty, as trustees, is to educate people on the need for action. If we are about to run out in 4 years time, one can expect that within a year, this will result in increased requests for IPv4 addressing as well as changes in RIR policies making it harder to get an allocation, i.e. more paperwork, more data, more involved checking process. This really means that it is within current business planning horizons. We may not run out of IPv4 in a year, but there will likely be dramatic changes in RIR policies by then (2 ARIN policy cycles). Disabling IPv6 is a wise move if it is coupled with pressure on vendors to fix the problems, and a plan to have it turned back on again within 12 months. --Michael Dillon From Paul_Vixie at isc.org Sat Jun 9 19:34:11 2007 From: Paul_Vixie at isc.org (Paul_Vixie at isc.org) Date: Sat, 09 Jun 2007 23:34:11 +0000 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: Your message of "Sat, 09 Jun 2007 17:17:05 -0400." <008601c7aadb$8b443010$081872cf@Leadmon.local> References: <1070607055425.24656B-100000@Ives.egh.com><466863B5.3090305@mcsnet.ca><700EAF4E-44AD-412B-8BBA-0AE3EB540BE1@delong.com><466965F5.2090105@mvn.net><004901c7aa05$63a36700$c80a0a0a@integrated.net><58495.1181333844@sa.vix.com> <011001c7aa1d$19cfc9d0$6701a8c0@atlanta.polycom.com> <008601c7aadb$8b443010$081872cf@Leadmon.local> Message-ID: <74551.1181432051@sa.vix.com> > I would agree, the knowledge required to setup and multihome with BGP is not > something that everyone in mass will just know. I have helped many smaller > ISP's with BGP issues, as it's just not something that everyone learns. So > this alone would keep every joe from a /24, or I would think.. my experience is, if this is where the value proposition is, there will be consultants, training, appliances, a whole support market for it. just like "dialup ISP in a box" or "web ASP in a box" or "spam engine in a box" or "botnet in a box". the people who see and want the value can pay money and absolutely will make a market in that value. remember that most of the paper spam sent to postal addresses from "whois" are from people who do not know what "whois" is or where the addresses came from. middlemen are everywhere. don't underestimate their levelling powers. From reid at mejac.palo-alto.ca.us Sat Jun 9 21:34:24 2007 From: reid at mejac.palo-alto.ca.us (Brian Reid) Date: Sat, 09 Jun 2007 18:34:24 -0700 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <008601c7aadb$8b443010$081872cf@Leadmon.local> References: <1070607055425.24656B-100000@Ives.egh.com> <466863B5.3090305@mcsnet.ca><700EAF4E-44AD-412B-8BBA-0AE3EB540BE1@delong.com> <466965F5.2090105@mvn.net> <004901c7aa05$63a36700$c80a0a0a@integrated.net> <58495.1181333844@sa.vix.com> <011001c7aa1d$19cfc9d0$6701a8c0@atlanta.polycom.com> <008601c7aadb$8b443010$081872cf@Leadmon.local> Message-ID: > > >> If someone is willing to pay for pipes to diverse providers and a >> BGP-capable router and has enough clue to get BGP working, there is a >> sizeable* faction that believes they "deserve" a routing slot. > > I would agree, the knowledge required to setup and multihome with BGP is not > something that everyone in mass will just know. I have helped many smaller > ISP's with BGP issues, as it's just not something that everyone learns. So > this alone would keep every joe from a /24, or I would think.. > > >> > anybody who wants to multihome can do that pretty easily, and if >> > that's all it takes to qualify for a PI /24, then we're more or less >> > throwing open the doors and inviting anybody who really wants >> > a PI /24 to ask for one. >> >> I don't think anyone is saying that you don't need to justify use of a /24. >> Today you have to justify a /22, and that's not much harder than a /24. >> It's well known that people fib when making requests, and most of the >> people getting /22s today could probably only justify a /24 anyways -- if >> that. >> >> The only legitimate complaint I've heard here is that it's easier to lie >> your way to a /24 than to a /22, but wouldn't we be better served by >> mandating that ARIN pursue fraud more diligently? The Board said as much >> in their recent announcement, given the not-so-distant-anymore exhaustion >> of v4 space. > > I would have to agree with that, I can't tell you how many times I have seen > stuff setup just to fake need for space, just to meet a larger > qualification. It's without a doubt not that hard to do, and if they are > going to go through the issue of faking a larger layout and getting space > anyway, I could see the reasoning behind putting a /24 out there and saving > a lot of wasted space. > > >> Reclamation, if passed, may also help by enforcing standards on existing >> blocks. My original intent was ARIN would go after the biggest blocks >> first (to recover address space), but perhaps they need to go after the >> smallest ones as well (to recover routing slots). > > > There is an amazing amount of wasted IP space allocated, as much as many > would curse over it, there is a real need to go back and require pre-ARIN > allocations to be shown to be used, or justified as what would be reclaimed > I am sure would be astounding. > > I know of /16's that are just totally unused, some that weren't even being > announced, and some that were to just show they are out there, but with no > intention of actually being used. Heck just the other day I was talking > with some about an ISP purchase, and that one of the sellers got the ISP to > let him keep one of the /18's personally. I know the guy, he has no place > to use it, just knows that IP space costs $$, and as it was a pre-ARIN > block from long ago, knew he could just keep hang on to it in case he had a > need for it sometime. So there is LOTS of wasted space, without a doubt, > and at times a legit person would really use a /24 and has a slim chance of > getting it.. > >> >> * I don't know if this faction is the majority or not. They're certainly >> not as vocal as the crybabies. >> ** I have no inside knowledge, just common sense. >> >> Stephen Sprunk "Those people who think they know everything >> CCIE #3723 are a great annoyance to those of us who do." >> K5SSS --Isaac Asimov > > On a side note not list related, interesting ham call, had to look it up > just to see if it was actually real.. WB3FFV here by the way.. *smiles* > > --- > Howard Leadmon > > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From reid at mejac.palo-alto.ca.us Sun Jun 10 00:23:09 2007 From: reid at mejac.palo-alto.ca.us (Brian Reid) Date: Sat, 09 Jun 2007 21:23:09 -0700 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: References: <1070607055425.24656B-100000@Ives.egh.com> <466863B5.3090305@mcsnet.ca><700EAF4E-44AD-412B-8BBA-0AE3EB540BE1@delong.com> <466965F5.2090105@mvn.net> <004901c7aa05$63a36700$c80a0a0a@integrated.net> <58495.1181333844@sa.vix.com> <011001c7aa1d$19cfc9d0$6701a8c0@atlanta.polycom.com> <008601c7aadb$8b443010$081872cf@Leadmon.local> Message-ID: <329401844DF0695319B924F9@hindolveston.reid.org> Sorry, folks. I have no idea where that message came from. I wasn't even home at the time it was sent, though the headers do indicate it was sent from my desktop. From jmorrison at bogomips.com Sun Jun 10 18:03:00 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Sun, 10 Jun 2007 15:03:00 -0700 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <58495.1181333844@sa.vix.com> References: <1070607055425.24656B-100000@Ives.egh.com> <466863B5.3090305@mcsnet.ca> <700EAF4E-44AD-412B-8BBA-0AE3EB540BE1@delong.com> <466965F5.2090105@mvn.net> <004901c7aa05$63a36700$c80a0a0a@integrated.net> <58495.1181333844@sa.vix.com> Message-ID: <466C7514.9020509@bogomips.com> It costs money to get an AS number, this may be a dis-incentive. BGP requires some thought and complexity to setup, while there are multiple "plug and play" load balancing/NAT hack appliances out there. BGP may not be a supported product offering on your basic service, so you may have to upgrade your service plan and pay setup/engineering charges to get BGP. A PI /24 may be unroutable - you run the risk of being filtered. This used to be a big concern a few years ago. (The fact that it doesn't seem to be any more seems to point to the fact that the initial routing table size panic is over). These are all dis-incentives to running out and getting an ASN and PI /24 unless you need it. If you can fudge justification of a PA /24,. you can do it for a PI /24, so I don't see the difference. If you can fudge it, that seems like an enforcement/administrative issue, not a policy issue. A first hurdle to getting a PI/24 allocation might be to show you are running with a PA /24 Taking a look at the big picture - if an organization can legitimately justify its requirements and knows enough about what it is doing to want an ASN and a PI /24 initial allocation, I don't think ARIN should be getting in the way. Current policy can scarcely be justified any more, and that just leaves it looking like the anti-trust/competition limiting policy that it inadvertently is. We should not rely on knee-jerk reactions and circular reasoning to shape policy - e.g. the usual address space depletion and routing table explosion arguments, where trying to conserve the status quo for as long as possible simply delays the adoption or development of newer technology (IPv6 and a solution (other than Moore's Law) to routing. I think people would be very hard pressed to prove that this policy would "break the Internet" which would seem to be the only arguments against it. Absolute worst case is you may see an earlier transition to IPv6 (many would say this is a plus!) and some routing black holes for the newcomers who can't route their new PI /24s. Paul_Vixie at isc.org wrote: >> As I've said a couple times recently, I'm not opposed to / am in favor of >> issuing PI /24s to any multihomed network. >> > > so, PI /24 for multihomers, but not for TE routes or lockin-avoidance? or, > in light of how easy it would be for a TE route spewer or a lockin-avoider > to just multihome in order to get a /24, do you really just mean "PI /24 > for anybody who asks" ? > > >> If you're multihomed, your PI /24 takes up the same global table routing >> slot your PA /24 would (less space if you had multiple PA /24s from your >> various providers which you'd give up to get PI). >> > > for a PA /24 there's presumably a covering route which makes your addresses > "reachable from the DFZ" even from places who don't hear or filter your /24. > so, there's a bit of a qualitative difference in the case where a /24 isn't > multihomed. i agree that if it's multihomed, PI uses less DFZ DVRP than PA. > > >> If you're not multihomed, and not big enough to qualify for PI space under >> current guidelines, sorry, you get to keep using PA. >> > > anybody who wants to multihome can do that pretty easily, and if that's all > it takes to qualify for a PI /24, then we're more or less throwing open the > doors and inviting anybody who really wants a PI /24 to ask for one. (to me > this isn't a bad idea since the worst DFZ bloat is from TE not multihoming.) > > >> Otherwise the routing tables really would explode. >> > > by any reasonable definition of that word, the DFZ at 220KP has exploded. so > when we talk about explosion let's qualify it: "explode again (>1MP)." and > after than we'll say "explode yet again (>5MP)." the community's record for > preventing these explosions isn't good; for coping with them, slightly better. > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at istaff.org Sun Jun 10 18:16:42 2007 From: jcurran at istaff.org (John Curran) Date: Sun, 10 Jun 2007 18:16:42 -0400 Subject: [ppml] IPv6, Vista, and the Popular Press In-Reply-To: References: <20070608205329.GA42129@ussenterprise.ufp.org> Message-ID: At 11:52 PM +0100 6/9/07, wrote: > >If the board was serious about wanting to warn the public (at least the >part of the public that deals with newtorking) then they will issue >another press release repeating their warning and specifically >addressing comments which recommend turning of IPv6 in MS Vista systems. It's quite logical for the ARIN Board to inform the ISP community that the availability of large IPv4 blocks is going to change in the future. This is because there is a direct relationship between ARIN and its members. In my personal opinion, Internet Service Providers need to realize that IPv6 adoption is *their* issue, and begin to educating their user community that the addition of IPv6 (at least as far as their publicly facing servers) is going to be necessary in the next few years. As part of such education, it would be perfectly logical for ISP's to also mention that turning off IPv6 for those servers is likely a step in the wrong direction... /John From dean at av8.com Mon Jun 11 01:41:42 2007 From: dean at av8.com (Dean Anderson) Date: Mon, 11 Jun 2007 01:41:42 -0400 (EDT) Subject: [ppml] IPv6, Vista, and the Popular Press In-Reply-To: <46174.1181369041@sa.vix.com> Message-ID: The message below is not a serious reply. Don't believe any of what's below. Even though Vixie is an ARIN Board Member, his response isn't a serious reply to the issues you cite; issues which have been raised by others, as well. One would think ARIN Board Members would respond with more facts and less BS. Maybe the ARIN membership should be more selective in the selection of ARIN Board Members, and find people who are interested in promoting the Internet, rather than in snide comments that derail legitimate concerns and discussion. --Dean On Sat, 9 Jun 2007, Paul Vixie wrote: > > Why have I heard so much about routers not being able to handle IPv6? > > bunch of whiners, prolly. > > > Is it really not as big a problem as I've heard (I honestly don't know), or > > was the "can be built with '90s hardware" believe a bit optimistic? > > it really isn't a problem. really. > > > Oh, and the urban legend about 64 versus 128 bits I heard from someone who > > was on the IPv6 working group, though I don't recall who it was now. > > everybody who was anybody was on the ipv6 working group. great big parties, > standing room only in the meeting rooms, spilled out into the hallways. > > > I'll take your word on it, but it's still the case that a lot of people > > don't fully understand just how large 64 and 128 bit numbers are. :-) > > while they're representable as numbers, and drc (whose words are not to be > dismissed likely) said here yesterday that they are numbers, to me they are > more usefully thought of as bit vectors. when compared to other bit vectors > like GPU or VLIW ALU's, 128 bits isn't so much. i was perplexed by the very > desperate need to immediately waste half of them on EUI64, as it folks didn't > feel safe when surrounded by all that address space and needed to burn some > of it off to get down to a size they could comprehend, but, 128 bits isn't > really all that large when you consider the 4-bit and 16-bit boundaries > imposed by the PTR naming conventions. > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From jcurran at istaff.org Mon Jun 11 05:16:50 2007 From: jcurran at istaff.org (John Curran) Date: Mon, 11 Jun 2007 05:16:50 -0400 Subject: [ppml] IPv6, Vista, and the Popular Press In-Reply-To: <20070608225853.GA10403@tummy.com> References: <20070608205329.GA42129@ussenterprise.ufp.org> <20070608225853.GA10403@tummy.com> Message-ID: At 4:58 PM -0600 6/8/07, Sean Reifschneider wrote: >I have heard that a large part of the reason IPv6 is 128 bits of address >space instead of 64 is that a significant number of people on the committee >didn't fully understand that 64 bits is way way more than twice the number >of addresses we have with IPv4. The folks on the IPNG Directorate may have disagreed quite a bit over various requirements for IPng, but it was not from being unable to comprehend the size of the address space. /John From jcurran at istaff.org Mon Jun 11 05:32:57 2007 From: jcurran at istaff.org (John Curran) Date: Mon, 11 Jun 2007 05:32:57 -0400 Subject: [ppml] IPv6, Vista, and the Popular Press [more] In-Reply-To: References: <20070608205329.GA42129@ussenterprise.ufp.org> <20070608225853.GA10403@tummy.com> Message-ID: At 5:16 AM -0400 6/11/07, John Curran wrote: >At 4:58 PM -0600 6/8/07, Sean Reifschneider wrote: >>I have heard that a large part of the reason IPv6 is 128 bits of address >>space instead of 64 is that a significant number of people on the committee >>didn't fully understand that 64 bits is way way more than twice the number >>of addresses we have with IPv4. > >The folks on the IPNG Directorate may have disagreed quite >a bit over various requirements for IPng, but it was not from >being unable to comprehend the size of the address space. For clarity: IPv6 address length was set by the IPng Directorate prior to the IPv6 working group coming into existence (i.e. in the 1993 to mid-1994 timeframe). I was a member of this Directorate. /John From ipng at 69706e6720323030352d30312d31340a.nosense.org Mon Jun 11 06:58:29 2007 From: ipng at 69706e6720323030352d30312d31340a.nosense.org (Mark Smith) Date: Mon, 11 Jun 2007 20:28:29 +0930 Subject: [ppml] IPv6, Vista, and the Popular Press [more] In-Reply-To: References: <20070608205329.GA42129@ussenterprise.ufp.org> <20070608225853.GA10403@tummy.com> Message-ID: <20070611202829.aa7d2bee.ipng@69706e6720323030352d30312d31340a.nosense.org> On Mon, 11 Jun 2007 05:32:57 -0400 John Curran wrote: > At 5:16 AM -0400 6/11/07, John Curran wrote: > >At 4:58 PM -0600 6/8/07, Sean Reifschneider wrote: > >>I have heard that a large part of the reason IPv6 is 128 bits of address > >>space instead of 64 is that a significant number of people on the committee > >>didn't fully understand that 64 bits is way way more than twice the number > >>of addresses we have with IPv4. > > > >The folks on the IPNG Directorate may have disagreed quite > >a bit over various requirements for IPng, but it was not from > >being unable to comprehend the size of the address space. > > For clarity: IPv6 address length was set by the IPng Directorate prior > to the IPv6 working group coming into existence (i.e. in the 1993 to > mid-1994 timeframe). I was a member of this Directorate. > By the sounds of it John can probably provide a lot of first hand detail, however, in addition to that, Christian Huitema's book, "IPv6 : The New Internet Protocol", 2nd Edition, provides a lot of explanation of the rational behind a lot of the decisions. >From what I understand from that book, the original IPv6 addressing was 64 bits in size. However, to allow for deriving node addresses from IEEE MAC addresses, and allowing for those to be increased from 48 to 64 bits, the decision was made to make the node address portion of the address 64 bites, and then to make the network portion also 64 bits. Regards, Mark. From Alain_Durand at cable.comcast.com Mon Jun 11 21:38:42 2007 From: Alain_Durand at cable.comcast.com (Durand, Alain) Date: Mon, 11 Jun 2007 21:38:42 -0400 Subject: [ppml] IPv6, Vista, and the Popular Press [more] In-Reply-To: <20070611202829.aa7d2bee.ipng@69706e6720323030352d30312d31340a.nosense.org> Message-ID: > >From what I understand from that book, the original IPv6 > addressing was > 64 bits in size. However, to allow for deriving node > addresses from IEEE MAC addresses, and allowing for those to > be increased from 48 to > 64 bits, the decision was made to make the node address > portion of the address 64 bites, and then to make the network > portion also 64 bits. The 64 bit EUI came much later, at about the same time as 8+8... Steve Deering always told me that his original design was 64 bits as you can read in the original SIP proposal (SIP: Steve's IP) There was at the time disagreement between the proponent of variable length addresses (NSAP) and fixed length address. When SIP and PIP (Paul's IP from Paul Francis) were merged into SIPP (SIP Plus), the compromise was to use a 'long' fixed format, hence 128 bits. - Alain. From jeroen at unfix.org Thu Jun 14 06:00:11 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 14 Jun 2007 11:00:11 +0100 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: References: Message-ID: <467111AB.20203@spaghetti.zurich.ibm.com> [cc'ing RIPE address policy + ARIN PPML where the discussion on this happened, I have not seen any 'operators' who have said the below, if there are they are there and can thus raise their voices because they will see this message; removed the silly spam scoring subject...] JORDI PALET MARTINEZ wrote: > Operators have said that they will not be able to use ULA, but they could > use ULA-C, for example for thinks like microallocations for internal > infrastructure's. I really wonder where you got that idea, as I know of no such operator who would ever say that. If there are any, let them bring up their argumentation, please don't come up with "somebody said that" it does not work that way. Real network operators, especially involved in the RIPE or other RIR's, have more than enough address space from their PA allocations that they can easily receive and they very well know how to use a /48 from that for internal infrastructure as everybody does this. The IPv6 PA policies even describe that a /48 can be used per POP of the owner of the PA block. Also in the ARIN region any organization can get a /48 PI block for about $100/year, as such these organizations won't be needing this address space either as they can easily take a /64 out of that for those needs. Firewalling is the key here. > I think the policy proposal that I sent to several regions includes text and > links to other documents that can clarify this perspective. > > For example in RIPE NCC: > http://www.ripe.net/ripe/policies/proposals/2007-05.html That is your proposal indeed. No "Operator" has stood behind this and various people from various organizations have clearly asked you and the RIPE NCC to *freeze* this proposal till at least the IETF has worked out. Anybody needing a "globally unique" block can get either PA or PI space. ULA-C as such is useless. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From marla.azinger at frontiercorp.com Thu Jun 14 13:31:29 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Thu, 14 Jun 2007 13:31:29 -0400 Subject: [ppml] Revising Centrally Assigned ULA draft Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272F925@nyrofcs2ke2k01.corp.pvt> I think a point here that needs to be looked at is this: If ULA-C is addressed by IETF and then in turn we end up with RIR's responsible for handing out ULA-C blocks, then those existing policy's such as ARIN's NRPM 6.10.2 Microallocations for Internal Infastructure should be expired and no longer an active policy. And there are different flavors to the debate of why ULA-C would be better than such policy as ARIN's NRPM 6.10.2 Microallocations for Internal Infastructure. Ie Standardization, conservation ect... Cheers! Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Jeroen Massar Sent: Thursday, June 14, 2007 3:00 AM To: jordi.palet at consulintel.es Cc: ARIN People Posting Mailing List; ipv6 at ietf.org; address-policy-wg at ripe.net Subject: Re: [ppml] Revising Centrally Assigned ULA draft [cc'ing RIPE address policy + ARIN PPML where the discussion on this happened, I have not seen any 'operators' who have said the below, if there are they are there and can thus raise their voices because they will see this message; removed the silly spam scoring subject...] JORDI PALET MARTINEZ wrote: > Operators have said that they will not be able to use ULA, but they could > use ULA-C, for example for thinks like microallocations for internal > infrastructure's. I really wonder where you got that idea, as I know of no such operator who would ever say that. If there are any, let them bring up their argumentation, please don't come up with "somebody said that" it does not work that way. Real network operators, especially involved in the RIPE or other RIR's, have more than enough address space from their PA allocations that they can easily receive and they very well know how to use a /48 from that for internal infrastructure as everybody does this. The IPv6 PA policies even describe that a /48 can be used per POP of the owner of the PA block. Also in the ARIN region any organization can get a /48 PI block for about $100/year, as such these organizations won't be needing this address space either as they can easily take a /64 out of that for those needs. Firewalling is the key here. > I think the policy proposal that I sent to several regions includes text and > links to other documents that can clarify this perspective. > > For example in RIPE NCC: > http://www.ripe.net/ripe/policies/proposals/2007-05.html That is your proposal indeed. No "Operator" has stood behind this and various people from various organizations have clearly asked you and the RIPE NCC to *freeze* this proposal till at least the IETF has worked out. Anybody needing a "globally unique" block can get either PA or PI space. ULA-C as such is useless. Greets, Jeroen From Lee.Howard at stanleyassociates.com Thu Jun 14 17:13:46 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 14 Jun 2007 17:13:46 -0400 Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <008601c7aadb$8b443010$081872cf@Leadmon.local> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4062205D7@CL-S-EX-1.stanleyassociates.com> > I would have to agree with that, I can't tell you how many > times I have seen stuff setup just to fake need for space, Do you ever say, "Hey, don't commit fraud"? > used. Heck just the other day I was talking with some about > an ISP purchase, and that one of the sellers got the ISP to > let him keep one of the /18's personally. I know the guy, he > has no place to use it, just knows that IP space costs $$, > and as it was a pre-ARIN block from long ago, knew he could > just keep hang on to it in case he had a need for it > sometime. Did you say, "I don't think that's consistent with ARIN's policies or the community's best interest" ? Do I correctly understand that you believe the above examples to be deceptive and contrary to the common good? Lee From dean at av8.com Fri Jun 15 00:37:36 2007 From: dean at av8.com (Dean Anderson) Date: Fri, 15 Jun 2007 00:37:36 -0400 (EDT) Subject: [ppml] Suggestion for ARIN to deligate smaller IP blocks In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4062205D7@CL-S-EX-1.stanleyassociates.com> Message-ID: On Thu, 14 Jun 2007, Howard, W. Lee wrote: > > I would have to agree with that, I can't tell you how many > > times I have seen stuff setup just to fake need for space, > > Do you ever say, "Hey, don't commit fraud"? Saying this often does no good, and elicits responses from chuckles to revenge blocks to silence the complaints. Many people, senior people, high officials at internet-related non-profit corporations even, seem to think that they have a right to make material false statements, deprive others of their legal rights, and personally profit in the scheme. A recent example is found at http://www.av8.net/IETF-watch/People/Housley/ If you want to volunteer legal services, please contact me for more information. > > used. Heck just the other day I was talking with some about > > an ISP purchase, and that one of the sellers got the ISP to > > let him keep one of the /18's personally. I know the guy, he > > has no place to use it, just knows that IP space costs $$, > > and as it was a pre-ARIN block from long ago, knew he could > > just keep hang on to it in case he had a need for it > > sometime. > > Did you say, "I don't think that's consistent with ARIN's > policies or the community's best interest" ? > > Do I correctly understand that you believe the above examples > to be deceptive and contrary to the common good? > > Lee > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From martin.hannigan at batelnet.bs Fri Jun 15 01:56:12 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Fri, 15 Jun 2007 01:56:12 -0400 Subject: [ppml] IPv6, Vista, and the Popular Press Message-ID: <467229fc.44.4ee8.4193@batelnet.bs> ----- Original Message ----- From: To: Subject: Re: [ppml] IPv6, Vista, and the Popular Press Date: Sat, 9 Jun 2007 23:52:54 +0100 > > With the Board's recent step to get the IPv6 word out, > > is there anything else the RIR community can do to head > > off the advice of "just turn it off"? If sysadmins are > > deinstalling IPv6 support in OS's like Vista then > > deploying IPv6 is going to be even more difficult. > > If the board was serious about wanting to warn the public I would call a board resolution and a subsequent press release serious, Michael. -M< From alh-ietf at tndh.net Fri Jun 15 03:23:29 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Fri, 15 Jun 2007 16:23:29 +0900 Subject: [ppml] IPv6, Vista, and the Popular Press [more] In-Reply-To: References: <20070611202829.aa7d2bee.ipng@69706e6720323030352d30312d31340a.nosense.org> Message-ID: <163901c7af1e$142aafd0$3c800f70$@net> Durand, Alain wrote: > > >From what I understand from that book, the original IPv6 > > addressing was > > 64 bits in size. However, to allow for deriving node > > addresses from IEEE MAC addresses, and allowing for those to > > be increased from 48 to > > 64 bits, the decision was made to make the node address > > portion of the address 64 bites, and then to make the network > > portion also 64 bits. > > The 64 bit EUI came much later, at about the same time as 8+8... > Steve Deering always told me that his original design was 64 bits as > you can read in the original SIP proposal (SIP: Steve's IP) > There was at the time disagreement between the proponent of variable > length addresses (NSAP) and fixed length address. > When SIP and PIP (Paul's IP from Paul Francis) were merged into > SIPP (SIP Plus), the compromise was to use a 'long' fixed format, > hence 128 bits. The problem of the day that caused more than 64 bits was that 'too many bits were being used by the pesky hosts to allow for the ISP hierarchy that was expected'. This resulted in giving the entire 64 bits of the original design to routing. People keep complaining about waste, but the reality is that the real waste is in giving more bits to the routing system that will never use them. IPv6 is not the last protocol known to mankind. It will be replaced long before the public routing world uses 2^48. Myopic conservatism is the real source of waste because it precludes the opportunity for others to innovate with bits that would otherwise sit on the shelf forever. Tony From narten at us.ibm.com Fri Jun 15 10:19:15 2007 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 15 Jun 2007 10:19:15 -0400 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <467111AB.20203@spaghetti.zurich.ibm.com> References: <467111AB.20203@spaghetti.zurich.ibm.com> Message-ID: <200706151419.l5FEJF7f026533@cichlid.raleigh.ibm.com> Jeroen Massar writes: > JORDI PALET MARTINEZ wrote: > > Operators have said that they will not be able to use ULA, but they cou= > ld > > use ULA-C, for example for thinks like microallocations for internal > > infrastructure's. > I really wonder where you got that idea, as I know of no such operator > who would ever say that. If there are any, let them bring up their > argumentation, please don't come up with "somebody said that" it does > not work that way. Maybe the assertion came from those who supported ARIN Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure (http://www.arin.net/policy/proposals/2006_2.html), where using a /48 out of their aggregate did not solve the technical problem at hand. At that time, the question was raised whether ULA-P solved the problem adequately. The answer I heard was a very clear "no". And ULA-C (if had existed then) would have. Thomas From info at arin.net Fri Jun 15 10:32:46 2007 From: info at arin.net (Member Services) Date: Fri, 15 Jun 2007 10:32:46 -0400 Subject: [ppml] Policy Implementation Schedule Message-ID: <4672A30E.8020403@arin.net> On 14 June 2007 the ARIN Board of Trustees adopted five policy proposals: 2007-4: Changes to IPv6 policy - removal of "interim" consideration 2007-7: Creation of Policy for Subsequent End-User IP Requests/Assignments 2007-8: Transfer Policy Clarifications 2007-9: Modernization of ISP Immediate Need Policy 2007-11: Refinement of ISP Initial Allocation Policy These proposals will be implemented no later than 15 September 2007. Policy proposal texts are available at the Policy Proposal Archive which can be found at: http://www.arin.net/policy/proposal_archive.html Regards, Member Services Department American Registry for Internet Numbers From jordi.palet at consulintel.es Fri Jun 15 11:14:43 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 15 Jun 2007 15:14:43 +0000 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <467111AB.20203@spaghetti.zurich.ibm.com> Message-ID: If you doubt about folks stating anything, then you should read *before* minutes of meetings. I'm now off-line in a plane, so can't point you to a specific URL, but this has been said at least in one ARIN meeting. It has been clear across all this discussion in several exploders, that there are both opinions, people that want ULA-C and people that don't. What you need to be smart here is to realize that those than don't want ULA-C have no any objective reason to oppose to it, because implementing ULA-C has no negative impact in others. While opposing to it has negative impact to all: Folks will use global space (PA or PI) for doing the function of ULA-C an this is a waste, yes a small waste but a waste. It seems to me irresponsible and unbalanced to do or try things like changing the HD-ratio or the default assignment size to end-sites because it is a waste, and then oppose to those that want to have ULA-C, not impacting in others and avoiding one further small saving in global unicast space. I'm not trying to convince anyone about supporting ULA-C, because it seems an impossible mission at least for a few, but at least, don't object to it if having it doesn't force you in any further implications, which is the case. Regards, Jordi > De: Jeroen Massar > Organizaci?n: Unfix > Responder a: > Fecha: Thu, 14 Jun 2007 11:00:11 +0100 > Para: > CC: ARIN People Posting Mailing List , , > "address-policy-wg at ripe.net" > Asunto: Re: Revising Centrally Assigned ULA draft > > [cc'ing RIPE address policy + ARIN PPML where the discussion on this > happened, I have not seen any 'operators' who have said the below, if > there are they are there and can thus raise their voices because they > will see this message; removed the silly spam scoring subject...] > > JORDI PALET MARTINEZ wrote: >> Operators have said that they will not be able to use ULA, but they could >> use ULA-C, for example for thinks like microallocations for internal >> infrastructure's. > > I really wonder where you got that idea, as I know of no such operator > who would ever say that. If there are any, let them bring up their > argumentation, please don't come up with "somebody said that" it does > not work that way. > > Real network operators, especially involved in the RIPE or other RIR's, > have more than enough address space from their PA allocations that they > can easily receive and they very well know how to use a /48 from that > for internal infrastructure as everybody does this. The IPv6 PA policies > even describe that a /48 can be used per POP of the owner of the PA block. > > Also in the ARIN region any organization can get a /48 PI block for > about $100/year, as such these organizations won't be needing this > address space either as they can easily take a /64 out of that for those > needs. Firewalling is the key here. > > >> I think the policy proposal that I sent to several regions includes text and >> links to other documents that can clarify this perspective. >> >> For example in RIPE NCC: >> http://www.ripe.net/ripe/policies/proposals/2007-05.html > > That is your proposal indeed. No "Operator" has stood behind this and > various people from various organizations have clearly asked you and the > RIPE NCC to *freeze* this proposal till at least the IETF has worked out. > > Anybody needing a "globally unique" block can get either PA or PI space. > ULA-C as such is useless. > > Greets, > Jeroen > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6 at ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Fri Jun 15 12:03:25 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 15 Jun 2007 16:03:25 +0000 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A0272F925@nyrofcs2ke2k01.corp.pvt> Message-ID: Hi Marla, In fact, when I started to work on this, it was because I realized about the possibility to use ULA-C as the space for the microallocations and talking with different folks they said that it will be possible with ULA-C, but not ULA. I also talked with people from the AC and they considered the point (I was told) to use ULA-C for the microallocations when ULA-C is available. So my view is that probably the microallocations policy should not expire, but instead, be modified to make usage of the ULA-C space instead of global unicast. Regards, Jordi > De: "Azinger, Marla" > Responder a: > Fecha: Thu, 14 Jun 2007 13:31:29 -0400 > Para: Jeroen Massar , > CC: ARIN People Posting Mailing List , , > > Conversaci?n: [ppml] Revising Centrally Assigned ULA draft > Asunto: RE: [ppml] Revising Centrally Assigned ULA draft > > I think a point here that needs to be looked at is this: > > If ULA-C is addressed by IETF and then in turn we end up with RIR's > responsible for handing out ULA-C blocks, then those existing policy's such as > ARIN's NRPM 6.10.2 Microallocations for Internal Infastructure should be > expired and no longer an active policy. > > And there are different flavors to the debate of why ULA-C would be better > than such policy as ARIN's NRPM 6.10.2 Microallocations for Internal > Infastructure. Ie Standardization, conservation ect... > > Cheers! > Marla Azinger > Frontier Communications > > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Jeroen Massar > Sent: Thursday, June 14, 2007 3:00 AM > To: jordi.palet at consulintel.es > Cc: ARIN People Posting Mailing List; ipv6 at ietf.org; > address-policy-wg at ripe.net > Subject: Re: [ppml] Revising Centrally Assigned ULA draft > > > [cc'ing RIPE address policy + ARIN PPML where the discussion on this > happened, I have not seen any 'operators' who have said the below, if > there are they are there and can thus raise their voices because they > will see this message; removed the silly spam scoring subject...] > > JORDI PALET MARTINEZ wrote: >> Operators have said that they will not be able to use ULA, but they could >> use ULA-C, for example for thinks like microallocations for internal >> infrastructure's. > > I really wonder where you got that idea, as I know of no such operator > who would ever say that. If there are any, let them bring up their > argumentation, please don't come up with "somebody said that" it does > not work that way. > > Real network operators, especially involved in the RIPE or other RIR's, > have more than enough address space from their PA allocations that they > can easily receive and they very well know how to use a /48 from that > for internal infrastructure as everybody does this. The IPv6 PA policies > even describe that a /48 can be used per POP of the owner of the PA block. > > Also in the ARIN region any organization can get a /48 PI block for > about $100/year, as such these organizations won't be needing this > address space either as they can easily take a /64 out of that for those > needs. Firewalling is the key here. > > >> I think the policy proposal that I sent to several regions includes text and >> links to other documents that can clarify this perspective. >> >> For example in RIPE NCC: >> http://www.ripe.net/ripe/policies/proposals/2007-05.html > > That is your proposal indeed. No "Operator" has stood behind this and > various people from various organizations have clearly asked you and the > RIPE NCC to *freeze* this proposal till at least the IETF has worked out. > > Anybody needing a "globally unique" block can get either PA or PI space. > ULA-C as such is useless. > > Greets, > Jeroen > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From marla.azinger at frontiercorp.com Fri Jun 15 15:14:31 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Fri, 15 Jun 2007 15:14:31 -0400 Subject: [ppml] Revising Centrally Assigned ULA draft Message-ID: <454810F09B5AA04E9D78D13A5C39028A023EFACB@nyrofcs2ke2k01.corp.pvt> Jordi- We are saying the same thing. Just how you get there is different. It is true, we could either modify or eliminate the current ARIN policy to work in unison with what might be a finsished RFC on ULA-C. I just believe that sometimes it is easier to start with a fresh policy. In this case, I think it would be less confusing to expire the current policy and replace it with a new one that is more fitting as opposed to trying to modify the current one. A modification could quickly confuse anyone who has not been following all of the ULA emails and conversations. I suppose we can figure this out when we get to that bridge. Cheers! Marla Azinger Frontier Communications ARIN AC -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of JORDI PALET MARTINEZ Sent: Friday, June 15, 2007 9:03 AM To: ARIN People Posting Mailing List Cc: ipv6 at ietf.org; address-policy-wg at ripe.net Subject: Re: [ppml] Revising Centrally Assigned ULA draft Hi Marla, In fact, when I started to work on this, it was because I realized about the possibility to use ULA-C as the space for the microallocations and talking with different folks they said that it will be possible with ULA-C, but not ULA. I also talked with people from the AC and they considered the point (I was told) to use ULA-C for the microallocations when ULA-C is available. So my view is that probably the microallocations policy should not expire, but instead, be modified to make usage of the ULA-C space instead of global unicast. Regards, Jordi > De: "Azinger, Marla" > Responder a: > Fecha: Thu, 14 Jun 2007 13:31:29 -0400 > Para: Jeroen Massar , > CC: ARIN People Posting Mailing List , , > > Conversaci?n: [ppml] Revising Centrally Assigned ULA draft > Asunto: RE: [ppml] Revising Centrally Assigned ULA draft > > I think a point here that needs to be looked at is this: > > If ULA-C is addressed by IETF and then in turn we end up with RIR's > responsible for handing out ULA-C blocks, then those existing policy's such as > ARIN's NRPM 6.10.2 Microallocations for Internal Infastructure should be > expired and no longer an active policy. > > And there are different flavors to the debate of why ULA-C would be better > than such policy as ARIN's NRPM 6.10.2 Microallocations for Internal > Infastructure. Ie Standardization, conservation ect... > > Cheers! > Marla Azinger > Frontier Communications > > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Jeroen Massar > Sent: Thursday, June 14, 2007 3:00 AM > To: jordi.palet at consulintel.es > Cc: ARIN People Posting Mailing List; ipv6 at ietf.org; > address-policy-wg at ripe.net > Subject: Re: [ppml] Revising Centrally Assigned ULA draft > > > [cc'ing RIPE address policy + ARIN PPML where the discussion on this > happened, I have not seen any 'operators' who have said the below, if > there are they are there and can thus raise their voices because they > will see this message; removed the silly spam scoring subject...] > > JORDI PALET MARTINEZ wrote: >> Operators have said that they will not be able to use ULA, but they could >> use ULA-C, for example for thinks like microallocations for internal >> infrastructure's. > > I really wonder where you got that idea, as I know of no such operator > who would ever say that. If there are any, let them bring up their > argumentation, please don't come up with "somebody said that" it does > not work that way. > > Real network operators, especially involved in the RIPE or other RIR's, > have more than enough address space from their PA allocations that they > can easily receive and they very well know how to use a /48 from that > for internal infrastructure as everybody does this. The IPv6 PA policies > even describe that a /48 can be used per POP of the owner of the PA block. > > Also in the ARIN region any organization can get a /48 PI block for > about $100/year, as such these organizations won't be needing this > address space either as they can easily take a /64 out of that for those > needs. Firewalling is the key here. > > >> I think the policy proposal that I sent to several regions includes text and >> links to other documents that can clarify this perspective. >> >> For example in RIPE NCC: >> http://www.ripe.net/ripe/policies/proposals/2007-05.html > > That is your proposal indeed. No "Operator" has stood behind this and > various people from various organizations have clearly asked you and the > RIPE NCC to *freeze* this proposal till at least the IETF has worked out. > > Anybody needing a "globally unique" block can get either PA or PI space. > ULA-C as such is useless. > > Greets, > Jeroen > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From owen at delong.com Fri Jun 15 15:40:52 2007 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Jun 2007 12:40:52 -0700 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: References: Message-ID: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> On Jun 15, 2007, at 8:14 AM, JORDI PALET MARTINEZ wrote: > If you doubt about folks stating anything, then you should read > *before* > minutes of meetings. I'm now off-line in a plane, so can't point > you to a > specific URL, but this has been said at least in one ARIN meeting. > > It has been clear across all this discussion in several exploders, > that > there are both opinions, people that want ULA-C and people that > don't. What > you need to be smart here is to realize that those than don't want > ULA-C > have no any objective reason to oppose to it, because implementing > ULA-C has > no negative impact in others. While opposing to it has negative > impact to > all: Folks will use global space (PA or PI) for doing the function > of ULA-C > an this is a waste, yes a small waste but a waste. > Jordi, You have this backwards. Using PI for the purposes of ULA-C is no waste at all. Sectioning off a huge chunk of address space for ULA-C is the waste. If it's all PI, then, it can seamlessly move between being unrouted or routed as the address-holder sees fit and as needs change. If it is set aside as ULA, then, the address space is forever wasted and cannot (theoretically) be used as routable space, no matter how little of it is needed for ULA-C. Those of us who oppose ULA-C have what we believe to be an objective position that it provides no additional benefit over PI space while simultaneously creating some unnecessary classification of addresses that makes their status in the routing table ill-defined at best. In our opinion, this carries the potential for significant consequences globally. Just because we do not agree with you does not mean that our concerns are not legitimate. Do I think UUNET and others should be able to get secondary microallocations to solve the problem they presented? Absolutely. Do I think that we need to set aside a /8, /12, /16, or whatever separate from the rest of PI space to do it? No. We should just issue them a /48 or whatever it is they need from the general pool of available PI space and be done with it. No waste at all. No negative consequences to anyone. No ambiguous status as to where you can or can't route the addresses, etc. Owen From kkargel at polartel.com Fri Jun 15 16:13:40 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 15 Jun 2007 15:13:40 -0500 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106670703C@mail> I agree wholeheartedly. There is nothing you can do with ULA-C that you can't do with PI and a minor firewall rule or two. Leaving the space as PI gives it either-or capability, putting it as ULA reduces PI. (And don't talk about 'more PI than we could ever use'.. remember when Mr. Gates told us you would never need more than 640K of RAM?)(of course he denies it now..) > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Owen DeLong > Sent: Friday, June 15, 2007 2:41 PM > To: jordi.palet at consulintel.es > Cc: ARIN People Posting Mailing List; ipv6 at ietf.org; > address-policy-wg at ripe.net > Subject: Re: [ppml] Revising Centrally Assigned ULA draft > > > On Jun 15, 2007, at 8:14 AM, JORDI PALET MARTINEZ wrote: > > > If you doubt about folks stating anything, then you should read > > *before* > > minutes of meetings. I'm now off-line in a plane, so can't > point you > > to a specific URL, but this has been said at least in one ARIN > > meeting. > > > > It has been clear across all this discussion in several exploders, > > that there are both opinions, people that want ULA-C and > people that > > don't. What you need to be smart here is to realize that those than > > don't want ULA-C have no any objective reason to oppose to > it, because > > implementing ULA-C has no negative impact in others. While > opposing to > > it has negative impact to > > all: Folks will use global space (PA or PI) for doing the > function of > > ULA-C an this is a waste, yes a small waste but a waste. > > > Jordi, > You have this backwards. Using PI for the purposes of > ULA-C is no waste at all. Sectioning off a huge chunk of > address space for ULA-C is the waste. > If it's all PI, then, it can seamlessly move between being > unrouted or routed as the address-holder sees fit and as > needs change. If it is set aside as ULA, then, the address > space is forever wasted and cannot (theoretically) be used as > routable space, no matter how little of it is needed for ULA-C. > > Those of us who oppose ULA-C have what we believe to be > an objective position that it provides no additional benefit > over PI space while simultaneously creating some unnecessary > classification of addresses that makes their status in the > routing table ill-defined at best. In our opinion, this > carries the potential for significant consequences globally. > > Just because we do not agree with you does not mean > that our concerns are not legitimate. > > Do I think UUNET and others should be able to get > secondary microallocations to solve the problem they > presented? Absolutely. Do I think that we need to set aside > a /8, /12, /16, or whatever separate from the rest of PI > space to do it? No. > We should just issue them a /48 or whatever it is they need > from the general pool of available PI space and be done with > it. No waste at all. No negative consequences to anyone. > No ambiguous status as to where you can or can't route the > addresses, etc. > > Owen > > _______________________________________________ > This message sent to you through the ARIN Public Policy > Mailing List (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From tcrosby at bgmu.com Fri Jun 15 16:15:07 2007 From: tcrosby at bgmu.com (Todd Crosby) Date: Fri, 15 Jun 2007 15:15:07 -0500 Subject: [ppml] PPML Digest, Vol 24, Issue 27 (Auto Reply) Message-ID: I will be on vacation from Friday 6/15/2007 to MTuesday 6/19/2007. If you need immediate assistance please contact our NOC or 24 hr dispatch. Thank You >>> ppml 06/15/07 15:13 >>> Send PPML mailing list submissions to ppml at arin.net To subscribe or unsubscribe via the World Wide Web, visit http://lists.arin.net/mailman/listinfo/ppml or, via email, send a message with subject or body 'help' to ppml-request at arin.net You can reach the person managing the list at ppml-owner at arin.net When replying, please edit your Subject line so it is more specific than "Re: Contents of PPML digest..." Today's Topics: 1. Re: Revising Centrally Assigned ULA draft (JORDI PALET MARTINEZ) 2. Re: Revising Centrally Assigned ULA draft (JORDI PALET MARTINEZ) 3. Re: Revising Centrally Assigned ULA draft (Azinger, Marla) 4. Re: Revising Centrally Assigned ULA draft (Owen DeLong) 5. Re: Revising Centrally Assigned ULA draft (Kevin Kargel) ---------------------------------------------------------------------- Message: 1 Date: Fri, 15 Jun 2007 15:14:43 +0000 From: JORDI PALET MARTINEZ Subject: Re: [ppml] Revising Centrally Assigned ULA draft To: Cc: ARIN People Posting Mailing List , "address-policy-wg at ripe.net" Message-ID: Content-Type: text/plain; charset="ISO-8859-1" If you doubt about folks stating anything, then you should read *before* minutes of meetings. I'm now off-line in a plane, so can't point you to a specific URL, but this has been said at least in one ARIN meeting. It has been clear across all this discussion in several exploders, that there are both opinions, people that want ULA-C and people that don't. What you need to be smart here is to realize that those than don't want ULA-C have no any objective reason to oppose to it, because implementing ULA-C has no negative impact in others. While opposing to it has negative impact to all: Folks will use global space (PA or PI) for doing the function of ULA-C an this is a waste, yes a small waste but a waste. It seems to me irresponsible and unbalanced to do or try things like changing the HD-ratio or the default assignment size to end-sites because it is a waste, and then oppose to those that want to have ULA-C, not impacting in others and avoiding one further small saving in global unicast space. I'm not trying to convince anyone about supporting ULA-C, because it seems an impossible mission at least for a few, but at least, don't object to it if having it doesn't force you in any further implications, which is the case. Regards, Jordi > De: Jeroen Massar > Organizaci?n: Unfix > Responder a: > Fecha: Thu, 14 Jun 2007 11:00:11 +0100 > Para: > CC: ARIN People Posting Mailing List , , > "address-policy-wg at ripe.net" > Asunto: Re: Revising Centrally Assigned ULA draft > > [cc'ing RIPE address policy + ARIN PPML where the discussion on this > happened, I have not seen any 'operators' who have said the below, if > there are they are there and can thus raise their voices because they > will see this message; removed the silly spam scoring subject...] > > JORDI PALET MARTINEZ wrote: >> Operators have said that they will not be able to use ULA, but they could >> use ULA-C, for example for thinks like microallocations for internal >> infrastructure's. > > I really wonder where you got that idea, as I know of no such operator > who would ever say that. If there are any, let them bring up their > argumentation, please don't come up with "somebody said that" it does > not work that way. > > Real network operators, especially involved in the RIPE or other RIR's, > have more than enough address space from their PA allocations that they > can easily receive and they very well know how to use a /48 from that > for internal infrastructure as everybody does this. The IPv6 PA policies > even describe that a /48 can be used per POP of the owner of the PA block. > > Also in the ARIN region any organization can get a /48 PI block for > about $100/year, as such these organizations won't be needing this > address space either as they can easily take a /64 out of that for those > needs. Firewalling is the key here. > > >> I think the policy proposal that I sent to several regions includes text and >> links to other documents that can clarify this perspective. >> >> For example in RIPE NCC: >> http://www.ripe.net/ripe/policies/proposals/2007-05.html > > That is your proposal indeed. No "Operator" has stood behind this and > various people from various organizations have clearly asked you and the > RIPE NCC to *freeze* this proposal till at least the IETF has worked out. > > Anybody needing a "globally unique" block can get either PA or PI space. > ULA-C as such is useless. > > Greets, > Jeroen > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6 at ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ------------------------------ Message: 2 Date: Fri, 15 Jun 2007 16:03:25 +0000 From: JORDI PALET MARTINEZ Subject: Re: [ppml] Revising Centrally Assigned ULA draft To: ARIN People Posting Mailing List Cc: ipv6 at ietf.org, address-policy-wg at ripe.net Message-ID: Content-Type: text/plain; charset="ISO-8859-1" Hi Marla, In fact, when I started to work on this, it was because I realized about the possibility to use ULA-C as the space for the microallocations and talking with different folks they said that it will be possible with ULA-C, but not ULA. I also talked with people from the AC and they considered the point (I was told) to use ULA-C for the microallocations when ULA-C is available. So my view is that probably the microallocations policy should not expire, but instead, be modified to make usage of the ULA-C space instead of global unicast. Regards, Jordi > De: "Azinger, Marla" > Responder a: > Fecha: Thu, 14 Jun 2007 13:31:29 -0400 > Para: Jeroen Massar , > CC: ARIN People Posting Mailing List , , > > Conversaci?n: [ppml] Revising Centrally Assigned ULA draft > Asunto: RE: [ppml] Revising Centrally Assigned ULA draft > > I think a point here that needs to be looked at is this: > > If ULA-C is addressed by IETF and then in turn we end up with RIR's > responsible for handing out ULA-C blocks, then those existing policy's such as > ARIN's NRPM 6.10.2 Microallocations for Internal Infastructure should be > expired and no longer an active policy. > > And there are different flavors to the debate of why ULA-C would be better > than such policy as ARIN's NRPM 6.10.2 Microallocations for Internal > Infastructure. Ie Standardization, conservation ect... > > Cheers! > Marla Azinger > Frontier Communications > > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Jeroen Massar > Sent: Thursday, June 14, 2007 3:00 AM > To: jordi.palet at consulintel.es > Cc: ARIN People Posting Mailing List; ipv6 at ietf.org; > address-policy-wg at ripe.net > Subject: Re: [ppml] Revising Centrally Assigned ULA draft > > > [cc'ing RIPE address policy + ARIN PPML where the discussion on this > happened, I have not seen any 'operators' who have said the below, if > there are they are there and can thus raise their voices because they > will see this message; removed the silly spam scoring subject...] > > JORDI PALET MARTINEZ wrote: >> Operators have said that they will not be able to use ULA, but they could >> use ULA-C, for example for thinks like microallocations for internal >> infrastructure's. > > I really wonder where you got that idea, as I know of no such operator > who would ever say that. If there are any, let them bring up their > argumentation, please don't come up with "somebody said that" it does > not work that way. > > Real network operators, especially involved in the RIPE or other RIR's, > have more than enough address space from their PA allocations that they > can easily receive and they very well know how to use a /48 from that > for internal infrastructure as everybody does this. The IPv6 PA policies > even describe that a /48 can be used per POP of the owner of the PA block. > > Also in the ARIN region any organization can get a /48 PI block for > about $100/year, as such these organizations won't be needing this > address space either as they can easily take a /64 out of that for those > needs. Firewalling is the key here. > > >> I think the policy proposal that I sent to several regions includes text and >> links to other documents that can clarify this perspective. >> >> For example in RIPE NCC: >> http://www.ripe.net/ripe/policies/proposals/2007-05.html > > That is your proposal indeed. No "Operator" has stood behind this and > various people from various organizations have clearly asked you and the > RIPE NCC to *freeze* this proposal till at least the IETF has worked out. > > Anybody needing a "globally unique" block can get either PA or PI space. > ULA-C as such is useless. > > Greets, > Jeroen > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ------------------------------ Message: 3 Date: Fri, 15 Jun 2007 15:14:31 -0400 From: "Azinger, Marla" Subject: Re: [ppml] Revising Centrally Assigned ULA draft To: , "ARIN People Posting Mailing List" Cc: ipv6 at ietf.org, address-policy-wg at ripe.net Message-ID: <454810F09B5AA04E9D78D13A5C39028A023EFACB at nyrofcs2ke2k01.corp.pvt> Content-Type: text/plain; charset="iso-8859-1" Jordi- We are saying the same thing. Just how you get there is different. It is true, we could either modify or eliminate the current ARIN policy to work in unison with what might be a finsished RFC on ULA-C. I just believe that sometimes it is easier to start with a fresh policy. In this case, I think it would be less confusing to expire the current policy and replace it with a new one that is more fitting as opposed to trying to modify the current one. A modification could quickly confuse anyone who has not been following all of the ULA emails and conversations. I suppose we can figure this out when we get to that bridge. Cheers! Marla Azinger Frontier Communications ARIN AC -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of JORDI PALET MARTINEZ Sent: Friday, June 15, 2007 9:03 AM To: ARIN People Posting Mailing List Cc: ipv6 at ietf.org; address-policy-wg at ripe.net Subject: Re: [ppml] Revising Centrally Assigned ULA draft Hi Marla, In fact, when I started to work on this, it was because I realized about the possibility to use ULA-C as the space for the microallocations and talking with different folks they said that it will be possible with ULA-C, but not ULA. I also talked with people from the AC and they considered the point (I was told) to use ULA-C for the microallocations when ULA-C is available. So my view is that probably the microallocations policy should not expire, but instead, be modified to make usage of the ULA-C space instead of global unicast. Regards, Jordi > De: "Azinger, Marla" > Responder a: > Fecha: Thu, 14 Jun 2007 13:31:29 -0400 > Para: Jeroen Massar , > CC: ARIN People Posting Mailing List , , > > Conversaci?n: [ppml] Revising Centrally Assigned ULA draft > Asunto: RE: [ppml] Revising Centrally Assigned ULA draft > > I think a point here that needs to be looked at is this: > > If ULA-C is addressed by IETF and then in turn we end up with RIR's > responsible for handing out ULA-C blocks, then those existing policy's such as > ARIN's NRPM 6.10.2 Microallocations for Internal Infastructure should be > expired and no longer an active policy. > > And there are different flavors to the debate of why ULA-C would be better > than such policy as ARIN's NRPM 6.10.2 Microallocations for Internal > Infastructure. Ie Standardization, conservation ect... > > Cheers! > Marla Azinger > Frontier Communications > > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > Jeroen Massar > Sent: Thursday, June 14, 2007 3:00 AM > To: jordi.palet at consulintel.es > Cc: ARIN People Posting Mailing List; ipv6 at ietf.org; > address-policy-wg at ripe.net > Subject: Re: [ppml] Revising Centrally Assigned ULA draft > > > [cc'ing RIPE address policy + ARIN PPML where the discussion on this > happened, I have not seen any 'operators' who have said the below, if > there are they are there and can thus raise their voices because they > will see this message; removed the silly spam scoring subject...] > > JORDI PALET MARTINEZ wrote: >> Operators have said that they will not be able to use ULA, but they could >> use ULA-C, for example for thinks like microallocations for internal >> infrastructure's. > > I really wonder where you got that idea, as I know of no such operator > who would ever say that. If there are any, let them bring up their > argumentation, please don't come up with "somebody said that" it does > not work that way. > > Real network operators, especially involved in the RIPE or other RIR's, > have more than enough address space from their PA allocations that they > can easily receive and they very well know how to use a /48 from that > for internal infrastructure as everybody does this. The IPv6 PA policies > even describe that a /48 can be used per POP of the owner of the PA block. > > Also in the ARIN region any organization can get a /48 PI block for > about $100/year, as such these organizations won't be needing this > address space either as they can easily take a /64 out of that for those > needs. Firewalling is the key here. > > >> I think the policy proposal that I sent to several regions includes text and >> links to other documents that can clarify this perspective. >> >> For example in RIPE NCC: >> http://www.ripe.net/ripe/policies/proposals/2007-05.html > > That is your proposal indeed. No "Operator" has stood behind this and > various people from various organizations have clearly asked you and the > RIPE NCC to *freeze* this proposal till at least the IETF has worked out. > > Anybody needing a "globally unique" block can get either PA or PI space. > ULA-C as such is useless. > > Greets, > Jeroen > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml ------------------------------ Message: 4 Date: Fri, 15 Jun 2007 12:40:52 -0700 From: Owen DeLong Subject: Re: [ppml] Revising Centrally Assigned ULA draft To: jordi.palet at consulintel.es Cc: ARIN People Posting Mailing List , ipv6 at ietf.org, "address-policy-wg at ripe.net" Message-ID: <04576D9D-F221-480C-A38E-421D96C3251E at delong.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jun 15, 2007, at 8:14 AM, JORDI PALET MARTINEZ wrote: > If you doubt about folks stating anything, then you should read > *before* > minutes of meetings. I'm now off-line in a plane, so can't point > you to a > specific URL, but this has been said at least in one ARIN meeting. > > It has been clear across all this discussion in several exploders, > that > there are both opinions, people that want ULA-C and people that > don't. What > you need to be smart here is to realize that those than don't want > ULA-C > have no any objective reason to oppose to it, because implementing > ULA-C has > no negative impact in others. While opposing to it has negative > impact to > all: Folks will use global space (PA or PI) for doing the function > of ULA-C > an this is a waste, yes a small waste but a waste. > Jordi, You have this backwards. Using PI for the purposes of ULA-C is no waste at all. Sectioning off a huge chunk of address space for ULA-C is the waste. If it's all PI, then, it can seamlessly move between being unrouted or routed as the address-holder sees fit and as needs change. If it is set aside as ULA, then, the address space is forever wasted and cannot (theoretically) be used as routable space, no matter how little of it is needed for ULA-C. Those of us who oppose ULA-C have what we believe to be an objective position that it provides no additional benefit over PI space while simultaneously creating some unnecessary classification of addresses that makes their status in the routing table ill-defined at best. In our opinion, this carries the potential for significant consequences globally. Just because we do not agree with you does not mean that our concerns are not legitimate. Do I think UUNET and others should be able to get secondary microallocations to solve the problem they presented? Absolutely. Do I think that we need to set aside a /8, /12, /16, or whatever separate from the rest of PI space to do it? No. We should just issue them a /48 or whatever it is they need from the general pool of available PI space and be done with it. No waste at all. No negative consequences to anyone. No ambiguous status as to where you can or can't route the addresses, etc. Owen ------------------------------ Message: 5 Date: Fri, 15 Jun 2007 15:13:40 -0500 From: "Kevin Kargel" Subject: Re: [ppml] Revising Centrally Assigned ULA draft To: "Owen DeLong" , Cc: ARIN People Posting Mailing List , ipv6 at ietf.org, address-policy-wg at ripe.net Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106670703C at mail> Content-Type: text/plain; charset="us-ascii" I agree wholeheartedly. There is nothing you can do with ULA-C that you can't do with PI and a minor firewall rule or two. Leaving the space as PI gives it either-or capability, putting it as ULA reduces PI. (And don't talk about 'more PI than we could ever use'.. remember when Mr. Gates told us you would never need more than 640K of RAM?)(of course he denies it now..) > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Owen DeLong > Sent: Friday, June 15, 2007 2:41 PM > To: jordi.palet at consulintel.es > Cc: ARIN People Posting Mailing List; ipv6 at ietf.org; > address-policy-wg at ripe.net > Subject: Re: [ppml] Revising Centrally Assigned ULA draft > > > On Jun 15, 2007, at 8:14 AM, JORDI PALET MARTINEZ wrote: > > > If you doubt about folks stating anything, then you should read > > *before* > > minutes of meetings. I'm now off-line in a plane, so can't > point you > > to a specific URL, but this has been said at least in one ARIN > > meeting. > > > > It has been clear across all this discussion in several exploders, > > that there are both opinions, people that want ULA-C and > people that > > don't. What you need to be smart here is to realize that those than > > don't want ULA-C have no any objective reason to oppose to > it, because > > implementing ULA-C has no negative impact in others. While > opposing to > > it has negative impact to > > all: Folks will use global space (PA or PI) for doing the > function of > > ULA-C an this is a waste, yes a small waste but a waste. > > > Jordi, > You have this backwards. Using PI for the purposes of > ULA-C is no waste at all. Sectioning off a huge chunk of > address space for ULA-C is the waste. > If it's all PI, then, it can seamlessly move between being > unrouted or routed as the address-holder sees fit and as > needs change. If it is set aside as ULA, then, the address > space is forever wasted and cannot (theoretically) be used as > routable space, no matter how little of it is needed for ULA-C. > > Those of us who oppose ULA-C have what we believe to be > an objective position that it provides no additional benefit > over PI space while simultaneously creating some unnecessary > classification of addresses that makes their status in the > routing table ill-defined at best. In our opinion, this > carries the potential for significant consequences globally. > > Just because we do not agree with you does not mean > that our concerns are not legitimate. > > Do I think UUNET and others should be able to get > secondary microallocations to solve the problem they > presented? Absolutely. Do I think that we need to set aside > a /8, /12, /16, or whatever separate from the rest of PI > space to do it? No. > We should just issue them a /48 or whatever it is they need > from the general pool of available PI space and be done with > it. No waste at all. No negative consequences to anyone. > No ambiguous status as to where you can or can't route the > addresses, etc. > > Owen > > _______________________________________________ > This message sent to you through the ARIN Public Policy > Mailing List (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > ------------------------------ _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml End of PPML Digest, Vol 24, Issue 27 ************************************ From ipng at 69706e6720323030352d30312d31340a.nosense.org Fri Jun 15 18:49:11 2007 From: ipng at 69706e6720323030352d30312d31340a.nosense.org (Mark Smith) Date: Sat, 16 Jun 2007 08:19:11 +0930 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106670703C@mail> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <70DE64CEFD6E9A4EB7FAF3A06314106670703C@mail> Message-ID: <20070616081911.0f6dcfef.ipng@69706e6720323030352d30312d31340a.nosense.org> On Fri, 15 Jun 2007 15:13:40 -0500 "Kevin Kargel" wrote: > I agree wholeheartedly. There is nothing you can do with ULA-C that you > can't do with PI and a minor firewall rule or two. Leaving the space as > PI gives it either-or capability, putting it as ULA reduces PI. (And > don't talk about 'more PI than we could ever use'.. remember when Mr. > Gates told us you would never need more than 640K of RAM?)(of course he > denies it now..) > > I understand that that was an IBM design decision - they chose to allow 384KB out of the 1MB of address space of the 8086/8088 for option ROMs for add-in cards. That decision was made during the design of the original IBM PC (i.e. the one before the XT), which originally came with 16KB of RAM (and a audio cassette interface for storage, no serial ports or printer ports, and a monochrome 4KB text adaptor). Allowing 384KB for option ROMs allowed for plenty of IO card expansion, because the platform was initially very barebones, and 640KB was extremely large amount of RAM at the time. The OS at the time didn't provide device drivers, unlike today's OSes - the option ROMs was were that functionality resided. When you look at that problem, at the time it was addressed, the 640KB/384KB boundary seems, at least to me, to be quite reasonable. The IBM PC architecture was never expected to (a) set an industry standard and (b) ever last as long as it has. Gates was unlikely to have ever been consulted on it, or conversely, was only ever agreeing with a decision that had already been made. Don't use this (mis)quote as a lack of design foresight, use it as an example of wildly unexpected success. IPv6 doesn't have the addressing quantity constraints that IPv4 has, so allow for wildly different and expanded uses of it and it's large address space. As a general example of how IPv6's "large" addressing could be used, look at Ethernet. Nobody needs 2^47 unicast addresses on a LAN segment. We "waste" millions of addresses everytime we enable a new LAN segment. The Ethernet address space we "waste" when a point to point ethernet link is brought up is the most "obscene" amount of address space "waste" I've ever seen in my life - because a point-to-point link doesn't even need addressing - the frame is either for this end or the other end. So what has all that "wasted" Ethernet address space got us ? _Convenience_ It is convenient that we can plug an Ethernet card in and not have to worry about configuring addresses or addressing collisions. Non-technical people can buy a network card at the local electrical store, plug it into their computer, and the ethernet functionality work (installing device drivers is obviously not a problem that ethernet attemps to solve). It's the original "plug-and-play". With Ethernet, we get a lot of convenience at the cheap price of 32 or so bits of "wasted" address space (on the rough assumption that nobody would ever build an ethernet segment with more than 65K nodes), or 64 bits in each packet. Here's what the people who chose 48 bit addressing for Ethernet said about the decision : "48-bit host numbers lead to large Ethernet and internet packets. We believe that this will not pose a problem as both local and public data networks continue to offer higher bandwidths at reasonable costs, and the memory and logic costs associated with storing and processing these numbers continue to become lower with the advances in LSI technology." ("48-bit Absolute Internet and Ethernet Host Numbers", Yogan K. Dalal and Robert S. Printis - definately worth a read) When did they say it ? 1981! 26 years ago! The problem with applying an IPv4 mentality to an IPv6 addressing problem is that IPv4 hasn't been an abundant resource for 15 or so years. We've had to give up operational convenience with it because we needed to ensure functionality as the Internet grew. When it came to the crunch, convenience had to be sacrificed. IPv6 address space is abundant, so we can now go back to placing value on operational convenience. All we need to do is ensure there isn't any reckless use of IPv6's address space. So, getting back to the ULA topic : If (non-globally routed) PI is the answer to the ULA-C question, is there going to be enough (non-globally routed) PI so that I can get a (non-globally routed) PI allocation for my home, at a small charge for the guaranteed uniqueness e.g. US$10 per annum ? How about my Personal Area Network that interconnects my mobile phone, portable music player and pedometer in my shoes. Will there be enough (non-globally routed) PI that everybody on the planet who might end up having that sort of PAN can get a (non-globally routed) PI address allocation, should they want one ? How about if they want separate allocations for both their PAN and their home network. If the answer is no, then (non-globally routed) PI it isn't solving the ULA/ULA-C problem. > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > Behalf Of Owen DeLong > > Sent: Friday, June 15, 2007 2:41 PM > > To: jordi.palet at consulintel.es > > Cc: ARIN People Posting Mailing List; ipv6 at ietf.org; > > address-policy-wg at ripe.net > > Subject: Re: [ppml] Revising Centrally Assigned ULA draft > > > > > > On Jun 15, 2007, at 8:14 AM, JORDI PALET MARTINEZ wrote: > > > > > If you doubt about folks stating anything, then you should read > > > *before* > > > minutes of meetings. I'm now off-line in a plane, so can't > > point you > > > to a specific URL, but this has been said at least in one ARIN > > > meeting. > > > > > > It has been clear across all this discussion in several exploders, > > > that there are both opinions, people that want ULA-C and > > people that > > > don't. What you need to be smart here is to realize that those than > > > don't want ULA-C have no any objective reason to oppose to > > it, because > > > implementing ULA-C has no negative impact in others. While > > opposing to > > > it has negative impact to > > > all: Folks will use global space (PA or PI) for doing the > > function of > > > ULA-C an this is a waste, yes a small waste but a waste. > > > > > Jordi, > > You have this backwards. Using PI for the purposes of > > ULA-C is no waste at all. Sectioning off a huge chunk of > > address space for ULA-C is the waste. > > If it's all PI, then, it can seamlessly move between being > > unrouted or routed as the address-holder sees fit and as > > needs change. If it is set aside as ULA, then, the address > > space is forever wasted and cannot (theoretically) be used as > > routable space, no matter how little of it is needed for ULA-C. > > > > Those of us who oppose ULA-C have what we believe to be > > an objective position that it provides no additional benefit > > over PI space while simultaneously creating some unnecessary > > classification of addresses that makes their status in the > > routing table ill-defined at best. In our opinion, this > > carries the potential for significant consequences globally. > > > > Just because we do not agree with you does not mean > > that our concerns are not legitimate. > > > > Do I think UUNET and others should be able to get > > secondary microallocations to solve the problem they > > presented? Absolutely. Do I think that we need to set aside > > a /8, /12, /16, or whatever separate from the rest of PI > > space to do it? No. > > We should just issue them a /48 or whatever it is they need > > from the general pool of available PI space and be done with > > it. No waste at all. No negative consequences to anyone. > > No ambiguous status as to where you can or can't route the > > addresses, etc. > > > > Owen > > > > _______________________________________________ > > This message sent to you through the ARIN Public Policy > > Mailing List (PPML at arin.net). > > Manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From randy at psg.com Fri Jun 15 18:58:12 2007 From: randy at psg.com (Randy Bush) Date: Fri, 15 Jun 2007 12:58:12 -1000 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <20070616081911.0f6dcfef.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <70DE64CEFD6E9A4EB7FAF3A06314106670703C@mail> <20070616081911.0f6dcfef.ipng@69706e6720323030352d30312d31340a.nosense.org> Message-ID: <46731984.3090708@psg.com> > If (non-globally routed) PI is the answer to the ULA-C question, is > there going to be enough (non-globally routed) PI so that I can get a > (non-globally routed) PI allocation for my home, at a small charge for > the guaranteed uniqueness e.g. US$10 per annum ? How about my Personal > Area Network that interconnects my mobile phone, portable music player > and pedometer in my shoes. Will there be enough (non-globally routed) > PI that everybody on the planet who might end up having that sort of > PAN can get a (non-globally routed) PI address allocation, should they > want one ? How about if they want separate allocations for both their > PAN and their home network. these are rir policy and price issues. they are not technical issues. except for routability, which, as smb says, don't think you ain't gonna want to connect it some day; you will. randy From jordi.palet at consulintel.es Sat Jun 16 10:38:08 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 16 Jun 2007 14:38:08 +0000 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A023EFACB@nyrofcs2ke2k01.corp.pvt> Message-ID: Hi Marla, Agree, but actually I was wondering, if the AC/board has the power so just modify the policy in order to use ULA-C space, assuming that when the ULA-C becomes available, it offers the same features required by this policy. It may be much easier and faster instead of going thru the PDP all the way. Or even the staff, because this becomes then only an implementation issue (kind of "we usedd prefix xx until now, but ULA-C is available and we can use that space w/o implications on the existing policy itself, same as if we exhaust the initial prefix for this policy and need to start using a new one"). Anyway is something that could be debated when ULA-C is available :-) Regards, Jordi > De: "Azinger, Marla" > Responder a: > Fecha: Fri, 15 Jun 2007 15:14:31 -0400 > Para: , ARIN People Posting Mailing List > > CC: , > Conversaci?n: [ppml] Revising Centrally Assigned ULA draft > Asunto: RE: [ppml] Revising Centrally Assigned ULA draft > > Jordi- We are saying the same thing. Just how you get there is different. > > It is true, we could either modify or eliminate the current ARIN policy to > work in unison with what might be a finsished RFC on ULA-C. I just believe > that sometimes it is easier to start with a fresh policy. In this case, I > think it would be less confusing to expire the current policy and replace it > with a new one that is more fitting as opposed to trying to modify the current > one. A modification could quickly confuse anyone who has not been following > all of the ULA emails and conversations. > > I suppose we can figure this out when we get to that bridge. > > Cheers! > Marla Azinger > Frontier Communications > ARIN AC > > > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > JORDI PALET MARTINEZ > Sent: Friday, June 15, 2007 9:03 AM > To: ARIN People Posting Mailing List > Cc: ipv6 at ietf.org; address-policy-wg at ripe.net > Subject: Re: [ppml] Revising Centrally Assigned ULA draft > > > Hi Marla, > > In fact, when I started to work on this, it was because I realized about the > possibility to use ULA-C as the space for the microallocations and talking > with different folks they said that it will be possible with ULA-C, but not > ULA. > > I also talked with people from the AC and they considered the point (I was > told) to use ULA-C for the microallocations when ULA-C is available. > > So my view is that probably the microallocations policy should not expire, > but instead, be modified to make usage of the ULA-C space instead of global > unicast. > > Regards, > Jordi > > > > >> De: "Azinger, Marla" >> Responder a: >> Fecha: Thu, 14 Jun 2007 13:31:29 -0400 >> Para: Jeroen Massar , >> CC: ARIN People Posting Mailing List , , >> >> Conversaci?n: [ppml] Revising Centrally Assigned ULA draft >> Asunto: RE: [ppml] Revising Centrally Assigned ULA draft >> >> I think a point here that needs to be looked at is this: >> >> If ULA-C is addressed by IETF and then in turn we end up with RIR's >> responsible for handing out ULA-C blocks, then those existing policy's such >> as >> ARIN's NRPM 6.10.2 Microallocations for Internal Infastructure should be >> expired and no longer an active policy. >> >> And there are different flavors to the debate of why ULA-C would be better >> than such policy as ARIN's NRPM 6.10.2 Microallocations for Internal >> Infastructure. Ie Standardization, conservation ect... >> >> Cheers! >> Marla Azinger >> Frontier Communications >> >> >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >> Jeroen Massar >> Sent: Thursday, June 14, 2007 3:00 AM >> To: jordi.palet at consulintel.es >> Cc: ARIN People Posting Mailing List; ipv6 at ietf.org; >> address-policy-wg at ripe.net >> Subject: Re: [ppml] Revising Centrally Assigned ULA draft >> >> >> [cc'ing RIPE address policy + ARIN PPML where the discussion on this >> happened, I have not seen any 'operators' who have said the below, if >> there are they are there and can thus raise their voices because they >> will see this message; removed the silly spam scoring subject...] >> >> JORDI PALET MARTINEZ wrote: >>> Operators have said that they will not be able to use ULA, but they could >>> use ULA-C, for example for thinks like microallocations for internal >>> infrastructure's. >> >> I really wonder where you got that idea, as I know of no such operator >> who would ever say that. If there are any, let them bring up their >> argumentation, please don't come up with "somebody said that" it does >> not work that way. >> >> Real network operators, especially involved in the RIPE or other RIR's, >> have more than enough address space from their PA allocations that they >> can easily receive and they very well know how to use a /48 from that >> for internal infrastructure as everybody does this. The IPv6 PA policies >> even describe that a /48 can be used per POP of the owner of the PA block. >> >> Also in the ARIN region any organization can get a /48 PI block for >> about $100/year, as such these organizations won't be needing this >> address space either as they can easily take a /64 out of that for those >> needs. Firewalling is the key here. >> >> >>> I think the policy proposal that I sent to several regions includes text and >>> links to other documents that can clarify this perspective. >>> >>> For example in RIPE NCC: >>> http://www.ripe.net/ripe/policies/proposals/2007-05.html >> >> That is your proposal indeed. No "Operator" has stood behind this and >> various people from various organizations have clearly asked you and the >> RIPE NCC to *freeze* this proposal till at least the IETF has worked out. >> >> Anybody needing a "globally unique" block can get either PA or PI space. >> ULA-C as such is useless. >> >> Greets, >> Jeroen >> > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware that > any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From Ed.Lewis at neustar.biz Sat Jun 16 12:58:09 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Sat, 16 Jun 2007 12:58:09 -0400 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> Message-ID: At 12:40 -0700 6/15/07, Owen DeLong wrote: >Using PI for the purposes of ULA-C is no waste at all. Sectioning off a >huge chunk of address space for ULA-C is the waste. >...ULA-C ... provides no additional benefit over PI space while >simultaneously creating some unnecessary classification of addresses >that makes their status in the routing table ill-defined at best. After reading this, I swing back to the position of thinking $undef_ref_ULA-C is a bad idea *IF* PI space is freely available to all comers, not just multi-homers. But if routing fears cause PI space to be restricted, then I am still sympathetic to network-layer-scoped addresses. Still I am losing faith in scoped addressing above layer 2 (i.e., except link-local) will ever be beneficial. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From owen at delong.com Sat Jun 16 13:18:28 2007 From: owen at delong.com (Owen DeLong) Date: Sat, 16 Jun 2007 10:18:28 -0700 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> Message-ID: <88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com> On Jun 16, 2007, at 9:58 AM, Edward Lewis wrote: > At 12:40 -0700 6/15/07, Owen DeLong wrote: > >> Using PI for the purposes of ULA-C is no waste at all. Sectioning >> off a >> huge chunk of address space for ULA-C is the waste. > >> ...ULA-C ... provides no additional benefit over PI space while >> simultaneously creating some unnecessary classification of addresses >> that makes their status in the routing table ill-defined at best. > > After reading this, I swing back to the position of thinking > $undef_ref_ULA-C is a bad idea *IF* PI space is freely available to > all comers, not just multi-homers. > > But if routing fears cause PI space to be restricted, then I am still > sympathetic to network-layer-scoped addresses. Still I am losing > faith in scoped addressing above layer 2 (i.e., except link-local) > will ever be beneficial. I completely agree. Therefore, the right thing to do is let ARIN manage address space and let people who run routers manage the routing table. This artificial management of routing table space through RIR policy simply doesn't work in a v6 world. Because of the need for balancing address conservation with routing table growth, we had to live with these difficulties in IPv4. However, in IPv6, ARIN is no longer an appropriate point of control for routing table issues. This must be turned back to the ISPs. Owen From drc at virtualized.org Sat Jun 16 14:32:24 2007 From: drc at virtualized.org (David Conrad) Date: Sat, 16 Jun 2007 11:32:24 -0700 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com> Message-ID: Owen, On Jun 16, 2007, at 10:18 AM, Owen DeLong wrote: > Therefore, the right thing to do is let ARIN manage > address space and let people who run routers manage the routing > table. This artificial management of routing table space through RIR > policy simply doesn't work in a v6 world. Just to be clear I understand, to summarize what I think you (and others) are saying: a) RIR policies shouldn't be used to attempt to constrain (IPv6) routing system growth b) IPv6 PI space should be available to everyone who requests it Is this accurate? (I'm not disagreeing, I just want to understand the underlying rules) Thanks, -drc From jeroen at unfix.org Sat Jun 16 14:42:20 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 16 Jun 2007 19:42:20 +0100 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com> Message-ID: <46742F0C.4080702@spaghetti.zurich.ibm.com> David Conrad wrote: > Owen, > > On Jun 16, 2007, at 10:18 AM, Owen DeLong wrote: >> Therefore, the right thing to do is let ARIN manage >> address space and let people who run routers manage the routing >> table. This artificial management of routing table space through RIR >> policy simply doesn't work in a v6 world. > > Just to be clear I understand, to summarize what I think you (and > others) are saying: > > a) RIR policies shouldn't be used to attempt to constrain (IPv6) > routing system growth This will be solved in time, when needed, with a Loc/Id split. When and if ever the routing tables really become to large to manage this will be forced upon people and nobody will suddenly have a problem with it. Work on this is underway and will be more than done before there are more than 100k IPv6 routes or a million or two of them, especially as we are still on <800 of them. > b) IPv6 PI space should be available to everyone who requests it Indeed, though with one teeny weeny important addition: Address space is available on request based on justification of need. Thus when you say "Hi I want a /48 for my office", the the RIR says "cool sign up, pay the fees, presto". But when a end-user goes to a RIR and says "I need a /32 for my office", then they should definitely request justification for this need of address space. Some of the "IPv6 PI" proposals to date have tried to avoid that justification clause, which is a waste of address space. The 'fees' portion is just as an incentive to make sure that somebody doesn't request a million of them and never uses them, that is the justification: use your address space. Things people have to pay for will be used (unless somebody is throwing with cash of course ;) As current yearly 'fee' for ARIN is only a $100 US for a /48 I really can't imagine any serious organization who really needs address space not being able to cough that up, especially when compared to costs for hardware and paying the actual upstreams or having to renumber when changing ISP's or having NAT-hell with RFC1918. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From mack at exchange.alphared.com Sat Jun 16 21:59:47 2007 From: mack at exchange.alphared.com (mack) Date: Sat, 16 Jun 2007 20:59:47 -0500 Subject: [ppml] Revising Centrally Assigned ULA draft Message-ID: <859D2283FD04CA44986CC058E06598F84173D1C99D@exchange4.exchange.alphared.local> Original message: > >Date: Fri, 15 Jun 2007 15:13:40 -0500 >From: "Kevin Kargel" >Subject: Re: [ppml] Revising Centrally Assigned ULA draft >To: "Owen DeLong" , >Cc: ARIN People Posting Mailing List , ipv6 at ietf.org, > address-policy-wg at ripe.net >Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106670703C at mail> >Content-Type: text/plain; charset="us-ascii" > >I agree wholeheartedly. There is nothing you can do with ULA-C that you can't do with PI and a minor firewall rule or >two. Leaving the space as PI gives it either-or capability, putting it as ULA reduces PI. (And don't talk about >'more PI than we could ever use'.. remember when Mr. >Gates told us you would never need more than 640K of RAM?)(of course he denies it now..) Comments on ULA-C: The space for ULA-C is already listed as 'reserved'. This is the first half of the /12 listed for ULA. The second half is ULA-L. Therefore it isn't a 'waste'. It is usefully to some people. There is no 'grey area' about the routing. The whole point of ULA-C is 'not globally routable'. These are not intended to be publicly routed any more than ULA-L is. Both will probably be 'leaked' just as private address space is now. People wanting IPv6 NAT should be given the tools to do so. I don't want it but there are people that do. If the community wants a rule to provide /48s and corresponding ASNs to businesses, there needs to be discussion on that but no one has put forth a policy proposal. I am fairly certain it would be immediately shot down. No ones current equipment could handle the number of routes that would result. Whether we like it or not routing capability is going to drive the vote on that one. Comments on IPv6 exhaustion: I am sure there are uses that could take up large chunks of IPv6 address space. I don't think people realize how truly huge IPv6 is. For comparison: Moon: Mass 7.35 x 10^22kg. IPv6 address space: 3.4 x 10^38 Assuming every person on the planet receives a publicly routable /48. We will only have used 1/46000th of the public space. How many sensors in the carpet? How many nanobots floating in our bloodstream will it take? Should medical nanobots use public address space? Now if we give every insect their own /48 .. THEN we have a problem. Insects must not be given anything larger than a /64. That would consume half of the address space. We definitely need EUI64 for insects. No one is going to sit there and assign them IP addresses. And if they crawl over to the neighbors their IP addresses can automatically be reassigned. Hopefully, we have moved to IPv7 by that point. Useful new feature of IPv7 - Structured interstellar routing (how many bits for intergalactic, inter-solar, interplanetary, etc?). Quantum Addressing (IP addresses for every electron, proton, neutron, etc and each state of such particles) Alien Transport Protocol conversion (alien races have their own IP versions that must communicate). If the above numbers are off, someone please correct them. LR Mack McBride Network Administrator Alpha Red, Inc. From jeroen at unfix.org Sat Jun 16 22:32:58 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Sun, 17 Jun 2007 03:32:58 +0100 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <859D2283FD04CA44986CC058E06598F84173D1C99D@exchange4.exchange.alphared.local> References: <859D2283FD04CA44986CC058E06598F84173D1C99D@exchange4.exchange.alphared.local> Message-ID: <46749D5A.5030000@spaghetti.zurich.ibm.com> mack wrote: [..] > Comments on ULA-C: > > The space for ULA-C is already listed as 'reserved'. > This is the first half of the /12 listed for ULA. You actually mean /7, fc00::/7, where fc00::/8 is reserved for ULA-C and fd00::/8 is reserved for ULA (RFC4193) Also see http://www.iana.org/assignments/ipv6-address-space It would really help if you would actually read the documents and get your facts straight. > The second half is ULA-L. ULA-L? There really is no such thing. It is either ULA (RFC4193) or ULA-C, which is not defined yet, except for maybe section 3.2 of RFC4193 which calls it "ULA with a Global ID", which is rather odd "Unique *LOCAL* Address with a *GLOBAL* ID" ;) > Therefore it isn't a 'waste'. True, the address space is already reserved, but that can be undone quite easily and it can be reassigned for different purposes. There are, afaik, no implementations that block usage of this address space or treat it specially in any way yet. > It is usefully to some people. What exactly is that "use" you are talking about? Can you explain the advantage of PI. Also do mind the big disadvantage that it has: People will want to connect to the internet one day. > There is no 'grey area' about the routing. > The whole point of ULA-C is 'not globally routable'. > These are not intended to be publicly routed any more than ULA-L is. > Both will probably be 'leaked' just as private address space is now. Thus your assumption is exactly what a lot of other people say: use PI. > People wanting IPv6 NAT should be given the tools to do so. > I don't want it but there are people that do. Which people want this? Let these people come forward and demonstrate their needs for it. Saying that there "might be a need" is not good enough. Show us use cases. Show us why it does not fit under PI. > If the community wants a rule to provide /48s and corresponding ASNs to > businesses, there needs to be discussion on that but no one has put forth a > policy proposal. I am fairly certain it would be immediately shot down. > No ones current equipment could handle the number of routes that would result. There are 800 routes in the IPv6 DFZ today. Hardware vendors claim to be handle 2.000.000 of those with ease with current hardware. How fast do you think that IPv6 will grow? [..] > Assuming every person on the planet receives a publicly routable /48. > We will only have used 1/46000th of the public space. You are so forgetting HD ratios. Look them up, it is a good read. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From kloch at kl.net Sat Jun 16 23:15:47 2007 From: kloch at kl.net (Kevin Loch) Date: Sat, 16 Jun 2007 23:15:47 -0400 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <859D2283FD04CA44986CC058E06598F84173D1C99D@exchange4.exchange.alphared.local> References: <859D2283FD04CA44986CC058E06598F84173D1C99D@exchange4.exchange.alphared.local> Message-ID: <4674A763.9020803@kl.net> mack wrote: > People wanting IPv6 NAT should be given the tools to do so. > I don't want it but there are people that do. Ok but what part of IPv6 NAT requires ULA-C instead of ULA-L or globally unique addresses? NAT is just translation and addresses are "private" or not depending on who you announce them to and how you filter at your borders. RFC's don't make addresses private, engineers do. The illusion of security benefits from RFC1918 space is largely a side effect of the extreme non-uniqueness of it. The goals of "private" addressing and guaranteed uniqueness might not be compatible. - Kevin From drc at virtualized.org Sat Jun 16 23:26:46 2007 From: drc at virtualized.org (David Conrad) Date: Sat, 16 Jun 2007 20:26:46 -0700 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <46742F0C.4080702@spaghetti.zurich.ibm.com> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com> <46742F0C.4080702@spaghetti.zurich.ibm.com> Message-ID: <37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org> Jeroen, On Jun 16, 2007, at 11:42 AM, Jeroen Massar wrote: >> a) RIR policies shouldn't be used to attempt to constrain (IPv6) >> routing system growth > This will be solved in time, when needed, with a Loc/Id split. What do you see as the incentive that will be driving the shift to the "loc/id split"? >> b) IPv6 PI space should be available to everyone who requests it > Indeed, though with one teeny weeny important addition: Address > space is > available on request based on justification of need. [justification for more than a /48 clipped] I'm not sure I follow this. Theoretically, there are 281,474,976,710,656 /48s in the IPv6 address space. However, taking only the address space that has been designated as "global unicast", there are 35,184,372,088,832 /48s available for assignment (actually less, since we've already been allocating out of that pool, but we're still talking about noise). This is still an insanely big number -- assuming equal distribution across the ~7 billion people on the planet (by the time IPv6 see significant deployment), each person on the planet could get 5,026 /48s. Now, if, as you say, the "current yearly 'fee' for ARIN is only a $100 US for a /48" (is this actually the case?), it would seem "justification of need" would be superfluous -- there is plenty of financial disincentive preventing getting more address space than any organization would actually need, particularly given the minimum allocation unit can address 1,208,925,819,614,629,174,706,176 interfaces (or, if you prefer, 65536 LANs, each LAN capable of having up to 18,446,744,073,709,551,616 interfaces). Given no need for RIR policies to try to constrain routing system growth and (at least one) /48 IPv6 PI available on request, wouldn't a more rational, vastly simpler approach be for the RIRs to simply set up a web page that charges $100/year per /48? Further, the rationale for a /32 for ISPs no longer appears to make sense. If everybody can get a /48, why would ISPs need 16 (or more) additional bits of address space than everybody else? Since their customers would be bringing their own address space with them, why wouldn't they be like every body else and get a /48 and, if necessary, get more /48s (at $100/year) for their internal infrastructure as they need it? I suspect I am missing something. Curiously, -drc From drc at virtualized.org Sat Jun 16 23:30:03 2007 From: drc at virtualized.org (David Conrad) Date: Sat, 16 Jun 2007 20:30:03 -0700 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <46749D5A.5030000@spaghetti.zurich.ibm.com> References: <859D2283FD04CA44986CC058E06598F84173D1C99D@exchange4.exchange.alphared.local> <46749D5A.5030000@spaghetti.zurich.ibm.com> Message-ID: Jeroen, On Jun 16, 2007, at 7:32 PM, Jeroen Massar wrote: > There are 800 routes in the IPv6 DFZ today. Hardware vendors claim > to be > handle 2.000.000 of those with ease with current hardware. Oddly, some folks at ISPs have indicated "with ease" is not accurate. I will honestly admit to not knowing who to believe. >> Assuming every person on the planet receives a publicly routable /48. >> We will only have used 1/46000th of the public space. > You are so forgetting HD ratios. Look them up, it is a good read. I believe HD ratio applies to hierarchical addressing. Allocations of at least one /48 on request regardless of network topology is not hierarchical. Rgds, -drc From bicknell at ufp.org Sun Jun 17 21:01:14 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 17 Jun 2007 21:01:14 -0400 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com> <46742F0C.4080702@spaghetti.zurich.ibm.com> <37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org> Message-ID: <20070618010114.GB45940@ussenterprise.ufp.org> In a message written on Sat, Jun 16, 2007 at 08:26:46PM -0700, David Conrad wrote: > Further, the rationale for a /32 for ISPs no longer appears to make > sense. If everybody can get a /48, why would ISPs need 16 (or more) > additional bits of address space than everybody else? Since their > customers would be bringing their own address space with them, why > wouldn't they be like every body else and get a /48 and, if > necessary, get more /48s (at $100/year) for their internal > infrastructure as they need it? So, let me repeat what I got out of your message to make sure I'm understanding your question: RIR's would give out one /48 to any organization that requests one and charge them a fee of $100. There would be no other requirements to get space. Here's the simple problem, you give up all aggregation day one. This is rather significant. I'm going to (probably mis)quote Jason Shiller here that (roughly) "Verizon Business has as many internal routes as there are routes in the default free zone". Now, not all will be customers, some will be internal links, loopbacks and the like. However, were all those customers to have non-aggregateable allocations from ARIN then Verizon Business would have no way to summarize any of those routes, and would dump (in order of magnitude) roughly as many prefixes into the DFZ as are there now. Lather, rince, repeat for other ISP's. I believe were a plan as you describe implemented the number of routes in the default free zone would jump by at least one order of magnitude overnight, perhaps closer to two orders of magnitude. Can routers be built to handle that? I'm sure they can, but the market really hates a step function, and virtually none of the existing hardware could support it. So even if we could get there and thought it was a good thing, it would be a very painful transition. I do believe though, that you are correct that if we did give everyone a /48, there would be no reason for most ISP's to get more than a /48 themselves, save perhaps those with large amounts of single IP dynamic customers (e.g. Cable Companies) that might actually exceed the 65536 subnets available... -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stephen at sprunk.org Sun Jun 17 21:22:04 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 17 Jun 2007 20:22:04 -0500 Subject: [ppml] Revising Centrally Assigned ULA draft References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com><46742F0C.4080702@spaghetti.zurich.ibm.com> <37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org> Message-ID: <014101c7b147$e937efa0$6701a8c0@atlanta.polycom.com> Thus spake "David Conrad" > On Jun 16, 2007, at 11:42 AM, Jeroen Massar wrote: >>> a) RIR policies shouldn't be used to attempt to constrain (IPv6) >>> routing system growth >> This will be solved in time, when needed, with a Loc/Id split. > > What do you see as the incentive that will be driving the shift to > the "loc/id split"? Failure of routers to handle the number of identifiers being handed out. > Now, if, as you say, the "current yearly 'fee' for ARIN is only a > $100 US for a /48" (is this actually the case?), ARIN's current fee for folks who have only direct assignments (of whatever protocol(s) or size) is $100/yr. > it would seem "justification of need" would be superfluous -- there > is plenty of financial disincentive preventing getting more address > space than any organization would actually need, particularly > given the minimum allocation unit can address > 1,208,925,819,614,629,174,706,176 interfaces (or, if you prefer, > 65536 LANs, each LAN capable of having up to > 18,446,744,073,709,551,616 interfaces). > > Given no need for RIR policies to try to constrain routing system > growth and (at least one) /48 IPv6 PI available on request, wouldn't > a more rational, vastly simpler approach be for the RIRs to simply > set up a web page that charges $100/year per /48? Your "given" is currently false. ARIN policies are influenced by those that live in the DFZ (i.e. big ISPs), and since those folks are scared of routing growth, ARIN's policies are crafted such that only those folks who "deserve" a routing slot get one. AFAICT, that is not going to change until we get the ID/LOC split everyone keeps talking about -- then DFZ players should only care about LOC growth, not ID growth. The current consensus criteria for "deserving" a routing slot can be found in the NRPM. > Further, the rationale for a /32 for ISPs no longer appears to make > sense. If everybody can get a /48, why would ISPs need 16 (or more) > additional bits of address space than everybody else? Since their > customers would be bringing their own address space with them, why > wouldn't they be like every body else and get a /48 and, if > necessary, get more /48s (at $100/year) for their internal > infrastructure as they need it? > > I suspect I am missing something. ISPs need /32s so they can assign /48s or /56s to folks who don't "deserve" a routing slot of their own, which current accounts for the vast majority of users/orgs on the Internet. Please note that I'm not necessarily defending the above thinking, just explaining it. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From stephen at sprunk.org Sun Jun 17 21:37:12 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 17 Jun 2007 20:37:12 -0500 Subject: [ppml] Revising Centrally Assigned ULA draft References: Message-ID: <016601c7b14c$3601d8b0$6701a8c0@atlanta.polycom.com> Thus spake "JORDI PALET MARTINEZ" > Agree, but actually I was wondering, if the AC/board has the power > so just modify the policy in order to use ULA-C space, assuming > that when the ULA-C becomes available, it offers the same > features required by this policy. It may be much easier and faster > instead of going thru the PDP all the way. This sounds suspiciously like "I don't seem to have the support of the community, so I wonder if the Board/AC can ignore the process and do what I want anyways." I don't know whether or not they can do that; it doesn't seem possible, but there's probably a loophole or two. However, given the vocal opposition to the proposal (and the very existence of ULA-C), I doubt you'd ever convince them to if they could. It's one thing to sneak through something that nobody cares about either way, but it's entirely different to deliberately exclude the community on something so divisive. > Anyway is something that could be debated when ULA-C is > available :-) If you seriously propose doing the above, I suspect you'll manage to alienate even the folks who agree with ULA-C. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From randy at psg.com Sun Jun 17 22:12:13 2007 From: randy at psg.com (Randy Bush) Date: Sun, 17 Jun 2007 16:12:13 -1000 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <014101c7b147$e937efa0$6701a8c0@atlanta.polycom.com> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com><46742F0C.4080702@spaghetti.zurich.ibm.com> <37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org> <014101c7b147$e937efa0$6701a8c0@atlanta.polycom.com> Message-ID: <4675E9FD.9030200@psg.com> >> What do you see as the incentive that will be driving the shift to >> the "loc/id split"? > Failure of routers to handle the number of identifiers being handed out. david ward (cisco) and john scudder (juniper) stood at the podium in the ripe routing wg and said o their routers can handle two million routes today, and o their routers will be able to handle ten million routes in two to three years. and if you believe that is true in real life actual operational use, then i have this bridge ... and do you believe in an internet where all dfz routers have to be monsters such as the crash-1? randy From michael.dillon at bt.com Mon Jun 18 03:23:21 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 18 Jun 2007 08:23:21 +0100 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <20070618010114.GB45940@ussenterprise.ufp.org> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com><88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com><46742F0C.4080702@spaghetti.zurich.ibm.com><37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org> <20070618010114.GB45940@ussenterprise.ufp.org> Message-ID: > I believe were a plan as you describe implemented the number > of routes in the default free zone would jump by at least one > order of magnitude overnight, perhaps closer to two orders of > magnitude. By continuing this discussion in PPML instead of on the IETF WG list, you are helping to ensure that ULA-C becomes a reality. It would be better if you take this discussion to the IETF, so that PPML can focus on other work. --Michael Dillon From JOHN at egh.com Mon Jun 18 04:06:47 2007 From: JOHN at egh.com (John Santos) Date: Mon, 18 Jun 2007 04:06:47 -0400 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <20070618010114.GB45940@ussenterprise.ufp.org> Message-ID: <1070618035523.24656G-301000@Ives.egh.com> It's easy to shoot down a proposal if you just assume it says something it doesn't. 1) Nothing prevents ISPs from continuing to get large chunks of PA space and assigning suitable small chunks of that to their customers. IE aggregation just as it exists to day. This would probably serve the needs of 99% of their customers. 2) There is no guarantee of routability given. If you want your /48 routed, you will have to find someone willing to route it. Presumably, they would charge you for it. Presumably, they would charge you much less to route a /48 (or whatever) they assigned to you out of their PA space. ARIN is in the number administration business. It is *not* in the routing business. It doesn't route anything for anybody (except maybe itself.) Maybe the problem here is people are expecting ARIN policy to enforce their business policy so they don't have to give the customer the bad news that they are going to charge them an arm and a leg to route their small subnet. Instead, they just try to keep ARIN's policy such that their customers can't get small subnets in the first place. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 -------------- next part -------------- In a message written on Sat, Jun 16, 2007 at 08:26:46PM -0700, David Conrad wrote: > Further, the rationale for a /32 for ISPs no longer appears to make > sense. If everybody can get a /48, why would ISPs need 16 (or more) > additional bits of address space than everybody else? Since their > customers would be bringing their own address space with them, why > wouldn't they be like every body else and get a /48 and, if > necessary, get more /48s (at $100/year) for their internal > infrastructure as they need it? So, let me repeat what I got out of your message to make sure I'm understanding your question: RIR's would give out one /48 to any organization that requests one and charge them a fee of $100. There would be no other requirements to get space. Here's the simple problem, you give up all aggregation day one. This is rather significant. I'm going to (probably mis)quote Jason Shiller here that (roughly) "Verizon Business has as many internal routes as there are routes in the default free zone". Now, not all will be customers, some will be internal links, loopbacks and the like. However, were all those customers to have non-aggregateable allocations from ARIN then Verizon Business would have no way to summarize any of those routes, and would dump (in order of magnitude) roughly as many prefixes into the DFZ as are there now. Lather, rince, repeat for other ISP's. I believe were a plan as you describe implemented the number of routes in the default free zone would jump by at least one order of magnitude overnight, perhaps closer to two orders of magnitude. Can routers be built to handle that? I'm sure they can, but the market really hates a step function, and virtually none of the existing hardware could support it. So even if we could get there and thought it was a good thing, it would be a very painful transition. I do believe though, that you are correct that if we did give everyone a /48, there would be no reason for most ISP's to get more than a /48 themselves, save perhaps those with large amounts of single IP dynamic customers (e.g. Cable Companies) that might actually exceed the 65536 subnets available... -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From bicknell at ufp.org Mon Jun 18 09:30:11 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 18 Jun 2007 09:30:11 -0400 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <1070618035523.24656G-301000@Ives.egh.com> References: <20070618010114.GB45940@ussenterprise.ufp.org> <1070618035523.24656G-301000@Ives.egh.com> <20070618010114.GB45940@ussenterprise.ufp.org> Message-ID: <20070618133011.GA89006@ussenterprise.ufp.org> In a message written on Mon, Jun 18, 2007 at 08:23:21AM +0100, michael.dillon at bt.com wrote: > By continuing this discussion in PPML instead of on the IETF WG list, > you are helping to ensure that ULA-C becomes a reality. It would be > better if you take this discussion to the IETF, so that PPML can focus > on other work. If you remember back a few years when ARIN had to provide input to the IETF I was a rather strong objector to making it a "policy" to provide input. I believed then and now that ARIN needs a method to "speak". The issue at hand brings this up tenfold. While I think it is valuable for members of the ARIN community to participate in the IETF process there's no way for the IETF to know that the members who do participate are representatives of the community. Directly, how does the IETF know that the people who showed up aren't the kooks? I think it is valuable to put the question "The ARIN community supports the IETF's work on ULA-C" (or similar) to the membership, determine consensus, and then have a way for ARIN to issue a statement to the IETF that the ARIN community, as a whole is for or against the concept. In a message written on Mon, Jun 18, 2007 at 04:06:47AM -0400, John Santos wrote: > It's easy to shoot down a proposal if you just assume it says something > it doesn't. I wasn't addressing the proposal at all, I was addressing David Conrad's interpretation of it, and most importantly his question of what would happen if his view were to come true. > ARIN is in the number administration business. It is *not* in the > routing business. It doesn't route anything for anybody (except > maybe itself.) However, ARIN does have to keep the membership happy. Your statement would sound silly when put to any physical industry: BMW is in the car building business. It is *not* in the driving business. There are alternatives to ARIN, although I don't think any are particularly pretty. Remember a few years ago when a number of people were unhappy with the state of the DNS root, so they ran their own roots with additional zones? In theory that could happen here. If ISP's in the DFZ are unhappy enough with ARIN's policies they could set up a new registry, all agree to use it, and poof, ARIN is irrelevant. While ARIN may not be in the routing business, virtually all of the consumers of its output are, and so they care a lot that what ARIN provides is useful for that purpose. If ARIN were to allocate in a way that was bad for the routing system the ISP's would revolt, in the most extreme case by ignoring ARIN completely. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From Paul_Vixie at isc.org Mon Jun 18 09:45:15 2007 From: Paul_Vixie at isc.org (Paul_Vixie at isc.org) Date: Mon, 18 Jun 2007 13:45:15 +0000 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: Your message of "Mon, 18 Jun 2007 04:06:47 -0400." <1070618035523.24656G-301000@Ives.egh.com> References: <1070618035523.24656G-301000@Ives.egh.com> Message-ID: <27422.1182174315@sa.vix.com> this is a nice summary of an attractive viewpoint: > 2) There is no guarantee of routability given. If you want your > /48 routed, you will have to find someone willing to route it. > Presumably, they would charge you for it. Presumably, they would > charge you much less to route a /48 (or whatever) they assigned > to you out of their PA space. these costs would inevitably be transitive. all router operators would have to charge more for longer prefixes, whether as part of settlement fees to their peers or as part of transit fees to their customers. the ratio of "how much this route helps me" to "how much this route hurts me" is assumed to be worse for longer prefixes (which take the same amount of router resources but offer a lower number of possible destinations.) the quality of the destinations can't be considered in the global route-charge economy -- a /32 full of spammers has to be presumed to be more valuable than a /48 with a single root name server in it. this is attractive in spite of its shortcomings simply because it puts the cost of TE routes back on the businesses who use them, and assures that if massive TE routing became the norm, there would be enough capital in the economy to support the 10-megaroute equipment that virtually all of us would need. it allows someone who values provider independence (either for high availability or anti-lockin) to offer value in exchange, which is what a functioning economy depends on. this libertarian ideal of "use your dollar votes!" is attractive almost everywhere it's first proposed. but attractive or not, is it realistic? can somebody show some numbers whereby we can know what a small/medium business's "route costs" would be for a /48, and how these costs would role up, and how they'd affect typical peer-level settlement agreements at both tier 1 and tier 2, and how they'd affect typical transit agreements at tier 1 and tier 2? i'm especially interested in how the economy would support "cost aggregation" whereby it's not cheaper to take your /48 to a tier 1 than to a tier 2, owing to quantity discounts in those agreements which allow a tier 2 to "roll in" the costs. (otherwise route charges just support more lockin than we have now.) > Maybe the problem here is people are expecting ARIN policy to enforce > their business policy so they don't have to give the customer the > bad news that they are going to charge them an arm and a leg to > route their small subnet. Instead, they just try to keep ARIN's > policy such that their customers can't get small subnets in the > first place. i think the problem is different. here are four alternative problem statements that could each yield the sentiment you're noting here: (1) ARIN's policies have historically attempted to balance cost vs value of various prefix lengths, since although ARIN doesn't operate routers for third parties, ARIN's members do. (2) a lot of us remember the 64MB RP limits of the early 90's and aren't inclined to skate deliberately near/toward that edge. (3) a 10-megaroute router may become practical, but a 10-megaroute DFZ doesn't feel like it would ever reach convergence, even if we could afford the bandwidth to inflict that much BGP traffic. (4) nobody really knows how a route-charge economy would look in practice, and so there's some fear that it could negatively affect consumers and middlemen. (sort of like electricity deregulation in california during the Enron era.) so: attractive yes, but practical maybe not, plz send out some numbers. From JOHN at egh.com Mon Jun 18 10:00:08 2007 From: JOHN at egh.com (John Santos) Date: Mon, 18 Jun 2007 10:00:08 -0400 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <20070618133011.GA89006@ussenterprise.ufp.org> Message-ID: <1070618094916.24656A-301000@Ives.egh.com> Leo - actually, my comments were directed more to what David said then your replies, but I'm having strange difficulties with quoting... I think if ARIN is going have a policy that is dictated by the needs of routing, it should explicitly say so in the policy. Especially if the policy has bad side effects on others. Then, if and when the routing issues become resolved, the policy could be revoked because it would no longer be needed, and if people wanted to retain the policy, they would need to come up with some new justification. Currently, it looks like you need to able to justify a large number of hosts to get PI, which is currently the only way to get ISP-independent addresses. Either allowing PI for small networks to all comers (with no explicit guarantee of routability) or ULA-C (with a "guarantee" of non-routability) seems to be the only way to overcome this. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 -------------- next part -------------- In a message written on Mon, Jun 18, 2007 at 08:23:21AM +0100, michael.dillon at bt.com wrote: > By continuing this discussion in PPML instead of on the IETF WG list, > you are helping to ensure that ULA-C becomes a reality. It would be > better if you take this discussion to the IETF, so that PPML can focus > on other work. If you remember back a few years when ARIN had to provide input to the IETF I was a rather strong objector to making it a "policy" to provide input. I believed then and now that ARIN needs a method to "speak". The issue at hand brings this up tenfold. While I think it is valuable for members of the ARIN community to participate in the IETF process there's no way for the IETF to know that the members who do participate are representatives of the community. Directly, how does the IETF know that the people who showed up aren't the kooks? I think it is valuable to put the question "The ARIN community supports the IETF's work on ULA-C" (or similar) to the membership, determine consensus, and then have a way for ARIN to issue a statement to the IETF that the ARIN community, as a whole is for or against the concept. In a message written on Mon, Jun 18, 2007 at 04:06:47AM -0400, John Santos wrote: > It's easy to shoot down a proposal if you just assume it says something > it doesn't. I wasn't addressing the proposal at all, I was addressing David Conrad's interpretation of it, and most importantly his question of what would happen if his view were to come true. > ARIN is in the number administration business. It is *not* in the > routing business. It doesn't route anything for anybody (except > maybe itself.) However, ARIN does have to keep the membership happy. Your statement would sound silly when put to any physical industry: BMW is in the car building business. It is *not* in the driving business. There are alternatives to ARIN, although I don't think any are particularly pretty. Remember a few years ago when a number of people were unhappy with the state of the DNS root, so they ran their own roots with additional zones? In theory that could happen here. If ISP's in the DFZ are unhappy enough with ARIN's policies they could set up a new registry, all agree to use it, and poof, ARIN is irrelevant. While ARIN may not be in the routing business, virtually all of the consumers of its output are, and so they care a lot that what ARIN provides is useful for that purpose. If ARIN were to allocate in a way that was bad for the routing system the ISP's would revolt, in the most extreme case by ignoring ARIN completely. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From stephen at sprunk.org Mon Jun 18 09:53:12 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 18 Jun 2007 08:53:12 -0500 Subject: [ppml] Revising Centrally Assigned ULA draft References: <1070618035523.24656G-301000@Ives.egh.com> Message-ID: <02f901c7b1b1$a3525c40$6701a8c0@atlanta.polycom.com> Thus spake "John Santos" > 2) There is no guarantee of routability given. If you want your > /48 routed, you will have to find someone willing to route it. > Presumably, they would charge you for it. Presumably, they would > charge you much less to route a /48 (or whatever) they assigned > to you out of their PA space. I can't tell if you're talking about PI or ULA(-C) here -- which I suppose is the whole issue at hand. ARIN doesn't/can't guarantee routability for any blocks, nor can it (or the IETF) guarantee non-routability. That's up to individual operators. > ARIN is in the number administration business. It is *not* in the > routing business. It doesn't route anything for anybody (except > maybe itself.) Right, which is why we need to drop this silly ULA-C idea and just let everyone who needs PI get it. Some will route their prefix publicly while others will not; that's not ARIN's concern. > Maybe the problem here is people are expecting ARIN policy > to enforce their business policy so they don't have to give the > customer the bad news that they are going to charge them an > arm and a leg to route their small subnet. Instead, they just try > to keep ARIN's policy such that their customers can't get small > subnets in the first place. You are aware that "small" means less than 256 hosts for a multihomed site or 1024 hosts for a single-homed site, right? Everyone larger than that can already get a PI /48 under current policy. If you have fewer hosts than that and have a compelling need for PI space, please describe your situation (including number of hosts, number of upstreams, and when you plan to deploy v6) so that we can discuss modifying policy to accomodate it. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From michael.dillon at bt.com Mon Jun 18 10:11:54 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 18 Jun 2007 15:11:54 +0100 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <20070618133011.GA89006@ussenterprise.ufp.org> References: <20070618010114.GB45940@ussenterprise.ufp.org><1070618035523.24656G-301000@Ives.egh.com><20070618010114.GB45940@ussenterprise.ufp.org> <20070618133011.GA89006@ussenterprise.ufp.org> Message-ID: > While I think it is valuable for members of the ARIN > community to participate in the IETF process there's no way > for the IETF to know that the members who do participate are > representatives of the community. Directly, how does the > IETF know that the people who showed up aren't the kooks? If you have a problem with IETF process, this too is a matter for discussion on IETF mailing lists, not on PPML. > I think it is valuable to put the question "The ARIN > community supports the IETF's work on ULA-C" (or similar) to > the membership, determine consensus, and then have a way for > ARIN to issue a statement to the IETF that the ARIN > community, as a whole is for or against the concept. Until people like you take the discussion of ULA-C to the IETF IPV6 WG, there is no IETF work on ULA-C. > There are alternatives to ARIN, although I don't think any > are particularly pretty. Remember a few years ago when a > number of people were unhappy with the state of the DNS root, > so they ran their own roots with additional zones? In theory > that could happen here. If ISP's in the DFZ are unhappy > enough with ARIN's policies they could set up a new registry, > all agree to use it, and poof, ARIN is irrelevant. Excellent idea. The DNS people tried it now people have a better understanding of why the current unique root system is beneficial. If someone wants to do this with addressing (and Cymru, completewhois, and the various RRs already do this) then they should go ahead. It does not hurt for people to try the experiment. The very nature of the intelligent-edge IP internetwork is to enable such experimentation without harming those who do not want to participate in the experiments. --Michael Dillon From drc at virtualized.org Mon Jun 18 14:09:17 2007 From: drc at virtualized.org (David Conrad) Date: Mon, 18 Jun 2007 11:09:17 -0700 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <20070618010114.GB45940@ussenterprise.ufp.org> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com> <46742F0C.4080702@spaghetti.zurich.ibm.com> <37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org> <20070618010114.GB45940@ussenterprise.ufp.org> Message-ID: Leo, On Jun 17, 2007, at 6:01 PM, Leo Bicknell wrote: > RIR's would give out one /48 to any organization that requests one > and charge them a fee of $100. There would be no other requirements > to get space. That would appear to be what people are arguing for, yes. > Here's the simple problem, you give up all aggregation day one. Not really. The fact that PI /48s are available does not automatically mean everyone must obtain them. > However, were all those customers to have non-aggregateable > allocations from ARIN then Verizon Business would have no way to > summarize any of those routes, and would dump (in order of magnitude) > roughly as many prefixes into the DFZ as are there now. Two points: a) huh? Last I checked, there were 800 IPv6 prefixes being routed b) I have been told that folks from both Juniper and Cisco have stated publicly that they can easily meet short term routing requirements and have no concerns about meeting longer term requirements. > I believe were a plan as you describe implemented the number of > routes in the default free zone would jump by at least one order > of magnitude overnight, perhaps closer to two orders of magnitude. In the immortal words of Dr. Peter Venkman, "Human sacrifice, dogs and cats living together - mass hysteria." Even if the RIRs started paying people to take IPv6 prefixes, you wouldn't see a jump "jump by at least one order of magnitude overnight, perhaps closer to two orders of magnitude." The fact that someone has address space does not mean ISPs must route it. And, as I understand the discussions, that's sort of the point. Since around 1994 or so, the RIRs have been tagged with being the routing police. Now, we're told by router vendors that today, routers can handle an order of magnitude more routes than what they're currently handling. As such, the policies created to enable RIRs-as-routing-police come into question. > I do believe though, that you are correct that if we did give > everyone a /48, there would be no reason for most ISP's to get more > than a /48 themselves, save perhaps those with large amounts of > single IP dynamic customers (e.g. Cable Companies) that might > actually exceed the 65536 subnets available... More to the point, the allocations of /19s and /20s (and shorter) could be seen as egregious and unconscionable wastes of vast tracts of address space. Rgds, -drc From drc at virtualized.org Mon Jun 18 14:32:47 2007 From: drc at virtualized.org (David Conrad) Date: Mon, 18 Jun 2007 11:32:47 -0700 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <014101c7b147$e937efa0$6701a8c0@atlanta.polycom.com> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com><46742F0C.4080702@spaghetti.zurich.ibm.com> <37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org> <014101c7b147$e937efa0$6701a8c0@atlanta.polycom.com> Message-ID: Stephen, On Jun 17, 2007, at 6:22 PM, Stephen Sprunk wrote: >> What do you see as the incentive that will be driving the shift to >> the "loc/id split"? > > Failure of routers to handle the number of identifiers being handed > out. Wouldn't the more natural reaction to this be route filtering? I'll admit that I have some skepticism that the Internet community is going to spend the money necessary redeploy IPv6, particularly as the need for that redeployment would be the success of IPv6. I used to be a strong proponent of a loc/id split, but have pretty much given up since it seems people far smarter than me argue there isn't really a problem. > The current consensus criteria for "deserving" a routing slot can > be found in the NRPM. Is it just me or is there appears to be a disconnect here: - On the one hand, we're told that routers can today handle an order of magnitude more "routing slots" and over the long term, can handle oodles more and that the RIRs don't do "routability". - On the other hand, ARIN policies are oriented towards conserving "routing slots" and people are proposing fairly obscene hacks to obtain address space that won't (at least in theory) consume "routing slots". It's probably just me... Rgds, -drc From bicknell at ufp.org Mon Jun 18 14:34:54 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 18 Jun 2007 14:34:54 -0400 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com> <46742F0C.4080702@spaghetti.zurich.ibm.com> <37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org> <20070618010114.GB45940@ussenterprise.ufp.org> Message-ID: <20070618183454.GA10207@ussenterprise.ufp.org> In a message written on Mon, Jun 18, 2007 at 11:09:17AM -0700, David Conrad wrote: > >Here's the simple problem, you give up all aggregation day one. > > Not really. The fact that PI /48s are available does not > automatically mean everyone must obtain them. Everyone, no. However, would you not agree a lot of people who don't try for PI today because it's hard/complicated/expensive would be more inclined to get it if it were as easy as filling out a web page and sending in a check for $100? > a) huh? Last I checked, there were 800 IPv6 prefixes being routed Entirely the wrong metric. We're in a start-up mode. Since we're likely to see a relatively full transition to IPv6 in under 5 years, looking at the start up figure now is worthless. There will be somewhere between the number of AS's allocated and the number of current IPv4 routes in the DFZ in the future IPv6 DFZ, and that's the interesting number. > b) I have been told that folks from both Juniper and Cisco have > stated publicly that they can easily meet short term routing > requirements and have no concerns about meeting longer term > requirements. And yet, the major operators keep standing up and telling the RIR community it's BS. I think there are three major factors why the two do not intersect: 1) Operators want to hold on to legacy hardware longer than they probably should, so in many cases are constrained by 2-3 generations back in routing gear. 2) Vendors believe that since their current product, introduced last month can do the job that operators should just swap out their entire network in the next 6 months and be happy. 3) Customers are pushing for technologies like Layer 3 VPN's which are eating up routing slots in the new wizbang hardware far faster than DFZ growth. > Even if the RIRs started paying people to take IPv6 prefixes, you > wouldn't see a jump "jump by at least one order of magnitude > overnight, perhaps closer to two orders of magnitude." The fact that > someone has address space does not mean ISPs must route it. I disagree. If we put a policy like this in place before the rush to get IPv6 space really hits in a big way I think you would find the IPv6 DFZ would surpass the IPv4 DFZ in a matter of 2-3 years after the rush starts. I'm not sure that's a problem if it happened slowly, but if over 2 years ISP's go from having to route 200,000 IPv4 prefixes to 200,000 IPv4 + 400,000 IPv6, that alone will be quite painful. Step functions are hard on budgets and people. I think in the 5-10 year timeframe you would easily be one order of magnitude larger than our current predictions for DFZ growth. > More to the point, the allocations of /19s and /20s (and shorter) > could be seen as egregious and unconscionable wastes of vast tracts > of address space. On this point we are in violent agreement. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From drc at virtualized.org Mon Jun 18 14:42:40 2007 From: drc at virtualized.org (David Conrad) Date: Mon, 18 Jun 2007 11:42:40 -0700 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <20070618133011.GA89006@ussenterprise.ufp.org> References: <20070618010114.GB45940@ussenterprise.ufp.org> <1070618035523.24656G-301000@Ives.egh.com> <20070618010114.GB45940@ussenterprise.ufp.org> <20070618133011.GA89006@ussenterprise.ufp.org> Message-ID: <1AF7CF52-9B95-4CAD-B392-C4237CDE1AFF@virtualized.org> Leo, Just to clarify: On Jun 18, 2007, at 6:30 AM, Leo Bicknell wrote: > In a message written on Mon, Jun 18, 2007 at 04:06:47AM -0400, John > Santos wrote: >> It's easy to shoot down a proposal if you just assume it says >> something >> it doesn't. > > I wasn't addressing the proposal at all, I was addressing David > Conrad's > interpretation of it, and most importantly his question of what would > happen if his view were to come true. I am extrapolating based on behaviors I see being discussed or implemented in all the RIRs regarding the liberalization of PI allocation policies. Your extrapolation of my extrapolation made assumptions that John is pointing out aren't necessarily valid. The availability of PI to anyone who asks does not imply that the address space is routed nor does it imply PA space magically goes away or is deaggregated. Rgds, -drc From bicknell at ufp.org Mon Jun 18 14:56:22 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 18 Jun 2007 14:56:22 -0400 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <1AF7CF52-9B95-4CAD-B392-C4237CDE1AFF@virtualized.org> References: <20070618010114.GB45940@ussenterprise.ufp.org> <1070618035523.24656G-301000@Ives.egh.com> <20070618010114.GB45940@ussenterprise.ufp.org> <20070618133011.GA89006@ussenterprise.ufp.org> <1AF7CF52-9B95-4CAD-B392-C4237CDE1AFF@virtualized.org> Message-ID: <20070618185622.GC10207@ussenterprise.ufp.org> In a message written on Mon, Jun 18, 2007 at 11:42:40AM -0700, David Conrad wrote: > I am extrapolating based on behaviors I see being discussed or > implemented in all the RIRs regarding the liberalization of PI > allocation policies. Your extrapolation of my extrapolation made > assumptions that John is pointing out aren't necessarily valid. The > availability of PI to anyone who asks does not imply that the address > space is routed nor does it imply PA space magically goes away or is > deaggregated. I agree with your statements, however I think we have to make some educated guess at what is probable. Regarding the second, we have a long history in IPv4 that given the choice between PA and PI, people would rather have PI. The only barriers that have kept people from getting PI are RIR policies and cost. So I would imagine if the bar to get PI were set "as low as possible" that most (80%?) of the people with PA today would move to PI. Now, once we're in that situation, let's look at routing. First, keep in mind we're in a situation now where the lions share of the allocated prefixes are /48's. The tool used today to limit the number of routing entries taken up is prefix length. Well, if I route so much as a single one of the PI /48's, and I want to use that tool I have to allow them all. Can I generate a prefix-list that contains everything in the DFZ? Probably not. Do I trust my Internet Neighbors to only allow in prefixes that "justify" a routing slot? Heck no, someone is going to charge money to get the slot and let anyone get it, and then everyone else will have to do the same or be at a competitive disadvantage. Does crypto solve the problem? No, same issue, the provider will sign it for a fee. We need a method of deciding "worth" that can be implemented independently by each ISP and does not require them to trust their neighbor. Today that is prefix length. I've seen nothing in any policy proposal or in any of the active IETF groups that seems to have even a remotely workable solution. Thus, IPv6 is falling back to the same thing as IPv4, prefix length, and more "important" people get larger blocks. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From owen at delong.com Mon Jun 18 15:09:21 2007 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Jun 2007 12:09:21 -0700 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <20070618183454.GA10207@ussenterprise.ufp.org> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com> <46742F0C.4080702@spaghetti.zurich.ibm.com> <37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org> <20070618010114.GB45940@ussenterprise.ufp.org> <20070618183454.GA10207@ussenterprise.ufp.org> Message-ID: <1A289E88-8FE2-483F-8501-DE0A81B8A42B@delong.com> On Jun 18, 2007, at 11:34 AM, Leo Bicknell wrote: > In a message written on Mon, Jun 18, 2007 at 11:09:17AM -0700, > David Conrad wrote: >>> Here's the simple problem, you give up all aggregation day one. >> >> Not really. The fact that PI /48s are available does not >> automatically mean everyone must obtain them. > > Everyone, no. However, would you not agree a lot of people who > don't try for PI today because it's hard/complicated/expensive would > be more inclined to get it if it were as easy as filling out a web > page and sending in a check for $100? > Yes... However, this is not necessarily a bad thing... >> a) huh? Last I checked, there were 800 IPv6 prefixes being routed > > Entirely the wrong metric. We're in a start-up mode. Since we're > likely to see a relatively full transition to IPv6 in under 5 years, > looking at the start up figure now is worthless. There will be > somewhere between the number of AS's allocated and the number of > current IPv4 routes in the DFZ in the future IPv6 DFZ, and that's > the interesting number. > Yep... Probably around 60,000. This is 1/4 of the current routing table size. >> b) I have been told that folks from both Juniper and Cisco have >> stated publicly that they can easily meet short term routing >> requirements and have no concerns about meeting longer term >> requirements. > > And yet, the major operators keep standing up and telling the RIR > community it's BS. I think there are three major factors why the > two do > not intersect: > > 1) Operators want to hold on to legacy hardware longer than they > probably should, so in many cases are constrained by 2-3 > generations back in routing gear. > 2) Vendors believe that since their current product, introduced last > month can do the job that operators should just swap out their > entire > network in the next 6 months and be happy. > 3) Customers are pushing for technologies like Layer 3 VPN's which are > eating up routing slots in the new wizbang hardware far faster > than DFZ > growth. > All of those things are probably true. Still, the fact remains that just because the RIR issues space does not require ISPs to route it. The ISPs have gotten a free ride on the RIRs performing the routing police role in IPv4. They've perhaps even become used to that fact. However, the fact is that role was given to the RIRs because of the need to balance that issue with the issue of address space conservation. In IPv6 that need no longer exists. As such, the role of Routing Table Police needs to transition back to the ISPs who are best suited to address the issue. >> Even if the RIRs started paying people to take IPv6 prefixes, you >> wouldn't see a jump "jump by at least one order of magnitude >> overnight, perhaps closer to two orders of magnitude." The fact that >> someone has address space does not mean ISPs must route it. > > I disagree. If we put a policy like this in place before the rush > to get IPv6 space really hits in a big way I think you would find > the IPv6 DFZ would surpass the IPv4 DFZ in a matter of 2-3 years > after the rush starts. I'm not sure that's a problem if it happened > slowly, but if over 2 years ISP's go from having to route 200,000 > IPv4 prefixes to 200,000 IPv4 + 400,000 IPv6, that alone will be > quite painful. Step functions are hard on budgets and people. > I think in the 5-10 year timeframe you would easily be one order of > magnitude larger than our current predictions for DFZ growth. > Nothing in the RIRs issuing 400,000 IPv6 prefixes requires ISPs to route them. As such, I think it is up to the ISPs to decide which of those prefixes they are willing to route and which ones they are not. >> More to the point, the allocations of /19s and /20s (and shorter) >> could be seen as egregious and unconscionable wastes of vast tracts >> of address space. > > On this point we are in violent agreement. > Yep. In fact, I'm half tempted to propose policy that makes the justification documents for any IPv6 allocation or assignment shorter than /24 subject to public review. Owen From dlw+arin at tellme.com Mon Jun 18 15:26:37 2007 From: dlw+arin at tellme.com (David Williamson) Date: Mon, 18 Jun 2007 12:26:37 -0700 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org> <014101c7b147$e937efa0$6701a8c0@atlanta.polycom.com> Message-ID: <20070618192637.GF24827@shell01.corp.tellme.com> On Mon, Jun 18, 2007 at 11:32:47AM -0700, David Conrad wrote: > Is it just me or is there appears to be a disconnect here: > > - On the one hand, we're told that routers can today handle an order > of magnitude more "routing slots" and over the long term, can handle > oodles more and that the RIRs don't do "routability". There's two pieces here that are interesting. There's sufficient raw copmuting power and space to hold a complete 10M-route table, which I do believe routers are likely to have "soon". The other piece is more dynamic - you need to have some way to send/receive full table updates in a timely fashion, and process them to convergence before the next set of large disturbances to your local table. Given the way BGP works, I think the latter is unlikely to be an operable possibility at 10M-routes. For my org, all failures would be handled in ~100ms. BGP presently takes minutes to converge. Changing that to 10s of minutes (while additional updates continue to show up) is just not a workable solution. The number of routing slots really is important, regrettably. That whole loc/id split thing will need to get solved, somehow. I know I'm really not looking forward to the BGP replacement period. I suspect it will be at least as painful as the IPv4 -> IPv6 transition. I simply don't think the current combination of BGP and IP is going to scale in the way that some folks claim. I could be wrong, but.... -David From jeroen at unfix.org Mon Jun 18 15:34:45 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 18 Jun 2007 20:34:45 +0100 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <20070618183454.GA10207@ussenterprise.ufp.org> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com> <46742F0C.4080702@spaghetti.zurich.ibm.com> <37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org> <20070618010114.GB45940@ussenterprise.ufp.org> <20070618183454.GA10207@ussenterprise.ufp.org> Message-ID: <4676DE55.6070100@spaghetti.zurich.ibm.com> Leo Bicknell wrote: > In a message written on Mon, Jun 18, 2007 at 11:09:17AM -0700, David Conrad wrote: >>> Here's the simple problem, you give up all aggregation day one. >> Not really. The fact that PI /48s are available does not >> automatically mean everyone must obtain them. > > Everyone, no. However, would you not agree a lot of people who > don't try for PI today because it's hard/complicated/expensive would > be more inclined to get it if it were as easy as filling out a web > page and sending in a check for $100? pssst... the $100/year is already the case for a /40-/48 IPv6 PI in your beloved ARIN region. And how many of those are actually to be found in the "IPv6 DFZ"? Actually from ARIN only 32% of the allocated blocks are actually being routed at the moment. Of those PI ones given out only 10 out of 60 of them are being seen somewhere in the "IPv6 DFZ" (according to GRH). So even though it is quite cheap, not many are actually using it (yet). In RIPE land at least 52% of the prefixes, and those are quite a bit more than in ARIN land are already at least being announced. >> a) huh? Last I checked, there were 800 IPv6 prefixes being routed > > Entirely the wrong metric. We're in a start-up mode. Since we're > likely to see a relatively full transition to IPv6 in under 5 years, > looking at the start up figure now is worthless. There will be > somewhere between the number of AS's allocated and the number of > current IPv4 routes in the DFZ in the future IPv6 DFZ, and that's > the interesting number. Even if every single 16bit ASN would have a single entry, that would be a mind whopping 65k entries (and I am not even considering private ASNs For that matter. If there would be ULA-C one day, then we also need ASN-C, because they solve exactly the same kind of problem. Another reason why ULA-C can simply be solved by what we now call PI. Note also that "PI" doesn't actually have to show up in the routing tables, it can actually be used only internally, or do you have a route to 9.0.0.0/8 or the various other military networks ? :) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From bmanning at karoshi.com Mon Jun 18 16:00:04 2007 From: bmanning at karoshi.com (bmanning at karoshi.com) Date: Mon, 18 Jun 2007 20:00:04 +0000 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <4676DE55.6070100@spaghetti.zurich.ibm.com> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com> <46742F0C.4080702@spaghetti.zurich.ibm.com> <37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org> <20070618010114.GB45940@ussenterprise.ufp.org> <20070618183454.GA10207@ussenterprise.ufp.org> <4676DE55.6070100@spaghetti.zurich.ibm.com> Message-ID: <20070618200004.GA20414@vacation.karoshi.com.> On Mon, Jun 18, 2007 at 08:34:45PM +0100, Jeroen Massar wrote: > > Actually from ARIN only 32% of the allocated blocks are actually being > routed at the moment. Of those PI ones given out only 10 out of 60 of > them are being seen somewhere in the "IPv6 DFZ" (according to GRH). > So even though it is quite cheap, not many are actually using it (yet). as seen from that particular keyhole > Note also that "PI" doesn't actually have to show up in the routing > tables, it can actually be used only internally, or do you have a route > to 9.0.0.0/8 or the various other military networks ? :) why yes i do. lime.ep.net>sh ip route 9.0.0.0 Routing entry for 9.0.0.0/8, 2 known subnets Variably subnetted with 2 masks B 9.4.0.0/16 [20/9] via 160.81.102.133, 1w0d B 9.144.115.0/24 [20/760] via 160.81.102.133, 1d23h lime.ep.net> don't you? --bill > > Greets, > Jeroen > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From michael.dillon at bt.com Mon Jun 18 16:10:09 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 18 Jun 2007 21:10:09 +0100 Subject: [ppml] How many IPv6 bits do you get without public scrutiny? In-Reply-To: <1A289E88-8FE2-483F-8501-DE0A81B8A42B@delong.com> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com><88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com><46742F0C.4080702@spaghetti.zurich.ibm.com><37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org><20070618010114.GB45940@ussenterprise.ufp.org><20070618183454.GA10207@ussenterprise.ufp.org> <1A289E88-8FE2-483F-8501-DE0A81B8A42B@delong.com> Message-ID: > In fact, I'm half tempted to propose policy that makes the > justification documents for any IPv6 allocation or assignment > shorter than /24 subject to public review. Now there is something worth discussing on PPML unlike that ULA nonsense which belongs in the IETF. The fact is that we give ISPs a /32 because that seems big enough for most service providers. For most of them it is more than enough. But we currently have policy that gives really big ISPs more bits in one block because this is less wasteful. But in IPv6 "wasteful" is defined differently from IPv4. Perhaps the very concept of giving more than a /32 is wasteful. Or perhaps there is another boundary such as the /24 which Owen mentions, beyond which we are being wasteful. If you stick with the 4-bit nibble boundaries that came out of the /56 discussions, then perhaps the RIRs should only have discretion to increase that /32 to a /28 but no larger unless there is a public discussion and some kind of policy approval. After all, the IPv6 space is a public resource and for one organization to grab a huge chunk of it, relative to everybody else's chunk, seems to me to be a public policy issue. I believe there is some precedence in this with the 126/8 allocation that APNIC gave to Softbank. I know there certainly is some precedent in the way the /24 was given to the cable industry. So there are two questions. Is there a boundary beyond which an RIR cannot allocate a single large block to one organization? And should we allow the /32 boundary to be shoved up a bit at a time, or only a whole nibble? --Michael Dillon From jeroen at unfix.org Mon Jun 18 17:13:20 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 18 Jun 2007 22:13:20 +0100 Subject: [ppml] ULA-C draft version 2 available (I-D ACTION:draft-ietf-ipv6-ula-central-02.txt) Message-ID: <4676F570.7050107@spaghetti.zurich.ibm.com> Reply-To set to ipv6 at ietf.org, use it as there is where the discussion should be. This mail is mostly so that folks can't claim that they "didn't know". IETF is, just like the RIR communities open and individual participation. Thus if you have something on your mind, write down the arguments and send them in. Note on the IETF lists: subscription is helpful, otherwise you might not get the responses (unless you read the public archive). List Admins will, as soon as possible approve mails that get into the queue though, but with todays amount of spam coming in that might not be immediate. The document is at: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-02.txt Subscription information + archive etc for ipv6 at ietf.org can be found at: https://www1.ietf.org/mailman/listinfo/ipv6 Greets, Jeroen -------- Original Message -------- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Centrally Assigned Unique Local IPv6 Unicast Addresses Author(s) : R. Hinden, B. Haberman Filename : draft-ietf-ipv6-ula-central-02.txt Pages : 11 Date : 2007-6-18 This document defines Centrally allocated IPv6 Unique Local addresses. These addresses are globally unique and are intended for local communications, usually inside of a site. They are not expected to be routable on the global Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipv6-ula-central-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-ula-central-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From sleibrand at internap.com Mon Jun 18 17:23:45 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 18 Jun 2007 14:23:45 -0700 Subject: [ppml] How many IPv6 bits do you get without public scrutiny? In-Reply-To: References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com><88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com><46742F0C.4080702@spaghetti.zurich.ibm.com><37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org><20070618010114.GB45940@ussenterprise.ufp.org><20070618183454.GA10207@ussenterprise.ufp.org> <1A289E88-8FE2-483F-8501-DE0A81B8A42B@delong.com> Message-ID: <4676F7E1.1050603@internap.com> Perhaps it would be useful and inform the discussion if ARIN staff could comment on the number of large allocations (>/32, >/28, >/24, etc.), and provide (probably anonymized) justification details for some of them? -Scott michael.dillon at bt.com wrote: >> In fact, I'm half tempted to propose policy that makes the >> justification documents for any IPv6 allocation or assignment >> shorter than /24 subject to public review. >> > > The fact is that we give ISPs a /32 because that seems big enough for > most service providers. For most of them it is more than enough. But we > currently have policy that gives really big ISPs more bits in one block > because this is less wasteful. But in IPv6 "wasteful" is defined > differently from IPv4. Perhaps the very concept of giving more than a > /32 is wasteful. Or perhaps there is another boundary such as the /24 > which Owen mentions, beyond which we are being wasteful. If you stick > with the 4-bit nibble boundaries that came out of the /56 discussions, > then perhaps the RIRs should only have discretion to increase that /32 > to a /28 but no larger unless there is a public discussion and some kind > of policy approval. After all, the IPv6 space is a public resource and > for one organization to grab a huge chunk of it, relative to everybody > else's chunk, seems to me to be a public policy issue. > > So there are two questions. Is there a boundary beyond which an RIR > cannot allocate a single large block to one organization? And should we > allow the /32 boundary to be shoved up a bit at a time, or only a whole > nibble? > From drc at virtualized.org Tue Jun 19 12:04:34 2007 From: drc at virtualized.org (David Conrad) Date: Tue, 19 Jun 2007 09:04:34 -0700 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <20070618183454.GA10207@ussenterprise.ufp.org> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com> <46742F0C.4080702@spaghetti.zurich.ibm.com> <37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org> <20070618010114.GB45940@ussenterprise.ufp.org> <20070618183454.GA10207@ussenterprise.ufp.org> Message-ID: Leo, On Jun 18, 2007, at 11:34 AM, Leo Bicknell wrote: >> a) huh? Last I checked, there were 800 IPv6 prefixes being routed > > Entirely the wrong metric. ... > There will be > somewhere between the number of AS's allocated and the number of > current IPv4 routes in the DFZ in the future IPv6 DFZ, and that's > the interesting number. So, between 60K and 250K additional routes, which (according to the router vendors) is still 1/4th what today's routers can handle. That would appear to double the size of the routing table over a 2 to 3 year period, not be a "jump by at least one order of magnitude overnight, perhaps closer to two orders of magnitude." > And yet, the major operators keep standing up and telling the RIR > community it's BS. Clearly there is a disconnect. From my perspective, operators who are concerned have been completely drowned out by those who (for whatever reason) are not concerned. If major operators actually believe what the router vendors is saying is BS, then they should probably stop preaching to the choir in the RIR community and make their feelings known more forcefully in places like NANOG (I wasn't there, did anyone shoot down Scudder's presentation?) and the IETF. > If we put a policy like this in place before the rush > to get IPv6 space really hits in a big way I think you would find > the IPv6 DFZ would surpass the IPv4 DFZ in a matter of 2-3 years > after the rush starts. Aside from the fact that the IPv6 DFZ surpassing the IPv4 DFZ is a mere doubling and there is (supposedly) sufficient headroom in routers today, much less 2 to 3 years from now, what would drive the rush for IPv6 space? I am skeptical that simply it's availability (particularly if the $100/year fee was recurrent). IPv6 would need to provide something that IPv4+NAT doesn't. Rgds, -drc From BillD at cait.wustl.edu Tue Jun 19 12:33:36 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 19 Jun 2007 11:33:36 -0500 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: Message-ID: This debate about the headroom in routers.... "major ISPs say this"...... "router vendors say this".... Haven't heard anything real capacity from someone claiming the former title recently..... But, Randy Bush stated in an earlier email..."funny. just last week, the big two router vendors stood in front of us at ripe and said two million prefixes today and ten million in a few years." I'm thinking 'holding them' and 'routing them' in a real-world DFZ may be a different issue. But, seems clear from most of what I hear that David's doubling or tripling of routes is doable an a more likely number than 2 or 3 orders of magnitude. Someone really know? Someone speak. bd > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of David Conrad > Sent: Tuesday, June 19, 2007 11:05 AM > To: Leo Bicknell > Cc: Public Policy Mailing List > Subject: Re: [ppml] Revising Centrally Assigned ULA draft > > > Leo, > > On Jun 18, 2007, at 11:34 AM, Leo Bicknell wrote: > >> a) huh? Last I checked, there were 800 IPv6 prefixes being routed > > > > Entirely the wrong metric. > ... > > There will be > > somewhere between the number of AS's allocated and the number of > > current IPv4 routes in the DFZ in the future IPv6 DFZ, and > that's the > > interesting number. > > So, between 60K and 250K additional routes, which (according to the > router vendors) is still 1/4th what today's routers can > handle. That > would appear to double the size of the routing table over a 2 to 3 > year period, not be a "jump by at least one order of magnitude > overnight, perhaps closer to two orders of magnitude." > > > And yet, the major operators keep standing up and telling the RIR > > community it's BS. > > Clearly there is a disconnect. From my perspective, operators who > are concerned have been completely drowned out by those who (for > whatever reason) are not concerned. If major operators actually > believe what the router vendors is saying is BS, then they should > probably stop preaching to the choir in the RIR community and make > their feelings known more forcefully in places like NANOG (I wasn't > there, did anyone shoot down Scudder's presentation?) and the IETF. > > > If we put a policy like this in place before the rush > > to get IPv6 space really hits in a big way I think you > would find the > > IPv6 DFZ would surpass the IPv4 DFZ in a matter of 2-3 > years after the > > rush starts. > > Aside from the fact that the IPv6 DFZ surpassing the IPv4 DFZ is a > mere doubling and there is (supposedly) sufficient headroom in > routers today, much less 2 to 3 years from now, what would drive the > rush for IPv6 space? I am skeptical that simply it's availability > (particularly if the $100/year fee was recurrent). IPv6 would need > to provide something that IPv4+NAT doesn't. > > Rgds, > -drc > > _______________________________________________ > This message sent to you through the ARIN Public Policy > Mailing List (PPML at arin.net). Manage your mailing list > subscription at: http://lists.arin.net/mailman/listinfo/ppml > From drc at virtualized.org Tue Jun 19 12:37:02 2007 From: drc at virtualized.org (David Conrad) Date: Tue, 19 Jun 2007 09:37:02 -0700 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <20070618192637.GF24827@shell01.corp.tellme.com> References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org> <014101c7b147$e937efa0$6701a8c0@atlanta.polycom.com> <20070618192637.GF24827@shell01.corp.tellme.com> Message-ID: David, On Jun 18, 2007, at 12:26 PM, David Williamson wrote: > The number of routing slots really is important, regrettably. No argument. I gather the question is, who is responsible for them? The RIRs or the ISPs? > That > whole loc/id split thing will need to get solved, somehow. There are many solutions. None of which are likely to actually get deployed in the real world. The problem is that as you get more IPv6 penetration, the harder it is to make changes. You end up needing what Noel Chiappa calls a "jack up" solution: take the entire Internet, jack it up, and insert something underneath it that actually scales. This is hard and typically requires coordination. Filters are much easier and require no coordination. > I know I'm > really not looking forward to the BGP replacement period. I > suspect it > will be at least as painful as the IPv4 -> IPv6 transition. "Life is pain." -- Siddharta Gautama > I simply > don't think the current combination of BGP and IP is going to scale > in the way that some folks claim. I could be wrong, but.... You're not wrong. Flat routing is not scalable, but that's the direction we're heading for very valid business reasons. The question is, how do we deal with it. As far as I can tell, of the people who actually think about this stuff, there are 6 camps: - The Moore's Law Groupies: hardware technology will save us. - The loc/id Dreamers: new Internet architecture will save us. - The King Canute Wannabes: Stop, tide! Stop, you hear me! - The Ostrich Emulators: It works today. Scalability is hard. Let's go shopping! - The CIDR Warriors: Been there, done that. Filters are your friend. - The Cynics: We're doomed anyway. No points for guessing which camp I fall in... :-) Rgds, -drc From jmorrison at bogomips.com Tue Jun 19 12:54:07 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Tue, 19 Jun 2007 09:54:07 -0700 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com> <46742F0C.4080702@spaghetti.zurich.ibm.com> <37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org> <20070618010114.GB45940@ussenterprise.ufp.org> <20070618183454.GA10207@ussenterprise.ufp.org> Message-ID: <46780A2F.9010703@bogomips.com> I second your comments. Reality check: It seems like knee-jerk, fear/uncertainty and doubt are influencing policy decisions. This is bad. A lot of the arguments and reasoning is 10 years old, but the fact is there's been a lot of new silicon since then. But here are some links to some IETF and NANOG presentations, in the interest of informed decision making: (Juniper) Scudder's NANOG presentation: http://www.nanog.org/mtg-0702/presentations/fib-scudder.pdf (this is where the 10 million route claim is made) My summary: - existing technology will scale for the next decade - some other promising areas of research, long term effort - or don't run BGP in the core (there's no need for full BGP on P routers) - deployed, working today (This last one may be useful to point out - a lot of core (P) routers simply forward labels and have no need for full tables.) IETF 68 plenary http://www3.ietf.org/proceedings/07mar/slides/plenaryw-3.pdf - 5 to 10 years of growth, scalability not yet limited by FIB/RIB size - (speed and forwarding path more the issue) - No Need for Panic IETF 68 - routing - some nice tables and statistics http://www3.ietf.org/proceedings/07mar/slides/rtgarea-2.pdf - routing scalability (routes advertised and withdrawn) - seems like clear-cut case for dampening - some nice graphs of prefix growth. (Looks like linear growth to me) David Conrad wrote: > Leo, > > On Jun 18, 2007, at 11:34 AM, Leo Bicknell wrote: > >>> a) huh? Last I checked, there were 800 IPv6 prefixes being routed >>> >> Entirely the wrong metric. >> > ... > >> There will be >> somewhere between the number of AS's allocated and the number of >> current IPv4 routes in the DFZ in the future IPv6 DFZ, and that's >> the interesting number. >> > > So, between 60K and 250K additional routes, which (according to the > router vendors) is still 1/4th what today's routers can handle. That > would appear to double the size of the routing table over a 2 to 3 > year period, not be a "jump by at least one order of magnitude > overnight, perhaps closer to two orders of magnitude." > > >> And yet, the major operators keep standing up and telling the RIR >> community it's BS. >> > > Clearly there is a disconnect. From my perspective, operators who > are concerned have been completely drowned out by those who (for > whatever reason) are not concerned. If major operators actually > believe what the router vendors is saying is BS, then they should > probably stop preaching to the choir in the RIR community and make > their feelings known more forcefully in places like NANOG (I wasn't > there, did anyone shoot down Scudder's presentation?) and the IETF. > > >> If we put a policy like this in place before the rush >> to get IPv6 space really hits in a big way I think you would find >> the IPv6 DFZ would surpass the IPv4 DFZ in a matter of 2-3 years >> after the rush starts. >> > > Aside from the fact that the IPv6 DFZ surpassing the IPv4 DFZ is a > mere doubling and there is (supposedly) sufficient headroom in > routers today, much less 2 to 3 years from now, what would drive the > rush for IPv6 space? I am skeptical that simply it's availability > (particularly if the $100/year fee was recurrent). IPv6 would need > to provide something that IPv4+NAT doesn't. > > Rgds, > -drc > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlw+arin at tellme.com Tue Jun 19 13:11:18 2007 From: dlw+arin at tellme.com (David Williamson) Date: Tue, 19 Jun 2007 10:11:18 -0700 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <46780A2F.9010703@bogomips.com> References: <88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com> <46742F0C.4080702@spaghetti.zurich.ibm.com> <37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org> <20070618010114.GB45940@ussenterprise.ufp.org> <20070618183454.GA10207@ussenterprise.ufp.org> <46780A2F.9010703@bogomips.com> Message-ID: <20070619171118.GJ24827@shell01.corp.tellme.com> On Tue, Jun 19, 2007 at 09:54:07AM -0700, John Paul Morrison wrote: > - 5 to 10 years of growth, scalability not yet limited by FIB/RIB size - > (speed and forwarding path more the issue) > - No Need for Panic So the existing small ISP at the edge of the DFZ behind a couple of DS-3s is going to be fine? Even if this poor sap buys bigger hardware to accomodate a larger FIB/RIB, how's he going to get a full table update (after maintenance or a crash) in a timely fashion? I agree there's no need for panic, but there's need for some serious work. The biggest players are going to be pushing the edge of the RIB/FIB envelope. The next set down in scale (but still near the "core", whatever that is) will be pretty much okay. The little guys near the edge are going to be pretty screwed unless they put out some serious dollars. I don't think the scaling issues are solved for everyone. Not even close. There may be solutions for some, but it's not general. The vendors can stand up and pat themselves on the back, but that doesn't mean this will all really work. Put me down in the class of cynics. It's not entirely obvious to me that the network as we know it today will continue to operate nearly as smoothly as it does now (and I'm surprised that it does). Without a forcing cuntion of some kind, there's no real possibility for change. We can all hope that the transition to IPv6 does that. I suspect it won't. For ppml purposes, I'm very tempted to write a followup to 2007-6 that's even less restrictive. Let's remove all minimum allocation sizes from ARIN policies. You get what you can justify. That would be good stewardship of the number resources, even if it would be horribly bad for the routing system. ARIN doesn't guarantee routability, though, so I don't see a problem there. If I do propose such a thing, I fully expect to get shouted down, even though I think it might be in the best interests of the network as a whole. If it forces a change in the routing system (a loc/id split solution, or a way to monetize routing slots, or...something more creative) - that's good! Stoking the fires, -David From randy at psg.com Tue Jun 19 13:28:54 2007 From: randy at psg.com (Randy Bush) Date: Tue, 19 Jun 2007 07:28:54 -1000 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <20070619171118.GJ24827@shell01.corp.tellme.com> References: <88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com> <46742F0C.4080702@spaghetti.zurich.ibm.com> <37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org> <20070618010114.GB45940@ussenterprise.ufp.org> <20070618183454.GA10207@ussenterprise.ufp.org> <46780A2F.9010703@bogomips.com> <20070619171118.GJ24827@shell01.corp.tellme.com> Message-ID: <46781256.6010303@psg.com> > So the existing small ISP at the edge of the DFZ behind a couple of > DS-3s is going to be fine? Even if this poor sap buys bigger hardware > to accomodate a larger FIB/RIB, how's he going to get a full table > update (after maintenance or a crash) in a timely fashion? > > I agree there's no need for panic, but there's need for some serious > work. The biggest players are going to be pushing the edge of the > RIB/FIB envelope. The next set down in scale (but still near the > "core", whatever that is) will be pretty much okay. The little guys > near the edge are going to be pretty screwed unless they put out some > serious dollars. and there is no rational way out. id/loc is fantasy, old fantasy. once upon a time, one used to be able to run a small (often rural) telco with small equipment. now a small telco has to buy monster switch(es). guess why? and now you may be able to infer why the vendors are not panicked and are telling us everything is alright. randy From jmorrison at bogomips.com Tue Jun 19 13:35:22 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Tue, 19 Jun 2007 10:35:22 -0700 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <20070619171118.GJ24827@shell01.corp.tellme.com> References: <88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com> <46742F0C.4080702@spaghetti.zurich.ibm.com> <37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org> <20070618010114.GB45940@ussenterprise.ufp.org> <20070618183454.GA10207@ussenterprise.ufp.org> <46780A2F.9010703@bogomips.com> <20070619171118.GJ24827@shell01.corp.tellme.com> Message-ID: <467813DA.7090502@bogomips.com> I would question why a small ISP would need to buy bigger hardware. I've setup small ISPs and multi-homed businesses and know that most don't really need full routes. A small ISP can always default. Chances are one of their upstreams is either better or cheaper than the other one, and their backup link is more costly or slower. It's always been costly to run full BGP, and if small business or ISP doesn't want to keep pace, then that's their choice. They won't be out of business if they start filtering or defaulting. Anyway, I think when we're talking about the fundamental scalability and future of the Internet, and basing policy that affects everyone - the argument has always been that the core would collapse if we did or didn't do X. ("the sky is falling" argument). These vendors and presentations seem to show the complete opposite. David Williamson wrote: > On Tue, Jun 19, 2007 at 09:54:07AM -0700, John Paul Morrison wrote: > >> - 5 to 10 years of growth, scalability not yet limited by FIB/RIB size - >> (speed and forwarding path more the issue) >> - No Need for Panic >> > > So the existing small ISP at the edge of the DFZ behind a couple of > DS-3s is going to be fine? Even if this poor sap buys bigger hardware > to accomodate a larger FIB/RIB, how's he going to get a full table > update (after maintenance or a crash) in a timely fashion? > > I agree there's no need for panic, but there's need for some serious > work. The biggest players are going to be pushing the edge of the > RIB/FIB envelope. The next set down in scale (but still near the > "core", whatever that is) will be pretty much okay. The little guys > near the edge are going to be pretty screwed unless they put out some > serious dollars. > > I don't think the scaling issues are solved for everyone. Not even > close. There may be solutions for some, but it's not general. The > vendors can stand up and pat themselves on the back, but that doesn't > mean this will all really work. > > Put me down in the class of cynics. It's not entirely obvious to me > that the network as we know it today will continue to operate nearly as > smoothly as it does now (and I'm surprised that it does). Without a > forcing cuntion of some kind, there's no real possibility for change. > We can all hope that the transition to IPv6 does that. I suspect it > won't. > > For ppml purposes, I'm very tempted to write a followup to 2007-6 > that's even less restrictive. Let's remove all minimum allocation > sizes from ARIN policies. You get what you can justify. That would be > good stewardship of the number resources, even if it would be horribly > bad for the routing system. ARIN doesn't guarantee routability, > though, so I don't see a problem there. > > If I do propose such a thing, I fully expect to get shouted down, even > though I think it might be in the best interests of the network as a > whole. If it forces a change in the routing system (a loc/id split > solution, or a way to monetize routing slots, or...something more > creative) - that's good! > > Stoking the fires, > > -David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kkargel at polartel.com Tue Jun 19 14:41:58 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 19 Jun 2007 13:41:58 -0500 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <46781256.6010303@psg.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066707047@mail> Randy and Dave, Just popping in as one of the "small rural telco / ISP's" .. From my point of view I am not terribly worried about the routing table issue. I have every confidence that the 7xxx class cisco routers I am running now will be able to manage it with hopefully not too terrible upgrades. Even a small telco these days needs to have a fairly hefty edge router to be able to meet their customers data needs, and almost all will have more than one just for redundancy/failover. This sort of solves the initial table issue as hopefully the redundant edge routers will be connected with an IBGP and will be able to locally populate each other's tables when needed. It could well be that I am living in my own nerf fantasy, but whether right or wrong I suspect that I am not the only one holding that opinion. If I were an even smaller ISP as I was a few years ago, with a small router and a single circuit to one upstream, then I would just greatly simplify my own routing table with a default entry or three and depend on my upstream for routing. I know of a couple of small ISP's today who do things that way and are very happy. While I understand the desire by end users (home/SOHO) to have their own PI space, I am not sure how to do it for tiny blocks and maintain efficient aggregation. Lets face it, for tiny networks things will just work better if you get your IP's from the people you get your bandwidth from. Isn't this one of the issued DNS was designed to resolve? Kevin > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Randy Bush > Sent: Tuesday, June 19, 2007 12:29 PM > To: David Williamson > Cc: Public Policy Mailing List > Subject: Re: [ppml] Revising Centrally Assigned ULA draft > > > So the existing small ISP at the edge of the DFZ behind a couple of > > DS-3s is going to be fine? Even if this poor sap buys > bigger hardware > > to accomodate a larger FIB/RIB, how's he going to get a full table > > update (after maintenance or a crash) in a timely fashion? > > > > I agree there's no need for panic, but there's need for > some serious > > work. The biggest players are going to be pushing the edge of the > > RIB/FIB envelope. The next set down in scale (but still near the > > "core", whatever that is) will be pretty much okay. The > little guys > > near the edge are going to be pretty screwed unless they > put out some > > serious dollars. > > and there is no rational way out. id/loc is fantasy, old fantasy. > > once upon a time, one used to be able to run a small (often > rural) telco with small equipment. now a small telco has to > buy monster switch(es). > guess why? > > and now you may be able to infer why the vendors are not > panicked and are telling us everything is alright. > > randy > _______________________________________________ > This message sent to you through the ARIN Public Policy > Mailing List (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From randy at psg.com Tue Jun 19 15:00:01 2007 From: randy at psg.com (Randy Bush) Date: Tue, 19 Jun 2007 09:00:01 -1000 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066707047@mail> References: <70DE64CEFD6E9A4EB7FAF3A063141066707047@mail> Message-ID: <467827B1.9080207@psg.com> > From my point of view I am not terribly worried about the routing > table issue. I have every confidence that the 7xxx class cisco > routers I am running now will be able to manage it with hopefully not > too terrible upgrades. you are either living in a fantasy that a 7xxx cisco will handle O(10^6) routes, we are not talking about the dfz in the direction it is heading, or we think quite differently about where it is heading. randy From kkargel at polartel.com Tue Jun 19 15:14:19 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 19 Jun 2007 14:14:19 -0500 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <467827B1.9080207@psg.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066707049@mail> Yes, I agree that I may be living in a fantasy.. my point was just that I am probably not alone in this fantasy world.. I guess I am hoping that there will always be some aggregability (is that a word?) when it comes to routing. I emphatically agree that if every end user gets a random tiny ip block and those blocks are distributed chaotically then routing will break for all but the biggest iron routers. In that scenario shortest path routing would be unmanagable. Entropic portable micro-routes will just not work with current routing schemes. Kevin > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Tuesday, June 19, 2007 2:00 PM > To: Kevin Kargel > Cc: PPML at arin.net > Subject: Re: [ppml] Revising Centrally Assigned ULA draft > > > From my point of view I am not terribly worried about the routing > > table issue. I have every confidence that the 7xxx class cisco > > routers I am running now will be able to manage it with > hopefully not > > too terrible upgrades. > > you are either living in a fantasy that a 7xxx cisco will > handle O(10^6) routes, we are not talking about the dfz in > the direction it is heading, or we think quite differently > about where it is heading. > > randy > From stephen at sprunk.org Tue Jun 19 15:51:09 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 19 Jun 2007 14:51:09 -0500 Subject: [ppml] Revising Centrally Assigned ULA draft References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com><46742F0C.4080702@spaghetti.zurich.ibm.com> <37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org> <014101c7b147$e937efa0$6701a8c0@atlanta.polycom.com> Message-ID: <014901c7b2ac$1bb7ae10$423816ac@atlanta.polycom.com> Thus spake "David Conrad" > On Jun 17, 2007, at 6:22 PM, Stephen Sprunk wrote: >> The current consensus criteria for "deserving" a routing slot can be >> found in the NRPM. > > Is it just me or is there appears to be a disconnect here: > > - On the one hand, we're told that routers can today handle an order of > magnitude more "routing slots" and over the long term, can handle oodles > more and that the RIRs don't do "routability". > > - On the other hand, ARIN policies are oriented towards conserving > "routing slots" and people are proposing fairly obscene hacks to obtain > address space that won't (at least in theory) consume "routing slots". > > It's probably just me... I think the disconnect is that the vendors are claiming massive numbers, but it'll be N years before those routers are deployed at every single point they're required, and N is expected to be large enough to render the vendors' claims irrelevant for current discussions. Even those that replace their "core" routers every ~3 years just push them down to the next level in the network; even if those 10M-route beasts will be available in 2 years, N will is going to be large enough we can't use them as the basis for policies we're making today. Vendors always base their pitches on the crazy idea that every customers will replace every router in their network every couple of years just because they have some cool new chassis or linecard available, which I'm sure would be very lucrative for them but isn't realistic. In the words of Bandy Rush, I encourage my competitors to do that... S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From bicknell at ufp.org Tue Jun 19 17:48:24 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 19 Jun 2007 17:48:24 -0400 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: References: <04576D9D-F221-480C-A38E-421D96C3251E@delong.com> <88A2BA80-EC82-4AF1-9388-C054BD9CA7F0@delong.com> <46742F0C.4080702@spaghetti.zurich.ibm.com> <37BA1D0D-5A11-4B36-AE6D-A2791943C44B@virtualized.org> <20070618010114.GB45940@ussenterprise.ufp.org> <20070618183454.GA10207@ussenterprise.ufp.org> Message-ID: <20070619214824.GA4220@ussenterprise.ufp.org> In a message written on Tue, Jun 19, 2007 at 09:04:34AM -0700, David Conrad wrote: > So, between 60K and 250K additional routes, which (according to the > router vendors) is still 1/4th what today's routers can handle. That > would appear to double the size of the routing table over a 2 to 3 > year period, not be a "jump by at least one order of magnitude > overnight, perhaps closer to two orders of magnitude." Under current policies. In the scenario you put forth PI was much easier to get, which will also mean an increase in the number of ASN's being allocated. Let me put it to you this way. Verizon Business (I pick on Jason as he's the only one I've seen stand up recently and give a metric, if someone has better numbers) has 200,000 internal routes IIRC. They have what, perhaps 2,000 RIR allocations (I bet it's less) so the average RIR block turns into 100 routes. Humm, that sounds low for a company getting /12's and such. Still, it's a factor of 100. If all of those turned into PI in the DFZ, you'd have a factor of 100 more routes. So if there's 200,000 routes today, it would be 20,000,000 routes in the time period it took people to get the space. Now, let's me optimistic and say 25% take advantage. That's still 5 million routes in perhaps 5 years time. Going from 200,000 to 5 million in 5 years pretty much is a step function, at least to me. And I think 25% buy in and an "average block" turning into 100 routes is both way low. > Clearly there is a disconnect. From my perspective, operators who > are concerned have been completely drowned out by those who (for > whatever reason) are not concerned. If major operators actually > believe what the router vendors is saying is BS, then they should > probably stop preaching to the choir in the RIR community and make > their feelings known more forcefully in places like NANOG (I wasn't > there, did anyone shoot down Scudder's presentation?) and the IETF. Part of the issue is that the "box" being able to do, say, 1 million routes does not mean the DFZ can be 1 million routes. If an ISP is going to deploy a 1 million route router with a 5 year lifespan, that's effectively maybe 500,000 routes today, to allow for growth over that lifespan. In a large provider that 500,000 routes is then probably divided to 200,000 in the DFZ, another 200,000 of internal routes to suport the Internet business, and 100,000 to support Layer 3 VPN's on the edge devices. So a 1M router box, buyable today is "full", in the sense of everything that will go on it with a 5 year life span, and 200,000 routes. Those numbers are just IPv4 too, that's left zero headroom for IPv6. Perhaps Jason can give a nod to my swag, but I think that's the jist of why he stands up at the meetings and is so concerned. > Aside from the fact that the IPv6 DFZ surpassing the IPv4 DFZ is a > mere doubling and there is (supposedly) sufficient headroom in > routers today, much less 2 to 3 years from now, what would drive the > rush for IPv6 space? I am skeptical that simply it's availability > (particularly if the $100/year fee was recurrent). IPv6 would need > to provide something that IPv4+NAT doesn't. IPv4 exhaustion will drive the rush. The first person who is effectively forced to use IPv6 will start pressuring the people they want to talk to use IPv6. As more people are forced to use IPv6, that groundswell will happen rather quickly. I think you'll find within a 18-24 month period 80% or more of the current IPv4 internet trying to migrate to at least dual-stack. So they will get IPv6 space. If PI is "easier" they will ask for it, because in IPv4 PI was better, reserved for the eletes, and makes your life a lot easier. I think that's still true, but even if it's not the change will happen so quick we have no chance of educating the masses of network admins around the globe. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From drc at virtualized.org Tue Jun 19 18:34:45 2007 From: drc at virtualized.org (David Conrad) Date: Tue, 19 Jun 2007 15:34:45 -0700 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: <20070618185622.GC10207@ussenterprise.ufp.org> References: <20070618010114.GB45940@ussenterprise.ufp.org> <1070618035523.24656G-301000@Ives.egh.com> <20070618010114.GB45940@ussenterprise.ufp.org> <20070618133011.GA89006@ussenterprise.ufp.org> <1AF7CF52-9B95-4CAD-B392-C4237CDE1AFF@virtualized.org> <20070618185622.GC10207@ussenterprise.ufp.org> Message-ID: Leo, On Jun 18, 2007, at 11:56 AM, Leo Bicknell wrote: > I think we have to make some educated guess at what is probable. Indeed. My (perhaps not so) educated guesses: - In the face of a lack of consensus that routing technology is facing a scalability crisis, there will be increasing economic, business, religious, and political pressure to further liberalize IPv6 allocation policies, with the end state being "at least one PI / 48 on request". This pressure (political, in particular, egged on by the economic, business and religious) will increase exponentially as the IPv4 free pool depletes. - Pointing out that router upgrades cost money and take time will be taken as merely being co-opted into the vast ISP conspiracy aimed at the continued suppression of the non-ISP masses by either Lazy or Evil Greedy Bastards(tm) (been there, seen that, and actually do have the T-shirt). - Inertia being the second most powerful force in the universe will actively resist deployment of any significant shift in Internet technology (e.g., loc/id split) unless somehow the first most powerful force in the universe, profit motive, can be utilized to overcome inertia. - Threats of imminent death of the Internet due to routers falling over or infinite bgp convergence times are insufficient to trigger the first most powerful force in the universe because ISPs can, have, and will apply filters to protect their own infrastructure and customers. - The first most powerful force in the universe will be against you when people who have obtained /48s via liberalized PI allocation policies (either being discussed or implemented in all RIRs as I understand it) come to their ISPs and offer cold hard cash to have those /48s routed. As network engineers, you will lose the battle against the sales and marketing folks. - There are 5 geographical monopolies, each with their own agenda. That the ARIN community makes a decision regarding the appropriateness of PI-for-everybody has little affect on the communities in the other geographic monopolies. In fact, it is easy to imagine the first most powerful force in the universe acting to encourage an RIR to meet its community's demands in a way that ensures financial sustainability in the face of the post-IPv4-free- pool apocalypse. Of course, these are just guesses. > We need a method of deciding "worth" that can be implemented > independently by each ISP and does not require them to trust their > neighbor. I don't disagree. Are RIR policies the best place to establish worth? Rgds, -drc From bicknell at ufp.org Tue Jun 19 18:39:02 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 19 Jun 2007 18:39:02 -0400 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: References: <20070618010114.GB45940@ussenterprise.ufp.org> <1070618035523.24656G-301000@Ives.egh.com> <20070618010114.GB45940@ussenterprise.ufp.org> <20070618133011.GA89006@ussenterprise.ufp.org> <1AF7CF52-9B95-4CAD-B392-C4237CDE1AFF@virtualized.org> <20070618185622.GC10207@ussenterprise.ufp.org> Message-ID: <20070619223901.GA8116@ussenterprise.ufp.org> In a message written on Tue, Jun 19, 2007 at 03:34:45PM -0700, David Conrad wrote: > I don't disagree. Are RIR policies the best place to establish worth? I think the problem is worse than your question alludes to.... With the current technology, protocols, and deployment tools I think RIR's are the only place you can establish worth. There is no second solution. So best place or not, it's the only solution for right now. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From mack at exchange.alphared.com Tue Jun 19 23:09:30 2007 From: mack at exchange.alphared.com (mack) Date: Tue, 19 Jun 2007 22:09:30 -0500 Subject: [ppml] Revising Centrally Assigned ULA draft In-Reply-To: References: Message-ID: <859D2283FD04CA44986CC058E06598F84173D1CA47@exchange4.exchange.alphared.local> A number of people had a number of scathing remarks regarding my last post: 1) If people want to use IPv6 NAT let them. Some are going to because there are going to be people marketing equipment for it. I don't honestly think anyone is going to be using PAT with IPv6. If they are then they are seriously brain damaged and should not have access to a computer. 2) The number of routes in the table is going to be an issue. Cisco has a route processor that will handle 1M routes IPv4 routes and 512K IPv6 routes. It will be at least 2 years before the next iteration is ready I am fairly certain. The price tag of this device is rather high and requires every blade to be upgraded with a new DFC board as well. Multiply that buy the number of routers required to carry full routes. We aren't planning on upgrading this year. We are stuck with the current 512K IPv4 and 256K IPv6 routes limit. We currently see about 220K global prefixes in IPv4 and 845 in IPv6. The total number of prefixes is higher, but those are the ones seen from a majority of providers. 3) The BGP loads on edge routers are quite high. It takes several minutes for a full BGP reload of one session. Bad things can happen if multiple BGP sessions reset at once. I have seen that happen. It isn't pretty. This isn't a future problem. This is happening now. 4) /48s are going to get filtered if the number of routes gets too high. That is a fact of life. If the router won't handle it, then it won't get routed. 5) Criteria for /48s to people who have a business need (as opposed to routing need) is a different policy issue. IP addresses based on business need would make a good policy proposal should someone choose to write one. Basics of a business need proposal for IPv6 only: a) Entity must be capable of routing the IP block assigned. (This includes technical capability as well as owning equipment and having an appropriate contract with an upstream) b) Entity must be a business or non-profit organization as defined by some set of criteria (Tax ID # perhaps). c) Entity must show that renumbering its IP space on changing transit providers would be a significant financial burden on the entity or its customers. (some minimum computer count and other statistics) d) Entity must be a unique site from any other entity granted IP space. (no double dipping or having a single web server in someone's data center). The arguments against ULA-C seem to be: 1) It is a waste of space (how big are those nanobots again?). 2) People will use it for NAT (which is their own problem). 3) People have a business case for IP addresses (which is a different issue). 4) Everyone should be able to get a /48. Why do the same people who argue ULA-C is a waste of space think everyone should have a /48? Summary: As someone who has to deal with this on a daily basis, I would prefer to see aggregated routes. ULA and ULA-C is the appropriate place for giving out unique /48s to anyone that wants them and can't/won't justify them. If someone thinks a business need proposal is worth fleshing out please do so. LR Mack McBride Network Administrator Alpha Red, Inc. From michael.dillon at bt.com Wed Jun 20 05:05:54 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 20 Jun 2007 10:05:54 +0100 Subject: [ppml] Worth of a routing table slot In-Reply-To: <20070619223901.GA8116@ussenterprise.ufp.org> References: <20070618010114.GB45940@ussenterprise.ufp.org><1070618035523.24656G-301000@Ives.egh.com><20070618010114.GB45940@ussenterprise.ufp.org><20070618133011.GA89006@ussenterprise.ufp.org><1AF7CF52-9B95-4CAD-B392-C4237CDE1AFF@virtualized.org><20070618185622.GC10207@ussenterprise.ufp.org> <20070619223901.GA8116@ussenterprise.ufp.org> Message-ID: > I think the problem is worse than your question alludes to.... > > With the current technology, protocols, and deployment tools > I think RIR's are the only place you can establish worth. > There is no second solution. I disagree. The IETF is already discussing these issues and seeking solutions. Since this is a longer term issue that does not need a solution within 12 months, and may need vendor support in changing routing software, it makes more sense to take this discussion to the IETF working groups. Remember that an IETF WG is only as good as the people who participate. ARIN and the other RIRs really don't have the mandate to solve this problem of the value of routing table slots or the increased consumption of routing table slots. The IETF created the problem in the design of its protocols and the IETF is the place to fix the problem. Discussing these issues on PPML only devalues ARIN by focussing attention away from issues which ARIN can deal with. --Michael Dillon From billigeziggis at freenet.de Wed Jun 20 23:28:59 2007 From: billigeziggis at freenet.de (billigeziggis at freenet.de) Date: Thu, 21 Jun 2007 05:28:59 +0200 Subject: [ppml] Zigaretten 49% billiger//Cigarettes 50% discount Message-ID: <168520268902557@mx.freenet.de> Endlich k?nnen Sie legal und seri?s Ihre Zigaretten per Post aus Spanien bestellen. Sparen Sie bis zu 50% zum hohen Deutschen Preis. Vom WDR getestet. Legal und seri?s! Kein Zoll keine Geb?hren Versand schnell innerhalb 48 Stunden per UPS Alle beliebten Marken sind im Shop erh?ltlich! Neu:Zahlen Sie sicher mit Paypal/Moneybookers www.star-smokers.com English Version: Get 50% discount for your Cigarettes. All Brands you want. Legal and serius! Free shipping! Filter Cigarettes and Roling Tobacco -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Type: image/jpeg Size: 26014 bytes Desc: not available URL: From jcurran at istaff.org Thu Jun 21 09:34:28 2007 From: jcurran at istaff.org (John Curran) Date: Thu, 21 Jun 2007 09:34:28 -0400 Subject: [ppml] LACNIC announces IPv6 adoption time line for their region - http://lacnic.net/ipv6/en/ Message-ID: "The goal of this campaign is that the region of Latin America and the Caribbean completes the IPv6 adoption process before January 1st, 2011." (20 June 2007) FYI, /John From info at arin.net Thu Jun 21 09:51:15 2007 From: info at arin.net (Member Services) Date: Thu, 21 Jun 2007 09:51:15 -0400 Subject: [ppml] Get Involved in ARIN's Policy Process Message-ID: <467A8253.8080102@arin.net> On 7 May, the ARIN Board passed a resolution indicating that ARIN's ability to allocate large contiguous IPv4 address blocks will be limited as the unallocated pool is reduced. As a result, community members have expressed renewed interest in the ARIN policy process. Anyone may participate in the open and transparent policy development process. The Internet Resource Policy Evaluation Process (IRPEP) details how a proposal becomes a policy. IRPEP is available at: http://www.arin.net/policy/irpep.html After you are familiar with the IRPEP submitting a policy proposal is simple. 1. Fill out the policy proposal template available at: http://www.arin.net/policy/irpep_template.html 2. Submit it to policy at arin.net 3. Your proposal will be posted to the Public Policy Mailing List and forwarded to the Advisory Council for consideration to be numbered as a formal proposal. If you have any questions, you may send those to policy at arin.net as well. A new animated feature describes the policy process and explains how you can participate. Watch the tutorial at: http://www.arin.net/education/cbt/IRPEP/ Policy proposal discussions occur on the Public Policy Mailing List (PPML) and at biannual Public Policy meetings. Subscribe to the PPML today and plan to attend ARIN XX in Albuquerque, NM! http://lists.arin.net/mailman/listinfo/ppml http://www.arin.net/ARIN-XX/ Contact Member Services at info at arin.net if you have any questions. Regards, Raymond A. Plzak President and CEO American Registry for Internet Numbers (ARIN) From info at arin.net Thu Jun 21 11:27:46 2007 From: info at arin.net (Member Services) Date: Thu, 21 Jun 2007 11:27:46 -0400 Subject: [ppml] Cryptographic Authentication Message-ID: <467A98F2.3020703@arin.net> On 14 June 2007 the ARIN Board of Trustees rejected the three proposals listed below. *2007-1: Reinstatement of PGP Authentication Method *2007-2: Documentation of the Mail-From Authentication Method *2007-3: Documentation of the X.509 Authentication Method With regard to these proposals, the ARIN Board of Trustees makes the following statement. ************************************** "On 17 May 2007 the ARIN Advisory Council advanced policy proposals 2007-1, 2007-2, and 2007-3 to the Board of Trustees, recommending adoption. The Board found strong community support for ARIN to use crypto authentication mechanisms whenever possible and to implement PGP as soon as possible. However, the Board believes that the use of crypto authentication mechanisms is an operational matter and not an Internet number resource policy matter, and thus did not adopt these as policy proposals. Instead, the Board has directed staff to implement crypto authentication mechanisms (specifically including PGP) on all communications concerning the management of Internet number resources whenever feasible. It further directed the staff to implement the use of PGP as soon as possible. The Board recommended that ARIN staff develop training materials to assist those communicating with ARIN about the management of Internet number resources in making use of crypto authentication mechanisms in their communication with ARIN. The Board of Trustees would like to thank the Advisory Council and the authors for their work in advancing these functional proposals." *********************************************** The PGP crypto authentication method will be implemented not later than 15 September 2007. Policy proposal texts are available at the Policy Proposal Archive which can be found at: http://www.arin.net/policy/proposal_archive.html Regards, Member Services Department American Registry for Internet Numbers From sandy at tislabs.com Thu Jun 21 11:40:01 2007 From: sandy at tislabs.com (Sandy Murphy) Date: Thu, 21 Jun 2007 11:40:01 -0400 (EDT) Subject: [ppml] Cryptographic Authentication In-Reply-To: <467A98F2.3020703@arin.net> Message-ID: <20070621154001.11DBD3F47B@pecan.tislabs.com> >However, the Board believes that the use of crypto authentication >mechanisms is an operational matter and not an Internet number resource >policy matter I would say that authentication is not just an operational matter but also a matter of security policy. Which immediately brings up the question - what is ARIN's security policy and where is it documented? >Instead, the Board has directed staff to implement crypto >authentication mechanisms (specifically including PGP) on all >communications concerning the management of Internet number resources >whenever feasible. It further directed the staff to implement the use of >PGP as soon as possible. This is a good thing. --Sandy From Paul_Vixie at isc.org Thu Jun 21 18:45:52 2007 From: Paul_Vixie at isc.org (Paul_Vixie at isc.org) Date: Thu, 21 Jun 2007 22:45:52 +0000 Subject: [ppml] Paul Vixie: Re: draft-ietf-ipv6-ula-central-02.txt use case Message-ID: <63100.1182465952@sa.vix.com> for those of you not following the ipv6 at ietf.org mailing list, here's a sample: -------------- next part -------------- An embedded message was scrubbed... From: Paul Vixie Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case Date: Thu, 21 Jun 2007 22:43:20 +0000 Size: 4773 URL: From sleibrand at internap.com Thu Jun 21 20:31:38 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 21 Jun 2007 20:31:38 -0400 (EDT) Subject: [ppml] draft-ietf-ipv6-ula-central-02.txt use case (fwd) Message-ID: And a reply. Isn't cross-posting great? :) ---------- Forwarded message ---------- Date: Thu, 21 Jun 2007 17:28:26 -0700 From: Scott Leibrand To: Paul Vixie Cc: ipv6 at ietf.org Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case Paul Vixie wrote: > > by asking for a use case, i'm pointing out that if you can't be reached by > an ip packet from "there", then your need to look up a PTR corresponding to > an address in "there" is unfathomable. > I get that. But just because I *do* have IP reachability to "there", that doesn't mean my local resolver is configured to go "there" for DNS resolution. That's why I need to have a delegation chain pointing to the appropriate name server over "there". >> I guess what it comes down to is that the intended use case for ULA-C is to >> connect a bunch of companies with private address space on a private >> network. >> > > the idea that someone would only need PI for "public networking" is bizarre. > quite a lot of normal IPv4 space is never advertised into the "default free > zone" but it's universally unique and used "privately" with passion & verve, > and there is no reason to expect that IPv6 PI won't be used the same way. > > a global RIR policy to support this "private network" use case would suggest > that each RIR lay aside a /32 worth of space that was meant to be carved up > in /48 chunks for folks who needed smaller chunks of address space for > private > networking, with advice to the community that no address space in these /32's > be advertised to the DFZ, and that it be filtered out if seen in the DFZ. an > RIR could theoretically come up with a "private space only" membership class > with lower fees. whois and PTR-space NS RRsets would be managed normally. > You just did an excellent job of describing ULA-C. The only difference is that ULA-C is being specified top-down through the RFC process, rather than being put together in an ad-hoc bottom-up process that may be different for each RIR. > i think the disconnect here is that a lot of folks are assuming that the RIR > system only allocates "public" address space. that's not true today, and it > never has been true (compare historical allocations vs. DFZ advertisements), > and there's no reason to try to make it true or to assume that it ever will > be true. RIRs allocate universally unique space. how it's used (public vs. > private) is not an RIR concern. > It is true that someone who can get a PI allocation can use it for internal use just as they would with ULA-C. However, since someone who can get a PI allocation can easily put it in the DFZ, the RIR membership has made restricting the distribution of PI space an RIR concern through the policy process. The RIRs could elect to allocate private-use-only PI out of a special block, but such space is less likely to remain out of the DFZ, because the designation of it as not-to-be-routed would not carry the force of an RFC standard, and there would not be a single block (FC00::/7) to filter, but several different blocks, one from each RIR who chose to create private-use PI space. As such, I believe that the IETF should designate ULA-C and hand it off to IANA and the RIRs to manage, rather than having the RIRs designate private-use-only PI space. -Scott From jeroen at unfix.org Fri Jun 22 09:32:59 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 22 Jun 2007 14:32:59 +0100 Subject: [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC Message-ID: <467BCF8B.4090308@spaghetti.zurich.ibm.com> [*full rant mode*] My eye just fell on a very strange new allocation, apparently made under some new rules in the AFRINIC region which seem to be very wasteful and very out of sync with the rest of the world who are at least thinking a bit about address conservation instead of just blowing address space like there is no tomorrow: http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm#5 details: 8<-------------- 5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organization must: a) be an LIR; b) not be an end site; c) show a detailed plan to provide IPv6 connectivity to organizations in the AfriNIC region. d) show a reasonable plan for making /48 IPv6 assignments to end sites in the AfriNIC region within twelve months. The LIR should also plan to announce the allocation as a single aggregated block in the inter-domain routing system within twelve months. 5.1.2. Initial allocation size Organizations that meet the initial allocation criteria are eligible to receive a minimum allocation of /32. ---------------------------------------------->8 Wow, so you make a new 'company' in 911 land and say "I am going to allocate a single /48" and you get a FULL /32 even when you will never ever ever use it or even are going to think about using it? The first "organization" which is using this to waste space seems to be: inet6num: 2001:42d0::/32 netname: AfriNIC-IPv6-1 descr: AfriNIC descr: RIR country: MU Gee, the RIR itself. How many people are using the AFRINIC network? 10-50? Are they really *ever* going to need more than a /48? Are they ever going to have a need for 65536 of those /48's? Really this is just a waste of address space. Yes there is "enough", but being sooo obviously wasteful just to be able to have a nice slot in the routing tables is a bit over done. I hope that the other regions take this in mind too when (re)considering their address policies. Giving out /48's or even a /40 to an organization that is in-effect an end-site I can understand, especially when they can justify the need for that amount of address space. But giving /32's to every single endsite that simply asks for it is very very very far fetched. They will not even ever fill up a /40 of address space even if they would have two sites (read: offices) in every country in Africa, let alone 65536 sites. Such a waste. Funnily later in the above document they point to HD ratios. What point is that when the waste is already happened? RIR's should be giving out address space based on "need" and that need must justified, giving out /32's as "those fit in the routing slots" is a really really bad idea. In short: if you want a nice /32 without issues: setup a small shop in Africa and presto! Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From jordi.palet at consulintel.es Fri Jun 22 10:06:27 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 22 Jun 2007 16:06:27 +0200 Subject: [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467BCF8B.4090308@spaghetti.zurich.ibm.com> Message-ID: Jeroen, This is just ridiculous. All the RIRs have their own /32 for their internal usage. Regards, Jordi > De: Jeroen Massar > Organizaci?n: Unfix > Responder a: > Fecha: Fri, 22 Jun 2007 14:32:59 +0100 > Para: ARIN Address Policy , RIPE Address Policy > , AFRNIC IPv6 , APNIC > IPv6 > Asunto: [ppml] How to get a IPv6 /32 the cheap way: go to AFRINIC > > [*full rant mode*] > > My eye just fell on a very strange new allocation, apparently made under some > new rules in the AFRINIC region which seem to be very wasteful and very out of > sync with the rest of the world who are at least thinking a bit about address > conservation instead of just blowing address space like there is no tomorrow: > > http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm#5 details: > 8<-------------- > 5.1.1. Initial allocation criteria > To qualify for an initial allocation of IPv6 address space, an organization > must: > a) be an LIR; > b) not be an end site; > c) show a detailed plan to provide IPv6 connectivity to organizations in the > AfriNIC region. > d) show a reasonable plan for making /48 IPv6 assignments to end sites in the > AfriNIC region within twelve months. The LIR should also plan to announce the > allocation as a single aggregated block in the inter-domain routing system > within twelve months. > > 5.1.2. Initial allocation size > > Organizations that meet the initial allocation criteria are eligible to > receive a minimum allocation of /32. > ---------------------------------------------->8 > > Wow, so you make a new 'company' in 911 land and say "I am going to allocate a > single /48" and you get a FULL /32 even when you will never ever ever use it > or even are going to think about using it? > > The first "organization" which is using this to waste space seems to be: > > inet6num: 2001:42d0::/32 > netname: AfriNIC-IPv6-1 > descr: AfriNIC > descr: RIR > country: MU > > Gee, the RIR itself. How many people are using the AFRINIC network? 10-50? Are > they really *ever* going to need more than a /48? Are they ever going to have > a need for 65536 of those /48's? > > Really this is just a waste of address space. Yes there is "enough", but being > sooo obviously wasteful just to be able to have a nice slot in the routing > tables is a bit over done. > > > I hope that the other regions take this in mind too when (re)considering their > address policies. > > Giving out /48's or even a /40 to an organization that is in-effect an > end-site I can understand, especially when they can justify the need for that > amount of address space. But giving /32's to every single endsite that simply > asks for it is very very very far fetched. They will not even ever fill up a > /40 of address space even if they would have two sites (read: offices) in > every country in Africa, let alone 65536 sites. Such a waste. > > Funnily later in the above document they point to HD ratios. What point is > that when the waste is already happened? > > > RIR's should be giving out address space based on "need" and that need must > justified, giving out /32's as "those fit in the routing slots" is a really > really bad idea. > > In short: if you want a nice /32 without issues: setup a small shop in Africa > and presto! > > Greets, > Jeroen > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jeroen at unfix.org Fri Jun 22 10:18:25 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 22 Jun 2007 15:18:25 +0100 Subject: [ppml] [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: References: Message-ID: <467BDA31.4030607@spaghetti.zurich.ibm.com> JORDI PALET MARTINEZ wrote: > Jeroen, > > This is just ridiculous. What is ridiculous is that /32's are getting wasted and will never be used. What is also ridiculous is that RIR policies are trying to avoid end-sites getting /48's in some places who need it to 'control routingtable entries' but then this shows up as a full /32 that never will be used. Now *THAT* is what is ridiculous. I have no problem at all with an organization receiving a justified /48, but a /32 for an organisation that will never ever use more than a /40 is ridiculous. > All the RIRs have their own /32 for their internal usage. APNIC has one indeed: 2001:dc0::/32 but the rest doesn't. ARIN has a 2001:500::/48 which is more correct, they won't need much more. Where exactly is the one for RIPE, ARIN and LACNIC? See that is not !ALL! RIPE even went so far to use 2 /48's (SURFNET+BIT) to avoid coming into the mess of being preferential to themselves. Also, since when is a RIR special in anyway? Also, since when do those networks justify the need of 65536 /48's? The point is not about AFRINIC, it is about wasting address space without justification. Alain Patrick AINA wrote: > This does not meet the requirements above. So you won't get it. It fully does, how else did AFRINIC assign a /32 to themselves? Nick Hilliard wrote: > Frankly, I fail to see the problem here. IMO, bona-fide LIRs should be > entitled to an ipv6 allocation under these terms at least in the RIPE > region. I agree that when an organization can justify (using HD ratios etc) the need for address space that they will fully be able to get that address space without any issues. But is AFRINIC (10-50 people) able to justify a /32 based on that? Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From adiel at afrinic.net Fri Jun 22 10:45:53 2007 From: adiel at afrinic.net (Adiel A. Akplogan) Date: Fri, 22 Jun 2007 18:45:53 +0400 Subject: [ppml] [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467BCF8B.4090308@spaghetti.zurich.ibm.com> References: <467BCF8B.4090308@spaghetti.zurich.ibm.com> Message-ID: <200706221451.l5MEpIQP012336@ns1.afrinic.net> Hello Jeroen, >[*full rant mode*] > >My eye just fell on a very strange new allocation, apparently made under some >new rules in the AFRINIC region which seem to be very wasteful and very out of >sync with the rest of the world who are at least thinking a bit about address >conservation instead of just blowing address space like there is no tomorrow: > >http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm#5 details: >8<-------------- >5.1.1. Initial allocation criteria >To qualify for an initial allocation of IPv6 address space, an >organization must: >a) be an LIR; >b) not be an end site; >c) show a detailed plan to provide IPv6 connectivity to organizations in the >AfriNIC region. >d) show a reasonable plan for making /48 IPv6 assignments to end sites in the >AfriNIC region within twelve months. The LIR should also plan to announce the >allocation as a single aggregated block in the inter-domain routing system >within twelve months. > >5.1.2. Initial allocation size > >Organizations that meet the initial allocation criteria are eligible to >receive a minimum allocation of /32. >---------------------------------------------->8 > >Wow, so you make a new 'company' in 911 land and say "I am going to allocate a >single /48" and you get a FULL /32 even when you will never ever ever use it >or even are going to think about using it? I think you have missed the point a) which says "be an LIR". So you must already be an LIR (and go through the LIR setup process) to get IPv6 allocation from AfrINIC. >The first "organization" which is using this to waste space seems to be: > >inet6num: 2001:42d0::/32 >netname: AfriNIC-IPv6-1 >descr: AfriNIC >descr: RIR >country: MU > >Gee, the RIR itself. How many people are using the AFRINIC network? 10-50? Are >they really *ever* going to need more than a /48? Are they ever going to have >a need for 65536 of those /48's? You can not take AfriNIC own allocation case to illustrate your assertion here ... We have allocated that bloc to our own Infrastructure (which has three locations to be connected together) so each with its own /48. Further to that we have other IPv6 Internal projects which will probably require several /48. As RIR I think we are in the position to evaluate our own need before making an allocation and if it was made be sure that is after careful evaluation. >Really this is just a waste of address space. Yes there is "enough", but being >sooo obviously wasteful just to be able to have a nice slot in the routing >tables is a bit over done. I don't see the waist. >Giving out /48's or even a /40 to an organization that is in-effect an >end-site I can understand, especially when they can justify the need for that >amount of address space. But giving /32's to every single endsite that simply >asks for it is very very very far fetched. They will not even ever fill up a >/40 of address space even if they would have two sites (read: offices) in >every country in Africa, let alone 65536 sites. Such a waste. Please read http://www.afrinic.net/docs/policies/afpol-v6200701.htm >Funnily later in the above document they point to HD ratios. What point is >that when the waste is already happened? I think you are confusing the IPv6 allocation to LIR document with PI assignment document which in fact was a proposal until few days where it was ratified by AfriNIC board (... but not yet implemented). >RIR's should be giving out address space based on "need" and that need must >justified, giving out /32's as "those fit in the routing slots" is a really >really bad idea. That is what we do. You can not have such affirmation based on a single case. >In short: if you want a nice /32 without issues: setup a small shop in Africa >and presto! You won't get it like that. - a. From jordi.palet at consulintel.es Fri Jun 22 11:17:32 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 22 Jun 2007 17:17:32 +0200 Subject: [ppml] [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467BDA31.4030607@spaghetti.zurich.ibm.com> Message-ID: You need to read all the policies before making such statements. For example that explains the /32 in LACNIC. RIRs can be considered, and in fact they are, critical infrastructures, and in some regions, then they get a /32, and while you can't warrantee that a /48 will be filtered, I agree that a /32 is the right size for any critical infrastructure. Regards, Jordi > De: Jeroen Massar > Organizaci?n: Unfix > Responder a: > Fecha: Fri, 22 Jun 2007 15:18:25 +0100 > Para: > CC: , RIPE Address Policy , "IPv6 > in Africa " , APNIC > IPv6 , Nick Hilliard , > > Asunto: Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to > AFRINIC > > JORDI PALET MARTINEZ wrote: >> Jeroen, >> >> This is just ridiculous. > > What is ridiculous is that /32's are getting wasted and will never be used. > What is also ridiculous is that RIR policies are trying to avoid end-sites > getting /48's in some places who need it to 'control routingtable entries' > but then this shows up as a full /32 that never will be used. > > Now *THAT* is what is ridiculous. > > I have no problem at all with an organization receiving a justified /48, but a > /32 for an organisation that will never ever use more than a /40 is > ridiculous. > >> All the RIRs have their own /32 for their internal usage. > > APNIC has one indeed: 2001:dc0::/32 but the rest doesn't. > ARIN has a 2001:500::/48 which is more correct, they won't need much more. > Where exactly is the one for RIPE, ARIN and LACNIC? See that is not !ALL! > > RIPE even went so far to use 2 /48's (SURFNET+BIT) to avoid coming into the > mess of being preferential to themselves. > > Also, since when is a RIR special in anyway? > Also, since when do those networks justify the need of 65536 /48's? > > The point is not about AFRINIC, it is about wasting address space without > justification. > > Alain Patrick AINA wrote: >> This does not meet the requirements above. So you won't get it. > > It fully does, how else did AFRINIC assign a /32 to themselves? > > Nick Hilliard wrote: >> Frankly, I fail to see the problem here. IMO, bona-fide LIRs should be >> entitled to an ipv6 allocation under these terms at least in the RIPE >> region. > > I agree that when an organization can justify (using HD ratios etc) the need > for address space that they will fully be able to get that address space > without any issues. But is AFRINIC (10-50 people) able to justify a /32 based > on that? > > Greets, > Jeroen > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jeroen at unfix.org Fri Jun 22 11:24:17 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 22 Jun 2007 16:24:17 +0100 Subject: [ppml] [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <200706221451.l5MEpIQP012336@ns1.afrinic.net> References: <467BCF8B.4090308@spaghetti.zurich.ibm.com> <200706221451.l5MEpIQP012336@ns1.afrinic.net> Message-ID: <467BE9A1.80008@spaghetti.zurich.ibm.com> Adiel A. Akplogan wrote: > Hello Jeroen, [..] >> Gee, the RIR itself. How many people are using the AFRINIC network? >> 10-50? Are they really *ever* going to need more than a /48? Are they >> ever going to have a need for 65536 of those /48's? > > You can not take AfriNIC own allocation case to illustrate your > assertion here Why not? Is AfriNIC special, is AfriNIC outside of the policy rules set by their own membership? What does make AfriNIC so special to not even consult the rest of the world, let alone your membership, in making these decisions? So why did that not happen in the first place? > We have allocated that bloc to our own Infrastructure (which has three > locations to be connected together) so each with its own /48. Further > to that we have other IPv6 Internal projects which will probably > require several /48. I can fully understand a /48 per 'location', especially when they are administratively separate and/or very remote from each other. But you will never reach more than 50 of those locations. Those are a large amount and big projects AfriNIC is (going to) run then. By going to provide these services don't you think you are going against your membership, who only recently got the hard policy of only getting a /48 and they have to fully justify it. Or does AfriNIC think that everybody will be eligible for a /32? Also, is AfriNIC really going to use a full /32 with a staff of what 10-50 people or even less than that? AfriNIC is not an ISP as far as I am aware, unless some other business ventures unrelated to you being a RIR is being tapped into. As such, hosting projects is not an option either as that would mean you get clients, and that would be the only way that you could justify having a need for multiple /48's in that area. Can you clarify? > As RIR I think we are in the position to evaluate > our own need before making an allocation and if it > was made be sure that is after careful evaluation. Can you please explain again why a *RIR* (Regional Internet Registry) will be using 65536 /48's in the coming, lets take a liberal, 10 years? Can you show FULL justification for this? Just as a little example, there is a little RIR, one of the older ones, you might know them as "RIPE", they have been around for a long time and helped AfriNIC get off the ground. They are running a LOT of big projects and doing a lot of community work. Still they did not allocate a /32 to themselves, or a /48 for that matter. They are using two /48's from ISP's who donated those prefixes to them. This as their membership decided for them that a RIR is not special and also because they don't claim (_afaik_) to need that kind of address space. A /48 is sufficient for them. Another good example is another little RIR, called ARIN, they also only have a single /48 for their own network, also granted under the policy as specified by their membership. How come that AfriNIC doesn't think that a /48 or max a /40, under your own PI policy which was recently approved by your membership is not good enough. Is AfriNIC special on this planet? >> Really this is just a waste of address space. Yes there is "enough", >> but being sooo obviously wasteful just to be able to have a nice slot >> in the routing >> tables is a bit over done. > > I don't see the waist. I almost am having to ponder asking you how good you are in a role of a RIR if you can't do the math of 65536 /48's being wasted on this. I agree, it is nothing compared to the full address space of 128bits, but that is also what people though about 32bit IPv4 addresses, remind yourself of all the wailing people are doing about MIT having a /8. This is the exact same situation. Except now people are pointing at you when you don't justify the space. Especially when you are doing it without an appropriate policy in place. > Please read http://www.afrinic.net/docs/policies/afpol-v6200701.htm Which is not linked directly from the website, but I did find it from the email archives. Also that policy specifies one single /48. Not a /32 which is as you should know 65536 more than that. Just in case you wonder, as I mentioned already a couple of times also in other threads, I fully support organizations getting a /48 or upto even a /40 or more. But all as long as they can actually JUSTIFY that space. Saying "we are RIR, we can do what we want, we will run big projects" is not a good justification. >> Funnily later in the above document they point to HD ratios. What >> point is >> that when the waste is already happened? > > I think you are confusing the IPv6 allocation to LIR document with PI > assignment document which in fact was a proposal until few days where > it was ratified by AfriNIC board (... but not yet implemented). No I was referring to the following URL which I mentioned in my mail: http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm#5 Also, clearly if such a policy is not implemented yet, how can AfriNIC itself make use of that policy then? >> RIR's should be giving out address space based on "need" and that need >> must justified, giving out /32's as "those fit in the routing slots" >> is a really really bad idea. > > That is what we do. You can not have such affirmation based on a single > case. You didn't give any valid justification (yet), also you didn't even have a policy for this kind of allocation. Doing something once, doesn't mean you didn't break policy, especially when there is no such policy. >> In short: if you want a nice /32 without issues: setup a small shop in >> Africa >> and presto! > > You won't get it like that. Then how did you, being AfriNIC get it? Please elaborate, I am really wondering about how this works. And I very sure that a lot of other people are also very interested in knowing about these practices. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From jeroen at unfix.org Fri Jun 22 11:27:55 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 22 Jun 2007 16:27:55 +0100 Subject: [ppml] [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: References: Message-ID: <467BEA7B.1000608@spaghetti.zurich.ibm.com> JORDI PALET MARTINEZ wrote: > You need to read all the policies before making such statements. For example > that explains the /32 in LACNIC. A 10-50 people organization that is not an ISP, doesn't do hosting, only has 3 offices, get a /32, which is good for 65536 /48's, please explain me how that is 'good justification' ? > RIRs can be considered, and in fact they are, critical infrastructures, and > in some regions, then they get a /32, and while you can't warrantee that a > /48 will be filtered, I agree that a /32 is the right size for any critical > infrastructure. RIR's provide "Address Space" not a "routing guarantee". ARIN has a micro-allocation policies for "critical infrastructure", these are of size /48. This is for The IX "critical infrastructure" policies also only provide a /48. Filtering is something that is happening at the ISP's, not at the RIR. It is nothing that the RIR can do about, and it is also nothing that the RIR would have to worry about. According to your analogy, anybody should be getting IPv4 /24 or IPv6 /32's simply because they have 1 box somewhere and they are afraid of being filtered. That is not how justification of address space works. If it does work that way today, then it definitely has to be changed ASAP. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From Ed.Lewis at neustar.biz Fri Jun 22 11:34:23 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 22 Jun 2007 11:34:23 -0400 Subject: [ppml] on PPML? - was Re: [GLOBAL-V6] How to get ... In-Reply-To: <467BE9A1.80008@spaghetti.zurich.ibm.com> References: <467BCF8B.4090308@spaghetti.zurich.ibm.com> <200706221451.l5MEpIQP012336@ns1.afrinic.net> <467BE9A1.80008@spaghetti.zurich.ibm.com> Message-ID: At 16:24 +0100 6/22/07, Jeroen Massar wrote: >Why not? Is AfriNIC special, is AfriNIC outside of the policy rules set by >their own membership? What does make AfriNIC so special to not even consult >the rest of the world, let alone your membership, in making these decisions? I am reading this on ARIN's PPML (I noticed upon preparing this reply that there was massive cross-posting). I question whether this discussion is appropriate for this mailing list, especially the pointed criticism raised in the quoted text above. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From jeroen at unfix.org Fri Jun 22 11:36:07 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 22 Jun 2007 16:36:07 +0100 Subject: [ppml] [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <200706221526.46024.aalain@trstech.net> References: <467BDA31.4030607@spaghetti.zurich.ibm.com> <200706221526.46024.aalain@trstech.net> Message-ID: <467BEC67.5080307@spaghetti.zurich.ibm.com> Alain Patrick AINA wrote: > On Friday 22 June 2007 14:18:25 Jeroen Massar wrote: > >> Alain Patrick AINA wrote: >>> This does not meet the requirements above. So you won't get it. >> It fully does, how else did AFRINIC assign a /32 to themselves? > > This would have been your question instead of concluding so negatively on a > global note. Excuses, I will try to add a short bullet pointed list of items next time with a nice animated powerpoint presentation and an executive summary to make my question come across to you. I've sent it to all the RIR lists as it affects global policy decisions: that a single RIR is acting in their own good without even having asked their own membership about this situation. Their statement of "we are a RIR we know what we are doing" is not good enough, especially as there is no active policy actually allowing them to request such a allocation even under their own policies. Any policy that simply allows any party to get a /32 without justification is the same as when IPv4 started out, where everybody simply got a /8. Indeed at that timepoint there was enough space, but what is the main complaint from various people nowadays: that they should have gotten less as they didn't need it in the first place. We can indeed give IPv6 prefixes for free, give every household a /32, and we'll probably not run out yet; and if we do we have another 7 tries when 2000::/3 runs full. But is that really what people want? To simply squat on the address space as much as possible, so that you at least have it? Not a good thing, especially not a good thing when a RIR does it themselves. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From jeroen at unfix.org Fri Jun 22 11:44:08 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 22 Jun 2007 16:44:08 +0100 Subject: [ppml] on PPML? - was Re: How to get ... In-Reply-To: References: <467BCF8B.4090308@spaghetti.zurich.ibm.com> <200706221451.l5MEpIQP012336@ns1.afrinic.net> <467BE9A1.80008@spaghetti.zurich.ibm.com> Message-ID: <467BEE48.6050108@spaghetti.zurich.ibm.com> Edward Lewis wrote: > At 16:24 +0100 6/22/07, Jeroen Massar wrote: > >> Why not? Is AfriNIC special, is AfriNIC outside of the policy rules set by >> their own membership? What does make AfriNIC so special to not even consult >> the rest of the world, let alone your membership, in making these decisions? > > I am reading this on ARIN's PPML (I noticed upon preparing this reply > that there was massive cross-posting). I question whether this > discussion is appropriate for this mailing list, especially the > pointed criticism raised in the quoted text above. Global address consumption affects everybody globally. As such, if AfriNIC decides to waste address space, that affects all RIR's globally. As such it also affects ARIN, as such it affects you. As an exercise, remind me again where Canada is, does this fall in ARIN region or in the AfriNIC region? Then please try to explain me why I saw this recently: 2001:42c8::/32 Canada TGB-V6-AFRICA Indeed, even if you are a company in the ARIN region you can go to AfriNIC and get a prefix there. Note: Absolutely nothing against Teleglobe, they simply have their head office in Canada, and they are (going to) operate a network in Africa (which is great!). And the above is most likely a completely valid case for getting them an assignment, even though it does skew the statistics quite a bit because the country information is wrong. But still this shows that if a company wants, they could set up shop in Africa and use AfriNIC policies to get an assignment, thus bypassing the policies which are really in effect in the ARIN region. This of course also goes for every other RIR region. As prefixes are global, nobody will try to limit you using that prefix in the rest of the world. This in the end can mean that regions disappear, and all the hard work people do on complaining about policies is futile. And that was the subject of the message wasn't it!? :) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From pesherb at yahoo.com Fri Jun 22 12:07:33 2007 From: pesherb at yahoo.com (Peter Sherbin) Date: Fri, 22 Jun 2007 09:07:33 -0700 (PDT) Subject: [ppml] [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467BEC67.5080307@spaghetti.zurich.ibm.com> Message-ID: <20070622160733.264.qmail@web58705.mail.re1.yahoo.com> > We can indeed give IPv6 prefixes for free, give every household a /32, and > we'll probably not run out yet... But is that really what people want? Precisely. Any entity with a free will is entitled to a part of IPv6 space free of charge. And yes we will need enough addresses pointing to every cell in a human body. Wether current policies and architecture support it and if such space will be used any time soon is another question under discussion, e.g. RAM, etc. Thanks, Peter --- Jeroen Massar wrote: > Alain Patrick AINA wrote: > > On Friday 22 June 2007 14:18:25 Jeroen Massar wrote: > > > >> Alain Patrick AINA wrote: > >>> This does not meet the requirements above. So you won't get it. > >> It fully does, how else did AFRINIC assign a /32 to themselves? > > > > This would have been your question instead of concluding so negatively on a > > global note. > > Excuses, I will try to add a short bullet pointed list of items next time with > a nice animated powerpoint presentation and an executive summary to make my > question come across to you. > > I've sent it to all the RIR lists as it affects global policy decisions: that > a single RIR is acting in their own good without even having asked their own > membership about this situation. > > Their statement of "we are a RIR we know what we are doing" is not good > enough, especially as there is no active policy actually allowing them to > request such a allocation even under their own policies. > > Any policy that simply allows any party to get a /32 without justification is > the same as when IPv4 started out, where everybody simply got a /8. Indeed at > that timepoint there was enough space, but what is the main complaint from > various people nowadays: that they should have gotten less as they didn't need > it in the first place. > > We can indeed give IPv6 prefixes for free, give every household a /32, and > we'll probably not run out yet; and if we do we have another 7 tries when > 2000::/3 runs full. But is that really what people want? To simply squat on > the address space as much as possible, so that you at least have it? > > Not a good thing, especially not a good thing when a RIR does it themselves. > > Greets, > Jeroen > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ____________________________________________________________________________________ Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469 From jeroen at unfix.org Fri Jun 22 12:09:06 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 22 Jun 2007 17:09:06 +0100 Subject: [ppml] [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467BEE69.60906@inex.ie> References: <467BDA31.4030607@spaghetti.zurich.ibm.com> <467BEE69.60906@inex.ie> Message-ID: <467BF422.7030901@spaghetti.zurich.ibm.com> Nick Hilliard wrote: > Jeroen Massar wrote: >> I agree that when an organization can justify (using HD ratios etc) >> the need >> for address space that they will fully be able to get that address space >> without any issues. But is AFRINIC (10-50 people) able to justify a >> /32 based >> on that? > > Jeroen, > > you're muddling two separate issues here. > > 1. There is no special justification for a LIR to be assigned a /32 in > afrinic areas. As far as I'm concerned, this is fine and I'd be all in > favour of this sort of allocation guideline making its way into RIPE-land. I am also fine with that as long as there is a justification for the address space. Just being LIR is not good enough IMHO. Address space should be provided under the premise that it will actually be used one day. As such /48's are very appropriate for end-sites, upto /40 for large corporations, anything above that should be able to get a /32. But this all by justification of need. That we have enough address space today is great, but when they invent this nice "stay young forever pill to fly to Jupiter and back forever", then people in that era and everybody else also want to have IPv6 address space (unless we replace it again by then :). This thus might affect you yourself too, as such, I speak up on this. > 2. Afrinic allocated themselves a /32. > > Afrinic are a RIR, not a LIR, and it appears that they broke the rules > by allocating themselves a /32 (i.e. LIR size) instead of a /48 > (end-user size). And also without any real justification, as of yet. > This is not good. The least we expect from the (monopolistic) RIRs is > that they abide strictly by the rules set out by themselves and the > community. If they have any sense in the matter, they'll hand themselves > back the /32 and re-assign themselves a /48 under the generic PI > assignment classification. And nobody (I think :) would have a problem with that. Even a /45 would not be looked strangely at, as they can JUSTIFY that amount of address space. (3 offices, 5 very very large projects, reasonably believable IMHO) A /32, is not though. > TBH, the amount of address space which Afrinic allocated to themselves > is of very little technical importance. I agree, relative to a 128bits of address space, a /32 is effectively nothing. > What's relevant is that they broke their own rules, which will damage > their reputation and the level of trust they have in their geographic area. Absolutely. Thanks for getting that out of my ramblings. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From Ed.Lewis at neustar.biz Fri Jun 22 12:09:56 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 22 Jun 2007 12:09:56 -0400 Subject: [ppml] on PPML? - was Re: How to get ... In-Reply-To: <467BEE48.6050108@spaghetti.zurich.ibm.com> References: <467BCF8B.4090308@spaghetti.zurich.ibm.com> <200706221451.l5MEpIQP012336@ns1.afrinic.net> <467BE9A1.80008@spaghetti.zurich.ibm.com> <467BEE48.6050108@spaghetti.zurich.ibm.com> Message-ID: At 16:44 +0100 6/22/07, Jeroen Massar wrote: >Global address consumption affects everybody globally. As such, if AfriNIC >decides to waste address space, that affects all RIR's globally. As such it >also affects ARIN, as such it affects you. I guess I was too subtle in making my point. If you are criticizing the activities of Afrinic, take it up discreetly with Afrinic. The "Court of Public Opinion" is not a place for a fair "fight." I don't like the precedent of accusing an RIR of a misdoing and asking them to publicly defend themselves. The RIR's operate in a delicate balance of both openness in policy development and resource registration and confidentiality in handling and judging the worthiness of requests. Working in a environment of openness, confidentiality, and neutrality is difficult. You cannot defend yourself to the fullest because of the limits of what can be, what can not be, and what might otherwise be implied. Plus this is the ARIN mailing list. >Then please try to explain me why I saw this recently: >2001:42c8::/32 Canada TGB-V6-AFRICA I believe that question is wholly inappropriate for this list. Especially for this list. (In the pulic meetings, our chair doesn't tolerate personal "accusations" either, something I was heartened to witness in April.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From jeroen at unfix.org Fri Jun 22 12:23:08 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 22 Jun 2007 17:23:08 +0100 Subject: [ppml] on PPML? - was Re: How to get ... In-Reply-To: References: <467BCF8B.4090308@spaghetti.zurich.ibm.com> <200706221451.l5MEpIQP012336@ns1.afrinic.net> <467BE9A1.80008@spaghetti.zurich.ibm.com> <467BEE48.6050108@spaghetti.zurich.ibm.com> Message-ID: <467BF76C.3010202@spaghetti.zurich.ibm.com> Edward Lewis wrote: > At 16:44 +0100 6/22/07, Jeroen Massar wrote: > >> Global address consumption affects everybody globally. As such, if >> AfriNIC >> decides to waste address space, that affects all RIR's globally. As >> such it >> also affects ARIN, as such it affects you. > > I guess I was too subtle in making my point. Which point? Sorry, but not everybody is into prose, some people are engineers and simply want straight words. > If you are criticizing the activities of Afrinic, take it up discreetly > with Afrinic. The "Court of Public Opinion" is not a place for a fair > "fight." It is a problem with AfriNIC that has an effect globally. It is not a fight, it is public questioning. If you want to ignore it, then ignore it. > I don't like the precedent of accusing an RIR of a misdoing and asking > them to publicly defend themselves. The RIR's operate in a delicate > balance of both openness in policy development and resource registration > and confidentiality in handling and judging the worthiness of requests. That openness is not there when a RIR makes up their own rules without asking their membership. Or did I miss the superinternal memo that is not supposed to be public in the first place? > Working in a environment of openness, confidentiality, and neutrality is > difficult. You cannot defend yourself to the fullest because of the > limits of what can be, what can not be, and what might otherwise be > implied. > > Plus this is the ARIN mailing list. Stop thinking in your little American box. Or is the war in Iraq something that does not happen in the US and thus not relevant? To pull something in that also shows that local decisions have global effects. >> Then please try to explain me why I saw this recently: >> 2001:42c8::/32 Canada TGB-V6-AFRICA > > I believe that question is wholly inappropriate for this list. > Especially for this list. (In the pulic meetings, our chair doesn't > tolerate personal "accusations" either, something I was heartened to > witness in April.) If you try to say "Shut up" to me then either: - simply say on this list - simply say so by sending a private message And I am very sure that ARIN staff and other people are also very able to provide me with a similar message when needed very quickly. Please bring arguments along, they tend to help. I brought that up as a note to show you *WHY* it was appropriate to bring these matters up on the PPML mailinglist as policies and decisions happening in other regions *DO* affect ARIN. Let me repeat again, that I have NOTHING against that 2001:42c8::/32 assignment which is really a good thing and very well justified. It only demonstrates that Address Policy is a global thing, not something local. Organizations are global and the Internet is global. Policies and laws etc are not but they do affect us globally. And in case you don't like me mailing, then simply block all mail from jeroen at unfix.org, which is always nicely PGP signed, thus should be very easy to block in your MUA or even MTA. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From iwumba at yahoo.fr Fri Jun 22 12:44:55 2007 From: iwumba at yahoo.fr (Iwu Mbatelege) Date: Fri, 22 Jun 2007 16:44:55 +0000 (GMT) Subject: [ppml] Re : on PPML? - was Re: How to get ... Message-ID: <378359.11161.qm@web27508.mail.ukl.yahoo.com> Please stop this non sense debate here: Have you also come across the following address waist? I haven't seen you guys making any noise about them! 014/8 Jun 91 IANA - Public Data Network ---- (a whole /8 for an organisation of less than 20 people?) inet6num: 2001:07F8::/29 inet6num: 2001:07FD::/32 netname: K-rootserver-net-20030829 descr: This assignment given to k-root.server.net descr: maintained by the RIPE NCC --- (just for the Kroot server Infratsructure ????? is this an LIR) inet6num2001:0DC0::/32 netnameAPNIC-AP-V6-20030124 descrAPNIC Pty Ltd - Brisbane Offices + Servers descrLevel 1, 33 Park Rd descrPO Box 2131, Milton descrBrisbane, QLD. countryAU --- (just for APNIC??? an LIR?) So is your problem with AfriNIC or you are going to request IANA , RIPE NCC, APNIC too to send you their justifications? note that most of the v6 assignments/allocations above were made in 2003 where none of these RIR had IPv6 PI policy in place. IM. ----- Message d'origine ---- De : Jeroen Massar ? : Edward Lewis Cc : ARIN Address Policy Envoy? le : Vendredi, 22 Juin 2007, 20h23mn 08s Objet : Re: [ppml] on PPML? - was Re: How to get ... Edward Lewis wrote: > At 16:44 +0100 6/22/07, Jeroen Massar wrote: > >> Global address consumption affects everybody globally. As such, if >> AfriNIC >> decides to waste address space, that affects all RIR's globally. As >> such it >> also affects ARIN, as such it affects you. > > I guess I was too subtle in making my point. Which point? Sorry, but not everybody is into prose, some people are engineers and simply want straight words. > If you are criticizing the activities of Afrinic, take it up discreetly > with Afrinic. The "Court of Public Opinion" is not a place for a fair > "fight." It is a problem with AfriNIC that has an effect globally. It is not a fight, it is public questioning. If you want to ignore it, then ignore it. > I don't like the precedent of accusing an RIR of a misdoing and asking > them to publicly defend themselves. The RIR's operate in a delicate > balance of both openness in policy development and resource registration > and confidentiality in handling and judging the worthiness of requests. That openness is not there when a RIR makes up their own rules without asking their membership. Or did I miss the superinternal memo that is not supposed to be public in the first place? > Working in a environment of openness, confidentiality, and neutrality is > difficult. You cannot defend yourself to the fullest because of the > limits of what can be, what can not be, and what might otherwise be > implied. > > Plus this is the ARIN mailing list. Stop thinking in your little American box. Or is the war in Iraq something that does not happen in the US and thus not relevant? To pull something in that also shows that local decisions have global effects. >> Then please try to explain me why I saw this recently: >> 2001:42c8::/32 Canada TGB-V6-AFRICA > > I believe that question is wholly inappropriate for this list. > Especially for this list. (In the pulic meetings, our chair doesn't > tolerate personal "accusations" either, something I was heartened to > witness in April.) If you try to say "Shut up" to me then either: - simply say on this list - simply say so by sending a private message And I am very sure that ARIN staff and other people are also very able to provide me with a similar message when needed very quickly. Please bring arguments along, they tend to help. I brought that up as a note to show you *WHY* it was appropriate to bring these matters up on the PPML mailinglist as policies and decisions happening in other regions *DO* affect ARIN. Let me repeat again, that I have NOTHING against that 2001:42c8::/32 assignment which is really a good thing and very well justified. It only demonstrates that Address Policy is a global thing, not something local. Organizations are global and the Internet is global. Policies and laws etc are not but they do affect us globally. And in case you don't like me mailing, then simply block all mail from jeroen at unfix.org, which is always nicely PGP signed, thus should be very easy to block in your MUA or even MTA. Greets, Jeroen _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml _____________________________________________________________________________ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail -------------- next part -------------- An HTML attachment was scrubbed... URL: From drc at virtualized.org Fri Jun 22 12:45:31 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 22 Jun 2007 12:45:31 -0400 Subject: [ppml] [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: References: Message-ID: <84C1471F-22C0-4970-A939-835B6E9770CF@virtualized.org> On Jun 22, 2007, at 11:17 AM, JORDI PALET MARTINEZ wrote: > RIRs can be considered, and in fact they are, critical > infrastructures, Why? Rgds, -drc From leo.vegoda at icann.org Fri Jun 22 13:11:50 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 22 Jun 2007 19:11:50 +0200 Subject: [ppml] [address-policy-wg] Re : on PPML? - was Re: How to get ... In-Reply-To: <378359.11161.qm@web27508.mail.ukl.yahoo.com> References: <378359.11161.qm@web27508.mail.ukl.yahoo.com> Message-ID: <14635C03-1F65-4684-91F3-029BEEDB3419@icann.org> On 22 Jun 2007, at 6:44pm, Iwu Mbatelege wrote: [...] > Have you also come across the following address waist? I haven't seen > you guys making any noise about them! > > 014/8 Jun 91 IANA - Public Data Network > ---- (a whole /8 for an organisation of less than 20 people?) > I am actively reviewing this registry. Over the last few months I have had excellent support from a large number of people and have been able to remove most of the 1000+ assignments that were listed there. It is quite possible that the last 11 assignments are no longer actively used and can be returned. I am in contact with most of those organisations, confirming their status and hope to be able to update RFC 3330 as a result later this year. Regards, -- Leo Vegoda IANA Numbers Liaison From drc at virtualized.org Fri Jun 22 13:41:52 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 22 Jun 2007 13:41:52 -0400 Subject: [ppml] Re : on PPML? - was Re: How to get ... In-Reply-To: <378359.11161.qm@web27508.mail.ukl.yahoo.com> References: <378359.11161.qm@web27508.mail.ukl.yahoo.com> Message-ID: Iwu, > Have you also come across the following address waist? I haven't seen > you guys making any noise about them! > > 014/8 Jun 91 IANA - Public Data Network > ---- (a whole /8 for an organisation of less than 20 people?) Actually, the PDN /8 was allocated for integrating X.25 networks into the Internet. Individual /32s were assigned to X.25 endpoints run by different companies, so representing 14/8 as "a whole /8 for an organization of less than 20 people" is not accurate. And besides, Leo Vegoda has been very active in recovering the /32s so we can return 14/8 to the free pool. There used to be over 200 assignments in that /8. There are lots of better examples in the "legacy /8" space, however I'm not sure "historical reasons" is a good rationale for current policy in an entirely different address space. > inet6num: 2001:07F8::/29 > inet6num: 2001:07FD::/32 > netname: K-rootserver-net-20030829 > descr: This assignment given to k-root.server.net > descr: maintained by the RIPE NCC > > --- (just for the Kroot server Infratsructure ????? is this an LIR) Because root name server addresses must be encoded into configurations of all caching servers on the Internet, I believe that they are very special and should be treated specially. Rgds, -drc From steve at blighty.com Fri Jun 22 14:10:09 2007 From: steve at blighty.com (Steve Atkins) Date: Fri, 22 Jun 2007 11:10:09 -0700 Subject: [ppml] on PPML? - was Re: How to get ... In-Reply-To: <467BF76C.3010202@spaghetti.zurich.ibm.com> References: <467BCF8B.4090308@spaghetti.zurich.ibm.com> <200706221451.l5MEpIQP012336@ns1.afrinic.net> <467BE9A1.80008@spaghetti.zurich.ibm.com> <467BEE48.6050108@spaghetti.zurich.ibm.com> <467BF76C.3010202@spaghetti.zurich.ibm.com> Message-ID: On Jun 22, 2007, at 9:23 AM, Jeroen Massar wrote: > > And in case you don't like me mailing, then simply block all mail from > jeroen at unfix.org, which is always nicely PGP signed, thus should be > very easy > to block in your MUA or even MTA. > If the ppml list admins could do this, it would be appreciated. Cheers, Steve From owen at delong.com Fri Jun 22 14:33:06 2007 From: owen at delong.com (Owen DeLong) Date: Fri, 22 Jun 2007 11:33:06 -0700 Subject: [ppml] on PPML? - was Re: How to get ... In-Reply-To: References: <467BCF8B.4090308@spaghetti.zurich.ibm.com> <200706221451.l5MEpIQP012336@ns1.afrinic.net> <467BE9A1.80008@spaghetti.zurich.ibm.com> <467BEE48.6050108@spaghetti.zurich.ibm.com> <467BF76C.3010202@spaghetti.zurich.ibm.com> Message-ID: On Jun 22, 2007, at 11:10 AM, Steve Atkins wrote: > > On Jun 22, 2007, at 9:23 AM, Jeroen Massar wrote: > >> >> And in case you don't like me mailing, then simply block all mail >> from >> jeroen at unfix.org, which is always nicely PGP signed, thus should be >> very easy >> to block in your MUA or even MTA. >> > > If the ppml list admins could do this, it would be appreciated. > > Cheers, > Steve Steve, While I find Jeroen annoying and some of his stuff posted to the list is somewhat off-topic for the list in my opinion, I do not think that he has done anything to warrant him being removed from the list. Owen From jordi.palet at consulintel.es Fri Jun 22 14:34:36 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 22 Jun 2007 20:34:36 +0200 Subject: [ppml] [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <84C1471F-22C0-4970-A939-835B6E9770CF@virtualized.org> Message-ID: Because in some regions the policies, that have been developed by the community say so. I don't agree with the existing definitions of critical infrastructures, but I respect the policies developed following the PDP. If we don't agree with that point, then we should propose policy changes thru the PDP, but not make a useless critic. It is just my opinion, of course. Regards, Jordi > De: David Conrad > Responder a: > Fecha: Fri, 22 Jun 2007 12:45:31 -0400 > Para: > CC: , RIPE Address Policy , APNIC > IPv6 , "IPv6 in Africa > " > Asunto: Re: [GLOBAL-V6] [ppml] How to get a IPv6 /32 the cheap way: go to > AFRINIC > > On Jun 22, 2007, at 11:17 AM, JORDI PALET MARTINEZ wrote: >> RIRs can be considered, and in fact they are, critical >> infrastructures, > > Why? > > Rgds, > -drc > > _______________________________________________ > global-v6 mailing list > global-v6 at lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/global-v6 ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From kloch at kl.net Fri Jun 22 14:58:52 2007 From: kloch at kl.net (Kevin Loch) Date: Fri, 22 Jun 2007 14:58:52 -0400 Subject: [ppml] [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <84C1471F-22C0-4970-A939-835B6E9770CF@virtualized.org> References: <84C1471F-22C0-4970-A939-835B6E9770CF@virtualized.org> Message-ID: <467C1BEC.2000402@kl.net> David Conrad wrote: > On Jun 22, 2007, at 11:17 AM, JORDI PALET MARTINEZ wrote: >> RIRs can be considered, and in fact they are, critical >> infrastructures, > > Why? > in-addr.arpa, ip6.arpa and probably more in the future if we ever get crypto authenticated/validated routing. To a lesser extent whois. For me it's just inconvenient when it is unavailable but the government(s) may have a different opinion about that. - Kevin From randy at psg.com Fri Jun 22 15:06:40 2007 From: randy at psg.com (Randy Bush) Date: Fri, 22 Jun 2007 09:06:40 -1000 Subject: [ppml] [address-policy-wg] Re: [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <003101c7b4f5$20f39510$62dabf30$@cx> References: <467BEA7B.1000608@spaghetti.zurich.ibm.com> <003101c7b4f5$20f39510$62dabf30$@cx> Message-ID: <467C1DC0.80801@psg.com> > As long as each entity only have a single prefix, the dfz should be > somewhat optimal. great idea! was one of the rationales for A, B, and C. oops. randy From drc at virtualized.org Fri Jun 22 15:13:48 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 22 Jun 2007 15:13:48 -0400 Subject: [ppml] [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467C1BEC.2000402@kl.net> References: <84C1471F-22C0-4970-A939-835B6E9770CF@virtualized.org> <467C1BEC.2000402@kl.net> Message-ID: <08F2ACD4-0AA7-4E91-BB58-6F9726B6294D@virtualized.org> Hi, On Jun 22, 2007, at 2:58 PM, Kevin Loch wrote: > David Conrad wrote: >> On Jun 22, 2007, at 11:17 AM, JORDI PALET MARTINEZ wrote: >>> RIRs can be considered, and in fact they are, critical >>> infrastructures, >> >> Why? >> > in-addr.arpa, ip6.arpa and probably more in the future if > we ever get crypto authenticated/validated routing. To a lesser > extent whois. Sorry, I was a bit obtuse. I was trying to imply that as far as I know, there is no formal definition of "critical infrastructure" that is applicable across all regions. As an aside, this would appear to be another case of confusion between allocation policy and routing policy... Rgds, -drc From jeroen at unfix.org Fri Jun 22 15:59:40 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 22 Jun 2007 20:59:40 +0100 Subject: [ppml] Where to get your address space (Was: on PPML? - was Re: How to get ...) In-Reply-To: <467C20E3.8020605@bogus.com> References: <467BCF8B.4090308@spaghetti.zurich.ibm.com> <200706221451.l5MEpIQP012336@ns1.afrinic.net> <467BE9A1.80008@spaghetti.zurich.ibm.com> <467BEE48.6050108@spaghetti.zurich.ibm.com> <467C20E3.8020605@bogus.com> Message-ID: <467C2A2C.5040609@spaghetti.zurich.ibm.com> Joel Jaeggli wrote: > Jeroen Massar wrote: [..] > Their head office is in India... Oops, in deed Teleglobe is VSNL, which is indeed in India :) Showing even more how this case is international as it covers a third RIR region. [..] > Teleglobe is a large ISP with an lir function and likely qualifies for a > /32 or larger under all current rir policy in all regions where they are > present which is probably all of them. Which is what I said, also why it is not problem at all that they got it as they would easily qualify for it and very likely use most chunks of it. The point that I wanted to make, which is clearly not seen, is that an organization can in effect pick their RIR and go to the RIR that actually caters for their needs irrespectively of their actual location or where the prefix will be really used. As such bypassing all the nice policies made on this list because in another RIR region other people decided on something different. In the RIPE region but need IPv6 "PI" space? Set up shop in the US, go to ARIN and get your prefix, presto done, happy smiley engineer folks. >> But still this shows that if a company wants, they could set up shop in Africa >> and use AfriNIC policies to get an assignment, thus bypassing the policies >> which are really in effect in the ARIN region. > > My employer has a /32 in the arin region are we wasting it? Most likely at the moment yes :) But in the long term most _ISPs_ and you most likely too, will use quite a bit of it. Trying to guess if you will be using exactly a /40 or a /36 or whatever is futile, a /32 is assumed to be a generic fit-most-ISPs size. This is good as it is equally divided and doesn't create a mess. A RIR is not an ISP though and they will never be one and as such they ARE wasting address space. Pushing their own request through their own system is the weird thing there though. [..] > The rirs are in the business of handing out address space to their > constituents. IPV4 has been a scare resource since 1992, possibly > earlier, ipv6 is not. IPv4 was not a scarce resource when it people started using it either. Look at it now. > Much of the current debate appears to focus on the scarcity of routing > slots rather than address space. and a larger allocations where at one > time perceived to produce benefits to topological aggregation. I personally can't care less about routing slots and neither should the RIRs. Clearly the RIR policies are indeed solely focused on routing slots while they should be about managing address space. IMHO this really has to change. > You may be of the opinion that a /48 is a hell of a lot of subnets. That is a lot for a single site yes. But when the requesting organization can demonstrate that it has a need for more address space and they can justify it then they should always be able to get more address space. That is what RIRs should be doing and nothing else. [..] > I read it as "Those crazy Africans are out of control" which I don't > believe to be the case. My experience with afrinic policy creation is > that it's at least as rational as the arin region, but you're entitled > to your own opinion. In this nice case there is no active policy to be found in that region which allows them to give themselves a /32. And considering that they can't justify more than 3 locations (thus 3 sites) and a 'few big projects', a /32 is really a lot of wasted address space. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From Lee.Howard at stanleyassociates.com Fri Jun 22 17:14:03 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 22 Jun 2007 17:14:03 -0400 Subject: [ppml] Where to get your address space (Was: on PPML? - was Re: How to get ...) In-Reply-To: <467C2A2C.5040609@spaghetti.zurich.ibm.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40631FE82@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Jeroen Massar > Sent: Friday, June 22, 2007 4:00 PM > To: Joel Jaeggli > Cc: ARIN Address Policy; Edward Lewis > Subject: [ppml] Where to get your address space (Was: on > PPML? - was Re: How to get ...) > > The point that I wanted to make, which is clearly not seen, is that an > organization can in effect pick their RIR and go to the RIR that actually > caters for their needs irrespectively of their actual location or where the > prefix will be really used. What policy change do you propose? Lee From randy at psg.com Fri Jun 22 17:24:07 2007 From: randy at psg.com (Randy Bush) Date: Fri, 22 Jun 2007 11:24:07 -1000 Subject: [ppml] Where to get your address space (Was: on PPML? - was Re: How to get ...) In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40631FE82@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40631FE82@CL-S-EX-1.stanleyassociates.com> Message-ID: <467C3DF7.1030001@psg.com> >> The point that I wanted to make, which is clearly not seen, is that >> an organization can in effect pick their RIR and go to the RIR that >> actually caters for their needs irrespectively of their actual >> location or where the prefix will be really used. > What policy change do you propose? i have this recurring nightmare where i go to the doctor with a really serious problem and she says "what policy changes do you propose?" perhaps all things are not best fixed by policy? see recent board decisions re crypto, for a current example. randy From jeroen at unfix.org Fri Jun 22 17:27:58 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 22 Jun 2007 22:27:58 +0100 Subject: [ppml] Where to get your address space (Was: on PPML? - was Re: How to get ...) In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40631FE82@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40631FE82@CL-S-EX-1.stanleyassociates.com> Message-ID: <467C3EDE.2070502@spaghetti.zurich.ibm.com> Howard, W. Lee wrote: > > Jeroen Massar wrote: >> The point that I wanted to make, which is clearly not seen, is that an >> organization can in effect pick their RIR and go to the RIR that actually >> caters for their needs irrespectively of their actual location or where the >> prefix will be really used. > > > What policy change do you propose? In ARIN land no policy changes are required IMHO. I can even say that the ARIN policies are currently the sanest of all the various RIRs, especially when looking at the prefixes being handed out and to what kind of organizations. A comment there might be that universities are getting /32's which is a lot of space, but those places might be providing connectivity to all their dorms and then a /32 is easily half filled sooner or later. Having them have a chunk of space that is 'more than enough for years to come' is then better than having them come back every year or so and having them gather multiple prefixes. Better in a sense of management and also routing for the short term. Only "complaint" about currenyl policies that I am aware of is that some very small networks (eg those who only have a IPv4 /24 or similar) would also like to have their own /48, but they currently do not qualify. As such the oly change that might be considered is maybe removing the distinction between "PA" and "PI", as it is all just address space, and neither of them should be broken up. But that is not to prevalent here anyway and it seems that, at least for the moment, folks are being nice and keeping their prefixes mostly aggregated, this might change though over time when folks want to perform traffic engineering. This then still is a routing issue, not an addressing issue, which is what the RIRs should be handling. Enforcing prefix sizes is something that ISPs can do, a RIR could maybe only say "please don't" nothing more. The problem that I brought to light is only that when a policy here might not be good enough for some situations, folks can go somewhere else and get it there by pushing policy through in that region where people are less conservative or less informed. And as AfriNIC suddenly seems to have a very open policy, that might be a way for some people to circumvent the policies that have been outlined here. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From Lee.Howard at stanleyassociates.com Fri Jun 22 17:58:00 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 22 Jun 2007 17:58:00 -0400 Subject: [ppml] Where to get your address space (Was: on PPML? - was Re: How to get ...) In-Reply-To: <467C3DF7.1030001@psg.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40631FE9E@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Friday, June 22, 2007 5:24 PM > To: Howard, W. Lee > Cc: PPML at arin.net > Subject: Re: [ppml] Where to get your address space (Was: on > PPML? - was Re: How to get ...) > > >> The point that I wanted to make, which is clearly not > seen, is that > >> an organization can in effect pick their RIR and go to the > RIR that > >> actually caters for their needs irrespectively of their actual > >> location or where the prefix will be really used. > > What policy change do you propose? > > i have this recurring nightmare where i go to the doctor with > a really serious problem and she says "what policy changes do > you propose?" > > perhaps all things are not best fixed by policy? see recent > board decisions re crypto, for a current example. That's a fair criticism. Funny, too. Maybe a better question is, "What should we do differently?" In this case, I think a coordinated policy among the RIRs would be required, but there could be other tools. Lee > > randy > From Lee.Howard at stanleyassociates.com Fri Jun 22 18:06:54 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 22 Jun 2007 18:06:54 -0400 Subject: [ppml] Where to get your address space (Was: on PPML? - was Re: How to get ...) In-Reply-To: <467C3EDE.2070502@spaghetti.zurich.ibm.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40631FEA1@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: Jeroen Massar [mailto:jeroen at unfix.org] > Sent: Friday, June 22, 2007 5:28 PM > To: Howard, W. Lee > Cc: PPML at arin.net > Subject: Re: [ppml] Where to get your address space (Was: on > PPML? - was Re: How to get ...) > > Howard, W. Lee wrote: > > Jeroen Massar wrote: > > What policy change do you propose? > > In ARIN land no policy changes are required IMHO. Excellent! yea, us! > As such the oly change that might be considered is maybe > removing the distinction between "PA" and "PI", as it is all > just address space, and neither of them should be broken up. "PA" means "Provider Aggregatable," as in, "Assigned from a provider's larger (aggregated) block." "PI" means "Provider Independent," as in, "Not aggregated, can be taken to other providers." [1] How do you remove the distinction? Inferring from the previous paragraphs. . . do you think all address assignments should be directly from the RIR? > The problem that I brought to light is only that when a > policy here might not be good enough for some situations, > folks can go somewhere else and get it there by pushing > policy through in that region where people are less > conservative or less informed. What should we do differently? > > Greets, > Jeroen [1] You probably know this, but I like to repeat it from time to time for people who are new to the conversation. From marla.azinger at frontiercorp.com Fri Jun 22 19:12:51 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Fri, 22 Jun 2007 19:12:51 -0400 Subject: [ppml] Notification for Change to ARIN AC Policy Review Process Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272F947@nyrofcs2ke2k01.corp.pvt> Hello ARIN Community- For the past 5 months the ARIN AC has been analyzing the internal workings of the AC Policy Review Process. We are happy to say we have now modified our internal process so that we will better serve all ARIN participants. The following change is effective immediately: *AC shepherds will now be assigned to a policy proposal 3 to 4 days (barring any unforeseeable circumstances) after it is initially posted to the PPML. (Old process had shepherd assigned after initial AC review was over) We believe this change will enable the AC to have better communication with the authors. *AC Shepherd is an AC member who has been appointed to oversee a proposal through the policy process and work with the authors in regards to the proposal to include guidance, revisions and obtaining feedback from the community. Shepherds provide status reports at AC meetings. If a policy author is unable to present the proposal at the Public Policy Meeting, a shepherd will present the proposal. There are normally 2 to 3 AC members appointed as shepherd per proposal. We thank everyone for their involvement and suggestions. Stay tuned...more good changes to come. Cheers! Marla Azinger AC Chair From Yves.Poppe at vsnlinternational.com Fri Jun 22 22:16:53 2007 From: Yves.Poppe at vsnlinternational.com (Yves Poppe) Date: Fri, 22 Jun 2007 22:16:53 -0400 Subject: [ppml] Where to get your address space (Was: on PPML? - was Re: How to get ...) In-Reply-To: <467C3EDE.2070502@spaghetti.zurich.ibm.com> Message-ID: Dear PPMLers, My interest was tweaked when Jeroen Massar first mentioned Teleglobe, now part of VSNL, when we wa trying to make a point about bypassing RIR policies and now implying lax policies of some RIR's. Without wanting to interfere in your sometimes spirited exchanges, I wish to offer some clarification. Our Teleglobe/VSNL AS6453 is a global network circling the globe and physically present with 200+ POP's in 35+ countries representing the various RIR regions. Consequently we indeed obtain local address blocks according to the specific policies of the various RIR's responsible for the respective regions where we serve customers and do business. The fallacy in Jeroen's reasoning was when he concluded earlier in the exchange: "But still this shows that if a company wants, they could set up shop in Africa and use AfriNIC policies to get an assignment, thus bypassing the policies which are really in effect in the ARIN region" and now still continues in the same vain by saying "And as AfriNIC suddenly seems to have a very open policy, that might be a way for some people to circumvent the policies that have been outlined here". As Adiel Akplogan mentioned in his intervention, anyone who applies for a block in any of the five RIR's has to provide the adequate justification. The systems works and I hope it continues to work. Yves Yves Poppe Director Business Development IP Services VSNL International tel: 1-514-8687248 cell: 1-514-8048162 fax: 1-514-8687033 e-mail: yves.poppe at vsnlinternational.com web: www.vsnlinternational.com -----Message d'origine----- De : ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]De la part de Jeroen Massar Envoy? : Friday, June 22, 2007 5:28 PM ? : Howard, W. Lee Cc : PPML at arin.net Objet : Re: [ppml] Where to get your address space (Was: on PPML? - was Re: How to get ...) Howard, W. Lee wrote: > > Jeroen Massar wrote: >> The point that I wanted to make, which is clearly not seen, is that an >> organization can in effect pick their RIR and go to the RIR that actually >> caters for their needs irrespectively of their actual location or where the >> prefix will be really used. > > > What policy change do you propose? In ARIN land no policy changes are required IMHO. I can even say that the ARIN policies are currently the sanest of all the various RIRs, especially when looking at the prefixes being handed out and to what kind of organizations. A comment there might be that universities are getting /32's which is a lot of space, but those places might be providing connectivity to all their dorms and then a /32 is easily half filled sooner or later. Having them have a chunk of space that is 'more than enough for years to come' is then better than having them come back every year or so and having them gather multiple prefixes. Better in a sense of management and also routing for the short term. Only "complaint" about currenyl policies that I am aware of is that some very small networks (eg those who only have a IPv4 /24 or similar) would also like to have their own /48, but they currently do not qualify. As such the oly change that might be considered is maybe removing the distinction between "PA" and "PI", as it is all just address space, and neither of them should be broken up. But that is not to prevalent here anyway and it seems that, at least for the moment, folks are being nice and keeping their prefixes mostly aggregated, this might change though over time when folks want to perform traffic engineering. This then still is a routing issue, not an addressing issue, which is what the RIRs should be handling. Enforcing prefix sizes is something that ISPs can do, a RIR could maybe only say "please don't" nothing more. The problem that I brought to light is only that when a policy here might not be good enough for some situations, folks can go somewhere else and get it there by pushing policy through in that region where people are less conservative or less informed. Greets, Jeroen From bmanning at vacation.karoshi.com Sat Jun 23 08:41:53 2007 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 23 Jun 2007 12:41:53 +0000 Subject: [ppml] [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <467BEA7B.1000608@spaghetti.zurich.ibm.com> References: <467BEA7B.1000608@spaghetti.zurich.ibm.com> Message-ID: <20070623124153.GA25412@vacation.karoshi.com.> On Fri, Jun 22, 2007 at 04:27:55PM +0100, Jeroen Massar wrote: > > According to your analogy, anybody should be getting IPv4 /24 or IPv6 /32's > simply because they have 1 box somewhere and they are afraid of being filtered. > > That is not how justification of address space works. If it does work that way > today, then it definitely has to be changed ASAP. > > Greets, > Jeroen Jeroen, You have your mission then. Since RIR policies are set regionally, BY THEIR MEMBERS and not globally, you can affect change by going to each RIR and persuading their members to support your policy proposals. When/If you can get concensus by ALL the RIRs on a given suite of policy, Then you get a global policy. See how easy it is? > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From jcurran at istaff.org Sat Jun 23 09:40:34 2007 From: jcurran at istaff.org (John Curran) Date: Sat, 23 Jun 2007 09:40:34 -0400 Subject: [ppml] Where to get your address space In-Reply-To: <467C3DF7.1030001@psg.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40631FE82@CL-S-EX-1.stanleyassociates.com> <467C3DF7.1030001@psg.com> Message-ID: At 11:24 AM -1000 6/22/07, Randy Bush wrote: > >> The point that I wanted to make, which is clearly not seen, is that >>> an organization can in effect pick their RIR and go to the RIR that >>> actually caters for their needs irrespectively of their actual >>> location or where the prefix will be really used. >> What policy change do you propose? > >i have this recurring nightmare where i go to the doctor with a really >serious problem and she says "what policy changes do you propose?" Yep, me too... Apparently, an undocumented side effect from serving on the ARIN Board. Think of it as an strange honorarium of sorts for your past participation. ;-) /John p.s. Recently, my doc's been adding: "and please be quick, this particular office is closing shortly... " From randy at psg.com Sat Jun 23 13:08:18 2007 From: randy at psg.com (Randy Bush) Date: Sat, 23 Jun 2007 07:08:18 -1000 Subject: [ppml] Where to get your address space In-Reply-To: References: <369EB04A0951824ABE7D8BAC67AF9BB40631FE82@CL-S-EX-1.stanleyassociates.com> <467C3DF7.1030001@psg.com> Message-ID: <467D5382.3090501@psg.com> John Curran wrote: > At 11:24 AM -1000 6/22/07, Randy Bush wrote: >>>> The point that I wanted to make, which is clearly not seen, is that >>>> an organization can in effect pick their RIR and go to the RIR that >>>> actually caters for their needs irrespectively of their actual >>>> location or where the prefix will be really used. >>> What policy change do you propose? >> i have this recurring nightmare where i go to the doctor with a really >> serious problem and she says "what policy changes do you propose?" > Yep, me too... Apparently, an undocumented side effect from serving on > the ARIN Board. Think of it as an strange honorarium of sorts for your > past participation. semi-humor aside, there is an underlying problem here. while we pride ourselves on bottom-up, member driven, blah blah, what we sometimes end up with is network constraint/design by not just one committee, but five or more very large committees, some of which are dominated by folk who have never seen a router. we were aware of this when designing arin, hence the existence of the ac and a process with board approval for policies. this is somewhat lacking in other communities, and hence the swings are wider and perhaps less well aimed. and, as the arin ac and board are put in place by popularity contests, we can get some pretty loose cannons. perhaps inter-rir coordination of policies which affect global routing etc. would put a bit more damping in the system. this might not be a bug. the net does seem to kinda work; perhaps i have just forgotten those policies which were so urgent that they needed immediate change. randy From bicknell at ufp.org Sat Jun 23 13:14:26 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 23 Jun 2007 13:14:26 -0400 Subject: [ppml] RIR Shopping, Table Growth x5? Message-ID: <20070623171426.GA22425@ussenterprise.ufp.org> The recent flair up on AfriNIC reminded me of an issue I thought was worth discussion several weeks ago. One of the things we're trying to do when crafting IPv6 policy is look into the crystal ball to see what we think the future holds. I, and others, look for a fairly optimistic future where most entities get enough address space that we approach 1 prefix per ASN. If you're a global company though, it would seem the current policies in all of the regions lead us down a path to 5 prefixes per ASN. That is, each company would get a prefix from each RIR. The question is, with IPv6 is this a good thing? That's a very loaded question of course, and the answer may depend a bit on the structure of the company (single global ASN, multiple ASN's, single corporate structure, multiple affiliates) and has implications on mergers and divestitures down the road. Should RIR's consider in more detail what has been allocated by other RIR's? Is IPv6 different from IPv4 in that respect? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From randy at psg.com Sun Jun 24 21:57:51 2007 From: randy at psg.com (Randy Bush) Date: Sun, 24 Jun 2007 15:57:51 -1000 Subject: [ppml] [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: References: <84C1471F-22C0-4970-A939-835B6E9770CF@virtualized.org> Message-ID: <467F211F.8040203@psg.com> we all think we're critical, john. the original point was root servers, as their ip addresses are hard coded in jillions of systems around the solar system. from there, it has been the typical slippery slope. now folk think their grandma is critically ill and needs a /32. entropic social effect. when design is by committee, eventually everything turns into crap. randy From paul at vix.com Tue Jun 26 01:19:34 2007 From: paul at vix.com (Paul Vixie) Date: Tue, 26 Jun 2007 05:19:34 +0000 Subject: [ppml] Paul Vixie: Re: draft-ietf-ipv6-ula-central-02.txt use cases Message-ID: <77505.1182835174@sa.vix.com> another ipv6 at ietf.org snapshot for those of you not following it in person: -------------- next part -------------- An embedded message was scrubbed... From: Paul Vixie Subject: Re: draft-ietf-ipv6-ula-central-02.txt use cases Date: Tue, 26 Jun 2007 05:12:56 +0000 Size: 8253 URL: From randy at psg.com Tue Jun 26 01:28:18 2007 From: randy at psg.com (Randy Bush) Date: Mon, 25 Jun 2007 22:28:18 -0700 Subject: [ppml] Paul Vixie: Re: draft-ietf-ipv6-ula-central-02.txt use cases In-Reply-To: <77505.1182835174@sa.vix.com> References: <77505.1182835174@sa.vix.com> Message-ID: <4680A3F2.2070504@psg.com> > Re: draft-ietf-ipv6-ula-central-02.txt use cases > From: Paul Vixie > Date: Tue, 26 Jun 2007 05:12:56 +0000 > To: IETF IPv6 Mailing List > To: IETF IPv6 Mailing List > > >> Apparently people are still having a hard time visualizing use cases for >> ULA-C, so let me try again to lay one out: sure be nice to know to whom you were responding. and they might like the recognition for there words, despite your (and i) disagreeing with them. randy From sleibrand at internap.com Tue Jun 26 13:55:08 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 26 Jun 2007 13:55:08 -0400 (EDT) Subject: [ppml] Paul Vixie: Re: draft-ietf-ipv6-ula-central-02.txt use cases In-Reply-To: <4680A3F2.2070504@psg.com> References: <77505.1182835174@sa.vix.com> <4680A3F2.2070504@psg.com> Message-ID: Randy, Paul's reasoned and thoughtful response was quoting my message, which is included below. I'll Cc: ppml when I've had a chance to draft a reply, as we're starting to discuss the similarities and differences between ULA-C and a possible new kind of private PI. -Scott On 06/25/07 at 7:39pm -0700, Scott Leibrand wrote: > > Date: Mon, 25 Jun 2007 19:39:51 -0700 > From: Scott Leibrand > Cc: IETF IPv6 Mailing List > Subject: Re: draft-ietf-ipv6-ula-central-02.txt use cases > > Apparently people are still having a hard time visualizing use cases for ULA-C, so let me try again > to lay one out: > > Let's say I build a somewhat ad-hoc wireless mesh network covering a residential area to provide > Internet service. For my Internet connectivity, I get service from several different ISPs, each of > which gives me an IPv6 subnet (PA space). As this is a wireless network based on inexpensive > hardware often deployed in a residential setting (and possibly involves some mobility), I can't > count on any portion of my network to maintain reachability to any particular ISP uplink. In > addition, I am likely to change ISPs over time, and I'm too small to qualify for PI space, so I > choose to number my internal network infrastructure out of private (ULA) space. In parallel, I also > use DHCP, DHCP-PD, etc. to assign subnets of my various PA space to users on various portions of my > network (thereby giving them IPv6 address(es) of whichever Internet uplinks are available to them). > (I may also use some form of DHCP to assign PA space to my router interfaces, or I may choose to > hide that detail by doing my mesh networking below layer 3, or I may choose to use ULA space there > and rewrite the source address of any ULA-sourced packets leaving my network for the Internet.) > > Now let's say I am thinking a little bit bigger than just my neighborhood, and would also like my > network to connect to neighboring mesh networks. (This could fairly easily evolve into an > arbitrarily large internetwork enabling disaster-resistant connectivity across neighborhoods, > cities, or entire regions.) In order to facilitate troubleshooting, I elect to use ULA-C space for > my network infrastructure, including router interfaces, (and either rewrite source addresses of any > packets (presumably ICMP) my routers send out to the Internet, or also assign PA space to each > interface with something like DHCP-PD, so that the router can use IPv6 address selection to use a > public address for packets destined for public Internet addresses). As before, I would give out PA > subnet(s) to users for Internet connectivity, but I might also elect to give them ULA addresses to > communicate with other hosts on my mesh network and neighboring ones. > > In a situation like this, I need to be able to resolve PTRs for hosts using my neighboring networks' > ULA space without any prior knowledge about the neighboring wireless network. If both networks are > numbered out of ULA-C space, this is easy: I send my PTR queries to my regular DNS resolver, which > has a PA address and Internet connectivity, and can resolve the PTR from the DNS server > authoritative for my neighboring wireless network's ULA-C block. > > So, again, I see that ULA-C is a very simple solution to fill a very useful function that cannot be > filled by local ULAs alone (at least without adding additional complexity to DNS). Importantly, > this functionality does not depend on ULA-C providing an additional assurance of uniqueness, but on > the fact that my block (and its authoritative DNS servers) can be registered, and others can query > the registered data. > > As IPv6 adoption takes hold and dynamic wireless networking becomes cheaper and more widespread, I > would see this kind of use case, and its many permutations, becoming more and more common. Can you > describe a way to use existing address types available to small networks (PA and ULA-L) and existing > DNS technologies to support the requirements listed above? If not, I would argue that we should > complete the process of ULA-C standardization, as it represents the simplest available solution to > the problem. > > > -Scott > On 06/25/07 at 10:28pm -0700, Randy Bush wrote: >> Re: draft-ietf-ipv6-ula-central-02.txt use cases >> From: Paul Vixie >> Date: Tue, 26 Jun 2007 05:12:56 +0000 >> To: IETF IPv6 Mailing List >> To: IETF IPv6 Mailing List >> >> >>> Apparently people are still having a hard time visualizing use cases for >>> ULA-C, so let me try again to lay one out: > > sure be nice to know to whom you were responding. and they might like > the recognition for there words, despite your (and i) disagreeing with them. > > randy > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From Ed.Lewis at neustar.biz Tue Jun 26 14:06:50 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 26 Jun 2007 14:06:50 -0400 Subject: [ppml] MX NIR announcement Message-ID: From this: http://www.nic.mx/es/Noticias_2?NEWS=220 #As of 1/1/11, all the new IP addresses will be allocated on IPv6 # #Monterrey, Mexico, June 21th, 2007. - According to forecasts of some #investigators, in the next three years the central pool of Internet #Protocol addresses of the present version 4, IPv4 will be depleted, so from #January 1st, of 2011, NIC Mexico will not be able to allocate anymore IPv4 #addresses and will only assign IP addresses in version 6 of the Internet #Protocol (IPv6). We should get to see a real world reaction to setting an end date. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. From arin-contact at dirtside.com Tue Jun 26 16:03:43 2007 From: arin-contact at dirtside.com (William Herrin) Date: Tue, 26 Jun 2007 16:03:43 -0400 Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration Incentive Address Space Message-ID: <3c3e3fca0706261303s74d39ccqed8f591727a90cee@mail.gmail.com> Hi Folks, I've prepared a policy proposal I hope to submit to ARIN entitled "IPv4 to IPv6 Migration Incentive Address Space." Through preemptively assigning IPv6 addresses to IPv4 holders, it seeks to address three problems ARIN faces: 1. The looming exhaustion of the IPv4 space. 2. Obsolete and incorrect legacy IPv4 registration and contact information. 3. Legacy IPv4 registrants don't pay their fair share. The current draft of the proposal is at: http://bill.herrin.us/arin-policy-proposal.html If you're willing, please read through it. I'd very much like to hear: a. Would you vote Yea or Nay? and b. How would you improve the proposal? Thanks in advance, Bill Herrin Note: Resent with from address that's actually subscribed to ppml. If the prior one slips through, my apologies for sending it twice. -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From owen at delong.com Tue Jun 26 16:54:15 2007 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Jun 2007 13:54:15 -0700 Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration Incentive Address Space In-Reply-To: <3c3e3fca0706261303s74d39ccqed8f591727a90cee@mail.gmail.com> References: <3c3e3fca0706261303s74d39ccqed8f591727a90cee@mail.gmail.com> Message-ID: <4DFB8EA6-97A3-4E57-9ED1-C8CB2CCB6CEC@delong.com> In response to your email: Preemptively assigning space is a horribly bad idea. People who want space should apply for it and I would welcome proposals that make that process easier, especially for existing IPv4 holders. However, I will _NOT_ support any policy which proposes automatically creating unused assignments. It's just not a good idea. 1. This isn't a problem, just the next step in the evolution of the internet. It's not like IPv4 stops working when we run out of free space, we just stop being able to easily add more networks. 2. This is a problem, but, ARIN policy alone will never address it. The real solution is to simply allow it to die its natural death when IPv4 goes away as a result of overwhelming migration to IPv6. This will take several years, but, so would any meaningful solution to this stated problem, so, I think our efforts are best focused on proper and thorough IPv6 deployment instead. 3. This is a Red Herring and should be dropped. The reality is that most legacy IPv4 registrants are end-users. Do you really think that collecting $100/year from each of them is vital to ARIN or meaningful to the community? ARIN has no business relationship with these people and no standing to force them into one. In response to your actual policy proposal: I would vote NEA. First paragraph and table: This is just a bad idea altogether as stated above. This alone is enough to force a NEA vote from me. If you want to change this to ARIN shall upon request issue the following assignments to existing ARIN IPv4 recipients and/or legacy address space holders in the ARIN region: IPv4 total holdings IPv6 prefix received /22-/32 /48 or /64 at requester's discretion /8-/22 /32 /1-/8 Appropriate space determined by ARIN staff Since no single body has more than 1/2 the total IPv4 space, I don't believe a criteria for /0 is necessary. Your original table shows a fundamental misunderstanding of IPv6 prefix sizes. The intent and design of IPv6 (for better or worse) is that a single network is always a /64. An organization with more than one network gets at least a /48. An LIR which is issuing prefixes to other organizations recieves a /32 (essentially any ISP). Now for your numbered proposal paragraphs: 1. Again, bad idea... See above. 2. Bad idea... See above. 3. Bad idea... See above. Very bad idea... Giving additional space to legacy holders without contacting them and verifying that they even still exist is just plain dumb. Why bring the mistakes made in the early v4 days forward into IPv6? 4. There's no reason whatsoever to tie these things together and produce an automatic map. The RIRs are perfectly capable of issuing appropriate blocks in response to applications submitted by the existing address holders. There is no benefit to defining this "migration space" and pushing it off into some random portion of the IPv6 space that gets split up all over the globe instead of having these allocations come from the appropriate RIR blocks to begin with. Owen On Jun 26, 2007, at 1:03 PM, William Herrin wrote: > Hi Folks, > > I've prepared a policy proposal I hope to submit to ARIN entitled > "IPv4 to IPv6 Migration Incentive Address Space." Through preemptively > assigning IPv6 addresses to IPv4 holders, it seeks to address three > problems ARIN faces: > > 1. The looming exhaustion of the IPv4 space. > 2. Obsolete and incorrect legacy IPv4 registration and contact > information. > 3. Legacy IPv4 registrants don't pay their fair share. > > The current draft of the proposal is at: > > http://bill.herrin.us/arin-policy-proposal.html > > If you're willing, please read through it. I'd very much like to hear: > a. Would you vote Yea or Nay? and b. How would you improve the > proposal? > > Thanks in advance, > Bill Herrin > > Note: Resent with from address that's actually subscribed to ppml. If > the prior one slips through, my apologies for sending it twice. > > -- > William D. Herrin herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. Web: > Falls Church, VA 22042-3004 > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml From sleibrand at internap.com Tue Jun 26 17:13:29 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 26 Jun 2007 14:13:29 -0700 Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration Incentive Address Space In-Reply-To: <3c3e3fca0706261303s74d39ccqed8f591727a90cee@mail.gmail.com> References: <3c3e3fca0706261303s74d39ccqed8f591727a90cee@mail.gmail.com> Message-ID: <46818179.3000000@internap.com> William, A couple of critiques of this proposal, which may prevent it from gaining consensus: * Anyone with an IPv4 assignment from ARIN can request an IPv6 assignment under existing policy, and they will likely receive it with no trouble whatsoever. (We just requested ours, and it was remarkably easy, since we didn't have to justify the size of our allocation like we do for IPv4.) * While reservation of a /32 is trivial space-wise, reservation of that many distinct IPv6 netblocks, with the expectation that they can all be routed, will accelerate routing table growth. To put some numbers around the issue, there are some 220,000 routes in the IPv4 routing table today, but only some 40,000 ASNs allocated (much less actively announcing routes). Many of those routes come from the way RIRs have had to incrementally give out additional space as needed, such that announcements cannot be aggregated. (You alluded to this in the case of Verizon, but the problem is also present to varying degrees for any small network that has grown enough to require additional assignments.) The current IPv6 assignment policies resolve this issue by giving networks a much larger netblock than they initially need, thereby reducing the number of routes that need to be announced in IPv6 to be much closer to one per ASN. If we were to accept announcement of a /56 for every /24 of IPv4 space, we would give up much of that gain. * Many of the benefits you site of algorithmically mapping IPv4 space into IPv6 space might be compelling if we were planning on turning off IPv4 support any time soon. But since the IPv4 Internet will continue to function (just stop growing for the most part), those benefits seem less compelling. In short, I'm skeptical that a scheme like this would be helpful, mostly because existing IPv6 allocation and assignment policies do a much better job than IPv4 policies did of helping constrain routing table growth, and also because existing IPv6 policies already make it easy for IPv4 holders to get IPv6 space (usually with zero additional cost). I think we've done most everything we can to make it easy for IPv4 holders to get IPv6 space. I think what's needed now is for network operators to do the grunt work of actually testing and deploying IPv6 in their respective environments. -Scott William Herrin wrote: > Hi Folks, > > I've prepared a policy proposal I hope to submit to ARIN entitled > "IPv4 to IPv6 Migration Incentive Address Space." Through preemptively > assigning IPv6 addresses to IPv4 holders, it seeks to address three > problems ARIN faces: > > 1. The looming exhaustion of the IPv4 space. > 2. Obsolete and incorrect legacy IPv4 registration and contact information. > 3. Legacy IPv4 registrants don't pay their fair share. > > The current draft of the proposal is at: > > http://bill.herrin.us/arin-policy-proposal.html > > If you're willing, please read through it. I'd very much like to hear: > a. Would you vote Yea or Nay? and b. How would you improve the > proposal? > > Thanks in advance, > Bill Herrin > > Note: Resent with from address that's actually subscribed to ppml. If > the prior one slips through, my apologies for sending it twice. > > From tony at lava.net Tue Jun 26 18:16:23 2007 From: tony at lava.net (Antonio Querubin) Date: Tue, 26 Jun 2007 12:16:23 -1000 (HST) Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration Incentive Address Space In-Reply-To: <3c3e3fca0706261303s74d39ccqed8f591727a90cee@mail.gmail.com> References: <3c3e3fca0706261303s74d39ccqed8f591727a90cee@mail.gmail.com> Message-ID: On Tue, 26 Jun 2007, William Herrin wrote: > Hi Folks, > > I've prepared a policy proposal I hope to submit to ARIN entitled > "IPv4 to IPv6 Migration Incentive Address Space." Through preemptively > assigning IPv6 addresses to IPv4 holders, it seeks to address three > problems ARIN faces: > > 1. The looming exhaustion of the IPv4 space. > 2. Obsolete and incorrect legacy IPv4 registration and contact information. > 3. Legacy IPv4 registrants don't pay their fair share. > > The current draft of the proposal is at: > > http://bill.herrin.us/arin-policy-proposal.html I'd vote nay. As a transition mechanism this isn't too different than 6to4 which is already available to every IPv4 address holder. From sleibrand at internap.com Tue Jun 26 20:38:17 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 26 Jun 2007 17:38:17 -0700 Subject: [ppml] draft-ietf-ipv6-ula-central-02.txt use cases In-Reply-To: <77167.1182834776@sa.vix.com> References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com> <77167.1182834776@sa.vix.com> Message-ID: <4681B179.2020301@internap.com> Paul Vixie wrote: >> Apparently people are still having a hard time visualizing use cases for >> ULA-C, so let me try again to lay one out: >> ... >> > > thanks. > And thank you for your thoughtful and reasoned response. >> So, again, I see that ULA-C is a very simple solution to fill a very useful >> function that cannot be filled by local ULAs alone (at least without adding >> additional complexity to DNS). Importantly, this functionality does not >> depend on ULA-C providing an additional assurance of uniqueness, but on the >> fact that my block (and its authoritative DNS servers) can be registered, >> and others can query the registered data. >> > > if you want registration, then you want a new kind of RIR PI space, since it > has to be unique, and the registration data has to be made and kept accurate. > Yeah, to me that's what ULA-C should be, a block of space defined by the IETF, delegated by IANA to the RIRs, and administered as "unique local" or "private PI" space. I don't care whether we call it ULA-C and allocate it out of FC00, or if we call it private PI and chose a different subnet. > >> ... >> Now let's say I am thinking a little bit bigger than just my neighborhood, >> and would also like my network to connect to neighboring mesh networks. >> > > i like this vision, it matches my own. > > >> In order to facilitate troubleshooting, I elect to use ULA-C space for my >> network infrastructure, including router interfaces, (and either rewrite >> source addresses of any packets (presumably ICMP) my routers send out to the >> Internet, or also assign PA space to each interface with something like >> DHCP-PD, so that the router can use IPv6 address selection to use a public >> address for packets destined for public Internet addresses). >> > > i was almost going to snort beer out my nose at how funny that was, until the > millisecond when i realized that you didn't know it was funny to say "in order > to facilitate troubleshooting" and then follow with that description of rube > goldbergesque complexity. why did you leave out the part where the anvil that > had been launched a few moments earlier finally, inevitably, lands on the > coyote's midriff? > > but we (both) digress from the real point: > I'm not sure which aspects of what I outline you would consider unnecessarily complex, but I agree that is tangential to our discussion, so we can follow that up offline if you like. > >> In a situation like this, I need to be able to resolve PTRs for hosts using >> my neighboring networks' ULA space without any prior knowledge about the >> neighboring wireless network. >> > > which wouldn't be nec'y if both of these networks were in some new kind of PI > space that was allocated out of a prefix designated by IANA for non-DFZ use. > (i keep bringing the discussion back to that point because asking IANA to > designate such a prefix ought to be the IETF's reaction to the ULA-C draft.) > > but i still digress, let's get to the meat of it: > I'm not sure this is a digression. What you're describing is exactly what I think ULA-C should be: a well-known block (that DFZ operators would filter announcements from) from which PI assignments can be made without the restrictions required on public PI space to avoid routing table bloat. > >> If both networks are numbered out of ULA-C space, this is easy: I send my >> PTR queries to my regular DNS resolver, which has a PA address and Internet >> connectivity, and can resolve the PTR from the DNS server authoritative for >> my neighboring wireless network's ULA-C block. >> > > here you're equating, dangerously in my opinion, three unrelated concepts: > > 1. "public internet" > 2. "PA address" > 3. "internet connectivity" > > please re-think this in terms of "connectivity realms", of which the DFZ is > one, and the american automotive exchange is another, and every fortune-2000 > internal network is another, and every ad-hoc wireless mesh is another. in > these terms, you'd have successfully pointed out that a given host may be in > more than one connectivity realm, and that it's impossible to know in advance > whether a network peer you reach in realm A can reach the same realm B that > you can reach. now take it one step further -- stop according the DFZ any > special status, treat it as just another connectivity realm to which any > given network peer of yours may or may not have access. > While I agree with this analysis in the abstract, and would not opposed a private PI policy based on it (as it would likely be quite robust), I'm not sure that we can simply see the public Internet as just another connectivity realm. I believe that the history of the Internet, and the architecture we have built up to support it (particularly the addressing architecture, as defined by the IETF and delegated from IANA to the RIRs to ISPs and to end sites), require that we consider the public Internet to be a unique connectivity realm. > >> Can you describe a way to use existing address types available to small >> networks (PA and ULA-L) and existing DNS technologies to support the >> requirements listed above? If not, I would argue that we should complete >> the process of ULA-C standardization, as it represents the simplest >> available solution to the problem. >> > > i see ULA-C as a giant rubber band and some rocket powered roller skates > which will finally, really, we mean it this time, allow the coyote to catch > that darn roadrunner. > > the simpler solution is to recognize the following primary facts of reality: > > 1. every host needs a lan-scoped address > Link-local. Done. > 2. most hosts also need one or more global-scoped addresses > 3. each of those global-scoped addresses will be in some connectivity realm > Agreed. > 4. many of those connectivity realms will transitively, invisibly, overlap > 5. the DFZ or "public internet" isn't special, it's just a connectivity realm > 6. of all connectivity realms, the DFZ may not always be the largest one > Perhaps not, especially depending on your definition of "largest". However, any connectivity realm that approaches the public Internet in terms of the number and diversity of interconnected participants will require an addressing and routing framework to meet the various needs of its different participants in a mutually acceptable manner. As long as we're talking about IPv6, that addressing framework will need to coexist with the addressing framework of the public Internet. Given the current Internet addressing architecture, that means we need some way to partition off part of the IPv6 address space, designate it as "not to be routed in the DFZ", and assign pieces of that space to anyone wishing to internetwork in a connectivity realm other than the DFZ. > 7. all global-scoped addresses need ongoing reliable DNS and WHOIS support > 8. address DNS/WHOIS support is traditionally a regional, bottom-up function > Agreed, which is why I advocate that ULA-C space (or whatever we end up calling the space that fills the needs described above) be assigned to Regional Internet Registries (RIRs), who can then assign it to end users and provide appropriate DNS and WHOIS support. I would also support allowing the RIRs to allocate such non-DFZ-routed space to Local Internet Registries (LIRs), so that they can serve their members/customers by reassigning such space and providing DNS and/or WHOIS services in a method (and possibly a connectivity realm) not served by the RIRs directly. > if we can get agreement on those, then the resulting conclusions are easy. > Given our slightly differing opinions on the special significance of the "public Internet" connectivity realm, I would love to hear what conclusions you draw based on the above points. I would draw the following conclusions: * There is a need to allocate and assign IPv6 address space, in a non-restrictive manner, to entities wishing to internetwork outside of the public Internet's DFZ. * There is a need to provide reliable DNS and WHOIS support for these addresses. The methods of providing such DNS support should include, but should not be limited to, allowing registrants to delegate DNS authority to servers reachable from the public Internet. Other methods for providing reliable DNS support for these addresses should be explored, but no method should be allowed which imposes an undue burden on Internet DNS infrastructure. -Scott From andrew.dul at quark.net Tue Jun 26 20:37:55 2007 From: andrew.dul at quark.net (Andrew Dul) Date: Tue, 26 Jun 2007 17:37:55 -0700 Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration Incentive AddressSpace In-Reply-To: <3c3e3fca0706261303s74d39ccqed8f591727a90cee@mail.gmail.com > Message-ID: <20070627010340.ED16B1444F1@smtp2.arin.net> At 04:03 PM 6/26/2007 -0400, William Herrin wrote: >Hi Folks, > >I've prepared a policy proposal I hope to submit to ARIN entitled >"IPv4 to IPv6 Migration Incentive Address Space." Through preemptively >assigning IPv6 addresses to IPv4 holders, it seeks to address three >problems ARIN faces: > >1. The looming exhaustion of the IPv4 space. >2. Obsolete and incorrect legacy IPv4 registration and contact information. >3. Legacy IPv4 registrants don't pay their fair share. > >The current draft of the proposal is at: > >http://bill.herrin.us/arin-policy-proposal.html > I do not support this policy proposal. I do not think automatically assigning address space to existing IPv4 resource holders will actually create an incentive to use IPv6. I believe that IPv6 space is available to existing IPv4 holders under the current policies. Regards, Andrew From william at elan.net Tue Jun 26 22:13:45 2007 From: william at elan.net (william(at)elan.net) Date: Tue, 26 Jun 2007 19:13:45 -0700 (PDT) Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration Incentive AddressSpace In-Reply-To: <20070627010340.ED16B1444F1@smtp2.arin.net> References: <20070627010340.ED16B1444F1@smtp2.arin.net> Message-ID: On Tue, 26 Jun 2007, Andrew Dul wrote: > At 04:03 PM 6/26/2007 -0400, William Herrin wrote: >> Hi Folks, >> >> I've prepared a policy proposal I hope to submit to ARIN entitled >> "IPv4 to IPv6 Migration Incentive Address Space." Through preemptively >> assigning IPv6 addresses to IPv4 holders, it seeks to address three >> problems ARIN faces: >> >> 1. The looming exhaustion of the IPv4 space. >> 2. Obsolete and incorrect legacy IPv4 registration and contact information. >> 3. Legacy IPv4 registrants don't pay their fair share. >> >> The current draft of the proposal is at: >> >> http://bill.herrin.us/arin-policy-proposal.html >> > > I do not support this policy proposal. I do not think automatically > assigning address space to existing IPv4 resource holders will actually > create an incentive to use IPv6. I believe that IPv6 space is available > to existing IPv4 holders under the current policies. I do not support that proposal either. But I'd like to mention that availability of ipv6 to existing ipv4 holders is not the same as incentive to start using it and to migrate - and we do need something in this area. Perhaps what should be discussed are those willing to go all the way and to fully transition and give up part or all of their ipv4 space replacing that with v6. What kind of incentive to give those willing to do it is interesting question, perhaps if its one of the legacy holders they could be given free ride (no maintenance fees) for additional say 10 years; what incentive to give to ISPs willing to do it is another issue, again perhaps some discount to normal fees could generate interest and ARIN can probably do it easily considering existing budgetary surplus. -- William Leibzon Elan Networks william at elan.net From william at elan.net Tue Jun 26 22:15:51 2007 From: william at elan.net (william(at)elan.net) Date: Tue, 26 Jun 2007 19:15:51 -0700 (PDT) Subject: [ppml] MX NIR announcement In-Reply-To: References: Message-ID: On Tue, 26 Jun 2007, Edward Lewis wrote: > From this: > > http://www.nic.mx/es/Noticias_2?NEWS=220 > > #As of 1/1/11, all the new IP addresses will be allocated on IPv6 > # > #Monterrey, Mexico, June 21th, 2007. - According to forecasts of some > #investigators, in the next three years the central pool of Internet > #Protocol addresses of the present version 4, IPv4 will be depleted, so from > #January 1st, of 2011, NIC Mexico will not be able to allocate anymore IPv4 > #addresses and will only assign IP addresses in version 6 of the Internet > #Protocol (IPv6). > > We should get to see a real world reaction to setting an end date. You mean like Mexican companies opening branches in US in anticipation, so they could get ip addresses from ARIN when this goes in effect? Its not going to work properly unless all RIRs do this together! -- William Leibzon Elan Networks william at elan.net From arin-contact at dirtside.com Tue Jun 26 23:50:44 2007 From: arin-contact at dirtside.com (William Herrin) Date: Tue, 26 Jun 2007 23:50:44 -0400 Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration Incentive Address Space In-Reply-To: <46818179.3000000@internap.com> References: <3c3e3fca0706261303s74d39ccqed8f591727a90cee@mail.gmail.com> <46818179.3000000@internap.com> Message-ID: <3c3e3fca0706262050o8c9accl7139ca4e75e94d2c@mail.gmail.com> On 6/26/07, Scott Leibrand wrote: > A couple of critiques of this proposal, which may prevent it from > gaining consensus: Thanks Scott, I appreciate the comments. > * Anyone with an IPv4 assignment from ARIN can request an IPv6 > assignment under existing policy, and they will likely receive it > with no trouble whatsoever. (We just requested ours, and it was > remarkably easy, since we didn't have to justify the size of our > allocation like we do for IPv4.) I agree. Yet IPv6 uptake increases at a pace which won't meet the 10% deployment mark before IPv4 exhaustion. Three years from now, that will be a real problem for Internap. You sell a high value service with cleverly optimized routes. Without IPv6 in place, no more IPv4 addresses means no new customers despite your technology. Cogent gets them instead because this week Cogent is the one with spare IP addresses. Next week it'll be someone else, Level 3 maybe, but not you. You're stuck until a customer leaves and forfeits his IP addresses. That's why I've proposed an -Incentive- space, not merely a migration space. We have maybe three years to get IPv6 to a point where dialup users, dsl users and folks with wifi laptops at Starbucks receive IPv6 addresses automatically alongside the IPv4 addresses. That's three years to get IPv6 in the hands of the end users and every network admin in the path from us to them. If we can't bring Mohammad to the mountain, maybe its in our interest for the mountain to make a trip. > * While reservation of a /32 is trivial space-wise, reservation of > that many distinct IPv6 netblocks, with the expectation that they > can all be routed, will accelerate routing table growth. I think that's a legitimate concern that deserves investigation. In the worst case scenario, 100% of the organizations who announce IPv4 space would announce all of the IPv6 blocks they receive under this proposal. Since IPv6 addresses are 4 times the size of IPv4 addresses, that would increase the memory demand on routers by a factor of 4. A factor of 5 if you consider that they also have to maintain the IPv4 table. That yields two questions: 1. Is anything approaching the worst case scenario a plausible outcome, and 2. What would be the impact of such an increase? The impact of the worst case scenario is nasty but survivable. Some folks are still running on 256 mb routers. That dies. So do 512mb routers and 1 gb becomes tight. On the other hand, servers come with 8 gb these days and expand to 32 gb without too much difficulty or cost. That has inverted from the early days when your cx-rp1 had 64mb and your sparc web server had 32. Granted this is an oversimplification: routers have multiple processors and multiple task-specific sets of memory. Nevertheless, its reasonable to expect that router vendors could make an 8-factor jump in routing table capacity in the next generation of products without unduly increasing the cost. So the next question is: is it real? I don't think so. I'd need more data (and maybe the folks at ARIN can help out here) but I suspect that something on the order of 75% of the route slots are filled by 5% of the organizations. I'll bet that the much of the same 5% will prefer a single contiguous block of IPv6 space and will neither need nor choose to claim the space under this proposal. Does anyone have hard numbers on how many discontiguous v4 allocations are held by the top 1%, 5% and 10% of ARIN registrants? Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From arin-contact at dirtside.com Wed Jun 27 00:14:30 2007 From: arin-contact at dirtside.com (William Herrin) Date: Wed, 27 Jun 2007 00:14:30 -0400 Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration Incentive AddressSpace In-Reply-To: References: <20070627010340.ED16B1444F1@smtp2.arin.net> Message-ID: <3c3e3fca0706262114u559dcb95scd08b277bc5ad9bd@mail.gmail.com> On 6/26/07, william(at)elan.net wrote: > I'd like to mention that > availability of ipv6 to existing ipv4 holders is not the same as > incentive to start using it and to migrate - and we do need something > in this area. Hi William, You're darn right we do. The problem is, ARIN has only three posessions it -can- offer as incentives. 1. Discounts on the fees 2. IP addresses 3. T-shirts and baubles ARIN has already discounted the fees to zero. It improved the IPv6 uptake rate, but not enough. "I saved the Internet" T-shirts might be fun way to reward IPv6 registrants but I don't see a gimmick filling the gap. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From stephen at sprunk.org Wed Jun 27 00:48:05 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 26 Jun 2007 23:48:05 -0500 Subject: [ppml] draft-ietf-ipv6-ula-central-02.txt use cases References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com><77167.1182834776@sa.vix.com> <4681B179.2020301@internap.com> Message-ID: <024b01c7b876$94b06b70$443816ac@atlanta.polycom.com> Thus spake "Scott Leibrand" >> which wouldn't be nec'y if both of these networks were in some >> new kind of PI space that was allocated out of a prefix designated >> by IANA for non-DFZ use. (i keep bringing the discussion back >> to that point because asking IANA to designate such a prefix >> ought to be the IETF's reaction to the ULA-C draft.) >> >> but i still digress, let's get to the meat of it: > > I'm not sure this is a digression. What you're describing is > exactly what I think ULA-C should be: a well-known block (that > DFZ operators would filter announcements from) from which PI > assignments can be made without the restrictions required on > public PI space to avoid routing table bloat. If this is what we mean by "private PI", then I'm against that too. Dressing up ULA-C with a different prefix and name but retaining all of the operational stupidity doesn't solve any problems. A turd by any other name smells just as foul. If we want to issue address space to folks for "private" use, it needs to be out of the same block(s) that the RIRs use to allocate space for "public" use, because sooner or later those "private" networks are going to end up being publicly routed. If we are concerned that giving "real" PI space to every org that asks for it will result in the immediate death of the DFZ, then there needs to be some sort of tag attached to blocks that says whether or not the registrant has met whatever the current rules are for deserving a routing slot. If routing certificates ever take off, they could contain a flag that gives the current public routability status, or the RIR could just not issue a certificate at all if someone hasn't met the bar. That's an entirely separate matter from whether or not they get addresses. One could also argue that the RIRs do not belong in the routability decision path at all, since their job is to ensure uniqueness, and some other quasi-public entity responsible for the health of the DFZ would produce "routability" certificates. That also gives rise to the possibility of different models than we have today, like a market where people could buy and sell routing slots. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From william at elan.net Wed Jun 27 02:42:08 2007 From: william at elan.net (william(at)elan.net) Date: Tue, 26 Jun 2007 23:42:08 -0700 (PDT) Subject: [ppml] FYI - Afrinic ratifies IPv6 PI policy Message-ID: ---------- Forwarded message ---------- Date: Wed, 27 Jun 2007 08:35:44 +0400 From: Hisham R Rojoa Reply-To: contact at afrinic.net To: announce at afrinic.net, rpd at afrinic.net, afripv6 at afrinic.net Subject: [AfriNIC-announce] Implementation of IPv6 PI Assignment for End Sites Dear Colleagues and Members We would like to inform you that the AfriNIC board has ratified the policy afpol-v6200701 (IPv6 Provider Independent Assignment for End Sites) on the 13th June 2007. We will be implementing this policy as from the 6th of July 2007. More information regarding this policy can be found at http://www.afrinic.net/docs/policies/afpol-v6200701.htm. Best Regards Hisham R. Rojoa AfriNIC _______________________________________________ announce mailing list announce at afrinic.net https://lists.afrinic.net/mailman/listinfo.cgi/announce From heldal at eml.cc Wed Jun 27 07:54:33 2007 From: heldal at eml.cc (Per Heldal) Date: Wed, 27 Jun 2007 13:54:33 +0200 Subject: [ppml] draft-ietf-ipv6-ula-central-02.txt use cases In-Reply-To: <024b01c7b876$94b06b70$443816ac@atlanta.polycom.com> References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com><77167.1182834776@sa.vix.com> <4681B179.2020301@internap.com> <024b01c7b876$94b06b70$443816ac@atlanta.polycom.com> Message-ID: <1182945273.21026.97.camel@localhost.localdomain> On Tue, 2007-06-26 at 23:48 -0500, Stephen Sprunk wrote: > If we want to issue address space to folks for "private" use, it needs to be > out of the same block(s) that the RIRs use to allocate space for "public" > use, because sooner or later those "private" networks are going to end up > being publicly routed. But if we do this shouldn't we also take steps to prevent abuse (hijacking etc) of those "private" blocks. History has shown that unannounced PI-blocks that nobody is missing can be abused for a long time before anybody cries foul. We may have made a hash of v4, but shouldn't have to make the same mistake from the start with v6. Maybe RIRs should announce "private" or otherwise "quarantined" blocks from a special AS so that they can easily be identified and filtered ... although they'd end up wasting space in the DFZ (whatever that is;). ... which is closely related to the following: > > If we are concerned that giving "real" PI space to every org that asks for > it will result in the immediate death of the DFZ, then there needs to be > some sort of tag attached to blocks that says whether or not the registrant > has met whatever the current rules are for deserving a routing slot. If > routing certificates ever take off, they could contain a flag that gives the > current public routability status, or the RIR could just not issue a > certificate at all if someone hasn't met the bar. That's an entirely > separate matter from whether or not they get addresses. Until there's a reliable mechanism to verify the origin of a prefix all we can do is try to cope through policies. Is the lack of route-certificates an excuse to not try to do something about the problem in the meantime? > > One could also argue that the RIRs do not belong in the routability decision > path at all, since their job is to ensure uniqueness, and some other > quasi-public entity responsible for the health of the DFZ would produce > "routability" certificates. That also gives rise to the possibility of > different models than we have today, like a market where people could buy > and sell routing slots. Isn't that like calling for a "global internet constitution"? What about a mechanism to establish some form of "common ground" on which routing-policy-decisions can be made. To "navigate" the world of routing an allocation-policies today is like navigating an aircraft without the ability to adjust the altimeter for varying air-pressure. There are too many inconsistent and independent sources of information with widely varying quality and formats. Things would be easier if inter-domain-routers were required to form a relation to address-registries for all network-domains in which they wish to operate (normally ARIN + RIRs + possibly private) in addition to whatever routing policies each operator choose to implement (in reality they already do but the quality that information tend to vary a lot with operator clue). Registries would then have to announce the allocation policies (blocks and prefix-lengths) through standardised formats and mechanisms/protocols available globally. Address-space that is not covered by a policy would by definition be unused (hence the need for separate bogon-filtering and the related debogonizing-issues would be mostly eliminated). Combine this with: - A strong recommendation from address registries to announce aggregates for optimum visibility/routability (note: _recommendation_ not _requirement_). In reality this is just a formalisation of current practise. - Standards which must require IDR implementations to never drop aggregates even if the available set of more-specifics cover the entire block specified by the allocation policy. A 3rd party might choose to ignore the smaller blocks and would loose "visibility" without the aggregate. (note: path selection algorithms based on longest-prefix-match would not be affected). (- Maybe even a BGP node should be able to tell its peer(s) that it doesn't want to receive routes more specific than allocation policies. Although it might be hard to ensure that different ASes conform to the same allocation policies.) With such a thing in place one would at least have a fair chance of knowing how local routing-policy decisions might affect routability. Now you can safely ignore TE-churn from distant networks while choosing to accept more specifics from peers and others in your "neighbourhood" and still feel reasonably confident that you're not loosing anything important. In a better world that has route-certificates and unlimited IDR-scalability this makes no sense, but will we get there in time to avoid trouble. //per From jordi.palet at consulintel.es Wed Jun 27 09:29:42 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 27 Jun 2007 09:29:42 -0400 Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration Incentive Address Space In-Reply-To: <3c3e3fca0706261303s74d39ccqed8f591727a90cee@mail.gmail.com> Message-ID: Hi, In principle, I don't support this proposal, no need to repeat what has been said already. Also, I will suggest, if the proposal is submitted, to replace migration with transition, coexistence, integration, or a combination of all them, but definitively not migration. This is something that has been discussed already in many foras. With IPv6 we aren't breaking IPv4, and migration has this connotation, we just add IPv6 support on existing IPv4 infrastructures. It is true that in the long term IPv4 may disappear, but it is a different history and very long term widely speaking. We should make sure that the people don't get the wrong idea, despite journalist and PR folks still insisting on migration. When I do training, frequently explain this point, and people still ask when you talk about migration "so I disable IPv4", which is wrong, at least in local area networks at the time being. Regards, Jordi > De: William Herrin > Responder a: > Fecha: Tue, 26 Jun 2007 16:03:43 -0400 > Para: > Asunto: [ppml] Solicing comments: IPv4 to IPv6 Migration Incentive Address > Space > > Hi Folks, > > I've prepared a policy proposal I hope to submit to ARIN entitled > "IPv4 to IPv6 Migration Incentive Address Space." Through preemptively > assigning IPv6 addresses to IPv4 holders, it seeks to address three > problems ARIN faces: > > 1. The looming exhaustion of the IPv4 space. > 2. Obsolete and incorrect legacy IPv4 registration and contact information. > 3. Legacy IPv4 registrants don't pay their fair share. > > The current draft of the proposal is at: > > http://bill.herrin.us/arin-policy-proposal.html > > If you're willing, please read through it. I'd very much like to hear: > a. Would you vote Yea or Nay? and b. How would you improve the > proposal? > > Thanks in advance, > Bill Herrin > > Note: Resent with from address that's actually subscribed to ppml. If > the prior one slips through, my apologies for sending it twice. > > -- > William D. Herrin herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. Web: > Falls Church, VA 22042-3004 > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From Ed.Lewis at neustar.biz Wed Jun 27 09:54:20 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 27 Jun 2007 09:54:20 -0400 Subject: [ppml] MX NIR announcement In-Reply-To: References: Message-ID: At 19:15 -0700 6/26/07, william(at)elan.net wrote: >You mean like Mexican companies opening branches in US in anticipation, so >they could get ip addresses from ARIN when this goes in effect? Let's see if it happens. Yes, it's a possibility, but reality matters more. >Its not going to work properly unless all RIRs do this together! That's a prediction. It's better to work based on conclusions. I don't mean to pick on the post...we do work more about what might happen on this list rather than what is happening. I'm guilty of that. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. From Lee.Howard at stanleyassociates.com Wed Jun 27 09:58:06 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 27 Jun 2007 09:58:06 -0400 Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration IncentiveAddress Space In-Reply-To: <3c3e3fca0706262050o8c9accl7139ca4e75e94d2c@mail.gmail.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4063A2B2E@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of William Herrin > Sent: Tuesday, June 26, 2007 11:51 PM > To: Scott Leibrand > Cc: ppml at arin.net > Subject: Re: [ppml] Solicing comments: IPv4 to IPv6 Migration > IncentiveAddress Space > > * While reservation of a /32 is trivial space-wise, > reservation of > > that many distinct IPv6 netblocks, with the > expectation that they > > can all be routed, will accelerate routing table growth. > > Since IPv6 > addresses are 4 times the size of IPv4 addresses, that would > increase the memory demand on routers by a factor of 4. A > factor of 5 if you consider that they also have to maintain > the IPv4 table. "2 to the 64th power" is significantly more than "4 times (2 to the 32nd power)." There are roughly 4 billion addresses in IPv4. There are roughly 18 quintillion subnets in IPv6. 18,000,000,000,000,000,000 > 4*4,000,000,000 Regarding upper limits on the routing table: * Assuming one and only one contiguous assignment per entity, and assuming each entity announces only their aggregate, then if multihoming were not a requirement for a direct assignment, the 65,000 ASNs is not an upper limit; in fact, the upper limit is bound by available prefixes. * These are questionable assumptions. * CPU is at least as constraining as memory. Lee From jeroen at unfix.org Wed Jun 27 10:17:41 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 27 Jun 2007 15:17:41 +0100 Subject: [ppml] [GLOBAL-V6] [afripv6-discuss] Re: How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <025101c7b4fe$3df99c50$ec1afea9@ipv6forum> References: <467BDA31.4030607@spaghetti.zurich.ibm.com><467BEE69.60906@inex.ie> <467BF422.7030901@spaghetti.zurich.ibm.com> <025101c7b4fe$3df99c50$ec1afea9@ipv6forum> Message-ID: <46827185.2010801@spaghetti.zurich.ibm.com> Latif LADID ("The New Internet based on IPv6") wrote: > Joeren, > > To be fair, start your rant also about those that got /13 and those that got > /19 :-) I've not seen a /13 in the routing tables nor in the allocation tables yet. Where did this occur? A /13 would be 34.359.738.368 /48's, I don't know of any ISP currently actively providing residential access in all countries on this planet and then about 5 of those planets. The /19's you mention are for France Telecom and Deutsche Telekom, both clearly where able to justify to the RIR that they needed 536.870.912 /48's, based on HD ratio and home countries respectively having 64 and 83 million inhabitants with most likely added plan of providing the rest of Europe with connectivity too, is not too far fetched. With only the home countries in mind a /21 would have sufficed, but that doesn't cover the HD ratio. Now if there was a /56 policy for home-end-users then it would surely have been way too much, but with the current HD policy it isn't. There are several other such "large" prefixes, but they all are allocated to ISP's who have been around for a long time and are providing connectivity to a large amount of users in a similar way as the above two ISP's. But a single /32 for a ~5 person organization quickly grabbing it before their own PI policy becomes in effect is a bit strange don't you think. And no "we have 3 offices and a few big projects" is far from correct justification. As such, sneaking in a /32 from under their own policies is a waste of address space. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From jeroen at unfix.org Wed Jun 27 10:25:46 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 27 Jun 2007 15:25:46 +0100 Subject: [ppml] Critical or not and at what size (Was: How to get a IPv6 /32 the cheap way: go to AFRINIC) In-Reply-To: <467BF308.3070708@bugest.net> References: <467BCF8B.4090308@spaghetti.zurich.ibm.com> <467BF308.3070708@bugest.net> Message-ID: <4682736A.7050708@spaghetti.zurich.ibm.com> Kosuke Ito wrote: > Please read carefully about the section of Critical Infrastructure. > > AfriNIC is eligible to have a /32 by the policy. How exactly is a RIR more "Critical" to the Internet than Google, YouTube, MySpace or whatever site somebody uses daily? I understand if one would state "A RIR is critical as it provides service X", but then the RIR itself is not the critical infra, it is that service. RIPE itself doesn't have a /32 nor a /48, they are using a /48 that they have from an ISP out of PA space. K.ROOT *does* fall under critical infra though, and that has, according to that policy a prefix. If one states "but they have a DNS server", then how does that make my DNS server not critical? Especially a DNS server by for instance Akamai powering hunderds of well used domains? [..APNIC policy..] > The maximum assignment made under these terms is /32 per operator. And this is the important portion of that part: "The maximum". That doesn't mean that if you can't justify it that you per default should be getting a /32. The default should be a /48, and more if one can justify it. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From jeroen at unfix.org Wed Jun 27 10:51:15 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 27 Jun 2007 15:51:15 +0100 Subject: [ppml] [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC In-Reply-To: <200706221451.l5MEpIQP012336@ns1.afrinic.net> References: <467BCF8B.4090308@spaghetti.zurich.ibm.com> <200706221451.l5MEpIQP012336@ns1.afrinic.net> Message-ID: <46827963.4070801@spaghetti.zurich.ibm.com> Adiel A. Akplogan wrote: [..] >> Wow, so you make a new 'company' in 911 land and say "I am going to >> allocate a >> single /48" and you get a FULL /32 even when you will never ever ever >> use it >> or even are going to think about using it? > > I think you have missed the point a) which says "be an LIR". So you must > already be an LIR (and go through the LIR setup process) to get IPv6 > allocation from AfrINIC. Is it that difficult to become an LIR then? Last time I checked it simply means having a registered company in a country and paying the bills. For the rest, nothing policy wise will stop one from becoming one. >> The first "organization" which is using this to waste space seems to be: >> >> inet6num: 2001:42d0::/32 >> netname: AfriNIC-IPv6-1 >> descr: AfriNIC >> descr: RIR >> country: MU >> >> Gee, the RIR itself. How many people are using the AFRINIC network? >> 10-50? Are >> they really *ever* going to need more than a /48? Are they ever going >> to have >> a need for 65536 of those /48's? > > You can not take AfriNIC own allocation case to illustrate your > assertion here Why not? It is clearly the first block that has been using this policy. Some other people mentioned that you might have been using the "Critical Infrastructure" policy, but clearly you are not, otherwise you would have mentioned that, but you did not. Also even that policy mentions that a /32 is the maximum size and not the default, meaning that one still has to justify that address space. > We have allocated that bloc to our own Infrastructure (which has three > locations to be connected together) so each with its own /48. > Further to that we have other IPv6 Internal projects which will > probably require several /48. So you allocate 65536 /48's because you have *three* offices and maybe some "big projects". I don't see why those big projects require the need for individual /48's. Reminder: a /48 is 65536 /64's and in total that contains several millions of /128's to be used for addressing. Under that premise, is every website hosted by a virtual hoster also getting their own /48? That will be a huge waste of address space when you justify it like that. I sincerely hope that that is not the justification that AfriNIC is using, as when that is the case it is really disproportionate to the rest of the world. > As RIR I think we are in the position to evaluate our own need > before making an allocation and if it was made be sure that is > after careful evaluation. I wonder how 'careful' this evaluation was and I am seriously doubting any further 'evaluation'. Seeing that three (small) offices and some unspecified projects A /45 (8 /48's) would have been correctly justified by the above, but a /32 (65536 /48's) is really not. That you want a globally routable prefix and your own chunk of space is fine, but don't waste (not waist) the address space. >> Really this is just a waste of address space. Yes there is "enough", >> but being> sooo obviously wasteful just to be able to have a nice >> slot in the routing tables is a bit over done. > > I don't see the waist. You don't see a waste of 65500 /48's which can otherwise really be used by the new PI policy which your membership has voted on and setup? wow. Why does that PI policy exist when one is going to give out /32's for small sites anyway? And yes AfriNIC is a small site. Now if you had more than 200 offices and thousands of employees or what about real customers who are people and users themselves, then a /32 might be justified, but in this case, far from. [..] >> RIR's should be giving out address space based on "need" and that need >> must justified, giving out /32's as "those fit in the routing slots" is >> a really really bad idea. > > That is what we do. You can not have such affirmation based on a single > case. Thus you admit that the justification was wrong, but just because you made a mistake once (which you can still easily turn back btw as the prefix is not in use yet, or just chunk it down to a /45) it can't really be called a mistake? >> In short: if you want a nice /32 without issues: setup a small shop in >> Africa and presto! > > You won't get it like that. Clearly you can, otherwise that /32 you have now would not be there would it not? Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From arin-contact at dirtside.com Wed Jun 27 10:55:07 2007 From: arin-contact at dirtside.com (William Herrin) Date: Wed, 27 Jun 2007 10:55:07 -0400 Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration IncentiveAddress Space In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4063A2B2E@CL-S-EX-1.stanleyassociates.com> References: <3c3e3fca0706262050o8c9accl7139ca4e75e94d2c@mail.gmail.com> <369EB04A0951824ABE7D8BAC67AF9BB4063A2B2E@CL-S-EX-1.stanleyassociates.com> Message-ID: <3c3e3fca0706270755w41fe2bf8s3dd012bf4c0d617c@mail.gmail.com> On 6/27/07, Howard, W. Lee wrote: > > Since IPv6 > > addresses are 4 times the size of IPv4 addresses, that would > > increase the memory demand on routers by a factor of 4. A > > factor of 5 if you consider that they also have to maintain > > the IPv4 table. > > "2 to the 64th power" is significantly more than > "4 times (2 to the 32nd power)." > There are roughly 4 billion addresses in IPv4. > There are roughly 18 quintillion subnets in IPv6. > > 18,000,000,000,000,000,000 > 4*4,000,000,000 Howard, The question was: how would this proposal impact the routing table. In the worst case scenario, this proposal would place the same number of routes in the IPv6 table that are presently in the IPv4 table: roughly 220,000. The amount of memory necessary to list every possible subnet in IPv6 is not at issue and not relevant to the discussion. On the other hand, my math was in error. Because the IPv6 subnet size is fixed at /64 by the standard, routers need never consider or store the last 8 bytes of the route. Accordingly, the IPv6 route table in the worst case scenario need only consume twice the memory of the IPv4 table, not 4 times as much. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From jeroen at unfix.org Wed Jun 27 11:03:52 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 27 Jun 2007 16:03:52 +0100 Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration IncentiveAddress Space In-Reply-To: <3c3e3fca0706270755w41fe2bf8s3dd012bf4c0d617c@mail.gmail.com> References: <3c3e3fca0706262050o8c9accl7139ca4e75e94d2c@mail.gmail.com> <369EB04A0951824ABE7D8BAC67AF9BB4063A2B2E@CL-S-EX-1.stanleyassociates.com> <3c3e3fca0706270755w41fe2bf8s3dd012bf4c0d617c@mail.gmail.com> Message-ID: <46827C58.4050404@spaghetti.zurich.ibm.com> [I also *FAR* from like this proposed proposal, if folks want IPv6 let them get it from the RIR, it is there they just need to ask for it] William Herrin wrote: [..] > The question was: how would this proposal impact the routing table. In > the worst case scenario, this proposal would place the same number of > routes in the IPv6 table that are presently in the IPv4 table: roughly > 220,000. No, you are looking at it from the wrong way. At the moment there are about 40k active ASN's who indeed announce about 200k IPv4 routes. In IPv6 there are about 1000 prefixes (of which ~800 good ones) in the IPv6 tables, with about 800 ASN's announcing them. That is a ~13% overhead. Thus if every internet-active ASN would announce a single prefix + the overhead you would get 40k + 13.3% is only ~55k prefixes. But we have ASN32 nowadays so that can explode up to 4 million ;) > The amount of memory necessary to list every possible subnet in IPv6 > is not at issue and not relevant to the discussion. > > On the other hand, my math was in error. Because the IPv6 subnet size > is fixed at /64 by the standard, routers need never consider or store > the last 8 bytes of the route. Accordingly, the IPv6 route table in > the worst case scenario need only consume twice the memory of the IPv4 > table, not 4 times as much. You are wrong again though, routers need to handle the FULL 128bits. And fortunately currently they still do that. It might be one day though that routers might have a fast-path handling only the first 48 bits and a slow path for handling the rest. Currently that is not the case and the IPv6 RFC's also state that hardware and software must route on the FULL 128bits. How they do that is their problem of course. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From jeroen at unfix.org Wed Jun 27 11:26:29 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 27 Jun 2007 16:26:29 +0100 Subject: [ppml] RIR Shopping, Table Growth x5? In-Reply-To: <20070623171426.GA22425@ussenterprise.ufp.org> References: <20070623171426.GA22425@ussenterprise.ufp.org> Message-ID: <468281A5.8050804@spaghetti.zurich.ibm.com> Leo Bicknell wrote: [..] > If you're a global company though, it would seem the current policies > in all of the regions lead us down a path to 5 prefixes per ASN. > That is, each company would get a prefix from each RIR. The problem with having 1 prefix globally is that you might get the following scenario (not an issue if you have great connectivity worldwide of course like most transit providers hopefully have*): Big Office in Beijing, 10GE Small Office in New York, 100mbit Small Office in Amsterdam, 100mbit Now actually most of your clients (lets say you made the new cool YouTube incarnation and doing loads of traffic) are in the US and Europe, but your actual hardware is mostly in Beijing. This will result you into having to either: - announce your /32 in all three locations => and thus having to backhaul all that traffic to Beijing yourself which might just clog up your 100mbit link and the 10GE is never used ('locally announcing BGP' might help a wee bit) - announcing the /32 only in Beijing => Having to backhaul 200mbit, with extra latency. - splitting the /32 into a /33 (Beijing) and two /34's (NY+Ams) => avoiding the above problems totally As the first situation is totally undesired, you will end up in having 3 prefixes for this company anyway. As such, if that company decided to justify a /48 from ARIN for NY, a /48 from RIPE for Ams and a /40 for Beijing it has exactly the same effect, except that the prefixes are separate and they have to configure 3 lines in their firewall instead of one global well defined prefix. > The question is, with IPv6 is this a good thing? That's a very > loaded question of course, and the answer may depend a bit on the > structure of the company (single global ASN, multiple ASN's, single > corporate structure, multiple affiliates) and has implications on > mergers and divestitures down the road. The real answer probably lies in a solution like id/loc or shim6 etc. Having ISP's with PA prefixes in the core and having the 'more specifics' and 'PI prefixes' using such a mechanism that doesn't fill up the DFZ. By keeping separate blocks for PI prefixes and also special sizes >/32 these can at one day in the future easily be weeded out. > Should RIR's consider in more detail what has been allocated by other > RIR's? Is IPv6 different from IPv4 in that respect? No, I don't think that has to be done. Though at the part where the requester justifies the address space, they should only either justify the requirements for address space in the requesting region, when going for multiple prefixes, or globally/multi-region when doing that. Greets, Jeroen * = though, for instance (!random example grabbing!) UUNET/MCI has already received about 8 /32's for different purposes globally. The space is easily justified by them and each /32 only covers a country, but I would not be surprised that they did this simply because of the above described problem: keeping traffic local. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From arin-contact at dirtside.com Wed Jun 27 11:49:59 2007 From: arin-contact at dirtside.com (William Herrin) Date: Wed, 27 Jun 2007 11:49:59 -0400 Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration IncentiveAddress Space In-Reply-To: <46827C58.4050404@spaghetti.zurich.ibm.com> References: <3c3e3fca0706262050o8c9accl7139ca4e75e94d2c@mail.gmail.com> <369EB04A0951824ABE7D8BAC67AF9BB4063A2B2E@CL-S-EX-1.stanleyassociates.com> <3c3e3fca0706270755w41fe2bf8s3dd012bf4c0d617c@mail.gmail.com> <46827C58.4050404@spaghetti.zurich.ibm.com> Message-ID: <3c3e3fca0706270849n3e493f1cg1096998db8cf9f8b@mail.gmail.com> On 6/27/07, Jeroen Massar wrote: > William Herrin wrote: > > The question was: how would this proposal impact the routing table. In > > the worst case scenario, this proposal would place the same number of > > routes in the IPv6 table that are presently in the IPv4 table: roughly > > 220,000. > > No, you are looking at it from the wrong way. At the moment there are > about 40k active ASN's who indeed announce about 200k IPv4 routes. > In IPv6 there are about 1000 prefixes (of which ~800 good ones) in the > IPv6 tables, with about 800 ASN's announcing them. That is a ~13% > overhead. Thus if every internet-active ASN would announce a single > prefix + the overhead you would get 40k + 13.3% is only ~55k prefixes. Jeroen, That sounds like its closer to the best case scenario: every IPv4 org deploys IPv6 but the orgs with large numbers of v4 allocations choose not to claim them under this proposal and get single allocations through the regular process instead. > You are wrong again though, routers need to handle the FULL 128bits. And > fortunately currently they still do that. Okay. Then my original numbers for the worst case stand: each IPv6 route slot takes roughly 4 times the memory of the IPv4 route slots and the worst case is that we have the same number of them as we do IPv4 slots. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From Lee.Howard at stanleyassociates.com Wed Jun 27 12:57:41 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 27 Jun 2007 12:57:41 -0400 Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration IncentiveAddress Space In-Reply-To: <3c3e3fca0706270755w41fe2bf8s3dd012bf4c0d617c@mail.gmail.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4063A2D9E@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf > Of William Herrin > Sent: Wednesday, June 27, 2007 10:55 AM > To: Howard, W. Lee > Cc: Scott Leibrand; ppml at arin.net > Subject: Re: [ppml] Solicing comments: IPv4 to IPv6 Migration > IncentiveAddress Space > > On 6/27/07, Howard, W. Lee wrote: > > > Since IPv6 > > > addresses are 4 times the size of IPv4 addresses, that would > > > increase the memory demand on routers by a factor of 4. A > factor of > > > 5 if you consider that they also have to maintain the IPv4 table. > > > > "2 to the 64th power" is significantly more than > > "4 times (2 to the 32nd power)." > > There are roughly 4 billion addresses in IPv4. > > There are roughly 18 quintillion subnets in IPv6. > > > > 18,000,000,000,000,000,000 > 4*4,000,000,000 > > The question was: how would this proposal impact the routing > table. In the worst case scenario, this proposal would place > the same number of routes in the IPv6 table that are > presently in the IPv4 table: roughly 220,000. Only if: - everyone who will be connected is already connected, - everyone who will have a prefix already has a prefix, - every prefix that has been assigned or allocated is announced. These may be true enough that debating them doesn't matter, but your math wasn't clear to me. Also, I note Jeroen's correction: with 32-bit ASNs, there are a possible 4 billion multihomed sites, each typically announcing at least one prefix on two paths. Lee From bicknell at ufp.org Wed Jun 27 13:08:36 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 27 Jun 2007 13:08:36 -0400 Subject: [ppml] RIR Shopping, Table Growth x5? In-Reply-To: <468281A5.8050804@spaghetti.zurich.ibm.com> References: <20070623171426.GA22425@ussenterprise.ufp.org> <468281A5.8050804@spaghetti.zurich.ibm.com> Message-ID: <20070627170836.GA15316@ussenterprise.ufp.org> In a message written on Wed, Jun 27, 2007 at 04:26:29PM +0100, Jeroen Massar wrote: > * = though, for instance (!random example grabbing!) UUNET/MCI has > already received about 8 /32's for different purposes globally. The > space is easily justified by them and each /32 only covers a country, > but I would not be surprised that they did this simply because of the > above described problem: keeping traffic local. I guess that's the question though. If a company can get 8 /32's around the world, should our allocation policies somehow allow them to get a /29 they can subdivide into /32's from a single RIR, and then nothing from others? That preserves the ability to aggregate, while the current scheme of getting them from multiple RIR's at different times does not. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From bicknell at ufp.org Wed Jun 27 13:20:46 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 27 Jun 2007 13:20:46 -0400 Subject: [ppml] draft-ietf-ipv6-ula-central-02.txt use cases In-Reply-To: <4681B179.2020301@internap.com> References: <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com> <77167.1182834776@sa.vix.com> <4681B179.2020301@internap.com> Message-ID: <20070627172046.GB15316@ussenterprise.ufp.org> In a message written on Tue, Jun 26, 2007 at 05:38:17PM -0700, Scott Leibrand wrote: > Yeah, to me that's what ULA-C should be, a block of space defined by the > IETF, delegated by IANA to the RIRs, and administered as "unique local" > or "private PI" space. I don't care whether we call it ULA-C and > allocate it out of FC00, or if we call it private PI and chose a > different subnet. I would like to suggest the term "Provider Unroutable" space. PU for short. It keeps with the PI/PA pattern. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From mksmith at adhost.com Wed Jun 27 13:32:05 2007 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 27 Jun 2007 10:32:05 -0700 Subject: [ppml] RIR Shopping, Table Growth x5? In-Reply-To: <20070627170836.GA15316@ussenterprise.ufp.org> References: <20070623171426.GA22425@ussenterprise.ufp.org><468281A5.8050804@spaghetti.zurich.ibm.com> <20070627170836.GA15316@ussenterprise.ufp.org> Message-ID: <17838240D9A5544AAA5FF95F8D520316022AC096@ad-exh01.adhost.lan> > > In a message written on Wed, Jun 27, 2007 at 04:26:29PM +0100, Jeroen > Massar wrote: > > * = though, for instance (!random example grabbing!) UUNET/MCI has > > already received about 8 /32's for different purposes globally. The > > space is easily justified by them and each /32 only covers a country, > > but I would not be surprised that they did this simply because of the > > above described problem: keeping traffic local. > > I guess that's the question though. If a company can get 8 /32's > around the world, should our allocation policies somehow allow them to > get a /29 they can subdivide into /32's from a single RIR, and then > nothing from others? That preserves the ability to aggregate, while > the current scheme of getting them from multiple RIR's at different > times does not. > Wouldn't that require all traffic to be routed via the connection(s) in the geographic region of the assigning RIR? That seems like a fairly drastic limitation to connectivity for the sake of route aggregation. I would think geographic aggregation regardless of where the company above has its offices would make more sense. So, their Chinese office would aggregate into the "Chinese Block" and the US office would be aggregated into the "US Block" and so on. Regards, Michael K. Smith From drc at virtualized.org Wed Jun 27 13:32:39 2007 From: drc at virtualized.org (David Conrad) Date: Wed, 27 Jun 2007 13:32:39 -0400 Subject: [ppml] RIR Shopping, Table Growth x5? In-Reply-To: <20070627170836.GA15316@ussenterprise.ufp.org> References: <20070623171426.GA22425@ussenterprise.ufp.org> <468281A5.8050804@spaghetti.zurich.ibm.com> <20070627170836.GA15316@ussenterprise.ufp.org> Message-ID: <5E615DE8-965C-42E1-9025-62F1B8949936@virtualized.org> Leo, On Jun 27, 2007, at 1:08 PM, Leo Bicknell wrote: > If a company can get 8 /32's > around the world, should our allocation policies somehow allow them > to get a /29 they can subdivide into /32's from a single RIR, and > then nothing from others? That preserves the ability to aggregate, > while the current scheme of getting them from multiple RIR's at > different times does not. I suspect the point of /32s from each RIR is because they don't want them aggregated. That is, if they got a /29, I'm guessing they'd announce more specifics for traffic engineering purposes. Rgds, -drc From bicknell at ufp.org Wed Jun 27 13:49:26 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 27 Jun 2007 13:49:26 -0400 Subject: [ppml] RIR Shopping, Table Growth x5? In-Reply-To: <4682A159.30109@bogus.com> References: <20070627170836.GA15316@ussenterprise.ufp.org> <17838240D9A5544AAA5FF95F8D520316022AC096@ad-exh01.adhost.lan> <4682A159.30109@bogus.com> Message-ID: <20070627174926.GB18521@ussenterprise.ufp.org> In a message written on Wed, Jun 27, 2007 at 10:41:45AM -0700, Joel Jaeggli wrote: > There is no topological agreation of PI space geographically. I don't > get together with the other isps in my rir region and collectively > announce my address space... that would fundamentally alter how people > buy transit. I was not clear in my original mail, but I was speaking of PA space for the purpose of my question. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From mksmith at adhost.com Wed Jun 27 13:59:18 2007 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 27 Jun 2007 10:59:18 -0700 Subject: [ppml] RIR Shopping, Table Growth x5? In-Reply-To: <4682A159.30109@bogus.com> References: <20070623171426.GA22425@ussenterprise.ufp.org><468281A5.8050804@spaghetti.zurich.ibm.com> <20070627170836.GA15316@ussenterprise.ufp.org> <17838240D9A5544AAA5FF95F8D520316022AC096@ad-exh01.adhost.lan> <4682A159.30109@bogus.com> Message-ID: <17838240D9A5544AAA5FF95F8D520316022AC0AA@ad-exh01.adhost.lan> > Subject: Re: [ppml] RIR Shopping, Table Growth x5? > > Michael K. Smith - Adhost wrote: > >> In a message written on Wed, Jun 27, 2007 at 04:26:29PM +0100, > Jeroen > >> Massar wrote: > >>> * = though, for instance (!random example grabbing!) UUNET/MCI has > >>> already received about 8 /32's for different purposes globally. The > >>> space is easily justified by them and each /32 only covers a > > country, > >>> but I would not be surprised that they did this simply because of > > the > >>> above described problem: keeping traffic local. > >> I guess that's the question though. If a company can get 8 /32's > >> around the world, should our allocation policies somehow allow them > to > >> get a /29 they can subdivide into /32's from a single RIR, and then > >> nothing from others? That preserves the ability to aggregate, while > >> the current scheme of getting them from multiple RIR's at different > >> times does not. > >> > > > > Wouldn't that require all traffic to be routed via the connection(s) > in > > the geographic region of the assigning RIR? That seems like a fairly > > drastic limitation to connectivity for the sake of route aggregation. > I > > would think geographic aggregation regardless of where the company > above > > has its offices would make more sense. So, their Chinese office > would > > aggregate into the "Chinese Block" and the US office would be > aggregated > > into the "US Block" and so on. > > There is no topological agreation of PI space geographically. I don't > get together with the other isps in my rir region and collectively > announce my address space... that would fundamentally alter how people > buy transit. > Understood. I was thinking more in terms of RIR blocks from which I would assume (with all that implies) there is some natural geographic aggregation that occurs. Regards, Mike From Dan.Thorson at seagate.com Wed Jun 27 14:11:23 2007 From: Dan.Thorson at seagate.com (Dan.Thorson at seagate.com) Date: Wed, 27 Jun 2007 13:11:23 -0500 Subject: [ppml] RIR Shopping, Table Growth x5? In-Reply-To: <17838240D9A5544AAA5FF95F8D520316022AC096@ad-exh01.adhost.lan> Message-ID: ppml-bounces at arin.net wrote on 06/27/2007 12:32:05 PM: > > > I guess that's the question though. If a company can get 8 /32's > > around the world, should our allocation policies somehow allow them to > > get a /29 they can subdivide into /32's from a single RIR, and then > > nothing from others? That preserves the ability to aggregate, while > > the current scheme of getting them from multiple RIR's at different > > times does not. > > > > Wouldn't that require all traffic to be routed via the connection(s) in > the geographic region of the assigning RIR? That seems like a fairly > drastic limitation to connectivity for the sake of route aggregation. I > would think geographic aggregation regardless of where the company above > has its offices would make more sense. So, their Chinese office would > aggregate into the "Chinese Block" and the US office would be aggregated > into the "US Block" and so on. What if I want that traffic from the China office to be able to use the China Internet connection under normal conditions, but leverage my Corporate WAN in the event there is upstream provider or other Internet issues in China (that is, the China sites use the China ISP until there's issues... and then China could transit the Corporate WAN to a different ISP connection located elsewhere in the Corporate WAN). This would imply that a corporation would want 1) Provider Independant space 2) multiple blocks of "routable/announcable" IPv6 space 3) have those blocks be agregatable such that, for example: IPblock/48 #1 announced from China IPblock/48 #2 announced from Japan IPblock/48 #3 announced from California IPblock/48 #4 announced from London and then the agregate /46 would be announced from all sites... so each site announces two prefixes... one /46 and one /48 (unless the site has poor BW, in which case they wouldn't announce the /46). Bottom line: Agregatable PI space is highly desired for a world-wide corporation. danT =================================================== Dan Thorson - Seagate Technology - CCIE 10754 desk +1 (952) 402-8293 fax +1 (952) 402-1007 SeaTel 8-402-8293 =================================================== From shamilton at exactor.com Wed Jun 27 14:15:47 2007 From: shamilton at exactor.com (shamilton at exactor.com) Date: Wed, 27 Jun 2007 14:15:47 -0400 (EDT) Subject: [ppml] draft-ietf-ipv6-ula-central-02.txt use cases In-Reply-To: <1182945273.21026.97.camel@localhost.localdomain> References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com><77167.1182834776@sa.vix.com> <4681B179.2020301@internap.com> <024b01c7b876$94b06b70$443816ac@atlanta.polycom.com> <1182945273.21026.97.camel@localhost.localdomain> Message-ID: <10310.207.47.110.138.1182968147.squirrel@www.exactor.com> I totally agree with Stephen and others than regardless of original intent 'private' PI routes will end up public, whether by intention down the road, by accident, or by hi-jacking. It strikes me that the way to address this is after the allocation process by means of routing authentication only - RADB and it's ilk now, certificates later maybe. Call me naive but I thought a key factor in v6 deployment is that there is enough to go round so NAT / PA will not be forced onto organizations that don't want it - surely it's enough of a burden to get PI space, manage it in RADB/DNS, setup BGP, pay an ISP to receive your advertisements (there's a whole other choke point here where ISPs can institute their own policies on what is reasonable). I'm young and inexperienced compared to many of you I know, but I can't see the IPv6 table being < 300K routes in a few years, but neither can I see it being double that - whilst I see some pent up demand for multi-homing using PI space, I also see many people who will continue using NAT in IPv6 because that's their security guys dogma (it isn't mine & I'm not interested in that whole discussion again). It will continue to require a degree of clue to participate in the global table, and if people need to announce their aggregates to make things work that's a lesson they will learn (or that their ISPs will share/force upon them) Regards Simon Hamilton-Wilkes > On Tue, 2007-06-26 at 23:48 -0500, Stephen Sprunk wrote: >> If we want to issue address space to folks for "private" use, it needs >> to be >> out of the same block(s) that the RIRs use to allocate space for >> "public" >> use, because sooner or later those "private" networks are going to end >> up >> being publicly routed. > > But if we do this shouldn't we also take steps to prevent abuse > (hijacking etc) of those "private" blocks. History has shown that > unannounced PI-blocks that nobody is missing can be abused for a long > time before anybody cries foul. We may have made a hash of v4, but > shouldn't have to make the same mistake from the start with v6. Maybe > RIRs should announce "private" or otherwise "quarantined" blocks from a > special AS so that they can easily be identified and filtered ... > although they'd end up wasting space in the DFZ (whatever that is;). > > ... which is closely related to the following: >> >> If we are concerned that giving "real" PI space to every org that asks >> for >> it will result in the immediate death of the DFZ, then there needs to be >> some sort of tag attached to blocks that says whether or not the >> registrant >> has met whatever the current rules are for deserving a routing slot. If >> routing certificates ever take off, they could contain a flag that gives >> the >> current public routability status, or the RIR could just not issue a >> certificate at all if someone hasn't met the bar. That's an entirely >> separate matter from whether or not they get addresses. > > Until there's a reliable mechanism to verify the origin of a prefix all > we can do is try to cope through policies. Is the lack of > route-certificates an excuse to not try to do something about the > problem in the meantime? > > >> >> One could also argue that the RIRs do not belong in the routability >> decision >> path at all, since their job is to ensure uniqueness, and some other >> quasi-public entity responsible for the health of the DFZ would produce >> "routability" certificates. That also gives rise to the possibility of >> different models than we have today, like a market where people could >> buy >> and sell routing slots. > > Isn't that like calling for a "global internet constitution"? > > What about a mechanism to establish some form of "common ground" on > which routing-policy-decisions can be made. To "navigate" the world of > routing an allocation-policies today is like navigating an aircraft > without the ability to adjust the altimeter for varying air-pressure. > There are too many inconsistent and independent sources of information > with widely varying quality and formats. Things would be easier if > inter-domain-routers were required to form a relation to > address-registries for all network-domains in which they wish to operate > (normally ARIN + RIRs + possibly private) in addition to whatever > routing policies each operator choose to implement (in reality they > already do but the quality that information tend to vary a lot with > operator clue). Registries would then have to announce the allocation > policies (blocks and prefix-lengths) through standardised formats and > mechanisms/protocols available globally. Address-space that is not > covered by a policy would by definition be unused (hence the need for > separate bogon-filtering and the related debogonizing-issues would be > mostly eliminated). > > Combine this with: > > - A strong recommendation from address registries to announce aggregates > for optimum visibility/routability (note: _recommendation_ not > _requirement_). In reality this is just a formalisation of current > practise. > > - Standards which must require IDR implementations to never drop > aggregates even if the available set of more-specifics cover the entire > block specified by the allocation policy. A 3rd party might choose to > ignore the smaller blocks and would loose "visibility" without the > aggregate. (note: path selection algorithms based on > longest-prefix-match would not be affected). > > (- Maybe even a BGP node should be able to tell its peer(s) that it > doesn't want to receive routes more specific than allocation policies. > Although it might be hard to ensure that different ASes conform to the > same allocation policies.) > > > With such a thing in place one would at least have a fair chance of > knowing how local routing-policy decisions might affect routability. Now > you can safely ignore TE-churn from distant networks while choosing to > accept more specifics from peers and others in your "neighbourhood" and > still feel reasonably confident that you're not loosing anything > important. > > In a better world that has route-certificates and unlimited > IDR-scalability this makes no sense, but will we get there in time to > avoid trouble. > > > //per > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From jmorrison at bogomips.com Wed Jun 27 14:16:34 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Wed, 27 Jun 2007 11:16:34 -0700 Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration Incentive Address Space In-Reply-To: <3c3e3fca0706262050o8c9accl7139ca4e75e94d2c@mail.gmail.com> References: <3c3e3fca0706261303s74d39ccqed8f591727a90cee@mail.gmail.com> <46818179.3000000@internap.com> <3c3e3fca0706262050o8c9accl7139ca4e75e94d2c@mail.gmail.com> Message-ID: <4682A982.3050702@bogomips.com> I do not support this proposal as it essentially duplicates the IPv6 address space already allocated to IPv4 users, documented in RFC 3056 (6to4). Every single IPv4 address automatically gets an IPv6 /48 allocation. From RFC 3056: "Within the subscriber site it can be used exactly like any other valid IPv6 prefix, e.g., for automated address assignment and discovery according to the normal mechanisms such as [CONF, DISC], for native IPv6 routing, or for the "6over4" mechanism [6OVER4]." In short, 6to4 assigns IPv6 addresses that can be used for native IPv6 and it specifies a tunneling protocol, using the IPv4 internet as a backbone. I think the RFC contains some unneeded baggage about it being a transition solution and suggests some restrictions on the way it is used within native IPv6 routing. The RFC was written in a more optimistic time, probably assuming the transition to IPv6 would be quicker. I don't see why people with existing IPv4 addresses shouldn't just slap on 2002:: - bypassing the whole process of assigning new "native" IPv6 space. (Much the way CIDR was a natural extension or generalization to IPv4 routing, utilizing 2002:: for native global IPv6 routing may be the same) From jordi.palet at consulintel.es Wed Jun 27 15:03:08 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 27 Jun 2007 15:03:08 -0400 Subject: [ppml] The Choice: IPv4 Exhaustion or Transition to IPv6 Message-ID: Hi all, I've published a document trying to analyze the IPv4 exhaustion problem and what is ahead of us, considering among others, changes in policies. http://www.ipv6tf.org/index.php?page=news/newsroom&id=3004 I guess this could be useful in order to understand possible implications of modifying existing policies, or setting up new ones, or even just to create some debate about those changes. The document was completed last April, but didn't had the time to tidy up until a few days ago. Regards, Jordi ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From tedm at ipinc.net Wed Jun 27 16:08:26 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 27 Jun 2007 13:08:26 -0700 Subject: [ppml] The Choice: IPv4 Exhaustion or Transition to IPv6 In-Reply-To: Message-ID: This is a very useful document to hand off to a manager that doesen't know shit from shinola about networking, but it is not really a technical document. The biggest glaring problems I see with it is the document makes an assumption that Peer to Peer is a Good Thing that everbody wants, and it completely ignores the desire of end user consumers to be provider-independent. Your average business owner does not want peer to peer. He does not want his employees running instant messaging, or online gaming or file sharing or any of that. He likes NAT devices because they make it harder for those applications to run. And the newer NAT devices on the market are getting more and more unfriendly to those protocols. Right now Cisco has put in protocol blocking for AIM, ICQ, IRC and a bunch of other of those protocols into it's high-end IOS. It works by examining the packets themselves so setting the AIM client to use port 80 to find an AIM server so as to sidestep the blocks is useless. It will only be a matter of time before you will see this technology appear in the low-end Cisco AKA Linksys gear that sells for under $300. Secondly, your average business owner does not want to have the IP handcuffs on him. If he gets pissed off at his ISP he wants the ability to call another ISP competitor and move his connection to the competitor without the expense of renumbering his internal network. In the United States today, the market for networking gear sold to the SOHO under-100 employee firms EXCEEDS the dollar value of the market for networking gear sold to the traditional enterprise. Intel has been studying this market for years and they saw the SOHO exceed the enterprise sometime back in 1998 (I do not know if Intel ever declassified these marketing studies but I know they exist) that is why they got into that market. A lot of other networking firms that kept focusing on the enterprise (can you say Bay Networks, Cabletron, etc.) went bankrupt. It is of course, true that large enterprises with 1000's of desktops will want to be multihomed and thus will want to get their own AS and own portable numbering, and thus are very interested in the IPv6 issues. But they are a market minority. The majority of businesses are not like this and even if all ISP's switch over to IPv6 and all business do likewise, your still going to see a very large demand for NAT devices. Even if they are nothing more than 1:1 IPv6 translators. If you could rework the document to include this issue it might be usable to a much wider audience. Ted >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >JORDI PALET MARTINEZ >Sent: Wednesday, June 27, 2007 12:03 PM >To: ppml at arin.net >Subject: [ppml] The Choice: IPv4 Exhaustion or Transition to IPv6 > > >Hi all, > >I've published a document trying to analyze the IPv4 exhaustion problem and >what is ahead of us, considering among others, changes in policies. > >http://www.ipv6tf.org/index.php?page=news/newsroom&id=3004 > >I guess this could be useful in order to understand possible >implications of >modifying existing policies, or setting up new ones, or even just to create >some debate about those changes. > >The document was completed last April, but didn't had the time to tidy up >until a few days ago. > >Regards, >Jordi > > > > > > >********************************************** >The IPv6 Portal: http://www.ipv6tf.org > >Bye 6Bone. Hi, IPv6 ! >http://www.ipv6day.org > >This electronic message contains information which may be >privileged or confidential. The information is intended to be for >the use of the individual(s) named above. If you are not the >intended recipient be aware that any disclosure, copying, >distribution or use of the contents of this information, including >attached files, is prohibited. > > > >_______________________________________________ >This message sent to you through the ARIN Public Policy Mailing List >(PPML at arin.net). >Manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/ppml > From sleibrand at internap.com Wed Jun 27 18:13:34 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 27 Jun 2007 15:13:34 -0700 Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration Incentive Address Space In-Reply-To: <3c3e3fca0706262050o8c9accl7139ca4e75e94d2c@mail.gmail.com> References: <3c3e3fca0706261303s74d39ccqed8f591727a90cee@mail.gmail.com> <46818179.3000000@internap.com> <3c3e3fca0706262050o8c9accl7139ca4e75e94d2c@mail.gmail.com> Message-ID: <4682E10E.7090706@internap.com> William Herrin wrote: > Yet IPv6 uptake increases at a pace which won't meet the 10% > deployment mark before IPv4 exhaustion. You assume a continued linear pace... > > Three years from now, that will be a real problem for Internap. You > sell a high value service with cleverly optimized routes. Without IPv6 > in place, no more IPv4 addresses means no new customers despite your > technology. Cogent gets them instead because this week Cogent is the > one with spare IP addresses. Next week it'll be someone else, Level 3 > maybe, but not you. You're stuck until a customer leaves and forfeits > his IP addresses. In our case, we intend to be fully ready to offer IPv6 services before our customers require them, which means before IPv4 space is exhausted. We know what needs to happen to offer IPv6 support (and have known that for a few years now). On the hardware side, all the new hardware we've purchased in the last several years has supported IPv6 forwarding in hardware, and we have been gradually replacing much of the hardware that doesn't support IPv6 through our normal equipment refresh projects. On the software and systems side of things, we have to time our IPv6 investments such that we take the necessary steps in time, but not allow it to delay more urgent needs that have a more immediate effect on revenue. > > That's why I've proposed an -Incentive- space, not merely a migration > space. We have maybe three years to get IPv6 to a point where dialup > users, dsl users and folks with wifi laptops at Starbucks receive IPv6 > addresses automatically alongside the IPv4 addresses. That's three > years to get IPv6 in the hands of the end users and every network > admin in the path from us to them. If we can't bring Mohammad to the > mountain, maybe its in our interest for the mountain to make a trip. I think an appropriate historical analogy for IPv6 readiness is y2k compliance. As with IPv4 exhaustion, insiders knew the y2k bug would be a problem years or decades before y2k. As with y2k, the benefits of IPv6 readiness come mostly from avoiding problems when the century / IPv4 space runs out. Most of the benefits of being y2k compliant came on January 1st, 2000, and most of the benefit of being IPv6 ready will come when IPv4 space is exhausted. I think it's worth comparing the two scenarios on a timeline basis as well: How much legacy code had been y2k-patched as of June 1997? A Google news archive search confirms that in 1997, while most major news organizations were running stories on the y2k bug, analysts were looking at the efforts to date and predicting that "companies are not acting expeditiously enough to be fully year 2000 compliant by the close of the decade" and "more than one-half of all organizations world-wide will not fully complete their year 2000 effort." (http://www.pbs.org/newshour/@capitol/forum/april97/2000_4-28e.html) In fact, what happened was that companies first focused on ensuring that new hardware and software was y2k compliant, enabling normal or slightly-accelerated upgrade/refresh cycles to take care of a lot of the problem. For the legacy applications that couldn't be easily replaced by 01/01/2000, efforts to patch things mostly got rolling in 1998 and early 1999. (Office Space was released 02/19/1999.) So the lesson I would draw from the y2k/IPv4 comparison is that if we can educate stakeholders on the problem, most of them will make pretty good decisions and make the necessary preparations. And since the impacts of IPv4 exhaustion will be more gradual than the y2k bug (the IPv4 Internet will keep working long after every RIR exhausts their free IPv4 pools), there will be varying degrees of preparedness for IPv4 exhaustion: that's fine. -Scott From sleibrand at internap.com Wed Jun 27 18:32:19 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 27 Jun 2007 15:32:19 -0700 Subject: [ppml] draft-ietf-ipv6-ula-central-02.txt use cases In-Reply-To: <024b01c7b876$94b06b70$443816ac@atlanta.polycom.com> References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com><77167.1182834776@sa.vix.com> <4681B179.2020301@internap.com> <024b01c7b876$94b06b70$443816ac@atlanta.polycom.com> Message-ID: <4682E573.7010300@internap.com> Stephen Sprunk wrote: > Thus spake "Scott Leibrand" >> >> I'm not sure this is a digression. What you're describing is >> exactly what I think ULA-C should be: a well-known block (that >> DFZ operators would filter announcements from) from which PI >> assignments can be made without the restrictions required on >> public PI space to avoid routing table bloat. > > If this is what we mean by "private PI", then I'm against that too. > Dressing up ULA-C with a different prefix and name but retaining all > of the operational stupidity doesn't solve any problems. A turd by > any other name smells just as foul. > > If we want to issue address space to folks for "private" use, it needs > to be out of the same block(s) that the RIRs use to allocate space for > "public" use, because sooner or later those "private" networks are > going to end up being publicly routed. Then why aren't we routing 10/8 yet? And what about ULA-L? Does that need to be abolished as well? If private space is indistinguishable (by routers) from public space, then such space will indeed end up being routed. But if I can simply add "deny FC00::/7" to my bogon filter, then I need never see such routes. > > If we are concerned that giving "real" PI space to every org that asks > for it will result in the immediate death of the DFZ, then there needs > to be some sort of tag attached to blocks that says whether or not the > registrant has met whatever the current rules are for deserving a > routing slot. If routing certificates ever take off, they could > contain a flag that gives the current public routability status, or > the RIR could just not issue a certificate at all if someone hasn't > met the bar. That's an entirely separate matter from whether or not > they get addresses. I agree with you that such a model would be a good one for a future Internet where routing certificates or something similar have been widely adopted. In today's world, the tools available to operators on currently-deployed routers allow filtering out well-known bogon prefixes (like FC00::/7) and prefix-length filters on non-bogon space. If we want to allow innovation at the edge of the network, where it happens fastest, without waiting for innovation at the core, where it's slowest, we need to give as much flexibility as possible to end sites without disrupting anything at the core. At some future date when an identifier/locator split protocol has taken hold and the number of routes no longer matters, we'll be free to relax the rules on PI space, or start accepting routes from FD00::/8. And in the mean time, small network operators will have the freedom to innovate without imposing their route announcements on anyone else. -Scott From sleibrand at internap.com Wed Jun 27 20:05:58 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 27 Jun 2007 17:05:58 -0700 Subject: [ppml] draft-ietf-ipv6-ula-central-02.txt use cases In-Reply-To: <10310.207.47.110.138.1182968147.squirrel@www.exactor.com> References: <200706221709.l5MH9uEN003458@mail.reprise.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com><77167.1182834776@sa.vix.com> <4681B179.2020301@internap.com> <024b01c7b876$94b06b70$443816ac@atlanta.polycom.com> <1182945273.21026.97.camel@localhost.localdomain> <10310.207.47.110.138.1182968147.squirrel@www.exactor.com> Message-ID: <4682FB66.5010200@internap.com> >> On Tue, 2007-06-26 at 23:48 -0500, Stephen Sprunk wrote: >> >>> If we want to issue address space to folks for "private" use, it needs >>> to be out of the same block(s) that the RIRs use to allocate space for >>> "public" use, because sooner or later those "private" networks are going to end up being publicly routed. >>> >> But if we do this shouldn't we also take steps to prevent abuse >> (hijacking etc) of those "private" blocks. History has shown that >> unannounced PI-blocks that nobody is missing can be abused for a long >> time before anybody cries foul. We may have made a hash of v4, but >> shouldn't have to make the same mistake from the start with v6. Maybe >> RIRs should announce "private" or otherwise "quarantined" blocks from a >> special AS so that they can easily be identified and filtered ... >> although they'd end up wasting space in the DFZ (whatever that is;). >> >> shamilton at exactor.com wrote: > I totally agree with Stephen and others than regardless of original > intent 'private' PI routes will end up public, whether by intention down > the road, by accident, or by hi-jacking. It strikes me that the way to > address this is after the allocation process by means of routing > authentication only - RADB and it's ilk now, certificates later maybe. > I believe this should be addressed as well, and the simplest way to take steps to prevent abuse of private space is to allocate it all out of a single block, and encourage operators to filter any announcements they see out of that block ("deny FC00::/7"). There's no need for routing authentication, certificates, special ASNs, etc. If that's not good enough, then we need to just go ahead and adopt a liberal PI policy for IPv6 and be done with it. It seems to me that this debate is stuck between those who think any sort of ULA-C or liberalized PI is going too far, and those who think that ULA-C doesn't go far enough, and want liberalized PI instead. IMO, ULA-C is the best middle ground we have, and if the folks who think it doesn't go far enough aren't willing to support a step in that direction, then we'll just have to sit where we're at until there's enough demand for liberalized PI. -Scott From paul at vix.com Wed Jun 27 22:31:42 2007 From: paul at vix.com (Paul Vixie) Date: Thu, 28 Jun 2007 02:31:42 +0000 Subject: [ppml] draft-ietf-ipv6-ula-central-02.txt use cases In-Reply-To: Your message of "Wed, 27 Jun 2007 17:05:58 MST." <4682FB66.5010200@internap.com> References: <200706221709.l5MH9uEN003458@mail.reprise.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com><77167.1182834776@sa.vix.com> <4681B179.2020301@internap.com> <024b01c7b876$94b06b70$443816ac@atlanta.polycom.com> <1182945273.21026.97.camel@localhost.localdomain> <10310.207.47.110.138.1182968147.squirrel@www.exactor.com> <4682FB66.5010200@internap.com> Message-ID: <3513.1182997902@sa.vix.com> From: Scott Leibrand > ... IMO, ULA-C is the best middle ground we have, and if the folks who think > it doesn't go far enough aren't willing to support a step in that direction, > then we'll just have to sit where we're at until there's enough demand for > liberalized PI. which ULA-C draft do you mean? on june 21, IETF published ula-central-02 at and it includes text about a 40-bit random number and permanent allocations without any need for renewal and any procedure for deallocation, and has instructions to IANA, with expectations that the RIRs will be the IANA's choice of operator for the "public database". this doesn't sound like what you're in favour of. if what you think ought to be done is that FC::/7 should be reserved by IANA for non-DFZ use and that chunks like /16's ought to be handed to RIR's and /32's ought to be handed to LIR's and that RIR/LIR fee and qualification levels ought to be lower for this kind of space so that anyone who wants a /48 even if it's for their laptop ought to be able to get one and get IN-ADDR service and have the same WHOIS as normal PI... then you'll have to write that as an Internet Draft and submit it in competition to central-02. but i don't think you (scott liebrand) are in favour of central-02 as written and i know i'm not either. so it's jarring to hear you say "ULA-C is the best middle ground we have". the ULA-C on the table isn't the one you've advocated. From sleibrand at internap.com Thu Jun 28 01:41:59 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 27 Jun 2007 22:41:59 -0700 Subject: [ppml] draft-ietf-ipv6-ula-central-02.txt use cases In-Reply-To: <3513.1182997902@sa.vix.com> References: <200706221709.l5MH9uEN003458@mail.reprise.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com><77167.1182834776@sa.vix.com> <4681B179.2020301@internap.com> <024b01c7b876$94b06b70$443816ac@atlanta.polycom.com> <1182945273.21026.97.camel@localhost.localdomain> <10310.207.47.110.138.1182968147.squirrel@www.exactor.com> <4682FB66.5010200@internap.com> <3513.1182997902@sa.vix.com> Message-ID: <46834A27.3070309@internap.com> Paul Vixie wrote: > From: Scott Leibrand > > >> ... IMO, ULA-C is the best middle ground we have, and if the folks who think >> it doesn't go far enough aren't willing to support a step in that direction, >> then we'll just have to sit where we're at until there's enough demand for >> liberalized PI. >> > > which ULA-C draft do you mean? on june 21, IETF published ula-central-02 at > and > it includes text about a 40-bit random number and permanent allocations without > any need for renewal and any procedure for deallocation, and has instructions > to IANA, with expectations that the RIRs will be the IANA's choice of operator > for the "public database". this doesn't sound like what you're in favour of. > > if what you think ought to be done is that FC::/7 should be reserved by IANA > for non-DFZ use and that chunks like /16's ought to be handed to RIR's and > /32's ought to be handed to LIR's and that RIR/LIR fee and qualification > levels ought to be lower for this kind of space so that anyone who wants a > /48 even if it's for their laptop ought to be able to get one and get IN-ADDR > service and have the same WHOIS as normal PI... then you'll have to write that > as an Internet Draft and submit it in competition to central-02. > > but i don't think you (scott liebrand) are in favour of central-02 as written > and i know i'm not either. so it's jarring to hear you say "ULA-C is the best > middle ground we have". the ULA-C on the table isn't the one you've advocated. > I much prefer the text you've proposed to that in draft-ietf-ipv6-ula-central-02.txt. I also agree with you that the random permanent allocations are somewhat inconsistent with the need to maintain reverse DNS. Thank you for suggesting better language, so I didn't have to. I'd hate to see the results if I were to start designing header formats without help. :-) -Scott From heldal at eml.cc Thu Jun 28 04:46:26 2007 From: heldal at eml.cc (Per Heldal) Date: Thu, 28 Jun 2007 10:46:26 +0200 Subject: [ppml] draft-ietf-ipv6-ula-central-02.txt use cases In-Reply-To: <46836D78.1020202@gmail.com> References: <200706221709.l5MH9uEN003458@mail.reprise.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B5@XCH-NW-7V2.nw.nos.boeing.com> <467C1F53.9070600@spaghetti.zurich.ibm.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com><77167.1182834776@sa.vix.com> <4681B179.2020301@internap.com> <024b01c7b876$94b06b70$443816ac@atlanta.polycom.com> <1182945273.21026.97.camel@localhost.localdomain> <46836D78.1020202@gmail.com> Message-ID: <1183020386.21421.35.camel@localhost.localdomain> On Thu, 2007-06-28 at 10:12 +0200, Brian E Carpenter wrote: > On 2007-06-27 13:54, Per Heldal wrote: > > On Tue, 2007-06-26 at 23:48 -0500, Stephen Sprunk wrote: > >> If we want to issue address space to folks for "private" use, it needs to be > >> out of the same block(s) that the RIRs use to allocate space for "public" > >> use, because sooner or later those "private" networks are going to end up > >> being publicly routed. > > > > But if we do this shouldn't we also take steps to prevent abuse > > (hijacking etc) of those "private" blocks. > > No, I don't think so. ULAs are for local use. We provide a mechanism > to ensure that they are extremely likely to be unique, but as long as > they are used locally, and confined locally both by routing and by > DNS, it actually doesn't matter operationally if someone else uses the > same prefix in their local area. I wasn't talking about ULA at all, but about an attempt to limit abuse of PI or even PA space whenever such blocks are allocated but not announced externally. Whether allocated PI is used for private purposes by accident or intentionally doesn't matter in that respect. ULA is no problem as it's trivial to block all of it with one single config-statement. The rest of my rant was about my wish to formalise and automate the relation between allocation policies and operational practises. I.e. why keep pretending registry-policies have nothing to do with routing when so many IDRs in the DFZ has a config full of stuff derived from those policies? //per From paul at vix.com Thu Jun 28 10:39:18 2007 From: paul at vix.com (Paul Vixie) Date: Thu, 28 Jun 2007 14:39:18 +0000 Subject: [ppml] draft-ietf-ipv6-ula-central-02.txt use cases In-Reply-To: Your message of "Wed, 27 Jun 2007 22:41:59 MST." <46834A27.3070309@internap.com> References: <200706221709.l5MH9uEN003458@mail.reprise.com> <20070622195429.GG31273@elvis.mu.org> <467C2EE6.3070100@spaghetti.zurich.ibm.com> <20070623005010.GI31273@elvis.mu.org> <467D0806.7030100@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B7@XCH-NW-7V2.nw.nos.boeing.com> <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <46807C77.2020101@internap.com><77167.1182834776@sa.vix.com> <4681B179.2020301@internap.com> <024b01c7b876$94b06b70$443816ac@atlanta.polycom.com> <1182945273.21026.97.camel@localhost.localdomain> <10310.207.47.110.138.1182968147.squirrel@www.exactor.com> <4682FB66.5010200@internap.com> <3513.1182997902@sa.vix.com> <46834A27.3070309@i nternap.com> Message-ID: <11096.1183041558@sa.vix.com> From: Scott Leibrand > Paul Vixie wrote: > > > but i don't think you (scott liebrand) are in favour of central-02 as > > written and i know i'm not either. so it's jarring to hear you say "ULA-C > > is the best middle ground we have". the ULA-C on the table isn't the one > > you've advocated. > > I much prefer the text you've proposed to that in > draft-ietf-ipv6-ula-central-02.txt. I also agree with you that the random > permanent allocations are somewhat inconsistent with the need to maintain > reverse DNS. Thank you for suggesting better language, so I didn't have to. > ... for reference, here's the text scott is referring to, posted to ipv6 at ietf.org last night: Paul Vixie wrote: > these are my comments on the following I-D: > >> Title : Centrally Assigned Unique Local IPv6 Unicast Addresses >> Author(s) : R. Hinden, B. Haberman >> Filename : draft-ietf-ipv6-ula-central-02.txt >> Pages : 11 >> Date : 2007-6-18 >> >> > > first, in 3.1, this table: > > | 7 bits |1| 40 bits | 16 bits | 64 bits | > +--------+-+------------+-----------+----------------------------+ > | Prefix |L| Global ID | Subnet ID | Interface ID | > +--------+-+------------+-----------+----------------------------+ > > should be replaced with this one: > > | 7 bits |1| 8 bits | 16 bits | 16 bits | 80 bits | > +--------+-+----------+---------+---------+----------+ > | Prefix |L| Reserved | RIR Num | LIR Num | User Num | > +--------+-+----------+---------+---------+----------+ > > where "Prefix" and "L" are defined as shown in central-02, and the other > fields are defined as follows: > > Reserved Set to 0 by all implementors of this specification, > but may be set to nonzero by implementors of a later > specification. > > RIR Num Identifiers assigned by IANA for each /16 as > allocated to an Regional Internet Address Registry > (RIR). For direct allocations by IANA, the value > of zero (0x0000) is reserved. > > LIR Num Identifiers assigned by RIR for each /32 as > allocated to a Local Internet Address Registry (LIR). > For direct allocations by an RIR, the value of zero > (0x0000) is reserved. > > User Num Identifier assigned by an end user or network > operator who implements this specification. > > second, delete all of section 3.2 including subsections 3.2.1, 3.2.2, 3.2.3. > > third, replace section 7.0 with the following: > > --- > > 7.0 IANA Considerations > > IANA is hereby instructed to reserve address block FC::/7 for private > unique addresses, and to allocate /32 blocks to Regional Internet > Address Registries (RIRs) who request same after adopting policies > consistent with this specification. Allocation shall be similar in > all ways to normal IANA address allocation to RIRs, including but not > limited to IN-ADDR.ARPA delegations and WHOIS records. > > --- > > Paul Vixie > not speaking for ISC > not speaking for ARIN From arin-contact at dirtside.com Thu Jun 28 11:32:21 2007 From: arin-contact at dirtside.com (William Herrin) Date: Thu, 28 Jun 2007 11:32:21 -0400 Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration Incentive Address Space In-Reply-To: <4682A982.3050702@bogomips.com> References: <3c3e3fca0706261303s74d39ccqed8f591727a90cee@mail.gmail.com> <46818179.3000000@internap.com> <3c3e3fca0706262050o8c9accl7139ca4e75e94d2c@mail.gmail.com> <4682A982.3050702@bogomips.com> Message-ID: <3c3e3fca0706280832q3b98e0d6u3f84507856bf6990@mail.gmail.com> On 6/27/07, John Paul Morrison wrote: > I do not support this proposal as it essentially duplicates the IPv6 > address space already allocated to IPv4 users, documented in RFC 3056 > (6to4). John, First, thank you for privately discussing 6to4's functionality with me. You were very helpful and informative. You are not alone in suggesting that 6to4 might suitably replace the Migration Incentive Space proposal, however 6to4 has several issues which would need to be addressed before it could be considered a valid alternative. I'd like to find if there is a consensus on ppml as to whether those issues should be addressed in 6to4. If they should, I'll start working on such a proposal with the intent that it replace the Migration Incentive Space proposal. If they should not, then I would ask that 6to4 be considered irrelevant to and dropped from the discussion. 6to4 Problem #1: Implementation of 6to4 is an optional component of the IPv6 protocol. Devices confronted with a 2002:: address may but need not recognize that packets to such a destination should be encapsulated in an IPv4 packet. The Migration Incentive Space proposal is intended to rely on only those components of IPv6 which are mandatory. 6to4 Problem #2: Its unclear whether the authors of RFC 3056 intended that it be possilble for prefixes within 2002:: to be announced into the global IPv6 BGP table so that all native IPv6 networks could reach such hosts without IPv4 encapsulation. Indeed, some parts of the document suggest that an available IPv6 route should NOT take priority over encapsulation. For 6to4 to reasonably replace the Migration Incentive Space, it would need to be clarified that ARIN encourages IPv4 holders to announce an appropriately selected 2002:: route, that remote IPv6 systems should give native IPv6 routes to 2002:: destinations priorirty over the encalsulated IPv4 route, and that ARIN intends such blocks within 2002:: to have the same validity as any other IPv6 block they assign or allocate. 6to4 Problem #3: Its unclear whether the authors of RFC 3056 intended that prefixes within 2002:: continue to exist in IPv4's post-exhaustion phase when IPv6 has become the dominant protocol. The Migration Incentive Space is intended to be a permanant solution whose addresses continue to see use after IPv4's end of life. 6to4 Problem #4: ARIN does not control the reverse DNS for 6to4 prefixes associated with the IPv4 blocks which ARIN manages. It is presently managed by the NRO, an organization in which ARIN participates (see https://6to4.nro.net/). The documentation for 6to4 reverse dns states that, "This password is not mandatory when the site is accessed from inside your 6to4 source address. It is intended to prevent an arbitrary access from locking out the domain if the address is not static. (It is recognized that this places far less trust than normal in the correctness of a 6to4 delegation)." For 6to4 to work as a replacement for the Migration Incentive Space, reverse DNS for the blocks under ARIN's authority would need to be operated with a degree of security and access comperable to what ARIN applies to its normal delegation of reverse DNS. So, the question I put to you and to the others who have suggested 6to4 is this: Do we seek changes and clarifications to address these four problems or do we drop 6to4 from consideration as an alternative to the Migration Incentive Space proposal? Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From owen at delong.com Thu Jun 28 12:34:02 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Jun 2007 09:34:02 -0700 Subject: [ppml] Policy Proposal: Resource Reclamation Incentives Message-ID: <371EB4EE-C2FE-46CD-BAF9-DB35937B572A@delong.com> Here's an attempt to partially drain the swamp and create some incentives for legacy holders to both return available IPv4 space and start using IPv6. Comments welcome. Owen Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 Policy Proposal Name: Legacy Outreach and Partial Reclamation Author name: Owen DeLong email: owen at delong.com telephone: 408-921-6984 organization: JITTR Networks Proposal Version: 0.0.1 Submission Date: 2007 April 22 Proposal type: M new, modify, or delete. Policy term: permanent temporary, permanent, or renewable. Policy statement: Modify section 4.6 as follows: 4.6 Amnesty Requests ARIN will accept the return or relinquishment of any address space from any existing address holder. If the address holder wishes to aggregate into a single block, ARIN may work with the address holder to arrive at an allocation or assignment which is equal to or smaller than the sum of their existing blocks and which best meets the needs of the existing holder and the community. There shall be no fee for returning addresses under this policy. Further, organizations returning addresses under this policy shall receive the following benefits: 1. If the organization does not currently pay ARIN fees, they shall remain fee exempt. 2. If the organization currently pays ARIN fees, their fees shall be waived for two years for each /20 equivalent returned, with any fractional /20 equivalent resulting in a one-time single year waiver. 3. Any organization returning address space under this policy shall continue under their existing RSA or they may choose to sign the current RSA. For organizations which currently do not have an RSA, they may sign the current RSA, or, they may choose to remain without an RSA. 4. All organizations returning space under this policy shall, if they meet other eligibility requirements and so request, obtain an appropriate IPv6 end-user assignment or ISP allocation as applicable, with no fees for the first 5 years. Organizations electing to receive IPv6 allocation/assignment under this provision must sign a current RSA and must agree that all of their IPv4 resources are henceforth subject to the RSA. Organizations taking this election shall be subject to end-user fees for their IPv4 resources not previously under an ARIN RSA. If they are already an ARIN subscriber, then IPv4 resources affected by this process may, instead, be added to their existing subscriber agreement at the address holder's discretion. Rationale: The current amnesty policy does a nice job of facilitating aggregation, which was the intent when it was drafted. However, as we approach IPv4 free-space exhaustion, the community now has an additional need to facilitate address reclamation. A very high percentage of underutilized space is in the hands of legacy holders who currently have no benefit to joining the ARIN process. Further, there is an unfortunate perception that doing so will require force the legacy holder into certain future disadvantages. This proposal attempts to resolve both of those issues while also providing some incentive to legacy organizations to start using IPv6 resources and bring their IPv4 resources into the ARIN process. This policy attempts to provide some benefit and remove most of the costs of making partial IPv4 returns. It also attempts to provide an incentive for these IPv4 holders to join the ARIN process. Timetable for implementation: Immediate Meeting presenter: TBD, probably Owen DeLong END OF TEMPLATE From jeroen at unfix.org Thu Jun 28 13:17:00 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 28 Jun 2007 18:17:00 +0100 Subject: [ppml] Policy Proposal: Resource Reclamation Incentives In-Reply-To: <371EB4EE-C2FE-46CD-BAF9-DB35937B572A@delong.com> References: <371EB4EE-C2FE-46CD-BAF9-DB35937B572A@delong.com> Message-ID: <4683ED0C.40409@spaghetti.zurich.ibm.com> Owen DeLong wrote: > Here's an attempt to partially drain the swamp and create some > incentives > for legacy holders to both return available IPv4 space and start using > IPv6. > > Comments welcome. This sounds like a very reasonable proposal and I would support this. One thing that might be added, for the numbers people, is a cost/savings table outlining what savings they will have over the coming years and what it will be costing them after that. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From jordi.palet at consulintel.es Thu Jun 28 12:57:27 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 28 Jun 2007 12:57:27 -0400 Subject: [ppml] The Choice: IPv4 Exhaustion or Transition to IPv6 In-Reply-To: Message-ID: Hi Ted, The document is more intended to the non-technical people, but precisely to folks that don't understand the PDP, how address distribution works, etc. For this reason I try to avoid as much as possible going into many technical details, including going into the PI thing. Also the document was not intended to defend or not peer-to-peer, it just explains what we have in the networks that typically evolve faster, and they are residential networks, were peer-to-peer is more used than in enterprise ones. I think it is important to read the document as a compilation of what is happening with IPv4, and what we can do to postpone the exhaustion and how much those possible mitigations will offer to us and a very "crystal-ball" like idea of what may be the cost, implications, etc. It is not intended to be precise, because it is not possible, and I will be making it up if I try that, but instead, waking up about what may happen and if those parallel paths are short term or long term solutions, as I believe is the case for IPv6. The document is not also an IPv6 document, but definitively, especially in the last pages, assuming that we believe that IPv6 will be the long term solution (at least the one we have at hand right now), trying to describe the picture for the different "phases" of the exhaustion in that case. All what you mention about PI, renumbering and NAT, it is very related, and I think it is applicable to what I mention in the document about the increase in the usage of NAT and chances for kind of IPv6-to-IPv4 (even with NAT) proxies if required. So what I hope from this document is that it is useful to be hand off to other folks by this community, even if it may be not directly so helpful for techies like us, as you already said. I'm sure it is not perfect, but I'm not convinced it will be good to turn it into a technical document, because it is supposed that we already know about all this. Regards, Jordi > De: Ted Mittelstaedt > Responder a: > Fecha: Wed, 27 Jun 2007 13:08:26 -0700 > Para: , > Asunto: RE: [ppml] The Choice: IPv4 Exhaustion or Transition to IPv6 > > > This is a very useful document to hand off to a manager that doesen't know > shit from shinola about networking, but it is not really a technical > document. > > The biggest glaring problems I see with it is the document makes an > assumption that Peer to Peer is a Good Thing that everbody wants, > and it completely ignores the desire of end user consumers to be > provider-independent. > > Your average business owner does not want peer to peer. He does not > want his employees running instant messaging, or online gaming or > file sharing or any of that. He likes NAT devices because they make it > harder for those applications to run. And the newer NAT devices on > the market are getting more and more unfriendly to those protocols. > Right now Cisco has put in protocol blocking for AIM, ICQ, IRC and a > bunch of other of those protocols into it's high-end IOS. It works > by examining the packets themselves so setting the AIM client to use > port 80 to find an AIM server so as to sidestep the blocks is useless. > It will only be a matter of time before you will see this technology > appear in the low-end Cisco AKA Linksys gear that sells for under $300. > > Secondly, your average business owner does not want to have the IP > handcuffs on him. If he gets pissed off at his ISP he wants the > ability to call another ISP competitor and move his connection to > the competitor without the expense of renumbering his internal network. > > In the United States today, the market for networking gear sold to > the SOHO under-100 employee firms EXCEEDS the dollar value of the > market for networking gear sold to the traditional enterprise. Intel > has been studying this market for years and they saw the SOHO > exceed the enterprise sometime back in 1998 (I do not know if Intel > ever declassified these marketing studies but I know they exist) > that is why they got into that market. A lot of other networking > firms that kept focusing on the enterprise (can you say Bay Networks, > Cabletron, etc.) went bankrupt. > > It is of course, true that large enterprises with 1000's of desktops > will want to be multihomed and thus will want to get their own AS > and own portable numbering, and thus are very interested in the IPv6 > issues. But they are a market minority. The majority of businesses > are not like this and even if all ISP's switch over to IPv6 and > all business do likewise, your still going to see a very large demand > for NAT devices. Even if they are nothing more than 1:1 IPv6 > translators. > > If you could rework the document to include this issue it might be > usable to a much wider audience. > > Ted > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >> JORDI PALET MARTINEZ >> Sent: Wednesday, June 27, 2007 12:03 PM >> To: ppml at arin.net >> Subject: [ppml] The Choice: IPv4 Exhaustion or Transition to IPv6 >> >> >> Hi all, >> >> I've published a document trying to analyze the IPv4 exhaustion problem and >> what is ahead of us, considering among others, changes in policies. >> >> http://www.ipv6tf.org/index.php?page=news/newsroom&id=3004 >> >> I guess this could be useful in order to understand possible >> implications of >> modifying existing policies, or setting up new ones, or even just to create >> some debate about those changes. >> >> The document was completed last April, but didn't had the time to tidy up >> until a few days ago. >> >> Regards, >> Jordi >> >> >> >> >> >> >> ********************************************** >> The IPv6 Portal: http://www.ipv6tf.org >> >> Bye 6Bone. Hi, IPv6 ! >> http://www.ipv6day.org >> >> This electronic message contains information which may be >> privileged or confidential. The information is intended to be for >> the use of the individual(s) named above. If you are not the >> intended recipient be aware that any disclosure, copying, >> distribution or use of the contents of this information, including >> attached files, is prohibited. >> >> >> >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml >> > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From bicknell at ufp.org Thu Jun 28 16:43:55 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 28 Jun 2007 16:43:55 -0400 Subject: [ppml] draft-ietf-ipv6-ula-central-02.txt use cases In-Reply-To: <4682E573.7010300@internap.com> References: <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <4681B179.2020301@internap.com> <024b01c7b876$94b06b70$443816ac@atlanta.polycom.com> <4682E573.7010300@internap.com> Message-ID: <20070628204355.GA47796@ussenterprise.ufp.org> In a message written on Wed, Jun 27, 2007 at 03:32:19PM -0700, Scott Leibrand wrote: > Then why aren't we routing 10/8 yet? And what about ULA-L? Does that > need to be abolished as well? If private space is indistinguishable (by > routers) from public space, then such space will indeed end up being > routed. But if I can simply add "deny FC00::/7" to my bogon filter, > then I need never see such routes. There's a funamental difference between 10/8 (and, to a degree ULA-L) and ULA-C. If we both inject 10/8 into the DFZ today, we will have a collision. If we both inject a ULA-L prefix into the DFZ, there's a reasonable chance we will have a collision (statistics aside, most people are going to ignore the random number thing and start at predictable bit boundaries). No DFZ provider is going to tolerate collisions and the troubleshooting it brings. However, ULA-C's entire purpose is to guarantee uniqueness. DFZ providers will not have to fear a collision at all, only that the route may be filtered somewhere down your line. A large number of businesses have been built on "pay your money and take your chances", and I think many people will route ULA-C's under that mantra. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From bicknell at ufp.org Thu Jun 28 16:49:10 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 28 Jun 2007 16:49:10 -0400 Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration Incentive Address Space In-Reply-To: <3c3e3fca0706280832q3b98e0d6u3f84507856bf6990@mail.gmail.com> References: <3c3e3fca0706261303s74d39ccqed8f591727a90cee@mail.gmail.com> <46818179.3000000@internap.com> <3c3e3fca0706262050o8c9accl7139ca4e75e94d2c@mail.gmail.com> <4682A982.3050702@bogomips.com> <3c3e3fca0706280832q3b98e0d6u3f84507856bf6990@mail.gmail.com> Message-ID: <20070628204910.GB47796@ussenterprise.ufp.org> In a message written on Thu, Jun 28, 2007 at 11:32:21AM -0400, William Herrin wrote: > 6to4 Problem #1: Implementation of 6to4 is an optional component of > the IPv6 protocol. Devices confronted with a 2002:: address may but > need not recognize that packets to such a destination should be > encapsulated in an IPv4 packet. The Migration Incentive Space proposal > is intended to rely on only those components of IPv6 which are > mandatory. My (limited) understanding of 6to4 is that devices on the IPv6 side are supposed to treat the addresses as if they were any other IPv6 address, i.e. there is nothing special for an IPv6 host. It's only in the device that provides the gateway serivce from IPv6 to IPv4 (the destination of the 2002:: route) that special code is required. > 6to4 Problem #2: Its unclear whether the authors of RFC 3056 intended > that it be possilble for prefixes within 2002:: to be announced into > the global IPv6 BGP table so that all native IPv6 networks could reach > such hosts without IPv4 encapsulation. Indeed, some parts of the > document suggest that an available IPv6 route should NOT take priority > over encapsulation. For 6to4 to reasonably replace the Migration > Incentive Space, it would need to be clarified that ARIN encourages > IPv4 holders to announce an appropriately selected 2002:: route, that > remote IPv6 systems should give native IPv6 routes to 2002:: > destinations priorirty over the encalsulated IPv4 route, and that ARIN > intends such blocks within 2002:: to have the same validity as any > other IPv6 block they assign or allocate. Following on to #1, on the IPv6 side the routes are normal routes. This allows you to have a single 6to4 gateway and carry 2002:: across your network to all of your sites/subnets. I believe the intentionw as to actually have the (single) route in the DFZ, or at least, each provider putting its own route in its own network to a 6to4 gateway. > 6to4 Problem #4: ARIN does not control the reverse DNS for 6to4 > prefixes associated with the IPv4 blocks which ARIN manages. It is > presently managed by the NRO, an organization in which ARIN > participates (see https://6to4.nro.net/). The documentation for 6to4 > reverse dns states that, "This password is not mandatory when the site > is accessed from inside your 6to4 source address. It is intended to > prevent an arbitrary access from locking out the domain if the address > is not static. (It is recognized that this places far less trust than > normal in the correctness of a 6to4 delegation)." For 6to4 to work as > a replacement for the Migration Incentive Space, reverse DNS for the > blocks under ARIN's authority would need to be operated with a degree > of security and access comperable to what ARIN applies to its normal > delegation of reverse DNS. Agreed. > So, the question I put to you and to the others who have suggested > 6to4 is this: Do we seek changes and clarifications to address these > four problems or do we drop 6to4 from consideration as an alternative > to the Migration Incentive Space proposal? I would like someone with much more familiariaty with 6to4 to comment. It might be worth engaging some of the original authors. Clearly we don't want to break 6to4 as an option, however it seems to me there may be a path to sanity here... -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From owen at delong.com Thu Jun 28 16:53:48 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Jun 2007 13:53:48 -0700 Subject: [ppml] Fwd: Policy Proposal: Resource Reclamation Incentives References: <01FAB7DC-99F9-4B97-AE6C-409F4F4D1288@delong.com> Message-ID: <70150C4C-DA2D-4015-AAD3-99DA485A25BC@delong.com> Originally this was a reply to a private message from Celeste, but, I received her permission to post it. Owen Begin forwarded message: > From: Owen DeLong > Date: June 28, 2007 11:23:44 AM PDT (CA) > To: Celeste Anderson > Subject: Re: [ppml] Policy Proposal: Resource Reclamation Incentives > > > On Jun 28, 2007, at 10:36 AM, Celeste Anderson wrote: > >> Owen, >> >> "Organizations taking this election shall be subject to end-user >> fees for their IPv4 resources not previously under an ARIN RSA. >> If they are already an ARIN subscriber, then IPv4 resources >> affected by this process may, instead, be added to their existing >> subscriber agreement at the address holder's discretion." >> >> Not sure making the legacy IPv4 address space subject to new RSA >> rules (section 4) will be attractive to those holding large blocks. >> > Maybe not. However, if they want free IPv6 space, that's the price > they pay. > > Doesn't seem an unreasonable trade to me. > >> If the desired result is to get legacy holders to return unused or >> underutilized IPv4 address space AND to start migrating to IPv6 >> space, I would suggest waiving fees for their IPv4 allocation (in >> other words keeping the legacy status), and just making them pay >> for the IPv6 fees for the new IPv6 allocation. >> > The policy fully allows the first half without any cost or RSA > consequences. > If they want to pay full price for their IPv6 space, then, they can > still take > advantage of the return policy and get IPv6 space without > subjecting their > remaining IPv4 resources to the RSA. > > Basically, this allows the legacy holder to have whichever combination > best suits their needs, but, one of the key purposes of this proposal > is to encourage legacy holders to move IPv4 resources under RSA > control if possible. > > So... There are three key purposes to this proposal: > > 1. Encourage legacy holders with unused IPv4 space to return > it. > > This can be done without any additional RSA or fee consequences > to the legacy holder. In fact, we offer free IPv4 registration > services > to them for some time if they are currently paying fees. (We can't > exactly reduce the fees of someone who doesn't currently pay > anything, so, not sure what I can offer there). > > 2. Encourage legacy holders to move their existing resources > under ARIN RSA management > > 3. Encourage legacy holders to obtain and utilize IPv6 addresses. > > Objectives 2 and 3 are somewhat combined in that we offer free IPv6 > resources for some time in exchange for compliance with Objective 2. > > Owen > >> Just my two cents :) >> >> Celeste. >> >> >> ----- Original Message ----- From: "Owen DeLong" >> To: "ARIN Address Policy" ; >> Sent: Thursday, June 28, 2007 9:34 AM >> Subject: [ppml] Policy Proposal: Resource Reclamation Incentives >> >> >>> Here's an attempt to partially drain the swamp and create some >>> incentives >>> for legacy holders to both return available IPv4 space and start >>> using >>> IPv6. >>> >>> Comments welcome. >>> >>> Owen >>> >>> >>> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 >>> >>> >>> Policy Proposal Name: Legacy Outreach and Partial Reclamation >>> Author >>> name: Owen DeLong >>> email: owen at delong.com >>> telephone: 408-921-6984 >>> organization: JITTR Networks >>> >>> Proposal Version: 0.0.1 >>> Submission Date: 2007 April 22 >>> Proposal type: M >>> new, modify, or delete. >>> Policy term: permanent >>> temporary, permanent, or renewable. >>> Policy statement: >>> Modify section 4.6 as follows: >>> >>> 4.6 Amnesty Requests >>> ARIN will accept the return or relinquishment of any address space >>> from any existing address holder. If the address holder wishes to >>> aggregate into a single block, ARIN may work with the address holder >>> to arrive at an allocation or assignment which is equal to or >>> smaller >>> than the sum of their existing blocks and which best meets the needs >>> of the existing holder and the community. There shall be no fee for >>> returning addresses under this policy. Further, organizations >>> returning addresses under this policy shall receive the following >>> benefits: >>> >>> 1. If the organization does not currently pay ARIN >>> fees, they shall remain fee exempt. >>> >>> 2. If the organization currently pays ARIN fees, >>> their fees shall be waived for two years for >>> each /20 equivalent returned, with any fractional /20 >>> equivalent resulting in a one-time single year waiver. >>> >>> 3. Any organization returning address space under >>> this policy shall continue under their existing >>> RSA or they may choose to sign the current RSA. >>> For organizations which currently do not >>> have an RSA, they may sign the current RSA, or, >>> they may choose to remain without an RSA. >>> >>> 4. All organizations returning space under this >>> policy shall, if they meet other eligibility >>> requirements and so request, obtain an >>> appropriate IPv6 end-user assignment >>> or ISP allocation as applicable, with no fees >>> for the first 5 years. Organizations electing >>> to receive IPv6 allocation/assignment under >>> this provision must sign a current RSA and >>> must agree that all of their IPv4 resources are >>> henceforth subject to the RSA. Organizations >>> taking this election shall be subject to end-user >>> fees for their IPv4 resources not previously >>> under an ARIN RSA. If they are already an >>> ARIN subscriber, then IPv4 resources >>> affected by this process may, instead, be added to >>> their existing subscriber agreement at the >>> address holder's discretion. >>> >>> Rationale: >>> >>> The current amnesty policy does a nice job of facilitating >>> aggregation, which was the intent when it was drafted. However, >>> as we approach IPv4 free-space exhaustion, the community now >>> has an additional need to facilitate address reclamation. >>> >>> A very high percentage of underutilized space is in the hands of >>> legacy holders who currently have no benefit to joining the ARIN >>> process. Further, there is an unfortunate perception that doing >>> so will require force the legacy holder into certain future >>> disadvantages. >>> This proposal attempts to resolve both of those issues while also >>> providing some incentive to legacy organizations to start using >>> IPv6 resources and bring their IPv4 resources into the ARIN >>> process. >>> >>> This policy attempts to provide some benefit and remove most of >>> the costs of making partial IPv4 returns. It also attempts to >>> provide an incentive for these IPv4 holders to join the ARIN >>> process. >>> >>> Timetable for implementation: >>> >>> Immediate >>> >>> Meeting presenter: >>> >>> TBD, probably Owen DeLong >>> >>> END OF TEMPLATE >>> _______________________________________________ >>> This message sent to you through the ARIN Public Policy Mailing List >>> (PPML at arin.net). >>> Manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/ppml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at vix.com Thu Jun 28 16:53:31 2007 From: paul at vix.com (Paul Vixie) Date: Thu, 28 Jun 2007 20:53:31 +0000 Subject: [ppml] draft-ietf-ipv6-ula-central-02.txt use cases In-Reply-To: Your message of "Thu, 28 Jun 2007 16:43:55 -0400." <20070628204355.GA47796@ussenterprise.ufp.org> References: <467FDEAA.1020503@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com> <467FE693.5060103@spaghetti.zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com> <46805763.6040708@apnic.net> <4681B179.2020301@internap.com> <024b01c7b876$94b06b70$443816ac@atlanta.polycom.com> <4682E573.7010300@internap.com> <20070628204355.GA47796@ussenterprise.ufp.org> Message-ID: <66984.1183064011@sa.vix.com> > ..., ULA-C's entire purpose is to guarantee uniqueness. DFZ providers will > not have to fear a collision at all, only that the route may be filtered > somewhere down your line. A large number of businesses have been built on > "pay your money and take your chances", and I think many people will route > ULA-C's under that mantra. we already know that it'll cross a lot of private peering AS boundaries. but as to whether it'll reach the DFZ reliably, i don't know, and does anybody care at this stage, since any of us who want to filter it will have an RFC to point to as our defense? From bicknell at ufp.org Thu Jun 28 17:10:58 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 28 Jun 2007 17:10:58 -0400 Subject: [ppml] Policy Proposal: Resource Reclamation Incentives In-Reply-To: <371EB4EE-C2FE-46CD-BAF9-DB35937B572A@delong.com> References: <371EB4EE-C2FE-46CD-BAF9-DB35937B572A@delong.com> Message-ID: <20070628211058.GC47796@ussenterprise.ufp.org> In a message written on Thu, Jun 28, 2007 at 09:34:02AM -0700, Owen DeLong wrote: > 1. If the organization does not currently pay ARIN > fees, they shall remain fee exempt. I'm not strongly opposed to this point, however I question it's value. ARIN implemented a $100 maintenance fee I believe largely as a yearly "touch point" after previous expereince with no-fee resources lead to many out of date records. I'm totally down with waving initial fees and maybe even a year or two, but I can't imagine $100 going forward makes a big difference to anyone. > 2. If the organization currently pays ARIN fees, > their fees shall be waived for two years for > each /20 equivalent returned, with any fractional /20 > equivalent resulting in a one-time single year waiver. I'd roll #1 and #2 into "Pays no fees for two years." Short, simple. Again though, not enough to make me not support the proposal. > 3. Any organization returning address space under > this policy shall continue under their existing > RSA or they may choose to sign the current RSA. > For organizations which currently do not > have an RSA, they may sign the current RSA, or, > they may choose to remain without an RSA. I strongly object to giving out any new resource that is not covered by an RSA. That's a deal breaker for me. > 4. All organizations returning space under this > policy shall, if they meet other eligibility > requirements and so request, obtain an > appropriate IPv6 end-user assignment > or ISP allocation as applicable, with no fees > for the first 5 years. Organizations electing > to receive IPv6 allocation/assignment under > this provision must sign a current RSA and > must agree that all of their IPv4 resources are > henceforth subject to the RSA. Organizations > taking this election shall be subject to end-user > fees for their IPv4 resources not previously > under an ARIN RSA. If they are already an > ARIN subscriber, then IPv4 resources > affected by this process may, instead, be added to > their existing subscriber agreement at the > address holder's discretion. Sounds good. I really like the concept here of finding a way to provide an incentive to turn in old space for newer, more aggregateable, more usable (IPv6) going forward. However I feel very strongly we need RSA's in place for new resources, the lack of one was a major mistaken in the past we can't repeat. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From owen at delong.com Thu Jun 28 17:28:02 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Jun 2007 14:28:02 -0700 Subject: [ppml] Policy Proposal: Resource Reclamation Incentives In-Reply-To: <20070628211058.GC47796@ussenterprise.ufp.org> References: <371EB4EE-C2FE-46CD-BAF9-DB35937B572A@delong.com> <20070628211058.GC47796@ussenterprise.ufp.org> Message-ID: <8CD91D80-2E99-44CC-88B5-BE7FDFEDA803@delong.com> Sorry for multiple posts on this, but Leo raises some new questions and I would like to address those. I'll try not to repeat my previous comments. On Jun 28, 2007, at 2:10 PM, Leo Bicknell wrote: > In a message written on Thu, Jun 28, 2007 at 09:34:02AM -0700, Owen > DeLong wrote: >> 1. If the organization does not currently pay ARIN >> fees, they shall remain fee exempt. > > I'm not strongly opposed to this point, however I question it's > value. ARIN implemented a $100 maintenance fee I believe largely > as a yearly "touch point" after previous expereince with no-fee > resources lead to many out of date records. I'm totally down with > waving initial fees and maybe even a year or two, but I can't imagine > $100 going forward makes a big difference to anyone. > Yes, however, faced with the choice between return some address space and pay $100/year and keep your address space and continue to pay nothing, which would you choose? Which do you think most people would choose? >> 2. If the organization currently pays ARIN fees, >> their fees shall be waived for two years for >> each /20 equivalent returned, with any fractional /20 >> equivalent resulting in a one-time single year waiver. > > I'd roll #1 and #2 into "Pays no fees for two years." Short, simple. > Again though, not enough to make me not support the proposal. > See justification for number 1 as to why this isn't a good idea. Further, I wanted to create some incentive to return as much space as possible, hence two years per /20 equivalent. >> 3. Any organization returning address space under >> this policy shall continue under their existing >> RSA or they may choose to sign the current RSA. >> For organizations which currently do not >> have an RSA, they may sign the current RSA, or, >> they may choose to remain without an RSA. > > I strongly object to giving out any new resource that is not covered > by an RSA. That's a deal breaker for me. > This isn't giving any new resources out. It's allowing them to return space without penalty. My intent here isn't to give away the store, it's to remove as many barriers to address return as possible while still providing some incentives to join into the ARIN process. In like 99% of these cases, the space retained would be an existing prefix or a fraction of an existing prefix. In those 1% cases where we hand out, say a new /20 in trade for a 50 or 60 discreet class C's, I think I'd rather have one /20 out there without an RSA and reclaim the 50 or 60 class C's than keep the existing 50 or 60 class C's out there without an RSA. If you think this through, I suspect you would, too. This policy does not in any way provide for someone to get more space than they already have or expand their current space without returning at least as much as they are receiving. >> 4. All organizations returning space under this >> policy shall, if they meet other eligibility >> requirements and so request, obtain an >> appropriate IPv6 end-user assignment >> or ISP allocation as applicable, with no fees >> for the first 5 years. Organizations electing >> to receive IPv6 allocation/assignment under >> this provision must sign a current RSA and >> must agree that all of their IPv4 resources are >> henceforth subject to the RSA. Organizations >> taking this election shall be subject to end-user >> fees for their IPv4 resources not previously >> under an ARIN RSA. If they are already an >> ARIN subscriber, then IPv4 resources >> affected by this process may, instead, be added to >> their existing subscriber agreement at the >> address holder's discretion. > > Sounds good. > > I really like the concept here of finding a way to provide an > incentive to turn in old space for newer, more aggregateable, more > usable (IPv6) going forward. However I feel very strongly we need > RSA's in place for new resources, the lack of one was a major > mistaken in the past we can't repeat. > While I agree, I don't see this as repeating that mistake so much as providing a way to narrow the scope of the existing mistake while not penalizing people for doing the right thing. I tried very hard to make this policy something that gains ground from where we are now while removing as many barriers to progress for legacy holders as I could. Note that to get IPv6 space for free, they have to move their IPv4 resources all under current RSA. If they just want to return IPv4 resources and don't want to sign an RSA for the ones they keep, I really don't see how that is an any way not better than forcing them to keep all their existing IPv4 resources to avoid signing the RSA. Owen From bicknell at ufp.org Thu Jun 28 17:45:16 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 28 Jun 2007 17:45:16 -0400 Subject: [ppml] Policy Proposal: Resource Reclamation Incentives In-Reply-To: <8CD91D80-2E99-44CC-88B5-BE7FDFEDA803@delong.com> References: <371EB4EE-C2FE-46CD-BAF9-DB35937B572A@delong.com> <20070628211058.GC47796@ussenterprise.ufp.org> <8CD91D80-2E99-44CC-88B5-BE7FDFEDA803@delong.com> Message-ID: <20070628214515.GA52422@ussenterprise.ufp.org> In a message written on Thu, Jun 28, 2007 at 02:28:02PM -0700, Owen DeLong wrote: > Yes, however, faced with the choice between return some address space > and pay $100/year and keep your address space and continue to pay > nothing, which would you choose? > > Which do you think most people would choose? I feeling is $100/year going forward is not a major decision making factor for most people, and the ROI if you got the $1250 intial fees waved for a new allocation (of for instance IPv6 space) is 12 years, which isn't bad. > >> 3. Any organization returning address space > >> under > >> this policy shall continue under their > >> existing > >> RSA or they may choose to sign the current > >> RSA. > >> For organizations which currently do not > >> have an RSA, they may sign the current RSA, > >> or, > >> they may choose to remain without an RSA. > > > >I strongly object to giving out any new resource that is not covered > >by an RSA. That's a deal breaker for me. > > > This isn't giving any new resources out. It's allowing them to return > space without penalty. My intent here isn't to give away > the store, it's to remove as many barriers to address return as possible > while still providing some incentives to join into the ARIN process. Ok, you referenced Amnesty, which is section 4.6, and so that was on my brain. In 4.6 you can turn in space and get new space (potentially a smaller, and/or contiguous block) back. I am ok with someone not having to sign an RSA if the only action is to return space. In that case I think section 3 is grossly over specified: 3. Return of an address block should not change the relationship between ARIN and the organization for any blocks not being returned. However, perhaps it would be better if you crafted a replacement for 4.6, which kept the current trade in arrangement, and left us with a single cohesive 4.6 between what is there now and your proposal. > In like 99% of these cases, the space retained would be an existing > prefix or a fraction of an existing prefix. In those 1% cases where we > hand out, say a new /20 in trade for a 50 or 60 discreet class C's, I > think I'd rather have one /20 out there without an RSA and reclaim > the 50 or 60 class C's than keep the existing 50 or 60 class C's out > there without an RSA. If you think this through, I suspect you would, > too. This policy does not in any way provide for someone to get > more space than they already have or expand their current > space without returning at least as much as they are receiving. Nope. Nothing new going out without an RSA. I'm quite firm on that point. I'm fairly positive I'll strongly oppose any policy that tries to give out anything not under an RSA. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stephen at sprunk.org Thu Jun 28 18:47:17 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 28 Jun 2007 17:47:17 -0500 Subject: [ppml] draft-ietf-ipv6-ula-central-02.txt use cases References: <467FDEAA.1020503@spaghetti.zurich.ibm.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED8B9@XCH-NW-7V2.nw.nos.boeing.com><467FE693.5060103@spaghetti.zurich.ibm.com><39C363776A4E8C4A94691D2BD9D1C9A1029ED8BB@XCH-NW-7V2.nw.nos.boeing.com><46805763.6040708@apnic.net><4681B179.2020301@internap.com><024b01c7b876$94b06b70$443816ac@atlanta.polycom.com><4682E573.7010300@internap.com><20070628204355.GA47796@ussenterprise.ufp.org> <66984.1183064011@sa.vix.com> Message-ID: <049001c7b9d8$f3a834b0$573816ac@atlanta.polycom.com> Thus spake "Paul Vixie" > we already know that [ULA-C will] cross a lot of private peering > AS boundaries. but as to whether it'll reach the DFZ reliably, i > don't know, and does anybody care at this stage, since any of > us who want to filter it will have an RFC to point to as our > defense? How well will that defense work when you've got a half-million customers flooding your support desk because the hot new website of the day (MySpace, YouTube, etc) is on ULA-C space and you're blocking it -- but your competitors aren't? Users couldn't care less about RFCs; all they know is your ISP sucks because they can't get to "the entire Internet". S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From jmorrison at bogomips.com Thu Jun 28 19:45:27 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Thu, 28 Jun 2007 16:45:27 -0700 Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration Incentive Address Space In-Reply-To: <3c3e3fca0706280832q3b98e0d6u3f84507856bf6990@mail.gmail.com> References: <3c3e3fca0706261303s74d39ccqed8f591727a90cee@mail.gmail.com> <46818179.3000000@internap.com> <3c3e3fca0706262050o8c9accl7139ca4e75e94d2c@mail.gmail.com> <4682A982.3050702@bogomips.com> <3c3e3fca0706280832q3b98e0d6u3f84507856bf6990@mail.gmail.com> Message-ID: <46844817.9010105@bogomips.com> There are some valid concerns, and I think it would be good to discuss them, since they can be fixed. Quickly: 1. RFC 3056 describes three things: an IPv6 allocation (2002::/16), an IPv4 protocol for tunneling, and specifies some things for routing 2002:: on the IPv6 Internet. This is a lot, and while the first two items are simple, the merits of the last point could certainly be discussed. 2. 6to4 tunelling describes an IPv4 protocol, not an IPv6 one. It's used for IPv6 to traverse IPv4 networks. Only the 6to4 gateway needs to understand how to encapsulate/de-encapsulate the traffic. Any IPv6 stack should work with a 2002: 6to4 address 3. I agree that there are some limitations like DNS delegation, whether it's permanent, 6to4 prefixes on the native IPv6 Internet. These last points are not built into IPv6 and are a matter of policy or current practice. It would be worthwhile to address in terms of policy or revising the RFC. More detailed verbiage: I emailed the RFC author's and a big concern was "importing the IPv4 swamp" into the IPv6 routing tables. It's a nice idea, but I'm not sure it's the best place to mandate this. Since ISPs typically filter IPv4 prefixes longer than /24, it doesn't seem necessary to stipulate this at all in the RFC. The equivalent would be to filter on /40 prefixes for routes imported via 6to4. The only real caveat is that 2002::/16 (and only that one) is a kind of default route (it's really the IPv4 0.0.0.0 route) - so that prefix needs special treatment. Somehow I don't think the IPv4 swamp is going to evaporate - maybe IPv6 with PA addresses will do a great job of cleaning up the routing tables, but I think that's expecting a lot. If everyone goes out and gets new PI address space for v6, then you may just end doubling the routing table size. It seems like a fairly straightforward transition to IPv6 on the Internet backbone by running a single IPv6 routing table, with the existing IPv4 prefixes simply being imported/converted to IPv6 prefixes by prepending 2002:: William Herrin wrote: > On 6/27/07, John Paul Morrison wrote: >> I do not support this proposal as it essentially duplicates the IPv6 >> address space already allocated to IPv4 users, documented in RFC 3056 >> (6to4). > > John, > > First, thank you for privately discussing 6to4's functionality with > me. You were very helpful and informative. > > You are not alone in suggesting that 6to4 might suitably replace the > Migration Incentive Space proposal, however 6to4 has several issues > which would need to be addressed before it could be considered a valid > alternative. I'd like to find if there is a consensus on ppml as to > whether those issues should be addressed in 6to4. If they should, I'll > start working on such a proposal with the intent that it replace the > Migration Incentive Space proposal. If they should not, then I would > ask that 6to4 be considered irrelevant to and dropped from the > discussion. > > 6to4 Problem #1: Implementation of 6to4 is an optional component of > the IPv6 protocol. Devices confronted with a 2002:: address may but > need not recognize that packets to such a destination should be > encapsulated in an IPv4 packet. The Migration Incentive Space proposal > is intended to rely on only those components of IPv6 which are > mandatory. > > 6to4 Problem #2: Its unclear whether the authors of RFC 3056 intended > that it be possilble for prefixes within 2002:: to be announced into > the global IPv6 BGP table so that all native IPv6 networks could reach > such hosts without IPv4 encapsulation. Indeed, some parts of the > document suggest that an available IPv6 route should NOT take priority > over encapsulation. For 6to4 to reasonably replace the Migration > Incentive Space, it would need to be clarified that ARIN encourages > IPv4 holders to announce an appropriately selected 2002:: route, that > remote IPv6 systems should give native IPv6 routes to 2002:: > destinations priorirty over the encalsulated IPv4 route, and that ARIN > intends such blocks within 2002:: to have the same validity as any > other IPv6 block they assign or allocate. > > 6to4 Problem #3: Its unclear whether the authors of RFC 3056 intended > that prefixes within 2002:: continue to exist in IPv4's > post-exhaustion phase when IPv6 has become the dominant protocol. The > Migration Incentive Space is intended to be a permanant solution whose > addresses continue to see use after IPv4's end of life. > > 6to4 Problem #4: ARIN does not control the reverse DNS for 6to4 > prefixes associated with the IPv4 blocks which ARIN manages. It is > presently managed by the NRO, an organization in which ARIN > participates (see https://6to4.nro.net/). The documentation for 6to4 > reverse dns states that, "This password is not mandatory when the site > is accessed from inside your 6to4 source address. It is intended to > prevent an arbitrary access from locking out the domain if the address > is not static. (It is recognized that this places far less trust than > normal in the correctness of a 6to4 delegation)." For 6to4 to work as > a replacement for the Migration Incentive Space, reverse DNS for the > blocks under ARIN's authority would need to be operated with a degree > of security and access comperable to what ARIN applies to its normal > delegation of reverse DNS. > > So, the question I put to you and to the others who have suggested > 6to4 is this: Do we seek changes and clarifications to address these > four problems or do we drop 6to4 from consideration as an alternative > to the Migration Incentive Space proposal? > > Regards, > Bill Herrin > From scott.beuker at sjrb.ca Thu Jun 28 20:27:58 2007 From: scott.beuker at sjrb.ca (Scott Beuker) Date: Thu, 28 Jun 2007 18:27:58 -0600 Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration Incentive Address Space In-Reply-To: <3c3e3fca0706280832q3b98e0d6u3f84507856bf6990@mail.gmail.com> Message-ID: William, The most fundamental problem I have with your proposal is the inefficiencies of automatic IPv6 assignments via translation from IPv4. One of the benefits we should hope to achieve from a transition to IPv6 is to reduce the fragmentation of assignments in the IPv4 space. So the status quo of having organizations apply for and receive a single IPv6 assignment from ARIN is highly desirable. As has been stated, approval for IPv6 address space shouldn't be a stumbling block for anyone who has IPv4 space. In light of this, the rest of the proposal is moot, because it seems the crux is the automatic mapping of address space. But I do applaud anyone making an effort to move IPv6 adoption forward, and hope you will continue your work. I just think you may need to go back to the drawing board on this one. Thanks, Scott Beuker Network Architect, IP Backbone Shaw Internet Engineering -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Thursday, June 28, 2007 9:32 AM To: John Paul Morrison Cc: ppml at arin.net Subject: Re: [ppml] Solicing comments: IPv4 to IPv6 Migration Incentive Address Space On 6/27/07, John Paul Morrison wrote: > I do not support this proposal as it essentially duplicates the IPv6 > address space already allocated to IPv4 users, documented in RFC 3056 > (6to4). John, First, thank you for privately discussing 6to4's functionality with me. You were very helpful and informative. You are not alone in suggesting that 6to4 might suitably replace the Migration Incentive Space proposal, however 6to4 has several issues which would need to be addressed before it could be considered a valid alternative. I'd like to find if there is a consensus on ppml as to whether those issues should be addressed in 6to4. If they should, I'll start working on such a proposal with the intent that it replace the Migration Incentive Space proposal. If they should not, then I would ask that 6to4 be considered irrelevant to and dropped from the discussion. 6to4 Problem #1: Implementation of 6to4 is an optional component of the IPv6 protocol. Devices confronted with a 2002:: address may but need not recognize that packets to such a destination should be encapsulated in an IPv4 packet. The Migration Incentive Space proposal is intended to rely on only those components of IPv6 which are mandatory. 6to4 Problem #2: Its unclear whether the authors of RFC 3056 intended that it be possilble for prefixes within 2002:: to be announced into the global IPv6 BGP table so that all native IPv6 networks could reach such hosts without IPv4 encapsulation. Indeed, some parts of the document suggest that an available IPv6 route should NOT take priority over encapsulation. For 6to4 to reasonably replace the Migration Incentive Space, it would need to be clarified that ARIN encourages IPv4 holders to announce an appropriately selected 2002:: route, that remote IPv6 systems should give native IPv6 routes to 2002:: destinations priorirty over the encalsulated IPv4 route, and that ARIN intends such blocks within 2002:: to have the same validity as any other IPv6 block they assign or allocate. 6to4 Problem #3: Its unclear whether the authors of RFC 3056 intended that prefixes within 2002:: continue to exist in IPv4's post-exhaustion phase when IPv6 has become the dominant protocol. The Migration Incentive Space is intended to be a permanant solution whose addresses continue to see use after IPv4's end of life. 6to4 Problem #4: ARIN does not control the reverse DNS for 6to4 prefixes associated with the IPv4 blocks which ARIN manages. It is presently managed by the NRO, an organization in which ARIN participates (see https://6to4.nro.net/). The documentation for 6to4 reverse dns states that, "This password is not mandatory when the site is accessed from inside your 6to4 source address. It is intended to prevent an arbitrary access from locking out the domain if the address is not static. (It is recognized that this places far less trust than normal in the correctness of a 6to4 delegation)." For 6to4 to work as a replacement for the Migration Incentive Space, reverse DNS for the blocks under ARIN's authority would need to be operated with a degree of security and access comperable to what ARIN applies to its normal delegation of reverse DNS. So, the question I put to you and to the others who have suggested 6to4 is this: Do we seek changes and clarifications to address these four problems or do we drop 6to4 from consideration as an alternative to the Migration Incentive Space proposal? Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From sleibrand at internap.com Thu Jun 28 20:34:37 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 28 Jun 2007 17:34:37 -0700 Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration Incentive Address Space In-Reply-To: <46844817.9010105@bogomips.com> References: <3c3e3fca0706261303s74d39ccqed8f591727a90cee@mail.gmail.com> <46818179.3000000@internap.com> <3c3e3fca0706262050o8c9accl7139ca4e75e94d2c@mail.gmail.com> <4682A982.3050702@bogomips.com> <3c3e3fca0706280832q3b98e0d6u3f84507856bf6990@mail.gmail.com> <46844817.9010105@bogomips.com> Message-ID: <4684539D.1030408@internap.com> John and William, I don't have a lot of experience with it myself, but I recall reading awhile back that a lot of the 2002::/16 "default" routes on the IPv6 Internet today are broken in one way or another, such than 6to4 service is quite unreliable. Perhaps others on the list can elaborate on that... -Scott John Paul Morrison wrote: > There are some valid concerns, and I think it would be good to discuss > them, since they can be fixed. > > Quickly: > > 1. RFC 3056 describes three things: an IPv6 allocation (2002::/16), an > IPv4 protocol for tunneling, and specifies some things for routing > 2002:: on the IPv6 Internet. > This is a lot, and while the first two items are simple, the merits of > the last point could certainly be discussed. > > 2. 6to4 tunelling describes an IPv4 protocol, not an IPv6 one. It's used > for IPv6 to traverse IPv4 networks. Only the 6to4 gateway needs to > understand > how to encapsulate/de-encapsulate the traffic. Any IPv6 stack should > work with a 2002: 6to4 address > > 3. I agree that there are some limitations like DNS delegation, whether > it's permanent, 6to4 prefixes on the native IPv6 Internet. > These last points are not built into IPv6 and are a matter of policy or > current practice. It would be worthwhile to address in terms of policy > or revising the RFC. > > More detailed verbiage: > > I emailed the RFC author's and a big concern was "importing the IPv4 > swamp" into the IPv6 routing tables. It's a nice idea, but I'm not sure > it's the best place to mandate this. > Since ISPs typically filter IPv4 prefixes longer than /24, it doesn't > seem necessary to stipulate this at all in the RFC. The equivalent would > be to filter on /40 prefixes for routes imported via 6to4. The only real > caveat is that 2002::/16 (and only that one) is a kind of default route > (it's really the IPv4 0.0.0.0 route) - so that prefix needs special > treatment. > Somehow I don't think the IPv4 swamp is going to evaporate - maybe IPv6 > with PA addresses will do a great job of cleaning up the routing tables, > but I think that's expecting a lot. If everyone goes out and gets new PI > address space for v6, then you may just end doubling the routing table > size. > > It seems like a fairly straightforward transition to IPv6 on the > Internet backbone by running a single IPv6 routing table, with the > existing IPv4 prefixes simply > being imported/converted to IPv6 prefixes by prepending 2002:: > > > > > William Herrin wrote: > >> On 6/27/07, John Paul Morrison wrote: >> >>> I do not support this proposal as it essentially duplicates the IPv6 >>> address space already allocated to IPv4 users, documented in RFC 3056 >>> (6to4). >>> >> John, >> >> First, thank you for privately discussing 6to4's functionality with >> me. You were very helpful and informative. >> >> You are not alone in suggesting that 6to4 might suitably replace the >> Migration Incentive Space proposal, however 6to4 has several issues >> which would need to be addressed before it could be considered a valid >> alternative. I'd like to find if there is a consensus on ppml as to >> whether those issues should be addressed in 6to4. If they should, I'll >> start working on such a proposal with the intent that it replace the >> Migration Incentive Space proposal. If they should not, then I would >> ask that 6to4 be considered irrelevant to and dropped from the >> discussion. >> >> 6to4 Problem #1: Implementation of 6to4 is an optional component of >> the IPv6 protocol. Devices confronted with a 2002:: address may but >> need not recognize that packets to such a destination should be >> encapsulated in an IPv4 packet. The Migration Incentive Space proposal >> is intended to rely on only those components of IPv6 which are >> mandatory. >> >> 6to4 Problem #2: Its unclear whether the authors of RFC 3056 intended >> that it be possilble for prefixes within 2002:: to be announced into >> the global IPv6 BGP table so that all native IPv6 networks could reach >> such hosts without IPv4 encapsulation. Indeed, some parts of the >> document suggest that an available IPv6 route should NOT take priority >> over encapsulation. For 6to4 to reasonably replace the Migration >> Incentive Space, it would need to be clarified that ARIN encourages >> IPv4 holders to announce an appropriately selected 2002:: route, that >> remote IPv6 systems should give native IPv6 routes to 2002:: >> destinations priorirty over the encalsulated IPv4 route, and that ARIN >> intends such blocks within 2002:: to have the same validity as any >> other IPv6 block they assign or allocate. >> >> 6to4 Problem #3: Its unclear whether the authors of RFC 3056 intended >> that prefixes within 2002:: continue to exist in IPv4's >> post-exhaustion phase when IPv6 has become the dominant protocol. The >> Migration Incentive Space is intended to be a permanant solution whose >> addresses continue to see use after IPv4's end of life. >> >> 6to4 Problem #4: ARIN does not control the reverse DNS for 6to4 >> prefixes associated with the IPv4 blocks which ARIN manages. It is >> presently managed by the NRO, an organization in which ARIN >> participates (see https://6to4.nro.net/). The documentation for 6to4 >> reverse dns states that, "This password is not mandatory when the site >> is accessed from inside your 6to4 source address. It is intended to >> prevent an arbitrary access from locking out the domain if the address >> is not static. (It is recognized that this places far less trust than >> normal in the correctness of a 6to4 delegation)." For 6to4 to work as >> a replacement for the Migration Incentive Space, reverse DNS for the >> blocks under ARIN's authority would need to be operated with a degree >> of security and access comperable to what ARIN applies to its normal >> delegation of reverse DNS. >> >> So, the question I put to you and to the others who have suggested >> 6to4 is this: Do we seek changes and clarifications to address these >> four problems or do we drop 6to4 from consideration as an alternative >> to the Migration Incentive Space proposal? >> >> Regards, >> Bill Herrin >> >> > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From jordi.palet at consulintel.es Fri Jun 29 10:02:20 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 29 Jun 2007 10:02:20 -0400 Subject: [ppml] Solicing comments: IPv4 to IPv6 Migration Incentive Address Space In-Reply-To: <4684539D.1030408@internap.com> Message-ID: I'm a frequent user of 6to4, every time I don't have native connectivity and I've a public IPv4 address. Some times it even works with a private IPv4 address if the NAT box is able to do "proto-41-forwarding" (for more info about this look at http://www.euro6ix.org/documentation/euro6ix_co_upm-consulintel_wp4_ipv6_tun nels_nat_v1_6.pdf and http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-proto41-nat-03.txt ). So definitively it is not broken, and the number of 6to4 relays keeps increasing. In fact, I've started a thread at the afripv6-discuss mailing list in order to help to setup 6to4 relay, which become even more important there where the bandwidth is more expensive, because it avoids traffic going thru upstream links. The first message on this is here: https://lists.afrinic.net/pipermail/afripv6-discuss/2007/000061.html More information about 6to4 also available at: http://www.ipv6tf.org/index.php?page=using/connectivity/6to4 Regards, Jordi > De: Scott Leibrand > Responder a: > Fecha: Thu, 28 Jun 2007 17:34:37 -0700 > Para: John Paul Morrison > CC: , William Herrin > Asunto: Re: [ppml] Solicing comments: IPv4 to IPv6 Migration Incentive Address > Space > > John and William, > > I don't have a lot of experience with it myself, but I recall reading > awhile back that a lot of the 2002::/16 "default" routes on the IPv6 > Internet today are broken in one way or another, such than 6to4 service > is quite unreliable. Perhaps others on the list can elaborate on that... > > -Scott > > > John Paul Morrison wrote: >> There are some valid concerns, and I think it would be good to discuss >> them, since they can be fixed. >> >> Quickly: >> >> 1. RFC 3056 describes three things: an IPv6 allocation (2002::/16), an >> IPv4 protocol for tunneling, and specifies some things for routing >> 2002:: on the IPv6 Internet. >> This is a lot, and while the first two items are simple, the merits of >> the last point could certainly be discussed. >> >> 2. 6to4 tunelling describes an IPv4 protocol, not an IPv6 one. It's used >> for IPv6 to traverse IPv4 networks. Only the 6to4 gateway needs to >> understand >> how to encapsulate/de-encapsulate the traffic. Any IPv6 stack should >> work with a 2002: 6to4 address >> >> 3. I agree that there are some limitations like DNS delegation, whether >> it's permanent, 6to4 prefixes on the native IPv6 Internet. >> These last points are not built into IPv6 and are a matter of policy or >> current practice. It would be worthwhile to address in terms of policy >> or revising the RFC. >> >> More detailed verbiage: >> >> I emailed the RFC author's and a big concern was "importing the IPv4 >> swamp" into the IPv6 routing tables. It's a nice idea, but I'm not sure >> it's the best place to mandate this. >> Since ISPs typically filter IPv4 prefixes longer than /24, it doesn't >> seem necessary to stipulate this at all in the RFC. The equivalent would >> be to filter on /40 prefixes for routes imported via 6to4. The only real >> caveat is that 2002::/16 (and only that one) is a kind of default route >> (it's really the IPv4 0.0.0.0 route) - so that prefix needs special >> treatment. >> Somehow I don't think the IPv4 swamp is going to evaporate - maybe IPv6 >> with PA addresses will do a great job of cleaning up the routing tables, >> but I think that's expecting a lot. If everyone goes out and gets new PI >> address space for v6, then you may just end doubling the routing table >> size. >> >> It seems like a fairly straightforward transition to IPv6 on the >> Internet backbone by running a single IPv6 routing table, with the >> existing IPv4 prefixes simply >> being imported/converted to IPv6 prefixes by prepending 2002:: >> >> >> >> >> William Herrin wrote: >> >>> On 6/27/07, John Paul Morrison wrote: >>> >>>> I do not support this proposal as it essentially duplicates the IPv6 >>>> address space already allocated to IPv4 users, documented in RFC 3056 >>>> (6to4). >>>> >>> John, >>> >>> First, thank you for privately discussing 6to4's functionality with >>> me. You were very helpful and informative. >>> >>> You are not alone in suggesting that 6to4 might suitably replace the >>> Migration Incentive Space proposal, however 6to4 has several issues >>> which would need to be addressed before it could be considered a valid >>> alternative. I'd like to find if there is a consensus on ppml as to >>> whether those issues should be addressed in 6to4. If they should, I'll >>> start working on such a proposal with the intent that it replace the >>> Migration Incentive Space proposal. If they should not, then I would >>> ask that 6to4 be considered irrelevant to and dropped from the >>> discussion. >>> >>> 6to4 Problem #1: Implementation of 6to4 is an optional component of >>> the IPv6 protocol. Devices confronted with a 2002:: address may but >>> need not recognize that packets to such a destination should be >>> encapsulated in an IPv4 packet. The Migration Incentive Space proposal >>> is intended to rely on only those components of IPv6 which are >>> mandatory. >>> >>> 6to4 Problem #2: Its unclear whether the authors of RFC 3056 intended >>> that it be possilble for prefixes within 2002:: to be announced into >>> the global IPv6 BGP table so that all native IPv6 networks could reach >>> such hosts without IPv4 encapsulation. Indeed, some parts of the >>> document suggest that an available IPv6 route should NOT take priority >>> over encapsulation. For 6to4 to reasonably replace the Migration >>> Incentive Space, it would need to be clarified that ARIN encourages >>> IPv4 holders to announce an appropriately selected 2002:: route, that >>> remote IPv6 systems should give native IPv6 routes to 2002:: >>> destinations priorirty over the encalsulated IPv4 route, and that ARIN >>> intends such blocks within 2002:: to have the same validity as any >>> other IPv6 block they assign or allocate. >>> >>> 6to4 Problem #3: Its unclear whether the authors of RFC 3056 intended >>> that prefixes within 2002:: continue to exist in IPv4's >>> post-exhaustion phase when IPv6 has become the dominant protocol. The >>> Migration Incentive Space is intended to be a permanant solution whose >>> addresses continue to see use after IPv4's end of life. >>> >>> 6to4 Problem #4: ARIN does not control the reverse DNS for 6to4 >>> prefixes associated with the IPv4 blocks which ARIN manages. It is >>> presently managed by the NRO, an organization in which ARIN >>> participates (see https://6to4.nro.net/). The documentation for 6to4 >>> reverse dns states that, "This password is not mandatory when the site >>> is accessed from inside your 6to4 source address. It is intended to >>> prevent an arbitrary access from locking out the domain if the address >>> is not static. (It is recognized that this places far less trust than >>> normal in the correctness of a 6to4 delegation)." For 6to4 to work as >>> a replacement for the Migration Incentive Space, reverse DNS for the >>> blocks under ARIN's authority would need to be operated with a degree >>> of security and access comperable to what ARIN applies to its normal >>> delegation of reverse DNS. >>> >>> So, the question I put to you and to the others who have suggested >>> 6to4 is this: Do we seek changes and clarifications to address these >>> four problems or do we drop 6to4 from consideration as an alternative >>> to the Migration Incentive Space proposal? >>> >>> Regards, >>> Bill Herrin >>> >>> >> >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml >> > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From kkargel at polartel.com Fri Jun 29 10:08:26 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 29 Jun 2007 09:08:26 -0500 Subject: [ppml] I-D ACTION:draft-ietf-ipv6-ula-central-02.txt In-Reply-To: <200706290333.l5T3XT31048006@drugs.dv.isc.org> Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410667070D0@mail> So is what you are really saying is that the addresses "may" wind up in the DFZ and you do want them to be able to transit the DFZ? otherwise anywhere your ULA packets live the processing entity should also be able to reach the ULA-DNS .. what I am hearing is that you feel if it is technically possible to route ULA across the DFZ then we should not limit that capability.. leave it up to the user.. I'm still confused.. > -----Original Message----- > From: Mark_Andrews at isc.org [mailto:Mark_Andrews at isc.org] > Sent: Thursday, June 28, 2007 10:33 PM > To: Kevin Kargel > Cc: ipv6 at ietf.org > Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt > > > > I am afraid I am slow.. I still don't get the need to publicly > > advertise DNS for ULA(-x) .. if your neighbor cannot route > to your ULA > > he doesn't need to know what it's names are.. if you do > allow him to > > enter your network via VPN or whatever there is either a dhcp-like > > process by which he is granted an address which will also > give him a > > name server to use, or when he says "Hey, Can I have access to your > > network" you can say "Sure, here are your credentials and my DNS > > server is..."=20 > > Well firstly these address will appear outside of IPv6 packets > in environments where they will be automatically processed along > with every other IPv6 address that is being processed. The > place that it processing the addresses may or may not be able > to reach the ULA-C servers for the reverse lookup. > > It really should be up to the *user* of the ULA-C addresses > to decide if they want to provide more than NXDOMAIN to > interested parties on the Internet. We shouldn't be > arbitarially limiting functionality if it is technically > possible to provide that functionality. > > > Then of course because you can populate your DNS server > with whatever > > zones you want when your neighbor queries your name server it will > > tell him what he wants to know. > > > > Aren't your DNS servers going to provide different views > for clients > > coming from PI or PA than they do for clients coming from > ULAx anyway? > > or is your network going to be a completely glass house? Typically > > "local" clients get more access and information than > non-local clients. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org > From info at arin.net Fri Jun 29 10:57:59 2007 From: info at arin.net (Member Services) Date: Fri, 29 Jun 2007 10:57:59 -0400 Subject: [ppml] Policy Proposal: Resource Reclamation Incentives In-Reply-To: <371EB4EE-C2FE-46CD-BAF9-DB35937B572A@delong.com> References: <371EB4EE-C2FE-46CD-BAF9-DB35937B572A@delong.com> Message-ID: <46851DF7.8020106@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next regularly scheduled meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Owen DeLong wrote: > Here's an attempt to partially drain the swamp and create some > incentives > for legacy holders to both return available IPv4 space and start using > IPv6. > > Comments welcome. > > Owen > > > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 > > > Policy Proposal Name: Legacy Outreach and Partial Reclamation > Author > name: Owen DeLong > email: owen at delong.com > telephone: 408-921-6984 > organization: JITTR Networks > > Proposal Version: 0.0.1 > Submission Date: 2007 April 22 > Proposal type: M > new, modify, or delete. > Policy term: permanent > temporary, permanent, or renewable. > Policy statement: > Modify section 4.6 as follows: > > 4.6 Amnesty Requests > ARIN will accept the return or relinquishment of any address space > from any existing address holder. If the address holder wishes to > aggregate into a single block, ARIN may work with the address holder > to arrive at an allocation or assignment which is equal to or smaller > than the sum of their existing blocks and which best meets the needs > of the existing holder and the community. There shall be no fee for > returning addresses under this policy. Further, organizations > returning addresses under this policy shall receive the following > benefits: > > 1. If the organization does not currently pay ARIN > fees, they shall remain fee exempt. > > 2. If the organization currently pays ARIN fees, > their fees shall be waived for two years for > each /20 equivalent returned, with any fractional /20 > equivalent resulting in a one-time single year waiver. > > 3. Any organization returning address space under > this policy shall continue under their existing > RSA or they may choose to sign the current RSA. > For organizations which currently do not > have an RSA, they may sign the current RSA, or, > they may choose to remain without an RSA. > > 4. All organizations returning space under this > policy shall, if they meet other eligibility > requirements and so request, obtain an > appropriate IPv6 end-user assignment > or ISP allocation as applicable, with no fees > for the first 5 years. Organizations electing > to receive IPv6 allocation/assignment under > this provision must sign a current RSA and > must agree that all of their IPv4 resources are > henceforth subject to the RSA. Organizations > taking this election shall be subject to end-user > fees for their IPv4 resources not previously > under an ARIN RSA. If they are already an > ARIN subscriber, then IPv4 resources > affected by this process may, instead, be added to > their existing subscriber agreement at the > address holder's discretion. > > Rationale: > > The current amnesty policy does a nice job of facilitating > aggregation, which was the intent when it was drafted. However, > as we approach IPv4 free-space exhaustion, the community now > has an additional need to facilitate address reclamation. > > A very high percentage of underutilized space is in the hands of > legacy holders who currently have no benefit to joining the ARIN > process. Further, there is an unfortunate perception that doing > so will require force the legacy holder into certain future > disadvantages. > This proposal attempts to resolve both of those issues while also > providing some incentive to legacy organizations to start using > IPv6 resources and bring their IPv4 resources into the ARIN > process. > > This policy attempts to provide some benefit and remove most of > the costs of making partial IPv4 returns. It also attempts to > provide an incentive for these IPv4 holders to join the ARIN > process. > > Timetable for implementation: > > Immediate > > Meeting presenter: > > TBD, probably Owen DeLong > > END OF TEMPLATE > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From jordi.palet at consulintel.es Fri Jun 29 19:24:39 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 29 Jun 2007 19:24:39 -0400 Subject: [ppml] ICANN Board Resolution on the Deployment of IPv6 Message-ID: I think this resolution that has been taken unanimously by the board today here in San Juan deservers this email at least: http://www.ipv6tf.org/index.php?page=news/newsroom&id=3052 Regards, Jordi ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From marla.azinger at frontiercorp.com Sat Jun 30 11:42:35 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Sat, 30 Jun 2007 11:42:35 -0400 Subject: [ppml] Policy Proposal: Resource Reclamation Incentives Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272F959@nyrofcs2ke2k01.corp.pvt> Hello ARIN Community- Cathy Aronson and Lea Roberts will serve as the AC Shepherds for this proposal. Thank you for your time Marla Azinger AC Chair -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Member Services Sent: Friday, June 29, 2007 7:58 AM To: ppml at arin.net Subject: Re: [ppml] Policy Proposal: Resource Reclamation Incentives ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next regularly scheduled meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Owen DeLong wrote: > Here's an attempt to partially drain the swamp and create some > incentives > for legacy holders to both return available IPv4 space and start using > IPv6. > > Comments welcome. > > Owen > > > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 > > > Policy Proposal Name: Legacy Outreach and Partial Reclamation > Author > name: Owen DeLong > email: owen at delong.com > telephone: 408-921-6984 > organization: JITTR Networks > > Proposal Version: 0.0.1 > Submission Date: 2007 April 22 > Proposal type: M > new, modify, or delete. > Policy term: permanent > temporary, permanent, or renewable. > Policy statement: > Modify section 4.6 as follows: > > 4.6 Amnesty Requests > ARIN will accept the return or relinquishment of any address space > from any existing address holder. If the address holder wishes to > aggregate into a single block, ARIN may work with the address holder > to arrive at an allocation or assignment which is equal to or smaller > than the sum of their existing blocks and which best meets the needs > of the existing holder and the community. There shall be no fee for > returning addresses under this policy. Further, organizations > returning addresses under this policy shall receive the following > benefits: > > 1. If the organization does not currently pay ARIN > fees, they shall remain fee exempt. > > 2. If the organization currently pays ARIN fees, > their fees shall be waived for two years for > each /20 equivalent returned, with any fractional /20 > equivalent resulting in a one-time single year waiver. > > 3. Any organization returning address space under > this policy shall continue under their existing > RSA or they may choose to sign the current RSA. > For organizations which currently do not > have an RSA, they may sign the current RSA, or, > they may choose to remain without an RSA. > > 4. All organizations returning space under this > policy shall, if they meet other eligibility > requirements and so request, obtain an > appropriate IPv6 end-user assignment > or ISP allocation as applicable, with no fees > for the first 5 years. Organizations electing > to receive IPv6 allocation/assignment under > this provision must sign a current RSA and > must agree that all of their IPv4 resources are > henceforth subject to the RSA. Organizations > taking this election shall be subject to end-user > fees for their IPv4 resources not previously > under an ARIN RSA. If they are already an > ARIN subscriber, then IPv4 resources > affected by this process may, instead, be added to > their existing subscriber agreement at the > address holder's discretion. > > Rationale: > > The current amnesty policy does a nice job of facilitating > aggregation, which was the intent when it was drafted. However, > as we approach IPv4 free-space exhaustion, the community now > has an additional need to facilitate address reclamation. > > A very high percentage of underutilized space is in the hands of > legacy holders who currently have no benefit to joining the ARIN > process. Further, there is an unfortunate perception that doing > so will require force the legacy holder into certain future > disadvantages. > This proposal attempts to resolve both of those issues while also > providing some incentive to legacy organizations to start using > IPv6 resources and bring their IPv4 resources into the ARIN > process. > > This policy attempts to provide some benefit and remove most of > the costs of making partial IPv4 returns. It also attempts to > provide an incentive for these IPv4 holders to join the ARIN > process. > > Timetable for implementation: > > Immediate > > Meeting presenter: > > TBD, probably Owen DeLong > > END OF TEMPLATE > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From jordi.palet at consulintel.es Sat Jun 30 12:21:39 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 30 Jun 2007 12:21:39 -0400 Subject: [ppml] Policy Proposal: Resource Reclamation Incentives In-Reply-To: <371EB4EE-C2FE-46CD-BAF9-DB35937B572A@delong.com> Message-ID: I think this is an excellent proposal. Regards, Jordi > De: Owen DeLong > Responder a: > Fecha: Thu, 28 Jun 2007 09:34:02 -0700 > Para: ARIN Address Policy , > Asunto: [ppml] Policy Proposal: Resource Reclamation Incentives > > Here's an attempt to partially drain the swamp and create some > incentives > for legacy holders to both return available IPv4 space and start using > IPv6. > > Comments welcome. > > Owen > > > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 > > > Policy Proposal Name: Legacy Outreach and Partial Reclamation > Author > name: Owen DeLong > email: owen at delong.com > telephone: 408-921-6984 > organization: JITTR Networks > > Proposal Version: 0.0.1 > Submission Date: 2007 April 22 > Proposal type: M > new, modify, or delete. > Policy term: permanent > temporary, permanent, or renewable. > Policy statement: > Modify section 4.6 as follows: > > 4.6 Amnesty Requests > ARIN will accept the return or relinquishment of any address space > from any existing address holder. If the address holder wishes to > aggregate into a single block, ARIN may work with the address holder > to arrive at an allocation or assignment which is equal to or smaller > than the sum of their existing blocks and which best meets the needs > of the existing holder and the community. There shall be no fee for > returning addresses under this policy. Further, organizations > returning addresses under this policy shall receive the following > benefits: > > 1. If the organization does not currently pay ARIN > fees, they shall remain fee exempt. > > 2. If the organization currently pays ARIN fees, > their fees shall be waived for two years for > each /20 equivalent returned, with any fractional /20 > equivalent resulting in a one-time single year waiver. > > 3. Any organization returning address space under > this policy shall continue under their existing > RSA or they may choose to sign the current RSA. > For organizations which currently do not > have an RSA, they may sign the current RSA, or, > they may choose to remain without an RSA. > > 4. All organizations returning space under this > policy shall, if they meet other eligibility > requirements and so request, obtain an > appropriate IPv6 end-user assignment > or ISP allocation as applicable, with no fees > for the first 5 years. Organizations electing > to receive IPv6 allocation/assignment under > this provision must sign a current RSA and > must agree that all of their IPv4 resources are > henceforth subject to the RSA. Organizations > taking this election shall be subject to end-user > fees for their IPv4 resources not previously > under an ARIN RSA. If they are already an > ARIN subscriber, then IPv4 resources > affected by this process may, instead, be added to > their existing subscriber agreement at the > address holder's discretion. > > Rationale: > > The current amnesty policy does a nice job of facilitating > aggregation, which was the intent when it was drafted. However, > as we approach IPv4 free-space exhaustion, the community now > has an additional need to facilitate address reclamation. > > A very high percentage of underutilized space is in the hands of > legacy holders who currently have no benefit to joining the ARIN > process. Further, there is an unfortunate perception that doing > so will require force the legacy holder into certain future > disadvantages. > This proposal attempts to resolve both of those issues while also > providing some incentive to legacy organizations to start using > IPv6 resources and bring their IPv4 resources into the ARIN > process. > > This policy attempts to provide some benefit and remove most of > the costs of making partial IPv4 returns. It also attempts to > provide an incentive for these IPv4 holders to join the ARIN > process. > > Timetable for implementation: > > Immediate > > Meeting presenter: > > TBD, probably Owen DeLong > > END OF TEMPLATE > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From mysidia at gmail.com Sat Jun 30 15:46:33 2007 From: mysidia at gmail.com (James Hess) Date: Sat, 30 Jun 2007 14:46:33 -0500 Subject: [ppml] Policy Proposal: Resource Reclamation Incentives In-Reply-To: References: <371EB4EE-C2FE-46CD-BAF9-DB35937B572A@delong.com> Message-ID: <6eb799ab0706301246r50a5d6cdg667193830ec6a4b7@mail.gmail.com> On 6/30/07, JORDI PALET MARTINEZ wrote: I would say the proposal has merits. But it doesn't really offer much "incentive" to legacy holders who pay no fees. What it really does is eliminate some disincentives, they'd otherwise have, like having fees to pay in the future from returning legacy space and getting a little less space. More may be needed to be done to 'drain the swamp' If a legacy registrant is happy about having all that extra address space, what will incite them to renumber? If they want Ipv6 space under this policy, then they have to pay anyways. Such legacy registrants still have tremendous disincentives from entertaining obtaining Ipv6 addresses. I think what is really needed, overall, is a huge disincentive for a legacy registrant to fail to join RIR process -- I think the disincentive for not participating, combined with an incentive for participating could be an effective combination. For example, an Announcement that after a certain date, legacy assignments from before the community/RIR process will cease to be recognized by the community, including addresses would go away from official WHOIS, reverse mapping, and after a waiting period, become available to be reassigned, and it is up to the legacy registrants to justify and obtain a permanent allocation from the RIR serving their region. Combined with a caveat of NOT joining the process, the policy of being able to return address space and receive a "proper", justified address space of an appropriate size, with an agreement between registry and registrant, to recognize that address assignment going forward, would be a huge incentive. Since the alternative would be unpalatable. > I think this is an excellent proposal. > > Regards, > Jordi -- -J From dudepron at gmail.com Sat Jun 30 22:38:53 2007 From: dudepron at gmail.com (heh heh) Date: Sat, 30 Jun 2007 22:38:53 -0400 Subject: [ppml] Policy Proposal: Resource Reclamation Incentives In-Reply-To: <371EB4EE-C2FE-46CD-BAF9-DB35937B572A@delong.com> References: <371EB4EE-C2FE-46CD-BAF9-DB35937B572A@delong.com> Message-ID: <480dad640706301938geaf4152k9bd9b44163a6abca@mail.gmail.com> Owen, Doesn't #1 and #4 conflict with each other or am I missing something? #1 says that they will remain exempt #4 says that anyone returning will be exempt for 5yrs So, if I return legacy space, which one do I fall under? Aaron On 6/28/07, Owen DeLong wrote: > > Here's an attempt to partially drain the swamp and create some > incentives > for legacy holders to both return available IPv4 space and start using > IPv6. > > Comments welcome. > > Owen > > > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 > > > Policy Proposal Name: Legacy Outreach and Partial Reclamation > Author > name: Owen DeLong > email: owen at delong.com > telephone: 408-921-6984 > organization: JITTR Networks > > Proposal Version: 0.0.1 > Submission Date: 2007 April 22 > Proposal type: M > new, modify, or delete. > Policy term: permanent > temporary, permanent, or renewable. > Policy statement: > Modify section 4.6 as follows: > > 4.6 Amnesty Requests > ARIN will accept the return or relinquishment of any > address space > from any existing address holder. If the address holder > wishes to > aggregate into a single block, ARIN may work with the > address holder > to arrive at an allocation or assignment which is equal to > or smaller > than the sum of their existing blocks and which best meets > the needs > of the existing holder and the community. There shall be > no fee for > returning addresses under this policy. Further, > organizations > returning addresses under this policy shall receive the > following > benefits: > > 1. If the organization does not currently pay > ARIN > fees, they shall remain fee exempt. > > 2. If the organization currently pays ARIN > fees, > their fees shall be waived for two years > for > each /20 equivalent returned, with any > fractional /20 > equivalent resulting in a one-time single > year waiver. > > 3. Any organization returning address space > under > this policy shall continue under their > existing > RSA or they may choose to sign the current > RSA. > For organizations which currently do not > have an RSA, they may sign the current > RSA, or, > they may choose to remain without an RSA. > > 4. All organizations returning space under > this > policy shall, if they meet other > eligibility > requirements and so request, obtain an > appropriate IPv6 end-user assignment > or ISP allocation as applicable, with no > fees > for the first 5 years. Organizations > electing > to receive IPv6 allocation/assignment > under > this provision must sign a current RSA and > must agree that all of their IPv4 > resources are > henceforth subject to the RSA. > Organizations > taking this election shall be subject to > end-user > fees for their IPv4 resources not > previously > under an ARIN RSA. If they are already an > ARIN subscriber, then IPv4 resources > affected by this process may, instead, be > added to > their existing subscriber agreement at the > address holder's discretion. > > Rationale: > > The current amnesty policy does a nice job of facilitating > aggregation, which was the intent when it was drafted. However, > as we approach IPv4 free-space exhaustion, the community now > has an additional need to facilitate address reclamation. > > A very high percentage of underutilized space is in the hands of > legacy holders who currently have no benefit to joining the ARIN > process. Further, there is an unfortunate perception that doing > so will require force the legacy holder into certain future > disadvantages. > This proposal attempts to resolve both of those issues while also > providing some incentive to legacy organizations to start using > IPv6 resources and bring their IPv4 resources into the ARIN > process. > > This policy attempts to provide some benefit and remove most of > the costs of making partial IPv4 returns. It also attempts to > provide an incentive for these IPv4 holders to join the ARIN > process. > > Timetable for implementation: > > Immediate > > Meeting presenter: > > TBD, probably Owen DeLong > > END OF TEMPLATE > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleibrand at internap.com Sat Jun 30 22:48:41 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 30 Jun 2007 19:48:41 -0700 Subject: [ppml] Policy Proposal: Resource Reclamation Incentives In-Reply-To: <480dad640706301938geaf4152k9bd9b44163a6abca@mail.gmail.com> References: <371EB4EE-C2FE-46CD-BAF9-DB35937B572A@delong.com> <480dad640706301938geaf4152k9bd9b44163a6abca@mail.gmail.com> Message-ID: <46871609.9060508@internap.com> I think what Owen meant was: 1. If the organization does not currently pay ARIN fees, their remaining IPv4 resources shall remain fee exempt. and 4. All organizations returning space under this policy shall, if they meet other eligibility requirements and so request, obtain an appropriate IPv6 end-user assignment or ISP allocation as applicable, with no fees for these IPv6 resources for the first 5 years.... etc. I presume that the normal rules (that you pay the greater of your IPv4 or IPv6 fees, not the sum) will still apply in such situations, meaning that a legacy IPv4 holder who returns some of their space and gets an IPv6 block will begin paying fees, based on their IPv6 space, after 5 years. Owen, am I reading between the lines correctly? -Scott P.S. Aaron, you might want to update the From: line your mailer generates. :-) heh heh wrote: > Owen, > Doesn't #1 and #4 conflict with each other or am I missing something? > #1 says that they will remain exempt > #4 says that anyone returning will be exempt for 5yrs > So, if I return legacy space, which one do I fall under? > > Aaron > > On 6/28/07, *Owen DeLong* > > wrote: > > Here's an attempt to partially drain the swamp and create some > incentives > for legacy holders to both return available IPv4 space and start using > IPv6. > > Comments welcome. > > Owen > > > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 > > > Policy Proposal Name: Legacy Outreach and Partial Reclamation > Author > name: Owen DeLong > email: owen at delong.com > telephone: 408-921-6984 > organization: JITTR Networks > > Proposal Version: 0.0.1 > Submission Date: 2007 April 22 > Proposal type: M > new, modify, or delete. > Policy term: permanent > temporary, permanent, or renewable. > Policy statement: > Modify section 4.6 as follows: > > 4.6 Amnesty Requests > ARIN will accept the return or relinquishment of > any address space > from any existing address holder. If the address > holder wishes to > aggregate into a single block, ARIN may work with > the address holder > to arrive at an allocation or assignment which is > equal to or smaller > than the sum of their existing blocks and which > best meets the needs > of the existing holder and the community. There > shall be no fee for > returning addresses under this policy. Further, > organizations > returning addresses under this policy shall > receive the following > benefits: > > 1. If the organization does not > currently pay ARIN > fees, they shall remain fee exempt. > > 2. If the organization currently pays > ARIN fees, > their fees shall be waived for two > years for > each /20 equivalent returned, with > any fractional /20 > equivalent resulting in a one-time > single year waiver. > > 3. Any organization returning address > space under > this policy shall continue under > their existing > RSA or they may choose to sign the > current RSA. > For organizations which currently > do not > have an RSA, they may sign the > current RSA, or, > they may choose to remain without > an RSA. > > 4. All organizations returning space > under this > policy shall, if they meet other > eligibility > requirements and so request, > obtain an > appropriate IPv6 end-user assignment > or ISP allocation as applicable, > with no fees > for the first 5 > years. Organizations electing > to receive IPv6 > allocation/assignment under > this provision must sign a current > RSA and > must agree that all of their IPv4 > resources are > henceforth subject to the RSA. > Organizations > taking this election shall be > subject to end-user > fees for their IPv4 resources not > previously > under an ARIN RSA. If they are > already an > ARIN subscriber, then IPv4 resources > affected by this process may, > instead, be added to > their existing subscriber > agreement at the > address holder's discretion. > > Rationale: > > The current amnesty policy does a nice job of facilitating > aggregation, which was the intent when it was > drafted. However, > as we approach IPv4 free-space exhaustion, the community now > has an additional need to facilitate address reclamation. > > A very high percentage of underutilized space is in the > hands of > legacy holders who currently have no benefit to joining > the ARIN > process. Further, there is an unfortunate perception that > doing > so will require force the legacy holder into certain future > disadvantages. > This proposal attempts to resolve both of those issues > while also > providing some incentive to legacy organizations to start > using > IPv6 resources and bring their IPv4 resources into the ARIN > process. > > This policy attempts to provide some benefit and remove > most of > the costs of making partial IPv4 returns. It also > attempts to > provide an incentive for these IPv4 holders to join the ARIN > process. > > Timetable for implementation: > > Immediate > > Meeting presenter: > > TBD, probably Owen DeLong > > END OF TEMPLATE > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net ). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > > > ------------------------------------------------------------------------ > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml