From bjohnson at drtel.com Thu Nov 1 09:54:43 2007 From: bjohnson at drtel.com (Brian Johnson) Date: Thu, 1 Nov 2007 08:54:43 -0500 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <4728F24B.4060101@internap.com> References: <4728F24B.4060101@internap.com> Message-ID: <29A54911243620478FF59F00EBB12F47C323C4@ex01.drtel.lan> Scott Leibrand wrote: > Not if you do peer-level localpref communities on the backup > announcements. That way, if I'm a third party network filtering at > RIR-assignment size, and I prefer transit provider 1 (like everyone > else), then my packets hit that transit provider, then get immediately > sent across the closest peering link to the preferred transit provider. > Not completely optimal, but it preserves the ISP's ability to do > inbound > TE, while providing a safety valve to filter deaggregates where > necessary without losing reachability. Again, I'm not advocating > anyone > start filtering just yet, but I think we need to design our policies to > ensure we don't block the safety valve. MY ENTIRE POINT IS THAT ARIN NEEDS TO STAY OUT OF ROUTING POLICY! - Brian From briand at ca.afilias.info Thu Nov 1 11:11:51 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Thu, 01 Nov 2007 11:11:51 -0400 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <4728CCE0.6030703@internap.com> References: <47275F4F.4000109@internap.com> <472762CB.4010507@ca.afilias.info><472768D8.50809@internap.com> <47289F86.3080809@internap.com> <29A54911243620478FF59F00EBB12F47C32354@ex01.drtel.lan> <4728CA84.8070501@internap.com> <29A54911243620478FF59F00EBB12F47C32365@ex01.drtel.lan> <4728CCE0.6030703@internap.com> Message-ID: <4729ECB7.2010807@ca.afilias.info> Scott Leibrand wrote: > Brian Johnson wrote: > >> Scott Leibrand wrote: >> >> >>>> Question: Does it say you cannot advertise smaller portions as well as the larger block? >>>> >>>> >>>> >>> There's some debate on that, but as I read it, no. My understanding is that you're free to advertise subnets longer than /32 out of PA space, >>> but other networks are free to filter them. >>> >>> I think it may eventually be necessary to move toward something similar for IPv4, but it's not all that urgent just yet. >>> >>> >>> >> So I can announce subnets longer than /32 to my desire and anyone can >> filter as they desire. >> >> Sounds like the IPv4 status quo to me. >> > > Almost, but with one important difference: you have to announce your > covering aggregate, which makes it safe to filter more-specifics without > affecting reachability. > Here's a thought: For any policy that requires usage of blocks assigned by $RIR, in addition to testing reachability of hosts in the block, require that the full block itself be seen in the DFZ (i.e. as a covering aggregate). It puts a rather narrow interpretation of use (announcement) of the block, but rather elegantly addresses the covering aggregate issue. Anyone announcing more specifics but not announcing their covering aggregate, would not satisfy the $RIR requirements for their assignment, and after some period of time, would be requested to return their "unused" block. (I expect this won't fly, but may give other folks ideas about how to approach addressing the issue, policy-wise.) Brian From stephen at sprunk.org Thu Nov 1 11:33:10 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 1 Nov 2007 10:33:10 -0500 Subject: [ppml] Effects of explosive routing table growth on ISP behavior References: <47275F4F.4000109@internap.com> <472762CB.4010507@ca.afilias.info><472768D8.50809@internap.com> <47289F86.3080809@internap.com> <29A54911243620478FF59F00EBB12F47C32354@ex01.drtel.lan> <4728CA84.8070501@internap.com> <29A54911243620478FF59F00EBB12F47C32365@ex01.drtel.lan><4728CCE0.6030703@internap.com> <4729ECB7.2010807@ca.afilias.info> Message-ID: <00f601c81ca0$f61649a0$5a3816ac@atlanta.polycom.com> Thus spake "Brian Dickson" > Here's a thought: > > For any policy that requires usage of blocks assigned by $RIR, in > addition to testing reachability of hosts in the block, require that the > full block itself be seen in the DFZ (i.e. as a covering aggregate). There is no single, coherent DFZ. ARIN policy also allows assignment of blocks for private use. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From stephen at sprunk.org Thu Nov 1 14:01:03 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 1 Nov 2007 13:01:03 -0500 Subject: [ppml] Effects of explosive routing table growth on ISP behavior References: <29A54911243620478FF59F00EBB12F47C32368@ex01.drtel.lan><4728D600.6060903@internap.com> <29A54911243620478FF59F00EBB12F47C32370@ex01.drtel.lan> Message-ID: <019701c81cb2$170d4080$5a3816ac@atlanta.polycom.com> Thus spake "Brian Johnson" > Scott Leibrand wrote: >> I don't think that's true. Today, anything you advertise in IPv4 down >> to a /24 will be accepted more or less by everyone. > > Yes. But this came about due to common network policy and time, > not ARIN policy. It could just as easily been a /20 if the screaming > was not as loud. I bet we'll be at /20, at least in the blocks where /20 is the minimum, within a few years due to all the routers falling over from accepting /24 deaggregates. It'd be really nice if someone would produce a tool that would auto-create filter lists that would permit N-bit deaggregates of each block assigned by the RIRs. As long as a covering aggregate was announced, each network could tune N to keep their routers from falling over. > My only real point is that routing decisions should not be directly > "governed" by ARIN policy. I think we are just beating this topic with a > smelly herring. :) They're not "governed" per se, since ARIN has no enforcement powers, but the independent decisions by the various ISPs are definitely influenced by ARIN policy -- and vice versa. At most, ARIN controls what the _minimum_ size of the routing tables are; operators can allow more than that but realistically they can't allow less. e.g. ARIN can hand out /20s and ISPs can filter at /24, but if ARIN was handing out /24s ISPs couldn't filter at /20. It'd be nice to see some blocks designated as having _shorter_ maximum lengths so that we wouldn't be forced to accept /20s in blocks that mega-ISPs were getting /10s from. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From tedm at ipinc.net Thu Nov 1 14:10:20 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 1 Nov 2007 11:10:20 -0700 Subject: [ppml] Projected date of assignable IPv4 is it 2010 right now? Message-ID: I see by the following: http://www.tndh.net/~tony/ietf/IPv4%20Address%20Fractal%20Map.pdf That as of last month the IPv4 projected runout date is now 2010? Anyone want to speculate/elaborate or make any different guesses? Ted From jlewis at lewis.org Thu Nov 1 14:24:19 2007 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 1 Nov 2007 14:24:19 -0400 (EDT) Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <019701c81cb2$170d4080$5a3816ac@atlanta.polycom.com> References: <29A54911243620478FF59F00EBB12F47C32368@ex01.drtel.lan><4728D600.6060903@internap.com> <29A54911243620478FF59F00EBB12F47C32370@ex01.drtel.lan> <019701c81cb2$170d4080$5a3816ac@atlanta.polycom.com> Message-ID: On Thu, 1 Nov 2007, Stephen Sprunk wrote: > It'd be really nice if someone would produce a tool that would auto-create > filter lists that would permit N-bit deaggregates of each block assigned by > the RIRs. As long as a covering aggregate was announced, each network could > tune N to keep their routers from falling over. That's a little hard to automate since not all the RIRs post the necessary info in easy to programatically grab ways. Most do. Besides, given that the RIR minimum allocations in each /8 are reasonably static, do you really need this filter to be regularly auto-generated? If you use the one I posted to nanog a few weeks ago, it'll block all the "smaller than minimum"-RIR routes for the /8's known at the time the filter was written. New /8s would get let through down to the default /24 size. So it's not like a bogon list, where status changes have to be reflected in the filter ASAP or routes get ignored. The problem is clueless networks deaggregating and not announcing covering CIDRs. There's lots of them. I'm considering setting up a web site and possibly a DNSBL-style DNS zone that would allow people to look up "their IP" and see if "their ISP is without clue". The idea being to make it easy for people to realize their web sites, mail servers, whatever are being run by networks abusing the DFZ and are at risk of falling off the internet when networks start filtering based on RIR minimum allocations. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From stephen at sprunk.org Thu Nov 1 15:33:10 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 1 Nov 2007 14:33:10 -0500 Subject: [ppml] Effects of explosive routing table growth on ISP behavior References: <29A54911243620478FF59F00EBB12F47C32368@ex01.drtel.lan><4728D600.6060903@internap.com> <29A54911243620478FF59F00EBB12F47C32370@ex01.drtel.lan> <019701c81cb2$170d4080$5a3816ac@atlanta.polycom.com> Message-ID: <025e01c81cbe$ed405780$5a3816ac@atlanta.polycom.com> Thus spake "Jon Lewis" > On Thu, 1 Nov 2007, Stephen Sprunk wrote: >> It'd be really nice if someone would produce a tool that would auto- >> create filter lists that would permit N-bit deaggregates of each >> block assigned by the RIRs. As long as a covering aggregate >> was announced, each network could tune N to keep their routers >> from falling over. > > That's a little hard to automate since not all the RIRs post the necessary > info in easy to programatically grab ways. Most do. > > Besides, given that the RIR minimum allocations in each /8 are > reasonably static, do you really need this filter to be regularly auto- > generated? Yes, because actual allocation/assignment sizes vary over time even if the minima do not. You could design it to trade off zero false positives for a reasonable number of false negatives, but you'd still want to update it at least monthly. > If you use the one I posted to nanog a few weeks ago, it'll block all > the "smaller than minimum"-RIR routes for the /8's known at the time > the filter was written. Smaller-than-minimum is a good start. Smaller-than-actual is better, or at least solves a different problem. All one has to do is look at the CIDR Report to see that many folks with /14s to /18s are deaggregating down to /20s and /24s. Those deaggregates are in /8s with minima of /20 and /24, so a smaller-than-minima filter won't catch them -- but they're clogging up tens of thousands of routing slots all over the world. Also, I do have some tolerance for deaggregates, as long as the covering aggregate is provided. How much that tolerance is (i.e. the value of N) will depend on how close my routers are to falling over this week. In fact, N may even be a function of how many AS hops they are from me: deaggregates from India or somewhere else 5+ hops away don't particularly interest me, but ones from here in the US/Canada may. In fact, if someone were assigned a /24 here, I might want their /27s; I don't want /24s (or even /14s) from someone further away with a /10 -- as long as that /10 makes it to me. > The problem is clueless networks deaggregating and not > announcing covering CIDRs. There's lots of them. I'm considering > setting up a web site and possibly a DNSBL-style DNS zone that > would allow people to look up "their IP" and see if "their ISP is > without clue". The idea being to make it easy for people to realize > their web sites, mail servers, whatever are being run by networks > abusing the DFZ and are at risk of falling off the internet when > networks start filtering based on RIR minimum allocations. Interesting idea, but the audience you're trying to clue in won't show up until they get filtered out of the DFZ and are wondering why -- if ever. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From jlewis at lewis.org Thu Nov 1 16:07:05 2007 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 1 Nov 2007 16:07:05 -0400 (EDT) Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <025e01c81cbe$ed405780$5a3816ac@atlanta.polycom.com> References: <29A54911243620478FF59F00EBB12F47C32368@ex01.drtel.lan><4728D600.6060903@internap.com> <29A54911243620478FF59F00EBB12F47C32370@ex01.drtel.lan> <019701c81cb2$170d4080$5a3816ac@atlanta.polycom.com> <025e01c81cbe$ed405780$5a3816ac@atlanta.polycom.com> Message-ID: On Thu, 1 Nov 2007, Stephen Sprunk wrote: > Yes, because actual allocation/assignment sizes vary over time even if the > minima do not. You could design it to trade off zero false positives for a > reasonable number of false negatives, but you'd still want to update it at > least monthly. Ah, basing it on actual assignments. With what frequency can a single IP hit the various RIR whois servers before getting blocked/throttled? :) > Interesting idea, but the audience you're trying to clue in won't show up > until they get filtered out of the DFZ and are wondering why -- if ever. The networks won't, but I'm hoping if some of their customers do, they might listen to them. My experience so far with contacting deaggregated networks is they either don't care (as broken as you think it is, our shit works) or as an outsider, you can't talk to anyone who'll understand the issue enough to care enough to bring it to the attention of anyone (if they have anyone) who has the access/ability to make changes. ---------------------------------------------------------------------- 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 Thu Nov 1 19:06:03 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 01 Nov 2007 16:06:03 -0700 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <29A54911243620478FF59F00EBB12F47C323C4@ex01.drtel.lan> References: <4728F24B.4060101@internap.com> <29A54911243620478FF59F00EBB12F47C323C4@ex01.drtel.lan> Message-ID: <472A5BDB.5050608@internap.com> Brian Johnson wrote: > > MY ENTIRE POINT IS THAT ARIN NEEDS TO STAY OUT OF ROUTING POLICY! > I understand your point, I just disagree with it, and am presenting arguments to the contrary. How do you propose we administer IPv4 after the exhaustion of the ARIN free pool? Should we allow transfers of any and all addresses down to /32 regardless of the impact on the routing system? Should we simply deny all IPv4 requests, and require everyone to get PA space from ISPs who have it? Does that constitute anticompetitive behavior? -Scott From jlewis at lewis.org Thu Nov 1 21:19:23 2007 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 1 Nov 2007 21:19:23 -0400 (EDT) Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <4728CA84.8070501@internap.com> References: <47275F4F.4000109@internap.com> <472762CB.4010507@ca.afilias.info><472768D8.50809@internap.com> <47289F86.3080809@internap.com> <29A54911243620478FF59F00EBB12F47C32354@ex01.drtel.lan> <4728CA84.8070501@internap.com> Message-ID: On Wed, 31 Oct 2007, Scott Leibrand wrote: >> Question: Does it say you cannot advertise smaller portions as well as >> the larger block? >> > > There's some debate on that, but as I read it, no. My understanding is > that you're free to advertise subnets longer than /32 out of PA space, > but other networks are free to filter them. [from the v6 ISP template] 14. Will you announce only the single, aggregated IPv6 prefix you are allocated by ARIN? Indicate YES or NO. ... 14. Specify YES or NO. If you receive an allocation from ARIN and you will only announce the least specific, aggregated prefix to your BGP neighbors, indicate YES. If you plan to announce more specifics of your allocation to your BGP neighbors, indicate NO. I said yes when applying for our /32. The instructions imply that no is a valid answer. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From steveb at eagle.ca Thu Nov 1 21:17:41 2007 From: steveb at eagle.ca (Steve Bertrand) Date: Thu, 01 Nov 2007 21:17:41 -0400 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <472A5BDB.5050608@internap.com> References: <4728F24B.4060101@internap.com> <29A54911243620478FF59F00EBB12F47C323C4@ex01.drtel.lan> <472A5BDB.5050608@internap.com> Message-ID: <472A7AB5.9040108@eagle.ca> Scott Leibrand wrote: > Brian Johnson wrote: >> MY ENTIRE POINT IS THAT ARIN NEEDS TO STAY OUT OF ROUTING POLICY! >> > > I understand your point, I just disagree with it, and am presenting > arguments to the contrary. Am I the only one here who can see that nearly every thread on this list lately has more to do with the operational aspect of IPv4 routing than it does creating forward-going policy? If every word that was spent on arguing whether ARIN should or shouldn't be involved in routing policy was spent on positive motions to avoid routing collapse, the IPv4 runout/routing slot problems would be solved by now. If ARIN should stay out of routing policy, then operators should stay out of numbering policy. That's like saying that my local council should impose new bylaws without consulting it's constituents, isn't it? ARIN shouldn't *create* routing policy, but it sure should have a serious interest in it's consequences, when it passes policy that has one hell of a direct affect on it. Steve From sleibrand at internap.com Thu Nov 1 21:28:04 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 01 Nov 2007 18:28:04 -0700 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: References: <47275F4F.4000109@internap.com> <472762CB.4010507@ca.afilias.info><472768D8.50809@internap.com> <47289F86.3080809@internap.com> <29A54911243620478FF59F00EBB12F47C32354@ex01.drtel.lan> <4728CA84.8070501@internap.com> Message-ID: <472A7D24.9080903@internap.com> Jon Lewis wrote: > On Wed, 31 Oct 2007, Scott Leibrand wrote: > >>> Question: Does it say you cannot advertise smaller portions as well as >>> the larger block? >>> >> >> There's some debate on that, but as I read it, no. My understanding is >> that you're free to advertise subnets longer than /32 out of PA space, >> but other networks are free to filter them. > > [from the v6 ISP template] > 14. Will you announce only the single, aggregated IPv6 prefix you > are allocated by ARIN? Indicate YES or NO. > ... > 14. Specify YES or NO. If you receive an allocation from ARIN > and you will only announce the least specific, aggregated > prefix to your BGP neighbors, indicate YES. If you plan to > announce more specifics of your allocation to your BGP > neighbors, indicate NO. > > I said yes when applying for our /32. The instructions imply that no > is a valid answer. My impression that a NO answer would disqualify you for an ISP /32, but perhaps ARIN staff can clarify. NRPM 6.5.1.1 point C seems to state that YES is a requirement: 6.5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organization must: 1. be an LIR; 2. not be an end site; 3. *plan to provide IPv6 connectivity to organizations to which it will assign IPv6 address space, by advertising that connectivity through its single aggregated address allocation; and* 4. be an existing, known ISP in the ARIN region or have a plan for making at least 200 /48 assignments to other organizations within five years. -Scott From mysidia at gmail.com Thu Nov 1 23:43:55 2007 From: mysidia at gmail.com (James Hess) Date: Thu, 1 Nov 2007 22:43:55 -0500 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <472A7D24.9080903@internap.com> References: <47275F4F.4000109@internap.com> <472762CB.4010507@ca.afilias.info> <472768D8.50809@internap.com> <47289F86.3080809@internap.com> <29A54911243620478FF59F00EBB12F47C32354@ex01.drtel.lan> <4728CA84.8070501@internap.com> <472A7D24.9080903@internap.com> Message-ID: <6eb799ab0711012043i4ea88d0agfb189529c8754307@mail.gmail.com> On 11/1/07, Scott Leibrand wrote: > > [from the v6 ISP template] > > 14. Will you announce only the single, aggregated IPv6 prefix you > > are allocated by ARIN? Indicate YES or NO. > > ... ... > My impression that a NO answer would disqualify you for an ISP /32, but > perhaps ARIN staff can clarify. NRPM 6.5.1.1 point C seems to state > that YES is a requirement: > 6.5.1.1. Initial allocation criteria Here's a thought: Planning to provide IPv6 connectivity by advertising through its single aggregated address allocation. Is different from Planning to provide IPv6 connectivity by advertising ONLY its single exact aggregated address allocation. The third requirement of that 6.5.1.1 does not specifically state that other advertisements than the single aggregate allocation must not be planned. Additional advertisements may have to do with connectivity in addition to what is advertised through the aggregate. But existence of advertisement of the aggregate satisfies (3) despite the extraneous advertisements. Does the whole aggregate even have to appear in a single advertisement to satisfy (3)? Advertisement of a subset of the allocation is still potentially sufficient to provide connectivity through addresses which are a part of the single aggregated allocation. "single aggregated address" are characteristics of the allocation. If you plan to provide connectivity through obtaining multiple non-aggregated IPv6 allocations, then you fail (3). (3) doesn't say *plan to provide IPv6 connectivity to organizations to which it will assign IPv6 address space, by advertising that connectivity through a single advertisement of its entire single aggregated address allocation; and* > > To qualify for an initial allocation of IPv6 address space, an > organization must: > > 1. be an LIR; > 2. not be an end site; > 3. *plan to provide IPv6 connectivity to organizations to which it > will assign IPv6 address space, by advertising that connectivity > through its single aggregated address allocation; and* > 4. be an existing, known ISP in the ARIN region or have a plan for > making at least 200 /48 assignments to other organizations within > five years. -- -J From pekkas at netcore.fi Fri Nov 2 02:19:26 2007 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 2 Nov 2007 08:19:26 +0200 (EET) Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <472A5BDB.5050608@internap.com> References: <4728F24B.4060101@internap.com> <29A54911243620478FF59F00EBB12F47C323C4@ex01.drtel.lan> <472A5BDB.5050608@internap.com> Message-ID: On Thu, 1 Nov 2007, Scott Leibrand wrote: > Brian Johnson wrote: >> >> MY ENTIRE POINT IS THAT ARIN NEEDS TO STAY OUT OF ROUTING POLICY! >> > > I understand your point, I just disagree with it, and am presenting > arguments to the contrary. > > How do you propose we administer IPv4 after the exhaustion of the ARIN > free pool? Should we allow transfers of any and all addresses down to > /32 regardless of the impact on the routing system? Should we simply > deny all IPv4 requests, and require everyone to get PA space from ISPs > who have it? Does that constitute anticompetitive behavior? FWIW, I agree with Scott's arguments on this. I think everyone agrees that RIRs should stay out of the business of guaranteeing that whatever they allocate or assign are routable. However, I can see only downsides in not trying to design allocation/assignment policies in such a manner that the routing system behaviour could be on a more sustainable basis. "Must advertise the least specific superblock" is IMHO a good expectation is to set. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From heldal at eml.cc Fri Nov 2 08:31:31 2007 From: heldal at eml.cc (Per Heldal) Date: Fri, 02 Nov 2007 13:31:31 +0100 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <29A54911243620478FF59F00EBB12F47C323C4@ex01.drtel.lan> References: <4728F24B.4060101@internap.com> <29A54911243620478FF59F00EBB12F47C323C4@ex01.drtel.lan> Message-ID: <1194006691.22547.19.camel@obelix.sandbu> On Thu, 2007-11-01 at 08:54 -0500, Brian Johnson wrote: > MY ENTIRE POINT IS THAT ARIN NEEDS TO STAY OUT OF ROUTING POLICY! I'm not so sure the hands-off approach to routing-policy is going to work when there are no more blocks to hand out. Is it just RIRs that have no business being involved in routing-policy or do you resist any coordination of routing-policies between DFZ operators? Suppose a market emerges and it must be regulated, how do you enforce regulations without a stick? If the RIRs can't advise operators on routing-policies, who can? //per From michael.dillon at bt.com Fri Nov 2 10:23:36 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 2 Nov 2007 14:23:36 -0000 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <1194006691.22547.19.camel@obelix.sandbu> References: <4728F24B.4060101@internap.com><29A54911243620478FF59F00EBB12F47C323C4@ex01.drtel.lan> <1194006691.22547.19.camel@obelix.sandbu> Message-ID: > On Thu, 2007-11-01 at 08:54 -0500, Brian Johnson wrote: > > MY ENTIRE POINT IS THAT ARIN NEEDS TO STAY OUT OF ROUTING POLICY! > Is it just RIRs that have no business being involved in > routing-policy or do you resist any coordination of > routing-policies between DFZ operators? Suppose a market > emerges and it must be regulated, how do you enforce > regulations without a stick? If the RIRs can't advise > operators on routing-policies, who can? This is a silly comment. The RIRs have no business in routing policy because they do not have the expertise, and the true stakeholders in member companies are not involved in the RIRs. The RIRs have no competent advice to give an ISP on routing policy. That said, there is nothing wrong with RIRs mediating some coordination of routing policies between DFZ operators, but this must be done, first and foremost, by getting the routing policy stakeholders involved in the process. If they don't buy-in, then it won't work. And please don't send me a list of the few PPML participants who also happen to have design authority in their networks. I know that there are a few such people, but the point is that RIR policy is being set, for the most part, by people who do not design their companies' networks or set their companies' routing policy. --Michael Dillon P.S. Some might argue, with some justification, that not all ARIN members have the right internal stakeholders involved in the ARIN policymaking process. There is a difference between administering the IP address supply chain, and the making of IP address allocation policy. From heldal at eml.cc Fri Nov 2 11:12:45 2007 From: heldal at eml.cc (Per Heldal) Date: Fri, 02 Nov 2007 16:12:45 +0100 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: References: <4728F24B.4060101@internap.com> <29A54911243620478FF59F00EBB12F47C323C4@ex01.drtel.lan> <1194006691.22547.19.camel@obelix.sandbu> Message-ID: <1194016365.22547.35.camel@obelix.sandbu> On Fri, 2007-11-02 at 14:23 +0000, michael.dillon at bt.com wrote: > > On Thu, 2007-11-01 at 08:54 -0500, Brian Johnson wrote: > > > MY ENTIRE POINT IS THAT ARIN NEEDS TO STAY OUT OF ROUTING POLICY! > > > Is it just RIRs that have no business being involved in > > routing-policy or do you resist any coordination of > > routing-policies between DFZ operators? Suppose a market > > emerges and it must be regulated, how do you enforce > > regulations without a stick? If the RIRs can't advise > > operators on routing-policies, who can? > > This is a silly comment. The RIRs have no business in routing > policy because they do not have the expertise, and the true > stakeholders in member companies are not involved in the RIRs. > The RIRs have no competent advice to give an ISP on routing > policy. > Between the lines, maybe that's exactly what I indicated that has to change. There should be plenty of routing competence combined within the organisations represented in the ARIN community. I never argued that ARIN itself has the knowledge. They can only mediate community-member's contributions as defined by the community they serve. > That said, there is nothing wrong with RIRs mediating some > coordination of routing policies between DFZ operators, but > this must be done, first and foremost, by getting the routing > policy stakeholders involved in the process. If they don't buy-in, > then it won't work. > > And please don't send me a list of the few PPML participants who > also happen to have design authority in their networks. I know > that there are a few such people, but the point is that RIR policy > is being set, for the most part, by people who do not design their > companies' networks or set their companies' routing policy. As said above; if that is so, maybe it'll have to change? Or do we have to establish a completely new organisation with the authorisation to even get heavy-handed should it be necessary? As was said in ARIN and RIPE meetings in the last weeks the choice may stand between strict industry self-regulation of heavy-handed 3rd party regulators which may be even less educated than today's RIR contributors. //per From info at arin.net Fri Nov 2 13:29:24 2007 From: info at arin.net (Member Services) Date: Fri, 02 Nov 2007 13:29:24 -0400 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <472A7D24.9080903@internap.com> References: <47275F4F.4000109@internap.com> <472762CB.4010507@ca.afilias.info><472768D8.50809@internap.com> <47289F86.3080809@internap.com> <29A54911243620478FF59F00EBB12F47C32354@ex01.drtel.lan> <4728CA84.8070501@internap.com> <472A7D24.9080903@internap.com> Message-ID: <472B5E74.80509@arin.net> Scott Leibrand wrote: > Jon Lewis wrote: > >> On Wed, 31 Oct 2007, Scott Leibrand wrote: >> >>>> Question: Does it say you cannot advertise smaller portions as well as >>>> the larger block? >>>> >>> >>> There's some debate on that, but as I read it, no. My understanding is >>> that you're free to advertise subnets longer than /32 out of PA space, >>> but other networks are free to filter them. >> >> >> [from the v6 ISP template] >> 14. Will you announce only the single, aggregated IPv6 prefix you >> are allocated by ARIN? Indicate YES or NO. >> ... >> 14. Specify YES or NO. If you receive an allocation from ARIN >> and you will only announce the least specific, aggregated >> prefix to your BGP neighbors, indicate YES. If you plan to >> announce more specifics of your allocation to your BGP >> neighbors, indicate NO. >> >> I said yes when applying for our /32. The instructions imply that no >> is a valid answer. > > > My impression that a NO answer would disqualify you for an ISP /32, > but perhaps ARIN staff can clarify. NRPM 6.5.1.1 point C seems to > state that YES is a requirement: > > > 6.5.1.1. Initial allocation criteria > > To qualify for an initial allocation of IPv6 address space, an > organization must: > > 1. be an LIR; > 2. not be an end site; > 3. *plan to provide IPv6 connectivity to organizations to which it > will assign IPv6 address space, by advertising that connectivity > through its single aggregated address allocation; and* > 4. be an existing, known ISP in the ARIN region or have a plan for > making at least 200 /48 assignments to other organizations within > five years. > > > > -Scott > Hello Scott- As you indicate above, NRPM 6.5.1.1(3) states that an organization "must plan to provide IPv6 connectivity to organizations to which it will assign IPv6 address space, by advertising that connectivity through its single aggregated address allocation". If a requester answers YES to question 14, then this clearly meets the policy. A NO answer to this question would not be an immediate denial, but instead would lead staff to ask for clarification as to whether the organization intended to announce the single, aggregated prefix at all. The policy doesn't specifically preclude an organization from announcing more specifics of the larger prefix. Because this question seems to be somewhat confusing, ARIN staff will update the template today to clarify this question and the instructions. Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers From narten at us.ibm.com Fri Nov 2 13:41:35 2007 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 02 Nov 2007 10:41:35 -0700 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <29A54911243620478FF59F00EBB12F47C32354@ex01.drtel.lan> References: <47275F4F.4000109@internap.com> <472762CB.4010507@ca.afilias.info><472768D8.50809@internap.com> <47289F86.3080809@internap.com> <29A54911243620478FF59F00EBB12F47C32354@ex01.drtel.lan> Message-ID: <200711021741.lA2HfZkc016267@localhost.localdomain> "Brian Johnson" writes: > > If by "require" you mean "enforce", then you're probably right. > > However, if by "require" you mean "state what should happen" there is > > precedent: the IPv6 guidelines say you have to announce your > allocation > > as a single netblock. > > > Question: Does it say you cannot advertise smaller portions as well as > the larger block? The policy text does not. As one of the authors of the original text (as adopted by APNIC/ARIN/RIPE), there was no intention to disallow advertising of longer prefixes. Indeed, that is not something that RIR policy would normally get involved in. The intention was, to be clear, to ensure that a single aggregate _could_ be advertised, and it would provide reachability for all the covered addresses. In some sense, this goes hand-in-hand with the definition of being an ISP. You are handing out address space plus providing connectivity for that space. "Stephen Sprunk" writes: > Also, I do have some tolerance for deaggregates, as long as the covering > aggregate is provided. How much that tolerance is (i.e. the value of N) > will depend on how close my routers are to falling over this week. In fact, > N may even be a function of how many AS hops they are from me: deaggregates > from India or somewhere else 5+ hops away don't particularly interest me, > but ones from here in the US/Canada may. In fact, if someone were assigned > a /24 here, I might want their /27s; I don't want /24s (or even /14s) from > someone further away with a /10 -- as long as that /10 makes it to > me. The above is why the aggregate must be advertised. That way, if deaggregates are also advertised, anyone can freely filter them, with the result being reduced performance, but not broken connectivity. It is important that RIR policy preserve aggregation to the maximum degree possible, so that if/when increasing use of filters kicks in, global connectivity can be maintained. Jon Lewis writes: > [from the v6 ISP template] > 14. Will you announce only the single, aggregated IPv6 prefix you > are allocated by ARIN? Indicate YES or NO. > ... > 14. Specify YES or NO. If you receive an allocation from ARIN > and you will only announce the least specific, aggregated > prefix to your BGP neighbors, indicate YES. If you plan to > announce more specifics of your allocation to your BGP > neighbors, indicate NO. IMO, this is an incorrect application of what the policy calls for. Member Services writes: > Hello Scott- > As you indicate above, NRPM 6.5.1.1(3) states that an organization "must > plan to provide IPv6 connectivity to organizations to which it will > assign IPv6 address space, by advertising that connectivity through its > single aggregated address allocation". > If a requester answers YES to question 14, then this clearly meets the > policy. A NO answer to this question would not be an immediate denial, > but instead would lead staff to ask for clarification as to whether the > organization intended to announce the single, aggregated prefix at all. > The policy doesn't specifically preclude an organization from announcing > more specifics of the larger prefix. > Because this question seems to be somewhat confusing, ARIN staff will > update the template today to clarify this question and the > instructions. Thanks! I think this is a good example of where subtle nuances in the wording can have a much bigger impact than intended. Glad to see this get clarified. Thomas From tedm at ipinc.net Fri Nov 2 14:09:41 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 2 Nov 2007 11:09:41 -0700 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <200711021741.lA2HfZkc016267@localhost.localdomain> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Thomas Narten >Sent: Friday, November 02, 2007 10:42 AM >To: ppml at arin.net >Subject: Re: [ppml] Effects of explosive routing table growth on ISP >behavior > > >> Because this question seems to be somewhat confusing, ARIN staff will >> update the template today to clarify this question and the >> instructions. > >Thanks! I think this is a good example of where subtle nuances in the >wording can have a much bigger impact than intended. > Actually a LOT of times this is really required. Until you opened your big yap here, the advocates of ARIN-hands-off-routing policy all thought the documentation from ARIN proved their case, while the rest of us knew the real truth - which is that ARIN is involved in routing policy since they are making everyone advertise the aggregate at minimum. Now that you have made this clear the rest of us are going to have to waste a bunch of time with a vocal minority of ARIN-out-of-routing-policy types who will start bitching and moaning that the policy needs to be struck down. Thanks a lot!!! ;-) Ted From stephen at sprunk.org Fri Nov 2 13:41:03 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 2 Nov 2007 12:41:03 -0500 Subject: [ppml] Effects of explosive routing table growth on ISP behavior References: <4728F24B.4060101@internap.com><29A54911243620478FF59F00EBB12F47C323C4@ex01.drtel.lan><1194006691.22547.19.camel@obelix.sandbu> Message-ID: <00fc01c81d7d$40314f30$663816ac@atlanta.polycom.com> Thus spake >> On Thu, 2007-11-01 at 08:54 -0500, Brian Johnson wrote: >> > MY ENTIRE POINT IS THAT ARIN NEEDS TO STAY OUT OF >> > ROUTING POLICY! > >> Is it just RIRs that have no business being involved in >> routing-policy or do you resist any coordination of >> routing-policies between DFZ operators? Suppose a market >> emerges and it must be regulated, how do you enforce >> regulations without a stick? If the RIRs can't advise >> operators on routing-policies, who can? > > This is a silly comment. The RIRs have no business in routing > policy because they do not have the expertise, and the true > stakeholders in member companies are not involved in the RIRs. > The RIRs have no competent advice to give an ISP on routing > policy. Perhaps I'm cynical, but I believe if the industry doesn't show more leadership and self-regulation, we're going to end up regulated by outsiders. The question may not be "are the RIRs competent to do this" but rather "are the RIRs less incompetent than the other options." As horrifying as the thought of turning control of the DFZ over to PPML/NANOG may be, it's slightly less horrifying than turning it over to Congress and the FCC -- or the UN. IMHO, as always. Another take is that if the RIRs _were_ involved in routing policy, the appropriate stakeholders and competent engineers would show up. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From bicknell at ufp.org Fri Nov 2 16:58:57 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 2 Nov 2007 15:58:57 -0500 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <00fc01c81d7d$40314f30$663816ac@atlanta.polycom.com> References: <00fc01c81d7d$40314f30$663816ac@atlanta.polycom.com> Message-ID: <20071102205857.GA55891@ussenterprise.ufp.org> In a message written on Fri, Nov 02, 2007 at 12:41:03PM -0500, Stephen Sprunk wrote: > Another take is that if the RIRs _were_ involved in routing policy, the > appropriate stakeholders and competent engineers would show up. It is worth pointing out that in different regions this is handled differently. For instance, RIPE handles both the functions of Nanog and of ARIN as a single org. There are of course, pros and cons, but it is not impossible to consider having routing policy and addressing policy under the same umbrella. -- 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 michael.dillon at bt.com Fri Nov 2 17:08:33 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 2 Nov 2007 21:08:33 -0000 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <20071102205857.GA55891@ussenterprise.ufp.org> References: <00fc01c81d7d$40314f30$663816ac@atlanta.polycom.com> <20071102205857.GA55891@ussenterprise.ufp.org> Message-ID: > It is worth pointing out that in different regions this is > handled differently. For instance, RIPE handles both the > functions of Nanog and of ARIN as a single org. Nope. RIPE and RIPE NCC are two separate orgs with separate budgets and management. They may hold joint meetings more often than ARIN/NANOG, but they are not integrated as you have assumed. --Michael Dillon From nigel at titley.com Fri Nov 2 18:07:37 2007 From: nigel at titley.com (Nigel Titley) Date: Fri, 02 Nov 2007 22:07:37 +0000 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: References: <00fc01c81d7d$40314f30$663816ac@atlanta.polycom.com> <20071102205857.GA55891@ussenterprise.ufp.org> Message-ID: <472B9FA9.7050704@titley.com> michael.dillon at bt.com wrote: >> It is worth pointing out that in different regions this is >> handled differently. For instance, RIPE handles both the >> functions of Nanog and of ARIN as a single org. >> > > Nope. RIPE and RIPE NCC are two separate orgs with separate > budgets and management. They may hold joint meetings more > often than ARIN/NANOG, but they are not integrated as you > have assumed. > To be slightly more precise: RIPE is the body which makes policy. It has no budget and no formal membership. It is run as a number of working groups, loosely coordinated by the RIPE Chair. It periodically (twice yearly) meets up in a conference which has two parts: the European Operators Forum (which roughly corresponds to NANOG), and the Working Groups, which roughly correspond to the ARIN meeting. The RIPE NCC is a not for profit organisation which performs the RIR function in Europe, and executes the policy decided by RIPE. It is exactly analogous to ARIN, except that the RIPE NCC board takes no part in the development of policy but is merely concerned with the commercial sound operation of the RIPE NCC. So in a sense, there is no such thing as a RIPE NCC meeting joint or otherwise. The whole thing is confused by the fact that the RIPE NCC organises the RIPE meeting. I'm sure that isn't clearer, but then.... Nigel From info at arin.net Mon Nov 5 14:41:51 2007 From: info at arin.net (Member Services) Date: Mon, 05 Nov 2007 14:41:51 -0500 Subject: [ppml] Policy Proposal: IPv6 Assignment Size Reduction In-Reply-To: <471CC069.6040005@arin.net> References: <471CC069.6040005@arin.net> Message-ID: <472F71FF.3060008@arin.net> > The AC will assign shepherds in the near future. ARIN will provide > the names of the shepherds to the community via the PPML. The shepherds from the ARIN Advisory Council for this proposal are Alec Peterson and Bill Darte. Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > 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 ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as a formal policy proposal as written. If the > AC accepts the proposal, it will be posted as a formal policy proposal > to PPML and it will be presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The AC > will work with the author to clarify, combine or divide the proposal. At > their following meeting the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision. If a proposal is not accepted, then > 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 AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > 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/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: IPv6 Assignment Size Reduction > > Author: Brian Dickson > > Proposal Version: 1 > > Submission Date: Oct 18, 2007 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > 6.5.4.1. Assignment address space size > > End-users are assigned an end site assignment from their LIR or ISP. The > exact size of the assignment is a local decision for the LIR or ISP to > make, using a minimum value of a /120 (when only one subnet is > anticipated for the end site) up to the normal maximum of /48, except in > cases of extra large end sites where a larger assignment can be justified. > > The following guidelines may be useful (but they are only guidelines): > > * /120 for a very small customer with one subnet, using static > assignments or DHCPv6 > * /116 for a small customer with a few subnets, using static > assignments or DHCPv6 > * /112 for a medium size customer with a significant total number > of hosts and/or subnets, using static assignments and/or DHCPv6 > * /96 for large customers > * /80 for very large customers, or for customers using a proposed > modified version of V6-autoconf (which uses EUI-48 instead of EUI-64) > * /72 for customers with several subnets using modified V6-autoconf > (which uses EUI-48 instead of EUI-64) > * /64 when it is known that one and only one subnet is needed, for > a customer that absolutely requires either traditional IPv6 > autoconfiguration, or IPv6 host Interface Identifier cryptographic > generation > * /60 for sites where a mix of IPv6-autoconfiguration and other > address assignment techiques are required > * /56 for very large sites > * /52 for very, very large sites > * /48 for extremely large sites > > For end sites to whom reverse DNS will be delegated, the LIR/ISP should > consider making an assignment on a nibble (4-bit) boundary to simplify > reverse lookup delegation. > > Rationale: > > The intent is to provide more current guidance, to both ARIN members, > and to ARIN staff, based on available IPv6 technology, and for the > encouragement of efficient assignment of IPv6 address space. > > IPv6 supports numerous methods for address assignments to end nodes. > Those include autoconfiguration, static assignment, and DHCPv6. > Of those, only autoconfiguration requires use of /64 as the prefix size. > > Efficient use of IPv6 space should discourage widespread use of /64's, > or for use of autoconfiguration as the sole justification for > allocations of large address space. > > In particular, the effective lifetime of PA assignments to ISPs/LIRs, is > largely a factor of internal aggregation, and the size of end assignments. > > Rather than meeting ISP needs by assigning very large IPv6 PA blocks, it > would be wiser to encourage assignments that to not significantly use up > available PA space for the ISP, even for very large customers. > > The overall intent is to minimize the need for any PA recipient, to > return to ARIN for subsequent assignments, thus reducing the need for > additional globally routable prefixes using up slots in routers in the > DFZ - something that affects the long-term ability for all ISPs to > continue to scale in a cost-effective manner. > > Timetable for implementation: Immediate > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From info at arin.net Mon Nov 5 14:42:54 2007 From: info at arin.net (Member Services) Date: Mon, 05 Nov 2007 14:42:54 -0500 Subject: [ppml] Policy Proposal: 200-reduction-6.5.1.1.d In-Reply-To: <471CC078.2060401@arin.net> References: <471CC078.2060401@arin.net> Message-ID: <472F723E.6050701@arin.net> > The AC will assign shepherds in the near future. ARIN will provide > the names of the shepherds to the community via the PPML. The shepherds from the ARIN Advisory Council for this proposal are Paul Andersen and Bill Darte. Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > 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 ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as a formal policy proposal as written. If the > AC accepts the proposal, it will be posted as a formal policy proposal > to PPML and it will be presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The AC > will work with the author to clarify, combine or divide the proposal. At > their following meeting the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision. If a proposal is not accepted, then > 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 AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > 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/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: 200-reduction-6.5.1.1.d > > Author: Brian Dickson > > Proposal Version: 1 > > Submission Date: Oct 18, 2007 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > In 6.5.1.1 d), where 2007-25 proposes: > > "be an existing, known ISP in the ARIN region or have a plan for making > at least 200 end-site assignments to other organizations within 5 years." > > replace with" > "be an existing, known ISP in the ARIN region or have a plan for making > at least 20 end-site assignments to other organizations, or for > providing IPv6 transit to one or more IPv6 PI blocks belonging to other > organizations, within 5 years." > > Rationale: > > The purpose of the text is to establish reasonable ways for an ISP to > demonstrate that it is in fact an ISP. Any of the above listed > conditions satisfy that need, and the intent is to avoid having the text > of the policy prevent any legitimate ISP from receiving an initial IPv6 > allocation. > > It does lower the bar, but in a justifiable fashion. It is not necessary > for an ISP to have lots of PA assignments. It is necessary for an ISP to > be announcing PA *or* PI blocks to the internet, and relaxing the > criteria to recognize both possibilities jointly, makes the policy > reflect the actual realities for any number of large regional ISPs, who > may have sold off portions of their business but who still operate > significant infrastructure. > > Timetable for implementation: Immediate > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From info at arin.net Mon Nov 5 14:47:24 2007 From: info at arin.net (Member Services) Date: Mon, 05 Nov 2007 14:47:24 -0500 Subject: [ppml] Policy Proposal: globally-coordinated-RIR-pie-IPv4 In-Reply-To: <472646C9.3000207@arin.net> References: <472646C9.3000207@arin.net> Message-ID: <472F734C.60803@arin.net> > The AC will assign shepherds in the near future. ARIN will provide > the names of the shepherds to the community via the PPML. The shepherds from the ARIN Advisory Council for this proposal are Paul Andersen and Stacy Taylor. Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > 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 ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as a formal policy proposal as written. If the > AC accepts the proposal, it will be posted as a formal policy proposal > to PPML and it will be presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The AC > will work with the author to clarify, combine or divide the proposal. At > their following meeting the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision. If a proposal is not accepted, then > 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 AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > 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/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: globally-coordinated-RIR-pie-IPv4 > > Author: Brian Dickson > > Proposal Version: 1 > > Submission Date: 26 October 2007 > > Proposal type: new > > Policy term: renewable > > Policy statement: > > This policy concerns the globally-coordinated allocations of IPv4 > address space from IANA to the RIRs. > > The policy is intended to be compatible with 2007-23 (in its expected > final form). > > The overview of the policy is: > At the last reasonable time to do so, divide up the remaining IPv4 space > based on currently projected use between that time and the date at which > no more IPv4 space is available at any RIR for new allocations. > > Here is how the policy is to be implemented: > > 1) RIRs should provide up-to-date assignment projections for their > respective regions, and provide up-to-date utilization on their current > IANA-assigned block(s) from which assignments are made. > > 2) RIRs should provide an official projection on IANA Exhaustion Date > (IED) to the community through their website, at their Policy Meetings > and through any other effective means. > > 3) When any RIR requests a /8 from IANA, the current assignment > projections for that RIR should be combined with the RIR's currently > available IANA blocks (i.e. from which RIR assignments are made). This > should be compared with the global available IANA unused space (for > allocating to RIRs), the current projected usage rate of the RIR, and > the current projected IED. > > If the RIR projection shows that the RIR would not expect to use up two > /8 blocks before IED, the "Pie-splitting" event will be triggered. > > 4) Splitting the Pie - the following method will be used to determine > the final IPv4 global IANA allocations to the RIRs: > For each RIR, the following calculation will be done: > (i) Determine from the current projection, the total allocations > the RIR will make from present to IED > (ii) Subtract from this, unallocated RIR space already received > from ARIN (if any) > (iii) Round the result to the nearest /12 > (iv) Subtract from this amount, one /8 (to be set aside to satisfy > the 2005-23 policy proposal for "End Policy for IANA IPv4 allocations to > RIRs") > (v) Allocate this amount to the RIR immediately. Every effort > should be made to divide these allocations among RIRs in as aggregatable > a fashion as possible. > > 5) The allocations made will result in just 5 * /8 being left in the > IANA pool, which will trigger 2007-23. > > 6) This in turn, will result in the last 5 * /8's being allocate to the > RIR's, one for each. > > > Rationale: > > The objective of this policy is to ensure that the remaining IPv4 pool > is distributed so as to provide each RIR with a quantity of IPv4 > addresses that will last for an expected duration. > > The intent is for this duration to be as close to the same for each RIR > as possible. > > By following the rules above, the "pie split" is done: > - as late as possible > - as fairly as possible > - in a consistent manner for all RIRs > - early enough that each RIR is guaranteed at least one /8 > > The final /8 allocations are done *after* this allocation, so that there > can be no issue of fairness, with each RIR being guaranteed to get one > of the final /8's at the same time. > > The "pie split" is timed so that no RIR will have so much (relative) > IPv4 address space, as to expect to have IPv4 space after any other RIR > has exhausted its own IPv4 space. > > By providing a "pie split" which is based on the same data as the IED > projection, the following results occur: > - there is no contention over the process by which the division of > resources occur > - all RIRs have the ability to project, well in advance of the "pie > split", exactly when their own IPv4 space will be exhausted. It will > happen at the IED date -- no sooner, no later. > - No RIR "shopping" is likely to occur. Consequently, no inter-RIR "land > grab" is likely to occur, and thus the projections for IED itself are > likely to remain consistent, as will the per-RIR projections. > - LIRs are likely to view the policy as neutral, and thus fair. > - Because it removes the incentive for RIR shopping, the rules > preventing RIR shopping will become largely moot (but still > recommended). The perception then of anti-shopping provisions might then > be that it maintains stability, rather than penalizing any > RIR/LIR/region. > > Additional Observations about Fast vs Slow RIRs > > Fast-consuming RIRs will contribute more heavily towards the consumption > rate. In turn, these RIRs will be the largest component of the > projections of IED. > > Low-consuming RIRs will have less impact on IED. However, the low rate > means that these RIRs will have *greater* proportional accuracy when it > comes to knowing how much space they need between present time and IED. > (This is because, the uncertainty on allocation needs, will be the > result of multiplying the uncertainty on IED date, by the rate of > consumption. Low-consuming LIRs, will have less uncertainty on their > penultimate allocation.) > > The uncertainty on exact date of IED, is expected to be largely > invariant across RIRs. > > Any changes to individual RIR allocation trends, after the "pie split" > date, are not expected to exceed the individual RIR's own uncertainty at > "pie split" date. In other words, the accuracy of each RIR's IED is > expected to increase over time, and to continue to fall within the range > of the original upper and lower limits (based on rounding to /12) of the > RIR's allocation from IANA. > > Timetable for implementation: immediate > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From rw at firstpr.com.au Mon Nov 5 23:40:04 2007 From: rw at firstpr.com.au (Robin Whittle) Date: Tue, 06 Nov 2007 15:40:04 +1100 Subject: [ppml] IRTF RRG: finer allocation of IPv4 space Message-ID: <472FF024.4090601@firstpr.com.au> Denizens of PPML may be interested in joining the IRTF Routing Research Group list: http://www.irtf.org/charter?gtype=rg&group=rrg http://psg.com/lists/rrg/2007/maillist.html The RRG is discussing several ITR-ETR (Ingress Tunnel Router - Egress Tunnel Router) schemes which are intended primarily to help the routing system scale well with growing demand for more multihomed end-user networks - for both IPv4 and IPv6. I think it would be great to have more hands on deck on the RRG list to discuss and critique the various proposals. At some stage, the RRG will recommend to the IETF what new architectural proposals should be developed further. I think this is likely to consist of one of the ITR-ETR schemes (or perhaps some combination of bits of them) and one or more enhancements to BGP. All of these ITR-ETR schemes enable address space to be assigned to end-user networks in finer divisions than is currently practical with BGP. Each such division does not involve a BGP advertised prefix - and in principle, individual IP addresses can be assigned. This means all these schemes all capable of enabling new management structures for IPv4 address space, including assigning space in increments as small as 128, 64, 32 ... 8, 4, 2 or 1 IP addresses. All these schemes are intended primarily to resolve the problems in routing scaling, for both IPv4 and IPv6, with incremental deployment and no changes to hosts or most BGP routers. While they are all, in principle, capable of enabling a much more efficient use of IPv4 space, for many more end-user networks, with multihoming and portability of addresses between ISPs, only my proposal - Ivip - has this as an explicit goal. The proposals are: LISP-CONS http://tools.ietf.org/html/draft-farinacci-lisp-04 http://tools.ietf.org/html/draft-meyer-lisp-cons-02 LISP-NERD http://tools.ietf.org/html/draft-farinacci-lisp-04 http://tools.ietf.org/html/draft-lear-lisp-nerd-02 eFIT-APT http://tools.ietf.org/html/draft-jen-apt-00 http://www.cs.ucla.edu/~lixia/papers/07SIG_IP6WS.pdf http://tools.ietf.org/html/draft-wang-ietf-efit-00 Ivip http://www.firstpr.com.au/ip/ivip/ http://tools.ietf.org/html/draft-whittle-ivip-arch-00 TRRP http://bill.herrin.us/network/trrp.html Also of interest: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ http://tools.ietf.org/html/draft-templin-inetmtu-05 Two proposals, applicable to all ITR-ETR schemes, for coping with the problems of Path MTU Discovery, MTU limits etc. in the tunnel between the ITR and the ETR. http://www.iab.org/about/workshops/routingandaddressing/ http://tools.ietf.org/html/rfc4984 The late 2006 IAB workshop on the routing and addressing crisis. http://www.firstpr.com.au/ip/ivip/comp/ My comparison of LISP-CONS/NERD, eFIT-APT and Ivip. http://www.isi.edu/ant/address/ http://www.isi.edu/~johnh/PAPERS/Heidemann07c.pdf http://www.firstpr.com.au/ip/host-density-per-prefix/ Two recent IPv4 ping surveys find just over 100 million ping-responsive IPv4 addresses, which is around 4% of advertised addresses. http://www.ripe.net/ripe/meetings/ripe-55/presentations/huston-ipv4.pdf Geoff Huston's "train wreck" presentation, in which he estimates that only 5 to 20% of advertised IPv4 address space is actually used by a hosts. http://www.ripe.net/ripe/meetings/ripe-55/presentations/bush-ipv6-transition.pdf Randy Bush's presentation on the difficulties of introducing IPv6, and how every network using IPv6 will need some IPv4 space for a long time to come. - Robin From BillD at cait.wustl.edu Tue Nov 6 09:12:53 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 6 Nov 2007 08:12:53 -0600 Subject: [ppml] IRTF RRG: finer allocation of IPv4 space References: <472FF024.4090601@firstpr.com.au> Message-ID: Thank you Robin for you invitation and your work in this area. Denizens of the ppml and all those interested in addressing policy and the future of Internet communications and governance should be interested in solutions to the scaling of Internet routing. It is the bigger problem (IMO) that faces this community more than v4 exhaustion and v6 adoption. A solution to scalable routing and more efficient allocations and assignments of addresses solve many policy issues that seem quite sticky at the moment. Bill Darte ARIN AC -----Original Message----- From: ppml-bounces at arin.net on behalf of Robin Whittle Sent: Mon 11/5/2007 10:40 PM To: ppml at arin.net Subject: [ppml] IRTF RRG: finer allocation of IPv4 space Denizens of PPML may be interested in joining the IRTF Routing Research Group list: http://www.irtf.org/charter?gtype=rg&group=rrg http://psg.com/lists/rrg/2007/maillist.html The RRG is discussing several ITR-ETR (Ingress Tunnel Router - Egress Tunnel Router) schemes which are intended primarily to help the routing system scale well with growing demand for more multihomed end-user networks - for both IPv4 and IPv6. I think it would be great to have more hands on deck on the RRG list to discuss and critique the various proposals. At some stage, the RRG will recommend to the IETF what new architectural proposals should be developed further. I think this is likely to consist of one of the ITR-ETR schemes (or perhaps some combination of bits of them) and one or more enhancements to BGP. All of these ITR-ETR schemes enable address space to be assigned to end-user networks in finer divisions than is currently practical with BGP. Each such division does not involve a BGP advertised prefix - and in principle, individual IP addresses can be assigned. This means all these schemes all capable of enabling new management structures for IPv4 address space, including assigning space in increments as small as 128, 64, 32 ... 8, 4, 2 or 1 IP addresses. All these schemes are intended primarily to resolve the problems in routing scaling, for both IPv4 and IPv6, with incremental deployment and no changes to hosts or most BGP routers. While they are all, in principle, capable of enabling a much more efficient use of IPv4 space, for many more end-user networks, with multihoming and portability of addresses between ISPs, only my proposal - Ivip - has this as an explicit goal. The proposals are: LISP-CONS http://tools.ietf.org/html/draft-farinacci-lisp-04 http://tools.ietf.org/html/draft-meyer-lisp-cons-02 LISP-NERD http://tools.ietf.org/html/draft-farinacci-lisp-04 http://tools.ietf.org/html/draft-lear-lisp-nerd-02 eFIT-APT http://tools.ietf.org/html/draft-jen-apt-00 http://www.cs.ucla.edu/~lixia/papers/07SIG_IP6WS.pdf http://tools.ietf.org/html/draft-wang-ietf-efit-00 Ivip http://www.firstpr.com.au/ip/ivip/ http://tools.ietf.org/html/draft-whittle-ivip-arch-00 TRRP http://bill.herrin.us/network/trrp.html Also of interest: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ http://tools.ietf.org/html/draft-templin-inetmtu-05 Two proposals, applicable to all ITR-ETR schemes, for coping with the problems of Path MTU Discovery, MTU limits etc. in the tunnel between the ITR and the ETR. http://www.iab.org/about/workshops/routingandaddressing/ http://tools.ietf.org/html/rfc4984 The late 2006 IAB workshop on the routing and addressing crisis. http://www.firstpr.com.au/ip/ivip/comp/ My comparison of LISP-CONS/NERD, eFIT-APT and Ivip. http://www.isi.edu/ant/address/ http://www.isi.edu/~johnh/PAPERS/Heidemann07c.pdf http://www.firstpr.com.au/ip/host-density-per-prefix/ Two recent IPv4 ping surveys find just over 100 million ping-responsive IPv4 addresses, which is around 4% of advertised addresses. http://www.ripe.net/ripe/meetings/ripe-55/presentations/huston-ipv4.pdf Geoff Huston's "train wreck" presentation, in which he estimates that only 5 to 20% of advertised IPv4 address space is actually used by a hosts. http://www.ripe.net/ripe/meetings/ripe-55/presentations/bush-ipv6-transition.pdf Randy Bush's presentation on the difficulties of introducing IPv6, and how every network using IPv6 will need some IPv4 space for a long time to come. - Robin _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleibrand at internap.com Tue Nov 6 10:18:14 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 06 Nov 2007 09:18:14 -0600 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <00fc01c81d7d$40314f30$663816ac@atlanta.polycom.com> References: <4728F24B.4060101@internap.com><29A54911243620478FF59F00EBB12F47C323C4@ex01.drtel.lan><1194006691.22547.19.camel@obelix.sandbu> <00fc01c81d7d$40314f30$663816ac@atlanta.polycom.com> Message-ID: <473085B6.6080501@internap.com> Stephen Sprunk wrote: > Perhaps I'm cynical, but I believe if the industry doesn't show more > leadership and self-regulation, we're going to end up regulated by > outsiders. The question may not be "are the RIRs competent to do this" but > rather "are the RIRs less incompetent than the other options." As > horrifying as the thought of turning control of the DFZ over to PPML/NANOG > may be, it's slightly less horrifying than turning it over to Congress and > the FCC -- or the UN. IMHO, as always. > Well put. This is exactly why I ran for the ARIN AC. I know enough to know that I don't know all the answers (too many knows, I know), but I do believe these kinds of questions are very important to address now, before the sky starts falling in Washington, New York, and in newsrooms around the world. > Another take is that if the RIRs _were_ involved in routing policy, the > appropriate stakeholders and competent engineers would show up. > Many of us are already quite involved, and I agree with you that even more people will become more involved as the stakes go up. IMO, that will strengthen our public policy process, which will be necessary for the challenges of the upcoming period. -Scott From bjohnson at drtel.com Tue Nov 6 10:45:01 2007 From: bjohnson at drtel.com (Brian Johnson) Date: Tue, 6 Nov 2007 09:45:01 -0600 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <00fc01c81d7d$40314f30$663816ac@atlanta.polycom.com> References: <4728F24B.4060101@internap.com><29A54911243620478FF59F00EBB12F47C323C4@ex01.drtel.lan><1194006691.22547.19.camel@obelix.sandbu> <00fc01c81d7d$40314f30$663816ac@atlanta.polycom.com> Message-ID: <29A54911243620478FF59F00EBB12F47D0EC48@ex01.drtel.lan> Stephen Sprunk wrote: > > Perhaps I'm cynical, but I believe if the industry doesn't show more > leadership and self-regulation, we're going to end up regulated by > outsiders. The question may not be "are the RIRs competent to do this" > but > rather "are the RIRs less incompetent than the other options." YES. ARIN is far less competent than the current system. If you are asking yourself "what is the current system?", please excuse yourself from this thread. > As > horrifying as the thought of turning control of the DFZ over to > PPML/NANOG > may be, it's slightly less horrifying than turning it over to Congress > and > the FCC -- or the UN. IMHO, as always. > I would agree that if ANY government type agency were in charge of routing policy, you might as well go looking for a better job if you are a network engineer. - Brian From bjohnson at drtel.com Tue Nov 6 10:45:10 2007 From: bjohnson at drtel.com (Brian Johnson) Date: Tue, 6 Nov 2007 09:45:10 -0600 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: References: <4728F24B.4060101@internap.com><29A54911243620478FF59F00EBB12F47C323C4@ex01.drtel.lan><1194006691.22547.19.camel@obelix.sandbu> Message-ID: <29A54911243620478FF59F00EBB12F47D0EC49@ex01.drtel.lan> michael.dillon at bt.com wrote: > > This is a silly comment. The RIRs have no business in routing > policy because they do not have the expertise, and the true > stakeholders in member companies are not involved in the RIRs. > The RIRs have no competent advice to give an ISP on routing > policy. > Well said! > That said, there is nothing wrong with RIRs mediating some > coordination of routing policies between DFZ operators, but > this must be done, first and foremost, by getting the routing > policy stakeholders involved in the process. If they don't buy-in, > then it won't work. > I would have absolutely no problem with this. I just do not want a single central authority making these sorts of decisions. This is how bad things happen even if the intentions are good. It's sort of like a separations of powers issue with me. > And please don't send me a list of the few PPML participants who > also happen to have design authority in their networks. I know > that there are a few such people, but the point is that RIR policy > is being set, for the most part, by people who do not design their > companies' networks or set their companies' routing policy. > I'm one of those people and while I want to have input into the process, I don't want to be dictated, by ARIN, as to my routing policy. I believe that market forces will deal with this. - Brian From info at arin.net Wed Nov 7 17:33:53 2007 From: info at arin.net (Member Services) Date: Wed, 07 Nov 2007 17:33:53 -0500 Subject: [ppml] Policy Proposal: Cooperative distribution of the end of the IPv4 free pool Message-ID: <47323D51.1070005@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 ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as a formal policy proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision. If a proposal is not accepted, then 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 AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. 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/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Cooperative distribution of the end of the IPv4 free pool Author: Tony Hain Proposal Version: 1.0 Submission Date: Oct-30-2007 Proposal type: new Policy term: permanent Policy summary: This policy will establish a process for RIR-to-RIR redistribution of the tail-end of the IPv4 pool, taking effect after the IANA Reserve is exhausted. Each redistribution Allocation will be triggered by the recipient RIR depleting its reserve to a 30 day supply, and will result in up to a 3 month supply being transferred from the RIR with the longest remaining time before it exhausts its own pool. Policy statement: At the point when any given RIR is within 30 days of depleting its remaining IPv4 pool, a survey will be taken of the other 4 to determine the remaining time before each of them exhausts their pool (including both member use and recent redistribution allocations to other RIRs). The one with the longest window before exhausting its pool will be designated as the source RIR. The recipient RIR will follow procedures for an LIR in the source RIR region to request a block that is expected to be sufficient for up to 3 months, but is no larger than 1/8th of the source RIR's remaining pool. At the point where no RIR can supply a block that is less than 1/8th of their remaining pool that will sustain the recipient RIR for 30 days, the recipient RIR will collect its requests each week, and forward those individual requests to the source RIR designated that week. Rationale: This policy will establish a mechanism for the Allocation of IPv4 address blocks between RIR's, but will not go into effect until the IANA pool has been depleted. It is really bizarre to watch the maneuvering as the global RIR community grapples with 'fairness' of distributing the last few IANA Reserve /8 blocks. On one level this just appears to be petty sibling rivalry, as people are bickering over who gets the last cookie and whimpering about 'fairness'. At the same time, each RIR is chartered to look after the interests of its membership so it is to be expected that they will each want to get as much as possible to meet the needs of their respective membership. Existing practice requires RIR's to acquire blocks from IANA, which leads to the current round of nonsense about optimal distribution of the remaining pool based on elaborate mathematical models. This globally submitted policy proposal attempts to resolve the issue by shifting to an RIR-to-RIR Allocation model after the IANA pool is depleted. This policy would effectively result in each RIR becoming a virtual LIR member of all of the other RIR's for the sole purpose of managing the tail-end of the IPv4 pool. Timetable for implementation: Before 1/1/2009 From info at arin.net Thu Nov 8 08:22:04 2007 From: info at arin.net (Member Services) Date: Thu, 08 Nov 2007 08:22:04 -0500 Subject: [ppml] Policy Proposal: Cooperative distribution of the end of the IPv4 free pool In-Reply-To: <47323D51.1070005@arin.net> References: <47323D51.1070005@arin.net> Message-ID: <47330D7C.8030209@arin.net> > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. The shepherds from the ARIN Advisory Council for this proposal are Leo Bicknell and Bill Darte. Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > 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 ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as a formal policy proposal as written. If > the AC accepts the proposal, it will be posted as a formal policy > proposal to PPML and it will be presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The AC > will work with the author to clarify, combine or divide the proposal. At > their following meeting the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision. If a proposal is not accepted, then > 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 AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > 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/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Cooperative distribution of the end of the IPv4 > free pool > > Author: Tony Hain > > Proposal Version: 1.0 > > Submission Date: Oct-30-2007 > > Proposal type: new > > Policy term: permanent > > Policy summary: > This policy will establish a process for RIR-to-RIR redistribution of > the tail-end of the IPv4 pool, taking effect after the IANA Reserve is > exhausted. Each redistribution Allocation will be triggered by the > recipient RIR depleting its reserve to a 30 day supply, and will result > in up to a 3 month supply being transferred from the RIR with the > longest remaining time before it exhausts its own pool. > > Policy statement: > At the point when any given RIR is within 30 days of depleting its > remaining IPv4 pool, a survey will be taken of the other 4 to determine > the remaining time before each of them exhausts their pool (including > both member use and recent redistribution allocations to other RIRs). > The one with the longest window before exhausting its pool will be > designated as the source RIR. The recipient RIR will follow procedures > for an LIR in the source RIR region to request a block that is expected > to be sufficient for up to 3 months, but is no larger than 1/8th of the > source RIR's remaining pool. At the point where no RIR can supply a > block that is less than 1/8th of their remaining pool that will sustain > the recipient RIR for 30 days, the recipient RIR will collect its > requests each week, and forward those individual requests to the source > RIR designated that week. > > Rationale: > This policy will establish a mechanism for the Allocation of IPv4 > address blocks between RIR's, but will not go into effect until the IANA > pool has been depleted. > > It is really bizarre to watch the maneuvering as the global RIR > community grapples with 'fairness' of distributing the last few IANA > Reserve /8 blocks. On one level this just appears to be petty sibling > rivalry, as people are bickering over who gets the last cookie and > whimpering about 'fairness'. At the same time, each RIR is chartered to > look after the interests of its membership so it is to be expected that > they will each want to get as much as possible to meet the needs of > their respective membership. > > Existing practice requires RIR's to acquire blocks from IANA, which > leads to the current round of nonsense about optimal distribution of the > remaining pool based on elaborate mathematical models. > > This globally submitted policy proposal attempts to resolve the issue by > shifting to an RIR-to-RIR Allocation model after the IANA pool is depleted. > > This policy would effectively result in each RIR becoming a virtual LIR > member of all of the other RIR's for the sole purpose of managing the > tail-end of the IPv4 pool. > > Timetable for implementation: Before 1/1/2009 > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From rich at commandinformation.com Wed Nov 14 12:28:41 2007 From: rich at commandinformation.com (Rich, Yurie) Date: Wed, 14 Nov 2007 12:28:41 -0500 Subject: [ppml] Policy Proposal Name: IPv6 Assignment Size Reduction Message-ID: <1AD33A3140054D45A0EF89AB74D5B1E1C1FE66@SFED01.fed.corp.cmdinfo.com> For reasons too numerous to list here, I'll simply state that I, my company - Command Information, and many of the customers I represent, including the IPv6 Business Council, strongly oppose this policy proposal. Not only does it fundamentally break numerous structures in IPv6 environments, it is attempting to solve a problem that doesn't exist. I applaud efforts to learn from our previous mistakes and integrate a conservationist mindset for IPv6 address allocation, but I don't believe this policy will accomplish that. Regards, Yurie Rich Director, IPv6 Services Group Command Information > 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 ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as a formal policy proposal as written. If > the AC accepts the proposal, it will be posted as a formal policy > proposal to PPML and it will be presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The > AC will work with the author to clarify, combine or divide the > proposal. At their following meeting the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept the > proposal, the AC will explain their decision. If a proposal is not > accepted, then 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 AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this proposal > on the PPML, particularly their support or non-support and the > reasoning behind their opinion. Such participation contributes to a > thorough vetting and provides important guidance to the AC in their deliberations. > > 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/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: IPv6 Assignment Size Reduction > > Author: Brian Dickson > > Proposal Version: 1 > > Submission Date: Oct 18, 2007 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > 6.5.4.1. Assignment address space size > > End-users are assigned an end site assignment from their LIR or ISP. > The exact size of the assignment is a local decision for the LIR or > ISP to make, using a minimum value of a /120 (when only one subnet is > anticipated for the end site) up to the normal maximum of /48, except > in cases of extra large end sites where a larger assignment can be justified. > > The following guidelines may be useful (but they are only guidelines): > > * /120 for a very small customer with one subnet, using static > assignments or DHCPv6 > * /116 for a small customer with a few subnets, using static > assignments or DHCPv6 > * /112 for a medium size customer with a significant total number > of hosts and/or subnets, using static assignments and/or DHCPv6 > * /96 for large customers > * /80 for very large customers, or for customers using a proposed > modified version of V6-autoconf (which uses EUI-48 instead of EUI-64) > * /72 for customers with several subnets using modified > V6-autoconf (which uses EUI-48 instead of EUI-64) > * /64 when it is known that one and only one subnet is needed, > for a customer that absolutely requires either traditional IPv6 > autoconfiguration, or IPv6 host Interface Identifier cryptographic > generation > * /60 for sites where a mix of IPv6-autoconfiguration and other > address assignment techiques are required > * /56 for very large sites > * /52 for very, very large sites > * /48 for extremely large sites > > For end sites to whom reverse DNS will be delegated, the LIR/ISP > should consider making an assignment on a nibble (4-bit) boundary to > simplify reverse lookup delegation. > > Rationale: > > The intent is to provide more current guidance, to both ARIN members, > and to ARIN staff, based on available IPv6 technology, and for the > encouragement of efficient assignment of IPv6 address space. > > IPv6 supports numerous methods for address assignments to end nodes. > Those include autoconfiguration, static assignment, and DHCPv6. > Of those, only autoconfiguration requires use of /64 as the prefix size. > > Efficient use of IPv6 space should discourage widespread use of /64's, > or for use of autoconfiguration as the sole justification for > allocations of large address space. > > In particular, the effective lifetime of PA assignments to ISPs/LIRs, > is largely a factor of internal aggregation, and the size of end assignments. > > Rather than meeting ISP needs by assigning very large IPv6 PA blocks, > it would be wiser to encourage assignments that to not significantly > use up available PA space for the ISP, even for very large customers. > > The overall intent is to minimize the need for any PA recipient, to > return to ARIN for subsequent assignments, thus reducing the need for > additional globally routable prefixes using up slots in routers in the > DFZ - something that affects the long-term ability for all ISPs to > continue to scale in a cost-effective manner. > > Timetable for implementation: Immediate > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN > Member Services Help Desk at info at arin.net if you experience any issues. > Powered by CardScan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 11488 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3098 bytes Desc: not available URL: From cort at kanren.net Wed Nov 14 13:09:08 2007 From: cort at kanren.net (Cort Buffington) Date: Wed, 14 Nov 2007 12:09:08 -0600 Subject: [ppml] Policy Proposal Name: IPv6 Assignment Size Reduction In-Reply-To: <1AD33A3140054D45A0EF89AB74D5B1E1C1FE66@SFED01.fed.corp.cmdinfo.com> References: <1AD33A3140054D45A0EF89AB74D5B1E1C1FE66@SFED01.fed.corp.cmdinfo.com> Message-ID: <624FA7B5-D1B9-4C6D-9EEA-F3F99077FCBB@kanren.net> I agree completely with Yurie. This proposal only proves that the policy-makers at ARIN are incapable of thinking in the IPv6 paradigm, and continue to think that IPv6 is IPv4 with larger address space. On Nov 14, 2007, at 11:28 AM, Rich, Yurie wrote: > For reasons too numerous to list here, I?ll simply state that I, my > company ? Command Information, and many of the customers I > represent, including the IPv6 Business Council, strongly oppose this > policy proposal. Not only does it fundamentally break numerous > structures in IPv6 environments, it is attempting to solve a problem > that doesn?t exist. I applaud efforts to learn from our previous > mistakes and integrate a conservationist mindset for IPv6 address > allocation, but I don?t believe this policy will accomplish that. > > Regards, > > Yurie Rich > Director, IPv6 Services Group > Command Information > > > > 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 ARIN Advisory Council (AC) will review this proposal at their > next > > regularly scheduled meeting. The AC may decide to: > > > > 1. Accept the proposal as a formal policy proposal as written. > If > > the AC accepts the proposal, it will be posted as a formal policy > > proposal to PPML and it will be presented at a Public Policy > Meeting. > > > > 2. Postpone their decision regarding the proposal until the next > > regularly scheduled AC meeting in order to work with the author. The > > AC will work with the author to clarify, combine or divide the > > proposal. At their following meeting the AC will accept or not > accept the proposal. > > > > 3. Not accept the proposal. If the AC does not accept the > > proposal, the AC will explain their decision. If a proposal is not > > accepted, then 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 AC will assign shepherds in the near future. ARIN will provide > the > > names of the shepherds to the community via the PPML. > > > > In the meantime, the AC invites everyone to comment on this proposal > > on the PPML, particularly their support or non-support and the > > reasoning behind their opinion. Such participation contributes to a > > thorough vetting and provides important guidance to the AC in > their deliberations. > > > > 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/ > > > > Regards, > > > > Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ## * ## > > > > > > Policy Proposal Name: IPv6 Assignment Size Reduction > > > > Author: Brian Dickson > > > > Proposal Version: 1 > > > > Submission Date: Oct 18, 2007 > > > > Proposal type: modify > > > > Policy term: permanent > > > > Policy statement: > > > > 6.5.4.1. Assignment address space size > > > > End-users are assigned an end site assignment from their LIR or ISP. > > The exact size of the assignment is a local decision for the LIR or > > ISP to make, using a minimum value of a /120 (when only one subnet > is > > anticipated for the end site) up to the normal maximum of /48, > except > > in cases of extra large end sites where a larger assignment can be > justified. > > > > The following guidelines may be useful (but they are only > guidelines): > > > > * /120 for a very small customer with one subnet, using static > > assignments or DHCPv6 > > * /116 for a small customer with a few subnets, using static > > assignments or DHCPv6 > > * /112 for a medium size customer with a significant total > number > > of hosts and/or subnets, using static assignments and/or DHCPv6 > > * /96 for large customers > > * /80 for very large customers, or for customers using a > proposed > > modified version of V6-autoconf (which uses EUI-48 instead of > EUI-64) > > * /72 for customers with several subnets using modified > > V6-autoconf (which uses EUI-48 instead of EUI-64) > > * /64 when it is known that one and only one subnet is needed, > > for a customer that absolutely requires either traditional IPv6 > > autoconfiguration, or IPv6 host Interface Identifier cryptographic > > generation > > * /60 for sites where a mix of IPv6-autoconfiguration and other > > address assignment techiques are required > > * /56 for very large sites > > * /52 for very, very large sites > > * /48 for extremely large sites > > > > For end sites to whom reverse DNS will be delegated, the LIR/ISP > > should consider making an assignment on a nibble (4-bit) boundary to > > simplify reverse lookup delegation. > > > > Rationale: > > > > The intent is to provide more current guidance, to both ARIN > members, > > and to ARIN staff, based on available IPv6 technology, and for the > > encouragement of efficient assignment of IPv6 address space. > > > > IPv6 supports numerous methods for address assignments to end nodes. > > Those include autoconfiguration, static assignment, and DHCPv6. > > Of those, only autoconfiguration requires use of /64 as the prefix > size. > > > > Efficient use of IPv6 space should discourage widespread use of / > 64's, > > or for use of autoconfiguration as the sole justification for > > allocations of large address space. > > > > In particular, the effective lifetime of PA assignments to ISPs/ > LIRs, > > is largely a factor of internal aggregation, and the size of end > assignments. > > > > Rather than meeting ISP needs by assigning very large IPv6 PA > blocks, > > it would be wiser to encourage assignments that to not significantly > > use up available PA space for the ISP, even for very large > customers. > > > > The overall intent is to minimize the need for any PA recipient, to > > return to ARIN for subsequent assignments, thus reducing the need > for > > additional globally routable prefixes using up slots in routers in > the > > DFZ - something that affects the long-term ability for all ISPs to > > continue to scale in a cost-effective manner. > > > > Timetable for implementation: Immediate > > > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the > ARIN > > Public Policy Mailing List (PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN > > Member Services Help Desk at info at arin.net if you experience any > issues. > > > > > > > > Powered by CardScan > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the > ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN > Member Services > Help Desk at info at arin.net if you experience any issues. -- Cort Buffington Assistant Director for Technical Services The Kansas Research and Education Network cort at kanren.net Office: +1-785-856-9800 x301 Mobile: +1-785-865-7206 From michael.dillon at bt.com Wed Nov 14 13:25:31 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 14 Nov 2007 18:25:31 -0000 Subject: [ppml] Policy Proposal Name: IPv6 Assignment Size Reduction In-Reply-To: <624FA7B5-D1B9-4C6D-9EEA-F3F99077FCBB@kanren.net> References: <1AD33A3140054D45A0EF89AB74D5B1E1C1FE66@SFED01.fed.corp.cmdinfo.com> <624FA7B5-D1B9-4C6D-9EEA-F3F99077FCBB@kanren.net> Message-ID: > I agree completely with Yurie. This proposal only proves that > the policy-makers at ARIN are incapable of thinking in the > IPv6 paradigm, and continue to think that IPv6 is IPv4 with > larger address space. I also agree with Yurie, however I disagree with you. How would you feel if people went around saying that Cort Buffington is incapable of thinking in the IPv6 paradigm and continues to think that IPv6 is IPv4 with larger address space? Because that is precisely what you *ARE* saying about Cort Buffington. And you can trust me on this because I read it on the ARIN PPML and that is a pretty authoritative source of information. In case you don't quite get this variation on the pot calling the kettle black, you, Cort Buffington are one of the ARIN policy-makers so any slur that you cast on this group is a slur on yourself. I'd also like to note that this is a proposal submitted by one individual and does not reflect the views of ARIN policy-makers until it has passed the gauntlet of this list, a members' meeting and an Advisory Council meeting. To reiterate, I agree with Yurie that this policy is a bad idea for many reasons and I don't think it is productive to list them all. --Michael Dillon P.S. I tend to agree with you that there are too many people still stuck in IPv4 thinking who just don't get IPv6 yet. But that is an education problem more suitable to deal with on the ARIN IPv6 wiki at http://www.getipv6.info than on PPML. From cort at kanren.net Wed Nov 14 13:33:41 2007 From: cort at kanren.net (Cort Buffington) Date: Wed, 14 Nov 2007 12:33:41 -0600 Subject: [ppml] Policy Proposal Name: IPv6 Assignment Size Reduction In-Reply-To: References: <1AD33A3140054D45A0EF89AB74D5B1E1C1FE66@SFED01.fed.corp.cmdinfo.com> <624FA7B5-D1B9-4C6D-9EEA-F3F99077FCBB@kanren.net> Message-ID: Yes, then I to accuse an entire body -- such as the ARIN membership of this. Myself included. Probably worse for me. I know better, but use the excuse that I don't have the time to donate to help educate the world and be active enough to try and be part of swaying such proposals before they happen rather than just bad-mouthing them after they've been produced by hard-working folks who do take the time to put them together. I spend time on the PPML armchair quarterbacking rather than on the IPv6 Wiki contributing information. Michael, I take your comments to heart. To the Wiki with me. On Nov 14, 2007, at 12:25 PM, wrote: > >> I agree completely with Yurie. This proposal only proves that >> the policy-makers at ARIN are incapable of thinking in the >> IPv6 paradigm, and continue to think that IPv6 is IPv4 with >> larger address space. > > I also agree with Yurie, however I disagree with you. > > How would you feel if people went around saying that Cort Buffington > is > incapable of thinking in the IPv6 paradigm and continues to think that > IPv6 is IPv4 with larger address space? Because that is precisely what > you *ARE* saying about Cort Buffington. > > And you can trust me on this because I read it on the ARIN PPML and > that > is a pretty authoritative source of information. > > In case you don't quite get this variation on the pot calling the > kettle > black, you, Cort Buffington are one of the ARIN policy-makers so any > slur that you cast on this group is a slur on yourself. > > I'd also like to note that this is a proposal submitted by one > individual and does not reflect the views of ARIN policy-makers > until it > has passed the gauntlet of this list, a members' meeting and an > Advisory > Council meeting. To reiterate, I agree with Yurie that this policy > is a > bad idea for many reasons and I don't think it is productive to list > them all. > > --Michael Dillon > > P.S. I tend to agree with you that there are too many people still > stuck > in IPv4 thinking who just don't get IPv6 yet. But that is an education > problem more suitable to deal with on the ARIN IPv6 wiki at > http://www.getipv6.info than on PPML. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the > ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN > Member Services > Help Desk at info at arin.net if you experience any issues. > -- Cort Buffington Assistant Director for Technical Services The Kansas Research and Education Network cort at kanren.net Office: +1-785-856-9800 x301 Mobile: +1-785-865-7206 From michael.dillon at bt.com Wed Nov 14 13:51:04 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 14 Nov 2007 18:51:04 -0000 Subject: [ppml] Policy Proposal Name: IPv6 Assignment Size Reduction In-Reply-To: References: <1AD33A3140054D45A0EF89AB74D5B1E1C1FE66@SFED01.fed.corp.cmdinfo.com> <624FA7B5-D1B9-4C6D-9EEA-F3F99077FCBB@kanren.net> Message-ID: > ... I don't have the time to > donate to help educate the world and be active enough to try > and be part of swaying such proposals before they happen > rather than just bad-mouthing them after they've been > produced by hard-working folks who do take the time to put > them together. Nobody will ever be able to sway the authors of bad proposals before they happen, but once the proposal is officially submitted to ARIN, it is important to post some sort of reply voicing your support for a proposal or your opposition. At the ARIN meeting, when the proposal is presented, they also state how many people on the list spoke FOR the proposal and how many AGAINST it. That is one of the pieces of information that the Advisory Council considers before deciding what to do with a proposal. So, armchair quarterbacking is a good thing and it is part of the policymaking process. --Michael Dillon P.S. Remember that most proposals *NEVER* become ARIN policy. From stephen at sprunk.org Wed Nov 14 14:33:59 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 14 Nov 2007 13:33:59 -0600 Subject: [ppml] Policy Proposal Name: IPv6 Assignment Size Reduction References: <1AD33A3140054D45A0EF89AB74D5B1E1C1FE66@SFED01.fed.corp.cmdinfo.com> <624FA7B5-D1B9-4C6D-9EEA-F3F99077FCBB@kanren.net> Message-ID: <012301c826f9$d65ab480$6401a8c0@atlanta.polycom.com> Thus spake "Cort Buffington" > I agree completely with Yurie. This proposal only proves that the > policy-makers at ARIN are incapable of thinking in the IPv6 > paradigm, and continue to think that IPv6 is IPv4 with larger > address space. A proposal is just that: a proposal. More importantly, it's by an individual, and it's up to the rest of us "ARIN policy-makers", including you, to say whether we think it's a good or bad one. The AC will determine whether there's consensus either way. Speaking for myself only, I think this proposal falls in the "bad" category for two main reasons. The first is (as you note) that it's applying IPv4 thinking inappropriately to IPv6; there is no shortage of bits to worry about in IPv6, and we shouldn't be trying to import the nightmares of subnet sizing, defeating one of IPv6's few advantages. The second is that, based on comments at the recent meeting, it becamse clear to me that "guidelines" do not belong in the NRPM, only concrete requirements that staff can apply to requests; this proposal not only fails to fix that problem with 6.5.4.1 but indeed makes it worse. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From BillD at cait.wustl.edu Thu Nov 15 15:18:06 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Thu, 15 Nov 2007 14:18:06 -0600 Subject: [ppml] Policy Proposal Name: IPv6 Assignment Size Reduction References: <1AD33A3140054D45A0EF89AB74D5B1E1C1FE66@SFED01.fed.corp.cmdinfo.com><624FA7B5-D1B9-4C6D-9EEA-F3F99077FCBB@kanren.net> Message-ID: Here, Here! Bill Darte ARIN AC -----Original Message----- From: ppml-bounces at arin.net on behalf of michael.dillon at bt.com Sent: Wed 11/14/2007 12:51 PM To: ppml at arin.net Subject: Re: [ppml] Policy Proposal Name: IPv6 Assignment Size Reduction > ... I don't have the time to > donate to help educate the world and be active enough to try > and be part of swaying such proposals before they happen > rather than just bad-mouthing them after they've been > produced by hard-working folks who do take the time to put > them together. Nobody will ever be able to sway the authors of bad proposals before they happen, but once the proposal is officially submitted to ARIN, it is important to post some sort of reply voicing your support for a proposal or your opposition. At the ARIN meeting, when the proposal is presented, they also state how many people on the list spoke FOR the proposal and how many AGAINST it. That is one of the pieces of information that the Advisory Council considers before deciding what to do with a proposal. So, armchair quarterbacking is a good thing and it is part of the policymaking process. --Michael Dillon P.S. Remember that most proposals *NEVER* become ARIN policy. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ipgoddess at gmail.com Thu Nov 15 15:23:27 2007 From: ipgoddess at gmail.com (Stacy Taylor) Date: Thu, 15 Nov 2007 12:23:27 -0800 Subject: [ppml] Policy Proposal Name: IPv6 Assignment Size Reduction In-Reply-To: <012301c826f9$d65ab480$6401a8c0@atlanta.polycom.com> References: <1AD33A3140054D45A0EF89AB74D5B1E1C1FE66@SFED01.fed.corp.cmdinfo.com> <624FA7B5-D1B9-4C6D-9EEA-F3F99077FCBB@kanren.net> <012301c826f9$d65ab480$6401a8c0@atlanta.polycom.com> Message-ID: <1c16a4870711151223m6c66fd0bn352872a53c06d7b0@mail.gmail.com> I agree with Stephen and Yuri AND Cort. :) Stacy On Nov 14, 2007 11:33 AM, Stephen Sprunk wrote: > Thus spake "Cort Buffington" > > I agree completely with Yurie. This proposal only proves that the > > policy-makers at ARIN are incapable of thinking in the IPv6 > > paradigm, and continue to think that IPv6 is IPv4 with larger > > address space. > > A proposal is just that: a proposal. More importantly, it's by an > individual, and it's up to the rest of us "ARIN policy-makers", including > you, to say whether we think it's a good or bad one. The AC will determine > whether there's consensus either way. > > Speaking for myself only, I think this proposal falls in the "bad" category > for two main reasons. The first is (as you note) that it's applying IPv4 > thinking inappropriately to IPv6; there is no shortage of bits to worry > about in IPv6, and we shouldn't be trying to import the nightmares of subnet > sizing, defeating one of IPv6's few advantages. The second is that, based > on comments at the recent meeting, it becamse clear to me that "guidelines" > do not belong in the NRPM, only concrete requirements that staff can apply > to requests; this proposal not only fails to fix that problem with 6.5.4.1 > but indeed makes it worse. > > S > > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > -- :):) /S From bonomi at mail.r-bonomi.com Thu Nov 15 19:28:42 2007 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Thu, 15 Nov 2007 18:28:42 -0600 (CST) Subject: [ppml] Policy Proposal Name: IPv6 Assignment Size Reduction Message-ID: <200711160028.lAG0Sgtg000658@mail.r-bonomi.com> For the record, one more party opines that this proposal is in the Bad Idea(TM) class. The 'why' has been already clearly elucidated, no need to repeat. From dmf at unl.edu Thu Nov 15 19:34:15 2007 From: dmf at unl.edu (Dale M Finkelson) Date: Thu, 15 Nov 2007 18:34:15 -0600 Subject: [ppml] Policy Proposal Name: IPv6 Assignment Size Reduction In-Reply-To: <200711160028.lAG0Sgtg000658@mail.r-bonomi.com> Message-ID: Hi, I agree this is a bad idea, for much the same reasons that have been articulated to date. Dale Finkelson -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveb at eagle.ca Fri Nov 16 08:25:24 2007 From: steveb at eagle.ca (Steve Bertrand) Date: Fri, 16 Nov 2007 08:25:24 -0500 Subject: [ppml] Policy Proposal Name: IPv6 Assignment Size Reduction In-Reply-To: References: <1AD33A3140054D45A0EF89AB74D5B1E1C1FE66@SFED01.fed.corp.cmdinfo.com> <624FA7B5-D1B9-4C6D-9EEA-F3F99077FCBB@kanren.net> Message-ID: <473D9A44.2040201@eagle.ca> michael.dillon at bt.com wrote: > So, armchair quarterbacking is a good thing and it is part of the > policymaking process. For the record then, and given what you said about the NAY/YAY consideration at the meetings, myself, and the company that I work for strongly oppose this policy. Steve From briand at ca.afilias.info Fri Nov 16 14:53:16 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Fri, 16 Nov 2007 14:53:16 -0500 Subject: [ppml] IPv6 addressing, allocation, and subnets In-Reply-To: <471D3021.5080606@ca.afilias.info> References: <471CC069.6040005@arin.net> <20071022160654.GS23649@shell01.cell.sv2.tellme.com> <471D3021.5080606@ca.afilias.info> Message-ID: <473DF52C.4090409@ca.afilias.info> [This message/thread is intended to provide further context for discussions on IPv6 allocation policies. I have one request: please refrain from discussion *of* those policies within this thread, if possible.] Addressing schemes and allocation policies, *within* an organization, can and do vary substantially. I would like to illustrate some non-trivial situations, which lead to some such schemes. And, most importantly, how managing combined IPv4 and IPv6 addressing schemes is one area of special importance when considering policies specific to IPv6. First, let's dispose of the trivial situations. These would include, but are not limited to: - greenfield networks doing IPv6 only - client-only networks (e.g. consumer ISPs with dynamic IP address allocation only) - sites using autoconfiguration only (In fact, the greenfield situation isn't necessarily trivial, as we will discuss below; however, we don't want to add to the confusion just yet.) So, we want to take a look at networks where: - both IPv4 and IPv6 are in use, or will be in use - some of the IP addresses are assigned to hosts, where the addresses assigned do not change - there is more than one prefix in use within the site (otherwise, this too is a "trivial" set-up) When there is more than one prefix in use at a site, in the IPv4 world, there are many possible reasons: - growth - hosts needed to be added to a subnet, and renumbering was not feasible, so additional prefixes were added to the same physical LAN - separation - the need to keep functional separation between sets of hosts (e.g. clients and servers, for security domain reasons) - utilization - too much traffic existed on a single LAN, and the LAN was partitioned to accommodate the traffic - portability - in anticipation of relocating servers or sets of servers, they were numbered from different prefixes from the outset, so that relocation would not require renumbering Certainly, the last three (separation, utilization, portability) are invariant across IP versions - the same situation would exist under both IPv4 and IPv6. Any of those reasons would require subnet usage, whether under IPv4 or IPv6. As to growth, in the IPv6 world, *future* growth would likely be trivially accommodated within the sizes of subnets available. And at some point, IPv4 growth will cease to be viable, so nearly all growth would need to be handled within IPv6 address blocks. However, if a non-trivial amount of sub-netting due to growth existed in IPv4, the same rules for the other three subnet conditions are likely to apply. When establishing a network plan for a dual-stack environment, where there is already a significant deployment of IPv4, and the above situations exist (separation, utilization, portability), management of the addressing scheme is an important consideration. The easiest scheme is that of a direct mapping. Treat the sub-netting scheme from one or more blocks, as a tree with a single root, and map that wholesale onto an IPv6 prefix. The host portion of each subnet would be numbered identically, permitting very scalable management of the IP addressing for both IPv4 and IPv6 for all such dual-stack hosts. Advanced versions may introduce extra bits into the subnet scheme by left-shifting and zero-padding, by some number of bits, for the whole network plan. For example, VLSM scheme consisting of three /26's, a /27, and two /28's, numbered out of a single /24, instead of being mapped onto a /120, might be mapped onto a /12, expanding each prefix by 8 bits. The prefixes would be three /114's, a /115, and two /116's. The hosts in the /27 (ranging from .1 to .31) would still have the same last 5 bits, but there would now be 13 bits of host on that prefix. In the absence of the ability to assign prefixes longer than /64, the management of dual-stacked hosts becomes a nightmare. Rather than treat the whole tree as a mapped entity, each prefix in the tree would need a corresponding mapped prefix. This is something which demonstrably does not scale, and the larger the original prefix, the greater the pain. Let's consider some examples of methods which can *only* work if assignments of subnets > /64 are possible. Consider an ISP X, who has customers Y and Z. Both Y and Z have multiple IPv4 prefixes assigned to them by X, all of which are PA. X intends on offering IPv6 service to Y and Z in addition to IPv4. These too will be PA assignments. What X would like to do, is give Y and Z the easy way out - have IPv6 blocks for each, suitable for mapping their non-continguous IPv4 assignments. This would be trivially possible by using a /96 for *each* of Y and Z, or even a larger block, such as a /88 or even a /80. Mapping all of Y's existing IPv4 prefixes would be done by the trivial binary "OR" of the new IPv6 block for Y, call it Y::/96, and the existing 32-bit values for the IPv4 prefixes, Y1, Y2, ..., Yn, as 128-bit values "::Yn". The trees for Y and Z will be sparse, of course, but will have 1:1 address mapping for all IPv4 and IPv6 addresses used by Y and Z. (The trick is, the mapping is different for Y and for Z.) The original blocks in IPv4 would contain intermingled Y and Z prefixes, within blocks assigned to X. The mapped blocks would separate out the Y and Z components, within sparse copies of the mapped *entire* IPv4 space. The number of blocks that X would need to maintain would be N, the number of customers of X, rather than M*N, the number of assignments made to all customers in the history of X. If X is not able to make assignments > /64, or to register those assignments, all of this is impossible, or alternatively, must allocate a huge amount of space per customer to handle these mappings. For example, of Y has prefixes as long as /29, and address space from both traditional class "A" and class "C" space, then 29 bits are needed for a mapping region. The smallest prefix able to handle the whole range of Y's existing IPv4 space, as a 1:1 single mapping into IPv6, would be a /(64-29) or a /35. The only other options are for Y to be given multiple IPv6 assignments by X. In other words, by making the IPv6 assignments the same as, or even worse than, the IPv4 assignments. (Worse than, because every assignment would be a /64.) If you were X, would you be in any rush to do this, until customers requested IPv6 space? And would you even *try* to handle requests in any manner other than as new requests, rather than support customers wanting to do such mappings? Brian Dickson From sleibrand at internap.com Fri Nov 16 15:27:13 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 16 Nov 2007 12:27:13 -0800 Subject: [ppml] IPv6 addressing, allocation, and subnets In-Reply-To: <473DF52C.4090409@ca.afilias.info> References: <471CC069.6040005@arin.net> <20071022160654.GS23649@shell01.cell.sv2.tellme.com> <471D3021.5080606@ca.afilias.info> <473DF52C.4090409@ca.afilias.info> Message-ID: <473DFD21.40903@internap.com> Brian, Do I understand your argument correctly that you perceive the primary driver for IPv6 addressing plans to be compatibility with (and similarity to) the existing IPv4 plans? If so, then your argument that we need to do things similarly to how we do them in IPv4 applies, because your goal is to have everything as similar as possible to the IPv4 setup. An alternative, however, would be to set your IPv6 addressing plans up to be independent of your IPv4 addressing plan (which, as you outlined, often comes with a lot of cruft due to networks and subnets being too small to accommodate growth). In such a scenario, you could choose to have all subnets be /64 (to accommodate currently-deployed autoconfiguration methods as well as addressing methods like HBA and CGA). There is no reason for an IPv6 subnet to be larger than /64: just because you assign a /64 for a LAN with an IPv4 /29 doesn't mean you need a /63 for a LAN that got a /28. If you don't want/need autoconfiguration, HBA, or CGA, you're free to deploy subnets smaller than /64. However, doing so comes with risks, as you may decide in the future that you really do need extra host bits. If those risks (or your renumbering costs) are negligible, that's fine. However, I think it's a mistake to encourage people to simply bit-map their IPv4 addressing architecture into IPv6 without considering whether such an addressing plan is ideal given the new capabilities of IPv6. In summary, I think you have correctly identified bit-mapping from IPv4 as one possible IPv6 addressing plan. However, I think it would be a mistake to encourage (or worse, require) networks to do such mapping, thereby incorporating complexity from their IPv4 addressing plan into their IPv6 network, without carefully considering whether a new addressing plan would be more appropriate for the IPv6 portion of their network. -Scott Brian Dickson wrote: > [This message/thread is intended to provide further context for > discussions on IPv6 allocation policies. > I have one request: please refrain from discussion *of* those policies > within this thread, if possible.] > > Addressing schemes and allocation policies, *within* an organization, > can and do vary substantially. > > I would like to illustrate some non-trivial situations, which lead to > some such schemes. > > And, most importantly, how managing combined IPv4 and IPv6 addressing > schemes is one area of special importance when considering policies > specific to IPv6. > > First, let's dispose of the trivial situations. > > These would include, but are not limited to: > - greenfield networks doing IPv6 only > - client-only networks (e.g. consumer ISPs with dynamic IP address > allocation only) > - sites using autoconfiguration only > > (In fact, the greenfield situation isn't necessarily trivial, as we will > discuss below; however, we don't want to add to the confusion just yet.) > > So, we want to take a look at networks where: > - both IPv4 and IPv6 are in use, or will be in use > - some of the IP addresses are assigned to hosts, where the addresses > assigned do not change > - there is more than one prefix in use within the site (otherwise, this > too is a "trivial" set-up) > > When there is more than one prefix in use at a site, in the IPv4 world, > there are many possible reasons: > - growth - hosts needed to be added to a subnet, and renumbering was not > feasible, so additional prefixes were added to the same physical LAN > - separation - the need to keep functional separation between sets of > hosts (e.g. clients and servers, for security domain reasons) > - utilization - too much traffic existed on a single LAN, and the LAN > was partitioned to accommodate the traffic > - portability - in anticipation of relocating servers or sets of > servers, they were numbered from different prefixes from the outset, so > that relocation would not require renumbering > > > Certainly, the last three (separation, utilization, portability) are > invariant across IP versions - the same situation would exist under both > IPv4 and IPv6. > Any of those reasons would require subnet usage, whether under IPv4 or IPv6. > > As to growth, in the IPv6 world, *future* growth would likely be > trivially accommodated within the sizes of subnets available. > And at some point, IPv4 growth will cease to be viable, so nearly all > growth would need to be handled within IPv6 address blocks. > However, if a non-trivial amount of sub-netting due to growth existed in > IPv4, the same rules for the other three subnet conditions are likely to > apply. > > When establishing a network plan for a dual-stack environment, where > there is already a significant deployment of IPv4, and the above > situations exist (separation, utilization, portability), management of > the addressing scheme is an important consideration. > > The easiest scheme is that of a direct mapping. > Treat the sub-netting scheme from one or more blocks, as a tree with a > single root, and map that wholesale onto an IPv6 prefix. > The host portion of each subnet would be numbered identically, > permitting very scalable management of the IP addressing for both IPv4 > and IPv6 for all such dual-stack hosts. > > Advanced versions may introduce extra bits into the subnet scheme by > left-shifting and zero-padding, by some number of bits, for the whole > network plan. > For example, VLSM scheme consisting of three /26's, a /27, and two > /28's, numbered out of a single /24, instead of being mapped onto a > /120, might be mapped onto a /12, expanding each prefix by 8 bits. > The prefixes would be three /114's, a /115, and two /116's. The hosts in > the /27 (ranging from .1 to .31) would still have the same last 5 bits, > but there would now be 13 bits of host on that prefix. > > In the absence of the ability to assign prefixes longer than /64, the > management of dual-stacked hosts becomes a nightmare. > > Rather than treat the whole tree as a mapped entity, each prefix in the > tree would need a corresponding mapped prefix. > This is something which demonstrably does not scale, and the larger the > original prefix, the greater the pain. > > Let's consider some examples of methods which can *only* work if > assignments of subnets > /64 are possible. > > Consider an ISP X, who has customers Y and Z. Both Y and Z have multiple > IPv4 prefixes assigned to them by X, all of which are PA. > X intends on offering IPv6 service to Y and Z in addition to IPv4. These > too will be PA assignments. > > What X would like to do, is give Y and Z the easy way out - have IPv6 > blocks for each, suitable for mapping their non-continguous IPv4 > assignments. > This would be trivially possible by using a /96 for *each* of Y and Z, > or even a larger block, such as a /88 or even a /80. > > Mapping all of Y's existing IPv4 prefixes would be done by the trivial > binary "OR" of the new IPv6 block for Y, call it Y::/96, and the > existing 32-bit values for the IPv4 prefixes, Y1, Y2, ..., Yn, as > 128-bit values "::Yn". > The trees for Y and Z will be sparse, of course, but will have 1:1 > address mapping for all IPv4 and IPv6 addresses used by Y and Z. > (The trick is, the mapping is different for Y and for Z.) > The original blocks in IPv4 would contain intermingled Y and Z prefixes, > within blocks assigned to X. > The mapped blocks would separate out the Y and Z components, within > sparse copies of the mapped *entire* IPv4 space. > The number of blocks that X would need to maintain would be N, the > number of customers of X, rather than M*N, the number of assignments > made to all customers in the history of X. > > If X is not able to make assignments > /64, or to register those > assignments, all of this is impossible, or alternatively, must allocate > a huge amount of space per customer to handle these mappings. > > For example, of Y has prefixes as long as /29, and address space from > both traditional class "A" and class "C" space, then 29 bits are needed > for a mapping region. > > The smallest prefix able to handle the whole range of Y's existing IPv4 > space, as a 1:1 single mapping into IPv6, would be a /(64-29) or a /35. > > The only other options are for Y to be given multiple IPv6 assignments by X. > In other words, by making the IPv6 assignments the same as, or even > worse than, the IPv4 assignments. > (Worse than, because every assignment would be a /64.) > > If you were X, would you be in any rush to do this, until customers > requested IPv6 space? > > And would you even *try* to handle requests in any manner other than as > new requests, rather than support customers wanting to do such mappings? > > Brian Dickson > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From briand at ca.afilias.info Fri Nov 16 15:30:03 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Fri, 16 Nov 2007 15:30:03 -0500 Subject: [ppml] IPv6 addressing, allocation, and subnets In-Reply-To: <473DF52C.4090409@ca.afilias.info> References: <471CC069.6040005@arin.net> <20071022160654.GS23649@shell01.cell.sv2.tellme.com> <471D3021.5080606@ca.afilias.info> <473DF52C.4090409@ca.afilias.info> Message-ID: <473DFDCB.5090508@ca.afilias.info> Brian Dickson wrote: > /120, might be mapped onto a /12, expanding each prefix by 8 bits. ObTypo: the /12 above should read /112. Brian From briand at ca.afilias.info Fri Nov 16 16:02:45 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Fri, 16 Nov 2007 16:02:45 -0500 Subject: [ppml] IPv6 addressing, allocation, and subnets In-Reply-To: <473DFD21.40903@internap.com> References: <471CC069.6040005@arin.net> <20071022160654.GS23649@shell01.cell.sv2.tellme.com> <471D3021.5080606@ca.afilias.info> <473DF52C.4090409@ca.afilias.info> <473DFD21.40903@internap.com> Message-ID: <473E0575.1070409@ca.afilias.info> Scott Leibrand wrote: > Brian, > > Do I understand your argument correctly that you perceive the primary > driver for IPv6 addressing plans to be compatibility with (and > similarity to) the existing IPv4 plans? If so, then your argument > that we need to do things similarly to how we do them in IPv4 applies, > because your goal is to have everything as similar as possible to the > IPv4 setup. > No, it's actually the converse of the above. The problem I'm illustrating is the hammer/nail problem. If it is not *possible* to do any kind of bit-mapped plan, then we are not supporting those who *might* choose to (or need to) do so. *Allowing* someone to do something, or providing them the means, is very different from encouraging it. On the other hand, if we make it impossible, we are taking away the option from anyone who may otherwise benefit from it. We take away all tools but the hammer. And, I believe that those who have the greatest likelihood of having non-trivial network addressing under IPv4, and a need to maintain dual-stack for such, are those who we *most* want to encourage adoption of IPv6 - the content folks. Making it as easy as possible to migrate to dual-stack as early as possible, should be something we keep in mind in considering policies for IPv6 allocation. Even if it isn't ARIN policy (yet) to officially encourage IPv6 adoption, it *is* policy among other similar groups, whose constituency has heavy overlap with ARIN. > An alternative, however, would be to set your IPv6 addressing plans up > to be independent of your IPv4 addressing plan (which, as you > outlined, often comes with a lot of cruft due to networks and subnets > being too small to accommodate growth). In such a scenario, you could > choose to have all subnets be /64 (to accommodate currently-deployed > autoconfiguration methods as well as addressing methods like HBA and > CGA). There is no reason for an IPv6 subnet to be larger than /64: > just because you assign a /64 for a LAN with an IPv4 /29 doesn't mean > you need a /63 for a LAN that got a /28. > Again, let me emphasize, this has to do with ARIN policy, not my own plans. Let's presume that the mapping scheme for one recipient involves a large number of subnets, more than what would reasonably be expected to have a hand-crafted subnet plan. I'm not sure where you would draw the line, but imagine a case of several dozen, say about 80 subnets, of varying sizes, scattered over several IPv4 CIDR blocks. The idea is ongoing management of combined IPv4 and IPv6 dual-stack hosts. This would presumably involve adding, removing, and changing addresses for hosts. Having a bit-mapped structure for the management of the combined IPv4 and IPv6 assignments, is considerably easy to manage than that of per-prefix mappings. Per-prefix mapping scales badly, as it requires maintaining the mapping in both directions, for every prefix independently. As soon as you get beyond double-digits of prefixes, it becomes unreasonable to expect anyone to embrace such a scheme. (I would suggest even at double-digits, many would blanch at the idea.) > If you don't want/need autoconfiguration, HBA, or CGA, you're free to > deploy subnets smaller than /64. However, doing so comes with risks, > as you may decide in the future that you really do need extra host > bits. If those risks (or your renumbering costs) are negligible, > that's fine. However, I think it's a mistake to encourage people to > simply bit-map their IPv4 addressing architecture into IPv6 without > considering whether such an addressing plan is ideal given the new > capabilities of IPv6. > If you read my original post, I did in fact discuss techniques for extra host bits - add those in the middle, by padding. Pad every host with M bits of zeros (or any value you care to use). Map every prefix to (Y::) | ::(Yn< In summary, I think you have correctly identified bit-mapping from > IPv4 as one possible IPv6 addressing plan. However, I think it would > be a mistake to encourage (or worse, require) networks to do such > mapping, thereby incorporating complexity from their IPv4 addressing > plan into their IPv6 network, without carefully considering whether a > new addressing plan would be more appropriate for the IPv6 portion of > their network. This is neither about encouraging, nor about requiring, a particular plan. It is about *allowing* it, by providing the essential tools to support it. The only tool needed, currently, is the ability to register allocations >/64 - something I perceive the current policy to prohibit. (And now we stray into discussions about policy, rather than about the use cases.) Brian From sleibrand at internap.com Fri Nov 16 16:15:47 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 16 Nov 2007 13:15:47 -0800 Subject: [ppml] Policy regarding subnets smaller than /64 In-Reply-To: <473E0575.1070409@ca.afilias.info> References: <471CC069.6040005@arin.net> <20071022160654.GS23649@shell01.cell.sv2.tellme.com> <471D3021.5080606@ca.afilias.info> <473DF52C.4090409@ca.afilias.info> <473DFD21.40903@internap.com> <473E0575.1070409@ca.afilias.info> Message-ID: <473E0883.4000003@internap.com> Brian Dickson wrote: > > The problem I'm illustrating is the hammer/nail problem. > If it is not *possible* to do any kind of bit-mapped plan, then we are > not supporting those who *might* choose to (or need to) do so. Ok. I'm not opposed to allowing the use of subnets longer/smaller than /64, although I do oppose your earlier policy proposal to encourage it via ARIN guidelines. > This is neither about encouraging, nor about requiring, a particular > plan. It is about *allowing* it, by providing the essential tools to > support it. > The only tool needed, currently, is the ability to register > allocations >/64 - something I perceive the current policy to > prohibit. (And now we stray into discussions about policy, rather than > about the use cases.) Ok, let's discuss the policy then, as this is the public policy mailing list. :-) IMO it's entirely appropriate to use subnets smaller/longer than /64 for certain use cases, like the one you outlined. I do not believe it is appropriate to allocate anything smaller/longer than a /64 to a downstream customer, as doing so limits their ability to grow as needed. In order to support your subnetting scheme, I believe an LIR should reassign an appropriately sized netblock (/64, /56, or /48), and the recipient network should subnet that assignment as needed to support their need for variably-sized subnets. If they don't need an entire /64, then they can reserve the rest of it for future growth. What other "essential tools" do you believe are missing from current policy? -Scott From briand at ca.afilias.info Fri Nov 16 16:26:18 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Fri, 16 Nov 2007 16:26:18 -0500 Subject: [ppml] Policy regarding subnets smaller than /64 In-Reply-To: <473E0883.4000003@internap.com> References: <471CC069.6040005@arin.net> <20071022160654.GS23649@shell01.cell.sv2.tellme.com> <471D3021.5080606@ca.afilias.info> <473DF52C.4090409@ca.afilias.info> <473DFD21.40903@internap.com> <473E0575.1070409@ca.afilias.info> <473E0883.4000003@internap.com> Message-ID: <473E0AFA.10700@ca.afilias.info> Scott Leibrand wrote: > Brian Dickson wrote: >> >> The problem I'm illustrating is the hammer/nail problem. >> If it is not *possible* to do any kind of bit-mapped plan, then we >> are not supporting those who *might* choose to (or need to) do so. > > Ok. I'm not opposed to allowing the use of subnets longer/smaller > than /64, although I do oppose your earlier policy proposal to > encourage it via ARIN guidelines. > >> This is neither about encouraging, nor about requiring, a particular >> plan. It is about *allowing* it, by providing the essential tools to >> support it. >> The only tool needed, currently, is the ability to register >> allocations >/64 - something I perceive the current policy to >> prohibit. (And now we stray into discussions about policy, rather >> than about the use cases.) > > Ok, let's discuss the policy then, as this is the public policy > mailing list. :-) > > IMO it's entirely appropriate to use subnets smaller/longer than /64 > for certain use cases, like the one you outlined. I do not believe it > is appropriate to allocate anything smaller/longer than a /64 to a > downstream customer, as doing so limits their ability to grow as > needed. In order to support your subnetting scheme, I believe an LIR > should reassign an appropriately sized netblock (/64, /56, or /48), > and the recipient network should subnet that assignment as needed to > support their need for variably-sized subnets. If they don't need an > entire /64, then they can reserve the rest of it for future growth. > As long as the ability to do assignments within the allocated block below the /64 exist, I don't have a big problem with making a /64 the smallest aggregate available for assignment. (I do think it would be reasonable to assign longer prefixes, but I acknowledge that those of us who feel that way are currently in the minority, or are primarily lurkers on the ppml.) > What other "essential tools" do you believe are missing from current > policy? > > -Scott None that I am aware of. Can anyone else think of requirements that would affect ARIN policy? Or requirements of any kind? (The development of dual-stack address management tools is left as an exercise for the LIRs and/or their customers. :-)) Brian From alh-ietf at tndh.net Fri Nov 16 16:26:34 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Fri, 16 Nov 2007 13:26:34 -0800 Subject: [ppml] IPv6 addressing, allocation, and subnets In-Reply-To: <473E0575.1070409@ca.afilias.info> References: <471CC069.6040005@arin.net> <20071022160654.GS23649@shell01.cell.sv2.tellme.com> <471D3021.5080606@ca.afilias.info> <473DF52C.4090409@ca.afilias.info> <473DFD21.40903@internap.com> <473E0575.1070409@ca.afilias.info> Message-ID: <08b001c82897$5d1180a0$173481e0$@net> Brian, Clearly you have yourself wedged into the mindset where you don't want to deploy /64 subnets. That is fine, and no one is requiring you to. It is also clear that smart people can come up with cases where the existing IPv6 design is not optimal. The error of their ways though is when they try to turn these corner cases into something bigger than they are. http://www.isoc-au.org.au/06ipv6summit/talks/Ron_Broersma.pdf shows on slide 22 that trivial mappings between IPv4 & IPv6 are possible, and the fact that this has been deployed for years in a non-trivial environment shows that it does scale, even with /64 subnets. DREN does not do the trivial 1:1 mapping of host id between versions, but that would be possible for organizations that find any differences in numbers to be a challenge. You are arguing to redesign the protocol in the wrong forum, and the wrong decade. The time to have made your points was 1995, and even then similar proposals were considered and rejected. It is time to let this bad idea go... Tony > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Brian Dickson > Sent: Friday, November 16, 2007 1:03 PM > To: Scott Leibrand > Cc: ppml at arin.net > Subject: Re: [ppml] IPv6 addressing, allocation, and subnets > > Scott Leibrand wrote: > > Brian, > > > > Do I understand your argument correctly that you perceive the primary > > driver for IPv6 addressing plans to be compatibility with (and > > similarity to) the existing IPv4 plans? If so, then your argument > > that we need to do things similarly to how we do them in IPv4 > applies, > > because your goal is to have everything as similar as possible to the > > IPv4 setup. > > > No, it's actually the converse of the above. > The problem I'm illustrating is the hammer/nail problem. > If it is not *possible* to do any kind of bit-mapped plan, then we are > not supporting those who *might* choose to (or need to) do so. > *Allowing* someone to do something, or providing them the means, is > very > different from encouraging it. > > On the other hand, if we make it impossible, we are taking away the > option from anyone who may otherwise benefit from it. We take away all > tools but the hammer. > > And, I believe that those who have the greatest likelihood of having > non-trivial network addressing under IPv4, and a need to maintain > dual-stack for such, are those who we *most* want to encourage adoption > of IPv6 - the content folks. > > Making it as easy as possible to migrate to dual-stack as early as > possible, should be something we keep in mind in considering policies > for IPv6 allocation. > Even if it isn't ARIN policy (yet) to officially encourage IPv6 > adoption, it *is* policy among other similar groups, whose constituency > has heavy overlap with ARIN. > > An alternative, however, would be to set your IPv6 addressing plans > up > > to be independent of your IPv4 addressing plan (which, as you > > outlined, often comes with a lot of cruft due to networks and subnets > > being too small to accommodate growth). In such a scenario, you > could > > choose to have all subnets be /64 (to accommodate currently-deployed > > autoconfiguration methods as well as addressing methods like HBA and > > CGA). There is no reason for an IPv6 subnet to be larger than /64: > > just because you assign a /64 for a LAN with an IPv4 /29 doesn't mean > > you need a /63 for a LAN that got a /28. > > > Again, let me emphasize, this has to do with ARIN policy, not my own > plans. > > Let's presume that the mapping scheme for one recipient involves a > large > number of subnets, more than what would reasonably be expected to have > a > hand-crafted subnet plan. > I'm not sure where you would draw the line, but imagine a case of > several dozen, say about 80 subnets, of varying sizes, scattered over > several IPv4 CIDR blocks. > > The idea is ongoing management of combined IPv4 and IPv6 dual-stack > hosts. This would presumably involve adding, removing, and changing > addresses for hosts. > Having a bit-mapped structure for the management of the combined IPv4 > and IPv6 assignments, is considerably easy to manage than that of > per-prefix mappings. > > Per-prefix mapping scales badly, as it requires maintaining the mapping > in both directions, for every prefix independently. > As soon as you get beyond double-digits of prefixes, it becomes > unreasonable to expect anyone to embrace such a scheme. > (I would suggest even at double-digits, many would blanch at the idea.) > > If you don't want/need autoconfiguration, HBA, or CGA, you're free to > > deploy subnets smaller than /64. However, doing so comes with risks, > > as you may decide in the future that you really do need extra host > > bits. If those risks (or your renumbering costs) are negligible, > > that's fine. However, I think it's a mistake to encourage people to > > simply bit-map their IPv4 addressing architecture into IPv6 without > > considering whether such an addressing plan is ideal given the new > > capabilities of IPv6. > > > If you read my original post, I did in fact discuss techniques for > extra > host bits - add those in the middle, by padding. Pad every host with M > bits of zeros (or any value you care to use). > Map every prefix to (Y::) | ::(Yn< bits before mapping). > > In summary, I think you have correctly identified bit-mapping from > > IPv4 as one possible IPv6 addressing plan. However, I think it would > > be a mistake to encourage (or worse, require) networks to do such > > mapping, thereby incorporating complexity from their IPv4 addressing > > plan into their IPv6 network, without carefully considering whether a > > new addressing plan would be more appropriate for the IPv6 portion of > > their network. > This is neither about encouraging, nor about requiring, a particular > plan. It is about *allowing* it, by providing the essential tools to > support it. > The only tool needed, currently, is the ability to register allocations > >/64 - something I perceive the current policy to prohibit. (And now > we > stray into discussions about policy, rather than about the use cases.) > > Brian > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN > Member Services > Help Desk at info at arin.net if you experience any issues. From sleibrand at internap.com Fri Nov 16 16:32:32 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 16 Nov 2007 13:32:32 -0800 Subject: [ppml] Policy regarding subnets smaller than /64 In-Reply-To: <473E0AFA.10700@ca.afilias.info> References: <471CC069.6040005@arin.net> <20071022160654.GS23649@shell01.cell.sv2.tellme.com> <471D3021.5080606@ca.afilias.info> <473DF52C.4090409@ca.afilias.info> <473DFD21.40903@internap.com> <473E0575.1070409@ca.afilias.info> <473E0883.4000003@internap.com> <473E0AFA.10700@ca.afilias.info> Message-ID: <473E0C70.4030704@internap.com> Brian Dickson wrote: > Scott Leibrand wrote: >> >> Ok, let's discuss the policy then, as this is the public policy >> mailing list. :-) >> >> IMO it's entirely appropriate to use subnets smaller/longer than /64 >> for certain use cases, like the one you outlined. I do not believe >> it is appropriate to allocate anything smaller/longer than a /64 to a >> downstream customer, as doing so limits their ability to grow as >> needed. In order to support your subnetting scheme, I believe an LIR >> should reassign an appropriately sized netblock (/64, /56, or /48), >> and the recipient network should subnet that assignment as needed to >> support their need for variably-sized subnets. If they don't need an >> entire /64, then they can reserve the rest of it for future growth. >> > As long as the ability to do assignments within the allocated block > below the /64 exist, I don't have a big problem with making a /64 the > smallest aggregate available for assignment. I'm not sure I understand your first use of "assignment" there. Currently, there's nothing to stop you from *using* a longer prefix as a subnet. Are you advocating for something more than that, like the ability to assign a network longer/smaller than /64 between organizations? > (I do think it would be reasonable to assign longer prefixes, but I > acknowledge that those of us who feel that way are currently in the > minority, or are primarily lurkers on the ppml.) >> What other "essential tools" do you believe are missing from current >> policy? >> > None that I am aware of. > > Can anyone else think of requirements that would affect ARIN policy? > Or requirements of any kind? I think this is one of those things where it's best for ARIN to provide each end network discretion as to how to use their addresses internally, so I'm pretty happy with the current policies. -Scott From briand at ca.afilias.info Fri Nov 16 16:53:45 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Fri, 16 Nov 2007 16:53:45 -0500 Subject: [ppml] IPv6 addressing, allocation, and subnets In-Reply-To: <08b001c82897$5d1180a0$173481e0$@net> References: <471CC069.6040005@arin.net> <20071022160654.GS23649@shell01.cell.sv2.tellme.com> <471D3021.5080606@ca.afilias.info> <473DF52C.4090409@ca.afilias.info> <473DFD21.40903@internap.com> <473E0575.1070409@ca.afilias.info> <08b001c82897$5d1180a0$173481e0$@net> Message-ID: <473E1169.9070200@ca.afilias.info> Tony Hain wrote: > Brian, > > Clearly you have yourself wedged into the mindset where you don't want to > deploy /64 subnets. That is fine, and no one is requiring you to. It is also > clear that smart people can come up with cases where the existing IPv6 > design is not optimal. The error of their ways though is when they try to > turn these corner cases into something bigger than they are. > > I don't believe you remember the discussions we had at NANOG where I indicated that none of what is being discussed, is related to plans involving me or my employer. (We do in fact deploy only /64 subnets, except for external point-to-point links to ISPs.) I am addressing the issues that affect those who have not yet deployed IPv6, and for whom the deployment is likely to be fraught with difficulty and peril, specifically *because* of those who view IPv6 as a universe where all prefixes are /64. It is important to adopt policies which support the needs of all ARIN members, *and* their customers, not just the majority of ARIN *participants*. The fact that someone has not yet deployed IPv6, does not mean that that party's needs are irrelevant. We should plan to accommodate the needs of those who show up late to the ball, rather than punish them for not being part of the "in" crowd. The whole point of the Internet is connectivity, and facilitating other parties connection to the Internet is part and parcel of, and the entire value of, being on the Internet. > http://www.isoc-au.org.au/06ipv6summit/talks/Ron_Broersma.pdf shows on > slide 22 that trivial mappings between IPv4 & IPv6 are possible, and the > Uh, no it does not. I would appreciate it if you would at least read what I wrote, or if presenting counter-arguments, read things to which you point people. For the benefit of those too busy to follow your URL, here's the text from the page: Example Re-addressing scheme Re-address the network for consistency between protocols ? IPv4 ? move all subnets to /24 or larger ? Align VLAN number with 3rd octet of IPv4 address ? Align IPv6 ?subnet number? with the above [pictures omitted for brevity] Benefits ? Reduction in complexity ? Easier for operations staff, once re-addressing is complete Note ? Assumes you have enough IPv4 address space to change it as well. So, this is *not* a mapping scheme - it's a combined addressing scheme, which requires that all IPv4 subnets be *renumbered* into /24, and that only /24:/64 mappings are supported. And, it requires that you have *space* to do this renumbering in IPv4. None of this meets the implied situation that mappings *are* trivial. Rather, it shows that *only* trivial mappings scale. > You are arguing to redesign the protocol in the wrong forum, and the wrong > decade. The time to have made your points was 1995, and even then similar > proposals were considered and rejected. It is time to let this bad idea > go... > CIDR and VLSM are hardly bad ideas, and support for analogous schemes between IPv4 and IPv6 is very timely. The fact that widescale deployment of CIDR happened concurrently or after IPv6 design time (1995) is the counter-argument. It is not surprising that, absent experience with IPv4 CIDR, that IPv6's authors didn't see its value. IPv6 is not what the authors of the RFCs say it is outside of the RFCs themselves. It is only what the RFCs themselves dictate - and from the main IPv6 RFC, it has *no* internal structure. Some uses of IPv6, and some protocols, assign meaning to certain bits. And use of IPv6 which is consistent with the RFCs, is neither redesign, nor incorrect use of, the protocol. It is time to get with the CIDR program, not to advocate the antiquated class-ful paradigm. Respectfully, Brian Dickson From briand at ca.afilias.info Fri Nov 16 17:00:09 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Fri, 16 Nov 2007 17:00:09 -0500 Subject: [ppml] Policy regarding subnets smaller than /64 In-Reply-To: <473E0C70.4030704@internap.com> References: <471CC069.6040005@arin.net> <20071022160654.GS23649@shell01.cell.sv2.tellme.com> <471D3021.5080606@ca.afilias.info> <473DF52C.4090409@ca.afilias.info> <473DFD21.40903@internap.com> <473E0575.1070409@ca.afilias.info> <473E0883.4000003@internap.com> <473E0AFA.10700@ca.afilias.info> <473E0C70.4030704@internap.com> Message-ID: <473E12E9.4090908@ca.afilias.info> Scott Leibrand wrote: > I'm not sure I understand your first use of "assignment" there. > Currently, there's nothing to stop you from *using* a longer prefix as > a subnet. Are you advocating for something more than that, like the > ability to assign a network longer/smaller than /64 between > organizations? > Yes. The analogous kind of thing would be the ability to assign down to a /29 in IPv4. Registration of what is used, can be important for all of the things that go along with registration, e.g. different abuse contacts, technical contacts, etc. Ditto delegation of ip6.arpa reverse mappings on the nibble boundary, below the /64 level (not sure if this is an issue, but just want to list it as something necessary for such assignments.) Brian From sleibrand at internap.com Fri Nov 16 17:39:04 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 16 Nov 2007 14:39:04 -0800 Subject: [ppml] Policy regarding subnets smaller than /64 In-Reply-To: <473E12E9.4090908@ca.afilias.info> References: <471CC069.6040005@arin.net> <20071022160654.GS23649@shell01.cell.sv2.tellme.com> <471D3021.5080606@ca.afilias.info> <473DF52C.4090409@ca.afilias.info> <473DFD21.40903@internap.com> <473E0575.1070409@ca.afilias.info> <473E0883.4000003@internap.com> <473E0AFA.10700@ca.afilias.info> <473E0C70.4030704@internap.com> <473E12E9.4090908@ca.afilias.info> Message-ID: <473E1C08.6040202@internap.com> Brian Dickson wrote: > Scott Leibrand wrote: >> I'm not sure I understand your first use of "assignment" there. >> Currently, there's nothing to stop you from *using* a longer prefix >> as a subnet. Are you advocating for something more than that, like >> the ability to assign a network longer/smaller than /64 between >> organizations? >> > Yes. The analogous kind of thing would be the ability to assign down > to a /29 in IPv4. > Registration of what is used, can be important for all of the things > that go along with registration, e.g. different abuse contacts, > technical contacts, etc. Ok, so you basically want to be able to SWIP (reassign to customers) prefixes longer than /64? I don't think that is necessary, and feel that it would have enough negative side effects to be something we don't want to encourage. Consider a monopolistic telco, for example, who likes to artificially differentiate and charge more for "value-added" services. If they are allowed to do so, they may wish to assign /124s to all their customers, on the assumption that if you have more than 16 hosts, you obviously need a more expensive tier of service. This would stifle innovation at the edge, precluding the use of HBA, CGA, or autoconfiguration. I think the current guidelines are much more appropriate, encouraging /56's for residential users, /64 for networks with known single-subnet needs, and allowing everyone who wants a /48 to get one. In my opinion, if you have different organizations, different contacts, etc. for different networks, there's no real reason not to give a different /64, /56, or /48 to each org as needed. > Ditto delegation of ip6.arpa reverse mappings on the nibble boundary, > below the /64 level (not sure if this is an issue, but just want to > list it as something necessary for such assignments.) I'm pretty sure this can be done today. -Scott From stephen at sprunk.org Fri Nov 16 17:27:52 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 16 Nov 2007 16:27:52 -0600 Subject: [ppml] Policy Proposal Name: IPv6 Assignment Size Reduction References: <1AD33A3140054D45A0EF89AB74D5B1E1C1FE66@SFED01.fed.corp.cmdinfo.com> <624FA7B5-D1B9-4C6D-9EEA-F3F99077FCBB@kanren.net> <473D9A44.2040201@eagle.ca> Message-ID: <057501c828a2$2fce2070$6401a8c0@atlanta.polycom.com> Thus spake Steve Bertrand > For the record then, and given what you said about the NAY/YAY > consideration at the meetings, myself, and the company that I work > for strongly oppose this policy. Not to pick on Steve in particular, but this is the second time this week I've seen corporate endorsement of a policy position. My understanding is that ARIN, like the IETF, is a community of _people_ with opinions and that corporate affiliations are for identification only. Can someone from the BoT or AC clarify whether I've got that right? S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From stephen at sprunk.org Fri Nov 16 17:17:19 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 16 Nov 2007 16:17:19 -0600 Subject: [ppml] IPv6 addressing, allocation, and subnets References: <471CC069.6040005@arin.net> <20071022160654.GS23649@shell01.cell.sv2.tellme.com> <471D3021.5080606@ca.afilias.info><473DF52C.4090409@ca.afilias.info> <473DFD21.40903@internap.com> <473E0575.1070409@ca.afilias.info> Message-ID: <057201c828a2$2ed170f0$6401a8c0@atlanta.polycom.com> Thus spake Brian Dickson > No, it's actually the converse of the above. > The problem I'm illustrating is the hammer/nail problem. > If it is not *possible* to do any kind of bit-mapped plan, then we are > not supporting those who *might* choose to (or need to) do so. > *Allowing* someone to do something, or providing them the means, > is very different from encouraging it. > > On the other hand, if we make it impossible, we are taking away > the option from anyone who may otherwise benefit from it. We take > away all tools but the hammer. I see nothing in ARIN policy that prevents the use of subnets longer than /64 within an end site's assignment. I can't recall having seen any proposals to change that, either. Finally, I have no objection to people doing so if that's what floats their boat. However, I do have a serious problem with ARIN potentially allowing LIRs to assign prefixes longer than /64 to end sites. If an end site wants to use /65 or longer subnets, that's fine with me, but they can take them out of the /64, /56, or /48 that they got from their LIR. ARIN policy should be about the minimum efficiency bar, and everyone should be measured according to that standard -- and that standard is a /64 per subnet. If you want to be more efficient, in your view, than that, we do not need to change the policy to "allow" it. > Let's presume that the mapping scheme for one recipient involves > a large umber of subnets, more than what would reasonably be > expected to have a hand-crafted subnet plan. > I'm not sure where you would draw the line, but imagine a case of > several dozen, say about 80 subnets, of varying sizes, scattered > over several IPv4 CIDR blocks. > > The idea is ongoing management of combined IPv4 and IPv6 dual- > stack hosts. This would presumably involve adding, removing, and > changing addresses for hosts. > Having a bit-mapped structure for the management of the combined > IPv4 and IPv6 assignments, is considerably easy to manage than > that of per-prefix mappings. I wasn't aware people were trying to manage their addresses that way. If you really want to maintain mapped addresses, rather than taking advantage of a clean start with IPv6, how about taking a /96 from your /64 (or whatever) and postpending the entire IPv4 address? It doesn't get any simpler than that. > This is neither about encouraging, nor about requiring, a particular > plan. It is about *allowing* it, by providing the essential tools to > support it. > The only tool needed, currently, is the ability to register allocations > >/64 - something I perceive the current policy to prohibit. (And now > we stray into discussions about policy, rather than about the use > cases.) I don't see why you need the ability to assign a prefix longer than /64 _in ARIN's database_. If the site doesn't want to use all their bits, give them a /64 anyways and who cares what they do inside of it? Why make it ARIN's business to know? There is absolutely _no_ shortage of /64s. Simply put, I don't care what you do to the right of the /64 boundary, and neither should ARIN. What I object to is making staff pay attention to anything past that boundary, and that's what your proposal would do. And, as stated previously, the "guidelines" are bad policy and need to be removed from the NRPM in the first place, not enlarged. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From sleibrand at internap.com Fri Nov 16 17:56:42 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 16 Nov 2007 14:56:42 -0800 Subject: [ppml] Individuals vs. organizations in the public policy process In-Reply-To: <057501c828a2$2fce2070$6401a8c0@atlanta.polycom.com> References: <1AD33A3140054D45A0EF89AB74D5B1E1C1FE66@SFED01.fed.corp.cmdinfo.com> <624FA7B5-D1B9-4C6D-9EEA-F3F99077FCBB@kanren.net> <473D9A44.2040201@eagle.ca> <057501c828a2$2fce2070$6401a8c0@atlanta.polycom.com> Message-ID: <473E202A.4040403@internap.com> Stephen Sprunk wrote: > Thus spake Steve Bertrand > >> For the record then, and given what you said about the NAY/YAY >> consideration at the meetings, myself, and the company that I work >> for strongly oppose this policy. >> > > Not to pick on Steve in particular, but this is the second time this week > I've seen corporate endorsement of a policy position. My understanding is > that ARIN, like the IETF, is a community of _people_ with opinions and that > corporate affiliations are for identification only. > > Can someone from the BoT or AC clarify whether I've got that right? Speaking as an individual (I'm not on the AC yet anyway), I think that's correct, as far as the public policy process goes. As a matter of free speech, I think everyone is free to speak for their company if they wish, but that has no more weight than speaking for themselves. Where companies (ARIN members) matter is when it comes to voting: each ARIN member (ORG ID) get just one designated member representative, and hence one vote for AC and BoT seats. However, it's important to distinguish between such elections (and other actions taken during the ARIN member meeting), and the public policy process (and public policy meeting), which operates by consensus of individual participants. -Scott From briand at ca.afilias.info Fri Nov 16 18:06:26 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Fri, 16 Nov 2007 18:06:26 -0500 Subject: [ppml] Policy regarding subnets smaller than /64 In-Reply-To: <473E1C08.6040202@internap.com> References: <471CC069.6040005@arin.net> <20071022160654.GS23649@shell01.cell.sv2.tellme.com> <471D3021.5080606@ca.afilias.info> <473DF52C.4090409@ca.afilias.info> <473DFD21.40903@internap.com> <473E0575.1070409@ca.afilias.info> <473E0883.4000003@internap.com> <473E0AFA.10700@ca.afilias.info> <473E0C70.4030704@internap.com> <473E12E9.4090908@ca.afilias.info> <473E1C08.6040202@internap.com> Message-ID: <473E2272.4060800@ca.afilias.info> Scott Leibrand wrote: > Ok, so you basically want to be able to SWIP (reassign to customers) > prefixes longer than /64? > > I don't think that is necessary, and feel that it would have enough > negative side effects to be something we don't want to encourage. > Consider a monopolistic telco, for example, who likes to artificially > differentiate and charge more for "value-added" services. If they are > allowed to do so, they may wish to assign /124s to all their > customers, on the assumption that if you have more than 16 hosts, you > obviously need a more expensive tier of service. This would stifle > innovation at the edge, precluding the use of HBA, CGA, or > autoconfiguration. I don't think the inability to SWIP addresses will in any way affect the behavior of any monopolistic telco. And as such, I think the telco vs SWIP issue is a red herring. I agree that entities allocating prefixes to customers without consideration of the needs of customers, will harm innovation (and customers). I do not agree that it is the business of ARIN to attempt to curb monopolistic abuse - there are much better places, and much better equipped organizations, for that kind of activity (e.g. FTC, FCC, DOJ, etc. in the US, and similar organizations in the other ARIN countries.) And, considering that I already gave an example of how SWIP of a prefix /N, regardless of the value of N, is an activity that could be considered not only valid, but necessary, I have to emphasize that I see this as important for support of non-trivial deployments of IPv6. > In my opinion, if you have different organizations, different > contacts, etc. for different networks, there's no real reason not to > give a different /64, /56, or /48 to each org as needed. Forcing specific sizes of end-use *within* a site, flies in the face of allowing sites to use IPv6 as they see fit. Brian From Fred.Wettling at Bechtel.com Sat Nov 17 12:27:45 2007 From: Fred.Wettling at Bechtel.com (Wettling, Fred) Date: Sat, 17 Nov 2007 12:27:45 -0500 Subject: [ppml] Individuals vs. organizations in the public policyprocess In-Reply-To: <473E202A.4040403@internap.com> References: <1AD33A3140054D45A0EF89AB74D5B1E1C1FE66@SFED01.fed.corp.cmdinfo.com> <624FA7B5-D1B9-4C6D-9EEA-F3F99077FCBB@kanren.net> <473D9A44.2040201@eagle.ca><057501c828a2$2fce2070$6401a8c0@atlanta.polycom.com> <473E202A.4040403@internap.com> Message-ID: <3400197AD5EC0540BC920AB9A1FD243311F349CF@fres0094.amers.ibechtel.com> The ARIN policy discussions are not limited to individuals. "Policy development is an open and transparent process. Anyone may participate in the process -- a prior relationship as an ARIN member or customer is not a requirement..." Link: http://www.arin.net/policy/index.html Organizations pay the ARIN fees, receive the vast majority of the addresses allocated by ARIN, and are subject to the ARIN policies. As Scott mentioned, the ARIN member organizations each get one vote. PPML participants should consider that individuals speaking on behalf of their organization may have gone through an internal vetting process before posting a note. This will often include internal discussions/debates/education and an enterprise impact analysis of the policy proposal. >From my perspective the organizational affiliation is useful when a PPML message is posted as a position of the organization. It helps provide additional context for the comment. Regards - Fred -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Scott Leibrand Sent: Friday, November 16, 2007 5:57 PM To: Stephen Sprunk Cc: ARIN PPML Subject: Re: [ppml] Individuals vs. organizations in the public policyprocess Stephen Sprunk wrote: > Thus spake Steve Bertrand > > For the record then, and given what you said about the NAY/YAY consideration at the meetings, myself, and the company that I work for strongly oppose this policy. > > Not to pick on Steve in particular, but this is the second time this week I've seen corporate endorsement of a policy position. My understanding is that ARIN, like the IETF, is a community of _people_ with opinions and that corporate affiliations are for identification only. > > Can someone from the BoT or AC clarify whether I've got that right? Speaking as an individual (I'm not on the AC yet anyway), I think that's correct, as far as the public policy process goes. As a matter of free speech, I think everyone is free to speak for their company if they wish, but that has no more weight than speaking for themselves. Where companies (ARIN members) matter is when it comes to voting: each ARIN member (ORG ID) get just one designated member representative, and hence one vote for AC and BoT seats. However, it's important to distinguish between such elections (and other actions taken during the ARIN member meeting), and the public policy process (and public policy meeting), which operates by consensus of individual participants. -Scott From michael.dillon at bt.com Sun Nov 18 16:59:22 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 18 Nov 2007 21:59:22 -0000 Subject: [ppml] IPv6 addressing, allocation, and subnets In-Reply-To: <473E1169.9070200@ca.afilias.info> References: <471CC069.6040005@arin.net> <20071022160654.GS23649@shell01.cell.sv2.tellme.com> <471D3021.5080606@ca.afilias.info> <473DF52C.4090409@ca.afilias.info><473DFD21.40903@internap.com> <473E0575.1070409@ca.afilias.info><08b001c82897$5d1180a0$173481e0$@net> <473E1169.9070200@ca.afilias.info> Message-ID: > It is time to get with the CIDR program, not to advocate the > antiquated class-ful paradigm. CIDR is IPv4. We are discussing IPv6 which is different. If ARIN does not require LIRs to count hosts, and allows LIRs to justify a /48 for every IPv6 site, then LIRs have no restrictions which would prevent them from implementing a miserly addressing plan such as you promote. >From a policy point of view, the existing policy already allows LIRs to do what you suggest. There is no need for policy change. >From an education point of view, ARIN should be following the IETF's lead since they are the one's that created IPv6. Note that ARIN does operate an IPv6 wiki at http://www.getipv6.info and if you want to explain your addressing plan to everyone, you are free to create a page there. Just make it clear that this is your recommendation, not that of the IETF. It would be nice if more people would post pages outlining their IPv6 addressing plans and how they arrived at their decisions. --Michael Dillon From briand at ca.afilias.info Sun Nov 18 19:58:17 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Sun, 18 Nov 2007 19:58:17 -0500 Subject: [ppml] IPv6 addressing, allocation, and subnets In-Reply-To: References: <471CC069.6040005@arin.net> <20071022160654.GS23649@shell01.cell.sv2.tellme.com> <471D3021.5080606@ca.afilias.info> <473DF52C.4090409@ca.afilias.info><473DFD21.40903@internap.com> <473E0575.1070409@ca.afilias.info><08b001c82897$5d1180a0$173481e0$@net> <473E1169.9070200@ca.afilias.info> Message-ID: <4740DFA9.2050107@ca.afilias.info> michael.dillon at bt.com wrote: >> It is time to get with the CIDR program, not to advocate the >> antiquated class-ful paradigm. >> > > CIDR is IPv4. We are discussing IPv6 which is different. No, I'm afraid you're wrong on this point. CIDR is classless inter-domain routing. It is neither IPv4 nor IPv6. The basic concept underpinning CIDR is, longest match wins when comparing two prefixes. Without it, CIDR would not have worked, or not have scaled. With it, covering aggregates and variable-length subnet masks (VLSM) are possible, and provide the basic tools for scaling both internal and external routing domains. And, as it happens, IPv6 *is* CIDR-oriented. The primary RFC for IPv6 specifically excludes any requirement for specific structure within IPv6 addresses, when viewed by routers. (Currently this is RFC 4291.) It does anticipate that routers will have knowledge of hierarchical routing schemes (examples would include OSPF or ISIS, with stub or not-so-stubby areas). And, while IPv6 supports the notion of fixed-size interface identifier (II) (currently fixed at a size of 64 bits for global unicast prefixes), the II is used for link-local addressing and node address autoconfiguration only. Static host address configuration, and DHCPv6, support prefixes of arbitrary length, and are not restricted to /64 prefixes. So, your contention that IPv6 is "different", and not CIDR, is patently false. (Link-local addressing is a clever alternative to ARP, and one of the better elements of IPv6. However, IPv6 does not require that all IPv6 addresses on an interface use the EUI-64 value as the host part of the address; it does specify that when doing autoconfiguration, the interface identifier is used for the host portion.) Brian From michael.dillon at bt.com Mon Nov 19 04:43:55 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 19 Nov 2007 09:43:55 -0000 Subject: [ppml] IPv6 addressing, allocation, and subnets In-Reply-To: <4740DFA9.2050107@ca.afilias.info> References: <471CC069.6040005@arin.net> <20071022160654.GS23649@shell01.cell.sv2.tellme.com> <471D3021.5080606@ca.afilias.info> <473DF52C.4090409@ca.afilias.info><473DFD21.40903@internap.com> <473E0575.1070409@ca.afilias.info><08b001c82897$5d1180a0$173481e0$@net> <473E1169.9070200@ca.afilias.info> <4740DFA9.2050107@ca.afilias.info> Message-ID: > michael.dillon at bt.com wrote: > >> It is time to get with the CIDR program, not to advocate the > >> antiquated class-ful paradigm. > >> > > > > CIDR is IPv4. We are discussing IPv6 which is different. > No, I'm afraid you're wrong on this point. > > CIDR is classless inter-domain routing. It is neither IPv4 nor IPv6. You were talking about subnet planning, not about routing. In the context of addressing plans and planning network architecture, CIDR is only important with IPv4. CIDR is what allows you to design subnets with the minimum number of addresses and aggregate the mess behind a shorter prefix. In the IPv6 world, CIDR is not terribly relevant even if, technically, it still exists. The fact is that you *CAN* design your IPv6 subnetting plan along classful lines if you want to. > With it, covering aggregates and variable-length subnet masks > (VLSM) are possible, and provide the basic tools for scaling > both internal and external routing domains. Notice how infrequently people mention VLSM these days because it is just considered to be a part of CIDR. The meaning of terminology changes depending on context and depending on the times. To most networking people these days, CIDR is an IPv4 thing that lets you make your subnets as small as possible to conserve addresses. The term is tainted with the concept of "address conservation" which is not necessary or desirable when planning IPv6 networks. > And, as it happens, IPv6 *is* CIDR-oriented. Technically, IPv6 doesn't need CIDR to be tacked onto the design because it was there in the first place. IPv6 always has routed based on the longest prefix. > So, your contention that IPv6 is "different", and not CIDR, > is patently false. You are mincing words. 90% of the people on this list have never read any of these RFCs and don't care to debate the fine points of technical terminology. This is a policy forum. We don't really care whether or not IPv6 can be stretched this way or that. We have to respect the IETF's core design and make our policies around that. --Michael Dillon From kurt at amnh.org Mon Nov 19 08:46:41 2007 From: kurt at amnh.org (Kurt Kruegel) Date: Mon, 19 Nov 2007 08:46:41 -0500 Subject: [ppml] PPML Digest, Vol 29, Issue 15 Message-ID: <20071119134639.1D46D5B76F@lepore.amnh.org> -----Original Message----- From: ppml-request at arin.net To: ppml at arin.net Sent: 11/18/07 12:00 PM Subject: PPML Digest, Vol 29, Issue 15 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: Individuals vs. organizations in the public policyprocess (Wettling, Fred) ---------------------------------------------------------------------- Message: 1 Date: Sat, 17 Nov 2007 12:27:45 -0500 From: "Wettling, Fred" Subject: Re: [ppml] Individuals vs. organizations in the public policyprocess To: "ARIN PPML" Message-ID: <3400197AD5EC0540BC920AB9A1FD243311F349CF at fres0094.amers.ibechtel.com> Content-Type: text/plain; charset="us-ascii" The ARIN policy discussions are not limited to individuals. "Policy development is an open and transparent process. Anyone may participate in the process -- a prior relationship as an ARIN member or customer is not a requirement..." Link: http://www.arin.net/policy/index.html Organizations pay the ARIN fees, receive the vast majority of the addresses allocated by ARIN, and are subject to the ARIN policies. As Scott mentioned, the ARIN member organizations each get one vote. PPML participants should consider that individuals speaking on behalf of their organization may have gone through an internal vetting process before posting a note. This will often include internal discussions/debates/education and an enterprise impact analysis of the policy proposal. >From my perspective the organizational affiliation is useful when a PPML message is posted as a position of the organization. It helps provide additional context for the comment. Regards - Fred -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at ari From info at arin.net Mon Nov 19 11:56:33 2007 From: info at arin.net (Member Services) Date: Mon, 19 Nov 2007 11:56:33 -0500 Subject: [ppml] ARIN Mailing List Acceptable Use Policies (AUPs) Message-ID: <4741C041.6060500@arin.net> As a reminder to the community, ARIN enforces the Acceptable Use Policies (AUPs) to safeguard and facilitate open, constructive dialogue on its mailing lists. There are two Mailing List AUPs found in Section 9 of the Number Resource Policy Manual. This AUP is available on the ARIN website at: http://www.arin.net/policy/nrpm.html#nine1 Regards, Member Services American Registry for Internet Numbers (ARIN) From sob at harvard.edu Mon Nov 19 15:30:27 2007 From: sob at harvard.edu (Scott O. Bradner) Date: Mon, 19 Nov 2007 15:30:27 -0500 (EST) Subject: [ppml] people or employers (was Re: Policy Proposal Name: IPv6 Assignment Size Reduction) Message-ID: <20071119203027.5024A647B14@newdev.eecs.harvard.edu> > Not to pick on Steve in particular, but this is the second time this week > I've seen corporate endorsement of a policy position. My understanding is > that ARIN, like the IETF, is a community of _people_ with opinions and that > corporate affiliations are for identification only. > > Can someone from the BoT or AC clarify whether I've got that right? you got it right the only time that affiliations are important in ARIN functions (other than paying the bills :-) ) is when members are nominating or voting in elections - the rest of the time we hope that the people who participate can think for themselves Scott From sob at harvard.edu Mon Nov 19 15:36:09 2007 From: sob at harvard.edu (Scott O. Bradner) Date: Mon, 19 Nov 2007 15:36:09 -0500 (EST) Subject: [ppml] people or employers (was Re: Policy Proposal Name: IPv6 ... Message-ID: <20071119203609.BD4A5647B7B@newdev.eecs.harvard.edu> fred sed: > PPML participants should consider that individuals speaking on behalf of > their organization may have gone through an internal vetting process > before posting a note. This will often include internal > discussions/debates/education and an enterprise impact analysis of the > policy proposal. I hope that people participating in the ppml will generally feel free to express their own opinions and that it is a rare case where everthing must be vetted internally before posting is permitted - I think we will lose much of the technical discussion if that becomes the norm in any case - it is speifically not assumed by the BoT that people are speaking for anyone but themselves and are speaking based on their own thought processes Scott From info at arin.net Tue Nov 20 13:47:05 2007 From: info at arin.net (Member Services) Date: Tue, 20 Nov 2007 13:47:05 -0500 Subject: [ppml] Policy Proposal: IPv6 Assignment Size Reduction - AC did not accept Message-ID: <47432BA9.9040506@arin.net> On 15 November 2007, the ARIN Advisory Council (AC) concluded its review of the proposed policy 'IPv6 Assignment Size Reduction' and did not accept it as a formal policy proposal. The AC provided the following explanation of their decision: "The reason we do not accept it is because there has not been any support on the Public Policy Mailing List." During the initial review period the AC may decide to: 1) Accept the proposal as a formal policy proposal as written. 2) Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. 3) Not accept the policy proposal. In the event that the AC decides not to accept the proposal, then the author may elect to use the petition process to advance the proposal. For petition details see the section called "Petition Process" in the ARIN Internet Resource Policy Evaluation Process which can be found at: http://www.arin.net/policy/irpep.html The deadline for the author to initiate a petition per the ARIN Internet Resource Policy Evaluation Process is 40 days prior to the meeting; the petition deadline for the ARIN XXI Public Policy Meeting is 23:59 EDT, 27 February 2008. If the author chooses not to petition or the petition is unsuccessful, then the proposed policy is closed. If a petition is successful, then the proposal will be numbered and posted for discussion and presented at ARIN's Public Policy Meeting. Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv6 Assignment Size Reduction Author: Brian Dickson Proposal Version: 1 Submission Date: Oct 18, 2007 Proposal type: modify Policy term: permanent Policy statement: 6.5.4.1. Assignment address space size End-users are assigned an end site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /120 (when only one subnet is anticipated for the end site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified. The following guidelines may be useful (but they are only guidelines): * /120 for a very small customer with one subnet, using static assignments or DHCPv6 * /116 for a small customer with a few subnets, using static assignments or DHCPv6 * /112 for a medium size customer with a significant total number of hosts and/or subnets, using static assignments and/or DHCPv6 * /96 for large customers * /80 for very large customers, or for customers using a proposed modified version of V6-autoconf (which uses EUI-48 instead of EUI-64) * /72 for customers with several subnets using modified V6-autoconf (which uses EUI-48 instead of EUI-64) * /64 when it is known that one and only one subnet is needed, for a customer that absolutely requires either traditional IPv6 autoconfiguration, or IPv6 host Interface Identifier cryptographic generation * /60 for sites where a mix of IPv6-autoconfiguration and other address assignment techiques are required * /56 for very large sites * /52 for very, very large sites * /48 for extremely large sites For end sites to whom reverse DNS will be delegated, the LIR/ISP should consider making an assignment on a nibble (4-bit) boundary to simplify reverse lookup delegation. Rationale: The intent is to provide more current guidance, to both ARIN members, and to ARIN staff, based on available IPv6 technology, and for the encouragement of efficient assignment of IPv6 address space. IPv6 supports numerous methods for address assignments to end nodes. Those include autoconfiguration, static assignment, and DHCPv6. Of those, only autoconfiguration requires use of /64 as the prefix size. Efficient use of IPv6 space should discourage widespread use of /64's, or for use of autoconfiguration as the sole justification for allocations of large address space. In particular, the effective lifetime of PA assignments to ISPs/LIRs, is largely a factor of internal aggregation, and the size of end assignments. Rather than meeting ISP needs by assigning very large IPv6 PA blocks, it would be wiser to encourage assignments that to not significantly use up available PA space for the ISP, even for very large customers. The overall intent is to minimize the need for any PA recipient, to return to ARIN for subsequent assignments, thus reducing the need for additional globally routable prefixes using up slots in routers in the DFZ - something that affects the long-term ability for all ISPs to continue to scale in a cost-effective manner. Timetable for implementation: Immediate From info at arin.net Tue Nov 20 13:51:05 2007 From: info at arin.net (Member Services) Date: Tue, 20 Nov 2007 13:51:05 -0500 Subject: [ppml] Policy Proposal: globally-coordinated-RIR-pie-IPv4 - AC postponed decision Message-ID: <47432C99.90500@arin.net> On 15 November 2007, the ARIN Advisory Council (AC) postponed their decision regarding "globally-coordinated-RIR-pie-IPv4" in order for the shepherds to work with the author. The AC will review this proposal at their next regularly scheduled meeting. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/submission_archive.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: globally-coordinated-RIR-pie-IPv4 Author: Brian Dickson Proposal Version: 1 Submission Date: 26 October 2007 Proposal type: new Policy term: renewable Policy statement: This policy concerns the globally-coordinated allocations of IPv4 address space from IANA to the RIRs. The policy is intended to be compatible with 2007-23 (in its expected final form). The overview of the policy is: At the last reasonable time to do so, divide up the remaining IPv4 space based on currently projected use between that time and the date at which no more IPv4 space is available at any RIR for new allocations. Here is how the policy is to be implemented: 1) RIRs should provide up-to-date assignment projections for their respective regions, and provide up-to-date utilization on their current IANA-assigned block(s) from which assignments are made. 2) RIRs should provide an official projection on IANA Exhaustion Date (IED) to the community through their website, at their Policy Meetings and through any other effective means. 3) When any RIR requests a /8 from IANA, the current assignment projections for that RIR should be combined with the RIR's currently available IANA blocks (i.e. from which RIR assignments are made). This should be compared with the global available IANA unused space (for allocating to RIRs), the current projected usage rate of the RIR, and the current projected IED. If the RIR projection shows that the RIR would not expect to use up two /8 blocks before IED, the "Pie-splitting" event will be triggered. 4) Splitting the Pie - the following method will be used to determine the final IPv4 global IANA allocations to the RIRs: For each RIR, the following calculation will be done: (i) Determine from the current projection, the total allocations the RIR will make from present to IED (ii) Subtract from this, unallocated RIR space already received from ARIN (if any) (iii) Round the result to the nearest /12 (iv) Subtract from this amount, one /8 (to be set aside to satisfy the 2005-23 policy proposal for "End Policy for IANA IPv4 allocations to RIRs") (v) Allocate this amount to the RIR immediately. Every effort should be made to divide these allocations among RIRs in as aggregatable a fashion as possible. 5) The allocations made will result in just 5 * /8 being left in the IANA pool, which will trigger 2007-23. 6) This in turn, will result in the last 5 * /8's being allocate to the RIR's, one for each. Rationale: The objective of this policy is to ensure that the remaining IPv4 pool is distributed so as to provide each RIR with a quantity of IPv4 addresses that will last for an expected duration. The intent is for this duration to be as close to the same for each RIR as possible. By following the rules above, the "pie split" is done: - as late as possible - as fairly as possible - in a consistent manner for all RIRs - early enough that each RIR is guaranteed at least one /8 The final /8 allocations are done *after* this allocation, so that there can be no issue of fairness, with each RIR being guaranteed to get one of the final /8's at the same time. The "pie split" is timed so that no RIR will have so much (relative) IPv4 address space, as to expect to have IPv4 space after any other RIR has exhausted its own IPv4 space. By providing a "pie split" which is based on the same data as the IED projection, the following results occur: - there is no contention over the process by which the division of resources occur - all RIRs have the ability to project, well in advance of the "pie split", exactly when their own IPv4 space will be exhausted. It will happen at the IED date -- no sooner, no later. - No RIR "shopping" is likely to occur. Consequently, no inter-RIR "land grab" is likely to occur, and thus the projections for IED itself are likely to remain consistent, as will the per-RIR projections. - LIRs are likely to view the policy as neutral, and thus fair. - Because it removes the incentive for RIR shopping, the rules preventing RIR shopping will become largely moot (but still recommended). The perception then of anti-shopping provisions might then be that it maintains stability, rather than penalizing any RIR/LIR/region. Additional Observations about Fast vs Slow RIRs Fast-consuming RIRs will contribute more heavily towards the consumption rate. In turn, these RIRs will be the largest component of the projections of IED. Low-consuming RIRs will have less impact on IED. However, the low rate means that these RIRs will have *greater* proportional accuracy when it comes to knowing how much space they need between present time and IED. (This is because, the uncertainty on allocation needs, will be the result of multiplying the uncertainty on IED date, by the rate of consumption. Low-consuming LIRs, will have less uncertainty on their penultimate allocation.) The uncertainty on exact date of IED, is expected to be largely invariant across RIRs. Any changes to individual RIR allocation trends, after the "pie split" date, are not expected to exceed the individual RIR's own uncertainty at "pie split" date. In other words, the accuracy of each RIR's IED is expected to increase over time, and to continue to fall within the range of the original upper and lower limits (based on rounding to /12) of the RIR's allocation from IANA. Timetable for implementation: immediate From info at arin.net Tue Nov 20 13:51:29 2007 From: info at arin.net (Member Services) Date: Tue, 20 Nov 2007 13:51:29 -0500 Subject: [ppml] Policy Proposal: 200-reduction-6.5.1.1.d - AC postponed decision Message-ID: <47432CB1.4090301@arin.net> On 15 November 2007, the ARIN Advisory Council (AC) postponed their decision regarding "200-reduction-6.5.1.1.d" in order for the shepherds to work with the author. The AC will review this proposal at their next regularly scheduled meeting. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/submission_archive.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: 200-reduction-6.5.1.1.d Author: Brian Dickson Proposal Version: 1 Submission Date: Oct 18, 2007 Proposal type: modify Policy term: permanent Policy statement: In 6.5.1.1 d), where 2007-25 proposes: "be an existing, known ISP in the ARIN region or have a plan for making at least 200 end-site assignments to other organizations within 5 years." replace with" "be an existing, known ISP in the ARIN region or have a plan for making at least 20 end-site assignments to other organizations, or for providing IPv6 transit to one or more IPv6 PI blocks belonging to other organizations, within 5 years." Rationale: The purpose of the text is to establish reasonable ways for an ISP to demonstrate that it is in fact an ISP. Any of the above listed conditions satisfy that need, and the intent is to avoid having the text of the policy prevent any legitimate ISP from receiving an initial IPv6 allocation. It does lower the bar, but in a justifiable fashion. It is not necessary for an ISP to have lots of PA assignments. It is necessary for an ISP to be announcing PA *or* PI blocks to the internet, and relaxing the criteria to recognize both possibilities jointly, makes the policy reflect the actual realities for any number of large regional ISPs, who may have sold off portions of their business but who still operate significant infrastructure. Timetable for implementation: Immediate From info at arin.net Tue Nov 20 13:51:58 2007 From: info at arin.net (Member Services) Date: Tue, 20 Nov 2007 13:51:58 -0500 Subject: [ppml] Policy Proposal 2007-27: Cooperative distribution of the end of the IPv4 free pool Message-ID: <47432CCE.5050106@arin.net> On 15 November 2007, the ARIN Advisory Council (AC) concluded their initial review of "Cooperative distribution of the end of the IPv4 free pool" and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-27: Cooperative distribution of the end of the IPv4 free pool. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_27.html All persons in the community are encouraged to discuss Policy Proposal 2007-27 prior to it being presented at the ARIN XXI Public Policy Meeting in April 2008. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-27 Cooperative distribution of the end of the IPv4 free pool Author: Tony Hain Proposal type: new Policy term: permanent Policy summary: This policy will establish a process for RIR-to-RIR redistribution of the tail-end of the IPv4 pool, taking effect after the IANA Reserve is exhausted. Each redistribution Allocation will be triggered by the recipient RIR depleting its reserve to a 30 day supply, and will result in up to a 3 month supply being transferred from the RIR with the longest remaining time before it exhausts its own pool. Policy statement: At the point when any given RIR is within 30 days of depleting its remaining IPv4 pool, a survey will be taken of the other 4 to determine the remaining time before each of them exhausts their pool (including both member use and recent redistribution allocations to other RIRs). The one with the longest window before exhausting its pool will be designated as the source RIR. The recipient RIR will follow procedures for an LIR in the source RIR region to request a block that is expected to be sufficient for up to 3 months, but is no larger than 1/8th of the source RIR's remaining pool. At the point where no RIR can supply a block that is less than 1/8th of their remaining pool that will sustain the recipient RIR for 30 days, the recipient RIR will collect its requests each week, and forward those individual requests to the source RIR designated that week. Rationale: This policy will establish a mechanism for the Allocation of IPv4 address blocks between RIR's, but will not go into effect until the IANA pool has been depleted. It is really bizarre to watch the maneuvering as the global RIR community grapples with 'fairness' of distributing the last few IANA Reserve /8 blocks. On one level this just appears to be petty sibling rivalry, as people are bickering over who gets the last cookie and whimpering about 'fairness'. At the same time, each RIR is chartered to look after the interests of its membership so it is to be expected that they will each want to get as much as possible to meet the needs of their respective membership. Existing practice requires RIR's to acquire blocks from IANA, which leads to the current round of nonsense about optimal distribution of the remaining pool based on elaborate mathematical models. This globally submitted policy proposal attempts to resolve the issue by shifting to an RIR-to-RIR Allocation model after the IANA pool is depleted. This policy would effectively result in each RIR becoming a virtual LIR member of all of the other RIR's for the sole purpose of managing the tail-end of the IPv4 pool. Timetable for implementation: Before 1/1/2009 From Fred.Wettling at Bechtel.com Tue Nov 20 14:01:38 2007 From: Fred.Wettling at Bechtel.com (Wettling, Fred) Date: Tue, 20 Nov 2007 14:01:38 -0500 Subject: [ppml] people or employers... In-Reply-To: <20071119203609.BD4A5647B7B@newdev.eecs.harvard.edu> References: <20071119203609.BD4A5647B7B@newdev.eecs.harvard.edu> Message-ID: <3400197AD5EC0540BC920AB9A1FD243311F8A9E0@fres0094.amers.ibechtel.com> I agree with Scott that the PPLM should be a place where people feel free to openly provide their perspectives and operate in unfiltered "real time" mode to be of most value. My point was that some organizations may reached some internal decisions or positions based on actual development and/or deployment experience with the topic that is being debated *BEFORE* the topic was raised on the PPML. PPML postings that include organizational position provides some context that may be of value to some of the participants, and perhaps not others. I suggest that relevant context (organizational or otherwise) be viewed as other attributes used to explain the perspective of the individual making the posting. Is the horse dead? Fred -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Scott O. Bradner Sent: Monday, November 19, 2007 3:36 PM To: ppml at arin.net Subject: Re: [ppml] people or employers (was Re: Policy Proposal Name: IPv6... fred sed: > PPML participants should consider that individuals speaking on behalf > of their organization may have gone through an internal vetting > process before posting a note. This will often include internal > discussions/debates/education and an enterprise impact analysis of the > policy proposal. I hope that people participating in the ppml will generally feel free to express their own opinions and that it is a rare case where everthing must be vetted internally before posting is permitted - I think we will lose much of the technical discussion if that becomes the norm in any case - it is speifically not assumed by the BoT that people are speaking for anyone but themselves and are speaking based on their own thought processes Scott From vit at mcdean.com Wed Nov 21 17:08:34 2007 From: vit at mcdean.com (Vitaliy Andryeyeshyn) Date: Wed, 21 Nov 2007 17:08:34 -0500 Subject: [ppml] Vitaliy Andryeyeshyn is out of the office. Message-ID: I will be out of the office starting 11/21/2007 and will not return until 12/01/2007. I will respond to your message when I return. Please contact Sergiy Lapin on burning issues. --- LEGAL DISCLAIMER: M.C. Dean, Inc. and its subsidiaries (Openband and Aneco) considers this email and any files transmitted with it to be confidential, proprietary or privileged information intended solely for the use of the named recipient(s). M. C. Dean, Inc. accepts no liability for the content of this email or for the consequences of any actions taken on the basis of the information contained in it, unless that information is subsequently confirmed in writing. Employees of M.C. Dean, Inc. are instructed not to infringe on any rights of the recipient; any such communication violates company policy. If you are not the intended recipient, any disclosure, copying, distribution, or action taken or omitted in reliance on this information is strictly prohibited by M.C. Dean, Inc.; please notify the sender immediately by return email, delete this communication and destroy all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: