From drc at virtualized.org Wed Aug 1 00:25:51 2007 From: drc at virtualized.org (David Conrad) Date: Tue, 31 Jul 2007 21:25:51 -0700 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> Message-ID: John, On Jul 31, 2007, at 8:17 PM, John Curran wrote: > You're going to be going through several > dozen of these blocks every week in order to meet the same > customer demand. Why are you assuming the ISPs won't be apply back pressure in the form of (significantly) increased cost per IP address to their customers? > The moment that you try and squeeze down the address space > that you're providing, the customer walk to a competitor who says > that giving them that entire /24 is "no problem". And how long will that competitor be able to say that? Everybody is in the same boat. Rgds, -drc From drc at virtualized.org Wed Aug 1 00:34:45 2007 From: drc at virtualized.org (David Conrad) Date: Tue, 31 Jul 2007 21:34:45 -0700 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> Message-ID: <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> John, On Jul 31, 2007, at 8:38 PM, John Curran wrote: > The burn rate is between 10 to 15 /8's per annum, increasing, > and while you'll see some pieces of the legacy space show up, > the extractable and reusable space will burn off under that > demand in a few short years. So you do not believe that under pricing pressure, people will be more efficient in address space usage thereby reducing the consumption rate? This seems counter intuitive to me. I once had 6 static IP addresses for my home. I reverted to one dynamic IP address + NAT exclusively because it was cheaper. Perhaps I'm overly price sensitive. Further, I would assume the largest address consumers, faced with non- predictable costs in obtaining resources will likely accelerate deployment plans for IPv6 for their internal infrastructure where possible, thereby freeing up the IPv4 addresses they're using for that infrastructure for customer assignment further reducing the consumption of the "available" pool. Seems to me that the demand for IPv4 will only decrease over time (although it may spike during a land rush prior to free pool exhaustion, depending on how the policies evolve). > very quickly the largest ISP's > will face having to ignore new routes from their peers (or they'll > be seeing if they can replace every EGP router to some of "2M" > route variety, only to do it again every ninety days...) I'm curious how you derived 'every ninety days'. I would assume that if a market were to develop, shorter prefixes would be more desirable than longer and ISPs would make deals like "free service for life plus this new car if you cede your /16 to me" or some such. Yes, as time goes on, there will be a trend towards longer prefixes as the aggregatable prefixes get consumed, but there will _always_ be the back pressure of the prefix length filters as they exist today. > Markets > aren't hierarchical, and there's no working backpressure model > for the imputed non-hierarchical routing cost, Sure there is. It's called prefix length filters -- that's what worked the last time we were in this situation. As I've said before, I wonder who is going to be playing the part of Sean Doran. The fear of obtaining unroutable prefixes means there is a limit to the length of prefix that will be on the market. > so it will spin apart sooner or later. "In the long term, we're all dead." -- John Maynard Keynes Rgds, -drc From randy at psg.com Wed Aug 1 00:52:24 2007 From: randy at psg.com (Randy Bush) Date: Tue, 31 Jul 2007 18:52:24 -1000 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> Message-ID: <46B01188.1070102@psg.com> i'll tell you what worries the hell outta me. we have someone from the iana talking what i see as both both business and operational sense. and we have arin board members telling us the end of the world is neigh and/or that we should bet on techno-idealism as opposed to greed and next quarter's net. something is very scary broken here. things are going to get uglier. but they will be a continuous processes. they'll be slow enough we can even see them, talk about them, and make decisions based on our perceptions. almost as if this was a business. the one thing that is gonna make things very hard for us is being able to get dual-stack equipment, software, ... lack of availability will severely limit our options. and trying to use address assignment policy to affect vendors may be the most extreme case of everything looking like a nail to the fool with the hammer that i have ever seen. this discussion should be happening on nanog and the isps should be shaking withheld orders at the vendors unless they have high quality dual stack kit. and i wanna nominate drc for arin board! (yes, i know) randy From brian at meganet.net Wed Aug 1 00:55:42 2007 From: brian at meganet.net (Brian Wallingford) Date: Wed, 1 Aug 2007 00:55:42 -0400 (EDT) Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> Message-ID: On Tue, 31 Jul 2007, David Conrad wrote: :John, : :On Jul 31, 2007, at 8:38 PM, John Curran wrote: :> The burn rate is between 10 to 15 /8's per annum, increasing, :> and while you'll see some pieces of the legacy space show up, :> the extractable and reusable space will burn off under that :> demand in a few short years. : :So you do not believe that under pricing pressure, people will be :more efficient in address space usage thereby reducing the :consumption rate? This seems counter intuitive to me. I once had 6 :static IP addresses for my home. I reverted to one dynamic IP :address + NAT exclusively because it was cheaper. Perhaps I'm overly :price sensitive. Absolutely they will. Long story short, every salesperson we've ever hired (and we still have the same salesfolks we hired in '96-'97) was required to do front-level tech support for three months before getting their sales seat. In the interim, they were taught routing-101, dns-101, email-101, etc., and they were educated as to what "justified" means when a prospective customer blindly requests a "class C" or anything more than a /29, and how NATing can satisfy many requirements. End result is that the *vast* majority of our T1/T3 customers (much like our static dsl customers, oddly enough) use either a /30 or /29. It's not that difficult to make the most of resources at hand. Years ago, I could have easily requested and been allocated much more than I have now. -brian (formerly the "ip nazi" in-house) From paul at vix.com Wed Aug 1 01:49:47 2007 From: paul at vix.com (Paul Vixie) Date: Wed, 01 Aug 2007 05:49:47 +0000 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/w RSA + efficient use)) In-Reply-To: Your message of "Tue, 31 Jul 2007 10:58:37 MST." <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <46AA8423.5060202@internap.com> <3c3e3fca0707271832y749f09ccw38ddf7b7a4f3d435@mail.gmail.com> <46AAA4C3.3050103@internap.com> <3c3e3fca0707271944v6fca3ccel68547b6067a34a9c@mail.gmail.com> <46AAB480.6020400@internap.com> <6eb799ab0707280622o313680b7gc639fa2bade0fd5f@mail.gmail.com> <46AB6585.7080900@psg.com> <6eb799ab0707281047l71652f57n9f75737c2bef054f@mail.gmail.com> <46AC0DF3.8050902@psg.com> <3c3e3fca0707290212r74d8d8adod8489ab5f9d9d8bf@mail.gmail.com> <46ACB03E.4020208@psg.com> <65115.1185725352@sa.vix.com> <6C350250-4E0A-49B7-A8DE-A2A24335BBD9@virtualized.org> <76042.1185814077@sa.vix.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> < 1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> Message-ID: <93896.1185947387@sa.vix.com> in (that's a message-id), michael dillon did a fine job of explaining why a market might not form, in answer to david conrad's answer to my question ("why will a market form"). i have only one further response to what drc wrote: > So, from my perspective, it would seem the conditions are ripe for a market. > The question then becomes, why wouldn't a market form? I haven't been able > to come up with a convincing reason. because there are no goods or services. ip addresses aren't property, and the right to use them isn't an asset once you divorce it from an ip network that's using those addresses. i didn't make that rule -- david conrad did, or at least, david conrad participated in writing down the rule which had predated his work in founding APNIC. see RFC 2052. an offer to sell ip addresses or to sell the right to use them is, to me, an admission that one no longer needs to use those ip addresses to connect devices to the internet. since connecting the devices to the internet was the purpose of all allocations throughout time, both in ARIN and other RIRs, and for both RIR and pre-RIR ("legacy") assignments, i would view an attempt to sell that right to use, as an abrogation of that right to use. but in all the assertions of a market's inevitability, and even among the excellent falsifications provided yesterday by william ferrin, noone other than michael dillon has challenged the basic assertion that there are goods and/or services to be marketed. instead we argue about whether there's a finite supply and what that might mean, we argue about whether the market could be liquid or not... but the fact that MIT would be sued eighteen ways in the first week and nineteen on sunday if 18.0.0.0/8 showed up on e-bay is like a great white elephant in the room, that most of you don't want to talk about, except michael dillon, whom most of you seem to be ignoring. note: arin's board of trustees has not stated a position on this topic, and if they were to state one, i would not be the spokesman. i am speaking my own mind here, and have taken off my trustee hat for this message. david continued: > I don't have a strong opinion on whether the markets are efficient. > However, given a market already exists, albeit one that is buried under the > need to buy/sell companies which hold IP address assets, I'm not sure how > you can say they aren't inevitable. i can say that the fixed costs of the fraud that has to be perpetrated in order to circumvent policy to transfer an ip address block, are fairly high, and function as a transaction cost, which is to say a barrier to transfer. as such, they do some good in protecting the routing table, since blocks smaller than a /21 are probably not worth the fixed transaction overhead of the fraud involved. removing those fixed costs, to transform what is now a black market into a normal "market", is not on my list of things to wish for. > And just to be perfectly clear, I don't necessarily consider this a good > thing. The creation of the entities known as "domainers" is a perfect > example of the risks of market driven economics. However, it isn't clear to > me that playing King Canute and demanding the tide not come in is a good > stewardship nor a good way to address those risks. having ARIN play king canute is likewise not on my list of things to wish for. but, i am not a fatalist. to me, the future is not cast. we may have alternatives and we should investigate them. we also have a status quo that may have benefits unseen by many, and we should not discard it lightly. From jcurran at istaff.org Wed Aug 1 07:42:02 2007 From: jcurran at istaff.org (John Curran) Date: Wed, 1 Aug 2007 07:42:02 -0400 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/w RSA + efficient use)) In-Reply-To: <46B01188.1070102@psg.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> Message-ID: At 6:52 PM -1000 7/31/07, Randy Bush wrote: >and we have arin board members telling us the end of the world is neigh >and/or that we should bet on techno-idealism as opposed to greed and >next quarter's net. You've got lots of folks pointing out that having an "anything goes" policy with respect to address reassignment might be bad - the use of the word "collapse" in this context isn't new: RFC 2008: "Hierarchical routing requires that aggregation boundaries for the addressing information be formed along some hierarchy. As a result, many exceptions will be injected into the routing system in the future, besides those exceptions that currently exist. Each exception added to the routing system deters the scalability of the routing system. The exact number of exceptions that can be tolerated is dependent on the technology used to support routing. Unbridled growth in the number of such exceptions will cause the routing system to collapse." Historically, the guidance to the RIR's has been to consider the potential impact of various allocation policies on the routing infrastructure. This includes the potential impact of assignment transfers, specifically those that arise independent of the transfer of network infrastructure. >things are going to get uglier. but they will be a continuous >processes. they'll be slow enough we can even see them, talk about >them, and make decisions based on our perceptions. almost as if this >was a business. Slow continuous processes coming out of a discontinuous event which impacts thousands of independent (but linked via routing) entities, all of whom try to cooperate but benefit more if they maximize their own payoff? (insert drc wikipedia reference here ;-) >but at no time will growth be inhibited. as we all know, the internet >routes around blockage. and growth will find the currently least cost >path. that's life in the big city. Your slides highlight the pain that moving to IPv6 is... the essence of much of the debate is whether the community is better served by recognizing and/or encouraging a "market" in IPv4 during that long transition period. I'm guessing that yourself (and drc) see such as desirable or inevitable, given normal business pressure for the quarterly results. The rub is that some of us see those same pressures, in presence of said "market" and due to the extensively referenced Prinsoner's Dilemma wr.t. routing behavior, yielding an explosive situation which doesn't have an obvious equilibrium point. If the community decides that we should abandon the RFC 2008 & 2050 guidance with respect to hierarchical assignment and reassignment and rely upon the ISP community to "do the right thing", then that's obviously how we'll proceed. It certainly creates some interesting short-term options for continued growth. /John >and i wanna nominate drc for arin board! (yes, i know) p.s. drc was a great board member (but we lost him to a "higher" calling :-) ) From randy at psg.com Wed Aug 1 07:45:02 2007 From: randy at psg.com (Randy Bush) Date: Wed, 01 Aug 2007 01:45:02 -1000 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/w RSA + efficient use)) In-Reply-To: References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> Message-ID: <46B0723E.7080301@psg.com> http://www.apnic.net/docs/policy/proposals/prop-050-v001.html From jcurran at istaff.org Wed Aug 1 07:46:14 2007 From: jcurran at istaff.org (John Curran) Date: Wed, 1 Aug 2007 07:46:14 -0400 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/w RSA + efficient use)) In-Reply-To: <46B0723E.7080301@psg.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> Message-ID: At 1:45 AM -1000 8/1/07, Randy Bush wrote: >http://www.apnic.net/docs/policy/proposals/prop-050-v001.html Exactly the question at hand. /John From randy at psg.com Wed Aug 1 07:52:28 2007 From: randy at psg.com (Randy Bush) Date: Wed, 01 Aug 2007 01:52:28 -1000 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/w RSA + efficient use)) In-Reply-To: References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> Message-ID: <46B073FC.1060400@psg.com> John Curran wrote: > At 1:45 AM -1000 8/1/07, Randy Bush wrote: >> http://www.apnic.net/docs/policy/proposals/prop-050-v001.html > Exactly the question at hand. damn! i shoulda thought of that. :) first, it is one of the questions. second, as it stands, it is limited to intra-rir, still embedded in the regional monopoly fantasy. randy From arin-contact at dirtside.com Wed Aug 1 09:22:49 2007 From: arin-contact at dirtside.com (William Herrin) Date: Wed, 1 Aug 2007 09:22:49 -0400 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/w RSA + efficient use)) In-Reply-To: <93896.1185947387@sa.vix.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <93896.1185947387@sa.vix.com> Message-ID: <3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com> On 8/1/07, Paul Vixie wrote: > > So, from my perspective, it would seem the conditions are ripe for a market. > > The question then becomes, why wouldn't a market form? I haven't been able > > to come up with a convincing reason. > > because there are no goods or services. ip addresses aren't property, [...] > an offer to sell ip addresses or to sell the right to use them is, to me, an > admission that one no longer needs to use those ip addresses [...] i > would view an attempt to sell that right to use, as an abrogation of > that right to use. > > but in all the assertions of a market's inevitability, and even among the > excellent falsifications provided yesterday by william [H]errin, noone other > than michael dillon has challenged the basic assertion that there are goods > and/or services to be marketed. Paul, I wouldn't call it an assumption. There are at least two methods to rent or sell IP addresses which function within the existing policy and a probability of increasing pressure from the operators to liberalize the policy itself. I'll let the latter stand as an unsupported claim. For the former, the two methods are: 1. The Ruse. Something other than IP addresses is leased but the practical affect is to indefinitely lease the IP addresses, as in my MIT message on the list yesterday. 2. The Container Sale. Instead of selling the IP addresses, you sell the entity which holds the registration. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From jcurran at istaff.org Wed Aug 1 09:35:12 2007 From: jcurran at istaff.org (John Curran) Date: Wed, 1 Aug 2007 09:35:12 -0400 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/w RSA + efficient use)) In-Reply-To: <3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <93896.1185947387@sa.vix.com> <3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com> Message-ID: At 9:22 AM -0400 8/1/07, William Herrin wrote: > >I wouldn't call it an assumption. There are at least two methods to >rent or sell IP addresses which function within the existing policy Full agreement there... The question is whether liberalization or prevention of the practice (and under what conditions) is the overall desire of the community. There's certainly things that could be done in either direction, once the desired goal is known. /John From michael.dillon at bt.com Wed Aug 1 10:00:41 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 1 Aug 2007 15:00:41 +0100 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/w RSA + efficient use)) In-Reply-To: References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com><88234.1185818363@sa.vix.com><0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org><24940.1185829923@sa.vix.com><12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org><71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com><83945.1185848565@sa.vix.com><1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com><1953.1185921854@sa.vix.com><61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com><567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org><46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> Message-ID: > >http://www.apnic.net/docs/policy/proposals/prop-050-v001.html Written by Geoff Huston, a proponent of buying and selling of IPv4 addresses. This proposal allows two address holders to transfer ownership of an address range directly, without first returning it to the RIR. The proposal doesn't deal with any details of the business arrangement between the two parties but presumably, the end goal of the proposal is to enable a market in IP addresses. The proposal does require the recipient of the address range to comply with RIR policies so they presumably must show a technical justification for the address range. And it requires the company giving away adddresses to NOT apply for new addresses for some period of time. Presumably the theory is that company A has a surplus and instead of handing it to the RIR or waiting for an RIR audit to reclaim the addresses, they sell some addresses to company B instead. This type of policy is pushing the RIRs into being commodities exchanges for IP addresses. Note, that even though this policy proposal only applies to IPv4 addresses, it is possible that it may set legal precedents for other types of Internet numbering resources such as IPv6 addresses, AS numbers, MIBs and so on. And yes, even telephone numbers. Another implication of this proposal is that a company holding a single RIR allocation, e.g. a /16, could deaggregate their routes and begin announcing 256 /24 prefixes so that they can sell off addresses which they no longer need. A company could reduce their address needs by a vigorous program of converting customers to NAT, a conversion to IPv6, or simply by selling their customers and network while holding on to their valuable IP address ranges. I don't like it. It just makes life more complicated during a time period in which we already have enough complexity to deal with. APNIC will discuss this at their meeting on the 6th of September. --Michael Dillon From stephen at sprunk.org Wed Aug 1 09:55:14 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 1 Aug 2007 08:55:14 -0500 Subject: [ppml] More on Kremen/Cohen References: Message-ID: <010301c7d447$98ebdf70$403816ac@atlanta.polycom.com> Thus spake "Dean Anderson" > Holy perjury and fraudulent transfers, batman. Dean, This has nothing to do with ARIN's public policy process. If you insist on ranting on these matters, please do so where it is on-topic: arin-discuss. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From owen at delong.com Wed Aug 1 11:03:02 2007 From: owen at delong.com (Owen DeLong) Date: Wed, 1 Aug 2007 08:03:02 -0700 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/w RSA + efficient use)) In-Reply-To: References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <93896.1185947387@sa.vix.com> <3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com> Message-ID: On Aug 1, 2007, at 6:35 AM, John Curran wrote: > At 9:22 AM -0400 8/1/07, William Herrin wrote: >> >> I wouldn't call it an assumption. There are at least two methods to >> rent or sell IP addresses which function within the existing policy > > Full agreement there... The question is whether liberalization > or prevention of the practice (and under what conditions) is the > overall desire of the community. There's certainly things that > could be done in either direction, once the desired goal is known. > I would favor prevention, but, I'm not sure how one would construct prevention from the MIT case being a ruse vs. the MIT case being a legitimate service. So long as the dial-up accounts with MIT actually functioned, I would consider that to be legitimate service rather than ruse. Owen From info at arin.net Wed Aug 1 11:03:24 2007 From: info at arin.net (Member Services) Date: Wed, 01 Aug 2007 11:03:24 -0400 Subject: [ppml] Policy Proposal: PIv6 for legacy holders with RSA and efficient use In-Reply-To: <46AE1EA9.3010509@arin.net> References: <46AE1EA9.3010509@arin.net> Message-ID: <46B0A0BC.6010508@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 Suzanne Woolf and Ron da Silva. 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: PIv6 for legacy holders with RSA and efficient use > > Author: Scott Leibrand > > Proposal Version: 1.0 > > Submission Date: 7/28/2007 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Modify NRPM section 6.5.8.1 (Direct assignments from ARIN to end-user > organizations: Criteria), to read: > > To qualify for a direct assignment, an organization must: > > 1. not be an IPv6 LIR; and > 2. qualify for an IPv4 assignment or allocation from ARIN under the > IPv4 policy currently in effect, or demonstrate efficient > utilization of a direct IPv4 assignment or allocation covered by a > current ARIN RSA. > > Rationale: > > Current policy allows direct IPv6 allocations and assignments to nearly > all organizations with IPv4 allocations or assignments from ARIN. As a > result, such organizations can get IPv6 space just as easily as they can > get IPv4 space, making it easy for them to transition to IPv6 as soon as > they're ready to do so. However, there are some organizations who > received IPv4 /23's and /24's prior to the formation of ARIN, and use > that space in a multihomed, provider-independent fashion. Under current > policy, such organizations cannot get IPv6 PI space without artificially > inflating host counts, and are therefore discouraged from adopting IPv6. > This policy proposal aims to remove this disincentive, and allow such > organizations to easily adopt IPv6. > > In addition, pre-ARIN assignments were issued through an informal > process, and many legacy resource holders have not yet entered into a > formal agreement with ARIN, the manager of many such IP numbering > resources. This policy proposal would require that such assignments be > brought under a current ARIN Registration Services Agreement, thereby > formalizing the relationship. > > Some pre-ARIN assignments may not be used efficiently. As unallocated > IPv4 numbering resources are approaching exhaustion, it is important to > ensure efficient utilization of IPv4 assignments, and to arrange for > reclamation of unused space. Therefore, this policy would require that > the organization wishing to receive IPv6 PI space demonstrate efficient > utilization of their IPv4 assignment. (Efficient utilization is already > defined elsewhere in policy, and the exact mechanism for achieving and > determining efficient use is a matter of procedure, not of policy, so > detailed procedures are not included in the policy statement above. The > intent is that any organization with an assignment of /23 or larger > which is less than 50% utilized would renumber and return whole unused > CIDR blocks as necessary to bring the remaining CIDR block to 50% > utilization or higher. A /24 should be considered efficiently utilized > as long as it is in use for multihoming, as /25's and smaller are not > routable for that purpose.) > > It has been suggested that this policy would be useful only until the > growth of IPv6 exceeds the growth of IPv4. I would agree with this, > and would further posit that the existing "qualify ... under the IPv4 > policy currently in effect" language should also be modified at that > time. I have therefore proposed this policy with a policy term of > "permanent", with the expectation that this section of policy (6.5.8.1) > will be rewritten at the appropriate time to entirely remove all IPv4 > dependencies. > > Timetable for implementation: immediate > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From arin-contact at dirtside.com Wed Aug 1 11:26:53 2007 From: arin-contact at dirtside.com (William Herrin) Date: Wed, 1 Aug 2007 11:26:53 -0400 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/w RSA + efficient use)) In-Reply-To: <3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <93896.1185947387@sa.vix.com> <3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com> Message-ID: <3c3e3fca0708010826y5963aa94r40f4993f6a8e6456@mail.gmail.com> On 8/1/07, William Herrin wrote: > On 8/1/07, Paul Vixie wrote: > > but in all the assertions of a market's inevitability, and even among the > > excellent falsifications provided yesterday by william [H]errin, noone other > > than michael dillon has challenged the basic assertion that there are goods > > and/or services to be marketed. > > There are at least two methods to > rent or sell IP addresses which function within the existing policy > > 1. The Ruse. Something other than IP addresses is leased but the > practical affect is to indefinitely lease the IP addresses. > 2. The Container Sale. Instead of selling the IP addresses, you sell > the entity which holds the registration. Let me offer a concrete example of the ruse and the container sale: Container Sale: In the late 1990's, Verio purchased Clark Net, a local Internet Service Provider serving Baltimore and Washington DC. With the purchase, Verio gained control of the IP addresses allocated to Clark Net. The Ruse: In 2003 or so, Verio sold its T1 accounts in the Clark Net region to Cogent. The associated IP addresses were reallocated to Cogent. In many cases these were prefixes longer than /24. Cogent served these with IP transit purchased in bulk from Verio. In other cases the addresses combined to form /24's and shorter prefixes. These were deaggregated from the larger Verio/Clark Net blocks and separately announced. Calling it a ruse may be misleading because this is clearly a legitimate business transaction where the primary asset was not IP addresses. Nevertheless, the consequence is the same: IP address blocks have been split up and portions permanently transferred from entity to entity without RIR involvement and in exchange for remuneration. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From bicknell at ufp.org Wed Aug 1 11:30:22 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 1 Aug 2007 11:30:22 -0400 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: <46AFFD25.5050909@psg.com> References: <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> Message-ID: <20070801153022.GA69425@ussenterprise.ufp.org> In a message written on Tue, Jul 31, 2007 at 05:25:25PM -1000, Randy Bush wrote: > > Surprise! Now you have to go hunt down a /24 here, maybe a /20 now > > and then (presuming some folks factor their old assignments). > > i think you significantly underestimate what will be on ebay. as drc > said O(100) /8s. but time will tell, won't it. Markets are very efficient. It is unfortunate that for many things that can be subdivided the sum of the parts is greater than the whole. It would not surprise me to find out that if a market happens it's far easier to sell a /8 as 65536 /24's, each costing $10k, than as a single block costing $65 million, both of which generate the same "profit". -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From paul at vix.com Wed Aug 1 12:00:59 2007 From: paul at vix.com (Paul Vixie) Date: Wed, 01 Aug 2007 16:00:59 +0000 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/w RSA + efficient use)) In-Reply-To: Your message of "Wed, 01 Aug 2007 05:49:47 GMT." <93896.1185947387@sa.vix.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <46AA8423.5060202@internap.com> <3c3e3fca0707271832y749f09ccw38ddf7b7a4f3d435@mail.gmail.com> <46AAA4C3.3050103@internap.com> <3c3e3fca0707271944v6fca3ccel68547b6067a34a9c@mail.gmail.com> <46AAB480.6020400@internap.com> <6eb799ab0707280622o313680b7gc639fa2bade0fd5f@mail.gmail.com> <46AB6585.7080900@psg.com> <6eb799ab0707281047l71652f57n9f75737c2bef054f@mail.gmail.com> <46AC0DF3.8050902@psg.com> <3c3e3fca0707290212r74d8d8adod8489ab5f9d9d8bf@mail.gmail.com> <46ACB03E.4020208@psg.com> <65115.1185725352@sa.vix.com> <6C350250-4E0A-49B7-A8DE-A2A24335BBD9@virtualized.org> <76042.1185814077@sa.vix.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> < 1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <93896.1185947387@sa.vix.com> Message-ID: <55013.1185984059@sa.vix.com> > ... at least, david conrad participated in writing down the rule which had > predated his work in founding APNIC. see RFC 2052. i meant of course RFC 2050. apologies to all, i shouldn't post late at night. From llynch at civil-tongue.net Wed Aug 1 12:03:26 2007 From: llynch at civil-tongue.net (Lucy Lynch) Date: Wed, 1 Aug 2007 09:03:26 -0700 (PDT) Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> Message-ID: <20070801083756.C64274@hiroshima.bogus.com> On Tue, 31 Jul 2007, David Conrad wrote: > On Jul 31, 2007, at 3:44 PM, Paul Vixie wrote: >> can each extant enterprise /8 be carved up into 64K /24's without >> exploding >> the global routing table / default free zone / internet core? > > I'm told YFRV have indicated we're currently at 10% what routers > today can handle and by the time we see the shattering of legacy > space into the routing system, the limits will be much higher. > Plenty o' room... > > NOTE: I do not believe this, however the people paying the bills will > use arguments along these lines in CEO and board room discussions and > guess where network operators' input will land? > > Anyhow, there won't be an explosion. As Randy points out elsewhere, > routing table growth is boiling the frog. See http://en.wikipedia.org/ > wiki/Boiling_frog or http://en.wikipedia.org/wiki/ > Tragedy_of_the_commons (Wikipedia is great! :-)). commons isn't quite right - common pool closer - "Common pool resources (CPR) are characterised by the difficulty of excluding actors from using them and the fact that the use by one individual or group means that less is available for use by others. (The latter point distinguishes CPR from pure public goods which exhibit both non excludability and non rivalry in consumption). CPRs include some fisheries, irrigation systems and grazing areas. Also: A valued natural or human-made resource or facility in which one person's use subtracts from another's use and [from which] it is often necessary but difficult to exclude potential users." Jointly managing the common-pool is tough and we (collective we: IANA/RIRs/ISPs/vendors/standards folk/etc.) will need to show a very high level of co-ordination, fairness, and foresight if we want to have continued governmental support for the current distributed model of resource allocation. A relevant paper from the CPR field: Common Property,Regulatory Property, and Environmental Protection:. Comparing Community-Based Management to Tradable Environmental Allowances Carol M. Rose (2000) http://dlc.dlib.indiana.edu/archive/00000333/00/rosec041200.pdf and for some idea of the scale of resources and planning needed to pull off multi-stakehold common-pool management see: The Millennium Ecosystem Assessment assessed the consequences of ecosystem change for human well-being. From 2001 to 2005, the MA involved the work of more than 1,360 experts worldwide. Their findings provide a state-of-the-art scientific appraisal of the condition and trends in the worlds ecosystems and the services they provide, as well as the scientific basis for action to conserve and use them sustainably... http://www.millenniumassessment.org/en/Index.aspx and for a fairly depressing read on how shared resourses drift toward private property see: Establishing Ownership: First Possession versus Accession (Thomas Merrill) http://repositories.cdlib.org/cgi/viewcontent.cgi?article=1174&context=berkeley_law_econ - Lucy > Rgds, > -drc > > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From tvest at pch.net Wed Aug 1 12:04:31 2007 From: tvest at pch.net (Tom Vest) Date: Wed, 1 Aug 2007 12:04:31 -0400 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/w RSA + efficient use)) In-Reply-To: <3c3e3fca0708010826y5963aa94r40f4993f6a8e6456@mail.gmail.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <93896.1185947387@sa.vix.com> <3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com> <3c3e3fca0708010826y5963aa94r40f4993f6a8e6456@mail.gmail.com> Message-ID: On Aug 1, 2007, at 11:26 AM, William Herrin wrote: >> On 8/1/07, Paul Vixie wrote: >>> but in all the assertions of a market's inevitability, and even >>> among the >>> excellent falsifications provided yesterday by william [H]errin, >>> noone other >>> than michael dillon has challenged the basic assertion that there >>> are goods >>> and/or services to be marketed. >> >> There are at least two methods to >> rent or sell IP addresses which function within the existing policy >> >> 1. The Ruse. Something other than IP addresses is leased but the >> practical affect is to indefinitely lease the IP addresses. >> 2. The Container Sale. Instead of selling the IP addresses, you sell >> the entity which holds the registration. > > > Let me offer a concrete example of the ruse and the container sale: > > Container Sale: In the late 1990's, Verio purchased Clark Net, a local > Internet Service Provider serving Baltimore and Washington DC. With > the purchase, Verio gained control of the IP addresses allocated to > Clark Net. > > The Ruse: In 2003 or so, Verio sold its T1 accounts in the Clark Net > region to Cogent. The associated IP addresses were reallocated to > Cogent. In many cases these were prefixes longer than /24. Cogent > served these with IP transit purchased in bulk from Verio. In other > cases the addresses combined to form /24's and shorter prefixes. These > were deaggregated from the larger Verio/Clark Net blocks and > separately announced. > > Calling it a ruse may be misleading because this is clearly a > legitimate business transaction where the primary asset was not IP > addresses. Nevertheless, the consequence is the same: IP address > blocks have been split up and portions permanently transferred from > entity to entity without RIR involvement and in exchange for > remuneration. Since the categorization will likely inform the proposed responses, it's perhaps not merely quibbling to reiterate that "the ruse" in this case seems to be just another variety of "container transfer". In some sense all protocol number transfers that do not comply with concurrent policies (whatever they may be at the time) are "ruse- like" by definition, so it's not clear why one would attribute more or less misfeasance/malfeasance to some transactions than others -- unless of course they occurred in direct contravention to authoritative (meaning at present, RIR) guidance. It's perhaps also worth noting that so described the "container sale" is just a special case of the general method of network business strategy/problem solving which occurs at every level -- e.g. company acquisitions to secure cable or sat landings to address geographically isolated markets, or to secure established interconnection relationships to address topo/logically isolated markets. The (ISP) interprets all such impediments as congestion and routes around -- so perhaps there are other historical observations/ lessons that can be applied here... TV From paul at vix.com Wed Aug 1 12:35:23 2007 From: paul at vix.com (Paul Vixie) Date: Wed, 01 Aug 2007 16:35:23 +0000 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/w RSA + efficient use)) In-Reply-To: Your message of "Wed, 01 Aug 2007 09:22:49 -0400." <3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <93896.1185947387@sa.vix.com> <3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com> Message-ID: <63550.1185986123@sa.vix.com> bill herrin wrote: > ... and a probability of increasing pressure from the operators to > liberalize the policy itself. > > I'll let the latter stand as an unsupported claim. as to that unsupported claim, the community could use the open policy development process to liberalize things, or the community could use the open policy development process to tighten things up. this is not a strict one-address-one-vote democracy. it'll be very interesting to see what kinds of proposals come onto the field and which ones are welcomed. not everyone expects to be able to afford "market pricing", especially considering issues like globalization, futures, hoarding, and speculation. there are no simple slam dunks here that i can see. > For the former, the two methods are: > > 1. The Ruse. Something other than IP addresses is leased but the > practical affect is to indefinitely lease the IP addresses, as in my > MIT message on the list yesterday. this is brilliant, by the way. > 2. The Container Sale. Instead of selling the IP addresses, you sell > the entity which holds the registration. ip addresses don't go with a business, they go with an operating network. at the moment those things are usually just treated as equivilent, but i think an auditor could tell the difference. paul ps. not speaking as an arin trustee in this message. From drc at virtualized.org Wed Aug 1 12:39:44 2007 From: drc at virtualized.org (David Conrad) Date: Wed, 1 Aug 2007 09:39:44 -0700 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/w RSA + efficient use)) In-Reply-To: References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> Message-ID: <253A3C86-0E33-4FED-BB7F-0179F5F1C7B0@virtualized.org> John, On Aug 1, 2007, at 4:42 AM, John Curran wrote: > I'm guessing that yourself (and drc) see such as desirable or > inevitable, > given normal business pressure for the quarterly results. Desirable? Not particularly (as I've mentioned in the past). Inevitable? Yeah, pretty much. > The rub is > that some of us see those same pressures, in presence of said "market" > and due to the extensively referenced Prinsoner's Dilemma wr.t. > routing > behavior, yielding an explosive situation which doesn't have an > obvious > equilibrium point. Well, yeah. And all those neat sandcastles we've built since 1996 are going to be destroyed when the tide comes in. I'm curious. How are you going to stop the tide from coming in? Closing your eyes and saying "I don't like it because it'll be bad" probably won't do the trick... Rgds, -drc From bmanning at vacation.karoshi.com Wed Aug 1 13:21:55 2007 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 1 Aug 2007 17:21:55 +0000 Subject: [ppml] the docmoc method of knoted thread removal Message-ID: <20070801172155.GA4145@vacation.karoshi.com.> ppml has become an "in" place to be to air topics of interest in the addressing community. and as is true w/ many such "flash-mob" events, there seem to be a few folks who dominate the consumption of bandwidth, creating knots in the thread of discussion. the tried/proven docmoc method of knot removal is to avoid reading postings from the prolific and read posts from the occasional poster - the argument here is to look for fresh points of view. I appreciate Lucy's post and the pointers. --bill From George.Kuzmowycz at aipso.com Wed Aug 1 10:09:21 2007 From: George.Kuzmowycz at aipso.com (George Kuzmowycz) Date: Wed, 01 Aug 2007 10:09:21 -0400 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) Message-ID: Saying that markets "might not form" is not the same as saying markets will not form. Lack of liquidity may lead to inefficiencies in pricing, but it does not mean that purchases and sales are impossible. Accountants are able to assign value to all sorts of things that mere mortals consider intangible or illiquid. Probably even some readers of this list work for or have worked for an employer that compensated them at least partially in promises instead of cash (i.e. options), or in things of value that couldn't easily be sold (i.e. restricted shares). Seeing 18.0.0.0/8 on ebay may be the reductio ad absurdum, but on the other hand, is, say, a struggling manufacturing firm with a legacy B more or less valuable as an M&A target than a similar firm with no such IP space? If more valuable, then by how much? I think history shows that market mechanisms are better at distributing scarce resources than central planning is. >>> "Paul Vixie" 08/01/2007 1:49:47 AM >>> in (that's a message-id), michael dillon did a fine job of explaining why a market might not form From jcurran at istaff.org Wed Aug 1 13:29:11 2007 From: jcurran at istaff.org (John Curran) Date: Wed, 1 Aug 2007 13:29:11 -0400 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/w RSA + efficient use)) In-Reply-To: <253A3C86-0E33-4FED-BB7F-0179F5F1C7B0@virtualized.org> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> <253A3C86-0E33-4FED-BB7F-0179F5F1C7B0@virtualized.org> Message-ID: At 9:39 AM -0700 8/1/07, David Conrad wrote: >Desirable? Not particularly (as I've mentioned in the past). >Inevitable? Yeah, pretty much. If everyone throws up their hands, then it could indeed be inevitable. (Of course, that's a great sign off community consensus, so I've got no problem with that outcome) If folks (read: ICANN/IANA/RIR/IETF/ISPs) want to prevent a market, it's not that hard to do. >>The rub is >>that some of us see those same pressures, in presence of said "market" >>and due to the extensively referenced Prinsoner's Dilemma wr.t. routing >>behavior, yielding an explosive situation which doesn't have an obvious >>equilibrium point. > >Well, yeah. And all those neat sandcastles we've built since 1996 are going to be destroyed when the tide comes in. > >I'm curious. How are you going to stop the tide from coming in? >Closing your eyes and saying "I don't like it because it'll be bad" probably won't do the trick... Which tide? As noted above, there's quite a bit that could be done if one wanted to deter (or accelerate!) emergence of a market, once we know the desired outcome. If you're talking about how to prevent self-immolation of the ISP community when they attempt to keep up routing tables that go from approximately hierarchical to significantly non-hierarchical, I really don't know. The cool part about that problem is that by the time its a perfectly obvious problem to everyone involved, there actually may be no way to undo the situation from within. /John From drc at virtualized.org Wed Aug 1 13:34:52 2007 From: drc at virtualized.org (David Conrad) Date: Wed, 1 Aug 2007 10:34:52 -0700 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/w RSA + efficient use)) In-Reply-To: <93896.1185947387@sa.vix.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <46AA8423.5060202@internap.com> <3c3e3fca0707271832y749f09ccw38ddf7b7a4f3d435@mail.gmail.com> <46AAA4C3.3050103@internap.com> <3c3e3fca0707271944v6fca3ccel68547b6067a34a9c@mail.gmail.com> <46AAB480.6020400@internap.com> <6eb799ab0707280622o313680b7gc639fa2bade0fd5f@mail.gmail.com> <46AB6585.7080900@psg.com> <6eb799ab0707281047l71652f57n9f75737c2bef054f@mail.gmail.com> <46AC0DF3.8050902@psg.com> <3c3e3fca0707290212r74d8d8adod8489ab5f9d9d8bf@mail.gmail.com> <46ACB03E.4020208@psg.com> <65115.1185725352@sa.vix.com> <6C350250-4E0A-49B7-A8DE-A2A24335BBD9@virtualized.org> <76042.1185814077@sa.vix.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <93896.1185947387@sa.vix.com> Message-ID: Paul, On Jul 31, 2007, at 10:49 PM, Paul Vixie wrote: > in UKBR.domain1.systemhost.net> > (that's a message-id), michael dillon did a fine job of explaining > why a market > might not form, in answer to david conrad's answer to my question > ("why will a > market form"). Actually, he didn't. He might have made an argument that the market won't be sustainable in the long term, but I've never disputed that -- hopefully, IPv4 will go away someday and as such, any market for that resource would collapse. >> The question then becomes, why wouldn't a market form? > because there are no goods or services. You're kidding, right? > ip addresses aren't property, and > the right to use them isn't an asset once you divorce it from an ip > network > that's using those addresses. Asserting something repeatedly does not make it true. I suspect if you ask, the vast majority of provider independent address holders would, in fact, consider their IPv4 addresses their property. Perhaps they are mistaken. Perhaps you and ARIN's legal counsel are. I'm sure we'll find out relatively soon. > i didn't make that rule -- david conrad did, > or at least, david conrad participated in writing down the rule > which had > predated his work in founding APNIC. see RFC 2052. I suspect you mean RFC 2050 (and I was involved in writing it while I was at APNIC, not before). You might look at the date of publication, read the IESG preamble, and ponder whether the circumstances in which that document were published are still applicable today. > but the fact that MIT would be sued eighteen ways > in the first week and nineteen on sunday if 18.0.0.0/8 showed up on > e-bay > is like a great white elephant in the room, that most of you don't > want to > talk about, except michael dillon, whom most of you seem to be > ignoring. Hard to ignore something that has yet to be asserted. I'm curious. Who would you see filing the lawsuit against MIT, Networld+Interop, Halliburton, etc. should they decide to lease out unused parts of their network address space? ARIN? > i can say that the fixed costs of the fraud that has to be > perpetrated in > order to circumvent policy to transfer an ip address block, are > fairly high, > and function as a transaction cost, which is to say a barrier to > transfer. Sorry, what fraud has been perpetrated? > as such, they do some good in protecting the routing table, since > blocks > smaller than a /21 are probably not worth the fixed transaction > overhead of > the fraud involved. Ignoring whether or not it is fraud, I assure you, you are simply wrong here. > removing those fixed costs, to transform what is now a > black market into a normal "market", is not on my list of things to > wish for. The fact that you might not wish for it or that you don't like it or that you think it not "Good for the Internet"(tm) does not mean it won't happen. I need merely point to spam as an example you may have some familiarity with. > we may have > alternatives and we should investigate them. OK, what are those alternatives? Rgds, -drc From drc at virtualized.org Wed Aug 1 13:46:29 2007 From: drc at virtualized.org (David Conrad) Date: Wed, 1 Aug 2007 10:46:29 -0700 Subject: [ppml] the docmoc method of knoted thread removal In-Reply-To: <20070801172155.GA4145@vacation.karoshi.com.> References: <20070801172155.GA4145@vacation.karoshi.com.> Message-ID: <632DAC1A-3A80-45C9-96C0-B6B8D74D3478@virtualized.org> I can take a hint from an esteemed ARIN board of trustees member. I'll go back to getting real work done. Rgds, -drc On Aug 1, 2007, at 10:21 AM, bmanning at vacation.karoshi.com wrote: > > ppml has become an "in" place to be to air topics of interest in > the addressing > community. and as is true w/ many such "flash-mob" events, there > seem to be a > few folks who dominate the consumption of bandwidth, creating knots > in the > thread of discussion. > > the tried/proven docmoc method of knot removal is to avoid reading > postings > from the prolific and read posts from the occasional poster - the > argument > here is to look for fresh points of view. > > I appreciate Lucy's post and the pointers. > > --bill > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > > From bmanning at vacation.karoshi.com Wed Aug 1 13:58:53 2007 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 1 Aug 2007 17:58:53 +0000 Subject: [ppml] the docmoc method of knoted thread removal In-Reply-To: <632DAC1A-3A80-45C9-96C0-B6B8D74D3478@virtualized.org> References: <20070801172155.GA4145@vacation.karoshi.com.> <632DAC1A-3A80-45C9-96C0-B6B8D74D3478@virtualized.org> Message-ID: <20070801175853.GB4856@vacation.karoshi.com.> well, its does seem that the horse is dead and beating it won't make it go faster. clearly you have defenseable points and so do others. myself, i'm of roughly the same mind as Mr. Curren - e.g. - we will do what the community, through the existing policy development process, directs us to do. I did find Lucy's post a refreshing change of pace, with pointers to real work/analysis in areas similar to the space we find for the addressing regime. and as a current Trustee, I feel the obligation to read ALL the posts, esp. those from former Trustees. --bill On Wed, Aug 01, 2007 at 10:46:29AM -0700, David Conrad wrote: > I can take a hint from an esteemed ARIN board of trustees member. > > I'll go back to getting real work done. > > Rgds, > -drc > > On Aug 1, 2007, at 10:21 AM, bmanning at vacation.karoshi.com wrote: > > > > >ppml has become an "in" place to be to air topics of interest in > >the addressing > >community. and as is true w/ many such "flash-mob" events, there > >seem to be a > >few folks who dominate the consumption of bandwidth, creating knots > >in the > >thread of discussion. > > > >the tried/proven docmoc method of knot removal is to avoid reading > >postings > >from the prolific and read posts from the occasional poster - the > >argument > >here is to look for fresh points of view. > > > >I appreciate Lucy's post and the pointers. > > > >--bill > >_______________________________________________ > >This message sent to you through the ARIN Public Policy Mailing List > >(PPML at arin.net). > >Manage your mailing list subscription at: > >http://lists.arin.net/mailman/listinfo/ppml > > > > From paul at vix.com Wed Aug 1 14:15:08 2007 From: paul at vix.com (Paul Vixie) Date: Wed, 01 Aug 2007 18:15:08 +0000 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: Your message of "Wed, 01 Aug 2007 10:09:21 -0400." References: Message-ID: <84424.1185992108@sa.vix.com> > Saying that markets "might not form" is not the same as saying markets > will not form. not only am i not saying "will not form" i'm not saying "should not form". so, when i said "might not form" i really meant only "might not form". > Seeing 18.0.0.0/8 on ebay may be the reductio ad absurdum, but on the > other hand, is, say, a struggling manufacturing firm with a legacy B > more or less valuable as an M&A target than a similar firm with no such > IP space? If more valuable, then by how much? does the internet community want ARIN to scrutinize that transaction to ensure that there's an operating network for which the company still qualifies, or does the internet community want ARIN to turn a blind eye if the "seller" forms a wholly owned subsidiary, transfers this "asset" into it, and sells that company, with this class B as its only "asset"? ARIN is an instrument of the community, and if the community wants this kind of transfer to be a trivial matter of paperwork, then there are ways for the community to express that desire through policy development. > I think history shows that market mechanisms are better at distributing > scarce resources than central planning is. you could say that if you look for all the iron and coal that was dug out of the ground under the soviet union and wonder "where's the steel? where's the finished product? where's the economy?" you couldn't say that if you looked at the free market in electricity pricing in california back in 2001. so, i think history can show whatever we want it to show. ps. i'm not speaking as an arin trustee in this message. From randy at psg.com Wed Aug 1 14:44:02 2007 From: randy at psg.com (Randy Bush) Date: Wed, 01 Aug 2007 08:44:02 -1000 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/w RSA + efficient use)) In-Reply-To: References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <93896.1185947387@sa.vix.com> <3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com> Message-ID: <46B0D472.7000508@psg.com> > The question is whether liberalization or prevention of the practice > (and under what conditions) is the overall desire of the community. > There's certainly things that could be done in either direction, once > the desired goal is known. there is trade in address space now. when arin runs out of iana free pool space, this trade will *seriously* accelerate. get over it. the question is only whether arin takes its head out of the 1990s and becomes title agent (rpki) to authenticate trading, or whether verisign, or whomever, takes that business away from arin. arin's choice. randy From tedm at ipinc.net Wed Aug 1 15:11:09 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 1 Aug 2007 12:11:09 -0700 Subject: [ppml] More on Kremen/Cohen In-Reply-To: <010301c7d447$98ebdf70$403816ac@atlanta.polycom.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Stephen Sprunk >Sent: Wednesday, August 01, 2007 6:55 AM >To: Dean Anderson; ARIN PPML >Subject: Re: [ppml] More on Kremen/Cohen > > >Thus spake "Dean Anderson" >> Holy perjury and fraudulent transfers, batman. > >Dean, > >This has nothing to do with ARIN's public policy process. Stephen, I disagree with this statement. We all dodged the bullet on this one - if the case hadn't been dismissed on a technicality, it might have severly impacted ARIN's public policy pocess. Dean is completely misguided by thinking that the public good would be served by attempting to resurrect this case by filing various (futile IMHO) motions. It is almost a certainty that if further policy is adopted by ARIN that turns out to have negative impacts, that it will trigger more court cases. This case really should serve as a warning to everyone. Ted From Lee.Howard at stanleyassociates.com Wed Aug 1 16:25:21 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 1 Aug 2007 16:25:21 -0400 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4068FD457@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of David Conrad > Sent: Wednesday, August 01, 2007 1:35 PM > To: Paul Vixie > Cc: ppml at arin.net > Subject: Re: [ppml] alternative realities (was PIv6 for > legacy holders (/wRSA + efficient use)) > > > i didn't make that rule -- david conrad did, or at least, > david conrad > > participated in writing down the rule which had predated > his work in > > founding APNIC. see RFC 2052. > > I suspect you mean RFC 2050 (and I was involved in writing it > while I was at APNIC, not before). You might look at the > date of publication, read the IESG preamble, and ponder > whether the circumstances in which that document were > published are still applicable today. I could guess at whether you would co-author such an RFC today, or I could ask you what you think, though you might have trouble doffing your hat. Are the goals enumerated in RFC2050 still supported by the ARIN community? 1) Conservation: Fair distribution of globally unique Internet address space according to the operational needs of the end-users and Internet Service Providers operating networks using this address space. Prevention of stockpiling in order to maximize the lifetime of the Internet address space. 2) Routability: Distribution of globally unique Internet addresses in a hierarchical manner, permitting the routing scalability of the addresses. This scalability is necessary to ensure proper operation of Internet routing, although it must be stressed that routability is in no way guaranteed with the allocation or assignment of IPv4 addresses. 3) Registration: Provision of a public registry documenting address space allocation and assignment. This is necessary to ensure uniqueness and to provide information for Internet trouble shooting at all levels. Lee From jcurran at istaff.org Wed Aug 1 16:26:23 2007 From: jcurran at istaff.org (John Curran) Date: Wed, 1 Aug 2007 16:26:23 -0400 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/w RSA + efficient use)) In-Reply-To: <46B0D472.7000508@psg.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <93896.1185947387@sa.vix.com> <3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com> <46B0D472.7000508@psg.com> Message-ID: At 8:44 AM -1000 8/1/07, Randy Bush wrote: > > The question is whether liberalization or prevention of the practice >> (and under what conditions) is the overall desire of the community. >> There's certainly things that could be done in either direction, once >> the desired goal is known. > >there is trade in address space now. when arin runs out of iana free >pool space, this trade will *seriously* accelerate. If that's what the community desires, then let's get it done. You seem to see it as inevitable, which is my objection. If the ISP community doesn't want to proceed in that direction, then ARIN will hold the line on the existing policies, and take the measures necessary. >the question is only whether arin takes its head out of the 1990s and >becomes title agent (rpki) to authenticate trading, or whether verisign, >or whomever, takes that business away from arin. ARIN doesn't need the "business"; ARIN's here to manage and help conserve scarce Internet protocol resources, and to educate Internet protocol users on how to efficiently utilize these scarce resources as a service to the entire Internet community. /John From George.Kuzmowycz at aipso.com Wed Aug 1 16:51:31 2007 From: George.Kuzmowycz at aipso.com (George Kuzmowycz) Date: Wed, 01 Aug 2007 16:51:31 -0400 Subject: [ppml] alternative realities (was PIv6 for legacy holders(/w RSA + efficient use)) Message-ID: I thought this was the IP-address-consuming community. If this is the ISP community, then I am on the wrong mailing list. >>> "John Curran" 08/01/2007 4:26:23 PM >>> If that's what the community desires, then let's get it done. You seem to see it as inevitable, which is my objection. If the ISP community From info at arin.net Wed Aug 1 17:31:03 2007 From: info at arin.net (Member Services) Date: Wed, 1 Aug 2007 17:31:03 -0400 Subject: [ppml] ARIN Board Statement on the Future of Addressing Policy Message-ID: <002a01c7d483$432067f0$528888c0@arin.net> The American Registry for Internet Numbers Board of Trustees released a statement today that assures ARIN will continue to facilitate the policy development process that defines how Internet Protocol (IP) addresses are distributed in its region, and also reaffirms that ARIN's policies do not encourage profit-driven speculation in IP addresses. The complete statement is included below and is also online at http://www.arin.net/media/200701August_Statement.pdf. On 1 August 2007, the ARIN Board of Trustees issued the following statement: Statement of ARIN's Board of Trustees regarding future Internet address policy in the ARIN region The global Internet requires numeric addresses for the routing of communications traffic. These addresses are necessarily finite in nature and have been defined in two groups. One group, called "Internet Protocol version 4," or IPv4, was defined in 1979 as a pool of approximately 4,300,000,000 addresses.(1)(2) In anticipation of the Internet growing larger than can be accommodated by the IPv4 pool, a second group, called "Internet Protocol version 6," or IPv6, was defined in 1995 as a pool of approximately 340,000,000,000,000,000,000,000,000,000,000,000,000 addresses, an address space billions upon billions of times larger.(3) In accordance with Internet governance principles, IP addresses of both versions are allocated to users by the Regional Internet Registries.(4) Because IP addresses are a finite resource, the allocation process is defined and overseen democratically and transparently by the public. The allocation process seeks to balance two goals: universal access to the Internet, and the stability of the Internet's essential communications function.(5) Because the growth of the Internet is leading to full use of the IPv4 address pool, soon the Regional Internet Registries will no longer have new, previously unassigned IPv4 addresses to allocate to users.(6) Forward-thinking users have already begun the transition to the much more plentiful IPv6 addresses in anticipation of this situation. There are, however, those who propose that the democratically established governance principles now be abandoned, to create a market in IP addresses. A market that abandons these existing, consensus-driven core values would encourage speculators to take advantage of the upcoming time of relative scarcity of IPv4 addresses to profit from less foresightful users' remaining need. The purpose of this memorandum is to assure the community that the democratic principles of Internet governance will be adhered to by ARIN, the Regional Internet Registry serving Canada, many Caribbean and North Atlantic islands, and the United States.(7) The resource-allocation policy under which ARIN operates has been produced through an open, transparent, and democratic process over more than a decade. ARIN is fully dedicated to preserving universal access and stable functionality of the Internet, and our policies do not encourage profit-driven speculation in the Internet addresses. The current resource management mechanism is fully sufficient to address the upcoming shortage of IPv4 addresses, and a continuation of sober and responsible enforcement will ensure continued maximum benefit to and protection of the entire Internet community. ---- (1) Internet Engineering Note 111, Internet Protocol, August 1979, by the University of Southern California Information Sciences Institute. http://www.networksorcery.com/enp/ien/ien111.txt (2) Internet Engineering Task Force Request for Comment number 760, DOD Standard Internet Protocol, January 1980, by the University of Southern California Information Sciences Institute. http://www.ietf.org/rfc/rfc0760.txt (3) Internet Engineering Task Force Request for Comment number 1883, Internet Protocol Version 6 (IPv6) Specification, December 1995, by Steve Deering and Robert Hinden. http://www.ietf.org/rfc/rfc1883.txt (4) Internet Engineering Task Force Request for Comment number 2050, Internet Registry IP Allocation Guidelines, November 1996, by Kim Hubbard, Mark Kosters, David Conrad, Daniel Karrenberg, and Jon Postel. http://www.ietf.org/rfc/rfc2050.txt (5) Internet Engineering Task Force Request for Comment number 2008, Implications of Various Address Allocation Policies for Internet Routing, October 1996, by Yakov Rekhter and Tony Li. http://www.ietf.org/rfc/rfc2008.txt (6) IPv4 Address Report, updated daily, by Geoff Huston. http://www.potaroo.net/tools/ipv4/index.html (7) The countries and territories of ARIN's service region are named at http://www.arin.net/community/ARINcountries.html Regards, Raymond A. Plzak President and CEO American Registry for Internet Numbers (ARIN) From michael.dillon at bt.com Wed Aug 1 18:23:01 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 1 Aug 2007 23:23:01 +0100 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: <63550.1185986123@sa.vix.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com><88234.1185818363@sa.vix.com><0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org><24940.1185829923@sa.vix.com><12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org><71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com><83945.1185848565@sa.vix.com><1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org><93896.1185947387@sa.vix.com><3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com> <63550.1185986123@sa.vix.com> Message-ID: > > 1. The Ruse. Something other than IP addresses is leased but the > > practical affect is to indefinitely lease the IP addresses, > as in my > > MIT message on the list yesterday. > > this is brilliant, by the way. Indeed! I haven't seen such brilliant ideas since Enron. --Michael Dillon From michael.dillon at bt.com Wed Aug 1 18:40:10 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 1 Aug 2007 23:40:10 +0100 Subject: [ppml] alternative realities (was PIv6 for legacy holders(/wRSA + efficient use)) In-Reply-To: References: Message-ID: > I thought this was the IP-address-consuming community. If > this is the ISP community, then I am on the wrong mailing list. This is the open, public policy mailing list for ARIN's policy development. If you want to let ISPs drive ARIN's policy, then you are free to go elsewhere but don't complain when the new policies suit ISPs better than other IP address consumers. If I were you, I would hang around and contribute your point of view. We desperately need more diversity of ideas here, such as the papers which Lucy Lynch posted. The discussion should not be a two-sided debate, but a rambling many-sided discussion that gets us to something that is workable, useful and can be implemented in the short timeframe left for the IPv4 free pool. I'm not sure that we have a clear direction yet on what ARIN can do that is useful and is also clearly a workable solution. --Michael Dillon From paul at vix.com Wed Aug 1 19:20:37 2007 From: paul at vix.com (Paul Vixie) Date: Wed, 01 Aug 2007 23:20:37 +0000 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: Your message of "Wed, 01 Aug 2007 23:23:01 +0100." References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com><88234.1185818363@sa.vix.com><0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org><24940.1185829923@sa.vix.com><12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org><71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com><83945.1185848565@sa.vix.com><1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org><93896.1185947387@sa.vix.com><3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com> <63550.1185986123@sa.vix.com> Message-ID: <58568.1186010437@sa.vix.com> > > > 1. The Ruse. Something other than IP addresses is leased but the > > > practical affect is to indefinitely lease the IP addresses, as in my MIT > > > message on the list yesterday. > > > > this is brilliant, by the way. > > Indeed! I haven't seen such brilliant ideas since Enron. if it's a bad thing, then is there also policy work to be done about it? From sleibrand at internap.com Wed Aug 1 19:30:28 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 01 Aug 2007 16:30:28 -0700 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: <58568.1186010437@sa.vix.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com><88234.1185818363@sa.vix.com><0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org><24940.1185829923@sa.vix.com><12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org><71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com><83945.1185848565@sa.vix.com><1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org><93896.1185947387@sa.vix.com><3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com> <63550.1185986123@sa.vix.com> <58568.1186010437@sa.vix.com> Message-ID: <46B11794.50907@internap.com> Paul Vixie wrote: > > if it's a bad thing, then is there also policy work to be done about it? I'm not sure a hammer is needed here, as I'm not sure this is a nail. Let's say that a legacy /8 holder like MIT decides to start leasing out their IP space to "customers" buying a tunnel, dial-up, or some other similar form of connectivity. Let's say there is sufficient demand for IP space that they sign up a number of customers, each receiving a /24 with their tunnel and announcing it in BGP to their upstreams. Now let's say this kind of behavior causes the routing table to explode. If I'm a DFZ operator who is no longer able to handle all these prefixes, my solution is pretty simple: stop accepting /24's carved up out of /8 allocations. Doing so would cause me to send traffic to MIT's customers via the MIT /8. That in turn would either mean that the traffic would hit MIT's network and then get sent to MIT's customers via their tunnel, or it would hit an intermediate network that was listening to the more-specific /24 announcement from MIT's customers (probably because they're being paid to do so), who would in turn send the traffic along normally. In summary, I'm sure this kind of thing will happen as we exhaust the IPv4 free pool, but I'm not sure it will break things too badly. -Scott From paul at vix.com Wed Aug 1 19:46:26 2007 From: paul at vix.com (Paul Vixie) Date: Wed, 01 Aug 2007 23:46:26 +0000 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: Your message of "Wed, 01 Aug 2007 16:30:28 MST." <46B11794.50907@internap.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com><88234.1185818363@sa.vix.com><0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org><24940.1185829923@sa.vix.com><12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org><71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com><83945.1185848565@sa.vix.com><1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org><93896.1185947387@sa.vix.com><3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com> <63550.1185986123@sa.vix.com> <58568.1186010437@sa.vix.com> <46B11794.50907@internap.com> Message-ID: <60331.1186011986@sa.vix.com> scott wrote, answering my "is there policy work to do?" question: > Let's say that a legacy /8 holder like MIT decides to start leasing out > their IP space to "customers" buying a tunnel, dial-up, or some other > similar form of connectivity. Let's say there is sufficient demand for > IP space that they sign up a number of customers, each receiving a /24 > with their tunnel and announcing it in BGP to their upstreams. Now > let's say this kind of behavior causes the routing table to explode. If > I'm a DFZ operator who is no longer able to handle all these prefixes, > my solution is pretty simple: stop accepting /24's carved up out of /8 > allocations. Doing so would cause me to send traffic to MIT's customers > via the MIT /8. That in turn would either mean that the traffic would > hit MIT's network and then get sent to MIT's customers via their tunnel, > or it would hit an intermediate network that was listening to the > more-specific /24 announcement from MIT's customers (probably because > they're being paid to do so), who would in turn send the traffic along > normally. > > In summary, I'm sure this kind of thing will happen as we exhaust the > IPv4 free pool, but I'm not sure it will break things too badly. i am less sure that this kind of thing will happen in /8-land. the actors are too large and too bright and too visible. in /16-land, where it's much harder for you to tell the players without a scorecard, and where scorecards could be lawsuit magnets, it could be prevalent. if it happens often enough using enough different /16's then you might have trouble figuring out what to filter, especially if it changes every day, and the list gets long. are you prepared to say that this problem will be self-correcting and that the routing system will remain stable under that sort of growth? i'm not. i'm also not sure what to do about it. but someone who thinks it would be bad should try to propose some policy to make it better, i'd like to read that. From jcurran at istaff.org Wed Aug 1 20:02:11 2007 From: jcurran at istaff.org (John Curran) Date: Wed, 1 Aug 2007 20:02:11 -0400 Subject: [ppml] alternative realities In-Reply-To: <60331.1186011986@sa.vix.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com><88234.118581 8363@sa.vix.com><0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org><249 40.1185829923@sa.vix.com><12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized .org><71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com><83945.1185848565@sa.vix.com><1E5A9D35-D086-47BC -A1DD-9BF71577F316@virtualized.org><93896.1185947387@sa.vix.com><3c3e3fca0 708010622s55108197i52ac54957249a1f1@mail.gmail.com> <63550.1185986123@sa.vix.com> <58568.1186010437@sa.vix.com> <46B11794.50907@internap.com> <60331.1186011986@sa.vix.com> Message-ID: At 11:46 PM +0000 8/1/07, Paul Vixie wrote: >scott wrote, answering my "is there policy work to do?" question: > >> Let's say that a legacy /8 holder like MIT decides to start leasing out >> their IP space to "customers" buying a tunnel, dial-up, or some other >> similar form of connectivity. Let's say there is sufficient demand for >> IP space that they sign up a number of customers, each receiving a /24 >> with their tunnel and announcing it in BGP to their upstreams. Now >> let's say this kind of behavior causes the routing table to explode. If >> I'm a DFZ operator who is no longer able to handle all these prefixes, >> my solution is pretty simple: stop accepting /24's carved up out of /8 >> allocations. Doing so would cause me to send traffic to MIT's customers >> via the MIT /8. That in turn would either mean that the traffic would >> hit MIT's network and then get sent to MIT's customers via their tunnel, >> or it would hit an intermediate network that was listening to the >> more-specific /24 announcement from MIT's customers (probably because >> they're being paid to do so), who would in turn send the traffic along >> normally. >> >> In summary, I'm sure this kind of thing will happen as we exhaust the >> IPv4 free pool, but I'm not sure it will break things too badly. > >i am less sure that this kind of thing will happen in /8-land. the actors >are too large and too bright and too visible. in /16-land, where it's much >harder for you to tell the players without a scorecard, and where scorecards >could be lawsuit magnets, it could be prevalent. if it happens often enough >using enough different /16's then you might have trouble figuring out what >to filter, especially if it changes every day, and the list gets long. are >you prepared to say that this problem will be self-correcting and that the >routing system will remain stable under that sort of growth? i'm not. i'm >also not sure what to do about it. but someone who thinks it would be bad >should try to propose some policy to make it better, i'd like to read that. Just to be clear (and speaking purely as Internet denizen), it's quite possible that Big-space-holder will simply claim that they're an ISP with an innovative business plan, and that would be accurate depending on the specific definition of ISP being used. Desirability judgements aside, it seems to be a good assessment of what some network-connected sites would explore as an option... /John From sleibrand at internap.com Wed Aug 1 20:07:39 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 01 Aug 2007 17:07:39 -0700 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: <60331.1186011986@sa.vix.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com><88234.1185818363@sa.vix.com><0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org><24940.1185829923@sa.vix.com><12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org><71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com><83945.1185848565@sa.vix.com><1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org><93896.1185947387@sa.vix.com><3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com> <63550.1185986123@sa.vix.com> <58568.1186010437@sa.vix.com> <46B11794.50907@internap.com> <60331.1186011986@sa.vix.com> Message-ID: <46B1204B.4050707@internap.com> Paul Vixie wrote: > scott wrote, answering my "is there policy work to do?" question: > > >> Let's say that a legacy /8 holder like MIT decides to start leasing out >> their IP space to "customers" buying a tunnel, dial-up, or some other >> similar form of connectivity. Let's say there is sufficient demand for >> IP space that they sign up a number of customers, each receiving a /24 >> with their tunnel and announcing it in BGP to their upstreams. Now >> let's say this kind of behavior causes the routing table to explode. If >> I'm a DFZ operator who is no longer able to handle all these prefixes, >> my solution is pretty simple: stop accepting /24's carved up out of /8 >> allocations. Doing so would cause me to send traffic to MIT's customers >> via the MIT /8. That in turn would either mean that the traffic would >> hit MIT's network and then get sent to MIT's customers via their tunnel, >> or it would hit an intermediate network that was listening to the >> more-specific /24 announcement from MIT's customers (probably because >> they're being paid to do so), who would in turn send the traffic along >> normally. >> >> In summary, I'm sure this kind of thing will happen as we exhaust the >> IPv4 free pool, but I'm not sure it will break things too badly. >> > > i am less sure that this kind of thing will happen in /8-land. the actors > are too large and too bright and too visible. in /16-land, where it's much > harder for you to tell the players without a scorecard, and where scorecards > could be lawsuit magnets, it could be prevalent. if it happens often enough > using enough different /16's then you might have trouble figuring out what > to filter, especially if it changes every day, and the list gets long. are > you prepared to say that this problem will be self-correcting and that the > routing system will remain stable under that sort of growth? i'm not. i'm > also not sure what to do about it. but someone who thinks it would be bad > should try to propose some policy to make it better, i'd like to read that. > If someone can come up with a helpful policy, I'm all ears. But yes, I do think this kind of thing will be self-correcting, for one simple reason: you don't have to know who's doing it to filter effectively. All you need to know is what the minimum allocation size for each address range is. (I know you know all this already, but I'm sure there are others who don't.) A quick look at http://www.iana.org/assignments/ipv4-address-space and http://www.arin.net/reference/ip_blocks.html gives me a pretty good idea that I could filter, more or less safely, anything larger than /8 in the 0/8 to 56/8 range (with a couple exceptions, like down to /20 in 24/8), down to /16 in the 128/8 to 172/8 range, down to /20 in the 63/8 to 99/8 range, etc. If I were to implement such a policy, I'd first take a good hard look at my BGP table (rather than the cursory look I just did), but it's by no means necessary to identify the specific players doing the deaggregation in order to appropriately filter it. If my reading of history is correct (as it was mostly before my time), we've been through something similar before, with a number of players filtering down to minimum allocation size for many years before routers caught back up with the size of the table and the filters became more of a problem (affecting reachability of folks not advertising their aggregate route) than they were worth. But if we see a high level of deaggregation of allocated netblocks (without a change in the underlying IANA or RIR allocation), I suspect we'll see a return of these prefix length filters. -Scott From arin-contact at dirtside.com Wed Aug 1 21:29:55 2007 From: arin-contact at dirtside.com (William Herrin) Date: Wed, 1 Aug 2007 21:29:55 -0400 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <93896.1185947387@sa.vix.com> <3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com> <63550.1185986123@sa.vix.com> Message-ID: <3c3e3fca0708011829p6f1091f3r7f6968c2c2daa85d@mail.gmail.com> On 8/1/07, michael.dillon at bt.com wrote: > > > 1. The Ruse. Something other than IP addresses is leased but the > > this is brilliant, by the way. > > Indeed! I haven't seen such brilliant ideas since Enron. Michael, I won't suggest we all run out and Make Money Fast. And I'm sure a few operators will be happy to slit their own throats by retaliating with prefix filtering, just like in the last table size crisis. More customers for the rest. I will go so far as to suggest that the only chance of avoiding the ruse that's even close to realistic is to beat the v4 bandits to the punch and get IPv6 deployed. Within the context of ARIN public policy, that means exactly two things: 1. Remove policy level obstructions to those seeking IPv6 address space and 2. Make it more difficult to get IPv4 space without deploying IPv6 than it is to deploy IPv6 and get IPv4 space. There are proposals on the table which do both of these things, like "PIv6 for legacy holders (/w RSA + efficient use)" and "IPv4 Soft Landing." I'd vote yes. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From paul at vix.com Wed Aug 1 23:39:51 2007 From: paul at vix.com (Paul Vixie) Date: Thu, 02 Aug 2007 03:39:51 +0000 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: Your message of "Wed, 01 Aug 2007 17:07:39 MST." <46B1204B.4050707@internap.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com><88234.1185818363@sa.vix.com><0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org><24940.1185829923@sa.vix.com><12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org><71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com><83945.1185848565@sa.vix.com><1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org><93896.1185947387@sa.vix.com><3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com> <63550.1185986123@sa.vix.com> <58568.1186010437@sa.vix.com> <46B11794.50907@internap.com> <60331.1186011986@sa.vix.com> <46B1204B.4050707@internap.com> Message-ID: <1248.1186025991@sa.vix.com> > ... yes, I do think this kind of thing will be self-correcting, for one > simple reason: you don't have to know who's doing it to filter effectively. i think you're being overly optimistic. > All you need to know is what the minimum allocation size for each address > range is. (I know you know all this already, but I'm sure there are others > who don't.) A quick look at > http://www.iana.org/assignments/ipv4-address-space and > http://www.arin.net/reference/ip_blocks.html gives me a pretty good idea > that I could filter, more or less safely, anything larger than /8 in the 0/8 > to 56/8 range (with a couple exceptions, like down to /20 in 24/8), down to > /16 in the 128/8 to 172/8 range, down to /20 in the 63/8 to 99/8 range, etc. i don't think it's anywhere near that simple. also, even if you find a way to express it, if others accept these routes and you don't, then your support queue fills up and theirs does not, and perhaps customers leave you and go to them. > If I were to implement such a policy, I'd first take a good hard look at my > BGP table (rather than the cursory look I just did), but it's by no means > necessary to identify the specific players doing the deaggregation in order > to appropriately filter it. ah, the irony. i guess what went around came around? internap used to be one of the worst TE deaggregators. welcome to concern about other folks' deaggregation and global routing table size and shared fate. > If my reading of history is correct (as it was mostly before my time), > we've been through something similar before, with a number of players > filtering down to minimum allocation size for many years before routers > caught back up with the size of the table and the filters became more of > a problem (affecting reachability of folks not advertising their > aggregate route) than they were worth. But if we see a high level of > deaggregation of allocated netblocks (without a change in the underlying > IANA or RIR allocation), I suspect we'll see a return of these prefix > length filters. they'll return, but relaxing them for one's customers will be common, and relaxing them for peers in exchange for reflexive relaxation from peers will be common. recurring revenue is king. "unfiltered" will be a competitive advantage. you cannot count on others doing the right thing for the internet (or else i'd be able to count on you to deploy V6 right now as an incentive to get others to do likewise since they could reach internap even on V6.) ps. i am not speaking as an arin trustee in this message. From sleibrand at internap.com Thu Aug 2 00:29:47 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 01 Aug 2007 21:29:47 -0700 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: <1248.1186025991@sa.vix.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com><88234.1185818363@sa.vix.com><0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org><24940.1185829923@sa.vix.com><12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org><71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com><83945.1185848565@sa.vix.com><1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org><93896.1185947387@sa.vix.com><3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com> <63550.1185986123@sa.vix.com> <58568.1186010437@sa.vix.com> <46B11794.50907@internap.com> <60331.1186011986@sa.vix.com> <46B1204B.4050707@internap.com> <1248.1186025991@sa.vix.com> Message-ID: <46B15DBB.5060604@internap.com> Yes, TE deaggregation is worth money, and yes, transit customers will pay their transit providers to accept such deaggregates, just as Internap's customers did, and Internap in turn did. (Remember, Internap bought transit from most tier 1 providers, and payed money to filterers like Verio to accept Internap's deaggregates.) I'm not talking here about rejecting more-specifics from one's own customers: that is just dumb. What I'm talking about, instead, is filtering "distant" more-specifics: those outside their sphere of usefulness. (as-pathlimit would be a quite useful way to do this.) I agree with you that an "unfiltered" BGP feed will be a competitive advantage, and will command a price premium. That price premium will be required to fund the beefier routers required to continue handling a full, unfiltered table. At the same time, however, lower-cost providers will be free to choose to filter their BGP tables, saving money on routers, and passing those savings on to their customers. They can also, if they wish, buy transit and point default at someone who doesn't filter, as a catch-all to ensure reachability to more-specific prefixes not covered by an announced aggregate. This (filtering the fragmenting IPv4 routing table) won't be about "the good of the Internet": it'll be about business. Some ISPs will choose the high-end market, and buy 2M or 10M route routers to handle the fragmentation. Some ISPs will choose to filter some routes, but accept most and use a default to ensure full reachability. Others may choose to filter aggressively and accept some collateral unreachability. The key here is that we must choose, among our alternate realities, one that preserves freedom of choice. If we choose the future of APNIC prop-050: IPv4 address transfers, we eliminate the choice to filter deaggregation, and leave ourselves with no choice but to keep up with an exploding route table or withdraw from the DFZ. -Scott Paul Vixie wrote: >> ... yes, I do think this kind of thing will be self-correcting, for one >> simple reason: you don't have to know who's doing it to filter effectively. >> > > i think you're being overly optimistic. > > >> All you need to know is what the minimum allocation size for each address >> range is. (I know you know all this already, but I'm sure there are others >> who don't.) A quick look at >> http://www.iana.org/assignments/ipv4-address-space and >> http://www.arin.net/reference/ip_blocks.html gives me a pretty good idea >> that I could filter, more or less safely, anything larger than /8 in the 0/8 >> to 56/8 range (with a couple exceptions, like down to /20 in 24/8), down to >> /16 in the 128/8 to 172/8 range, down to /20 in the 63/8 to 99/8 range, etc. >> > > i don't think it's anywhere near that simple. also, even if you find a way > to express it, if others accept these routes and you don't, then your support > queue fills up and theirs does not, and perhaps customers leave you and go to > them. > > >> If I were to implement such a policy, I'd first take a good hard look at my >> BGP table (rather than the cursory look I just did), but it's by no means >> necessary to identify the specific players doing the deaggregation in order >> to appropriately filter it. >> > > ah, the irony. i guess what went around came around? internap used to be one > of the worst TE deaggregators. welcome to concern about other folks' > deaggregation and global routing table size and shared fate. > > >> If my reading of history is correct (as it was mostly before my time), >> we've been through something similar before, with a number of players >> filtering down to minimum allocation size for many years before routers >> caught back up with the size of the table and the filters became more of >> a problem (affecting reachability of folks not advertising their >> aggregate route) than they were worth. But if we see a high level of >> deaggregation of allocated netblocks (without a change in the underlying >> IANA or RIR allocation), I suspect we'll see a return of these prefix >> length filters. >> > > they'll return, but relaxing them for one's customers will be common, and > relaxing them for peers in exchange for reflexive relaxation from peers will > be common. recurring revenue is king. "unfiltered" will be a competitive > advantage. you cannot count on others doing the right thing for the internet > (or else i'd be able to count on you to deploy V6 right now as an incentive > to get others to do likewise since they could reach internap even on V6.) > > ps. i am not speaking as an arin trustee in this message. > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From michel at arneill-py.sacramento.ca.us Thu Aug 2 00:55:18 2007 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 1 Aug 2007 21:55:18 -0700 Subject: [ppml] alternative realities In-Reply-To: <1248.1186025991@sa.vix.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com><88234.1185818363@sa.vix.com><0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org><24940.1185829923@sa.vix.com><12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org><71643.1185845108@sa.vix.com><46AE90C6.8060406@psg.com><83945.1185848565@sa.vix.com><1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org><93896.1185947387@sa.vix.com><3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com><63550.1185986123@sa.vix.com><58568.1186010437@sa.vix.com> <46B11794.50907@internap.com><60331.1186011986@sa.vix.com> <46B1204B.4050707@internap.com> <1248.1186025991@sa.vix.com> Message-ID: Talking about alternative realities, there's one already here that I did not suspect it was: double-NAT. I'm not talking about China, I'm talking about mainland USA. Here's the story: I volunteered to provide WiFi Internet access to a site-in-the-middle-of-nowhere for 3 days. For free, of course. I decided that what I could do for the money would be to share my 3G phone. So I grab another laptop (not mine, heaven forbid), connect the phone to one of the USB ports and a $35 Belkin WiFi "router" (bought at the closest Staples) to the Ethernet port, and share the connection by checking the appropriate box in M$ windblows XP's config. My laptop becomes a DHCP server and a NAT box. The only other configuration required is to disable DHCP on the Belkin and assign a static IP (192.168.0.2) to it, also configure a password, there will be teens using it. Half-surprise #1: the IP address I get from the 3G phone is a 10.net. Darn, the el-cheapo unlimited plan does not entitle one to a real IP address. Half-surprise #2: it works just fine. It's built into XP, it takes 30 seconds to configure. It's powered by a 12-volt inverter off the car's battery. It's double-NAT: my laptop (the DHCP server) hands out IP addresses out of 192.168.0.0/24. No, people using it can't host their web site on it, which I don't want them to in the first place. However, people drive in, power up their laptop, see only one ESSID (remember, we're in the middle of nowhere), and connect to it just fine. They can check their email, look at their stock portfolio, and email the digital picture of their progeniture to grandma. Someone explains me again why I should spend money to upgrade to IPv6? I.S.D.N: I Still Don't Need. Michel. From paul at vix.com Thu Aug 2 02:15:46 2007 From: paul at vix.com (Paul Vixie) Date: Thu, 02 Aug 2007 06:15:46 +0000 Subject: [ppml] alternative realities In-Reply-To: Your message of "Wed, 01 Aug 2007 21:55:18 MST." References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com><88234.1185818363@sa.vix.com><0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org><24940.1185829923@sa.vix.com><12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org><71643.1185845108@sa.vix.com><46AE90C6.8060406@psg.com><83945.1185848565@sa.vix.com><1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org><93896.1185947387@sa.vix.com><3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com><63550.1185986123@sa.vix.com><58568.1186010437@sa.vix.com> <46B11794.50907@internap.com><60331.1186011986@sa.vix.com> <46B1204B.4050707@internap.com> <1248.1186025991@sa.vix.com> Message-ID: <29320.1186035346@sa.vix.com> > Someone explains me again why I should spend money to upgrade to IPv6? as an individual, you might not need it yet. 3G phones and all. double NAT. (cool stuff, but is it art? is it impressive enough for the Maker Faire?) the connectivity community of which you are a part needs IPv6, though. if you're only adding endstations to the IPv4 internet and you don't need SIP to work or are prepared to fiddle endlessly with proxies, you'll be just fine. but if someone somewhere wants to add 20M 3G handsets, they can't use RFC 1918 or any other part of IPv4. if you want the connectivity community of which you are a part to continue to grow, you need to be part of the IPv6 wave. From kkargel at polartel.com Thu Aug 2 09:37:53 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 2 Aug 2007 08:37:53 -0500 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: <46B1204B.4050707@internap.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com><88234.1185818363@sa.vix.com><0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org><24940.1185829923@sa.vix.com><12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org><71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com><83945.1185848565@sa.vix.com><1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org><93896.1185947387@sa.vix.com><3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com> <63550.1185986123@sa.vix.com> <58568.1186010437@sa.vix.com><46B11794.50907@internap.com> <60331.1186011986@sa.vix.com> <46B1204B.4050707@internap.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066707226@mail> On the topic of prefix filtering, don't forget that it will happen for reasons other than being mean to deagregators. As a case in point currently the US Federal Government is forcing all ISP's to run some sort of CALEA intercept program. For many ISP's the best place to run this is within the IOS on their routers. The problem turns up that in many routers there is not enough memory to run both the CALEA software and a full BGP table. One method of dealing with this is for the ISP to implement prefix filters to limit the size of the BGP table and free up memory to allow the router to run the mandated CALEA. Granted there are other ways to reduce the BGP table, but prefix filtering is perhaps the easiest, requiring just three lines of code in the router config and very little thought. /16 or maybe /19 are pretty natural points to set a filter at. Filtering to /16 will reduce a BGP table from over 200K routes to under 2K routes. Anyway, my point is that deaggregated routes will likely be hurt just because some admins take other actions to make their networks more efficient, with no thought to restricting networks for any purpose. I'm not saying this is good or a good way to do things, just that it will happen. Kevin :$s/worry/happy/g > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Scott Leibrand > Sent: Wednesday, August 01, 2007 7:08 PM > To: Paul Vixie > Cc: ppml at arin.net > Subject: Re: [ppml] alternative realities (was PIv6 for > legacy holders (/wRSA + efficient use)) > > Paul Vixie wrote: > > scott wrote, answering my "is there policy work to do?" question: > > > > > >> Let's say that a legacy /8 holder like MIT decides to > start leasing > >> out their IP space to "customers" buying a tunnel, > dial-up, or some > >> other similar form of connectivity. Let's say there is sufficient > >> demand for IP space that they sign up a number of customers, each > >> receiving a /24 with their tunnel and announcing it in BGP > to their > >> upstreams. Now let's say this kind of behavior causes the routing > >> table to explode. If I'm a DFZ operator who is no longer able to > >> handle all these prefixes, my solution is pretty simple: stop > >> accepting /24's carved up out of /8 allocations. Doing so would > >> cause me to send traffic to MIT's customers via the MIT > /8. That in > >> turn would either mean that the traffic would hit MIT's > network and > >> then get sent to MIT's customers via their tunnel, or it > would hit an > >> intermediate network that was listening to the more-specific /24 > >> announcement from MIT's customers (probably because they're being > >> paid to do so), who would in turn send the traffic along normally. > >> > >> In summary, I'm sure this kind of thing will happen as we > exhaust the > >> IPv4 free pool, but I'm not sure it will break things too badly. > >> > > > > i am less sure that this kind of thing will happen in /8-land. the > > actors are too large and too bright and too visible. in /16-land, > > where it's much harder for you to tell the players without a > > scorecard, and where scorecards could be lawsuit magnets, > it could be > > prevalent. if it happens often enough using enough different /16's > > then you might have trouble figuring out what to filter, > especially if > > it changes every day, and the list gets long. are you > prepared to say > > that this problem will be self-correcting and that the > routing system > > will remain stable under that sort of growth? i'm not. > i'm also not > > sure what to do about it. but someone who thinks it would > be bad should try to propose some policy to make it better, > i'd like to read that. > > > > If someone can come up with a helpful policy, I'm all ears. > But yes, I do think this kind of thing will be > self-correcting, for one simple > reason: you don't have to know who's doing it to filter effectively. > All you need to know is what the minimum allocation size for > each address range is. (I know you know all this already, > but I'm sure there are others who don't.) A quick look at > http://www.iana.org/assignments/ipv4-address-space and > http://www.arin.net/reference/ip_blocks.html gives me a > pretty good idea that I could filter, more or less safely, > anything larger than /8 in the > 0/8 to 56/8 range (with a couple exceptions, like down to /20 > in 24/8), down to /16 in the 128/8 to 172/8 range, down to > /20 in the 63/8 to 99/8 range, etc. If I were to implement > such a policy, I'd first take a good hard look at my BGP > table (rather than the cursory look I just did), but it's by > no means necessary to identify the specific players doing the > deaggregation in order to appropriately filter it. > > If my reading of history is correct (as it was mostly before > my time), we've been through something similar before, with a > number of players filtering down to minimum allocation size > for many years before routers caught back up with the size of > the table and the filters became more of a problem (affecting > reachability of folks not advertising their aggregate route) > than they were worth. But if we see a high level of > deaggregation of allocated netblocks (without a change in the > underlying IANA or RIR allocation), I suspect we'll see a > return of these prefix length filters. > > -Scott > _______________________________________________ > This message sent to you through the ARIN Public Policy > Mailing List (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From spetty at iconnect-corp.com Thu Aug 2 11:41:20 2007 From: spetty at iconnect-corp.com (Steven E. Petty) Date: Thu, 2 Aug 2007 11:41:20 -0400 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) Message-ID: <428E6440939F654F8BD72C49361E855FF35DF5@suzie.iconnect-corp.com> I'm not certain your assumptions are valid. I know my workplace is currently multihomed using a /24 assigned from cogent in the 38. This filter would remove my routes. Under current ARIN policies, our two dozen or so hosts don't qualify us for a direct assignment/allocation despite multi-homing. Steve -----Original Message----- From: Scott Leibrand [mailto:sleibrand at internap.com] Sent: Wednesday, August 01, 2007 8:08 PM To: Paul Vixie Cc: ppml at arin.net Subject: Re: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) If someone can come up with a helpful policy, I'm all ears. But yes, I do think this kind of thing will be self-correcting, for one simple reason: you don't have to know who's doing it to filter effectively. All you need to know is what the minimum allocation size for each address range is. (I know you know all this already, but I'm sure there are others who don't.) A quick look at http://www.iana.org/assignments/ipv4-address-space and http://www.arin.net/reference/ip_blocks.html gives me a pretty good idea that I could filter, more or less safely, anything larger than /8 in the 0/8 to 56/8 range (with a couple exceptions, like down to /20 in 24/8), down to /16 in the 128/8 to 172/8 range, down to /20 in the 63/8 to 99/8 range, etc. If I were to implement such a policy, I'd first take a good hard look at my BGP table (rather than the cursory look I just did), but it's by no means necessary to identify the specific players doing the deaggregation in order to appropriately filter it. -Scott _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From sleibrand at internap.com Thu Aug 2 12:06:43 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 02 Aug 2007 09:06:43 -0700 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: <428E6440939F654F8BD72C49361E855FF35DF5@suzie.iconnect-corp.com> References: <428E6440939F654F8BD72C49361E855FF35DF5@suzie.iconnect-corp.com> Message-ID: <46B20113.9090907@internap.com> Steven, Does Cogent have a route to your /24? Do they announce a covering aggregate? If so, then you will retain reachability even to networks who filter your /24, via Cogent's aggregate.. -Scott Steven E. Petty wrote: > I'm not certain your assumptions are valid. I know my workplace is > currently multihomed using a /24 assigned from cogent in the 38. This > filter would remove my routes. Under current ARIN policies, our two > dozen or so hosts don't qualify us for a direct assignment/allocation > despite multi-homing. > > Steve > > -----Original Message----- > From: Scott Leibrand [mailto:sleibrand at internap.com] > Sent: Wednesday, August 01, 2007 8:08 PM > To: Paul Vixie > Cc: ppml at arin.net > Subject: Re: [ppml] alternative realities (was PIv6 for legacy holders > (/wRSA + efficient use)) > > > > If someone can come up with a helpful policy, I'm all ears. But yes, I > do think this kind of thing will be self-correcting, for one simple > reason: you don't have to know who's doing it to filter effectively. > All you need to know is what the minimum allocation size for each > address range is. (I know you know all this already, but I'm sure there > are others who don't.) A quick look at > http://www.iana.org/assignments/ipv4-address-space and > http://www.arin.net/reference/ip_blocks.html gives me a pretty good idea > that I could filter, more or less safely, anything larger than /8 in the > 0/8 to 56/8 range (with a couple exceptions, like down to /20 in 24/8), > down to /16 in the 128/8 to 172/8 range, down to /20 in the 63/8 to 99/8 > range, etc. If I were to implement such a policy, I'd first take a good > hard look at my BGP table (rather than the cursory look I just did), but > it's by no means necessary to identify the specific players doing the > deaggregation in order to appropriately filter it. > > > > -Scott > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From peter at boku.net Thu Aug 2 12:20:18 2007 From: peter at boku.net (Peter Eisch) Date: Thu, 02 Aug 2007 11:20:18 -0500 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: <46B20113.9090907@internap.com> Message-ID: ...or you'll be black-holed if your Cogent line is down while your other ISP's circuit is alive and kicking. Multi-homing in that reality becomes hit and miss. It's not worth paying any fees to the second ISP if anyone who wants to reach you is sitting behind a filtering ISP. The funny part is that they lose you as a customer based on policy enacted by a non-related entity. peter On 8/2/07 11:06 AM, "Scott Leibrand" wrote: > Steven, > > Does Cogent have a route to your /24? Do they announce a covering > aggregate? If so, then you will retain reachability even to networks > who filter your /24, via Cogent's aggregate.. > > -Scott > > Steven E. Petty wrote: >> I'm not certain your assumptions are valid. I know my workplace is >> currently multihomed using a /24 assigned from cogent in the 38. This >> filter would remove my routes. Under current ARIN policies, our two >> dozen or so hosts don't qualify us for a direct assignment/allocation >> despite multi-homing. >> >> Steve >> >> -----Original Message----- >> From: Scott Leibrand [mailto:sleibrand at internap.com] >> Sent: Wednesday, August 01, 2007 8:08 PM >> To: Paul Vixie >> Cc: ppml at arin.net >> Subject: Re: [ppml] alternative realities (was PIv6 for legacy holders >> (/wRSA + efficient use)) >> >> >> >> If someone can come up with a helpful policy, I'm all ears. But yes, I >> do think this kind of thing will be self-correcting, for one simple >> reason: you don't have to know who's doing it to filter effectively. >> All you need to know is what the minimum allocation size for each >> address range is. (I know you know all this already, but I'm sure there >> are others who don't.) A quick look at >> http://www.iana.org/assignments/ipv4-address-space and >> http://www.arin.net/reference/ip_blocks.html gives me a pretty good idea >> that I could filter, more or less safely, anything larger than /8 in the >> 0/8 to 56/8 range (with a couple exceptions, like down to /20 in 24/8), >> down to /16 in the 128/8 to 172/8 range, down to /20 in the 63/8 to 99/8 >> range, etc. If I were to implement such a policy, I'd first take a good >> hard look at my BGP table (rather than the cursory look I just did), but >> it's by no means necessary to identify the specific players doing the >> deaggregation in order to appropriately filter it. >> >> >> >> -Scott >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml >> > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From arin-contact at dirtside.com Thu Aug 2 13:01:13 2007 From: arin-contact at dirtside.com (William Herrin) Date: Thu, 2 Aug 2007 13:01:13 -0400 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: References: <46B20113.9090907@internap.com> Message-ID: <3c3e3fca0708021001v4f504128r88a9afac71db9741@mail.gmail.com> On 8/2/07, Peter Eisch wrote: > Multi-homing in that reality becomes hit and miss. It's not worth paying > any fees to the second ISP if anyone who wants to reach you is sitting > behind a filtering ISP. The funny part is that they lose you as a customer > based on policy enacted by a non-related entity. Peter, That's only true if a sufficiently high percentage of the ASes filter the route. If only a few ISPs filter the route then their customers suffer at least as much as you do. That can be a real problem for the filtering ISP if you have interesting content and the ISP's business model happens to be predicated on hyper-optimized routing with a strong SLA. Prefix filtering by a network operator weakens his ability to reach others on the Internet at the same time that it weakens yours. In fact, it weakens him more than you: your access is only obstucted to one entity. His is obstructed to many. That's a weakness his competitors can exploit. Now you know why most of us stopped filtering to prefixes shorter than /24 the last time we tried it. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From paul at vix.com Thu Aug 2 13:12:37 2007 From: paul at vix.com (Paul Vixie) Date: Thu, 02 Aug 2007 17:12:37 +0000 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: Your message of "Thu, 02 Aug 2007 13:01:13 -0400." <3c3e3fca0708021001v4f504128r88a9afac71db9741@mail.gmail.com> References: <46B20113.9090907@internap.com> <3c3e3fca0708021001v4f504128r88a9afac71db9741@mail.gmail.com> Message-ID: <85118.1186074757@sa.vix.com> prefix filtering will be the first refuge for some, the last refuge for many, as the routing table continues to grow. even if new routers can handle ~2mR and even if global BGP could ever converge with that many churning routes, we will always be a community of both people who can afford new routers and people who cannot. as john curran said, the more or less slow organic growth of the routing table is something the community knows how to adjust to, but a sudden step might look an awful lot like collapse to a lot of people. multihoming using somebody else's address space ("cutouts") is suboptimal in its path selection and fallback, and doesn't really save a route globally since most folks will carry it, but it does offer other folks a cheap kill when they're looking for some way to save memory in their own non-new routers. the idea that prefix filtering would affect cutouts and subdividers but not TE is entirely new to me. i thought it was all going to go to hell in the same handbasket, since distant people wouldn't be able to tell the difference even if it mattered to them which it won't. randy, are your "grazing the commons" slides online somewhere, and if so can you post the URL here? i think a lot of folks weren't in the field last time you made the rounds with these. From cliffb at cjbsys.bdb.com Thu Aug 2 13:37:22 2007 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Thu, 02 Aug 2007 13:37:22 -0400 Subject: [ppml] alternative realities (was PIv6 for legacy, holders (/wRSA + efficient use)) Message-ID: <46B21652.3040904@cjbsys.bdb.com> With regards to MIT and or/other /8s that are "privately held", is the internet better off getting those turned in and split up which adds to the routing table or letting the private holder become a default ISP/mini IANA/ARIN in effect with a /8 aggregated address and keep the table smaller? I realize that's not in keeping with current policy but would it make sense (other than to grow MIT's endowment fund)? I would think other companies who got legacy /8s would be even more inclined to go this route since ARIN's control of the address space would certainly be in question. If the number of $65M is anywhere near correct, a company would be well advised to start thinking about this and get the lawyers up to speed. Cliff From sleibrand at internap.com Thu Aug 2 13:57:59 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 02 Aug 2007 10:57:59 -0700 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: References: Message-ID: <46B21B27.8000106@internap.com> Peter Eisch wrote: > ...or you'll be black-holed if your Cogent line is down while your other > ISP's circuit is alive and kicking. > Not if Cogent accepts your /24 from your other ISP. And if you pay them to, I'm sure they will. > Multi-homing in that reality becomes hit and miss. It's not worth paying > any fees to the second ISP if anyone who wants to reach you is sitting > behind a filtering ISP. The funny part is that they lose you as a customer > based on policy enacted by a non-related entity. > Yes, I realize that multihoming is "easier" and "better" without filtering, which is why no one filters any longer. However, I did troubleshoot the problems that occurred back when Verio filtered, and while it's better to no longer have to do so, it wasn't an insurmountable problem to deal with, either. Going forward, I don't think tier 1 NSPs are going to choose to filter each other's routes aggressively, unless the deaggregation gets really bad. However, I do think that a large spike in deaggregation due to IPv4 free pool exhaustion will prompt a new look at route filtering policies. I suspect a number of networks will discover they can safely filter distant deaggregates, and tools like as-pathlimit will be deployed to assist in this. We may even see router vendors deploying BGP stacks that can automatically filter out unnecessary deaggregates (such as those whose next-hop is identical to a covering BGP route, and whose local-pref is equal or lower and as-path is equal or longer). I wouldn't advocate turning on such features toward your customers, but I could definitely see people deploying it on routes received from their transit providers. Whatever alternate reality we end up with, I think we can trust network operators to do what's in their best interest, and to find a way to effectively deal with IPv4 deaggregation, as long as we don't completely abandon aggregation and hierarchical allocation. -Scott > On 8/2/07 11:06 AM, "Scott Leibrand" wrote: > > >> Steven, >> >> Does Cogent have a route to your /24? Do they announce a covering >> aggregate? If so, then you will retain reachability even to networks >> who filter your /24, via Cogent's aggregate.. >> >> -Scott >> >> Steven E. Petty wrote: >> >>> I'm not certain your assumptions are valid. I know my workplace is >>> currently multihomed using a /24 assigned from cogent in the 38. This >>> filter would remove my routes. Under current ARIN policies, our two >>> dozen or so hosts don't qualify us for a direct assignment/allocation >>> despite multi-homing. >>> >>> Steve >>> >>> From info at arin.net Thu Aug 2 14:01:30 2007 From: info at arin.net (Member Services) Date: Thu, 02 Aug 2007 14:01:30 -0400 Subject: [ppml] Policy Proposal: Definition of known ISP and changes to IPv6 initial allocation criteria In-Reply-To: <46AE170F.6010901@arin.net> References: <46AE170F.6010901@arin.net> Message-ID: <46B21BFA.2050009@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 Alec Peterson. 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: Definition of known ISP and changes to IPv6 > initial allocation criteria > > Author: Kevin Loch > > Proposal Version: 1 > > Submission Date: 2007-07-27 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add the following section 6.2.10: > > 6.2.10 Existing ISP > > An existing ISP is an organization which meets the following > criteria: > > 1. Has IPv4 or IPv6 address space directly allocated > by ARIN; or > 2. Has at least a total of an IPv4 /23 or an IPv6 /44 of address > space reallocated to them via SWIP by one or more upstream > ISPs. > > Address space directly assigned from ARIN or reassigned from > upstream ISPs does not count towards these requirements. > > Replace 6.5.1.1 (d) with the following text: > > d. be an existing ISP in the ARIN region or have a plan for > making assignments to at least 200 separate organizations > within five years. > > Rationale: > > This policy proposal would change two things in the IPv6 > Initial allocation criteria. It adds a definition for > "known ISP" and changes "200 /48 assignments" to > 200 assignments of any size, but to separate organizations. > > Existing ISP: > > The term "existing, known ISP" in the IPv6 ISP qualification > section is too vague and does not give ARIN staff sufficient > guidance for evaluating qualifications. This text defines > "existing, ISP" in a precise manner and removes the unnecessary > and ambiguous word "known". > > It has come to the author's attention that several organizations > have been refused IPv6 ISP allocations because they were not > considered an existing, known ISP. At least one of these > organizations has a /18 worth of IPv4 space reallocated to them > by various upstream ISPs and over 200 IPv4 customers. An > organization's choice to use provider addresses does not > have any affect on whether or not they are in fact an ISP. > > Address space that has been reallocated (not reassigned) > is a good indicato of an ISP as those SWIP templates > are only supposed to be used for downstream ISPs. > > The IPv4 /23 value was selected to match the utilization > requirement for the smallest direct IPv4 allocation from ARIN > under current policy. > > The IPv6 /44 value was selected to represent a number > of downstream customers comparable to the IPv4 requirements. > > > Updates to IPv6 initial allocation criteria: > > Section 6.5.4.1 recommends /56 assignments in some cases and > /48 assignments in others. The Initial allocation criteria > should reflect the flexibility of these recommendations. > An ISP should not have to provide an inefficient address > plan on their application even though they expect to have > over 200 IPv6 customers. > > Timetable for implementation: Immediate > > > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From paul at vix.com Thu Aug 2 14:12:01 2007 From: paul at vix.com (Paul Vixie) Date: Thu, 02 Aug 2007 18:12:01 +0000 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: Your message of "Thu, 02 Aug 2007 10:57:59 MST." <46B21B27.8000106@internap.com> References: <46B21B27.8000106@internap.com> Message-ID: <99813.1186078321@sa.vix.com> > Whatever alternate reality we end up with, I think we can trust network > operators to do what's in their best interest, and to find a way to > effectively deal with IPv4 deaggregation, as long as we don't completely > abandon aggregation and hierarchical allocation. > > -Scott the use of the word "we" above intrigues me. what natural predator will keep the deaggregation animal from overrunning our habitat? filtering will be like a broad spectrum poison, killing a little bit of everything. who is this "we" that you think is going to do the right thing when all of the wrong things are being done distantly from "us"? paul ps. not speaking as an arin trustee. From sleibrand at internap.com Thu Aug 2 14:38:03 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 02 Aug 2007 11:38:03 -0700 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: <99813.1186078321@sa.vix.com> References: <46B21B27.8000106@internap.com> <99813.1186078321@sa.vix.com> Message-ID: <46B2248B.4010506@internap.com> Paul Vixie wrote: >> Whatever alternate reality we end up with, I think we can trust network >> operators to do what's in their best interest, and to find a way to >> effectively deal with IPv4 deaggregation, as long as we don't completely >> abandon aggregation and hierarchical allocation. >> >> -Scott >> > > the use of the word "we" above intrigues me. what natural predator will > keep the deaggregation animal from overrunning our habitat? filtering > will be like a broad spectrum poison, killing a little bit of everything. > who is this "we" that you think is going to do the right thing when all > of the wrong things are being done distantly from "us"? > I'm optimistic that the Internet will survive this round of accelerated routing table growth (after IPv4 free pool exhaustion), as it did the last one (during the bubble). It won't happen without effort, or without pain, but it won't kill us, either. I'm also optimistic that we've learned some lessons from the last round of deaggregation, and will have narrow-spectrum therapies (like as-pathlimit) to treat the next round. For example, there's no particular reason that a North American network needs to hear all the /24 deaggregates from Asia and Europe if they're covered by larger aggregates, and vice versa. It's not really a case that "they" are doing bad things, and "we" are doing everything right. Rather, deaggregation is something that is very useful locally, and not so useful further away, so if filtering becomes necessary, it would be appropriate for everyone to filter distantly-originated deaggregates, and continue listening to locally-originated ones. -Scott From Lee.Howard at stanleyassociates.com Thu Aug 2 15:11:17 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 2 Aug 2007 15:11:17 -0400 Subject: [ppml] alternative realities (was PIv6 for legacy, holders (/wRSA + efficient use)) In-Reply-To: <46B21652.3040904@cjbsys.bdb.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4068FDAD2@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Cliff Bedore > Sent: Thursday, August 02, 2007 1:37 PM > To: PPML > Subject: Re: [ppml] alternative realities (was PIv6 for > legacy, holders (/wRSA + efficient use)) > > With regards to MIT and or/other /8s that are "privately > held", is the internet better off getting those turned in and > split up which adds to the routing table or letting the > private holder become a default ISP/mini IANA/ARIN in effect > with a /8 aggregated address and keep the table smaller? I think the Internet is better of with ARIN allocating based on need than it would be with other organizations allocating based on cash. You asked the question--what do you think? > Cliff Lee From drc at virtualized.org Thu Aug 2 16:43:30 2007 From: drc at virtualized.org (David Conrad) Date: Thu, 2 Aug 2007 13:43:30 -0700 Subject: [ppml] alternative realities (was PIv6 for legacy, holders (/wRSA + efficient use)) In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4068FDAD2@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB4068FDAD2@CL-S-EX-1.stanleyassociates.com> Message-ID: <5784C83A-3726-4AFE-AA05-E4FF7557C608@virtualized.org> [My one post to PPML today, forgive me if this is deemed repetitive or "undemocratic"] Lee, Of course, that's not really the question (since the answer is obvious). If you posit the unlikely universe in which IPv6 isn't deployed when the IPv4 free pool runs dry, which option would be best for ISPs: a) telling new customers to go away or b) obtaining address space via "non-traditional" means from one of the holders of the "legacy" O(100) /8s? As a former large ISP employee, which do you think you'd be encouraged by your former bosses to choose? I guess I'm skeptical that those holders of the "legacy" O(100) /8s will voluntarily return their unused address space to ARIN (or other appropriate RIR) out of "enlightened self-interest". As such, those holders of the "legacy" O(100) /8s will need to be incented to renumber and/or part with "their" address space. How do you think that can realistically be done? Rgds, -drc On Aug 2, 2007, at 12:11 PM, Howard, W. Lee wrote: >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >> Behalf Of Cliff Bedore >> Sent: Thursday, August 02, 2007 1:37 PM >> To: PPML >> Subject: Re: [ppml] alternative realities (was PIv6 for >> legacy, holders (/wRSA + efficient use)) >> >> With regards to MIT and or/other /8s that are "privately >> held", is the internet better off getting those turned in and >> split up which adds to the routing table or letting the >> private holder become a default ISP/mini IANA/ARIN in effect >> with a /8 aggregated address and keep the table smaller? > > I think the Internet is better of with ARIN allocating based on > need than it would be with other organizations allocating based > on cash. > > You asked the question--what do you think? > >> Cliff > > > Lee > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > > From Lee.Howard at stanleyassociates.com Thu Aug 2 17:29:05 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 2 Aug 2007 17:29:05 -0400 Subject: [ppml] alternative realities (was PIv6 for legacy, holders (/wRSA + efficient use)) In-Reply-To: <5784C83A-3726-4AFE-AA05-E4FF7557C608@virtualized.org> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB406980FAA@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: David Conrad [mailto:drc at virtualized.org] > Sent: Thursday, August 02, 2007 4:44 PM > To: Howard, W. Lee > Cc: PPML > Subject: Re: [ppml] alternative realities (was PIv6 for > legacy, holders (/wRSA + efficient use)) > > [My one post to PPML today, forgive me if this is deemed > repetitive or "undemocratic"] I'm honored. > If you posit the unlikely universe in which IPv6 isn't > deployed when the IPv4 free pool runs dry, which option would > be best for ISPs: > > a) telling new customers to go away > b) obtaining address space via "non-traditional" means from > one of the holders of the "legacy" O(100) /8s? c) assign IPv6 space and provide a transition mechanism. d) put them behind NAT. e) give them a smaller assignment than they could previously have justified and help them use it well. I'm going out on a limb and say that the consensus is that a market would be some degree of ungood. If so, then maybe there are ways to prevent it, stall it, or make is less ungood. Stalling long enough is equivalent to preventing. There's a Soft Landing proposal that attempts to fill the gap, and several others. Combined with "How can we prevent/stall/mitigate?" should be "How can we reduce demand for IPv4 addresses?" These are not rhetorical: all are invited to respond. > I guess I'm skeptical that those holders of the "legacy" > O(100) /8s will voluntarily return their unused address space > to ARIN (or other appropriate RIR) out of "enlightened > self-interest". I'm not sure we've asked them what it would take to get them to use address space more efficiently and return the rest. Um, "Hey, legacy holders! What would it take to get you to use address space really conservatively and give the rest back?" I have been much more opinionated here than I usually am. I want to be very clear that I can't say what other Board members think, and I'm always open to changing my mind. This message, and this disclaimer, are terser than the first draft. Lee > Rgds, > -drc > > On Aug 2, 2007, at 12:11 PM, Howard, W. Lee wrote: > > >> -----Original Message----- > >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] > On Behalf > >> Of Cliff Bedore > >> Sent: Thursday, August 02, 2007 1:37 PM > >> To: PPML > >> Subject: Re: [ppml] alternative realities (was PIv6 for legacy, > >> holders (/wRSA + efficient use)) > >> > >> With regards to MIT and or/other /8s that are "privately held", is > >> the internet better off getting those turned in and split up which > >> adds to the routing table or letting the private holder become a > >> default ISP/mini IANA/ARIN in effect with a /8 aggregated > address and > >> keep the table smaller? > > > > I think the Internet is better of with ARIN allocating > based on need > > than it would be with other organizations allocating based on cash. > > > > You asked the question--what do you think? > > > >> Cliff > > > > > > Lee > > _______________________________________________ > > This message sent to you through the ARIN Public Policy > Mailing List > > (PPML at arin.net). > > Manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml > > > > > From kloch at kl.net Thu Aug 2 17:36:10 2007 From: kloch at kl.net (Kevin Loch) Date: Thu, 02 Aug 2007 17:36:10 -0400 Subject: [ppml] alternative realities (was PIv6 for legacy, holders (/wRSA + efficient use)) In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB406980FAA@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB406980FAA@CL-S-EX-1.stanleyassociates.com> Message-ID: <46B24E4A.5@kl.net> Howard, W. Lee wrote: > > I'm going out on a limb and say that the consensus is that > a market would be some degree of ungood. > > If so, then maybe there are ways to prevent it, stall it, > or make is less ungood. One way to make a free market in addresses "less ungood" is to prevent subdivision, or only allow it down to a certain size (/20). To accomplish that you would have to open said market early enough to prevent someone else from doing it for you. I'm not suggesting that is the path we should take but it is one possibility of several bad options. - Kevin From randy at psg.com Thu Aug 2 17:38:15 2007 From: randy at psg.com (Randy Bush) Date: Thu, 02 Aug 2007 11:38:15 -1000 Subject: [ppml] alternative realities (was PIv6 for legacy, holders (/wRSA + efficient use)) In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB406980FAA@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB406980FAA@CL-S-EX-1.stanleyassociates.com> Message-ID: <46B24EC7.7040907@psg.com> ok, since drc thinks bill's gag order allows one post a day, i will indulge. as a red diaper baby, i am cheered at seeing support for each according to their needs as opposed to open market. can't trust those damned open markets at all. need five year plan! marxist-lenist theory survives in the rir game! randy From stephen at sprunk.org Thu Aug 2 18:09:33 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 2 Aug 2007 17:09:33 -0500 Subject: [ppml] alternative realities (was PIv6 for legacy, holders (/wRSA + efficient use)) References: <369EB04A0951824ABE7D8BAC67AF9BB4068FDAD2@CL-S-EX-1.stanleyassociates.com> <5784C83A-3726-4AFE-AA05-E4FF7557C608@virtualized.org> Message-ID: <059601c7d551$e52e9110$403816ac@atlanta.polycom.com> Thus spake "David Conrad" > I guess I'm skeptical that those holders of the "legacy" O(100) /8s > will voluntarily return their unused address space to ARIN (or other > appropriate RIR) out of "enlightened self-interest". Stanford voluntarily returned 36/8, so it's not impossible. It appears 46/8, 49/8, and 50/8 were returned as well. > As such, those holders of the "legacy" O(100) /8s will need to > be incented to renumber and/or part with "their" address space. > How do you think that can realistically be done? Carrots are good. However, I'd like to first see ARIN politely ask legacy holders to voluntarily return any unused space (and/or sign an RSA), plus reclaim abandoned space, before we enact any carrot policies -- and certainly before we start discussing sticks S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From stephen at sprunk.org Thu Aug 2 18:40:47 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 2 Aug 2007 17:40:47 -0500 Subject: [ppml] More on Kremen/Cohen References: Message-ID: <065301c7d55a$6d672e40$403816ac@atlanta.polycom.com> Thus spake "Ted Mittelstaedt" >>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >>Stephen Sprunk >>This has nothing to do with ARIN's public policy process. > > I disagree with this statement. > > We all dodged the bullet on this one - if the case hadn't been > dismissed on a technicality, it might have severly impacted ARIN's > public policy pocess. We don't know what the final resolution would have been if it hadn't for that technicality. That was the simplest way to deal with the unlawful order; I'm sure that ARIN's counsel had plenty of other arguments that could have been used successfully if that failed, but there was no need to use them. > It is almost a certainty that if further policy is adopted by > ARIN that turns out to have negative impacts, that it will trigger > more court cases. This case really should serve as a warning to > everyone. We have been told to make policy that is best for the community without regard to any theoretical legal consequences. ARIN has counsel for that, and they will advise us if we're entering unsafe territory. If court actions affect existing policy, the BoT is empowered to act on an emergency basis. Counsel has not told us that we need to care about the Kremen/Cohen matter when making policy, so it's off-topic here until then, as are Dean's various allegations against Mr. Vixie and other folks (many not even involved in the ARIN process at all). S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From stephen at sprunk.org Thu Aug 2 18:55:55 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 2 Aug 2007 17:55:55 -0500 Subject: [ppml] Motivating migration to IPv6 References: <200707311748.l6VHmwqP026867@s25.firmware.com> Message-ID: <065401c7d55a$6d947fd0$403816ac@atlanta.polycom.com> Thus spake "Robert Bonomi" > Proposed: > A) every IPv4 block assignment includes the assignment of an > 'equivalent-size' IPv6 address block ( e.g. assuming '1 IPv4 /32' > == '1 IPv6 /64) I'm against this, for the same reason I'm against it when Ted proposed it a while back: a responsible steward does not give people resources that they haven't asked for (among others). Also, there's no "equivalent" sizes between v4 and v6. Ignoring the above complaint, I think it would be sufficient to say that ARIN would issue a minimum-sized v6 block (based on the applicant's type) on the next request for a v4 block. Few folks should ever exceed the current minima in v6 land. > B) _subsequent_ v4 requests must show the required utilization > levels of *both* the allocated IPv4 *and* IPv6 space. With > "utilization" of IPv6 space requiring the actual deployment of > functional machines in that address-space. That's interesting; the problem is that utilization in v6 is a rather meaningless term, particularly for folks who have (oversized) minimum blocks. Many ISPs will _never_ get "acceptable" utilization of their /32; ditto for end-users and their /48s. > C) As the pool of available IPv4 addresses gets smaller, the > ratio of the relative size of the IPv6 allocation vs the IPv4 > allocation _increases_. Unnecessary. > For 'revenue' purposes, the 'paired' IPv4 and IPv6 allocations are > counted as single block, as long as both are allocated. IF the > requestor _returns_ the IPv4 block, they get a significant discount > on the IPv6 space for some period of time. (50% off for 5 years, > maybe?) That effectively means that we're cutting rates in half for both types for the next five years. My proposal that orgs pay either their v4 fees or v6 fees, whichever is more, has the same long-term effect without the unintended consequences. > Another possible 'motivator' for IPv6 migration -- tie the > requirements for getting _additional_ IPv4 space to the ratio of > IPv6 vs IPv4 space that the requestor _already_ has "in verified > use". The less IPv6 space they have in use relative to their > IPv4 space the *higher* the utilization of the IPv4 space they > have to show to get any additional IPv4 space. I like the general direction of this, but I'd prefer it be simpler; even just the number of hosts that have v4 and/or v6 addresses assigned would be a useful measure, if not perfect. I also think that the first step should be less drastic, like requiring everyone to submit a detailed v6 migration plan with their first v4 request after date X, and a status update with each additional v4 request. ARIN could collect a lot of data that would help with its educational efforts. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From sean.copeland at ibips.com Thu Aug 2 19:18:58 2007 From: sean.copeland at ibips.com (Sean Copeland) Date: Thu, 2 Aug 2007 16:18:58 -0700 Subject: [ppml] I am in the office today, however I will not be responding to e-mails until after 6 PM PD Message-ID: <10708021618.AA56331@ibips.com> I am in the office today, however I will not be responding to e-mails until after 6 PM PDT. If this is an emergent situation, please contact Sofi. Thanks Sean From tedm at ipinc.net Thu Aug 2 19:40:46 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 2 Aug 2007 16:40:46 -0700 Subject: [ppml] More on Kremen/Cohen In-Reply-To: <065301c7d55a$6d672e40$403816ac@atlanta.polycom.com> Message-ID: >-----Original Message----- >From: Stephen Sprunk [mailto:stephen at sprunk.org] >Sent: Thursday, August 02, 2007 3:41 PM >To: Ted Mittelstaedt >Cc: ARIN PPML >Subject: Re: [ppml] More on Kremen/Cohen > > > >Counsel has not told us that we need to care about the Kremen/Cohen matter >when making policy, so it's off-topic here until then, That isn't correct. If Counsel issues an opinion that the Kremen/Cohen matter is of no consequence when making policy then you would have a point. However, Counsel not issuing an opinion one way or the other, cannot be construed that the matter is of no consequence. Your argument is similar to saying that because the lawyer down the street hasn't told me that I need to have homeowners insurance, then I must not need to have it. Since lawyers cost money, the usual procedure in most organizations is to not ask them to review anything unless your ready to implement it. Our policy discussions here are quite far in advance of implementation so it wouldn't be usual for them to be reviewed by legal counsel. That does NOT mean, however, that you go and do something obviously illegal. I could propose a policy that spammers be shot-dead-on-sight and I'm sure a lot of people might agree with it, and agree it is best for the community, your being ludicrous if you say I should go ahead and propose it without regard to any legal consequences. While I definitely agree that the Kremen/Cohen fight wasn't worth anything more than a dismissal on a technicality, I only agree because of the nature of the combatants. Neither of those human beings are worth a plugged nickle. The issues raised, however, were bigger than the combatants and definitely were more than "theoretical legal consequences." >as are >Dean's various >allegations against Mr. Vixie and other folks (many not even >involved in the >ARIN process at all). > Well, that's a different matter and there's no point in expanding this thread by including that issue. Frankly I personally found the whole thing highly amusing and quite an enjoyable spectacle - not much different than watching Jay Leno's monologe on the Tonight Show. Amusing, and fun, but hardly something to take seriously. Ted From paul at vix.com Thu Aug 2 20:17:25 2007 From: paul at vix.com (Paul Vixie) Date: Fri, 03 Aug 2007 00:17:25 +0000 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: Your message of "Thu, 02 Aug 2007 11:38:03 MST." <46B2248B.4010506@internap.com> References: <46B21B27.8000106@internap.com> <99813.1186078321@sa.vix.com> <46B2248B.4010506@internap.com> Message-ID: <83517.1186100245@sa.vix.com> [vixie] > who is this "we" that you think is going to do the right thing when all > of the wrong things are being done distantly from "us"? [leibrand] > I'm also optimistic that we've learned some lessons from the last round > of deaggregation, and will have narrow-spectrum therapies (like > as-pathlimit) to treat the next round. i'm not getting through here. scott, there is no "we" in the "routing table full" scenario. last time around "we" dodged the bullet because the network was small, and CIDR was an easy way to accomodate future growth, and moore's law was an easy way to cope with current growth. if pool depletion leads to mass deaggregation and steps in the global table size, it'll be every network for itself -- the ultimate assymetric cost:benefit equation -- a meltdown. [leibrand] > For example, there's no particular reason that a North American network > needs to hear all the /24 deaggregates from Asia and Europe if they're > covered by larger aggregates, and vice versa. covered by larger aggregates having the same path? or would it then be possible for competing wet transit operators to out-duel eachother using announcement sizes? and are you SURE there would be any lost TE benefit, even if anycast wasn't in use? these are distant people's networks, about which comparatively few local decisions can be well informed. [leibrand] > It's not really a case that "they" are doing bad things, and "we" are doing > everything right. Rather, deaggregation is something that is very useful > locally, and not so useful further away, so if filtering becomes necessary, > it would be appropriate for everyone to filter distantly-originated > deaggregates, and continue listening to locally-originated ones. that's an overly sweeping information losing generality. (btw, i was serious when i said i hoped you'd tell the internap ipv6 story in a nanog presentation... we've got to get more network operators thinking about this subject.) From bicknell at ufp.org Thu Aug 2 20:47:34 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 2 Aug 2007 20:47:34 -0400 Subject: [ppml] More on Kremen/Cohen In-Reply-To: References: <065301c7d55a$6d672e40$403816ac@atlanta.polycom.com> Message-ID: <20070803004734.GA6522@ussenterprise.ufp.org> In a message written on Thu, Aug 02, 2007 at 04:40:46PM -0700, Ted Mittelstaedt wrote: > Since lawyers cost money, the usual procedure in most organizations > is to not ask them to review anything unless your ready to > implement it. Our policy discussions here are quite far in advance > of implementation so it wouldn't be usual for them to be reviewed > by legal counsel. That does NOT mean, however, that you go and > do something obviously illegal. I could propose a policy that > spammers be shot-dead-on-sight and I'm sure a lot of people might > agree with it, and agree it is best for the community, your being > ludicrous if you say I should go ahead and propose it without > regard to any legal consequences. For those who haven't been to a meeting... Every proposal discussed at a meeting includes a "staff assessment". This includes ARIN staff providing some information on if they see implementation problems, and giving the time frame for work to be completed to implement a policy. It also includes a review from council, who is also at the meeting and able to answer questions. So while a policy proposal is not reviewed by council solely because it's discussed on PPML, all formal proposals are reviewed and presented to the public prior to determining consensus. It is absolutely the case that the staff assessment, either due to staff or council's remarks have had significant impact in how the community feels about proposals in the past. I believe you should be able to find these in the notes from previous meetings on the web site without too much trouble. Obviously there may be additional, or more in depth review before the AC or the Board considers the proposal, particularly if the AC, Board, or council requests such an action. -- 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 mysidia at gmail.com Thu Aug 2 20:52:52 2007 From: mysidia at gmail.com (James Hess) Date: Thu, 2 Aug 2007 19:52:52 -0500 Subject: [ppml] Motivating migration to IPv6 In-Reply-To: <200707311748.l6VHmwqP026867@s25.firmware.com> References: <200707311748.l6VHmwqP026867@s25.firmware.com> Message-ID: <6eb799ab0708021752x6d1b516ie112d4c80fec6f46@mail.gmail.com> On 7/31/07, Robert Bonomi wrote: > > > I'm sure the following idea has to have occured to better minds than mine, > but I _cannot_ see what the downside to it is -- > > Given that: > 1) it is policy to 'encourage' migration to IPv6 > 2) there is a looming shortage of IPv4 addresses available for > assignment > 3) _At_present_ IPv4 address-space *is* viewed by requestors as > 'preferable' > to IPv6 space. > 4) more than 95% of address-space assignments are to entities for which > there > is a reasonable expectation they will be making _additional_ address- > space requests in the 'not too distant' future. I'm trying to think of ways to simplify the concept... Why not do the following? Reserve some IPv4 blocks, possibly including reclaimed blocks, to be allocated only to sites that have already received and continue to met a utilization efficiency criterion in terms of connected publicly visible hosts for an allocation of IPv6 space. Ideally I think the reservation be done not just by one RIR, but by all RIRs, and IANA practices revised to set aside a good number of /8s of IPv4 addresses as " reserved for allocation to users transitioning to IPv6". The reservations would make large blocks unavailable to users that have not deployed IPv6, thereby motivating them to deploy IPv6 in order to draw from the reserved block of addresses. It doesn't force anyone to deploy IPv6. In fact, they might use NAT for the additional hosts, rather than get a bigger block of IPv4 space. It only discourages networks expanding (adding many hosts using public IPs) without also obtaining IPv6 connectivity, to instead obtain IPv6 connectivity at the best possible time -- while they are already expanding their network. It creates a miniaturized version of the very same issue that in 4 years will effect every network that's going to need to ask someone else for additional IPv4 space after total exhaustion of the registry pools. And while it encourages IPv6, the policy wouldn't "force" it to be adopted any more than exhaustion ultimately will. Essentially, in the name of encouraging a more long-term sustainable practice, a smaller "pseudo-exhaustion" is spawned 1 to 2 years earlier, due to the reservations. I assume that promotes greater stability than just a right out exhaustion, as rapidly expanding networks will have adopted IPv6, and experience with the pseudo-exhaustion will give people better experience in terms of knowledge of what to expect when IPv4 eventually runs out. -- -J -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at istaff.org Thu Aug 2 22:11:05 2007 From: jcurran at istaff.org (John Curran) Date: Thu, 2 Aug 2007 22:11:05 -0400 Subject: [ppml] FYI - CSM Article on IPv4 address shortage In-Reply-To: <46B24EC7.7040907@psg.com> References: <369EB04A0951824ABE7D8BAC67AF9BB406980FAA@CL-S-EX-1.stanleyassociates.com> <46B24EC7.7040907@psg.com> Message-ID: http://www.csmonitor.com/2007/0803/p02s01-ussc.html Very readable for the general public (and obviously tamer than the PPML equivalent :-) /John From sean.copeland at ibips.com Thu Aug 2 22:18:25 2007 From: sean.copeland at ibips.com (Sean Copeland) Date: Thu, 2 Aug 2007 19:18:25 -0700 Subject: [ppml] I am in the office today, however I will not be responding to e-mails until after 6 PM PD Message-ID: <10708021918.AA59533@ibips.com> I am in the office today, however I will not be responding to e-mails until after 6 PM PDT. If this is an emergent situation, please contact Sofi. Thanks Sean From bmanning at vacation.karoshi.com Thu Aug 2 22:23:29 2007 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 3 Aug 2007 02:23:29 +0000 Subject: [ppml] alternative realities (was PIv6 for legacy, holders (/wRSA + efficient use)) In-Reply-To: <46B24EC7.7040907@psg.com> References: <369EB04A0951824ABE7D8BAC67AF9BB406980FAA@CL-S-EX-1.stanleyassociates.com> <46B24EC7.7040907@psg.com> Message-ID: <20070803022329.GA7303@vacation.karoshi.com.> On Thu, Aug 02, 2007 at 11:38:15AM -1000, Randy Bush wrote: > ok, since drc thinks bill's gag order allows one post a day, i will indulge. > > randy you have got to be joking. gag order? my post pointed out a tried/true method to leap through the threads of folks bickering w/ each other w/o bringing anything new to the table. Stop reading their posts. Nowhere did i assert people should stop posting whatever they feel is relevent. or perhaps you ment some other bill? --bill From mysidia at gmail.com Thu Aug 2 22:30:34 2007 From: mysidia at gmail.com (James Hess) Date: Thu, 2 Aug 2007 21:30:34 -0500 Subject: [ppml] FYI - CSM Article on IPv4 address shortage In-Reply-To: References: <369EB04A0951824ABE7D8BAC67AF9BB406980FAA@CL-S-EX-1.stanleyassociates.com> <46B24EC7.7040907@psg.com> Message-ID: <6eb799ab0708021930o3f94fb3bk9f7d1395e022b184@mail.gmail.com> On 8/2/07, John Curran wrote: > > http://www.csmonitor.com/2007/0803/p02s01-ussc.html > > Very readable for the general public (and obviously tamer > than the PPML equivalent :-) > /John Yes, however, I would say the article leaves something desired when it comes to the technical details... "Addresses under the current standard, known as IPv4, are made up of four integers between 0 and 255. That allows for roughly 4.3 billion addresses ? not enough to keep pace with expanding Internet access in India and China as well as the variety of devices going online. Newer IPv6 addresses are made up of six integers instead of four, allowing trillions of trillions of new addresses." Last I checked, IPv6 addresses were 128-bit not 48-bit, the article should say 16 octets or "numbers", not 6. [With just 6 octets, the extra addresses might be exhausted in 50 years.] -- -J -------------- next part -------------- An HTML attachment was scrubbed... URL: From cliffb at cjbsys.bdb.com Fri Aug 3 08:38:28 2007 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Fri, 03 Aug 2007 08:38:28 -0400 Subject: [ppml] alternative realities (was PIv6 for legacy, holders (/wRSA + efficient use)) In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4068FDAD2@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB4068FDAD2@CL-S-EX-1.stanleyassociates.com> Message-ID: <46B321C4.1060501@cjbsys.bdb.com> Howard, W. Lee wrote: >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >> Behalf Of Cliff Bedore >> Sent: Thursday, August 02, 2007 1:37 PM >> To: PPML >> Subject: Re: [ppml] alternative realities (was PIv6 for >> legacy, holders (/wRSA + efficient use)) >> >> With regards to MIT and or/other /8s that are "privately >> held", is the internet better off getting those turned in and >> split up which adds to the routing table or letting the >> private holder become a default ISP/mini IANA/ARIN in effect >> with a /8 aggregated address and keep the table smaller? >> > > I think the Internet is better of with ARIN allocating based on > need than it would be with other organizations allocating based > on cash. > > You asked the question--what do you think? > I have mixed feelings. In general, good stewardship would make you want to have it turned in and reissued appropriately. As a /24, I worry that if we get enough deaggregation, the routing tables will get big enough that I might get lost. I'm not a technical routing wizard but I keep reading about the tables getting too big in spite of the sales droid promises and people filtering above /24s and I'd like to not get lost. If people really believe that /24s won't get lost, convince the /8 owners to turn them in. I think if all the remaining space became /24s we'd be in routing table trouble and if they stayed much bigger, we'd probably be safe. Where is that breakpoint and where will it be in 2, 3 or 5 years? I know that in theory, ARIN shouldn't care about routing but if they just give out addresses that thhey know can't get routed, that can't be considered good stewardship The other problem is that some of the legacy /8s are going to start looking at addresses as major assets and could easily become a major ISP overnight and as I stated, I'm not sure what recourse ARIN/IANA has to recover any part of the /8. In spite of the statements here that addresses are not property, I certainly felt that my /24 was granted with no conditions regarding my use or disposal of it. A legal challenge to a legacy /8s ability to become this overnight super ISP would be a crap shoot at best. Cliff > >> Cliff >> > > > Lee > > From dave at mvn.net Fri Aug 3 11:29:43 2007 From: dave at mvn.net (David E. Smith) Date: Fri, 03 Aug 2007 10:29:43 -0500 Subject: [ppml] Motivating migration to IPv6 In-Reply-To: <065401c7d55a$6d947fd0$403816ac@atlanta.polycom.com> References: <200707311748.l6VHmwqP026867@s25.firmware.com> <065401c7d55a$6d947fd0$403816ac@atlanta.polycom.com> Message-ID: <46B349E7.7080907@mvn.net> Stephen Sprunk wrote: > My proposal that orgs pay either their v4 fees or v6 fees, whichever is > more, has the same long-term effect without the unintended consequences. Now this is a proposal I can get behind. :) I work for a fairly small ISP (we've got a single /19). I've been following this discussion, and I've wanted to play with IPv6 for a while. I can't, however, cost-justify it to the boss. Right now, there are IPv6 fee waivers, but they're presently only guaranteed through the end of the year. Unless the IPv6 fees are waived again, we'll either have to return the allocation in a few months, or somehow come up with $2250 to pay for something we don't presently *need*. (Right now, our upstream doesn't support IPv6, saying none of their customers are clamoring for it; it's a very chicken-and-egg problem.) Meanwhile, we're small enough that $2250 a year (assuming we get a "Small" allocation, the same as our current IPv4 one) is a pretty hefty expense. My customers aren't asking about IPv6, much of our gear doesn't support it, and there's not that much you can do with it (that you can't do with IPv4) -- it's a very hard sell. If I could get some kind of guarantee or other really solid reassurance that trying to deploy IPv6 isn't going to cost me money I don't really have for something I don't yet need, I'd be glad to start tinkering. The aforementioned proposal makes perfect sense to me. (A longer-term fee waiver, say through 2011 or so, would work just as well from my perspective, though I can't say how well it'd work for ARIN.) David Smith MVN.net From sean.copeland at ibips.com Fri Aug 3 12:06:16 2007 From: sean.copeland at ibips.com (Sean Copeland) Date: Fri, 3 Aug 2007 09:06:16 -0700 Subject: [ppml] I am in the office today, however I will not be responding to e-mails until after 6 PM PD Message-ID: <10708030906.AA19282@ibips.com> I am in the office today, however I will not be responding to e-mails until after 6 PM PDT. If this is an emergent situation, please contact Sofi. Thanks Sean From kkargel at polartel.com Fri Aug 3 12:07:00 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 3 Aug 2007 11:07:00 -0500 Subject: [ppml] Motivating migration to IPv6 In-Reply-To: <46B349E7.7080907@mvn.net> References: <200707311748.l6VHmwqP026867@s25.firmware.com><065401c7d55a$6d947fd0$403816ac@atlanta.polycom.com> <46B349E7.7080907@mvn.net> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066707238@mail> I am in much the same boat as David.. I sincerely hope that the cost waivers are going to stay in place until IPv6 is actually useful. I have gone ahead and gotten an allocation, but I am not sure whether we will be able to justify an actual payment if the waiver runs out before I am able to route v6. Kevin :$s/worry/happy/g > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of David E. Smith > Sent: Friday, August 03, 2007 10:30 AM > To: ppml at arin.net > Subject: Re: [ppml] Motivating migration to IPv6 > > Stephen Sprunk wrote: > > > My proposal that orgs pay either their v4 fees or v6 fees, > whichever > > is more, has the same long-term effect without the > unintended consequences. > > Now this is a proposal I can get behind. :) > > I work for a fairly small ISP (we've got a single /19). I've > been following this discussion, and I've wanted to play with > IPv6 for a while. I can't, however, cost-justify it to the boss. > > Right now, there are IPv6 fee waivers, but they're presently > only guaranteed through the end of the year. Unless the IPv6 > fees are waived again, we'll either have to return the > allocation in a few months, or somehow come up with $2250 to > pay for something we don't presently *need*. (Right now, our > upstream doesn't support IPv6, saying none of their customers > are clamoring for it; it's a very chicken-and-egg problem.) > > Meanwhile, we're small enough that $2250 a year (assuming we > get a "Small" allocation, the same as our current IPv4 one) > is a pretty hefty expense. My customers aren't asking about > IPv6, much of our gear doesn't support it, and there's not > that much you can do with it (that you can't do with IPv4) -- > it's a very hard sell. > > If I could get some kind of guarantee or other really solid > reassurance that trying to deploy IPv6 isn't going to cost me > money I don't really have for something I don't yet need, I'd > be glad to start tinkering. The aforementioned proposal makes > perfect sense to me. (A longer-term fee waiver, say through > 2011 or so, would work just as well from my perspective, > though I can't say how well it'd work for ARIN.) > > David Smith > MVN.net > _______________________________________________ > This message sent to you through the ARIN Public Policy > Mailing List (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From captain at netidea.com Fri Aug 3 12:25:26 2007 From: captain at netidea.com (Kirk Ismay) Date: Fri, 03 Aug 2007 09:25:26 -0700 Subject: [ppml] Motivating migration to IPv6 In-Reply-To: <46B349E7.7080907@mvn.net> References: <200707311748.l6VHmwqP026867@s25.firmware.com> <065401c7d55a$6d947fd0$403816ac@atlanta.polycom.com> <46B349E7.7080907@mvn.net> Message-ID: <46B356F6.9090902@netidea.com> David E. Smith wrote: > Stephen Sprunk wrote: > > >> My proposal that orgs pay either their v4 fees or v6 fees, whichever is >> more, has the same long-term effect without the unintended consequences. >> > > Now this is a proposal I can get behind. :) > > I work for a fairly small ISP (we've got a single /19). I've been > following this discussion, and I've wanted to play with IPv6 for a > while. I can't, however, cost-justify it to the boss. > I support this proposal, for the same reasons. We've got an IPv4 /20 and we're a fairly small shop also. I'd like to play with IPv6, if I could only find the time. ;) Sincerely, Kirk Ismay System Administrator -- Net Idea 201-625 Front Street Nelson, BC V1L 4B6 P:250-352-3512 | F:250-352-9780 | TF:1-888-352-3512 Check out our brand new website! www.netidea.com From sleibrand at internap.com Fri Aug 3 13:53:20 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 3 Aug 2007 13:53:20 -0400 (EDT) Subject: [ppml] clarification of IPv4 and IPv6 fees In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB405EA23BB@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB405EA23BB@CL-S-EX-1.stanleyassociates.com> Message-ID: Lee, Can you provide us an update on this? As the topic has come up again on PPML, it would be great to see a final decision along the lines you described (that when temporary waivers for IPv6 have expired, that subscriber members will pay the greater of their IPv4 or IPv6 fees, not both), and to get http://www.arin.net/billing/fee_schedule.html updated accordingly. Thanks, Scott On 05/23/07 at 10:30am -0400, Howard, W. Lee I said at the April 2007 Members Meeting that I owed the > community a clarification of what IPv6 fees would look like > when the current waivers expire. I have checked with the > Finance Committee, but not the full Board. It is our common > understanding that beginning January 1, 2008, when temporary > waivers for IPv6 have expired, that subscriber members will > pay the greater of their IPv4 or IPv6 fees, not both. > > That is to say that ISPs will pay for either their IPv4 > renewal or their IPv6 renewal, whichever dollar amount is > higher. > > End user organizations who pay a $100 consolidated annual > maintenance fee will pay the same annual maintenance. > > We have also received a number of excellent suggestions for > other ways to structure fees. We are collecting data to > see how each model would affect ARIN's long term ability to > continue providing services, and will be discussing them in > the coming months. > > I hope that is clearer, and I will be working with the ARIN > staff on language for the web site that reflects the intent. > > > Your Treasurer, > > Lee Howard > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From tedm at ipinc.net Fri Aug 3 14:09:37 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 3 Aug 2007 11:09:37 -0700 Subject: [ppml] Motivating migration to IPv6 In-Reply-To: <46B349E7.7080907@mvn.net> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >David E. Smith >Sent: Friday, August 03, 2007 8:30 AM >To: ppml at arin.net >Subject: Re: [ppml] Motivating migration to IPv6 > > >Stephen Sprunk wrote: > >> My proposal that orgs pay either their v4 fees or v6 fees, whichever is >> more, has the same long-term effect without the unintended consequences. > >Now this is a proposal I can get behind. :) > I had thought that someone else was already working on a proposal like this, I've seen this discussed before on this list. Ted From tedm at ipinc.net Fri Aug 3 14:12:15 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 3 Aug 2007 11:12:15 -0700 Subject: [ppml] Motivating migration to IPv6 In-Reply-To: Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Ted Mittelstaedt >Sent: Friday, August 03, 2007 11:10 AM >To: David E. Smith; ppml at arin.net >Subject: Re: [ppml] Motivating migration to IPv6 > > > > >>-----Original Message----- >>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >>David E. Smith >>Sent: Friday, August 03, 2007 8:30 AM >>To: ppml at arin.net >>Subject: Re: [ppml] Motivating migration to IPv6 >> >> >>Stephen Sprunk wrote: >> >>> My proposal that orgs pay either their v4 fees or v6 fees, whichever is >>> more, has the same long-term effect without the unintended consequences. >> >>Now this is a proposal I can get behind. :) >> > >I had thought that someone else was already working on a proposal >like this, I've seen this discussed before on this list. > oops, refer to thread titled " clarification of IPv4 and IPv6 fees" Ted > From Lee.Howard at stanleyassociates.com Fri Aug 3 14:21:45 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 3 Aug 2007 14:21:45 -0400 Subject: [ppml] clarification of IPv4 and IPv6 fees In-Reply-To: Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB406981471@CL-S-EX-1.stanleyassociates.com> Yes, I was typing a response when your message came in. The Finance Committee of the Board of Trustees has heard this message, and clarified the fee schedule: an organization pays only the higher of IPv4 or IPv6 renewals. Clarifying language is on its way to the Fee Schedule page of ARIN's web site. Regarding the waiver, the Finance Committee recently considered over a dozen different proposals, and you can expect to see an announcement soon. Your Friendly Treasurer, Lee > -----Original Message----- > From: Scott Leibrand [mailto:sleibrand at internap.com] > Sent: Friday, August 03, 2007 1:53 PM > To: Howard, W. Lee > Cc: PPML at arin.net > Subject: Re: [ppml] clarification of IPv4 and IPv6 fees > > Lee, > > Can you provide us an update on this? As the topic has come > up again on PPML, it would be great to see a final decision > along the lines you described (that when temporary waivers > for IPv6 have expired, that subscriber members will pay the > greater of their IPv4 or IPv6 fees, not both), and to get > http://www.arin.net/billing/fee_schedule.html updated accordingly. > > Thanks, > Scott > > On 05/23/07 at 10:30am -0400, Howard, W. Lee > > > I said at the April 2007 Members Meeting that I owed the > community a > > clarification of what IPv6 fees would look like when the current > > waivers expire. I have checked with the Finance Committee, but not > > the full Board. It is our common understanding that > beginning January > > 1, 2008, when temporary waivers for IPv6 have expired, that > subscriber > > members will pay the greater of their IPv4 or IPv6 fees, not both. > > > > That is to say that ISPs will pay for either their IPv4 renewal or > > their IPv6 renewal, whichever dollar amount is higher. > > > > End user organizations who pay a $100 consolidated annual > maintenance > > fee will pay the same annual maintenance. > > > > We have also received a number of excellent suggestions for > other ways > > to structure fees. We are collecting data to see how each > model would > > affect ARIN's long term ability to continue providing services, and > > will be discussing them in the coming months. > > > > I hope that is clearer, and I will be working with the ARIN > staff on > > language for the web site that reflects the intent. > > > > > > Your Treasurer, > > > > Lee Howard > > > > > > _______________________________________________ > > This message sent to you through the ARIN Public Policy > Mailing List > > (PPML at arin.net). > > Manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml > > > From tedm at ipinc.net Fri Aug 3 14:24:12 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 3 Aug 2007 11:24:12 -0700 Subject: [ppml] More on Kremen/Cohen In-Reply-To: <20070803004734.GA6522@ussenterprise.ufp.org> Message-ID: >-----Original Message----- >From: Leo Bicknell [mailto:bicknell at ufp.org] >Sent: Thursday, August 02, 2007 5:48 PM >To: Ted Mittelstaedt >Cc: Stephen Sprunk; ARIN PPML >Subject: Re: [ppml] More on Kremen/Cohen > > >In a message written on Thu, Aug 02, 2007 at 04:40:46PM -0700, Ted >Mittelstaedt wrote: >> Since lawyers cost money, the usual procedure in most organizations >> is to not ask them to review anything unless your ready to >> implement it. Our policy discussions here are quite far in advance >> of implementation so it wouldn't be usual for them to be reviewed >> by legal counsel. That does NOT mean, however, that you go and >> do something obviously illegal. I could propose a policy that >> spammers be shot-dead-on-sight and I'm sure a lot of people might >> agree with it, and agree it is best for the community, your being >> ludicrous if you say I should go ahead and propose it without >> regard to any legal consequences. > >For those who haven't been to a meeting... > >Every proposal discussed at a meeting includes a "staff assessment". >This includes ARIN staff providing some information on if they see >implementation problems, and giving the time frame for work to be >completed to implement a policy. It also includes a review from >council, who is also at the meeting and able to answer questions. > >So while a policy proposal is not reviewed by council solely because >it's discussed on PPML, all formal proposals are reviewed and >presented to the public prior to determining consensus. It is >absolutely the case that the staff assessment, either due to staff >or council's remarks have had significant impact in how the community >feels about proposals in the past. > So, did counsel ever comment on any past "shoot spammers dead on sight" proposals? There had to have been at least one! :-) Thanks, Leo, for the detailed explanation of the review process. Ted From tedm at ipinc.net Fri Aug 3 14:41:15 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 3 Aug 2007 11:41:15 -0700 Subject: [ppml] alternative realities (was PIv6 for legacy, holders (/wRSA + efficient use)) In-Reply-To: <059601c7d551$e52e9110$403816ac@atlanta.polycom.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Stephen Sprunk >Sent: Thursday, August 02, 2007 3:10 PM >To: David Conrad; Howard, W. Lee >Cc: ARIN PPML >Subject: Re: [ppml] alternative realities (was PIv6 for legacy,holders >(/wRSA + efficient use)) > > >Thus spake "David Conrad" >> I guess I'm skeptical that those holders of the "legacy" O(100) /8s >> will voluntarily return their unused address space to ARIN (or other >> appropriate RIR) out of "enlightened self-interest". > >Stanford voluntarily returned 36/8, so it's not impossible. It appears >46/8, 49/8, and 50/8 were returned as well. > >> As such, those holders of the "legacy" O(100) /8s will need to >> be incented to renumber and/or part with "their" address space. >> How do you think that can realistically be done? > >Carrots are good. However, I'd like to first see ARIN politely ask legacy >holders to voluntarily return any unused space (and/or sign an RSA), plus >reclaim abandoned space, before we enact any carrot policies -- and >certainly before we start discussing sticks > I would NOT support any such activity unless ARIN -ALSO- stated that the Legacy holder MUST INDICATE IF THEY WANT TO CONTINUE TO RETAIN the space. Sending a letter out is not good enough. Odds are that a LOT of the legacy space is held by organizations that have no idea they have it, certainly aren't using it, and have no way of using it even if they wanted to do so. The SOP in cases like these are when the network manager gets this letter that they have no idea what in the hell is being discussed, they will toss it in the garbage. ARIN must not assume that FAILURE TO RESPOND to a letter is an indication that the Legacy holder still wants to retain their assignment. Personally my own preference would be that failure to respond means the legacy holder DOES NOT WANT to retain the assignment - but I know the community wouldn't stand for that. ONLY a RESPONSE in the negative can be taken as the legacy holder wants to continue holding on to their assignment. A lack of response needs to be taken as: "Status unknown, try again later" (Refer to your neighborhood Magic 8 Ball for the usual phrasing ;-) I would hope ARIN would take lack of response as an opportunity to followup with a phone call, at least for the larger assignments. Ted From dave at mvn.net Fri Aug 3 15:32:41 2007 From: dave at mvn.net (David E. Smith) Date: Fri, 03 Aug 2007 14:32:41 -0500 Subject: [ppml] clarification of IPv4 and IPv6 fees In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB406981471@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB406981471@CL-S-EX-1.stanleyassociates.com> Message-ID: <46B382D9.6090508@mvn.net> Howard, W. Lee wrote: > The Finance Committee of the Board of Trustees has heard this > message, and clarified the fee schedule: an organization pays > only the higher of IPv4 or IPv6 renewals. Clarifying language > is on its way to the Fee Schedule page of ARIN's web site. This makes me all kinds of happy. Shortly after this language is posted, I'll submit my initial IPv6 request. :D (I'm sure someone in ARIN is sighing right now, knowing there's about to be a big nasty flood of initial IPv6 requests. Thanks for putting up with us!) David Smith MVN.net From stephen at sprunk.org Fri Aug 3 15:31:35 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 3 Aug 2007 14:31:35 -0500 Subject: [ppml] More on Kremen/Cohen References: Message-ID: <02d901c7d607$d7112a50$543816ac@atlanta.polycom.com> Thus spake "Ted Mittelstaedt" > So, did counsel ever comment on any past "shoot spammers > dead on sight" proposals? There had to have been at least one! :-) I'm not aware of that having been formally proposed in the past. You're welcome to submit such a proposal (or any other) yourself if you're curious what the response would be; the directions are at: http://www.arin.net/policy/irpep.html In the past, counsel _has_ commented negatively on several proposals; check the PPML archives for "Staff Assessment" messages that are sent out prior to each meeting. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From paul at vix.com Fri Aug 3 17:59:53 2007 From: paul at vix.com (Paul Vixie) Date: Fri, 03 Aug 2007 21:59:53 +0000 Subject: [ppml] Motivating migration to IPv6 In-Reply-To: Your message of "Thu, 02 Aug 2007 19:52:52 EST." <6eb799ab0708021752x6d1b516ie112d4c80fec6f46@mail.gmail.com> References: <200707311748.l6VHmwqP026867@s25.firmware.com> <6eb799ab0708021752x6d1b516ie112d4c80fec6f46@mail.gmail.com> Message-ID: <83999.1186178393@sa.vix.com> James, thanks for this, I am very intrigued with the good effects it could have and the bad side effects it should not have, compared to other policy proposals now under consideration. I hope that you will do further work on it (see http://www.arin.net/policy/irpep.html for details) so that it can be formally considered by the community. --Paul re: > Date: Thu, 2 Aug 2007 19:52:52 -0500 > From: "James Hess" > To: ppml at arin.net > Subject: Re: [ppml] Motivating migration to IPv6 > Sender: ppml-bounces at arin.net > > ... Why not do the following? > > Reserve some IPv4 blocks, possibly including reclaimed blocks, to be > allocated only to sites that have already received and continue to met a > utilization efficiency criterion in terms of connected publicly visible > hosts for an allocation of IPv6 space. > > Ideally I think the reservation be done not just by one RIR, but by all > RIRs, and IANA practices revised to set aside a good number of /8s of IPv4 > addresses as " reserved for allocation to users transitioning to IPv6". > > The reservations would make large blocks unavailable to users that have not > deployed IPv6, thereby motivating them to deploy IPv6 in order to draw from > the reserved block of addresses. > > It doesn't force anyone to deploy IPv6. In fact, they might use NAT for the > additional hosts, rather than get a bigger block of IPv4 space. > > It only discourages networks expanding (adding many hosts using public IPs) > without also obtaining IPv6 connectivity, to instead obtain IPv6 > connectivity at the best possible time -- while they are already expanding > their network. > > It creates a miniaturized version of the very same issue that in 4 years > will effect every network that's going to need to ask someone else for > additional IPv4 space after total exhaustion of the registry pools. > > And while it encourages IPv6, the policy wouldn't "force" it to be adopted > any more than exhaustion ultimately will. > > Essentially, in the name of encouraging a more long-term sustainable > practice, a smaller "pseudo-exhaustion" is spawned 1 to 2 years earlier, due > to the reservations. > > I assume that promotes greater stability than just a right out exhaustion, > as rapidly expanding networks will have adopted IPv6, and experience with > the pseudo-exhaustion will give people better experience in terms of > knowledge of what to expect when IPv4 eventually runs out. > > -- > -J From sleibrand at internap.com Fri Aug 3 18:17:42 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 03 Aug 2007 15:17:42 -0700 Subject: [ppml] Motivating migration to IPv6 In-Reply-To: <83999.1186178393@sa.vix.com> References: <200707311748.l6VHmwqP026867@s25.firmware.com> <6eb799ab0708021752x6d1b516ie112d4c80fec6f46@mail.gmail.com> <83999.1186178393@sa.vix.com> Message-ID: <46B3A986.8070000@internap.com> James, In order to submit this as a formal policy proposal, we'll need to work out what would be considered an acceptable utilization efficiency criterion (or criteria, as it may be different for allocations than for assignments). One possibility would be that, for each assignment or allocation out of the reserved pool, an equivalent number of hosts must have IPv6 connectivity available. So for example, if an end-user requests an additional /22 assignment and presents a justification of 1000 new hosts, they could demonstrate that they have assigned and routed IPv6 addresses to 1000 hosts. (If they have less than a /22 of existing IPv4 space, say a /23, they could perhaps instead demonstrate IPv6 rollout half as many hosts as have IPv4 connectivity.) Similarly, if an ISP requests an additional /20 allocation, they could demonstrate they have assigned and routed IPv6 subnets to customers representing a /20 worth of IP space. Thoughts? -Scott Paul Vixie wrote: > James, thanks for this, I am very intrigued with the good effects it could > have and the bad side effects it should not have, compared to other policy > proposals now under consideration. I hope that you will do further work on > it (see http://www.arin.net/policy/irpep.html for details) so that it can be > formally considered by the community. --Paul > > re: > > >> Date: Thu, 2 Aug 2007 19:52:52 -0500 >> From: "James Hess" >> To: ppml at arin.net >> Subject: Re: [ppml] Motivating migration to IPv6 >> Sender: ppml-bounces at arin.net >> >> ... Why not do the following? >> >> Reserve some IPv4 blocks, possibly including reclaimed blocks, to be >> allocated only to sites that have already received and continue to met a >> utilization efficiency criterion in terms of connected publicly visible >> hosts for an allocation of IPv6 space. >> >> Ideally I think the reservation be done not just by one RIR, but by all >> RIRs, and IANA practices revised to set aside a good number of /8s of IPv4 >> addresses as " reserved for allocation to users transitioning to IPv6". >> >> The reservations would make large blocks unavailable to users that have not >> deployed IPv6, thereby motivating them to deploy IPv6 in order to draw from >> the reserved block of addresses. >> >> It doesn't force anyone to deploy IPv6. In fact, they might use NAT for the >> additional hosts, rather than get a bigger block of IPv4 space. >> >> It only discourages networks expanding (adding many hosts using public IPs) >> without also obtaining IPv6 connectivity, to instead obtain IPv6 >> connectivity at the best possible time -- while they are already expanding >> their network. >> >> It creates a miniaturized version of the very same issue that in 4 years >> will effect every network that's going to need to ask someone else for >> additional IPv4 space after total exhaustion of the registry pools. >> >> And while it encourages IPv6, the policy wouldn't "force" it to be adopted >> any more than exhaustion ultimately will. >> >> Essentially, in the name of encouraging a more long-term sustainable >> practice, a smaller "pseudo-exhaustion" is spawned 1 to 2 years earlier, due >> to the reservations. >> >> I assume that promotes greater stability than just a right out exhaustion, >> as rapidly expanding networks will have adopted IPv6, and experience with >> the pseudo-exhaustion will give people better experience in terms of >> knowledge of what to expect when IPv4 eventually runs out. >> >> -- >> -J >> > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From sleibrand at internap.com Fri Aug 3 19:33:59 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 03 Aug 2007 16:33:59 -0700 Subject: [ppml] alternative realities (was PIv6 for legacy holders (/wRSA + efficient use)) In-Reply-To: <83517.1186100245@sa.vix.com> References: <46B21B27.8000106@internap.com> <99813.1186078321@sa.vix.com> <46B2248B.4010506@internap.com> <83517.1186100245@sa.vix.com> Message-ID: <46B3BB67.7010703@internap.com> Paul Vixie wrote: > i'm not getting through here. scott, there is no "we" in the "routing table > full" scenario. last time around "we" dodged the bullet because the network > was small, and CIDR was an easy way to accomodate future growth, and moore's > law was an easy way to cope with current growth. if pool depletion leads to > mass deaggregation and steps in the global table size, it'll be every network > for itself -- the ultimate assymetric cost:benefit equation -- a meltdown. > Perhaps we are understanding each other, but simply disagree about the dynamics of such a system. Perhaps it would be illustrative to look at mass deaggregation from the perspectives of some of the major types of players in the routing system: - From the perspective of a multihomed end-site network buying transit from two or more DFZ providers, "the Internet" is this big messy place "out there" that they'd like to be able to talk to. For inbound traffic, such a network will want to announce their route to all of their transit providers. If they have PI space, they'll expect those announcements to be propagated globally. If they are using PA space, they'll need their announcements to be accepted by both of their transit providers, both directly and indirectly, so that if their session to provider A goes down (or is de-preferred for TE), provider A will hear the announcement from provider B and route the traffic over the alternate path. For outbound traffic, routing can be pretty simple. If they have gear that supports it, they can get a full routing table from all of their transit providers, and do all sorts of cool things with that to manage outbound traffic. If their gear isn't quite that beefy, or deaggregation gets bad, they can take default routes from their transit providers, and possibly accept a number of BGP routes as well, but filter most of the rest of the mess and leave it up to their transit providers to know all the details. For this class of network, it's pretty easy to filter as much of the routing table as needed. - From the perspective of a multihomed ISP buying transit from one or more DFZ providers and selling full-BGP-feed transit to customers, many of their concerns will be the same as the multihomed end-site. In addition, however, the ISP has an incentive to carry a full, unfiltered BGP table, so that they don't lose any traffic from multihomed downstreams to a competitor announcing longer prefixes. For this class of network, the degree of filtering (of routes received from their transit providers) becomes a cost / revenue tradeoff. - For large, usually international, networks that do not buy transit (commonly referred to as "tier 1's"), the decision to filter is more costly still, and there is less ability to filter. Since they don't buy transit, such networks can only filter from peers, and since they don't have any default routes, they can only (safely) filter out subnets covered by a larger aggregate. If they do filter, and other tier 1's do not, then those other networks will likely end up carrying traffic to the filtered netblocks from networks that don't filter themselves. So, if we see mass deaggregation, I would expect filtering to progress something like this: - Multihomed end-sites would be the first to filter, either to the extreme (accepting only a default route) or more selectively. - As more multihomed end-sites begin filtering, the amount of traffic lost (by a filtering ISP to a non-filtering ISP with longer prefixes) would decrease. As deaggregation gets more severe, it would reduce the cost of filtering and increase the cost of not filtering, so more multihomed ISPs with transit would begin filtering, most likely on prefix-length, and may employ a default route to catch traffic to any long prefixes without a properly announced covering aggregate. - If this continues, then at some point tier 1 networks' incentives would also shift, just as the smaller ISPs' did, and they would begin to consider filtering longer prefixes heard from their peers. They would need to be careful that all filtered prefixes have a covering aggregate, as no default route would be available to route traffic to filtered prefixes. To preserve failover and TE, they would also need to ensure that, when they accept a route from a multihomed customer, they also accept that route (or a covering aggregate) from their peers. So, in conclusion, I see a set of incentives that, in case of massive deaggregation, would prompt most networks on the Internet to filter deaggregates (prefixes longer than the minimum assignment length) from their transit providers and peers, and accept them, directly and indirectly, from their paying customers. This would, in turn, ensure that DFZ operators would be able to charge their own customers for accepting most of the deaggregates in their own table. -Scott From billf at powerset.com Fri Aug 3 20:14:38 2007 From: billf at powerset.com (bill fumerola) Date: Fri, 3 Aug 2007 17:14:38 -0700 Subject: [ppml] Policy Proposal 2007-6 (was Re: More on Kremen/Cohen) In-Reply-To: References: <20070803004734.GA6522@ussenterprise.ufp.org> Message-ID: <20070804001438.GG42834@elvis.mu.org> On Fri, Aug 03, 2007 at 11:24:12AM -0700, Ted Mittelstaedt wrote: > So, did counsel ever comment on any past "shoot spammers dead on sight" > proposals? There had to have been at least one! :-) while counsel hasn't, the ARIN staff[1] and AC[2] have shot down a proposal - dead on sight - that changes the size of minimum allocation, using spammers as a scapegoat. that's not quite the same thing, though. -- bill 1. http://lists.arin.net/pipermail/ppml/2007-April/006601.html 2. http://lists.arin.net/pipermail/ppml/2007-April/006716.html From stephen at sprunk.org Fri Aug 3 21:31:01 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 3 Aug 2007 20:31:01 -0500 Subject: [ppml] Policy Proposal 2007-6 (was Re: More on Kremen/Cohen) References: <20070803004734.GA6522@ussenterprise.ufp.org> <20070804001438.GG42834@elvis.mu.org> Message-ID: <047a01c7d637$35cef750$543816ac@atlanta.polycom.com> Thus spake "bill fumerola" > On Fri, Aug 03, 2007 at 11:24:12AM -0700, Ted Mittelstaedt wrote: >> So, did counsel ever comment on any past "shoot spammers >> dead on sight" proposals? There had to have been at least one! :-) > > while counsel hasn't, the ARIN staff[1] and AC[2] have shot down a > proposal - dead on sight - that changes the size of minimum allocation, > using spammers as a scapegoat. > > that's not quite the same thing, though. The AC accepted the proposal, staff commented on it as they do every accepted proposal, and it was debated at the next meeting. It was not "shot down". I wasn't in attendance, but I was watching the live stream, and it appeared to me that the comments by staff substantively influenced the consensus at the last minute, i.e. a number of people that had intended to support it found themselves opposing it. The AC correctly determined that there was no remaining consensus in favor of the proposal (as opposed to a consensus against it), and didn't recommend it to the BoT for adoption. This is all within the defined process, and IMHO is exactly why we ask staff to comment on proposals. The attendees could have ignored staff's comments if they didn't find them credible. If so, and the BoT found that the problem was significant enough, they could have refused to implement it. Neither happened. It was the attendees, not the AC or staff, that ended up shooting 2007-6 down. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From owen at delong.com Sat Aug 4 01:15:39 2007 From: owen at delong.com (Owen DeLong) Date: Fri, 3 Aug 2007 22:15:39 -0700 Subject: [ppml] Policy Proposal 2007-6 (was Re: More on Kremen/Cohen) In-Reply-To: <20070804001438.GG42834@elvis.mu.org> References: <20070803004734.GA6522@ussenterprise.ufp.org> <20070804001438.GG42834@elvis.mu.org> Message-ID: <4C05513E-434C-4730-BF06-BD4EBBEB8DD9@delong.com> On Aug 3, 2007, at 5:14 PM, bill fumerola wrote: > On Fri, Aug 03, 2007 at 11:24:12AM -0700, Ted Mittelstaedt wrote: >> So, did counsel ever comment on any past "shoot spammers dead on >> sight" >> proposals? There had to have been at least one! :-) > > while counsel hasn't, the ARIN staff[1] and AC[2] have shot down a > proposal - dead on sight - that changes the size of minimum > allocation, > using spammers as a scapegoat. > I do not believe that ARIN staff shot down the proposal. I do believe that they expressed concerns about the proposal, some of which were specious in my opinion, but, nonetheless, I do not believe staff killed this proposal. While I did support the proposal, I honestly believe that the AC, faced with a 50/50 split in the room and a relatively even split argument on the mailing list leading up to the meeting did not have any way to consider that there was consensus. I do believe that the AC should have opted to work with the author on a redraft addressing the concerns expressed, and, I believe that we will eventually see a proposal which addresses these needs and these concerns in the future. Such a proposal may be limited to IPv6, however, by the time it sees the light of day. I do hope it comes sooner. > that's not quite the same thing, though. > > -- bill > > 1. http://lists.arin.net/pipermail/ppml/2007-April/006601.html > 2. http://lists.arin.net/pipermail/ppml/2007-April/006716.html > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Owen From sleibrand at internap.com Sat Aug 4 14:42:13 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 04 Aug 2007 11:42:13 -0700 Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: <46B0723E.7080301@psg.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> Message-ID: <46B4C885.5030904@internap.com> For anyone who missed it, Randy's link below is a policy proposal currently being discussed by APNIC's PPML equivalent (sig-policy) that would create a regulated market in IPv4 addresses, and would allow APNIC IP space to be divided up and transferred in blocks as small as /24. Anyone who's interested in that topic may want to read the sig-policy mailing list archives (http://www.apnic.net/mailing-lists/sig-policy/). -Scott Randy Bush wrote: > http://www.apnic.net/docs/policy/proposals/prop-050-v001.html > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From woody at pch.net Sat Aug 4 14:47:02 2007 From: woody at pch.net (Bill Woodcock) Date: Sat, 4 Aug 2007 11:47:02 -0700 (PDT) Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: <46B4C885.5030904@internap.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <88234.1185818363@sa.vix.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> <46B4C885.5030904@internap.com> Message-ID: On Sat, 4 Aug 2007, Scott Leibrand wrote: > A policy proposal currently being discussed by APNIC's PPML > equivalent (sig-policy) would create a regulated market in IPv4 > addresses. Uh, actually an _unregulated_ market, which is the bone of contention. " ...proposal to _remove_ APNIC policy restrictions on the transfer of registration of IPv4 address allocations... " -Bill From sleibrand at internap.com Sat Aug 4 15:05:45 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 04 Aug 2007 12:05:45 -0700 Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> <46B4C885.5030904@internap.com> Message-ID: <46B4CE09.2090901@internap.com> Bill Woodcock wrote: > On Sat, 4 Aug 2007, Scott Leibrand wrote: > > A policy proposal currently being discussed by APNIC's PPML > > equivalent (sig-policy) would create a regulated market in IPv4 > > addresses. > > Uh, actually an _unregulated_ market, which is the bone of contention. > > " ...proposal to _remove_ APNIC policy restrictions on the > transfer of registration of IPv4 address allocations... " > The regulation I'm referring to are the conditions on the IPv4 address block and on the source and recipients of the transfer. I agree that the proposed regulation is rather weak, and is *much* weaker than present regulations on address transfer. -Scott From drc at virtualized.org Sat Aug 4 16:51:39 2007 From: drc at virtualized.org (David Conrad) Date: Sat, 4 Aug 2007 13:51:39 -0700 Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: <46B4CE09.2090901@internap.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org> <24940.1185829923@sa.vix.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> <46B4C885.5030904@internap.com> <46B4! CE09.2090901@internap.com> Message-ID: On Aug 4, 2007, at 12:05 PM, Scott Leibrand wrote: > Bill Woodcock wrote: >> On Sat, 4 Aug 2007, Scott Leibrand wrote: >>> A policy proposal currently being discussed by APNIC's PPML >>> equivalent (sig-policy) would create a regulated market in IPv4 >>> addresses. >> >> Uh, actually an _unregulated_ market, which is the bone of >> contention. >> >> " ...proposal to _remove_ APNIC policy restrictions on the >> transfer of registration of IPv4 address allocations... " >> > > The regulation I'm referring to are the conditions on the IPv4 address > block and on the source and recipients of the transfer. I agree that > the proposed regulation is rather weak, and is *much* weaker than > present regulations on address transfer. I would be curious to know real world experiences of folks who exercise section 8 of the NPRM. Also, does anyone believe ISPs are going to remove the filters that implicitly limit the length of a usable (for the purposes of highest likelihood of global routability) IPv4 prefix to a /24? If so, why? Rgds, -drc From sleibrand at internap.com Sat Aug 4 17:22:23 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 04 Aug 2007 14:22:23 -0700 Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> <46B4C885.5030904@internap.com> <46B4! CE09.2090901@internap.com> Message-ID: <46B4EE0F.6050508@internap.com> David Conrad wrote: > I would be curious to know real world experiences of folks who > exercise section 8 of the NPRM. We recently transfered some IP space and ASNs from a company we acquired, and the process wasn't too difficult, once we got the appropriate internal folks involved to come up with the documents showing legal proof of the acquisition. > > Also, does anyone believe ISPs are going to remove the filters that > implicitly limit the length of a usable (for the purposes of highest > likelihood of global routability) IPv4 prefix to a /24? If so, why? I don't think anyone expects the default maximum prefix length accepted to get longer than /24 any time soon. The problem I see with prop-050 is that it bypasses the APNIC minimum allocation length (usually /20 or /21, sometimes /22) and allows allocations to be carved up into /24's and sold. If we see that actually happening, it will be much more difficult in the future to appropriately filter deaggregates (/24's, /23's, etc.) if the IPv4 routing table grows to the point that networks want to do so. -Scott From iljitsch at muada.com Sat Aug 4 18:23:11 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 5 Aug 2007 00:23:11 +0200 Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: <46B4EE0F.6050508@internap.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> <46B4C885.5030904@internap.com> <46B4! CE09.2090901@internap.com> Message-ID: <5C51EA1A-C01A-40B7-98A3-D829FEDEC90D@muada.com> On 4-aug-2007, at 23:22, Scott Leibrand wrote: > I don't think anyone expects the default maximum prefix length > accepted > to get longer than /24 any time soon. The problem I see with prop-050 > is that it bypasses the APNIC minimum allocation length (usually / > 20 or > /21, sometimes /22) and allows allocations to be carved up into /24's > and sold. If we see that actually happening, it will be much more > difficult in the future to appropriately filter deaggregates (/24's, > /23's, etc.) if the IPv4 routing table grows to the point that > networks > want to do so. In the RIPE region, I get a /21 when I become a LIR. For the purpose of this discussion, assuming something similar in the APNIC region. So what if I sell off 4 /24s to different people, use the other 4 myself and come back for more? Is APNIC going to hold me responsible for the use of those /24s that I sold? What if I request a /8 because I can sell 65000 /24s? From sleibrand at internap.com Sat Aug 4 18:24:57 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 04 Aug 2007 15:24:57 -0700 Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: <5C51EA1A-C01A-40B7-98A3-D829FEDEC90D@muada.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> <46B4C885.5030904@internap.com> <46B4! CE09.2090901@internap.com> <5C51EA1A-C01A-40B7-98A3-D829FEDEC90D@muada.com> Message-ID: <46B4FCB9.9010807@internap.com> Iljitsch van Beijnum wrote: > On 4-aug-2007, at 23:22, Scott Leibrand wrote: > >> I don't think anyone expects the default maximum prefix length accepted >> to get longer than /24 any time soon. The problem I see with prop-050 >> is that it bypasses the APNIC minimum allocation length (usually /20 or >> /21, sometimes /22) and allows allocations to be carved up into /24's >> and sold. If we see that actually happening, it will be much more >> difficult in the future to appropriately filter deaggregates (/24's, >> /23's, etc.) if the IPv4 routing table grows to the point that networks >> want to do so. > > In the RIPE region, I get a /21 when I become a LIR. For the purpose > of this discussion, assuming something similar in the APNIC region. So > what if I sell off 4 /24s to different people, use the other 4 myself > and come back for more? Is APNIC going to hold me responsible for the > use of those /24s that I sold? What if I request a /8 because I can > sell 65000 /24s? Take a look at the policy proposal. There's a 24-month waiting period for people who sell addresses. -Scott From iljitsch at muada.com Sat Aug 4 18:40:04 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 5 Aug 2007 00:40:04 +0200 Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: <46B4FCB9.9010807@internap.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> <46B4C885.5030904@internap.com> <46B4! CE09.2090901@internap.com> <5C51EA1A-C01A-40B7-98A3-D829FEDEC90D@muada.com> <46! B4FCB9.9010807@internap.com> Message-ID: On 5-aug-2007, at 0:24, Scott Leibrand wrote: > Take a look at the policy proposal. There's a 24-month waiting > period for people who sell addresses. I think this is a bad proposal. The legitimate needs that this proposal wants to serve can more easily be accommodated as follows: 1. The prospective new holder of the addresses requests address space under the regular rules 2. The prospective new holder is granted a certain amount of address space 3. The prospective new holder asks to receive the amount of address space granted in the form of the address blocks in question 4. RIR asks old holder if they're willing to give up the address space under the condition that it will be assigned to the prospective new holder 5. If no, nothing 6. If yes, addresses go back to RIR, RIR gives them to new holder This would allow a market to form once IPv4 address space is depleted, but not before. But the important difference is that in all cases, the new holder is subject to the current rules. I.e., you can't transfer a legacy /16 to an organization that only needs a /24. (Which of course sucks if you want the transfer because you have a server on 172.31.0.1 and another on 172.31.255.254 without anything in the middle, but hey, sometimes life sucks.) From info at arin.net Mon Aug 6 10:51:44 2007 From: info at arin.net (Member Services) Date: Mon, 06 Aug 2007 10:51:44 -0400 Subject: [ppml] Outcome of Community Consultation: ARIN WHOIS Directory Services Message-ID: <46B73580.9090904@arin.net> The result of Suggestion 2007.15, sent through the ARIN Consultation and Suggestion Process and asking for ARIN WHOIS to accept CIDR style queries, was an ARIN community consultation on enhancements to this directory service. The archive of the consultation mailing list discussion is available at: http://www.arin.net/acsp/community_consult/23-07-2007_WhoisDirectoryService.html We thank those who provided valuable feedback during this consultation. This feedback will be used to develop the WHOIS improvement project. We anticipate beginning work on this project in the 1st quarter of 2008. Regards, Member Services American Registry for Internet Numbers (ARIN) From kloch at kl.net Mon Aug 6 11:21:35 2007 From: kloch at kl.net (Kevin Loch) Date: Mon, 06 Aug 2007 11:21:35 -0400 Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> <46B4C885.5030904@internap.com> <46B4! CE09.2090901@internap.com> Message-ID: <46B73C7F.9090401@kl.net> David Conrad wrote: > Also, does anyone believe ISPs are going to remove the filters that > implicitly limit the length of a usable (for the purposes of highest > likelihood of global routability) IPv4 prefix to a /24? If so, why? I hope not, and if subdivision/deaggregation gets bad enough we will see filters tighten. In a worst case scenario we filter at /20 across the board and anyone using longer prefix gets to move. - Kevin From paul at vix.com Mon Aug 6 12:20:54 2007 From: paul at vix.com (Paul Vixie) Date: Mon, 06 Aug 2007 16:20:54 +0000 Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: Your message of "Mon, 06 Aug 2007 11:21:35 -0400." <46B73C7F.9090401@kl.net> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> <46B4C885.5030904@internap.com> <46B4! CE09.2090901@internap.com> < 46B73C7F.9090401@kl.net> Message-ID: <22649.1186417254@sa.vix.com> > > Also, does anyone believe ISPs are going to remove the filters that > > implicitly limit the length of a usable (for the purposes of highest > > likelihood of global routability) IPv4 prefix to a /24? If so, why? > > I hope not, and if subdivision/deaggregation gets bad enough we will see > filters tighten. In a worst case scenario we filter at /20 across > the board and anyone using longer prefix gets to move. what would you have f.root-servers.org do in that case? our IPv4 address is in a /24, and our IPv6 address is in a /48. even apart from the question of how long it takes to renumber a root name server, where would you like us to move? we have other address blocks but those other blocks aren't anycast. paul ps. not speaking as an arin trustee. From sleibrand at internap.com Mon Aug 6 12:29:27 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 06 Aug 2007 09:29:27 -0700 Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: <22649.1186417254@sa.vix.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> <46B4C885.5030904@internap.com> <46B4! CE09.2090901@internap.com> < 46B73C7F.9090401@kl.net> <22649.1186417254@sa.vix.com> Message-ID: <46B74C67.6090303@internap.com> Paul Vixie wrote: >>> Also, does anyone believe ISPs are going to remove the filters that >>> implicitly limit the length of a usable (for the purposes of highest >>> likelihood of global routability) IPv4 prefix to a /24? If so, why? >>> >> I hope not, and if subdivision/deaggregation gets bad enough we will see >> filters tighten. In a worst case scenario we filter at /20 across >> the board and anyone using longer prefix gets to move. >> > > what would you have f.root-servers.org do in that case? our IPv4 address > is in a /24, and our IPv6 address is in a /48. even apart from the question > of how long it takes to renumber a root name server, where would you like us > to move? we have other address blocks but those other blocks aren't anycast. > For that and many other reasons, it would make much more sense (in the worst case scenario) for everyone to filter according to the minimum allocation size for each IPv4 /8, as published by the RIRs (i.e. http://www.arin.net/reference/ip_blocks.html and http://www.apnic.net/db/min-alloc.html). -Scott From dlw+arin at tellme.com Mon Aug 6 12:39:09 2007 From: dlw+arin at tellme.com (David Williamson) Date: Mon, 6 Aug 2007 09:39:09 -0700 Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: <46B74C67.6090303@internap.com> References: <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> <46B4C885.5030904@internap.com> <46B4!CE09.2090901@internap.com> <46B73C7F.9090401@kl.net> <22649.1186417254@sa.vix.com> <46B74C67.6090303@internap.com> Message-ID: <20070806163909.GB28754@shell01.cell.sv2.tellme.com> On Mon, Aug 06, 2007 at 09:29:27AM -0700, Scott Leibrand wrote: > For that and many other reasons, it would make much more sense (in the > worst case scenario) for everyone to filter according to the minimum > allocation size for each IPv4 /8, as published by the RIRs (i.e. > http://www.arin.net/reference/ip_blocks.html and > http://www.apnic.net/db/min-alloc.html). A great idea, but won't they put more value on swamp class C networks? I can't think of a better way to drive value for a black/white market in ip space than to differentiate some of it. I'll also note that this sort of thing will have greater impact on younger organizations. The consipracy theory types might look at sliding the effective routing boundary towards shorter prefixes as a sign that the older/larger organizations are trying to retain control over the Internet. I don't think that's intentionally the case, but it's wasy to see it that way. -David From owen at delong.com Mon Aug 6 12:58:38 2007 From: owen at delong.com (Owen DeLong) Date: Mon, 6 Aug 2007 09:58:38 -0700 Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: <20070806163909.GB28754@shell01.cell.sv2.tellme.com> References: <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> <46B4C885.5030904@internap.com> <46B4!CE09.2090901@internap.com> <46B73C7F.9090401@kl.net> <22649.1186417254@sa.vix.com> <46B74C67.6090303@internap.com> <20070806163909.GB28754@shell01.cell.sv2.tellme.com> Message-ID: Thus spake dlw at tellme.com: > A great idea, but won't they put more value on swamp class C networks? > I can't think of a better way to drive value for a black/white market > in ip space than to differentiate some of it. I fear that if we do not get a good portion of the legacy holders into some form of RSA with ARIN, such a black market in swamp space is an inevitable result. Further, I think you will see varying policies by ISPs towards blocking large portions of swamp space just because they can't reliably predict what is or isn't a valid address there. Despite comments from the detractors who think that I am (pick one): 1. A legacy apologist (whatever that means) 2. Out to inflict ARIN evil on legacy address holders (goes well with the first one, doesn't it?) 3. Trying to back-door permanent status for address squatters 4. Trying to undermine ARINs ability to deal with the legacy issue My real motivation, actually, is to try and create good policy which is fair and balanced, but, allows legacy address holders and ARIN to come to a mutual understanding which allows ARIN to provide good solid registration services to legacy holders in a manner that is not punitive to ARIN, legacy holders, or the ARIN membership. I firmly support efforts towards outreach to legacy holders. I am willing to accept that legacy holders are less likely to agree to annual fees, but, I think that agreeing to an annual contact refresh might be acceptable to most. As such, I support and will continue to support policy that enables that. I believe that legacy holders view some of the revocation and open-ended modification at any time without notice provisions of the RSA as a threat and a detriment compared to their existing status. As such, I believe it is to the benefit of the ARIN community to be able to identify legacy holders reliably and maintain contact with them on a regular basis such that defunct address registrations can be reclaimed and removed from whois to prevent hijacking and abuse. Therefore, I support the idea of an ARIN RSA for legacy holders which preserves their current status to whatever extent is feasible, but, at least requires annual contact refresh with ARIN and provides mecahnisms for ARIN to reliably determine if the addresses are no longer needed. I have written and submitted policy language to this effect. While I received notification from the AC that the submitted policy was not accepted as a formal proposal, neither the shepherds, nor any other members of the AC have yet contacted me with any of the reasons for this decision. I am open to suggestions from others, and, willing to support policies proposed by others that I believe work towards the above defined goals. Owen From sleibrand at internap.com Mon Aug 6 13:07:06 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 06 Aug 2007 10:07:06 -0700 Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: <20070806163909.GB28754@shell01.cell.sv2.tellme.com> References: <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> <46B4C885.5030904@internap.com> <46B4!CE09.2090901@internap.com> <46B73C7F.9090401@kl.net> <22649.1186417254@sa.vix.com> <46B74C67.6090303@internap.com> <20070806163909.GB28754@shell01.cell.sv2.tellme.com> Message-ID: <46B7553A.4060908@internap.com> David Williamson wrote: > On Mon, Aug 06, 2007 at 09:29:27AM -0700, Scott Leibrand wrote: > >> For that and many other reasons, it would make much more sense (in the >> worst case scenario) for everyone to filter according to the minimum >> allocation size for each IPv4 /8, as published by the RIRs (i.e. >> http://www.arin.net/reference/ip_blocks.html and >> http://www.apnic.net/db/min-alloc.html). >> > > A great idea, but won't they put more value on swamp class C networks? > I can't think of a better way to drive value for a black/white market > in ip space than to differentiate some of it. > I would note that the class C swamp isn't listed on these pages. Where/how to filter legacy classful space is left as an exercise for future operators... -Scott From randy at psg.com Mon Aug 6 13:45:01 2007 From: randy at psg.com (Randy Bush) Date: Mon, 06 Aug 2007 07:45:01 -1000 Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: <46B74C67.6090303@internap.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> <46B4C885.5030904@internap.com> <46B4! CE09.2090901@internap.com> < 46B73C7F.9090401@kl.net> <22649.1186417254@sa.vix.com> <46B74C67.6090303@internap.com > Message-ID: <46B75E1D.8020003@psg.com> [ my allowed by bill one post for the day ] > it would make much more sense (in the worst case scenario) for > everyone to filter according to the minimum allocation size for each > IPv4 /8, as published by the RIRs (i.e. > http://www.arin.net/reference/ip_blocks.html and > http://www.apnic.net/db/min-alloc.html). i may have been the last satanic phyltre nazi to do that. it collapsed under financial pressure from sales and marketing within months of my leaving verio. in today's and tomorrow's world it will collapse under sales and marketing pressure as soon as someone big enough announces a /29 and starts calling folk well above your pay grade. randy From iljitsch at muada.com Mon Aug 6 13:49:32 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 6 Aug 2007 19:49:32 +0200 Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: <46B74C67.6090303@internap.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> <46B4C885.5030904@internap.com> <46B4! CE09.2090901@internap.com> < 46B73C7F.9090401@kl.net> <22649.1186417254@sa.vix.com>! <46B74C67.6090303@internap.com> Message-ID: <0FDE7374-1422-4224-B937-15A42ABF0C65@muada.com> On 6-aug-2007, at 18:29, Scott Leibrand wrote: > For that and many other reasons, it would make much more sense (in the > worst case scenario) for everyone to filter according to the minimum > allocation size for each IPv4 /8, as published by the RIRs (i.e. > http://www.arin.net/reference/ip_blocks.html and > http://www.apnic.net/db/min-alloc.html). Unfortunately, the RIRs, don't bother making this actually useful. Worst offender is RIPE. They say that the longest prefix for 91/8, 193/8 and 194/8 is a /29. Filtering on this still allows for 6 million routes, which will kill any router that I've ever heard of. 91/8 only has /24 and bigger, 193/8 has 8 /29s and 194/8 4 /28s. (Total number of prefixes < /24 is 79, all from RIPE.) What would need to happen is that only a single prefix length is allocated from any given block. This means no longer reserving adjoining space for future growth, but this doesn't help aggregation in practice anyway so it's no big loss. From leo.vegoda at icann.org Mon Aug 6 14:46:46 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 6 Aug 2007 20:46:46 +0200 Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: <0FDE7374-1422-4224-B937-15A42ABF0C65@muada.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> <46B4C885.5030904@internap.com> <46B4! CE09.2090901@internap.com> < 46B73C7F.9090401@kl.net> <22649.1186417254@sa.vix.com>! ! <46B74C67.6090303@internap.com> <0FDE7374-1422-4224-B937-15A42ABF0C65@muada.com> Message-ID: <4ECF81FD-2083-43B1-86FE-079F9BCAA85D@icann.org> On 6 Aug 2007, at 19:49, Iljitsch van Beijnum wrote: [...] > What would need to happen is that only a single prefix length is > allocated from any given block. This means no longer reserving > adjoining space for future growth, but this doesn't help aggregation > in practice anyway so it's no big loss. It would obviously make things far simpler for anyone writing filters. It's a shame that it's not a practical proposition. Regards, Leo Vegoda From iljitsch at muada.com Mon Aug 6 15:09:26 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 6 Aug 2007 21:09:26 +0200 Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: <4ECF81FD-2083-43B1-86FE-079F9BCAA85D@icann.org> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> <46B4C885.5030904@internap.com> <46B4! CE09.2090901@internap.com> < 46B73C7F.9090401@kl.net> <22649.1186417254@sa.vix.com>! ! ! <46B74C67.6090303@internap.com> <0FDE7374-1422-4224-B937-15A42ABF0C65@muada.com> <4ECF81FD-2083-43B1-86FE-079F9BCAA85D@icann.org> Message-ID: <404C09E8-334E-4B28-9020-7B8715B6840C@muada.com> On 6-aug-2007, at 20:46, Leo Vegoda wrote: >> What would need to happen is that only a single prefix length is >> allocated from any given block. This means no longer reserving >> adjoining space for future growth, but this doesn't help aggregation >> in practice anyway so it's no big loss. > It would obviously make things far simpler for anyone writing > filters. It's a shame that it's not a practical proposition. Hm, the other RIRs don't seem to need to reserve 3 /8s for giving out /29s. Or give out ANYTHING longer than a /24, for that matter. Take your pick: solve the problems in human space in human time, or in forwarding planes on nanosecond scale time. From tedm at ipinc.net Mon Aug 6 18:06:45 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 6 Aug 2007 15:06:45 -0700 Subject: [ppml] APNIC policy proposal to create a regulated market inIPv4 addresses In-Reply-To: <22649.1186417254@sa.vix.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Paul Vixie >Sent: Monday, August 06, 2007 9:21 AM >To: Public Policy Mailing List >Subject: Re: [ppml] APNIC policy proposal to create a regulated market >inIPv4 addresses > > >> > Also, does anyone believe ISPs are going to remove the filters that >> > implicitly limit the length of a usable (for the purposes of highest >> > likelihood of global routability) IPv4 prefix to a /24? If so, why? >> >> I hope not, and if subdivision/deaggregation gets bad enough we will see >> filters tighten. In a worst case scenario we filter at /20 across >> the board and anyone using longer prefix gets to move. > >what would you have f.root-servers.org do in that case? our IPv4 address >is in a /24, and our IPv6 address is in a /48. even apart from >the question >of how long it takes to renumber a root name server, where would >you like us >to move? we have other address blocks but those other blocks >aren't anycast. > Well, he's being an idiot but that doesen't mean the rest of us would. A /20 filter would be interesting - in practice, of course, you would have to exempt all of the -important- places that are advertising under that - such as f.root-servers.org, for example. That's not "across-the-board" of course, but it might get the job done for a while. Ted From tedm at ipinc.net Mon Aug 6 18:15:50 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 6 Aug 2007 15:15:50 -0700 Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: <46B75E1D.8020003@psg.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Randy Bush >Sent: Monday, August 06, 2007 10:45 AM >To: Scott Leibrand >Cc: Public Policy Mailing List >Subject: Re: [ppml] APNIC policy proposal to create a regulated market >in IPv4 addresses > > >[ my allowed by bill one post for the day ] > >> it would make much more sense (in the worst case scenario) for >> everyone to filter according to the minimum allocation size for each >> IPv4 /8, as published by the RIRs (i.e. >> http://www.arin.net/reference/ip_blocks.html and >> http://www.apnic.net/db/min-alloc.html). > >i may have been the last satanic phyltre nazi to do that. it collapsed >under financial pressure from sales and marketing within months of my >leaving verio. > >in today's and tomorrow's world it will collapse under sales and >marketing pressure as soon as someone big enough announces a /29 and >starts calling folk well above your pay grade. > No it wouldn't. The people writing the filter would make an exception for the /29 and life would go on. What -would- eventually collapse is if a whole -lot- of bigger, richer fish started announcing /29s. Eventually you would have to push back on to those sales and financial people the following cold facts: 1) We need a set of bigger, more expensive, more powerful routers 2) We need to devote a 6-figure-salary network engineer full time to maintaining the filters in the bigger, more expensive, and more powerful routers. (adding in those /29's) Your sales and marketing people would probably welcome it, that is, if your someone like Verio. Because they would figure that if Verio has to spend this kind of money that all Verio's competitors would have to do so as well. And Verio has more money so the other competitors would die first. This is kind of like the Ronald Reagan view of how to defeat Russia in the Cold War. Outspend them. I don't know if it worked, but it sure gave us some awfully big budget deficits. Ted From tedm at ipinc.net Mon Aug 6 18:36:27 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 6 Aug 2007 15:36:27 -0700 Subject: [ppml] APNIC policy proposal to create a regulated market inIPv4 addresses In-Reply-To: Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Owen DeLong >Sent: Monday, August 06, 2007 9:59 AM >To: David Williamson >Cc: Public Policy Mailing List >Subject: Re: [ppml] APNIC policy proposal to create a regulated market >inIPv4 addresses > > >Thus spake dlw at tellme.com: > >> A great idea, but won't they put more value on swamp class C networks? >> I can't think of a better way to drive value for a black/white market >> in ip space than to differentiate some of it. > >I fear that if we do not get a good portion of the legacy holders >into some form >of RSA with ARIN, such a black market in swamp space is an inevitable >result. As swamp space is only IPv4, and IPv4 will eventually die sooner or later, this black market will end up being nothing more than an interesting historical footnote. Much like the profiteering during the US Civil War, a bunch of people made a bunch of money on a market that doesen't exist now, and nobody cares anymore. >Further, I think you will see varying policies by ISPs towards >blocking large >portions of swamp space just because they can't reliably predict what >is or >isn't a valid address there. > And the swamp space holders can renumber into IPv6 and why is this a problem...? >Despite comments from the detractors who think that I am (pick one): > > 1. A legacy apologist (whatever that means) > 2. Out to inflict ARIN evil on legacy address holders >(goes well > with the first one, doesn't it?) > 3. Trying to back-door permanent status for address squatters ding ding ding! Seriously, I'm perfectly willing for you to have permanent status for your IPv4 address squatters. Since the squatters are only squatting on IPv4 that is just one more nail in the IPv4 coffin. > 4. Trying to undermine ARINs ability to deal with the >legacy issue > >My real motivation, actually, is to try and create good policy which is >fair and balanced, but, allows legacy address holders and ARIN to >come to a mutual understanding which allows ARIN to provide good >solid registration services to legacy holders in a manner that is >not punitive to ARIN, legacy holders, or the ARIN membership. > ARIN is already providing good solid registration services to IPv4 legacy holders. What, pray tell, is deficit? Do you want the ability for legacy holders to sell IPv4? OK not a problem - the purchaser will of course have to sign an RSA and start paying fees to the RIR for the registration to be changed so it's not any real difference than if the purchaser got the IPv4 numbering from the RIR in the first place. If the purchaser cannot show justification to ARIN for the block they bought, then as they say, they just bought a pig-in-a-poke. It's like buying a car with a missing title - you may have the actual car and can even drive it around and use it, but if you get pulled over you get a ticket for no registration. Similarly, if a legacy holder "sells" a block to someone who cannot provide ARIN justification, and thus cannot sign an RSA, the purchaster may find themselves blocked by the various netcops. >I firmly support efforts towards outreach to legacy holders. > >I am willing to accept that legacy holders are less likely to agree to >annual fees, but, I think that agreeing to an annual contact >refresh might be acceptable to most. As such, I support and will >continue to support policy that enables that. > I don't. The community has determined the legacy holders are getting their IPv4 for free. Until there is the will to change this, there is no point in having the legacy holders do anything other than keeping their contact info current. >I believe that legacy holders view some of the revocation and >open-ended modification at any time without notice provisions >of the RSA as a threat and a detriment compared to their existing >status. Probably. But since they have to accept these clauses to get any IPv6, I don't see the issue here... As such, I believe it is to the benefit of the ARIN >community to be able to identify legacy holders reliably and >maintain contact with them on a regular basis such that >defunct address registrations can be reclaimed and removed >from whois to prevent hijacking and abuse. Therefore, I support >the idea of an ARIN RSA for legacy holders which preserves their >current status to whatever extent is feasible, but, at least requires >annual contact refresh with ARIN and provides mecahnisms for >ARIN to reliably determine if the addresses are no longer needed. > It's much simpler to simply have ARIN attempt to contact the legacy holder addresses that the legacy holders have submitted, and if the address is old and bogus, then revoke the block. The entire reason for the contact info being current is so that members of the community can contact the IP block holder if there is a problem. Thus if the published contact info isn't good enough to do this, then the legacy holder shouldn't have the block assigned any longer. If it is good enough for the community to contact the legacy holder, it's good enough for ARIN to contact the legacy holder. Ted From arin-contact at dirtside.com Mon Aug 6 19:01:49 2007 From: arin-contact at dirtside.com (William Herrin) Date: Mon, 6 Aug 2007 19:01:49 -0400 Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: <46B73C7F.9090401@kl.net> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> <46B4C885.5030904@internap.com> <46B73C7F.9090401@kl.net> Message-ID: <3c3e3fca0708061601p20be2a9fud9b4384b578c23d1@mail.gmail.com> On 8/6/07, Kevin Loch wrote: > In a worst case scenario we filter at /20 across > the board and anyone using longer prefix gets to move. Kevin, I wouldn't bank on it. There are relatively few scenarios where a financially healthy DFZ participant who isn't right at the edge of the DFZ (where its easy to add a default route) chooses to filter prefixes at /23 or shorter instead of buying newer routers. Sure we'll threaten to filter. Some of us will actually implement provisional filtering. Then the sales folk will ask us to look in to why the very upset Mr. Big Customer can't stream mp3s from bobsgarageband.com at work even though it works fine on his cable modem at home. That'll bring us face to face with the harsh reality that ram is cheap and finding customers isn't. YFRV already foresees this and has prepared a product line just for us. What's more likely IMO is that if he hasn't already, your favorite router vendor will tweak BGP and reorder large updates so that shorter prefixes converge first. Folks on /24's will suffer a longer outage during convergence than folks on a /16, but the routes will all be honored. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From michel at arneill-py.sacramento.ca.us Tue Aug 7 00:16:21 2007 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 6 Aug 2007 21:16:21 -0700 Subject: [ppml] alternative realities In-Reply-To: <29320.1186035346@sa.vix.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com><88234.1185818363@sa.vix.com><0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org><24940.1185829923@sa.vix.com><12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org><71643.1185845108@sa.vix.com><46AE90C6.8060406@psg.com><83945.1185848565@sa.vix.com><1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org><93896.1185947387@sa.vix.com><3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com><63550.1185986123@sa.vix.com><58568.1186010437@sa.vix.com><46B11794.50907@internap.com><60331.1186011986@sa.vix.com><46B1204B.4050707@internap.com> <1248.1186025991@sa.vix.com> <29320.1186035346@sa.vix.com> Message-ID: >> Someone explains me again why I should spend money to upgrade to IPv6? > Paul Vixie wrote: > the connectivity community of which you are a part needs IPv6, though. Nope. Voice does not need IPv6, and the only hosts I care to connect directly: a) are in the US with 4 IPv4 addresses per capita which is enough for the rest of my life and b) use apps that work behind double nat anyway. > and you don't need SIP to work SIP is a protocol that was designed to demonstrate that NAT was breaking things. Point well taken: it is broken. I use Skype. It's survival of the fittest, aka evolution. Paul, your arguments are 10 years old. Something else than this broken record, please. The launch window for IPv6 was 5 years ago. > Joel Jaeggli wrote: > Your 3g cellphone provider will have 50-100 million ip speaking > devices on your network to manage at some point in the near future That's an oldie too. Besides, it's not my problem. IP packet transport is a commodity, and cell phone providers will provide what I want: IPv4. I am not upgrading while there still is bickering about PI, ULAs, policies, etc. Furthermore, I would definitely not upgrade if the large operator folk had it their way with the 4K DMZ and no PI whatsoever. Michel. From leo.vegoda at icann.org Tue Aug 7 03:19:49 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 7 Aug 2007 09:19:49 +0200 Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: <404C09E8-334E-4B28-9020-7B8715B6840C@muada.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> <46B4C885.5030904@internap.com> <46B4! CE09.2090901@internap.com> < 46B73C7F.9090401@kl.net> <22649.1186417254@sa.vix.com>! ! ! ! <46B74C67.6090303@internap.com> <0FDE7374-1422-4224-B937-15A42ABF0C65@muada.com> <4ECF81FD-2083-43B1-86FE-079F9BCAA85D@icann.org> <404C09E8-334E-4B28-9020-7B8715B6840C@muada.com> Message-ID: <64243F13-9D87-413C-84C7-1042CB91B56E@icann.org> On 6 Aug 2007, at 21:09, Iljitsch van Beijnum wrote: > On 6-aug-2007, at 20:46, Leo Vegoda wrote: > >>> What would need to happen is that only a single prefix length is >>> allocated from any given block. This means no longer reserving >>> adjoining space for future growth, but this doesn't help aggregation >>> in practice anyway so it's no big loss. > >> It would obviously make things far simpler for anyone writing >> filters. It's a shame that it's not a practical proposition. > > Hm, the other RIRs don't seem to need to reserve 3 /8s for giving > out /29s. Or give out ANYTHING longer than a /24, for that matter. > > Take your pick: solve the problems in human space in human time, or > in forwarding planes on nanosecond scale time. I don't disagree with the goal you've described. If it's important to you then I suggest you complete this template: http://www.ripe.net/ripe/policies/proposals/template/ and pass it to the RIPE Address Policy WG chairs so that they can put it into the policy development process. You may find that discussing RIPE issues on the RIPE mailing lists is a more effective way of resolving the problems with the RIPE NCC. Regards, Leo Vegoda From BillD at cait.wustl.edu Tue Aug 7 09:36:06 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 7 Aug 2007 08:36:06 -0500 Subject: [ppml] On proposing ARIN policy - was RE: More on Kremen/Cohen In-Reply-To: <02d901c7d607$d7112a50$543816ac@atlanta.polycom.com> Message-ID: Of course everyone is encouraged to become involved with the ARIN public policy process and likewise everyone is encouraged to consider policy changes or additions that they think would improve their lot or the lot of the industry at large. I do suggest however that the ppml is the place to 'test' the reception that a policy proposal is likely to receive from the industry at large. It is, of course, industry consensus that is needed to move a proposal to the Board of Trustees for ratification. Making a formal proposal at the link provided by Stephen below, when a proposal first comes to mind will cause the Internet Resource Policy Evaluation Process (IRPEP http://www.arin.net/policy/irpep.html) to formally engage. Advisory Council members are then assigned to 'shepherd' these proposals through the IRPEP. Engaging the formal process is always available, but may not be in the best interest of the proposal author(s). If ideas are first introduced on the ppml then those ideas that receive significant negative feedback and/or constructive criticism on the ppml can be re-evaluated and insight might be gained on how to best craft a proposal for submission to ARIN and thus stand the best chance of being understandable, incorporate improvements proposed by a broader group, and be well-received by the industry. I encourage people with 'ideas' to submit them to the ppml and I encourage participants on the ppml to always give fair consideration to these ideas, offer constructive advice, and state clearly whether you are FOR or AGAINST these ideas. Thanks, Bill Darte ARIN Advisory Council > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Stephen Sprunk > Sent: Friday, August 03, 2007 2:32 PM > To: Ted Mittelstaedt > Cc: ARIN PPML > Subject: Re: [ppml] More on Kremen/Cohen > > > Thus spake "Ted Mittelstaedt" > > So, did counsel ever comment on any past "shoot spammers > > dead on sight" proposals? There had to have been at least one! :-) > > I'm not aware of that having been formally proposed in the > past. You're > welcome to submit such a proposal (or any other) yourself if > you're curious > what the response would be; the directions are at: > > http://www.arin.net/policy/irpep.html > > In the past, counsel _has_ commented negatively on several > proposals; check > the PPML archives for "Staff Assessment" messages that are > sent out prior to > each meeting. > > S > > Stephen Sprunk "Those people who think they know everything > CCIE #3723 are a great annoyance to those of us who do." > K5SSS --Isaac Asimov > > > _______________________________________________ > This message sent to you through the ARIN Public Policy > Mailing List (PPML at arin.net). Manage your mailing list > subscription at: http://lists.arin.net/mailman/listinfo/ppml > From paul at vix.com Tue Aug 7 11:18:28 2007 From: paul at vix.com (Paul Vixie) Date: Tue, 07 Aug 2007 15:18:28 +0000 Subject: [ppml] alternative realities In-Reply-To: Your message of "Mon, 06 Aug 2007 21:16:21 MST." References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com><88234.1185818363@sa.vix.com><0ADD7367-339E-4360-80CD-45DEA230CE87@virtualized.org><24940.1185829923@sa.vix.com><12CF3748-BEF2-4FAC-A1A2-801634C67084@virtualized.org><71643.1185845108@sa.vix.com><46AE90C6.8060406@psg.com><83945.1185848565@sa.vix.com><1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org><93896.1185947387@sa.vix.com><3c3e3fca0708010622s55108197i52ac54957249a1f1@mail.gmail.com><63550.1185986123@sa.vix.com><58568.1186010437@sa.vix.com><46B11794.50907@internap.com><60331.1186011986@sa.vix.com><46B1204B.4050707@internap.com> <1248.1186025991@sa.vix.com> <29320.1186035346@sa.vix.com> Message-ID: <44510.1186499908@sa.vix.com> > > the connectivity community of which you are a part needs IPv6, though. > > Nope. Voice does not need IPv6, and the only hosts I care to connect > directly: a) are in the US with 4 IPv4 addresses per capita which is enough > for the rest of my life and b) use apps that work behind double nat anyway. so, you (michel py) do not personally need IPv6 at this time. i agree. > > and you don't need SIP to work > > SIP is a protocol that was designed to demonstrate that NAT was breaking > things. Point well taken: it is broken. I use Skype. It's survival of > the fittest, aka evolution. so, you (michel py) do not personally need IPv6 at this time. i agree. > Paul, your arguments are 10 years old. Something else than this broken > record, please. The launch window for IPv6 was 5 years ago. you (michel py) are not alone on the internet. and in true microsoft style, the overwhelming majority of the devices that will be connected to the internet have not been built yet. stop thinking steady state. there's a LOT of growth occurring far from your head, and even that is only the beginning of the real internet to be built by our kids and grandkids. > I am not upgrading while there still is bickering about PI, ULAs, > policies, etc. Furthermore, I would definitely not upgrade if the large > operator folk had it their way with the 4K DMZ and no PI whatsoever. i know this. but it's unrelated to the rest of your statements here. note that there is an IPv6 PI policy in place, and you might qualify for it now. From kloch at kl.net Tue Aug 7 11:32:57 2007 From: kloch at kl.net (Kevin Loch) Date: Tue, 07 Aug 2007 11:32:57 -0400 Subject: [ppml] APNIC policy proposal to create a regulated market in IPv4 addresses In-Reply-To: <22649.1186417254@sa.vix.com> References: <3c3e3fca0707241228r6dcd014ey7ed90da84131b027@mail.gmail.com> <71643.1185845108@sa.vix.com> <46AE90C6.8060406@psg.com> <83945.1185848565@sa.vix.com> <1E5A9D35-D086-47BC-A1DD-9BF71577F316@virtualized.org> <3c3e3fca0707311526i5a1ac121w4e512931f732b5fe@mail.gmail.com> <1953.1185921854@sa.vix.com> <61ACEB05-86BF-4254-8C25-437AFC7168D5@virtualized.org> <46AFF74B.8010602@psg.com> <46AFFD25.5050909@psg.com> <567041B9-EF93-471C-912B-92ED47E5F4EC@virtualized.org> <46B01188.1070102@psg.com> <46B0723E.7080301@psg.com> <46B4C885.5030904@internap.com> <46B4! CE09.2090901@internap.com> < 46B73C7F.9090401@kl.net> <22649.1186417254@sa.vix.com> Message-ID: <46B890A9.7030809@kl.net> Paul Vixie wrote: >>> Also, does anyone believe ISPs are going to remove the filters that >>> implicitly limit the length of a usable (for the purposes of highest >>> likelihood of global routability) IPv4 prefix to a /24? If so, why? >> I hope not, and if subdivision/deaggregation gets bad enough we will see >> filters tighten. In a worst case scenario we filter at /20 across >> the board and anyone using longer prefix gets to move. > > what would you have f.root-servers.org do in that case? our IPv4 address > is in a /24, and our IPv6 address is in a /48. even apart from the question > of how long it takes to renumber a root name server, where would you like us > to move? we have other address blocks but those other blocks aren't anycast. I put that out there as a worst case scenario, as in my sessions won't stay up without it. Surely other less drastic measures would be used before that point, but new routes would always pop up to work around each incremental step. This is all in the context of an essentially unregulated market for IP addresses where arbitrary subdivision is possible. Sounds pretty grim right? It is. I would make exceptions for *.root-servers, but don't expect everyone to. People are lazy, Many will copy templates they find from various sources, each with different exceptions and different typos. For a contemporary example, http://www.space.net/~gert/RIPE/ipv6-filters.html STILL lists 2620::/23 with a recommended filter size of /32. The good news is, even in this catastrophic scenario, d and h-root are fortunately within /16 assignments and can give out new addresses for the rest for those with outdated hint files. The bad news is of course for everyone who would have to renumber, possibly multiple times as filters are incrementally tightened. Those who suggested filtering on minimum RIR assignment sizes are implying that it is not possible to subdivide assignments in the forthcoming market. This is exactly the point I was trying to make, that allowing subdivision even below /20 will eventually result in drastic filtering. - Kevin From tedm at ipinc.net Tue Aug 7 15:29:23 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 7 Aug 2007 12:29:23 -0700 Subject: [ppml] alternative realities In-Reply-To: Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Michel Py >Sent: Wednesday, August 01, 2007 9:55 PM >To: ppml at arin.net >Subject: Re: [ppml] alternative realities > > >Talking about alternative realities, there's one already here that I did >not suspect it was: double-NAT. I'm not talking about China, I'm talking >about mainland USA. > >Here's the story: I volunteered to provide WiFi Internet access to a >site-in-the-middle-of-nowhere for 3 days. For free, of course. I decided >that what I could do for the money would be to share my 3G phone. So I >grab another laptop (not mine, heaven forbid), connect the phone to one >of the USB ports and a $35 Belkin WiFi "router" (bought at the closest >Staples) to the Ethernet port, and share the connection by checking the >appropriate box in M$ windblows XP's config. My laptop becomes a DHCP >server and a NAT box. > >The only other configuration required is to disable DHCP on the Belkin >and assign a static IP (192.168.0.2) to it, also configure a password, >there will be teens using it. > >Half-surprise #1: the IP address I get from the 3G phone is a 10.net. >Darn, the el-cheapo unlimited plan does not entitle one to a real IP >address. > >Half-surprise #2: it works just fine. It's built into XP, it takes 30 >seconds to configure. It's powered by a 12-volt inverter off the car's >battery. It's double-NAT: my laptop (the DHCP server) hands out IP >addresses out of 192.168.0.0/24. I don't think this is double-nat (unless your considering the Belkin which should have been replaced with an access point - what kind of network person are you, you knew that Internet Sharing is nat already and you bought a wifi router? - in any cast the Belkin is not germane to the discussion). On the surface it appears to be IPv4<->IPv6 NAT and the question is how exactly did it work. I didn't know XP's Internet Sharing had that built in to it, and I still strongly suspect it doesen't. I would suspect, that there's more here going on under the covers that you realize. You said you plugged the phone into a USB port on the XP system. I'll bet that you ran some form of PPPoE that tunnelled your IPv4 on the XP system through the IPv6 network the phone used, to some set of gateway servers that the phone provider has setup. This probably was hidden from you by the phone connectivity software. > >No, people using it can't host their web site on it, which I don't want >them to in the first place. However, people drive in, power up their >laptop, see only one ESSID (remember, we're in the middle of nowhere), >and connect to it just fine. They can check their email, look at their >stock portfolio, and email the digital picture of their progeniture to >grandma. > >Someone explains me again why I should spend money to upgrade to IPv6? >I.S.D.N: I Still Don't Need. > As an end user, you shouldn't. There will be plenty of ISPs out there willing to continue to have you connect through them to the Internet using IPv4. Some of them might not even charge you any extra for doing it. And most of them aren't going to be telling the end user WHAT the end user is using. End users interact with the Internet via domain names, Michel. They do not as a rule care what the TCP application does after getting the domain name. Most likely the ISP's that will only hand out IPv6 IP addresses will be stating "Windows Vista or later required" on their signup forms sometime about 5 years after the end of product support from Microsoft for Windows XP. That is about the earliest they will feel comfortable telling people without IPv6 support to get lost. And of course, their setup software will configure their customers PC's behind the customers back - into IPv6. Migrating end users to IPv6 is almost wholly dependent on adoption rates of the Windows operating system versions - this is the 2000 pound pink elephant in the room that nobody wants to talk about. There's no real point in discussing end user migration when 40% of the user base hasn't upgraded past Windows 2000 (which does not have production IPv6 support) When we see Windows Vista reaching 50% penetration and the "post Vista" windows OS at 20% penetration, and the "pre Vista" os's at 30% penetration of all Windows desktops, that will then be the time to start discussing migration of SOHO end users independently connected to ISPs, to IPv6. Ted From drc at virtualized.org Tue Aug 7 15:42:55 2007 From: drc at virtualized.org (David Conrad) Date: Tue, 7 Aug 2007 12:42:55 -0700 Subject: [ppml] alternative realities In-Reply-To: References: Message-ID: <447A9D20-0B10-4341-A488-FE9F7E6D0BD2@virtualized.org> Ted, On Aug 7, 2007, at 12:29 PM, Ted Mittelstaedt wrote: > When we see Windows Vista reaching 50% penetration and the "post > Vista" windows OS at 20% penetration, and the "pre Vista" os's at > 30% penetration of all Windows desktops, that will then be the time > to start discussing migration of SOHO end users independently > connected to ISPs, to IPv6. An interesting theory. But doesn't this assume that the content those users want to gain access to is also available on IPv6? And why would those content providers assume the cost of deploying IPv6 if there are no customers to use it? Regards, -drc (who has given up and turned off IPv6 in my laptop because it was too annoying to wait for IPv6 to fail before falling back to IPv4) From mark at mcsnet.ca Tue Aug 7 16:05:16 2007 From: mark at mcsnet.ca (Mark Beland) Date: Tue, 07 Aug 2007 14:05:16 -0600 Subject: [ppml] alternative realities In-Reply-To: <447A9D20-0B10-4341-A488-FE9F7E6D0BD2@virtualized.org> References: <447A9D20-0B10-4341-A488-FE9F7E6D0BD2@virtualized.org> Message-ID: <46B8D07C.9080300@mcsnet.ca> I completely agree, The hard core capitalists would say let market forces drive the deployment of ipv6. That is to say, I think ARIN is in a position to force the implementation of ipv6, and thats what they should do, work towards making ipv4 more expensive, less practical, or simply 'expire' allocations to force rapid uptake of ipv6 so we're not living out the next 20 years in an mixed v4 v6 environment. Unless proper planning is done to ensure a smooth migration, what we will see is users demanding either or both ipv4 and ipv6 addresses creating a really big mess..... Not to mention the supposed 'free market' of ipv4 addresses that are liable to be traded as commodities once exhaustion occurs. From where I stand, the question here is whether we choose to plan ahead and take measures to ensure the development of a proper migration strategy that encourages/forces the upgrade to the new technology, or simply let the network operators find their own solutions that may or may not be in the best interest of the community at large. David Conrad wrote: > Ted, > > On Aug 7, 2007, at 12:29 PM, Ted Mittelstaedt wrote: > >> When we see Windows Vista reaching 50% penetration and the "post >> Vista" windows OS at 20% penetration, and the "pre Vista" os's at >> 30% penetration of all Windows desktops, that will then be the time >> to start discussing migration of SOHO end users independently >> connected to ISPs, to IPv6. >> > > An interesting theory. But doesn't this assume that the content > those users want to gain access to is also available on IPv6? And > why would those content providers assume the cost of deploying IPv6 > if there are no customers to use it? > > Regards, > -drc > (who has given up and turned off IPv6 in my laptop because it was too > annoying to wait for IPv6 to fail before falling back to IPv4) > > _______________________________________________ > 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 Lee.Howard at stanleyassociates.com Tue Aug 7 16:14:47 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 7 Aug 2007 16:14:47 -0400 Subject: [ppml] alternative realities In-Reply-To: <46B8D07C.9080300@mcsnet.ca> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB406A0A7F8@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Mark Beland > Sent: Tuesday, August 07, 2007 4:05 PM > To: David Conrad > Cc: ppml at arin.net > Subject: Re: [ppml] alternative realities > > From where I stand, the question here is whether we choose > to plan ahead and take measures to ensure the development of > a proper migration strategy that encourages/forces the > upgrade to the new technology, What plans do you propose or endorse? In what way should ARIN encourage or force use of IPv6? Lee From kkargel at polartel.com Tue Aug 7 17:29:13 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 7 Aug 2007 16:29:13 -0500 Subject: [ppml] alternative realities In-Reply-To: <46B8D07C.9080300@mcsnet.ca> References: <447A9D20-0B10-4341-A488-FE9F7E6D0BD2@virtualized.org> <46B8D07C.9080300@mcsnet.ca> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106670726D@mail> I have a hard time accepting any philosophy that says "just make it more expensive because your can".. If you have a whole bunch of money that you don't know what to do with I can give you some good ideas.. but I need every penny I have, so please quit spending it for me. What you will do by artificially jacking v4 prices is rape the small shops and drive them out of business. Maybe that is your intent, to leave consumers with nobody to deal with but the mega-ISP's.. personally I think that is a pretty sad way to think about it. There is nothing evil about leaving IPv4 in place. If you don't want to use it then don't use it. People will migrate to v6 as content does, and as hardware evolves to handle it. This will be a natural and unavoidable transition. > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Mark Beland > Sent: Tuesday, August 07, 2007 3:05 PM > To: David Conrad > Cc: ppml at arin.net > Subject: Re: [ppml] alternative realities > > I completely agree, > The hard core capitalists would say let market forces drive > the deployment of ipv6. That is to say, I think ARIN is in a > position to force the implementation of ipv6, and thats what > they should do, work towards making ipv4 more expensive, less > practical, or simply 'expire' > allocations to force rapid uptake of ipv6 so we're not living > out the next 20 years in an mixed v4 v6 environment. > Unless proper planning is done to ensure a smooth migration, > what we will see is users demanding either or both ipv4 and > ipv6 addresses creating a really big mess..... Not to mention > the supposed 'free market' of ipv4 addresses that are liable > to be traded as commodities once exhaustion occurs. > From where I stand, the question here is whether we choose > to plan ahead and take measures to ensure the development of > a proper migration strategy that encourages/forces the > upgrade to the new technology, or simply let the network > operators find their own solutions that may or may not be in > the best interest of the community at large. > > > > > David Conrad wrote: > > Ted, > > > > On Aug 7, 2007, at 12:29 PM, Ted Mittelstaedt wrote: > > > >> When we see Windows Vista reaching 50% penetration and the "post > >> Vista" windows OS at 20% penetration, and the "pre Vista" > os's at 30% > >> penetration of all Windows desktops, that will then be the time to > >> start discussing migration of SOHO end users independently > connected > >> to ISPs, to IPv6. > >> > > > > An interesting theory. But doesn't this assume that the > content those > > users want to gain access to is also available on IPv6? > And why would > > those content providers assume the cost of deploying IPv6 > if there are > > no customers to use it? > > > > Regards, > > -drc > > (who has given up and turned off IPv6 in my laptop because > it was too > > annoying to wait for IPv6 to fail before falling back to IPv4) > > > > _______________________________________________ > > 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. > > > > _______________________________________________ > 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 mark at mcsnet.ca Tue Aug 7 18:43:12 2007 From: mark at mcsnet.ca (Mark Beland) Date: Tue, 07 Aug 2007 16:43:12 -0600 Subject: [ppml] alternative realities In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106670726D@mail> References: <447A9D20-0B10-4341-A488-FE9F7E6D0BD2@virtualized.org> <46B8D07C.9080300@mcsnet.ca> <70DE64CEFD6E9A4EB7FAF3A06314106670726D@mail> Message-ID: <46B8F580.8090608@mcsnet.ca> Kevin, First off, I think I'm one of the 'smaller guys'.. (two /20's).. I don't know if my concerns here are well founded, but the way I can see this going over, the big guys won't be caught out in the cold, they'll strategically buy out a few legacy ipv4 holders making sure they have got all the addresses they need......... If the big guys have ample supply of ipv4 addresses, why switch... This forces your competitors (the little guys) to put customers on ipv6.. My concern here, bottom line, is some ISP's being forced to put users on ipv6 while others are not... I think there will be a great deal of resistance from users..... especially when they realize that they have a small fraction of the services available on ipv6 (consider peer-to-peer applications) ....... Obviously, over time, this will change, but this will put some providers (I think all the little ones) at a significant disadvantage once they run out of ipv4 space. I think we'll see users demanding both ipv4 and ipv6 (at first)...... In an ideal situation, like you say, the transition occurs naturally.... But I think what will happen is that ISP's won't offer ipv6 until Arin nearly runs out of ipv4 addresses. Then we won't have ipv4 addresses to give them, and ipv4 will be the new selling feature, customers will shop for isp's who can offer them ipv4............. I don't think this situation is in anyone's best interest. But the big guys will probably be in a better position because they'll be able to find addresses..?.. ... ... I just wish we could take a harder line focused on discontinuing v4 rather than just letting it die out, as this would avoid the supply and demand situation that I see happening... ... Am I'm just being a pessimist here? Kevin Kargel wrote: > I have a hard time accepting any philosophy that says "just make it > more expensive because your can".. > > If you have a whole bunch of money that you don't know what to do with I > can give you some good ideas.. but I need every penny I have, so please > quit spending it for me. > > What you will do by artificially jacking v4 prices is rape the small > shops and drive them out of business. Maybe that is your intent, to > leave consumers with nobody to deal with but the mega-ISP's.. > personally I think that is a pretty sad way to think about it. > > There is nothing evil about leaving IPv4 in place. If you don't want to > use it then don't use it. People will migrate to v6 as content does, > and as hardware evolves to handle it. This will be a natural and > unavoidable transition. > > > > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >> Behalf Of Mark Beland >> Sent: Tuesday, August 07, 2007 3:05 PM >> To: David Conrad >> Cc: ppml at arin.net >> Subject: Re: [ppml] alternative realities >> >> I completely agree, >> The hard core capitalists would say let market forces drive >> the deployment of ipv6. That is to say, I think ARIN is in a >> position to force the implementation of ipv6, and thats what >> they should do, work towards making ipv4 more expensive, less >> practical, or simply 'expire' >> allocations to force rapid uptake of ipv6 so we're not living >> out the next 20 years in an mixed v4 v6 environment. >> Unless proper planning is done to ensure a smooth migration, >> what we will see is users demanding either or both ipv4 and >> ipv6 addresses creating a really big mess..... Not to mention >> the supposed 'free market' of ipv4 addresses that are liable >> to be traded as commodities once exhaustion occurs. >> From where I stand, the question here is whether we choose >> to plan ahead and take measures to ensure the development of >> a proper migration strategy that encourages/forces the >> upgrade to the new technology, or simply let the network >> operators find their own solutions that may or may not be in >> the best interest of the community at large. >> >> >> >> >> David Conrad wrote: >> >>> Ted, >>> >>> On Aug 7, 2007, at 12:29 PM, Ted Mittelstaedt wrote: >>> >>> >>>> When we see Windows Vista reaching 50% penetration and the "post >>>> Vista" windows OS at 20% penetration, and the "pre Vista" >>>> >> os's at 30% >> >>>> penetration of all Windows desktops, that will then be the time to >>>> start discussing migration of SOHO end users independently >>>> >> connected >> >>>> to ISPs, to IPv6. >>>> >>>> >>> An interesting theory. But doesn't this assume that the >>> >> content those >> >>> users want to gain access to is also available on IPv6? >>> >> And why would >> >>> those content providers assume the cost of deploying IPv6 >>> >> if there are >> >>> no customers to use it? >>> >>> Regards, >>> -drc >>> (who has given up and turned off IPv6 in my laptop because >>> >> it was too >> >>> annoying to wait for IPv6 to fail before falling back to IPv4) >>> >>> _______________________________________________ >>> 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. >> >>> >>> >> _______________________________________________ >> 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. >> >> > _______________________________________________ > 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 michel at arneill-py.sacramento.ca.us Tue Aug 7 21:47:52 2007 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 7 Aug 2007 18:47:52 -0700 Subject: [ppml] alternative realities In-Reply-To: References: Message-ID: > Ted Mittelstaedt wrote: > I don't think this is double-nat Double NAT it is. AT&T hands me a single 10.net address which obviously is natted to get out to the public Internet, and I hand clients 192.168 addresses which are natted to the 10.net address. > (unless your considering the Belkin which should have been > replaced with an access point. The Belkin is used as an access point. A WiFi router is half the money of an access point and does exactly the same if you don't plug anything on the WAN port. > - what kind of network person are you, you knew that Internet > Sharing is nat already and you bought a wifi router? I'm the kind of person who was not born wealthy and does not have unlimited amounts of taxpayer's or customer's money to waste by buying an access point for twice as much as a router. The laptop used for that is an old clunker without Wifi, You must be in marketing; removing the NAT part of a router, calling it an access point and selling it for twice as much when there's half of the goods in it. Michel. From kkargel at polartel.com Wed Aug 8 10:25:36 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 8 Aug 2007 09:25:36 -0500 Subject: [ppml] alternative realities In-Reply-To: <46B8F580.8090608@mcsnet.ca> References: <447A9D20-0B10-4341-A488-FE9F7E6D0BD2@virtualized.org> <46B8D07C.9080300@mcsnet.ca> <70DE64CEFD6E9A4EB7FAF3A06314106670726D@mail> <46B8F580.8090608@mcsnet.ca> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066707272@mail> Mark, I suspect - as you say - you may be being the pessimist here. You are not taking in to account v4<->v6 gateway services, that will continue to offer connectivity to both nets so long as the dual stack exists. Don't get me wrong, pessimists have value too, we need to look at all sides of the situation. Maybe I am in a soft place. I have my IPv4, and if necessary I can squeeze what I have to provide for me during growth. I can nat, and use private space if needed. It will restrict what my customers can do but that is better than cutting them off. It may not be easy or comfortable, but it can be done. I also have my IPv6 allocation, and with the help of the wonderful folks at Hurricane Electric I am learning to use it. That is the best advice I can give to anyone. Get your IPv6 now, get it in place and running. If you learn to dual stack and set up a 4<->6 gateway that will take some small pressure off of your IPv4 infrastructure. You will be able to continue providing IPv4 to your customers, you will be able to transparantly provide what services are available on IPv6. I am sure we will see customers demanding both IPv4 and IPv6 (even if they don't know that's what they are doing). Because of that I think it is foolish to slit our own throats by forcing the demise of a service our customers demand. So long as they keep giving me money I will do my danged best to provide what they are paying me for. The "if I can't have it nobody can" school of thought might make you feel better momentarily, but it won't work in the long run. Accelerating the demise of IPv4 unnaturally is a great example of 'cutting off your nose to spite your face', if you pardon the alliteration. It is sort of like looking at a gas4 shortage. It is obvious that if there is a gas4 shortage and you sell your car that you won't have a gas4 problem anymore. Unfortunaltely you won't be able to meet your transportation needs either. Naturally you will try to proselytize and get everyone else to sell their cars too, but that won't do anything about the need for personal transportation. Getting the government to outlaw cars altogether won't help the short term needs either. Of course you can advocate the formation of the electric bus6 service, that someday will stop at everyone's house and take them where they need to go, but in the meantime your neighbors and family won't be able to buy more groceries than they can carry, and they will only be able to shop at the local store. On the other hand, if you kept your car, and offered rides to your neighbors whenever you could, while at the same time working towards getting electric bus6 running, maybe you could continue to meet your needs until bus6 was fully functional and could take care of you. > -----Original Message----- > From: Mark Beland [mailto:mark at mcsnet.ca] > Sent: Tuesday, August 07, 2007 5:43 PM > To: Kevin Kargel > Cc: ppml at arin.net > Subject: Re: [ppml] alternative realities > > Kevin, > First off, I think I'm one of the 'smaller guys'.. (two > /20's).. I don't know if my concerns here are well founded, > but the way I can see this going over, the big guys won't be > caught out in the cold, they'll strategically buy out a few > legacy ipv4 holders making sure they have got all the > addresses they need......... If the big guys have ample > supply of ipv4 addresses, why switch... This forces your > competitors (the little guys) to put customers on ipv6.. > > My concern here, bottom line, is some ISP's being forced to > put users on > ipv6 while others are not... I think there will be a great > deal of resistance from users..... especially when they > realize that they have a small fraction of the services > available on ipv6 (consider peer-to-peer applications) ....... > Obviously, over time, this will change, > but this will put some providers (I think all the little > ones) at a significant disadvantage once they run out of ipv4 space. > > I think we'll see users demanding both ipv4 and ipv6 (at > first)...... In an ideal situation, like you say, the > transition occurs naturally.... But I think what will happen > is that ISP's won't offer ipv6 until Arin nearly runs out of > ipv4 addresses. Then we won't have ipv4 addresses to give > them, and ipv4 will be the new selling feature, customers > will shop for isp's who can offer them ipv4............. I > don't think this situation is in anyone's best interest. > But the big guys will probably be in a better position > because they'll be able to find addresses..?.. ... ... I just > wish we could take a harder line focused on discontinuing v4 > rather than just letting it die out, as this would avoid the > supply and demand situation that I see happening... ... Am > I'm just being a pessimist here? > > > > > > Kevin Kargel wrote: > > I have a hard time accepting any philosophy that says > "just make it > > more expensive because your can".. > > > > If you have a whole bunch of money that you don't know what > to do with > > I can give you some good ideas.. but I need every penny I have, so > > please quit spending it for me. > > > > What you will do by artificially jacking v4 prices is rape > the small > > shops and drive them out of business. Maybe that is your > intent, to > > leave consumers with nobody to deal with but the mega-ISP's.. > > personally I think that is a pretty sad way to think about it. > > > > There is nothing evil about leaving IPv4 in place. If you > don't want > > to use it then don't use it. People will migrate to v6 as content > > does, and as hardware evolves to handle it. This will be a natural > > and unavoidable transition. > > > > > > > > > >> -----Original Message----- > >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] > On Behalf > >> Of Mark Beland > >> Sent: Tuesday, August 07, 2007 3:05 PM > >> To: David Conrad > >> Cc: ppml at arin.net > >> Subject: Re: [ppml] alternative realities > >> > >> I completely agree, > >> The hard core capitalists would say let market forces drive the > >> deployment of ipv6. That is to say, I think ARIN is in a > position to > >> force the implementation of ipv6, and thats what they > should do, work > >> towards making ipv4 more expensive, less practical, or simply > >> 'expire' > >> allocations to force rapid uptake of ipv6 so we're not > living out the > >> next 20 years in an mixed v4 v6 environment. > >> Unless proper planning is done to ensure a smooth > migration, what we > >> will see is users demanding either or both ipv4 and > >> ipv6 addresses creating a really big mess..... Not to mention the > >> supposed 'free market' of ipv4 addresses that are liable > to be traded > >> as commodities once exhaustion occurs. > >> From where I stand, the question here is whether we > choose to plan > >> ahead and take measures to ensure the development of a proper > >> migration strategy that encourages/forces the upgrade to the new > >> technology, or simply let the network operators find their own > >> solutions that may or may not be in the best interest of the > >> community at large. > >> > >> > >> > >> > >> David Conrad wrote: > >> > >>> Ted, > >>> > >>> On Aug 7, 2007, at 12:29 PM, Ted Mittelstaedt wrote: > >>> > >>> > >>>> When we see Windows Vista reaching 50% penetration and the "post > >>>> Vista" windows OS at 20% penetration, and the "pre Vista" > >>>> > >> os's at 30% > >> > >>>> penetration of all Windows desktops, that will then be > the time to > >>>> start discussing migration of SOHO end users independently > >>>> > >> connected > >> > >>>> to ISPs, to IPv6. > >>>> > >>>> > >>> An interesting theory. But doesn't this assume that the > >>> > >> content those > >> > >>> users want to gain access to is also available on IPv6? > >>> > >> And why would > >> > >>> those content providers assume the cost of deploying IPv6 > >>> > >> if there are > >> > >>> no customers to use it? > >>> > >>> Regards, > >>> -drc > >>> (who has given up and turned off IPv6 in my laptop because > >>> > >> it was too > >> > >>> annoying to wait for IPv6 to fail before falling back to IPv4) > >>> > >>> _______________________________________________ > >>> 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. > >> > >>> > >>> > >> _______________________________________________ > >> 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. > >> > >> > > _______________________________________________ > > 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 tedm at ipinc.net Wed Aug 8 14:05:21 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 8 Aug 2007 11:05:21 -0700 Subject: [ppml] alternative realities In-Reply-To: Message-ID: >-----Original Message----- >From: Michel Py [mailto:michel at arneill-py.sacramento.ca.us] >Sent: Tuesday, August 07, 2007 6:48 PM >To: Ted Mittelstaedt; ppml at arin.net >Subject: RE: [ppml] alternative realities > > >> Ted Mittelstaedt wrote: >> I don't think this is double-nat > >Double NAT it is. AT&T hands me a single 10.net address which obviously >is natted to get out to the public Internet, and I hand clients 192.168 >addresses which are natted to the 10.net address. > Um, I had thought you said IPv6 from AT&T? Ted From tedm at ipinc.net Wed Aug 8 14:11:12 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 8 Aug 2007 11:11:12 -0700 Subject: [ppml] alternative realities In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066707272@mail> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Kevin Kargel >Sent: Wednesday, August 08, 2007 7:26 AM >To: PPML at arin.net >Subject: Re: [ppml] alternative realities > > >Mark, > > > It is sort of like looking at a gas4 shortage. It is obvious >that if there is a gas4 shortage and you sell your car that you won't >have a gas4 problem anymore. Unfortunaltely you won't be able to meet >your transportation needs either. Nonsense! You replace your gas-hogging car with a nice Honda Shadow VLX and your transportation needs will be met very nicely, at 50mpg to boot! ;-) > Naturally you will try to proselytize and get everyone else to >sell their cars too, You've been reading Prius adverts, again. Ted From kkargel at polartel.com Wed Aug 8 14:22:34 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 8 Aug 2007 13:22:34 -0500 Subject: [ppml] alternative realities References: Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410669B2B2C@mail> >Nonsense! You replace your gas-hogging car with a nice Honda Shadow VLX >and your transportation needs will be met very nicely, at 50mpg to boot! ;-) Yes, I thought of that, but we don't have VLX available.. only car or bus6 .. From martin.hannigan at batelnet.bs Wed Aug 8 14:57:43 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Wed, 08 Aug 2007 14:57:43 -0400 Subject: [ppml] alternative realities Message-ID: <46ba1227.128.382c.28864@batelnet.bs> ----- Original Message ----- From: Mark Beland To: Kevin Kargel Cc: ppml at arin.net Subject: Re: [ppml] alternative realities Date: Tue, 07 Aug 2007 16:43:12 -0600 > Kevin, > First off, I think I'm one of the 'smaller guys'.. (two > /20's).. I don't know if my concerns here are well > founded, but the way I can see this going over, the big > guys won't be caught out in the cold, they'll > strategically buy out a few legacy ipv4 holders making > sure they have got all the addresses they need......... > If the big guys have ample supply of ipv4 addresses, why > switch... This forces your competitors (the little guys) > to put customers on ipv6.. > > My concern here, bottom line, is some ISP's being forced > to put users on ipv6 while others are not... The problem with arguing big vs. small is that you create classes and that forces inequalities. We should be careful to maintain a "one for all" approach in order for things to remain "fair". >I think > there will be a great deal of resistance from users..... and.. > I think we'll see users demanding both ipv4 and ipv6 (at > first) Users aren't going to resist or demand anything except working Internet service. -M< From tedm at ipinc.net Wed Aug 8 15:17:33 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 8 Aug 2007 12:17:33 -0700 Subject: [ppml] alternative realities In-Reply-To: <46B8F580.8090608@mcsnet.ca> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Mark Beland >Sent: Tuesday, August 07, 2007 3:43 PM >To: Kevin Kargel >Cc: ppml at arin.net >Subject: Re: [ppml] alternative realities > > >Kevin, >First off, I think I'm one of the 'smaller guys'.. (two /20's).. I don't >know if my concerns here are well founded, >but the way I can see this going over, the big guys won't be caught out >in the cold, they'll strategically buy out a >few legacy ipv4 holders making sure they have got all the addresses they >need......... I think they will, but I also think that this will merely stave off the inevitable. >If the big guys have ample >supply of ipv4 addresses, why switch... This forces your competitors >(the little guys) to put customers on ipv6.. > >My concern here, bottom line, is some ISP's being forced to put users on >ipv6 while others are not... Mark, I have the same concern. But here is the deal. The small providers are dancing with elephants - they always have been. There are 3 big elephants in this deal. First is when the supply of IPv4 runs out. Second is what Microsoft does with Vista and it's following operating systems with regards to IPv6. Third is the uptake rate of Vista and the following Windows operating systems. As a small provider you just have to come to terms with the fact that we have absolutely zero control over these three elephants. If IPv4 runout happens after Vista uptake is well established, we will be fine. If Microsoft doesen't completely screw up the IPv6 implementation in the Windows desktop OS's we will be fine. The first factor is determined by the users, how quickly they abandon their old PC hardware and buy into the new dual-core stuff. Hardware prices out there are -awfully- cheap, but Vista really breaks a LOT of software. While there is IPv6 for XP, it isn't on by default - and there's LOTS of users out there running hardware they got from their friends or from the local chop shop where the user is missing the XP install media, and getting them up on it will be a challenge. The second factor is going to be determined by what the major elephants like Ebay, and so on, do for IPv6 deployment and how quickly they offer access via IPv6 to their servers, and how the Microsoft clients behave when faced with the following: testhost# nslookup Default Server: dns1.ipinc.net Address: 65.75.192.10 > www.kame.net Server: dns1.ipinc.net Address: 65.75.192.10 Non-authoritative answer: Name: www.kame.net Address: 203.178.141.194 > set q=AAAA > www.kame.net Server: dns1.ipinc.net Address: 65.75.192.10 Non-authoritative answer: Name: www.kame.net Address: 2001:200:0:8002:203:47ff:fea5:3085 > Question - if the Vista client is dual-stacked, and sees this, what does it -pefer- to use? IPv4 or IPv6? How Microsoft solves those kinds of questions is going to largely dictate the speed of IPv6 deployment I think. If they do stupid things, which is SOP for them with networking decisions, then IPv6 deployment will be years longer than it should be. Note that with the above example, I don't see IPv6 records for ebay, cnn.com, etc. >I think there >will be a great deal of resistance from users..... especially when they >realize that they have a small fraction of the >services available on ipv6 (consider peer-to-peer applications) ....... >Obviously, over time, this will change, >but this will put some providers (I think all the little ones) at a >significant disadvantage once they run out of ipv4 >space. > Maybe, maybe not. It all depends on when runout happens and how rapidly IPv6 OS's enter production. If your a small ISP that runs out of public IPv4 then as long as your customers are all IPv6 compliant, then it should be a simple matter to build a IPv6->IPv4 proxy. Both mod_proxy in Apache can do this as well a Squid. Of if you don't want to build a proxy, have customers use the following: http://ipv6gate.sixxs.net/ >I think we'll see users demanding both ipv4 and ipv6 (at first)...... In >an ideal situation, like you say, the >transition occurs naturally.... But I think what will happen is that >ISP's won't offer ipv6 until Arin nearly runs >out of ipv4 addresses. Then we won't have ipv4 addresses to give them, >and ipv4 will be the new selling feature, >customers will shop for isp's who can offer them ipv4 Well you can avoid that problem very simply by handling the IPv4/IPv6 stuff behind the scenes for the customers and not making a big deal about it in your marketing. Customers shop for -connectivity- If you can offer them connectivity they aren't going to care if they are on public IPv4, or translated IPv4, or public IPv6, or IPv6 proxied to IPv4. As long as everything works and they can get where they want to go. ............. I >don't think this situation is in anyone's best interest. >But the big guys will probably be in a better position because they'll >be able to find addresses..?.. ... ... I just wish >we could take a harder line focused on discontinuing v4 rather than just >letting it die out, as this would avoid the >supply and demand situation that I see happening... ... Am I'm just >being a pessimist here? > I agree with this, insofar that ANY ISP that wants to continue to do things "the same way we have always done them", meaning, running IPv4 only, is going to be at a disadvantage once they run out of IPv4, in a post-IPv4- runout world. And for sure, there is always going to be expense switching from "the same way we have always done things" to a dual-stack or IPv6-only-with-proxy environment. Those expenses will DECREASE further in the future as they always do with any technological improvement. So the ISP's that are able to delay IPv6 switchover as long as possible will have it the cheapest, and will benefit from all of the other work that everyone else has done. I agree if there was any way to "force" switchover to take place all at the same time, it would benefit most those who seek to "continue to do things the same way we have always done them" But, ultimately what it boils down to for the small ISP is that we can't affect the elephants, we very likely can't get switchover forced, and the one bit of hope that we do have to make it through this is that freeware proxy code does exist, we can deploy it right now and so when the time does come that the marketing people are trying to scare customers to sign up with them based on "shortage of IPv4" that if we have the proxy infrastructure in place, we can still service our customers and keep them connected. Ted From bmanning at vacation.karoshi.com Thu Aug 9 12:21:37 2007 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 9 Aug 2007 16:21:37 +0000 Subject: [ppml] too many variables Message-ID: <20070809162137.GA1797@vacation.karoshi.com.> I asked this question to a couple of folks: "at the current churn rate/ration, at what size doe the FIB need to be before it will not converge?" and got these answers: --------- jabber log --------- a fine question, has been asked many times, and afaik noone has provided any empirically grounded answer. a few realities hinder our ability to answer this question. (1) there are technology factors we can't predict, e.g., moore's law effects on hardware development (2) there are economics and policy and social factors we can't predict, e.g., how much convegence-capable hardware will providers/vendors be able to afford, how those costs will affect consumer prices, how that will affect consumer uptake, network growth, and industry dynamics, how regulation affects all of the above (3) We Don't Have Any Data from providers on the dynamics of BGP and IGP interactions, much less network wide convergence, so the research community can't provide any empirically grounded input into an answer {elided} ------------------------------- & ------ Forwarded Message ------ Date: Tue, 07 Aug 2007 To: bmanning at karoshi.com Subject: CPU Usage Router Upstream Uptime BGP cpu per 1 sec uptime Cat6500/SUP720 1 >1yr 53ms/sec C7200/NPE-G1 1 158days 15ms/sec C7304/NSE100 4+2 177days 55ms/sec C7200/NPE-G1 1+2 26days 8ms/sec C7301 1 214days 7ms/sec GR2000 0+1 101days 6ms/sec Upstream: M+N, M is # of EBGP with full route feed , N is # of IBGP with full route feed Provided if the CPU consumption is propotional to the routing table size, the hard limit would be 10 times to the current size, allowing other tasks to obtain some CPU cycles. ----- End forwarded message ----- so, one might presume that w/o a change in algorithm, and unlimited memory, that the CPU would run out of cycles to compute convergence at ~ 10x the current size of the routing table (abt 250,000 prefixes). so putting a stake in the ground, BGP will stop working @ around 2,500,000 routes - can't converge... regardless of IPv4 or IPv6. unless the CPU's change or the convergence algorithm changes. --bill From paul at vix.com Thu Aug 9 13:12:12 2007 From: paul at vix.com (Paul Vixie) Date: Thu, 09 Aug 2007 17:12:12 +0000 Subject: [ppml] too many variables In-Reply-To: Your message of "Thu, 09 Aug 2007 16:21:37 GMT." <20070809162137.GA1797@vacation.karoshi.com.> References: <20070809162137.GA1797@vacation.karoshi.com.> Message-ID: <6786.1186679532@sa.vix.com> > From: bmanning at vacation.karoshi.com > To: ppml at arin.net, nanog at nanog.org yikes. cross posting between two public lists seems like a really bad idea. i'm going to follow this up on ppml only. > I asked this question to a couple of folks: > > "at the current churn rate/ration, at what size doe the FIB need to > be before it will not converge?" > > and got these answers: none of which were germane. given infinite cpu and infinite RAM and a stated DAG size and a stated churn rate and a stated average interprovider link size and a stated headroom target on those links, at what point is there not enough bandwidth to carry the updates? then, if bandwidth isn't a consideration but the speed of light remains as stated, at what point does convergence stop being theoretically possible? once we know those limits, we can ask questions to which the last set of answers were germane, like how many megacomputrons do we need in core routers, edge routers, tier 1 routers, tier 2 routers, etc. and from that, finally, we could guess reasonable maximum RIB and FIB sizes for a worst case definition of "can reach everything from". From randy at psg.com Thu Aug 9 13:24:58 2007 From: randy at psg.com (Randy Bush) Date: Thu, 09 Aug 2007 07:24:58 -1000 Subject: [ppml] too many variables In-Reply-To: <20070809162137.GA1797@vacation.karoshi.com.> References: <20070809162137.GA1797@vacation.karoshi.com.> Message-ID: <46BB4DEA.90406@psg.com> the fib in a heavily peered dfz router does not often converge now. the question is when will the router not be able to process the volume of churn, i.e. fall behind further and further? as there is non-trivial headroom in the algorithms, moore's law on the processors, etc. etc., your message is as operationally meaningful as dave and john telling us they can handle 2m prefixes today. randy From randy at psg.com Thu Aug 9 13:24:58 2007 From: randy at psg.com (Randy Bush) Date: Thu, 09 Aug 2007 07:24:58 -1000 Subject: [ppml] too many variables In-Reply-To: <20070809162137.GA1797@vacation.karoshi.com.> References: <20070809162137.GA1797@vacation.karoshi.com.> Message-ID: <46BB4DEA.90406@psg.com> the fib in a heavily peered dfz router does not often converge now. the question is when will the router not be able to process the volume of churn, i.e. fall behind further and further? as there is non-trivial headroom in the algorithms, moore's law on the processors, etc. etc., your message is as operationally meaningful as dave and john telling us they can handle 2m prefixes today. randy From bmanning at vacation.karoshi.com Thu Aug 9 17:04:04 2007 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 9 Aug 2007 21:04:04 +0000 Subject: [ppml] too many variables In-Reply-To: <46BB4DEA.90406@psg.com> References: <20070809162137.GA1797@vacation.karoshi.com.> <46BB4DEA.90406@psg.com> Message-ID: <20070809210404.GA3965@vacation.karoshi.com.> On Thu, Aug 09, 2007 at 07:24:58AM -1000, Randy Bush wrote: > > the fib in a heavily peered dfz router does not often converge now. never? or over some predefined period of time? > the > question is when will the router not be able to process the volume of > churn, i.e. fall behind further and further? yes. presuming the churn ratio stays the same and: > as there is non-trivial > headroom in the algorithms, the BGP algorithm does not change (BGP-5, BGP-6 etc anyone) > > moore's law on the processors, etc. etc., yes, yes, yes... too many variables. fixing the processors to what is fielded TODAY, with existing algorithms, etc... if the ONE variable is to allow enough memory to hold prefixen, will BGP fail (a router not being able to process the volume of churn) at what point? (other variables: number of exteranal peers, IGP updates, AS path length, etc... what else needs to be considered?) > your message is as operationally meaningful as dave and john telling us > they can handle 2m prefixes today. well, maybe. the numbers were collected from live boxen. not enough data for anything you might be able to use tho. > > randy From randy at psg.com Thu Aug 9 18:10:53 2007 From: randy at psg.com (Randy Bush) Date: Thu, 09 Aug 2007 12:10:53 -1000 Subject: [ppml] too many variables In-Reply-To: <20070809210404.GA3965@vacation.karoshi.com.> References: <20070809162137.GA1797@vacation.karoshi.com.> <46BB4DEA.90406@psg.com> <20070809210404.GA3965@vacation.karoshi.com.> Message-ID: <46BB90ED.8070101@psg.com> >> the fib in a heavily peered dfz router does not often converge now. > never? or over some predefined period of time? not often >> as there is non-trivial headroom in the algorithms, > the BGP algorithm does not change (BGP-5, BGP-6 etc anyone) algorithm != protocol randy From vgill at vijaygill.com Thu Aug 9 23:22:40 2007 From: vgill at vijaygill.com (vijay gill) Date: Thu, 9 Aug 2007 20:22:40 -0700 Subject: [ppml] too many variables In-Reply-To: <46BB4DEA.90406@psg.com> References: <20070809162137.GA1797@vacation.karoshi.com.> <46BB4DEA.90406@psg.com> Message-ID: <21ef2c1c0708092022i7c67c7g9ff0d11915668d5d@mail.gmail.com> On 8/9/07, Randy Bush wrote: > > the fib in a heavily peered dfz router does not often converge now. the > question is when will the router not be able to process the volume of > churn, i.e. fall behind further and further? as there is non-trivial > headroom in the algorithms, moore's law on the processors, etc. etc., > your message is as operationally meaningful as dave and john telling us > they can handle 2m prefixes today. Randy, do you have data on this - that a peered dfz router does often not converge now? /vijay randy > _______________________________________________ > 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 pesherb at yahoo.com Fri Aug 10 10:29:54 2007 From: pesherb at yahoo.com (Peter Sherbin) Date: Fri, 10 Aug 2007 07:29:54 -0700 (PDT) Subject: [ppml] [RRG] Routers in DFZ In-Reply-To: <20070809162137.GA1797@vacation.karoshi.com.> Message-ID: <487856.32056.qm@web58701.mail.re1.yahoo.com> Here is a good comment on the recent RRG discussion about routers in DFZ and relationship between number of prefixes and the processing power. Details are below and here is the essence: > so, one might presume that w/o a change in algorithm, and unlimited > memory, that the CPU would run out of cycles to compute convergence > at ~ 10x the current size of the routing table (abt 250,000 prefixes). > > so putting a stake in the ground, BGP will stop working @ around > 2,500,000 routes - can't converge... regardless of IPv4 or IPv6. > unless the CPU's change or the convergence algorithm changes. In particular it provides a theoretical limit that can be added to the Problem Statement draft-narten-radir-problem-statement-00.txt Thanks, Peter --- bmanning at vacation.karoshi.com wrote: > I asked this question to a couple of folks: > > "at the current churn rate/ration, at what size doe the FIB need to > be before it will not converge?" > > and got these answers: > > --------- jabber log --------- > a fine question, has been asked many times, and afaik noone has > provided any empirically grounded answer. > > a few realities hinder our ability to answer this question. > > (1) there are technology factors we can't predict, e.g., > moore's law effects on hardware development > (2) there are economics and policy and social factors we > can't predict, e.g., how much convegence-capable > hardware will providers/vendors be able to afford, > how those costs will affect consumer prices, > how that will affect consumer uptake, network > growth, and industry dynamics, how regulation affects > all of the above > (3) We Don't Have Any Data from providers on the dynamics of BGP > and IGP interactions, much less network wide convergence, > so the research community can't provide any empirically > grounded input into an answer > > {elided} > ------------------------------- > & > ------ Forwarded Message ------ > > Date: Tue, 07 Aug 2007 > To: bmanning at karoshi.com > Subject: CPU Usage > > Router Upstream Uptime BGP cpu per 1 sec uptime > Cat6500/SUP720 1 >1yr 53ms/sec > C7200/NPE-G1 1 158days 15ms/sec > C7304/NSE100 4+2 177days 55ms/sec > C7200/NPE-G1 1+2 26days 8ms/sec > C7301 1 214days 7ms/sec > GR2000 0+1 101days 6ms/sec > > Upstream: M+N, M is # of EBGP with full route feed , N is # of IBGP > with full route feed > > Provided if the CPU consumption is propotional to the routing table > size, the hard limit would be 10 times to the current size, allowing > other tasks to obtain some CPU cycles. > > ----- End forwarded message ----- > > so, one might presume that w/o a change in algorithm, and unlimited > memory, that the CPU would run out of cycles to compute convergence > at ~ 10x the current size of the routing table (abt 250,000 prefixes). > > so putting a stake in the ground, BGP will stop working @ around > 2,500,000 routes - can't converge... regardless of IPv4 or IPv6. > unless the CPU's change or the convergence algorithm changes. > > --bill > _______________________________________________ > 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. > ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC From bicknell at ufp.org Fri Aug 10 12:36:50 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 10 Aug 2007 12:36:50 -0400 Subject: [ppml] too many variables In-Reply-To: <20070809162137.GA1797@vacation.karoshi.com.> References: <20070809162137.GA1797@vacation.karoshi.com.> Message-ID: <20070810163650.GA48274@ussenterprise.ufp.org> In a message written on Thu, Aug 09, 2007 at 04:21:37PM +0000, bmanning at vacation.karoshi.com wrote: > (1) there are technology factors we can't predict, e.g., > moore's law effects on hardware development Some of that is predictable though. I'm sitting here looking at a heavily peered exchange point router with a rather large FIB. It has in it a Pentium III 700Mhz processor. Per Wikipedia (http://en.wikipedia.org/wiki/Pentium_III) it appears they were released in late 1999 to early 2000. This box is solidly two, perhaps three, and maybe even 4 doublings behind things that are already available at your local best buy off the shelf. Heck, this chip is slower than the original Xbox chip, a $400 obsolete game console. -- 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 jmorrison at bogomips.com Fri Aug 10 13:24:41 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Fri, 10 Aug 2007 10:24:41 -0700 Subject: [ppml] too many variables In-Reply-To: <20070810163650.GA48274@ussenterprise.ufp.org> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> Message-ID: <46BC9F59.4020501@bogomips.com> And yet people still say the sky is falling with respect to routing convergence and FIB size. Probably a better comparison BTW, would be with a Nintendo or Playstation, as they are MIPS and PowerPC based. Even the latest route processor for a decent peering box is only a 1.2 GHz PowerPC with 2 GB RAM (RSP720) - so basically an old iBook is enough for the BGP control plane load these days? I think this has something to do with the vendors giving you just enough to keep you going, but not so much that you delay hardware upgrades :-) There have been big gains in silicon for the fast switched path, but the route processors even on high end routers are still pretty low end in comparison to what's common on the average desktop. I would say that when control plane/processor power becomes critical, I would hope to see better processors inside. With the IETF saying that speed and forwarding path are the bottlenecks now, not FIB size, perhaps there just isn't enough load to push Core Duo processors in your routers. (If Apple can switch, why not Cisco?) http://www3.ietf.org/proceedings/07mar/slides/plenaryw-3.pdf John Paul Morrison, CCIE 8191 A better comparison would be with a Playstation or Nintendo, Leo Bicknell wrote: > In a message written on Thu, Aug 09, 2007 at 04:21:37PM +0000, bmanning at vacation.karoshi.com wrote: > >> (1) there are technology factors we can't predict, e.g., >> moore's law effects on hardware development >> > > Some of that is predictable though. I'm sitting here looking at a > heavily peered exchange point router with a rather large FIB. It > has in it a Pentium III 700Mhz processor. Per Wikipedia > (http://en.wikipedia.org/wiki/Pentium_III) it appears they were > released in late 1999 to early 2000. This box is solidly two, > perhaps three, and maybe even 4 doublings behind things that are > already available at your local best buy off the shelf. > > Heck, this chip is slower than the original Xbox chip, a $400 > obsolete game console. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 tedm at ipinc.net Fri Aug 10 14:05:37 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 10 Aug 2007 11:05:37 -0700 Subject: [ppml] too many variables In-Reply-To: <20070810163650.GA48274@ussenterprise.ufp.org> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Leo Bicknell >Sent: Friday, August 10, 2007 9:37 AM >To: bmanning at vacation.karoshi.com >Cc: ppml at arin.net; nanog at nanog.org >Subject: Re: [ppml] too many variables > > >In a message written on Thu, Aug 09, 2007 at 04:21:37PM +0000, >bmanning at vacation.karoshi.com wrote: >> (1) there are technology factors we can't predict, e.g., >> moore's law effects on hardware development > >Some of that is predictable though. I'm sitting here looking at a >heavily peered exchange point router with a rather large FIB. It >has in it a Pentium III 700Mhz processor. Per Wikipedia >(http://en.wikipedia.org/wiki/Pentium_III) it appears they were >released in late 1999 to early 2000. This box is solidly two, >perhaps three, and maybe even 4 doublings behind things that are >already available at your local best buy off the shelf. > >Heck, this chip is slower than the original Xbox chip, a $400 >obsolete game console. > Leo, I think you should take your old Xbox and load Linux on it, you can get it here: http://www.xbox-linux.org/wiki/Download Then load Quagga on that and route your BGP with it, you can get that here: http://www.quagga.net/ Then when that is up and running call in your router vendor sales representative and ask him why should all of us bother buying new routers when we can just use any old Xbox to do the same thing, faster. maybe that might shame them into actually designing product with -current- technology. Is it just me that finds it deplorable that the large router vendors see fit to charge billions of bucks for technology that any current microwave oven controller could knock into a cocked hat? Ted From vgill at vijaygill.com Fri Aug 10 14:08:26 2007 From: vgill at vijaygill.com (vijay gill) Date: Fri, 10 Aug 2007 11:08:26 -0700 Subject: [ppml] too many variables In-Reply-To: <46BC9F59.4020501@bogomips.com> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> Message-ID: <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> On 8/10/07, John Paul Morrison wrote: > > And yet people still say the sky is falling with respect to routing > convergence and FIB size. Probably a better comparison BTW, would be with a > Nintendo or Playstation, as they are MIPS and PowerPC based. Even the latest > route processor for a decent peering box is only a 1.2 GHz PowerPC with 2 > GB RAM (RSP720) - so basically an old iBook is enough for the BGP control > plane load these days? I think this has something to do with the vendors > giving you just enough to keep you going, but not so much that you delay > hardware upgrades :-) > > There have been big gains in silicon for the fast switched path, but the > route processors even on high end routers are still pretty low end in > comparison to what's common on the average desktop. > I would say that when control plane/processor power becomes critical, I > would hope to see better processors inside. > > With the IETF saying that speed and forwarding path are the bottlenecks > now, not FIB size, perhaps there just isn't enough load to push Core Duo > processors in your routers. (If Apple can switch, why not Cisco?) > http://www3.ietf.org/proceedings/07mar/slides/plenaryw-3.pdf > I guess people are still spectacularly missing the real point. The point isn't that the latest generation hardware cpu du jour you can pick up from the local hardware store is doubling processing power every n months. The point is that getting them qualified, tested, verified, and then deployed is a non trivial task. We need to be substantially behind moores observation to be economically viable. I have some small number of route processors in my network and it is a major hassle to get even those few upgraded. In other words, if you have a network that you can upgrade the RPs on every 18 months, let me know. /vijay John Paul Morrison, CCIE 8191 > > A better comparison would be with a Playstation or Nintendo, > > Leo Bicknell wrote: > > In a message written on Thu, Aug 09, 2007 at 04:21:37PM +0000, bmanning at vacation.karoshi.com wrote: > > (1) there are technology factors we can't predict, e.g., > moore's law effects on hardware development > > Some of that is predictable though. I'm sitting here looking at a > heavily peered exchange point router with a rather large FIB. It > has in it a Pentium III 700Mhz processor. Per Wikipedia > (http://en.wikipedia.org/wiki/Pentium_III) it appears they were > released in late 1999 to early 2000. This box is solidly two, > perhaps three, and maybe even 4 doublings behind things that are > already available at your local best buy off the shelf. > > Heck, this chip is slower than the original Xbox chip, a $400 > obsolete game console. > > ------------------------------ > > _______________________________________________ > 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. > > > > _______________________________________________ > 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 bicknell at ufp.org Fri Aug 10 14:24:55 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 10 Aug 2007 14:24:55 -0400 Subject: [ppml] too many variables In-Reply-To: <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> Message-ID: <20070810182455.GA57260@ussenterprise.ufp.org> In a message written on Fri, Aug 10, 2007 at 11:08:26AM -0700, vijay gill wrote: > substantially behind moores observation to be economically viable. I > have some small number of route processors in my network and it is a > major hassle to get even those few upgraded. In other words, if you > have a network that you can upgrade the RPs on every 18 months, let me You're mixing problems. Even though you may only be able to put in a new route processor every 3-5 years doesn't mean the vendor shouldn't have a faster version every 18 months, or even sooner. It's the addition of the two that's the problem. You're 5 year cycle may come a year before the vendors 5 year cycle, putting you on 9 year old gear before you refresh next. Vendor J got it half right. The RP is a separately replaceable component based on a commodity motherboard, hooked in with commodity ethernet, using the most popular CPU and ram on the market. And yes, I understand needing to pay extra for the sheet metal, cooling calculations, and other items. But, they still cost 10x a PC based on the same components, and are upgraded perhaps every 3 years, at best. They don't even take advantage of perhaps going from a 2.0Ghz processor to a 2.4, using the same motherboard, RAM, disk, etc. But I think the point still stands, I bet Vendor J in particular could pop out a Core 2 Duo based RP with 8 gig of ram and a 300+ gig hard drive in under 6 months while holding the price point if BGP convergence demanded it, and their customers made it a priority. To Bill's original e-mail. Can we count on 2x every 18 months going forward? No. But betting on 2x every 24 months, and accounting for the delta between currently shipping and currently available hardware seems completely reasonable when assessing the real problem. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From paul at vix.com Fri Aug 10 14:32:59 2007 From: paul at vix.com (Paul Vixie) Date: Fri, 10 Aug 2007 18:32:59 +0000 Subject: [ppml] too many variables In-Reply-To: Your message of "Fri, 10 Aug 2007 11:08:26 MST." <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> Message-ID: <61720.1186770779@sa.vix.com> [ vijay] > I guess people are still spectacularly missing the real point. The point > isn't that the latest generation hardware cpu du jour you can pick up from > the local hardware store is doubling processing power every n months. agreed. > The point is that getting them qualified, tested, verified, and then > deployed is a non trivial task. We need to be substantially behind moores > observation to be economically viable. I have some small number of route > processors in my network and it is a major hassle to get even those few > upgraded. In other words, if you have a network that you can upgrade the RPs > on every 18 months, let me know. yow. while i agree that routing processors cannot, and have historically not had to, track moore's law, i am still surprised to see such a heavy focus on the RP. my (ample) gut feeling on this is that system level (combinatorial) effects would limit Internet routing long before moore's law could do so. From vgill at vijaygill.com Fri Aug 10 14:33:34 2007 From: vgill at vijaygill.com (vijay gill) Date: Fri, 10 Aug 2007 11:33:34 -0700 Subject: [ppml] too many variables In-Reply-To: <20070810182455.GA57260@ussenterprise.ufp.org> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> <20070810182455.GA57260@ussenterprise.ufp.org> Message-ID: <21ef2c1c0708101133h635397f4r6a7e8d60eb0d7462@mail.gmail.com> On 8/10/07, Leo Bicknell wrote: > > In a message written on Fri, Aug 10, 2007 at 11:08:26AM -0700, vijay gill > wrote: > > substantially behind moores observation to be economically viable. I > > have some small number of route processors in my network and it is a > > major hassle to get even those few upgraded. In other words, if you > > have a network that you can upgrade the RPs on every 18 months, let > me > > You're mixing problems. > > Even though you may only be able to put in a new route processor > every 3-5 years doesn't mean the vendor shouldn't have a faster > version every 18 months, or even sooner. It's the addition of the > two that's the problem. You're 5 year cycle may come a year before > the vendors 5 year cycle, putting you on 9 year old gear before you > refresh next. The vendor has to qualify, write code for, and support n versions. This IS a part of the problem. Just blindly swapping out CPUs is non trivial, as any systems engineer can tell you. The support cost will be passed on to the consumer. /vijay Vendor J got it half right. The RP is a separately replaceable > component based on a commodity motherboard, hooked in with commodity > ethernet, using the most popular CPU and ram on the market. And > yes, I understand needing to pay extra for the sheet metal, cooling > calculations, and other items. > > But, they still cost 10x a PC based on the same components, and are > upgraded perhaps every 3 years, at best. They don't even take > advantage of perhaps going from a 2.0Ghz processor to a 2.4, using > the same motherboard, RAM, disk, etc. > > But I think the point still stands, I bet Vendor J in particular > could pop out a Core 2 Duo based RP with 8 gig of ram and a 300+ > gig hard drive in under 6 months while holding the price point if > BGP convergence demanded it, and their customers made it a priority. > > To Bill's original e-mail. Can we count on 2x every 18 months going > forward? No. But betting on 2x every 24 months, and accounting for the > delta between currently shipping and currently available hardware seems > completely reasonable when assessing the real problem. > > -- > 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 > > _______________________________________________ > 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 vgill at vijaygill.com Fri Aug 10 14:36:07 2007 From: vgill at vijaygill.com (vijay gill) Date: Fri, 10 Aug 2007 11:36:07 -0700 Subject: [ppml] too many variables In-Reply-To: <61720.1186770779@sa.vix.com> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> <61720.1186770779@sa.vix.com> Message-ID: <21ef2c1c0708101136w1507772dv91b258b6dc248b0f@mail.gmail.com> On 8/10/07, Paul Vixie wrote: > > [ vijay] > > > I guess people are still spectacularly missing the real point. The > point > > isn't that the latest generation hardware cpu du jour you can pick up > from > > the local hardware store is doubling processing power every n months. > > agreed. > > > The point is that getting them qualified, tested, verified, and then > > deployed is a non trivial task. We need to be substantially behind > moores > > observation to be economically viable. I have some small number of route > > processors in my network and it is a major hassle to get even those few > > upgraded. In other words, if you have a network that you can upgrade the > RPs > > on every 18 months, let me know. > > yow. while i agree that routing processors cannot, and have historically > not > had to, track moore's law, i am still surprised to see such a heavy focus > on > the RP. my (ample) gut feeling on this is that system level > (combinatorial) > effects would limit Internet routing long before moore's law could do so. It is an easy derivative/proxy for the system level effect is all. Bandwidth for updates (inter and intra system) are another choking point but folks tend to be even less aware of those than cpu. /vijay -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Fri Aug 10 14:37:50 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 10 Aug 2007 11:37:50 -0700 Subject: [ppml] too many variables In-Reply-To: <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> Message-ID: > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of vijay gill > Sent: Friday, August 10, 2007 11:08 AM > To: John Paul Morrison > Cc: ppml at arin.net; nanog at nanog.org > Subject: Re: [ppml] too many variables > I guess people are still spectacularly missing the real point. The point isn't that the latest generation > hardware cpu du jour you can pick up from the local hardware store is doubling processing power every n months. > The point is that getting them qualified, tested, verified, and then deployed is a non trivial task. This is nonsense. The hardware cpu de jour that you pick up from the local chop shop is 1-2 years BEHIND what the high end fileserver vendors are using. Companies like HP go through a qualification, testing and verification process for their high end gear that is no less rigorous than what Cisco uses. The big difference is that the PC vendors get the processors from Intel and AMD when they are in beta, and do their design and development while Intel and AMD are doing their own CPU design and development. So when Intel is done and ready to release, there is little work for the PC vendors left to do to ship complete product. The router vendors are approaching this like Ford and Chevy build car computers. They can get old Pentium 3 700Mhz chips for a few bucks a processor so that is what they are using. They can make an extra $90 in profit selling a $5000 router CPU card that has a $10 processor in it than a $5000 router CPU card that has a $100 processor in it. And from a marketing perspective if the router uses some exotic RISC chip that nobody has ever heard of, (because it's 15 year old obsolete technology) that somewhat insulates them from unflattering comparisons like what people are making here. This kind of attitude is symptomatic of the embedded systems industry. Price the stuff out first THEN develop for it. This is why for example you don't have an Ethernet jack in your automobile that you can plug a laptop in and get a complete fault code analysis for a vehicle failure from an embedded webserver in the engine computer. The embedded systems people insist on reinventing the wheel every time they design something and do their best to ignore what goes on in the PC world. Go ahead and make your arguments about deployment, but it is the router vendors who are foot dragging here. Ted From vgill at vijaygill.com Fri Aug 10 14:41:46 2007 From: vgill at vijaygill.com (vijay gill) Date: Fri, 10 Aug 2007 11:41:46 -0700 Subject: [ppml] too many variables In-Reply-To: References: <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> Message-ID: <21ef2c1c0708101141n3856e2edq53393c50a10ddfdb@mail.gmail.com> On 8/10/07, Ted Mittelstaedt wrote: > > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > vijay gill > > Sent: Friday, August 10, 2007 11:08 AM > > To: John Paul Morrison > > Cc: ppml at arin.net; nanog at nanog.org > > Subject: Re: [ppml] too many variables > > > > I guess people are still spectacularly missing the real point. The point > isn't that the latest generation > > hardware cpu du jour you can pick up from the local hardware store is > doubling processing power every n months. > > The point is that getting them qualified, tested, verified, and then > deployed is a non trivial task. > > This is nonsense. The hardware cpu de jour that you pick up from the > local > chop shop is 1-2 years > BEHIND what the high end fileserver vendors are using. Companies like HP > go > through a qualification, > testing and verification process for their high end gear that is no less > rigorous than what Cisco uses. I knew reading nanog was a bad idea. However, now that I am well and truly in the weeds, might as well go forth. The phrase that I think I am looking for is.... it's coming to me...almost there.... ah yes amortization specifically amortization...units sold... cost basis... something something. /vijay The big difference is that the PC vendors get the processors from Intel and > AMD when they are > in beta, and do their design and development while Intel and AMD are doing > their own > CPU design and development. So when Intel is done and ready to release, > there is little work > for the PC vendors left to do to ship complete product. > > The router vendors are approaching this like Ford and Chevy build car > computers. They can get > old Pentium 3 700Mhz chips for a few bucks a processor so that is what > they > are using. They > can make an extra $90 in profit selling a $5000 router CPU card that has a > $10 processor in it than > a $5000 router CPU card that has a $100 processor in it. And from a > marketing perspective if > the router uses some exotic RISC chip that nobody has ever heard of, > (because it's 15 year old > obsolete technology) that somewhat insulates them from unflattering > comparisons like what > people are making here. > > This kind of attitude is symptomatic of the embedded systems industry. > Price the stuff out first > THEN develop for it. This is why for example you don't have an Ethernet > jack in your automobile > that you can plug a laptop in and get a complete fault code analysis for a > vehicle failure > from an embedded webserver in the engine computer. The embedded systems > people insist on > reinventing the wheel every time they design something and do their best > to > ignore what > goes on in the PC world. > > Go ahead and make your arguments about deployment, but it is the router > vendors who are foot > dragging here. > > Ted > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at vix.com Fri Aug 10 14:42:23 2007 From: paul at vix.com (Paul Vixie) Date: Fri, 10 Aug 2007 18:42:23 +0000 Subject: [ppml] too many variables In-Reply-To: Your message of "Fri, 10 Aug 2007 11:36:07 MST." <21ef2c1c0708101136w1507772dv91b258b6dc248b0f@mail.gmail.com> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> <61720.1186770779@sa.vix.com> <21ef2c1c0708101136w1507772dv91b258b6dc248b0f@mail.gmail.com> Message-ID: <62683.1186771343@sa.vix.com> > > ... is that system level (combinatorial) effects would limit Internet > > routing long before moore's law could do so. > > It is an easy derivative/proxy for the system level effect is all. Bandwidth > for updates (inter and intra system) are another choking point but folks > tend to be even less aware of those than cpu. is bandwidth the only consideration? number of graph nodes and number of advertised endpoints and churn rate per endpoint don't enter into the limits? at what system size does speed of light begin to enter into the equation? (note, as i told geoff huston: if it seems like john scudder's outbound BGP announcement compression observations are relevant, or that moore's law is relevant, then you're misunderstanding my question or i'm asking it wrong.) From tedm at ipinc.net Fri Aug 10 14:59:52 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 10 Aug 2007 11:59:52 -0700 Subject: [ppml] too many variables In-Reply-To: <21ef2c1c0708101141n3856e2edq53393c50a10ddfdb@mail.gmail.com> Message-ID: > -----Original Message----- > From: vijay gill [mailto:vgill at vijaygill.com] > Sent: Friday, August 10, 2007 11:42 AM > To: Ted Mittelstaedt > Cc: John Paul Morrison; ppml at arin.net; nanog at nanog.org > Subject: Re: [ppml] too many variables > I knew reading nanog was a bad idea. However, now that I am well and truly in the weeds, > might as well go forth. > The phrase that I think I am looking for is.... it's coming to me...almost there.... ah yes > amortization specifically amortization...units sold... cost basis... something something. Which has nothing to do with what I was saying. And, nothing to do with what you said initially - which was testing. An embedded system vendor can go out right now and start a brand new design that will be ready for sale in 3 years from now. They can use a beta CPU that isn't for sale now. They can use a new CPU that costs $150 per Or they can use a 4 year old CPU that costs $50 per They know in 3 years the beta CPU will be new, and will cost about $200 per They know in 3 years the new CPU now will be 3 years old and will cost about $100 per In 3 years from now the 4 year old CPU will be 7 years old and will cost about $20 per The cost to design and develop the product with all the sheet metal and controllers and everything else is going to be about the same. And as you point out quantity sold dictates price. But adding an extra $100 to $200 to the cost of a $5000 item to allow the designers to select a CPU that is 4-5 years newer is very possible. Using commodity controller parts instead of special-ordering everything or having it built-to-spec is also very possible. The problem is attitude - the embedded systems people are beancounters and if they can save $50 on a part that would go into a $5000 list item, even when that additional $50 would tremendously improve the power of the device, they will do it. As someone else pointed out, the customers aren't demanding CPU power in routers, so the router vendors aren't focusing on that. But when the customers do start demanding it, the router vendors will not have any problem providing it. Ted From vgill at vijaygill.com Fri Aug 10 14:33:34 2007 From: vgill at vijaygill.com (vijay gill) Date: Fri, 10 Aug 2007 11:33:34 -0700 Subject: [ppml] too many variables In-Reply-To: <20070810182455.GA57260@ussenterprise.ufp.org> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> <20070810182455.GA57260@ussenterprise.ufp.org> Message-ID: <21ef2c1c0708101133h635397f4r6a7e8d60eb0d7462@mail.gmail.com> On 8/10/07, Leo Bicknell wrote: > > In a message written on Fri, Aug 10, 2007 at 11:08:26AM -0700, vijay gill > wrote: > > substantially behind moores observation to be economically viable. I > > have some small number of route processors in my network and it is a > > major hassle to get even those few upgraded. In other words, if you > > have a network that you can upgrade the RPs on every 18 months, let > me > > You're mixing problems. > > Even though you may only be able to put in a new route processor > every 3-5 years doesn't mean the vendor shouldn't have a faster > version every 18 months, or even sooner. It's the addition of the > two that's the problem. You're 5 year cycle may come a year before > the vendors 5 year cycle, putting you on 9 year old gear before you > refresh next. The vendor has to qualify, write code for, and support n versions. This IS a part of the problem. Just blindly swapping out CPUs is non trivial, as any systems engineer can tell you. The support cost will be passed on to the consumer. /vijay Vendor J got it half right. The RP is a separately replaceable > component based on a commodity motherboard, hooked in with commodity > ethernet, using the most popular CPU and ram on the market. And > yes, I understand needing to pay extra for the sheet metal, cooling > calculations, and other items. > > But, they still cost 10x a PC based on the same components, and are > upgraded perhaps every 3 years, at best. They don't even take > advantage of perhaps going from a 2.0Ghz processor to a 2.4, using > the same motherboard, RAM, disk, etc. > > But I think the point still stands, I bet Vendor J in particular > could pop out a Core 2 Duo based RP with 8 gig of ram and a 300+ > gig hard drive in under 6 months while holding the price point if > BGP convergence demanded it, and their customers made it a priority. > > To Bill's original e-mail. Can we count on 2x every 18 months going > forward? No. But betting on 2x every 24 months, and accounting for the > delta between currently shipping and currently available hardware seems > completely reasonable when assessing the real problem. > > -- > 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 > > _______________________________________________ > 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 paul at vix.com Fri Aug 10 14:42:23 2007 From: paul at vix.com (Paul Vixie) Date: Fri, 10 Aug 2007 18:42:23 +0000 Subject: [ppml] too many variables In-Reply-To: Your message of "Fri, 10 Aug 2007 11:36:07 MST." <21ef2c1c0708101136w1507772dv91b258b6dc248b0f@mail.gmail.com> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> <61720.1186770779@sa.vix.com> <21ef2c1c0708101136w1507772dv91b258b6dc248b0f@mail.gmail.com> Message-ID: <62683.1186771343@sa.vix.com> > > ... is that system level (combinatorial) effects would limit Internet > > routing long before moore's law could do so. > > It is an easy derivative/proxy for the system level effect is all. Bandwidth > for updates (inter and intra system) are another choking point but folks > tend to be even less aware of those than cpu. is bandwidth the only consideration? number of graph nodes and number of advertised endpoints and churn rate per endpoint don't enter into the limits? at what system size does speed of light begin to enter into the equation? (note, as i told geoff huston: if it seems like john scudder's outbound BGP announcement compression observations are relevant, or that moore's law is relevant, then you're misunderstanding my question or i'm asking it wrong.) From vgill at vijaygill.com Fri Aug 10 14:41:46 2007 From: vgill at vijaygill.com (vijay gill) Date: Fri, 10 Aug 2007 11:41:46 -0700 Subject: [ppml] too many variables In-Reply-To: References: <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> Message-ID: <21ef2c1c0708101141n3856e2edq53393c50a10ddfdb@mail.gmail.com> On 8/10/07, Ted Mittelstaedt wrote: > > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > vijay gill > > Sent: Friday, August 10, 2007 11:08 AM > > To: John Paul Morrison > > Cc: ppml at arin.net; nanog at nanog.org > > Subject: Re: [ppml] too many variables > > > > I guess people are still spectacularly missing the real point. The point > isn't that the latest generation > > hardware cpu du jour you can pick up from the local hardware store is > doubling processing power every n months. > > The point is that getting them qualified, tested, verified, and then > deployed is a non trivial task. > > This is nonsense. The hardware cpu de jour that you pick up from the > local > chop shop is 1-2 years > BEHIND what the high end fileserver vendors are using. Companies like HP > go > through a qualification, > testing and verification process for their high end gear that is no less > rigorous than what Cisco uses. I knew reading nanog was a bad idea. However, now that I am well and truly in the weeds, might as well go forth. The phrase that I think I am looking for is.... it's coming to me...almost there.... ah yes amortization specifically amortization...units sold... cost basis... something something. /vijay The big difference is that the PC vendors get the processors from Intel and > AMD when they are > in beta, and do their design and development while Intel and AMD are doing > their own > CPU design and development. So when Intel is done and ready to release, > there is little work > for the PC vendors left to do to ship complete product. > > The router vendors are approaching this like Ford and Chevy build car > computers. They can get > old Pentium 3 700Mhz chips for a few bucks a processor so that is what > they > are using. They > can make an extra $90 in profit selling a $5000 router CPU card that has a > $10 processor in it than > a $5000 router CPU card that has a $100 processor in it. And from a > marketing perspective if > the router uses some exotic RISC chip that nobody has ever heard of, > (because it's 15 year old > obsolete technology) that somewhat insulates them from unflattering > comparisons like what > people are making here. > > This kind of attitude is symptomatic of the embedded systems industry. > Price the stuff out first > THEN develop for it. This is why for example you don't have an Ethernet > jack in your automobile > that you can plug a laptop in and get a complete fault code analysis for a > vehicle failure > from an embedded webserver in the engine computer. The embedded systems > people insist on > reinventing the wheel every time they design something and do their best > to > ignore what > goes on in the PC world. > > Go ahead and make your arguments about deployment, but it is the router > vendors who are foot > dragging here. > > Ted > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vgill at vijaygill.com Fri Aug 10 14:36:07 2007 From: vgill at vijaygill.com (vijay gill) Date: Fri, 10 Aug 2007 11:36:07 -0700 Subject: [ppml] too many variables In-Reply-To: <61720.1186770779@sa.vix.com> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> <61720.1186770779@sa.vix.com> Message-ID: <21ef2c1c0708101136w1507772dv91b258b6dc248b0f@mail.gmail.com> On 8/10/07, Paul Vixie wrote: > > [ vijay] > > > I guess people are still spectacularly missing the real point. The > point > > isn't that the latest generation hardware cpu du jour you can pick up > from > > the local hardware store is doubling processing power every n months. > > agreed. > > > The point is that getting them qualified, tested, verified, and then > > deployed is a non trivial task. We need to be substantially behind > moores > > observation to be economically viable. I have some small number of route > > processors in my network and it is a major hassle to get even those few > > upgraded. In other words, if you have a network that you can upgrade the > RPs > > on every 18 months, let me know. > > yow. while i agree that routing processors cannot, and have historically > not > had to, track moore's law, i am still surprised to see such a heavy focus > on > the RP. my (ample) gut feeling on this is that system level > (combinatorial) > effects would limit Internet routing long before moore's law could do so. It is an easy derivative/proxy for the system level effect is all. Bandwidth for updates (inter and intra system) are another choking point but folks tend to be even less aware of those than cpu. /vijay -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at vix.com Fri Aug 10 14:32:59 2007 From: paul at vix.com (Paul Vixie) Date: Fri, 10 Aug 2007 18:32:59 +0000 Subject: [ppml] too many variables In-Reply-To: Your message of "Fri, 10 Aug 2007 11:08:26 MST." <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> Message-ID: <61720.1186770779@sa.vix.com> [ vijay] > I guess people are still spectacularly missing the real point. The point > isn't that the latest generation hardware cpu du jour you can pick up from > the local hardware store is doubling processing power every n months. agreed. > The point is that getting them qualified, tested, verified, and then > deployed is a non trivial task. We need to be substantially behind moores > observation to be economically viable. I have some small number of route > processors in my network and it is a major hassle to get even those few > upgraded. In other words, if you have a network that you can upgrade the RPs > on every 18 months, let me know. yow. while i agree that routing processors cannot, and have historically not had to, track moore's law, i am still surprised to see such a heavy focus on the RP. my (ample) gut feeling on this is that system level (combinatorial) effects would limit Internet routing long before moore's law could do so. From stephen at sprunk.org Sat Aug 11 20:27:43 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 11 Aug 2007 19:27:43 -0500 Subject: [ppml] alternative realities References: <447A9D20-0B10-4341-A488-FE9F7E6D0BD2@virtualized.org><46B8D07C.9080300@mcsnet.ca> <70DE64CEFD6E9A4EB7FAF3A06314106670726D@mail> Message-ID: <033a01c7dc7b$b5a0a240$6401a8c0@atlanta.polycom.com> Thus spake "Kevin Kargel" > I have a hard time accepting any philosophy that says "just make > it more expensive because your can".. I, too, disagree with that. However, the reality is that for most operators, v4 is going to rapidly grow in cost no matter what we do. The laissez-faire types are saying that we should just wait for it to happen and that will be the motivation for people to migrate to v6. However, I personally think that's too late, and that it's reasonable to consider trying to smooth out those costs so that people can see what's coming and get v6 ready before the combined cost of keeping v4 running _and_ trying to roll out v6 bankrupts them. > What you will do by artificially jacking v4 prices is rape the small > shops and drive them out of business. Maybe that is your intent, to > leave consumers with nobody to deal with but the mega-ISP's.. > personally I think that is a pretty sad way to think about it. Part of the problem is that the smaller folks, and those that conserve, are punished by the current fee schedule but those who consume massive amounts (80% of the total) address space pay _virtually nothing_ for waste. If we were to rationalize the fees, such that everyone paid the same, the fees of smaller, cash-strapped businesses would go _down_ while the space hogs would be motivated to provide the desperately-needed critical mass of v6 deployment. > There is nothing evil about leaving IPv4 in place. If you don't want to > use it then don't use it. People will migrate to v6 as content does, > and as hardware evolves to handle it. This will be a natural and > unavoidable transition. It's not unavoidable; it's entirely possible that the Internet will evolve into a multi-layered v4 NAT network with the vast majority of endpoints being second-class "client-only" hosts and absurd costs for getting first-class server address space. Keep in mind that certain ISPs benefit from this and it fits the thinking of their Bell-shaped heads. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From christopher.morrow at gmail.com Sun Aug 12 00:24:03 2007 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Sun, 12 Aug 2007 00:24:03 -0400 Subject: [ppml] too many variables In-Reply-To: <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> Message-ID: <75cb24520708112124y4074effcr80c836c6cc93720a@mail.gmail.com> On 8/10/07, vijay gill wrote: > I guess people are still spectacularly missing the real point. The point > isn't that the latest generation hardware cpu du jour you can pick up from > the local hardware store is doubling processing power every n months. The > point is that getting them qualified, tested, verified, and then deployed is > a non trivial task. We need to be substantially behind moores observation to > be economically viable. I have some small number of route processors in my > network and it is a major hassle to get even those few upgraded. In other > words, if you have a network that you can upgrade the RPs on every 18 > months, let me know. Also, the problem isn't JUST the RP... there are many parts to this problem, focus on the RP alone isn't going to solve the problem in the longer term. I suspect this is also in the area of 'a PITA to get tested/validated/installed' for any trivially sized network since it may require architectural changes to the devices. -Chris From christopher.morrow at gmail.com Sun Aug 12 00:28:31 2007 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Sun, 12 Aug 2007 00:28:31 -0400 Subject: [ppml] too many variables In-Reply-To: <20070810182455.GA57260@ussenterprise.ufp.org> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> <20070810182455.GA57260@ussenterprise.ufp.org> Message-ID: <75cb24520708112128u1a77e9fflf05789f53b5a2bcf@mail.gmail.com> On 8/10/07, Leo Bicknell wrote: > But I think the point still stands, I bet Vendor J in particular > could pop out a Core 2 Duo based RP with 8 gig of ram and a 300+ > gig hard drive in under 6 months while holding the price point if > BGP convergence demanded it, and their customers made it a priority. This does still presume that the problem is resolved with just more ram and cpu cycles on the 'RP'... note that the FIB isn't held in RAM in larger gear and clock cycles on existing gear may already be faster than the pathway from RIB to FIB. I think Vijay was getting at this, and PaulV's aiming at that later on in this discussion (combinatorial effects)... Putting a really large engine in a ford festiva may make lots of horsepower, but you still can't take the clown brigade to the movies in it (not easily atleast). From michael.dillon at bt.com Sun Aug 12 13:29:13 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 12 Aug 2007 18:29:13 +0100 Subject: [ppml] too many variables In-Reply-To: <46BC9F59.4020501@bogomips.com> References: <20070809162137.GA1797@vacation.karoshi.com><20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> Message-ID: > And yet people still say the sky is falling with > respect to routing convergence and FIB size. > Probably a better comparison BTW, would be with a Actually, the better comparison is with the power of current processors used in Juniper and Cisco gear with the current Moore's law power of common off-the-shelf PC processors. Then go back to the point in time when there were real actual issues with FIB size on routers, and look at the same relative power. Today, is there a bigger or a smaller gap than way back when there were real problems on the net. If the gap is bigger or the same, then we are nuts to worry about it. If the gap is significantly smaller then we should get some serious researchers to figure out the real limits of current technology and the future technology at the point where the gap has gone to zero. --Michael Dillon From m.hertrick at neovera.com Sun Aug 12 16:53:27 2007 From: m.hertrick at neovera.com (Michael Hertrick) Date: Sun, 12 Aug 2007 16:53:27 -0400 Subject: [ppml] too many variables In-Reply-To: References: <20070809162137.GA1797@vacation.karoshi.com><20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> Message-ID: <46BF7347.7050509@neovera.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Would anyone on the ARIN PPML care to comment on the use of MPLS to relieve core routers of the BGP overhead? Is MPLS relevant to the discussion? Thanks, Mike. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGv3NHcJVdtfpkLb8RAveFAJ0UJLrCrYHPso3K/KYkZtV0JYZVsACcDELc AaFvh32VAh0pkEu9d2vjs7k= =X5PH -----END PGP SIGNATURE----- From randy at psg.com Sun Aug 12 17:51:16 2007 From: randy at psg.com (Randy Bush) Date: Sun, 12 Aug 2007 11:51:16 -1000 Subject: [ppml] too many variables In-Reply-To: <46BF7347.7050509@neovera.com> References: <20070809162137.GA1797@vacation.karoshi.com><20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <46BF7347.7050509@neovera.com> Message-ID: <46BF80D4.7030504@psg.com> Michael Hertrick wrote: > Would anyone on the ARIN PPML care to comment on the use of MPLS to > relieve core routers of the BGP overhead? helps as much as ether switches or atm. those non-ip things ain't routers, they're switches. randy From christopher.morrow at gmail.com Sun Aug 12 20:41:32 2007 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Sun, 12 Aug 2007 20:41:32 -0400 Subject: [ppml] too many variables In-Reply-To: <46BF80D4.7030504@psg.com> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <46BF7347.7050509@neovera.com> <46BF80D4.7030504@psg.com> Message-ID: <75cb24520708121741me5178d7ve78c88bd3a6c03cc@mail.gmail.com> On 8/12/07, Randy Bush wrote: > Michael Hertrick wrote: > > Would anyone on the ARIN PPML care to comment on the use of MPLS to > > relieve core routers of the BGP overhead? > > helps as much as ether switches or atm. those non-ip things ain't > routers, they're switches. because in the end if you have to know where all networks are and 0/0 -> left doesn't solve it well enough for you, mpls, atm, frame, it's all going to have to get to L3 and a /network/ at some point for resolution onward. -Chris From william at elan.net Mon Aug 13 05:08:48 2007 From: william at elan.net (william(at)elan.net) Date: Mon, 13 Aug 2007 02:08:48 -0700 (PDT) Subject: [ppml] too many variables In-Reply-To: <46BF7347.7050509@neovera.com> References: <20070809162137.GA1797@vacation.karoshi.com><20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <46BF7347.7050509@neovera.com> Message-ID: On Sun, 12 Aug 2007, Michael Hertrick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Would anyone on the ARIN PPML care to comment on the use of MPLS to > relieve core routers of the BGP overhead? > > Is MPLS relevant to the discussion? Isn't the right place for this question NANOG or IETF? -- William Leibzon Elan Networks william at elan.net From m.hertrick at neovera.com Mon Aug 13 09:24:40 2007 From: m.hertrick at neovera.com (=?utf-8?B?TWljaGFlbCBIZXJ0cmljaw==?=) Date: Mon, 13 Aug 2007 13:24:40 +0000 Subject: [ppml] too many variables In-Reply-To: References: <20070809162137.GA1797@vacation.karoshi.com><20070810163650.GA48274@ussenterprise.ufp.org><46BC9F59.4020501@bogomips.com> <46BF7347.7050509@neovera.com> Message-ID: <1593800701-1187011525-cardhu_decombobulator_blackberry.rim.net-2137942198-@bxe018.bisx.prod.on.blackberry> You're right. This does not belong here. Sent via BlackBerry by AT&T -----Original Message----- From: "william(at)elan.net" Date: Mon, 13 Aug 2007 02:08:48 To:Michael Hertrick Cc:ppml at arin.net Subject: Re: [ppml] too many variables On Sun, 12 Aug 2007, Michael Hertrick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Would anyone on the ARIN PPML care to comment on the use of MPLS to > relieve core routers of the BGP overhead? > > Is MPLS relevant to the discussion? Isn't the right place for this question NANOG or IETF? -- William Leibzon Elan Networks william at elan.net From bicknell at ufp.org Mon Aug 13 10:25:32 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 13 Aug 2007 10:25:32 -0400 Subject: [ppml] too many variables In-Reply-To: <46C04E9A.3050804@cisco.com> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> <20070810182455.GA57260@ussenterprise.ufp.org> <46C04E9A.3050804@cisco.com> Message-ID: <20070813142532.GA32490@ussenterprise.ufp.org> In a message written on Mon, Aug 13, 2007 at 02:29:14PM +0200, Eliot Lear wrote: > This assumes "the real problem" is CPU performance, where many have > argued that the real problem is memory bandwidth. Memory doesn't track > Moore's Law. Besides, Moore's Law isn't a law. What's your Plan B? > This is where a lot of RRG/RAM work is going on right now. I think there are multiple problems with core routers. However, the discussion here was about BGP being able to converge. For that, the FIB is not important, there need be no routing plane. What sort of computer does it take to get 200 sessions at an exchange point and compute a FIB in a "reasonable" amount of time? That's determined first by the implementation (algorithm) and second by the processor speed. It may also be impacted due to the bandwidth between routers, although I'm skeptical that's an issue. [Why? Let's say 10,000 routes per peer, and 50 peers all on a single giabit ethernet exchange. Let's also put an upper bound of 512 bytes per route. That's ~250Mbytes, or what, maybe 30 seconds?] It seems to me an off the shelf PC with a Core 2 Duo processor, 4 gig of memory, and a gigabit ethernet port would be 1-2 orders of magnitude faster than what's currently in the routers. Optimize for a multithreaded CPU, add a second and it would converge really fast. My own experience is that zebra / quagga blow away the performance of any router out there as long as you don't ask them to install the routes in the kernel (which is really slow in a general purpose OS). Now, once the FIB is computed, can we push it into line cards, is there enough memory on them, can they do wire rate lookups, etc are all good questions and all quickly drift into specialized hardware. There are no easy answers at that step... -- 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 Ed.Lewis at neustar.biz Mon Aug 13 10:51:54 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 13 Aug 2007 10:51:54 -0400 Subject: [ppml] too many variables In-Reply-To: References: <20070809162137.GA1797@vacation.karoshi.com><20070810163650.GA48274@ussent erprise.ufp.org> <46BC9F59.4020501@bogomips.com> <46BF7347.7050509@neovera.com> Message-ID: At 2:08 -0700 8/13/07, william(at)elan.net wrote: >Isn't the right place for this question NANOG or IETF? Ordinarily I don't like to discourage discussion no matter how tangential it is to the main theme of the list, but in this case I agree. ARIN has the responsibility to develop and follow address assignment procedures that maximize the value of the networks it supports, in particular the global public Internet (but not limited to that network). To do this, it is important to understand, like an avid fan of a sport, the nuances of the network and in particular it's system of routing. Like sports fans though, ARIN is powerless (realistically) to "fix" the problems of the operational aspect of the network. No more so than yelling "change the pitcher" gets the manager out of the dugout and to the mound will our discussion of Moore's law help the situation. Especially as there are so many subtle points to balance. Reading though all of the messages on this list, I don't believe there is any policy ARIN can use to solve the problem of routing, hence, not remove what is probably the largest bottleneck to IPv6 adoption. (I recall a discussion about the about to started 6Bone experiment in which someone said "it's a great idea, but as it rides on tunnels in v4 we won't get to test out any meaningful routing solution.") But we can scream "change the pitcher (protocol)" when the pitch count gets high. IPv6 has more destinations than IPv4. IPv6 was supposed to be able to count on traffic aggregation to make it run smoother. In the intervening years the network has evolved in ways that make route aggregation less likely to happen. Demand for traffic engineering, multihoming, etc., drive PI space needs. Failures of ISPs post-boom have made organizations unlikely to rely on one ISP's address space. I don't think that the routing problem is a situation ARIN can really fix. ARIN can only hope to maximize the benefit of allocating addresses one way or another to make the networks work. We can't do much about solving the need to reach all the destinations in the network in the way the users of the Internet want to reach them (and be reached by them). It's good to be up on the topic, but what is apparent is either a new engineering approach to find one's way from one point in a network to another or some operational practice that divides the problem of navigation into simpler ones that we can solve with proven technology. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. From jmorrison at bogomips.com Mon Aug 13 15:45:57 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Mon, 13 Aug 2007 12:45:57 -0700 Subject: [ppml] too many variables In-Reply-To: <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> Message-ID: <46C0B4F5.6070801@bogomips.com> No, the real point is that there is a big gap between the best current CPU technology, and what is available for sale today in high end routers marketed at service providers. I mean a single core, 1.2 GHz processor is quite a bit behind a 3 GHz, multi-core processor which is available today on high end, qualified and tested servers. And probably behind by more than 18 months too. I think this is proof that there are a lot of other factors driving network technology, because if there were really enough demand or market for it, we'd see 3GHz multicore procs for sale in routers NOW, not in 18 - 24 months. Since the control plane side of the equation is at least 18-24 months behind the curve, I think this makes it very hard to argue that BGP and Internet routing are in dire shape and are about to collapse. Another point: how many people run their boxes at 80 or 90% CPU in well managed production networks? Most people I know would like to see them practically idle, with the line cards or silicon doing the work, or at least under 50%. So if most well run networks are running boxes with CPU's 18 months behind the Moore's law curve, and running them at 50%, wouldn't this mean that they are running about 36 months behind? I'd say we're not really looking at CPU bound problems. vijay gill wrote: > > > On 8/10/07, *John Paul Morrison* > wrote: > > And yet people still say the sky is falling with respect to > routing convergence and FIB size. Probably a better comparison > BTW, would be with a Nintendo or Playstation, as they are MIPS and > PowerPC based. Even the latest route processor for a decent > peering box is only a 1.2 GHz PowerPC with 2 GB RAM (RSP720) - so > basically an old iBook is enough for the BGP control plane load > these days? I think this has something to do with the vendors > giving you just enough to keep you going, but not so much that you > delay hardware upgrades :-) > > There have been big gains in silicon for the fast switched path, > but the route processors even on high end routers are still pretty > low end in comparison to what's common on the average desktop. > I would say that when control plane/processor power becomes > critical, I would hope to see better processors inside. > > With the IETF saying that speed and forwarding path are the > bottlenecks now, not FIB size, perhaps there just isn't enough > load to push Core Duo processors in your routers. (If Apple can > switch, why not Cisco?) > http://www3.ietf.org/proceedings/07mar/slides/plenaryw-3.pdf > > > > > I guess people are still spectacularly missing the real point. The > point isn't that the latest generation hardware cpu du jour you can > pick up from the local hardware store is doubling processing power > every n months. The point is that getting them qualified, tested, > verified, and then deployed is a non trivial task. We need to be > substantially behind moores observation to be economically viable. I > have some small number of route processors in my network and it is a > major hassle to get even those few upgraded. In other words, if you > have a network that you can upgrade the RPs on every 18 months, let me > know. > > /vijay > > > John Paul Morrison, CCIE 8191 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmorrison at bogomips.com Mon Aug 13 15:58:20 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Mon, 13 Aug 2007 12:58:20 -0700 Subject: [ppml] too many variables In-Reply-To: References: Message-ID: <46C0B7DC.3060409@bogomips.com> It's a nice idea and an excellent point about the marketing of routers, but technically I think an Xbox would choke on the actual packet forwarding. It's as if you need to take a really fast processor for the control-plane, and use it to update the forwarding plane on fast hardware routers/switches. (Oh wait, didn't somebody already invent that? :-) Lookup Ipsilon and MPLS. Or distributed/MLS switching) Ted Mittelstaedt wrote: > Leo, > > I think you should take your old Xbox and load Linux on it, > you can get it here: > > http://www.xbox-linux.org/wiki/Download > > Then load Quagga on that and route your BGP with it, you can > get that here: > > http://www.quagga.net/ > > Then when that is up and running call in your router vendor > sales representative and ask him why should all of us bother buying > new routers when we can just use any old Xbox to do the same > thing, faster. > > maybe that might shame them into actually designing product with > -current- technology. > > Is it just me that finds it deplorable that the large router > vendors see fit to charge billions of bucks for technology that > any current microwave oven controller could knock into a cocked hat? > > Ted > _______________________________________________ > 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 jmorrison at bogomips.com Mon Aug 13 16:11:30 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Mon, 13 Aug 2007 13:11:30 -0700 Subject: [ppml] too many variables In-Reply-To: <62683.1186771343@sa.vix.com> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> <61720.1186770779@sa.vix.com> <21ef2c1c0708101136w1507772dv91b258b6dc248b0f@mail.gmail.com> <62683.1186771343@sa.vix.com> Message-ID: <46C0BAF2.6080409@bogomips.com> Can't any network problem can be solved by adding another layer of indirection? Don't all the various nodes in a system simply "disappear" when another technology comes along to organize, replace and manage the problem differently? With iBGP there's been confederations and route-reflectors to divide the problem into smaller pieces, even MPLS to remove a lot of the scalability issues. But perhaps in the future, after many more consolidations and bankruptcies, there may only be a couple of major carriers left. This would solve a lot of BGP decision making algorithms. You'd either go with the Red ISP or the Blue ISP, just like politics! Paul Vixie wrote: >>> ... is that system level (combinatorial) effects would limit Internet >>> routing long before moore's law could do so. >>> >> It is an easy derivative/proxy for the system level effect is all. Bandwidth >> for updates (inter and intra system) are another choking point but folks >> tend to be even less aware of those than cpu. >> > > is bandwidth the only consideration? number of graph nodes and number of > advertised endpoints and churn rate per endpoint don't enter into the limits? > at what system size does speed of light begin to enter into the equation? > > (note, as i told geoff huston: if it seems like john scudder's outbound BGP > announcement compression observations are relevant, or that moore's law is > relevant, then you're misunderstanding my question or i'm asking it wrong.) > _______________________________________________ > 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 info at arin.net Tue Aug 14 08:46:49 2007 From: info at arin.net (Member Services) Date: Tue, 14 Aug 2007 08:46:49 -0400 Subject: [ppml] Deadline for Policy Proposals - 18 August 2007 Message-ID: <46C1A439.3020407@arin.net> The ARIN XX Public Policy Meeting will take place 17-18 October 2007 in Albuquerque, NM. New policy proposals must be submitted by 23:59 EDT, 18 August 2007, in order to be considered by the ARIN Advisory Council for possible inclusion on the ARIN XX agenda. This is in accordance with ARIN's Internet Resource Policy Evaluation Process, which requires that proposed policies be submitted at least 60 days prior to the meeting. Those who wish to propose new ARIN number resource policies or modifications to existing policies must submit a Policy Proposal Template. The template must be sent via e-mail to policy at arin.net. The Policy Proposal Template can be found at: http://www.arin.net/policy/irpep_template.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) From bicknell at ufp.org Tue Aug 14 09:54:53 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 14 Aug 2007 09:54:53 -0400 Subject: [ppml] too many variables In-Reply-To: <8b7d2e170708131753h73d18f42j564adcff7e0c09f9@mail.gmail.com> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> <20070810182455.GA57260@ussenterprise.ufp.org> <46C04E9A.3050804@cisco.com> <20070813142532.GA32490@ussenterprise.ufp.org> <8b7d2e170708131753h73d18f42j564adcff7e0c09f9@mail.gmail.com> Message-ID: <20070814135453.GA38680@ussenterprise.ufp.org> In a message written on Mon, Aug 13, 2007 at 05:53:00PM -0700, Scott Whyte wrote: > Pick a newly released Core 2 Duo. How long will Intel be selling it? > How does that compare with getting it into your RP design, tested, > produced, OS support integrated, sold, and stocked in your depots? Intel designates chips for "long life". That's why Vendor J is still souring P-III 600's, which were new almost 8 years ago now. Which one of the current chips is in that bucket, I don't know, but the vendors could find out. Plus, your argument doesn't hold for the simple reason that servers have the same lifespan as routers in most companies. HP, Dell, IBM, they don't seem to be going under with changes in Intel's line of chips. They don't seem to have support issues. As the vendors move to off the shelf parts the arguments about testing, stocking, and so forth start to go out the window. More importantly, why specialize? Vendor J's RE is basically a PC connected to the backplane with FastEthernet. They did a lot of engineering in airflow, sheet metal, and other packaging issues to put it in a Juniper package, but to what end? Compare with Avaya. When they moved to a Linux brain in their phone switch line they moved the brain out of the specialized forwarding hardware (the old Definity PBX) and into a, wait for it, PC! Yes, an off the shelf 2U PC they source from a third party, connected to the backplane with Gigabit Ethernet. Vendors also kill themselves on the depot side because they hate to give you a free upgrade. If vendors changed their maintenance policies to be "what you have or faster", when it became cost prohibitive to stock P-III 600's they could stop, giving you the P-III 1.2g that came afterwards when you RMA a part. It's probably cheaper to stop stocking multiple parts and provide "free" upgrades on failure than to stock all the varieties. Of course, I think if the RE were an external 2RU PC that they sold for $5,000 (which is still highway robbery) ISP's might upgrade more than once every 10 years.... The problem here is that large companies don't like to take risk, and any change is perceived as a risk. Cisco and Juniper will not be "creative" in finding a solution, particularly when it may reduce cost (and thus, revenue). Small startups that might take the risk can't play in the specialized forwarding side of things. We can exist in this state, primarily because we're not pushing the cutting edge. Route Processors are WAY behind current technology. Fordwarding hardware is WAY ahead of current need. Cost/bit is the problem, and has been for some number of years. We have OC-768, but can't afford to deploy the DWDM systems to support it. We have 32 way Xenon boxes, but we can't afford to change the design to use them as route processors. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From bicknell at ufp.org Tue Aug 14 09:54:53 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 14 Aug 2007 09:54:53 -0400 Subject: [ppml] too many variables In-Reply-To: <8b7d2e170708131753h73d18f42j564adcff7e0c09f9@mail.gmail.com> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> <20070810182455.GA57260@ussenterprise.ufp.org> <46C04E9A.3050804@cisco.com> <20070813142532.GA32490@ussenterprise.ufp.org> <8b7d2e170708131753h73d18f42j564adcff7e0c09f9@mail.gmail.com> Message-ID: <20070814135453.GA38680@ussenterprise.ufp.org> In a message written on Mon, Aug 13, 2007 at 05:53:00PM -0700, Scott Whyte wrote: > Pick a newly released Core 2 Duo. How long will Intel be selling it? > How does that compare with getting it into your RP design, tested, > produced, OS support integrated, sold, and stocked in your depots? Intel designates chips for "long life". That's why Vendor J is still souring P-III 600's, which were new almost 8 years ago now. Which one of the current chips is in that bucket, I don't know, but the vendors could find out. Plus, your argument doesn't hold for the simple reason that servers have the same lifespan as routers in most companies. HP, Dell, IBM, they don't seem to be going under with changes in Intel's line of chips. They don't seem to have support issues. As the vendors move to off the shelf parts the arguments about testing, stocking, and so forth start to go out the window. More importantly, why specialize? Vendor J's RE is basically a PC connected to the backplane with FastEthernet. They did a lot of engineering in airflow, sheet metal, and other packaging issues to put it in a Juniper package, but to what end? Compare with Avaya. When they moved to a Linux brain in their phone switch line they moved the brain out of the specialized forwarding hardware (the old Definity PBX) and into a, wait for it, PC! Yes, an off the shelf 2U PC they source from a third party, connected to the backplane with Gigabit Ethernet. Vendors also kill themselves on the depot side because they hate to give you a free upgrade. If vendors changed their maintenance policies to be "what you have or faster", when it became cost prohibitive to stock P-III 600's they could stop, giving you the P-III 1.2g that came afterwards when you RMA a part. It's probably cheaper to stop stocking multiple parts and provide "free" upgrades on failure than to stock all the varieties. Of course, I think if the RE were an external 2RU PC that they sold for $5,000 (which is still highway robbery) ISP's might upgrade more than once every 10 years.... The problem here is that large companies don't like to take risk, and any change is perceived as a risk. Cisco and Juniper will not be "creative" in finding a solution, particularly when it may reduce cost (and thus, revenue). Small startups that might take the risk can't play in the specialized forwarding side of things. We can exist in this state, primarily because we're not pushing the cutting edge. Route Processors are WAY behind current technology. Fordwarding hardware is WAY ahead of current need. Cost/bit is the problem, and has been for some number of years. We have OC-768, but can't afford to deploy the DWDM systems to support it. We have 32 way Xenon boxes, but we can't afford to change the design to use them as route processors. -- 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 khelms at zcorum.com Tue Aug 14 10:28:00 2007 From: khelms at zcorum.com (Scott Helms) Date: Tue, 14 Aug 2007 10:28:00 -0400 Subject: [ppml] too many variables In-Reply-To: <20070814135453.GA38680@ussenterprise.ufp.org> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> <20070810182455.GA57260@ussenterprise.ufp.org> <46C04E9A.3050804@cisco.com> <20070813142532.GA32490@ussenterprise.ufp.org> <8b7d2e170708131753h73d18f42j564adcff7e0c09f9@mail.gmail.com> <20070814135453.GA38680@ussenterprise.ufp.org> Message-ID: <46C1BBF0.9080508@zcorum.com> > Plus, your argument doesn't hold for the simple reason that servers > have the same lifespan as routers in most companies. HP, Dell, > IBM, they don't seem to be going under with changes in Intel's line > of chips. They don't seem to have support issues. As the vendors > move to off the shelf parts the arguments about testing, stocking, > and so forth start to go out the window. > I don't believe that "most" is accurate here. I have and know of many 36xx series routers in service as well as quite a few 25xx and 40xx series, but I know of relatively few servers with a 8+ year life span. Perhaps in places where they are focused on very large systems that might be true, but I don't believe that represents "most companies". > The problem here is that large companies don't like to take risk, > and any change is perceived as a risk. Cisco and Juniper will not > be "creative" in finding a solution, particularly when it may reduce > cost (and thus, revenue). Small startups that might take the risk > can't play in the specialized forwarding side of things. We can exist > in this state, primarily because we're not pushing the cutting edge. > This is at best overly simplistic and at worst untrue. The fact is that processors are a relatively small part of the overall cost and using commodity parts in telco/ISP gear has been done before and is being done now. (Crack open a Redback SMS and look at the processors on the FE and the CE). Scott Helms From info at arin.net Tue Aug 14 17:08:35 2007 From: info at arin.net (Member Services) Date: Tue, 14 Aug 2007 17:08:35 -0400 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests Message-ID: <46C219D3.4080608@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: Expand timeframe of Additional Requests Author: Dan Alexander Proposal Version: Version 1.0 Submission Date: 8/14/2007 Proposal type: modify Policy term: permanent Policy statement: The proposal is to modify section 4.2.4.4 of the NRPM Current wording: "After a subscriber has been a member of ARIN for one year they may choose to request a six-month supply of IP addresses." Change to: "After an organization has been an ARIN member in good standing for one year, they may choose to request up to a 12 month supply of IP addresses." Rationale: Currently, all RIR's provide organizations with at least a 12 month supply of IPv4 address space when making subsequent requests, with the exception of the ARIN region. The primary reason for this change is for continuity among all RIR. In doing so, all established organizations have a more consistent access to IP resources. The adjustment does not change demand on IPv4 address space. It only changes the frequency in which established organizations need to request address space. This would allow for fewer potential aggregates allocated to an organization providing more consolidated routing announcements. This does not change the requirement on new organizations where established growth trends have yet to be established. Timetable for implementation: Immediate From bicknell at ufp.org Tue Aug 14 09:54:53 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 14 Aug 2007 09:54:53 -0400 Subject: [ppml] too many variables In-Reply-To: <8b7d2e170708131753h73d18f42j564adcff7e0c09f9@mail.gmail.com> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> <20070810182455.GA57260@ussenterprise.ufp.org> <46C04E9A.3050804@cisco.com> <20070813142532.GA32490@ussenterprise.ufp.org> <8b7d2e170708131753h73d18f42j564adcff7e0c09f9@mail.gmail.com> Message-ID: <20070814135453.GA38680@ussenterprise.ufp.org> In a message written on Mon, Aug 13, 2007 at 05:53:00PM -0700, Scott Whyte wrote: > Pick a newly released Core 2 Duo. How long will Intel be selling it? > How does that compare with getting it into your RP design, tested, > produced, OS support integrated, sold, and stocked in your depots? Intel designates chips for "long life". That's why Vendor J is still souring P-III 600's, which were new almost 8 years ago now. Which one of the current chips is in that bucket, I don't know, but the vendors could find out. Plus, your argument doesn't hold for the simple reason that servers have the same lifespan as routers in most companies. HP, Dell, IBM, they don't seem to be going under with changes in Intel's line of chips. They don't seem to have support issues. As the vendors move to off the shelf parts the arguments about testing, stocking, and so forth start to go out the window. More importantly, why specialize? Vendor J's RE is basically a PC connected to the backplane with FastEthernet. They did a lot of engineering in airflow, sheet metal, and other packaging issues to put it in a Juniper package, but to what end? Compare with Avaya. When they moved to a Linux brain in their phone switch line they moved the brain out of the specialized forwarding hardware (the old Definity PBX) and into a, wait for it, PC! Yes, an off the shelf 2U PC they source from a third party, connected to the backplane with Gigabit Ethernet. Vendors also kill themselves on the depot side because they hate to give you a free upgrade. If vendors changed their maintenance policies to be "what you have or faster", when it became cost prohibitive to stock P-III 600's they could stop, giving you the P-III 1.2g that came afterwards when you RMA a part. It's probably cheaper to stop stocking multiple parts and provide "free" upgrades on failure than to stock all the varieties. Of course, I think if the RE were an external 2RU PC that they sold for $5,000 (which is still highway robbery) ISP's might upgrade more than once every 10 years.... The problem here is that large companies don't like to take risk, and any change is perceived as a risk. Cisco and Juniper will not be "creative" in finding a solution, particularly when it may reduce cost (and thus, revenue). Small startups that might take the risk can't play in the specialized forwarding side of things. We can exist in this state, primarily because we're not pushing the cutting edge. Route Processors are WAY behind current technology. Fordwarding hardware is WAY ahead of current need. Cost/bit is the problem, and has been for some number of years. We have OC-768, but can't afford to deploy the DWDM systems to support it. We have 32 way Xenon boxes, but we can't afford to change the design to use them as route processors. -- 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 sleibrand at internap.com Tue Aug 14 17:45:44 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 14 Aug 2007 14:45:44 -0700 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: <46C219D3.4080608@arin.net> References: <46C219D3.4080608@arin.net> Message-ID: <46C22288.70100@internap.com> Dan, I think this would've been a good change to make a few years ago, when we were further away from IPv4 exhaustion. However, I think this proposal moves us in the wrong direction with regards to avoiding hoarding as IPv4 free pool exhaustion nears. -Scott 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: Expand timeframe of Additional Requests > > Author: Dan Alexander > > Proposal Version: Version 1.0 > > Submission Date: 8/14/2007 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > The proposal is to modify section 4.2.4.4 of the NRPM > > Current wording: > "After a subscriber has been a member of ARIN for one year they may > choose to request a six-month supply of IP addresses." > > Change to: > "After an organization has been an ARIN member in good standing for one > year, they may choose to request up to a 12 month supply of IP addresses." > > > Rationale: > > Currently, all RIR's provide organizations with at least a 12 month > supply of IPv4 address space when making subsequent requests, with the > exception of the ARIN region. The primary reason for this change is for > continuity among all RIR. In doing so, all established organizations > have a more consistent access to IP resources. > > The adjustment does not change demand on IPv4 address space. It only > changes the frequency in which established organizations need to request > address space. > > This would allow for fewer potential aggregates allocated to an > organization providing more consolidated routing announcements. > > This does not change the requirement on new organizations where > established growth trends have yet to be established. > > > 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 Tue Aug 14 18:00:34 2007 From: info at arin.net (Member Services) Date: Tue, 14 Aug 2007 18:00:34 -0400 Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) Message-ID: <46C22602.7080600@arin.net> This proposal is in the Initial Review stage of the ARIN Internet Resource Policy Evaluation Process. On 17 May 2007 the ARIN Advisory Council (AC) reviewed 'IPv4 Soft Landing (version 1.0)' and decided to postpone their decision regarding the proposal in order to work with the author. The author submitted the following revised version of the 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 shepherd for this proposal is Bill Darte. 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: IPv4 Soft Landing Author: David Conrad Proposal Version: 2.0 Submission Date: 2007-08-14 Proposal type: New Policy term: Permanent Policy statement: This policy is intended to replace section 4.2.4.1 of the ARIN Number Resource Policy Manual with wording substantially along the lines of: --- begin modification --- 4.2.4.1 In order to encourage a smooth transition to IPv6, ARIN has instituted a set of IPv4 Address Allocation "phases" that vary the requirements for address allocation using the amount of address space remaining unallocated by IANA as a metric. As the amount of address space in the IANA free pool is reduced, the requirements for IPv4 address allocation are made more stringent. When requesting additional IPv4 address space, ISPs must meet the requirements of the IPv4 Address Allocation phase ARIN was in when the request was submitted. These phases will require the requester to demonstrate increasingly efficient utilization of previously allocated IPv4 address space, including all space reassigned to their customers. In addition, depending on the IPv4 Address Allocation phase ARIN was in when the request was submitted, there may be additional requirements that will need to be met by the requester such as completing a survey on IPv6 deployment plans, documentation of non-private address space used for internal infrastructure, documentation of IPv6 plans for offering connectivity and services, etc. The reassignment information section of the ARIN ISP Network Request Template should be completed for all address blocks that have been allocated to your organization. In the template, line 1b. Assigned: information will be verified via SWIP/RWHOIS and 1c. Reserved: should be used to indicate internal network information. Please note that until all requirements are met and your prior utilization is verified to meet the requirements specified in the IPv4 Address Allocation phase in which the request was received, ARIN can neither process nor approve a request for additional addresses. IPv4 Allocation Phases The thresholds and the requirements to justify an allocation of new IPv4 address space from ARIN are defined in this section. Phase: 0 Threshold: Greater than 40 /8s Requirements: Requesters must: * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 25% utilization - Demonstrate a one year requirement of 50% utilization Phase: 1 Threshold: 40 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 25% utilization - Demonstrate a one year requirement of 50% utilization * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used. Phase: 2 Threshold: 25 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 85% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 50% utilization - Demonstrate a one year requirement of 75% utilization * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used. * Provide plans for migrating all non-RFC 1918 address space used for internal infrastructure either to IPv6 (preferred) or to private addressing where possible. Where such migration is not possible, provide documentation listing the use of addresses that are not migratable and the reasons for the inability to migrate. * Demonstrate documented plans for availability of production IPv6 infrastructure and connectivity services within 6 months of submitting the request. Phase: 3 Threshold: 10 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 90% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 75% utilization - Demonstrate a one year requirement of 90% utilization * Provide documentation demonstrating migration (where possible) of non-RFC 1918 address space used for internal infrastructure to either IPv6 (preferred) or private addressing. * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure, how it is used, and why it is not possible to migrate those addresses to either IPv6 (preferred) or private addressing. * Demonstrate availability of production IPv6 infrastructure and connectivity services. Notes: * Phase 0 reflects current allocation requirements. * Phases 1 through 3 are to be implemented 30 days after IANA allocates address space from the IPv4 free pool that reduces that free pool to a number of /8s that are at or below the threshold specified. * If multiple thresholds should be crossed within a 30 day period, the requirements from the last threshold crossed will be applied to requesters for additional address space at the time of the request. --- end modification --- Rationale: The rationale for this proposal is threefold: * to prolong the availability of IPv4 addresses for requesters who can provide sufficient justification; * to encourage the deployment of IPv6 as an alternative to IPv4 by making the requirements to justify IPv4 allocations increasingly stringent over time; * to promote the more efficient use of increasingly scarce IPv4 resources. As the lack of significant deployment of IPv6 can attest, the cost of deploying IPv6 currently outweighs the benefits that protocol would appear to provide. This proposal aims to encourage the deployment of IPv6 by over time, making the allocation of IPv4 both more difficult and contingent on the requester demonstrating both support for IPv6 as well as requiring a demonstration that the IPv4 address space they administer is being used efficiently. The goal of these measures is to rebalance the IPv6 deployment cost/benefit ratio thereby encouraging greater uptake of IPv6 before the IPv4 free pool is exhausted. The "IPv4 Soft Landing" policy aims to provide for a smoother transition away from IPv4 towards IPv6 by imposing increasingly strict requirements for new address allocations as the amount of address space available in the IANA unallocated IPv4 address pool decreases. These increased requirements include both more stringent reassignment and utilization percentages as well as requiring documented IPv6 infrastructure services and connectivity provision and the documentation or reuse of public IPv4 address space used for internal infrastructure. The increased stringency in the allocation requirements is intended both to increase the efficiency of utilization of the IPv4 address space and to reduce the likelihood of a "run" on the remaining free pool of IPv4 address space. ARIN staff would be expected to use the same mechanisms in use today to verify conformance to the specified requirements. The requirements for demonstration of IPv6 infrastructure services and connectivity are intended to motivate ISPs to provide those services before the only address space they can offer their customers is IPv6, thereby offering an opportunity to break the "chicken-and-egg" problem limiting significant IPv6 deployment. Verification of these requirements can be done by ARIN staff by using IPv6 transport to connect to published services of the ISP (e.g., DNS servers, WWW URLs, etc.) as well as using IPv6 ping to identified addresses internal to the ISP. Obviously, false positive responses for most any objective mechanism for verifying the availability can be engineered, so ARIN staff may also consider subjective reports of an inability to obtain IPv6 services by customers as an indicator of (lack of) conformance to this requirement. The requirements to migrate internal infrastructure to either IPv6 or private (e.g., RFC 1918) addressing are intended to improve the efficiency of utilization of IPv4 address space, reserving the scarce IPv4 resources for purposes for which IPv6 or private addresses are not suitable. These requirements acknowledge that pragmatically, the use of IPv4 is absolutely essential only for servers in client-server architectures, machines engaged in peer-to-peer applications, and entry points for NAT/ALG devices. As such, use of IPv4 for purposes such as router interface numbering, client-only devices, and devices which should not be available from external networks should be discouraged. Since there can be circumstances in which migration of internal infrastructure addresses to private addressing would not be feasible, this policy allows for requesters to document those situations in which it is not possible to do the migration. The time for transition between phases of this policy are not fixed, rather they depend on the rate of consumption of IPv4 address space from the IANA free pool. Current RIR operational procedure is to request 2 /8s from the IANA when the RIR's current pool of free IPv4 address space is depleted. This procedure should ensure transitions between phases will have some lead-time, so organizations can prepare for the next phase of IPv4 address allocation. Given the highly volatile nature of IPv4 consumption and the inability to define a predictive model rooted in an underlying theory rather than extrapolating over existing data, the thresholds chosen are acknowledged to be somewhat arbitrary. The intent of the chosen values is to provide a "reasonable" amount of time, approximately 18 months, between transitions at current consumption rates (approximately 10 /8s per year). However, it should be explicitly noted that one of the intents of this policy is to extend the IPv4 free pool lifetime, thus as the policy becomes effective, the amount of time between phase transitions would presumably increase. Timetable for implementation: Immediately upon approval of this policy by the ARIN Board of Trustees. From davids at webmaster.com Tue Aug 14 18:03:27 2007 From: davids at webmaster.com (David Schwartz) Date: Tue, 14 Aug 2007 15:03:27 -0700 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: <46C22288.70100@internap.com> Message-ID: > Dan, > > I think this would've been a good change to make a few years ago, when > we were further away from IPv4 exhaustion. However, I think this > proposal moves us in the wrong direction with regards to avoiding > hoarding as IPv4 free pool exhaustion nears. > > -Scott That was precisely my initial reaction to the proposal. Then I read this: > > Currently, all RIR's provide organizations with at least a 12 month > > supply of IPv4 address space when making subsequent requests, with the > > exception of the ARIN region. The primary reason for this change is for > > continuity among all RIR. In doing so, all established organizations > > have a more consistent access to IP resources. I think a level playing field is a good thing. But I do agree that it may send the wrong message. DS From drc at virtualized.org Tue Aug 14 18:08:26 2007 From: drc at virtualized.org (David Conrad) Date: Tue, 14 Aug 2007 15:08:26 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) In-Reply-To: <46C22602.7080600@arin.net> References: <46C22602.7080600@arin.net> Message-ID: <8B52F74C-B4C4-48CF-97DD-CB1C365B6793@virtualized.org> Hi, As you'll see, this pass attempts to simplify the proposal somewhat: - fewer phases - remove the requirement for auditing/auditors I tried to address the comments people provided to me on the last go around, but I'm sure I missed a few for which I apologize. Regards, -drc On Aug 14, 2007, at 3:00 PM, Member Services wrote: > This proposal is in the Initial Review stage of the ARIN Internet > Resource Policy Evaluation Process. On 17 May 2007 the ARIN Advisory > Council (AC) reviewed 'IPv4 Soft Landing (version 1.0)' and decided to > postpone their decision regarding the proposal in order to work > with the > author. The author submitted the following revised version of the > 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 shepherd for this proposal is Bill Darte. 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: IPv4 Soft Landing > > Author: David Conrad > > Proposal Version: 2.0 > > Submission Date: 2007-08-14 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > This policy is intended to replace section 4.2.4.1 of the ARIN Number > Resource Policy Manual with wording substantially along the lines of: > > --- begin modification --- > 4.2.4.1 > > In order to encourage a smooth transition to IPv6, ARIN has instituted > a set of IPv4 Address Allocation "phases" that vary the requirements > for address allocation using the amount of address space remaining > unallocated by IANA as a metric. As the amount of address space in > the IANA free pool is reduced, the requirements for IPv4 address > allocation are made more stringent. > > When requesting additional IPv4 address space, ISPs must meet the > requirements of the IPv4 Address Allocation phase ARIN was in when the > request was submitted. These phases will require the requester to > demonstrate increasingly efficient utilization of previously allocated > IPv4 address space, including all space reassigned to their > customers. In addition, depending on the IPv4 Address Allocation phase > ARIN was in when the request was submitted, there may be additional > requirements that will need to be met by the requester such as > completing a survey on IPv6 deployment plans, documentation of > non-private address space used for internal infrastructure, > documentation of IPv6 plans for offering connectivity and services, > etc. > > The reassignment information section of the ARIN ISP Network Request > Template should be completed for all address blocks that have been > allocated to your organization. In the template, line 1b. Assigned: > information will be verified via SWIP/RWHOIS and 1c. Reserved: should > be used to indicate internal network information. Please note that > until all requirements are met and your prior utilization is verified > to meet the requirements specified in the IPv4 Address Allocation > phase in which the request was received, ARIN can neither process nor > approve a request for additional addresses. > > IPv4 Allocation Phases > > The thresholds and the requirements to justify an allocation of new > IPv4 address space from ARIN are defined in this section. > > Phase: 0 > Threshold: Greater than 40 /8s > Requirements: > > Requesters must: > > * Demonstrate efficient utilization of 100% of all previous IPv4 > allocations and at least 80% utilization of the most recent > allocation. > > * For downstream customers: > > - Demonstrate an immediate requirement of 25% utilization > > - Demonstrate a one year requirement of 50% utilization > > Phase: 1 > Threshold: 40 /8s > Requirements: > > Requesters must: > > * Provide a response to a survey (individual responses to be held in > confidence by ARIN staff) exploring requester IPv6 transition plans > and impediments, anonymized summary data of which may be published > by ARIN. > > * Demonstrate efficient utilization of 100% of all previous IPv4 > allocations and at least 80% utilization of the most recent > allocation. > > * For downstream customers: > > - Demonstrate an immediate requirement of 25% utilization > > - Demonstrate a one year requirement of 50% utilization > > * Provide a detailed listing of all non-RFC 1918 address space used > for internal infrastructure and how it is used. > > Phase: 2 > Threshold: 25 /8s > Requirements: > > Requesters must: > > * Provide a response to a survey (individual responses to be held in > confidence by ARIN staff) exploring requester IPv6 transition plans > and impediments, anonymized summary data of which may be published > by ARIN. > > * Demonstrate efficient utilization of 100% of all previous IPv4 > allocations and at least 85% utilization of the most recent > allocation. > > * For downstream customers: > > - Demonstrate an immediate requirement of 50% utilization > > - Demonstrate a one year requirement of 75% utilization > > * Provide a detailed listing of all non-RFC 1918 address space used > for internal infrastructure and how it is used. > > * Provide plans for migrating all non-RFC 1918 address space used for > internal infrastructure either to IPv6 (preferred) or to private > addressing where possible. Where such migration is not possible, > provide documentation listing the use of addresses that are not > migratable and the reasons for the inability to migrate. > > * Demonstrate documented plans for availability of production IPv6 > infrastructure and connectivity services within 6 months of > submitting the request. > > Phase: 3 > Threshold: 10 /8s > Requirements: > > Requesters must: > > * Provide a response to a survey (individual responses to be held in > confidence by ARIN staff) exploring requester IPv6 transition plans > and impediments, anonymized summary data of which may be published > by ARIN. > > * Demonstrate efficient utilization of 100% of all previous IPv4 > allocations and at least 90% utilization of the most recent > allocation. > > * For downstream customers: > > - Demonstrate an immediate requirement of 75% utilization > > - Demonstrate a one year requirement of 90% utilization > > * Provide documentation demonstrating migration (where possible) of > non-RFC 1918 address space used for internal infrastructure to > either IPv6 (preferred) or private addressing. > > * Provide a detailed listing of all non-RFC 1918 address space used > for internal infrastructure, how it is used, and why it is not > possible to migrate those addresses to either IPv6 (preferred) or > private addressing. > > * Demonstrate availability of production IPv6 infrastructure and > connectivity services. > > Notes: > > * Phase 0 reflects current allocation requirements. > > * Phases 1 through 3 are to be implemented 30 days after IANA > allocates address space from the IPv4 free pool that reduces that > free pool to a number of /8s that are at or below the threshold > specified. > > * If multiple thresholds should be crossed within a 30 day period, the > requirements from the last threshold crossed will be applied to > requesters for additional address space at the time of the request. > > --- end modification --- > > Rationale: > > The rationale for this proposal is threefold: > > * to prolong the availability of IPv4 addresses for requesters who can > provide sufficient justification; > > * to encourage the deployment of IPv6 as an alternative to IPv4 by > making the requirements to justify IPv4 allocations increasingly > stringent over time; > > * to promote the more efficient use of increasingly scarce IPv4 > resources. > > As the lack of significant deployment of IPv6 can attest, the cost of > deploying IPv6 currently outweighs the benefits that protocol would > appear to provide. This proposal aims to encourage the deployment of > IPv6 by over time, making the allocation of IPv4 both more difficult > and contingent on the requester demonstrating both support for IPv6 as > well as requiring a demonstration that the IPv4 address space they > administer is being used efficiently. The goal of these measures is > to rebalance the IPv6 deployment cost/benefit ratio thereby > encouraging greater uptake of IPv6 before the IPv4 free pool is > exhausted. > > The "IPv4 Soft Landing" policy aims to provide for a smoother > transition away from IPv4 towards IPv6 by imposing increasingly strict > requirements for new address allocations as the amount of address > space available in the IANA unallocated IPv4 address pool decreases. > These increased requirements include both more stringent reassignment > and utilization percentages as well as requiring documented IPv6 > infrastructure services and connectivity provision and the > documentation or reuse of public IPv4 address space used for internal > infrastructure. > > The increased stringency in the allocation requirements is intended > both to increase the efficiency of utilization of the IPv4 address > space and to reduce the likelihood of a "run" on the remaining free > pool of IPv4 address space. ARIN staff would be expected to use the > same mechanisms in use today to verify conformance to the specified > requirements. > > The requirements for demonstration of IPv6 infrastructure services and > connectivity are intended to motivate ISPs to provide those services > before the only address space they can offer their customers is IPv6, > thereby offering an opportunity to break the "chicken-and-egg" problem > limiting significant IPv6 deployment. Verification of these > requirements can be done by ARIN staff by using IPv6 transport to > connect to published services of the ISP (e.g., DNS servers, WWW URLs, > etc.) as well as using IPv6 ping to identified addresses internal to > the ISP. Obviously, false positive responses for most any objective > mechanism for verifying the availability can be engineered, so ARIN > staff may also consider subjective reports of an inability to obtain > IPv6 services by customers as an indicator of (lack of) conformance to > this requirement. > > The requirements to migrate internal infrastructure to either IPv6 or > private (e.g., RFC 1918) addressing are intended to improve the > efficiency of utilization of IPv4 address space, reserving the scarce > IPv4 resources for purposes for which IPv6 or private addresses are > not suitable. These requirements acknowledge that pragmatically, the > use of IPv4 is absolutely essential only for servers in client-server > architectures, machines engaged in peer-to-peer applications, and > entry points for NAT/ALG devices. As such, use of IPv4 for purposes > such as router interface numbering, client-only devices, and devices > which should not be available from external networks should be > discouraged. Since there can be circumstances in which migration of > internal infrastructure addresses to private addressing would not be > feasible, this policy allows for requesters to document those > situations in which it is not possible to do the migration. > > The time for transition between phases of this policy are not fixed, > rather they depend on the rate of consumption of IPv4 address space > from the IANA free pool. Current RIR operational procedure is to > request 2 /8s from the IANA when the RIR's current pool of free IPv4 > address space is depleted. This procedure should ensure transitions > between phases will have some lead-time, so organizations can prepare > for the next phase of IPv4 address allocation. > > Given the highly volatile nature of IPv4 consumption and the inability > to define a predictive model rooted in an underlying theory rather > than extrapolating over existing data, the thresholds chosen are > acknowledged to be somewhat arbitrary. The intent of the chosen > values is to provide a "reasonable" amount of time, approximately 18 > months, between transitions at current consumption rates > (approximately 10 /8s per year). However, it should be explicitly > noted that one of the intents of this policy is to extend the IPv4 > free pool lifetime, thus as the policy becomes effective, the amount > of time between phase transitions would presumably increase. > > Timetable for implementation: > > Immediately upon approval of this policy by the ARIN Board of > Trustees. > > > _______________________________________________ > 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 arin-contact at dirtside.com Tue Aug 14 18:18:26 2007 From: arin-contact at dirtside.com (William Herrin) Date: Tue, 14 Aug 2007 18:18:26 -0400 Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) In-Reply-To: <8B52F74C-B4C4-48CF-97DD-CB1C365B6793@virtualized.org> References: <46C22602.7080600@arin.net> <8B52F74C-B4C4-48CF-97DD-CB1C365B6793@virtualized.org> Message-ID: <3c3e3fca0708141518l7b69b18fna00012652bd65790@mail.gmail.com> On 8/14/07, David Conrad wrote: > > Policy Proposal Name: IPv4 Soft Landing David, I'd like to see implementation contingent on the acceptance of "substantially identical" policies at the other registries. Otherwise it would only serve to disadvantage the ARIN region during the endgame. Other than that, I think this is a great idea and I hope it passes. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From sleibrand at internap.com Tue Aug 14 18:25:39 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 14 Aug 2007 15:25:39 -0700 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: References: Message-ID: <46C22BE3.2070701@internap.com> David Schwartz wrote: >> Dan, >> >> I think this would've been a good change to make a few years ago, when >> we were further away from IPv4 exhaustion. However, I think this >> proposal moves us in the wrong direction with regards to avoiding >> hoarding as IPv4 free pool exhaustion nears. >> >> -Scott >> > > That was precisely my initial reaction to the proposal. Then I read this: > > >>> Currently, all RIR's provide organizations with at least a 12 month >>> supply of IPv4 address space when making subsequent requests, with the >>> exception of the ARIN region. The primary reason for this change is for >>> continuity among all RIR. In doing so, all established organizations >>> have a more consistent access to IP resources. >>> > > I think a level playing field is a good thing. But I do agree that it may > send the wrong message. > Perhaps policy proposals to change 1-year-supply clauses to 6-month-supply ones would be another way to level the playing field, while moving us in the direction we need to go to deal with IPv4 free pool exhaustion... -Scott From tedm at ipinc.net Tue Aug 14 19:06:49 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 14 Aug 2007 16:06:49 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) In-Reply-To: <3c3e3fca0708141518l7b69b18fna00012652bd65790@mail.gmail.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >William Herrin >Sent: Tuesday, August 14, 2007 3:18 PM >To: David Conrad >Cc: ppml at arin.net >Subject: Re: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) > > >On 8/14/07, David Conrad wrote: >> > Policy Proposal Name: IPv4 Soft Landing > >David, > >I'd like to see implementation contingent on the acceptance of >"substantially identical" policies at the other registries. Otherwise >it would only serve to disadvantage the ARIN region during the >endgame. That is setting up a catch-22 since the other registries could rightly say they will only implement it if ARIN does it first. The proper way to accomplish this (IMHO) is to pass the proposal then in 2 years if none of the other registries step up to bat, then pass another proposal that rolls everything back. Or if you don't trust the community to do this, then add an automatic rollback clause to the proposal that revokes the clauses if no other registry follows suit. However, I really don't think this will disadvantage the ARIN region. IPv4 runout is coming no matter what and like your typical Ebay auction we won't see much activity for IPv4 requests until the last minute, thus we won't know how ARIN is doing relative to the other regions, and there won't be enough time then to change policy to affect runout in ARIN one way or another in response to what is happening. Ted From owen at delong.com Tue Aug 14 19:37:29 2007 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Aug 2007 16:37:29 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) In-Reply-To: References: Message-ID: On Aug 14, 2007, at 4:06 PM, Ted Mittelstaedt wrote: > > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On >> Behalf Of >> William Herrin >> Sent: Tuesday, August 14, 2007 3:18 PM >> To: David Conrad >> Cc: ppml at arin.net >> Subject: Re: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) >> >> >> On 8/14/07, David Conrad wrote: >>>> Policy Proposal Name: IPv4 Soft Landing >> >> David, >> >> I'd like to see implementation contingent on the acceptance of >> "substantially identical" policies at the other registries. Otherwise >> it would only serve to disadvantage the ARIN region during the >> endgame. > > That is setting up a catch-22 since the other registries could rightly > say they will only implement it if ARIN does it first. > Not exactly. I wouldn't say "ALL others must implement it first, I would say that ALL registries must pass substantially identical policies, after which, the registries shall work together towards coordinated implementation dates." > The proper way to accomplish this (IMHO) is to pass the proposal then > in 2 years if none of the other registries step up to bat, then > pass another proposal that rolls everything back. Or if you don't > trust the community to do this, then add an automatic rollback clause > to the proposal that revokes the clauses if no other registry follows > suit. > That's too late. By then, you've already placed the ARIN region at a substantial disadvantage WRT the other registries and a high percentage of the remaining IPv4 free pool could well be already gone. > However, I really don't think this will disadvantage the ARIN region. > IPv4 runout is coming no matter what and like your typical Ebay > auction > we won't see much activity for IPv4 requests until the last minute, > thus we won't know how ARIN is doing relative to the other regions, > and there won't be enough time then to change policy to affect runout > in ARIN one way or another in response to what is happening. > I disagre. We already know how ARIN is doing relative to other regions if you pay attention at any of the meetings during Leslies very informative presentations. If you were asleep during that part of the meeting, the slides are available on the ARIN web site and are mostly self explanatory. Owen From sleibrand at internap.com Tue Aug 14 19:59:53 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 14 Aug 2007 16:59:53 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) In-Reply-To: <46C22602.7080600@arin.net> References: <46C22602.7080600@arin.net> Message-ID: <46C241F9.2080505@internap.com> I support this proposal. I would agree that this proposal should also be presented to other RIRs to help ensure policy consistency, but even if only ARIN were to adopt it, I don't believe this proposal significantly disadvantages ARIN members relative to other RIR members. Most of what this proposal requires is in the long-term best interest of the applicant anyway (as well as being good for the community as a whole), so the main additional burden of complying with the proposed policy would be an administrative one. -Scott Member Services wrote: > This proposal is in the Initial Review stage of the ARIN Internet > Resource Policy Evaluation Process. On 17 May 2007 the ARIN Advisory > Council (AC) reviewed 'IPv4 Soft Landing (version 1.0)' and decided to > postpone their decision regarding the proposal in order to work with the > author. The author submitted the following revised version of the > 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 shepherd for this proposal is Bill Darte. 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: IPv4 Soft Landing > > Author: David Conrad > > Proposal Version: 2.0 > > Submission Date: 2007-08-14 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > This policy is intended to replace section 4.2.4.1 of the ARIN Number > Resource Policy Manual with wording substantially along the lines of: > > --- begin modification --- > 4.2.4.1 > > In order to encourage a smooth transition to IPv6, ARIN has instituted > a set of IPv4 Address Allocation "phases" that vary the requirements > for address allocation using the amount of address space remaining > unallocated by IANA as a metric. As the amount of address space in > the IANA free pool is reduced, the requirements for IPv4 address > allocation are made more stringent. > > When requesting additional IPv4 address space, ISPs must meet the > requirements of the IPv4 Address Allocation phase ARIN was in when the > request was submitted. These phases will require the requester to > demonstrate increasingly efficient utilization of previously allocated > IPv4 address space, including all space reassigned to their > customers. In addition, depending on the IPv4 Address Allocation phase > ARIN was in when the request was submitted, there may be additional > requirements that will need to be met by the requester such as > completing a survey on IPv6 deployment plans, documentation of > non-private address space used for internal infrastructure, > documentation of IPv6 plans for offering connectivity and services, > etc. > > The reassignment information section of the ARIN ISP Network Request > Template should be completed for all address blocks that have been > allocated to your organization. In the template, line 1b. Assigned: > information will be verified via SWIP/RWHOIS and 1c. Reserved: should > be used to indicate internal network information. Please note that > until all requirements are met and your prior utilization is verified > to meet the requirements specified in the IPv4 Address Allocation > phase in which the request was received, ARIN can neither process nor > approve a request for additional addresses. > > IPv4 Allocation Phases > > The thresholds and the requirements to justify an allocation of new > IPv4 address space from ARIN are defined in this section. > > Phase: 0 > Threshold: Greater than 40 /8s > Requirements: > > Requesters must: > > * Demonstrate efficient utilization of 100% of all previous IPv4 > allocations and at least 80% utilization of the most recent > allocation. > > * For downstream customers: > > - Demonstrate an immediate requirement of 25% utilization > > - Demonstrate a one year requirement of 50% utilization > > Phase: 1 > Threshold: 40 /8s > Requirements: > > Requesters must: > > * Provide a response to a survey (individual responses to be held in > confidence by ARIN staff) exploring requester IPv6 transition plans > and impediments, anonymized summary data of which may be published > by ARIN. > > * Demonstrate efficient utilization of 100% of all previous IPv4 > allocations and at least 80% utilization of the most recent > allocation. > > * For downstream customers: > > - Demonstrate an immediate requirement of 25% utilization > > - Demonstrate a one year requirement of 50% utilization > > * Provide a detailed listing of all non-RFC 1918 address space used > for internal infrastructure and how it is used. > > Phase: 2 > Threshold: 25 /8s > Requirements: > > Requesters must: > > * Provide a response to a survey (individual responses to be held in > confidence by ARIN staff) exploring requester IPv6 transition plans > and impediments, anonymized summary data of which may be published > by ARIN. > > * Demonstrate efficient utilization of 100% of all previous IPv4 > allocations and at least 85% utilization of the most recent > allocation. > > * For downstream customers: > > - Demonstrate an immediate requirement of 50% utilization > > - Demonstrate a one year requirement of 75% utilization > > * Provide a detailed listing of all non-RFC 1918 address space used > for internal infrastructure and how it is used. > > * Provide plans for migrating all non-RFC 1918 address space used for > internal infrastructure either to IPv6 (preferred) or to private > addressing where possible. Where such migration is not possible, > provide documentation listing the use of addresses that are not > migratable and the reasons for the inability to migrate. > > * Demonstrate documented plans for availability of production IPv6 > infrastructure and connectivity services within 6 months of > submitting the request. > > Phase: 3 > Threshold: 10 /8s > Requirements: > > Requesters must: > > * Provide a response to a survey (individual responses to be held in > confidence by ARIN staff) exploring requester IPv6 transition plans > and impediments, anonymized summary data of which may be published > by ARIN. > > * Demonstrate efficient utilization of 100% of all previous IPv4 > allocations and at least 90% utilization of the most recent > allocation. > > * For downstream customers: > > - Demonstrate an immediate requirement of 75% utilization > > - Demonstrate a one year requirement of 90% utilization > > * Provide documentation demonstrating migration (where possible) of > non-RFC 1918 address space used for internal infrastructure to > either IPv6 (preferred) or private addressing. > > * Provide a detailed listing of all non-RFC 1918 address space used > for internal infrastructure, how it is used, and why it is not > possible to migrate those addresses to either IPv6 (preferred) or > private addressing. > > * Demonstrate availability of production IPv6 infrastructure and > connectivity services. > > Notes: > > * Phase 0 reflects current allocation requirements. > > * Phases 1 through 3 are to be implemented 30 days after IANA > allocates address space from the IPv4 free pool that reduces that > free pool to a number of /8s that are at or below the threshold > specified. > > * If multiple thresholds should be crossed within a 30 day period, the > requirements from the last threshold crossed will be applied to > requesters for additional address space at the time of the request. > > --- end modification --- > > Rationale: > > The rationale for this proposal is threefold: > > * to prolong the availability of IPv4 addresses for requesters who can > provide sufficient justification; > > * to encourage the deployment of IPv6 as an alternative to IPv4 by > making the requirements to justify IPv4 allocations increasingly > stringent over time; > > * to promote the more efficient use of increasingly scarce IPv4 > resources. > > As the lack of significant deployment of IPv6 can attest, the cost of > deploying IPv6 currently outweighs the benefits that protocol would > appear to provide. This proposal aims to encourage the deployment of > IPv6 by over time, making the allocation of IPv4 both more difficult > and contingent on the requester demonstrating both support for IPv6 as > well as requiring a demonstration that the IPv4 address space they > administer is being used efficiently. The goal of these measures is > to rebalance the IPv6 deployment cost/benefit ratio thereby > encouraging greater uptake of IPv6 before the IPv4 free pool is > exhausted. > > The "IPv4 Soft Landing" policy aims to provide for a smoother > transition away from IPv4 towards IPv6 by imposing increasingly strict > requirements for new address allocations as the amount of address > space available in the IANA unallocated IPv4 address pool decreases. > These increased requirements include both more stringent reassignment > and utilization percentages as well as requiring documented IPv6 > infrastructure services and connectivity provision and the > documentation or reuse of public IPv4 address space used for internal > infrastructure. > > The increased stringency in the allocation requirements is intended > both to increase the efficiency of utilization of the IPv4 address > space and to reduce the likelihood of a "run" on the remaining free > pool of IPv4 address space. ARIN staff would be expected to use the > same mechanisms in use today to verify conformance to the specified > requirements. > > The requirements for demonstration of IPv6 infrastructure services and > connectivity are intended to motivate ISPs to provide those services > before the only address space they can offer their customers is IPv6, > thereby offering an opportunity to break the "chicken-and-egg" problem > limiting significant IPv6 deployment. Verification of these > requirements can be done by ARIN staff by using IPv6 transport to > connect to published services of the ISP (e.g., DNS servers, WWW URLs, > etc.) as well as using IPv6 ping to identified addresses internal to > the ISP. Obviously, false positive responses for most any objective > mechanism for verifying the availability can be engineered, so ARIN > staff may also consider subjective reports of an inability to obtain > IPv6 services by customers as an indicator of (lack of) conformance to > this requirement. > > The requirements to migrate internal infrastructure to either IPv6 or > private (e.g., RFC 1918) addressing are intended to improve the > efficiency of utilization of IPv4 address space, reserving the scarce > IPv4 resources for purposes for which IPv6 or private addresses are > not suitable. These requirements acknowledge that pragmatically, the > use of IPv4 is absolutely essential only for servers in client-server > architectures, machines engaged in peer-to-peer applications, and > entry points for NAT/ALG devices. As such, use of IPv4 for purposes > such as router interface numbering, client-only devices, and devices > which should not be available from external networks should be > discouraged. Since there can be circumstances in which migration of > internal infrastructure addresses to private addressing would not be > feasible, this policy allows for requesters to document those > situations in which it is not possible to do the migration. > > The time for transition between phases of this policy are not fixed, > rather they depend on the rate of consumption of IPv4 address space > from the IANA free pool. Current RIR operational procedure is to > request 2 /8s from the IANA when the RIR's current pool of free IPv4 > address space is depleted. This procedure should ensure transitions > between phases will have some lead-time, so organizations can prepare > for the next phase of IPv4 address allocation. > > Given the highly volatile nature of IPv4 consumption and the inability > to define a predictive model rooted in an underlying theory rather > than extrapolating over existing data, the thresholds chosen are > acknowledged to be somewhat arbitrary. The intent of the chosen > values is to provide a "reasonable" amount of time, approximately 18 > months, between transitions at current consumption rates > (approximately 10 /8s per year). However, it should be explicitly > noted that one of the intents of this policy is to extend the IPv4 > free pool lifetime, thus as the policy becomes effective, the amount > of time between phase transitions would presumably increase. > > Timetable for implementation: > > Immediately upon approval of this policy by the ARIN Board of Trustees. > > > _______________________________________________ > 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 drc at virtualized.org Tue Aug 14 20:28:19 2007 From: drc at virtualized.org (David Conrad) Date: Tue, 14 Aug 2007 17:28:19 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) In-Reply-To: <3c3e3fca0708141518l7b69b18fna00012652bd65790@mail.gmail.com> References: <46C22602.7080600@arin.net> <8B52F74C-B4C4-48CF-97DD-CB1C365B6793@virtualized.org> <3c3e3fca0708141518l7b69b18fna00012652bd65790@mail.gmail.com> Message-ID: William, On Aug 14, 2007, at 3:18 PM, William Herrin wrote: > I'd like to see implementation contingent on the acceptance of > "substantially identical" policies at the other registries. Otherwise > it would only serve to disadvantage the ARIN region during the > endgame. I'd be distressed if the RIRs entered into a 5-way Prisoner's Dilemma game in their handling of the IPv4 free pool exhaustion. I'm in the process of preparing something like Soft Landing for the APNIC public policy process (and will do something similar in the other RIRs), but one of the reasons I'm not couching this in terms of a 'global policy' is because I don't think it needs to be identical across the various regions. If it does, then I'm not sure I understand the need for multiple RIRs... > Other than that, I think this is a great idea and I hope it passes. Thanks! Regards, -drc From michael.c.loevner at verizon.com Wed Aug 15 11:55:52 2007 From: michael.c.loevner at verizon.com (michael.c.loevner at verizon.com) Date: Wed, 15 Aug 2007 11:55:52 -0400 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: <46C219D3.4080608@arin.net> Message-ID: I support this proposal. I'm sure ARIN staff will continue to be diligent in ensuring that the address blocks assigned are justified over the period they are requested for. I don't see it as encouraging a run on addresses, if people want to provide fake justification to get additional addreses for the purpose of hoarding, they can just as well do it over a 6 month period as a 12 month period. -Mike Member Services Sent by: ppml-bounces at arin.net 08/14/2007 05:08 PM To ppml at arin.net cc Subject [ppml] Policy Proposal: Expand timeframe of Additional Requests 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: Expand timeframe of Additional Requests Author: Dan Alexander Proposal Version: Version 1.0 Submission Date: 8/14/2007 Proposal type: modify Policy term: permanent Policy statement: The proposal is to modify section 4.2.4.4 of the NRPM Current wording: "After a subscriber has been a member of ARIN for one year they may choose to request a six-month supply of IP addresses." Change to: "After an organization has been an ARIN member in good standing for one year, they may choose to request up to a 12 month supply of IP addresses." Rationale: Currently, all RIR's provide organizations with at least a 12 month supply of IPv4 address space when making subsequent requests, with the exception of the ARIN region. The primary reason for this change is for continuity among all RIR. In doing so, all established organizations have a more consistent access to IP resources. The adjustment does not change demand on IPv4 address space. It only changes the frequency in which established organizations need to request address space. This would allow for fewer potential aggregates allocated to an organization providing more consolidated routing announcements. This does not change the requirement on new organizations where established growth trends have yet to be established. 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 christy.m.le at verizon.com Wed Aug 15 12:02:24 2007 From: christy.m.le at verizon.com (christy.m.le at verizon.com) Date: Wed, 15 Aug 2007 12:02:24 -0400 Subject: [ppml] Christy M. Le is out of the office. Message-ID: I will be out of the office starting 08/15/2007 and will not return until 08/20/2007. I will respond to your message when I return. For IPDIA issue, please call (866) 598-1818 Option #4. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at mcsnet.ca Wed Aug 15 12:08:43 2007 From: mark at mcsnet.ca (Mark Beland) Date: Wed, 15 Aug 2007 10:08:43 -0600 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: References: Message-ID: <46C3250B.9050900@mcsnet.ca> I support this as well, especially if the other rir's are also doing it. michael.c.loevner at verizon.com wrote: > I support this proposal. I'm sure ARIN staff will continue to be diligent > in ensuring that the address blocks assigned are justified over the period > they are requested for. I don't see it as encouraging a run on addresses, > if people want to provide fake justification to get additional addreses > for the purpose of hoarding, they can just as well do it over a 6 month > period as a 12 month period. > > -Mike > > > > > Member Services > Sent by: ppml-bounces at arin.net > 08/14/2007 05:08 PM > > To > ppml at arin.net > cc > > Subject > [ppml] Policy Proposal: Expand timeframe of Additional Requests > > > > > > > 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: Expand timeframe of Additional Requests > > Author: Dan Alexander > > Proposal Version: Version 1.0 > > Submission Date: 8/14/2007 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > The proposal is to modify section 4.2.4.4 of the NRPM > > Current wording: > "After a subscriber has been a member of ARIN for one year they may > choose to request a six-month supply of IP addresses." > > Change to: > "After an organization has been an ARIN member in good standing for one > year, they may choose to request up to a 12 month supply of IP addresses." > > > Rationale: > > Currently, all RIR's provide organizations with at least a 12 month > supply of IPv4 address space when making subsequent requests, with the > exception of the ARIN region. The primary reason for this change is for > continuity among all RIR. In doing so, all established organizations > have a more consistent access to IP resources. > > The adjustment does not change demand on IPv4 address space. It only > changes the frequency in which established organizations need to request > address space. > > This would allow for fewer potential aggregates allocated to an > organization providing more consolidated routing announcements. > > This does not change the requirement on new organizations where > established growth trends have yet to be established. > > > 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. > > > _______________________________________________ > 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 Daniel_Alexander at Cable.Comcast.com Wed Aug 15 13:03:16 2007 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Wed, 15 Aug 2007 13:03:16 -0400 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests References: <46C22BE3.2070701@internap.com> Message-ID: <997BC128AE961E4A8B880CD7442D94800127CAEA@NJCHLEXCMB01.cable.comcast.com> Scott, I think of hoarding occurring in two ways. One would be where an organization, inadvertently or not, requests more address space than they actually use in the six months or a year. The other case is where the org would falsify or exaggerate an application to get more than they need. For the second one to happen, we would have to assume that ARIN does not perform due diligence during the review of an application. Since I go through this process several times a year, I can say with confidence, that is not the case. Also, if an organization is submitting fraudulent applications, that ARIN is not catching, it wouldn't matter what the timeframe is, since they would just keep coming back for more. There are several ways to throttle this problem. One is what's currently in place. The one year allowance is for established organizations who have documented growth. If the organization doesn't have established growth trends, then ARIN would not approve the application for the full amount of what is requested. This has also happened to me on several occasions. :) If for some reason, an org is allocated too much space, this would only be a one-time-shot. If an org didn't grow at the rate it originally anticipated, it wouldn't be able to make another application until the current space is used. There are also a number of discussions and proposals around ARIN being able to audit and or reclaim space that is not being used properly. It's just my opinion, but these are better means to control hoarding, rather than restricting allocations to legitimate applications of need. I will concede I might be missing something though. If you can think of ways this proposal could be abused, I would appreciate the input. I like your suggestion that maybe they should all be six months. I just figured it would be easier to bring one Registry in line with the policy of the other four, rather than bring the other four in line with the one. Thanks, Dan ________________________________ From: ppml-bounces at arin.net on behalf of Scott Leibrand Sent: Tue 8/14/2007 6:25 PM To: davids at webmaster.com Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal: Expand timeframe of Additional Requests David Schwartz wrote: >> Dan, >> >> I think this would've been a good change to make a few years ago, when >> we were further away from IPv4 exhaustion. However, I think this >> proposal moves us in the wrong direction with regards to avoiding >> hoarding as IPv4 free pool exhaustion nears. >> >> -Scott >> > > That was precisely my initial reaction to the proposal. Then I read this: > > >>> Currently, all RIR's provide organizations with at least a 12 month >>> supply of IPv4 address space when making subsequent requests, with the >>> exception of the ARIN region. The primary reason for this change is for >>> continuity among all RIR. In doing so, all established organizations >>> have a more consistent access to IP resources. >>> > > I think a level playing field is a good thing. But I do agree that it may > send the wrong message. > Perhaps policy proposals to change 1-year-supply clauses to 6-month-supply ones would be another way to level the playing field, while moving us in the direction we need to go to deal with IPv4 free pool exhaustion... -Scott _______________________________________________ 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 tedm at ipinc.net Wed Aug 15 14:24:13 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 15 Aug 2007 11:24:13 -0700 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: <997BC128AE961E4A8B880CD7442D94800127CAEA@NJCHLEXCMB01.cable.comcast.com> Message-ID: -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Alexander, Daniel Sent: Wednesday, August 15, 2007 10:03 AM To: ppml at arin.net Subject: Re: [ppml] Policy Proposal: Expand timeframe of Additional Requests >Scott, >I think of hoarding occurring in two ways. Hi Dan, One of the things I would like to point out for the list is that there seems to be an assumption that after IPv4 runout, that IPv4 addresses will increase or at least, retain, value. This assumption is necessary for all of the gloom and doom scenarios. After all nobody hoards items that have no, or a declining, value. I feel this assumption is seriously flawed for several perhaps obvious, reasons I'll detail here: 1) Return. IPv4 runout will cause some organizations to begin the process of switching over to IPv6. As they do this they will no longer have need of IPv4 and will be able to start renting/selling it or returning it to the RIR. Right now I feel a glaring policy hole is there does not seem to be financial incentive to return IPv4 and every time it's been suggested (primariarly in conjunction with the legacy holders) it's been shouted down - but sooner or later people will come to their senses and realize that getting orgs to return IPv4 will help to accellerate adoption of IPv6 - because even if the returned IPv4 is never used, you can point to "ACME, Inc" and state with authority that they have no allocated or assigned IPv4 and if they can do IPv6 you can too. Besides, return of IPv4 is essential to nipping any "ebay Inc trade of IPv4" numbers in the bud, which most people agree is something we want to do. Nobody is going to risk building a business plan on selling their IPv4 when there is a chance that without warning a large chunk of IPv4 will be returned to the RIR which can then commence filling any pending IPv4 requests, and kill all your potential customers. 2) Sheer growth. A lot has been claimed how the legacy assignments are a drop in the bucket. Well, I will ask the question - if every IPv4 allocation ARIN makes from this day forward to the date of IPv4 runout in 5 years or so went straight to a hoarder, then wouldn't that mean that as of IPv4 runout date if all hoarders were to immediately start selling their hoards, wouldn't that really only constitute just a 5 year supply of IPv4? If someone out there were hoarding a 20-year supply of IPv4 then you might have something to be worried about. But it seems to me that it's now way too late to start hoarding IPv4 anyhow - sure a few people might do it and make a little bit of money, but we are talking garage operators. An anaology is this - there are a few people out there making a living selling used cars over Ebay. But that has not resulted in the closure of car dealerships across the land. There's not enough market for car sales through Ebay to have an impact on the economy - just as there isn't going to be enough hoarded IPv4 out there to make any impact on the future growth of the Internet. 3) History. The history of technology change has been that as soon as something new is introduced, people start getting afraid of being left behind and they will jump on the new thing, even if the old thing works as well or even better. For example, you can go buy old used desktop Bell telephones with push buttons, using old technology, that sound 1000% better than the new piece-of-crap phones that sell at Target for more money. But people buy the new piece-of-crap phones because they think they are better just because they are new. Clearly IPv4 will be able to handle networking traffic post-IPv4 runout, but it seems to me that once people have to start deploying IPv6 that a lot of them will start thinking it works better to handle networking traffic, merely because it's newer, not because of any logical reason. Witness the old Betamax vs VHS wars. Both formats were neck and neck for a while then VHS got ahead and it was like a cascade failure - very rapidly betamax vanished. My feeling is that as soon as a tipping point is reached that IPv4 will disappear very rapidly. And that tipping point is going to be triggered by IPv4 runout, without anyone's help. We just need to figure out if there's anything we can do to reduce the time between the date of IPv4 runout and the date of the tipping point. Ted From stephen at sprunk.org Wed Aug 15 15:39:30 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 15 Aug 2007 14:39:30 -0500 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests References: Message-ID: <0c3801c7df76$d1412170$6401a8c0@atlanta.polycom.com> Thus spake "Ted Mittelstaedt" > 1) Return. IPv4 runout will cause some organizations to begin the > process of switching over to IPv6. As they do this they will no > longer have need of IPv4 and will be able to start renting/selling it > or returning it to the RIR. Right now I feel a glaring policy hole is > there does not seem to be financial incentive to return IPv4 and > every time it's been suggested (primariarly in conjunction with the > legacy holders) it's been shouted down - but sooner or later > people will come to their senses and realize that getting orgs to > return IPv4 will help to accellerate adoption of IPv6 - because > even if the returned IPv4 is never used, you can point to "ACME, > Inc" and state with authority that they have no allocated or > assigned IPv4 and if they can do IPv6 you can too. There _is_ policy that allows return; the problem is the fee schedule. The 73 orgs that fit in the "X-large" category have absolutely no financial incentive to return space because they pay a constant amount until they get down to a /14, which in some cases means as little as 0.8% of their current consumption. Furthermore, since those orgs don't pay more as they consume more, there's not even a disincentive for them to waste _more_ space. These orgs currently hold 80% of ARIN-managed address space, so the small incentives (which do exist) for everyone else are just plain irrelevant -- even if smaller players conserve, that just leaves more space for the big guys to waste before exhaustion hits. If ARIN charged $0.268/yr/IP, just for the 26 /8s that show up as "ARIN" in IANA's list, that'd be enough to cover ARIN's current budget. Not only would that directly link consumption with fees (and thus encourage conservation/return), the vast majority of ARIN members would pay less under such a model as well. Of course, those 73 "X-large" orgs would be rather unhappy, which is why it hasn't been done. (There's also the lesser issue that end users with direct assignments pay $100/yr regardless of how much space they have, or $0/yr if they're legacy-only, so there is absolutely zero incentive for them to return anything if they deploy v6 because their fees won't change. We don't need _another_ flamefest about legacy holders, though, so let's stick to LIRs for the moment.) S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From Lee at Dilkie.com Wed Aug 15 16:48:01 2007 From: Lee at Dilkie.com (Lee Dilkie) Date: Wed, 15 Aug 2007 16:48:01 -0400 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: <0c3801c7df76$d1412170$6401a8c0@atlanta.polycom.com> References: <0c3801c7df76$d1412170$6401a8c0@atlanta.polycom.com> Message-ID: <46C36681.2030901@Dilkie.com> Stephen Sprunk wrote: > If ARIN charged $0.268/yr/IP, just for the 26 /8s that show up as "ARIN" in > IANA's list, that'd be enough to cover ARIN's current budget. Not only > > unless my math is wrong, I get somewhere in the order of $0.0229 or a tad over 2 cents/ip/yr to cover the current $10M budget. But your point is a good one. And 2 cents/ip isn't a bad number, the entire internet would generate $85M/yr for all the RiR's (well, it'd be a bit less due to loss of some non-valid space). And my legacy /24 would cost me $5.12/yr. At that, I'd easily consider a membership. -lee From stephen at sprunk.org Wed Aug 15 19:23:35 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 15 Aug 2007 18:23:35 -0500 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests References: <0c3801c7df76$d1412170$6401a8c0@atlanta.polycom.com> <46C36681.2030901@Dilkie.com> Message-ID: <0cda01c7df94$b877c7c0$6401a8c0@atlanta.polycom.com> Thus spake "Lee Dilkie" > Stephen Sprunk wrote: >> If ARIN charged $0.268/yr/IP, just for the 26 /8s that show up as >> "ARIN" in IANA's list, that'd be enough to cover ARIN's current >> budget. > > unless my math is wrong, I get somewhere in the order of $0.0229 or a > tad over 2 cents/ip/yr to cover the current $10M budget. I must have fat-fingered something with the calculator; $0.0229 is what I'm getting now as well. > But your point is a good one. And 2 cents/ip isn't a bad number, > the entire internet would generate $85M/yr for all the RiR's (well, > it'd be a bit less due to loss of some non-valid space). And my > legacy /24 would cost me $5.12/yr. At that, I'd easily consider a > membership. Well, there does need to be a certain minimum per org to cover billing, contracts, meetings, etc. which are fixed costs regardless how much space the org has. That doesn't need to be particularly large, but I think the current $100/yr for end-users seems reasonable; a /20 would be $93.90/yr at the above rate, so it'd be a wash for most small orgs anyways -- and certainly better than the $2,250/yr they pay now. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From sleibrand at internap.com Wed Aug 15 20:24:48 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 15 Aug 2007 17:24:48 -0700 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: <997BC128AE961E4A8B880CD7442D94800127CAEA@NJCHLEXCMB01.cable.comcast.com> References: <46C22BE3.2070701@internap.com> <997BC128AE961E4A8B880CD7442D94800127CAEA@NJCHLEXCMB01.cable.comcast.com> Message-ID: <46C39950.5040609@internap.com> Dan, I agree that massive hoarding requires exaggeration of stated need. However, what I'm worried about with lengthening the timeframe is that some organizations will request a year's worth of IP space as soon as they qualify for more, accelerating the transfer of unused addresses from RIRs to recipients and resulting in a greater time disparity of IPv4 free space exhaustion between ISPs, based not on how much efficiency and reclamation they performed, but on when they applied for their addresses. As we approach IPv4 free pool exhaustion, I think it makes sense to give orgs only enough IPv4 space to meet their immediate needs, ensuring a more level playing field between orgs. In any event, I don't think the difference between 6 months and a year is all that great, but I worry about accepting a policy proposal that moves us in the wrong direction, however slightly. -Scott Alexander, Daniel wrote: > Scott, > > I think of hoarding occurring in two ways. One would be where an > organization, inadvertently or not, requests more address space than > they actually use in the six months or a year. The other case is where > the org would falsify or exaggerate an application to get more than > they need. > > For the second one to happen, we would have to assume that ARIN does > not perform due diligence during the review of an application. Since I > go through this process several times a year, I can say with > confidence, that is not the case. Also, if an organization is > submitting fraudulent applications, that ARIN is not catching, it > wouldn't matter what the timeframe is, since they would just keep > coming back for more. > > There are several ways to throttle this problem. One is what's > currently in place. The one year allowance is for established > organizations who have documented growth. If the organization doesn't > have established growth trends, then ARIN would not approve the > application for the full amount of what is requested. This has also > happened to me on several occasions. :) If for some reason, an org > is allocated too much space, this would only be a one-time-shot. If an > org didn't grow at the rate it originally anticipated, it wouldn't be > able to make another application until the current space is used. > > There are also a number of discussions and proposals around ARIN being > able to audit and or reclaim space that is not being used properly. > It's just my opinion, but these are better means to control hoarding, > rather than restricting allocations to legitimate applications of need. > > I will concede I might be missing something though. If you can think > of ways this proposal could be abused, I would appreciate the input. I > like your suggestion that maybe they should all be six months. I > just figured it would be easier to bring one Registry in line with the > policy of the other four, rather than bring the other four in line > with the one. > > Thanks, > Dan > > ------------------------------------------------------------------------ > *From:* ppml-bounces at arin.net on behalf of Scott Leibrand > *Sent:* Tue 8/14/2007 6:25 PM > *To:* davids at webmaster.com > *Cc:* ppml at arin.net > *Subject:* Re: [ppml] Policy Proposal: Expand timeframe of Additional > Requests > > David Schwartz wrote: > >> Dan, > >> > >> I think this would've been a good change to make a few years ago, when > >> we were further away from IPv4 exhaustion. However, I think this > >> proposal moves us in the wrong direction with regards to avoiding > >> hoarding as IPv4 free pool exhaustion nears. > >> > >> -Scott > >> > > > > That was precisely my initial reaction to the proposal. Then I read > this: > > > > > >>> Currently, all RIR's provide organizations with at least a 12 month > >>> supply of IPv4 address space when making subsequent requests, with the > >>> exception of the ARIN region. The primary reason for this change > is for > >>> continuity among all RIR. In doing so, all established organizations > >>> have a more consistent access to IP resources. > >>> > > > > I think a level playing field is a good thing. But I do agree that > it may > > send the wrong message. > > > > Perhaps policy proposals to change 1-year-supply clauses to > 6-month-supply ones would be another way to level the playing field, > while moving us in the direction we need to go to deal with IPv4 free > pool exhaustion... > > -Scott > _______________________________________________ > 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. > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 drc at virtualized.org Wed Aug 15 20:51:30 2007 From: drc at virtualized.org (David Conrad) Date: Wed, 15 Aug 2007 17:51:30 -0700 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: References: Message-ID: Hi, On Aug 15, 2007, at 11:24 AM, Ted Mittelstaedt wrote: > 1) Return. IPv4 runout will cause some organizations to begin the > process of switching over to IPv6. Doesn't this assume the reason people haven't been switching over is because IPv4 is available? I thought the problem was that IPv6 doesn't provide sufficient benefit to outweigh the costs of deployment. Further, because there is insufficient perceived benefit in IPv6, customers aren't asking for it from their ISPs nor are they demanding IPv6 as a feature in the products those customers use to gain access to the Internet. As a result, there isn't support in large parts of the infrastructure (e.g., CPE routers, network management, customer provisioning, etc.) nor have content providers been willing to invest in IPv6-ifying their content provision infrastructure since there are no customers using IPv6 to gain access to that content. > Besides, return of IPv4 is essential to nipping any "ebay Inc trade > of IPv4" numbers in the bud, which most people agree is something > we want to do. This seems to at odds with your previous statement. If the reason people aren't switching over to IPv6 is because IPv4 is available, then wouldn't you want to encourage hoarders/speculators to buy up the IPv4 addresses to take them out of circulation? > 2) Sheer growth. A lot has been claimed how the legacy assignments > are a drop in the bucket. There have been approximately 100 legacy /8s assigned. This is more than the total allocations made to all the RIRs, combined. > Well, I will ask the question - if every IPv4 allocation ARIN makes > from this day forward to the date of IPv4 runout in 5 years or so > went straight to a hoarder, then wouldn't that mean that as of IPv4 > runout date if all hoarders were to immediately start selling their > hoards, wouldn't that really only constitute just a 5 year supply > of IPv4? Probably not. If ISPs were faced with a lack of IPv4 addresses they will adjust their behaviors in order to cope. That adjustment would likely impact the consumption rate. The concept of a "5 year supply" pre-supposes a particular consumption pattern. The assumption that address consumption patterns will remain constant in the face of run out is just silly. You can make the argument that consumption will increase due to "land grab" behavior (by hoarders, speculators, or the Men In Black) or you can make the argument that rationing and increased use of NAT will reduce consumption, but assuming consumption patterns will remain consistent with historical patterns is unlikely to match reality. > 3) History. The history of technology change has been that as soon > as something new is introduced, people start getting afraid of > being left behind and they will jump on the new thing, even if the > old thing works as well or even better. This does not appear to have impacted the uptake of IPv6. Regards, -drc From JThomas at Clarecomputer.com Thu Aug 16 00:14:54 2007 From: JThomas at Clarecomputer.com (John Thomas) Date: Wed, 15 Aug 2007 21:14:54 -0700 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: <0c3801c7df76$d1412170$6401a8c0@atlanta.polycom.com> References: <0c3801c7df76$d1412170$6401a8c0@atlanta.polycom.com> Message-ID: We just purchased another company that had an outstanding bill with ARIN for 2 /19's. ARIN said pay the $8000 and you get both /19's or pay nothing and ARIN would take them all back. 1 /19 was legacy from the days when IP addresses were free. We would have been quite happy to give back a /19 if ARIN would have been willing to do something for us financially. I realize that we are a guppy in the big pond though. John -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Stephen Sprunk Sent: Wednesday, August 15, 2007 12:40 PM To: Ted Mittelstaedt; Alexander, Daniel Cc: ARIN PPML Subject: Re: [ppml] Policy Proposal: Expand timeframe of Additional Requests Thus spake "Ted Mittelstaedt" > 1) Return. IPv4 runout will cause some organizations to begin the > process of switching over to IPv6. As they do this they will no > longer have need of IPv4 and will be able to start renting/selling it > or returning it to the RIR. Right now I feel a glaring policy hole is > there does not seem to be financial incentive to return IPv4 and > every time it's been suggested (primariarly in conjunction with the > legacy holders) it's been shouted down - but sooner or later > people will come to their senses and realize that getting orgs to > return IPv4 will help to accellerate adoption of IPv6 - because > even if the returned IPv4 is never used, you can point to "ACME, > Inc" and state with authority that they have no allocated or > assigned IPv4 and if they can do IPv6 you can too. There _is_ policy that allows return; the problem is the fee schedule. The 73 orgs that fit in the "X-large" category have absolutely no financial incentive to return space because they pay a constant amount until they get down to a /14, which in some cases means as little as 0.8% of their current consumption. Furthermore, since those orgs don't pay more as they consume more, there's not even a disincentive for them to waste _more_ space. These orgs currently hold 80% of ARIN-managed address space, so the small incentives (which do exist) for everyone else are just plain irrelevant -- even if smaller players conserve, that just leaves more space for the big guys to waste before exhaustion hits. If ARIN charged $0.268/yr/IP, just for the 26 /8s that show up as "ARIN" in IANA's list, that'd be enough to cover ARIN's current budget. Not only would that directly link consumption with fees (and thus encourage conservation/return), the vast majority of ARIN members would pay less under such a model as well. Of course, those 73 "X-large" orgs would be rather unhappy, which is why it hasn't been done. (There's also the lesser issue that end users with direct assignments pay $100/yr regardless of how much space they have, or $0/yr if they're legacy-only, so there is absolutely zero incentive for them to return anything if they deploy v6 because their fees won't change. We don't need _another_ flamefest about legacy holders, though, so let's stick to LIRs for the moment.) S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov _______________________________________________ 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 michael.dillon at bt.com Thu Aug 16 08:36:24 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 16 Aug 2007 13:36:24 +0100 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: <0c3801c7df76$d1412170$6401a8c0@atlanta.polycom.com> References: <0c3801c7df76$d1412170$6401a8c0@atlanta.polycom.com> Message-ID: > There _is_ policy that allows return; the problem is the fee > schedule. The > 73 orgs that fit in the "X-large" category have absolutely no > financial incentive to return space because they pay a > constant amount until they get down to a /14, Believe me, there is nothing that can be done to the fee schedule to give large organizations an incentive for returning IPv4. We pay $18,000 per year now. Even if it were double that, we still consider it to be a pittance in the overall corporate scheme of things. It would be a far greater incentive if we could somehow gain glory as a good corporate citizen by returning our IPv4 addresses as soon as they were no longer needed. Glory is something that you can take to the bank via your sales force using it to clinch major deals worth hundreds of millions, maybe billions. Just consider that in order to be able to return IPv4 addresses, an organization needs to first migrate some infrastructure to IPv6, second launch IPv6 products, third convert some IPv4 customers to the IPv6 products and 4th have good enough records to KNOW that the IPv4 address range is no longer needed. The act of returning those addresses broadcasts to everyone, how competent the organization is in all those areas, and how futureproof their services are. > (There's also the lesser issue that end users with direct > assignments pay $100/yr regardless of how much space they > have, or $0/yr if they're legacy-only, so there is absolutely > zero incentive for them to return anything if they deploy v6 > because their fees won't change. We don't need _another_ > flamefest about legacy holders, though, so let's stick to > LIRs for the moment.) Leaving aside that ARIN fees are NOT a matter of public policy and really should not be discussed on PPML, but on the ARIN-DISCUSS list, I think that the question of incentives to return IPv4 addresses is not nearly as simple as money issues. There was a little bit of dicsussion a while ago about the idea of requiring all new IPv4 allocation requests to contain the answers to a survey about IPv6 deployment within the organization. That survey was supposed to require the IP address management folks in or near the engineering department, to get the finance and regulatory and CTO type people involved in providing the answers. This creates a real incentive to deploy IPv6 because all those people will begin asking questions about their current strategies. They will all realize that IPv4 exhaustion could begin to bite them in as little as two years if RIR policies become more draconian. It's a question of identifying and quantifying risks associated with various strategies and realizing that IPv6 deployment helps to reduce risks. This doesn't incent returning IPv4 addresses, but it does incent IPv6 deployment. --Michael Dillon From Lee at dilkie.com Thu Aug 16 08:46:39 2007 From: Lee at dilkie.com (Lee Dilkie) Date: Thu, 16 Aug 2007 08:46:39 -0400 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: References: Message-ID: <46C4472F.6090203@dilkie.com> David Conrad wrote: > >> 3) History. The history of technology change has been that as soon >> as something new is introduced, people start getting afraid of >> being left behind and they will jump on the new thing, even if the >> old thing works as well or even better. >> > > This does not appear to have impacted the uptake of IPv6. > > > And this is where the earlier VHS vs BETAMAX analogy fails. When two competing technologies are head to head at the same time, and both offer (roughly) the same solution, your get these classic battles; VHS vs BETAMAX, Blu-RAY vs HD_DVD and of course, IP vs (IPX, banyan, X.25, SNA, the list goes on). There was a clear winner (eventually) in all those. However, comparing IPv6 to IPv4 isn't the same as VHS vs BETAMAX. Imagine if only BETAMAX was available in the early 80's (late 70's?) and VHS came along 10 years later. It offers no compelling reason to upgrade since it only offers essentially the same feature set. It'd never even get off the ground. For the consumer, a completely new technology with a compelling advantage needed to come along before VHS was abandoned (DVD was that). I see IPv6 in the same boat, trying to compete with IPv4 10 years (okay, probably like 25 years) later with essentially the same feature set. That's a hard sell. And folks. Please don't forget. The only migration strategy towards IPv6 is dual-stack. Folks are going to need both v6 and v4 addresses for a long time, this isn't going to relieve pressure for v4 addresses. -lee From kkargel at polartel.com Thu Aug 16 09:53:57 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 16 Aug 2007 08:53:57 -0500 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: <46C36681.2030901@Dilkie.com> References: <0c3801c7df76$d1412170$6401a8c0@atlanta.polycom.com> <46C36681.2030901@Dilkie.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410667072D0@mail> Being a small ISP this affects me differently. Having a /18 of IPv4 would incur a fee of about $450 , which wouldn't break the bank but does cause me concern when people want to raise my costs for nothing more than policy reasons. I don't mind paying more for added services, but I hate paying more to satisfy somebodies ego. If that $.0268 were applied to the IPv6 allocation as well I would surrender my IPv6 tomorrow. That cost would put me out of business and close my doors. > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Lee Dilkie > Sent: Wednesday, August 15, 2007 3:48 PM > To: Stephen Sprunk > Cc: ARIN PPML; Alexander, Daniel > Subject: Re: [ppml] Policy Proposal: Expand timeframe of > Additional Requests > > > > Stephen Sprunk wrote: > > If ARIN charged $0.268/yr/IP, just for the 26 /8s that show up as > > "ARIN" in IANA's list, that'd be enough to cover ARIN's current > > budget. Not only > > > > > unless my math is wrong, I get somewhere in the order of > $0.0229 or a tad over 2 cents/ip/yr to cover the current $10M budget. > > But your point is a good one. And 2 cents/ip isn't a bad > number, the entire internet would generate $85M/yr for all > the RiR's (well, it'd be a bit less due to loss of some > non-valid space). And my legacy /24 would cost me $5.12/yr. > At that, I'd easily consider a membership. > > -lee > > _______________________________________________ > 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 arin-contact at dirtside.com Thu Aug 16 10:12:28 2007 From: arin-contact at dirtside.com (William Herrin) Date: Thu, 16 Aug 2007 10:12:28 -0400 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A0631410667072D0@mail> References: <0c3801c7df76$d1412170$6401a8c0@atlanta.polycom.com> <46C36681.2030901@Dilkie.com> <70DE64CEFD6E9A4EB7FAF3A0631410667072D0@mail> Message-ID: <3c3e3fca0708160712n48c38b32u56a865bed38ae427@mail.gmail.com> On 8/16/07, Kevin Kargel wrote: > If that $.0268 were applied to the IPv6 allocation as well I would > surrender my IPv6 tomorrow. That cost would put me out of business and > close my doors. Kevin, Lets skip the straw men, hey? There is no shortage of IPv6 addresses and no one has suggested increasing the fees on IPv6 addresses for anybody. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From paul at vix.com Thu Aug 16 11:54:25 2007 From: paul at vix.com (Paul Vixie) Date: Thu, 16 Aug 2007 15:54:25 +0000 Subject: [ppml] dual-stack (was Re: Expand timeframe of Additional Requests ) In-Reply-To: Your message of "Thu, 16 Aug 2007 08:46:39 -0400." <46C4472F.6090203@dilkie.com> References: <46C4472F.6090203@dilkie.com> Message-ID: <95668.1187279665@sa.vix.com> > I see IPv6 in the same boat, trying to compete with IPv4 10 years (okay, > probably like 25 years) later with essentially the same feature set. > That's a hard sell. this analogy also falls apart (like all analogies) since there's no way that the entertainment industry could have "run out" of betamax and offered VHS as a way to keep doing what they'd been doing without "hitting the wall". we all want continued growth, enabled rather than fettered by technology. > And folks. Please don't forget. The only migration strategy towards IPv6 > is dual-stack. Folks are going to need both v6 and v4 addresses for a > long time, this isn't going to relieve pressure for v4 addresses. this seems to argue that we should have been deploying dual-stack for some years now, and that david conrad's soft landing proposal doesn't go far enough since it doesn't REQUIRE dual stack, merely asks to hear a plan for it. if we're going to need new V4 addresses for a long time, but we only have a supply that will last a short time, then the pressures toward NAT, toward black marketeering and piracy, toward deaggregation and routing table bloat, and toward RIR shopping and IP address globalization, give me a serious case of the heebee jeebees. can we talk about ways to use our last years of new IPv4 to get dual stack running everywhere, or at least running in enough places that a V6-only client in the post-V4-depletion era will have services they can talk to? should the conrad "soft landing" proposal require dual-stack for V4 allocations starting years before projected depletion? or maybe just for access-side or content- side? (separately and in other forums more technical, the industry ought to work on ways to make a V4-only pee cee able to get V4-like services from a local proxy that looks like a default gateway but actually does some kind of V6 tunnelling thing -- like NAT-PT except deployable. dual-stack as our only option, sucks.) From stephen at sprunk.org Thu Aug 16 12:47:02 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 16 Aug 2007 11:47:02 -0500 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests References: <0c3801c7df76$d1412170$6401a8c0@atlanta.polycom.com><46C36681.2030901@Dilkie.com> <70DE64CEFD6E9A4EB7FAF3A0631410667072D0@mail> Message-ID: <00b701c7e027$dc5edfa0$563816ac@atlanta.polycom.com> Thus spake "Kevin Kargel" > Being a small ISP this affects me differently. Having a /18 of IPv4 > would incur a fee of about $450 , which wouldn't break the bank An /18 costs an ISP $4500/yr today; you're objecting to your fees going down to $439.09/yr, a reduction of 90.2%? That doesn't make sense to me. > but does cause me concern when people want to raise my costs for > nothing more than policy reasons. I don't mind paying more for > added services, but I hate paying more to satisfy somebodies ego. Again, your fees would be going down, not up. Also, it's not just to satisfy someone's ego but because everyone is consuming a limited resource that we're rapidly running out of, and it makes sense that everyone pay the same amount for consumption instead of letting certain ISPs pay as little as 1/9000th of what smaller ISPs pay when they are consuming 80% of that scarce resource. > If that $.0268 were applied to the IPv6 allocation as well I would > surrender my IPv6 tomorrow. That cost would put me out of > business and close my doors. Obviously the same economics don't apply to v6. A single /48 would cost $32,399,211,965,672,061,882,125.52 at that price, which I'm pretty sure would put not just you but the entire industry out of business :) I don't know if ARIN's current v6 fee schedule makes sense either, but it's not a pressing concern at the moment since (a) nobody is using v6, and (b) no ISP would be paying v6 fees today even if they were using it. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From cliffb at cjbsys.bdb.com Thu Aug 16 13:24:27 2007 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Thu, 16 Aug 2007 13:24:27 -0400 (EDT) Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: <46C4472F.6090203@dilkie.com> from "Lee Dilkie" at Aug 16, 2007 08:46:39 AM Message-ID: <200708161724.l7GHOReY020615@cjbsys.bdb.com> > > David Conrad wrote: > > > >> 3) History. The history of technology change has been that as soon > >> as something new is introduced, people start getting afraid of > >> being left behind and they will jump on the new thing, even if the > >> old thing works as well or even better. > >> > > > > This does not appear to have impacted the uptake of IPv6. > > > > > > > And this is where the earlier VHS vs BETAMAX analogy fails. > > When two competing technologies are head to head at the same time, and > both offer (roughly) the same solution, your get these classic battles; > VHS vs BETAMAX, Blu-RAY vs HD_DVD and of course, IP vs (IPX, banyan, > X.25, SNA, the list goes on). > > There was a clear winner (eventually) in all those. > > However, comparing IPv6 to IPv4 isn't the same as VHS vs BETAMAX. > Imagine if only BETAMAX was available in the early 80's (late 70's?) and > VHS came along 10 years later. It offers no compelling reason to upgrade > since it only offers essentially the same feature set. It'd never even > get off the ground. For the consumer, a completely new technology with a > compelling advantage needed to come along before VHS was abandoned (DVD > was that). > I think a better analogy would be CDROMS. Everybody could read and eventually write to them. When DVDs came along (at least in the computer sense), they could read and write CDROMs. As I understand it, HD_DVD and BLU-RAY will also be backward compatible. That made adopting the new technology a no-brainer. I could read and write CDs with my DVD as well as create DVDs. IPv6 offers no such backward compatibility (Ok dual-stack does but it ain't quite the same). This will make it much harder to convince people that they want to change. The only technology thing I can think of that is as disruptive is the HDTV debacle foisted on the US by the FCC. Again a very disruptive technology change. (which I'll adopt around Feb 2009 :-) ) Cliff > I see IPv6 in the same boat, trying to compete with IPv4 10 years (okay, > probably like 25 years) later with essentially the same feature set. > That's a hard sell. > > And folks. Please don't forget. The only migration strategy towards IPv6 > is dual-stack. Folks are going to need both v6 and v4 addresses for a > long time, this isn't going to relieve pressure for v4 addresses. > > -lee > _______________________________________________ > 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. > -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From jmorrison at bogomips.com Thu Aug 16 13:25:46 2007 From: jmorrison at bogomips.com (John Paul Morrison) Date: Thu, 16 Aug 2007 10:25:46 -0700 Subject: [ppml] too many variables In-Reply-To: <20070814135453.GA38680@ussenterprise.ufp.org> References: <20070809162137.GA1797@vacation.karoshi.com> <20070810163650.GA48274@ussenterprise.ufp.org> <46BC9F59.4020501@bogomips.com> <21ef2c1c0708101108t5dc91c8dt4c4982d15635b780@mail.gmail.com> <20070810182455.GA57260@ussenterprise.ufp.org> <46C04E9A.3050804@cisco.com> <20070813142532.GA32490@ussenterprise.ufp.org> <8b7d2e170708131753h73d18f42j564adcff7e0c09f9@mail.gmail.com> <20070814135453.GA38680@ussenterprise.ufp.org> Message-ID: <46C4889A.8060505@bogomips.com> Vendor C does this with their IP PBX as well, practically all their other appliances, and their firewalls are just nicely packaged PCs. It might take a while for this to filter down to the routing side though. If anyone remembers MLS switching, there was the ability to have some more intelligent route processors distributing switching information out to ASICs (old Catalyst 5000 Netflow Feature Cards) Leo Bicknell wrote: > In a message written on Mon, Aug 13, 2007 at 05:53:00PM -0700, Scott Whyte wrote: > >> Pick a newly released Core 2 Duo. How long will Intel be selling it? >> How does that compare with getting it into your RP design, tested, >> produced, OS support integrated, sold, and stocked in your depots? >> > > Intel designates chips for "long life". That's why Vendor J is > still souring P-III 600's, which were new almost 8 years ago now. > Which one of the current chips is in that bucket, I don't know, but > the vendors could find out. > > Plus, your argument doesn't hold for the simple reason that servers > have the same lifespan as routers in most companies. HP, Dell, > IBM, they don't seem to be going under with changes in Intel's line > of chips. They don't seem to have support issues. As the vendors > move to off the shelf parts the arguments about testing, stocking, > and so forth start to go out the window. > > More importantly, why specialize? Vendor J's RE is basically a PC > connected to the backplane with FastEthernet. They did a lot of > engineering in airflow, sheet metal, and other packaging issues to > put it in a Juniper package, but to what end? > > Compare with Avaya. When they moved to a Linux brain in their phone > switch line they moved the brain out of the specialized forwarding > hardware (the old Definity PBX) and into a, wait for it, PC! Yes, > an off the shelf 2U PC they source from a third party, connected > to the backplane with Gigabit Ethernet. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Thu Aug 16 13:30:16 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 16 Aug 2007 10:30:16 -0700 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: Message-ID: >-----Original Message----- >From: David Conrad [mailto:drc at virtualized.org] >Sent: Wednesday, August 15, 2007 5:52 PM >To: Ted Mittelstaedt >Cc: Public Policy Mailing List >Subject: Re: [ppml] Policy Proposal: Expand timeframe of Additional >Requests > > >Hi, > >On Aug 15, 2007, at 11:24 AM, Ted Mittelstaedt wrote: >> 1) Return. IPv4 runout will cause some organizations to begin the >> process of switching over to IPv6. > >Doesn't this assume the reason people haven't been switching over is >because IPv4 is available? Yes > I thought the problem was that IPv6 >doesn't provide sufficient benefit to outweigh the costs of >deployment. That too. >Further, because there is insufficient perceived benefit >in IPv6, customers aren't asking for it from their ISPs nor are they >demanding IPv6 as a feature in the products those customers use to >gain access to the Internet. As a result, there isn't support in >large parts of the infrastructure (e.g., CPE routers, network >management, customer provisioning, etc.) nor have content providers >been willing to invest in IPv6-ifying their content provision >infrastructure since there are no customers using IPv6 to gain access >to that content. > All that is true. But you see, we aren't in an IPv4-runout status now, so people feel they still have a choice between what to deploy. >> Besides, return of IPv4 is essential to nipping any "ebay Inc trade >> of IPv4" numbers in the bud, which most people agree is something >> we want to do. > >This seems to at odds with your previous statement. If the reason >people aren't switching over to IPv6 is because IPv4 is available, >then wouldn't you want to encourage hoarders/speculators to buy up >the IPv4 addresses to take them out of circulation? > NO. The reason is that the IP numbers have no value to a hoarder unless they can sell them. So the hoarder is going to obtain as much as he can then as soon as IPv4 runout happens he's going to try to sell as much as he can as soon as he can - since the value of IPv4 will be highest right after runout. This will simply have the effect of delaying IPv6 switchover for the rich organizations that can afford to buy from hoarders. In other words, hoarding does not really take IPv4 out of circulation, since the hoarder has to see it put in to circulation to get paid. And the side effects would be terrible. Almost certainly it would prompt court cases and the like that could possibly produce caselaw in some jurisdictions of considering IP addresses property, thus ARIN might lose control of the assignment authority. That is why we would be foolish not to do what we can to make the environment for "ip v4 sales" to be very difficult for a hoarder to operate in. >> 2) Sheer growth. A lot has been claimed how the legacy assignments >> are a drop in the bucket. > >There have been approximately 100 legacy /8s assigned. This is more >than the total allocations made to all the RIRs, combined. > I keep waiting for someone to point this out when we get into these legacy holder flamefests. Sigh. >> Well, I will ask the question - if every IPv4 allocation ARIN makes >> from this day forward to the date of IPv4 runout in 5 years or so >> went straight to a hoarder, then wouldn't that mean that as of IPv4 >> runout date if all hoarders were to immediately start selling their >> hoards, wouldn't that really only constitute just a 5 year supply >> of IPv4? > >Probably not. If ISPs were faced with a lack of IPv4 addresses they >will adjust their behaviors in order to cope. That adjustment would >likely impact the consumption rate. The utilization requirements of the RIR already causes this as an incentive. >The concept of a "5 year supply" >pre-supposes a particular consumption pattern. The assumption that >address consumption patterns will remain constant in the face of run >out is just silly. That was just an example. I could have substituted "X year supply" then had to go into the detail of explaining that this means the timeperiod is variable due to factors, etc. >You can make the argument that consumption will >increase due to "land grab" behavior (by hoarders, speculators, or >the Men In Black) or you can make the argument that rationing and >increased use of NAT will reduce consumption, but assuming >consumption patterns will remain consistent with historical patterns >is unlikely to match reality. > That wasn't the point. I was making the point that no matter what you do, whether you stretch out or shrink the time before IPv4 runout, the fact is that runout will happen eventually and behaviors of ISP's will change. Even if hoarding and IP sales come into play, all it will do is put off the day of reckoning. Your arguing in effect that if people eat right and exercise that they will put off the time of their death so the focus of people should be eating right and exercising, and they shouldn't ever bother thinking about writing a will. >> 3) History. The history of technology change has been that as soon >> as something new is introduced, people start getting afraid of >> being left behind and they will jump on the new thing, even if the >> old thing works as well or even better. > >This does not appear to have impacted the uptake of IPv6. > IPv6 really hasn't been introduced. IPv6 is currently nothing more than a set of technical specifications without an implementation for the MAJORITY of operating systems in current production use. Once we see all Windows operating systems that are older than Vista drop down to 10% of the production installs in current use, we can consider that IPv6 has been introduced. Ted From tedm at ipinc.net Thu Aug 16 14:01:41 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 16 Aug 2007 11:01:41 -0700 Subject: [ppml] dual-stack (was Re: Expand timeframe of Additional Requests ) In-Reply-To: <95668.1187279665@sa.vix.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Paul Vixie >Sent: Thursday, August 16, 2007 8:54 AM >To: Public Policy Mailing List >Subject: [ppml] dual-stack (was Re: Expand timeframe of Additional >Requests ) > > >(separately and in other forums more technical, the industry ought >to work on >ways to make a V4-only pee cee able to get V4-like services from a >local proxy >that looks like a default gateway but actually does some kind of >V6 tunnelling >thing -- like NAT-PT except deployable. dual-stack as our only >option, sucks.) This has already been done for http. Please see the URL: http://ipv6gate.sixxs.net/ "...Welcome to the portal gate for the SixXS IPv6 IPv4 and IPv4 to IPv6 Website Gateway. The portal gives IPv6 capable http-clients access to IPv4-only websites and IPv4 capable http-clients access to IPv6-only websites..." I posted a link a while ago to the list that pointed to a site that gave instructions on how to setup an Apache webserver to provide transparent 6-to-4 proxy services. Count on Linksys Corp to produce a $149.00 device that will do this with all the popular protocols at some time in the future. Ted From drc at virtualized.org Thu Aug 16 14:09:23 2007 From: drc at virtualized.org (David Conrad) Date: Thu, 16 Aug 2007 11:09:23 -0700 Subject: [ppml] dual-stack (was Re: Expand timeframe of Additional Requests ) In-Reply-To: <95668.1187279665@sa.vix.com> References: <46C4472F.6090203@dilkie.com> <95668.1187279665@sa.vix.com> Message-ID: Hi, On Aug 16, 2007, at 8:54 AM, Paul Vixie wrote: > this seems to argue that we should have been deploying dual-stack > for some > years now, Well, yes. It would be depressing if this were a surprise. > and that david conrad's soft landing proposal doesn't go far > enough since it doesn't REQUIRE dual stack, merely asks to hear a > plan for it. Err, no. "Phase: 3 Threshold: 10 /8s Requirements: ... * Demonstrate availability of production IPv6 infrastructure and connectivity services." Well, OK. It doesn't say "dual stack" as I made the implicit assumption that people aren't going to turn off IPv4 to get IPv6. > if we're going to need new V4 addresses for a long time, Yes. > but we only have a supply that will last a short time, Where "we" is IANA/RIRs, yes. > then the pressures toward NAT, toward > black marketeering and piracy, toward deaggregation and routing > table bloat, > and toward RIR shopping and IP address globalization, give me a > serious case > of the heebee jeebees. It would be depressing if this were a surprise. For my own sanity, I must assume you are merely restating the obvious. > can we talk about ways to use our last years of new IPv4 to get > dual stack > running everywhere, or at least running in enough places that a V6- > only client > in the post-V4-depletion era will have services they can talk to? > should the > conrad "soft landing" proposal require dual-stack for V4 > allocations starting > years before projected depletion? or maybe just for access-side or > content- > side? For the sake of argument, assume IPv6 does not take off and that the IPv4 free pool becomes depleted to the point where an ISP is unable to obtain the address space they request. Pragmatically speaking, I see the following scenarios: a) the ISP cannibalizes the IPv4 addresses used for their internal infrastructure, either renumbering into private IPv4 address space or (preferabbly) into IPv6. b) the ISP negotiates a private deal with some entity that has more address space than they are using. This could be: 1) acquiring an entity that has address space, 2) offering services to customers who have address space if those customers give/lease their address space to the ISP, 3) or buying/leasing fragments of address space registered to another entity. Note that only b.3 implies additional routing system load, assuming the ISP doesn't announce new more specifics for traffic engineering. Also note that only b.1 and (maybe) b.3 imply involvement of the RIRs and this assumes the ISPs continue to use the RIRs as the means to determine address registration (the increased use of the black market for addresses will likely mean the RIR registration databases become less and less accurate over time). However, in all cases, there will be exceedingly strong pressure on the ISP to provide to the ISP's customers the absolute minimum address space possible, most likely single IP addresses to be used for the public side of NAT endpoints. I would imagine this will most likely be implemented as _significantly_ increased costs for PA space,likely coupled with increased hosting services as a business offering. Regards, -drc From tedm at ipinc.net Thu Aug 16 14:19:56 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 16 Aug 2007 11:19:56 -0700 Subject: [ppml] dual-stack (was Re: Expand timeframe of AdditionalRequests ) In-Reply-To: Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >David Conrad >Sent: Thursday, August 16, 2007 11:09 AM >To: Paul Vixie >Cc: Public Policy Mailing List >Subject: Re: [ppml] dual-stack (was Re: Expand timeframe of >AdditionalRequests ) > > >However, in all cases, there will be exceedingly strong pressure on >the ISP to provide to the ISP's customers the absolute minimum >address space possible, most likely single IP addresses to be used >for the public side of NAT endpoints. I would imagine this will most >likely be implemented as _significantly_ increased costs for PA >space,likely coupled with increased hosting services as a business >offering. > No, I suspect what the ISP's will do is tell the customers they have a choice: $15.95 a month DSL with IPv6 only $150.95 a month DSL with IPv4 only Then they will tell the customer if they want the cheap connectivity (substitute T1/Cable/ISDN/your preferred connectivity in place of DSL) to buy the $399.99 Linksys BEF-BEFV6-R6 IPv6 to IPv4 Proxy Gateway. (Substitute dlink/netgear/airlink/etc.etc. for Linksys) A product that is most likely on the drawing board at these companies right now, merely awaiting the marketing department's analysis of when it will become profitable to start selling them. Ted From kkargel at polartel.com Thu Aug 16 14:45:52 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 16 Aug 2007 13:45:52 -0500 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: <00b701c7e027$dc5edfa0$563816ac@atlanta.polycom.com> References: <0c3801c7df76$d1412170$6401a8c0@atlanta.polycom.com><46C36681.2030901@Dilkie.com> <70DE64CEFD6E9A4EB7FAF3A0631410667072D0@mail> <00b701c7e027$dc5edfa0$563816ac@atlanta.polycom.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410667072D7@mail> lol, yeah yur right.. I was confused.. my apologies to the list. Kevin > -----Original Message----- > From: Stephen Sprunk [mailto:stephen at sprunk.org] > Sent: Thursday, August 16, 2007 11:47 AM > To: Kevin Kargel; ARIN PPML > Subject: Re: [ppml] Policy Proposal: Expand timeframe of > Additional Requests > > Thus spake "Kevin Kargel" > > Being a small ISP this affects me differently. Having a > /18 of IPv4 > > would incur a fee of about $450 , which wouldn't break the bank > > An /18 costs an ISP $4500/yr today; you're objecting to your > fees going down to $439.09/yr, a reduction of 90.2%? That > doesn't make sense to me. > > > but does cause me concern when people want to raise my costs for > > nothing more than policy reasons. I don't mind paying more > for added > > services, but I hate paying more to satisfy somebodies ego. > > Again, your fees would be going down, not up. Also, it's not > just to satisfy someone's ego but because everyone is > consuming a limited resource that we're rapidly running out > of, and it makes sense that everyone pay the same amount for > consumption instead of letting certain ISPs pay as little as > 1/9000th of what smaller ISPs pay when they are consuming 80% > of that scarce resource. > > > If that $.0268 were applied to the IPv6 allocation as well I would > > surrender my IPv6 tomorrow. That cost would put me out of business > > and close my doors. > > Obviously the same economics don't apply to v6. A single /48 > would cost > $32,399,211,965,672,061,882,125.52 at that price, which I'm > pretty sure would put not just you but the entire industry > out of business :) > > I don't know if ARIN's current v6 fee schedule makes sense > either, but it's not a pressing concern at the moment since > (a) nobody is using v6, and (b) no ISP would be paying v6 > fees today even if they were using it. > > S > > Stephen Sprunk "Those people who think they know everything > CCIE #3723 are a great annoyance to those of us who do." > K5SSS --Isaac Asimov > > > From paul at vix.com Thu Aug 16 15:35:13 2007 From: paul at vix.com (Paul Vixie) Date: Thu, 16 Aug 2007 19:35:13 +0000 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: Your message of "Thu, 16 Aug 2007 10:30:16 MST." References: Message-ID: <57421.1187292913@sa.vix.com> > ... IP numbers have no value to a hoarder unless they can sell them. So the > hoarder is going to obtain as much as he can then as soon as IPv4 runout > happens he's going to try to sell as much as he can as soon as he can - > since the value of IPv4 will be highest right after runout. i wish that i agreed. even leaving aside the fact that IP addresses aren't property and that any market in them is a black market until and unless the community generally agrees to loosen the ties that bind us to RFC 2050, i'm struck by my utter disbelief that hoarders will dump. when you've got a pile of stuff that costs you nothing to hold onto (no upkeep, so this isn't like pork bellies), you will trickle it out into the market at a pace designed to keep prices high. if we postulate N hoarders and demand Q per interval T, each hoarder will have the quota of (N/Q)/T, knowing that if they exceed this they will not maximize their profit. see the RAM chip market for examples, except that in RAM chips the value of your hoard goes down with innovation -- having a lot of 256K chips is a burden when 512K chips come out, etc. IPv4 addresses, if the hoarders played their cards right, could increase in cost over time, since IPv6 is such a dark horse. > This will simply have the effect of delaying IPv6 switchover for the rich > organizations that can afford to buy from hoarders. In other words, > hoarding does not really take IPv4 out of circulation, since the hoarder has > to see it put in to circulation to get paid. a hoarder has to limit the amount put into circulation to get paid "the most." IOW, they would only dump in the months before IPv6 appeared to be viable, and that could still be "never" if the community doesn't get some coherency on it. > And the side effects would be terrible. Almost certainly it would prompt > court cases and the like that could possibly produce caselaw in some > jurisdictions of considering IP addresses property, thus ARIN might lose > control of the assignment authority. That is why we would be foolish not to > do what we can to make the environment for "ip v4 sales" to be very > difficult for a hoarder to operate in. on this point, i agree, with the proviso that ARIN's authority to allocate would become moot if there is nothing to allocate, and ARIN derives its authority from the community, who may yet cohere on the topic of address property rights. RFC 2050 describes a "right to use" on the "basis of need". perhaps if there's nothing left to allocate, the community will decide to expand this to a "right to use and/or dispose" which is the technical definition of property in most of the world. (dispose doesn't mean incinerate, it means do something that means you don't have it any more, like sell it.) that's a global community decision not a regional community decision. i don't know if it would be possible to rev RFC 2050 in today's world, but i expect some RIR bylaws somewhere might also have to be amended. also, on this point, the community seems thus far quite divided. folks who expect to keep needing more new IPv4 addresses after central pool depletion seem to favour the idea of making it "legal to buy them" (and therefore, "legal to sell them"). folks who expect to be able to renumber or to use NAT or to become more efficient seem to favour the idea of making it "legal to sell". on the other hand, folks who know that the highest and best use of property is to buy low and sell high, speculate, and subdivide, are concerned about the digital divide (can afford addresses vs. not), globalization (a village ISP in africa might be able to make the equivilent of a year's profit by selling their IP address block in new york), routing table growth due to subdivision, and probably other things i'm not thinking of at the moment. > > There have been approximately 100 legacy /8s assigned. This is more > > than the total allocations made to all the RIRs, combined. > > I keep waiting for someone to point this out when we get into these > legacy holder flamefests. Sigh. would the ARIN community agree to pay higher fees to build a cash hoard that ARIN could then use to "buy back" legacy space which would then be given to IANA to hand out on a "right to use, based on need" basis? (i'm not proposing this and i'm definitely not speaking as a trustee when pondering it, but i am curious to hear some answers.) > ... no matter what you do, whether you stretch out or shrink the time before > IPv4 runout, the fact is that runout will happen eventually and behaviors of > ISP's will change. Even if hoarding and IP sales come into play, all it > will do is put off the day of reckoning. yea, verily. tell it, brother. > > This does not appear to have impacted the uptake of IPv6. > > IPv6 really hasn't been introduced. IPv6 is currently nothing more than a > set of technical specifications without an implementation for the MAJORITY > of operating systems in current production use. > > Once we see all Windows operating systems that are older than Vista drop > down to 10% of the production installs in current use, we can consider that > IPv6 has been introduced. if you tell folks they can't have anything more than web access unless they upgrade to Vista, most will say that's fine, web access is all i need. let's not focus on the client platform in these discussions, that's a CPE/NAT-PT question for which v6ops at ietf is more suitable. From dean at av8.com Thu Aug 16 16:06:44 2007 From: dean at av8.com (Dean Anderson) Date: Thu, 16 Aug 2007 16:06:44 -0400 (EDT) Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: <46C39950.5040609@internap.com> Message-ID: Yes. Expanding the timeframe affirmatively enables hoarding. A longer timeframe increases the amount of addresses that can be requested, and extends the time to report on utilization. Anyone can lie for the timeframe. (or plans for usage just not work out). The longer the timeframe, the easier it is to lie, or just be "more wrong". If we are concerned about hoarding and the accuracy of planned usage, the timeframe should be reduced. --Dean On Wed, 15 Aug 2007, Scott Leibrand wrote: > Dan, > > I agree that massive hoarding requires exaggeration of stated need. > However, what I'm worried about with lengthening the timeframe is that > some organizations will request a year's worth of IP space as soon as > they qualify for more, accelerating the transfer of unused addresses > from RIRs to recipients and resulting in a greater time disparity of > IPv4 free space exhaustion between ISPs, based not on how much > efficiency and reclamation they performed, but on when they applied for > their addresses. > > As we approach IPv4 free pool exhaustion, I think it makes sense to give > orgs only enough IPv4 space to meet their immediate needs, ensuring a > more level playing field between orgs. > > In any event, I don't think the difference between 6 months and a year > is all that great, but I worry about accepting a policy proposal that > moves us in the wrong direction, however slightly. > > -Scott > > Alexander, Daniel wrote: > > Scott, > > > > I think of hoarding occurring in two ways. One would be where an > > organization, inadvertently or not, requests more address space than > > they actually use in the six months or a year. The other case is where > > the org would falsify or exaggerate an application to get more than > > they need. > > > > For the second one to happen, we would have to assume that ARIN does > > not perform due diligence during the review of an application. Since I > > go through this process several times a year, I can say with > > confidence, that is not the case. Also, if an organization is > > submitting fraudulent applications, that ARIN is not catching, it > > wouldn't matter what the timeframe is, since they would just keep > > coming back for more. > > > > There are several ways to throttle this problem. One is what's > > currently in place. The one year allowance is for established > > organizations who have documented growth. If the organization doesn't > > have established growth trends, then ARIN would not approve the > > application for the full amount of what is requested. This has also > > happened to me on several occasions. :) If for some reason, an org > > is allocated too much space, this would only be a one-time-shot. If an > > org didn't grow at the rate it originally anticipated, it wouldn't be > > able to make another application until the current space is used. > > > > There are also a number of discussions and proposals around ARIN being > > able to audit and or reclaim space that is not being used properly. > > It's just my opinion, but these are better means to control hoarding, > > rather than restricting allocations to legitimate applications of need. > > > > I will concede I might be missing something though. If you can think > > of ways this proposal could be abused, I would appreciate the input. I > > like your suggestion that maybe they should all be six months. I > > just figured it would be easier to bring one Registry in line with the > > policy of the other four, rather than bring the other four in line > > with the one. > > > > Thanks, > > Dan > > > > ------------------------------------------------------------------------ > > *From:* ppml-bounces at arin.net on behalf of Scott Leibrand > > *Sent:* Tue 8/14/2007 6:25 PM > > *To:* davids at webmaster.com > > *Cc:* ppml at arin.net > > *Subject:* Re: [ppml] Policy Proposal: Expand timeframe of Additional > > Requests > > > > David Schwartz wrote: > > >> Dan, > > >> > > >> I think this would've been a good change to make a few years ago, when > > >> we were further away from IPv4 exhaustion. However, I think this > > >> proposal moves us in the wrong direction with regards to avoiding > > >> hoarding as IPv4 free pool exhaustion nears. > > >> > > >> -Scott > > >> > > > > > > That was precisely my initial reaction to the proposal. Then I read > > this: > > > > > > > > >>> Currently, all RIR's provide organizations with at least a 12 month > > >>> supply of IPv4 address space when making subsequent requests, with the > > >>> exception of the ARIN region. The primary reason for this change > > is for > > >>> continuity among all RIR. In doing so, all established organizations > > >>> have a more consistent access to IP resources. > > >>> > > > > > > I think a level playing field is a good thing. But I do agree that > > it may > > > send the wrong message. > > > > > > > Perhaps policy proposals to change 1-year-supply clauses to > > 6-month-supply ones would be another way to level the playing field, > > while moving us in the direction we need to go to deal with IPv4 free > > pool exhaustion... > > > > -Scott > > _______________________________________________ > > 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. > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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. > > > _______________________________________________ > 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. > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From stephen at sprunk.org Thu Aug 16 16:22:47 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 16 Aug 2007 15:22:47 -0500 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests References: <57421.1187292913@sa.vix.com> Message-ID: <014b01c7e043$f0e50500$563816ac@atlanta.polycom.com> Thus spake "Paul Vixie" > would the ARIN community agree to pay higher fees to build a > cash hoard that ARIN could then use to "buy back" legacy space > which would then be given to IANA to hand out on a "right to use, > based on need" basis? (i'm not proposing this and i'm definitely > not speaking as a trustee when pondering it, but i am curious to > hear some answers.) I love that idea, however I propose the maximum price ARIN pay be the same as those orgs paid to acquire their blocks in the first place. Adjust for inflation if desired; it'll be $0 either way. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From michael.dillon at bt.com Thu Aug 16 16:46:26 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 16 Aug 2007 21:46:26 +0100 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: References: Message-ID: > And the side effects would be terrible. Almost certainly it > would prompt court cases and the like that could possibly > produce caselaw in some jurisdictions of considering IP > addresses property, thus ARIN might lose control of the > assignment authority. More likely the caselaw would find that ARIN has the stronger property rights in the IP addresses and that the ARIN members are merely being loaned the addresses under the ARIN policies. And the legacy holders have no property rights at all. In the end, if you don't get your addresses through the proper ARIN channels, or voluntarily come into compliance with ARIN rules, you could find that caselaw precedents set by hoarding cases will remove your right to use your legacy addresses. > IPv6 really hasn't been introduced. IPv6 is currently > nothing more than a set of technical specifications without > an implementation for the MAJORITY of operating systems in > current production use. Huh! I know there are IPv6 implementations for Windows 98 so I'm not sure where this comes from. In any case, with today's virtualization technology, you can take a Linux server and install a virtual machine to run the legacy application. The Linux server can then run whatever you need to gateway or proxy the communication into IPv6. On the other hand, if you are talking about consumer devices, then that is irrelevant. Let them keep using IPv4 because it isn't going away. If they want to use IPv6, then the ISP should set up a v6 tunnel broker for their customers. There will be plenty of customers who either don't require their older computers to have net connectivity, or who are used to a regular refresh cycle and will simply upgrade to v6 compatible devices when they switch to v6 Internet service. --Michael Dillon From tedm at ipinc.net Thu Aug 16 17:52:57 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 16 Aug 2007 14:52:57 -0700 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: <57421.1187292913@sa.vix.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Paul Vixie >Sent: Thursday, August 16, 2007 12:35 PM >To: Public Policy Mailing List >Subject: Re: [ppml] Policy Proposal: Expand timeframe of Additional >Requests > > >> ... IP numbers have no value to a hoarder unless they can sell >them. So the >> hoarder is going to obtain as much as he can then as soon as IPv4 runout >> happens he's going to try to sell as much as he can as soon as he can - >> since the value of IPv4 will be highest right after runout. > >i wish that i agreed. even leaving aside the fact that IP addresses aren't >property and that any market in them is a black market until and unless the >community generally agrees to loosen the ties that bind us to RFC 2050, i'm >struck by my utter disbelief that hoarders will dump. when you've got a >pile of stuff that costs you nothing to hold onto (no upkeep, so this isn't >like pork bellies), you will trickle it out into the market at a >pace designed >to keep prices high. if we postulate N hoarders and demand Q per >interval T, >each hoarder will have the quota of (N/Q)/T, knowing that if they >exceed this >they will not maximize their profit. see the RAM chip market for examples, >except that in RAM chips the value of your hoard goes down with >innovation -- >having a lot of 256K chips is a burden when 512K chips come out, etc. IPv4 >addresses, if the hoarders played their cards right, could increase in cost >over time, since IPv6 is such a dark horse. > But the hoarders are competing with each other and there is no OPEC here. The first hoarder to sell IP's will no doubt try what your saying - the next one will undercut, the thrid one will undercut more, and so on. Keep in mind what the hoarders are doing is borderline criminal - they lied on the RSA to get the stock, if ARIN catches up with them ARIN could revoke the entire assignment. If one of the ISPs they are pitching V4 to decides that they are trying to jack the price up too high - the ISP reports to ARIN and bam - addresses revoked. If some network adminstrator like you or I stumbles across something weird that leads us to believe there is some IPv4 selling going on in violation of the RSA we report it to ARIN and bam - ARIN investigates and the whole block is revoked. ARIN puts up a $5,000 reward for information regarding falsification of RSA and a disgruntled network admin fired from some ISP decides to get revenge and - bam ARIN investigates and the block is revoked. And all the while the rest of the legitimate world will be doing whatever possible to switchover to IPv6 and so as time passes the hoard will be worth less and less. Here's an idea for you - let's make a policy that any network or ISP that needs IPv4 addresses, if they report what they think is a hoarder that on investigation ARIN determines lied on their RSA, ARIN will immediately revoke the ENTIRE block allocated to the hoarder and give it to the network or ISP. That would probably kill the hoarders. Criminals have a notorious history of NOT cooperating with each other - at least, the ones outside of the government do - and they also have a notorious record of selling each other out for money. if a "killer app" appears that is IPv6 only - then almost ALL IPv4 on the Internet will immediately become worthless. And as IPv4 gets turned in - the hoarders will find themselves competing with the RIR's again to sell IPv4. My off-the-cuff estimate is that any hoarder is going to have a max of 3 years post-IPv4 runout to sell or "rent" their IPv4 stock before the price starts dropping due to oversupply. Another analogy is Freon, AKA Refrigerant 12. When the EPA banned the little R12 "chargette" cans they announced it a year in advance and a bunch of people ran out buying cases of the stuff - figuring they would make a killing 4-5 years later selling Freon. What happened is that within 3 years the price of Freon on the market crashed, and today there's tons of it out there, even though it hasn't been manufactured for years. Automakers and others switched over to R134a, and the gas refiners produced tons of it from recycled refrigerant they bought from the auto repair places. > >also, on this point, the community seems thus far quite divided. folks who >expect to keep needing more new IPv4 addresses after central pool depletion >seem to favour the idea of making it "legal to buy them" (and therefore, >"legal to sell them"). folks who expect to be able to renumber or >to use NAT >or to become more efficient seem to favour the idea of making it "legal to >sell". on the other hand, folks who know that the highest and best use of >property is to buy low and sell high, speculate, and subdivide, >are concerned >about the digital divide (can afford addresses vs. not), globalization (a >village ISP in africa might be able to make the equivilent of a >year's profit >by selling their IP address block in new york), routing table growth due to >subdivision, and probably other things i'm not thinking of at the moment. > If IPv4 "sales" are allowed widely it will drive a stake in the heart of IPv6 deployment and billions of dollars that the large networks have already invested in getting ready for IPv6 will have been wasted. I think the problem is the community hasn't throught it through. People are entranced with the idea that a legacy holder that paid nothing to get a /8 and nothing to maintain it might possibly be able to sell it for millions. It's the classic American get-rich-quick story that is nothing more than a mirage. Hopefully people will come to their senses and put a damper on this. Ted From tedm at ipinc.net Thu Aug 16 18:10:16 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 16 Aug 2007 15:10:16 -0700 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >michael.dillon at bt.com >Sent: Thursday, August 16, 2007 1:46 PM >To: ppml at arin.net >Subject: Re: [ppml] Policy Proposal: Expand timeframe of Additional >Requests > > >> And the side effects would be terrible. Almost certainly it >> would prompt court cases and the like that could possibly >> produce caselaw in some jurisdictions of considering IP >> addresses property, thus ARIN might lose control of the >> assignment authority. > >More likely the caselaw would find that ARIN has the stronger property >rights in the IP addresses and that the ARIN members are merely being >loaned the addresses under the ARIN policies. And the legacy holders >have no property rights at all. In the end, if you don't get your >addresses through the proper ARIN channels, or voluntarily come into >compliance with ARIN rules, you could find that caselaw precedents set >by hoarding cases will remove your right to use your legacy addresses. > The opponents of assisted suicide in the state that I live in, Oregon, thought that way. They dragged the courts in and succeeded in getting 2 pro-assisted suicide laws that were passed invalidated one after another. They thought they were so smart that they had manipulated the courts to get the result they wanted. It blew up in their faces though because it caused the population to become intensely pro-assisted suicide and public outcry finally forced the politicians to pass a 3rd law that was ten times worse (from the opponent's point of view) than the prior 2 ones. Indeed, the support was so solidified that when the federal government attempted to intervene and get the law invalidated, they failed. The courts and government are a chancy way of making policy and history is replete with examples of decisions that defy logic and made things worse. That caselaw would also of course only apply to the country that it happend in. > >> IPv6 really hasn't been introduced. IPv6 is currently >> nothing more than a set of technical specifications without >> an implementation for the MAJORITY of operating systems in >> current production use. > >Huh! I know there are IPv6 implementations for Windows 98 so I'm not >sure where this comes from. Unless it was distributed by Microsoft with the operating system it won't be supported by any of the 3rd party ISVs. Sure, Microsoft might give you support on their beta IPv6 stack, might even fix bugs in it. But someone like Peoplesoft won't give you the time of day if you have a problem, unless it was part of the operating system when the OS was originally released. Hell, half the time they won't even help you when their stuff breaks due to application of security patches! Ted From drc at virtualized.org Thu Aug 16 19:23:50 2007 From: drc at virtualized.org (David Conrad) Date: Thu, 16 Aug 2007 16:23:50 -0700 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: References: Message-ID: <80096473-EFAC-47BE-B577-3AE63E9F419D@virtualized.org> Ted, On Aug 16, 2007, at 2:52 PM, Ted Mittelstaedt wrote: > The first hoarder to sell IP's will no doubt try what your saying - > the next one will undercut, the thrid one will undercut more, and > so on. This is, of course, assumes a market in IP addresses will behave like any other market. However, there are some who do not believe this would apply to IP addresses and that speculators would engage in "Enron-like" behavior, driving the price of IPv4 addresses to ruinous heights. I suspect reality is somewhere in between and largely depends on the number of sellers. > Keep in mind what the hoarders are doing is borderline criminal - they > lied on the RSA to get the stock, if ARIN catches up with them ARIN > could revoke the entire assignment. As I mentioned, there are around 100 legacy /8s. By definition, these addresses were not assigned under an RSA. One may assert that those addresses implicitly fall under the RIR policy regime by tradition or some such, but I honestly can't imagine such assertions would go unchallenged. > Another analogy is Freon, AKA Refrigerant 12. > ... > What happened is > that within 3 years the price of Freon on the market crashed, and > today > there's tons of it out there, even though it hasn't been > manufactured for > years. An interesting analogy. > If IPv4 "sales" are allowed widely it will drive a stake in the > heart of > IPv6 deployment and billions of dollars that the large networks > have already > invested in getting ready for IPv6 will have been wasted. An interesting assertion that might need a bit of explanation. An alternative view is that the unpredictable (other than being higher) cost of obtaining IPv4 will encourage ISPs to migrate to IPv6 more quickly in order to regain some level of predictability in the costs of addressing. Regards, -drc From tedm at ipinc.net Thu Aug 16 21:03:31 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 16 Aug 2007 18:03:31 -0700 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: <80096473-EFAC-47BE-B577-3AE63E9F419D@virtualized.org> Message-ID: >-----Original Message----- >From: David Conrad [mailto:drc at virtualized.org] >Sent: Thursday, August 16, 2007 4:24 PM >To: Ted Mittelstaedt >Cc: Public Policy Mailing List >Subject: Re: [ppml] Policy Proposal: Expand timeframe of Additional >Requests > > >Ted, > >On Aug 16, 2007, at 2:52 PM, Ted Mittelstaedt wrote: >> The first hoarder to sell IP's will no doubt try what your saying - >> the next one will undercut, the thrid one will undercut more, and >> so on. > >This is, of course, assumes a market in IP addresses will behave like >any other market. However, there are some who do not believe this >would apply to IP addresses and that speculators would engage in >"Enron-like" behavior, driving the price of IPv4 addresses to ruinous >heights. Fine with me since that would impact the large networks ability to complete if they chose to not push IPv6 - and it is only the large networks pushing IPv6 that will get the IPv6 Spruce Goose off the ground. >I suspect reality is somewhere in between and largely >depends on the number of sellers. > And whether the community carves out exemptions to allow it. >> Keep in mind what the hoarders are doing is borderline criminal - they >> lied on the RSA to get the stock, if ARIN catches up with them ARIN >> could revoke the entire assignment. > >As I mentioned, there are around 100 legacy /8s. By definition, >these addresses were not assigned under an RSA. Under a current RSA. I had thought there WERE criteria for the original assignment. ARIN also is not under obligation to manage WHOIS records for the legacy holders, and is doing it for the good of the NON-legacy holders, mainly. If the legacy holders get heavily into IPv4 sales it will destroy the usefulness of the whois records that cover the legacy holders, thus there would no longer be an incentive to the community to have ARIN keep track of it. At that point the community could have ARIN drop all whois records for the legacy holders and it would essentially throw those blocks to the dogs. You do realize ARIN won't allow a transfer of a legacy block to a "purchaser" without a signed RSA and billing commencement, regardless of whether a legacy holder has made a side deal to "sell" the block to someone. There's a lot of ways I can think of to make hoarding and sale of legacy blocks an extremely uncomfortable thing for the legacy holders to engage in. I'm sure the community can think of many more. Furthermore since the legacy holders have held those blocks for so long I think it's not reasonable to assume they aren't already using quite a large amount of them - when they know they have them of course. I suspect a lot of legacy blocks are tied up with entities that have no legal existance any longer and are kind of in limbo. > One may assert that >those addresses implicitly fall under the RIR policy regime by >tradition or some such, but I honestly can't imagine such assertions >would go unchallenged. > >> Another analogy is Freon, AKA Refrigerant 12. >> ... >> What happened is >> that within 3 years the price of Freon on the market crashed, and >> today >> there's tons of it out there, even though it hasn't been >> manufactured for >> years. > >An interesting analogy. > >> If IPv4 "sales" are allowed widely it will drive a stake in the >> heart of >> IPv6 deployment and billions of dollars that the large networks >> have already >> invested in getting ready for IPv6 will have been wasted. > >An interesting assertion that might need a bit of explanation. OK well here's the idea on that. Organizations are naturally going to do the cheapest thing. If ARIN and the community makes IPv4 "sales" easy, pleasant, and sanctioned things, and there's a lot of IPv4 rolling around that is unused and easy to untie, then hoarders are going to flourish, the price of IPv4 will be low, and most ISP's will simply buy IPv4 from a broker rather than bothering with waiting in line for a IPv4 block to become freed up in one of the RIRs. But I just cannnot see how you could make such a thing happen for IPv4 sales without running afoul of a lot of policy and assumptions that people have made so far. The utilization requirements for one thing - how can a hoarder operate without having a large stockpile of unused numbers, and how can they get this without lying - unless they were a legacy holder - in which case the legacy holders sell off their holdings and ARIN forces the "buyers" to sign an RSA and meat utilization requirements, or the legacy holders attempt to "rent" the IP's out while not changing the whois data - which ruins whois, and thus provides incentives for the community to just drop recording of legacy IPv4 blocks in the public records. You cannot have it both ways as the saying goes. Worse, what would you do if you were a legitimate org that had been paying your money for the last 6 years for your /21 or whatever, and then found out you could turn it back in to ARIN and go to a broker and rent IPv4 from the broker for a quarter of the cost of what you had been paying ARIN? I would think a lot of people would go to the broker and sing a contract with them - that reduces control over the blocks that the RIRs have, the RIR's wouldn't stand for it. Then all the IPv6 incentive policy we have been talking about here becomes useless because the people paying for the IPv4 aren't paying the RIR now they are paying the broker and the broker is going to have an incentive to make them NOT update to IPv6 (since that will put him out of business) by making it cheap to retain the IPv4. And how does the RIR you apply incentive policy to a broker if they are going to allow brokering/hoarding? The whole thing becomes a house of cards with contradictory and hypocritical policy that is just going to invite lawsuits. >An >alternative view is that the unpredictable (other than being higher) >cost of obtaining IPv4 will encourage ISPs to migrate to IPv6 more >quickly in order to regain some level of predictability in the costs >of addressing. That too. Ted From leo.vegoda at icann.org Fri Aug 17 05:18:10 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 17 Aug 2007 11:18:10 +0200 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: References: Message-ID: <79664833-061A-4A66-B9C6-3252B51CEA81@icann.org> On 17 Aug 2007, at 03:03, Ted Mittelstaedt wrote: [...] > But I just cannnot see how you could make such a thing happen for > IPv4 sales without running afoul of a lot of policy and assumptions > that people have made so far. The utilization requirements for > one thing - how can a hoarder operate without having a large stockpile > of unused numbers, and how can they get this without lying - unless > they were a legacy holder - in which case the legacy holders sell > off their holdings and ARIN forces the "buyers" to sign an RSA and > meat utilization requirements, or > the legacy holders attempt to "rent" the IP's out while not changing > the whois data - which ruins whois, and thus provides incentives for > the community to just drop recording of legacy IPv4 blocks in the > public records. You're assuming that they wouldn't want to change the data in whois to show that their 'tenant' is responsible for the network in question. As long as the 'freeholder' can reclaim the space when the rent isn't paid there isn't a problem for them and they may well want to update ARIN's whois server or their own rwhois server. Regards, Leo Vegoda From info at arin.net Fri Aug 17 11:19:43 2007 From: info at arin.net (Member Services) Date: Fri, 17 Aug 2007 11:19:43 -0400 Subject: [ppml] Policy Proposal: End Policy for IANA IPv4 allocations to RIRs Message-ID: <46C5BC8F.7090302@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: End Policy for IANA IPv4 allocations to RIRs Author: JPNIC IPv4 countdown policy team; Akinori MAEMURA Akira NAKAGAWA Izumi OKUTANI Kosuke ITO Kuniaki KONDO Shuji NAKAMURA Susumu SATO Takashi ARANO Tomohiro FUJISAKI Tomoya YOSHIDA Toshiyuki HOSAKA Proposal Version: 2 Submission Date: 2007/08/17 Proposal type: new Policy term:renewable Policy statement: 1) Distribute a single /8 to each RIR at the point when new IANA free pool hits 5 */8. This date is defined as "IANA Exhaustion Date". 2) It should be completely left up to each RIR communities to define a regional policy on how to distribute the remaining RIR free pool to LIRs within their respective regions after "IANA Exhaustion Date". Note 1: It is fine for an RIR to continue operations with the existing policy if that is the consensus decision of the respective RIR community. Note 2: Address recovery and re-distribution of recovered address space is another important measure for considerations, but should be treated as a separate policy proposal from distribution of new IANA pool. 3) RIRs should provide an official projection on IANA Exhaustion Date to the community through their website, at their Policy Meetings and through any other effective means. Rationale: [current problem] There are two major issues in terms of address management if no measures are taken for IPv4 address exhaustion. 1) Continue applying a global coordinated policy for distribution of the last piece(s) of RIR's unallocated address block does not match the reality of the situation in each RIR region. Issues each RIR region will face during the exhaustion period vary by region as the level of development of IPv4 and IPv6 are widely different. As a result, applying a global co-ordinated policy may not adequately address issues in a certain region while it could be work for the others. For example, in a region where late comers desperately need even small blocks of IPv4 addresses to access to the IPv4 Internet, a policy that defines the target of allocations/assignments of IPv4 address space to be late comers would be appropriate in such region. This would allow availablilty of IPv4 address space for such requirements for more years. Another example comes from difference in IPv6 deployment rate. For a region where IPv6 deployment rate is low, measures may be necessary to prolong IPv4 address life for the existing business as well as for new businesses until networks are IPv6 ready. Some regions may have strong needs to secure IPv4 address space for translators. A globally coordinated policy which addresses all the issues listed above to meet the needs for all RIR regions may result in not solving issues in any of the regions. 2) LIRs and stakeholders remain unprepared for the situation if they are not informed If LIRs and the community are uninformed of the exhaustion, their services and networks remain unprepared to face the situation at the time of exhaustion. [Objective of the proposal] This proposal seeks to provide the following solutions to the problems listed above. 1) RIR community should be able to define their own regional policies on how to assign the last piece(s) of allocation block in order to address their own regional issues during the exhaustion period. 2) RIRs should provide official projection of the date when LIRs will be able to receive the allocations under the current criteria. The criteria should remain consistent until this date in order to avoid confusion. [Pros and Cons] Pros: + It allows each RIR community to define a policy on how to distribute the last piece(s) of allocations which best matches their situation. + It helps LIR better informed of the date when they are able to receive allocations from RIRs under the current criteria and prepare for the event. Cons: + Concerns could be raised about allocating a fixed size to all RIRs, that it artificially fastens the consumption rate of some RIR regions. However, its impact is kept to minimum by keeping the allocation size to a single /8 which makes merely 3-4 months difference. + Concerns could be raised that explicitly allowing regional policies will encourage RIR shopping. However, this should not happen if the requirements within each region is adequately reflected in each RIR's policy through PDP. RIR may also chose to add criteria to prevent LIRs from other regions submitting such requests. Timetable for implementation: Immediate after all 5 RIRs (and possibly ICANN) ratifies the policy. From owen at delong.com Fri Aug 17 11:47:58 2007 From: owen at delong.com (Owen DeLong) Date: Fri, 17 Aug 2007 08:47:58 -0700 Subject: [ppml] Policy Proposal: End Policy for IANA IPv4 allocations to RIRs In-Reply-To: <46C5C1F5.7020005@arin.net> References: <46C5BC8F.7090302@arin.net> <0BBD347F-1FC5-41D1-989D-69E09EA15A62@delong.com> <46C5C1F5.7020005@arin.net> Message-ID: <1D09261C-79D9-45B2-8494-F8AD1E1E6B3B@delong.com> DOH!!! Maybe you guys should set the Reply-to on those. ;-) Owen On Aug 17, 2007, at 8:42 AM, Member Services wrote: > Owen, > Your response only came back to Member Services (info at arin.net). > Please post to PPML. > > Thanks! > Erika Goedrich > ARIN Member Services > > Owen DeLong wrote: >> I am neutral on this policy. I don't support it, but, I have no >> strong opposition >> to it, either. >> However, I do wish to address some of the items contained in the >> narrative. >> First, I think it is absolutely essential that each RIR >> communicate the impending >> IPv4 free pool exhaustion to their constituency. I believe this >> is happening and >> I do not believe this policy would affect that in any way. >> Second, the assertion that current policy is a globally >> coordinated policy >> is absurd. Each RIR sets its own policy for allocation and >> assignment >> today. All that is globally coordinated currently is the policy >> on how >> the IANA allocates to RIRs. While I don't mind dividing the last 5 >> /8s evenly amongst the 5 RIRs (perhaps this policy should state >> the last N /8s where N is the current number of RIRs at the time N >> is reached, but, I don't anticipate N changing from 5 between now >> and then), I don't see the effect of this as being significantly >> different >> from what will likely happen naturally in the course of current >> IANA- >RIR >> policy. >> What this policy achieves is that each RIR clearly knows when it has >> received its last /8 from the IANA and knows which /8 that is. If we >> continue to follow current IANA->RIR practices, I believe that the >> IANA >> and RIRs will have a pretty good idea when that point is reached as >> well, with the possible surprise that some RIRs may receive one more >> allocation round than they expected to. >> Personally, I am much more concerned about the RIR policies to deal >> with RIR Free Pool exhaustion process. I'm pretty sure that IANA and >> RIRs can handle the IANA free pool exhaustion appropriately under >> existing policy, but, I don't regard this policy as harmful to >> that process. >> Owen >> On Aug 17, 2007, at 8:19 AM, 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: End Policy for IANA IPv4 allocations to RIRs >>> >>> Author: JPNIC IPv4 countdown policy team; >>> Akinori MAEMURA >>> Akira NAKAGAWA >>> Izumi OKUTANI >>> Kosuke ITO >>> Kuniaki KONDO >>> Shuji NAKAMURA >>> Susumu SATO >>> Takashi ARANO >>> Tomohiro FUJISAKI >>> Tomoya YOSHIDA >>> Toshiyuki HOSAKA >>> >>> Proposal Version: 2 >>> >>> Submission Date: 2007/08/17 >>> >>> Proposal type: new >>> >>> Policy term:renewable >>> >>> Policy statement: >>> >>> 1) Distribute a single /8 to each RIR at the point when new IANA >>> free >>> pool hits 5 */8. This date is defined as "IANA Exhaustion Date". >>> >>> 2) It should be completely left up to each RIR communities to >>> define a >>> regional policy on how to distribute the remaining RIR free >>> pool to >>> LIRs within their respective regions after "IANA Exhaustion >>> Date". >>> >>> Note 1: It is fine for an RIR to continue operations with the >>> existing policy if that is the consensus decision of the >>> respective RIR community. >>> >>> Note 2: Address recovery and re-distribution of recovered >>> address >>> space is another important measure for >>> considerations, but >>> should be treated as a separate policy proposal from >>> distribution of new IANA pool. >>> >>> 3) RIRs should provide an official projection on IANA Exhaustion >>> Date >>> to the community through their website, at their Policy Meetings >>> and through any other effective means. >>> >>> >>> Rationale: >>> [current problem] >>> There are two major issues in terms of address management if no >>> measures >>> are taken for IPv4 address exhaustion. >>> >>> 1) Continue applying a global coordinated policy for >>> distribution of the >>> last piece(s) of RIR's unallocated address block does not >>> match the >>> reality of the situation in each RIR region. >>> >>> Issues each RIR region will face during the exhaustion >>> period vary by >>> region as the level of development of IPv4 and IPv6 are widely >>> different. As a result, applying a global co-ordinated >>> policy may not >>> adequately address issues in a certain region while it could >>> be work >>> for the others. >>> >>> For example, in a region where late comers desperately need even >>> small blocks of IPv4 addresses to access to the IPv4 Internet, a >>> policy that defines the target of allocations/assignments of >>> IPv4 >>> address space to be late comers would be appropriate in such >>> region. >>> This would allow availablilty of IPv4 address space for such >>> requirements for more years. >>> >>> Another example comes from difference in IPv6 deployment rate. >>> For a region where IPv6 deployment rate is low, measures may be >>> necessary to prolong IPv4 address life for the existing >>> business as >>> well as for new businesses until networks are IPv6 ready. Some >>> regions may have strong needs to secure IPv4 address space for >>> translators. >>> >>> A globally coordinated policy which addresses all the issues >>> listed >>> above to meet the needs for all RIR regions may result in >>> not solving >>> issues in any of the regions. >>> >>> 2) LIRs and stakeholders remain unprepared for the situation if >>> they are >>> not informed >>> >>> If LIRs and the community are uninformed of the exhaustion, >>> their >>> services and networks remain unprepared to face the >>> situation at the >>> time of exhaustion. >>> >>> [Objective of the proposal] >>> This proposal seeks to provide the following solutions to the >>> problems >>> listed above. >>> >>> 1) RIR community should be able to define their own regional >>> policies on >>> how to assign the last piece(s) of allocation block in order to >>> address their own regional issues during the exhaustion period. >>> >>> 2) RIRs should provide official projection of the date when LIRs >>> will be >>> able to receive the allocations under the current criteria. The >>> criteria should remain consistent until this date in order >>> to avoid >>> confusion. >>> >>> [Pros and Cons] >>> Pros: >>> + It allows each RIR community to define a policy on how to >>> distribute >>> the last piece(s) of allocations which best matches their >>> situation. >>> >>> + It helps LIR better informed of the date when they are able to >>> receive >>> allocations from RIRs under the current criteria and prepare >>> for the >>> event. >>> >>> Cons: >>> + Concerns could be raised about allocating a fixed size to all >>> RIRs, >>> that it artificially fastens the consumption rate of some RIR >>> regions. >>> However, its impact is kept to minimum by keeping the >>> allocation size >>> to a single /8 which makes merely 3-4 months difference. >>> >>> + Concerns could be raised that explicitly allowing regional >>> policies >>> will encourage RIR shopping. However, this should not happen >>> if the >>> requirements within each region is adequately reflected in >>> each RIR's >>> policy through PDP. RIR may also chose to add criteria to >>> prevent LIRs >>> from other regions submitting such requests. >>> >>> >>> Timetable for implementation: >>> Immediate after all 5 RIRs (and possibly ICANN) ratifies the 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. From owen at delong.com Fri Aug 17 12:16:06 2007 From: owen at delong.com (Owen DeLong) Date: Fri, 17 Aug 2007 09:16:06 -0700 Subject: [ppml] Policy Proposal: End Policy for IANA IPv4 allocations to RIRs In-Reply-To: <1D09261C-79D9-45B2-8494-F8AD1E1E6B3B@delong.com> References: <46C5BC8F.7090302@arin.net> <0BBD347F-1FC5-41D1-989D-69E09EA15A62@delong.com> <46C5C1F5.7020005@arin.net> <1D09261C-79D9-45B2-8494-F8AD1E1E6B3B@delong.com> Message-ID: On Aug 17, 2007, at 8:47 AM, Owen DeLong wrote: > DOH!!! Maybe you guys should set the Reply-to on those. ;-) > > Owen > > On Aug 17, 2007, at 8:42 AM, Member Services wrote: Apologies to the list... I though I was sending that just to Erika and following up to the list with a simple repost. Owen From info at arin.net Fri Aug 17 14:21:35 2007 From: info at arin.net (Member Services) Date: Fri, 17 Aug 2007 14:21:35 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines Message-ID: <46C5E72F.2080903@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: IPv6 Assignment Guidelines Author: Leo Bicknell Proposal Version: 1.0 Submission Date: 8/17/2007 Proposal type: new Policy term: permanent Policy statement: Replace the text in section 6.5.4.1 with the following text: LIR's may assign blocks in the range of /48 to /64 to end sites. All assignments made by LIR's should meet a minimum HD-Ratio of .25. * /64 - Site needing only a single subnet. * /60 - Site with 2-3 subnets initially. * /56 - Site with 4-7 subnets initially. * /52 - Site with 8-15 subnets initially. * /48 - Site with 16+ subnets initially. 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. LIR's do not need to issue all 5 sizes of prefixes as long as the HD-Ratio requirement is met. Rationale: The existing section 6.5.4.1 does not provide clear guidance on how large of a prefix to allocate to a site. This makes it difficult for LIR's to know they are in compliance with the rules, and makes it harder for ARIN staff to evaluate requests per the communities wishes. This policy is based on an HD Ratio of .25 for end sites. The following table may be useful: Prefix Size Number of Subnets Required in Use to Meet .25 ----------- ----------------- --------------------------- /64 1 1 /60 16 2 /56 256 4 /52 4096 8 /48 65536 16 It is believed this policy provides clear guidance while allowing LIR's to make generous allocations to their end-sites. Timetable for implementation: immediate for new requests, 2 year grace period for all existing assignments. From info at arin.net Fri Aug 17 14:21:57 2007 From: info at arin.net (Member Services) Date: Fri, 17 Aug 2007 14:21:57 -0400 Subject: [ppml] Policy Proposal: ISP to LIR Clarification Message-ID: <46C5E745.5050708@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: ISP to LIR Clarification Author: Leo Bicknell Proposal Version: 1.0 Submission Date: 8/17/2007 Proposal type: modify Policy term: permanent Policy statement: Replace all instances of the word "ISP" in the NRPM with the word "LIR" and replace all instances of the phrase "LIR/ISP" with "LIR", except for the following: * Leave section 2.4 unchanged. * Leave section 2.7 unchanged. * In section 4.1.1, replace "ISPs" with "requesters". * In section 4.2, also remove "Internet Service Providers". * Leave section 6.2.4 unchanged. * Leave section 6.3.4 unchanged. * In section 6.9, replace "ISPs and LIRs" with "LIRs" for all three occurrence. Rationale: The NRPM is inconsistent. The terms ISP and LIR are used interchangeably throughout the document, with the term ISP being predominant in the IPv4 sections and the term LIR being predominant in the IPv6 sections. The use of the term ISP poses two different problems: 1) The term has meaning outside of ARIN's policy. Multiple discussions on PPML have degenerated over people arguing what an ISP is with regards to policy when the reality is that the relationship is defined in the NRPM. As LIR has no meaning outside of policy this confusion will be removed. 2) The other four RIRs have standardized on LIR. This change will make it easier for those doing business with more than one LIR to use consistent terms. This change does not alter any policy, it merely makes the policy easier to understand. Timetable for implementation: immediate From info at arin.net Fri Aug 17 14:22:31 2007 From: info at arin.net (Member Services) Date: Fri, 17 Aug 2007 14:22:31 -0400 Subject: [ppml] Policy Proposal: IPv6 Policy Housekeeping Message-ID: <46C5E767.6010406@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: IPv6 Policy Housekeeping Author: Leo Bicknell Proposal Version: 1.0 Submission Date: 8/17/2007 Proposal type: modify Policy term: permanent Policy statement: Change A: Remove the text between the section 6 header and the section 6.1 header. Remove section 6.1 entirely. Update all subsequent sections to have new section numbers (6.[n-1]). Change B: Move the image in section 6.2 to section 2. Remove sections 6.2.1 to 6.2.6. Change C: Move section 6.2.7 to (new) section 2.8, subheading "IPv6". Create section 2.8, subheading "IPv4", containing the following text: In IPv4, utilization is the percentage of the address space allocated or assigned relative to the total address space. Change D: Move section 6.2.8 to (new) section 2.8. Move section 6.2.9 to (new) section 2.9. As this leaves section 6.2 empty, remove section 6.2. Update all subsequent sections to have new section numbers (6.[n-1]). Change E: Remove section 6.3. Update all subsequent sections to have new section numbers (6.[n-1]). Change F: Remove section 6.4.1. Update all subsequent sections to have new section numbers (6.4.[n-1]). Change G: Remove section 6.4.2. Update all subsequent sections to have new section numbers (6.4.[n-1]). Change H: Remove section 6.4.4. Change I: In section 6.5.1.1.d, replace the existing statement with the new statement: "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." Change J: Remove section 6.5.3 entirely. Update all subsequent sections to have new section numbers (6.5.[n-1]). Replace part of the text as (new) section 6.5.4.4: "All /56 and larger assignments to end sites are required to be registered either by the LIR or its subordinate ISPs in such a way that the RIR/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary." Change K: Section 6.5.8.2, add the following sentence to the end of the first paragraph: "An HD-Ratio of .94 must be met for all assignments larger than a /48." Add to the end of the second paragraph: "This reservation may be assigned to other organizations later, at ARIN's discretion." Change L: Section 6.5.8.3, add a sentence between the two existing sentences: "Justification will be determined based on the .94 HD-Ratio metric." Change M: Remove section 6.6. Update all subsequent sections to have new section numbers (6.[n-1]). Change N: Change the title of section 6.7 from "Appendix A: HD-Ratio" to "HD-Ratio". Change O: Remove section 6.8. Update all subsequent sections to have new section numbers (6.[n-1]). Rationale: When the IPv6 policy was passed, it was considered to be an "interim" policy, and it was intended to be similar in all 5 RIR's. Since that time it has become clear the policy is no longer interim (and proposal 2007-4 was passed to change just that) and it has also been modified separately in the different RIR's. It was brought to the ARIN AC's attention that there were a number of problems with "Section 6" of the NRPM as a result of this legacy: * The policy contained a large number of items that were not policy. * The policy contained a few items that were self contradictory. * The added text was redundant in some cases with existing text. * The policy was overly vague in a few areas, leaving ARIN staff to have to make interpretations of what the policy intended. * Policy changes made since the initial IPv6 policy was adopted have not always updated all of the relevant sections due to the complexity of section 6. The intent of these changes is not to change any existing policy, but rather to remove all non-policy items, and update any ambiguous items with the way that ARIN staff is currently interprets the policy. Change A: Not policy. Unnecessary. Confusing (policy is interim). Change B: Sections 6.2.1 to 6.2.6 are definitions that are already defined in section 2.1 to 2.7 Repeating them here is unnecessary. The picture is useful though, and should be moved to section 2 as part of the definitions. Change C: This is a definition item, and should be in the definition section. Also, the v4 versions should be defined at the same time. Change D: These are both definitions that should be in the definitions section. Change E: This is a manifesto, and is not address policy. If anything these belong is ARIN's mission statement. Change F: Not policy; covered by the RSA as a legal matter. Change G: Not policy. A darn good warning though ARIN should include with any other boilerplate when issuing address space. Change H: Not policy, and covered by actual policy statement 6.5.1.2. Change I: Proposal 2005-8 amended section 6.5.4.1 to allow /56 and /64 allocations, but section 6.5.1.1.d was never updated to match the change. It is believed the intent of the policy, and ARIN staff's current interpretation of the policy match the updated text. Change J: The first part is not policy, and incorrectly states there is no policy as section 6.5.4 has the policy in it. Take the one useful part and make it part of the 6.5.4 criteria. Change K: No metric is currently listed to justify a larger initial assignment. It is believed ARIN staff is currently applying the HD-Ratio similar to the ISP policy, this puts that in writing. Make it clear that the reservation may not exist in perpetuity. Change L: No metric is given to justify additional assignments. It is believed that ARIN staff is currently applying the HD_Ratio similar to the ISP policy, this puts that in writing. Change M: References, while useful on the web page and in template instructions are not policy. Change N: It's not an appendix. It's not even at the end. Change O: The background information would be something nice to archive on the ARIN web site somewhere, but is not policy and should be removed from the policy manual. Timetable for implementation: Immediate. From randy at psg.com Fri Aug 17 14:27:00 2007 From: randy at psg.com (Randy Bush) Date: Fri, 17 Aug 2007 08:27:00 -1000 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <46C5E72F.2080903@arin.net> References: <46C5E72F.2080903@arin.net> Message-ID: <46C5E874.8050501@psg.com> > LIR's may assign blocks in the range of /48 to /64 to end sites. > All assignments made by LIR's should meet a minimum HD-Ratio of .25. > > * /64 - Site needing only a single subnet. > * /60 - Site with 2-3 subnets initially. > * /56 - Site with 4-7 subnets initially. > * /52 - Site with 8-15 subnets initially. > * /48 - Site with 16+ subnets initially. i am confused. is this telling isps what they must allocate to a customer? randy From jeroen at unfix.org Fri Aug 17 14:33:47 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 17 Aug 2007 19:33:47 +0100 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <46C5E72F.2080903@arin.net> References: <46C5E72F.2080903@arin.net> Message-ID: <46C5EA0B.3030304@spaghetti.zurich.ibm.com> Member Services wrote: [..] > LIR's may assign blocks in the range of /48 to /64 to end sites. > All assignments made by LIR's should meet a minimum HD-Ratio of .25. > > * /64 - Site needing only a single subnet. > * /60 - Site with 2-3 subnets initially. > * /56 - Site with 4-7 subnets initially. > * /52 - Site with 8-15 subnets initially. > * /48 - Site with 16+ subnets initially. I like the idea, but please don't make it too complex. The whole idea of having a /48 "everywhere" was to make moving around and avoiding renumbering at least the numberplan, easy. As such, please only keep it to: * /64 - Site really ever needing only a single subnet (eg a colo link). * /56 - Site with a low number of subnets (eg a residential user) * /48 - Site with a high number of subnets (eg a business/organization) Though a /64 should IMHO *NEVER* be given to an endsite and only be used in cases of colo facilities. If /64s are going to be made available to ISPs for assignment to endusers one can be sure that they will be playing the "IP addresses are expensive, if you need more IP addresses you will need to buy the businesses package and thus pay loads of money". ISPs should charge for bandwidth consumption, just like their transits are charging them. IMHO an ISP which is forcing users to get a business package aka pay a much higher fee because the user requires more addresses/subnets than provided normally, should be barred from any of the RIRs. Any ISP who is able to fill up a /32 worth of users should easily be able to afford the teeny bit of extra cost associated with getting a larger prefix from their RIR. Thus I state again: charge for bandwidth usage, not for the size of the prefix. The /56 is perfect for residential sites aka Joe Average HomeUser. The /48 should IMHO be provided to 'businesses' and other such organizations. If this setup can be unified around the world, or at least in the RIRs and ISPs adhere to it then the only tricky part of renumbering will be keeping a list where one stores IP addresses, and then getting the first couple of octets changed, at least one won't have to redesign the network as one used a subnet which one now suddenly can't get anymore. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From tedm at ipinc.net Fri Aug 17 14:40:33 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 17 Aug 2007 11:40:33 -0700 Subject: [ppml] Policy Proposal: End Policy for IANA IPv4 allocations toRIRs In-Reply-To: Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Owen DeLong >Sent: Friday, August 17, 2007 9:16 AM >To: Owen DeLong >Cc: Public Policy Mailing List >Subject: Re: [ppml] Policy Proposal: End Policy for IANA IPv4 >allocations toRIRs > > >Apologies to the list... I though I was sending that just to Erika >and following up to the list with a simple repost. At least you wern't advertising free kitens.... ;-) Ted From tedm at ipinc.net Fri Aug 17 14:59:02 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 17 Aug 2007 11:59:02 -0700 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: <79664833-061A-4A66-B9C6-3252B51CEA81@icann.org> Message-ID: >-----Original Message----- >From: Leo Vegoda [mailto:leo.vegoda at icann.org] >Sent: Friday, August 17, 2007 2:18 AM >To: Ted Mittelstaedt >Cc: David Conrad; Public Policy Mailing List >Subject: Re: [ppml] Policy Proposal: Expand timeframe of Additional >Requests > > >On 17 Aug 2007, at 03:03, Ted Mittelstaedt wrote: > >[...] > >> But I just cannnot see how you could make such a thing happen for >> IPv4 sales without running afoul of a lot of policy and assumptions >> that people have made so far. The utilization requirements for >> one thing - how can a hoarder operate without having a large stockpile >> of unused numbers, and how can they get this without lying - unless >> they were a legacy holder - in which case the legacy holders sell >> off their holdings and ARIN forces the "buyers" to sign an RSA and >> meat utilization requirements, or >> the legacy holders attempt to "rent" the IP's out while not changing >> the whois data - which ruins whois, and thus provides incentives for >> the community to just drop recording of legacy IPv4 blocks in the >> public records. > >You're assuming that they wouldn't want to change the data in whois >to show that their 'tenant' is responsible for the network in >question. No, not the issue. The issue is even if the whois records are changed, they can only be changed to show the "hoarder" as making an allocation to the "purchaser" The control over the IP block still stays with the "hoarder" So if for example the "hoarder" fails to pay their ARIN bill and ARIN yanks the hoarder's IP addresses, the "purchaser" has absolutely no recourse and will lose their IP addressing. For that reason I would assume the "purchasers" would insist on going through the appropriate ARIN RSA and have the block responsibility moved to them. >As long as the 'freeholder' can reclaim the space when the >rent isn't paid there isn't a problem for them and they may well want >to update ARIN's whois server or their own rwhois server. > If the "purchaser" is willing to have that sort of arraingement then the entire transaction is nothing more than a standard, allowed, IP sub allocation of IP addresses and wouldn't be objectionable. In other words you have eliminated the concept of hoarding and selling IP addresses and replaced it with what is already legally going on - the process of ISP's making allocations of IP addresses to their customers. Since ISP's are in competition with each other, the concept of windfalls of selling blocks of IPv4 addresses for millions goes right out the window - because the "renter" could choose any number of ISPs out there to obtain IP addresses from. Of course, those IP numbers still show the "hoarder" as having ownership. Remember, ARIN fulfills IPv4 requests on a first-come, first served order. Post-IPv4, ARIN will still be accepting IPv4 requests. They will just be telling the requestors that they will have to wait until IPv4 is turned in. As IPv4 is turned it, when ARIN can fill a backorder for IPv4 they will. Thus, if a "purchaser" goes to ARIN and says "wonkulating gronkulators agreed to sign a statement saying they don't need a /17 of IPv4 anymore and I want you to give it to me" then ARIN will say "wait a minute - there's other requests in line in front of you. If Wonkulating Gronkulators has freed up a /17 of IPv4 then great - but it's going to be given to the guy that has been waiting ahead of you for IPv4" Thus without ARIN approval I don't see how an "ebay market for IPv4" can exist that would allow responsibility for blocks to be passed between organizations, when there are people waiting in line for IPv4. Ted From bicknell at ufp.org Fri Aug 17 15:16:39 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 17 Aug 2007 15:16:39 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <46C5E874.8050501@psg.com> References: <46C5E72F.2080903@arin.net> <46C5E874.8050501@psg.com> Message-ID: <20070817191639.GC92950@ussenterprise.ufp.org> In a message written on Fri, Aug 17, 2007 at 08:27:00AM -1000, Randy Bush wrote: > > All assignments made by LIR's should meet a minimum HD-Ratio of .25. > > i am confused. is this telling isps what they must allocate to a customer? I am saying they must meet an HD-Ratio of .25 or higher on all allocations. The ISP can choose what to allocate in the range of HD-Ratio .25 - 1. How is that not clear? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From bicknell at ufp.org Fri Aug 17 15:20:28 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 17 Aug 2007 15:20:28 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <46C5EA0B.3030304@spaghetti.zurich.ibm.com> References: <46C5E72F.2080903@arin.net> <46C5EA0B.3030304@spaghetti.zurich.ibm.com> Message-ID: <20070817192028.GD92950@ussenterprise.ufp.org> In a message written on Fri, Aug 17, 2007 at 07:33:47PM +0100, Jeroen Massar wrote: > As such, please only keep it to: > * /64 - Site really ever needing only a single subnet (eg a colo link). > * /56 - Site with a low number of subnets (eg a residential user) > * /48 - Site with a high number of subnets (eg a business/organization) Here's the problem. When a provider comes back to ask for more IPv6 space, or is audited, or even puts in their intial request how is ARIN staff supposed to evaluate "a low number" of subnets. Is that 2? 50? 50,000? The current policy has two problems. 1) It states the sizes are only a guideline. Thus ARIN staff is pretty much forced to accept a /48 for everything, including a dial-up PC. 2) The current policy, even if it were not a guideline, uses the same vague langugage. I thought an HD-Ratio of .25 was generous, however if the community wants it to be .10, or .01 I'm fine with that too. I just feel strongly that ARIN staff be given a measureable critera rather than a amazingly vague "guideline". -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From bicknell at ufp.org Fri Aug 17 15:25:04 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 17 Aug 2007 15:25:04 -0400 Subject: [ppml] Policy Proposal: IPv6 Policy Housekeeping In-Reply-To: <46C5E767.6010406@arin.net> References: <46C5E767.6010406@arin.net> Message-ID: <20070817192504.GE92950@ussenterprise.ufp.org> There has been a lot of back channel discussion before I submitted this policy, and I want to bring PPML into the loop. This started out as a clean up effort, taking care of issues that don't affect policy but simply make the NRPM more confusing. The goal was not to change any policy. Along the way we ran into a number of ambiguous items that needed to be clarified. For some ARIN staff has some experience and has some sort of de facto policy since the written text is not clear. For others, since this is IPv6, the situations really haven't come up yet. I attempted to write clarifications matching the de facto policy and/or by trying to be as bland and uncontroversial as possible. Again, the goal was not to make new policy, but it really became necessary to a degree to make things fully make sense. If there are controversial items I'm inclined to pull those out, leaving this policy to be the non-controversial edits. Any items we pull out could be addressed in the future on a case by case basis by other policy proposals. Your comments on this matter are greatly appreciated. -- 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 Aug 17 16:12:50 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 17 Aug 2007 21:12:50 +0100 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <46C5E874.8050501@psg.com> References: <46C5E72F.2080903@arin.net> <46C5E874.8050501@psg.com> Message-ID: > > LIR's may assign blocks in the range of /48 to /64 to end sites. > > All assignments made by LIR's should meet a minimum HD-Ratio of .25. > > > > * /64 - Site needing only a single subnet. > > * /60 - Site with 2-3 subnets initially. > > * /56 - Site with 4-7 subnets initially. > > * /52 - Site with 8-15 subnets initially. > > * /48 - Site with 16+ subnets initially. > > i am confused. is this telling isps what they must allocate > to a customer? Yes. It seems that IPv6 addresses are scarce resources which must be carefully managed. Or perhaps it is another example of IPv4 thinking being applied where it is not needed. --Michael Dillon From bicknell at ufp.org Fri Aug 17 16:35:00 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 17 Aug 2007 16:35:00 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: References: <46C5E72F.2080903@arin.net> <46C5E874.8050501@psg.com> Message-ID: <20070817203500.GA629@ussenterprise.ufp.org> In a message written on Fri, Aug 17, 2007 at 09:12:50PM +0100, michael.dillon at bt.com wrote: > Yes. It seems that IPv6 addresses are scarce resources which must be > carefully managed. > > Or perhaps it is another example of IPv4 thinking being applied where it > is not needed. I am happy to amend the proposal to be "may assign a /48 to every site" (heck, make it a /32 for every site) if that's what the community wants. Incidently, this is the only way I can see ARIN staff really standing on the current policy, since what is in the NRPM is "here are guidelines". Back to my original point, all I care is that ARIN staff have solid guidelines. Since we use HD Ratio everywhere else in IPv6 policy I used that hammer and set the bar at .25. I thought allowing a site that needed only 16 subnets to have 65,536 was within IPv6's spirit of "enough address to last forever". -- 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 marla.azinger at frontiercorp.com Fri Aug 17 16:39:12 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Fri, 17 Aug 2007 16:39:12 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4C832@nyrofcs2ke2k01.corp.pvt> I remember when IPv4 was thought to be plenty as well. I understand the view of conservation with IPv6 being hard to swallow this early, but I'd rather learn from history opposed to repeating it. Cheers! Marla -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of michael.dillon at bt.com Sent: Friday, August 17, 2007 1:13 PM To: ppml at arin.net Subject: Re: [ppml] Policy Proposal: IPv6 Assignment Guidelines > > LIR's may assign blocks in the range of /48 to /64 to end sites. > > All assignments made by LIR's should meet a minimum HD-Ratio of .25. > > > > * /64 - Site needing only a single subnet. > > * /60 - Site with 2-3 subnets initially. > > * /56 - Site with 4-7 subnets initially. > > * /52 - Site with 8-15 subnets initially. > > * /48 - Site with 16+ subnets initially. > > i am confused. is this telling isps what they must allocate > to a customer? Yes. It seems that IPv6 addresses are scarce resources which must be carefully managed. Or perhaps it is another example of IPv4 thinking being applied where it is not needed. --Michael Dillon _______________________________________________ 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 michael.dillon at bt.com Fri Aug 17 16:51:16 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 17 Aug 2007 21:51:16 +0100 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A02A4C832@nyrofcs2ke2k01.corp.pvt> References: <454810F09B5AA04E9D78D13A5C39028A02A4C832@nyrofcs2ke2k01.corp.pvt> Message-ID: > I remember when IPv4 was thought to be plenty as well. I > understand the view of conservation with IPv6 being hard to > swallow this early, but I'd rather learn from history opposed > to repeating it. Yes, I too would like to learn from history. With IPv4, the question of "plenty" was a question of opinion. With IPv6, it is a question of mathematics. There is no shortage of IPv6 addresses and if the world ever does run out of IPv6 addresses, we will all be dead when it happens. I am glad to bequeath a tough technical problem to my descendants to save them from the boredom of a life in the machine. The lesson of history is that the introduction of VLSM and CIDR made life a lot harder for everybody in numerous ways. With IPv6 we have the possibility to have a simple and clean system where every building or campus or office connected to the network has the same size address prefix. Moving a network to another point in the topology only requires changing the prefix, not redoing subnet architecture and total readdressing. I can live with a two-tiered scheme in which all consumer homes have a /56 and all non-consumer sites have a /48 because sites rarely will switch categories. --Michael Dillon From bmanning at vacation.karoshi.com Fri Aug 17 17:19:05 2007 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 17 Aug 2007 21:19:05 +0000 Subject: [ppml] [Re: IPv6 addresses really are scarce after all] Message-ID: <20070817211905.GA12791@vacation.karoshi.com.> anyone have any idea on a viable distribution method OTHER THAN need? --bill ----- Forwarded message from Bill Manning ----- Date: Fri, 17 Aug 2007 14:10:10 -0700 To: michael.dillon at bt.com Cc: ietf at ietf.org Subject: Re: IPv6 addresses really are scarce after all Michael Dillon sez: "ARIN ... belives IPv6 addresses are ... resources that need to be [distributed] according to need." I guess I have to agree with this sentiment. If the ARIN community decides there is a better way to distribute IP addresses *OTHER THAN* need, I'd be really happy to hear what that method would be. --bill On Fri, Aug 17, 2007 at 09:08:43PM +0100, michael.dillon at bt.com wrote: > > It seems that someone in ARIN land believes that IPv6 addresses are > scarce resources that need to be carefully dribbled out to customers > according to need. The following proposal has just been formally made to > change ARIN's allocation policy. > > ------start of copied text------ > > Replace the text in section 6.5.4.1 with the following text: > > LIR's may assign blocks in the range of /48 to /64 to end sites. > All assignments made by LIR's should meet a minimum HD-Ratio of .25. > > * /64 - Site needing only a single subnet. > * /60 - Site with 2-3 subnets initially. > * /56 - Site with 4-7 subnets initially. > * /52 - Site with 8-15 subnets initially. > * /48 - Site with 16+ subnets initially. > > 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. > > LIR's do not need to issue all 5 sizes of prefixes as long as the > HD-Ratio requirement is met. > > ------end of copied text------ > > --Michael Dillon > --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ----- End forwarded message ----- From steveb at eagle.ca Fri Aug 17 17:24:01 2007 From: steveb at eagle.ca (Steve Bertrand) Date: Fri, 17 Aug 2007 17:24:01 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: References: <454810F09B5AA04E9D78D13A5C39028A02A4C832@nyrofcs2ke2k01.corp.pvt> Message-ID: <46C611F1.6030506@eagle.ca> > There is no shortage of IPv6 addresses and if the world > ever does run out of IPv6 addresses, we will all be dead when it > happens. Although there is no shortage, I disagree in principle. While I agree a two-tiered system would probably be best, assuming that we will never run out if IPv6 addresses is like saying nobody will need more than 640K. Nobody knows what the future holds, and being reasonably conservative at the beginning will only help later. What happens if someone implements something in the stack that would allow a device on a network to iterate through a billion addresses randomly every few minutes, with the ability to notify it's important peers to be able to avoid security threats? What if every single IP enabled device on the planet did this? I don't believe in never say never. As far as passing it to our descendants, they are going to have enough to deal with in the environment alone. > I can live with a two-tiered scheme in which all consumer > homes have a /56 and all non-consumer sites have a /48 because sites > rarely will switch categories. I support the previous statement. Clean and easy. Steve From drc at virtualized.org Fri Aug 17 17:34:41 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 17 Aug 2007 14:34:41 -0700 Subject: [ppml] [Re: IPv6 addresses really are scarce after all] In-Reply-To: <20070817211905.GA12791@vacation.karoshi.com.> References: <20070817211905.GA12791@vacation.karoshi.com.> Message-ID: <825A85CC-15E6-4A0D-B5D8-13843F0CF387@virtualized.org> Bill, Please define "viable". There are a large number of potential distribution models that could be applied depending on that definition. Regards, -drc On Aug 17, 2007, at 2:19 PM, bmanning at vacation.karoshi.com wrote: > > anyone have any idea on a viable distribution method > OTHER THAN need? > > --bill > > ----- Forwarded message from Bill Manning ----- > > Date: Fri, 17 Aug 2007 14:10:10 -0700 > To: michael.dillon at bt.com > Cc: ietf at ietf.org > Subject: Re: IPv6 addresses really are scarce after all > > Michael Dillon sez: > > "ARIN ... belives IPv6 addresses are ... resources that need to be > [distributed] according to need." > > I guess I have to agree with this sentiment. If the ARIN community > decides there is a better way to distribute IP addresses *OTHER THAN* > need, I'd be really happy to hear what that method would be. > > --bill > > > On Fri, Aug 17, 2007 at 09:08:43PM +0100, michael.dillon at bt.com wrote: >> >> It seems that someone in ARIN land believes that IPv6 addresses are >> scarce resources that need to be carefully dribbled out to customers >> according to need. The following proposal has just been formally >> made to >> change ARIN's allocation policy. >> >> ------start of copied text------ >> >> Replace the text in section 6.5.4.1 with the following text: >> >> LIR's may assign blocks in the range of /48 to /64 to end sites. >> All assignments made by LIR's should meet a minimum HD-Ratio of .25. >> >> * /64 - Site needing only a single subnet. >> * /60 - Site with 2-3 subnets initially. >> * /56 - Site with 4-7 subnets initially. >> * /52 - Site with 8-15 subnets initially. >> * /48 - Site with 16+ subnets initially. >> >> 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. >> >> LIR's do not need to issue all 5 sizes of prefixes as long as the >> HD-Ratio requirement is met. >> >> ------end of copied text------ >> >> --Michael Dillon >> > > --bill > > Opinions expressed may not even be mine by the time you read them, and > certainly don't reflect those of any other entity (legal or > otherwise). > > ----- End forwarded message ----- > _______________________________________________ > 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 bmanning at vacation.karoshi.com Fri Aug 17 17:37:41 2007 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 17 Aug 2007 21:37:41 +0000 Subject: [ppml] [Re: IPv6 addresses really are scarce after all] In-Reply-To: <825A85CC-15E6-4A0D-B5D8-13843F0CF387@virtualized.org> References: <20070817211905.GA12791@vacation.karoshi.com.> <825A85CC-15E6-4A0D-B5D8-13843F0CF387@virtualized.org> Message-ID: <20070817213741.GB12791@vacation.karoshi.com.> viable == can actually work in practice. please define "large number" - I don't need the whole list, but the top ten would be a good start. One might then ask the ARIN community which they prefer over need-based delegation --bill On Fri, Aug 17, 2007 at 02:34:41PM -0700, David Conrad wrote: > Bill, > > Please define "viable". > > There are a large number of potential distribution models that could > be applied depending on that definition. > > Regards, > -drc > > On Aug 17, 2007, at 2:19 PM, bmanning at vacation.karoshi.com wrote: > > > > anyone have any idea on a viable distribution method > > OTHER THAN need? > > > >--bill > > > >----- Forwarded message from Bill Manning ----- > > > >Date: Fri, 17 Aug 2007 14:10:10 -0700 > >To: michael.dillon at bt.com > >Cc: ietf at ietf.org > >Subject: Re: IPv6 addresses really are scarce after all > > > > Michael Dillon sez: > > > >"ARIN ... belives IPv6 addresses are ... resources that need to be > >[distributed] according to need." > > > >I guess I have to agree with this sentiment. If the ARIN community > >decides there is a better way to distribute IP addresses *OTHER THAN* > >need, I'd be really happy to hear what that method would be. > > > >--bill > > > > > >On Fri, Aug 17, 2007 at 09:08:43PM +0100, michael.dillon at bt.com wrote: > >> > >>It seems that someone in ARIN land believes that IPv6 addresses are > >>scarce resources that need to be carefully dribbled out to customers > >>according to need. The following proposal has just been formally > >>made to > >>change ARIN's allocation policy. > >> > >>------start of copied text------ > >> > >>Replace the text in section 6.5.4.1 with the following text: > >> > >>LIR's may assign blocks in the range of /48 to /64 to end sites. > >>All assignments made by LIR's should meet a minimum HD-Ratio of .25. > >> > >>* /64 - Site needing only a single subnet. > >>* /60 - Site with 2-3 subnets initially. > >>* /56 - Site with 4-7 subnets initially. > >>* /52 - Site with 8-15 subnets initially. > >>* /48 - Site with 16+ subnets initially. > >> > >>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. > >> > >>LIR's do not need to issue all 5 sizes of prefixes as long as the > >>HD-Ratio requirement is met. > >> > >>------end of copied text------ > >> > >>--Michael Dillon > >> > > > >--bill > > > >Opinions expressed may not even be mine by the time you read them, and > >certainly don't reflect those of any other entity (legal or > >otherwise). > > > >----- End forwarded message ----- > >_______________________________________________ > >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 kloch at kl.net Fri Aug 17 17:59:49 2007 From: kloch at kl.net (Kevin Loch) Date: Fri, 17 Aug 2007 17:59:49 -0400 Subject: [ppml] [Re: IPv6 addresses really are scarce after all] In-Reply-To: <825A85CC-15E6-4A0D-B5D8-13843F0CF387@virtualized.org> References: <20070817211905.GA12791@vacation.karoshi.com.> <825A85CC-15E6-4A0D-B5D8-13843F0CF387@virtualized.org> Message-ID: <46C61A55.4050307@kl.net> David Conrad wrote: > Bill, > > Please define "viable". > > There are a large number of potential distribution models that could > be applied depending on that definition. I can only think of 3: need greed lottery We're about to see what happens with v4 switching from need to greed. Let's see how that works out before thinking about changing v6. - Kevin From steveb at eagle.ca Fri Aug 17 18:12:45 2007 From: steveb at eagle.ca (Steve Bertrand) Date: Fri, 17 Aug 2007 18:12:45 -0400 Subject: [ppml] [Re: IPv6 addresses really are scarce after all] In-Reply-To: <46C61A55.4050307@kl.net> References: <20070817211905.GA12791@vacation.karoshi.com.> <825A85CC-15E6-4A0D-B5D8-13843F0CF387@virtualized.org> <46C61A55.4050307@kl.net> Message-ID: <46C61D5D.5040207@eagle.ca> > We're about to see what happens with v4 switching from need to greed. > Let's see how that works out before thinking about changing v6. IMHO, this may be backwards thinking. Let me explain my thoughts: We keep things as they are, waiting for impending D-Day of IPv4 runout, then decide to change policy and governance on handing out of IPv6 space. This may create a condition where we wouldn't have legacy holders (in the v4 sense), but it may arise that when policy does change, perhaps drastically after v4 runout, that there will be many, many organizations that have already received their v6, been paying existing rates (etc) that will then complain "that's not fair!". We'll be having this same discussion down the road, but with far more people who already have assignments to deal with that feel they did not get a 'fair deal'. There will be a scramble on v6 when v4 comes near it's end. Would this type of action and possible condition not put too much strain on the RIR's to keep focused on what they are supposed to be doing, as opposed to dealing with complaints? I believe that pro-active would be better than reactive. Steve From drc at virtualized.org Fri Aug 17 19:01:01 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 17 Aug 2007 16:01:01 -0700 Subject: [ppml] [Re: IPv6 addresses really are scarce after all] In-Reply-To: <20070817213741.GB12791@vacation.karoshi.com.> References: <20070817211905.GA12791@vacation.karoshi.com.> <825A85CC-15E6-4A0D-B5D8-13843F0CF387@virtualized.org> <20070817213741.GB12791@vacation.karoshi.com.> Message-ID: <0C2634E5-5173-4406-A646-C6971A0D19D0@virtualized.org> On Aug 17, 2007, at 2:37 PM, bmanning at vacation.karoshi.com wrote: > viable == can actually work in practice. Not a good definition. "Can actually work in practice" for whom? Sparse allocation of /48s on demand to anyone willing to pay a yearly registration fee is a perfectly viable distribution model. Allocating /12s to national PTT or equivalents in each country on the planet and letting them deal with allocations in country is a perfectly viable distribution model. Auctioning space to the highest bidder is a perfectly viable distribution model. Etc. All of these "work in practice". What is most likely _not_ going to work in practice is allocating blocks to ISPs and requiring all enterprises obtain PA address space from those ISPs. Given the liberalization of PI policies either implemented or being discussed in all the RIRs, this would appear to be understood. Regards, -drc From bmanning at vacation.karoshi.com Fri Aug 17 19:26:33 2007 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 17 Aug 2007 23:26:33 +0000 Subject: [ppml] [Re: IPv6 addresses really are scarce after all] In-Reply-To: <0C2634E5-5173-4406-A646-C6971A0D19D0@virtualized.org> References: <20070817211905.GA12791@vacation.karoshi.com.> <825A85CC-15E6-4A0D-B5D8-13843F0CF387@virtualized.org> <20070817213741.GB12791@vacation.karoshi.com.> <0C2634E5-5173-4406-A646-C6971A0D19D0@virtualized.org> Message-ID: <20070817232633.GA13690@vacation.karoshi.com.> On Fri, Aug 17, 2007 at 04:01:01PM -0700, David Conrad wrote: > On Aug 17, 2007, at 2:37 PM, bmanning at vacation.karoshi.com wrote: > > viable == can actually work in practice. > > Not a good definition. "Can actually work in practice" for whom? good for whom? :) perhaps the distribution method should be tempered by a caveat that the IP addresses so distributed would be used for their "best and highest" use - which in my mind is to be used for sourcing/sinking IP datagrams > Sparse allocation of /48s on demand to anyone willing to pay a yearly > registration fee is a perfectly viable distribution model. i'm ok w/ that - on the presumption that "anyone" will be using the prefix to source/sink datagrams. > Allocating /12s to national PTT or equivalents in each country on the > planet and letting them deal with allocations in country is a > perfectly viable distribution model. ok... but will temper this w/ the concern that PPT or equivalents tend to focus on fiscal gain over productive use. > Auctioning space to the highest bidder is a perfectly viable > distribution model. which begs the question of the value basis. if the IP space is treated as commodity - then is it being put to best use? all these varients are distribution based on available cash - completely abandoning the historical basis of need. or perhaps redefining need? to borrow from an earlier posting in this thread... these are all varients of the catagory *greed* as a distribution basis. i've heard three basis for distribution and raft of varients thereof. perhaps this si the "large number" that you refered to? > Etc. > > All of these "work in practice". > > What is most likely _not_ going to work in practice is allocating > blocks to ISPs and requiring all enterprises obtain PA address space > from those ISPs. Given the liberalization of PI policies either > implemented or being discussed in all the RIRs, this would appear to > be understood. so the IETF architectural model (PA) is flawed in practice and the RIR community is coping by discussing/adopting varients (PI). The fundamental underpinnings of PI are still need/merit based and not on some uncertain "market" valuation. (as described above). Do you think that the ARIN community will be happy with any of the distribution varients you list above? --bill > > Regards, > -drc From sleibrand at internap.com Fri Aug 17 21:39:17 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 17 Aug 2007 18:39:17 -0700 Subject: [ppml] Policy Proposal: End Policy for IANA IPv4 allocations to RIRs In-Reply-To: <46C5BC8F.7090302@arin.net> References: <46C5BC8F.7090302@arin.net> Message-ID: <46C64DC5.90009@internap.com> This seems like a reasonably fair way to exhaust the IANA free pool of IPv4 addresses. I would support this proposal. -Scott 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: End Policy for IANA IPv4 allocations to RIRs > > Author: JPNIC IPv4 countdown policy team; > Akinori MAEMURA > Akira NAKAGAWA > Izumi OKUTANI > Kosuke ITO > Kuniaki KONDO > Shuji NAKAMURA > Susumu SATO > Takashi ARANO > Tomohiro FUJISAKI > Tomoya YOSHIDA > Toshiyuki HOSAKA > > Proposal Version: 2 > > Submission Date: 2007/08/17 > > Proposal type: new > > Policy term:renewable > > Policy statement: > > 1) Distribute a single /8 to each RIR at the point when new IANA free > pool hits 5 */8. This date is defined as "IANA Exhaustion Date". > > 2) It should be completely left up to each RIR communities to define a > regional policy on how to distribute the remaining RIR free pool to > LIRs within their respective regions after "IANA Exhaustion Date". > > Note 1: It is fine for an RIR to continue operations with the > existing policy if that is the consensus decision of the > respective RIR community. > > Note 2: Address recovery and re-distribution of recovered address > space is another important measure for considerations, but > should be treated as a separate policy proposal from > distribution of new IANA pool. > > 3) RIRs should provide an official projection on IANA Exhaustion Date > to the community through their website, at their Policy Meetings > and through any other effective means. > > > Rationale: > [current problem] > There are two major issues in terms of address management if no measures > are taken for IPv4 address exhaustion. > > 1) Continue applying a global coordinated policy for distribution of the > last piece(s) of RIR's unallocated address block does not match the > reality of the situation in each RIR region. > > Issues each RIR region will face during the exhaustion period vary by > region as the level of development of IPv4 and IPv6 are widely > different. As a result, applying a global co-ordinated policy may not > adequately address issues in a certain region while it could be work > for the others. > > For example, in a region where late comers desperately need even > small blocks of IPv4 addresses to access to the IPv4 Internet, a > policy that defines the target of allocations/assignments of IPv4 > address space to be late comers would be appropriate in such region. > This would allow availablilty of IPv4 address space for such > requirements for more years. > > Another example comes from difference in IPv6 deployment rate. > For a region where IPv6 deployment rate is low, measures may be > necessary to prolong IPv4 address life for the existing business as > well as for new businesses until networks are IPv6 ready. Some > regions may have strong needs to secure IPv4 address space for > translators. > > A globally coordinated policy which addresses all the issues listed > above to meet the needs for all RIR regions may result in not solving > issues in any of the regions. > > 2) LIRs and stakeholders remain unprepared for the situation if they are > not informed > > If LIRs and the community are uninformed of the exhaustion, their > services and networks remain unprepared to face the situation at the > time of exhaustion. > > [Objective of the proposal] > This proposal seeks to provide the following solutions to the problems > listed above. > > 1) RIR community should be able to define their own regional policies on > how to assign the last piece(s) of allocation block in order to > address their own regional issues during the exhaustion period. > > 2) RIRs should provide official projection of the date when LIRs will be > able to receive the allocations under the current criteria. The > criteria should remain consistent until this date in order to avoid > confusion. > > [Pros and Cons] > Pros: > + It allows each RIR community to define a policy on how to distribute > the last piece(s) of allocations which best matches their situation. > > + It helps LIR better informed of the date when they are able to receive > allocations from RIRs under the current criteria and prepare for the > event. > > Cons: > + Concerns could be raised about allocating a fixed size to all RIRs, > that it artificially fastens the consumption rate of some RIR regions. > However, its impact is kept to minimum by keeping the allocation size > to a single /8 which makes merely 3-4 months difference. > > + Concerns could be raised that explicitly allowing regional policies > will encourage RIR shopping. However, this should not happen if the > requirements within each region is adequately reflected in each RIR's > policy through PDP. RIR may also chose to add criteria to prevent LIRs > from other regions submitting such requests. > > > Timetable for implementation: > Immediate after all 5 RIRs (and possibly ICANN) ratifies the 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. > From drc at virtualized.org Fri Aug 17 21:42:41 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 17 Aug 2007 18:42:41 -0700 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <46C611F1.6030506@eagle.ca> References: <454810F09B5AA04E9D78D13A5C39028A02A4C832@nyrofcs2ke2k01.corp.pvt> <46C611F1.6030506@eagle.ca> Message-ID: Steve, On Aug 17, 2007, at 2:24 PM, Steve Bertrand wrote: >> There is no shortage of IPv6 addresses and if the world >> ever does run out of IPv6 addresses, we will all be dead when it >> happens. Michael is right about one thing: we'll be dead because the Internet users of the world will unite and rightfully hunt us all down and kill us for being so inexcusably stupid as to burn through 2^128 addresses. :-) > What happens if someone implements something in the stack that would > allow a device on a network to iterate through a billion addresses > randomly every few minutes I think you're not really grasping the magnitude of 128 bits of address space. If you cycle through 1,000,000,000 addresses every "few" minutes (where few = 3), it will take over 105,000+ years to exhaust a single /64. > What if every single IP enabled device on the planet did this? Assume 7 billion people. Each person could have 2,635,249,153 IP enabled devices, cycling every 105,000+ years. The point of this meaningless exercise is that it is pretty hard to come up with a rational way to burn through 128 bits of address space. However, people are finding interesting ways to be irrational. Discussions about the length of assignments are largely pointless. Even if the RIRs all went back to the IETF addressing "architecture" (to use the word _very_ loosely) and allocated /48s to enterprises, there are a total of 35 trillion /48s in the IPv6 address space in the 1/8th of the address space the IETF has designated for unicast. This works out to over 5000 "enterprises" per person (again, assuming 7 billion people). The real problem isn't IPv6 address exhaustion, it is the risk of overwhelming the routing system. I would worry that allocating longer prefixes under the theory that it is less wasteful of address space might increase the chances that those longer prefixes would show up in the routing system. Regards, -drc From terry.l.davis at boeing.com Fri Aug 17 21:58:47 2007 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Fri, 17 Aug 2007 18:58:47 -0700 Subject: [ppml] [Re: IPv6 addresses really are scarce after all] In-Reply-To: <20070817232633.GA13690@vacation.karoshi.com.> References: <20070817211905.GA12791@vacation.karoshi.com.><825A85CC-15E6-4A0D-B5D8-13843F0CF387@virtualized.org><20070817213741.GB12791@vacation.karoshi.com.><0C2634E5-5173-4406-A646-C6971A0D19D0@virtualized.org> <20070817232633.GA13690@vacation.karoshi.com.> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A03685AB4@XCH-NW-8V1.nw.nos.boeing.com> Bill/David I do sense that there is growing understanding that the requirement for businesses or critical infrastructure providers to obtain their v6 addresses from their ISP, will not work in the real world. I think I hear that everyone is still looking for a fair allocation method that will have some basis in an entity's real need for address space. I hope that remains as an underlying goal. I do hope that national allocations to government are not seriously considered. Some of my concerns here would include: - The potential for there to wide disparity in the allocation methods each nation would implement that could fragment the Internet, even impacting end-to-end connectivity. - Disparate allocation rules that could seriously impact global trade, international business, and potentially global financial networks. - National allocation policies that could potentially change with every election/government change. Take care Terry > -----Original Message----- > From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] > Sent: Friday, August 17, 2007 4:27 PM > To: David Conrad > Cc: bmanning at vacation.karoshi.com; ppml at arin.net > Subject: Re: [ppml] [Re: IPv6 addresses really are scarce after all] > > On Fri, Aug 17, 2007 at 04:01:01PM -0700, David Conrad wrote: > > On Aug 17, 2007, at 2:37 PM, bmanning at vacation.karoshi.com wrote: > > > viable == can actually work in practice. > > > > Not a good definition. "Can actually work in practice" for whom? > > good for whom? :) perhaps the distribution method should > be tempered by a caveat that the IP addresses so distributed > would be used for their "best and highest" use - which in my > mind is to be used for sourcing/sinking IP datagrams > > > Sparse allocation of /48s on demand to anyone willing to pay a yearly > > registration fee is a perfectly viable distribution model. > > i'm ok w/ that - on the presumption that "anyone" will > be using the prefix to source/sink datagrams. > > > > Allocating /12s to national PTT or equivalents in each country on the > > planet and letting them deal with allocations in country is a > > perfectly viable distribution model. > > ok... but will temper this w/ the concern that PPT or equivalents > tend to focus on fiscal gain over productive use. > > > Auctioning space to the highest bidder is a perfectly viable > > distribution model. > > which begs the question of the value basis. if the IP space is > treated as commodity - then is it being put to best use? > > > all these varients are distribution based on available cash - completely > abandoning the historical basis of need. or perhaps redefining need? > > to borrow from an earlier posting in this thread... these are all varients > of the catagory *greed* as a distribution basis. > > i've heard three basis for distribution and raft of varients thereof. > perhaps this si the "large number" that you refered to? > > > Etc. > > > > All of these "work in practice". > > > > What is most likely _not_ going to work in practice is allocating > > blocks to ISPs and requiring all enterprises obtain PA address space > > from those ISPs. Given the liberalization of PI policies either > > implemented or being discussed in all the RIRs, this would appear to > > be understood. > > so the IETF architectural model (PA) is flawed in practice and the > RIR community is coping by discussing/adopting varients (PI). > The fundamental underpinnings of PI are still need/merit based and > not on some uncertain "market" valuation. (as described above). > > Do you think that the ARIN community will be happy with any of the > distribution varients you list above? > > --bill > > > > Regards, > > -drc > _______________________________________________ > 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 randy at psg.com Fri Aug 17 22:11:55 2007 From: randy at psg.com (Randy Bush) Date: Fri, 17 Aug 2007 16:11:55 -1000 Subject: [ppml] [Re: IPv6 addresses really are scarce after all] In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A03685AB4@XCH-NW-8V1.nw.nos.boeing.com> References: <20070817211905.GA12791@vacation.karoshi.com.><825A85CC-15E6-4A0D-B5D8-13843F0CF387@virtualized.org><20070817213741.GB12791@vacation.karoshi.com.><0C2634E5-5173-4406-A646-C6971A0D19D0@virtualized.org> <20070817232633.GA13690@vacation.karoshi.com.> <0D090F1E0F5536449C7E6527AFFA280A03685AB4@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: <46C6556B.3060905@psg.com> > I do sense that there is growing understanding that the requirement for > businesses or critical infrastructure providers to obtain their v6 > addresses from their ISP, will not work in the real world. after all, it has been such a tragic failure in ipv4, seriously inhibiting the use of the internet. randy From drc at virtualized.org Fri Aug 17 22:16:55 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 17 Aug 2007 19:16:55 -0700 Subject: [ppml] [Re: IPv6 addresses really are scarce after all] In-Reply-To: <20070817232633.GA13690@vacation.karoshi.com.> References: <20070817211905.GA12791@vacation.karoshi.com.> <825A85CC-15E6-4A0D-B5D8-13843F0CF387@virtualized.org> <20070817213741.GB12791@vacation.karoshi.com.> <0C2634E5-5173-4406-A646-C6971A0D19D0@virtualized.org> <20070817232633.GA13690@vacation.karoshi.com.> Message-ID: Bill, On Aug 17, 2007, at 4:26 PM, bmanning at vacation.karoshi.com wrote: > to borrow from an earlier posting in this thread... these are all > varients of the catagory *greed* as a distribution basis. ... > so the IETF architectural model (PA) is flawed in practice and the > RIR community is coping by discussing/adopting varients (PI). The > fundamental underpinnings of PI are still need/merit based and not > on some uncertain "market" valuation. (as described above). Huh? - Sparse allocation of /48s on demand with a registration fee isn't market based and is no more "greed" based than how IPv4 was originally allocated. - Allocating /12 to national entities says nothing about how the national entities distribute the addresses (particularly since this doesn't presume the national entities are national monopolies). This isn't anymore "greed" based than the way telephone numbers are handed out. - Auctioning space to the highest bidder says nothing about how those bidders subsequently re-assign the address space (although one would assume the winning bidders would want to recoup their costs). This might be argued to be "greed" based, but the implication would be that the FCC was greedy in spectrum auctions (perish the thought!). None of these are market based. > Do you think that the ARIN community will be happy with any of the > distribution varients you list above? My telepathy powers are notoriously weak. People have privately told me the sparse allocation approach is appealing. Regards, -drc From sleibrand at internap.com Sat Aug 18 00:12:34 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 17 Aug 2007 21:12:34 -0700 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <46C5E72F.2080903@arin.net> References: <46C5E72F.2080903@arin.net> Message-ID: <46C671B2.60800@internap.com> As expressed by others, I oppose this policy proposal as written, because I believe current guidelines are sufficient. ISPs should be free to delegate a /48 or /56 to users, as appropriate for their situation. I believe that any justification, including convenience, should be sufficient to allow allocation of a /48 instead of a smaller subnet. -Scott 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 Guidelines > > Author: Leo Bicknell > > Proposal Version: 1.0 > > Submission Date: 8/17/2007 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Replace the text in section 6.5.4.1 with the following text: > > LIR's may assign blocks in the range of /48 to /64 to end sites. > All assignments made by LIR's should meet a minimum HD-Ratio of .25. > > * /64 - Site needing only a single subnet. > * /60 - Site with 2-3 subnets initially. > * /56 - Site with 4-7 subnets initially. > * /52 - Site with 8-15 subnets initially. > * /48 - Site with 16+ subnets initially. > > 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. > > LIR's do not need to issue all 5 sizes of prefixes as long as the > HD-Ratio requirement is met. > > Rationale: > > The existing section 6.5.4.1 does not provide clear guidance on how > large of a prefix to allocate to a site. This makes it difficult for > LIR's to know they are in compliance with the rules, and makes it harder > for ARIN staff to evaluate requests per the communities wishes. > > This policy is based on an HD Ratio of .25 for end sites. The following > table may be useful: > > Prefix Size Number of Subnets Required in Use to Meet .25 > ----------- ----------------- --------------------------- > /64 1 1 > /60 16 2 > /56 256 4 > /52 4096 8 > /48 65536 16 > > It is believed this policy provides clear guidance while allowing LIR's > to make generous allocations to their end-sites. > > Timetable for implementation: immediate for new requests, 2 year grace > period for all existing assignments. > > > _______________________________________________ > 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 Sat Aug 18 00:30:53 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 17 Aug 2007 21:30:53 -0700 Subject: [ppml] Policy Proposal: IPv6 Policy Housekeeping In-Reply-To: <20070817192504.GE92950@ussenterprise.ufp.org> References: <46C5E767.6010406@arin.net> <20070817192504.GE92950@ussenterprise.ufp.org> Message-ID: <46C675FD.6020104@internap.com> I support this policy proposal as a whole. I haven't closely looked through each and every point, but I agree with the sentiment that any items that may be controversial should be pulled out as their own policy proposals. Thanks for doing the legwork on this. Some cleanup is badly overdue. -Scott Leo Bicknell wrote: > There has been a lot of back channel discussion before I submitted > this policy, and I want to bring PPML into the loop. > > This started out as a clean up effort, taking care of issues that > don't affect policy but simply make the NRPM more confusing. The > goal was not to change any policy. > > Along the way we ran into a number of ambiguous items that needed > to be clarified. For some ARIN staff has some experience and has > some sort of de facto policy since the written text is not clear. > For others, since this is IPv6, the situations really haven't come > up yet. > > I attempted to write clarifications matching the de facto policy > and/or by trying to be as bland and uncontroversial as possible. > Again, the goal was not to make new policy, but it really became > necessary to a degree to make things fully make sense. > > If there are controversial items I'm inclined to pull those out, > leaving this policy to be the non-controversial edits. Any items we > pull out could be addressed in the future on a case by case basis by > other policy proposals. > > Your comments on this matter are greatly appreciated. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 stephen at sprunk.org Sat Aug 18 00:35:56 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 17 Aug 2007 23:35:56 -0500 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines References: <46C5E72F.2080903@arin.net> <46C671B2.60800@internap.com> Message-ID: <01f101c7e153$7e794380$6601a8c0@atlanta.polycom.com> Thus spake "Scott Leibrand" > As expressed by others, I oppose this policy proposal as > written, because I believe current guidelines are sufficient. > ISPs should be free to delegate a /48 or /56 to users, as > appropriate for their situation. I believe that any justification, > including convenience, should be sufficient to allow allocation > of a /48 instead of a smaller subnet. Agreed. Current policy allows LIRs to assign either, and there should be no penalty for LIRs that choose to use either /56s or /48s. There is no shortage of anything but routing slots in IPv6. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From randy at psg.com Sat Aug 18 00:54:52 2007 From: randy at psg.com (Randy Bush) Date: Fri, 17 Aug 2007 18:54:52 -1000 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <01f101c7e153$7e794380$6601a8c0@atlanta.polycom.com> References: <46C5E72F.2080903@arin.net> <46C671B2.60800@internap.com> <01f101c7e153$7e794380$6601a8c0@atlanta.polycom.com> Message-ID: <46C67B9C.2000403@psg.com> >> As expressed by others, I oppose this policy proposal as >> written, because I believe current guidelines are sufficient. >> ISPs should be free to delegate a /48 or /56 to users, as >> appropriate for their situation. I believe that any justification, >> including convenience, should be sufficient to allow allocation >> of a /48 instead of a smaller subnet. > Agreed. Current policy allows LIRs to assign either, and there should be no > penalty for LIRs that choose to use either /56s or /48s. There is no > shortage of anything but routing slots in IPv6. let's get real here. if a customer and i are happy with my assigning them a /46.3, what the heck business is it of arin's? get outta my underwear! randy From leo.vegoda at icann.org Sat Aug 18 03:20:46 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Sat, 18 Aug 2007 09:20:46 +0200 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: References: Message-ID: <51F57705-CCA9-4339-9EF1-9B36A039B8EE@icann.org> On 17 Aug 2007, at 20:59, Ted Mittelstaedt wrote: [...] > Thus without ARIN approval I don't see how an "ebay market for > IPv4" can > exist that would allow responsibility for blocks to be passed between > organizations, when there are people waiting in line for IPv4. You would get it if sufficient demand for a market existed and some other organisation was willing to provide a registry that operated by a different set of policies. However, as ARIN's policies are set by consensus, the situation where ARIN's policies diverge significantly from the policies demanded by its constituency is unlikely to arise. The real issue is whether the participants in ARIN's policy making process want to keep the FCFS model or would prefer to move to a market-based model. Regards, Leo Vegoda From bmanning at vacation.karoshi.com Sat Aug 18 06:23:44 2007 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 18 Aug 2007 10:23:44 +0000 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: References: <454810F09B5AA04E9D78D13A5C39028A02A4C832@nyrofcs2ke2k01.corp.pvt> <46C611F1.6030506@eagle.ca> Message-ID: <20070818102344.GA17357@vacation.karoshi.com.> On Fri, Aug 17, 2007 at 06:42:41PM -0700, David Conrad wrote: {long counter point elided} > > The real problem isn't IPv6 address exhaustion, it is the risk of > overwhelming the routing system. I would worry that allocating > longer prefixes under the theory that it is less wasteful of address > space might increase the chances that those longer prefixes would > show up in the routing system. > > Regards, > -drc risk of overwhelming the routing system? guess i have to agree w/ you there... but surely its not a risk but a dead certainty. the routing system is "dead man walking" with regard to IPv6. some kind soul pointed out the magnitude of 128 bits... any of the current delegation metrics for which IPv6 is handed out, the current routing system will fail. --bill From paul at vix.com Sat Aug 18 12:28:07 2007 From: paul at vix.com (Paul Vixie) Date: Sat, 18 Aug 2007 16:28:07 +0000 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: Your message of "Fri, 17 Aug 2007 18:42:41 MST." References: <454810F09B5AA04E9D78D13A5C39028A02A4C832@nyrofcs2ke2k01.corp.pvt> <46C611F1.6030506@eagle.ca> Message-ID: <65554.1187454487@sa.vix.com> > However, people are finding interesting ways to be irrational. like using a /64 for a subnet? or like PI /48's to recreate the IPv4 swamp? > The real problem isn't IPv6 address exhaustion, it is the risk of > overwhelming the routing system. yea, verily. > I would worry that allocating > longer prefixes under the theory that it is less wasteful of address > space might increase the chances that those longer prefixes would > show up in the routing system. i don't think that's going to be the cause of overwhelming the routing system. PI /48 and LAN /64 will do that quite adequately, even if we never use more than 1% of the IPv6 pool in the doing of it. ps. not speaking as an arin trustee in this message. From drc at virtualized.org Sat Aug 18 13:45:40 2007 From: drc at virtualized.org (David Conrad) Date: Sat, 18 Aug 2007 10:45:40 -0700 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <65554.1187454487@sa.vix.com> References: <454810F09B5AA04E9D78D13A5C39028A02A4C832@nyrofcs2ke2k01.corp.pvt> <46C611F1.6030506@eagle.ca> <65554.1187454487@sa.vix.com> Message-ID: <7ACF4793-A13A-454B-AD93-72A243466340@virtualized.org> On Aug 18, 2007, at 9:28 AM, Paul Vixie wrote: >> However, people are finding interesting ways to be irrational. > like using a /64 for a subnet? 2^64 subnets is still an insanely large number. While it is ... questionable (particularly given how most large scale enterprise IT folk get twitchy when you say "stateless auto-configuration"), I don't see this as a real problem. It just turns the address space from 2^128 to 2^64. > or like PI /48's to recreate the IPv4 swamp? No. I was speaking more of allocating /20s, /19s, and shorter, particularly given the liberalization of PI allocation policies. People seem to forget that there are the same number of /19s (etc) in IPv6 as there are in IPv4. You want to conserve address space? Never _EVER_ allocate longer than a /32. If a requester has demonstrated they have consumed the / 32, grow it to a /31. If they have demonstrated they've consumed the /31, grow it to a /30. Etc. Never reserve space or allocate sequentially, simply use sparse allocation with bisection (that is, after all, why each RIR received a /12). Speaking of that, why is ARIN still allocating IPv6 sequentially? Regards, -drc From stephen at sprunk.org Sat Aug 18 14:07:53 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 18 Aug 2007 13:07:53 -0500 Subject: [ppml] dual-stack (was Re: Expand timeframe of Additional Requests ) References: <46C4472F.6090203@dilkie.com> <95668.1187279665@sa.vix.com> <00b601c7e027$daf93520$563816ac@atlanta.polycom.com> <33892.1187286904@sa.vix.com> Message-ID: <013b01c7e1c4$d9ceb230$6601a8c0@atlanta.polycom.com> Thus spake "Paul Vixie" >> What's wrong with NAT-PT? > > see http://tools.ietf.org/html/rfc4966, i guess. I'll save eveyone else some time reading: NAT is bad therefore NAT-PT is bad. >> My ideal CPE box would provide both v4 and v6 downstream. If the >> upstream was v6-only, it would get the inside prefix via DHCP PD and >> do NAT-PT for v4 traffic. If the upstream was v4-only, it would do 6to4 >> for v6 traffic. If both were available upstream, it'd do DHCP PD and >> native routing for v6, and normal NAT and DHCP for v4. > > you'll need to present a case for this to ietf/v6ops, and offer a solution > that lacks NAT-PT's statefulness and modal complexity. The IETF isn't interested in any transition model that doesn't require dual-stacking every host on the Internet before the first v6-only node appears. This is a fatal flaw that will ensure every model they come up with fails. Oh, and there's a moratorium on "new" transition models as well, so even if one had a great idea, it would be ignored on principle. NAT exists, despite IETF bleating about its evils, and these days virtually every host on the Internet is behind one. NAT-PT extends that evil, yes, but it gets us out of the chicken-and-egg problem we have today where nobody is willing to pay the cost of deploying v6 because nobody else has deployed v6. NAT-PT would provide a critical mass of hosts that _appear_ to be dual-stacked, giving other sites motivation to deploy v6 themselves and making it possible for v6-only networks and hosts to be deployed. > i agree with the general goal that a CPE could let V4-only devices > continue > to connect but not depend on a V4 ISP infrastructure other than at the > "far > edge". My model stil assumes that two v4-only hosts would speak native v4 to each other, though likely through NAT devices -- which is already common. An automatic v4-over-v6 tunneling mechanism is something we won't need for many years to come. >> The best case I see is that ISPs will deploy native v6 and then stuff all >> their customers (well, at least residential) behind a giant v4 NAT box >> per >> POP, handing out addresses in 10/8 via DHCP. That'd allow them to drop >> their v4 allocations, yet still provide "pure" access on v6, motivating >> customers to enable it. > > would that work? (is there a proof of concept running anyplace?) I can't see any reason it wouldn't work, but I also don't see the motivation for anyone to try today, since there's no native (or even NAT-PT'd) v6 hosts for their customers to talk to. I'm not aware of any proof of concept. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From bicknell at ufp.org Sat Aug 18 14:26:14 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 18 Aug 2007 14:26:14 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <7ACF4793-A13A-454B-AD93-72A243466340@virtualized.org> References: <454810F09B5AA04E9D78D13A5C39028A02A4C832@nyrofcs2ke2k01.corp.pvt> <46C611F1.6030506@eagle.ca> <65554.1187454487@sa.vix.com> <7ACF4793-A13A-454B-AD93-72A243466340@virtualized.org> Message-ID: <20070818182614.GA1870@ussenterprise.ufp.org> In a message written on Sat, Aug 18, 2007 at 10:45:40AM -0700, David Conrad wrote: > You want to conserve address space? Never _EVER_ allocate longer > than a /32. If a requester has demonstrated they have consumed the / > 32, grow it to a /31. If they have demonstrated they've consumed > the /31, grow it to a /30. Etc. Never reserve space or allocate > sequentially, simply use sparse allocation with bisection (that is, > after all, why each RIR received a /12). Circling back to my proposal that started this thread.... The issue addressed by this proposal is the size blocks LIR's assign from their PA blocks to customers. This proposal does nothing to change the size of blocks given out by ARIN. In theory if PA is done correctly (and we all know there will be some cut outs) these never appear in the global routing table. Do you have an opinion on if ISP's should be always giving out /48's to every customer, even if they have a single PC? Or shold an HD-Ratio like I proposed be used? Are you comfortable with ARIN staff only having a "guideline" to go on, or would you rather they, and the community have a firm criteria in the policy manual? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From drc at virtualized.org Sat Aug 18 14:44:06 2007 From: drc at virtualized.org (David Conrad) Date: Sat, 18 Aug 2007 11:44:06 -0700 Subject: [ppml] hoarding (was Policy Proposal: Expand timeframe of Additional Requests) In-Reply-To: <57421.1187292913@sa.vix.com> References: <57421.1187292913@sa.vix.com> Message-ID: Paul, On Aug 16, 2007, at 12:35 PM, Paul Vixie wrote: > even leaving aside the fact that IP addresses aren't property This is a red herring. Would calling the things that are being bought and sold "Address IRUs" make you (and Steve Ryan) feel better? > when you've got a pile of stuff that costs you nothing to hold onto There is an opportunity cost to holding on to your "pile of stuff". Presumably, IPv4 has a limited lifetime so the value of your pile will go to zero in the long term. > you will trickle it out into the market at a pace designed to keep > prices high. You can only effectively do this if you have cornered the market. > if we postulate N hoarders and demand Q per interval T, > each hoarder will have the quota of (N/Q)/T, knowing that if they > exceed this > they will not maximize their profit. I'm not bright enough to understand your equation (what are the units? people per address per second?), but I'm fairly certain that for your assertion to make sense, it assumes either perfect knowledge on the part of the hoarders (unlikely) or collusion amongst the hoarders (might interest the US FTC or equivalents elsewhere). > a hoarder has to limit the amount put into circulation to get paid > "the most." If they have cornered the market. If they have not, then they are competing against others who are wanting to get paid "the most". There are over 1 billion legacy addresses. I'm told by a (fairly :-)) reliable source that about 4% of that is actually routed. An interesting question would be 'how many potential sellers are there?' and the follow up, 'how quickly will they consolidate?'. > IOW, they would only dump in the months before IPv6 appeared to be > viable, And they would collectively determine this how? > on this point, i agree, with the proviso that ARIN's authority to > allocate > would become moot if there is nothing to allocate, and ARIN derives > its > authority from the community, who may yet cohere on the topic of > address > property rights. The problem isn't the _ARIN community_ "cohering" on the topic of address property rights. It is the folks who collectively hold more address space than all the RIRs combined cohering on the topic, particularly if you're proposing to take away their addresses without compensation. Within this mailing list, you are largely preaching to the choir. > i don't know if it would be possible to rev RFC 2050 in today's > world, but i expect some RIR bylaws somewhere might also have to be > amended. It wasn't possible in 1996/1997 to rev 2050 when I chaired the IRE (and later PAGAN) BOFs which were called for in 2050 and in the past, the RIRs have been quite energetic in asserting the IETF has no special role in the creation of RIR policies. There was an effort a few years back within the RIRs to revise 2050 so that it actually came closer to matching current practice, but the guy doing it apparently didn't hate his life as much as it seemed (:-)) and that effort appears to have died quietly. > folks who know that the highest and best use of > property is to buy low and sell high, speculate, and subdivide, are > concerned > about the digital divide (can afford addresses vs. not), When this becomes an issue, the free pool is exhausted, so this is irrelevant. Without some way of reclaiming unused space, the 'IPv4 digital divide' will be fixed in concrete and cannot move. In other resources, money has proven to be an incentive to encourage people to put their resources back into play. You would appear to believe markets can't be trusted for IP addresses. What is your alternative proposal? > globalization (a > village ISP in africa might be able to make the equivilent of a > year's profit > by selling their IP address block in new york), Is this good or bad? > routing table growth due to subdivision, The routing system is going to experience explosive growth. IPv6 has guaranteed that. The question is how can we keep from overgrazing the commons. Complicated as there are arguments about the size of the commons and even that the commons can be fully consumed... Regards, -drc From tony at lava.net Sat Aug 18 15:41:40 2007 From: tony at lava.net (Antonio Querubin) Date: Sat, 18 Aug 2007 09:41:40 -1000 (HST) Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <46C5E72F.2080903@arin.net> References: <46C5E72F.2080903@arin.net> Message-ID: On Fri, 17 Aug 2007, Member Services wrote: > All assignments made by LIR's should meet a minimum HD-Ratio of .25. > > * /64 - Site needing only a single subnet. > * /60 - Site with 2-3 subnets initially. > * /56 - Site with 4-7 subnets initially. > * /52 - Site with 8-15 subnets initially. > * /48 - Site with 16+ subnets initially. This adds unnecessary granularity to the assignment guidelines as well as perpetuates administrative complexity for LIRs. The /56 recommendation for 'small' sites was a welcome addition when it came but adding 2 more levels doesn't really add much value. Let's keep it simple. Antonio Querubin whois: AQ7-ARIN From paul at vix.com Sat Aug 18 16:40:17 2007 From: paul at vix.com (Paul Vixie) Date: Sat, 18 Aug 2007 20:40:17 +0000 Subject: [ppml] hoarding (was Policy Proposal: Expand timeframe of Additional Requests) In-Reply-To: Your message of "Sat, 18 Aug 2007 11:44:06 MST." References: <57421.1187292913@sa.vix.com> Message-ID: <31925.1187469617@sa.vix.com> david conrad quoted me... > > even leaving aside the fact that IP addresses aren't property ...and then wrote: > This is a red herring. Would calling the things that are being > bought and sold "Address IRUs" make you (and Steve Ryan) feel better? addresses aren't available on an IRU basis. don't call this a red herring while RFC 2050 and all of the RIR contracts and bylaws all say that addresses aren't assets, aren't transferrable, and are only made available on the basis of "need to connect". if you want to convert this to a red herring, then i suggest we talk about ways to do that, rather than declaring it to be so. From drc at virtualized.org Sat Aug 18 17:54:59 2007 From: drc at virtualized.org (David Conrad) Date: Sat, 18 Aug 2007 14:54:59 -0700 Subject: [ppml] address ownership In-Reply-To: <31925.1187469617@sa.vix.com> References: <57421.1187292913@sa.vix.com> <31925.1187469617@sa.vix.com> Message-ID: To clarify: On Aug 18, 2007, at 1:40 PM, Paul Vixie wrote: >>> even leaving aside the fact that IP addresses aren't property >> This is a red herring. Would calling the things that are being >> bought and sold "Address IRUs" make you (and Steve Ryan) feel better? > addresses aren't available on an IRU basis. Yes. Right now, under the terms of RSAs, address allocations are not (in theory) indefeasible. However, I was suggesting creating a new object corresponding to an "indefeasible right of use" for addresses on top of the underlying addresses that _could_ be bought and sold without veering off into pointless discussions about "address ownership". > don't call this a red herring while RFC 2050 and all ... RIR assertions that addresses can't be 'owned' (which isn't, by the way, in RFC 2050 -- you might ask yourself why not) do not apply to a majority of the IPv4 address space allocated to date unless the RIRs are asserting they have authority of address space not allocated by them. As such, discussions of ownership is 'a diversion or distraction from an original objective' of how to deal with a post- IPv4 run out world. If you disagree, why doesn't ARIN revoke (say) 45.0.0.0/8? Regards, -drc From drc at virtualized.org Sat Aug 18 18:10:07 2007 From: drc at virtualized.org (David Conrad) Date: Sat, 18 Aug 2007 15:10:07 -0700 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <20070818182614.GA1870@ussenterprise.ufp.org> References: <454810F09B5AA04E9D78D13A5C39028A02A4C832@nyrofcs2ke2k01.corp.pvt> <46C611F1.6030506@eagle.ca> <65554.1187454487@sa.vix.com> <7ACF4793-A13A-454B-AD93-72A243466340@virtualized.org> <20070818182614.GA1870@ussenterprise.ufp.org> Message-ID: Leo, On Aug 18, 2007, at 11:26 AM, Leo Bicknell wrote: > Do you have an opinion on if ISP's should be always giving out /48's > to every customer, even if they have a single PC? Given the IETF mandate for /64s for subnets, number of PCs is irrelevant. I don't have a strong opinion about /48s to every customer as I can see arguments on both sides. It would be easier for everybody and (assuming RIR to ISP allocations become more rational) I don't have concerns about running out of /48s. However, pragmatically speaking, I also don't see home users ever subnetting to a significant level, so it doesn't make a lot of sense to me to throw a potential of 64K subnets at them. As such the "/56 for home users - /48 for enterperise" split seems a reasonable compromise. > Are you comfortable with ARIN staff > only having a "guideline" to go on, or would you rather they, and the > community have a firm criteria in the policy manual? I am and always have been strongly in favor of firm criteria. Regards, -drc From paul at vix.com Sat Aug 18 19:59:02 2007 From: paul at vix.com (Paul Vixie) Date: Sat, 18 Aug 2007 23:59:02 +0000 Subject: [ppml] address ownership In-Reply-To: Your message of "Sat, 18 Aug 2007 14:54:59 MST." References: <57421.1187292913@sa.vix.com> <31925.1187469617@sa.vix.com> Message-ID: <72956.1187481542@sa.vix.com> > Right now, under the terms of RSAs, address allocations are not (in theory) > indefeasible. However, I was suggesting creating a new object corresponding > to an "indefeasible right of use" for addresses on top of the underlying > addresses that _could_ be bought and sold without veering off into pointless > discussions about "address ownership". wouldn't IANA revoke any allocation for which "need in order to connect" was no longer demonstrable, per RFC 2050? wouldn't an offer to sell an IRU-like instrument be clear evidence of "lack of need" in this context? > RIR assertions that addresses can't be 'owned' ... do not apply to a > majority of the IPv4 address space allocated to date unless the RIRs are > asserting they have authority of address space not allocated by them. i'm explicitly not addressing the question of authority. as leo vogoda said here recently, if the community wants ip addresses to become transferrable, they will act that way, and one of the changes they'd have to make is to the RIR system's rules. > As such, discussions of ownership is 'a diversion or distraction from an > original objective' of how to deal with a post- IPv4 run out world. it sounds as if we're begging the same question here but from different angles. if you think that making previous allocations transferrable is the way that the community ought to deal with a post-depletion world, then the questions to answer are: 1. is it steady state -- would we be able to last forever that way? 2. if not, how much time would it buy us before IPv6 really was mandatory, and is this forcing function REALLY the only way to get there? 3. would the meatspace governments of the world, who tolerate ICANN and the RIR system today, continue to do so under this kind of system? 4. are there changes the IETF or ICANN or ASO or NRO or the RIRs would need to make to any founding principles/bylaws, or is this just a policy change? 5. what will the implications be on IPv6 allocation? 6. what if the routing table exploded due to deaggregation even while there was still plenty of IPv4 space "for sale"? 7. what would everybody's new liabilities be? note-- any answer that proceeds from the assumption that there's nothing we can do about it so we just have to cope with terrible badness and pain is a waste of your time since i'll ignore it, so let's skip beyond that this time. if the community coheres its will around transferrability, then there's a lot of work to be done and not very many years to do it in. it's not simple and it's not the default nor the status quo. if the community coheres its will around nontransferrability, then there's also some work to do but plenty of time to do it. FCFS is the status quo and maintaining it is what's going to happen, unless some change is selected. > If you disagree, why doesn't ARIN revoke (say) 45.0.0.0/8? i don't know anything about that netblock, but if i did, i'd still refer it to ARIN staff. (i also don't know why ARIN allocates IPv6 sequentially, but i'm happy to refer that question to ARIN staff if you can't reach them.) From briand at ca.afilias.info Sun Aug 19 12:49:24 2007 From: briand at ca.afilias.info (briand at ca.afilias.info) Date: Sun, 19 Aug 2007 12:49:24 -0400 (EDT) Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <20070818182614.GA1870@ussenterprise.ufp.org> References: <454810F09B5AA04E9D78D13A5C39028A02A4C832@nyrofcs2ke2k01.corp.pvt> <46C611F1.6030506@eagle.ca> <65554.1187454487@sa.vix.com> <7ACF4793-A13A-454B-AD93-72A243466340@virtualized.org> <20070818182614.GA1870@ussenterprise.ufp.org> Message-ID: <65090.69.159.80.108.1187542164.squirrel@look.libertyrms.com> > In a message written on Sat, Aug 18, 2007 at 10:45:40AM -0700, David > Conrad wrote: >> You want to conserve address space? Never _EVER_ allocate longer >> than a /32. If a requester has demonstrated they have consumed the / >> 32, grow it to a /31. If they have demonstrated they've consumed >> the /31, grow it to a /30. Etc. Never reserve space or allocate >> sequentially, simply use sparse allocation with bisection (that is, >> after all, why each RIR received a /12). > > Circling back to my proposal that started this thread.... > > The issue addressed by this proposal is the size blocks LIR's assign > from their PA blocks to customers. This proposal does nothing to > change the size of blocks given out by ARIN. Bingo! The missing piece of the puzzle is one of PI assignments, not PA. All that is required to manage PA assignments from getting out of hand, is to limit the *PI* assignments. Let the recipients of PI blocks do with those as they wish, with one proviso: One (new/initial) PI assignment *only*, per ASN. And the *size* of PI assignments should be flexible, with the only requirement being, that whatever justification for the size of the request, is that it be self-consistent - that what is used for the justification matches the size of the requested space. If we limit one routing slot per ASN, the growth of the DFZ will not be problematic. The *only* problem with the IPv4 swamp, was that there were multiple assignments to ASNs, that couldn't be aggregated by the ASNs. If we place up front, the requirement that all assignments must always be aggregateable, by virtue of the fact that there isn't anything to aggregate, the problem never comes into existence. There will undoubtedly be cases of acquisition and mergers, where as a consequence of the joining of ASNs, that a single ASN has more than one PI block. But, if the rule is "once you *have* a block, you can't request another", rather than "you're only allowed one at any point in time", the result is suitably similar - growth only occurs at the rate of ASN assignments, which are gated by the rate at which new multihomed-via-BGP networks enter the DFZ universe. > In theory if PA is done correctly (and we all know there will be > some cut outs) these never appear in the global routing table. If PA is managed by recipients, without any requirement for ARIN to audit, but with the double-edged sword being that they recipient only gets one PI block to play with, the PA issue is self-managing. If the only rule is "one PI per ASN", it is entirely reasonable to expect that all members of the DFZ will have an incentive to enforce it. If even a modest proportion of the ASNs in the DFZ filter based on "we won't allow peers to deaggregate", then deaggregation will be nearly useless, and as a result, is likely to not be a large problem. It is a "hammer vs nail" rule set, but in this case, both the hammer and the nail are the right tools for the job. > Do you have an opinion on if ISP's should be always giving out /48's > to every customer, even if they have a single PC? Or shold an > HD-Ratio like I proposed be used? Are you comfortable with ARIN staff > only having a "guideline" to go on, or would you rather they, and the > community have a firm criteria in the policy manual? ARIN staff should never need to evaluate anything other than initial IPv6 requests, and should be extremely lenient in allocating those. Any justification that passes the giggle test, should be fine. Brian Dickson From michael.dillon at bt.com Sun Aug 19 17:45:45 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 19 Aug 2007 22:45:45 +0100 Subject: [ppml] hoarding (was Policy Proposal: Expand timeframe ofAdditional Requests) In-Reply-To: References: <57421.1187292913@sa.vix.com> Message-ID: > This is a red herring. Would calling the things that are > being bought and sold "Address IRUs" make you (and Steve > Ryan) feel better? No. In fact *YOUR* comment is the red herring. IP address allocations/assignments are not IRUs. For reference, here is the definition of an IRU from an AT&T contract that I found during a quick search of the web: ------------- 1.12 "Indefeasible Right to Use" or "IRU" shall mean the exclusive, unrestricted and (except in the case of a Payment Event of Default) indefeasible right to use the relevant Capacity (including equipment, fibers or capacity) for any legal purpose. The granting of such IRU does not convey title or legal ownership of any fibers or equipment on the AT&T Network. Except in the case of a Payment Event of Default (as defined below), the granting party shall have no right to revoke or restrict in any manner or to any degree whatsoever, through injunctive relief or otherwise, the use of the Right to Use granted to the receiving party. Notwithstanding the occurrence of a breach by the receiving party of any legal duty or obligation imposed by any contract, by the law of torts (including simple or gross negligence, strict liability or willful misconduct), or by federal or state laws, rules, regulations, orders, standards or ordinances, during the Term, it being understood and agreed that each such breach shall be compensable, if at all, by a remedy at law and not at equity. ----------- In fact, ARIN hands out a limited right to use which is defeasible. > There are over 1 billion legacy addresses. I'm told by a > (fairly :-)) reliable source that about 4% of that is > actually routed. That is the crux of the issue. The hoarders are already there. They have a stock of legacy IP addresses that they are sitting on in the hopes that a market can develop. Because these legacy addresses are not registered, we don't even know who these players are. > The problem isn't the _ARIN community_ "cohering" on the > topic of address property rights. It is the folks who > collectively hold more address space than all the RIRs > combined cohering on the topic, particularly if you're > proposing to take away their addresses without compensation. You've hit the nail on the head. The big difference between legacy holders and ARIN holders is that ARIN holders are playing by the rules, negotiating a common agreement with each other on a level playing field. The legacy holders are hiding in the shadows relying on vague threats of legal action. I believe that when push comes to shove, the U.S. government will come out on the side of an orderly regime (not market) because that is generally what the USG supports. For instance, SEC, WTO, Sarbanes-Oxley. Until the Department of Commerce formally makes a statement to the contrary, I believe that if early court cases do not establish the supremacy of ARIN rules over legacy holders, then the DOC will step in and move things in that direction. The best that legacy holders can hope for is that there will be a ruling which gives them a short time to come into compliance and show that their legacy allocations are in fact, in accordance with ARIN rules. > There was an effort a few years back within the > RIRs to revise 2050 so that it actually came closer to > matching current practice, but the guy doing it apparently > didn't hate his life as much as it seemed (:-)) and that > effort appears to have died quietly. That effort received virtually no public support. > The routing system is going to experience explosive growth. > IPv6 has guaranteed that. This is untrue. IPv6 does not change the routing system in any substantial way. It does increase the minimum number of bits per entry to 128. But at the same time it reduces the number of entries per major player to one in most cases. At the same time, all the techniques of mitigating routing table growth issues still exist and can be applied. The losers would be the small players who want to multihome on the global stage which is exactly the same as with IPv4, i.e. nobody will accept my /29 prefix. --Michael Dillon From michael.dillon at bt.com Sun Aug 19 17:48:59 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 19 Aug 2007 22:48:59 +0100 Subject: [ppml] address ownership In-Reply-To: References: <57421.1187292913@sa.vix.com><31925.1187469617@sa.vix.com> Message-ID: > If you disagree, why doesn't ARIN revoke (say) 45.0.0.0/8? ARIN negotiates, rather than revokes. At the end of a negotiation, ARIN may well choose to revoke, but as a steward of the address space, ARIN has to ensure that it is in a strong legal position. This is a well-known principle of business law. --Michael Dillon From michael.dillon at bt.com Sun Aug 19 17:59:50 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 19 Aug 2007 22:59:50 +0100 Subject: [ppml] Technical reason why /52,/56,/60,/64 are bad Message-ID: Interesting comment from IETF list which indicates there may be technical reasons for providers to prefer assigning no longer than /48 to customers at their edge. > -----Original Message----- > From: Robin Whittle [mailto:rw at firstpr.com.au] > Sent: 18 August 2007 03:47 > To: ietf at ietf.org > Subject: Re: IPv6 addresses really are scarce after all - /64 > FIB burden > > I am concerned about DFZ routers needing to have their FIBs look at > 48 bits of address for every packet sent to one of the new > end-user address blocks as allocated by ARIN, AfriNIC and now RIPE. > > But this is up to 16 bits worse: > > > * /64 - Site needing only a single subnet. > > * /60 - Site with 2-3 subnets initially. > > * /56 - Site with 4-7 subnets initially. > > * /52 - Site with 8-15 subnets initially. > > * /48 - Site with 16+ subnets initially. > > A wide TCAM can handle these address bits in a single > clock-cycle, but the high end routers CRS-1, M120 and MX960 > don't use TCAM in their FIB. TCAM chews too much power, is > too expensive, has long update times and has various other > problems. These high end routers use trie-based algorithms > involving lookups into gigabytes of slow, shared, DRAM. This > can only be done some number of bits at a time, where that > number may by 5 to probably 20 or maybe 24 at the absolute maximum. > > http://www.firstpr.com.au/ip/sram-ip-forwarding/router-fib/ > > Consider a stream of 50 IPv6 VoIP packets a second, each > bearing 20 bytes of data. Let's say it has to go through 16 > DFZ routers. With the new /64 allocation size, every packet > chews the resources of 20 routers each having to work its way > through 64 bits of address, with RAM lookups. That's 128 > bytes of address data to be processed, laboriously, en-route, > for a lousy 20 bytes of relatively inconsequential VoIP call > - 1/50 second. > > Each VoIP call between hosts in two /64 prefixes with 16 DFZ > routers en-route involves those routers collectively working > through this many bits: > > 50 * 2 * 64 * 16 = 120,400 bits!! > > This sounds really inefficient, compared to IPv4 in which DFZ > routers in practice need to look at 24 bits, at most, of the > destination address of IPv4 packets. Since only about 1.23% > of the advertised space is for prefixes of 21 bits or more: > > http://www.firstpr.com.au/ip/host-density-per-prefix/ > > 16 to 20 bits is probably sufficient for most packets. > > - Robin > > From rw at firstpr.com.au Sun Aug 19 21:29:54 2007 From: rw at firstpr.com.au (Robin Whittle) Date: Mon, 20 Aug 2007 11:29:54 +1000 Subject: [ppml] Technical reason why /52,/56,/60,/64 are bad In-Reply-To: References: Message-ID: <46C8EE92.7090201@firstpr.com.au> Michael Dillon quoted something I wrote on the IETF list, in response to the PPML message: http://lists.arin.net/pipermail/ppml/2007-August/008521.html It was my initial impression that these longer prefixes, to /64, were being assigned (allocated? - I get confused with the terminology) by RIRs as PA space for end-users. That would mean that there would be BGP advertised prefixes of this length, with the consequent need for all BGP routers to process 64 bits of destination address of some packets in their FIBs. After I wrote my first message, which Michael quoted, I read the PPML message more carefully and saw that it concerned LIRs (effectively ISPs, I think) providing PI space for their customers. This would mean that the /64 prefixes would not be advertised in BGP. So I wrote a retraction to the IETF list: http://www1.ietf.org/mail-archive/web/ietf/current/msg47249.html Can someone confirm my second understanding is correct? - Robin From christopher.morrow at gmail.com Sun Aug 19 21:46:33 2007 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Sun, 19 Aug 2007 21:46:33 -0400 Subject: [ppml] Technical reason why /52,/56,/60,/64 are bad In-Reply-To: References: Message-ID: <75cb24520708191846w31f72e6au2229e27734a7cf33@mail.gmail.com> just a quick clarifying note (not to michael so much as eventually robin) On 8/19/07, michael.dillon at bt.com wrote: > > problems. These high end routers use trie-based algorithms > > involving lookups into gigabytes of slow, shared, DRAM. This > > can only be done some number of bits at a time, where that > > number may by 5 to probably 20 or maybe 24 at the absolute maximum. Actually the normal DFZ sorts of devices as listed below will have to do lookups to a full 32 bits on many occasions... I suspect the trie-based lookups (and tcam lookups) are able today to do at least 32 bit lookups. In some cases the lookups actually are longer still as most of the DFZ-type routers implement ACL's via the route-table. So some TCAM based routers will use 'spare bits' in the tcam entry to cover port/protocol, some TCAM based routes are able to do 64+ bits of lookup actually since they can do in a single pass src and dest lookups (to do both acls and uRPF functionality). I suspect that the DRAM lookup type routers also have 64+ bits of lookup since they can do src/dest ip and port/protocol for acl functionality and uRPF. > > This sounds really inefficient, compared to IPv4 in which DFZ > > routers in practice need to look at 24 bits, at most, of the > > destination address of IPv4 packets. Since only about 1.23% > > of the advertised space is for prefixes of 21 bits or more: In practice they actually need more than 24 bits, see above and consult your local vendor. The DFZ is not made up of just /24 and larger routes :( -Chris From pwilson at apnic.net Sun Aug 19 21:46:15 2007 From: pwilson at apnic.net (Paul Wilson) Date: Mon, 20 Aug 2007 11:46:15 +1000 Subject: [ppml] Technical reason why /52,/56,/60,/64 are bad In-Reply-To: <46C8EE92.7090201@firstpr.com.au> References: <46C8EE92.7090201@firstpr.com.au> Message-ID: <000C265700B402E3DF195B1C@wav11.apnic.net> > > After I wrote my first message, which Michael quoted, I read the > PPML message more carefully and saw that it concerned LIRs > (effectively ISPs, I think) providing PI space for their customers. > This would mean that the /64 prefixes would not be advertised in > BGP. So I wrote a retraction to the IETF list: > > http://www1.ietf.org/mail-archive/web/ietf/current/msg47249.html > > Can someone confirm my second understanding is correct? Robin, Speaking for APNIC, this is correct - the longer prefixes are for customer assignments only, and are expected to be aggregated within larger portable blocks (allocations) held by ISPs, which under current policy are /32 at least. The longest portable prefix that we currently assign is /48. Paul Wilson APNIC ________________________________________________________________________ Paul Wilson, Director-General, APNIC http://www.apnic.net ph/fx +61 7 3858 3100/99 From sleibrand at internap.com Sun Aug 19 21:48:51 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Sun, 19 Aug 2007 18:48:51 -0700 Subject: [ppml] Technical reason why /52,/56,/60,/64 are bad In-Reply-To: <46C8EE92.7090201@firstpr.com.au> References: <46C8EE92.7090201@firstpr.com.au> Message-ID: <46C8F303.6090209@internap.com> The Assignment Guidelines proposal attempts to dictate what size prefixes LIRs (ISPs) assign to their customers. Such space, assigned by a provider, is PA (provider assigned). PI space is Provider Independent, meaning it is assigned directly by ARIN or other RIRs to end sites. PI space is not affected by this policy proposal. It is unclear to me whether this proposal would result in prefixes longer than /48 appearing in BGP. I suspect that what would happen instead is that anyone wanting to run BGP using PA space would still get a /48 (as they get /24's today) whether they expect to fully utilize it or not, and that smaller prefixes would be reserved for customers not running BGP. Regardless of whether there would be an impact to the DFZ, I remain opposed to the Assignment Guidelines proposal, as I believe that the existing guidelines (with two sizes, /48 and /56) are more appropriate, and that this is a matter best left to ISPs, with only general guidelines as to what to assign to whom. -Scott Robin Whittle wrote: > Michael Dillon quoted something I wrote on the IETF list, in > response to the PPML message: > > http://lists.arin.net/pipermail/ppml/2007-August/008521.html > > It was my initial impression that these longer prefixes, to /64, > were being assigned (allocated? - I get confused with the > terminology) by RIRs as PA space for end-users. That would mean > that there would be BGP advertised prefixes of this length, with the > consequent need for all BGP routers to process 64 bits of > destination address of some packets in their FIBs. > > After I wrote my first message, which Michael quoted, I read the > PPML message more carefully and saw that it concerned LIRs > (effectively ISPs, I think) providing PI space for their customers. > This would mean that the /64 prefixes would not be advertised in > BGP. So I wrote a retraction to the IETF list: > > http://www1.ietf.org/mail-archive/web/ietf/current/msg47249.html > > Can someone confirm my second understanding is correct? > > - 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. > From rw at firstpr.com.au Sun Aug 19 22:03:35 2007 From: rw at firstpr.com.au (Robin Whittle) Date: Mon, 20 Aug 2007 12:03:35 +1000 Subject: [ppml] IPv4 swamp, mh end-users & IP architectural solutions: LISP/APT/Ivip Message-ID: <46C8F677.5010900@firstpr.com.au> In "Re: [ppml] Policy Proposal: IPv6 Assignment Guidelines" Brian Dickson wrote, in part: > The *only* problem with the IPv4 swamp, was that there were > multiple assignments to ASNs, that couldn't be aggregated by the > ASNs. If we place up front, the requirement that all assignments > must always be aggregateable, by virtue of the fact that there > isn't anything to aggregate, the problem never comes into > existence. > > There will undoubtedly be cases of acquisition and mergers, where > as a consequence of the joining of ASNs, that a single ASN has > more than one PI block. > > But, if the rule is "once you *have* a block, you can't request > another", rather than "you're only allowed one at any point in > time", the result is suitably similar - growth only occurs at the > rate of ASN assignments, which are gated by the rate at which new > multihomed-via-BGP networks enter the DFZ universe. I disagree with the statement that the only problem with IPv4 routing is that some or many end-user networks (or ASNs in general - providers and end-users combined) have more than one BGP advertised prefix which are numerically separated and so can't be aggregated into a single advertised prefix. There are also problems with stability, excessive updates for some prefixes and the projected growth in the number of end-user networks which must be multihomed. I believe the same problem will afflict IPv6 if and when it is widely adopted, now that ARIN, AfriNIC and RIPE are assigning /48s of PI space to end-users. My understanding of the consensus on ROAP (Routing and Addressing Problem) is that the biggest single problem is the inability of the BGP control plane to cope with the growth in the number of multihomed end-user networks, which could reach into the millions - even if every network only had one advertised prefix. The discussions on the RAM list, resulting from the IAB RAWS workshop last year: http://www1.ietf.org/mail-archive/web/ram/current/ http://www.iab.org/about/workshops/routingandaddressing/ http://tools.ietf.org/html/draft-iab-raws-report lead me to think that the currently proposed solutions are of two types. Firstly, moderate improvements to BGP to improve stability and therefore to reduce some of the problems of having more and more advertised prefixes. Secondly, a "locator-ID" separation scheme involving tunnel routers, a mapping database etc. at the IP level to enable multihoming, traffic engineering and what I call "portable address space" for large numbers of end-user networks, without each such network adding to the number of BGP advertised prefixes. The schemes for doing this are LISP-NERD, LISP-CONS, eFIT-APT and my own proposal Ivip: http://www.firstpr.com.au/ip/ivip/ - which also supports mobility with nearly optimal path lengths for IPv4 and IPv6. It seems that a scheme such as one of these will be required, despite the fact they are all kludges with significant problems due to tunneling overhead, MTU limits -> fragmentation, disrupting Path MTU Discovery etc. All this effort is based on the notion that the problem is with the future number of end-user networks requiring multihoming - and that even if each required only a single advertised prefix there would still be such a scaling problem that some drastic architectural change (LISP/APT/Ivip etc.) would be required. - Robin From terry.l.davis at boeing.com Sun Aug 19 22:11:58 2007 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Sun, 19 Aug 2007 19:11:58 -0700 Subject: [ppml] [Re: IPv6 addresses really are scarce after all] In-Reply-To: <46C6556B.3060905@psg.com> References: <20070817211905.GA12791@vacation.karoshi.com.><825A85CC-15E6-4A0D-B5D8-13843F0CF387@virtualized.org><20070817213741.GB12791@vacation.karoshi.com.><0C2634E5-5173-4406-A646-C6971A0D19D0@virtualized.org> <20070817232633.GA13690@vacation.karoshi.com.> <0D090F1E0F5536449C7E6527AFFA280A03685AB4@XCH-NW-8V1.nw.nos.boeing.com> <46C6556B.3060905@psg.com> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A03685AB9@XCH-NW-8V1.nw.nos.boeing.com> Randy How many of the fortune 1000 and critical infrastructure providers will accept a permanent relationship with an ISP for their v6 addresses? I would not expect it to be many. There are some things that in the real world, we will not re-address because of an ISP change. Generally it will be a "critically" decision whether for business or critical infrastructure. Take care Terry > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Friday, August 17, 2007 7:12 PM > To: Davis, Terry L > Cc: bmanning at vacation.karoshi.com; David Conrad; ppml at arin.net > Subject: Re: [ppml] [Re: IPv6 addresses really are scarce after all] > > > I do sense that there is growing understanding that the requirement for > > businesses or critical infrastructure providers to obtain their v6 > > addresses from their ISP, will not work in the real world. > > after all, it has been such a tragic failure in ipv4, seriously > inhibiting the use of the internet. > > randy From randy at psg.com Sun Aug 19 22:21:01 2007 From: randy at psg.com (Randy Bush) Date: Sun, 19 Aug 2007 16:21:01 -1000 Subject: [ppml] Technical reason why /52,/56,/60,/64 are bad In-Reply-To: <46C8F303.6090209@internap.com> References: <46C8EE92.7090201@firstpr.com.au> <46C8F303.6090209@internap.com> Message-ID: <46C8FA8D.3080500@psg.com> > The Assignment Guidelines proposal attempts to dictate what size > prefixes LIRs (ISPs) assign to their customers. and who the hell gives arin this wonderful new prerogative to tell me how to run my business? and what will you do when i completely ignore it because it is none of your business? randy From randy at psg.com Sun Aug 19 22:22:52 2007 From: randy at psg.com (Randy Bush) Date: Sun, 19 Aug 2007 16:22:52 -1000 Subject: [ppml] [Re: IPv6 addresses really are scarce after all] In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A03685AB9@XCH-NW-8V1.nw.nos.boeing.com> References: <20070817211905.GA12791@vacation.karoshi.com.><825A85CC-15E6-4A0D-B5D8-13843F0CF387@virtualized.org><20070817213741.GB12791@vacation.karoshi.com.><0C2634E5-5173-4406-A646-C6971A0D19D0@virtualized.org> <20070817232633.GA13690@vacation.karoshi.com.> <0D090F1E0F5536449C7E6527AFFA280A03685AB4@XCH-NW-8V1.nw.nos.boeing.com> <46C6556B.3060905@psg.com> <0D090F1E0F5536449C7E6527AFFA280A03685AB9@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: <46C8FAFC.6090508@psg.com> > How many of the fortune 1000 and critical infrastructure providers will > accept a permanent relationship with an ISP for their v6 addresses? given no new real data (data != pontification on mailing lists), i guess we would have to look at history and say about the same number that do with v4. randy From terry.l.davis at boeing.com Sun Aug 19 22:29:51 2007 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Sun, 19 Aug 2007 19:29:51 -0700 Subject: [ppml] [Re: IPv6 addresses really are scarce after all] In-Reply-To: <46C8FAFC.6090508@psg.com> References: <20070817211905.GA12791@vacation.karoshi.com.><825A85CC-15E6-4A0D-B5D8-13843F0CF387@virtualized.org><20070817213741.GB12791@vacation.karoshi.com.><0C2634E5-5173-4406-A646-C6971A0D19D0@virtualized.org> <20070817232633.GA13690@vacation.karoshi.com.> <0D090F1E0F5536449C7E6527AFFA280A03685AB4@XCH-NW-8V1.nw.nos.boeing.com> <46C6556B.3060905@psg.com> <0D090F1E0F5536449C7E6527AFFA280A03685AB9@XCH-NW-8V1.nw.nos.boeing.com> <46C8FAFC.6090508@psg.com> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A03685ABC@XCH-NW-8V1.nw.nos.boeing.com> Randy I could agree with that assumption as least for the ARIN and RIPE regions. And if we expected similar long term ratios out of the other regions as they develop, we would probably be in the ballpark. Take care Terry > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Sunday, August 19, 2007 7:23 PM > To: Davis, Terry L > Cc: bmanning at vacation.karoshi.com; David Conrad; ppml at arin.net > Subject: Re: [ppml] [Re: IPv6 addresses really are scarce after all] > > > How many of the fortune 1000 and critical infrastructure providers will > > accept a permanent relationship with an ISP for their v6 addresses? > > given no new real data (data != pontification on mailing lists), i guess > we would have to look at history and say about the same number that do > with v4. > > randy From bicknell at ufp.org Sun Aug 19 22:52:52 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 19 Aug 2007 22:52:52 -0400 Subject: [ppml] Technical reason why /52,/56,/60,/64 are bad In-Reply-To: <46C8FA8D.3080500@psg.com> References: <46C8EE92.7090201@firstpr.com.au> <46C8F303.6090209@internap.com> <46C8FA8D.3080500@psg.com> Message-ID: <20070820025252.GA20740@ussenterprise.ufp.org> In a message written on Sun, Aug 19, 2007 at 04:21:01PM -1000, Randy Bush wrote: > and who the hell gives arin this wonderful new prerogative to tell me > how to run my business? and what will you do when i completely ignore > it because it is none of your business? Fascinating Randy. I guess you've never bothered to read ARIN's Number Resource Policy Manual. You may find this section entertaining. http://www.arin.net/policy/nrpm.html#four234 Of course, in your own presentation on the formation of ARIN you point out on side #7 that your ARIN allocations will have to be justified technically, and that actual engineering plans will be used. https://rip.psg.com/~randy/970414.fncac ARIN has been telling you from the start how to run your business, and I do believe you were one of the people who participated in the process to make it that way. -- 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 davids at webmaster.com Sun Aug 19 23:09:50 2007 From: davids at webmaster.com (David Schwartz) Date: Sun, 19 Aug 2007 20:09:50 -0700 Subject: [ppml] Technical reason why /52,/56,/60,/64 are bad In-Reply-To: <46C8FA8D.3080500@psg.com> Message-ID: > and who the hell gives arin this wonderful new prerogative to tell me > how to run my business? and what will you do when i completely ignore > it because it is none of your business? > > randy This might be a rational reply if we were talking about hinging assignments on something that had nothing to do with assignments. But evaluating efficient use of assigned address space when processing a request for additional address space is just unavoidable for a need-based address assignment scheme. If you think "use addresses the way the community agrees is efficient or you won't get any" is ARIN telling you how to run your business, then I would just have to ask what alternate means for evaluating address requests you would prefer. Perhaps you were making some subtler argument. Maybe you were trying to say that these kinds of policies are not needed in the IPv6 world and that a different kind of thinking is more appropriate in a world were addresses are not scarce? If so, lots of people might agree with you, but you actually need to make an argument like that. We're not smart enough to deduce it from anarchic chants like "keep your address assignment policies out of my business". DS From rw at firstpr.com.au Sun Aug 19 23:12:40 2007 From: rw at firstpr.com.au (Robin Whittle) Date: Mon, 20 Aug 2007 13:12:40 +1000 Subject: [ppml] Longer prefixes burden the FIBs of DFZ routers Message-ID: <46C906A8.3010204@firstpr.com.au> In "Technical reason why /52,/56,/60,/64 are bad", Christopher Morrow wrote: > just a quick clarifying note (not to michael so much as eventually > robin) > >> These high end routers use trie-based algorithms >> involving lookups into gigabytes of slow, shared, DRAM. This >> can only be done some number of bits at a time, where that >> number may by 5 to probably 20 or maybe 24 at the absolute >> maximum. > > Actually the normal DFZ sorts of devices as listed below will have > to do lookups to a full 32 bits on many occasions... I suspect the > trie-based lookups (and tcam lookups) are able today to do at > least 32 bit lookups. TCAM can be as wide as 72 bits, and if the router has enough TCAM space in its FIB, it doesn't matter how many bits are looked at, provided they fit within the 72 or 144 bit width of the TCAM. (However TCAM is expensive, power-hungry, must be soldered to the main board - can't be upgraded - and can be slow to update when the classification rules need to be changed.) There's no such thing as a 32 bit lookup unless what you need to find is a byte or less and if you have 4 gigabytes of RAM to hold the array, which no router's FIB has. The FEC (Forwarding Equivalence Class) information to specify how the packet should be switched within the router - to which interface and which input queue of that interfaces - is apparently 16 or 32 bits or more in larger routers. The high end routers CRS-1, M120 and MX960 do not use TCAM. According to what I could find out: http://www.firstpr.com.au/ip/sram-ip-forwarding/router-fib/ they use: CRS-1 ~1 gigabyte DDR DRAM (Slow ~55ns latency?) shared by 188 32 bit CPUs on a humongous ASIC. This is for a 40Gbps FIB. M120 64 megabytes RL-DRAM (Reduced latency ~15nsec) controlled by an I-chip ASIC. This is for a 10Gbps FIB. MX960 256 megabytes of SRAM - maybe DDR-II SRAM or QDR-II SRAM (the latter is the fastest RAM available, with latency and cycle times as low as 3.3nsec). This is for a 40Gbps FIB, but maybe it has four I-chips - in which case each has 64 megabytes. > In some cases the lookups actually are longer still as most of the > DFZ-type routers implement ACL's via the route-table. So some TCAM > based routers will use 'spare bits' in the tcam entry to cover > port/protocol, some TCAM based routes are able to do 64+ bits of > lookup actually since they can do in a single pass src and dest > lookups (to do both acls and uRPF functionality). I can imagine this being practical if the TCAM is wide enough, but this is highly unlikely to scale to IPv6's long addresses. > I suspect that the DRAM lookup type routers also have 64+ bits of > lookup since they can do src/dest ip and port/protocol for acl > functionality and uRPF. There's no such thing as a single memory cycle 64 bit lookup! I don't know enough about how these routers work, but I am wary that people who know even less about of these expensive devices, which we all pay for, assume routers can easily do things which are either impossible or extremely costly in terms of memory cycles, power dissipation, memory utilisation etc. >>> This sounds really inefficient, compared to IPv4 in which DFZ >>> routers in practice need to look at 24 bits, at most, of the >>> destination address of IPv4 packets. Since only about 1.23% >>> of the advertised space is for prefixes of 21 bits or more: > > In practice they actually need more than 24 bits, see above and > consult your local vendor. The DFZ is not made up of just /24 and > larger routes :( IPv4 routers need to be capable of analysing all 32 bits of each packet's destination address, but with a trie-based lookup scheme, depending on the "stride length" - such as 8 bits, then 6 then 6 or whatever - most of the packets can be classified in two or three memory lookups. The Tree Bitmap algorithm, as described in: Tree bitmap: hardware/software IP lookups with incremental updates Source ACM SIGCOMM Computer Communication Review archive Volume 34 , Issue 2 (April 2004) Pages: 97 - 122 Will Eatherton (Cisco Systems), George Varghese (UCSD), Zubin Dittia (Jibe Networks) portal.acm.org/citation.cfm?id=997160 (I have a copy of this paper . . .) involves doing the first 8 bits in RAM on the ASIC with subsequent reads to slow external shared DRAM, in strides such as 6 bits. Longer strides are obviously faster at finding the solution, but require more and more RAM. The Tree-Bitmap algorithm anticipates using a bunch of slow DRAM in four banks with the same data, so one bank can be reading while the rest are recovering from their last read operation. So these routers don't necessarily have more than 256 megs of RAM - and the Juniper ones only seem to have 64 megs. While the problems in routing and addressing are generally thought to be primarily in the BGP control plane: http://lists.arin.net/pipermail/ppml/2007-August/008572.html and while I don't know as much as I would like about router FIBs, I really think people who are devising address policy should consider the burden longer PI prefixes place on FIBs of DFZ routers. For instance, each VoIP call (50 packets a second in each direction) between hosts in two IPv6 PI /48 prefixes with 16 DFZ routers en-route involves those routers collectively working through this many bits of destination address per second: 50 * 2 * 48 * 16 = 76,800! This work is really hard, to be done within a microsecond or so, with the fastest and most expensive RAM and CPUs. Cisco had the largest ASIC in history fabricated by IBM to make their FIB for the CRS-1 - 188 32 bit CPUs and heaps of other stuff on one chip. Juniper no-doubt went to similarly Herculean efforts to create their I-chip and to provide fast ( = expensive, low density and power-hungry) RAM so the I-chip could perform well. The router manufacturers say they can do this, and more. No router manufacturer would want to be seen saying that they couldn't cope with higher and higher demands. But they can't cope with growth in the number of advertised prefixes, or in the length of those prefixes, without extremely complex, expensive, brute-force techniques with all the power dissipation and bulk this entails. All Internet users have to pay for all this stuff, and the power the routers dissipate, because we all pay our ISPs to pay other ISPs and transit providers - and they all have to pay big $$$ for routers which can handle these longer and more numerous prefixes. VoIP is supposed to be cheap and lightweight, but to me, with these /48 PI prefixes, it looks like a huge burden on the DFZ routers. So in general, to keep the DFZ routers simple, there should be as few as possible advertised prefixes, with those prefixes being as short as possible (meaning larger blocks of addresses). No-one knows how many DFZ routers there are. The best estimate is from the iPlane project: http://psg.com/lists/rrg/2007/msg00253.html http://psg.com/lists/rrg/2007/msg00262.html Singlehomed routers: 87k Routers in Default Free Zone: 123k Total BGP routers: 210k These are lower bounds: "These numbers are at most a lower bound on the numbers you are looking for, and we have no way to tell how tight this bound is. iPlane data is incomplete because of several reasons, such as limited number of vantage points, blocking of ICMP/UDP by routers, MPLS tunnels,.... And getting realistic numbers for those is an unfeasible task as of now, at least for the entire Internet." It seems the only way of reducing this load on all DFZ routers, while allowing for millions of multihomed end-user networks (and ideally for supporting portable address space for end-user networks which need it) is to surround the DFZ with a ring of Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers, as is proposed with LISP-NERD, LISP-CONS, eFIT-APT or Ivip. Those ITRs and their control system get a hammering, but make life easy for the DFZ routers. This page has links to all these proposals: http://www.firstpr.com.au/ip/ivip/ - Robin From randy at psg.com Sun Aug 19 23:14:35 2007 From: randy at psg.com (Randy Bush) Date: Sun, 19 Aug 2007 17:14:35 -1000 Subject: [ppml] Technical reason why /52,/56,/60,/64 are bad In-Reply-To: References: Message-ID: <46C9071B.2010201@psg.com> >> and who the hell gives arin this wonderful new prerogative to tell me >> how to run my business? and what will you do when i completely ignore >> it because it is none of your business? > This might be a rational reply if we were talking about hinging assignments > on something that had nothing to do with assignments. But evaluating > efficient use of assigned address space when processing a request for > additional address space is just unavoidable for a need-based address > assignment scheme. ahh, so that is why we had A, B, and C space. and ever since CIDR we have been unable to evaluate efficient utilization. now what did i not think of that? sheesh! silly me. randy From bicknell at ufp.org Sun Aug 19 23:33:11 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 19 Aug 2007 23:33:11 -0400 Subject: [ppml] Longer prefixes burden the FIBs of DFZ routers In-Reply-To: <46C906A8.3010204@firstpr.com.au> References: <46C906A8.3010204@firstpr.com.au> Message-ID: <20070820033311.GA23679@ussenterprise.ufp.org> One item I see missing from your post is the effect of "internal prefixes". Most ISP's carry a number of shorter prefixes in their IGP (or in iBGP), which of course has to be pushed down into the forwarding engines of the routers. In the IPv4 world we have /32's for loopbacks, /24-/29's for "critical infrastructure", nameservers, management servers, and the like. In some cases /30 or /31's may be carried throughout some of the network depending on how it's broken up internally. Most IPv6 networks have some similar situations. It may be /64's for critical infrastructure, /128's for loopbacks, and the like. It would be possible to assign /48's minimum everywhere to make this work, but if a company has a 1000 routers (as a very large ISP might), that would require them to use another 10 bits for router loopbacks alone, meaning we've assigned a /38 just out of loopbacks. If you're getting a /32 that's 1/64th of the space they received just for loopback addresses. The way I boil down what you're saying is that "more bits of address space require more expensive hardware". That's surely true. We also have a nice history of manufacturers getting caught on the wrong end of an assumption, vendors in the past who had lookups or cache's built around sizes that did not end up matching real world deployment. We're also early in IPv6's life. While we can't make it too expensive to deploy, we have to keep in mind the technology to foward it is going to get cheaper and cheaper over time. I can only imagine the discussions back in 1986-1988 over how you forward a /32 bit address space when 32 bit CPU's were brand new, memory cost a fortune, etc. At the end of the day, the thing I worry about most is locking into particular sizes. If the vendors are told by the IETF, the RIR's, and/or their customers "we only assign /48's, lookups longer than that can be "expensive" and some event happens in the future to change that assumption the results can be deadly. -- 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 christopher.morrow at gmail.com Sun Aug 19 23:59:17 2007 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Sun, 19 Aug 2007 23:59:17 -0400 Subject: [ppml] Technical reason why /52,/56,/60,/64 are bad In-Reply-To: <46C9071B.2010201@psg.com> References: <46C9071B.2010201@psg.com> Message-ID: <75cb24520708192059n2efdc38fj967414c8157dca53@mail.gmail.com> On 8/19/07, Randy Bush wrote: > ahh, so that is why we had A, B, and C space. and ever since CIDR we > have been unable to evaluate efficient utilization. now what did i not > think of that? sheesh! silly me. and wonderfully again we baked in those classes in the hardware/software! :) I think it'd be nice if we had the option to build networks (ipv6 ones) and supply customers with what they need, but lots of engineering/design time went into making a lot of decisions for us :( So, you can't expect RA to work with prefixes <> 64 bits, but you can't expect RA to do everything we get with DHCP anyway, so maybe that's "ok" ? -Chris From briand at ca.afilias.info Mon Aug 20 00:15:24 2007 From: briand at ca.afilias.info (briand at ca.afilias.info) Date: Mon, 20 Aug 2007 00:15:24 -0400 (EDT) Subject: [ppml] Longer prefixes burden the FIBs of DFZ routers In-Reply-To: <46C906A8.3010204@firstpr.com.au> References: <46C906A8.3010204@firstpr.com.au> Message-ID: <63549.74.122.168.81.1187583324.squirrel@look.libertyrms.com> > TCAM can be as wide as 72 bits, and if the router has enough TCAM > space in its FIB, it doesn't matter how many bits are looked at, > provided they fit within the 72 or 144 bit width of the TCAM. Not quite - the number of entries must fit in the total amount of TCAM memory. The specific entries themselves aren't relegated to only being the full bitwise representation of a prefix, even if that is the simplest scheme for storage and lookup. E.g., alternatives that use some kind of symbol-mapping scheme, or hash scheme, or other way of reducing the maximum number of bits required on a lookup, are one way of reducing both total TCAM memory used, and number of bits per entry. But, even at 144 bits, i.e. two "slots" per v6 prefix compared to one per v4 prefix, if the number of slots used is not unreasonable, TCAM can do the job (and do it in one cycle). > (However TCAM is expensive, power-hungry, must be soldered to the > main board - can't be upgraded - and can be slow to update when the > classification rules need to be changed.) Expensive, yes; power hungry, yes. It is *not* the case that they *must* be soldered to the main board - this per Cisco rep at the last NANOG. And ditto the upgradability. They haven't been made FRUs in the past, but there's nothing intrinsic to them that forces hard-wiring, other than design cost on the board itself. The TCAM standard has advanced, so that the next several generations will have completely compatible pinouts, specifically so that they *can* become FRUs. The main idea would be, upgrade TCAMs to higher density units, and stack more of them in serial on the main board. More total TCAM space, in the same number of "slots". > There's no such thing as a 32 bit lookup unless what you need to > find is a byte or less and if you have 4 gigabytes of RAM to hold > the array, which no router's FIB has. Wrong. Your idea of "what a router is", is just a little limited, which is why you believe this to be the case. Any reasonably big iron server, with multiple PCI-express buses, fast and numerous CPUS, and serious enough chip set, can do the job of "high-end router". 1 x 10GbE per PCI-E bus, nominally 4 or more, and upwards of 512GB of memory, can be put into a (big) box that runs routing software (such as quagga). Been there, done that, as the saying goes, and yes, it can do DFZ level routing and forwarding, with tons of capacity for long prefix lookups. Besides which, there's every reason to believe that one byte can hold enough information for the result of a route lookup. Think index into an array of objects, each of which includes in interface index and MAC address. One byte means 256 such objects, which is likely to be sufficient for the majority of devices holding default-free routing tables. Brian Dickson From briand at ca.afilias.info Mon Aug 20 01:56:38 2007 From: briand at ca.afilias.info (briand at ca.afilias.info) Date: Mon, 20 Aug 2007 01:56:38 -0400 (EDT) Subject: [ppml] IPv4 swamp, mh end-users & IP architectural solutions: LISP/APT/Ivip In-Reply-To: <46C8F677.5010900@firstpr.com.au> References: <46C8F677.5010900@firstpr.com.au> Message-ID: <63780.74.122.168.81.1187589398.squirrel@look.libertyrms.com> > In "Re: [ppml] Policy Proposal: IPv6 Assignment Guidelines" Brian > Dickson wrote, in part: > >> The *only* problem with the IPv4 swamp, was that there were >> multiple assignments to ASNs, that couldn't be aggregated by the >> ASNs. Note that the scope of my comment was swamp-specific. I was not addressing the existence of, cause of, or solutions to, IPv4 routing. And, in fact, the swamp isn't the only source of IPv4 table growth at excessive rates. Other causes have been: - failure to aggregate, deaggregation, and poor aggretation - inability to "force" third parties to employ BCP's - post-CIDR allocations that couldn't be aggregated (the swamp was pre-CIDR) - inability to limit scope of TE-based routing announcements The last item, is addressed in a new proposal for explicitly limiting how far a prefix should be propagated, as-path-limit. > I disagree with the statement that the only problem with IPv4 > routing is that some or many end-user networks (or ASNs in general - > providers and end-users combined) have more than one BGP advertised > prefix which are numerically separated and so can't be aggregated > into a single advertised prefix. There are also problems with > stability, excessive updates for some prefixes and the projected > growth in the number of end-user networks which must be multihomed. I'll ignore the middle two - they're orthogonal to routing table size issues. The last issue, however, is definitely germane. > My understanding of the consensus on ROAP (Routing and Addressing > Problem) is that the biggest single problem is the inability of the > BGP control plane to cope with the growth in the number of > multihomed end-user networks, which could reach into the millions - > even if every network only had one advertised prefix. And here's where thinking in IPv4 mode results in lots of good ideas chasing a place to live, where there are much simpler ideas, that can be implemented *currently*, with *current* technology, in very *simple* methods. They don't require any new protocols, and can be done by the network administrators of the "end-user" networks, with novice-level skill sets, and without the rest of the world needing to know about them. Here's where the break-down occurs, on the "millions and millions" issue: There is *need* for multi-homing, and there is "need" for multi-homing. The difference is, scope. Any organization which provides services for unaffiliated entities, which we can generally refer to as an ISP, might currently be single-homed, but can generally be categorized as *needing* to be multi-homed. It is reasonable to expect, sooner or later, that every ISP will be multihomed. However, the needs of most entities who are entirely self-contained, as far as multi-homing are concerned, get the "quoted" treatment. The fact that there is the ability to proscribe an architecture, with some level of centralized control, means that such an entity can achieve all the benefits of multihoming, without consuming DFZ routing slots. I'll give a specific example, below. I will note in advance, that there is lots of room for improvement over this scheme. However, I hope that my example demonstrates, that reasonable levels of redundancy on upstream connections, reachability, services offered to the world, and independence from vendor implementations and lock-in, mean that this kind of solution should be able to achieve acceptance in the enterprise space. And since I doubt I've covered all the bases, there are probably lots of other ways to do this kind of thing, some of which may even be better. :-) The key thing to remember is - in IPv4, address space is scarce, and not cheap. So, everyone is under the common misconception that you would only ever use one IP address (at most) per device. In IPv6, there's so much address space available, that it is entirely reasonable to presume multiple IPv6 addresses for everything. And that's the key to coming up with multi-homed schemes that scale, that work well, and that don't depend on DFZ slots for the multi-homed. Example of multi-homing without BGP, in an IPv6 world: Pick three colours that work for you, to identify address spaces that company X will use. Call them "red", "blue", and "purple". Say that X has two upstreams, "R" and "B". R uses (IPv6) address space RED, and B uses BLUE. R assigns "red" to X, and B assigns "blue" to X, both out of their respective PI/DFZ blocks. These two small blocks are PA space. They are presumed to be aggregated by R and B, and only exist in the DFZ as the aggregates RED and BLUE. Now, "purple" is a PI block given to X by their RIR. We will show how X can use "purple" to multi-home, without announcing "purple" into the DFZ. And, X will be able to do this and achieve all the benefits of multi-homing. What X does, is partition "purple" into 2 (or more) blocks. One block, p1, is used for 1:1 NAT with "red", the other, p2, for 1:1 NAT for "blue". X can have any topology it likes, internally and upstream; we will presume that for redundancy reasons, links to R and B are on different routers. X1 connects to R, and X2 to B. The main thing X will need, is a DNS infrastructure that supports "views", where the results returned can be configured to vary based on the source of the query. The DNS servers will need addresses on all three blocks, "red", "blue", and "purple". The global DNS served by X, will need to be advertised via those name servers only. Everything behind/beneath that, will need to be delegated by, or served by, those name servers, using the same "view" model. Any query via X1 needs to be given an answer with short TTL, and an address on the "red" block. Any query via X2 does the same, only from "blue". Thus, all other traffic follows the path established by the DNS servers, and inbound traffic to non-DNS infrastructure gets 1:1 NAT'd to "purple" addresses at either X1 or X2. This is all long and confusing, I know - but here's the end result: - if X1 or R goes away, the global DNS queries will "hunt" to "blue" addresses for the DNS servers, and "blue" answers will get returned - for X2/B, vice-versa occurs - the result of this is that, as long as one of the upstreams is available, bidirectional availability is assured - TE types of ingress/egress optimizations can be performed on source and/or destination by X1 and X2 - because the NAT is 1:1, it is suitable for every kind of service - any underlying service that cannot tolerate IP NAT, can be un-NAT'd at the other end, by reversing the 1:1 NAT function (since it is deterministic) Renumbering becomes very scalable, since the scope of renumbering the PA space(s) used, is limited to the core portions of the DNS infrastructure, and the routers X1 and X2 (and X3... if they exist). No renumbering of anyting in "purple" space is ever needed. And, all of this, while using PI space under the hood, for convenience purposes, does not require that the PI space be put in the DFZ. The un-NAT-ing that may be necessary, for things that require that the IP address be used as an identifier, does require sharing information about the PI block - but the scope of that is small compared to the size of the DFZ. And more importantly, that can effectively be a "shared secret". It's a feature, not a bug. The un-NAT stuff can even be implemented on a host basis, nearly trivially. I agree (before anyone needs to say it) that this won't work for ISPs, since the assignments/delegations that exist cross administrative boundaries. But I'd offer the opinion, that multi-homed non-ISPs are likely to outnumber multi-homed ISPs, by one or more orders of magnitude. And conversely, techniques such as this, while necessary to conserve the DFZ, can in fact do so. The fact that this can be done today, is all the more reason to push the ideas here, and start educating folks on the benefits of 1:1 NAT, use of PA space, and use of clever DNS tricks to handle reliability and availability requirements. Brian Dickson From rw at firstpr.com.au Mon Aug 20 05:14:32 2007 From: rw at firstpr.com.au (Robin Whittle) Date: Mon, 20 Aug 2007 19:14:32 +1000 Subject: [ppml] Longer prefixes burden the FIBs of DFZ routers In-Reply-To: <20070820033311.GA23679@ussenterprise.ufp.org> References: <46C906A8.3010204@firstpr.com.au> <20070820033311.GA23679@ussenterprise.ufp.org> Message-ID: <46C95B78.50301@firstpr.com.au> Hi Leo, You wrote, in part: > In the IPv4 world we have /32's for loopbacks, /24-/29's for "critical > infrastructure", nameservers, management servers, and the like. In > some cases /30 or /31's may be carried throughout some of the network > depending on how it's broken up internally. > > Most IPv6 networks have some similar situations. It may be /64's > for critical infrastructure, /128's for loopbacks, and the like. I didn't mention these, because I assume - perhaps wrongly - that these don't carry the burden of Internet traffic. It is my impression that when an FIB in a router is handling a packet which matches a /32 prefix which is for that router's IP address, or some other router's IP address, that the packet is most likely to be a BGP message between the routers or some configuration, logging traffic etc. Based on this, I figure it is not such a problem if the router's FIB takes a few more memory read cycles to classify the packet. > The way I boil down what you're saying is that "more bits of address > space require more expensive hardware". That's surely true. Yes - so I am keen to see address assignment policy for PI space not place too much of a burden on routers in the future. > We > also have a nice history of manufacturers getting caught on the > wrong end of an assumption, vendors in the past who had lookups or > cache's built around sizes that did not end up matching real world > deployment. If I was designing a router - which I am not - I would want to know what length prefix to optimise the performance for. It would be no good saying "Sometimes the router needs to handle /128 so the router must be optimised to forward packets to /128 prefixes" when in reality, most of the traffic would be to /32 to /48. The costs, complexity and power dissipation of optimising for /128 would surely lead to a more expensive an more unfriendly outcome than for something which was optimised for /48, but could do /128 less efficiently. > We're also early in IPv6's life. While we can't make it too expensive > to deploy, we have to keep in mind the technology to foward it is > going to get cheaper and cheaper over time. I can only imagine the > discussions back in 1986-1988 over how you forward a /32 bit address > space when 32 bit CPU's were brand new, memory cost a fortune, etc. I don't think that the last three decades of extraordinary progress in semiconductors can be used as a guide to the next decade or so. Current technologies are pushing fundamental physical limits, not just the ability to manufacture things smaller. There is only limited prospect for making things faster, cheaper, less power hungry etc. by reducing the transistor size further. > At the end of the day, the thing I worry about most is locking into > particular sizes. If the vendors are told by the IETF, the RIR's, > and/or their customers "we only assign /48's, lookups longer than > that can be "expensive" and some event happens in the future to > change that assumption the results can be deadly. I think it would be a very good idea for the IETF and the RIRs to decide, very carefully on something exactly like this. I think the IETF and the RIRs should be able to decide that under no circumstances would IPv6 address policy in the next decade or two require DFZ routers to look at any more than 48 bits of address for Internet traffic. It shouldn't be hard to decide that such a limit is realistic. Then routers can be built to efficiently handle this - to be optimised for actual traffic in for foreseeable future, not some much more expensive and unnecessary goal, such as being optimised for /64 or /128. - Robin From rw at firstpr.com.au Mon Aug 20 05:20:40 2007 From: rw at firstpr.com.au (Robin Whittle) Date: Mon, 20 Aug 2007 19:20:40 +1000 Subject: [ppml] IPv4 swamp, mh end-users & IP architectural solutions: LISP/APT/Ivip In-Reply-To: <63780.74.122.168.81.1187589398.squirrel@look.libertyrms.com> References: <46C8F677.5010900@firstpr.com.au> <63780.74.122.168.81.1187589398.squirrel@look.libertyrms.com> Message-ID: <46C95CE8.5020008@firstpr.com.au> Hi Brian, Thanks for your detailed response. I interpret the term "IPv4 swamp" more broadly than you do, I think. Most of your message concerns a proposal for IPv6 multihoming involving PI space which is not advertised. I hadn't heard of this proposal before. If you are really confident it would be widely accepted by end-users - and I agree with you on this: > But I'd offer the opinion, that multi-homed non-ISPs are likely to > outnumber multi-homed ISPs, by one or more orders of magnitude. - then I suggest you write it up as in Internet draft and/or present it to the RAM mailing list, where solutions to this multihoming problem are badly wanted. http://www1.ietf.org/mailman/listinfo/ram My initial critique of your proposal, which I only partially understand, is that firstly it involves NAT - which will probably make most people want to run the other way - and that secondly it involves fussy DNS arrangements. As far as I can see, the proposal doesn't provide for continuity of sessions on existing IP addresses - which is part of what most people require in "multihoming". Also, the requirement for special arrangements for some protocols, being handled in the hosts, sounds all too messy. If there were any serious prospect of end-users being happy to multihome IPv6 by SHIM6 or any other system other than using BGP and PI space as they do now with IPv4, then I can't imagine that ARIN, AfriNIC or RIPE would have reversed the long-standing policy of denying end-user networks PI space. There are still people, with decades of experience, who hold out hope that IPv6 multihoming can be achieved with SHIM6 of by some other method which does not involve PI space. However I think it is easy to prove this is unrealistic Having got a bunch of hosts configured and running, with a network set up with some addresses, the operator simply requires that the network keep running without any fuss, when the link from one ISP goes down and they decide to use a link to another ISP. The very last thing the end-user network can tolerate is a sudden change in addresses or the requirement that a bunch of hosts figure something out, or that they be told to do things differently. Hosts are extremely diverse, from massive servers, to old, obsolete machines, to IPv6 lightswitches etc. - many of which have no prospects for keeping their operating systems or application programs up to date. For end-users who, in their own judgement, need multihoming, the requirement is simple: The solution must not involve fancy software in correspondent hosts, special arrangements for certain protocols, any changes at all for the hosts on the network etc. The network needs to have a publicly reachable block of addresses and when one link goes down the packets need to flow on the other link ASAP. In short, they need their own PI space they can use with any ISP and they need a way of quickly switching the "routing system" (including any additional architectural elements such as are being discussed on the RAM list) so the packets go via a different ISP. I don't think it does any good trying to pretend that end-users will be happy with anything less, or anything more complex and therefore unreliable. The two ways of achieving that we know about are the conventional PI and BGP approach - which places unsustainable burdens on every DFZ router - or some scheme such as LISP, eFIT-APT or Ivip etc. I think these are all ugly, problematic, kludges - but at least they don't burden all DFZ routers. - Robin From izumi at nic.ad.jp Mon Aug 20 05:49:38 2007 From: izumi at nic.ad.jp (Izumi Okutani) Date: Mon, 20 Aug 2007 18:49:38 +0900 Subject: [ppml] Policy Proposal: End Policy for IANA IPv4 allocations to RIRs In-Reply-To: <1D09261C-79D9-45B2-8494-F8AD1E1E6B3B@delong.com> References: <46C5BC8F.7090302@arin.net> <0BBD347F-1FC5-41D1-989D-69E09EA15A62@delong.com> <46C5C1F5.7020005@arin.net> <1D09261C-79D9-45B2-8494-F8AD1E1E6B3B@delong.com> Message-ID: <46C963B2.3050405@nic.ad.jp> Thanks for the comments to our proposal. I've replied inline; >> Owen DeLong wrote: >>> I am neutral on this policy. I don't support it, but, I have no >>> strong opposition >>> to it, either. >>> However, I do wish to address some of the items contained in the >>> narrative. >>> First, I think it is absolutely essential that each RIR >>> communicate the impending >>> IPv4 free pool exhaustion to their constituency. I believe this >>> is happening and >>> I do not believe this policy would affect that in any way. You're probably right. It's something that is likely to happen in the actual practice anyway. The idea behind it is to give a better idea to each community when their respective RIR's free pool will be exhausted by defining how the IANA pool will be distributed. It may also help in RIRs coordination by providing ideas on what is agreeable to the community. >>> Second, the assertion that current policy is a globally >>> coordinated policy >>> is absurd. Each RIR sets its own policy for allocation and >>> assignment >>> today. All that is globally coordinated currently is the policy >>> on how >>> the IANA allocates to RIRs. While I don't mind dividing the last 5 If that's already the current policy pracitce, that's fine. This may be stating the obvious, but we weren't sure if the idea is shared by everyone and wanted to make it clear. (We assumed a certain level of co-ordination in RIR policies is considered desirable as an unwritten practice) >>> /8s evenly amongst the 5 RIRs (perhaps this policy should state >>> the last N /8s where N is the current number of RIRs at the time N >>> is reached, but, I don't anticipate N changing from 5 between now >>> and then), I don't see the effect of this as being significantly Point taken. N is already used by LACNIC proposal with a different definition, so we can define the number as "R" to avoid the confusion; ---- distribute a single /8 to each RIR when free IANA IPv4 address pool hits R, where R= no. of RIRs at the time of exhaustion (It is currently five) ---- >>> different >>> from what will likely happen naturally in the course of current >>> IANA- >RIR >>> policy. >>> What this policy achieves is that each RIR clearly knows when it has >>> received its last /8 from the IANA and knows which /8 that is. If we >>> continue to follow current IANA->RIR practices, I believe that the >>> IANA >>> and RIRs will have a pretty good idea when that point is reached as >>> well, with the possible surprise that some RIRs may receive one more >>> allocation round than they expected to. >>> Personally, I am much more concerned about the RIR policies to deal >>> with RIR Free Pool exhaustion process. I'm pretty sure that IANA and >>> RIRs can handle the IANA free pool exhaustion appropriately under >>> existing policy, but, I don't regard this policy as harmful to >>> that process. Thanks for the imput. I agree that distribution of RIR free pool would have a more direct impact to the community than that of the IANA pool. We are plannning to propose a policy for RIR-->LIR distribution in the APNIC region as the next step, and this is just a first step to move to the next. As mentioned in our proposal, we believe RIR-->LIR distribution policy should be defined by each region to best match each region's requirements, so it will be left up to ARIN community to decide what to do with the last few blocks of free ARIN pool. Hope this clarifies some of the ideas behind the proposal. Izumi >>> Owen >>> On Aug 17, 2007, at 8:19 AM, 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: End Policy for IANA IPv4 allocations to RIRs >>>> >>>> Author: JPNIC IPv4 countdown policy team; >>>> Akinori MAEMURA >>>> Akira NAKAGAWA >>>> Izumi OKUTANI >>>> Kosuke ITO >>>> Kuniaki KONDO >>>> Shuji NAKAMURA >>>> Susumu SATO >>>> Takashi ARANO >>>> Tomohiro FUJISAKI >>>> Tomoya YOSHIDA >>>> Toshiyuki HOSAKA >>>> >>>> Proposal Version: 2 >>>> >>>> Submission Date: 2007/08/17 >>>> >>>> Proposal type: new >>>> >>>> Policy term:renewable >>>> >>>> Policy statement: >>>> >>>> 1) Distribute a single /8 to each RIR at the point when new IANA >>>> free >>>> pool hits 5 */8. This date is defined as "IANA Exhaustion Date". >>>> >>>> 2) It should be completely left up to each RIR communities to >>>> define a >>>> regional policy on how to distribute the remaining RIR free >>>> pool to >>>> LIRs within their respective regions after "IANA Exhaustion >>>> Date". >>>> >>>> Note 1: It is fine for an RIR to continue operations with the >>>> existing policy if that is the consensus decision of the >>>> respective RIR community. >>>> >>>> Note 2: Address recovery and re-distribution of recovered >>>> address >>>> space is another important measure for >>>> considerations, but >>>> should be treated as a separate policy proposal from >>>> distribution of new IANA pool. >>>> >>>> 3) RIRs should provide an official projection on IANA Exhaustion >>>> Date >>>> to the community through their website, at their Policy Meetings >>>> and through any other effective means. >>>> >>>> >>>> Rationale: >>>> [current problem] >>>> There are two major issues in terms of address management if no >>>> measures >>>> are taken for IPv4 address exhaustion. >>>> >>>> 1) Continue applying a global coordinated policy for >>>> distribution of the >>>> last piece(s) of RIR's unallocated address block does not >>>> match the >>>> reality of the situation in each RIR region. >>>> >>>> Issues each RIR region will face during the exhaustion >>>> period vary by >>>> region as the level of development of IPv4 and IPv6 are widely >>>> different. As a result, applying a global co-ordinated >>>> policy may not >>>> adequately address issues in a certain region while it could >>>> be work >>>> for the others. >>>> >>>> For example, in a region where late comers desperately need even >>>> small blocks of IPv4 addresses to access to the IPv4 Internet, a >>>> policy that defines the target of allocations/assignments of >>>> IPv4 >>>> address space to be late comers would be appropriate in such >>>> region. >>>> This would allow availablilty of IPv4 address space for such >>>> requirements for more years. >>>> >>>> Another example comes from difference in IPv6 deployment rate. >>>> For a region where IPv6 deployment rate is low, measures may be >>>> necessary to prolong IPv4 address life for the existing >>>> business as >>>> well as for new businesses until networks are IPv6 ready. Some >>>> regions may have strong needs to secure IPv4 address space for >>>> translators. >>>> >>>> A globally coordinated policy which addresses all the issues >>>> listed >>>> above to meet the needs for all RIR regions may result in >>>> not solving >>>> issues in any of the regions. >>>> >>>> 2) LIRs and stakeholders remain unprepared for the situation if >>>> they are >>>> not informed >>>> >>>> If LIRs and the community are uninformed of the exhaustion, >>>> their >>>> services and networks remain unprepared to face the >>>> situation at the >>>> time of exhaustion. >>>> >>>> [Objective of the proposal] >>>> This proposal seeks to provide the following solutions to the >>>> problems >>>> listed above. >>>> >>>> 1) RIR community should be able to define their own regional >>>> policies on >>>> how to assign the last piece(s) of allocation block in order to >>>> address their own regional issues during the exhaustion period. >>>> >>>> 2) RIRs should provide official projection of the date when LIRs >>>> will be >>>> able to receive the allocations under the current criteria. The >>>> criteria should remain consistent until this date in order >>>> to avoid >>>> confusion. >>>> >>>> [Pros and Cons] >>>> Pros: >>>> + It allows each RIR community to define a policy on how to >>>> distribute >>>> the last piece(s) of allocations which best matches their >>>> situation. >>>> >>>> + It helps LIR better informed of the date when they are able to >>>> receive >>>> allocations from RIRs under the current criteria and prepare >>>> for the >>>> event. >>>> >>>> Cons: >>>> + Concerns could be raised about allocating a fixed size to all >>>> RIRs, >>>> that it artificially fastens the consumption rate of some RIR >>>> regions. >>>> However, its impact is kept to minimum by keeping the >>>> allocation size >>>> to a single /8 which makes merely 3-4 months difference. >>>> >>>> + Concerns could be raised that explicitly allowing regional >>>> policies >>>> will encourage RIR shopping. However, this should not happen >>>> if the >>>> requirements within each region is adequately reflected in >>>> each RIR's >>>> policy through PDP. RIR may also chose to add criteria to >>>> prevent LIRs >>>> from other regions submitting such requests. >>>> >>>> >>>> Timetable for implementation: >>>> Immediate after all 5 RIRs (and possibly ICANN) ratifies the 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. > > _______________________________________________ > 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 michael.dillon at bt.com Mon Aug 20 06:15:39 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 20 Aug 2007 11:15:39 +0100 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <46C5E72F.2080903@arin.net> References: <46C5E72F.2080903@arin.net> Message-ID: > Policy Proposal Name: IPv6 Assignment Guidelines > LIR's may assign blocks in the range of /48 to /64 to end sites. > All assignments made by LIR's should meet a minimum HD-Ratio of .25. I am opposed to tinkering with the IPv6 HD ratio at this point. The IPv6 HD ratio exists to deal with the case where an LIR returns to ARIN for their SECOND allocation. Because there is so little IPv6 deployment at present, I do not believe we have the data necessary to assess whether or not this is a problem which needs to be addressed. > * /64 - Site needing only a single subnet. > * /60 - Site with 2-3 subnets initially. > * /56 - Site with 4-7 subnets initially. > * /52 - Site with 8-15 subnets initially. > * /48 - Site with 16+ subnets initially. I oppose making the IPv6 assignment process more complex than it already is. We introduced the /56 to deal with a well-defined risk that MIGHT arise in the future. There is no evidence that the current regime will lead to IPv6 runout in our lifetimes. In addition, this proposal applies IPv4 thinking to IPv6. In general this is a bad thing because it delays the education process which ARIN is supposed to be supporting. > LIR's do not need to issue all 5 sizes of prefixes as long as > the HD-Ratio requirement is met. Making IPv6 ISP's lives complicated is not an appropriate action for ARIN at present considering the impending runout of IPv4 addresses. If clearer guidance is needed, then we could simply add language such as: /56 for small sites such as consumer subscribers and private homes which are expected to need only a few subnets over the next 5 years. --Michael Dillon From bmanning at vacation.karoshi.com Mon Aug 20 09:31:13 2007 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 20 Aug 2007 13:31:13 +0000 Subject: [ppml] hoarding (was Policy Proposal: Expand timeframe ofAdditional Requests) In-Reply-To: References: Message-ID: <20070820133113.GA5923@vacation.karoshi.com.> > That is the crux of the issue. The hoarders are already there. They have > a stock of legacy IP addresses that they are sitting on in the hopes > that a market can develop. Because these legacy addresses are not > registered, we don't even know who these players are. as a holder of legacy IP space, i object to your characterization. i did not get my blocks w/ an expectation of "a market" - i got them because i had a defensable use for them. regarding registration, i'm pretty sure there are records for (nearly) all assignments/delegations so i'm not understanding your claim that legacy addresses are "not registered".... > You've hit the nail on the head. The big difference between legacy > holders and ARIN holders is that ARIN holders are playing by the rules, > negotiating a common agreement with each other on a level playing field. > The legacy holders are hiding in the shadows relying on vague threats of > legal action. I believe that when push comes to shove, the U.S. > government will come out on the side of an orderly regime (not market) > because that is generally what the USG supports. For instance, SEC, WTO, > Sarbanes-Oxley. Until the Department of Commerce formally makes a > statement to the contrary, I believe that if early court cases do not > establish the supremacy of ARIN rules over legacy holders, then the DOC > will step in and move things in that direction. The best that legacy > holders can hope for is that there will be a ruling which gives them a > short time to come into compliance and show that their legacy > allocations are in fact, in accordance with ARIN rules. legacy address holders are "playing by the rules" that were in effect when they received their assignments. again i find your characterizations objectionable. what arin (and by extention the other RIR's and the IANA) need to do and to my understanding is doing is to haromize the legacy rules w/ current RIR procedures - then ensure that outreach is done to bring the legecy holders onboard. ARIN is doing a very good job in opening a dialog w/ legacy holders and is being careful, prudent, and deliberate in its steps to include legacy holders within the ARIN framework. your characterization has the tenor of a hostile standoff - requireing government intervention. i believe that the evidence thus far does not support your claims or beliefs. one could view your statements as trying to incite a "siege" mentality ... us v. them. which if correct would be, IMHO, entirely wrong. we -users of IP resources- are in this together and need to cooperate. > --Michael Dillon --bill manning From bicknell at ufp.org Mon Aug 20 10:13:47 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 20 Aug 2007 10:13:47 -0400 Subject: [ppml] Longer prefixes burden the FIBs of DFZ routers In-Reply-To: <46C95B78.50301@firstpr.com.au> References: <46C906A8.3010204@firstpr.com.au> <20070820033311.GA23679@ussenterprise.ufp.org> <46C95B78.50301@firstpr.com.au> Message-ID: <20070820141347.GA69608@ussenterprise.ufp.org> In a message written on Mon, Aug 20, 2007 at 07:14:32PM +1000, Robin Whittle wrote: > I didn't mention these, because I assume - perhaps wrongly - that > these don't carry the burden of Internet traffic. It is my > impression that when an FIB in a router is handling a packet which > matches a /32 prefix which is for that router's IP address, or some > other router's IP address, that the packet is most likely to be a > BGP message between the routers or some configuration, logging > traffic etc. I am rather sure this assumption is wrong, at least for IPv4. I'm not sure we have enough IPv6 experience to know if it is wrong for IPv6 as well. In IPv4 it would not be uncommon for an ISP to use a /32 "virtual address" to hit a pile of load balancers for a Usenet farm, or a VoIP switch farm, webmail front ends, or a streaming video farm. Many people put their caching resolvers all on virtual IP's and anycast them internally with BGP to provide more resiliency. /32's are used in IPv4 because the hardware can handle it, and we're all taught from birth to conserve space. In IPv6 could those all become /64's or /48's? On most of the IPv6 networks I've seen today people are at least playing with /128's for similar concepts, /126's and /127's for P2P links, and /112's for small lans. Will they survive the "test stage", who knows. But even if your assumption was right, it's wrong. That is to say if the only "expensive" operation was packets to my router loopbacks for iBGP it might look ok to have those lookups take more time in steady state. However all it takes is an attacker finding those addresses and DDoSing them with packets to make that not work. If the lookups are more expensive, the result is a much more attractive attack target. > If I was designing a router - which I am not - I would want to know > what length prefix to optimise the performance for. It would be no > good saying "Sometimes the router needs to handle /128 so the router > must be optimised to forward packets to /128 prefixes" when in > reality, most of the traffic would be to /32 to /48. I'm quite afraid this sounds like early IPv4 routers. They did Class A's, B's, and C's quite well, and some of them when you put in other length prefixes fell over. I suppose it looked like a good trade off for the software and hardware of the day; and in fact it might have been the right choice to get us where we are today. Those designs didn't last well though, and got fork lifted out when a problem occurred. > I think it would be a very good idea for the IETF and the RIRs to > decide, very carefully on something exactly like this. I think the > IETF and the RIRs should be able to decide that under no > circumstances would IPv6 address policy in the next decade or two > require DFZ routers to look at any more than 48 bits of address for > Internet traffic. A very interesting idea. I think a "decade or two" may be too long, but given we are in the early phases it may be worth considering your idea. I'm afraid it would have to be a global policy to mean something to the vendors, but perhaps a "under no circumstances will RIR's require prefixes longer than /XX before 2015" might be a way to reduce deployment costs. Of course, the trap is that if that assumption is built into hardware, and 2015 comes in a lean time there will be great pressure to keep it for economic reasons... From my own talking to vendor reps they are trying to may some hay with the fact that IPv6 routes are quite sparse relative to the address space. In particular, even if you cut off at /112, there are likely to be no routes in the /64-/112 space as currently deployed. Also, I believe the largest current allocation is a /21, so it's probably unlikely to have a route < /18. If we look just at those ranges, we're down to a space of 54 bits that are likely to be present in routes (18-64, 112-128). 54 bits is a lot more tractable than 128, and fits well within the 72 bit TCAM space. With a good method of hashing (in hardware) this could be done, and leave a pretty good chance that prefixes of the "unlikely lengths" would not cause significant problems until there were a lot of them. I would love to have reps from Cisco and Juniper (Foundry, Extreme, Force 10?) come to an ARIN meeting and give some information on how they handle forwarding IPv6 packets, and if ideas like your prefix length limit help them in a significant way or not. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From info at arin.net Mon Aug 20 10:29:07 2007 From: info at arin.net (Member Services) Date: Mon, 20 Aug 2007 10:29:07 -0400 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses Message-ID: <46C9A533.5090808@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: Decreasing Exponential Rationing of IPv4 IP Addresses Author: Dean Anderson Proposal Version: 1 Submission Date: 8/18/07 Proposal type: new Policy term: renewable Policy statement: ARIN will ration the remaining available IP Address Space according to a decreasing exponential function in the family of e^(-x), where the ultimate function and factors are chosen to ensure that the remaining IP address space lasts for at least 10 years. This function will be used to limit the IP Address space allocations. If IP Address Space becomes available (e.g. via return), the ration can be recalculated. However, Ration calculations will not be based on projected or anticipated returns. Contested IP Address Space will also be excluded from the amount of available Address Space for ration calculations. Rationale: Two reports[1,2] project that IP Addresses will be exhausted around March 2010. * Both reports agree that if IP Addresses continue to delegated at the present rates, we will run out of space in March 2010. * Everyone seems to agree that depletion will be a very bad event. * It is therefore imperative to begin rationing to slow down the rate of new delegations to conserve the available address space. * It is necessary to do this now. One can't start rationing after the resources run out. Sudden IPv4 IP Address Exhaustion is expected to cause sudden disruption and discontinuity in business operations and planning. As with other limited resources, the mere anticipation of exhaustion will lead to hoarding and other behaviors that increase the harm of a sudden exhaustion. Rationing on a decreasing exponential will essentially prevent total exhaustion and will gradually decrease the rate of IP Address delegation so to alleviate the harms of a sudden stop in IP Address delegation. Prevention of IPv4 IP Address Exhaustion will help ensure a smooth transition to IPV6. Rationing helps ensures that IP Address space remains available to future needs. [1] http://www.potaroo.net/tools/ipv4/index.html [2] http://www.tndh.net/~tony/ietf/ipv4-pool-combined-view.pdf Timetable for implementation: Immediate From owen at delong.com Mon Aug 20 10:41:36 2007 From: owen at delong.com (Owen DeLong) Date: Mon, 20 Aug 2007 07:41:36 -0700 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: <46C9A533.5090808@arin.net> References: <46C9A533.5090808@arin.net> Message-ID: <8E3ECA76-1A7F-4810-A845-6E8C0F009088@delong.com> I oppose this policy. The exhaustion of the IPv4 free pool will have minimal effect on existing operations. Rationing would have a much more detrimental effect. Extending the life of the IPv4 free pool through artificial constraints on current growth of the network will not provide any meaningful benefit to the community. Owen From bicknell at ufp.org Mon Aug 20 10:43:09 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 20 Aug 2007 10:43:09 -0400 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 In-Reply-To: <01f101c7e153$7e794380$6601a8c0@atlanta.polycom.com> <46C671B2.60800@internap.com> <46C611F1.6030506@eagle.ca> <46C5EA0B.3030304@spaghetti.zurich.ibm.com> <46C5E72F.2080903@arin.net> References: <65554.1187454487@sa.vix.com> <7ACF4793-A13A-454B-AD93-72A243466340@virtualized.org> <20070818182614.GA1870@ussenterprise.ufp.org> <454810F09B5AA04E9D78D13A5C39028A02A4C832@nyrofcs2ke2k01.corp.pvt> <46C611F1.6030506@eagle.ca> <46C5E72F.2080903@arin.net> <46C5EA0B.3030304@spaghetti.zurich.ibm.com> <46C5E72F.2080903@arin.net> Message-ID: <20070820144309.GA72252@ussenterprise.ufp.org> In a message written on Fri, Aug 17, 2007 at 07:33:47PM +0100, Jeroen Massar wrote: > The /56 is perfect for residential sites aka Joe Average HomeUser. > The /48 should IMHO be provided to 'businesses' and other such > organizations. In a message written on Fri, Aug 17, 2007 at 05:24:01PM -0400, Steve Bertrand wrote: > > I can live with a two-tiered scheme in which all consumer > > homes have a /56 and all non-consumer sites have a /48 because sites > > rarely will switch categories. > > I support the previous statement. Clean and easy. In a message written on Sat, Aug 18, 2007 at 03:10:07PM -0700, David Conrad wrote: > Given the IETF mandate for /64s for subnets, number of PCs is > irrelevant. I don't have a strong opinion about /48s to every > customer as I can see arguments on both sides. It would be easier > for everybody and (assuming RIR to ISP allocations become more > rational) I don't have concerns about running out of /48s. However, > pragmatically speaking, I also don't see home users ever subnetting > to a significant level, so it doesn't make a lot of sense to me to > throw a potential of 64K subnets at them. As such the "/56 for home > users - /48 for enterperise" split seems a reasonable compromise. In a message written on Fri, Aug 17, 2007 at 09:12:34PM -0700, Scott Leibrand wrote: > As expressed by others, I oppose this policy proposal as written, > because I believe current guidelines are sufficient. ISPs should be > free to delegate a /48 or /56 to users, as appropriate for their > situation. I believe that any justification, including convenience, > should be sufficient to allow allocation of a /48 instead of a smaller > subnet. In a message written on Fri, Aug 17, 2007 at 11:35:56PM -0500, Stephen Sprunk wrote: > Agreed. Current policy allows LIRs to assign either, and there should be no > penalty for LIRs that choose to use either /56s or /48s. There is no > shortage of anything but routing slots in IPv6. In a message written on Sat, Aug 18, 2007 at 09:41:40AM -1000, Antonio Querubin wrote: > This adds unnecessary granularity to the assignment guidelines as well as > perpetuates administrative complexity for LIRs. The /56 recommendation > for 'small' sites was a welcome addition when it came but adding 2 more > levels doesn't really add much value. Let's keep it simple. In a message written on Mon, Aug 20, 2007 at 11:15:39AM +0100, michael.dillon at bt.com wrote: > If clearer guidance is needed, then we could simply add language such > as: > > /56 for small sites such as consumer subscribers and private homes which > are expected to need only a few subnets over the next 5 years. The feedback is pretty clear, and so I'd like to offer up a straw man for a potentially better proposal. It's quite clear people want a simple rule, and want a /48 to be allowed. For reference, the existing policy is at http://www.arin.net/policy/nrpm.html#six54 Looking at the comments and considering the section following as well (6.5.4.2) I've combined them both into a single policy. While I find it unlikely ISP's will have customers wanting more than a /48 of PA space, the current policy states that such cases will be reviewed by the RIR without giving any criteria for how they should be reviewed, leaving both staff and the ISP with no guidance. Should such a larger block be needed it seemed logical to me to apply the same criteria as if the End Site came to ARIN for their own PI or PA block. ] 7. Policy statement: ] ] Delete the text in 6.5.4.2 and Replace the text in section 6.5.4.1 ] with the following text: ] ] LIR's may assign up to a /48 to an End Site. End Sites requiring ] more address space than a /48 may be assigned a larger block provided ] the utilization inside that block meets an HD Ratio of 0.94. ] ] 8. Rationale: ] ] The existing section 6.5.4.1 does not provide clear guidance on how ] large of a prefix to allocate to a site. This makes it difficult ] for LIR's to know they are in compliance with the rules, and makes ] it harder for ARIN staff to evaluate requests per the communities ] wishes. Would this straw man proposal get more support? Does it provide clearer guidance? -- 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 Mon Aug 20 11:08:22 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 20 Aug 2007 16:08:22 +0100 Subject: [ppml] hoarding (was Policy Proposal: Expand timeframe ofAdditional Requests) In-Reply-To: <20070820133113.GA5923@vacation.karoshi.com.> References: <20070820133113.GA5923@vacation.karoshi.com.> Message-ID: > your characterization has the tenor of a hostile > standoff - requireing > government intervention. i believe that the evidence > thus far does not > support your claims or beliefs. one could view your > statements as > trying to incite a "siege" mentality On the contrary. I am trying to point out that those who claim the courts will inevitably grant property rights to address holders, are making a very big assumption with a very weak foundation. There is reason to believe that if anyone takes the matter to the courts, they will basically support ARIN. >... us v. them. > which if correct > would be, IMHO, entirely wrong. we -users of IP > resources- are in this > together and need to cooperate. Most users of IP resources *ARE* cooperating and ARIN is at the heart of that. --Michael Dillon From arin-contact at dirtside.com Mon Aug 20 11:13:32 2007 From: arin-contact at dirtside.com (William Herrin) Date: Mon, 20 Aug 2007 11:13:32 -0400 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: <46C9A533.5090808@arin.net> References: <46C9A533.5090808@arin.net> Message-ID: <3c3e3fca0708200813u519aec73l99df3dd7ac99f4db@mail.gmail.com> On 8/20/07, Member Services wrote: > Policy Proposal Name: Decreasing Exponential Rationing of IPv4 IP Addresses I oppose this proposal on the grounds that it does not provide actionable policy which staff can follow. Dean: Specifics, specifics, specifics. What exactly does this mean in terms of how many addresses can be given to organizations given what documented or audited utilizations and when? And if you want to throw in a bone about contested IP address space, you first need to explicitly define how one contests space. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From michael.dillon at bt.com Mon Aug 20 11:36:36 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 20 Aug 2007 16:36:36 +0100 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 In-Reply-To: <20070820144309.GA72252@ussenterprise.ufp.org> References: <65554.1187454487@sa.vix.com><7ACF4793-A13A-454B-AD93-72A243466340@virtualized.org><20070818182614.GA1870@ussenterprise.ufp.org><454810F09B5AA04E9D78D13A5C39028A02A4C832@nyrofcs2ke2k01.corp.pvt><46C611F1.6030506@eagle.ca> <46C5E72F.2080903@arin.net><46C5EA0B.3030304@spaghetti.zurich.ibm.com><46C5E72F.2080903@arin.net> <20070820144309.GA72252@ussenterprise.ufp.org> Message-ID: > ] LIR's may assign up to a /48 to an End Site. End Sites > requiring ] more address space than a /48 may be assigned a > larger block provided ] the utilization inside that block > meets an HD Ratio of 0.94. I object to this use of the HD Ratio. Unless ARIN policy is changed to require all ISPs to regularly report their IPv6 utilization and current HD ratio, then I think ARIN should not require ISPs to "meet" an HD Ratio. Many ISPs will be getting an IPv6 allocation with the expectation that they will never come back for another allocation, or at least not for many years. In that time, the HD Ratio requirement could well be removed or changed. It is a burden to require ISPs to track that HD Ratio. If ARIN wishes to impose the burden it must be done openly and explicitly, not tacked on to another policy change. > ] The existing section 6.5.4.1 does not provide clear > guidance on how ] large of a prefix to allocate to a site. > This makes it difficult ] for LIR's to know they are in > compliance with the rules, and makes ] it harder for ARIN > staff to evaluate requests per the communities ] wishes. The existing language should really refer to RFC 3177 and then point out that we have an additional size of assignment (/56) which replaces the existing statement: Home network subscribers, connecting through on-demand or always-on connections should receive a /48. With this: Home network subscribers, connecting through on-demand or always-on connections should receive a /56. -- Michael Dillon From dlw+arin at tellme.com Mon Aug 20 11:45:50 2007 From: dlw+arin at tellme.com (David Williamson) Date: Mon, 20 Aug 2007 08:45:50 -0700 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 In-Reply-To: References: <20070820144309.GA72252@ussenterprise.ufp.org> Message-ID: <20070820154550.GB28312@shell01.cell.sv2.tellme.com> On Mon, Aug 20, 2007 at 04:36:36PM +0100, michael.dillon at bt.com wrote: > > ] LIR's may assign up to a /48 to an End Site. End Sites > > requiring ] more address space than a /48 may be assigned a > > larger block provided ] the utilization inside that block > > meets an HD Ratio of 0.94. > > I object to this use of the HD Ratio. The HD ratio is the only useful efficiency metric we've come up with, as near as I can tell. If an ISP isn't tracking this and is hopelessly inefficient, they'll need to figure it out before asking for more space. I suppose it's possible they just are efficient without tracking their HD ratio, but it seems more likely that an ISP would track this metric in their own best interest. Using a common metric as a method of insuring reasonable efficiency doesn't strike me as burdensome. Giving out a /48 by default, and then permitting larger space based on expected utilization (and measuring that via the HD ratio) seems entirely reasonable. I'm for this part of it, at least. -David From kloch at kl.net Mon Aug 20 11:58:56 2007 From: kloch at kl.net (Kevin Loch) Date: Mon, 20 Aug 2007 11:58:56 -0400 Subject: [ppml] Technical reason why /52,/56,/60,/64 are bad In-Reply-To: <75cb24520708191846w31f72e6au2229e27734a7cf33@mail.gmail.com> References: <75cb24520708191846w31f72e6au2229e27734a7cf33@mail.gmail.com> Message-ID: <46C9BA40.3060602@kl.net> Christopher Morrow wrote: > Actually the normal DFZ sorts of devices as listed below will have to > do lookups to a full 32 bits on many occasions... I suspect the > trie-based lookups (and tcam lookups) are able today to do at least 32 > bit lookups. Yes, for example nullrouting DOS attacks or rerouting small subnets during migration (or sometimes permanently ugh). There are many other examples depending on how close you are to the edges. If there are 128 bits in the address field we need to be able to route all 128 bits (quickly). - Kevin From bicknell at ufp.org Mon Aug 20 12:00:46 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 20 Aug 2007 12:00:46 -0400 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 In-Reply-To: References: <20070820144309.GA72252@ussenterprise.ufp.org> Message-ID: <20070820160046.GA79209@ussenterprise.ufp.org> In a message written on Mon, Aug 20, 2007 at 04:36:36PM +0100, michael.dillon at bt.com wrote: > I object to this use of the HD Ratio. Unless ARIN policy is changed to > require all ISPs to regularly report their IPv6 utilization and current > HD ratio, then I think ARIN should not require ISPs to "meet" an HD > Ratio. Many ISPs will be getting an IPv6 allocation with the expectation > that they will never come back for another allocation, or at least not > for many years. In that time, the HD Ratio requirement could well be > removed or changed. It is a burden to require ISPs to track that HD > Ratio. If ARIN wishes to impose the burden it must be done openly and > explicitly, not tacked on to another policy change. I'm not sure I understand your complaint at all. LIR's are already required to "meet" an HD Ratio of 0.94, from section 6.5.2: http://www.arin.net/policy/nrpm.html#six52 It clearly states that if you come back for more space, your existing space must be used to at least an HD Ratio of 0.94. Now, consider you're a LIR, and you have an end site that actually needs more than 65536 subnets. Under the current policy (6.5.4.2, http://www.arin.net/policy/nrpm.html#six542), here's the policy: ] When a single end site requires an additional /48 address block, it must ] request the assignment with documentation or materials that justify the ] request. Requests for multiple or additional /48s will be processed and ] reviewed (i.e., evaluation of justification) at the RIR/NIR level. There is no objective criteria. Does needing 65537 subnets get you a second /48 (or /47)? Can you get a /47 to have room for growth when you've used 65500? This change would make it so that if the first /48 is utilized to an HD Ratio of 0.94, then a second /48 (or /47 in total) could be assigned. When would an ISP report this information to ARIN? Only when they come back and ask for more space. When would they have to track HD Ratio for a downstream customer, ONLY if the customer received more than a /48 for a single site. Could it change? Sure. The same problem exists in IPv4, but of course much worse as you have to track every customer, not just the very large ones (http://www.arin.net/policy/nrpm.html#four2341, 80% rule). Surely you're not trying to say that since these rules may change in the future there should be no rules, no guidence for existing ISP's? -- 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 heldal at eml.cc Mon Aug 20 12:27:04 2007 From: heldal at eml.cc (Per Heldal) Date: Mon, 20 Aug 2007 18:27:04 +0200 Subject: [ppml] IPv4 swamp, mh end-users & IP architectural solutions: LISP/APT/Ivip In-Reply-To: <46C8F677.5010900@firstpr.com.au> References: <46C8F677.5010900@firstpr.com.au> Message-ID: <1187627224.13397.9.camel@localhost.localdomain> Proposals for future improvements are fine, and policies might some day change reflect that new reality. Current operational policies otoh must be based on what's possible with current off-the-shelf kit and software. //per From michael.dillon at bt.com Mon Aug 20 12:38:55 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 20 Aug 2007 17:38:55 +0100 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 In-Reply-To: <20070820160046.GA79209@ussenterprise.ufp.org> References: <20070820144309.GA72252@ussenterprise.ufp.org> <20070820160046.GA79209@ussenterprise.ufp.org> Message-ID: > It clearly states that if you come back for more space, your > existing space must be used to at least an HD Ratio of 0.94. Since most IPv6 LIRs will *NEVER* come back for a second allocation, there is currently no requirement for them to meet the HD Ratio in their allocations. You are adding this requirement by saying that *ALL* LIRs must meet the HD Ratio. > When would an ISP report this information to ARIN? Only when > they come back and ask for more space. Wrong. They would report it when the policy tells them to report it. Since the policy does not currently exist, they don't have to report anything, but other number allocation organizations require their number holders to provide monthly reports showing numbers used, numbers free, and numbers waiting to be free after customer cancellation. Also estimated runout dates. I'm not arguing for or against reporting. --Michael Dillon From stephen at sprunk.org Mon Aug 20 12:39:08 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 20 Aug 2007 11:39:08 -0500 Subject: [ppml] Longer prefixes burden the FIBs of DFZ routers References: <46C906A8.3010204@firstpr.com.au><20070820033311.GA23679@ussenterprise.ufp.org><46C95B78.50301@firstpr.com.au> <20070820141347.GA69608@ussenterprise.ufp.org> Message-ID: <01b601c7e34c$2e8d99c0$573816ac@atlanta.polycom.com> Thus spake "Leo Bicknell" > I'm quite afraid this sounds like early IPv4 routers. They did > Class A's, B's, and C's quite well, and some of them when > you put in other length prefixes fell over. I suppose it looked > like a good trade off for the software and hardware of the day; > and in fact it might have been the right choice to get us where > we are today. Those designs didn't last well though, and got > fork lifted out when a problem occurred. I don't remember it occurring the way you describe. In the early 90s we needed software upgrades to support CIDR-aware protocols due to address space and routing table issues, which was painful but didn't require a forklift, and in the late 90s we needed hardware upgrades needed to switch from route-caching to FIBs due to the inversion of the 80/20 rule, which did generally require a forklift. > I'm afraid it would have to be a global policy to mean > something to the vendors, but perhaps a "under no > circumstances will RIR's require prefixes longer than /XX > before 2015" might be a way to reduce deployment costs. That wouldn't help, AFAIK, since internal routes are already up to /128 and if forwarding packets to those destinations puts more strain on routers than forwarding to a /32 or even /64, it'll become a (perhaps unintentional) DDoS attack vector. The IETF has told vendors to not optimize for any particular route length, and so far it appears they're heeding that advice. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From stephen at sprunk.org Mon Aug 20 12:47:12 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 20 Aug 2007 11:47:12 -0500 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 References: <65554.1187454487@sa.vix.com><7ACF4793-A13A-454B-AD93-72A243466340@virtualized.org><20070818182614.GA1870@ussenterprise.ufp.org><454810F09B5AA04E9D78D13A5C39028A02A4C832@nyrofcs2ke2k01.corp.pvt><46C611F1.6030506@eagle.ca><46C5E72F.2080903@arin.net><46C5EA0B.3030304@spaghetti.zurich.ibm.com><46C5E72F.2080903@arin.net><20070820144309.GA72252@ussenterprise.ufp.org> Message-ID: <01b701c7e34c$2ee5cbe0$573816ac@atlanta.polycom.com> Thus spake >> ] LIR's may assign up to a /48 to an End Site. End Sites >> requiring ] more address space than a /48 may be assigned a >> larger block provided ] the utilization inside that block >> meets an HD Ratio of 0.94. > > I object to this use of the HD Ratio. Unless ARIN policy is > changed to require all ISPs to regularly report their IPv6 utilization > and current HD ratio, then I think ARIN should not require ISPs > to "meet" an HD Ratio. Many ISPs will be getting an IPv6 > allocation with the expectation that they will never come back > for another allocation, or at least not for many years. In that time, > the HD Ratio requirement could well be removed or changed. It > is a burden to require ISPs to track that HD Ratio. If ARIN > wishes to impose the burden it must be done openly and > explicitly, not tacked on to another policy change. That is not what Leo's strawman does; it doesn't require an ISP meet the HD Ratio for its entire allocation. What it does do is require that any end-user assignment larger than /48 be subject to the HD Ratio. Any assignment of /48 (or longer) is still assumed to be justified and no HD Ratio is applied. The current policy basically says "ask ARIN for permission for shorter than /48" and ARIN has stated they're granting all requests; I think we need better guidance in that area. Whether this is the proper metric is debatable, as is whether we need one yet, but it's heading in a direction consistent with other policies. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov From JOHN at egh.com Mon Aug 20 13:08:36 2007 From: JOHN at egh.com (John Santos) Date: Mon, 20 Aug 2007 13:08:36 -0400 Subject: [ppml] hoarding (was Policy Proposal: Expand timeframe ofAdditional Requests) In-Reply-To: <20070820133113.GA5923@vacation.karoshi.com.> Message-ID: <1070820130619.26032D-100000@Ives.egh.com> Bill - I am also a legacy holder and I second every thing you've said. Also, I find Micheal's characterization of my position and motives as false and demeaning. -- John On Mon, 20 Aug 2007 bmanning at vacation.karoshi.com wrote: > > That is the crux of the issue. The hoarders are already there. They have > > a stock of legacy IP addresses that they are sitting on in the hopes > > that a market can develop. Because these legacy addresses are not > > registered, we don't even know who these players are. > > as a holder of legacy IP space, i object to your characterization. > i did not get my blocks w/ an expectation of "a market" - i got them > because i had a defensable use for them. regarding registration, > i'm pretty sure there are records for (nearly) all assignments/delegations > so i'm not understanding your claim that legacy addresses are > "not registered".... > > > You've hit the nail on the head. The big difference between legacy > > holders and ARIN holders is that ARIN holders are playing by the rules, > > negotiating a common agreement with each other on a level playing field. > > The legacy holders are hiding in the shadows relying on vague threats of > > legal action. I believe that when push comes to shove, the U.S. > > government will come out on the side of an orderly regime (not market) > > because that is generally what the USG supports. For instance, SEC, WTO, > > Sarbanes-Oxley. Until the Department of Commerce formally makes a > > statement to the contrary, I believe that if early court cases do not > > establish the supremacy of ARIN rules over legacy holders, then the DOC > > will step in and move things in that direction. The best that legacy > > holders can hope for is that there will be a ruling which gives them a > > short time to come into compliance and show that their legacy > > allocations are in fact, in accordance with ARIN rules. > > legacy address holders are "playing by the rules" that were > in effect when they received their assignments. again > i find your characterizations objectionable. what arin (and by > extention the other RIR's and the IANA) need to do and to my > understanding is doing is to haromize the legacy rules w/ current > RIR procedures - then ensure that outreach is done to bring the > legecy holders onboard. > > ARIN is doing a very good job in opening a dialog w/ legacy holders > and is being careful, prudent, and deliberate in its steps to include > legacy holders within the ARIN framework. > > your characterization has the tenor of a hostile standoff - requireing > government intervention. i believe that the evidence thus far does not > support your claims or beliefs. one could view your statements as > trying to incite a "siege" mentality ... us v. them. which if correct > would be, IMHO, entirely wrong. we -users of IP resources- are in this > together and need to cooperate. > > > --Michael Dillon > > --bill manning > _______________________________________________ > 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. > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From sethm at rollernet.us Mon Aug 20 13:18:05 2007 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 20 Aug 2007 10:18:05 -0700 Subject: [ppml] hoarding (was Policy Proposal: Expand timeframe ofAdditional Requests) In-Reply-To: <1070820130619.26032D-100000@Ives.egh.com> References: <1070820130619.26032D-100000@Ives.egh.com> Message-ID: <46C9CCCD.3080005@rollernet.us> John Santos wrote: > Bill - > > I am also a legacy holder and I second every thing you've said. > > Also, I find Micheal's characterization of my position and motives > as false and demeaning. > Although I'm not a legacy holder myself, as far as I can see, the legacy holders *are* playing by the rules set up for them when they got their allocation. Just because nobody had the foresight to set rules back then doesn't give us the right to start raping them and accusing them of not following rules now. If you want to go after legacy holders, go get some /8's back. Is it really worth the effort for anything longer than a /16? Wouldn't our time be better spent making IPv6 adoption easier? Unless I see some /8's recovered, it seems totally pointless to pick on legacy allocations. ~Seth From bicknell at ufp.org Mon Aug 20 12:53:18 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 20 Aug 2007 12:53:18 -0400 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 In-Reply-To: References: <20070820160046.GA79209@ussenterprise.ufp.org> Message-ID: <20070820165318.GA84348@ussenterprise.ufp.org> In a message written on Mon, Aug 20, 2007 at 05:38:55PM +0100, michael.dillon at bt.com wrote: > Since most IPv6 LIRs will *NEVER* come back for a second allocation, > there is currently no requirement for them to meet the HD Ratio in their > allocations. You are adding this requirement by saying that *ALL* LIRs > must meet the HD Ratio. No, here's my text again: ] LIR's may assign up to a /48 to an End Site. End Sites requiring ] more address space than a /48 may be assigned a larger block provided ] the utilization inside that block meets an HD Ratio of 0.94. The first sentence is clear. Assign /128's, /112's, /64's, /56's, or /48's to your customers. No questions asked, ARIN does not meddle in these assignments in any way shape or form. The entire space from /128-/48 is wide open and up to each individual ISP. Only if you need to assign something larger, a /47-/1 do you then need to meet an HD Ratio of 0.94 for those larger assignments only. -- 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 dean at av8.com Mon Aug 20 13:19:49 2007 From: dean at av8.com (Dean Anderson) Date: Mon, 20 Aug 2007 13:19:49 -0400 (EDT) Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: <3c3e3fca0708200813u519aec73l99df3dd7ac99f4db@mail.gmail.com> Message-ID: On Mon, 20 Aug 2007, William Herrin wrote: > On 8/20/07, Member Services wrote: > > Policy Proposal Name: Decreasing Exponential Rationing of IPv4 IP Addresses > > > I oppose this proposal on the grounds that it does not provide > actionable policy which staff can follow. What isn't actionable about a specific upper limit? I see speed limits on the roads every day. > Dean: Specifics, specifics, specifics. What exactly does this mean in > terms of how many addresses can be given to organizations given what > documented or audited utilizations and when? What is vague about e^(-x)? What is vague about the pool of available IP Address? What is vague about 10 years? Anyone can calculate this function given only the actual number of available IP Adresses. I think the ARIN staff can handle that task. I provide for recalculation when address space is returned. It is a rationing policy. ARIN is rationing now, as some would say. This policy just defines an upper limit on delegation. The upper limit is set by a mathematical function that will keep a IP address space available for 10 years or more. The policy doesn't define the lower limit, nor does it further alter the policies for delegation. ARIN staff continue to do what they are doing now. But just can't exceed the upper limit set by this function. > And if you want to throw in a bone about contested IP address space, > you first need to explicitly define how one contests space. Disputes are usually opened by creating a ticket with ARIN. I used the term "contested" because I think that one could reasonably conclude a block is "contested" by providing ARIN with a court order regarding that block or ASN number. 'Contested' can come from quarters besides ARIN's ticketing process. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From sleibrand at internap.com Mon Aug 20 13:26:18 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 20 Aug 2007 10:26:18 -0700 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: <46C9A533.5090808@arin.net> References: <46C9A533.5090808@arin.net> Message-ID: <46C9CEBA.6070404@internap.com> Dean, Thank you for starting this discussion with a policy proposal. IMO we'll need to add some additional guidance to a policy proposal like this in order to ensure it's implemented in a way that meets the proposal's goals. For example, here are a few questions we might want to address: * How should rationing be achieved? Should all applicants receive smaller blocks than their justified usage would otherwise permit? Should all applications be placed on a waiting list and filled in a first-come-first-served basis as soon as the rationing function allows? * What mechanisms would be allowed to meet the needs of networks denied or delayed space under rationing? Would a market be created/allowed such that networks that really need IP space right away can purchase it from other networks that can more easily free up addresses through improved efficiency? Would networks needing space immediately be encouraged to get ("rent") PA space from a provider? * What do you mean by contested IP space? Are you referring to pre-ARIN allocations and assignments, or something else? I'm not sure if a rationing policy would be better than the Soft Landing proposal, but IMO rationing is an idea worth fleshing out and considering as an alternative. -Scott Member Services wrote: > Policy Proposal Name: Decreasing Exponential Rationing of IPv4 IP Addresses > > Author: Dean Anderson > > Proposal Version: 1 > > Submission Date: 8/18/07 > > Proposal type: new > > Policy term: renewable > > Policy statement: > > ARIN will ration the remaining available IP Address Space according to a > decreasing exponential function in the family of e^(-x), where the > ultimate function and factors are chosen to ensure that the remaining IP > address space lasts for at least 10 years. > This function will be used to limit the IP Address space allocations. > If IP Address Space becomes available (e.g. via return), the ration can > be recalculated. However, Ration calculations will not be based on > projected or anticipated returns. Contested IP Address Space will also > be excluded from the amount of available Address Space for ration > calculations. > > Rationale: > > Two reports[1,2] project that IP Addresses will be exhausted around > March 2010. > > * Both reports agree that if IP Addresses continue to delegated at the > present rates, we will run out of space in March 2010. > > * Everyone seems to agree that depletion will be a very bad event. > > * It is therefore imperative to begin rationing to slow down the rate of > new delegations to conserve the available address space. > > * It is necessary to do this now. One can't start rationing after the > resources run out. > > Sudden IPv4 IP Address Exhaustion is expected to cause sudden disruption > and discontinuity in business operations and planning. As with other > limited resources, the mere anticipation of exhaustion will lead to > hoarding and other behaviors that increase the harm of a sudden exhaustion. > > Rationing on a decreasing exponential will essentially prevent total > exhaustion and will gradually decrease the rate of IP Address delegation > so to alleviate the harms of a sudden stop in IP Address delegation. > > Prevention of IPv4 IP Address Exhaustion will help ensure a smooth > transition to IPV6. > > Rationing helps ensures that IP Address space remains available to > future needs. > > > [1] http://www.potaroo.net/tools/ipv4/index.html > [2] http://www.tndh.net/~tony/ietf/ipv4-pool-combined-view.pdf > > 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 mksmith at adhost.com Mon Aug 20 13:32:45 2007 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Mon, 20 Aug 2007 10:32:45 -0700 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <20070818102344.GA17357@vacation.karoshi.com.> References: <454810F09B5AA04E9D78D13A5C39028A02A4C832@nyrofcs2ke2k01.corp.pvt><46C611F1.6030506@eagle.ca> <20070818102344.GA17357@vacation.karoshi.com.> Message-ID: <17838240D9A5544AAA5FF95F8D52031602504F35@ad-exh01.adhost.lan> > Subject: Re: [ppml] Policy Proposal: IPv6 Assignment Guidelines > > On Fri, Aug 17, 2007 at 06:42:41PM -0700, David Conrad wrote: > {long counter point elided} > > > > The real problem isn't IPv6 address exhaustion, it is the risk of > > overwhelming the routing system. I would worry that allocating > > longer prefixes under the theory that it is less wasteful of address > > space might increase the chances that those longer prefixes would > > show up in the routing system. > > > > Regards, > > -drc > > risk of overwhelming the routing system? guess i have to > agree w/ you there... but surely its not a risk but a dead > certainty. > > the routing system is "dead man walking" with regard to > IPv6. some kind soul pointed out the magnitude of 128 bits... > any of the current delegation metrics for which IPv6 is > handed out, the current routing system will fail. > I couldn't agree more, but it seems to me that this is a technology problem, not a policy problem. If we are attempting to write policy to adjust the size of the global routing table then I think those policy decisions are misplaced. Regards, Mike From randy at psg.com Mon Aug 20 13:42:10 2007 From: randy at psg.com (Randy Bush) Date: Mon, 20 Aug 2007 07:42:10 -1000 Subject: [ppml] Technical reason why /52,/56,/60,/64 are bad In-Reply-To: <46C9BA40.3060602@kl.net> References: <75cb24520708191846w31f72e6au2229e27734a7cf33@mail.gmail.com> <46C9BA40.3060602@kl.net> Message-ID: <46C9D272.6040802@psg.com> Kevin Loch wrote: > If there are 128 bits in the address field we need to be able to route > all 128 bits (quickly). we went through this with the ivtf some years back, and made very clear that forwarding and routing on all 128 bits were mandatory. there should not be a problem in this space. i am not aware that any of us who use 126/ for p2p links, and insert them into is-is, use them as bgp next-hops, etc., have run into any problems. randy From drc at virtualized.org Mon Aug 20 13:44:33 2007 From: drc at virtualized.org (David Conrad) Date: Mon, 20 Aug 2007 10:44:33 -0700 Subject: [ppml] hoarding (was Policy Proposal: Expand timeframe ofAdditional Requests) In-Reply-To: References: <57421.1187292913@sa.vix.com> Message-ID: <03BD1051-3D8E-427E-8A52-D646973F15A3@virtualized.org> Michael, On Aug 19, 2007, at 2:45 PM, wrote: > No. In fact *YOUR* comment is the red herring. IP address > allocations/assignments are not IRUs. As I clarified in my note to Paul, I was proposing creating "Address IRUs" to allow for something to be bought and sold without getting into discussions about 'ownership' which I feel are a waste of time. >> There are over 1 billion legacy addresses. I'm told by a >> (fairly :-)) reliable source that about 4% of that is >> actually routed. > > That is the crux of the issue. The hoarders are already there. They > have > a stock of legacy IP addresses that they are sitting on in the hopes > that a market can develop. ? The fact that you received a legacy assignment makes you a hoarder? > Because these legacy addresses are not registered, we don't even > know who these players are. ? % whois -h whois.arin.net 18.0.0.0 % whois -h whois.arin.net 45.0.0.0 ... etc. > The legacy holders are hiding in the shadows relying on vague > threats of legal action. I'm not sure what benefit you derive by demonizing legacy address space holders. > I believe that when push comes to shove, the U.S. government will > come out on the side of an orderly regime (not market) because that > is generally what the USG supports. Historically, the US government has tended to favor markets over centralized planning and "from each according to ability, to each according to need". However, I have some skepticism that the US government would consider stepping into this mess, at least overtly. >> The routing system is going to experience explosive growth. >> IPv6 has guaranteed that. > This is untrue. IPv6 does not change the routing system in any > substantial way. It does increase the minimum number of bits per entry > to 128. But at the same time it reduces the number of entries per > major player to one in most cases. If IPv6 does not change the routing system, why do you believe ISPs will stop announcing more specifics for traffic engineering purposes? Because IPv6 does not change the routing system _and_ because people do not see any particular value in switching to IPv6 if the get locked into a provider due to the cost of renumbering, you'll see a proliferation of PI allocations. Further, as people become more dependent on IPv6-addressed Internet services at their home and businesses, it is likely they will be less tolerant of Internet service disruptions, hence are more likely to multihome. The combination of these will cause the routing system to experience significantly increased rates of growth. Regards, -drc From marla.azinger at frontiercorp.com Mon Aug 20 13:59:29 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Mon, 20 Aug 2007 13:59:29 -0400 Subject: [ppml] Technical reason why /52,/56,/60,/64 are bad Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272F9CE@nyrofcs2ke2k01.corp.pvt> Robin- This proposal (IPv6 Guidelines)is not saying that PA space will be re-assigned or re-allocated by a provider for bgp routing at these subnet sizes. This is only attempting to provide a clearer "how to decide what subnet size to re-assign or re-allocte". What subnet size should be permitted to route bgp and enable multihoming and TE is a seperate subject. It is easily confused within the discussions since PI space is registered within a "special block" that some people have willingly opened up filters to these smaller/more specific subnets that fall within the "PI special block range". And so far in regards to PA space, the perception that filters should only allow /32 through for bgp routing is being accepted. This difference between PA and PI is where alot of the confusion comes from. Hope that helps clarify it for you. Cheers! Marla -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Robin Whittle Sent: Sunday, August 19, 2007 6:30 PM To: ppml at arin.net Subject: Re: [ppml] Technical reason why /52,/56,/60,/64 are bad Michael Dillon quoted something I wrote on the IETF list, in response to the PPML message: http://lists.arin.net/pipermail/ppml/2007-August/008521.html It was my initial impression that these longer prefixes, to /64, were being assigned (allocated? - I get confused with the terminology) by RIRs as PA space for end-users. That would mean that there would be BGP advertised prefixes of this length, with the consequent need for all BGP routers to process 64 bits of destination address of some packets in their FIBs. After I wrote my first message, which Michael quoted, I read the PPML message more carefully and saw that it concerned LIRs (effectively ISPs, I think) providing PI space for their customers. This would mean that the /64 prefixes would not be advertised in BGP. So I wrote a retraction to the IETF list: http://www1.ietf.org/mail-archive/web/ietf/current/msg47249.html Can someone confirm my second understanding is correct? - 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. From briand at ca.afilias.info Mon Aug 20 14:08:28 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Mon, 20 Aug 2007 14:08:28 -0400 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 In-Reply-To: <20070820144309.GA72252@ussenterprise.ufp.org> References: <65554.1187454487@sa.vix.com> <7ACF4793-A13A-454B-AD93-72A243466340@virtualized.org> <20070818182614.GA1870@ussenterprise.ufp.org> <454810F09B5AA04E9D78D13A5C39028A02A4C832@nyrofcs2ke2k01.corp.pvt> <46C611F1.6030506@eagle.ca> <46C5E72F.2080903@arin.net> <46C5EA0B.3030304@spaghetti.zurich.ibm.com> <46C5E72F.2080903@arin.net> <20070820144309.GA72252@ussenterprise.ufp.org> Message-ID: <46C9D89C.6020001@ca.afilias.info> Leo Bicknell wrote: > > The feedback is pretty clear, and so I'd like to offer up a straw > man for a potentially better proposal. It's quite clear people > want a simple rule, and want a /48 to be allowed. > Uh, it doesn't seem you got my feedback, or didn't read it. Allow me to express my opinion clearly, then, up front, so you include it in your summary. I don't believe any LIRs should be given more than one PI block from which to allocate PA space. And, as such, this has two requirements to be a reasonable suggestion: * LIRs should be free to request PI space (the one block they get) that meets their forseeable needs (10 years at least). * LIRs should be free to assign PA space from their PI block as they see fit, with no further oversight needed ARIN staff should never need to evaluate anything other than initial IPv6 requests, and should be extremely lenient in allocating those. Any justification that passes the giggle test, should be fine. There is no need for any metric, HD or otherwise. The restriction of one new IPv6 block per ASN will keep the DFZ small, the rate of growth limited, and will encourage sensible PA assignment policies. If an LIR gives away all its space, that is its problem to deal with. It should be reasonable to expect it to claw-back some of its space in such an instance. But having the LIR recognize that the resource allocated to *it* is extremely finite, pushes the problem out of the DFZ space. Since this would be a new policy, and given the very limited number of PI blocks in the DFZ currently, I would propose that any LIR whose previous allotments were insufficient, be allowed to request one more block subsequent to enactment of this policy. It would not be fair to make the policy retroactive, and the impact of at most 300 or so additional PI blocks, ever, is not so much of a burden as to make it untenable. Brian Dickson P.S. Under this proposal, an alternative to the current "straw man", Randy would be free to assign half his space to one of his customers. -------------- next part -------------- A non-text attachment was scrubbed... Name: briand.vcf Type: text/x-vcard Size: 232 bytes Desc: not available URL: From marla.azinger at frontiercorp.com Mon Aug 20 14:12:36 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Mon, 20 Aug 2007 14:12:36 -0400 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272F9CF@nyrofcs2ke2k01.corp.pvt> While I think Scotts questions are much the same as mine would be ...if the community wants to support this proposal...but at this time I dont think this proposal is what we need. What I think we need more is: 1. How do we manage and re-use returned space? And this question has about 20 others within it just to answer the one. Regards Marla Azinger -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Scott Leibrand Sent: Monday, August 20, 2007 10:26 AM To: Member Services Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses Dean, Thank you for starting this discussion with a policy proposal. IMO we'll need to add some additional guidance to a policy proposal like this in order to ensure it's implemented in a way that meets the proposal's goals. For example, here are a few questions we might want to address: * How should rationing be achieved? Should all applicants receive smaller blocks than their justified usage would otherwise permit? Should all applications be placed on a waiting list and filled in a first-come-first-served basis as soon as the rationing function allows? * What mechanisms would be allowed to meet the needs of networks denied or delayed space under rationing? Would a market be created/allowed such that networks that really need IP space right away can purchase it from other networks that can more easily free up addresses through improved efficiency? Would networks needing space immediately be encouraged to get ("rent") PA space from a provider? * What do you mean by contested IP space? Are you referring to pre-ARIN allocations and assignments, or something else? I'm not sure if a rationing policy would be better than the Soft Landing proposal, but IMO rationing is an idea worth fleshing out and considering as an alternative. -Scott Member Services wrote: > Policy Proposal Name: Decreasing Exponential Rationing of IPv4 IP Addresses > > Author: Dean Anderson > > Proposal Version: 1 > > Submission Date: 8/18/07 > > Proposal type: new > > Policy term: renewable > > Policy statement: > > ARIN will ration the remaining available IP Address Space according to a > decreasing exponential function in the family of e^(-x), where the > ultimate function and factors are chosen to ensure that the remaining IP > address space lasts for at least 10 years. > This function will be used to limit the IP Address space allocations. > If IP Address Space becomes available (e.g. via return), the ration can > be recalculated. However, Ration calculations will not be based on > projected or anticipated returns. Contested IP Address Space will also > be excluded from the amount of available Address Space for ration > calculations. > > Rationale: > > Two reports[1,2] project that IP Addresses will be exhausted around > March 2010. > > * Both reports agree that if IP Addresses continue to delegated at the > present rates, we will run out of space in March 2010. > > * Everyone seems to agree that depletion will be a very bad event. > > * It is therefore imperative to begin rationing to slow down the rate of > new delegations to conserve the available address space. > > * It is necessary to do this now. One can't start rationing after the > resources run out. > > Sudden IPv4 IP Address Exhaustion is expected to cause sudden disruption > and discontinuity in business operations and planning. As with other > limited resources, the mere anticipation of exhaustion will lead to > hoarding and other behaviors that increase the harm of a sudden exhaustion. > > Rationing on a decreasing exponential will essentially prevent total > exhaustion and will gradually decrease the rate of IP Address delegation > so to alleviate the harms of a sudden stop in IP Address delegation. > > Prevention of IPv4 IP Address Exhaustion will help ensure a smooth > transition to IPV6. > > Rationing helps ensures that IP Address space remains available to > future needs. > > > [1] http://www.potaroo.net/tools/ipv4/index.html > [2] http://www.tndh.net/~tony/ietf/ipv4-pool-combined-view.pdf > > 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. > _______________________________________________ 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 michael.dillon at bt.com Mon Aug 20 14:18:06 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 20 Aug 2007 19:18:06 +0100 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 In-Reply-To: <20070820154550.GB28312@shell01.cell.sv2.tellme.com> References: <20070820144309.GA72252@ussenterprise.ufp.org> <20070820154550.GB28312@shell01.cell.sv2.tellme.com> Message-ID: > The HD ratio is the only useful efficiency metric we've come > up with, as near as I can tell. If an ISP isn't tracking > this and is hopelessly inefficient, they'll need to figure it > out before asking for more space. IPv6 ISPs don't need to be particularly efficient in assigning/allocating IPv6 subnets and most of them will never need to ask for more space. > Using a common metric as a method of insuring reasonable > efficiency doesn't strike me as burdensome. Since when is efficiency a goal in IPv6. I always thought that IPv6 was designed so that efficiency was no longer an issue. Instead, IPv6 enables network designers to build their networks the way they want to without worrying about wasting IP addresses. IPv6 is not IPv4 with more bits. --Michael Dillon From michael.dillon at bt.com Mon Aug 20 14:35:22 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 20 Aug 2007 19:35:22 +0100 Subject: [ppml] hoarding (was Policy Proposal: Expand timeframe ofAdditional Requests) In-Reply-To: <03BD1051-3D8E-427E-8A52-D646973F15A3@virtualized.org> References: <57421.1187292913@sa.vix.com> <03BD1051-3D8E-427E-8A52-D646973F15A3@virtualized.org> Message-ID: > > That is the crux of the issue. The hoarders are already there. They > > have a stock of legacy IP addresses that they are sitting on in the > > hopes that a market can develop. > > ? > > The fact that you received a legacy assignment makes you a hoarder? Of course not. Why does everyone interpret people's statements in such an extreme way? I did not use the word "all" or "every" in my statement. The fact is that it is not easy for ARIN registered address holders to be hoarders, but legacy holders have no such constraints on their activity. The idea of selling IP addresses is nothing new, it has been around for at over 10 years. Chances are that some hoarders are already quietly sitting on a supply of legacy address space. > % whois -h whois.arin.net 18.0.0.0 > % whois -h whois.arin.net 45.0.0.0 The holders of class A blocks are relatively well-known. But there is also a large number of class B and class C allocations out there which are less easy to figure out. > > The legacy holders are hiding in the shadows relying on vague > > threats of legal action. > > I'm not sure what benefit you derive by demonizing legacy address > space holders. Pointing out that legacy holders risk losing their address blocks during the IPv4 endgame is hardly demonizing them. If a legacy holder has a legitimate technical need for address space, then I can't see why they would not sign the ARIN RSA and participate with the rest of the industry. > > I believe that when push comes to shove, the U.S. government will > > come out on the side of an orderly regime (not market) > because that > > is generally what the USG supports. > > Historically, the US government has tended to favor markets over > centralized planning and "from each according to ability, to each > according to need". NANPA contradicts this assertion. Even when the USG supports market-based solutions they prefer rules-based markets with regulators (or at least formal 3rd-party oversight). The USG does not generally support free-for-alls, particularly in areas that are sensitive such as communications infrastructure. > However, I have some skepticism that the US > government would consider stepping into this mess, at least overtly. When and if there are court cases over the rights to IPv4 address blocks, I do expect the USG to step in because I expect that the court cases will initially be all over the map leading to a great deal of confusion. Until that happens, I don't expect the USG to say anything unless ICANN or NRO request it. --Michael Dillon From michael.dillon at bt.com Mon Aug 20 14:47:17 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 20 Aug 2007 19:47:17 +0100 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 In-Reply-To: <20070820165318.GA84348@ussenterprise.ufp.org> References: <20070820160046.GA79209@ussenterprise.ufp.org> <20070820165318.GA84348@ussenterprise.ufp.org> Message-ID: > ] LIR's may assign up to a /48 to an End Site. End Sites > requiring ] more address space than a /48 may be assigned a > larger block provided ] the utilization inside that block > meets an HD Ratio of 0.94. > > The first sentence is clear. Assign /128's, /112's, /64's, > /56's, or /48's to your customers. No questions asked, ARIN > does not meddle in these assignments in any way shape or > form. The entire space from /128-/48 is wide open and up to > each individual ISP. It's that kind of weasel-wording that I object to. The words "up to" make this wording directly contradict RFC 3177. The addition of a /56 size for consumer sites is a minor change to the IPv6 addressing architecture which has support within the IETF. But your statement about /128's etcetera is in direct contradiction to the IPv6 architecture. IPv6 is *NOT* the same as IPv4. --Michael Dillon From bicknell at ufp.org Mon Aug 20 14:57:45 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 20 Aug 2007 14:57:45 -0400 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 In-Reply-To: References: <20070820165318.GA84348@ussenterprise.ufp.org> Message-ID: <20070820185745.GA95277@ussenterprise.ufp.org> In a message written on Mon, Aug 20, 2007 at 07:47:17PM +0100, michael.dillon at bt.com wrote: > It's that kind of weasel-wording that I object to. The words "up to" > make this wording directly contradict RFC 3177. The addition of a /56 > size for consumer sites is a minor change to the IPv6 addressing > architecture which has support within the IETF. But your statement about > /128's etcetera is in direct contradiction to the IPv6 architecture. Are you saying the policy should lock it down in both directions? "LIR's will assign a /56 to residential users, nothing bigger, nothing smaller. LIR's will assign a /48 to enterprise users, nothing bigger, nothing smaller?" My wording contradicts nothing in RFC 3177. You can follow RFC 3177 and 100% comply with ARIN policy with my wording. You can also not follow 3177, do other things and comply with my wording. Is that too permissive? -- 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 tedm at ipinc.net Mon Aug 20 15:06:08 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 20 Aug 2007 12:06:08 -0700 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >David Conrad >Sent: Friday, August 17, 2007 6:43 PM >To: Steve Bertrand >Cc: ppml at arin.net >Subject: Re: [ppml] Policy Proposal: IPv6 Assignment Guidelines > > >Steve, > >On Aug 17, 2007, at 2:24 PM, Steve Bertrand wrote: >>> There is no shortage of IPv6 addresses and if the world >>> ever does run out of IPv6 addresses, we will all be dead when it >>> happens. > >Michael is right about one thing: we'll be dead because the Internet >users of the world will unite and rightfully hunt us all down and >kill us for being so inexcusably stupid as to burn through 2^128 >addresses. :-) > Hold on there - when running on the Infinite Improbability Drive the ship Heart of Gold cruises at a much higher improbability level than 2 to the power of 128 Ted From davids at webmaster.com Mon Aug 20 15:09:54 2007 From: davids at webmaster.com (David Schwartz) Date: Mon, 20 Aug 2007 12:09:54 -0700 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 In-Reply-To: <46C9D89C.6020001@ca.afilias.info> Message-ID: > I don't believe any LIRs should be given more than one PI block from > which to allocate PA space. > And, as such, this has two requirements to be a reasonable suggestion: > > * LIRs should be free to request PI space (the one block they get) > that meets their forseeable needs (10 years at least). > * LIRs should be free to assign PA space from their PI block as they > see fit, with no further oversight needed > > ARIN staff should never need to evaluate anything other than initial IPv6 > requests, and should be extremely lenient in allocating those. Any > justification that passes the giggle test, should be fine. I think this is going in the right direction, but I think it might go too far. I completely agree that more radical thinking is needed in the IPv6 world because addresses simply are not scarce and irrational rationing will cost the community more than any conceivable benefit. Specifically, I agree that: 1) It is largely senseless to have policies for small allocations from an ISP to their single-homed end users. There is simply no reason to care. I think we pretty much all already agree that this is so at the /48 level. 2) Routing slots are expensive, not address space. With the huge problem of address space conservation removed, we should be able to do a much better job at conserving routing slots. 3) IPv6 allocation can be based on foreseeable need for a decade. This means both from regional registries to LIRs and from LIRs to customers. But I disagree strongly that a hard and fast "one allocation" rule makes sense. I also do not agree that you can have a need-based assignment policy without any rules for what constitutes need. There will have to be additional allocations and that means that sub-allocations will have to be reviewed. I don't think you can get around that. DS From bicknell at ufp.org Mon Aug 20 15:17:10 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 20 Aug 2007 15:17:10 -0400 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 In-Reply-To: References: <46C9D89C.6020001@ca.afilias.info> Message-ID: <20070820191710.GA96789@ussenterprise.ufp.org> In a message written on Mon, Aug 20, 2007 at 12:09:54PM -0700, David Schwartz wrote: > 1) It is largely senseless to have policies for small allocations from an > ISP to their single-homed end users. There is simply no reason to care. I > think we pretty much all already agree that this is so at the /48 level. So, when Randy Bush gets his /32 from ARIN, and chooses to give two /33's to residental DSL customers, and the next day asks for more space that's ok? While I agree we shouldn't be wallowing around in the muck worring about every end user (as we do in IPv4), I think it's very important to set a boundary between the "I don't care" space and the "hey wait a minute, that's way too much" space. Since we give most residential users a /32 in IPv4, and we're running out, I would posit letting someone give out /33's to residential users in IPv6 will lead to the exhaustion of the IPv6 address space in rather short order. Which is why, in version 2 I put the same stake in the ground as RFC 3177. /48-/128, we don't care, do what you want. /1-/48, we care, there are rules. Is that not the right break point? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From drc at virtualized.org Mon Aug 20 15:17:23 2007 From: drc at virtualized.org (David Conrad) Date: Mon, 20 Aug 2007 12:17:23 -0700 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 In-Reply-To: References: <20070820144309.GA72252@ussenterprise.ufp.org> <20070820154550.GB28312@shell01.cell.sv2.tellme.com> Message-ID: <193A01A3-DC10-4139-8211-1734281C296F@virtualized.org> Michael, On Aug 20, 2007, at 11:18 AM, wrote: > IPv6 ISPs don't need to be particularly efficient in > assigning/allocating IPv6 subnets and most of them will never need to > ask for more space. I'm not sure why you say this. If you assign /48s to customers and ISPs are given /32s by default, you can have a maximum of 64K customers. Regards, -drc From tedm at ipinc.net Mon Aug 20 15:22:08 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 20 Aug 2007 12:22:08 -0700 Subject: [ppml] [Re: IPv6 addresses really are scarce after all] In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A03685AB9@XCH-NW-8V1.nw.nos.boeing.com> Message-ID: If the Fortune 1000 and critical infrastructure providers cannot obtain direct IPv6 allocations from a numbering authority, and refuse to get IPv6 from their ISP, then if there are enough of these people running around I am sure someone will design a network address translator that uses the IPv6 site local addresses, and you will have the same exact situation as what exists right now with IPv4. If you think that you have a better way to balance the needs of the Internet community to not have a gigantic route table with an org or business DESIRE to not get allocations from their ISP, then let's hear it. And keep in mind that the need of the Internet community is a -requirement- the desire of the business community is a -wish-. The Internet cannot survive with every single org advertising their own route - it cannot survive that way today under IPv4, and it won't be able to do it in the future under IPv6. Ted PS Some out there regard the existence of NAT as a tragic failure of the IPv4 Internet, seriously limiting it's use. ;-) >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Davis, Terry L >Sent: Sunday, August 19, 2007 7:12 PM >To: Randy Bush >Cc: bmanning at vacation.karoshi.com; ppml at arin.net >Subject: Re: [ppml] [Re: IPv6 addresses really are scarce after all] > > >Randy > >How many of the fortune 1000 and critical infrastructure providers will >accept a permanent relationship with an ISP for their v6 addresses? I >would not expect it to be many. There are some things that in the real >world, we will not re-address because of an ISP change. > >Generally it will be a "critically" decision whether for business or >critical infrastructure. > >Take care >Terry > > >> -----Original Message----- >> From: Randy Bush [mailto:randy at psg.com] >> Sent: Friday, August 17, 2007 7:12 PM >> To: Davis, Terry L >> Cc: bmanning at vacation.karoshi.com; David Conrad; ppml at arin.net >> Subject: Re: [ppml] [Re: IPv6 addresses really are scarce after all] >> >> > I do sense that there is growing understanding that the requirement >for >> > businesses or critical infrastructure providers to obtain their v6 >> > addresses from their ISP, will not work in the real world. >> >> after all, it has been such a tragic failure in ipv4, seriously >> inhibiting the use of the internet. >> >> randy >_______________________________________________ >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 stephen at sprunk.org Mon Aug 20 15:27:07 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 20 Aug 2007 14:27:07 -0500 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 References: <65554.1187454487@sa.vix.com> <7ACF4793-A13A-454B-AD93-72A243466340@virtualized.org> <20070818182614.GA1870@ussenterprise.ufp.org> <454810F09B5AA04E9D78D13A5C39028A02A4C832@nyrofcs2ke2k01.corp.pvt> <46C611F1.6030506@eagle.ca><46C5E72F.2080903@arin.net> <46C5EA0B.3030304@spaghetti.zurich.ibm.com> <46C5E72F.2080903@arin.net><20070820144309.GA72252@ussenterprise.ufp.org> <46C9D89C.6020001@ca.afilias.info> Message-ID: <038601c7e361$eece9f80$573816ac@atlanta.polycom.com> Thus spake "Brian Dickson" > Allow me to express my opinion clearly, then, up front, so you include > it in your summary. > > I don't believe any LIRs should be given more than one PI block from > which to allocate PA space. And, as such, this has two > requirements to be a reasonable suggestion: > > * LIRs should be free to request PI space (the one block they > get) that meets their forseeable needs (10 years at least). > * LIRs should be free to assign PA space from their PI block > as they see fit, with no further oversight needed > > ARIN staff should never need to evaluate anything other than > initial IPv6 requests, and should be extremely lenient in > allocating those. Any justification that passes the giggle test, > should be fine. > > There is no need for any metric, HD or otherwise. The restriction > of one new IPv6 block per ASN will keep the DFZ small, the rate > of growth limited, and will encourage sensible PA assignment > policies. > > If an LIR gives away all its space, that is its problem to deal with. > It should be reasonable to expect it to claw-back some of its > space in such an instance. But having the LIR recognize that > the resource allocated to *it* is extremely finite, pushes the > problem out of the DFZ space. The problem I see with that is LIRs would be motivated to make as big a land-grab as possible, and ARIN would have no metrics at its disposal to say no -- certainly not the unquantifiable "giggle test". What if Comcast, AT&T, Verizon, Cox, etc. said they planned on giving a /32 to every customer and thus they needed a /3 each? What tools have you given ARIN staff to say that's unjustified? This is not implementable. Leo's idea, while it may not be perfect, is. We need to give clear rules to staff so that they know whether to approve or deny requests and they have solid documentation to point to when doing so, or we'll end up back in the same boat we're in today where ARIN approves everything because we haven't given them any guidance on when they shouldn't (or, if ARIN turns evil in the future, denying everything for the same reason). 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 davids at webmaster.com Mon Aug 20 15:41:21 2007 From: davids at webmaster.com (David Schwartz) Date: Mon, 20 Aug 2007 12:41:21 -0700 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 In-Reply-To: <20070820191710.GA96789@ussenterprise.ufp.org> Message-ID: > In a message written on Mon, Aug 20, 2007 at 12:09:54PM -0700, > David Schwartz wrote: > > 1) It is largely senseless to have policies for small > > allocations from an > > ISP to their single-homed end users. There is simply no reason > > to care. I > > think we pretty much all already agree that this is so at the /48 level. > So, when Randy Bush gets his /32 from ARIN, and chooses to give two > /33's to residental DSL customers, and the next day asks for more > space that's ok? No. That's my point. What we don't want is people coming back to the registries too quickly. That's the cost we need to minimize. > Since we give most residential users a /32 in IPv4, and we're running > out, I would posit letting someone give out /33's to residential > users in IPv6 will lead to the exhaustion of the IPv6 address space > in rather short order. Right, that's why I am saying the complete sub-assignment freedom model is not reasonable. That's the argument I was responding to and that's the part of it I disagree with. > Which is why, in version 2 I put the same stake in the ground as > RFC 3177. /48-/128, we don't care, do what you want. /1-/48, we > care, there are rules. Is that not the right break point? That's not the only question. We also need to decide what the time interval for forecast need is going to be for assignments to multi-homed end users and LIRs. Is a decade unreasonable? As for whether /48 is the right choice or not, I honestly do not know. I certainly do not see any reason to increase it. How many end users on the planet could justify a /47? If your point was to convince me that I already have what I say I want, I think you're basically right. DS From dlw+arin at tellme.com Mon Aug 20 16:02:40 2007 From: dlw+arin at tellme.com (David Williamson) Date: Mon, 20 Aug 2007 13:02:40 -0700 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 In-Reply-To: References: <20070820144309.GA72252@ussenterprise.ufp.org> <20070820154550.GB28312@shell01.cell.sv2.tellme.com> Message-ID: <20070820200240.GD28312@shell01.cell.sv2.tellme.com> On Mon, Aug 20, 2007 at 07:18:06PM +0100, michael.dillon at bt.com wrote: > > Using a common metric as a method of insuring reasonable > > efficiency doesn't strike me as burdensome. > > Since when is efficiency a goal in IPv6. I always thought that IPv6 was > designed so that efficiency was no longer an issue. Instead, IPv6 > enables network designers to build their networks the way they want to > without worrying about wasting IP addresses. You seem to have missed the word "reasonable". Regardless of gigantic the space is (and it really really is huge), we could easily create an allocation scheme that would run us out of space if we tried. I sure don't want to deal with another round of this every again. Besides, I don't think an HD ratio of 0.94 for a /47 or shorter is going to be even vaguely burdensome on a network designer. > IPv6 is not IPv4 with more bits. Now that's true. That's also a key part of the deployment problem. In theory, IPv6 was going to solve all the world's ills. It would allow efficient multi-homing, solve world hunger, ease global warming, etc. We've managed to back away from those early promises so that we now have a bigger address field and incompatible headers. We'd have been better off just making v4 with more bits, at this point. (Think how easy a 6-to-4/4-to-6 NAT would be if this was true....) Anyway, I'm fairly certain we're going to have to agree to disagree. I don't see anything in Leo's current proposal that seems excessively burdensome, especially given the number of customers that most ISPs are likely to see with legitimate need for more than a /48 of space. -David From tedm at ipinc.net Mon Aug 20 16:23:56 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 20 Aug 2007 13:23:56 -0700 Subject: [ppml] hoarding (was Policy Proposal: Expand timeframeofAdditional Requests) In-Reply-To: <20070820133113.GA5923@vacation.karoshi.com.> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >bmanning at vacation.karoshi.com >Sent: Monday, August 20, 2007 6:31 AM >To: michael.dillon at bt.com >Cc: ppml at arin.net >Subject: Re: [ppml] hoarding (was Policy Proposal: Expand >timeframeofAdditional Requests) > > > legacy address holders are "playing by the rules" that were > in effect when they received their assignments. again > i find your characterizations objectionable. what arin (and by > extention the other RIR's and the IANA) need to do and to my > understanding is doing is to haromize the legacy rules w/ current > RIR procedures - then ensure that outreach is done to bring the > legecy holders onboard. This is really in my opinion completely unnecessary. The legacy rules can be simply ignored since all rules covering IPv4 will become obsolete once IPv6 is in wide use and IPv4 falls into disuse. Unless I have misread the rules, the current policy is if a legacy holder wants to give up IPv4 they can. If they want to sell a IPv4 block to someone the only way possible is by allowing the purchaser to completely take them over, and own them. There is no mechanism for a IPv4 holder whether legacy or not to "transfer" assignment of a block to some organization without that organization signing a RSA with a numbering authority. (unless the holder makes an assignment themselves - in which case the legacy holder is still listed as the overall owner of the block, and still maintains control over the block) As long as these are the rules then I see no incentive or possibility for a legacy holder to sell addresses and no real chance for such a market to develop. I do see legacy holders gain a SLIGHT market advantage during the timeperiod between IPv4 runout and wide use of IPv6-only IF they have large blocks of unused IPv4 that they can route for customers. Of course this would be a continuing "rental" situation, which is no different than any ISP currently has which has sufficient IPv4 to meet it's future customer needs. It would vanish as soon as IPv6 becomes established. Ted From tedm at ipinc.net Mon Aug 20 16:34:13 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 20 Aug 2007 13:34:13 -0700 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests In-Reply-To: <51F57705-CCA9-4339-9EF1-9B36A039B8EE@icann.org> Message-ID: >-----Original Message----- >From: Leo Vegoda [mailto:leo.vegoda at icann.org] >Sent: Saturday, August 18, 2007 12:21 AM >To: Ted Mittelstaedt >Cc: David Conrad; Public Policy Mailing List >Subject: Re: [ppml] Policy Proposal: Expand timeframe of Additional >Requests > > >On 17 Aug 2007, at 20:59, Ted Mittelstaedt wrote: > >[...] > >> Thus without ARIN approval I don't see how an "ebay market for >> IPv4" can >> exist that would allow responsibility for blocks to be passed between >> organizations, when there are people waiting in line for IPv4. > >You would get it if sufficient demand for a market existed and some >other organisation was willing to provide a registry that operated by >a different set of policies. No, you wouldn't still unless a large number of networks agreed to recognize that organization When we interconnect to upstream feeds, they check WHOIS and do not allow us to advertise IP blocks that we aren't showing as owners in the ARIN registry. All networks in the last 8 years we have bought service from have had this requirement. I could set myself up tomorrow as "some other organization willing to provide a registry" but I still wouldn't be able to BGP advertise an IP address unless it is in ARIN as belonging to me. >However, as ARIN's policies are set by >consensus, the situation where ARIN's policies diverge significantly >from the policies demanded by its constituency is unlikely to arise. >The real issue is whether the participants in ARIN's policy making >process want to keep the FCFS model or would prefer to move to a >market-based model. > market-based models are a disaster for most centralized common products. Anywhere that it is possible for a monopoly to form, market-based models are destroyed by collusion between the few suppliers of the resource and the government has to intervene and regulate. This really doesen't matter when your talking about something like investment-grade diamonds. Nobody -needs- investment-grade diamonds, and there's enough industrial-grade diamond mines outside of DeBeers control for competition to form. It does matter when your talking about something like electrical power, which where when market-based models were introduced (during so-called deregulation efforts) it has been a disaster. This is why the government is so intimately involved in oil production. Both as a regulation-maker and military support of oil field extraction efforts by so-called private companies. Ted From tedm at ipinc.net Mon Aug 20 16:35:07 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 20 Aug 2007 13:35:07 -0700 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <20070818102344.GA17357@vacation.karoshi.com.> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >bmanning at vacation.karoshi.com >Sent: Saturday, August 18, 2007 3:24 AM >To: David Conrad >Cc: ppml at arin.net >Subject: Re: [ppml] Policy Proposal: IPv6 Assignment Guidelines > > >On Fri, Aug 17, 2007 at 06:42:41PM -0700, David Conrad wrote: >{long counter point elided} >> >> The real problem isn't IPv6 address exhaustion, it is the risk of >> overwhelming the routing system. I would worry that allocating >> longer prefixes under the theory that it is less wasteful of address >> space might increase the chances that those longer prefixes would >> show up in the routing system. >> >> Regards, >> -drc > > risk of overwhelming the routing system? guess i have to > agree w/ you there... but surely its not a risk but a dead > certainty. > > the routing system is "dead man walking" with regard to > IPv6. some kind soul pointed out the magnitude of 128 bits... > any of the current delegation metrics for which IPv6 is > handed out, the current routing system will fail. Why? Does introducing IPv6 create billions of extra hosts that need to have IP numbers assigned? Ted From tedm at ipinc.net Mon Aug 20 16:45:52 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 20 Aug 2007 13:45:52 -0700 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing ofIPv4 IP Addresses In-Reply-To: <8E3ECA76-1A7F-4810-A845-6E8C0F009088@delong.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Owen DeLong >Sent: Monday, August 20, 2007 7:42 AM >To: Member Services >Cc: ppml at arin.net >Subject: Re: [ppml] Policy Proposal: Decreasing Exponential Rationing >ofIPv4 IP Addresses > > >I oppose this policy. > >The exhaustion of the IPv4 free pool will have minimal effect on >existing >operations. > >Rationing would have a much more detrimental effect. > >Extending the life of the IPv4 free pool through artificial >constraints on >current growth of the network will not provide any meaningful benefit >to the community. > I disagree with that, I think that extending the life will always provide benefits as there is still legacy gear that is in service and hasn't been replaced yet. However, the only way I can see of extending IPv4 is to withdraw assignments and allocations that were put out, either by the numbering authorities, or prior to them, that are not being used. This policy does nothing for that. Ted From Vin.Kelley at state.nm.us Mon Aug 20 16:47:37 2007 From: Vin.Kelley at state.nm.us (Kelley, Vincent, DoIT) Date: Mon, 20 Aug 2007 14:47:37 -0600 Subject: [ppml] Does anybody know how to unsubscribe? In-Reply-To: References: <46C9D89C.6020001@ca.afilias.info> Message-ID: Does anybody know how to unsubscribe? I've tried a couple of times without success. -Vin -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of David Schwartz Sent: Monday, August 20, 2007 1:10 PM To: ppml at arin.net Subject: Re: [ppml] IPv6 Assignment Guidelines, Straw Man #2 > I don't believe any LIRs should be given more than one PI block from > which to allocate PA space. > And, as such, this has two requirements to be a reasonable suggestion: > > * LIRs should be free to request PI space (the one block they get) > that meets their forseeable needs (10 years at least). > * LIRs should be free to assign PA space from their PI block as they > see fit, with no further oversight needed > > ARIN staff should never need to evaluate anything other than initial IPv6 > requests, and should be extremely lenient in allocating those. Any > justification that passes the giggle test, should be fine. I think this is going in the right direction, but I think it might go too far. I completely agree that more radical thinking is needed in the IPv6 world because addresses simply are not scarce and irrational rationing will cost the community more than any conceivable benefit. Specifically, I agree that: 1) It is largely senseless to have policies for small allocations from an ISP to their single-homed end users. There is simply no reason to care. I think we pretty much all already agree that this is so at the /48 level. 2) Routing slots are expensive, not address space. With the huge problem of address space conservation removed, we should be able to do a much better job at conserving routing slots. 3) IPv6 allocation can be based on foreseeable need for a decade. This means both from regional registries to LIRs and from LIRs to customers. But I disagree strongly that a hard and fast "one allocation" rule makes sense. I also do not agree that you can have a need-based assignment policy without any rules for what constitutes need. There will have to be additional allocations and that means that sub-allocations will have to be reviewed. I don't think you can get around that. DS _______________________________________________ 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. ______________________________________________________________________ This inbound email has been scanned by the MessageLabs Email Security System. ______________________________________________________________________ Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From stephen at sprunk.org Mon Aug 20 17:02:00 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 20 Aug 2007 16:02:00 -0500 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 References: <20070820144309.GA72252@ussenterprise.ufp.org><20070820154550.GB28312@shell01.cell.sv2.tellme.com> <193A01A3-DC10-4139-8211-1734281C296F@virtualized.org> Message-ID: <03e201c7e36e$d1fd61e0$573816ac@atlanta.polycom.com> Thus spake "David Conrad" > On Aug 20, 2007, at 11:18 AM, > wrote: >> IPv6 ISPs don't need to be particularly efficient in >> assigning/allocating IPv6 subnets and most of them will never >> need to ask for more space. > > I'm not sure why you say this. > > If you assign /48s to customers and ISPs are given /32s by default, > you can have a maximum of 64K customers. ... and most ARIN members don't have that many customers. Those that do mainly provide residential service and will be handing out /56's at most to those customers, giving them just shy of 17M assignments before they need more space. I'd expect those folks are smart enough to ask for larger allocations up front to save hassle later. Honestly, I expect that the Ma Bell and Ma Cable duopoly will converge on putting a few hundred customers on a shared /64, similar to what they do with v4. I'll consider it a minor miracle if I can get a /64 via DHCP PD for the inside of my firewall without having to upgrade to "business" service (and the corresponding monthly rates). With a design like that, a /32 per ISP is plenty. 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 Lee.Howard at stanleyassociates.com Mon Aug 20 17:56:05 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 20 Aug 2007 17:56:05 -0400 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 In-Reply-To: <03e201c7e36e$d1fd61e0$573816ac@atlanta.polycom.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB406B8E98C@CL-S-EX-1.stanleyassociates.com> > > If you assign /48s to customers and ISPs are given /32s by default, > > you can have a maximum of 64K customers. > > ... and most ARIN members don't have that many customers. What about the rest? > Those that do mainly provide residential service and will be > handing out /56's at most to those customers, giving them Why would they? The current NRPM offers non-binding guidelines, and a /48 is just as pretty as a /56. In fact, giving out more addresses could be considered a business differentiator; I would encourage my competitors (if I had any) to give their customers less than I do. Lee From bicknell at ufp.org Mon Aug 20 19:00:50 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 20 Aug 2007 19:00:50 -0400 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 In-Reply-To: <03e201c7e36e$d1fd61e0$573816ac@atlanta.polycom.com> References: <193A01A3-DC10-4139-8211-1734281C296F@virtualized.org> <03e201c7e36e$d1fd61e0$573816ac@atlanta.polycom.com> Message-ID: <20070820230050.GA13563@ussenterprise.ufp.org> In a message written on Mon, Aug 20, 2007 at 04:02:00PM -0500, Stephen Sprunk wrote: > ... and most ARIN members don't have that many customers. Those that do > mainly provide residential service and will be handing out /56's at most to > those customers, giving them just shy of 17M assignments before they need > more space. I'd expect those folks are smart enough to ask for larger > allocations up front to save hassle later. You mean, like these smart folks... inet6num: 2003::/19 netname: DE-TELEKOM-20050113 descr: Deutsche Telekom AG country: DE inet6num: 2a01:c000::/19 netname: FR-TELECOM-20051230 descr: France Telecom country: FR For the record, a /19 is 536,870,912 /48 assignments. There's 64 million people in France, 83 million in Germany. All of those people could get 5 /48's FROM BOTH PROVIDERS (10 total) with that much space. -- 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 kmedcalf at dessus.com Mon Aug 20 20:21:05 2007 From: kmedcalf at dessus.com (Keith Medcalf) Date: Mon, 20 Aug 2007 20:21:05 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: Message-ID: <9a5f82a45c9adc4f8af87c31625f4a50@mail.dessus.com> > > risk of overwhelming the routing system? guess i have to > > agree w/ you there... but surely its not a risk but a dead > > certainty. > > the routing system is "dead man walking" with regard to > > IPv6. some kind soul pointed out the magnitude of 128 bits... > > any of the current delegation metrics for which IPv6 is > > handed out, the current routing system will fail. > Why? Does introducing IPv6 create billions of extra hosts that > need to have IP numbers assigned? And more to the point: If every holder of a IPv4 routing slot (whether ISP or, like me, a legacy PI /24 holder) was "granted" a /28 and they were all routed in the DFZ, do you believe that the IPv6 table would contain any more entries than it currently does, if the current IPv4 rules were immediately thereafter imposed on future IPv6 and ASN allocations/assignments (with changes re size in that all IPv6 are /28). Would not the table merely double in size (entry-wise that is)? Could this be handled in the DFZ at present? If it can then there are no worries at all. You then need to evaluate if such a happening would be a best-case or a worst-case outcome ... or perhaps something in between that can be worked with. If this could not be handled in the DFZ at present, then there is a clear need to 'guide' the migration toward a more acceptable end-point. From andrew.dul at quark.net Mon Aug 20 21:22:36 2007 From: andrew.dul at quark.net (Andrew Dul) Date: Mon, 20 Aug 2007 18:22:36 -0700 Subject: [ppml] 2007-15 Legacy Record Authentication: Feedback and editing Message-ID: <20070821012218.6768F144734@smtp2.arin.net> Hello all, I wrote 2007-15 after a number of discussions with different ARIN community members about what could be done to encourage and get legacy IPv4 resource holders more involved in ARIN and specifically to bring those legacy records into a formal and defined relationship with ARIN. This policy proposal was written to hopefully address some of those areas through policy changes. http://www.arin.net/policy/proposals/2007_15.html The policy proposal text has induced quite a lot of discussion, as I expected, some of it around the policy and also spawning other discussions about legacy holders in general and the future or IPv4 & IPv6. I've written a short survey to help me as the author refine the policy proposal and hopefully present a policy at the upcoming meeting that will hopefully represent an option that the community can consider to implement in the future. If you are interested in this topic and this policy please visit this URL and fill out the short survey, I'll use the responses to fine-tune the policy text for presentation at the next meeting. http://www.quark.net/survey/survey.php?sid=29 The survey will be open until Aug 28, 2007. After that I'll gather the feedback, produce an updated version of the policy and submit it to PPML. Thanks, Andrew From rw at firstpr.com.au Tue Aug 21 00:24:23 2007 From: rw at firstpr.com.au (Robin Whittle) Date: Tue, 21 Aug 2007 14:24:23 +1000 Subject: [ppml] Longer prefixes burden the FIBs of DFZ routers In-Reply-To: <01b601c7e34c$2e8d99c0$573816ac@atlanta.polycom.com> References: <46C906A8.3010204@firstpr.com.au><20070820033311.GA23679@ussenterprise.ufp.org><46C95B78.50301@firstpr.com.au> <20070820141347.GA69608@ussenterprise.ufp.org> <01b601c7e34c$2e8d99c0$573816ac@atlanta.polycom.com> Message-ID: <46CA68F7.4010404@firstpr.com.au> Hi Leo, Thanks again for your helpful response. You wrote, in part: >> I didn't mention these, because I assume - perhaps wrongly - that >> these don't carry the burden of Internet traffic. It is my >> impression that when an FIB in a router is handling a packet >> which matches a /32 prefix which is for that router's IP address, >> or some other router's IP address, that the packet is most likely >> to be a BGP message between the routers or some configuration, >> logging traffic etc. > > I am rather sure this assumption is wrong, at least for IPv4. I'm > not sure we have enough IPv6 experience to know if it is wrong for > IPv6 as well. > > In IPv4 it would not be uncommon for an ISP to use a /32 "virtual > address" to hit a pile of load balancers for a Usenet farm, or a > VoIP switch farm, webmail front ends, or a streaming video farm. > Many people put their caching resolvers all on virtual IP's and > anycast them internally with BGP to provide more resiliency. I have only a partial understanding of this. My concern was primarily with what burden address policy places on all DFZ routers. If some or may ISPs want or need to do other more demanding things with their DFZ routers, but those things are not forced upon them by address policy, then that is their choice and not such a concern for the whole Internet. On the other hand, if many, most, or all DFZ routers already have to cope with various common, ISP-specific burdens such that the burdens specifically caused by address policy are not much more of a problem, then those common, ISP-specific burdens are of interest because they set some kind of boundary within which address policy burdens can be relatively freely added. > But even if your assumption was right, it's wrong. That is to say > if the only "expensive" operation was packets to my router > loopbacks for iBGP it might look ok to have those lookups take > more time in steady state. However all it takes is an attacker > finding those addresses and DDoSing them with packets to make that > not work. If the lookups are more expensive, the result is a much > more attractive attack target. DoS attacks are a concern, but to me it is a second-order problem compared to the task of handling the main volume of traffic. >> If I was designing a router - which I am not - I would want to >> know what length prefix to optimise the performance for. It >> would be no good saying "Sometimes the router needs to handle >> /128 so the router must be optimised to forward packets to /128 >> prefixes" when in reality, most of the traffic would be to /32 to >> /48. > ... >> I think it would be a very good idea for the IETF and the RIRs to >> decide, very carefully on something exactly like this. I think >> the IETF and the RIRs should be able to decide that under no >> circumstances would IPv6 address policy in the next decade or two >> require DFZ routers to look at any more than 48 bits of address >> for Internet traffic. > > A very interesting idea. I think a "decade or two" may be too > long, but given we are in the early phases it may be worth > considering your idea. I'm afraid it would have to be a global > policy to mean something to the vendors, but perhaps a "under no > circumstances will RIR's require prefixes longer than /XX before > 2015" might be a way to reduce deployment costs. Thanks for your tentative support of my idea. > Of course, the trap is that if that assumption is built into > hardware, and 2015 comes in a lean time there will be great > pressure to keep it for economic reasons... It is difficult to envisage IT adoption and usage beyond ten years into the future, but we do have two decades of Internet experience behind us now, and IPv6 has been around for a decade. I don't think it should be too hard to fix some kind of length limit for advertised prefixes, especially considering there is broad agreement that the total number of prefixes can't be allowed to grow continually beyond a few hundred thousand. The consensus on the RAM list seems to be that we will definitely need some new architectural arrangement for multihoming potentially millions of end-user networks, rather than just advertising more prefixes. > From my own talking to vendor reps they are trying to make some > hay with the fact that IPv6 routes are quite sparse relative to > the address space. In particular, even if you cut off at /112, > there are likely to be no routes in the /64-/112 space as > currently deployed. Also, I believe the largest current > allocation is a /21, so it's probably unlikely to have a route < > /18. If we look just at those ranges, we're down to a space of 54 > bits that are likely to be present in routes (18-64, 112-128). > 54 bits is a lot more tractable than 128, and fits well within the > 72 bit TCAM space. > > With a good method of hashing (in hardware) this could be done, > and leave a pretty good chance that prefixes of the "unlikely > lengths" would not cause significant problems until there were a > lot of them. I don't have a clear idea of how hashing would work, since the system has to make use of all the address bits up to the length of the prefix - not just segments of them, unless perhaps the 3 most significant bits can be ignored, because of some prior step which ensured they all matched 2000::/3. Also, if some addresses were slower to handle due to hash algorithm misses, then if this was known to attackers this could lead to the DoS critique. > I would love to have reps from Cisco and Juniper (Foundry, > Extreme, Force 10?) come to an ARIN meeting and give some > information on how they handle forwarding IPv6 packets, and if > ideas like your prefix length limit help them in a significant way > or not. I strongly agree. All Internet users pay for the routers and their operational costs. The router manufacturers have to create boxes which do whatever gymnastics result from address policies, IETF RFCs etc. and the practical aspects of running DFZ routers. I get the impression that some people seem to think this hardware stuff is relatively easy. I received a private message recently: > FIB scaling and speed is a solved problem (the best solutions > are proprietary). It is not a major cost driver in fast routers > relative to other features. but I don't believe this. It simply does cost more in terms of memory space, read cycle times, complexity of the CPU work in running the trie algorithm etc. (or vast width and depth of TCAM) to handle four million /128 prefixes compared to four million /24 prefixes or 250k of these lengths. My correspondent - who works for a high-end router company - responded: > FIB memory scales mostly with the number of prefixes, not their > size (it is super-linear, but not badly so). > > The number of memory cycles needed for FIB lookup is negligible > relative to the number of cycles needed for other forwarding > functions (e.g., statistics, ACLs, queue scheduling). While I understand these things are important for many purposes, I am not sure that Access Control Lists, detailed statistics or deciding which queue of the output interface to use are for DFZ routers. Maybe they are - I think my correspondent knows much more about this than I do. > The difference in cycles between v6 and v4 is more than made up by > the fact that the worst-case packet rate for IPv6 is 2/3 that for > IPv4. Still, I think we need to ensure that address policy places burdens on routers only to the degree that the benefits outweigh the costs. > If all IPv6 end-site prefix allocations were a fixed size (say > /48), that would make things slightly easier. But not enough to > get excited about. I think that even a moderate firming of the ground on which routers are designed would be worthwhile, provided it did not overly restrict Internet usage in the future. > Most vendors are trying to figure out how to implement line-rate > DPI. FIB lookups are the least of our problems. If you don't > believe me, talk to some other vendors. As far as I know, Deep Packet Inspection is not something which should be occurring in DFZ routers, at least in terms of handling ordinary traffic packets. I think this debate is straddling several related questions: 1 - To what extent can address policy be framed to enable the long-term design and manufacture of efficient, less expensive, less power hungry routers - without overly restricting Internet usage? 2 - To what extent is the length of advertised prefix a factor in the costs, efficiency etc. of FIB functions? 3 - To what extent are DFZ routers, in general, already doing things which are more demanding than required by plain Internet traffic - and therefore, to what extent can the plain traffic burdens be acceptably extended to match what the routers must already be capable of? 4 - Alternatively to 3, would it be feasible to distinguish between routers which handle plain traffic and those which do other fancy things, including MPLS, VPNs etc. as many ISPs want and need to do? I get the feeling the answer to the last question is currently No. In that case, routers will continually get more and more complex and overloaded with functionality which at least some portion of the market requires, with all DFZ routers necessarily being of this over-complex type, despite the actual requirements of plain DFZ traffic, according to actual Internet usage and address policy, being more modest. This is analogous to the car industry only being capable of producing one model, and since some people want some things and others want others, everyone has to buy a Humvee or a Cadillac, because that is the only model they make. I think address policy should be very finely tuned to the realities of router design. On the RAM list we are contemplating a major, kludgy (in my view) overlay of tunnel routers, global database, etc. simply due to the realities of router design not being able to cope with the demands of the BGP control plane with significantly more than the current 220k IPv4 BGP advertised prefixes. The trick would be to get the router people to say, in public, "Our company would find it difficult and expensive to do XYZ . . . " when they are sitting opposite their competitors, who might be prone to say "Sure, we can do that . . .". Maybe such discussions would need to be under the Cone of Silence - but would that run foul of anti-trust laws? Stephen Sprunk wrote, in part: > The IETF has told vendors to not optimize for any particular > route length, and so far it appears they're heeding that advice. If so, I think this would be an abandonment of the IETF's duty to facilitate the efficient operation of the Internet. (I don't recall the RFC which spells this out.) This would be like telling road engineers not to optimise highways for any particular type of traffic: sports cars, the largest trucks, buses, horses with carts, motorbikes, bicycles and trucks carrying oversize objects like parts of houses etc. DFZ traffic has a statistical profile, which changes over time. I think it is vital to set some limits on certain aspects of that to facilitate the design of routers which are optimised for the actual traffic they will handle. It would be nuts to design a router with enough FIB RAM and sufficient memory accesses so it could handle full line rate VoIP packets to /128 prefixes when in reality, this will never be required. The /48 PI prefix lengths already look really long to me. At the very least, I would expect the IETF and the RIRs to be able to say they won't expect DFZ routers to handle traffic packets addressed to anything longer than this for a long time - say to 2020. Many routers will no doubt be able to handle some packets to longer prefixes - but only due to the choice of the ISP to do so. If we insist that this be at no extra cost compared to /48, then the price of the whole router will go up significantly, with all Internet users paying for this, when in fact this faster handling of packets addressed to prefixes longer than /48 is not, or should not, be an actual requirement of handling DFZ traffic. - Robin http://www.firstpr.com.au/ip/ivip/ From rw at firstpr.com.au Tue Aug 21 01:05:09 2007 From: rw at firstpr.com.au (Robin Whittle) Date: Tue, 21 Aug 2007 15:05:09 +1000 Subject: [ppml] Longer prefixes burden the FIBs of DFZ routers In-Reply-To: <63549.74.122.168.81.1187583324.squirrel@look.libertyrms.com> References: <46C906A8.3010204@firstpr.com.au> <63549.74.122.168.81.1187583324.squirrel@look.libertyrms.com> Message-ID: <46CA7285.3060307@firstpr.com.au> Hi Brian, You wrote: >> TCAM can be as wide as 72 bits, and if the router has enough TCAM >> space in its FIB, it doesn't matter how many bits are looked at, >> provided they fit within the 72 or 144 bit width of the TCAM. > > Not quite - the number of entries must fit in the total amount of TCAM > memory. Yes - for brevity I didn't mention this. > The specific entries themselves aren't relegated to only being > the full bitwise representation of a prefix, even if that is the simplest > scheme for storage and lookup. > > E.g., alternatives that use some kind of symbol-mapping scheme, or > hash scheme, or other way of reducing the maximum number of bits > required on a lookup, are one way of reducing both total TCAM memory > used, and number of bits per entry. OK - I don't understand these hash approaches sufficiently. My impression is that they are a messy additional layer of complexity - with some results taking much longer than most - in a field where simplicity and speed, down to individual clock cycles, are crucial. > But, even at 144 bits, i.e. two "slots" per v6 prefix compared to one > per v4 prefix, if the number of slots used is not unreasonable, TCAM > can do the job (and do it in one cycle). TCAM is not used for the FEC (Forwarding Equivalence Class) classification of packets in the recent high-end routers - CRS-1, M120 or MX960. It has some very messy update problems in addition to the high cost, high power consumption, low physical density etc. TCAM needs to drive a fast static RAM too. >> (However TCAM is expensive, power-hungry, must be soldered to the >> main board - can't be upgraded - and can be slow to update when the >> classification rules need to be changed.) > > Expensive, yes; power hungry, yes. It is *not* the case that they *must* > be soldered to the main board - this per Cisco rep at the last NANOG. OK - they must be using special DIMMs or similar. The TCAM chips I am familiar with all have large (hundreds) of ball grid array "pins" and they need a substantial heatsinks, which greatly limits their physical density: http://documentation.renesas.com/eng/products/others/rej03h0001_r8a20211bg.pdf 361 balls, 27mm x 27mm. 266 comparisons per microsecond, for instance 72 bit input data with 256k rules. Generally chips come with detailed power consumption data, but TCAM chip specs often have no such details. They are massive comparator farms with input data ("address") lines and their inverted versions running vertically down the chip and with comparison lines running horizontally. On every cycle, on average half the data lines change state and all (or almost all) the comparison lines change state. There is large capacitance on all these lines and the whole chip is thrashing away, dissipating a lot of power. > And ditto the upgradability. They haven't been made FRUs Field Replaceable Units. > in the past, but > there's nothing intrinsic to them that forces hard-wiring, other than > design cost on the board itself. > > The TCAM standard has advanced, so that the next several generations will > have completely compatible pinouts, specifically so that they *can* become > FRUs. The main idea would be, upgrade TCAMs to higher density units, and > stack more of them in serial on the main board. More total TCAM space, in > the same number of "slots". It is all very well for router manufacturers to crank up their products with more grunt - which we all pay for. More and more TCAMs is not going to solve the overall problems in routing and addressing. Unless something is done, every new multihomed end-user adds at least one prefix, which means one comparison line in the TCAM of every FIB in every DFZ router - and most have a separate FIB for one or a few interfaces. There are at least 123k routers in the DFZ: http://psg.com/lists/rrg/2007/msg00253.html http://psg.com/lists/rrg/2007/msg00262.html >> There's no such thing as a 32 bit lookup unless what you need to >> find is a byte or less and if you have 4 gigabytes of RAM to hold >> the array, which no router's FIB has. > > Wrong. Your idea of "what a router is", is just a little limited, which > is why you believe this to be the case. I was discussing the hardware based, specialised FIB, dual redundant power supplies, etc. Cisco-Juniper-et-al. style routers which are preferred by ISPs for their DFZ routers, due to their physical and software robustness, I guess. > Any reasonably big iron server, with multiple PCI-express buses, > fast and numerous CPUS, and serious enough chip set, can do the job of > "high-end router". 1 x 10GbE per PCI-E bus, nominally 4 or more, > and upwards of 512GB of memory, can be put into a (big) box that runs > routing software (such as quagga). > > Been there, done that, as the saying goes, and yes, it can do DFZ level > routing and forwarding, with tons of capacity for long prefix lookups. This is a field I am interested in, for instance for implementing the ITR (Ingress Tunnel Router) function of my Ivip proposal: http://www.firstpr.com.au/ip/ivip/ If you have some URLs of pages describing such systems, please let me know them. I don't suggest that such server-based systems will be the norm for DFZ routers. > Besides which, there's every reason to believe that one byte can hold > enough information for the result of a route lookup. Think index into an > array of objects, each of which includes in interface index and MAC address. > One byte means 256 such objects, which is likely to be sufficient for the > majority of devices holding default-free routing tables. I would have thought that 8 bits would be fine too. I understand that in larger routers they typically use 16, 32 bits or perhaps more, because they are also specifying specific output queues in particular output interfaces. Still, for Internet traffic packets, as far as I know, there isn't any special queuing - but I may be wrong. - Robin From dean at av8.com Tue Aug 21 01:11:15 2007 From: dean at av8.com (Dean Anderson) Date: Tue, 21 Aug 2007 01:11:15 -0400 (EDT) Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: <46C9CEBA.6070404@internap.com> Message-ID: On Mon, 20 Aug 2007, Scott Leibrand wrote: > Dean, > > Thank you for starting this discussion with a policy proposal. > > IMO we'll need to add some additional guidance to a policy proposal like > this in order to ensure it's implemented in a way that meets the > proposal's goals. For example, here are a few questions we might want > to address: > > * How should rationing be achieved? Should all applicants receive > smaller blocks than their justified usage would otherwise permit? > Should all applications be placed on a waiting list and filled in > a first-come-first-served basis as soon as the rationing function > allows? My perception of the actual inner working of ARIN right now is that requests are handled roughly first come, first served, with the exception that people that get all their documents in order first, get served first. I can't say that this is really the case. But to the extent it is the case, then we already have a system that will work for rationing. Rationing based on a hard limit isn't always fair, but it is often necessary. For example, I recently saw on the news of water rationing after a flood in the UK. The people who get in line first, get their [ration] bottle of water first. This continues until the water buffalo [water tank on wheels] runs out. That's unfair to the people at the back of the line. But there is nothing better, sometimes. Likewise, I don't think we can determine who is 'most worthy' other than those who get in line earliest and get their paperwork in order first. One ISP is just as worthy as the next to get IP Addresses, assuming their documentation is the same. But there are a number of natural side effects that are quite beneficial. To give example of such side effects I'd like to relate an article I read just today about captive insurance strategies in Fortune Small Business Magazine. Captive insurance is where a group of small businesses get together and raise capital for their own insurance upto say $500k, and then purchase reinsurance for larger amounts. This also puts them in control of costs of small claims, because they select the claims to pay and the claims to fight, and they also get the profits when premiums paid in exceeds costs. Employees of these companies also naturally get the message that accidents are paid by the company, not by some nebulous far-off wealthy insurance company. Safety improves and claims decline. The company benefits, the employees benefit. These are beneficial side effects of captive group insurance. Imposing any hard-limit rationing regime will also have side effects on the way ARIN staff perform their duties even without further policy changes. Inclination to toward giving out somewhat smaller blocks and looking more closely at existing allocation and usage are natural ways to serve more people with less resources, and can be done within existing policy. I expect that this will be a natural consequence of a hard limit in any case. Once the ARIN staff realize they have a hard limit, they'll naturally look harder at documentation. This doesn't have to be specified. And if tightening doesn't 'just happen' as a side effect, the hard limit will stop delegations for a little while, and ARIN staff will simply have more time to look at the current requests and documentation. And if that still doesn't work, we can adjust the policy. However, we won't be running out of space for 10 years, so we have some little more time to work this out. I would expect that people who put in requests do not lose the place in line just because the hard limit for a timeframe is hit. I also thought some more about Mr. Herrin's assertion of ambiguity this afternoon. Although I suspect Mr. Herrin may merely be uncomfortable with calculating with exponentials, there are actually several different ways to calculate e^(-x). One could use their scientific calculator; use Maxima, Matlab, Mathematica, etc; use a series expansion; or use a table found a book. Rounding might make some small differnce. However, none of these make any difference to the 'big picture' of preventing IP Address Exhaustion for at least 10 years. In the first example I posted of a decreasing exponential, I described rationing a hundred widgets over 10 years. In the first year, you divide 100 by 10, and so give out 10 in the first year. 90 remain. In the second year, divide 90 by 10, and so give out 9. And so on. This approximation is fine, too. So, I think the method by which they calculate and scale e^(-x) makes no difference to the big picture of keeping address space available for at least 10 years. I think that staff will find some convenient means for doing this. And unless there is some "approximation" that isn't really e^(-x) and causes ARIN to allocate more IP addresses so that we will run out in less than 10 years, I don't think it necessary to impose much on the method or scale factor for calculating e^(-x). But if there is still ambiguity, I suggest the following should be completely clear: AIP is the available IP pool at year 0 (the start) Year 0 is (AIP) * (1/10) * e^(-0/10) = AIP/10 * 1 Year 1 is (AIP) * (1/10) * e^(-1/10) = AIP/10 * 0.9 Year 2 is (AIP) * (1/10) * e^(-2/10) = AIP/10 * 0.8 .... If you want to go by 3 month periods: (40 3 month periods in 10 years) quarter 0 is (AIP) * (1/40) * e^(-0/40) = AIP/40 * 1 quarter 1 is (AIP) * (1/40) * e^(-1/40) = AIP/40 * 0.97 quarter 2 is (AIP) * (1/40) * e^(-2/40) = AIP/40 * 0.95 .... When space is returned, the AIP is calculated, the process starts over at year 0, quarter 0, etc. I think ARIN staff will have a better view as to what timeframe to use conveniently. If they can't decide on a timeframe, then additional guidance will be necessary. Obviously, a very long timeframe is bad, for about the same reasons that extending the timeframe on delegation use is bad. Too short a time frame would be inconvenient, too. > * What mechanisms would be allowed to meet the needs of networks > denied or delayed space under rationing? Would a market be > created/allowed such that networks that really need IP space right > away can purchase it from other networks that can more easily free > up addresses through improved efficiency? Would networks needing > space immediately be encouraged to get ("rent") PA space from a > provider? I don't know about the whole market idea, yet. A market allocates some resources quite effectively (e.g. Oil, Capital, Dry goods), and allocates some things quite badly (e.g. Healthcare, Law Enforcement, Fire Protection, National Security). I haven't quite decided for myself whether IP Addresses are like Oil or are like Healthcare. But I can't deny that a market of a sort exists now, and will probably exist whether or not you try to impose rules on prohibiting that. Quite obviously, people with money who need IP Addresses can buy the ISPs that have already IP Addresses. Like the movie Wall Street, the raider can then turn the just-bought resources to their own more profitable purposes. There is almost no way to stop that; because so far as ARIN is concerned, nothing has changed. The business pages just report ISP X bought ISP Y. Allowing the sale of IP Address blocks on ebay would seem to make little difference. Recently, a person on a mailing list that I read, offered the use of his legacy /24 in exchange for hosting their server. I can't see anything wrong with that. On the other hand, IP Address delegations are basically leases from the government, and the landlords (the government) can specify that the leases either are or aren't transferrable. Usually, one wants some sensible cause for restrictions---e.g. you can't sell the nuclear weapons plant or whatever to just anyone---and so far in the "market" discussion, I haven't seen anyone really show the social harm in allowing blatant IP Address transferral for money. I've only seen hypocritical discussion of what is fair and what limits should be imposed retroactively (and hypocritically) on others. People speak of the probable USG interests; I think the USG will treat the issue of IP Addresses much like it treated frequency spectrum: Up for bid to the highest bidder, possibly subject to FCC regulation where necessary. But I do worry that a market for IP Addresses will eventually result in an Enron-like debacle with traders trying to cause power outages to generate higher prices and more profits. Indeed, the Iraq war seems to have done somewhat the same thing in the Oil industry, but we don't have any tapes (yet) of Dick Cheney or anyone saying the equivalent of 'drop that plant off-line for maintenance during the heat wave' to spike prices like we do for Enron. I've seen a lot (and have also occasionally been victim to) operators and even senior people in the Internet whose morals are about the same or less than those of Enron traders. But of course, the Enron, Worldcom, Adelphia, etc people were eventually found out and went to jail or were fired. If we create a market of IP Addresses, I think an Enron-like debacle is all but certain. So, the question for me is this: Is the benefit of a market worth the trouble? Almost certainly there will be trouble. Almost certainly some people will go to jail on fraud, criminal conspiracy, etc like with Enron etc. But outside the bad events, I think resources might be allocated quite well by a market. But I don't know how damaging the bad events might be. I'd guess they would be somehat similar to, but probably not as bad as, IP Address exhaustion. > * What do you mean by contested IP space? Are you referring to > pre-ARIN allocations and assignments, or something else? No. Just as I explained to Mr. Herrin, "contested" is a broad term to apply to ordinary disputes opened via the ticket system, and also to other disputes that may need to be negotiated or litigated. This is motivated by the Kremen case. It is so that ARIN staff can't ignore court orders, or otherwise pretend that they aren't subject to the jurisdiction of a court or otherwise ignore disputes. I think this issue has to be written into policies in some way. The provision I wrote doesn't change anything else, but just prevents ARIN from considering contested space in its space available. That affects the hard limit function. The provision consequently ensures that should ARIN "lose" the ensuing negotiation or court case, there will be space available. > I'm not sure if a rationing policy would be better than the Soft > Landing proposal, but IMO rationing is an idea worth fleshing out and > considering as an alternative. Thanks. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From dean at av8.com Tue Aug 21 01:13:34 2007 From: dean at av8.com (Dean Anderson) Date: Tue, 21 Aug 2007 01:13:34 -0400 (EDT) Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A0272F9CF@nyrofcs2ke2k01.corp.pvt> Message-ID: On Mon, 20 Aug 2007, Azinger, Marla wrote: > What I think we need more is: 1. How do we manage and re-use returned > space? Why would returned space be any different than space currently available? -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From sleibrand at internap.com Tue Aug 21 02:06:10 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 20 Aug 2007 23:06:10 -0700 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: References: Message-ID: <46CA80D2.8050303@internap.com> Ok. So to paraphrase, you anticipate that the rationing will lead to more stringent review of IPv4 applications, and that once the IPv4 addresses available for a particular period (month/quarter/year/whatever) are used up, applications will be waitlisted and filled on a FCFS basis at the start of the next period. That seams like a reasonably fair way to do things, at least until the waitlist starts getting long, at which point it might be worthwhile to start partially filling requests and require applicants to reapply and get back in line as soon as they use their partial allocation. It might be worthwhile exploring such options as part of the policy process, but I can also see the wisdom in allowing ARIN staff the leeway to manage the rationing as needed based on changing conditions. One thing I think we ought to consider is adjusting the timeframe. (I'll use your "divide by N" approximation, as it's easier to think about.) Under your proposal, with N=10, I would anticipate that we would begin seeing the impact of rationing immediately, and that the impacts may be large. Another option would be to set N to a lower value, say 5. Since we're approximately 5 years away from exhaustion at current projected rates, that may mean we can "ease into" the rationing regime, which may be advantageous. If we did that, we wouldn't run out of IPv4 space in 5 years, because each year the ration decreases exponentially, so that the smaller and smaller free pool continues to be extended until IPv6 adoption takes off and IPv4 space starts getting returned faster than it's given out. Another consideration is what to do about global coordination. As it stands today, the large pool of free IPv4 space is managed by IANA, which gives it out to RIRs as they use it. If ARIN were to adopt a strict rationing regime, say with N=10, but the other RIRs did not do so, then ARIN would see most of the remaining free pool used up by other RIRs, which ARIN became less and less able to fill its members IPv4 requests. Because of this concern, I think it's important to define how ARIN's rationing interacts with other RIRs assignment practices. One approach would be to try for a globally coordinated rationing system. Another would be to push for IANA to divide the free pool up in advance, and delay stringent rationing until ARIN has a fixed-size pool to work with. Do you have any thoughts on how to manage that aspect of things? With regards to markets, I agree with you that an unregulated free market in IPv4 space would be a disaster. I foresee something more closely managed, where perhaps someone wanting IPv4 space would first go to ARIN, get their justification approved, and then would have the option of either getting on the waitlist for available space or buying space, up to the amount they were able to justify, on a market. ARIN would then approve the sale, update the registry, and take the applicant off the waitlist. In any event, I see an IPv4 market as something that will only be useful once we exhaust the IPv4 free pool, or start a stringent rationing regime. So we should probably focus on proposals like Soft Landing and Rationing to deal with the runout phase, and then start thinking about markets, reclamation, etc. as soon as we have good runout policies in place. As for contested space, I agree that we need to put policies in place that constrain any possible unethical behavior, regardless of whether we agree or disagree on the ethics of various individuals or their past actions. I think the public policy process has largely done a good job creating such policies to date, and have no problem with your contested space clause in this policy proposal. -Scott Dean Anderson wrote: > On Mon, 20 Aug 2007, Scott Leibrand wrote: > > >> Dean, >> >> Thank you for starting this discussion with a policy proposal. >> >> IMO we'll need to add some additional guidance to a policy proposal like >> this in order to ensure it's implemented in a way that meets the >> proposal's goals. For example, here are a few questions we might want >> to address: >> >> * How should rationing be achieved? Should all applicants receive >> smaller blocks than their justified usage would otherwise permit? >> Should all applications be placed on a waiting list and filled in >> a first-come-first-served basis as soon as the rationing function >> allows? >> > > My perception of the actual inner working of ARIN right now is that > requests are handled roughly first come, first served, with the > exception that people that get all their documents in order first, get > served first. I can't say that this is really the case. But to the > extent it is the case, then we already have a system that will work for > rationing. Rationing based on a hard limit isn't always fair, but it is > often necessary. > > For example, I recently saw on the news of water rationing after a flood > in the UK. The people who get in line first, get their [ration] bottle > of water first. This continues until the water buffalo [water tank on > wheels] runs out. That's unfair to the people at the back of the line. > But there is nothing better, sometimes. Likewise, I don't think we can > determine who is 'most worthy' other than those who get in line earliest > and get their paperwork in order first. One ISP is just as worthy as > the next to get IP Addresses, assuming their documentation is the same. > > But there are a number of natural side effects that are quite > beneficial. To give example of such side effects I'd like to relate an > article I read just today about captive insurance strategies in Fortune > Small Business Magazine. Captive insurance is where a group of small > businesses get together and raise capital for their own insurance upto > say $500k, and then purchase reinsurance for larger amounts. This also > puts them in control of costs of small claims, because they select the > claims to pay and the claims to fight, and they also get the profits > when premiums paid in exceeds costs. Employees of these companies also > naturally get the message that accidents are paid by the company, not by > some nebulous far-off wealthy insurance company. Safety improves and > claims decline. The company benefits, the employees benefit. These are > beneficial side effects of captive group insurance. > > Imposing any hard-limit rationing regime will also have side effects on > the way ARIN staff perform their duties even without further policy > changes. Inclination to toward giving out somewhat smaller blocks and > looking more closely at existing allocation and usage are natural ways > to serve more people with less resources, and can be done within > existing policy. I expect that this will be a natural consequence of a > hard limit in any case. Once the ARIN staff realize they have a hard > limit, they'll naturally look harder at documentation. This doesn't > have to be specified. > > And if tightening doesn't 'just happen' as a side effect, the hard limit > will stop delegations for a little while, and ARIN staff will simply > have more time to look at the current requests and documentation. > > And if that still doesn't work, we can adjust the policy. However, we > won't be running out of space for 10 years, so we have some little more > time to work this out. > > I would expect that people who put in requests do not lose the place in > line just because the hard limit for a timeframe is hit. > > I also thought some more about Mr. Herrin's assertion of ambiguity this > afternoon. Although I suspect Mr. Herrin may merely be uncomfortable > with calculating with exponentials, there are actually several different > ways to calculate e^(-x). One could use their scientific calculator; > use Maxima, Matlab, Mathematica, etc; use a series expansion; or use a > table found a book. Rounding might make some small differnce. > However, none of these make any difference to the 'big picture' of > preventing IP Address Exhaustion for at least 10 years. > > In the first example I posted of a decreasing exponential, I described > rationing a hundred widgets over 10 years. In the first year, you divide > 100 by 10, and so give out 10 in the first year. 90 remain. In the > second year, divide 90 by 10, and so give out 9. And so on. This > approximation is fine, too. So, I think the method by which they > calculate and scale e^(-x) makes no difference to the big picture of > keeping address space available for at least 10 years. I think that > staff will find some convenient means for doing this. And unless there > is some "approximation" that isn't really e^(-x) and causes ARIN to > allocate more IP addresses so that we will run out in less than 10 > years, I don't think it necessary to impose much on the method or scale > factor for calculating e^(-x). > > But if there is still ambiguity, I suggest the following should be > completely clear: > > AIP is the available IP pool at year 0 (the start) > > Year 0 is (AIP) * (1/10) * e^(-0/10) = AIP/10 * 1 > Year 1 is (AIP) * (1/10) * e^(-1/10) = AIP/10 * 0.9 > Year 2 is (AIP) * (1/10) * e^(-2/10) = AIP/10 * 0.8 > .... > > If you want to go by 3 month periods: (40 3 month periods in 10 years) > > quarter 0 is (AIP) * (1/40) * e^(-0/40) = AIP/40 * 1 > quarter 1 is (AIP) * (1/40) * e^(-1/40) = AIP/40 * 0.97 > quarter 2 is (AIP) * (1/40) * e^(-2/40) = AIP/40 * 0.95 > .... > > When space is returned, the AIP is calculated, the process starts over > at year 0, quarter 0, etc. I think ARIN staff will have a better view > as to what timeframe to use conveniently. If they can't decide on a > timeframe, then additional guidance will be necessary. Obviously, a > very long timeframe is bad, for about the same reasons that extending > the timeframe on delegation use is bad. Too short a time frame would be > inconvenient, too. > > > > >> * What mechanisms would be allowed to meet the needs of networks >> denied or delayed space under rationing? Would a market be >> created/allowed such that networks that really need IP space right >> away can purchase it from other networks that can more easily free >> up addresses through improved efficiency? Would networks needing >> space immediately be encouraged to get ("rent") PA space from a >> provider? >> > > I don't know about the whole market idea, yet. A market allocates some > resources quite effectively (e.g. Oil, Capital, Dry goods), and > allocates some things quite badly (e.g. Healthcare, Law Enforcement, > Fire Protection, National Security). I haven't quite decided for myself > whether IP Addresses are like Oil or are like Healthcare. > > But I can't deny that a market of a sort exists now, and will probably > exist whether or not you try to impose rules on prohibiting that. > Quite obviously, people with money who need IP Addresses can buy the > ISPs that have already IP Addresses. Like the movie Wall Street, the > raider can then turn the just-bought resources to their own more > profitable purposes. There is almost no way to stop that; because so > far as ARIN is concerned, nothing has changed. The business pages just > report ISP X bought ISP Y. Allowing the sale of IP Address blocks on > ebay would seem to make little difference. > > Recently, a person on a mailing list that I read, offered the use of his > legacy /24 in exchange for hosting their server. I can't see anything > wrong with that. > > On the other hand, IP Address delegations are basically leases from the > government, and the landlords (the government) can specify that the > leases either are or aren't transferrable. Usually, one wants some > sensible cause for restrictions---e.g. you can't sell the nuclear > weapons plant or whatever to just anyone---and so far in the "market" > discussion, I haven't seen anyone really show the social harm in > allowing blatant IP Address transferral for money. I've only seen > hypocritical discussion of what is fair and what limits should be > imposed retroactively (and hypocritically) on others. People speak of > the probable USG interests; I think the USG will treat the issue of IP > Addresses much like it treated frequency spectrum: Up for bid to the > highest bidder, possibly subject to FCC regulation where necessary. > > But I do worry that a market for IP Addresses will eventually result in > an Enron-like debacle with traders trying to cause power outages to > generate higher prices and more profits. Indeed, the Iraq war seems to > have done somewhat the same thing in the Oil industry, but we don't have > any tapes (yet) of Dick Cheney or anyone saying the equivalent of 'drop > that plant off-line for maintenance during the heat wave' to spike > prices like we do for Enron. I've seen a lot (and have also > occasionally been victim to) operators and even senior people in the > Internet whose morals are about the same or less than those of Enron > traders. But of course, the Enron, Worldcom, Adelphia, etc people were > eventually found out and went to jail or were fired. > > If we create a market of IP Addresses, I think an Enron-like debacle is > all but certain. So, the question for me is this: Is the benefit of a > market worth the trouble? Almost certainly there will be trouble. > Almost certainly some people will go to jail on fraud, criminal > conspiracy, etc like with Enron etc. But outside the bad events, I > think resources might be allocated quite well by a market. But I don't > know how damaging the bad events might be. I'd guess they would be > somehat similar to, but probably not as bad as, IP Address exhaustion. > > >> * What do you mean by contested IP space? Are you referring to >> pre-ARIN allocations and assignments, or something else? >> > > No. Just as I explained to Mr. Herrin, "contested" is a broad term to > apply to ordinary disputes opened via the ticket system, and also to > other disputes that may need to be negotiated or litigated. This is > motivated by the Kremen case. It is so that ARIN staff can't ignore > court orders, or otherwise pretend that they aren't subject to the > jurisdiction of a court or otherwise ignore disputes. I think this > issue has to be written into policies in some way. The provision I wrote > doesn't change anything else, but just prevents ARIN from considering > contested space in its space available. That affects the hard limit > function. The provision consequently ensures that should ARIN "lose" the > ensuing negotiation or court case, there will be space available. > > >> I'm not sure if a rationing policy would be better than the Soft >> Landing proposal, but IMO rationing is an idea worth fleshing out and >> considering as an alternative. >> > > Thanks. > > --Dean > > From michael.dillon at bt.com Tue Aug 21 05:15:11 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 21 Aug 2007 10:15:11 +0100 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 In-Reply-To: References: <20070820191710.GA96789@ussenterprise.ufp.org> Message-ID: > As for whether /48 is the right choice or not, I honestly do > not know. I certainly do not see any reason to increase it. > How many end users on the planet could justify a /47? As far as I can see there are only two types of end user that can justify a /47. The first type is a large campus-type facility with lots of network infrastructure, for instance a large military base or Microsoft's central campus in the Seattle area. The second type is the large corporation with many, many scattered geographical locations which wishes to maintain tight control over Internet access by providing a single Internet gateway and connecting their locations using a VPN. There just aren't very many large campus-type facilities around that won't fit into a /48. They need to have a larger than usual internal usage of networks. And large corporations will think very careful before taking on the scaling challenges of a single Internet gateway combined with the introduction of a new Internet protocol. The same infrastructure that is used to hookup the locations to the VPN can be used for IPv6 Internet access and issues of control can be dealt with using smaller local IPv6 firewalls which removes the need to deal with scaling issues. In that case, each location will get its own /48 and their network architects can design a handful of site templates based on a /48 subnetting scheme. The ability to evade scaling issues and at the same time standardize network designs will be a big motivator for larger corporates to NOT chase /47 allocations but to just accept the local ISP's /48 allocations. Also, since IPv6 allows for multiple addresses per site, they are not stuck with just accepting random ISP assignments. They can also overlay this with central corporate addresses for important devices such as firewalls, servers, etc. and they can still have a VPN as well. This allows doing things like configuring all mail server (or mail server proxy gateways) with the same interface id, e.g. F1F0:F1F0:F1F0:F1F0 The English-speaking world has not had a lot of experience setting up IPv6 networks so we still don't know exactly how people will use this. One thing is sure, enterprise network designers often do not design things the same way as ISPs do. They have different goals, different toolsets, and different thought leaders. --Michael Dillon From pesherb at yahoo.com Tue Aug 21 09:37:18 2007 From: pesherb at yahoo.com (Peter Sherbin) Date: Tue, 21 Aug 2007 06:37:18 -0700 (PDT) Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines Message-ID: <762402.35476.qm@web58715.mail.re1.yahoo.com> You may want to look at the draft below, which aims at solving multiple items in this discussion. Peter A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sherbin-eia-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Elements of The Internet Architecture > Author(s) : P. Sherbin > Filename : draft-sherbin-eia-00.txt > Pages : 8 > Date : 2007-8-10 > > This document outlines the Internet architecture that can scale to > interconnect a very large number of communicating devices. It aims > at presenting a holistic view of the Internet various parts from > routing to number management as well as their interdependencies. The > draft also indicates the Internet cost drivers and cost vectors. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sherbin-eia-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request at ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-sherbin-eia-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv at ietf.org. > In the body type: > "FILE /internet-drafts/draft-sherbin-eia-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader implementation to > automatically retrieve the ASCII version of the Internet-Draft. > > > > > ____________________________________________________________________________________ > Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims > Stories at Yahoo! Games. > http://sims.yahoo.com/ > > -- > to unsubscribe send a message to rrg-request at psg.com with the > word 'unsubscribe' in a single line as the message text body. > archive: & ftp://psg.com/pub/lists/rrg > ____________________________________________________________________________________ Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/ From dlw+arin at tellme.com Tue Aug 21 11:28:41 2007 From: dlw+arin at tellme.com (David Williamson) Date: Tue, 21 Aug 2007 08:28:41 -0700 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 In-Reply-To: References: <20070820191710.GA96789@ussenterprise.ufp.org> Message-ID: <20070821152841.GX28312@shell01.cell.sv2.tellme.com> On Tue, Aug 21, 2007 at 10:15:11AM +0100, michael.dillon at bt.com wrote: > There just aren't very many large campus-type facilities around that > won't fit into a /48. ...and most such orgs will find a way to qualify as an ISP and get a /32 anyway. Given that we now all agree that essentially no one will need anything more than a /48 for an end-site, what is it in Leo's proposal that you don't like? If anything, it's perhaps unnecessary...but it still strikes me as a good idea to track any assignment larger than /48. -David From Ed.Lewis at neustar.biz Tue Aug 21 11:20:38 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 21 Aug 2007 11:20:38 -0400 Subject: [ppml] Technical reason why /52,/56,/60,/64 are bad In-Reply-To: <46C8FA8D.3080500@psg.com> References: <46C8EE92.7090201@firstpr.com.au> <46C8F303.6090209@internap.com> <46C8FA8D.3080500@psg.com> Message-ID: At 16:21 -1000 8/19/07, Randy Bush wrote: >> The Assignment Guidelines proposal attempts to dictate what size >> prefixes LIRs (ISPs) assign to their customers. > >and who the hell gives arin this wonderful new prerogative to tell me >how to run my business? and what will you do when i completely ignore >it because it is none of your business? I apologize for not resisting (further) to read the entire thread before posting. I want to add on something to Randy's comment. In 2005 I saw the development and presentation of an IPv6 idea at ARIN (Orlando), RIPE (Stockholm), and APNIC (Hanoi). After witnessing this, I realized this: 1) The RIRs only care about the assignments because they want to measure utilization (primarily when a request for more comes in). 2) The RIRs ought to stay away from any recommendations about operations. 3) The RIRs ought to stay away from any recommendations about the protocol. (As in, how many bits are needed in the "host part.") Given this, the proposals ought to avoid "assign" these prefixes but rather emphasize "we will measure utilization on these prefixes." Violating #2 resulted in rat holing on aggregation practices and elicits comments like Randy's above. (No offense Randy...) I recall the "rebirth" of the class-full space in IPv6 comment at APNIC. Violating #3 resulted in rat holing on new uses of IPv6 (addressing ice makers) and why so many bits are in the host part of the address. I urge the policies to document what ARIN does - measure utilization in this case - and stick to just that. If ARIN wants to measure utilization of private residences on /56's and sub-netted networks on /48, that is reasonable but don't give the impression of dictating an addressing strategy. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. From stephen at sprunk.org Tue Aug 21 12:00:06 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 21 Aug 2007 11:00:06 -0500 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines References: <9a5f82a45c9adc4f8af87c31625f4a50@mail.dessus.com> Message-ID: <01b201c7e40e$5b3280e0$483816ac@atlanta.polycom.com> Thus spake "Keith Medcalf" > And more to the point: If every holder of a IPv4 routing slot > (whether ISP or, like me, a legacy PI /24 holder) was "granted" > a /28 and they were all routed in the DFZ, do you believe that > the IPv6 table would contain any more entries than it currently > does, if the current IPv4 rules were immediately thereafter > imposed on future IPv6 and ASN allocations/assignments > (with changes re size in that all IPv6 are /28). > > Would not the table merely double in size (entry-wise that is)? As of last Friday, there were 25995 ASes and 228981 routes visible in the DFZ, or 8.8 routes/AS. Of those ASes, 11060 were origin-only ASes only announcing a single route; the other 14935 ASes accounted for 218921 routes, or 14.6 routes/AS. Several ASes announce over a thousand routes each, and many, many more announce hundreds each. If we were able to give exactly one address block per AS in v6, which is a goal of many of us, that means (in the absence of TE) the v6 routing table would be just over one tenth the size of the v4 table. Of course, TE messes that up, but the impact can be limited by mechanisms that ensure TE deaggregates only travel a few ASes away instead of polluting routing tables worldwide. That may not help the largest ISPs much, but at least it'll keep the problem mostly local to the folks who are causing it. > Could this be handled in the DFZ at present? If it can then > there are no worries at all. You then need to evaluate if such a > happening would be a best-case or a worst-case outcome ... > or perhaps something in between that can be worked with. I don't expect the number of routes in the v6 DFZ to be substantially smaller than with v4 -- but with fewer routes per player, we can accomodate more players. > If this could not be handled in the DFZ at present, then there is > a clear need to 'guide' the migration toward a more acceptable > end-point. There are ISPs who claim their routers are on the verge of falling over already, but not because of DFZ size -- they're carrying gobs of internal and MPLS VPN routes. The DFZ is just another thing they need to find space for in their routers, and it's not trivial but nor is it anywhere near today's limits on its own. 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 david.kessens at nsn.com Tue Aug 21 14:25:54 2007 From: david.kessens at nsn.com (David Kessens) Date: Tue, 21 Aug 2007 11:25:54 -0700 Subject: [ppml] IPv6 Assignment Guidelines, Straw Man #2 In-Reply-To: <20070820230050.GA13563@ussenterprise.ufp.org> References: <193A01A3-DC10-4139-8211-1734281C296F@virtualized.org> <03e201c7e36e$d1fd61e0$573816ac@atlanta.polycom.com> <20070820230050.GA13563@ussenterprise.ufp.org> Message-ID: <20070821182554.GA31743@nsn.com> Leo, On Mon, Aug 20, 2007 at 07:00:50PM -0400, Leo Bicknell wrote: > In a message written on Mon, Aug 20, 2007 at 04:02:00PM -0500, Stephen Sprunk wrote: > > ... and most ARIN members don't have that many customers. Those that do > > mainly provide residential service and will be handing out /56's at most to > > those customers, giving them just shy of 17M assignments before they need > > more space. I'd expect those folks are smart enough to ask for larger > > allocations up front to save hassle later. > > You mean, like these smart folks... > > inet6num: 2003::/19 > netname: DE-TELEKOM-20050113 > descr: Deutsche Telekom AG > country: DE > > inet6num: 2a01:c000::/19 > netname: FR-TELECOM-20051230 > descr: France Telecom > country: FR > > For the record, a /19 is 536,870,912 /48 assignments. There's 64 > million people in France, 83 million in Germany. All of those > people could get 5 /48's FROM BOTH PROVIDERS (10 total) with that > much space. I don't see what the number of people in France or Germany has anything to do with the size of their allocations. Both companies are multinational operations. I am sure you are familiar with the concept that allocations are based on the number of customers they have, not on the number of people in a particular country. For the record, I actually agree that /48's for residential customers are a bit at the lavish side ... Also, I am actually not convinced that these kind of superallocations are actually supported by the current IPv6 policies. The policy is quite detailed about /32 allocations but has few words on what to do when there is the perception that somebody might need more. That was done on purpose at the time as people felt that it was more important to get a policy out the door so that people could finally receive IPv6 allocations and to allow the policy to get refined when more experience is gained with LIRs that actually manage to sign up more than 200 or so ipv6 customers. I for one am quite surprised that it has been interpreted by at least one RIR that one can get these very large allocations even without first starting with a /32 and not even having 200 IPv6 customers signed up and/or a running native ipv6 network that spans more than a couple of links. On the other hand, some of these very large enterprises tend to roll out services to all their customers at once in a particular region and I can see that they might have a need to grow beyond a /32 if they really get started. However, it seems that a sparse allocation scheme could do the job in such cases. At the same time, what is really the (routing system) cost if only the biggest providers end up with a few prefixes ? In fact, they might actually have to deaggretate their space anyways if they got one very big block. David Kessens --- From tedm at ipinc.net Tue Aug 21 16:41:22 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 21 Aug 2007 13:41:22 -0700 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Dean Anderson >Sent: Monday, August 20, 2007 10:11 PM >To: Scott Leibrand >Cc: ppml at arin.net >Subject: Re: [ppml] Policy Proposal: Decreasing Exponential Rationing of >IPv4 IP Addresses > >often necessary. > >For example, I recently saw on the news of water rationing after a flood >in the UK. The people who get in line first, get their [ration] bottle >of water first. This continues until the water buffalo [water tank on >wheels] runs out. That's unfair to the people at the back of the line. This is a false analogy. First, the people at the end of the line can see how many people are ahead of them and see that everyone gets 1 ration. They can see how big the rations are and estimate how long the line would have to be to exhaust the water buffalo. So if the line was long enough then they wouldn't waste time and energy waiting in line since they would know there was no chance of getting water. With IPv4 we don't know how many people are on the waiting list and how big their allocations are. So in a waitlist situation there is no disincentive to attempting to get IPv4 Since you don't know what is going to happen you might as well try waiting. The extra waiting just uses up ARIN time and resources. >hard limit in any case. Once the ARIN staff realize they have a hard >limit, they'll naturally look harder at documentation. This doesn't >have to be specified. > ARIN already looks hard at documentation, it's kind of insulting to imply that they don't. What do you want ARIN staff to do? Get on an airplane and fly to the site needing the IP numbering to make a physical verification of all the systems there? There's no way they can look harder than they are already doing without incurring gigantic amounts of time and resources. >And if that still doesn't work, we can adjust the policy. However, we >won't be running out of space for 10 years, so we have some little more >time to work this out. > And in 20 years when IPv4 runout is imminent, people will use your same logic to justify even sillier restrictions on IPv4 and the Internet will not yet be switched over. Are you the guy that likes the doctor to rip the bandage off real quick or do you like them to pull it slow as they can? Sounds like you like your pain stretched out. Most people don't. Let's get this thing over and done with and go on to the next thing. > >I don't know about the whole market idea, yet. A market allocates some >resources quite effectively (e.g. Oil, Capital, Dry goods), and >allocates some things quite badly (e.g. Healthcare, Law Enforcement, >Fire Protection, National Security). I haven't quite decided for myself >whether IP Addresses are like Oil or are like Healthcare. > Market allocation of oil is an inmitigated disaster. Conservation is discouraged in some areas - like the United States with it's gas-hogging SUVs, and Veneswalia where the government subsidizes gas - and encouraged in other places, like Japan. >But I can't deny that a market of a sort exists now, and will probably >exist whether or not you try to impose rules on prohibiting that. >Quite obviously, people with money who need IP Addresses can buy the >ISPs that have already IP Addresses. Yes, so what? Not all ISPs are for sale at any price. And it quickly gets to the point that buying the ISP is more expensive then just upgrading your network to IPv6 and proxy servers and suchlike. Look at AOL. Everyone on it uses this fugly piece of garbage software that loads on their machine and literally rapes it - destroys all existing networking in the system. Do you think the AOL users know what is really under the hood that is transporting their Internet connectivity? Do you think they care? Think of how many AOL users are out there. Your coming from the approach that it's a Good Thing to stretch out IPv4. With the implication that there is something wrong with IPv6. What? Why do we want to delay IPv6 deployment? What are we waiting for? Once IPv4 runout happens, Windows Vista deployment will be penetrated enough to make IPv6 switchover easy enough. > Like the movie Wall Street, the >raider can then turn the just-bought resources to their own more >profitable purposes. There is almost no way to stop that; because so >far as ARIN is concerned, nothing has changed. The business pages just >report ISP X bought ISP Y. Allowing the sale of IP Address blocks on >ebay would seem to make little difference. > Then if it would make little difference then simply don't allow it and tell the ISP they have to buy the other ISP. After all "it makes little difference" >Recently, a person on a mailing list that I read, offered the use of his >legacy /24 in exchange for hosting their server. I can't see anything >wrong with that. > >On the other hand, IP Address delegations are basically leases from the >government, Absolutely not. What government. Show cites please, >and the landlords (the government) can specify that the >leases either are or aren't transferrable. Numbers are not property. >Usually, one wants some >sensible cause for restrictions---e.g. you can't sell the nuclear >weapons plant or whatever to just anyone---and so far in the "market" >discussion, I haven't seen anyone really show the social harm in >allowing blatant IP Address transferral for money. It's been discussed. Allowing IP addressing to become property, which would be a requirement to permit "sales", allows politics and government to get involved. So, your competitor ISP makes a big political donation to a senatorial campaign and a month later you find the government Bureau of IP numbers has just launched an investigation on your ISP's use of IP numbering and is legally demanding that you turn over a stack of paperwork that is going to take you literally 100 man hours to produce - and they will then spend another 500 hours and the next year arguing with you with a fine toothed comb. Oh sure, you haven't violated your contract and will be exonerated - but they will suck all your time away doing it which will destroy you anyway. You want this? >Addresses much like it treated frequency spectrum: Up for bid to the >highest bidder, possibly subject to FCC regulation where necessary. > Examine the skulduggery behind sales of frequency spectrum to "the highest bidder" then ponder if radio and TV will be the better for having just a handful of deep-pocket companies controlling it all. > >If we create a market of IP Addresses, I think an Enron-like debacle is >all but certain. So, the question for me is this: Is the benefit of a >market worth the trouble? Almost certainly there will be trouble. >Almost certainly some people will go to jail on fraud, criminal >conspiracy, etc like with Enron etc. But outside the bad events, I >think resources might be allocated quite well by a market. This logic is young and naieve and has no clue how big government and big business and politics work. The large ISP's have one thing the small ISPs don't have - deep pockets. If you put IP allocation into the market, the big ISP will simply use their deep pockets to put the rest of us out of business. Every heard the expression, he who has the gold makes the rules? We don't need this and we don't want it. And if it ever happens then the Internet will become as bland as the soft drink market, where coke and pepsi control virtually all of it, and are so interchangable that 3/4 of the people couldn't take the pepsi challenge and tell the difference. Why do you think pepsi stopped that marketing campaign? > The provision consequently ensures that should ARIN "lose" the >ensuing negotiation or court case, there will be space available. > If any future court case like this were to come up the best thing would be for ARIN to transfer jurisdiction to an RIR outside of the national court's jurisdiction. This is how you solve these things on a global scale. The court can then complain to the government and take it up with the United Nations where it belongs By the time those folks get done with it, it will be a moot issue. Ted From Daniel_Alexander at Cable.Comcast.com Tue Aug 21 16:49:31 2007 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Tue, 21 Aug 2007 16:49:31 -0400 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: References: <46C9CEBA.6070404@internap.com> Message-ID: <997BC128AE961E4A8B880CD7442D9480013AD63F@NJCHLEXCMB01.cable.comcast.com> Dean, There are several proposals that try to delay the depletion of IPv4 by restricting or rationing demand. One conern I have is the assumption that demand is primarily based on waste, hoarding and inefficiencies. Rationing of IP space currently exists with the RIR's in the form of the slow start method of allocation. While it may not be 100% efficient, one advantage is it rations IP allocations without restricting demand. Rationing, by restricting demand, ensures that IP are available for those who may need them in the future, by denying those who may need them in the present. Don't you trade one problem for another at that point. My opinion is that policy should never inhibit the genuine growth of the Internet. If the concern is hoarding, then the focus should be on reclaiming unused allocations, rather than prohibiting natural growth. I'll use the company I work for as an example. Not too long ago, we started offering VoIP services. We planned on a nationwide deployment, and marketing had ambitious goals for the number of devices deployed the first year. (as they often do). To deploy the service across our entire footprint, it was determined we would need X number of IP. (scopes of a certain size to be deployed on the CMTS and provisioned to the customer through DHCP) When ARIN provided the allocation to deploy the service, they used the slow start mechanisms. Their response was, we know you are asking for X, but you have no historical data to back that up. Therefore, we were given a percentage of X. Once that is used according to the utilization policies, we could then ask for more. In the end, that allocation only lasted us a month, given the rate the service took off. We had to juggle allocations, and renumber IP space to where it was needed most, to allow the time needed for a history of proven growth to develop, before ARIN would allocate larger blocks of IP space. If a strict approach to rationing is taken, what happens when a company needs IP for new customers, but is not provided them by the RIR. That scenario, is no different than if the IANA pool was allowed to deplete. It won't matter if the possibility exists they could get more the next time their turn came up. The customer has already gone elsewhere. Isn't IPv4 better served by ensuring those who need it get it, and those that aren't using it give it back, rather than restricting natural growth? Thanks, -Dan Alexander -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Dean Anderson Sent: Tuesday, August 21, 2007 1:11 AM To: Scott Leibrand Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses On Mon, 20 Aug 2007, Scott Leibrand wrote: > Dean, > > Thank you for starting this discussion with a policy proposal. > > IMO we'll need to add some additional guidance to a policy proposal > like this in order to ensure it's implemented in a way that meets the > proposal's goals. For example, here are a few questions we might want > to address: > > * How should rationing be achieved? Should all applicants receive > smaller blocks than their justified usage would otherwise permit? > Should all applications be placed on a waiting list and filled in > a first-come-first-served basis as soon as the rationing function > allows? My perception of the actual inner working of ARIN right now is that requests are handled roughly first come, first served, with the exception that people that get all their documents in order first, get served first. I can't say that this is really the case. But to the extent it is the case, then we already have a system that will work for rationing. Rationing based on a hard limit isn't always fair, but it is often necessary. For example, I recently saw on the news of water rationing after a flood in the UK. The people who get in line first, get their [ration] bottle of water first. This continues until the water buffalo [water tank on wheels] runs out. That's unfair to the people at the back of the line. But there is nothing better, sometimes. Likewise, I don't think we can determine who is 'most worthy' other than those who get in line earliest and get their paperwork in order first. One ISP is just as worthy as the next to get IP Addresses, assuming their documentation is the same. But there are a number of natural side effects that are quite beneficial. To give example of such side effects I'd like to relate an article I read just today about captive insurance strategies in Fortune Small Business Magazine. Captive insurance is where a group of small businesses get together and raise capital for their own insurance upto say $500k, and then purchase reinsurance for larger amounts. This also puts them in control of costs of small claims, because they select the claims to pay and the claims to fight, and they also get the profits when premiums paid in exceeds costs. Employees of these companies also naturally get the message that accidents are paid by the company, not by some nebulous far-off wealthy insurance company. Safety improves and claims decline. The company benefits, the employees benefit. These are beneficial side effects of captive group insurance. Imposing any hard-limit rationing regime will also have side effects on the way ARIN staff perform their duties even without further policy changes. Inclination to toward giving out somewhat smaller blocks and looking more closely at existing allocation and usage are natural ways to serve more people with less resources, and can be done within existing policy. I expect that this will be a natural consequence of a hard limit in any case. Once the ARIN staff realize they have a hard limit, they'll naturally look harder at documentation. This doesn't have to be specified. And if tightening doesn't 'just happen' as a side effect, the hard limit will stop delegations for a little while, and ARIN staff will simply have more time to look at the current requests and documentation. And if that still doesn't work, we can adjust the policy. However, we won't be running out of space for 10 years, so we have some little more time to work this out. I would expect that people who put in requests do not lose the place in line just because the hard limit for a timeframe is hit. I also thought some more about Mr. Herrin's assertion of ambiguity this afternoon. Although I suspect Mr. Herrin may merely be uncomfortable with calculating with exponentials, there are actually several different ways to calculate e^(-x). One could use their scientific calculator; use Maxima, Matlab, Mathematica, etc; use a series expansion; or use a table found a book. Rounding might make some small differnce. However, none of these make any difference to the 'big picture' of preventing IP Address Exhaustion for at least 10 years. In the first example I posted of a decreasing exponential, I described rationing a hundred widgets over 10 years. In the first year, you divide 100 by 10, and so give out 10 in the first year. 90 remain. In the second year, divide 90 by 10, and so give out 9. And so on. This approximation is fine, too. So, I think the method by which they calculate and scale e^(-x) makes no difference to the big picture of keeping address space available for at least 10 years. I think that staff will find some convenient means for doing this. And unless there is some "approximation" that isn't really e^(-x) and causes ARIN to allocate more IP addresses so that we will run out in less than 10 years, I don't think it necessary to impose much on the method or scale factor for calculating e^(-x). But if there is still ambiguity, I suggest the following should be completely clear: AIP is the available IP pool at year 0 (the start) Year 0 is (AIP) * (1/10) * e^(-0/10) = AIP/10 * 1 Year 1 is (AIP) * (1/10) * e^(-1/10) = AIP/10 * 0.9 Year 2 is (AIP) * (1/10) * e^(-2/10) = AIP/10 * 0.8 .... If you want to go by 3 month periods: (40 3 month periods in 10 years) quarter 0 is (AIP) * (1/40) * e^(-0/40) = AIP/40 * 1 quarter 1 is (AIP) * (1/40) * e^(-1/40) = AIP/40 * 0.97 quarter 2 is (AIP) * (1/40) * e^(-2/40) = AIP/40 * 0.95 .... When space is returned, the AIP is calculated, the process starts over at year 0, quarter 0, etc. I think ARIN staff will have a better view as to what timeframe to use conveniently. If they can't decide on a timeframe, then additional guidance will be necessary. Obviously, a very long timeframe is bad, for about the same reasons that extending the timeframe on delegation use is bad. Too short a time frame would be inconvenient, too. > * What mechanisms would be allowed to meet the needs of networks > denied or delayed space under rationing? Would a market be > created/allowed such that networks that really need IP space right > away can purchase it from other networks that can more easily free > up addresses through improved efficiency? Would networks needing > space immediately be encouraged to get ("rent") PA space from a > provider? I don't know about the whole market idea, yet. A market allocates some resources quite effectively (e.g. Oil, Capital, Dry goods), and allocates some things quite badly (e.g. Healthcare, Law Enforcement, Fire Protection, National Security). I haven't quite decided for myself whether IP Addresses are like Oil or are like Healthcare. But I can't deny that a market of a sort exists now, and will probably exist whether or not you try to impose rules on prohibiting that. Quite obviously, people with money who need IP Addresses can buy the ISPs that have already IP Addresses. Like the movie Wall Street, the raider can then turn the just-bought resources to their own more profitable purposes. There is almost no way to stop that; because so far as ARIN is concerned, nothing has changed. The business pages just report ISP X bought ISP Y. Allowing the sale of IP Address blocks on ebay would seem to make little difference. Recently, a person on a mailing list that I read, offered the use of his legacy /24 in exchange for hosting their server. I can't see anything wrong with that. On the other hand, IP Address delegations are basically leases from the government, and the landlords (the government) can specify that the leases either are or aren't transferrable. Usually, one wants some sensible cause for restrictions---e.g. you can't sell the nuclear weapons plant or whatever to just anyone---and so far in the "market" discussion, I haven't seen anyone really show the social harm in allowing blatant IP Address transferral for money. I've only seen hypocritical discussion of what is fair and what limits should be imposed retroactively (and hypocritically) on others. People speak of the probable USG interests; I think the USG will treat the issue of IP Addresses much like it treated frequency spectrum: Up for bid to the highest bidder, possibly subject to FCC regulation where necessary. But I do worry that a market for IP Addresses will eventually result in an Enron-like debacle with traders trying to cause power outages to generate higher prices and more profits. Indeed, the Iraq war seems to have done somewhat the same thing in the Oil industry, but we don't have any tapes (yet) of Dick Cheney or anyone saying the equivalent of 'drop that plant off-line for maintenance during the heat wave' to spike prices like we do for Enron. I've seen a lot (and have also occasionally been victim to) operators and even senior people in the Internet whose morals are about the same or less than those of Enron traders. But of course, the Enron, Worldcom, Adelphia, etc people were eventually found out and went to jail or were fired. If we create a market of IP Addresses, I think an Enron-like debacle is all but certain. So, the question for me is this: Is the benefit of a market worth the trouble? Almost certainly there will be trouble. Almost certainly some people will go to jail on fraud, criminal conspiracy, etc like with Enron etc. But outside the bad events, I think resources might be allocated quite well by a market. But I don't know how damaging the bad events might be. I'd guess they would be somehat similar to, but probably not as bad as, IP Address exhaustion. > * What do you mean by contested IP space? Are you referring to > pre-ARIN allocations and assignments, or something else? No. Just as I explained to Mr. Herrin, "contested" is a broad term to apply to ordinary disputes opened via the ticket system, and also to other disputes that may need to be negotiated or litigated. This is motivated by the Kremen case. It is so that ARIN staff can't ignore court orders, or otherwise pretend that they aren't subject to the jurisdiction of a court or otherwise ignore disputes. I think this issue has to be written into policies in some way. The provision I wrote doesn't change anything else, but just prevents ARIN from considering contested space in its space available. That affects the hard limit function. The provision consequently ensures that should ARIN "lose" the ensuing negotiation or court case, there will be space available. > I'm not sure if a rationing policy would be better than the Soft > Landing proposal, but IMO rationing is an idea worth fleshing out and > considering as an alternative. Thanks. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _______________________________________________ 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 dean at av8.com Tue Aug 21 22:11:52 2007 From: dean at av8.com (Dean Anderson) Date: Tue, 21 Aug 2007 22:11:52 -0400 (EDT) Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: <46CA80D2.8050303@internap.com> Message-ID: On Mon, 20 Aug 2007, Scott Leibrand wrote: > Ok. So to paraphrase, you anticipate that the rationing will lead to > more stringent review of IPv4 applications, and that once the IPv4 > addresses available for a particular period > (month/quarter/year/whatever) are used up, applications will be > waitlisted and filled on a FCFS basis at the start of the next period. > That seams like a reasonably fair way to do things, at least until the > waitlist starts getting long, at which point it might be worthwhile to > start partially filling requests and require applicants to reapply and > get back in line as soon as they use their partial allocation. Yes. I think they can partially fill requests, now. Another side effect of waiting is that people will make smaller requests that could be better documented and filled sooner. > It might be worthwhile exploring such options as part of the policy > process, but I can also see the wisdom in allowing ARIN staff the > leeway to manage the rationing as needed based on changing conditions. > > One thing I think we ought to consider is adjusting the timeframe. > (I'll use your "divide by N" approximation, as it's easier to think > about.) Under your proposal, with N=10, I would anticipate that we > would begin seeing the impact of rationing immediately, and that the > impacts may be large. Another option would be to set N to a lower > value, say 5. Since we're approximately 5 years away from exhaustion > at current projected rates, that may mean we can "ease into" the > rationing regime, which may be advantageous. If we did that, we > wouldn't run out of IPv4 space in 5 years, because each year the > ration decreases exponentially, so that the smaller and smaller free > pool continues to be extended until IPv6 adoption takes off and IPv4 > space starts getting returned faster than it's given out. Actually, we are just over 2.5 years away (March 2010). But 5 years could be a good number, to start. 7 sounds better, to me. > Another consideration is what to do about global coordination. As it > stands today, the large pool of free IPv4 space is managed by IANA, > which gives it out to RIRs as they use it. If ARIN were to adopt a > strict rationing regime, say with N=10, but the other RIRs did not do > so, then ARIN would see most of the remaining free pool used up by > other RIRs, which ARIN became less and less able to fill its members > IPv4 requests. Well, this seems like it could be a problem in the first 3 years (assuming the other RIRs don't follow suit). But after the other RIR's run out of space, ARIN will seem to have been the wise one, and the only one which can still allocate space. > Because of this concern, I think it's important to define how ARIN's > rationing interacts with other RIRs assignment practices. One approach > would be to try for a globally coordinated rationing system. Another > would be to push for IANA to divide the free pool up in advance, and > delay stringent rationing until ARIN has a fixed-size pool to work > with. Do you have any thoughts on how to manage that aspect of things? I think the same way. Ration IANA by the same method. RIRs are just the customers of IANA. I expect the other RIRs will follow suit, for the above reason. > With regards to markets, I agree with you that an unregulated free > market in IPv4 space would be a disaster. I foresee something more > closely managed, where perhaps someone wanting IPv4 space would first > go to ARIN, get their justification approved, and then would have the > option of either getting on the waitlist for available space or buying > space, up to the amount they were able to justify, on a market. ARIN > would then approve the sale, update the registry, and take the > applicant off the waitlist. In any event, I see an IPv4 market as > something that will only be useful once we exhaust the IPv4 free pool, > or start a stringent rationing regime. So we should probably focus on > proposals like Soft Landing and Rationing to deal with the runout > phase, and then start thinking about markets, reclamation, etc. as > soon as we have good runout policies in place. This assumes the market is made of people who have excess space and want to sell it. I think raiding is more likely---Buying up ISPs, and turning their assets to another more profitable purpose. But that is the economic purpose of profits---to put resources to their most profitable use. I don't think it is the raiding, or other genuine trading that is a problem. Its the manipulation of a market that is the problem. ARIN doesn't have the authority or police power to investigate and prosecute market manipulation. I think the choice is live with that disaster or continue as we are. Possibly, an SEC-regulated IP Address trading floor might work. Perhaps trading IP Addresses in the commodities market, maybe... This automatically involves a level of supervision and some protection against market frauds. Involving ARIN in tediously approving each step doesn't prevent market fraud---ARIN will just become the principal deceived, and ARIN has no police power to investigate or prosecute fraud. Some things have to be done by the government, or at least subject to government supervision and criminal penalties. > As for contested space, I agree that we need to put policies in place > that constrain any possible unethical behavior, regardless of whether > we agree or disagree on the ethics of various individuals or their > past actions. I think the public policy process has largely done a > good job creating such policies to date, and have no problem with your > contested space clause in this policy proposal. Thanks for your support. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owen at delong.com Tue Aug 21 23:27:39 2007 From: owen at delong.com (Owen DeLong) Date: Tue, 21 Aug 2007 20:27:39 -0700 Subject: [ppml] Policy Proposal 2007-13: Removal of ISP Immediate Need from End-User Message-ID: <4E02B2B9-FF7F-421B-B67D-67D0E1E088D2@delong.com> Not to distract from the various debates over the legal status of legacy holders, but, I'd like to know if there is any opposition for 2007-13, and, if so, what is it so that we can consider any needed changes prior to the meeting. My expectation is that this policy will require little discussion and be relatively non-controversial, as, it is almost entirely a language clean-up to what essentially amounts to contextual errors in the original policy. If anyone feels differently, please do say something so that the authors can work on resolving any issues prior to the deadline. Thanks, Owen From dean at av8.com Tue Aug 21 23:33:55 2007 From: dean at av8.com (Dean Anderson) Date: Tue, 21 Aug 2007 23:33:55 -0400 (EDT) Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: <997BC128AE961E4A8B880CD7442D9480013AD63F@NJCHLEXCMB01.cable.comcast.com> Message-ID: On Tue, 21 Aug 2007, Alexander, Daniel wrote: > Dean, > > There are several proposals that try to delay the depletion of IPv4 by > restricting or rationing demand. One conern I have is the assumption > that demand is primarily based on waste, hoarding and inefficiencies. > > Rationing of IP space currently exists with the RIR's in the form of the > slow start method of allocation. While it may not be 100% efficient, one > advantage is it rations IP allocations without restricting demand. > > Rationing, by restricting demand, ensures that IP are available for > those who may need them in the future, by denying those who may need > them in the present. Don't you trade one problem for another at that > point. No, time is a friend that goes with us on the journey (:-P) Time does work for us. First, when faced with waiting some months (or whatever timeframe) for a delegation, a company will tend to get more creative with the application. This creates more efficiency all by itself. Second, I that IPv6 will eventually catch on in time, and IPv4 demand will diminish in time. IPv6 will expand over time, and IPv4 will shrink over time. So we just have to keep IPv4 smoothly operating until IPv6 catches on. > My opinion is that policy should never inhibit the genuine growth of > the Internet. If the concern is hoarding, then the focus should be on > reclaiming unused allocations, rather than prohibiting natural growth. The concern isn't merely hoarding. Hoarding is a pernicious consequence of impending exhaustion of any resource. The problem is exhaustion of the resource. > I'll use the company I work for as an example. Not too long ago, we > started offering VoIP services. We planned on a nationwide deployment, > and marketing had ambitious goals for the number of devices deployed the > first year. (as they often do). To deploy the service across our entire > footprint, it was determined we would need X number of IP. (scopes of a > certain size to be deployed on the CMTS and provisioned to the customer > through DHCP) Actually, I don't know why you needed any more IP address space for VOIP to existing cable customers. The customers already have an IP address. Why do they need another one? I've been wondering about that for a while. I used to consult on VOIP engineering for GTE/Genuity/Level3. I'm not an expert in cable systems, tho. It seems to me that cable/residential systems are perfect for IPv6 deployment, since one might want to NAT residential users anyway to keep them from running servers and such. An IPv6 to IPv4 gateway in the headend seems like the perfect idea. And IPv4 (NAT) to IPv6 in the cable modem... I digress... > If a strict approach to rationing is taken, what happens when a > company needs IP for new customers, but is not provided them by the > RIR. Exactly the same thing that will happen in about 2.5 years. There is only one difference: Under my proposal, after some short time, you may still get an allocation. So, just like Paris Hilton, you get out of jail after a short bit. That is in contrast to, say, Bernie Ebbers, where you get 25 years and no early release because you don't like jail anymore. So, whose jail experience do you want to have: Paris Hilton's? Or Bernie Ebbers? You get to choose, but you have to do it now. You can't wait until April, 2010. If you wait that long, you get Bernie Ebber's experience. > That scenario, is no different than if the IANA pool was allowed to > deplete. It won't matter if the possibility exists they could get more > the next time their turn came up. The customer has already gone > elsewhere. Not if they're a cable customer: They're bound by a contract that they can't get out of. Houses will soon come with a builtin cable contract. (:-P) Seriously, they can't go elsewhere: there aren't any new IP addresses for anyone else, either. So unless someone else can figure a way to provide VOIP on that one IP address the existing cable customer already has, they won't be buying VOIP from anyone, and there won't even be any wiggle room for new or more efficient services at all. That's bad. Of course, if there is a way to (for example) provide VOIP with just one IP address, you probably should have figured that out before your competitor, did. > Isn't IPv4 better served by ensuring those who need it get it, and > those that aren't using it give it back, rather than restricting > natural growth? If we weren't going to run out, hard stop, no get out of jail card, in March 2010 (~2.5 years from now), you would have a point. Those who aren't using it now, will definitely be using it after March, 2010. There is nothing to give back. That was always an illusion. What are your plans after March, 2010, if we don't ration? --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From dean at av8.com Tue Aug 21 23:47:29 2007 From: dean at av8.com (Dean Anderson) Date: Tue, 21 Aug 2007 23:47:29 -0400 (EDT) Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: Message-ID: On Tue, 21 Aug 2007, Ted Mittelstaedt wrote: > With IPv4 we don't know how many people are on the waiting list and > how big their allocations are. So in a waitlist situation there is > no disincentive to attempting to get IPv4 Since you don't know what > is going to happen you might as well try waiting. This is a good point. It might be useful to publish the wait queue. Of course, while waiting, you might as well use the time to see if you can do your application without additional IP addresses. Twiddling your thumbs is up to you. Your competitor is probably trying to solve the same problem, though. > The extra waiting just uses up ARIN time and resources. I don't see how waiting takes up ARIN resources unproductively. The _waiting_ doesn't use any ARIN time or resources; ARIN staff don't have to sit on hold with you. > >hard limit in any case. Once the ARIN staff realize they have a hard > >limit, they'll naturally look harder at documentation. This doesn't > >have to be specified. > > > > ARIN already looks hard at documentation, it's kind of insulting to > imply that they don't. Some people think that ARIN staff doesn't have enough time to look as hard as they'd like. > What do you want ARIN staff to do? Now they have time to look as hard as they want. > And in 20 years when IPv4 runout is imminent, people will use your > same logic to justify even sillier restrictions on IPv4 and the > Internet will not yet be switched over. I doubt that. But it isn't up to me to make IPv6 more attractive. But in intervening 20 years, I suspect we'll dredge out Netware, SNA, ISO, or something if we can't get IPv6 going. > Are you the guy that likes the doctor to rip the bandage off real > quick or do you like them to pull it slow as they can? Sounds like > you like your pain stretched out. Most people don't. Try telling that to the heroin addict. Ever wonder where the Hospitals get the heroin to give to addicts? I do. How do you want your Oil supply handled? Do you want to just run out one day? Surprise! All the gas stations are closed. For good. As you see the last guy locking up shop, you say "What the hell!!". And he says: "Well, 6 months ago we asked and no one wanted rationing. They just wanted to get this over and done with." With that, he hops on his camel and rides away. And so you go home and freeze to death in your oil-heated home, in the dark, with no (oil-produced) electricity, and no cable TV, and no Internet. Of course, the American Indians finally get back the Black Hills of South Dakota...Its all good. > Let's get this thing over and done with and go on to the next thing. Ah. Well, running out of IPv4 won't get it 'over and done with'. > Your coming from the approach that it's a Good Thing to stretch out IPv4. > With the implication that there is something wrong with IPv6. > What? Why do we want to delay IPv6 deployment? What are we waiting > for? Once IPv4 runout happens, Windows Vista deployment will be > penetrated enough to make IPv6 switchover easy enough. I've made no such implication. IPv6 isn't waiting for anything from IPv4. IPv4 runout has very little relevance to IPv6. Running out of IPv4 won't make it any easier to go to IPv6. Hitting a hard limit on IPv4 is expected to cause a set of crises that are easily and prudently avoided by rationing. Rationing IPv4 also ramps up the incentive to move to IPv6 smoothly. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owen at delong.com Wed Aug 22 00:31:15 2007 From: owen at delong.com (Owen DeLong) Date: Tue, 21 Aug 2007 21:31:15 -0700 Subject: [ppml] IPv6 incentive policy Message-ID: The recent discussion of IPv4 rationing got me to thinking, and, somehow, this is the conclusion I came to. I will point out that item 9 is probably the most significant information in the template. Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 1. Policy Proposal Name: IPV6 incentive through IPv4 processing delays 2. Author a. name: Owen DeLong b. email: owen at delong.com c. telephone: 408-921-6984 d. organization: DELONG 3. Proposal Version: 1.0 4. Submission Date: August 21, 2007 5. Proposal type: new new, modify, or delete. 6. Policy term: temporary temporary, permanent, or renewable. 7. Policy statement: In order to encourage organizations to use IPv6 rather than IPv4, ARIN will introduce a delay in processing new IPv4 applications which is computed such that D=C/F where D is the number of delays which ARIN will wait to process the IPv4 template, C is the number of IP addresses currently in use by the applicant, and, F is the number of IP addresses currently in the IPv4 free pool (computed as the sum of the IP addresses in the ARIN free pool and the addresses remaining in the IANA free pool). ARIN may completely process the IPv4 template and reserve the addresses, collect fees, etc. immediately upon receiving the template using it's normal process. However, a delay shall be introduced which shall start on the date of the final data submission by the applicant prior to approval, and, which shall extend D days such that the value of D is computed as defined in the preceding paragraph. If the value of D is computed to anything less than one, then, it shall be treated as if the value was 1. IPv6 templates shall be processed immediately without any delay. This policy shall expire when the IPv4 free pool becomes double the size of the IPv4 free pool as of April 1, 2008. 8. Rationale: Apparently, some people feel that running out of free IPv4 addresses will be bad. This proposal provides a self-regulating mechanism for delaying that date by gradually increasing the time it takes to receive a new allocation or assignment from ARIN as the free pool shrinks. The fewer free addresses there are, the longer it will take to receive an assignment or allocation. Further, it has the additional advantage that it will provide faster allocations and assignments to those organizations which have smaller existing IP resource pools from which to draw while extending the delay factor for those few organizations which are already consuming the vast majority of IP address resources. 9. Timetable for implementation: April 1, 2008 10. Meeting presenter: Ruben Garret L. Goldberg END OF TEMPLATE From sleibrand at internap.com Wed Aug 22 00:59:43 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 21 Aug 2007 21:59:43 -0700 Subject: [ppml] Policy Proposal 2007-13: Removal of ISP Immediate Need from End-User In-Reply-To: <4E02B2B9-FF7F-421B-B67D-67D0E1E088D2@delong.com> References: <4E02B2B9-FF7F-421B-B67D-67D0E1E088D2@delong.com> Message-ID: <46CBC2BF.4090006@internap.com> No opposition here... -Scott Owen DeLong wrote: > Not to distract from the various debates over the legal status of legacy > holders, but, I'd like to know if there is any opposition for > 2007-13, and, > if so, what is it so that we can consider any needed changes prior to > the > meeting. > > My expectation is that this policy will require little discussion and be > relatively non-controversial, as, it is almost entirely a language > clean-up > to what essentially amounts to contextual errors in the original policy. > > If anyone feels differently, please do say something so that the authors > can work on resolving any issues prior to the deadline. > > Thanks, > > Owen > > _______________________________________________ > 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 Wed Aug 22 01:08:37 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 21 Aug 2007 22:08:37 -0700 Subject: [ppml] IPv6 incentive policy In-Reply-To: References: Message-ID: <46CBC4D5.10502@internap.com> Are you sure #9 is the most important? I thought it was #10. :-) I'm also interested to know what the units of D are. You said the "number of delays". I think you meant days, but in that case D would always be 1 until C got larger than F. Perhaps you meant for D to be measured in years, such that if F is 100x as big as C, you'd have a delay of .01 years (3.65 days)? -Scott Owen DeLong wrote: > The recent discussion of IPv4 rationing got me to thinking, and, > somehow, > this is the conclusion I came to. I will point out that item 9 is > probably the > most significant information in the template. > > > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 > > 1. Policy Proposal Name: IPV6 incentive through IPv4 processing delays > 2. Author > a. name: Owen DeLong > b. email: owen at delong.com > c. telephone: 408-921-6984 > d. organization: DELONG > 3. Proposal Version: 1.0 > 4. Submission Date: August 21, 2007 > 5. Proposal type: new > new, modify, or delete. > 6. Policy term: temporary > temporary, permanent, or renewable. > 7. Policy statement: > In order to encourage organizations to use IPv6 rather than IPv4, ARIN > will introduce a delay in processing new IPv4 applications which is > computed such that D=C/F where D is the number of delays which > ARIN will wait to process the IPv4 template, C is the number of IP > addresses currently in use by the applicant, and, F is the number of > IP addresses currently in the IPv4 free pool (computed as the sum of > the IP addresses in the ARIN free pool and the addresses remaining > in the IANA free pool). > > ARIN may completely process the IPv4 template and reserve the > addresses, collect fees, etc. immediately upon receiving the template > using it's normal process. However, a delay shall be introduced > which shall start on the date of the final data submission by the > applicant prior to approval, and, which shall extend D days such > that the value of D is computed as defined in the preceding > paragraph. If the value of D is computed to anything less than > one, then, it shall be treated as if the value was 1. > > IPv6 templates shall be processed immediately without any delay. > > This policy shall expire when the IPv4 free pool becomes double > the size of the IPv4 free pool as of April 1, 2008. > > 8. Rationale: > > Apparently, some people feel that running out of free IPv4 addresses > will be bad. This proposal provides a self-regulating mechanism > for delaying that date by gradually increasing the time it takes to > receive a new allocation or assignment from ARIN as the free > pool shrinks. > > The fewer free addresses there are, the longer it will take to > receive an assignment or allocation. Further, it has the additional > advantage that it will provide faster allocations and assignments > to those organizations which have smaller existing IP resource > pools from which to draw while extending the delay factor for > those few organizations which are already consuming the vast > majority of IP address resources. > > 9. Timetable for implementation: April 1, 2008 > 10. Meeting presenter: Ruben Garret L. Goldberg > > END OF TEMPLATE > > _______________________________________________ > 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 mysidia at gmail.com Wed Aug 22 01:28:34 2007 From: mysidia at gmail.com (James Hess) Date: Wed, 22 Aug 2007 00:28:34 -0500 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: <46C9A533.5090808@arin.net> References: <46C9A533.5090808@arin.net> Message-ID: <6eb799ab0708212228g3ac994bbpa28cd652af6052e7@mail.gmail.com> I oppose the proposed policy as stated. > ARIN will ration the remaining available IP Address Space according to a > decreasing exponential function in the family of e^(-x), where the > ultimate function and factors are chosen to ensure that the remaining IP > address space lasts for at least 10 years. The proposed policy provides no specific device by which rationing can be accomplished, no means to reach the end desired in the proposed rationale are precisely given... The proposal doesn't provide for exactly what "rationing is" for purposes of policy I suggest it's similar to just having as a policy "IPV4 assignments will not be allowed to consume all available IP addresses" Another problem is any rationing scheme ARIN attempts to implement beyond justified need seems essentially be indicative of a failure of ARIN to accomplish its mission -- it will mean organizations who have the proper justification and need IP addresses cannot be allocated all the addresses that they need, when they need the hosts to come online. Rationing poses serious problems, depending on how it is implemented, and still doesn't even manage to prevent exhaustion. Either the request will be denied, despite requestor's urgent need, or it will be delayed despite requestor's urgent need, or requestor will receive a smaller than sufficient number of addresses, and be left immediately asking for more. Rationing by ARIN doesn't truly prevent IPV4 exhaustion, because ARIN is not the only RIR, and if ARIN reduces rate of address allocation, the supply of addresses ARIN will need from the IANA pool will be smaller (meaning more of the remaining addresses may get allocated by other RIRs such as APNIC/LACNIC/RIPE/AfriNIC). If there is anything ARIN can ration anything on its own, I believe it's the pool allocated to ARIN, provided rationing starts only _after_ IANA pools are exhausted. Also, the IP address allocations are not discrete assignments of individual addresses that can easily be bound by a function such as Exp[-x]; these addresses have a structure, they are allocated in large blocks, powers of 2 in size, and if massive routing table growth is to be avoided, individual assignments should never be split over multiple repeat assignments over time. I pose that it is not acceptable to hand an organization who needs a /22 a /24 instead, let them request another /24 3 months mater, etc, until they finally get 4 totally discontinuous /24s... Hundreds of thousands of orgs routing 4 /24s instead of 1 /22 a piece would be a serious inefficiency, that rationing without some very well-thought-out guidelines could result in. By 2010, the resulting routing table fragmentation may well be a worse disease than IP exhaustion, if that sort of fragmentation occurs..... -- -J From owen at delong.com Wed Aug 22 01:33:02 2007 From: owen at delong.com (Owen DeLong) Date: Tue, 21 Aug 2007 22:33:02 -0700 Subject: [ppml] IPv6 incentive policy In-Reply-To: <46CBC4D5.10502@internap.com> References: <46CBC4D5.10502@internap.com> Message-ID: <7F9A405A-0EE7-4395-A1CC-41E65A35FFE7@delong.com> On Aug 21, 2007, at 10:08 PM, Scott Leibrand wrote: > Are you sure #9 is the most important? I thought it was #10. :-) > Take your pick. Unfortunatley, I hear that Mr. Goldberg will be unavailable to present at the meeting, due to a most unfortunate lack of pulse, so, I may be forced to present this if the AC moves it forward. > I'm also interested to know what the units of D are. You said the > "number of delays". I think you meant days, but in that case D > would always be 1 until C got larger than F. Perhaps you meant for > D to be measured in years, such that if F is 100x as big as C, > you'd have a delay of .01 years (3.65 days)? > Yes... D is in days. I suppose some scalar could be multiplied by D in order to cause these effects to be more pronounced early on and grow faster. I think that 400 might be a good starting number such that C/F=0.01 would result in 4 days, but, C/F=.5 would produce 20 days. Admittedly, I didn't spend much time thinking about fine-tuning the math prior to posting this. I do, however, think that if we fine tune the scalar value to be applied to D, we will end up with a result which comes fairly close to what Mr. Anderson has proposed in a much less computationally intensive and much more predictable delay-producing policy. So... Assuming we can find a scalar value, would you support or oppose this policy? Modifications included inline below. Thanks for your suggestions. Owen > -Scott > > Owen DeLong wrote: >> The recent discussion of IPv4 rationing got me to thinking, and, >> somehow, >> this is the conclusion I came to. I will point out that item 9 >> is probably the >> most significant information in the template. >> >> >> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 >> >> 1. Policy Proposal Name: IPV6 incentive through IPv4 processing >> delays >> 2. Author >> a. name: Owen DeLong >> b. email: owen at delong.com >> c. telephone: 408-921-6984 >> d. organization: DELONG 3. Proposal Version: 1.1 >> 4. Submission Date: August 21, 2007 >> 5. Proposal type: new >> 6. Policy term: temporary >> 7. Policy statement: >> In order to encourage organizations to use IPv6 rather than IPv4, >> ARIN >> will introduce a delay in processing new IPv4 applications which is computed such that D=X*C/F where D is the number of delays which >> ARIN will wait to process the IPv4 template, C is the number of IP >> addresses currently in use by the applicant, and, F is the number of >> IP addresses currently in the IPv4 free pool (computed as the sum of >> the IP addresses in the ARIN free pool and the addresses remaining in the IANA free pool). X shall be defined as _____. (See rationale section). >> >> ARIN may completely process the IPv4 template and reserve the >> addresses, collect fees, etc. immediately upon receiving the >> template >> using it's normal process. However, a delay shall be introduced >> which shall start on the date of the final data submission by the >> applicant prior to approval, and, which shall extend D days such >> that the value of D is computed as defined in the preceding >> paragraph. If the value of D is computed to anything less than >> one, then, it shall be treated as if the value was 1. >> >> IPv6 templates shall be processed immediately without any delay. >> >> This policy shall expire when the IPv4 free pool becomes double >> the size of the IPv4 free pool as of April 1, 2008. >> >> 8. Rationale: >> >> Apparently, some people feel that running out of free IPv4 addresses >> will be bad. This proposal provides a self-regulating mechanism >> for delaying that date by gradually increasing the time it takes to >> receive a new allocation or assignment from ARIN as the free >> pool shrinks. >> >> The fewer free addresses there are, the longer it will take to >> receive an assignment or allocation. Further, it has the additional >> advantage that it will provide faster allocations and assignments >> to those organizations which have smaller existing IP resource >> pools from which to draw while extending the delay factor for >> those few organizations which are already consuming the vast >> majority of IP address resources. Defining X -- This policy is deliberately incomplete. It is expected that the AC will judge consensus of the community towards a value of X and, at the time of promoting this policy to last call will replace the text "X shall be defined as _____. (See rationale section)." with "X shall be defined as " where is replaced with the actual number judged to be the consensus of the community. The policy author believes that 400 is a good starting value for X. The community is encouraged, when commenting on this proposal to state their desired value for X as part of their comments. Higher values of X will create a steeper ramp and longer initial delays. Lower values of X will create a more dramatic curve that starts to pick up later. >> >> 9. Timetable for implementation: April 1, 2008 >> 10. Meeting presenter: Ruben Garret L. Goldberg >> >> END OF TEMPLATE >> >> _______________________________________________ >> 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 michael.dillon at bt.com Wed Aug 22 03:15:40 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 22 Aug 2007 08:15:40 +0100 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing ofIPv4 IP Addresses In-Reply-To: <997BC128AE961E4A8B880CD7442D9480013AD63F@NJCHLEXCMB01.cable.comcast.com> References: <46C9CEBA.6070404@internap.com> <997BC128AE961E4A8B880CD7442D9480013AD63F@NJCHLEXCMB01.cable.comcast.com> Message-ID: > When ARIN provided the allocation to deploy the service, they > used the slow start mechanisms. Their response was, we know > you are asking for X, but you have no historical data to back > that up. Therefore, we were given a percentage of X. Once > that is used according to the utilization policies, we could > then ask for more. In the end, that allocation only lasted us > a month, given the rate the service took off. We had to > juggle allocations, and renumber IP space to where it was > needed most, to allow the time needed for a history of proven > growth to develop, before ARIN would allocate larger blocks > of IP space. There's another killer application of IPv6. Rolling out a new service without juggling scarce IP addresses, and delaying sales. --Michael Dillon From michael.dillon at bt.com Wed Aug 22 03:22:47 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 22 Aug 2007 08:22:47 +0100 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing ofIPv4 IP Addresses In-Reply-To: <6eb799ab0708212228g3ac994bbpa28cd652af6052e7@mail.gmail.com> References: <46C9A533.5090808@arin.net> <6eb799ab0708212228g3ac994bbpa28cd652af6052e7@mail.gmail.com> Message-ID: > ARIN will ration the remaining available IP Address Space according to > a decreasing exponential function in the family of e^(-x), where the > ultimate function and factors are chosen to ensure that the remaining > IP address space lasts for at least 10 years. I oppose this policy because it is meaningless gibberish, i.e. written in mathematical language. If a policy cannot be written in plain English, then we don't need it. ARIN is not the American Mathematical Society. --Michael Dillon From Keith at jcc.com Wed Aug 22 06:41:08 2007 From: Keith at jcc.com (Keith W. Hare) Date: Wed, 22 Aug 2007 06:41:08 -0400 Subject: [ppml] Policy Proposal 2007-13: Removal of ISP Immediate Need fromEnd-User Message-ID: Policy Proposal 2007-13 looks ok to me. Keith ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Tuesday, August 21, 2007 11:28 PM To: Public Policy Mailing List Subject: [ppml] Policy Proposal 2007-13: Removal of ISP Immediate Need fromEnd-User Not to distract from the various debates over the legal status of legacy holders, but, I'd like to know if there is any opposition for 2007-13, and, if so, what is it so that we can consider any needed changes prior to the meeting. My expectation is that this policy will require little discussion and be relatively non-controversial, as, it is almost entirely a language clean-up to what essentially amounts to contextual errors in the original policy. If anyone feels differently, please do say something so that the authors can work on resolving any issues prior to the deadline. Thanks, Owen _______________________________________________ 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 dean at av8.com Wed Aug 22 11:10:28 2007 From: dean at av8.com (Dean Anderson) Date: Wed, 22 Aug 2007 11:10:28 -0400 (EDT) Subject: [ppml] Policy Proposal 2007-13: Removal of ISP Immediate Need from End-User In-Reply-To: <4E02B2B9-FF7F-421B-B67D-67D0E1E088D2@delong.com> Message-ID: This also removes micro allocations from end users, which doesn't seem to be the intent. I agree that we should delete the phrase "immediate need [4.2.1.6] or" from section 4.3.4 so that it reads "End-users may qualify for address space under other policies such as Micro-allocation[4.4]" --Dean On Tue, 21 Aug 2007, Owen DeLong wrote: > Not to distract from the various debates over the legal status of legacy > holders, but, I'd like to know if there is any opposition for > 2007-13, and, > if so, what is it so that we can consider any needed changes prior to > the > meeting. > > My expectation is that this policy will require little discussion and be > relatively non-controversial, as, it is almost entirely a language > clean-up > to what essentially amounts to contextual errors in the original policy. > > If anyone feels differently, please do say something so that the authors > can work on resolving any issues prior to the deadline. > > Thanks, > > Owen > > _______________________________________________ > 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. > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owen at delong.com Wed Aug 22 11:30:40 2007 From: owen at delong.com (Owen DeLong) Date: Wed, 22 Aug 2007 08:30:40 -0700 Subject: [ppml] Policy Proposal 2007-13: Removal of ISP Immediate Need from End-User In-Reply-To: References: Message-ID: <3DE062B7-3732-45BB-B1C0-6EC7000EE5DA@delong.com> The proposal has no such effect. By deleting section 4.3.4, it does not prevent section 4.4 from being applied to end-users. Nothing in section 4.4 limits its application to ISPs. The verbiage in section 4.2.1.6 is irrational in the case of immediate need and redundant as to the rest. As such, I believe the policy accomplishes exactly what it intends. Owen On Aug 22, 2007, at 8:10 AM, Dean Anderson wrote: > This also removes micro allocations from end users, which doesn't seem > to be the intent. > > I agree that we should delete the phrase "immediate need [4.2.1.6] or" > from section 4.3.4 so that it reads > > "End-users may qualify for address space under other policies such as > Micro-allocation[4.4]" > > --Dean > > On Tue, 21 Aug 2007, Owen DeLong wrote: > >> Not to distract from the various debates over the legal status of >> legacy >> holders, but, I'd like to know if there is any opposition for >> 2007-13, and, >> if so, what is it so that we can consider any needed changes prior to >> the >> meeting. >> >> My expectation is that this policy will require little discussion >> and be >> relatively non-controversial, as, it is almost entirely a language >> clean-up >> to what essentially amounts to contextual errors in the original >> policy. >> >> If anyone feels differently, please do say something so that the >> authors >> can work on resolving any issues prior to the deadline. >> >> Thanks, >> >> Owen >> >> _______________________________________________ >> 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. >> >> > > -- > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 > From info at arin.net Wed Aug 22 13:25:59 2007 From: info at arin.net (Member Services) Date: Wed, 22 Aug 2007 13:25:59 -0400 Subject: [ppml] NRPM version 2007.2 - New Policy Implementation Message-ID: <46CC71A7.1090007@arin.net> On 14 June 2007, the ARIN Board of Trustees, based on the recommendations of the Advisory Council and noting that the Internet Resource Policy Evaluation Process had been followed, adopted the following policy proposal: 2007-11: Refinement of ISP Initial Allocation Policy 2007-9: Modernization of ISP Immediate Need Policy 2007-8: Transfer Policy Clarifications 2007-7: Creation of Policy for Subsequent End-User IP Requests/Assignments 2007-4: Changes to IPv6 policy - removal of "interim" consideration These policy proposals, as well as 2005-3: Lame Delegations, have been incorporated into version 2007.2 of the ARIN Number Resource Policy Manual (NRPM) which is effective 22 August 2007. NRPM version 2007.2 supersedes previous versions. See Appendix A of the NRPM for information regarding changes to the manual. The guidelines for lame delegations have been updated and can be found at: http://www.arin.net/reference/lame_delegations.html The NRPM can be found at: http://www.arin.net/policy/nrpm.html Appendix A can be found at: http://www.arin.net/policy/nrpm_changelog.html Regards, Member Services American Registry for Internet Numbers (ARIN) From dean at av8.com Wed Aug 22 15:23:14 2007 From: dean at av8.com (Dean Anderson) Date: Wed, 22 Aug 2007 15:23:14 -0400 (EDT) Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing ofIPv4 IP Addresses In-Reply-To: Message-ID: So, now ARIN can't do math? Actually, as a management body for a field of engineering and applied mathematics, greatly concerned with numbers, ARIN is indeed a sort of mathematical society. How do you competently and credibly claim to be able to do network engineering without mathematical formulas? I'd suppose you were joking, but indeed there are those who subscribe to Faith-based network engineering, and prefer Intelligent Design over Evolution. --Dean On Wed, 22 Aug 2007 michael.dillon at bt.com wrote: > > ARIN will ration the remaining available IP Address Space according to > > > a decreasing exponential function in the family of e^(-x), where the > > ultimate function and factors are chosen to ensure that the remaining > > IP address space lasts for at least 10 years. > > I oppose this policy because it is meaningless gibberish, i.e. written > in mathematical language. If a policy cannot be written in plain > English, then we don't need it. ARIN is not the American Mathematical > Society. > > --Michael Dillon > _______________________________________________ > 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. > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owen at delong.com Wed Aug 22 16:11:48 2007 From: owen at delong.com (Owen DeLong) Date: Wed, 22 Aug 2007 13:11:48 -0700 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: References: Message-ID: <6E2D60D5-4EB2-457E-AB5E-5C9915A55AB5@delong.com> On Aug 22, 2007, at 12:51 PM, Dean Anderson wrote: > On Tue, 21 Aug 2007, Owen DeLong wrote: > >> Despite my assurances that I expected ARIN staff to fully evaluate >> my request as thoroughly as policy required and the same as >> would be done with any other request, I received approval within >> a few hours. > > A few hours seems pretty short. > Not necessarily. There's really a point of diminishing returns on these things. Either the documentation is in order and the request complies with policy or it doesn't in most cases. Sure, there are always gray areas, but, staring at a gray blob for a long time does not make it darker or lighter, it just causes empty field myopia. >> I do not believe that ARIN felt in any way rushed to approve my >> application, and, I do not believe that they left out any steps in >> the >> process. I believe that my submission of complete, timely, and >> accurate documentation of a request which conformed to ARIN policies >> made it easy for them to thoroughly review my request and issue the >> assignment in a timely manner. > > Perhaps. Or perhaps they just feel confident they don't have to look > closely at your requests. Or, perhaps if they had spent more time on > your request, they'd have found something wrong with it. > I do not think that ARIN feels any greater or lesser need to evaluate my applications than anyone else's. I believe they work very hard to be as fair and equitable as possible. >>>> What do you want ARIN staff to do? >>> >>> Now they have time to look as hard as they want. >>> >> I am quite convinced that this is already the case. > > I'm not. > What, exactly, is it that you think prevents them from looking at an application as long as they want? I have had applications take anywhere from same day (this most recent one) to several months. At no time have I seen any indication that ARIN bows to any form of time pressure to approve a request, although, once a request is approved, I have seen them bend over backwards to accommodate urgent needs to complete the rest of the process. In fact, I believe that the approval process at ARIN takes pretty much as long as it takes no matter what you do. The only way to get your approval faster is to submit a well documented request that conforms to the policies and guidelines under which ARIN operates. >>>> Are you the guy that likes the doctor to rip the bandage off real >>>> quick or do you like them to pull it slow as they can? Sounds like >>>> you like your pain stretched out. Most people don't. >>> >>> Try telling that to the heroin addict. Ever wonder where the >>> Hospitals get the heroin to give to addicts? I do. >>> >> Hospitals do not give heroin to addicts. At least not in the US. In >> some cases, they give methadone, but, methadone is not the same as >> heroine. > > Ah. Thanks. > >>> How do you want your Oil supply handled? Do you want to just run >>> out one day? Surprise! All the gas stations are closed. For good. >>> As you see the last guy locking up shop, you say "What the hell!!". >>> >> I think that is the most likely scenario, but, there is a difference. >> >> Oil is a consumable. > > Its a limited resource that will run out someday. > >> When you run out of oil, your car stops functioning. The internet >> does >> not stop functioning when we run out of available IP addresses. >> Parts of the internet stop growing when we run out of available IP >> addresses. > > "New business" stops functioning. > No. New business never started functioning and continues to not start functioning, at least not on IPv4 the way that old businesses have functioned and continue to function. > When we run out of oil, civilization won't end; The human race > won't be > extinguished. But it might still be bad for society if done suddenly. > >> Please enumerate these crises and explain how that is true. > > I think that has been done. The guy from comcast gave an example > yesterday. > >> 1. I do not believe IPv4 free pool exhaustion creates any crisis. > > Well, then, if there aren't going to be any crises when we run out, > there certainly won't be any crises from rationing. > Crises, no. Hardships, yes. However, rationing does not eliminate these hardships or reduce them in any way. In fact, all rationing actually does in this case is guarantee that the hardships happen sooner and last longer. OTOH, without rationing, things continue as they are without any artificial hardships. Then, one day, we can't issue new addresses to newcomers. To me, this has little difference in effect from when you go to a store and they are sold out of a discontinued item. It's not a hardship. It's not a crisis. It's just the way things go. Sure, the person who wanted to buy said item is SOL, but, c'est la vie. I sort of ran into this just last night. A local office products store was selling 32" LCD Televisions for $399. Unfortunately, the only one they had left was the floor model which had some cosmetic damage to the case, but, was in perfect working order. They gave me 10% off of the price, and, I became the last person to get that deal on one of those TVs in my area. (They're still selling them on line for $699). The next person who wants one will not get one. Such is life. I couldn't get a new one in a box like I wanted. Such is life. So it will be with IPv4 addresses after the free pool runs out. Owen From bicknell at ufp.org Wed Aug 22 16:20:25 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 22 Aug 2007 16:20:25 -0400 Subject: [ppml] Policy Proposal: Definition of known ISP and changes to IPv6 initial allocation criteria In-Reply-To: <46AE170F.6010901@arin.net> References: <46AE170F.6010901@arin.net> Message-ID: <20070822202025.GB18561@ussenterprise.ufp.org> In a message written on Mon, Jul 30, 2007 at 12:51:27PM -0400, Member Services wrote: > Replace 6.5.1.1 (d) with the following text: > > d. be an existing ISP in the ARIN region or have a plan for > making assignments to at least 200 separate organizations > within five years. In my IPv6 Policy Housekeeping proposal, recently sent to PPML I proposed similar language, which was discovered today during AC review of the various proposals. Here's the language from the other proposal: ] Change I: ] ] In section 6.5.1.1.d, replace the existing statement with the new ] statement: ] ] "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." Were both proposals to pass, are these substantially similar enough that the AC could use either one to serve the purpose? -- 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 Wed Aug 22 16:40:42 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 22 Aug 2007 21:40:42 +0100 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing ofIPv4 IP Addresses In-Reply-To: References: Message-ID: > So, now ARIN can't do math? Sorry but no. ARIN is a corporation and last time I looked, corporations can't do math. Only people with an education in mathematics can do math. And since this is the ARIN *PUBLIC* policy mailing list, where a mathematics education is *NOT* a prerequisite, math is rather out of place. > How do you competently and credibly claim to be able to do > network engineering without mathematical formulas? I never claimed that. And I haven't any idea what network engineering has to do with ARIN or its policies. The ARIN policy book is intended to guide ARIN staff on dealing with number resource management, which is a fancy term for keeping track of lists of unique numbers. In general, policies of any sort, from federal laws down to the rules of the local poodle owners club, are best expressed in plain English. A while back, I proposed an ARIN policy that involved logarithms. If you want to look at how I did this, it is in ARIN's archive here http://www.arin.net/policy/proposals/2004_2.html Note that I didn't talk about "factors" but I did quote actual numbers. I never said / but I did say "divided by". And down at the bottom of that page is a link to another page with a table showing the actual numbers resulting from some sample calculations, a spreadsheet you could play with to examine the results of fiddling with the numbers, and a slide presentation with charts to display graphically just what it means to divide two logarithms. I didn't talk about picking a function from the family of e^(-x). In fact, I'm not really sure what that means altough I suspect that my old proposal may actually be a function in that family, or at least a cousin, if nothing else. > I'd > suppose you were joking, but indeed there are those who > subscribe to Faith-based network engineering, and prefer > Intelligent Design over Evolution. Actually, I prefer evolution of ARIN policy which is why I generally oppose all these intelligent designs to make the IPv4 endgame somehow better. And don't knock faith-based network engineering. If you understood the statistics you would realize that overprovisioning a network and praying is likely to produce a better quality network than piling heaps of intelligent design work and close monitoring systems and layer-2 switching into the mix. But that's not any business of ARIN policymakers, is it? --Michael Dillon From info at arin.net Wed Aug 22 16:53:40 2007 From: info at arin.net (Member Services) Date: Wed, 22 Aug 2007 16:53:40 -0400 Subject: [ppml] AC shepherds Message-ID: <46CCA254.4080900@arin.net> The ARIN Advisory Council (AC) assigned shepherds for the policy proposals received over the last several days as follows: The shepherds from the AC for "Expand timeframe of Additional Requests" are Marla Azinger and Matt Pounsett. The shepherds from the AC for "End Policy for IANA IPv4 allocations to RIRs" are Dan Alexander and Robert Seastrom. The shepherds from the AC for "IPv6 Assignment Guidelines" are Ron da Silva and Stacy Taylor. The shepherds from the AC for "ISP to LIR Clarification" are Heather Schiller and Paul Andersen. The shepherds from the AC for "IPv6 Policy Housekeeping" are Lea Roberts and Stacy Taylor. The shepherds from the AC for "Decreasing Exponential Rationing of IPv4 IP Addresses" are Dan Alexander and Cathy Aronson. Regards, Member Services American Registry for Internet Numbers (ARIN) From dlw+arin at tellme.com Wed Aug 22 16:57:32 2007 From: dlw+arin at tellme.com (David Williamson) Date: Wed, 22 Aug 2007 13:57:32 -0700 Subject: [ppml] Policy Proposal: Definition of known ISP and changes to IPv6 initial allocation criteria In-Reply-To: <20070822202025.GB18561@ussenterprise.ufp.org> References: <46AE170F.6010901@arin.net> <20070822202025.GB18561@ussenterprise.ufp.org> Message-ID: <20070822205732.GL28312@shell01.cell.sv2.tellme.com> On Wed, Aug 22, 2007 at 04:20:25PM -0400, Leo Bicknell wrote: > Were both proposals to pass, are these substantially similar enough > that the AC could use either one to serve the purpose? The only word that might present a problem is "known", and I think that's perhaps an unnecessary addition. I think the AC can handle this. -David From marla.azinger at frontiercorp.com Wed Aug 22 16:59:59 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Wed, 22 Aug 2007 16:59:59 -0400 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IPAddresses Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4C89A@nyrofcs2ke2k01.corp.pvt> Here are my two cents on this one. -I don't Support this -I don't support rationing of addresses. I support figuring out how to manage addresses once ARIN starts getting requests they cant fulfill with contiguous address space. -All RIR's would need to do this at the same time, or else ARIN will be at a disadvantage and not be able to request more space from IANA while other RIR's can. -This is similar to IPv4 Soft Landing proposal. They should be combined. Cheers! Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Member Services Sent: Monday, August 20, 2007 7:29 AM To: ppml at arin.net Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IPAddresses 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: Decreasing Exponential Rationing of IPv4 IP Addresses Author: Dean Anderson Proposal Version: 1 Submission Date: 8/18/07 Proposal type: new Policy term: renewable Policy statement: ARIN will ration the remaining available IP Address Space according to a decreasing exponential function in the family of e^(-x), where the ultimate function and factors are chosen to ensure that the remaining IP address space lasts for at least 10 years. This function will be used to limit the IP Address space allocations. If IP Address Space becomes available (e.g. via return), the ration can be recalculated. However, Ration calculations will not be based on projected or anticipated returns. Contested IP Address Space will also be excluded from the amount of available Address Space for ration calculations. Rationale: Two reports[1,2] project that IP Addresses will be exhausted around March 2010. * Both reports agree that if IP Addresses continue to delegated at the present rates, we will run out of space in March 2010. * Everyone seems to agree that depletion will be a very bad event. * It is therefore imperative to begin rationing to slow down the rate of new delegations to conserve the available address space. * It is necessary to do this now. One can't start rationing after the resources run out. Sudden IPv4 IP Address Exhaustion is expected to cause sudden disruption and discontinuity in business operations and planning. As with other limited resources, the mere anticipation of exhaustion will lead to hoarding and other behaviors that increase the harm of a sudden exhaustion. Rationing on a decreasing exponential will essentially prevent total exhaustion and will gradually decrease the rate of IP Address delegation so to alleviate the harms of a sudden stop in IP Address delegation. Prevention of IPv4 IP Address Exhaustion will help ensure a smooth transition to IPV6. Rationing helps ensures that IP Address space remains available to future needs. [1] http://www.potaroo.net/tools/ipv4/index.html [2] http://www.tndh.net/~tony/ietf/ipv4-pool-combined-view.pdf 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 marla.azinger at frontiercorp.com Wed Aug 22 17:04:56 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Wed, 22 Aug 2007 17:04:56 -0400 Subject: [ppml] Policy Proposal: IPv6 Policy Housekeeping Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272F9DD@nyrofcs2ke2k01.corp.pvt> Here are my two cents on this one: - I cant support this until the things that are to be taken out have a place to go like the creation of NPOG (Number Policy Operational Guidelines). -Change I. Make this a separate proposal due to it removing a /48 as a specification. In fact take it out of this proposal and let the other proposal(Definition of known ISP and changes to IPv6 initial allocation criteria) that was submitted address this issue. -Change H. I don't support removing this. I suggest relocating it to 6.5.1.2 because the wording is more clarifying in an example manner than what is currently written in 6.5.1.2 already. Cheers! Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Member Services Sent: Friday, August 17, 2007 11:23 AM To: ppml at arin.net Subject: [ppml] Policy Proposal: IPv6 Policy Housekeeping 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 Policy Housekeeping Author: Leo Bicknell Proposal Version: 1.0 Submission Date: 8/17/2007 Proposal type: modify Policy term: permanent Policy statement: Change A: Remove the text between the section 6 header and the section 6.1 header. Remove section 6.1 entirely. Update all subsequent sections to have new section numbers (6.[n-1]). Change B: Move the image in section 6.2 to section 2. Remove sections 6.2.1 to 6.2.6. Change C: Move section 6.2.7 to (new) section 2.8, subheading "IPv6". Create section 2.8, subheading "IPv4", containing the following text: In IPv4, utilization is the percentage of the address space allocated or assigned relative to the total address space. Change D: Move section 6.2.8 to (new) section 2.8. Move section 6.2.9 to (new) section 2.9. As this leaves section 6.2 empty, remove section 6.2. Update all subsequent sections to have new section numbers (6.[n-1]). Change E: Remove section 6.3. Update all subsequent sections to have new section numbers (6.[n-1]). Change F: Remove section 6.4.1. Update all subsequent sections to have new section numbers (6.4.[n-1]). Change G: Remove section 6.4.2. Update all subsequent sections to have new section numbers (6.4.[n-1]). Change H: Remove section 6.4.4. Change I: In section 6.5.1.1.d, replace the existing statement with the new statement: "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." Change J: Remove section 6.5.3 entirely. Update all subsequent sections to have new section numbers (6.5.[n-1]). Replace part of the text as (new) section 6.5.4.4: "All /56 and larger assignments to end sites are required to be registered either by the LIR or its subordinate ISPs in such a way that the RIR/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary." Change K: Section 6.5.8.2, add the following sentence to the end of the first paragraph: "An HD-Ratio of .94 must be met for all assignments larger than a /48." Add to the end of the second paragraph: "This reservation may be assigned to other organizations later, at ARIN's discretion." Change L: Section 6.5.8.3, add a sentence between the two existing sentences: "Justification will be determined based on the .94 HD-Ratio metric." Change M: Remove section 6.6. Update all subsequent sections to have new section numbers (6.[n-1]). Change N: Change the title of section 6.7 from "Appendix A: HD-Ratio" to "HD-Ratio". Change O: Remove section 6.8. Update all subsequent sections to have new section numbers (6.[n-1]). Rationale: When the IPv6 policy was passed, it was considered to be an "interim" policy, and it was intended to be similar in all 5 RIR's. Since that time it has become clear the policy is no longer interim (and proposal 2007-4 was passed to change just that) and it has also been modified separately in the different RIR's. It was brought to the ARIN AC's attention that there were a number of problems with "Section 6" of the NRPM as a result of this legacy: * The policy contained a large number of items that were not policy. * The policy contained a few items that were self contradictory. * The added text was redundant in some cases with existing text. * The policy was overly vague in a few areas, leaving ARIN staff to have to make interpretations of what the policy intended. * Policy changes made since the initial IPv6 policy was adopted have not always updated all of the relevant sections due to the complexity of section 6. The intent of these changes is not to change any existing policy, but rather to remove all non-policy items, and update any ambiguous items with the way that ARIN staff is currently interprets the policy. Change A: Not policy. Unnecessary. Confusing (policy is interim). Change B: Sections 6.2.1 to 6.2.6 are definitions that are already defined in section 2.1 to 2.7 Repeating them here is unnecessary. The picture is useful though, and should be moved to section 2 as part of the definitions. Change C: This is a definition item, and should be in the definition section. Also, the v4 versions should be defined at the same time. Change D: These are both definitions that should be in the definitions section. Change E: This is a manifesto, and is not address policy. If anything these belong is ARIN's mission statement. Change F: Not policy; covered by the RSA as a legal matter. Change G: Not policy. A darn good warning though ARIN should include with any other boilerplate when issuing address space. Change H: Not policy, and covered by actual policy statement 6.5.1.2. Change I: Proposal 2005-8 amended section 6.5.4.1 to allow /56 and /64 allocations, but section 6.5.1.1.d was never updated to match the change. It is believed the intent of the policy, and ARIN staff's current interpretation of the policy match the updated text. Change J: The first part is not policy, and incorrectly states there is no policy as section 6.5.4 has the policy in it. Take the one useful part and make it part of the 6.5.4 criteria. Change K: No metric is currently listed to justify a larger initial assignment. It is believed ARIN staff is currently applying the HD-Ratio similar to the ISP policy, this puts that in writing. Make it clear that the reservation may not exist in perpetuity. Change L: No metric is given to justify additional assignments. It is believed that ARIN staff is currently applying the HD_Ratio similar to the ISP policy, this puts that in writing. Change M: References, while useful on the web page and in template instructions are not policy. Change N: It's not an appendix. It's not even at the end. Change O: The background information would be something nice to archive on the ARIN web site somewhere, but is not policy and should be removed from the policy manual. 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 marla.azinger at frontiercorp.com Wed Aug 22 17:06:26 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Wed, 22 Aug 2007 17:06:26 -0400 Subject: [ppml] Policy Proposal: ISP to LIR Clarification Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4C89C@nyrofcs2ke2k01.corp.pvt> Here are my two cents on this one: -I support this one. -However before it goes forward it needs edit done to add one more change. 4.2.1.1 needs ISP changed to LIR. Cheers! Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Member Services Sent: Friday, August 17, 2007 11:22 AM To: ppml at arin.net Subject: [ppml] Policy Proposal: ISP to LIR Clarification 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: ISP to LIR Clarification Author: Leo Bicknell Proposal Version: 1.0 Submission Date: 8/17/2007 Proposal type: modify Policy term: permanent Policy statement: Replace all instances of the word "ISP" in the NRPM with the word "LIR" and replace all instances of the phrase "LIR/ISP" with "LIR", except for the following: * Leave section 2.4 unchanged. * Leave section 2.7 unchanged. * In section 4.1.1, replace "ISPs" with "requesters". * In section 4.2, also remove "Internet Service Providers". * Leave section 6.2.4 unchanged. * Leave section 6.3.4 unchanged. * In section 6.9, replace "ISPs and LIRs" with "LIRs" for all three occurrence. Rationale: The NRPM is inconsistent. The terms ISP and LIR are used interchangeably throughout the document, with the term ISP being predominant in the IPv4 sections and the term LIR being predominant in the IPv6 sections. The use of the term ISP poses two different problems: 1) The term has meaning outside of ARIN's policy. Multiple discussions on PPML have degenerated over people arguing what an ISP is with regards to policy when the reality is that the relationship is defined in the NRPM. As LIR has no meaning outside of policy this confusion will be removed. 2) The other four RIRs have standardized on LIR. This change will make it easier for those doing business with more than one LIR to use consistent terms. This change does not alter any policy, it merely makes the policy easier to understand. 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 marla.azinger at frontiercorp.com Wed Aug 22 17:08:55 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Wed, 22 Aug 2007 17:08:55 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4C89D@nyrofcs2ke2k01.corp.pvt> Here are my two cents on this one: -I support this as is. But if changes are being made based on the massive discussions and side tangents...I would need to se a brand new revision. -As written I view it as just giving a more detailed "how to" re-assign and has no bearing on routing. Cheers! Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Member Services Sent: Friday, August 17, 2007 11:22 AM To: ppml at arin.net Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines 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 Guidelines Author: Leo Bicknell Proposal Version: 1.0 Submission Date: 8/17/2007 Proposal type: new Policy term: permanent Policy statement: Replace the text in section 6.5.4.1 with the following text: LIR's may assign blocks in the range of /48 to /64 to end sites. All assignments made by LIR's should meet a minimum HD-Ratio of .25. * /64 - Site needing only a single subnet. * /60 - Site with 2-3 subnets initially. * /56 - Site with 4-7 subnets initially. * /52 - Site with 8-15 subnets initially. * /48 - Site with 16+ subnets initially. 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. LIR's do not need to issue all 5 sizes of prefixes as long as the HD-Ratio requirement is met. Rationale: The existing section 6.5.4.1 does not provide clear guidance on how large of a prefix to allocate to a site. This makes it difficult for LIR's to know they are in compliance with the rules, and makes it harder for ARIN staff to evaluate requests per the communities wishes. This policy is based on an HD Ratio of .25 for end sites. The following table may be useful: Prefix Size Number of Subnets Required in Use to Meet .25 ----------- ----------------- --------------------------- /64 1 1 /60 16 2 /56 256 4 /52 4096 8 /48 65536 16 It is believed this policy provides clear guidance while allowing LIR's to make generous allocations to their end-sites. Timetable for implementation: immediate for new requests, 2 year grace period for all existing assignments. _______________________________________________ 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 marla.azinger at frontiercorp.com Wed Aug 22 17:10:21 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Wed, 22 Aug 2007 17:10:21 -0400 Subject: [ppml] Policy Proposal: End Policy for IANA IPv4 allocations to RIRs Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4C89E@nyrofcs2ke2k01.corp.pvt> Here are my two cents: -I don't support this. Let it run out. Write a policy figuring out what IANA does once contiguous requests cant be met. -Section 2 needs to be removed. It isn't policy and more a suggestion/guidance of things that RIR's should think about doing. -Section 3 needs to be removed. It isn't policy and more a staff requirement for RIR's. Cheers! Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Member Services Sent: Friday, August 17, 2007 8:20 AM To: ppml at arin.net Subject: [ppml] Policy Proposal: End Policy for IANA IPv4 allocations to RIRs 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: End Policy for IANA IPv4 allocations to RIRs Author: JPNIC IPv4 countdown policy team; Akinori MAEMURA Akira NAKAGAWA Izumi OKUTANI Kosuke ITO Kuniaki KONDO Shuji NAKAMURA Susumu SATO Takashi ARANO Tomohiro FUJISAKI Tomoya YOSHIDA Toshiyuki HOSAKA Proposal Version: 2 Submission Date: 2007/08/17 Proposal type: new Policy term:renewable Policy statement: 1) Distribute a single /8 to each RIR at the point when new IANA free pool hits 5 */8. This date is defined as "IANA Exhaustion Date". 2) It should be completely left up to each RIR communities to define a regional policy on how to distribute the remaining RIR free pool to LIRs within their respective regions after "IANA Exhaustion Date". Note 1: It is fine for an RIR to continue operations with the existing policy if that is the consensus decision of the respective RIR community. Note 2: Address recovery and re-distribution of recovered address space is another important measure for considerations, but should be treated as a separate policy proposal from distribution of new IANA pool. 3) RIRs should provide an official projection on IANA Exhaustion Date to the community through their website, at their Policy Meetings and through any other effective means. Rationale: [current problem] There are two major issues in terms of address management if no measures are taken for IPv4 address exhaustion. 1) Continue applying a global coordinated policy for distribution of the last piece(s) of RIR's unallocated address block does not match the reality of the situation in each RIR region. Issues each RIR region will face during the exhaustion period vary by region as the level of development of IPv4 and IPv6 are widely different. As a result, applying a global co-ordinated policy may not adequately address issues in a certain region while it could be work for the others. For example, in a region where late comers desperately need even small blocks of IPv4 addresses to access to the IPv4 Internet, a policy that defines the target of allocations/assignments of IPv4 address space to be late comers would be appropriate in such region. This would allow availablilty of IPv4 address space for such requirements for more years. Another example comes from difference in IPv6 deployment rate. For a region where IPv6 deployment rate is low, measures may be necessary to prolong IPv4 address life for the existing business as well as for new businesses until networks are IPv6 ready. Some regions may have strong needs to secure IPv4 address space for translators. A globally coordinated policy which addresses all the issues listed above to meet the needs for all RIR regions may result in not solving issues in any of the regions. 2) LIRs and stakeholders remain unprepared for the situation if they are not informed If LIRs and the community are uninformed of the exhaustion, their services and networks remain unprepared to face the situation at the time of exhaustion. [Objective of the proposal] This proposal seeks to provide the following solutions to the problems listed above. 1) RIR community should be able to define their own regional policies on how to assign the last piece(s) of allocation block in order to address their own regional issues during the exhaustion period. 2) RIRs should provide official projection of the date when LIRs will be able to receive the allocations under the current criteria. The criteria should remain consistent until this date in order to avoid confusion. [Pros and Cons] Pros: + It allows each RIR community to define a policy on how to distribute the last piece(s) of allocations which best matches their situation. + It helps LIR better informed of the date when they are able to receive allocations from RIRs under the current criteria and prepare for the event. Cons: + Concerns could be raised about allocating a fixed size to all RIRs, that it artificially fastens the consumption rate of some RIR regions. However, its impact is kept to minimum by keeping the allocation size to a single /8 which makes merely 3-4 months difference. + Concerns could be raised that explicitly allowing regional policies will encourage RIR shopping. However, this should not happen if the requirements within each region is adequately reflected in each RIR's policy through PDP. RIR may also chose to add criteria to prevent LIRs from other regions submitting such requests. Timetable for implementation: Immediate after all 5 RIRs (and possibly ICANN) ratifies the 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. From marla.azinger at frontiercorp.com Wed Aug 22 17:12:02 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Wed, 22 Aug 2007 17:12:02 -0400 Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4C89F@nyrofcs2ke2k01.corp.pvt> Here are my two cents: -I don't support this. -Let it run out. Write a policy figuring out what ARIN does once contiguous requests cant be met. -If we do this and other RIR's don't we are just holding ourselves back from more allocations from IANA while others continue to receive more. -This is similar to another proposal. We should combine Decreasing Exponential Rationing of IPv4 IP Addresses with this one if we want to look at an approach like this. Cheers! Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Member Services Sent: Tuesday, August 14, 2007 3:01 PM To: ppml at arin.net Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) This proposal is in the Initial Review stage of the ARIN Internet Resource Policy Evaluation Process. On 17 May 2007 the ARIN Advisory Council (AC) reviewed 'IPv4 Soft Landing (version 1.0)' and decided to postpone their decision regarding the proposal in order to work with the author. The author submitted the following revised version of the 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 shepherd for this proposal is Bill Darte. 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: IPv4 Soft Landing Author: David Conrad Proposal Version: 2.0 Submission Date: 2007-08-14 Proposal type: New Policy term: Permanent Policy statement: This policy is intended to replace section 4.2.4.1 of the ARIN Number Resource Policy Manual with wording substantially along the lines of: --- begin modification --- 4.2.4.1 In order to encourage a smooth transition to IPv6, ARIN has instituted a set of IPv4 Address Allocation "phases" that vary the requirements for address allocation using the amount of address space remaining unallocated by IANA as a metric. As the amount of address space in the IANA free pool is reduced, the requirements for IPv4 address allocation are made more stringent. When requesting additional IPv4 address space, ISPs must meet the requirements of the IPv4 Address Allocation phase ARIN was in when the request was submitted. These phases will require the requester to demonstrate increasingly efficient utilization of previously allocated IPv4 address space, including all space reassigned to their customers. In addition, depending on the IPv4 Address Allocation phase ARIN was in when the request was submitted, there may be additional requirements that will need to be met by the requester such as completing a survey on IPv6 deployment plans, documentation of non-private address space used for internal infrastructure, documentation of IPv6 plans for offering connectivity and services, etc. The reassignment information section of the ARIN ISP Network Request Template should be completed for all address blocks that have been allocated to your organization. In the template, line 1b. Assigned: information will be verified via SWIP/RWHOIS and 1c. Reserved: should be used to indicate internal network information. Please note that until all requirements are met and your prior utilization is verified to meet the requirements specified in the IPv4 Address Allocation phase in which the request was received, ARIN can neither process nor approve a request for additional addresses. IPv4 Allocation Phases The thresholds and the requirements to justify an allocation of new IPv4 address space from ARIN are defined in this section. Phase: 0 Threshold: Greater than 40 /8s Requirements: Requesters must: * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 25% utilization - Demonstrate a one year requirement of 50% utilization Phase: 1 Threshold: 40 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 25% utilization - Demonstrate a one year requirement of 50% utilization * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used. Phase: 2 Threshold: 25 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 85% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 50% utilization - Demonstrate a one year requirement of 75% utilization * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used. * Provide plans for migrating all non-RFC 1918 address space used for internal infrastructure either to IPv6 (preferred) or to private addressing where possible. Where such migration is not possible, provide documentation listing the use of addresses that are not migratable and the reasons for the inability to migrate. * Demonstrate documented plans for availability of production IPv6 infrastructure and connectivity services within 6 months of submitting the request. Phase: 3 Threshold: 10 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 90% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 75% utilization - Demonstrate a one year requirement of 90% utilization * Provide documentation demonstrating migration (where possible) of non-RFC 1918 address space used for internal infrastructure to either IPv6 (preferred) or private addressing. * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure, how it is used, and why it is not possible to migrate those addresses to either IPv6 (preferred) or private addressing. * Demonstrate availability of production IPv6 infrastructure and connectivity services. Notes: * Phase 0 reflects current allocation requirements. * Phases 1 through 3 are to be implemented 30 days after IANA allocates address space from the IPv4 free pool that reduces that free pool to a number of /8s that are at or below the threshold specified. * If multiple thresholds should be crossed within a 30 day period, the requirements from the last threshold crossed will be applied to requesters for additional address space at the time of the request. --- end modification --- Rationale: The rationale for this proposal is threefold: * to prolong the availability of IPv4 addresses for requesters who can provide sufficient justification; * to encourage the deployment of IPv6 as an alternative to IPv4 by making the requirements to justify IPv4 allocations increasingly stringent over time; * to promote the more efficient use of increasingly scarce IPv4 resources. As the lack of significant deployment of IPv6 can attest, the cost of deploying IPv6 currently outweighs the benefits that protocol would appear to provide. This proposal aims to encourage the deployment of IPv6 by over time, making the allocation of IPv4 both more difficult and contingent on the requester demonstrating both support for IPv6 as well as requiring a demonstration that the IPv4 address space they administer is being used efficiently. The goal of these measures is to rebalance the IPv6 deployment cost/benefit ratio thereby encouraging greater uptake of IPv6 before the IPv4 free pool is exhausted. The "IPv4 Soft Landing" policy aims to provide for a smoother transition away from IPv4 towards IPv6 by imposing increasingly strict requirements for new address allocations as the amount of address space available in the IANA unallocated IPv4 address pool decreases. These increased requirements include both more stringent reassignment and utilization percentages as well as requiring documented IPv6 infrastructure services and connectivity provision and the documentation or reuse of public IPv4 address space used for internal infrastructure. The increased stringency in the allocation requirements is intended both to increase the efficiency of utilization of the IPv4 address space and to reduce the likelihood of a "run" on the remaining free pool of IPv4 address space. ARIN staff would be expected to use the same mechanisms in use today to verify conformance to the specified requirements. The requirements for demonstration of IPv6 infrastructure services and connectivity are intended to motivate ISPs to provide those services before the only address space they can offer their customers is IPv6, thereby offering an opportunity to break the "chicken-and-egg" problem limiting significant IPv6 deployment. Verification of these requirements can be done by ARIN staff by using IPv6 transport to connect to published services of the ISP (e.g., DNS servers, WWW URLs, etc.) as well as using IPv6 ping to identified addresses internal to the ISP. Obviously, false positive responses for most any objective mechanism for verifying the availability can be engineered, so ARIN staff may also consider subjective reports of an inability to obtain IPv6 services by customers as an indicator of (lack of) conformance to this requirement. The requirements to migrate internal infrastructure to either IPv6 or private (e.g., RFC 1918) addressing are intended to improve the efficiency of utilization of IPv4 address space, reserving the scarce IPv4 resources for purposes for which IPv6 or private addresses are not suitable. These requirements acknowledge that pragmatically, the use of IPv4 is absolutely essential only for servers in client-server architectures, machines engaged in peer-to-peer applications, and entry points for NAT/ALG devices. As such, use of IPv4 for purposes such as router interface numbering, client-only devices, and devices which should not be available from external networks should be discouraged. Since there can be circumstances in which migration of internal infrastructure addresses to private addressing would not be feasible, this policy allows for requesters to document those situations in which it is not possible to do the migration. The time for transition between phases of this policy are not fixed, rather they depend on the rate of consumption of IPv4 address space from the IANA free pool. Current RIR operational procedure is to request 2 /8s from the IANA when the RIR's current pool of free IPv4 address space is depleted. This procedure should ensure transitions between phases will have some lead-time, so organizations can prepare for the next phase of IPv4 address allocation. Given the highly volatile nature of IPv4 consumption and the inability to define a predictive model rooted in an underlying theory rather than extrapolating over existing data, the thresholds chosen are acknowledged to be somewhat arbitrary. The intent of the chosen values is to provide a "reasonable" amount of time, approximately 18 months, between transitions at current consumption rates (approximately 10 /8s per year). However, it should be explicitly noted that one of the intents of this policy is to extend the IPv4 free pool lifetime, thus as the policy becomes effective, the amount of time between phase transitions would presumably increase. Timetable for implementation: Immediately upon approval of this policy by the ARIN Board of Trustees. _______________________________________________ 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 marla.azinger at frontiercorp.com Wed Aug 22 17:14:04 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Wed, 22 Aug 2007 17:14:04 -0400 Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4C8A0@nyrofcs2ke2k01.corp.pvt> Here are my two cents on this one: Not sure if I am for or against this one. Below is are the pro's and con's I pulled from ppml and I can understand. Thus...leading to my indecision at this point. Brief Summary of PPML Pro's: -This would allow for fewer potential aggregates allocated to an organization providing more consolidated routing announcements. -a level playing field is a good thing among RIR's -I'm sure ARIN staff will continue to be diligent in ensuring that the address blocks assigned are justified over the period they are requested for. Brief Summary of PPML Con's: -I think this proposal moves us in the wrong direction with regards to avoiding hoarding as IPv4 free pool exhaustion nears. -Perhaps policy proposals to change 1-year-supply clauses to 6-month-supply ones would be another way to level the playing field, while moving us in the direction we need to go to deal with IPv4 free pool exhaustion... -This may lead to hording of Ipv4 addresses. Cheers! Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Member Services Sent: Tuesday, August 14, 2007 2:09 PM To: ppml at arin.net Subject: [ppml] Policy Proposal: Expand timeframe of Additional Requests 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: Expand timeframe of Additional Requests Author: Dan Alexander Proposal Version: Version 1.0 Submission Date: 8/14/2007 Proposal type: modify Policy term: permanent Policy statement: The proposal is to modify section 4.2.4.4 of the NRPM Current wording: "After a subscriber has been a member of ARIN for one year they may choose to request a six-month supply of IP addresses." Change to: "After an organization has been an ARIN member in good standing for one year, they may choose to request up to a 12 month supply of IP addresses." Rationale: Currently, all RIR's provide organizations with at least a 12 month supply of IPv4 address space when making subsequent requests, with the exception of the ARIN region. The primary reason for this change is for continuity among all RIR. In doing so, all established organizations have a more consistent access to IP resources. The adjustment does not change demand on IPv4 address space. It only changes the frequency in which established organizations need to request address space. This would allow for fewer potential aggregates allocated to an organization providing more consolidated routing announcements. This does not change the requirement on new organizations where established growth trends have yet to be established. 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 marla.azinger at frontiercorp.com Wed Aug 22 17:17:28 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Wed, 22 Aug 2007 17:17:28 -0400 Subject: [ppml] Policy Proposal: PIv6 for legacy holders with RSA andefficient use Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4C8A1@nyrofcs2ke2k01.corp.pvt> Here are my two cents on this one: -Undecided on this one. I havnt figured out what is the right thing to do. We need anyone that is willing to go to Ipv6 space. But we also need Legacy blocks to be handed back in that arent being used. I feel stuck in the middle. -As I read it, the current RSA only applies to resources received from ARIN, so legacy IPv4 holders can go ahead and get IPv6 space under RSA without having to bring their legacy IPv4 space under RSA or utilization requirements. Cheers! Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Member Services Sent: Monday, July 30, 2007 10:24 AM To: ppml at arin.net Subject: [ppml] Policy Proposal: PIv6 for legacy holders with RSA andefficient use 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: PIv6 for legacy holders with RSA and efficient use Author: Scott Leibrand Proposal Version: 1.0 Submission Date: 7/28/2007 Proposal type: new Policy term: permanent Policy statement: Modify NRPM section 6.5.8.1 (Direct assignments from ARIN to end-user organizations: Criteria), to read: To qualify for a direct assignment, an organization must: 1. not be an IPv6 LIR; and 2. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect, or demonstrate efficient utilization of a direct IPv4 assignment or allocation covered by a current ARIN RSA. Rationale: Current policy allows direct IPv6 allocations and assignments to nearly all organizations with IPv4 allocations or assignments from ARIN. As a result, such organizations can get IPv6 space just as easily as they can get IPv4 space, making it easy for them to transition to IPv6 as soon as they're ready to do so. However, there are some organizations who received IPv4 /23's and /24's prior to the formation of ARIN, and use that space in a multihomed, provider-independent fashion. Under current policy, such organizations cannot get IPv6 PI space without artificially inflating host counts, and are therefore discouraged from adopting IPv6. This policy proposal aims to remove this disincentive, and allow such organizations to easily adopt IPv6. In addition, pre-ARIN assignments were issued through an informal process, and many legacy resource holders have not yet entered into a formal agreement with ARIN, the manager of many such IP numbering resources. This policy proposal would require that such assignments be brought under a current ARIN Registration Services Agreement, thereby formalizing the relationship. Some pre-ARIN assignments may not be used efficiently. As unallocated IPv4 numbering resources are approaching exhaustion, it is important to ensure efficient utilization of IPv4 assignments, and to arrange for reclamation of unused space. Therefore, this policy would require that the organization wishing to receive IPv6 PI space demonstrate efficient utilization of their IPv4 assignment. (Efficient utilization is already defined elsewhere in policy, and the exact mechanism for achieving and determining efficient use is a matter of procedure, not of policy, so detailed procedures are not included in the policy statement above. The intent is that any organization with an assignment of /23 or larger which is less than 50% utilized would renumber and return whole unused CIDR blocks as necessary to bring the remaining CIDR block to 50% utilization or higher. A /24 should be considered efficiently utilized as long as it is in use for multihoming, as /25's and smaller are not routable for that purpose.) It has been suggested that this policy would be useful only until the growth of IPv6 exceeds the growth of IPv4. I would agree with this, and would further posit that the existing "qualify ... under the IPv4 policy currently in effect" language should also be modified at that time. I have therefore proposed this policy with a policy term of "permanent", with the expectation that this section of policy (6.5.8.1) will be rewritten at the appropriate time to entirely remove all IPv4 dependencies. Timetable for implementation: immediate _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From marla.azinger at frontiercorp.com Wed Aug 22 17:19:52 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Wed, 22 Aug 2007 17:19:52 -0400 Subject: [ppml] Policy Proposal: Definition of known ISP and changes to IPv6 initial allocation criteria Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4C8A2@nyrofcs2ke2k01.corp.pvt> Here are my two cents on this one: -I don't support this unless the definition is changed for Ipv4. -This prop and ipv6 housecleaning both attempt to change 6.5.1.1 (d). We only need one prop to do this. I suggest leaving it in this one and taking it out of the Ipv6 housecleaning one. -edits need to be done to change the acronym ISP to LIR. -edit needs to be done to include rwhois as an option in addition to SWIP -I feel the requirements here are week. I believe it would be better if this was revised in line with Scotts suggestion. It would be a stronger and more valid requirement if it were revised as follows: A LIR is an organization that reassigns and/or reallocates at a minimum a IPv4 /23 or IPv6 /44 worth of space to their own downstream customers. Cheers! Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Member Services Sent: Monday, July 30, 2007 9:51 AM To: ppml at arin.net Subject: [ppml] Policy Proposal: Definition of known ISP and changes to IPv6 initial allocation criteria 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: Definition of known ISP and changes to IPv6 initial allocation criteria Author: Kevin Loch Proposal Version: 1 Submission Date: 2007-07-27 Proposal type: new Policy term: permanent Policy statement: Add the following section 6.2.10: 6.2.10 Existing ISP An existing ISP is an organization which meets the following criteria: 1. Has IPv4 or IPv6 address space directly allocated by ARIN; or 2. Has at least a total of an IPv4 /23 or an IPv6 /44 of address space reallocated to them via SWIP by one or more upstream ISPs. Address space directly assigned from ARIN or reassigned from upstream ISPs does not count towards these requirements. Replace 6.5.1.1 (d) with the following text: d. be an existing ISP in the ARIN region or have a plan for making assignments to at least 200 separate organizations within five years. Rationale: This policy proposal would change two things in the IPv6 Initial allocation criteria. It adds a definition for "known ISP" and changes "200 /48 assignments" to 200 assignments of any size, but to separate organizations. Existing ISP: The term "existing, known ISP" in the IPv6 ISP qualification section is too vague and does not give ARIN staff sufficient guidance for evaluating qualifications. This text defines "existing, ISP" in a precise manner and removes the unnecessary and ambiguous word "known". It has come to the author's attention that several organizations have been refused IPv6 ISP allocations because they were not considered an existing, known ISP. At least one of these organizations has a /18 worth of IPv4 space reallocated to them by various upstream ISPs and over 200 IPv4 customers. An organization's choice to use provider addresses does not have any affect on whether or not they are in fact an ISP. Address space that has been reallocated (not reassigned) is a good indicato of an ISP as those SWIP templates are only supposed to be used for downstream ISPs. The IPv4 /23 value was selected to match the utilization requirement for the smallest direct IPv4 allocation from ARIN under current policy. The IPv6 /44 value was selected to represent a number of downstream customers comparable to the IPv4 requirements. Updates to IPv6 initial allocation criteria: Section 6.5.4.1 recommends /56 assignments in some cases and /48 assignments in others. The Initial allocation criteria should reflect the flexibility of these recommendations. An ISP should not have to provide an inefficient address plan on their application even though they expect to have over 200 IPv6 customers. Timetable for implementation: Immediate _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From marla.azinger at frontiercorp.com Wed Aug 22 17:21:06 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Wed, 22 Aug 2007 17:21:06 -0400 Subject: [ppml] Policy Proposal: IANA Policy for Allocation of ASN Blocks toRIRs Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4C8A3@nyrofcs2ke2k01.corp.pvt> Here are my two cents on this one: - I support this. It will add clarification that was missing and it doesnt appear to change anything. Cheers! Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Member Services Sent: Wednesday, July 25, 2007 7:47 AM To: ppml at arin.net Subject: [ppml] Policy Proposal: IANA Policy for Allocation of ASN Blocks toRIRs 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: Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks to Regional Internet Registries Author: Axel Pawlik Proposal Version: 1 Submission Date: 24 July 2007 Proposal type: New Policy term: renewable Policy statement: Abstract This document describes the policy governing the allocation of Autonomous System Numbers (ASNs) from the IANA to the Regional Internet Registries (RIRs). This policy document does not stipulate performance requirements in the provision of services by the IANA to an RIR. Such requirements will be specified by appropriate agreements between ICANN and the Number Resource Organization (NRO). 1. Allocation Principles IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2009, allocations of 2-byte only and 4-byte only ASN blocks will be made separately and independent of each other [1]. This means until 31 December 2009, RIRs can receive two separate ASN blocks, one for 2-byte only ASNs and one for 4-byte only ASNs from the IANA under this policy. After this date, IANA and the RIRs will cease to make any distinction between 2-byte only and 4-byte only ASNs, and will operate ASN allocations from an undifferentiated 4-byte ASN allocation pool. 2. Initial Allocations Each new RIR will be allocated a new ASN block. 3. Additional Allocations An RIR is eligible to receive (an) additional ASN block(s) from the IANA if one of the following conditions is met: 1. The RIR has assigned/allocated 80% of the previously received ASN block, or 2. The number of free ASNs currently held by the RIR is less than two months need. This projection is based on the monthly average number of ASNs assigned/allocated by the RIR over the previous six months. An RIR will be allocated as many ASN blocks as are needed to support their registration needs for the next 12 months, based on their average assignment/allocation rate over the previous six months, unless the RIR specifically requests fewer blocks than it qualifies for. 4. Announcement of IANA Allocations The IANA, the NRO and the RIRs will make announcements and update their respective websites/databases when an allocation is made by the IANA to an RIR. ICANN and the NRO will establish administrative procedures to manage this process. [1. http://www.ripe.net/ripe/policies/proposals/2005-12.html] Rationale: There are global policies governing the allocation of IPv4 and IPv6 blocks from the IANA to RIRs. At this point there is no specific policy regarding the allocation of Autonomous System Numbers from the IANA to the RIRs. This proposal will create a policy to fill this gap. The criteria being proposed has already been the practice between IANA and RIRs so far and it has been proven to work. It is designed to allow RIRs to request ASN blocks from the IANA in a timely fashion and maintain enough ASNs in holding to ensure that their registration services can be sustained. It is also proposed that the RIRs be allocated as many ASN blocks as are needed to support their registration needs for the next 12 months. This will generally mean that each RIR will only need to make one ASN request from the IANA each year, thus lowering operational overhead for the RIRs. Timetable for implementation: Immediate _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From marla.azinger at frontiercorp.com Wed Aug 22 17:23:49 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Wed, 22 Aug 2007 17:23:49 -0400 Subject: [ppml] Policy Proposal: Global Policy for the Allocation of the Remaining IPv4 Address Space Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4C8A4@nyrofcs2ke2k01.corp.pvt> Here are my two cents on this one: - I don't support this one. -Let it run out naturally. Write a policy figuring out what IANA does once contiguous requests cant be met. -This proposal is also taking the same approach as another policy (End Policy for IANA IPv4 allocations to RIRs) and they should be combined. Cheers! Marla Azinger Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Member Services Sent: Friday, July 20, 2007 7:48 AM To: ppml at arin.net Subject: [ppml] Policy Proposal: Global Policy for the Allocation of the Remaining IPv4 Address Space 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: Global Policy for the Allocation of the Remaining IPv4 Address Space Author: Roque Gagliano Co-authors: Francisco Obispo, Hytham EL Nakhal, Didier Allain Kla Proposal Version: v1 Submission Date: 07/17/2007 Proposal type: new Policy term: permanent Policy statement: This policy describes the process for the allocation of the remaining IPv4 space from IANA to the RIRs. When a minimum amount of available space is reached, an identical number of IPv4 allocation units (/8s) will be allocated from IANA to each RIR, replacing the current IPv4 allocation policy. In order to fulfill the requirements of this policy, at the time it is adopted, an identical number of IPv4 allocation units (N units) will be reserved by IANA for each RIR. The number N is defined as: 5. The reserved allocation units will no longer be part of the available space at the IANA pool. The process for the allocation of the remaining IPv4 space is divided in two consecutive phases: 1. Existing Policy Phase: During this phase IANA will continue allocating IPv4 addresses to the RIRs using the existing allocation policy. This phase will continue until a request for IPv4 address space from any RIR to IANA cannot be fulfilled with the remaining IPv4 space available at the IANA pool. This will be the last IPv4 address space request that IANA will accept from any RIR. At this point the next phase of the process will be initiated. 2. Exhaustion Phase: IANA will automatically allocate the reserved IPv4 allocation units to each RIR (N units to each one) and respond to the last request with the remaining available allocation units at the IANA pool (M units). 2.1. Size of the final IPv4 allocations: During this phase IANA will automatically allocate N allocation units to each RIR from the reserved space defined in this policy. IANA will also allocate M allocation units to the RIR that submitted the last request for IPv4 addresses. 2.2. Allocation of the remaining IPv4 Address space: After the completion of the evaluation of the final request for IPv4 addresses, IANA MUST: A) Immediately notify the NRO about the activation of the second phase of this policy. B) Proceed to allocate M allocation units to the RIR that submitted the last request for IPv4 address space. C) Proceed to allocate N allocation units to each RIR from the reserved space. Rationale: The IANA pool of allocation units of IPv4 addresses (/8s) is decreasing rapidly. A new policy is proposed to replace the current "on demand" policy in order to bring certainty on how the remaining space will be allocated. This policy eliminates the pressure on the remaining central pool of addresses by allocating equal amount of allocation units (N) to each RIR. RIR may be studying slow-landing policies or the possibility to reserve specific address spaces for "critical infrastructure" or new companies in order to comply with anti-trust regulations in its region. This policy allows each RIR to adopt those policies through its PDP, which is simpler than a global policy discussion process. Each RIR will have the exact information on the amount of address spaces that they will be receiving as a last allocation from the IANA. The policy is written in such a way that the discussion could be split in two sections: first do we agree on the concept of the policy and second what is the appropriate value for the last allocation units N. Timetable for implementation: This is a Global policy that needs to be approved by all RIRs and then ratified by ASO/ICANN. It has already reached consensus at LACNIC meeting. _______________________________________________ This message sent to you through the ARIN Public Policy Mailing List (PPML at arin.net). Manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml From marla.azinger at frontiercorp.com Wed Aug 22 17:28:42 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Wed, 22 Aug 2007 17:28:42 -0400 Subject: [ppml] Policy Proposal: Definition of known ISP and changes toIPv6 initial allocation criteria Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4C8A6@nyrofcs2ke2k01.corp.pvt> I dont want make people read my responses twice. And I sent out my reviews on each proposal and they appear to be taking a "processing" time. So when they show up you will see my suggestions for what should be combined and what needs to be taken out of yours and left in another similiar one. Cheers! Marla -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Leo Bicknell Sent: Wednesday, August 22, 2007 1:20 PM To: ppml at arin.net Subject: Re: [ppml] Policy Proposal: Definition of known ISP and changes toIPv6 initial allocation criteria In a message written on Mon, Jul 30, 2007 at 12:51:27PM -0400, Member Services wrote: > Replace 6.5.1.1 (d) with the following text: > > d. be an existing ISP in the ARIN region or have a plan for > making assignments to at least 200 separate organizations > within five years. In my IPv6 Policy Housekeeping proposal, recently sent to PPML I proposed similar language, which was discovered today during AC review of the various proposals. Here's the language from the other proposal: ] Change I: ] ] In section 6.5.1.1.d, replace the existing statement with the new ] statement: ] ] "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." Were both proposals to pass, are these substantially similar enough that the AC could use either one to serve the purpose? -- 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 From BillD at cait.wustl.edu Wed Aug 22 17:40:29 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Wed, 22 Aug 2007 16:40:29 -0500 Subject: [ppml] Policy Proposal: Definition of known ISP and changes toIPv6 initial allocation criteria In-Reply-To: <20070822202025.GB18561@ussenterprise.ufp.org> Message-ID: "known" is my only issue with the rewording. I believe know and existing are the same thing to a substantial number of entities and if that is the case, then it should be demonstrable and thus the case for ARIN. bd > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Leo Bicknell > Sent: Wednesday, August 22, 2007 3:20 PM > To: ppml at arin.net > Subject: Re: [ppml] Policy Proposal: Definition of known ISP > and changes toIPv6 initial allocation criteria > > > In a message written on Mon, Jul 30, 2007 at 12:51:27PM > -0400, Member Services wrote: > > Replace 6.5.1.1 (d) with the following text: > > > > d. be an existing ISP in the ARIN region or have a plan for > > making assignments to at least 200 separate organizations > > within five years. > > In my IPv6 Policy Housekeeping proposal, recently sent to > PPML I proposed similar language, which was discovered today > during AC review of the various proposals. Here's the > language from the other proposal: > > ] Change I: > ] > ] In section 6.5.1.1.d, replace the existing statement with the new > ] statement: > ] > ] "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." > > Were both proposals to pass, are these substantially similar > enough that the AC could use either one to serve the purpose? > > -- > 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 > From iljitsch at muada.com Wed Aug 22 17:56:53 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 22 Aug 2007 23:56:53 +0200 Subject: [ppml] Policy Proposal: IANA Policy for Allocation of ASN Blocks to RIRs In-Reply-To: <46A76281.4030706@arin.net> References: <46A76281.4030706@arin.net> Message-ID: On 25-jul-2007, at 16:47, Member Services wrote: > IANA allocates ASNs to RIRs in blocks of 1024 ASNs. Nobody cares. Can these guys figures this stuff out amongst themselves, please? > 2-byte only and 4-byte only ASN And can we please refer to these as 16-bit and 32-bit AS numbers? In the IETF, the word "byte" is traditionally shunned so anyone looking for this stuff will be searching for "32-bit" and not "4-byte". From mksmith at adhost.com Wed Aug 22 18:07:13 2007 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 22 Aug 2007 15:07:13 -0700 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing ofIPv4 IP Addresses In-Reply-To: References: Message-ID: <17838240D9A5544AAA5FF95F8D520316025051BF@ad-exh01.adhost.lan> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Dean Anderson > Sent: Wednesday, August 22, 2007 12:23 PM > To: michael.dillon at bt.com > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal: Decreasing Exponential Rationing > ofIPv4 IP Addresses > > So, now ARIN can't do math? > > Actually, as a management body for a field of engineering and applied > mathematics, greatly concerned with numbers, ARIN is indeed a sort of > mathematical society. > > How do you competently and credibly claim to be able to do network > engineering without mathematical formulas? I'd suppose you were > joking, > but indeed there are those who subscribe to Faith-based network > engineering, and prefer Intelligent Design over Evolution. > > --Dean If we were trying to write policies for a set of engineers then mathematical equations would be justified. However, what I think we're trying to do is write policies that are understandable and implementable by ARIN's user base. This base includes lots of entities and individuals that are perfectly capable of requesting and allocating IP resources without knowing a lick of math, aside from the ability to write enough numbers on a check to pay ARIN for the space. ARIN is not an mathematical society and it does not serve mathematicians. As some Physics professor somewhere said, "if you can't explain it to an 8 year old then you don't understand it." I think we should try to have all of our documentation, whether it be policy, procedures or FAQ's, written in a manner that is understandable to the greatest number of people possible. Regards, Mike Smith From bicknell at ufp.org Wed Aug 22 18:30:26 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 22 Aug 2007 18:30:26 -0400 Subject: [ppml] Policy Proposal: ISP to LIR Clarification In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A02A4C89C@nyrofcs2ke2k01.corp.pvt> References: <454810F09B5AA04E9D78D13A5C39028A02A4C89C@nyrofcs2ke2k01.corp.pvt> Message-ID: <20070822223026.GA25965@ussenterprise.ufp.org> In a message written on Wed, Aug 22, 2007 at 05:06:26PM -0400, Azinger, Marla wrote: > -However before it goes forward it needs edit done to add one > more change. 4.2.1.1 needs ISP changed to LIR. The proposal as written changes all instances of ISP to LIR, including the one in 4.2.1.1. There are only a few exceptions spelled out where the meaning of ISP seems to not be the same as LIR (hence some of the current confusion. The text of my proposal is below: ] Replace all instances of the word "ISP" in the NRPM with the word "LIR" ] and replace all instances of the phrase "LIR/ISP" with "LIR", except for ] the following: ] ] * Leave section 2.4 unchanged. ] * Leave section 2.7 unchanged. ] * In section 4.1.1, replace "ISPs" with "requesters". ] * In section 4.2, also remove "Internet Service Providers". ] * Leave section 6.2.4 unchanged. ] * Leave section 6.3.4 unchanged. ] * In section 6.9, replace "ISPs and LIRs" with "LIRs" for all three ] occurrence. Since writing, one of my fellow AC members has pointed out I had a numbering error. Where I refrence section 4.2 above, what it should have really refrenced was 4.2.1.1. There's no text between the 4.2 bullet and the 4.2.1.1 text, I simply mistakenly wrote down the wrong bullet point. I will be submitting a revision of the proposal to address this one minor numbering issue. You may be referencing the same thing I am in that bullet point, in section 4.2.1.1 is "Internet Service Providers (ISPs)", all of which needs to be replaced with "LIR". -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From bicknell at ufp.org Wed Aug 22 18:47:25 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 22 Aug 2007 18:47:25 -0400 Subject: [ppml] Policy Proposal: IPv6 Policy Housekeeping In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A0272F9DD@nyrofcs2ke2k01.corp.pvt> References: <454810F09B5AA04E9D78D13A5C39028A0272F9DD@nyrofcs2ke2k01.corp.pvt> Message-ID: <20070822224725.GB25965@ussenterprise.ufp.org> In a message written on Wed, Aug 22, 2007 at 05:04:56PM -0400, Azinger, Marla wrote: > - I cant support this until the things that are to be taken out > have a place to go like the creation of NPOG (Number Policy Operational > Guidelines). I would humbly suggest several of these sections have no place in any document produced by ARIN. For instance the 6.1.1 "Overview" section is an introduction to a stand alone document that no longer exists, and does not make sense as a NRPM or NPOG item. It may be worth trying to separate things worthy of the NPOG and things not, though. > -Change I. Make this a separate proposal due to it removing a > /48 as a specification. In fact take it out of this proposal and > let the other proposal(Definition of known ISP and changes to IPv6 > initial allocation criteria) that was submitted address this issue. This problem was actually created by 2005-8, which can be found at http://www.arin.net/policy/proposals/2005_8.html That proposal specifically addressed that it was ok to allocate /56's to customers. I believe ARIN staff (although it may have been a member of the public) stood up at the last meeting and pointed out that 6.5.1.1.d states: ] 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. Prompting the question: If you came to ARIN with a plan to allocate 250 /56 customers, does that meet the requirement of 6.5.1.1.d. Literally by the text it does not, meaning someone with 250 /56 customers is either forced to give them all a /48 (which would be allowed), or not receive IPv6 address space at all. My concern with letting Kevin Loch's proposal address this problem is that it is a side effect of his policy. His policy is about defining the term "existing known ISP", and it is only as a side effect of that he rewrites 6.5.1.1.d. People may well want the clarification in Change I (200+ /56 customers is good enough) without wanting his additional criteria that the requester must already have space, and must have at least a /23 of IPv4, or a /44 of IPv6 already. That said, I wouldn't put up a lot of resistance to a different course of action. > -Change H. I don't support removing this. I suggest relocating > it to 6.5.1.2 because the wording is more clarifying in an example > manner than what is currently written in 6.5.1.2 already. ] 6.5.1.2: ] ] Organizations may qualify for an initial allocation greater than /32 by ] submitting documentation that reasonably justifies the request. If so, ] the allocation size will be based on the number of existing users and ] the extent of the organization's infrastructure. ] 6.4.4: ] ] Where an existing IPv4 service provider requests IPv6 space for ] eventual transition of existing services to IPv6, the number of present ] IPv4 customers may be used to justify a larger request than would be ] justified if based solely on the IPv6 infrastructure. Really? You think the second sentence of 6.5.1.2 is harder to understand that 6.4.4? I would be more inclined to put it in the NPOG, but could live with it in 6.5.1.2 if people feel that's better. -- 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 iljitsch at muada.com Wed Aug 22 18:54:24 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 23 Aug 2007 00:54:24 +0200 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: <46C9A533.5090808@arin.net> References: <46C9A533.5090808@arin.net> Message-ID: <2C3CB56F-1829-4BF3-B9A9-C04B159A293A@muada.com> On 20-aug-2007, at 16:29, Member Services wrote: > Policy Proposal Name: Decreasing Exponential Rationing of IPv4 IP > Addresses I'm opposed to this policy. The main reason is because its premise is flawed: the policy supposes that making sure we don't run out of IPv4 address space the next 10 years is better than the situation where we do run out. However, addresses that sit in the ARIN warehouse unused don't do the community any good, while more stringent rules are harmful, because they make new deployments harder, take longer, and increase risks. Also, the policy doesn't describe a workable practice for the ARIN staff. What if 8 requests come in, 4 for 1 million addresses and 4 for 250000, and the current rationing is for 4 million? Do 4 people get their million and the 4 others get nothing? Or 7 get everything and one gets nothing? Or they all get 80%? In that case, the people who need 250000 will obviously ask for 400000 so they get 285000 but the big ones only get 700000. Or do the small ones get everything they ask for and the big ones only 75%? If you only get a percentage of the address space you need, this is nearly as harmful as not getting anything at all. And the benefits of gaming the system increase astronomically, so "address request fraud" will become much more common. As I said, rationing IPv4 addresses is a bad idea. But if the community wants to do it, there are better ways. Besides, something similar to rationing will happen by itself: around 10% of all requests is for 90% of the yearly address space used, meaning that it's for very large address blocks. At some point, these blocks will no longer be available. But the other 90% of the requests that only use up 15 - 20 million addresses a year can still be fullfilled from smaller blocks that remain available and from address space that is reclaimed. (This is more than 10 million addresses per year.) So small amounts of IPv4 address space will remain available in some form for years to come, the "running out" moment is the point where the largest requests, done but the world's largest ISPs, can no longer be fullfilled. From iljitsch at muada.com Wed Aug 22 19:11:03 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 23 Aug 2007 01:11:03 +0200 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <46C5E72F.2080903@arin.net> References: <46C5E72F.2080903@arin.net> Message-ID: On 17-aug-2007, at 20:21, Member Services wrote: > LIR's may assign blocks in the range of /48 to /64 to end sites. > All assignments made by LIR's should meet a minimum HD-Ratio of .25. > * /64 - Site needing only a single subnet. > * /60 - Site with 2-3 subnets initially. > * /56 - Site with 4-7 subnets initially. > * /52 - Site with 8-15 subnets initially. > * /48 - Site with 16+ subnets initially. I don't support this policy. Please note that at this time, there is rough consensus in the IETF that there is no technical reason to limit end-user assignments to anything smaller than a /48 block. Assuming 10 billion people on the planet, you can easily give them all a /48 from a /14, which is 1/2048th of the current IPv6 global unicast address space, which in turn is only a little more than 1/8th of the total IPv6 address space. Only when you apply the HD ratio in different places, address space starts disappearing much quicker. As someone who has filled out his share of address request forms, I can attest that it's extremely hard to predict address use in advance. As such, I would REALLY like to be able for ANY user who thinks he or she may possibly need it, to get a /48, no questions asked. If it's still deemed desireable to make the standard assignment for residential users smaller than that, I recommend a /60 because this is large enough to accommodate a fairly big home network (I have 5 Cisco routers and 2 wifi base stations in my house and never used more than 4 subnets) but small enough that people won't be tempted to cram a corporate network in it, only to grow out of it anyway and needing a rather painful renumbering operation (which would be a significant risk with assigning /56s). From sleibrand at internap.com Wed Aug 22 19:31:10 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 22 Aug 2007 16:31:10 -0700 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: References: <46C5E72F.2080903@arin.net> Message-ID: <46CCC73E.6030105@internap.com> Iljitsch van Beijnum wrote: > On 17-aug-2007, at 20:21, Member Services wrote: > > >> LIR's may assign blocks in the range of /48 to /64 to end sites. >> All assignments made by LIR's should meet a minimum HD-Ratio of .25. >> > > >> * /64 - Site needing only a single subnet. >> * /60 - Site with 2-3 subnets initially. >> * /56 - Site with 4-7 subnets initially. >> * /52 - Site with 8-15 subnets initially. >> * /48 - Site with 16+ subnets initially. >> > > I don't support this policy. > > Please note that at this time, there is rough consensus in the IETF > that there is no technical reason to limit end-user assignments to > anything smaller than a /48 block. > > > > I would REALLY like to be able for ANY user who > thinks he or she may possibly need it, to get a /48, no questions > asked. I agree with you in opposing this policy proposal, that /48s should be available to users who want/need them, and that none of our policies should discourage LIRs from allocating /48s as needed. > If it's still deemed desireable to make the standard > assignment for residential users smaller than that, I recommend a /60 > because this is large enough to accommodate a fairly big home network > (I have 5 Cisco routers and 2 wifi base stations in my house and > never used more than 4 subnets) but small enough that people won't be > tempted to cram a corporate network in it, only to grow out of it > anyway and needing a rather painful renumbering operation (which > would be a significant risk with assigning /56s). I've heard this argument (in favor of /60 instead of /56) before, and either would be fine with me, but I still don't understand why renumbering from a PA /56 into a PA /48 would be any harder than renumbering from a PA /48 to another provider's PA /48. Thanks, Scott From iljitsch at muada.com Wed Aug 22 19:37:32 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 23 Aug 2007 01:37:32 +0200 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <46CCC73E.6030105@internap.com> References: <46C5E72F.2080903@arin.net> <46CCC73E.6030105@internap.com> Message-ID: <267732C3-3CF0-4DDF-BC26-81323B53741A@muada.com> On 23-aug-2007, at 1:31, Scott Leibrand wrote: > I've heard this argument (in favor of /60 instead of /56) before, > and either would be fine with me, but I still don't understand why > renumbering from a PA /56 into a PA /48 would be any harder than > renumbering from a PA /48 to another provider's PA /48. The choice isn't the one between renumbering from a /56 to a /48 vs a /48 to a /48, but from a /60 to a /48 vs a /56 to a /48. I think / 60 -> /48 is a lot less painful. Once you move from a /60 to a /48 (or skip the /60 because you know you're not a residential user in the first place) you won't have to renumber when you deploy more subnets; only when changing ISPs. From drc at virtualized.org Wed Aug 22 19:44:44 2007 From: drc at virtualized.org (David Conrad) Date: Wed, 22 Aug 2007 16:44:44 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A02A4C89F@nyrofcs2ke2k01.corp.pvt> References: <454810F09B5AA04E9D78D13A5C39028A02A4C89F@nyrofcs2ke2k01.corp.pvt> Message-ID: <44BC5A2D-C8D1-4469-907B-B5AE6986C552@virtualized.org> Marla, Thanks for the input. On Aug 22, 2007, at 2:12 PM, Azinger, Marla wrote: > -I don't support this. OK. > -Let it run out. An understandable position to take. I'll admit I am somewhat skeptical that governments around the world will be willing to accept this approach. > Write a policy figuring out what ARIN does once contiguous requests > cant be met. I agree. Regardless of the approach ARIN takes in the lead up to run out, a policy proposing what should be done post run out would definitely be warranted. > -If we do this and other RIR's don't we are just holding ourselves > back from more allocations from IANA while others continue to > receive more. As has been pointed out, the incremental approach of "Soft Landing" would allow the ARIN community to revise the policy should it be determined that the ARIN region is being disadvantaged. In any event, I will be proposing something like "Soft Landing" to the other RIRs (missed the APNIC deadline, but hope to get something to RIPE and AfriNIC soon). > -This is similar to another proposal. We should combine Decreasing > Exponential Rationing of IPv4 IP Addresses with this one if we want > to look at an approach like this. While I will admit to not having been able to spend the time to fully understand the "Decreasing Exponential Rationing" proposal, I do not believe it to be that similar to "Soft Landing". "Soft Landing" is an attempt to encourage IPv6 deployment by explicitly adding requirements that encourage migration of infrastructure and services to IPv6, ultimately tying the allocation of additional IPv4 addresses to demonstrations of availability of IPv6 services. "Decreasing Exponential Rationing" merely constrains the amount of IPv4 address space being allocated. Also, I think fixed thresholds of IANA /8s are a lot easier for folks to understand than mathematical formula. Again, thanks for the input. Regards, -drc From sleibrand at internap.com Wed Aug 22 19:51:20 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 22 Aug 2007 16:51:20 -0700 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <267732C3-3CF0-4DDF-BC26-81323B53741A@muada.com> References: <46C5E72F.2080903@arin.net> <46CCC73E.6030105@internap.com> <267732C3-3CF0-4DDF-BC26-81323B53741A@muada.com> Message-ID: <46CCCBF8.8010300@internap.com> Iljitsch van Beijnum wrote: > On 23-aug-2007, at 1:31, Scott Leibrand wrote: > >> I've heard this argument (in favor of /60 instead of /56) before, and >> either would be fine with me, but I still don't understand why >> renumbering from a PA /56 into a PA /48 would be any harder than >> renumbering from a PA /48 to another provider's PA /48. > > The choice isn't the one between renumbering from a /56 to a /48 vs a > /48 to a /48, but from a /60 to a /48 vs a /56 to a /48. I think /60 > -> /48 is a lot less painful. Once you move from a /60 to a /48 (or > skip the /60 because you know you're not a residential user in the > first place) you won't have to renumber when you deploy more subnets; > only when changing ISPs. Ok. I'm assuming that networks would renumber due to change ISPs a lot more often than they would need to renumber due to network growth. I would also anticipate that any network growing larger than a /56 would qualify for an IPv6 PI /48, and would therefore only need to renumber once. I don't think the same could be said of all networks growing beyond a /60. -Scott From dlw+arin at tellme.com Wed Aug 22 19:54:43 2007 From: dlw+arin at tellme.com (David Williamson) Date: Wed, 22 Aug 2007 16:54:43 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) In-Reply-To: <44BC5A2D-C8D1-4469-907B-B5AE6986C552@virtualized.org> References: <454810F09B5AA04E9D78D13A5C39028A02A4C89F@nyrofcs2ke2k01.corp.pvt> <44BC5A2D-C8D1-4469-907B-B5AE6986C552@virtualized.org> Message-ID: <20070822235443.GN28312@shell01.cell.sv2.tellme.com> On Wed, Aug 22, 2007 at 04:44:44PM -0700, David Conrad wrote: > > -Let it run out. > > An understandable position to take. I'll admit I am somewhat > skeptical that governments around the world will be willing to accept > this approach. This may sound horribly cynical, but do you think governments will sufficiently understand the problem and then be able to take any sort of meaningful action before The End? Simply due to the timeline involved, I'm fairly certain that any governmental action will be after the fact. At that point, it simply won't matter. -David From sleibrand at internap.com Wed Aug 22 20:00:31 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 22 Aug 2007 17:00:31 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) In-Reply-To: <44BC5A2D-C8D1-4469-907B-B5AE6986C552@virtualized.org> References: <454810F09B5AA04E9D78D13A5C39028A02A4C89F@nyrofcs2ke2k01.corp.pvt> <44BC5A2D-C8D1-4469-907B-B5AE6986C552@virtualized.org> Message-ID: <46CCCE1F.9000709@internap.com> As mentioned before, I support the IPv4 Soft Landing proposal. I would agree with David that: * The IPv4 Soft Landing proposal will not significantly impair networks' ability to obtain IPv4 space. * The proposal will encourage/require adoption of IPv6 where appropriate, thereby reducing demand for remaining IPv4 space. * The IPv4 Soft Landing proposal and the Decreasing Exponential Rationing proposal are sufficiently different that they should remain separate proposals. I believe that they are somewhat complementary/orthogonal, in that either or both could be approved independently, depending on how we want to manage the IPv4 runout phase. -Scott David Conrad wrote: > Marla, > > Thanks for the input. > > On Aug 22, 2007, at 2:12 PM, Azinger, Marla wrote: > >> -I don't support this. >> > > OK. > > >> -Let it run out. >> > > An understandable position to take. I'll admit I am somewhat > skeptical that governments around the world will be willing to accept > this approach. > > >> Write a policy figuring out what ARIN does once contiguous requests >> cant be met. >> > > I agree. Regardless of the approach ARIN takes in the lead up to run > out, a policy proposing what should be done post run out would > definitely be warranted. > > >> -If we do this and other RIR's don't we are just holding ourselves >> back from more allocations from IANA while others continue to >> receive more. >> > > As has been pointed out, the incremental approach of "Soft Landing" > would allow the ARIN community to revise the policy should it be > determined that the ARIN region is being disadvantaged. In any > event, I will be proposing something like "Soft Landing" to the other > RIRs (missed the APNIC deadline, but hope to get something to RIPE > and AfriNIC soon). > > >> -This is similar to another proposal. We should combine Decreasing >> Exponential Rationing of IPv4 IP Addresses with this one if we want >> to look at an approach like this. >> > > While I will admit to not having been able to spend the time to fully > understand the "Decreasing Exponential Rationing" proposal, I do not > believe it to be that similar to "Soft Landing". "Soft Landing" is > an attempt to encourage IPv6 deployment by explicitly adding > requirements that encourage migration of infrastructure and services > to IPv6, ultimately tying the allocation of additional IPv4 addresses > to demonstrations of availability of IPv6 services. "Decreasing > Exponential Rationing" merely constrains the amount of IPv4 address > space being allocated. Also, I think fixed thresholds of IANA /8s > are a lot easier for folks to understand than mathematical formula. > > Again, thanks for the input. > > Regards, > -drc > > > > _______________________________________________ > 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 marla.azinger at frontiercorp.com Wed Aug 22 20:24:38 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Wed, 22 Aug 2007 20:24:38 -0400 Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4C8B8@nyrofcs2ke2k01.corp.pvt> David- Thank you for explaining how you see your prop different from the other one and how you dont see it so easy to combine them. Cheers! Malra -----Original Message----- From: David Conrad [mailto:drc at virtualized.org] Sent: Wednesday, August 22, 2007 4:45 PM To: Azinger, Marla Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) Marla, Thanks for the input. On Aug 22, 2007, at 2:12 PM, Azinger, Marla wrote: > -I don't support this. OK. > -Let it run out. An understandable position to take. I'll admit I am somewhat skeptical that governments around the world will be willing to accept this approach. > Write a policy figuring out what ARIN does once contiguous requests > cant be met. I agree. Regardless of the approach ARIN takes in the lead up to run out, a policy proposing what should be done post run out would definitely be warranted. > -If we do this and other RIR's don't we are just holding ourselves > back from more allocations from IANA while others continue to > receive more. As has been pointed out, the incremental approach of "Soft Landing" would allow the ARIN community to revise the policy should it be determined that the ARIN region is being disadvantaged. In any event, I will be proposing something like "Soft Landing" to the other RIRs (missed the APNIC deadline, but hope to get something to RIPE and AfriNIC soon). > -This is similar to another proposal. We should combine Decreasing > Exponential Rationing of IPv4 IP Addresses with this one if we want > to look at an approach like this. While I will admit to not having been able to spend the time to fully understand the "Decreasing Exponential Rationing" proposal, I do not believe it to be that similar to "Soft Landing". "Soft Landing" is an attempt to encourage IPv6 deployment by explicitly adding requirements that encourage migration of infrastructure and services to IPv6, ultimately tying the allocation of additional IPv4 addresses to demonstrations of availability of IPv6 services. "Decreasing Exponential Rationing" merely constrains the amount of IPv4 address space being allocated. Also, I think fixed thresholds of IANA /8s are a lot easier for folks to understand than mathematical formula. Again, thanks for the input. Regards, -drc From drc at virtualized.org Wed Aug 22 20:44:11 2007 From: drc at virtualized.org (David Conrad) Date: Wed, 22 Aug 2007 17:44:11 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) In-Reply-To: <20070822235443.GN28312@shell01.cell.sv2.tellme.com> References: <454810F09B5AA04E9D78D13A5C39028A02A4C89F@nyrofcs2ke2k01.corp.pvt> <44BC5A2D-C8D1-4469-907B-B5AE6986C552@virtualized.org> <20070822235443.GN28312@shell01.cell.sv2.tellme.com> Message-ID: <3F24C835-98E8-4AF2-8B9F-3BB69E700AB1@virtualized.org> David, On Aug 22, 2007, at 4:54 PM, David Williamson wrote: > This may sound horribly cynical, but do you think governments will > sufficiently understand the problem and then be able to take any sort > of meaningful action before The End? I'll see your cynicism and raise you. Since when does understanding preclude governmental action? :-) Regards, -drc From bicknell at ufp.org Wed Aug 22 21:44:55 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 22 Aug 2007 21:44:55 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: References: <46C5E72F.2080903@arin.net> Message-ID: <20070823014455.GA39561@ussenterprise.ufp.org> In a message written on Thu, Aug 23, 2007 at 01:11:03AM +0200, Iljitsch van Beijnum wrote: > I don't support this policy. > > Please note that at this time, there is rough consensus in the IETF > that there is no technical reason to limit end-user assignments to > anything smaller than a /48 block. Would you support my "Straw Man #2", reproduced here for your convenience? ] 7. Policy statement: ] ] Delete the text in 6.5.4.2 and Replace the text in section 6.5.4.1 ] with the following text: ] ] LIR's may assign up to a /48 to an End Site. End Sites requiring ] more address space than a /48 may be assigned a larger block provided ] the utilization inside that block meets an HD Ratio of 0.94. ] ] 8. Rationale: ] ] The existing section 6.5.4.1 does not provide clear guidance on how ] large of a prefix to allocate to a site. This makes it difficult ] for LIR's to know they are in compliance with the rules, and makes ] it harder for ARIN staff to evaluate requests per the communities ] wishes. -- 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 mysidia at gmail.com Wed Aug 22 22:01:48 2007 From: mysidia at gmail.com (James Hess) Date: Wed, 22 Aug 2007 21:01:48 -0500 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: <2C3CB56F-1829-4BF3-B9A9-C04B159A293A@muada.com> References: <46C9A533.5090808@arin.net> <2C3CB56F-1829-4BF3-B9A9-C04B159A293A@muada.com> Message-ID: <6eb799ab0708221901n49f61f4dq62cda813538c0106@mail.gmail.com> > So small amounts of IPv4 address space will remain available in some > form for years to come, the "running out" moment is the point where > the largest requests, done but the world's largest ISPs, can no > longer be fullfilled. I wouldn't count on "automatic rationing" I think it may be the case that when the large blocks run out; the world's largest ISPs may restructure their requests, essentially to attempt to request the largest possible "smaller block" that can still be available for allocation. In other words, they would rather ask for some additional smaller blocks than ask for the humongous block and get nothing, so whatever remains is potentially consumed very quickly. I would think the world's largest ISPs would be capable of hiring the proper researchers to do the math and find the best way to get as much of the remaining additional IP space as possible. However, maybe at the same time they would be researching getting their stuff cut over to IPv6 or some form of NAT/PAT setup to conserve V4 addressing. -- -J From tedm at ipinc.net Wed Aug 22 22:38:25 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 22 Aug 2007 19:38:25 -0700 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: Message-ID: >-----Original Message----- >From: Dean Anderson [mailto:dean at av8.com] >Sent: Tuesday, August 21, 2007 8:47 PM >To: Ted Mittelstaedt >Cc: Scott Leibrand; ppml at arin.net >Subject: RE: [ppml] Policy Proposal: Decreasing Exponential Rationing of >IPv4 IP Addresses > > >> The extra waiting just uses up ARIN time and resources. > >I don't see how waiting takes up ARIN resources unproductively. The >_waiting_ doesn't use any ARIN time or resources; ARIN staff don't have >to sit on hold with you. > It sure will because people who don't want to wait are going to try bugging ARIN periodically to find out their place "in line" and to pour out their host of sob stories on how they need to be expedited. >> >hard limit in any case. Once the ARIN staff realize they have a hard >> >limit, they'll naturally look harder at documentation. This doesn't >> >have to be specified. >> > >> >> ARIN already looks hard at documentation, it's kind of insulting to >> imply that they don't. > >Some people think that ARIN staff doesn't have enough time to look as >hard as they'd like. > ARIN has what - a surplus of 10 million bucks in the bank right now? And they can't hire more people? Review of applications can be done in parallel it is not a serial process with everything funneling through 1 person. Adding more people makes it go faster. > >How do you want your Oil supply handled? Do you want to just run out >one day? Surprise! All the gas stations are closed. For good. As you >see the last guy locking up shop, you say "What the hell!!". > >And he says: "Well, 6 months ago we asked and no one wanted rationing. >They just wanted to get this over and done with." With that, he hops on >his camel and rides away. > Actually if I could, YES. But it's just wishful thinking. The oil industry has -repeatedly- published the expected production life of the various oil fields. It is, of course, guesstimating when a new oil field is opened because they don't know how far up production can ramp. But once the field production stops growing they can do a very good job of forcasting the remaining life. In any case, diesel oil can be made from sawgrass so we have an infinite supply of it. And turbo diesels are pretty popular in Europe and they will be over here eventually. >And so you go home and freeze to death in your oil-heated home, in the >dark, with no (oil-produced) electricity, and no cable TV, and no >Internet. Of course, the American Indians finally get back the Black >Hills of South Dakota...Its all good. > Well, my home is natural gas, I could always go back to burning coal I suppose if that ran out - or wear a coat. Funny how people managed to live in homes for thousands of years without oil heat... And as for the squawk box - good! It might raise the average intelligence of the country population a good 20 points if that happened. > >> Let's get this thing over and done with and go on to the next thing. > >Ah. Well, running out of IPv4 won't get it 'over and done with'. > Yes it will. It will make it plain to everyone that if they have IPv4 existing they better think about switching over. Soon! >IPv6 isn't waiting for anything from >IPv4. IPv4 runout has very little relevance to IPv6. Running out of >IPv4 won't make it any easier to go to IPv6. > >Hitting a hard limit on IPv4 is expected to cause a set of crises that >are easily and prudently avoided by rationing. > What crises? >Rationing IPv4 also ramps up the incentive to move to IPv6 smoothly. > I don't see how. People that aren't migrating will not migrate until they can't get any more IPv4. It makes no difference if there's any in the bank or not. Ted From tedm at ipinc.net Wed Aug 22 22:43:34 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 22 Aug 2007 19:43:34 -0700 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <46CCCBF8.8010300@internap.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Scott Leibrand >Sent: Wednesday, August 22, 2007 4:51 PM >To: Iljitsch van Beijnum >Cc: ppml at arin.net >Subject: Re: [ppml] Policy Proposal: IPv6 Assignment Guidelines > > >Iljitsch van Beijnum wrote: >> On 23-aug-2007, at 1:31, Scott Leibrand wrote: >> >>> I've heard this argument (in favor of /60 instead of /56) before, and >>> either would be fine with me, but I still don't understand why >>> renumbering from a PA /56 into a PA /48 would be any harder than >>> renumbering from a PA /48 to another provider's PA /48. >> >> The choice isn't the one between renumbering from a /56 to a /48 vs a >> /48 to a /48, but from a /60 to a /48 vs a /56 to a /48. I think /60 >> -> /48 is a lot less painful. Once you move from a /60 to a /48 (or >> skip the /60 because you know you're not a residential user in the >> first place) you won't have to renumber when you deploy more subnets; >> only when changing ISPs. > >Ok. I'm assuming that networks would renumber due to change ISPs a lot >more often than they would need to renumber due to network growth. I >would also anticipate that any network growing larger than a /56 would >qualify for an IPv6 PI /48, and would therefore only need to renumber >once. I don't think the same could be said of all networks growing >beyond a /60. > I think your both naieve to think that your typical corporate customer with a couple hundred nodes and no redundancy to the Internet is going to put up with being told he has to renumber his entire internal network when he decides his current ISP is a chuckhead and decides to go to a competitor. I think said customer is going to look at the money that the labor hours would consume to do this, then call up Cisco and offer them 1/4 of that, and Cisco will happily take the money and supply a double-translation NAT box that will nat IPv6. They already have such things for IPv4 that allow people to do things like run their internal IPv4 network on the same numbers that are used for the root nameservers, etc. Ted From tedm at ipinc.net Wed Aug 22 22:44:38 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 22 Aug 2007 19:44:38 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) In-Reply-To: <20070822235443.GN28312@shell01.cell.sv2.tellme.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >David Williamson >Sent: Wednesday, August 22, 2007 4:55 PM >To: David Conrad >Cc: ppml at arin.net >Subject: Re: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) > > >On Wed, Aug 22, 2007 at 04:44:44PM -0700, David Conrad wrote: >> > -Let it run out. >> >> An understandable position to take. I'll admit I am somewhat >> skeptical that governments around the world will be willing to accept >> this approach. > >This may sound horribly cynical, but do you think governments will >sufficiently understand the problem and then be able to take any sort >of meaningful action before The End? > >Simply due to the timeline involved, I'm fairly certain that any >governmental action will be after the fact. At that point, it simply >won't matter. > As a one-time PolySci major I am also positive this is exactly the way it will work. Ted From tedm at ipinc.net Wed Aug 22 22:52:07 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 22 Aug 2007 19:52:07 -0700 Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) In-Reply-To: <3F24C835-98E8-4AF2-8B9F-3BB69E700AB1@virtualized.org> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >David Conrad >Sent: Wednesday, August 22, 2007 5:44 PM >To: David Williamson >Cc: Public Policy Mailing List >Subject: Re: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) > > >David, > >On Aug 22, 2007, at 4:54 PM, David Williamson wrote: >> This may sound horribly cynical, but do you think governments will >> sufficiently understand the problem and then be able to take any sort >> of meaningful action before The End? > >I'll see your cynicism and raise you. Since when does understanding >preclude governmental action? :-) > Ah, but they take a while before they get anywhere near it, you see. If you told the average government that their water supply is being contaminated by inadequate maintainence and rusting water mains, and they need to put more money into the water bureau so they can fix the pipes, they would pass a law that would mandate all open resivours be covered to prevent birds from pooping in them. Then when everyone is buying and drinking bottled water to avoid getting dysentary, the government would take that as proof that the existing water supply is adequate and no maintainence is needed. Then on the day that the largest water main, that runs under the front of the state capitol, ruptured, they would demand the resignation of the chief of the water bureau. Laugh while you can - this is a description of how bridge maintainence dollars are being handled in the US. Ted From stephen at sprunk.org Wed Aug 22 22:43:54 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 22 Aug 2007 21:43:54 -0500 Subject: [ppml] Policy Proposal: IPv6 Policy Housekeeping References: <454810F09B5AA04E9D78D13A5C39028A0272F9DD@nyrofcs2ke2k01.corp.pvt> Message-ID: <08a101c7e530$ed60bf40$483816ac@atlanta.polycom.com> Thus spake "Azinger, Marla" > - I cant support this until the things that are to be taken out have > a place to go like the creation of NPOG (Number Policy > Operational Guidelines). While I understand that argument, I do not feel that we should delay the proposal on that basis. The simple matter is that many of the sections to be removed are not policy and do not belong in the NRPM; whether they belong in a NPOG (which could be created without IRPEP action) doesn't change that fact. > -Change I. Make this a separate proposal due to it removing a > /48 as a specification. In fact take it out of this proposal and > let the other proposal(Definition of known ISP and changes to > IPv6 initial allocation criteria) that was submitted address this > issue. ] Change I: ] ] In section 6.5.1.1.d, replace the existing statement with the new ] statement: ] ] "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." I think this change is natural fallout from 2005-8 and does not constitute making "new" policy. However, if this change were to reduce support for the proposal as a whole, I would agree that it needs to be separated out. Question: If that were the case, would the AC allow the authors to submit a new proposal for the separated change even though the deadline has passed, or would it have to wait for the next policy cycle? If the latter, perhaps a better action would be for people to say "I support this proposal, except for Change X" and have the AC make edits later as consensus warrants? > -Change H. I don't support removing this. I suggest relocating it > to 6.5.1.2 because the wording is more clarifying in an example > manner than what is currently written in 6.5.1.2 already. ] Change H: ] ] Remove section 6.4.4. I do not find 6.5.1.2, as it stands, any less enlightening than 6.4.4; if anything, I prefer the language of the former since it's more general. Also, 6.4 describes "principles" while 6.5 gives the actual policy, so 6.4 has no effect in practice and thus doesn't belong in the NRPM. Moving text from 6.4 to 6.5 would be a policy change and inappropriate for a "housekeeping" proposal. 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 mack at exchange.alphared.com Wed Aug 22 23:16:37 2007 From: mack at exchange.alphared.com (mack) Date: Wed, 22 Aug 2007 22:16:37 -0500 Subject: [ppml] Dynamic IPs and IP runout Message-ID: <859D2283FD04CA44986CC058E06598F84B1D9AA4A2@exchange4.exchange.alphared.local> This is sure to create a firestorm so flame away: The biggest consumer of IPs is for end workstations. These could be converted to NAT but there is currently no incentive to do so. My home ISP still allocates dynamic ips for each DSL modem. On the other hand most of these end users are concerned with services available on the internet ie. smtp, ftp, http, https, IM, voip (which has various implementation some of which don't work well with NAT). These service for the most part don't work with both parties behind NAT. Additionally, high BW http sites can't be easily placed behind NAT due to flow limitations on network equipment. Some cable providers have already converted to NAT and I routinely deal with double NAT issues at work from end users. No one who does actual networking likes NAT, but I think more home users should be pushed behind it. Obviously some home users operate home businesses and such. We all have sidelines. Therefore if this direction is headed we need to provide exceptions. If most users were placed behind NAT they wouldn't notice (except the ones running bit torrent, slingbox and VOIP). Most of my relatives use two applications http and smtp (ie. web and e-mail) and wouldn't recognize the acronyms. Most businesses don't use much else either and they restrict bit torrent and the like. Perhaps we should be pushing reclamation efforts this direction. I know the legacy blocks look nice and juicy but the fact is home users are a softer target. Someone from ARIN may have figures on how many IPs are assigned to user boxes and how many provide services. It would be nice if they shared to determine if this direction has merit. LR Mack McBride Network Administrator Alpha Red, Inc. From stephen at sprunk.org Wed Aug 22 23:01:51 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 22 Aug 2007 22:01:51 -0500 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing ofIPv4 IP Addresses References: Message-ID: <08eb01c7e535$3cc5c590$483816ac@atlanta.polycom.com> Thus spake "Ted Mittelstaedt" >>From: Dean Anderson [mailto:dean at av8.com] >> >>Some people think that ARIN staff doesn't have enough time to > look as hard as they'd like. > > ARIN has what - a surplus of 10 million bucks in the bank right > now? And they can't hire more people? Review of applications > can be done in parallel it is not a serial process with everything > funneling through 1 person. Adding more people makes it go > faster. That depends on your definition of "faster". Processing a request takes the amount of time it takes; that latency is unavoidable. Throughput can be increased to a point by having as many analysts as there are concurrently outstanding requests, and that will reduce the latency due to waiting for an analyst to get to yours, but that's it. My understanding is that the vast majority of time is spent trying to figure out whether someone's request meets policy or not, particularly for first-time requestors, because of insufficient documentation. If we want to reduce that part of the latency, we need to fix the policy that created it -- not hire more people to perpetuate it. >>> Let's get this thing over and done with and go on to the next thing. >> >>Ah. Well, running out of IPv4 won't get it 'over and done with'. > > Yes it will. It will make it plain to everyone that if they have IPv4 > existing they better think about switching over. Soon! I agree; by stretching out the useful life of IPv4, we waste time and money that would be better spent migrating to IPv6. That is sufficient reason for me to oppose this proposal. 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 randy at psg.com Wed Aug 22 23:33:31 2007 From: randy at psg.com (Randy Bush) Date: Wed, 22 Aug 2007 17:33:31 -1000 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing ofIPv4 IP Addresses In-Reply-To: <08eb01c7e535$3cc5c590$483816ac@atlanta.polycom.com> References: <08eb01c7e535$3cc5c590$483816ac@atlanta.polycom.com> Message-ID: <46CD000B.9090405@psg.com> a plonkee wrote: >> Adding more people makes it go faster. http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959/ref=pd_bbs_sr_1/002-5628655-0864829?ie=UTF8&s=books&qid=1187839971&sr=8-1 randy From tedm at ipinc.net Thu Aug 23 00:02:11 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 22 Aug 2007 21:02:11 -0700 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing ofIPv4 IP Addresses In-Reply-To: <08eb01c7e535$3cc5c590$483816ac@atlanta.polycom.com> Message-ID: >-----Original Message----- >From: Stephen Sprunk [mailto:stephen at sprunk.org] >Sent: Wednesday, August 22, 2007 8:02 PM >To: Ted Mittelstaedt; Dean Anderson >Cc: ARIN PPML >Subject: Re: [ppml] Policy Proposal: Decreasing Exponential Rationing >ofIPv4 IP Addresses > > >Thus spake "Ted Mittelstaedt" >>>From: Dean Anderson [mailto:dean at av8.com] >>> >>>Some people think that ARIN staff doesn't have enough time to >> look as hard as they'd like. >> >> ARIN has what - a surplus of 10 million bucks in the bank right >> now? And they can't hire more people? Review of applications >> can be done in parallel it is not a serial process with everything >> funneling through 1 person. Adding more people makes it go >> faster. > >That depends on your definition of "faster". Processing a request >takes the >amount of time it takes; that latency is unavoidable. Throughput can be >increased to a point by having as many analysts as there are concurrently >outstanding requests, and that will reduce the latency due to >waiting for an >analyst to get to yours, but that's it. > Yes, of course keep in mind here I was refuting the OP's assertion that ARIN's staffers don't have enough time to review applications. Let me write out the explanation in long hand to make it more clear, if ARIN is indeed chronically overloaded as the OP asserted, then they have a backlog - since they have a lot of money, they can hire more people and AFTER they are trained, the work will go faster. You can draw some obvious conclusions from this. Since ARIN can hire more staff, and are NOT doing so (at least as far as we know) then they obviously do NOT have a backlog. As for the argument that adding more gerbils clogs up the wheel, sure that is true - which is why if you have an immediate and unexpected crisis, throwing more people at it is the worst thing you can do. It is, however NOT true if the problem is chronic. If there's 5 men's worth of work to get through in the day and you only hire 4 men, then you either have a backlog that gets bigger and bigger, or you do a half-assed job on the work you got. For a real world example of this check out Ford Motor Company's lead time on their new 2008 model trucks. >My understanding is that the vast majority of time is spent trying >to figure >out whether someone's request meets policy or not, particularly for >first-time requestors, because of insufficient documentation. If >we want to >reduce that part of the latency, we need to fix the policy that created >it -- not hire more people to perpetuate it. Or simply toss the application back to the requestor and tell them to do it over and this time read the instructions rather than watching the movie and reading Cliff's Notes? It works in high school... Ted From tedm at ipinc.net Thu Aug 23 00:03:43 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 22 Aug 2007 21:03:43 -0700 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing ofIPv4 IP Addresses In-Reply-To: <46CD000B.9090405@psg.com> Message-ID: >-----Original Message----- >From: Randy Bush [mailto:randy at psg.com] >Sent: Wednesday, August 22, 2007 8:34 PM >To: Stephen Sprunk >Cc: Ted Mittelstaedt; Dean Anderson; ARIN PPML >Subject: Re: [ppml] Policy Proposal: Decreasing Exponential Rationing >ofIPv4 IP Addresses > > >a plonkee wrote: >>> Adding more people makes it go faster. > >http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniv ersary/dp/0201835959/ref=pd_bbs_sr_1/002-5628655-0864829?ie=UTF8&s=books&qid =1187839971&sr=8-1 Wow, I didn't know Amazon was selling the Orange Catholic Bible.... Ted From mysidia at gmail.com Thu Aug 23 00:04:22 2007 From: mysidia at gmail.com (James Hess) Date: Wed, 22 Aug 2007 23:04:22 -0500 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: References: Message-ID: <6eb799ab0708222104q5c2941c7q1711077168fd1042@mail.gmail.com> > >How do you want your Oil supply handled? Do you want to just run out > >one day? Surprise! All the gas stations are closed. For good. As you > >see the last guy locking up shop, you say "What the hell!!". > > I suggest it's a better scenario than this one... Do you want to just run out one day? Surprise! There's still some gas left, but we'll be all out in 10 years, there's a perpetual line of 3,000 cars waiting to get into each station.... get in line, and hope it doesn't run out before it's your turn. Wait a few months before getting your gas... and by the time it's your turn in line, it's 10 years later, and you don't get any, or the ration level has dropped, so you only get 0.5 liters, whereas the guy just in front of you went off with 5 liters.. Now not only did you get insufficient supply, but you had to consume a lot more time, energy, and $$$ to get it, so did the station, by the way, and the line will just keep getting longer and longer the tighter the rationing gets, costing everyone. If they had just told you they were out, you could more easily move on, rather than fight over 0.5 liters of gas 10 years before the supply runs out. Specifying rationing as a "function," not actually included in the policy provides no control or guidance over how bad rationing gets. In fact, even the "function" has not been specified in sufficient detail to see how aggressive this rationing is. If rationing is to be done, the policy should contain a time table that shows how many addresses can be allocated over what time periods. The general rules/procedures that would be utilized to implement such rationing need be spelled out, otherwise, the result, the reasonableness, and material effect on requestors of address space would seem to be unpredictable. It remains to be shown that rationing overall has a benefit that outweighs the negatives and is any better than earlier exhaustion that rationing attempts to avoid. -- -J From dogwallah at gmail.com Thu Aug 23 00:15:34 2007 From: dogwallah at gmail.com (McTim) Date: Thu, 23 Aug 2007 07:15:34 +0300 Subject: [ppml] Policy Proposal: IANA Policy for Allocation of ASN Blocks to RIRs In-Reply-To: References: <46A76281.4030706@arin.net> Message-ID: On 8/23/07, Iljitsch van Beijnum wrote: > On 25-jul-2007, at 16:47, Member Services wrote: > > > IANA allocates ASNs to RIRs in blocks of 1024 ASNs. > > Nobody cares. Can these guys figures this stuff out amongst > themselves, please? I think they have, and are looking for our stamp of approval. It's good housekeeping, I support it. > > > 2-byte only and 4-byte only ASN > > And can we please refer to these as 16-bit and 32-bit AS numbers? In > the IETF, the word "byte" is traditionally shunned so anyone looking > for this stuff will be searching for "32-bit" and not "4-byte". so you do care ;-) -- Cheers, McTim $ whois -h whois.afrinic.net mctim From tedm at ipinc.net Thu Aug 23 00:54:23 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 22 Aug 2007 21:54:23 -0700 Subject: [ppml] Dynamic IPs and IP runout In-Reply-To: <859D2283FD04CA44986CC058E06598F84B1D9AA4A2@exchange4.exchange.alphared.local> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >mack >Sent: Wednesday, August 22, 2007 8:17 PM >To: ppml at arin.net >Subject: [ppml] Dynamic IPs and IP runout > > >This is sure to create a firestorm so flame away: > >The biggest consumer of IPs is for end workstations. >These could be converted to NAT but there is currently no >incentive to do so. >My home ISP still allocates dynamic ips for each DSL modem. > >On the other hand most of these end users are concerned with >services available >on the internet ie. smtp, ftp, http, https, IM, >voip (which has various implementation some of which don't work >well with NAT). > >These service for the most part don't work with both parties behind NAT. >Additionally, high BW http sites can't be easily placed behind NAT >due to flow >limitations on network equipment. > >Some cable providers have already converted to NAT and I routinely >deal with >double NAT issues at work from end users. >No one who does actual networking likes NAT, but I think more home >users should be >pushed behind it. > >Obviously some home users operate home businesses and such. >We all have sidelines. Therefore if this direction is headed we >need to provide exceptions. > >If most users were placed behind NAT they wouldn't notice (except >the ones running >bit torrent, slingbox and VOIP). The newest NAT devices do not have a problem with VoIP phones. I have been deploying Linksys RV042's at certain customer sites and their VoIP phones wok fine behind them. All NAT code contains exception routines for the icky protocols. Look at the code under the free BSD unixes (where NAT was first written and made available - I had FreeBSD NAT boxes running in 1997 at the company I was working at - at least a year before it came out in Cisco IOS version 11.2) and you will see a ton of them, and more added every year. >Most of my relatives use two applications >http and smtp (ie. web and e-mail) and wouldn't recognize the acronyms. >Most businesses don't use much else either and they restrict bit >torrent and the like. > Some of those are used almost exclusively for sharing illegal pirated stuff and frankly my personal feeling is I'm not pouring my blood, sweat and tears into my network just so some jerkoff can download a movie illegally that he could walk 5 blocks to the video start and buy for $9.99 (or check out from the library for free) If NAT breaks their stuff, so what. >Perhaps we should be pushing reclamation efforts this direction. >I know the legacy blocks look nice and juicy but the fact is home >users are a softer target. > It won't happen. I'll use a simple example. About 2 miles away from here is a grocery store. In it, you can buy apples for 80 cents a pound. About 1 mile away from here is a large vacant abandonded field that has a parking lot next to it. About 200 feet away from the lot is an apple tree. (part of an old orchard) When the apples are in season they are delicious. The ground under the tree is covered with rotten ones that have fallen off the tree. To pick apples off a tree like that requires a fruit picker which is basically a coffee can on a pole. (I have one) When the tree is in season you can spend about 10 minutes and pick a bag of apples. (I do) When apples are in season, how many people do you estimate actually do this? If your estimate is zero, you would be just about right. Most people would rather do the grocery store routine because they all feel their time is so valuable that they cannot afford to take the 10 minutes to get a result that tastes 100 times better than the stuff in the store. Your not going to see ARIN tell a large ISP with hundreds of thousands of customers to put all of them behind a translator and then hand back over part of their IPv4 holdings that are freed up - even though as you point out, it may be technically rather easy to do it. The politics of it are just wrong. Your going to get more support for going after a lost /8 that isn't being advertised in BGP than for going after the softer targets. Nobody in the US or Europe wants to be out in the field, picking the apples one by one by one. They are all going to go into the store and buy them. In other countries they don't have this problem - people will pick the apples. But in the Western culture the people will not accept a scheme like what your proposing. It goes against what they think is the normal way to do things. They will accept a scheme of going after the juicy ones because "that is what common sense would tell someone to do" Most have not come to understand that common sense is a cultural thing that is programmed into them. Enjoy the apples, though. Ted From sleibrand at internap.com Thu Aug 23 01:02:49 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 22 Aug 2007 22:02:49 -0700 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: References: Message-ID: <46CD14F9.6080408@internap.com> Ted Mittelstaedt wrote: > >> -----Original Message----- >> From: Scott Leibrand >> >> Ok. I'm assuming that networks would renumber due to change ISPs a lot >> more often than they would need to renumber due to network growth. I >> would also anticipate that any network growing larger than a /56 would >> qualify for an IPv6 PI /48, and would therefore only need to renumber >> once. I don't think the same could be said of all networks growing >> beyond a /60. >> > > I think your both naieve to think that your typical corporate customer > with a couple hundred nodes and no redundancy to the Internet is going > to put up with being told he has to renumber his entire internal network > when he decides his current ISP is a chuckhead and decides to go to a > competitor. I think said customer is going to look at the money that the > labor hours would consume to do this, then call up Cisco and offer them > 1/4 of that, and Cisco will happily take the money and supply a > double-translation NAT box that will nat IPv6. They already have such > things for IPv4 that allow people to do things like run their internal > IPv4 network on the same numbers that are used for the root nameservers, > etc. Call me naive if you want, but I've posted before (during the ULA-C discussion) that I fully expect that to happen. I just hope people choosing to do NATv6 will do so with ULA or PI space, not with PA space from their former provider (who has since reassigned it to another customer). And in the case of the corporation with the NATv6 box, the whole discussion is moot, and it doesn't really matter to them if they get a /48, /56, or even a /60 of PA space from their current provider. -Scott From sleibrand at internap.com Thu Aug 23 01:12:31 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 22 Aug 2007 22:12:31 -0700 Subject: [ppml] Dynamic IPs and IP runout In-Reply-To: <859D2283FD04CA44986CC058E06598F84B1D9AA4A2@exchange4.exchange.alphared.local> References: <859D2283FD04CA44986CC058E06598F84B1D9AA4A2@exchange4.exchange.alphared.local> Message-ID: <46CD173F.6060205@internap.com> Mack, I think that's exactly what ISPs will start doing the minute they realize there are no more free IP addresses to be had from ARIN. Until then, the incentives are actually the opposite direction: they're better off giving every customer a public IP, so they have more public IPs available when they convert all the customers to NAT. This isn't necessarily a bad thing. If, as part of managing a world without an IPv4 free pool, we decide to allow the regulated sale of IPv4 netblocks, then we will undoubtedly see the "supply" of IP addresses switch from the free pool (where they're free) to the low-hanging fruit like this. As Ted mentioned, I think we'd be wasting out time trying to get people to voluntarily return to ARIN space reclaimed this way. But I think we can set up the structures over the next couple years such that we have a smooth transition between getting IPs from the IPv4 free pool and getting them from ISPs who've reclaimed them like this. -Scott mack wrote: > This is sure to create a firestorm so flame away: > > The biggest consumer of IPs is for end workstations. > These could be converted to NAT but there is currently no incentive to do so. > My home ISP still allocates dynamic ips for each DSL modem. > > On the other hand most of these end users are concerned with services available > on the internet ie. smtp, ftp, http, https, IM, > voip (which has various implementation some of which don't work well with NAT). > > These service for the most part don't work with both parties behind NAT. > Additionally, high BW http sites can't be easily placed behind NAT due to flow > limitations on network equipment. > > Some cable providers have already converted to NAT and I routinely deal with > double NAT issues at work from end users. > No one who does actual networking likes NAT, but I think more home users should be > pushed behind it. > > Obviously some home users operate home businesses and such. > We all have sidelines. Therefore if this direction is headed we need to provide exceptions. > > If most users were placed behind NAT they wouldn't notice (except the ones running > bit torrent, slingbox and VOIP). Most of my relatives use two applications > http and smtp (ie. web and e-mail) and wouldn't recognize the acronyms. > Most businesses don't use much else either and they restrict bit torrent and the like. > > Perhaps we should be pushing reclamation efforts this direction. > I know the legacy blocks look nice and juicy but the fact is home users are a softer target. > > Someone from ARIN may have figures on how many IPs are assigned to user boxes and how many provide services. > It would be nice if they shared to determine if this direction has merit. > > LR Mack McBride > Network Administrator > Alpha Red, Inc. > _______________________________________________ > 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 michael.dillon at bt.com Thu Aug 23 08:53:06 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 23 Aug 2007 13:53:06 +0100 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: References: <46C5E72F.2080903@arin.net> Message-ID: > I don't support this policy. I also don't support it. > If it's still deemed > desireable to make the standard assignment for residential > users smaller than that, I recommend a /60 I disagree. ARIN has already settled on a /56 and the IETF consensus that all sites should be /48 is a bit more wobbly when it comes to consumer sites, i.e. homes and apartments. Many of the IETF members who agree that there is no technical reason to not do /48 everywhere, will also admit that using /56 for consumer subscribers only, is not going to create problems. > because this is > large enough to accommodate a fairly big home network (I have > 5 Cisco routers and 2 wifi base stations in my house and > never used more than 4 subnets) but small enough that people > won't be tempted to cram a corporate network in it, only to > grow out of it anyway and needing a rather painful > renumbering operation (which would be a significant risk with > assigning /56s). And there is a prime example of why a /56 for consumers only, will not create problems. It is exceedingly rare for a private home or apartment to turn into a business. For the very, very few who do this, there may be some pain, but that does not warrant a change in the public policy. Since there is no penalty to ISPs for assigning a /48 to a home user, anyone who anticipates building a corporate network in their basement or spare bedroom, should ask their ISP for a /48. Problem solved. --Michael Dillon From michael.dillon at bt.com Thu Aug 23 09:06:34 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 23 Aug 2007 14:06:34 +0100 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: References: <46CCCBF8.8010300@internap.com> Message-ID: > I think your both naieve to think that your typical corporate > customer with a couple hundred nodes and no redundancy to the > Internet is going to put up with being told he has to > renumber his entire internal network when he decides his > current ISP is a chuckhead and decides to go to a competitor. Perhaps you haven't read RFC 4192? It is not necessary to renumber the entire internal network to change ISPs. A lot of the number changing happens automatically, because both ISPs assign a /48 prefix. All interface addresses are unchanged, only the prefix changes. And this is accomplished in a two step process where you begin by adding a second prefix, which results in all interfaces having at least 2 IPv6 addresses. The process is not entirely painless, but it is far less work than with IPv4. > I think said customer is going to look at the money that the > labor hours would consume to do this, then call up Cisco and > offer them > 1/4 of that, and Cisco will happily take the money and supply > a double-translation NAT box that will nat IPv6. I don't think you understand Cisco's business model. They don't do low margin products unless the volume is very high, and the low margin product supports the sale of high-margin products. I'm sure that various Chinese manufacturers will supply such boxes because they tend to build anything that is possible and throw it onto the market to see if there is demand. But any kind of NAT sacrifices functionality and the cost of that is probably higher than the cost of IPv6 renumbering. --Michael Dillon From iljitsch at muada.com Thu Aug 23 09:08:51 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 23 Aug 2007 15:08:51 +0200 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <20070823014455.GA39561@ussenterprise.ufp.org> References: <46C5E72F.2080903@arin.net> <20070823014455.GA39561@ussenterprise.ufp.org> Message-ID: <726B6616-E652-49F7-B4C9-2BAEC71A985E@muada.com> On 23-aug-2007, at 3:44, Leo Bicknell wrote: > Would you support my "Straw Man #2", reproduced here for your > convenience? > ] LIR's may assign up to a /48 to an End Site. End Sites requiring > ] more address space than a /48 may be assigned a larger block > provided > ] the utilization inside that block meets an HD Ratio of 0.94. I'm not sure how that works. Do I need to use 33000 subnets in a /48 (that's about a HD ratio of 0.94) before I can get a /47? Or do I need to submit a plan for 456000 subnets to get a /44? But 456000 subnets will also fit in a /45, so why the extra bit? From iljitsch at muada.com Thu Aug 23 09:12:28 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 23 Aug 2007 15:12:28 +0200 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: <6eb799ab0708221901n49f61f4dq62cda813538c0106@mail.gmail.com> References: <46C9A533.5090808@arin.net> <2C3CB56F-1829-4BF3-B9A9-C04B159A293A@muada.com> <6eb799ab0708221901n49f61f4dq62cda813538c0106@mail.gmail.com> Message-ID: <3C8D0FA7-84E0-416B-AB83-62955B90D4D4@muada.com> On 23-aug-2007, at 4:01, James Hess wrote: > I think it may be the case that when the large blocks run out; the > world's largest ISPs > may restructure their requests, essentially to attempt to request > the largest > possible "smaller block" that can still be available for allocation. Why would they make life hard for themselves trying to get a /16 when they really need a /12? > In other words, they would rather ask for some additional smaller > blocks than > ask for the humongous block and get nothing, so whatever remains is > potentially > consumed very quickly. Farmers don't irrigate their land with bottled water... The scales are too different. From michael.dillon at bt.com Thu Aug 23 09:19:04 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 23 Aug 2007 14:19:04 +0100 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing ofIPv4 IP Addresses In-Reply-To: References: Message-ID: > Funny how people managed to live in homes for thousands of > years without oil heat... Yes they did, but have you ever been in one of those homes? I have been in two of them, in the Ural mountains of Russia in winter when the outside temperature rose up to minus 30 degrees in the daytime. These are small square boxes made of thick logs covered with a thick layer of plaster inside and out. The walls are roughly one and a half feet thick (50 cm). The kitchen is dominated by a huge clay platform that is a combination woodstove, bread oven and hypocaust. The master bed is on top of the platform behind the chimney, roughly in the center of the house. There are probably millions of Russians and Tatars and other Siberians living like this today. Most of them do have electricity and in larger towns they also have gas. But if the gas and electric are cut off, life goes on not much different from a thousand years ago. When resources are scarce, people can make do and go to great efforts to live off of what is available. And that is what we have done with IPv4 and NAT and DHCP etc. But we could live in an IPv6 world instead where everyone has enough subnet room in their personal home allocation to carve off 4 or 5 subnets for an in-law apartment. --Michael Dillon From Lee.Howard at stanleyassociates.com Thu Aug 23 09:29:07 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 23 Aug 2007 09:29:07 -0400 Subject: [ppml] Policy Proposal: IPv6 Policy Housekeeping In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A0272F9DD@nyrofcs2ke2k01.corp.pvt> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB406C0D870@CL-S-EX-1.stanleyassociates.com> > > -Change I. Make this a separate proposal due to it removing > a /48 as a specification. In fact take it out of this > proposal and let the other proposal(Definition of known ISP > and changes to IPv6 initial allocation criteria) that was > submitted address this issue. /48 is no longer a requirement, according to the "guidelines" in section 6.5.4.1. This change was passed as policy proposal 2005-8. Lee From Lee.Howard at stanleyassociates.com Thu Aug 23 09:38:49 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 23 Aug 2007 09:38:49 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB406C0D890@CL-S-EX-1.stanleyassociates.com> > >Ok. I'm assuming that networks would renumber due to change > ISPs a lot > >more often than they would need to renumber due to network > growth. I > >would also anticipate that any network growing larger than a > /56 would > >qualify for an IPv6 PI /48, and would therefore only need to > renumber > >once. I don't think the same could be said of all networks growing > >beyond a /60. > > > > I think your both naieve to think that your typical corporate > customer with a couple hundred nodes and no redundancy to the > Internet is going to put up with being told he has to > renumber his entire internal network when he decides his > current ISP is a chuckhead and decides to go to a competitor. How is that worse than the way things are now? If the choices are to (arguably) collapse the Internet under the weight of unaggregable routing tables, or make enterprise networks renumber when changing providers, which choice is preferable? > I think said customer is going to look at the money that the > labor hours would consume to do this, then call up Cisco and > offer them > 1/4 of that, and Cisco will happily take the money and supply > a double-translation NAT box that will nat IPv6. They > already have such things for IPv4 that allow people to do > things like run their internal > IPv4 network on the same numbers that are used for the root > nameservers, etc. Is that a problem? Are you saying this proposal is unneeded, and all end users should get PI space? Lee From jordi.palet at consulintel.es Thu Aug 23 09:55:20 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 23 Aug 2007 15:55:20 +0200 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <726B6616-E652-49F7-B4C9-2BAEC71A985E@muada.com> Message-ID: If we move into this direction, we should also change the global policy and get the RIRs returning the /12 to IANA, and make a new default allocation. I think this is a ridiculous discussion. /48 should be the default and in fact never APNIC and ARIN should have gone to the /56. RFC3177 is clear. I remember when I was accused about trying to go against the system with the ULA-C thing, however we go against the system with all this, because the system is /48, according to RFC3177. And even if the RFC is not there, is quite logic that /48 is enough for all the cases, and we should not start with barriers or ultra-conservation mind-set as in IPv4. The change in the HD-ratio was perfect enough to get IPv6 for around 480 years if I recall correctly Tony Hain calculation. I'm happy if it last only 100 years, because I'm sure we will have something new by then anyway, for many other reasons than addressing space. LIRs/ISPs should provide a /48 to all customers, no justification, no extra cost. The value of the service must come from other applications and services still to come, but they will never come if we fall again into the ultra-conservation thing. Regards, Jordi > De: Iljitsch van Beijnum > Responder a: > Fecha: Thu, 23 Aug 2007 15:08:51 +0200 > Para: Leo Bicknell > CC: > Asunto: Re: [ppml] Policy Proposal: IPv6 Assignment Guidelines > > On 23-aug-2007, at 3:44, Leo Bicknell wrote: > >> Would you support my "Straw Man #2", reproduced here for your >> convenience? > >> ] LIR's may assign up to a /48 to an End Site. End Sites requiring >> ] more address space than a /48 may be assigned a larger block >> provided >> ] the utilization inside that block meets an HD Ratio of 0.94. > > I'm not sure how that works. Do I need to use 33000 subnets in a /48 > (that's about a HD ratio of 0.94) before I can get a /47? Or do I > need to submit a plan for 456000 subnets to get a /44? But 456000 > subnets will also fit in a /45, so why the extra bit? > _______________________________________________ > 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. ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From bicknell at ufp.org Thu Aug 23 10:03:46 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 23 Aug 2007 10:03:46 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <726B6616-E652-49F7-B4C9-2BAEC71A985E@muada.com> References: <46C5E72F.2080903@arin.net> <20070823014455.GA39561@ussenterprise.ufp.org> <726B6616-E652-49F7-B4C9-2BAEC71A985E@muada.com> Message-ID: <20070823140346.GA91781@ussenterprise.ufp.org> In a message written on Thu, Aug 23, 2007 at 03:08:51PM +0200, Iljitsch van Beijnum wrote: > On 23-aug-2007, at 3:44, Leo Bicknell wrote: > >Would you support my "Straw Man #2", reproduced here for your > >convenience? > > >] LIR's may assign up to a /48 to an End Site. End Sites requiring > >] more address space than a /48 may be assigned a larger block > >provided > >] the utilization inside that block meets an HD Ratio of 0.94. > > I'm not sure how that works. Do I need to use 33000 subnets in a /48 > (that's about a HD ratio of 0.94) before I can get a /47? Or do I > need to submit a plan for 456000 subnets to get a /44? But 456000 > subnets will also fit in a /45, so why the extra bit? HD Ratio is defined in section 6.2.8: http://www.arin.net/policy/nrpm.html#six28 I've created a little table, I presume ARIN would make such a table available on the web site for easy reference. In A In Use Out of To Get /48 33,689 65,536 /47 /47 64,634 131,072 /46 /46 124,002 252,144 /45 I could go on, but we're now talking about a single site, getting PA space from a provider with over 100,000 subnets. That seems, unlikely. However, should it occur, the foruma works. Also, why the extra bit, we've decided with HD Ratio that as you get larger you should have some extra bits here and there to allow you to allocate efficiently internally, so it's more likely you'll fit in a single block. If you're worried about that, this is not the place to worry. Going from a /45 to a /44, inside of a PA block that's nicely aggregated is not such a big deal. Going from a /32 to a /19 due to the effects of HD ratio on larger providers is probably a better place to start. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From bicknell at ufp.org Thu Aug 23 10:05:49 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 23 Aug 2007 10:05:49 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: References: <726B6616-E652-49F7-B4C9-2BAEC71A985E@muada.com> Message-ID: <20070823140549.GB91781@ussenterprise.ufp.org> In a message written on Thu, Aug 23, 2007 at 03:55:20PM +0200, JORDI PALET MARTINEZ wrote: > I think this is a ridiculous discussion. /48 should be the default and in > fact never APNIC and ARIN should have gone to the /56. RFC3177 is clear. [snip] > LIRs/ISPs should provide a /48 to all customers, no justification, no extra > cost. The value of the service must come from other applications and > services still to come, but they will never come if we fall again into the > ultra-conservation thing. My straw man #2 does exactly that, sets a /48 as the "no justification" size. It also provides a mechanism for people who don't fit in a /48 to get a /47, /46, etc by using the HD Ratio. It would seem you would be in violent agreement, but from your message I get the impression you are not. Why? -- 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 jordi.palet at consulintel.es Thu Aug 23 10:16:00 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 23 Aug 2007 16:16:00 +0200 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <20070823140549.GB91781@ussenterprise.ufp.org> Message-ID: I didn't read all the messages in depth ... So probably got it wrong or replied to the wrong one, sorry :-( So yes, I will agree in /48, no justification, and using the HD-ratio for something bigger. I'm presuming that the measurement of the LIR allocation (/32 or whatever) will be based on the assignment to the end-users of /48, otherwise, the LIR/ISP should not meet the criteria for getting an allocation. Regards, Jordi > De: Leo Bicknell > Organizaci?n: United Federation of Planets > Responder a: > Fecha: Thu, 23 Aug 2007 10:05:49 -0400 > Para: > Asunto: Re: [ppml] Policy Proposal: IPv6 Assignment Guidelines > > In a message written on Thu, Aug 23, 2007 at 03:55:20PM +0200, JORDI PALET > MARTINEZ wrote: >> I think this is a ridiculous discussion. /48 should be the default and in >> fact never APNIC and ARIN should have gone to the /56. RFC3177 is clear. > [snip] >> LIRs/ISPs should provide a /48 to all customers, no justification, no extra >> cost. The value of the service must come from other applications and >> services still to come, but they will never come if we fall again into the >> ultra-conservation thing. > > My straw man #2 does exactly that, sets a /48 as the "no justification" > size. It also provides a mechanism for people who don't fit in a > /48 to get a /47, /46, etc by using the HD Ratio. > > It would seem you would be in violent agreement, but from your message I > get the impression you are not. Why? > > -- > 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 > _______________________________________________ > 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. ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From Ed.Lewis at neustar.biz Thu Aug 23 10:14:02 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 23 Aug 2007 10:14:02 -0400 Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) In-Reply-To: <3F24C835-98E8-4AF2-8B9F-3BB69E700AB1@virtualized.org> References: <454810F09B5AA04E9D78D13A5C39028A02A4C89F@nyrofcs2ke2k01.corp.pvt> <44BC5A2D-C8D1-4469-907B-B5AE6986C552@virtualized.org> <20070822235443.GN28312@shell01.cell.sv2.tellme.com> <3F24C835-98E8-4AF2-8B9F-3BB69E700AB1@virtualized.org> Message-ID: At 17:44 -0700 8/22/07, David Conrad wrote: >David, > >On Aug 22, 2007, at 4:54 PM, David Williamson wrote: >> This may sound horribly cynical, but do you think governments will >> sufficiently understand the problem and then be able to take any sort >> of meaningful action before The End? > >I'll see your cynicism and raise you. Since when does understanding >preclude governmental action? :-) A not so cynical question - has any government officially expressed any concerns about the IPv4 situation? I mean, is the concern over how governments will see this a "boogey man" (http://en.wikipedia.org/wiki/Boogey_man) or a concrete concern? Will the status of the RIR system be strengthened if there is a plan or if the situation is allowed to run its course as is? I.e., how important is it that at least one of the IPv4 run-out proposals make it through the Policy Development Process to implementation? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. From Ed.Lewis at neustar.biz Thu Aug 23 10:24:43 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 23 Aug 2007 10:24:43 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <20070823014455.GA39561@ussenterprise.ufp.org> References: <46C5E72F.2080903@arin.net> <20070823014455.GA39561@ussenterprise.ufp.org> Message-ID: At 21:44 -0400 8/22/07, Leo Bicknell wrote: >] LIR's may assign up to a /48 to an End Site. End Sites requiring From my experience seeing policies generated, I think that no policy should proscribe what an LIR can/may or cannot/may not do in the manner suggested above. "Assignments by LIRs no larger than /48 will not be reviewed by ARIN. Assignments greater than /48 will be reviewed to see if the additional space is warranted according to the 0.94 HD ratio policy. If the space is not warranted, ARIN will consider the excess space to be available for a different assignment, lowering the overall utilization score of the LIR." Yes, maybe I am twisting words and that is all, but the focus of the policy should be on utilization measurement and not on the provisioning activity. We should allow an LIR to be able to hold some /48's in reserve to accommodate expansion when they feel a particular customer might grow. (I am not assuming that LIR == ISP.) We want to leave that to the LIR as they better know the user of the space than ARIN. Such reserves will have to be subjectively accepted by ARIN staff when calculating the HD ration. I want to leave that to the discretion of the staff. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. From bjohnson at drtel.com Thu Aug 23 10:37:28 2007 From: bjohnson at drtel.com (Brian Johnson) Date: Thu, 23 Aug 2007 09:37:28 -0500 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: References: <46C5E72F.2080903@arin.net> Message-ID: <29A54911243620478FF59F00EBB12F47B39560@ex01.drtel.lan> > > because this is > > large enough to accommodate a fairly big home network (I have > > 5 Cisco routers and 2 wifi base stations in my house and > > never used more than 4 subnets) but small enough that people > > won't be tempted to cram a corporate network in it, only to > > grow out of it anyway and needing a rather painful > > renumbering operation (which would be a significant risk with > > assigning /56s). > > And there is a prime example of why a /56 for consumers only, will not > create problems. It is exceedingly rare for a private home or apartment > to turn into a business. For the very, very few who do this, there may > be some pain, but that does not warrant a change in the public policy. > Since there is no penalty to ISPs for assigning a /48 to a home user, > anyone who anticipates building a corporate network in their basement > or > spare bedroom, should ask their ISP for a /48. Problem solved. > Couldn't NAT be used as a band-aid in this situation? - Brian Johnson From michael.dillon at bt.com Thu Aug 23 10:49:21 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 23 Aug 2007 15:49:21 +0100 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <20070823140346.GA91781@ussenterprise.ufp.org> References: <46C5E72F.2080903@arin.net><20070823014455.GA39561@ussenterprise.ufp.org><726B6616-E652-49F7-B4C9-2BAEC71A985E@muada.com> <20070823140346.GA91781@ussenterprise.ufp.org> Message-ID: > Also, why the extra bit, we've decided with HD Ratio that as > you get larger you should have some extra bits here and there > to allow you to allocate efficiently internally, so it's more > likely you'll fit in a single block. If you're worried about > that, this is not the place to worry. Going from a /45 to a > /44, inside of a PA block that's nicely aggregated is not > such a big deal. Going from a /32 to a /19 due to the > effects of HD ratio on larger providers is probably a better > place to start. These skinflint measures just go against the grain. IPv6 was designed so that everyone, except the largest ISPs, gets more addresses than they could ever possibly need. That is so that everyone, except the largest ISPs, never needs to go back to their address provider for more addresses. That means that everyone, has spare subnets to carve off a few for some special project such as an in-law apartment. Additionally, IPv6 was designed so that everyone, except a few of the largest (and unusual) cases, gets the same size of allocation. When ARIN and APNIC went to /56 for consumer subscribers (homes and apartments) that didn't change this principle, just added another class of installation that is fairly clearly defined in the real world. The unusual exceptions are very large ISPs who might need a /20, not a /32. And a few campus-type end-user sites with lots of IT infrastructure that might need *TWO* /48s instead of one. I leave off data centers because I expect them to get a /32 and hand out a /48 to every customer, or maybe every rack. It is *NOT* wasteful to give an IPv6 installation more addresses than they will ever use. That is, in fact, by design. It allows any point in the network to maintain a surplus of unused subnets so that this point in the network can be expanded *WITHOUT RENUMBERING OR RESTRUCTURING* of the surrounding network. HD ratios have one useful purpose, and only one. That is to place a limit on the very largest ISPs who ask for more than one /32 allocation. It is there to prevent people from going wild, otherwise 20 of the world's largest providers could all make plans to server 25% of the world's population and all request far more /32s than they could ever use. In fact, there is no guarantee that the HD ratio rules will *EVER* be applied. Once IPv6 really kicks off (and it is starting to appear in RFPs with increasing frequency), people will get real-world experience with deployment, and I fully expect ISPs to change the RIR policies before anybody exhausts their first IPv6 allocation. --Michael Dillon From bicknell at ufp.org Thu Aug 23 10:52:22 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 23 Aug 2007 10:52:22 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: References: <46C5E72F.2080903@arin.net> <20070823014455.GA39561@ussenterprise.ufp.org> Message-ID: <20070823145222.GC97150@ussenterprise.ufp.org> In a message written on Thu, Aug 23, 2007 at 10:24:43AM -0400, Edward Lewis wrote: > "Assignments by LIRs no larger than /48 will not be reviewed by ARIN. > Assignments greater than /48 will be reviewed to see if the > additional space is warranted according to the 0.94 HD ratio policy. > If the space is not warranted, ARIN will consider the excess space to > be available for a different assignment, lowering the overall > utilization score of the LIR." I find the paragraph above to be identical in result to my straw man #2 proposal. I would not object to using this language; particularly if it results in more consensus. > We should allow an LIR to be able to hold some /48's in reserve to > accommodate expansion when they feel a particular customer might > grow. (I am not assuming that LIR == ISP.) We want to leave that to > the LIR as they better know the user of the space than ARIN. Such > reserves will have to be subjectively accepted by ARIN staff when > calculating the HD ration. I want to leave that to the discretion of > the staff. I believe regardless of the size of allocation from LIR -> End Site the HD Ratio allows the LIR to hold some /48's in reserve. I personally belive the two issues are completely unrelated. -- 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 Lee.Howard at stanleyassociates.com Thu Aug 23 10:59:06 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 23 Aug 2007 10:59:06 -0400 Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) In-Reply-To: Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB406C0D97D@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Edward Lewis > > A not so cynical question - has any government officially > expressed any concerns about the IPv4 situation? Many governments (or parts) have issued papers or orders calling for a transition to IPv6. Japan was an early leader, but you can search for any country and "IPv6" on Google and find something. The UN's Internet Governance Forum meeting #2 will apparently be holding workshops that may be relevant. Several governments have suggested that the ITU would be a better place for numbers and names to be managed that the current registries. If you read through the comments at http://www.intgovforum.org/Comments_draft_prog_Rio.html you find that several governments have concerns about the current Internet "governance" structures. I haven't found any direct messages from government agencies predicting the death of the Internet, but then I wouldn't expect to. Public servants are paying attention when it's their job to, but elected politicians aren't, much, yet. While fearmongering can by politically useful, causing panic (especially around business infrastructure) generally isn't, and is not the decision of civil servants. > I.e., how important is it that at least one of the IPv4 > run-out proposals make it through the Policy Development > Process to implementation? I think everyone should support or oppose policies as they believe is best for the Internet. I have great confidence in this community to apply experience and understanding to come to consensus around good policies. Keep doing that, and it's harder to argue that the current system doesn't work. Lee From raul at lacnic.net Thu Aug 23 11:01:33 2007 From: raul at lacnic.net (Raul Echeberria) Date: Thu, 23 Aug 2007 12:01:33 -0300 Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) In-Reply-To: References: <454810F09B5AA04E9D78D13A5C39028A02A4C89F@nyrofcs2ke2k01.corp.pvt> <44BC5A2D-C8D1-4469-907B-B5AE6986C552@virtualized.org> <20070822235443.GN28312@shell01.cell.sv2.tellme.com> <3F24C835-98E8-4AF2-8B9F-3BB69E700AB1@virtualized.org> Message-ID: <7.0.1.0.1.20070823115641.058ff1a8@lacnic.net> At 11:14 a.m. 23/08/2007, Edward Lewis wrote: >At 17:44 -0700 8/22/07, David Conrad wrote: > >David, > > > >On Aug 22, 2007, at 4:54 PM, David Williamson wrote: > >> This may sound horribly cynical, but do you think governments will > >> sufficiently understand the problem and then be able to take any sort > >> of meaningful action before The End? > > > >I'll see your cynicism and raise you. Since when does understanding > >preclude governmental action? :-) > >A not so cynical question - has any government officially expressed >any concerns about the IPv4 situation? I don't know how to define officially. But it was an issue that was addressed many times during the work of the Working Group on Internet Governance. Beside that, it has been an usual topic in many inter-governmental forums in the last year or so. I.e. the GAC of ICANN, in which the issue has been in the agenda since the Marrakesh meeting in 2006, but also in many other forums. I think that some governmnets are following this issue very closely. Is there any concrete proposal?. No yet, and I hope that it continues in this way. But in depends on what we do. Ra?l From raul at lacnic.net Thu Aug 23 11:04:26 2007 From: raul at lacnic.net (Raul Echeberria) Date: Thu, 23 Aug 2007 12:04:26 -0300 Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) In-Reply-To: <20070822235443.GN28312@shell01.cell.sv2.tellme.com> References: <454810F09B5AA04E9D78D13A5C39028A02A4C89F@nyrofcs2ke2k01.corp.pvt> <44BC5A2D-C8D1-4469-907B-B5AE6986C552@virtualized.org> <20070822235443.GN28312@shell01.cell.sv2.tellme.com> Message-ID: <7.0.1.0.1.20070823120156.0590efd8@lacnic.net> At 08:54 p.m. 22/08/2007, David Williamson wrote: >On Wed, Aug 22, 2007 at 04:44:44PM -0700, David Conrad wrote: > > > -Let it run out. > > > > An understandable position to take. I'll admit I am somewhat > > skeptical that governments around the world will be willing to accept > > this approach. > >This may sound horribly cynical, but do you think governments will >sufficiently understand the problem The answer to this part of the question is "I don't know, but it doesn't matter" >and then be able to take any sort >of meaningful action before The End? The answer to this part of the question, IMHO, is "certainly, yes". Ra?l From llynch at civil-tongue.net Thu Aug 23 11:16:15 2007 From: llynch at civil-tongue.net (Lucy Lynch) Date: Thu, 23 Aug 2007 08:16:15 -0700 (PDT) Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) In-Reply-To: References: <454810F09B5AA04E9D78D13A5C39028A02A4C89F@nyrofcs2ke2k01.corp.pvt> <44BC5A2D-C8D1-4469-907B-B5AE6986C552@virtualized.org> <20070822235443.GN28312@shell01.cell.sv2.tellme.com> <3F24C835-98E8-4AF2-8B9F-3BB69E700AB1@virtualized.org> Message-ID: <20070823080735.M43894@hiroshima.bogus.com> On Thu, 23 Aug 2007, Edward Lewis wrote: > At 17:44 -0700 8/22/07, David Conrad wrote: >> David, >> >> On Aug 22, 2007, at 4:54 PM, David Williamson wrote: >>> This may sound horribly cynical, but do you think governments will >>> sufficiently understand the problem and then be able to take any sort >>> of meaningful action before The End? >> >> I'll see your cynicism and raise you. Since when does understanding >> preclude governmental action? :-) > > A not so cynical question - has any government officially expressed > any concerns about the IPv4 situation? I mean, is the concern over > how governments will see this a "boogey man" > (http://en.wikipedia.org/wiki/Boogey_man) or a concrete concern? > Will the status of the RIR system be strengthened if there is a plan > or if the situation is allowed to run its course as is? not government - governments - see for example: The Internet Governance Forum (IGF) IPv4 depletion, transitioning to IPv6 http://info.intgovforum.org/yoppy.php?poj=59 The list of workshop topics for OGF Rio can be found here: http://info.intgovforum.org/wsl3.php?listy=CIR - lucy > I.e., how important is it that at least one of the IPv4 run-out > proposals make it through the Policy Development Process to > implementation? > From owen at delong.com Thu Aug 23 11:18:24 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 23 Aug 2007 08:18:24 -0700 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: References: <46CCCBF8.8010300@internap.com> Message-ID: <412AF3C3-54F9-492D-A54B-FDB19ECD3F37@delong.com> On Aug 23, 2007, at 6:06 AM, wrote: > >> I think your both naieve to think that your typical corporate >> customer with a couple hundred nodes and no redundancy to the >> Internet is going to put up with being told he has to >> renumber his entire internal network when he decides his >> current ISP is a chuckhead and decides to go to a competitor. > > Perhaps you haven't read RFC 4192? It is not necessary to renumber the > entire internal network to change ISPs. A lot of the number changing > happens automatically, because both ISPs assign a /48 prefix. All > interface addresses are unchanged, only the prefix changes. And > this is > accomplished in a two step process where you begin by adding a second > prefix, which results in all interfaces having at least 2 IPv6 > addresses. The process is not entirely painless, but it is far less > work > than with IPv4. > While the technical description is accurate, the consequences and the relative pain computation are myth. In any reasonably run enterprise, the majority of these addresses are handed out via DHCP, so, renumbering end hosts for the most part is irrelevant. The ones that are tend to be servers and can accommodate a second IPv4 address in most cases and the same scenario can apply for the most part. The real pain in renumbering, both IPv4 and IPv6 is the number of configuration files where your addresses appear that you do not control. This includes vendor, client, and partner VPN setups, holes punched in vendor, client, and partner firewalls, etc. This pain is identical in IPv4 and IPv6. Owen From info at arin.net Thu Aug 23 11:30:58 2007 From: info at arin.net (Member Services) Date: Thu, 23 Aug 2007 11:30:58 -0400 Subject: [ppml] Policy Proposal: ISP to LIR Clarification - version 1.1 In-Reply-To: <46C5E745.5050708@arin.net> References: <46C5E745.5050708@arin.net> Message-ID: <46CDA832.7030709@arin.net> The author submitted a revised version of their proposal. Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: ISP to LIR Clarification Author: Leo Bicknell Proposal Version: 1.1 Submission Date: 8/22/2007 Proposal type: modify Policy term: permanent Policy statement: Replace all instances of the word "ISP" in the NRPM with the word "LIR" and replace all instances of the phrase "LIR/ISP" with "LIR", except for the following: * Leave section 2.4 unchanged. * Leave section 2.7 unchanged. * In section 4.1.1, replace "ISPs" with "requesters". * In section 4.2.1.1, also remove "Internet Service Providers". * Leave section 6.2.4 unchanged. * Leave section 6.3.4 unchanged. * In section 6.9, replace "ISPs and LIRs" with "LIRs" for all three occurrence. Rationale: The NRPM is inconsistent. The terms ISP and LIR are used interchangeably throughout the document, with the term ISP being predominant in the IPv4 sections and the term LIR being predominant in the IPv6 sections. The use of the term ISP poses two different problems: 1) The term has meaning outside of ARIN's policy. Multiple discussions on PPML have degenerated over people arguing what an ISP is with regards to policy when the reality is that the relationship is defined in the NRPM. As LIR has no meaning outside of policy this confusion will be removed. 2) The other four RIRs have standardized on LIR. This change will make it easier for those doing business with more than one LIR to use consistent terms. This change does not alter any policy, it merely makes the policy easier to understand. Timetable for implementation: immediate 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: ISP to LIR Clarification > > Author: Leo Bicknell > > Proposal Version: 1.0 > > Submission Date: 8/17/2007 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Replace all instances of the word "ISP" in the NRPM with the word "LIR" > and replace all instances of the phrase "LIR/ISP" with "LIR", except for > the following: > > * Leave section 2.4 unchanged. > * Leave section 2.7 unchanged. > * In section 4.1.1, replace "ISPs" with "requesters". > * In section 4.2, also remove "Internet Service Providers". > * Leave section 6.2.4 unchanged. > * Leave section 6.3.4 unchanged. > * In section 6.9, replace "ISPs and LIRs" with "LIRs" for all three > occurrence. > > Rationale: > > The NRPM is inconsistent. The terms ISP and LIR are used > interchangeably throughout the document, with the term ISP being > predominant in the IPv4 sections and the term LIR being predominant in > the IPv6 sections. > > The use of the term ISP poses two different problems: > > 1) The term has meaning outside of ARIN's policy. Multiple discussions > on PPML have degenerated over people arguing what an ISP is with > regards to policy when the reality is that the relationship is > defined in the NRPM. As LIR has no meaning outside of policy > this confusion will be removed. > > 2) The other four RIRs have standardized on LIR. This change will make > it easier for those doing business with more than one LIR to use > consistent terms. > > This change does not alter any policy, it merely makes the policy easier > to understand. > > 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 bicknell at ufp.org Thu Aug 23 12:41:58 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 23 Aug 2007 12:41:58 -0400 Subject: [ppml] Policy Proposal: ISP to LIR Clarification - version 1.1 In-Reply-To: <46CDA832.7030709@arin.net> References: <46C5E745.5050708@arin.net> <46CDA832.7030709@arin.net> Message-ID: <20070823164158.GA5582@ussenterprise.ufp.org> It may not be immeidately obvious, but the only change is section number 4.2 -> 4.2.1.1, where I had made an error in writing down the section number. In a message written on Thu, Aug 23, 2007 at 11:30:58AM -0400, Member Services wrote: > The author submitted a revised version of their proposal. > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: ISP to LIR Clarification > > Author: Leo Bicknell > > Proposal Version: 1.1 > > Submission Date: 8/22/2007 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Replace all instances of the word "ISP" in the NRPM with the word > "LIR" and replace all instances of the phrase "LIR/ISP" with "LIR", > except for the following: > > * Leave section 2.4 unchanged. > * Leave section 2.7 unchanged. > * In section 4.1.1, replace "ISPs" with "requesters". > * In section 4.2.1.1, also remove "Internet Service Providers". > * Leave section 6.2.4 unchanged. > * Leave section 6.3.4 unchanged. > * In section 6.9, replace "ISPs and LIRs" with "LIRs" for all three > occurrence. > > Rationale: > > The NRPM is inconsistent. The terms ISP and LIR are used interchangeably > throughout the document, with the term ISP being predominant in the > IPv4 sections and the term LIR being predominant in the IPv6 sections. > > The use of the term ISP poses two different problems: > > 1) The term has meaning outside of ARIN's policy. Multiple discussions > on PPML have degenerated over people arguing what an ISP is with > regards to policy when the reality is that the relationship is > defined in the NRPM. As LIR has no meaning outside of policy > this confusion will be removed. > > 2) The other four RIRs have standardized on LIR. This change will make > it easier for those doing business with more than one LIR to use > consistent terms. > > This change does not alter any policy, it merely makes the policy easier > to understand. > > Timetable for implementation: immediate > > > > > 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: ISP to LIR Clarification > > > > Author: Leo Bicknell > > > > Proposal Version: 1.0 > > > > Submission Date: 8/17/2007 > > > > Proposal type: modify > > > > Policy term: permanent > > > > Policy statement: > > > > Replace all instances of the word "ISP" in the NRPM with the word "LIR" > > and replace all instances of the phrase "LIR/ISP" with "LIR", except for > > the following: > > > > * Leave section 2.4 unchanged. > > * Leave section 2.7 unchanged. > > * In section 4.1.1, replace "ISPs" with "requesters". > > * In section 4.2, also remove "Internet Service Providers". > > * Leave section 6.2.4 unchanged. > > * Leave section 6.3.4 unchanged. > > * In section 6.9, replace "ISPs and LIRs" with "LIRs" for all three > > occurrence. > > > > Rationale: > > > > The NRPM is inconsistent. The terms ISP and LIR are used > > interchangeably throughout the document, with the term ISP being > > predominant in the IPv4 sections and the term LIR being predominant in > > the IPv6 sections. > > > > The use of the term ISP poses two different problems: > > > > 1) The term has meaning outside of ARIN's policy. Multiple discussions > > on PPML have degenerated over people arguing what an ISP is with > > regards to policy when the reality is that the relationship is > > defined in the NRPM. As LIR has no meaning outside of policy > > this confusion will be removed. > > > > 2) The other four RIRs have standardized on LIR. This change will make > > it easier for those doing business with more than one LIR to use > > consistent terms. > > > > This change does not alter any policy, it merely makes the policy easier > > to understand. > > > > 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. > > > > > _______________________________________________ > 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. -- 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 marla.azinger at frontiercorp.com Thu Aug 23 12:56:45 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Thu, 23 Aug 2007 12:56:45 -0400 Subject: [ppml] Policy Proposal: ISP to LIR Clarification - version 1.1 Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4C8C0@nyrofcs2ke2k01.corp.pvt> Hey Leo- What about 4.2 itself? The title on that line is is "allocations to ISP's". Or did you somehow address that in a different way? That is why I suggested adding the change of 4.2.1.1 and not removing 4.2. You need to change both lines. -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Leo Bicknell Sent: Thursday, August 23, 2007 9:42 AM To: ppml at arin.net Subject: Re: [ppml] Policy Proposal: ISP to LIR Clarification - version 1.1 It may not be immeidately obvious, but the only change is section number 4.2 -> 4.2.1.1, where I had made an error in writing down the section number. In a message written on Thu, Aug 23, 2007 at 11:30:58AM -0400, Member Services wrote: > The author submitted a revised version of their proposal. > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: ISP to LIR Clarification > > Author: Leo Bicknell > > Proposal Version: 1.1 > > Submission Date: 8/22/2007 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Replace all instances of the word "ISP" in the NRPM with the word > "LIR" and replace all instances of the phrase "LIR/ISP" with "LIR", > except for the following: > > * Leave section 2.4 unchanged. > * Leave section 2.7 unchanged. > * In section 4.1.1, replace "ISPs" with "requesters". > * In section 4.2.1.1, also remove "Internet Service Providers". > * Leave section 6.2.4 unchanged. > * Leave section 6.3.4 unchanged. > * In section 6.9, replace "ISPs and LIRs" with "LIRs" for all three > occurrence. > > Rationale: > > The NRPM is inconsistent. The terms ISP and LIR are used interchangeably > throughout the document, with the term ISP being predominant in the > IPv4 sections and the term LIR being predominant in the IPv6 sections. > > The use of the term ISP poses two different problems: > > 1) The term has meaning outside of ARIN's policy. Multiple discussions > on PPML have degenerated over people arguing what an ISP is with > regards to policy when the reality is that the relationship is > defined in the NRPM. As LIR has no meaning outside of policy > this confusion will be removed. > > 2) The other four RIRs have standardized on LIR. This change will make > it easier for those doing business with more than one LIR to use > consistent terms. > > This change does not alter any policy, it merely makes the policy easier > to understand. > > Timetable for implementation: immediate > > > > > 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: ISP to LIR Clarification > > > > Author: Leo Bicknell > > > > Proposal Version: 1.0 > > > > Submission Date: 8/17/2007 > > > > Proposal type: modify > > > > Policy term: permanent > > > > Policy statement: > > > > Replace all instances of the word "ISP" in the NRPM with the word "LIR" > > and replace all instances of the phrase "LIR/ISP" with "LIR", except for > > the following: > > > > * Leave section 2.4 unchanged. > > * Leave section 2.7 unchanged. > > * In section 4.1.1, replace "ISPs" with "requesters". > > * In section 4.2, also remove "Internet Service Providers". > > * Leave section 6.2.4 unchanged. > > * Leave section 6.3.4 unchanged. > > * In section 6.9, replace "ISPs and LIRs" with "LIRs" for all three > > occurrence. > > > > Rationale: > > > > The NRPM is inconsistent. The terms ISP and LIR are used > > interchangeably throughout the document, with the term ISP being > > predominant in the IPv4 sections and the term LIR being predominant in > > the IPv6 sections. > > > > The use of the term ISP poses two different problems: > > > > 1) The term has meaning outside of ARIN's policy. Multiple discussions > > on PPML have degenerated over people arguing what an ISP is with > > regards to policy when the reality is that the relationship is > > defined in the NRPM. As LIR has no meaning outside of policy > > this confusion will be removed. > > > > 2) The other four RIRs have standardized on LIR. This change will make > > it easier for those doing business with more than one LIR to use > > consistent terms. > > > > This change does not alter any policy, it merely makes the policy easier > > to understand. > > > > 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. > > > > > _______________________________________________ > 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. -- 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 From dean at av8.com Thu Aug 23 14:40:57 2007 From: dean at av8.com (Dean Anderson) Date: Thu, 23 Aug 2007 14:40:57 -0400 (EDT) Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing ofIPv4 IP Addresses In-Reply-To: Message-ID: Two messages, inline --Dean On Wed, 22 Aug 2007 michael.dillon at bt.com wrote: > > So, now ARIN can't do math? > > Sorry but no. ARIN is a corporation and last time I looked, corporations > can't do math. Only people with an education in mathematics can do math. > And since this is the ARIN *PUBLIC* policy mailing list, where a > mathematics education is *NOT* a prerequisite, math is rather out of > place. This is absurd. > A while back, I proposed an ARIN policy that involved logarithms. And, apparently, hypocritical. On Wed, 22 Aug 2007, Michael K. Smith - Adhost wrote: > If we were trying to write policies for a set of engineers then > mathematical equations would be justified. Networks are designed by engineers. Engineers should understand math. > However, what I think we're trying to do is write policies that are > understandable and implementable by ARIN's user base. The user base doesn't implement the policies. ARIN does. > As some Physics professor somewhere said, "if you can't explain it to > an 8 year old then you don't understand it." :-) Yes. And I do have a book on Calculus for 7 year olds: http://www.amazon.com/Calculus-Young-People-Ages-Yes/dp/096216741X If a 7 year old can understand it, I'm sure that both you and ARIN can. ;-) --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From dean at av8.com Thu Aug 23 14:43:19 2007 From: dean at av8.com (Dean Anderson) Date: Thu, 23 Aug 2007 14:43:19 -0400 (EDT) Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: <2C3CB56F-1829-4BF3-B9A9-C04B159A293A@muada.com> Message-ID: On Thu, 23 Aug 2007, Iljitsch van Beijnum wrote: > > The main reason is because its premise is flawed: the policy supposes > that making sure we don't run out of IPv4 address space the next 10 > years is better than the situation where we do run out. I find it curious that people think that the effect of rationing (a temporary stop) is somehow worse than a permanent stop. > However, addresses that sit in the ARIN warehouse unused don't do the > community any good, while more stringent rules are harmful, because > they make new deployments harder, take longer, and increase risks. So you think we shouldn't turn down any request ever? All requests should be fullfilled under that notion. Obviously, we are already turning down requests. > Also, the policy doesn't describe a workable practice for the ARIN > staff. What if 8 requests come in, 4 for 1 million addresses and 4 > for 250000, and the current rationing is for 4 million? Do 4 people > get their million and the 4 others get nothing? Or 7 get everything > and one gets nothing? Or they all get 80%? In that case, the people > who need 250000 will obviously ask for 400000 so they get 285000 but > the big ones only get 700000. Or do the small ones get everything > they ask for and the big ones only 75%? This happens whether rationing occurs or not, because exactly the same thing happens when there are only 4 million addresses left. There is no change by rationing. We just repeat the same process with temporary stops. Under the current policy, the first to get their paperwork in order will be served. > If you only get a percentage of the address space you need, this is > nearly as harmful as not getting anything at all. But __Less__ harmful. > And the benefits of gaming the system increase astronomically, so > "address request fraud" will become much more common. But this happens anyway, rationing or not rationing. Hoarding isn't caused by rationing, its caused by resource exhaustion. However, rationing helps fight hoarding because they have to come back and show actual usage. > As I said, rationing IPv4 addresses is a bad idea. But if the > community wants to do it, there are better ways. Without an alternative proposal, its pretty hard to suppose there are better ways. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From info at arin.net Thu Aug 23 14:56:00 2007 From: info at arin.net (Member Services) Date: Thu, 23 Aug 2007 14:56:00 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 In-Reply-To: <46C5E72F.2080903@arin.net> References: <46C5E72F.2080903@arin.net> Message-ID: <46CDD840.1050001@arin.net> The author submitted a revised version of their proposal. Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv6 Assignment Guidelines Author: Leo Bicknell and Ed Lewis Proposal Version: 3.0 Submission Date: 8/23/2007 Proposal type: new Policy term: permanent Policy statement: Delete the text in 6.5.4.2 and Replace the text in section 6.5.4.1 with the following text: Assignments by LIRs /48 or smaller will not be reviewed by ARIN. Assignments greater than /48 will be reviewed to see if the additional space is warranted according to the 0.94 HD ratio policy. If the space is not warranted, ARIN will consider the excess space to be available for a different assignment, lowering the overall utilization score of the LIR. Rationale: The existing section 6.5.4.1 does not provide clear guidance on how ARIN should treat prefixes allocated to a site should an ISP come back for additional space in the future. This makes it difficult for LIR's to know if they are allocating in accordance with the rules under which they will be judged in the future. The existing section also provides no guidence on what the LIR or ARIN should do in the case a larger prefix is necessary. Timetable for implementation: immediate 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 Guidelines > > Author: Leo Bicknell > > Proposal Version: 1.0 > > Submission Date: 8/17/2007 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Replace the text in section 6.5.4.1 with the following text: > > LIR's may assign blocks in the range of /48 to /64 to end sites. > All assignments made by LIR's should meet a minimum HD-Ratio of .25. > > * /64 - Site needing only a single subnet. > * /60 - Site with 2-3 subnets initially. > * /56 - Site with 4-7 subnets initially. > * /52 - Site with 8-15 subnets initially. > * /48 - Site with 16+ subnets initially. > > 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. > > LIR's do not need to issue all 5 sizes of prefixes as long as the > HD-Ratio requirement is met. > > Rationale: > > The existing section 6.5.4.1 does not provide clear guidance on how > large of a prefix to allocate to a site. This makes it difficult for > LIR's to know they are in compliance with the rules, and makes it harder > for ARIN staff to evaluate requests per the communities wishes. > > This policy is based on an HD Ratio of .25 for end sites. The following > table may be useful: > > Prefix Size Number of Subnets Required in Use to Meet .25 > ----------- ----------------- --------------------------- > /64 1 1 > /60 16 2 > /56 256 4 > /52 4096 8 > /48 65536 16 > > It is believed this policy provides clear guidance while allowing LIR's > to make generous allocations to their end-sites. > > Timetable for implementation: immediate for new requests, 2 year grace > period for all existing assignments. > > > _______________________________________________ > 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 marla.azinger at frontiercorp.com Thu Aug 23 15:41:15 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Thu, 23 Aug 2007 15:41:15 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 Message-ID: <454810F09B5AA04E9D78D13A5C39028A02A4C8D2@nyrofcs2ke2k01.corp.pvt> I personally didnt have a problem with the first one. But this new version is a better way of accomplishing the goal. And the "how to advice" can be found elsewhere. It might now be a bad idea to take what you previously wrote and have them put that in NPOG as an example of "how to" Cheers! Marla Frontier Communications -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Member Services Sent: Thursday, August 23, 2007 11:56 AM To: ppml at arin.net Subject: Re: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 The author submitted a revised version of their proposal. Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv6 Assignment Guidelines Author: Leo Bicknell and Ed Lewis Proposal Version: 3.0 Submission Date: 8/23/2007 Proposal type: new Policy term: permanent Policy statement: Delete the text in 6.5.4.2 and Replace the text in section 6.5.4.1 with the following text: Assignments by LIRs /48 or smaller will not be reviewed by ARIN. Assignments greater than /48 will be reviewed to see if the additional space is warranted according to the 0.94 HD ratio policy. If the space is not warranted, ARIN will consider the excess space to be available for a different assignment, lowering the overall utilization score of the LIR. Rationale: The existing section 6.5.4.1 does not provide clear guidance on how ARIN should treat prefixes allocated to a site should an ISP come back for additional space in the future. This makes it difficult for LIR's to know if they are allocating in accordance with the rules under which they will be judged in the future. The existing section also provides no guidence on what the LIR or ARIN should do in the case a larger prefix is necessary. Timetable for implementation: immediate 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 Guidelines > > Author: Leo Bicknell > > Proposal Version: 1.0 > > Submission Date: 8/17/2007 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Replace the text in section 6.5.4.1 with the following text: > > LIR's may assign blocks in the range of /48 to /64 to end sites. > All assignments made by LIR's should meet a minimum HD-Ratio of .25. > > * /64 - Site needing only a single subnet. > * /60 - Site with 2-3 subnets initially. > * /56 - Site with 4-7 subnets initially. > * /52 - Site with 8-15 subnets initially. > * /48 - Site with 16+ subnets initially. > > 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. > > LIR's do not need to issue all 5 sizes of prefixes as long as the > HD-Ratio requirement is met. > > Rationale: > > The existing section 6.5.4.1 does not provide clear guidance on how > large of a prefix to allocate to a site. This makes it difficult for > LIR's to know they are in compliance with the rules, and makes it harder > for ARIN staff to evaluate requests per the communities wishes. > > This policy is based on an HD Ratio of .25 for end sites. The following > table may be useful: > > Prefix Size Number of Subnets Required in Use to Meet .25 > ----------- ----------------- --------------------------- > /64 1 1 > /60 16 2 > /56 256 4 > /52 4096 8 > /48 65536 16 > > It is believed this policy provides clear guidance while allowing LIR's > to make generous allocations to their end-sites. > > Timetable for implementation: immediate for new requests, 2 year grace > period for all existing assignments. > > > _______________________________________________ > 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. > _______________________________________________ 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 michael.dillon at bt.com Thu Aug 23 18:22:16 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 23 Aug 2007 23:22:16 +0100 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: <412AF3C3-54F9-492D-A54B-FDB19ECD3F37@delong.com> References: <46CCCBF8.8010300@internap.com> <412AF3C3-54F9-492D-A54B-FDB19ECD3F37@delong.com> Message-ID: > The real pain in renumbering, both IPv4 and IPv6 is the > number of configuration files where your addresses appear > that you do not control. This includes vendor, client, and > partner VPN setups, holes punched in vendor, client, and > partner firewalls, etc. > > This pain is identical in IPv4 and IPv6. Given the very low level of IPv6 deployment in the USA, I wonder how you can so definitively state that IPv6 renumbering pain (cost?) is identical to IPv4. --Michael Dillon From michael.dillon at bt.com Thu Aug 23 18:34:00 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 23 Aug 2007 23:34:00 +0100 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 In-Reply-To: <46CDD840.1050001@arin.net> References: <46C5E72F.2080903@arin.net> <46CDD840.1050001@arin.net> Message-ID: > Delete the text in 6.5.4.2 and Replace the text in section > 6.5.4.1 with the following text: > > Assignments by LIRs /48 or smaller will not be reviewed by ARIN. > Assignments greater than /48 will be reviewed to see if the > additional space is warranted according to the 0.94 HD ratio > policy. If the space is not warranted, ARIN will consider > the excess space to be available for a different assignment, > lowering the overall utilization score of the LIR. This seems to apply to second and subsequent allocations but the language does not clearly tie it into section 6.5.2. And anyhow, it could be years before there is any significant volume of requests for second allocations. Why do we need to waste time on this problem now? For this reason, I am opposed to this policy. Whether current policy is right or wrong is irrelevant, since the magnitude of the wrongness is limited to a minor squeak due to the small number of IPv6 LIR allocations. If a few dozen LIRs come back in the next two years and ask for a second /32 and ARIN rubberstamps the requests, it will do no harm to anyone, even if all of those RIRs have recklessly squandered their first allocation. --Michael Dillon From owen at delong.com Thu Aug 23 18:39:14 2007 From: owen at delong.com (Owen DeLong) Date: Thu, 23 Aug 2007 15:39:14 -0700 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines In-Reply-To: References: <46CCCBF8.8010300@internap.com> <412AF3C3-54F9-492D-A54B-FDB19ECD3F37@delong.com> Message-ID: <18A2D4F4-8E20-4472-8076-0962B1C7D18F@delong.com> On Aug 23, 2007, at 3:22 PM, wrote: >> The real pain in renumbering, both IPv4 and IPv6 is the >> number of configuration files where your addresses appear >> that you do not control. This includes vendor, client, and >> partner VPN setups, holes punched in vendor, client, and >> partner firewalls, etc. >> >> This pain is identical in IPv4 and IPv6. > > Given the very low level of IPv6 deployment in the USA, I wonder > how you > can so definitively state that IPv6 renumbering pain (cost?) is > identical to IPv4. > For the same size of network/organization with the same systems in place and the same number of external partners who have org A's addresses embedded in configuration on devices controlled by Orgs. B, C, D..., the problem space is identical and the solutions are also identical. Given an identical problem with an identical solution, generally, the implementation difficulty can be quantified as also being identical. Cost is only one form of pain. Owen From iljitsch at muada.com Thu Aug 23 18:40:29 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 24 Aug 2007 00:40:29 +0200 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: References: Message-ID: On 23-aug-2007, at 20:43, Dean Anderson wrote: >> The main reason is because its premise is flawed: the policy supposes >> that making sure we don't run out of IPv4 address space the next 10 >> years is better than the situation where we do run out. > I find it curious that people think that the effect of rationing (a > temporary stop) is somehow worse than a permanent stop. Allow me to direct your attention to the "frog in a pot of boiling water" metaphor. If you throw the frog in the water when it's already boiling, the frog immediately jumps out. However, if you put the frog in the water when it's still cool and then slowly increase the temperature, the frog's reflex to avoid heat never kicks in and it's boiled alive. Stretching IPv4 only means that people will delay the move to IPv6, increasing the duration of the non-optimal period where it's hard or impossible to get enough address space. By giving address space out as long as we can we delay the start of this period, by completely running out (well, whatever that means) people are very much encouraged to move to IPv6, bringing the end of the painful period closer. > So you think we shouldn't turn down any request ever? All requests > should be fullfilled under that notion. Obviously, we are already > turning down requests. Well, if this were 1993 that might have been an option, but we've had restrictions for the past decade that seem fairly workable, so let's keep those and not get more severe ones >> Also, the policy doesn't describe a workable practice for the ARIN >> staff. > This happens whether rationing occurs or not, because exactly the same > thing happens when there are only 4 million addresses left. My assumption of what would happen when we run out (in the absense of new policies) is that if a request comes in for more address space than is available, the request is denied A request for a smaller amount of address space that can still be accommodated would be honored. If you want your policy to work like that, you should say that in the proposal. >> And the benefits of gaming the system increase astronomically, so >> "address request fraud" will become much more common. > But this happens anyway, rationing or not rationing. Hoarding isn't > caused by rationing, its caused by resource exhaustion. However, > rationing helps fight hoarding because they have to come back and show > actual usage. With rationing, there are opportunities to try again, with running out, when you're done, you're done. In my opinion, hoarding isn't possible to harmful degrees with simply running out because only the organizations that already use large amounts of address space will be able to get large amounts of address space, so the address space is going to end up with those organizations whether they try to hoard or not. The only issue would be some organizations trying to hoard while others play by the rules. >> As I said, rationing IPv4 addresses is a bad idea. But if the >> community wants to do it, there are better ways. > Without an alternative proposal, its pretty hard to suppose there are > better ways. I don't want to give people bad ideas. :-) From packetgrrl at gmail.com Thu Aug 23 18:54:49 2007 From: packetgrrl at gmail.com (cja@daydream.com) Date: Thu, 23 Aug 2007 16:54:49 -0600 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 In-Reply-To: References: <46C5E72F.2080903@arin.net> <46CDD840.1050001@arin.net> Message-ID: Michael, I disagree. We know that at some point someone will need a subsequent allocation. It may be sooner than we think. Since we know it's going to happen we need to have a policy for it. Further we should try to have the best policies we can regardless of how many allocations are currently being given out. Thanks ----Cathy On 8/23/07, michael.dillon at bt.com wrote: > > > Delete the text in 6.5.4.2 and Replace the text in section > > 6.5.4.1 with the following text: > > > > Assignments by LIRs /48 or smaller will not be reviewed by ARIN. > > Assignments greater than /48 will be reviewed to see if the > > additional space is warranted according to the 0.94 HD ratio > > policy. If the space is not warranted, ARIN will consider > > the excess space to be available for a different assignment, > > lowering the overall utilization score of the LIR. > > This seems to apply to second and subsequent allocations but the > language does not clearly tie it into section 6.5.2. > > And anyhow, it could be years before there is any significant volume of > requests for second allocations. Why do we need to waste time on this > problem now? For this reason, I am opposed to this policy. Whether > current policy is right or wrong is irrelevant, since the magnitude of > the wrongness is limited to a minor squeak due to the small number of > IPv6 LIR allocations. > > If a few dozen LIRs come back in the next two years and ask for a second > /32 and ARIN rubberstamps the requests, it will do no harm to anyone, > even if all of those RIRs have recklessly squandered their first > allocation. > > --Michael Dillon > _______________________________________________ > 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 bicknell at ufp.org Thu Aug 23 19:05:56 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 23 Aug 2007 19:05:56 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 In-Reply-To: References: <46C5E72F.2080903@arin.net> <46CDD840.1050001@arin.net> Message-ID: <20070823230556.GA34993@ussenterprise.ufp.org> In a message written on Thu, Aug 23, 2007 at 11:34:00PM +0100, michael.dillon at bt.com wrote: > And anyhow, it could be years before there is any significant volume of > requests for second allocations. Why do we need to waste time on this > problem now? For this reason, I am opposed to this policy. Whether > current policy is right or wrong is irrelevant, since the magnitude of > the wrongness is limited to a minor squeak due to the small number of > IPv6 LIR allocations. If I had a choice as an LIR of doing something that will make my new request a cake walk in 10 years time, or will require me to go back and renumber 10 years worth of customers to comply, I would much rather do the right thing now. That requires me to know what the right thing is, up front. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From mack at exchange.alphared.com Thu Aug 23 23:09:09 2007 From: mack at exchange.alphared.com (mack) Date: Thu, 23 Aug 2007 22:09:09 -0500 Subject: [ppml] Various IPv6 issues Message-ID: <859D2283FD04CA44986CC058E06598F84B1D9AA527@exchange4.exchange.alphared.local> 1) I oppose allowing blanket allocations of /48s by an LIR. A /48 is close to infinite for practical purposes but is not infinite. I agree with a /56 for 'residential' use and /48 for 'commercial' use. This is basically the current guideline. Residential subnets are likely to be dynamic rather than static for routing aggregation reasons and are unlikely to need more than 256 subnets. Four tiers seems sufficient: /12 RIR /32 LIR /48 'commercial site' /56 'residential site' 2) IPv6 renumbering happens. We need a policy that says a network with X nodes is eligible for a /48 and with Y nodes is eligible for a /32. 3) IPv6 NAT is going to happen. It is going to be one to one rather than one to many which prevents breaking most protocols. ULA-C is not dead yet. Routable ULA-C is no different from PI /48 space. It just puts all of the filterable prefixes in one basket. 4) ARIN seems to be allocating on /29 boundaries to allow expansion while maintaining aggregation. This is a good thing. Obviously gaps can be filled in later if needed. 5) Geographically dispersed organizations will need more than a single /32 if a /32 is the smallest announcement and we do not wish to de-aggregate. Traffic engineering is also going to require either A) a new routing protocol, B) changes to BGP, C) deaggregation or D) multiple /32s. We need some policy with this in mind. Example with two locations, 2 transit providers and a link: Transit1 in location A. Transit2 in location B. Transport between A and B via Layer 2 connection (billed at 95th). Advertising the same prefix in both locations means that traffic from Transit2 will exit only in location B. But may actually be destined for A. The obvious solution is to apply for a second /32. I am not sure how ARIN expects these aspects to be handled. Guidance here would be useful. I am not sure how many companies fall in this category but I would venture to say it is a substantial consideration. -- LR Mack McBride Network Administrator Alpha Red, Inc. From drc at virtualized.org Thu Aug 23 23:28:57 2007 From: drc at virtualized.org (David Conrad) Date: Thu, 23 Aug 2007 20:28:57 -0700 Subject: [ppml] Various IPv6 issues In-Reply-To: <859D2283FD04CA44986CC058E06598F84B1D9AA527@exchange4.exchange.alphared.local> References: <859D2283FD04CA44986CC058E06598F84B1D9AA527@exchange4.exchange.alphared.local> Message-ID: <5E0B6F3C-73CF-4340-A402-C29CC07368FB@virtualized.org> Hi, On Aug 23, 2007, at 8:09 PM, mack wrote: > 4) ARIN seems to be allocating on /29 boundaries to allow expansion > while maintaining aggregation. > This is a good thing. Obviously gaps can be filled in later if > needed. I'm confused. One of the justifications for the allocation of /12s to the RIRs was that the RIRs needed to use "bisection allocation" and they needed an insanely huge pool in order to facilitate this. It does not appear that any of the RIRs are doing this. This isn't a good thing. If an LIR grows beyond a /29, that LIR will now need 2 prefixes. If bisection had been used, ARIN could grow the single prefix. Is how ARIN allocates prefixes to LIRs a policy issue or an operational issue? > Example with two locations, 2 transit providers and a link: > Transit1 in location A. > Transit2 in location B. > Transport between A and B via Layer 2 connection (billed at 95th). > > Advertising the same prefix in both locations means that traffic > from Transit2 will exit only in location B. > But may actually be destined for A. > > The obvious solution is to apply for a second /32. Yep. > I am not sure how ARIN expects these aspects to be handled. I'm not sure this is an ARIN issue. Rather I suspect it is a protocol issue (currently being discussed in the ram at iab.org and rrg at psg.com). Regards, -drc From drc at virtualized.org Fri Aug 24 00:03:30 2007 From: drc at virtualized.org (David Conrad) Date: Thu, 23 Aug 2007 21:03:30 -0700 Subject: [ppml] Various IPv6 issues In-Reply-To: <5E0B6F3C-73CF-4340-A402-C29CC07368FB@virtualized.org> References: <859D2283FD04CA44986CC058E06598F84B1D9AA527@exchange4.exchange.alphared.local> <5E0B6F3C-73CF-4340-A402-C29CC07368FB@virtualized.org> Message-ID: <10549E36-7FDB-488D-800B-853834D2D1BA@virtualized.org> Oops. APNIC is allocating using bisection, but it does not appear the other RIRs are. Apologies to the fine folks at APNIC. Regards, -drc On Aug 23, 2007, at 8:28 PM, David Conrad wrote: > Hi, > > On Aug 23, 2007, at 8:09 PM, mack wrote: >> 4) ARIN seems to be allocating on /29 boundaries to allow expansion >> while maintaining aggregation. >> This is a good thing. Obviously gaps can be filled in later if >> needed. > > I'm confused. > > One of the justifications for the allocation of /12s to the RIRs was > that the RIRs needed to use "bisection allocation" and they needed an > insanely huge pool in order to facilitate this. > > It does not appear that any of the RIRs are doing this. > > This isn't a good thing. If an LIR grows beyond a /29, that LIR will > now need 2 prefixes. If bisection had been used, ARIN could grow the > single prefix. > > Is how ARIN allocates prefixes to LIRs a policy issue or an > operational issue? > >> Example with two locations, 2 transit providers and a link: >> Transit1 in location A. >> Transit2 in location B. >> Transport between A and B via Layer 2 connection (billed at 95th). >> >> Advertising the same prefix in both locations means that traffic >> from Transit2 will exit only in location B. >> But may actually be destined for A. >> >> The obvious solution is to apply for a second /32. > > Yep. > >> I am not sure how ARIN expects these aspects to be handled. > > I'm not sure this is an ARIN issue. Rather I suspect it is a > protocol issue (currently being discussed in the ram at iab.org and > rrg at psg.com). > > Regards, > -drc > > _______________________________________________ > 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 dogwallah at gmail.com Fri Aug 24 00:19:02 2007 From: dogwallah at gmail.com (McTim) Date: Fri, 24 Aug 2007 07:19:02 +0300 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: References: <2C3CB56F-1829-4BF3-B9A9-C04B159A293A@muada.com> Message-ID: On 8/23/07, Dean Anderson wrote: > On Thu, 23 Aug 2007, Iljitsch van Beijnum wrote: > > > > The main reason is because its premise is flawed: the policy supposes > > that making sure we don't run out of IPv4 address space the next 10 > > years is better than the situation where we do run out. > > I find it curious that people think that the effect of rationing (a > temporary stop) is somehow worse than a permanent stop. > > > However, addresses that sit in the ARIN warehouse unused don't do the > > community any good, while more stringent rules are harmful, because > > they make new deployments harder, take longer, and increase risks. > > So you think we shouldn't turn down any request ever? All requests > should be fullfilled under that notion. Obviously, we are already > turning down requests. It's not obvious to me, I don't even think it's happening (for reasons of v4 scarcity). Perhaps RS staff can say if this is the case. -- Cheers, McTim $ whois -h whois.afrinic.net mctim From sleibrand at internap.com Fri Aug 24 01:21:59 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 23 Aug 2007 22:21:59 -0700 Subject: [ppml] Various IPv6 issues In-Reply-To: <859D2283FD04CA44986CC058E06598F84B1D9AA527@exchange4.exchange.alphared.local> References: <859D2283FD04CA44986CC058E06598F84B1D9AA527@exchange4.exchange.alphared.local> Message-ID: <46CE6AF7.7000308@internap.com> mack wrote: > 5) Geographically dispersed organizations will need more than a single /32 if a /32 is the > smallest announcement and we do not wish to de-aggregate. Traffic engineering is also > going to require either A) a new routing protocol, B) changes to BGP, C) deaggregation > or D) multiple /32s. > Deaggregation need not be global... > We need some policy with this in mind. > > Example with two locations, 2 transit providers and a link: > Transit1 in location A. > Transit2 in location B. > Transport between A and B via Layer 2 connection (billed at 95th). > > Advertising the same prefix in both locations means that traffic > from Transit2 will exit only in location B. > But may actually be destined for A. > > The obvious solution is to apply for a second /32. > That's one solution. Another would be to subnet the /32, announce your /32 from both locations, and also announce the subnets, each from its own location. Assuming you pay them to do so, your transit providers will be happy to accept your subnets from you and, importantly, from each other. They may also announce the routes to their peers, who may accept them. If they do, they'll route your traffic optimally the whole way through. If not, then some of the time the traffic will get routed to the wrong transit provider, who will have to hot-potato it off to the correct transit provider via the more-specific subnet. Assuming the two transit providers are relatively peered, this will result in minimal suboptimal routing. To me, that sounds a whole lot easier than designing and implementing a new or improved routing protocol, and a lot more flexible for preventing routing table explosion than giving applicants more space than they need so they can get avoid prefix length filters. -Scott From michael.dillon at bt.com Fri Aug 24 04:38:13 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 24 Aug 2007 09:38:13 +0100 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 In-Reply-To: <20070823230556.GA34993@ussenterprise.ufp.org> References: <46C5E72F.2080903@arin.net> <46CDD840.1050001@arin.net> <20070823230556.GA34993@ussenterprise.ufp.org> Message-ID: > If I had a choice as an LIR of doing something that will make > my new request a cake walk in 10 years time, or will require > me to go back and renumber 10 years worth of customers to > comply, I would much rather do the right thing now. > > That requires me to know what the right thing is, up front. Unfortunately, nobody can know what ARIN policy wil be 10 years from now. Policy is subject to change by the community. However, the IETF is closing their IPv6 working group because they feel that IPv6 is complete. From now on, IPv6 will be in maintenance mode. This means that you can be reasonably certain that the IPv6 addressing architecture will NOT change during the next 10 years. Any ISP that complies with the IPv6 addressing architecture is unlikely to have a problem in 10 years. If the unlikely does happen, and an ISP is unable to get a second allocation in 10 years from now, there is an easy solution. Create a new corporate entity, and have that entity apply for their first allocation. Or go to one of the other RIRs and get a first allocation from them. Or both. ARIN is not the Internet police. And ARIN does not know, and will not know for several years, what is the RIGHT thing to do with IPv6 addressing. --Michael Dillon From michael.dillon at bt.com Fri Aug 24 04:58:14 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 24 Aug 2007 09:58:14 +0100 Subject: [ppml] Various IPv6 issues In-Reply-To: <859D2283FD04CA44986CC058E06598F84B1D9AA527@exchange4.exchange.alphared.local> References: <859D2283FD04CA44986CC058E06598F84B1D9AA527@exchange4.exchange.alphared.local> Message-ID: > 1) I oppose allowing blanket allocations of /48s by an LIR. > A /48 is close to infinite for practical purposes but is not infinite. This is precisely the reason why the IETF's RFC 3177 recommends that ISPs allocate a /48 to all sites which need more than one subnet. In IPv4, the limited number of addresses available meant that any network which needed to grow much more than planned for a year or so, had to do it by adding new address blocks (additional route table entries) or by renumbering. Huge route tables, and complex renumbering processes were both considered to be bad, so the IETF tried to avoid this in IPv6. That's why the IPv6 address space is close to infinite, from a global viewpoint and why a single subnet (/64) is close to infinite from a local perpective. Therefore, a site is given /48 to try and maintain this "close to infinite" characteristic at the site level. > 2) IPv6 renumbering happens. We need a policy that says a > network with X nodes is eligible for a /48 and with Y nodes > is eligible for a /32. In IPv6 we do not count nodes. Instead we count site allocations/assignments. This used to be /48s but when the /56 was introduced for residential customer sites, this was modified so that a normal IPv6 site is counted as the equivalent of 256 private home sites. > Traffic engineering is also going > to require either A) a new routing protocol, B) changes to > BGP, C) deaggregation or D) multiple /32s. What is wrong with MPLS traffic engineering? > I am not sure how ARIN expects these aspects to be handled. > Guidance here would be useful. ARIN has never provided guidance on routing. --Michael Dillon From heldal at eml.cc Fri Aug 24 05:35:17 2007 From: heldal at eml.cc (Per Heldal) Date: Fri, 24 Aug 2007 11:35:17 +0200 Subject: [ppml] Various IPv6 issues In-Reply-To: <859D2283FD04CA44986CC058E06598F84B1D9AA527@exchange4.exchange.alphared.local> References: <859D2283FD04CA44986CC058E06598F84B1D9AA527@exchange4.exchange.alphared.local> Message-ID: <1187948117.17950.5.camel@localhost.localdomain> On Thu, 2007-08-23 at 22:09 -0500, mack wrote: > 4) ARIN seems to be allocating on /29 boundaries to allow expansion while maintaining aggregation. > This is a good thing. Obviously gaps can be filled in later if needed. > It also leaves a gap that vendors possibly could fill with minor changes to filter specs. I.e. permit up to /N but require the last few bits to be 0. This to prevent hijacking of unused blocks from sparse allocations. > 5) Geographically dispersed organizations will need more than a single /32 if a /32 is the > smallest announcement and we do not wish to de-aggregate. Traffic engineering is also > going to require either A) a new routing protocol, B) changes to BGP, C) deaggregation > or D) multiple /32s. There's still a lot that could be done within current standards by implementing dynamic mechanisms that take the as-path-length into account. //per From mack at exchange.alphared.com Fri Aug 24 07:48:28 2007 From: mack at exchange.alphared.com (mack) Date: Fri, 24 Aug 2007 06:48:28 -0500 Subject: [ppml] Various IPv6 issues In-Reply-To: <1187948117.17950.5.camel@localhost.localdomain> References: <859D2283FD04CA44986CC058E06598F84B1D9AA527@exchange4.exchange.alphared.local> <1187948117.17950.5.camel@localhost.localdomain> Message-ID: <859D2283FD04CA44986CC058E06598F84B1D9AA52D@exchange4.exchange.alphared.local> Thank you for your response. > -----Original Message----- > From: Per Heldal [mailto:heldal at eml.cc] > Sent: Friday, August 24, 2007 4:35 AM > To: mack > Cc: ppml at arin.net > Subject: Re: [ppml] Various IPv6 issues > > On Thu, 2007-08-23 at 22:09 -0500, mack wrote: > > 4) ARIN seems to be allocating on /29 boundaries to allow expansion > while maintaining aggregation. > > This is a good thing. Obviously gaps can be filled in later if > needed. > > > > It also leaves a gap that vendors possibly could fill with minor > changes > to filter specs. I.e. permit up to /N but require the last few bits to > be 0. This to prevent hijacking of unused blocks from sparse > allocations. TCAM masks allow this (at least in Cisco equipment). > > > > 5) Geographically dispersed organizations will need more than a > single /32 if a /32 is the > > smallest announcement and we do not wish to de-aggregate. Traffic > engineering is also > > going to require either A) a new routing protocol, B) changes to BGP, > C) deaggregation > > or D) multiple /32s. > > There's still a lot that could be done within current standards by > implementing dynamic mechanisms that take the as-path-length into > account. We can limit the distance a de-aggregate travels certainly but it is still a de-aggregate. At 2 as-hops it has still effected most of the backbones and major ISPs of the DFZ. At 3 as-hops it effects more than half of all ASes. > > > > //per > From iljitsch at muada.com Fri Aug 24 08:06:34 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 24 Aug 2007 14:06:34 +0200 Subject: [ppml] Various IPv6 issues In-Reply-To: <859D2283FD04CA44986CC058E06598F84B1D9AA527@exchange4.exchange.alphared.local> References: <859D2283FD04CA44986CC058E06598F84B1D9AA527@exchange4.exchange.alphared.local> Message-ID: <4DA26BBC-C9A8-425A-A0B6-9E9D3F37BFBB@muada.com> Allow me to disagree with ALL of your points: On 24-aug-2007, at 5:09, mack wrote: > I agree with a /56 for 'residential' use See my earlier comments on /56 vs /60. > 2) IPv6 renumbering happens. We need a policy that says a network > with X nodes is eligible for a /48 and with Y nodes is eligible for > a /32. Nodes are irrelevant. You can put every IP-capable device ever built in a /64. > 3) IPv6 NAT is going to happen. It is going to be one to one > rather than > one to many which prevents breaking most protocols. The protocols still break and unlike with IPv4, implementations don't contain any workarounds so good luck with that. > 4) ARIN seems to be allocating on /29 boundaries to allow expansion > while maintaining aggregation. > This is a good thing. Obviously gaps can be filled in later if > needed. It's a bad thing, becaue experience shows that filling in the gaps doesn't lead to good aggregation. This only serves to make utilization of address space sparser, making data structures in routing tables less efficient and filtering harder. > 5) Geographically dispersed organizations will need more than a > single /32 if a /32 is the > smallest announcement and we do not wish to de-aggregate. Traffic > engineering is also > going to require either A) a new routing protocol, B) changes to > BGP, C) deaggregation > or D) multiple /32s. Sure, why should multi-geography organizations pay for a private network if they can simply deaggregate and burden the entire world with the cost of bigger routers? Don't come crying to the IETF if bad policy breaks the internet. From packetgrrl at gmail.com Fri Aug 24 08:37:57 2007 From: packetgrrl at gmail.com (cja@daydream.com) Date: Fri, 24 Aug 2007 06:37:57 -0600 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 In-Reply-To: References: <46C5E72F.2080903@arin.net> <46CDD840.1050001@arin.net> <20070823230556.GA34993@ussenterprise.ufp.org> Message-ID: Michael, There are some who say that we do know the right thing with allocation policies for IPv6 but we're doing something else anyway. Who knows. I do know this. We need to have a policy for subsequent allocations now. This is just like when Jon Postel set aside 24.0.0.0/8 for cable. My organization got 24.0.0.0/14. No one at the Internic or IANA thought that we would ever come back for more. There was no policy. The reality is that we did go back for more over and over again. We used a lot of address space and it was highly utilized. When we went back for more we spent quite a bit of time with Kim and Jon sorting out a reasonable subsequent allocation policy for cable (one that is still in use and it has been over 10 years). I do realize that 24.0.0.0/14 is small compared to an IPv6 allocation but for its time it was huge. Someone will come back for more whether it's a reasonable request or not and we have to be ready. ----Cathy On 8/24/07, michael.dillon at bt.com wrote: > > > If I had a choice as an LIR of doing something that will make > > my new request a cake walk in 10 years time, or will require > > me to go back and renumber 10 years worth of customers to > > comply, I would much rather do the right thing now. > > > > That requires me to know what the right thing is, up front. > > Unfortunately, nobody can know what ARIN policy wil be 10 years from > now. Policy is subject to change by the community. > > However, the IETF is closing their IPv6 working group because they feel > that IPv6 is complete. From now on, IPv6 will be in maintenance mode. > This means that you can be reasonably certain that the IPv6 addressing > architecture will NOT change during the next 10 years. Any ISP that > complies with the IPv6 addressing architecture is unlikely to have a > problem in 10 years. > > If the unlikely does happen, and an ISP is unable to get a second > allocation in 10 years from now, there is an easy solution. Create a new > corporate entity, and have that entity apply for their first allocation. > Or go to one of the other RIRs and get a first allocation from them. Or > both. > > ARIN is not the Internet police. And ARIN does not know, and will not > know for several years, what is the RIGHT thing to do with IPv6 > addressing. > > --Michael Dillon > _______________________________________________ > 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 Fri Aug 24 10:41:17 2007 From: ipgoddess at gmail.com (Stacy Taylor) Date: Fri, 24 Aug 2007 07:41:17 -0700 Subject: [ppml] Policy Proposal: Definition of known ISP and changes to IPv6 initial allocation criteria In-Reply-To: <20070822205732.GL28312@shell01.cell.sv2.tellme.com> References: <46AE170F.6010901@arin.net> <20070822202025.GB18561@ussenterprise.ufp.org> <20070822205732.GL28312@shell01.cell.sv2.tellme.com> Message-ID: <1c16a4870708240741v73e77c18yc32804f37c375beb@mail.gmail.com> Hi Everyone, I am wondering why we are limiting the downstream reassignment to /23. My network has plenty of downstream ISPs/MSOs that sell Internet connectivity to their customers with way less space than that. Curious, Stacy On 8/22/07, David Williamson wrote: > On Wed, Aug 22, 2007 at 04:20:25PM -0400, Leo Bicknell wrote: > > Were both proposals to pass, are these substantially similar enough > > that the AC could use either one to serve the purpose? > > The only word that might present a problem is "known", and I think > that's perhaps an unnecessary addition. > > I think the AC can handle this. > > -David > _______________________________________________ > 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 Daniel_Alexander at Cable.Comcast.com Fri Aug 24 10:40:58 2007 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Fri, 24 Aug 2007 10:40:58 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 In-Reply-To: References: <46C5E72F.2080903@arin.net> <46CDD840.1050001@arin.net> Message-ID: <997BC128AE961E4A8B880CD7442D94800143911B@NJCHLEXCMB01.cable.comcast.com> To me, the rewrite seems contradictory to 6.5.2.1 Subsequent allocation criteria. If we say that ARIN will not review allocations of a /48 or smaller, how can staff review a subsequent request, when they have to confirm utilization to a /56? I've never been a big fan of section 6.5.4.1 Assignment Address space size. It should be up to the LIR/ISP to make those judgement calls as to the needs of itself and its customer. We don't try to put these guidelines into IPv4. Allocation practices are based on the criteria to get more space. If IPv6 subsequent allocations are based on the utilization of /56 units, then that will drive the allocation guidelines. I will concede that many LIR/ISP will never need a second allocation, so they are looking for some direction as to which way to go. It however, seems like an odd argument, because if they are never going to need another allocation, what does it matter how they distribute the allocation they've been given? -Dan -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com Sent: Thursday, August 23, 2007 6:34 PM To: ppml at arin.net Subject: Re: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 > Delete the text in 6.5.4.2 and Replace the text in section > 6.5.4.1 with the following text: > > Assignments by LIRs /48 or smaller will not be reviewed by ARIN. > Assignments greater than /48 will be reviewed to see if the additional > space is warranted according to the 0.94 HD ratio policy. If the > space is not warranted, ARIN will consider the excess space to be > available for a different assignment, lowering the overall utilization > score of the LIR. This seems to apply to second and subsequent allocations but the language does not clearly tie it into section 6.5.2. And anyhow, it could be years before there is any significant volume of requests for second allocations. Why do we need to waste time on this problem now? For this reason, I am opposed to this policy. Whether current policy is right or wrong is irrelevant, since the magnitude of the wrongness is limited to a minor squeak due to the small number of IPv6 LIR allocations. If a few dozen LIRs come back in the next two years and ask for a second /32 and ARIN rubberstamps the requests, it will do no harm to anyone, even if all of those RIRs have recklessly squandered their first allocation. --Michael Dillon _______________________________________________ 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 randy at psg.com Fri Aug 24 10:47:00 2007 From: randy at psg.com (Randy Bush) Date: Fri, 24 Aug 2007 04:47:00 -1000 Subject: [ppml] Policy Proposal: Definition of known ISP and changes to IPv6 initial allocation criteria In-Reply-To: <1c16a4870708240741v73e77c18yc32804f37c375beb@mail.gmail.com> References: <46AE170F.6010901@arin.net> <20070822202025.GB18561@ussenterprise.ufp.org> <20070822205732.GL28312@shell01.cell.sv2.tellme.com> <1c16a4870708240741v73e77c18yc32804f37c375beb@mail.gmail.com> Message-ID: <46CEEF64.2010309@psg.com> > I am wondering why we are limiting the downstream reassignment to /23. > My network has plenty of downstream ISPs/MSOs that sell Internet > connectivity to their customers with way less space than that. because folk with too much time on their hands spend some of it telling others how run their business? in albuquerque, i will be doing a presentation of blockers to ipv6 deployment. the content of this list and the proposals being made will feature prominently. folk might step back a few hundred meters and consider the embarrassing situation here. randy From bicknell at ufp.org Fri Aug 24 10:54:29 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 24 Aug 2007 10:54:29 -0400 Subject: [ppml] Policy Proposal: Definition of known ISP and changes to IPv6 initial allocation criteria In-Reply-To: <46CEEF64.2010309@psg.com> References: <46AE170F.6010901@arin.net> <20070822202025.GB18561@ussenterprise.ufp.org> <20070822205732.GL28312@shell01.cell.sv2.tellme.com> <1c16a4870708240741v73e77c18yc32804f37c375beb@mail.gmail.com> <46CEEF64.2010309@psg.com> Message-ID: <20070824145429.GA3558@ussenterprise.ufp.org> In a message written on Fri, Aug 24, 2007 at 04:47:00AM -1000, Randy Bush wrote: > > I am wondering why we are limiting the downstream reassignment to /23. > > My network has plenty of downstream ISPs/MSOs that sell Internet > > connectivity to their customers with way less space than that. > > because folk with too much time on their hands spend some of it telling > others how run their business? Clearly the solution to widespread IPv6 deployment is to give everyone who has a /29 of IPv4 space somewhere a /32 of IPv6 space. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From bicknell at ufp.org Fri Aug 24 11:07:01 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 24 Aug 2007 11:07:01 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 In-Reply-To: <997BC128AE961E4A8B880CD7442D94800143911B@NJCHLEXCMB01.cable.comcast.com> References: <46C5E72F.2080903@arin.net> <46CDD840.1050001@arin.net> <997BC128AE961E4A8B880CD7442D94800143911B@NJCHLEXCMB01.cable.comcast.com> Message-ID: <20070824150700.GB3558@ussenterprise.ufp.org> In a message written on Fri, Aug 24, 2007 at 10:40:58AM -0400, Alexander, Daniel wrote: > To me, the rewrite seems contradictory to 6.5.2.1 Subsequent allocation > criteria. If we say that ARIN will not review allocations of a /48 or > smaller, how can staff review a subsequent request, when they have to > confirm utilization to a /56? I don't see the conflict your seeing. The point is that ARIN will not look inside the allocations to end users. So if an ISP assigns a /48 to "Dan Alexander" ARIN will say "that's 256 /56's assigned." What ARIN won't do is say, "hey, isn't Dan only using a single /64, shouldn't you, Mr ISP have given him a /56 (or any other size)?" > I've never been a big fan of section 6.5.4.1 Assignment Address space > size. It should be up to the LIR/ISP to make those judgement calls as to > the needs of itself and its customer. We don't try to put these > guidelines into IPv4. Allocation practices are based on the criteria to > get more space. If IPv6 subsequent allocations are based on the > utilization of /56 units, then that will drive the allocation > guidelines. To say we don't put these guidelines into IPv4 is totally wrong. The guideline is different, but it's far more strict and it puts ARIN into the ISP's business. Section 4.2.3 deals with reassigning space to customers: http://www.arin.net/policy/nrpm.html#four23 In particular, 4.2.3.1 requires an ISP to get a justification from their customer for every block assigned, and 4.2.3.4.1 requires that the ISP show /each and every/ customer is using at least 80% of their space. When asking for new space, ARIN will absolutely ask for the justification provided by your customers, and look at the utilization inside customer blocks, for IPv4. More to the point, if what you desire is that the LIR/ISP can make the judgement calls, that's exactly what this policy does. It says, "Mr ISP, make any judgement call you want in the range of /48-/128. ARIN will never second guess your decision, nor will ARIN ever ask for the details of why you made your decision." > I will concede that many LIR/ISP will never need a second allocation, so > they are looking for some direction as to which way to go. It however, > seems like an odd argument, because if they are never going to need > another allocation, what does it matter how they distribute the > allocation they've been given? I totally disagree that most will never need a second allocation. In the ARIN region most ISP's have requested a /32 so far. At an HD-Ratio of 0.94 that gives them a little over 33,000 customers at a /48. The primary reason is many ISP's have received their current allocations for test networks and/or initial deployments, and not attempted to size to handle their entire customer base should IPv6 take off. [Note, that in and of it self doesn't meet with the Sprit of IPv6 allocation guidelines.] I believe there are at least 10, and perhaps closer to 100 ISP's who have at least that many customers in the US. There may be more. Indeed, outside the US we see /19's being assigned by RIPE to FT and DT; so it's likely some of the people who have /32's today will need more space in the future. I would like ARIN staff to track and report on subsequent requests, but I firmly believe we will have multiple requests for additional space processed in the next 5 years. -- 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 Aug 24 11:14:17 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 24 Aug 2007 16:14:17 +0100 Subject: [ppml] Policy Proposal: Definition of known ISP and changes toIPv6 initial allocation criteria In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A02A4C8A2@nyrofcs2ke2k01.corp.pvt> References: <454810F09B5AA04E9D78D13A5C39028A02A4C8A2@nyrofcs2ke2k01.corp.pvt> Message-ID: >It would be a stronger and more valid > requirement if it were revised as follows: A LIR is an > organization that reassigns and/or reallocates at a minimum a > IPv4 /23 or IPv6 /44 worth of space to their own downstream customers. Where does /23 and /44 come from? Is this an attempt to reintroduce the concept of NLAs and TLAs from the deprecated RFC 2450? I suggest that this type of suggestion does not belong in the ARIN public policy process but belongs in the in the IETF. We have an agreement with ICANN and the DoC, to work in cooperation with the IETF which means that we should not try to change the design of IPv6. As far as the IETF is concerned, an ISP is an entity that receives one or more /32 allocations for reassignment and reallocation to their downstream network infrastructure including that of customers. If we want to call this entity an LIR, fair enough. And if we want to define them by magnitude of IPv6 address space, then we should say than an LIR is an entity that reassigns/reallocates one or more /32 blocks of IP address space to downstream networks. --Michael Dillon From Lee.Howard at stanleyassociates.com Fri Aug 24 11:20:46 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 24 Aug 2007 11:20:46 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 In-Reply-To: <997BC128AE961E4A8B880CD7442D94800143911B@NJCHLEXCMB01.cable.comcast.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB406C84ACA@CL-S-EX-1.stanleyassociates.com> > Behalf Of Alexander, Daniel > Address space size. It should be up to the LIR/ISP to make > those judgement calls as to the needs of itself and its > customer. We don't try to put these guidelines into IPv4. There has to be a limit documented somewhere. I don't think ARIN should allocate more address space to an ISP who blows their /32 by assigning /30s to customers of all sizes. I don't think the current policy is clear what that limit is. I don't care what that limit is, but clear policy is needed. We do put similar limitations on IPv4, requiring 80% utilization. Michael Dillon said: > Why do we need to waste time on this problem now? ISP members have asked what they're supposed to do to make sure they can get their subsequent allocation, should they need one. I think ARIN should be able to hassle an applicant for a second allocation if they've been stupid, but we need to document what "stupid" looks like. Yes, that was a straight line. Go for it. Lee From michael.dillon at bt.com Fri Aug 24 11:35:34 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 24 Aug 2007 16:35:34 +0100 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 In-Reply-To: <20070824150700.GB3558@ussenterprise.ufp.org> References: <46C5E72F.2080903@arin.net> <46CDD840.1050001@arin.net><997BC128AE961E4A8B880CD7442D94800143911B@NJCHLEXCMB01.cable.comcast.com> <20070824150700.GB3558@ussenterprise.ufp.org> Message-ID: > I totally disagree that most will never need a second allocation. > In the ARIN region most ISP's have requested a /32 so far. > At an HD-Ratio of 0.94 that gives them a little over 33,000 > customers at a /48. The primary reason is many ISP's have > received their current allocations for test networks and/or > initial deployments, and not attempted to size to handle > their entire customer base should IPv6 take off. [Note, that > in and of it self doesn't meet with the Sprit of > IPv6 allocation guidelines.] Now there is something that we can fix with policy. How about allowing any LIR to receive a second allocation under the "first allocation" rules if they provide a signed statement that the earlier allocation was used only for testing and trial purposes and that they will return the earlier allocation to ARIN within 6 months? --Michael Dillon From bicknell at ufp.org Fri Aug 24 11:36:07 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 24 Aug 2007 11:36:07 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 In-Reply-To: References: <46C5E72F.2080903@arin.net> <20070824150700.GB3558@ussenterprise.ufp.org> Message-ID: <20070824153607.GC6207@ussenterprise.ufp.org> In a message written on Fri, Aug 24, 2007 at 04:35:34PM +0100, michael.dillon at bt.com wrote: > How about allowing any LIR to receive a second allocation under the > "first allocation" rules if they provide a signed statement that the > earlier allocation was used only for testing and trial purposes and that > they will return the earlier allocation to ARIN within 6 months? http://www.arin.net/policy/irpep_template.html I support the concept; but I also believe it is orthogonal to this policy. -- 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 dean at av8.com Fri Aug 24 14:29:37 2007 From: dean at av8.com (Dean Anderson) Date: Fri, 24 Aug 2007 14:29:37 -0400 (EDT) Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: Message-ID: On Fri, 24 Aug 2007, Iljitsch van Beijnum wrote: > Stretching IPv4 only means that people will delay the move to IPv6, This seems to be the unproven assumption and flaw in the IPv6 logic. Rationing doesn't "stretch" the lifetime of IPv4, and doesn't delay the move to IPv6. IPv4 will continue after exhaustion of the Available pool. Address space will be returned or reclaimed, and allocations will eventually resume. Exhaustion in this case just creates a bump in IPv4 operations. That bump, and consequences of the bump, can be avoided. However, there is no case where that bump greatly improves the transistion to IPv6. Just the opposite. Your scheme seems to be desperate and makes me more suspicious of IPv6. If IPv6 could stand on its own merits, you wouldn't need to try to wreck IPv4 to promote it. However, your attempt at wrecking IPv4 will fail, because IPv4 will survive, albeit with disruption and other more nasty problems that are entirely avoidable. This is just an irresponsible attempt at destruction, by people trying to promote IPv4. I'm going to have to look into IPv6, to find out what's wrong with it, that you would need to disrupt Ipv4. > My assumption of what would happen when we run out (in the absense of > new policies) is that if a request comes in for more address space > than is available, the request is denied A request for a smaller > amount of address space that can still be accommodated would be > honored. If you want your policy to work like that, you should say > that in the proposal. Well, this happens with or without rationing. > With rationing, there are opportunities to try again, with running > out, when you're done, you're done. ???? You can try again and again now, too. > In my opinion, hoarding isn't possible to harmful degrees with simply > running out because only the organizations that already use large > amounts of address space will be able to get large amounts of address > space, so the address space is going to end up with those > organizations whether they try to hoard or not. The only issue would > be some organizations trying to hoard while others play by the rules. ???? No difference whether rationing or not. None of your arguments make any difference under rationing or not rationing. So, they don't have any relevance to rationing. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From briand at ca.afilias.info Fri Aug 24 14:34:59 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Fri, 24 Aug 2007 14:34:59 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 In-Reply-To: <20070824153607.GC6207@ussenterprise.ufp.org> References: <46C5E72F.2080903@arin.net> <20070824150700.GB3558@ussenterprise.ufp.org> <20070824153607.GC6207@ussenterprise.ufp.org> Message-ID: <46CF24D3.4080000@ca.afilias.info> Leo Bicknell wrote: > In a message written on Fri, Aug 24, 2007 at 04:35:34PM +0100, michael.dillon at bt.com wrote: > >> How about allowing any LIR to receive a second allocation under the >> "first allocation" rules if they provide a signed statement that the >> earlier allocation was used only for testing and trial purposes and that >> they will return the earlier allocation to ARIN within 6 months? >> > > http://www.arin.net/policy/irpep_template.html > > I support the concept; but I also believe it is orthogonal to this > policy. > I am afraid I have to categorically refute that statement. Here are the two choices: (1) adopt a policy that applies (retroactively) to all recipients of IPv6 space, including already assigned space. (2) adopt a policy that applies only to new assignments. And having rules that say, our response to any new request (after the adoption date of the policy) will differ depending on whether you already have some space assigned under a prior policy, means the rules are of type (1). Michaels suggestion/proposition basically modifies the original proposal to make it (2). As it stands, it is (1). And (1) is not orthogonal, by definition - it is embodied whole hog in the proposed policy. I believe that the best result for the DFZ is achieved by (2), i.e. the suggestion Michael made. I would be a bit more flexible, and say merely "will withdraw all announcements covered by the earlier allocation, from the DFZ" within . No damage is done by the existence of unannounced prefixes - the only issue is announced prefixes. And, making it easier for "experimenters" / "early adopters" to adjust their assignment to better fit their needs, which may (far) exceed reserved space that ARIN may have kept as a buffer, is in everyone's interest. Keep in mind, we are at present talking about only 848 prefixes. Making exceptions for this tiny number, to avoid policies which might otherwise be bad in the long term, is something we should be prepared to do. Brian Dickson -------------- next part -------------- A non-text attachment was scrubbed... Name: briand.vcf Type: text/x-vcard Size: 232 bytes Desc: not available URL: From paul at vix.com Fri Aug 24 14:41:21 2007 From: paul at vix.com (Paul Vixie) Date: Fri, 24 Aug 2007 18:41:21 +0000 Subject: [ppml] Policy Proposal: Definition of known ISP and changes to IPv6 initial allocation criteria In-Reply-To: Your message of "Fri, 24 Aug 2007 10:54:29 -0400." <20070824145429.GA3558@ussenterprise.ufp.org> References: <46AE170F.6010901@arin.net> <20070822202025.GB18561@ussenterprise.ufp.org> <20070822205732.GL28312@shell01.cell.sv2.tellme.com> <1c16a4870708240741v73e77c18yc32804f37c375beb@mail.gmail.com> <46CEEF64.2010309@psg.com> <20070824145429.GA3558@ussenterprise.ufp.org> Message-ID: <52117.1187980881@sa.vix.com> > > because folk with too much time on their hands spend some of it telling > > others how run their business? > > Clearly the solution to widespread IPv6 deployment is to give > everyone who has a /29 of IPv4 space somewhere a /32 of IPv6 space. don't laugh. recreating the swamp may be our only way forward. From kloch at kl.net Fri Aug 24 14:50:16 2007 From: kloch at kl.net (Kevin Loch) Date: Fri, 24 Aug 2007 14:50:16 -0400 Subject: [ppml] Policy Proposal: Definition of known ISP and changes toIPv6 initial allocation criteria In-Reply-To: References: <454810F09B5AA04E9D78D13A5C39028A02A4C8A2@nyrofcs2ke2k01.corp.pvt> Message-ID: <46CF2868.1090703@kl.net> michael.dillon at bt.com wrote: >> It would be a stronger and more valid >> requirement if it were revised as follows: A LIR is an >> organization that reassigns and/or reallocates at a minimum a >> IPv4 /23 or IPv6 /44 worth of space to their own downstream customers. > > Where does /23 and /44 come from? Is this an attempt to reintroduce the > concept of NLAs and TLAs from the deprecated RFC 2450? This does not define what an ISP/LIR is in the scope of addressing topology, it defines the phrase "Existing ISP" for the purposes of the ISP initial assignment criteria. It's an attempt to have a precise definition that ARIN staff can use when evaluating the "Existing ISP" clause. Currently "Existing ISP" is ambiguous and ARIN staff is declining ISP's that use /18's worth of space from upstreams. I don't have a problem deleting the "Existing ISP" option but if it is in the policy there needs to be a useful definition. The /23 or /44 was what I thought was a reasonable definition. I'm sure there are many possible definitions but I was going for one that is easy for ARIN staff to measure against without extraordinary paperwork. > As far as the IETF is concerned, an ISP is an entity that receives one > or more /32 allocations for reassignment and reallocation to their > downstream network infrastructure including that of customers. If that is the definition the ARIN policy community wants to use for "Known ISP" then we need to delete that option from the ISP initial allocation criteria. It would create a circular reference. - Kevin From kloch at kl.net Fri Aug 24 14:51:42 2007 From: kloch at kl.net (Kevin Loch) Date: Fri, 24 Aug 2007 14:51:42 -0400 Subject: [ppml] Policy Proposal: Definition of known ISP and changes to IPv6 initial allocation criteria In-Reply-To: <1c16a4870708240741v73e77c18yc32804f37c375beb@mail.gmail.com> References: <46AE170F.6010901@arin.net> <20070822202025.GB18561@ussenterprise.ufp.org> <20070822205732.GL28312@shell01.cell.sv2.tellme.com> <1c16a4870708240741v73e77c18yc32804f37c375beb@mail.gmail.com> Message-ID: <46CF28BE.6000809@kl.net> Stacy Taylor wrote: > Hi Everyone, > I am wondering why we are limiting the downstream reassignment to /23. > My network has plenty of downstream ISPs/MSOs that sell Internet > connectivity to their customers with way less space than that. > Curious, > Stacy I'd like to hear more comments on this. Personally I think defining it that low is risky. - Kevin From kloch at kl.net Fri Aug 24 14:58:30 2007 From: kloch at kl.net (Kevin Loch) Date: Fri, 24 Aug 2007 14:58:30 -0400 Subject: [ppml] Policy Proposal: Definition of known ISP and changes to IPv6 initial allocation criteria In-Reply-To: <46CEEF64.2010309@psg.com> References: <46AE170F.6010901@arin.net> <20070822202025.GB18561@ussenterprise.ufp.org> <20070822205732.GL28312@shell01.cell.sv2.tellme.com> <1c16a4870708240741v73e77c18yc32804f37c375beb@mail.gmail.com> <46CEEF64.2010309@psg.com> Message-ID: <46CF2A56.6080201@kl.net> While breaking the 1 post per day guideline I promise I'll take at least 2 days off after this :) Randy Bush wrote: >> I am wondering why we are limiting the downstream reassignment to /23. >> My network has plenty of downstream ISPs/MSOs that sell Internet >> connectivity to their customers with way less space than that. > > because folk with too much time on their hands spend some of it telling > others how run their business? Did you read the proposal that was referenced? It deletes language for "200 /48 assignments in 5 years" and replaces it with "200 customer assignments in 5 years". That is a step in the right direction no? As for having too much time on my hands, I certainly don't and if you folks think I am just wasting your time please say so. I would gladly revoke the proposal to save everyone and myself the trouble. - Kevin From bicknell at ufp.org Fri Aug 24 15:47:43 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 24 Aug 2007 15:47:43 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 In-Reply-To: <46CF24D3.4080000@ca.afilias.info> References: <46C5E72F.2080903@arin.net> <20070824150700.GB3558@ussenterprise.ufp.org> <20070824153607.GC6207@ussenterprise.ufp.org> <46CF24D3.4080000@ca.afilias.info> Message-ID: <20070824194743.GB26958@ussenterprise.ufp.org> Michael's suggestion is a mulligan. It's a do-over your first time, which may be appropriate. If the R&D arm of the company asked for what they could get, and now the production side has figured out it should be something different, that's a good thing. Now, I thought that was the point of 6Bone space, but maybe we got the timing wrong which is why I don't think Michael's proposal is all bad. Now, let's assume Michael's policy passed and had the result he wanted, people didn't have to come back for a long time. I'll throw out 50 years. That to me argues my policy is needed even more. The current policy basically states "ARIN Staff will make a big old guess in 50 years if you did a good job. Hope so!". My policy says, "Here's the objective criteria ARIN staff will use 50 years from now to give you your second prefix." So all Michael's policy would do would be to change the application to be on requests 3-n, where as without it it would apply to 2-n. Which is why I submit the are orthogonal. -- 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 Lee.Howard at stanleyassociates.com Fri Aug 24 16:14:42 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 24 Aug 2007 16:14:42 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 In-Reply-To: <20070824194743.GB26958@ussenterprise.ufp.org> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB406C84D3F@CL-S-EX-1.stanleyassociates.com> > So all Michael's policy would do would be to change the application > to be on requests 3-n, where as without it it would apply to 2-n. > Which is why I submit the are orthogonal. I was with you until this. What are "2-n" and "3-n"? Lee From mike at mathbox.com Fri Aug 24 16:16:47 2007 From: mike at mathbox.com (Michael Thomas - Mathbox) Date: Fri, 24 Aug 2007 16:16:47 -0400 Subject: [ppml] SPAM-WARN:Re: Policy Proposal: Definition of known ISP and changes toIPv6 initial allocation criteria In-Reply-To: <46CF2868.1090703@kl.net> Message-ID: <200708241616689.SM00544@mikesplace> I object to the IPv4 /23 or IPv6 /44 requirement. It assumes a business model. Not everyone's business model is the same. Having a different business model does not eliminate one from having a need or from being an ISP/LIR. Assigning 50 /24s uses the same resources as 25 /23s, but there may be no /23 assignments. Further, you are building an artificial impediment for startup ISPs. I have read 60% to 80% of all of the emails generated by this list. My reading has not ignored any of the subjects. I think most everyone is trying to do the right thing. I see a lot of good back and forth discussion. But a lot of the discussion is about operating in the DFZ, or operating the DFZ. The devised solutions to those issues create artificial barriers to startup and barriers to entry. ARIN and the resources that it represents does not belong to the dues paying members of this list. ARIN and the resources that it represents belongs to everyone in the ARIN region, including that residential customer at the end of a cable or DSL connection. The problem is that the residential customer is not interested in this list and the majority of the smaller ISPs (do I even dare to call them regional) do not have the time or resources to participate. However, everyone of them funds the DFZ and ARIN. As regards ARIN policies, get your head out of the DFZ. If I buy transit through the DFZ, my upstreams will deal with it. If I join the DFZ, I will deal with it. If it requires the equivalent of the IPv4 swamp, to run IPv6, it will be solved. > >> It would be a stronger and more valid > >> requirement if it were revised as follows: A LIR is an > >> organization that reassigns and/or reallocates at a minimum a > >> IPv4 /23 or IPv6 /44 worth of space to their own > downstream customers. Michael Thomas Mathbox 978-683-6718 1-877-MATHBOX (Toll Free) From briand at ca.afilias.info Fri Aug 24 16:39:30 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Fri, 24 Aug 2007 16:39:30 -0400 Subject: [ppml] Policy Proposal: Definition of known ISP and changes to IPv6 initial allocation criteria In-Reply-To: <46CF2A56.6080201@kl.net> References: <46AE170F.6010901@arin.net> <20070822202025.GB18561@ussenterprise.ufp.org> <20070822205732.GL28312@shell01.cell.sv2.tellme.com> <1c16a4870708240741v73e77c18yc32804f37c375beb@mail.gmail.com> <46CEEF64.2010309@psg.com> <46CF2A56.6080201@kl.net> Message-ID: <46CF4202.8070801@ca.afilias.info> Kevin Loch wrote: > > Did you read the proposal that was referenced? It deletes language for > "200 /48 assignments in 5 years" and replaces it with "200 customer > assignments in 5 years". That is a step in the right direction no? > First, an observation: The set of policies that affect allocations, initial and otherwise, and assignments from allocations (in the case of PA space), need to be considered as a whole. This makes it a little, um, challenging, to modify individual elements, in isolation. Now, my comments related to the proposal. I think keeping "5 years" is fine. Removing the size of the assignments is good. But, I would go much further. Anyone providing internet access, regardless of financial motive, to an unrelated entity, should be considered an {ISP|LIR}. And, as such, should be able to request an initial allocation. The request should include the number of current V4 assignments, and requested/projected/known V6 assignments over one or more timeframes - immediate need, 5 year, 10 year, "ever". And the minimum number of assignments in any of the "now or 5 year" timeframe, should be very small (e.g. 2). Reasoning: The ARIN region contains any number of entities, who may operate in such a way as to offer services to unaffiliated entities. Some of those may require sufficient redundancy as to need fully independent multi-homing, by way of BGP. E.g. small, developing nations with limited infrastructure. The guiding principal for the DFZ is, "no deaggregation, please". This means that anyone doing BGP, needs an ASN, and at minimum one PI block. (I also believe that only one PI block should be announced into the DFZ per ASN, but that's another issue.) This means that, regardless of size, any entity acting as an ISP for any other entity, which needs to be or intends to be multi-homed, *must* be given a PI block. The flip side is, that we should *strongly* discourage any entity which will not be assigning space to unaffiliated entities, from requesting or being given, PI space. So, my specific suggestion is: s/200 /2 / (Or, open the floor to proposals for values of N, where currently N is 200. With supporting arguments, please, but keep it short.) Brian Dickson Footnote: The *size* of the initial allocation itself, is a topic for another day. (I think /48 is okay, but would not object to allowing requests for PI of smaller blocks, say, /64 or longer.) -------------- next part -------------- A non-text attachment was scrubbed... Name: briand.vcf Type: text/x-vcard Size: 232 bytes Desc: not available URL: From tedm at ipinc.net Fri Aug 24 16:45:07 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 24 Aug 2007 13:45:07 -0700 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationingof IPv4 IP Addresses In-Reply-To: Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Iljitsch van Beijnum >Sent: Thursday, August 23, 2007 3:40 PM >To: Dean Anderson >Cc: ARIN PPML >Subject: Re: [ppml] Policy Proposal: Decreasing Exponential Rationingof >IPv4 IP Addresses > > >On 23-aug-2007, at 20:43, Dean Anderson wrote: > >>> The main reason is because its premise is flawed: the policy supposes >>> that making sure we don't run out of IPv4 address space the next 10 >>> years is better than the situation where we do run out. > >> I find it curious that people think that the effect of rationing (a >> temporary stop) is somehow worse than a permanent stop. > >Allow me to direct your attention to the "frog in a pot of boiling >water" metaphor. If you throw the frog in the water when it's already >boiling, the frog immediately jumps out. However, if you put the frog >in the water when it's still cool and then slowly increase the >temperature, the frog's reflex to avoid heat never kicks in and it's >boiled alive. > Baloney, this was disproved some time ago: http://www.snopes.com/critters/wild/frogboil.asp Ted From ipgoddess at gmail.com Fri Aug 24 17:59:28 2007 From: ipgoddess at gmail.com (Stacy Taylor) Date: Fri, 24 Aug 2007 14:59:28 -0700 Subject: [ppml] Policy Proposal: Definition of known ISP and changes to IPv6 initial allocation criteria In-Reply-To: <46CF28BE.6000809@kl.net> References: <46AE170F.6010901@arin.net> <20070822202025.GB18561@ussenterprise.ufp.org> <20070822205732.GL28312@shell01.cell.sv2.tellme.com> <1c16a4870708240741v73e77c18yc32804f37c375beb@mail.gmail.com> <46CF28BE.6000809@kl.net> Message-ID: <1c16a4870708241459i7e3f59a3l4aa8a6f9b63b42d5@mail.gmail.com> Hi Everyone, Well, really, what is the difference, aside from allocation size, between a large carrier and a small one? Amount of customers? Flavors of connectivity? Number of peers? DFZ-itude? If my network provides connectivity to a city-specific wireless network who provides connectivity to customers, how are each not ISPs? To qualify for space, known ISP or not, you still need to meet the same utilization requirements. My little /25 wireless guy won't qualify whether he's recognized as an ISP or not. My point is, if I've reallocated that /25 to him, and he reassigns to his customers, thereby providing connectivity to The Internet, he is one. Thanks, Stacy On 8/24/07, Kevin Loch wrote: > Stacy Taylor wrote: > > Hi Everyone, > > I am wondering why we are limiting the downstream reassignment to /23. > > My network has plenty of downstream ISPs/MSOs that sell Internet > > connectivity to their customers with way less space than that. > > Curious, > > Stacy > > I'd like to hear more comments on this. Personally I think defining it > that low is risky. > > - Kevin > _______________________________________________ > 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 steveb at eagle.ca Fri Aug 24 18:02:02 2007 From: steveb at eagle.ca (Steve Bertrand) Date: Fri, 24 Aug 2007 18:02:02 -0400 Subject: [ppml] [OT] v6 Technical guidance Message-ID: <46CF555A.3080404@eagle.ca> I'm sorry to post this here, but I thought it as good a place as any. Very briefly, I recently was allocated a /32 v6 space, and am running into a few technical hurdles I can not find answers to. I am having a hard time finding any mailing lists that deal with the technical/implementation side of things. Can anyone recommend any decent, active technical IPv6 implementation mailing lists? Any advice is most appreciated. Tks and regards, Steve From bicknell at ufp.org Fri Aug 24 18:32:37 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 24 Aug 2007 18:32:37 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB406C84D3F@CL-S-EX-1.stanleyassociates.com> References: <20070824194743.GB26958@ussenterprise.ufp.org> <369EB04A0951824ABE7D8BAC67AF9BB406C84D3F@CL-S-EX-1.stanleyassociates.com> Message-ID: <20070824223237.GA38871@ussenterprise.ufp.org> In a message written on Fri, Aug 24, 2007 at 04:14:42PM -0400, Howard, W. Lee wrote: > > So all Michael's policy would do would be to change the application > > to be on requests 3-n, where as without it it would apply to 2-n. > > Which is why I submit the are orthogonal. > > I was with you until this. What are "2-n" and "3-n"? As it stands now, there is initial allocation, additional request, additional request ... That is, requests 2-n are additional requests, where this policy would come into play. With Michael's idea, the path could be: initial allocation, mulligan, additional request, additional request ... Making requests 3-n additional requests where this policy would come into play. -- 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 briand at ca.afilias.info Fri Aug 24 18:44:48 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Fri, 24 Aug 2007 18:44:48 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 In-Reply-To: <20070824223237.GA38871@ussenterprise.ufp.org> References: <20070824194743.GB26958@ussenterprise.ufp.org> <369EB04A0951824ABE7D8BAC67AF9BB406C84D3F@CL-S-EX-1.stanleyassociates.com> <20070824223237.GA38871@ussenterprise.ufp.org> Message-ID: <46CF5F60.1080502@ca.afilias.info> Leo Bicknell wrote: > In a message written on Fri, Aug 24, 2007 at 04:14:42PM -0400, Howard, W. Lee wrote: > >>> So all Michael's policy would do would be to change the application >>> to be on requests 3-n, where as without it it would apply to 2-n. >>> Which is why I submit the are orthogonal. >>> >> I was with you until this. What are "2-n" and "3-n"? >> > > As it stands now, there is > > initial allocation, additional request, additional request ... > > That is, requests 2-n are additional requests, where this policy would > come into play. > > With Michael's idea, the path could be: > > initial allocation, mulligan, additional request, additional request ... > > Making requests 3-n additional requests where this policy would come > into play. > > Ah. It would likely confuse folks less to use the perl-style elipsis, 2..n instead of 2-n (which can be interpreted too many ways, like about 2^n ways :-)). So, it is 2..n vs 3..n, or rather that network #1, vs networks #1 and #2 (which becomes (!!) #1). Brian -------------- next part -------------- A non-text attachment was scrubbed... Name: briand.vcf Type: text/x-vcard Size: 232 bytes Desc: not available URL: From briand at ca.afilias.info Fri Aug 24 18:50:12 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Fri, 24 Aug 2007 18:50:12 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 In-Reply-To: <46CF5F60.1080502@ca.afilias.info> References: <20070824194743.GB26958@ussenterprise.ufp.org> <369EB04A0951824ABE7D8BAC67AF9BB406C84D3F@CL-S-EX-1.stanleyassociates.com> <20070824223237.GA38871@ussenterprise.ufp.org> <46CF5F60.1080502@ca.afilias.info> Message-ID: <46CF60A4.7030503@ca.afilias.info> Brian Dickson wrote: > Leo Bicknell wrote: > >> In a message written on Fri, Aug 24, 2007 at 04:14:42PM -0400, Howard, W. Lee wrote: >> >> >>>> So all Michael's policy would do would be to change the application >>>> to be on requests 3-n, where as without it it would apply to 2-n. >>>> Which is why I submit the are orthogonal. >>>> >>>> >>> I was with you until this. What are "2-n" and "3-n"? >>> >>> >> As it stands now, there is >> >> initial allocation, additional request, additional request ... >> >> That is, requests 2-n are additional requests, where this policy would >> come into play. >> >> With Michael's idea, the path could be: >> >> initial allocation, mulligan, additional request, additional request ... >> >> Making requests 3-n additional requests where this policy would come >> into play. >> >> >> > Ah. It would likely confuse folks less to use the perl-style elipsis, > 2..n instead of 2-n (which can be interpreted too many ways, like about > 2^n ways :-)). > So, it is 2..n vs 3..n, or rather that network #1, vs networks #1 and #2 > (which becomes (!!) #1). > ... have special rules (or are grandfathered). (Forgot to complete the sentence.) Brian -------------- next part -------------- A non-text attachment was scrubbed... Name: briand.vcf Type: text/x-vcard Size: 232 bytes Desc: not available URL: From iljitsch at muada.com Sat Aug 25 08:15:32 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sat, 25 Aug 2007 14:15:32 +0200 Subject: [ppml] IPv6 addresses really are scarce after all In-Reply-To: <200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> References: <46C613E0.8010909@bogus.com> <46C629D2.20009@cs.utk.edu> <17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com> <46C6B5BB.5000203@cs.utk.edu> <200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> Message-ID: [CCing this to ARIN PPML and RIPE address-policy, but Reply-To: ietf at ietf.org, when replying, please pick just one list. Also, please read Thomas' entire original message at http://www1.ietf.org/mail- archive/web/ietf/current/msg47431.html ] [You may want to skip ahead to my point about the HD ratio at the end.] On 24-aug-2007, at 23:34, Thomas Narten wrote: > The fact is, the /48 boundary is _NOT_ architectural, True. However, this doesn't mean that /48 is completely arbitrary, either. /64 for subnets is based on the availability of 64-bit unique numbers in the form of MAC addresses that make it possible to have stateless autoconfiguration where a system always has the same address without the need for explicit coordination or configuration. People often attribute the fact that IPv4 addresses didn't run out in 2005 as predicted in the early 1990s to NAT, but there is another technique that is even more popular than NAT that also played in important rule: ethernet switching. Back when IPv6 was designed, it was common to have a substantial number of different subnets for different purposes to avoid having unnecessary large "collision domains". These days, you can easily throw hundreds, if not thousands of systems in a single subnet without performance penalties so most networks don't need all that many subnets. So the original goal of providing something a number of subnets that is large enough for 99.9% of all IPv6 users arguably required a /48 (65536 subnets). With 2000::/3 given out for global unicast purposes, that allows 2^45 / 48s, which should be more than enough to give all inhabitants of the planet their own /48 with a few to spare. So a /48 is both big enough for pretty much everyone, and small enough that we can give one to pretty much everyone. Last but not least, it's very useful to have a standard size, because then, if you go from one ISP to another, you're never in the situation where you need to renumber into a smaller block of address space, which is much, much harder than just replacing the first X bits of the address (where X is presumably 48). This was especially true in the presence of DNAME and bitlabels in the DNS. For those of you that don't know about this, it's rather complex and now obsolete, but around the turn of the century, this was a hot new mechanism to support easy renumbering in the DNS. (Read about it here http://www.apress.com/ book/supplementDownload.html?bID=10026&sID=3120 but don't say I didn't warn you.) So /48 was certainly "a good idea at the time". If we were doing all of this today, we could probably go a bit lower than 65536 subnets, such as 4096, but not THAT much lower. For instance, 256 subnets (/ 56) is still a very large number, so it assumes that people will be subnetting, but I'm not confident that it's enough for 99.9% of all future IPv6 users. Another issue is what we give to people who aren't going to build a network with subnets. The old recommendation was a /64 (= 1 subnet) for users who don't need to subnet. But unlike with IPv4, where end- users often get a single IP address and turn that into a subnet with NAT, with IPv6 you pretty much always need TWO subnets, although one of them can be shared. For instance, if I want to connect a bunch of computers in my home to my DSL line with IPv6, I need a /64 on my wifi network at home, but it's not really possible to use addresses from that same /64 between my ADSL modem and the DSL concentrator at the central office. As an ISP, I could set up one /64 to talk to all the DSL modems connected to a central office and then delegate a /64 to each user, but this is problematic for technical reasons (broadcasts/mulsticast vs NBMA) and control issues (which user does traffic from an address in that shared /64 come from). So if I were designing an ISP network, I would want to give at least two /64s or a /63 to every customer. In practice, it's much easier to go up a few bits and make it a /60, where I use one /64 for the SIP- customer link and the customer gets to use the other 15 subnets however they want. This way, I avoid getting support calls from people who want to have an extra DMZ subnet or different subnets for their wired and wireless networks. Again, as an ISP, I wouldn't want to think about how many subnets customers are going to use when they need more than that /60. Much easier to simply sell them a business account and give them a /48. Remember, every time a simple residential customer calls the support number, that costs an ISP the entire profit for that customer for a year. Avoiding support calls is one of the highest priorities for ISPs. > What the appropriate size of an assignment for an end site should be > is really more of an operational issue than architectural one. If a > site gets too little, and needs to get more later (maybe at the cost > of renumbering) that is an operational issue. And the idea that we can > give out "enough" address space to a site so that it doesn't have to > renumber (ever) is pretty silly. That doesn't mean it's impossible to pick sizes that are worse than others. And even though we have reverted back to simple use of the DNS with IPv6 where having the same address block size when going from ISP to ISP is less important, it's still beneficial to have as few block sizes as possible to that people don't have to go from big to small. > The RIRs adopted the "/48 to everyone" in its initial stab at IPv6 > policy back in 2002. Even at that time, there was much screaming and > gnashing of teeth from the operator community saying "wasteful", > "excessive", "really stupid", etc. The wastefulness occurred when the IPv6 address size was set to 128 bits. This means that every IPv6 packet has to carry 32 bytes of address information. Now that we've eaten that cost, there is little use in trying to _use_ fewer of those bits that we're paying for with every packet. I can see how "/48 for everyone" could be considered too much (although 35184 billion of those aren't going to be used up any time soon) but can we at least retain "/48 for everyone who asks for one"? > If I assign 4M /48's of IPv6 (one to each cable modem on my > network), according to the HD-ratio I am justified to obtain > something around a /20 of IPv6 addresses. In other words, I am > justified in getting 268M /48's even though I am only using > 4M of > them. That would be enough for me to assign at least two for > every household in the US (not just the 19M on my network). Yes, this is a problem that the current policies, including the unofficial ones (for instance that ARIN reserves a /29 when an ISP gets a /32) don't address. Suppose a large ISP that operates across the US or Europe gets that / 20. So how are they going to announce that, as a single /20? I don't think so. They're going to deaggregate. And they can easily do that, because their block is much larger than the minimum /32 block that people are presumably going to be filtering on. In the degenerative case, which we can already see in IPv4, ISPs simply announce whatever they have as the smallest possible announcement. So that ISP that needs 4 million /48s = 64 /32s but gets a /20 = 4096 /32s COULD advertise 4096 prefixes because the RIRs thought they would need to aggregate, while if the RIRs assumed that they wouldn't aggregate, they would have gotten the space in the form of a number of much smaller blocks and they would only have been able to announce 100 or so /32s. A much more appropriate policy would be to start with a certain minimum allocation, and then whenever someone comes back for more, give them a new block that is 2, 4 or 8 times as big as the previous block until a certain maximum block size is reached. For aggregation purposes, there is no benefit in having blocks larger than a /24, because by the time that a significant portion of the the IPv6 space ends up in the routing tables, having 2^24 routes won't be a problem. > The > community feedback was that LIRs were smart enough to make reasonable > assignments based on actual customer need. The trouble is that even more so than at the IETF, the RIR community as seen from the policy development process is whoever happens to show up. This means only a small part of all stakeholders provide input. > Surely, everyone will agree that > giving a /56 to home sites is more than enough space for the foresable > future! If /48 is too much for home sites then /56 is too much as well. From iljitsch at muada.com Sat Aug 25 08:35:59 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sat, 25 Aug 2007 14:35:59 +0200 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: References: Message-ID: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> On 24-aug-2007, at 20:29, Dean Anderson wrote: >> Stretching IPv4 only means that people will delay the move to IPv6, > This seems to be the unproven assumption Hm, IPv4 addresses are still available and few people are using IPv6. Maybe not "proof" but so far the facts are on my side. > IPv4 will continue after exhaustion of the Available > pool. Address space will be returned or reclaimed, and allocations > will > eventually resume. Exhaustion in this case just creates a bump in > IPv4 > operations. That bump, and consequences of the bump, can be avoided. Yes, and after all the cars have been turned into big piles of rust, you'll be able to get oil again, too. But that doesn't mean things revert back to the way they were before. > However, there is no case where that bump greatly improves the > transistion to IPv6. There are enough extremely pigheaded people in the world, it's possible that they'll forego IPv6 even when IPv4 moves past its expiration date. > Just the opposite. Huh? > Your scheme seems to be desperate and makes me > more suspicious of IPv6. If IPv6 could stand on its own merits, you > wouldn't need to try to wreck IPv4 to promote it. I'm not trying to wreck IPv4. I'm trying to keep it in a usable state as long as possible, which means continuing to fullfil address requests. As soon as people can't get IPv4 addresses at the required levels anymore, bad things start happen. As soon as having IPv6 connectivity is a reasonable substitue for having IPv4 connectivity, the bad things stop. It would be great if we could make the latter happen before the former, but due to the network effect this is pretty much impossible: nobody gains any advantage from being the first to implement IPv6 as long as it's reasonably possible to use IPv4 instead. This has nothing to do with merits, just with the fact that you can reach 99.9% of the world over IPv4 and 0.1% over IPv6. > However, your attempt at wrecking IPv4 will fail, because IPv4 will > survive, (Do I hear a disco song in the distance?) > albeit with disruption and other more nasty problems that are > entirely avoidable. This is just an irresponsible attempt at > destruction, by people trying to promote IPv4. Right, and so many people are now running AppleTalk, IPX, DECNET and so on. China has gotten 30 million addresses so far this year. That's more than all year last year. Once China has caught up, the really poor countries are next in line. IPv4 can't sustain our growing communication needs, it's as simple as that. > I'm going to have to look into IPv6, to find out what's wrong with it, > that you would need to disrupt Ipv4. I recommend reading a good book about it. >> My assumption of what would happen when we run out (in the absense of >> new policies) is that if a request comes in for more address space >> than is available, the request is denied A request for a smaller >> amount of address space that can still be accommodated would be >> honored. If you want your policy to work like that, you should say >> that in the proposal. > Well, this happens with or without rationing. You didn't specify that in your proposal. > None of your arguments make any difference under rationing or not > rationing. So, they don't have any relevance to rationing. If you are an ISP that is going to connect a million customers in the next few months, you need a million addresses. If you only get 800000, 80000, 8000 or 800, you have a problem. The severity of the problem may differ slightly, but in each case, you have a problem that you don't have if you get that million addresses. By giving out address space while it lasts we don't start creating problems before we have to so people have more time to be proactive. From iljitsch at muada.com Sat Aug 25 08:37:33 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sat, 25 Aug 2007 14:37:33 +0200 Subject: [ppml] [OT] v6 Technical guidance In-Reply-To: <46CF555A.3080404@eagle.ca> References: <46CF555A.3080404@eagle.ca> Message-ID: On 25-aug-2007, at 0:02, Steve Bertrand wrote: > Very briefly, I recently was allocated a /32 v6 space, and am running > into a few technical hurdles I can not find answers to. > I am having a hard time finding any mailing lists that deal with the > technical/implementation side of things. > Can anyone recommend any decent, active technical IPv6 implementation > mailing lists? http://lists.cluenet.de/mailman/listinfo/ipv6-ops would be a decent start. From jonathan at qx.net Sat Aug 25 10:17:50 2007 From: jonathan at qx.net (Jonathan Barker) Date: Sat, 25 Aug 2007 10:17:50 -0400 Subject: [ppml] Free Market In-Reply-To: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> References: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> Message-ID: <46D03A0E.1080302@qx.net> All, I have a proposal. In an earlier e-mail someone made mention of the word 'oil'. IPv4 addresses are like oil, in that it is a finite resource, and one day... we will run out. The way our economic markets handle this is simple. Increase the price of oil. Allow economic demand to set the price, and as the price of oil increases, other, often environmentally friendlier technologies take hold. What if we increased the price of new ipv4 allocations, across the board - and altered the current pricing scheme, such that those with legacy /8s pay what they are truly worth. This would be an incentive for those who have large volumes of unused space just sitting there to get rid of it, but also allow growth and use for those who are willing to pay for it. IPv6 prices, of course, remain forever at rock bottom. If you inserted economics into it - you might see some large blocks being returned. I know of one ISP here in Lexington that has 130,000 legacy IPv4 addresses. They use... maybe 2000. In fact, if Arin were to turn down a request for me - they'd be my first stop. I'd buy a t-1, with a /19 attached. I can't use the T-1 of bandwidth - but I'd certainly advertize the space out my Gig-E or OC12 links. That is an example of what some of us have to do to get additional IPv4 space in a hurry. I know starting up, we had to get our address space from upstreams. When we'd cancel an upstream... .renumbering time! Now that we have ARIN space, we don't have to do that - but if ARIN can't assign it - I'll certainly 'buy' it from someone else using the method detailed above. Paying monthly for "bandwidth" but actually for IP space. So, one way or another when IPv4 becomes scares, restricted or unavailable, the market will handle it. Why not shift the burden now onto those who hold all those massive allocations, and use ARIN to regulate the price of IP space. Maybe we should even be fair about it, and charge a fee for each and every address assigned by Arin. I'd be happy with 30 cents, per IP address, per year. That would be a nice incentive for those who don't use their space, to return it. It would also speed the switchover to IPv6, by inserting an economic incentive to do so. That's my 30 cents. Jonathan From jonathan at qx.net Sat Aug 25 11:33:36 2007 From: jonathan at qx.net (Jonathan Barker) Date: Sat, 25 Aug 2007 11:33:36 -0400 Subject: [ppml] And as for assignments... Message-ID: <46D04BD0.505@qx.net> And to create a little controversy... For an additional 2 cents... a /46, /52, /64 - all of these are excessive for a home user. Our core router can handle 1,000,000 IPv4, and 500,000 IPv6 routes - and that's with today's technology. Our 7613 need not see all the routes we distribute to our DSL / Wireless customers. Those can / will be aggregated into blocks before they hit the core.. just as our aggregation routers don't see any public BGP routes. From there we'll aggregate again into our /32 prefix 2607:F100 - which is how the global Internet will see us. We'll probably end up assigning /120s to individual homes, where subnetting is likely to never occur, and multi-homing isn't a realistic possibility. I know with my current DirecTV, XBOX, PS3, Vista Media Centers at home all participating on my network, they do not like being in separate subnets. Everything is happiest when they do not need to go through any sort of routing appliance to get to each other. A single block of 256 addreses - that'd put every device in my house in a nice discrete container, and still let me add in my refrigerator, oven, lamps, water heater - what ever you'd actually want to assign an address to. That being said, even if people could assign v6 to every device in their home... Would you really want to? Do people really need to know or care that their water heater is currently on or off? Wouldn't it be a nice surprise to find that overnight, their water heater had been hacked - and it was now set to 'off' just before their morning shower? Personally, despite being a huge technophile who loves to use SNMP to graph power consumption, temperature, humidity... I really don't think I want my water heater on publicly addressable space. Assigning a /64 to a home... or 2^64th addresses... which is the number of IPv4 addreses available on the Internet today - SQUARED... Surely I'm not the only person who thinks that's just crazy. I understand the desire to decrease the number of routes. I can see if you have a just a regular Cisco sup720 you're probably worried about the health of your hardware due to the 256,000 IPv4 route limit - and the fact that we have 224,966 global BGP routes at the moment. But... isn't the best answer to upgrade the hardware that's causing the limit, rather than implementing a company-wide policy that will be deliberately wasteful forever? It's a whole lot easier to change out a supervisor card, and upgrade some aggregation routers, than to get all your customers to renumber because one day ARIN may realize that 2^64 addresses for a residence is a highly wasteful use of resources, and decides to deny an ISP's request to add another allocation. Having said all that - This e-mail has a definitely different take on the issue from most all the e-mails I've read. My question is - What is wrong with my logic, in that most people who are commenting don't think in these terms? Jonathan From jordi.palet at consulintel.es Sat Aug 25 11:55:36 2007 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 25 Aug 2007 17:55:36 +0200 Subject: [ppml] And as for assignments... In-Reply-To: <46D04BD0.505@qx.net> Message-ID: I think you don't have tried IPv6 too much ..., otherwise I don't understand why you want to use /120. IPv6 has features such as autoconfiguration, CGAs, privacy, etc., which need /64 in each segment. So you don't really want to provide anything smaller than a /64, unless we change the specs and implementations work with the new specs. Regards, Jordi > De: Jonathan Barker > Responder a: > Fecha: Sat, 25 Aug 2007 11:33:36 -0400 > Para: ARIN PPML > Asunto: [ppml] And as for assignments... > > And to create a little controversy... > > For an additional 2 cents... a /46, /52, /64 - all of these are > excessive for a home user. Our core router can handle 1,000,000 IPv4, > and 500,000 IPv6 routes - and that's with today's technology. Our 7613 > need not see all the routes we distribute to our DSL / Wireless > customers. Those can / will be aggregated into blocks before they hit > the core.. just as our aggregation routers don't see any public BGP > routes. From there we'll aggregate again into our /32 prefix 2607:F100 > - which is how the global Internet will see us. We'll probably end up > assigning /120s to individual homes, where subnetting is likely to never > occur, and multi-homing isn't a realistic possibility. I know with my > current DirecTV, XBOX, PS3, Vista Media Centers at home all > participating on my network, they do not like being in separate subnets. > Everything is happiest when they do not need to go through any sort of > routing appliance to get to each other. A single block of 256 addreses - > that'd put every device in my house in a nice discrete container, and > still let me add in my refrigerator, oven, lamps, water heater - what > ever you'd actually want to assign an address to. > > That being said, even if people could assign v6 to every device in their > home... Would you really want to? Do people really need to know or care > that their water heater is currently on or off? Wouldn't it be a nice > surprise to find that overnight, their water heater had been hacked - > and it was now set to 'off' just before their morning shower? > Personally, despite being a huge technophile who loves to use SNMP to > graph power consumption, temperature, humidity... I really don't think I > want my water heater on publicly addressable space. > > Assigning a /64 to a home... or 2^64th addresses... which is the number > of IPv4 addreses available on the Internet today - SQUARED... Surely I'm > not the only person who thinks that's just crazy. I understand the > desire to decrease the number of routes. I can see if you have a just a > regular Cisco sup720 you're probably worried about the health of your > hardware due to the 256,000 IPv4 route limit - and the fact that we have > 224,966 global BGP routes at the moment. But... isn't the best answer to > upgrade the hardware that's causing the limit, rather than implementing > a company-wide policy that will be deliberately wasteful forever? It's a > whole lot easier to change out a supervisor card, and upgrade some > aggregation routers, than to get all your customers to renumber because > one day ARIN may realize that 2^64 addresses for a residence is a highly > wasteful use of resources, and decides to deny an ISP's request to add > another allocation. > > Having said all that - This e-mail has a definitely different take on > the issue from most all the e-mails I've read. > > My question is - What is wrong with my logic, in that most people who > are commenting don't think in these terms? > > Jonathan > _______________________________________________ > 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. ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From arin-contact at dirtside.com Sat Aug 25 12:11:25 2007 From: arin-contact at dirtside.com (William Herrin) Date: Sat, 25 Aug 2007 12:11:25 -0400 Subject: [ppml] Free Market In-Reply-To: <46D03A0E.1080302@qx.net> References: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> <46D03A0E.1080302@qx.net> Message-ID: <3c3e3fca0708250911w11e7d3dbje5db53cc823bc3b0@mail.gmail.com> Jonathan, This has been discussed ad nauseum in recent months. Suggest you read the archives. The short version is: ARIN only controls a fraction of the address space. ARIN has no authority to apply fees or take any other action with respect to address space which has not been delegated to it by IANA. This includes ALL of the legacy /8s. ARIN has questionable authority to apply fees or take action with respect to address space under its control which was assigned prior to its existance, that is prior to 1997 or so. This has to do with elements of its charter which allowed it to inherit responsibility for parts of "the swamp." Within the remaining space where ARIN's authority is clear, there simply isn't enough waste to make it worth a recovery effort. If they made an effort anyway, their action in light of the address space not under their control would unfairly harm recent registrants who have been using space efficiently. IANA itself has questionable authority to take action with respect to the legacy /8's. While IANA is the defacto authority for number assignments that authority is not cemented by statute, contract or precedent. Indeed, more than a few /8's were assigned before IANA even existed. Regards, Bill Herrin On 8/25/07, Jonathan Barker wrote: > All, > > I have a proposal. In an earlier e-mail someone made mention of the word > 'oil'. IPv4 addresses are like oil, in that it is a finite resource, and > one day... we will run out. The way our economic markets handle this is > simple. Increase the price of oil. Allow economic demand to set the > price, and as the price of oil increases, other, often environmentally > friendlier technologies take hold. > > What if we increased the price of new ipv4 allocations, across the board > - and altered the current pricing scheme, such that those with legacy > /8s pay what they are truly worth. This would be an incentive for those > who have large volumes of unused space just sitting there to get rid of > it, but also allow growth and use for those who are willing to pay for > it. IPv6 prices, of course, remain forever at rock bottom. > > If you inserted economics into it - you might see some large blocks > being returned. I know of one ISP here in Lexington that has 130,000 > legacy IPv4 addresses. They use... maybe 2000. In fact, if Arin were to > turn down a request for me - they'd be my first stop. I'd buy a t-1, > with a /19 attached. I can't use the T-1 of bandwidth - but I'd > certainly advertize the space out my Gig-E or OC12 links. That is an > example of what some of us have to do to get additional IPv4 space in a > hurry. > > I know starting up, we had to get our address space from upstreams. When > we'd cancel an upstream... .renumbering time! Now that we have ARIN > space, we don't have to do that - but if ARIN can't assign it - I'll > certainly 'buy' it from someone else using the method detailed above. > Paying monthly for "bandwidth" but actually for IP space. > > So, one way or another when IPv4 becomes scares, restricted or > unavailable, the market will handle it. Why not shift the burden now > onto those who hold all those massive allocations, and use ARIN to > regulate the price of IP space. > > Maybe we should even be fair about it, and charge a fee for each and > every address assigned by Arin. I'd be happy with 30 cents, per IP > address, per year. That would be a nice incentive for those who don't > use their space, to return it. It would also speed the switchover to > IPv6, by inserting an economic incentive to do so. That's my 30 cents. > > Jonathan > _______________________________________________ > 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. > -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From paul at vix.com Sat Aug 25 12:17:11 2007 From: paul at vix.com (Paul Vixie) Date: Sat, 25 Aug 2007 16:17:11 +0000 Subject: [ppml] And as for assignments... In-Reply-To: Your message of "Sat, 25 Aug 2007 17:55:36 +0200." References: Message-ID: <60124.1188058631@sa.vix.com> > I think you don't have tried IPv6 too much ..., otherwise I don't understand > why you want to use /120. i use ipv6 today. > IPv6 has features such as autoconfiguration, CGAs, privacy, etc., which need > /64 in each segment. So you don't really want to provide anything smaller > than a /64, unless we change the specs and implementations work with the new > specs. i don't want or like any of those features. dhcpv6 works just fine. i use autoconf because i'm too lazy to switch over to dhcpv6. a /120 per LAN would be just fine for me if there weren't so much spec-inertia in the "/64 per LAN" ideology. that having been said, there's no way to put the IPv6 band back together at this late date. we're stuck with /64 per LAN, regardless of the goodness or badness of that design choice. i wish i'd known how to make A6/DNAME stick in the face of opposition the way "/64 per LAN" did, but that's a different war. From paul at vix.com Sat Aug 25 12:34:49 2007 From: paul at vix.com (Paul Vixie) Date: Sat, 25 Aug 2007 16:34:49 +0000 Subject: [ppml] Free Market In-Reply-To: Your message of "Sat, 25 Aug 2007 10:17:50 -0400." <46D03A0E.1080302@qx.net> References: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> <46D03A0E.1080302@qx.net> Message-ID: <65206.1188059689@sa.vix.com> > I have a proposal. In an earlier e-mail someone made mention of the word > 'oil'. IPv4 addresses are like oil, in that it is a finite resource, and > one day... we will run out. The way our economic markets handle this is > simple. Increase the price of oil. Allow economic demand to set the > price, and as the price of oil increases, other, often environmentally > friendlier technologies take hold. i think we'll be choking on the fumes of the oil we've already burned long before we can use up the earth's supply, which ought to counterbalance the price index. there's a fire burning in greece right now that they just can't seem to put out, and the iberian peninsula is in a sustained drought, and arctic ice is melting, and so on. burning the last drop of oil, at any price, seems unlikely at this stage. i mention this only because it's an absolutely perfect analogy to the real situation with IPv4. > What if we increased the price of new ipv4 allocations, across the board > - and altered the current pricing scheme, such that those with legacy > /8s pay what they are truly worth. This would be an incentive for those > who have large volumes of unused space just sitting there to get rid of > it, but also allow growth and use for those who are willing to pay for > it. IPv6 prices, of course, remain forever at rock bottom. the limitation isn't on address space, it's on routing table size. using the last ipv4 address will require that advertisements be much smaller than they are now, which would mean a routing table much larger than we have now. so, just as with oil the long term problem is carbon not supply, with IP the long term problem is routing not supply. > If you inserted economics into it - you might see some large blocks being > returned. I know of one ISP here in Lexington that has 130,000 legacy IPv4 > addresses. They use... maybe 2000. In fact, if Arin were to turn down a > request for me - they'd be my first stop. I'd buy a t-1, with a /19 > attached. I can't use the T-1 of bandwidth - but I'd certainly advertize > the space out my Gig-E or OC12 links. That is an example of what some of > us have to do to get additional IPv4 space in a hurry. how many /16's can be carved up into /19's before the global routing table exceeds the size of routers that other networks can afford? and if we get to that point, will it make sense to add another /19, no matter where you can get it from or at what price, given that it won't be globally reachable? > I know starting up, we had to get our address space from upstreams. When > we'd cancel an upstream... .renumbering time! Now that we have ARIN > space, we don't have to do that - but if ARIN can't assign it - I'll > certainly 'buy' it from someone else using the method detailed above. > Paying monthly for "bandwidth" but actually for IP space. so, provider-assigned (PA) has a provably bad short term economic model (it functions as a price lock due to its renumbering penalty), whereas provider- independent (PI) has a provably bad long term economic model (it blows out the routing table). which bad economic models would ARIN's community like to pursue? > So, one way or another when IPv4 becomes scares, restricted or > unavailable, the market will handle it. by moving the problem from "us" to "our grandchildren". just like with oil. > Why not shift the burden now onto those who hold all those massive > allocations, and use ARIN to regulate the price of IP space. that's actually an unrelated topic. nobody anywhere has the authority to impose revocation terms or prices on pre-RIR allocations, and that's where the majority of IPv4 space still is. From stephen at sprunk.org Sat Aug 25 12:20:01 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 25 Aug 2007 11:20:01 -0500 Subject: [ppml] And as for assignments... References: <46D04BD0.505@qx.net> Message-ID: <01b301c7e737$c2c61f10$6601a8c0@atlanta.polycom.com> Thus spake "Jonathan Barker" > And to create a little controversy... > > For an additional 2 cents... a /46, /52, /64 - all of these are > excessive for a home user. ... We'll probably end up assigning > /120s to individual homes, where subnetting is likely to never > occur, and multi-homing isn't a realistic possibility. I know with > my current DirecTV, XBOX, PS3, Vista Media Centers at > home all participating on my network, they do not like being in > separate subnets. Everything is happiest when they do not > need to go through any sort of routing appliance to get to > each other. Methinks you haven't played with v6 much; a subnet is /64 except in very specialized cases like PTP links or loopbacks. While it is _possible_ to do what you propose, you're going to lose a lot of the advantages of v6 and make life much more difficult for both you and your customers by doing this. What is stopping you from giving each customer a /64? With your /32, that means you can have up to 4B customers, which should be sufficient :) Why bother trying to assign less? v6 is not v4; there is no need to go to extreme lengths to limit subnet sizes. > My question is - What is wrong with my logic, in that most > people who are commenting don't think in these terms? Whether you agree with their logic or not, the IETF has designed IPv6 to work with /64 host subnets, and a lot of things are difficult to impossible if you don't follow that model. Even if you manage to get minimal services working, you're going to find a lot of bugs in vendors' implementations or not be able to use the more novel services if you insist on a non-standard subnet size. 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 iljitsch at muada.com Sat Aug 25 13:32:57 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sat, 25 Aug 2007 19:32:57 +0200 Subject: [ppml] Free Market In-Reply-To: <65206.1188059689@sa.vix.com> References: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> <46D03A0E.1080302@qx.net> <65206.1188059689@sa.vix.com> Message-ID: <6B85F36E-FB48-457B-A02F-017AC39DAE6C@muada.com> On 25-aug-2007, at 18:34, Paul Vixie wrote: >> Why not shift the burden now onto those who hold all those massive >> allocations, and use ARIN to regulate the price of IP space. Hm, so what if ARIN increases the price beyond cost, where does the profit go to? > that's actually an unrelated topic. nobody anywhere has the > authority to > impose revocation terms or prices on pre-RIR allocations, and > that's where > the majority of IPv4 space still is. Depends on your definition... This is the status of the usable IPv4 address space by /8: +---------+----------+ | free | 47 | | afrinic | 2 | | apnic | 24 | | arin | 27 | | iana | 42 | | lacnic | 4 | | ripencc | 26 | | various | 49 | +---------+----------+ "IANA" are the legacy /8s, which is only the third largest group, after the free space. However, if you include "various", which is the class B space and 193/8 and 198/8, then the legacy space adds up to 91 /8s. If you group the RIRs together that's 83 /8s. If you look at the numbers of addresses allocated things look slightly different (in millions of addresses): +---------+---------+ | free | 16.777 | | afrinic | 9.013 | | apnic | 352.349 | | arin | 380.182 | | iana | 687.866 | | lacnic | 51.817 | | ripencc | 365.825 | | various | 671.548 | +---------+---------+ (Yes, apparently it's possible to assign address space to an end-user even though it's listed as "reserved" = free by IANA.) Anyway, I don't buy all the "no authority" crap. If we can make people change their address and change their phone number if numbering plans change, there is precedence for touching legacy address space. Not that it matters much, because even if you reclaim EVERYTHING we'll still be out of IPv4 space before 2020 even ignoring growth in address use. From drc at virtualized.org Sat Aug 25 15:36:59 2007 From: drc at virtualized.org (David Conrad) Date: Sat, 25 Aug 2007 12:36:59 -0700 Subject: [ppml] Free Market In-Reply-To: <65206.1188059689@sa.vix.com> References: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> <46D03A0E.1080302@qx.net> <65206.1188059689@sa.vix.com> Message-ID: Paul, On Aug 25, 2007, at 9:34 AM, Paul Vixie wrote: > the limitation isn't on address space, it's on routing table size. My understanding is that the limitation is actually routing table flux, not size. > how many /16's can be carved up into /19's before the global > routing table > exceeds the size of routers that other networks can afford? All of them? Perhaps you meant a prefix longer than /19 since there are only 524,288 of them theoretically possible (much less in practice) and we're told we can handle "2M routes today, 10M with no change in technology" (if you believe your friendly router vendor). However, if what our friendly router vendors are telling us is true, the fact that you have a lot of prefixes in the routing system doesn't mean a whole lot. What matters is how often those prefixes bounce. The (perfectly reasonable) assumption is that the more prefixes you have, the more routing flux you'll get. Of course, using limitations on trading address space as a means to try to control this flux is a bit like trying to limit carbon emissions by blocking the sale of oil fields, but whatever. I guess if all you have is a sledgehammer, everything looks like a watermelon. > so, provider-assigned (PA) has a provably bad short term economic > model (it > functions as a price lock due to its renumbering penalty), whereas > provider- > independent (PI) has a provably bad long term economic model (it > blows out > the routing table). PI has a _presumed_ bad long term economic model if you assume there are no additional constraints on the flux in the routing system. As you are aware, in the past some ISPs have imposed additional constraints to protect their customers routability within their networks (namely prefix length filters and flap dampening). These measures had both positive and negative impacts but it isn't like "OMG End of The Internet WE'RE DOOMED" is a foregone conclusion. >> So, one way or another when IPv4 becomes scares, restricted or >> unavailable, the market will handle it. > by moving the problem from "us" to "our grandchildren". just like > with oil. With oil, or rather carbon dioxide (and perhaps less controversially, with sulphur dioxide) emissions, governments have implemented 'tradable emission allowances', a reasonable short summary of one done in the US is at http://www.house.gov/jec/cost-gov/regs/cost/ emission.htm. One could imagine an environment where routing slots are managed the same was as SO2 emissions, perhaps with a periodic review of the maximum allowable number of slots to track improvements in technology. Of course, to imagine this, you also have to imagine either government (which?) intervention or a level of cooperation in self-regulation amongst ISPs that stretches credulity. Sort of like getting global agreement on addressing climate change. Oh well. Regards, -drc From jonathan at qx.net Sat Aug 25 15:58:53 2007 From: jonathan at qx.net (Jonathan Barker) Date: Sat, 25 Aug 2007 15:58:53 -0400 Subject: [ppml] And as for assignments... In-Reply-To: <01b301c7e737$c2c61f10$6601a8c0@atlanta.polycom.com> References: <46D04BD0.505@qx.net> <01b301c7e737$c2c61f10$6601a8c0@atlanta.polycom.com> Message-ID: <46D089FD.3080100@qx.net> All who have responded, I basically asked "What's wrong with my logic" just to make sure I wasn't missing anything. I can do /64s... you're right, I have so much address space with just a /32 under v6 that I could serve 4 billion customers - a figure I can say with certainty I'll never attain. But, once upon a time, IPv4 didn't have classless routing capabilities. That was built in later. If there's demand, all these other features can surely be built in for smaller blocks as well, whether IETF standard or not... (if a couple of near monopolies agree, that is. ;-) By the time we get most of the Internet on v6 - who knows what v6 will actually look like. I suppose I've held a little too much conservatism over from IPv4 constraints, as I have been very constrained when it comes to IP addressing. We're the most IPv4 efficient ISP I know of - but I just cannot understand why a single family dwelling would ever need or want 2^64 addresses. It's just so phenomenally wasteful. It's a little like building a 20 Gigawatt nuclear power plant for each and every household who needs power to run their PC. :-) Jonathan > > Methinks you haven't played with v6 much; a subnet is /64 except in > very specialized cases like PTP links or loopbacks. While it is > _possible_ to do what you propose, you're going to lose a lot of the > advantages of v6 and make life much more difficult for both you and > your customers by doing this. > > What is stopping you from giving each customer a /64? With your /32, > that means you can have up to 4B customers, which should be sufficient > :) Why bother trying to assign less? v6 is not v4; there is no need > to go to extreme lengths to limit subnet sizes. > >> My question is - What is wrong with my logic, in that most >> people who are commenting don't think in these terms? > > Whether you agree with their logic or not, the IETF has designed IPv6 > to work with /64 host subnets, and a lot of things are difficult to > impossible if you don't follow that model. Even if you manage to get > minimal services working, you're going to find a lot of bugs in > vendors' implementations or not be able to use the more novel services > if you insist on a non-standard subnet size. > > 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 paul at vix.com Sat Aug 25 17:07:30 2007 From: paul at vix.com (Paul Vixie) Date: Sat, 25 Aug 2007 21:07:30 +0000 Subject: [ppml] Free Market In-Reply-To: Your message of "Sat, 25 Aug 2007 12:36:59 MST." References: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> <46D03A0E.1080302@qx.net> <65206.1188059689@sa.vix.com> Message-ID: <19779.1188076050@sa.vix.com> (warning-- it's the weekend and drc and i appear to be behaving sillily.) > My understanding is that the limitation is actually routing table flux, not > size. it's a little of both. you can tolerate a lot more flux in a small table than in a large one. and a large one is likely to have a lot more than a small one. so large is a generally good indicator of badness in routing tables, even though a large one that had no flux would be easy to handle, since a large one without flux is almost a contradiction in terms. > ... and we're told we can handle "2M routes today, 10M with no > change in technology" (if you believe your friendly router vendor). noone believes router vendors who say that, and since even if it were somehow unaccountably true it would require that everybody buy new routers during a credit crunch in a thin-margin business, and we limit participation in "the core" to the "subset of 'everybody'" who can afford such things in this decade, the table would not grow after all and so nobody would actually need the new routers. so i think we can stop bringing up this possibility. > > so, provider-assigned (PA) has a provably bad short term economic model > > (it functions as a price lock due to its renumbering penalty), whereas > > provider- independent (PI) has a provably bad long term economic model (it > > blows out the routing table). > > PI has a _presumed_ bad long term economic model if you assume there are no > additional constraints on the flux in the routing system. As you are aware, > in the past some ISPs have imposed additional constraints to protect their > customers routability within their networks (namely prefix length filters > and flap dampening). These measures had both positive and negative impacts > but it isn't like "OMG End of The Internet WE'RE DOOMED" is a foregone > conclusion. those constraints will modify the meaning of PI sufficiently that we'd be discussing it as a third possibility. universal PA won't work, universal PI won't work, a hybrid of PA+PI has gotten us this far, we don't think it'll get us to a future we'll like, and nobody has a specific proposal or vision for what future we might like or how to get there. sounds doomish to me. > With oil, or rather carbon dioxide (and perhaps less controversially, with > sulphur dioxide) emissions, governments have implemented 'tradable emission > allowances', a reasonable short summary of one done in the US is at > http://www.house.gov/jec/cost-gov/regs/cost/emission.htm. i also like . (i assume you meant the above as a joke, so i'm sharing one i find funnier.) > One could imagine an environment where routing slots are managed the same > was as SO2 emissions, perhaps with a periodic review of the maximum > allowable number of slots to track improvements in technology. one could imagine, as edmond rostand did in cyrano de bergerac, flying to the moon by six novel methods. i'd prefer blueprints to imaginings, however. > Of course, to imagine this, you also have to imagine either government > (which?) intervention or a level of cooperation in self-regulation amongst > ISPs that stretches credulity. Sort of like getting global agreement on > addressing climate change. Oh well. DE GUICHE (turning round): Six? CYRANO (volubly): First, with body naked as your hand, Festooned about with crystal flacons, full O' th' tears the early morning dew distils; My body to the sun's fierce rays exposed To let it suck me up, as 't sucks the dew! DE GUICHE (surprised, making one step toward Cyrano): Ah! that makes one! (http://encyclopediaindex.com/b/cdben10.htm) From randy at psg.com Sat Aug 25 17:21:05 2007 From: randy at psg.com (Randy Bush) Date: Sun, 26 Aug 2007 06:21:05 +0900 Subject: [ppml] Free Market In-Reply-To: References: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> <46D03A0E.1080302@qx.net> <65206.1188059689@sa.vix.com> Message-ID: <46D09D41.408@psg.com> David Conrad wrote: > we're told we can handle "2M routes today, 10M with no change in > technology" (if you believe your friendly router vendor). do so at the internet's peril. it's bs. randy From iljitsch at muada.com Sat Aug 25 18:46:06 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 26 Aug 2007 00:46:06 +0200 Subject: [ppml] And as for assignments... In-Reply-To: <46D089FD.3080100@qx.net> References: <46D04BD0.505@qx.net> <01b301c7e737$c2c61f10$6601a8c0@atlanta.polycom.com> <46D089FD.3080100@qx.net> Message-ID: <62538DDF-FE7F-422A-91E1-83395F2EFB0E@muada.com> On 25-aug-2007, at 21:58, Jonathan Barker wrote: > But, once upon a time, IPv4 didn't have classless routing > capabilities. > That was built in later. If there's demand, all these other > features can > surely be built in for smaller blocks as well Yes, and that's our insurance policy against running out of IPv6 addresses: when we make a mess of the upper 64 bits, we can slice and dice the lower 64 bits and still have a few billon times the address space of the IPv4 internet. > I suppose I've held a little too much conservatism over from IPv4 > constraints, as I have been very constrained when it comes to IP > addressing. We're the most IPv4 efficient ISP I know of - but I just > cannot understand why a single family dwelling would ever need or want > 2^64 addresses. It's just so phenomenally wasteful. You have to remember that IPv6 was designed a decade and a half ago, when things were very different from the way they are now. For instance, unless I'm mistaken, DHCP wasn't standardized until late 1993 and didn't come into wide use until some years later. So when the decisions about how IPv6 works were made, many, if not most, IPv4 systems were still configured with an address manually. We didn't have ethernet switching, or even the notion that at some point pretty much everything would run over some flavor of ethernet. So subnetting was necessary in many more cases than now. Also, other protocols than IP were still in common use. So it's not strange that IPv6 was outfitted with something very similar to the inclusion of the MAC address in the network layer address like IPX and CLNP do. (Although the IPv6 designers got a bit carried away and pretty much included ALL of the address configuration mechanisms present in ALL protocols in IPv6.) The advantage of including the MAC address is that a system gets the same address every time without the need to do complex stuff in a server to make this possible. If we were to design IPv6 today, it's certainly possible that we'd use 64-bit addresses with a /48 per end-user which can then accommodate 16 4096-address subnets or 256 256-address subnets or some other combination. Although it would be better to use variable length addresses. This has the advantage that we can be economic with address bits at first and deploy more of them as required. This could give us for IPvX what NAT gives us today: the ability to plug in a box, get an address, and then turn that address into multiple addresses for further downstream delegation. But then in an architecturally clean way. -- I've written another book! http://www.runningipv6.net/ From arin-contact at dirtside.com Sat Aug 25 19:33:57 2007 From: arin-contact at dirtside.com (William Herrin) Date: Sat, 25 Aug 2007 19:33:57 -0400 Subject: [ppml] Free Market In-Reply-To: <19779.1188076050@sa.vix.com> References: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> <46D03A0E.1080302@qx.net> <65206.1188059689@sa.vix.com> <19779.1188076050@sa.vix.com> Message-ID: <3c3e3fca0708251633l1e9a030al4f9f4ee45e7aecde@mail.gmail.com> On 8/25/07, Paul Vixie wrote: > those constraints will modify the meaning of PI sufficiently that we'd be > discussing it as a third possibility. universal PA won't work, universal PI > won't work, a hybrid of PA+PI has gotten us this far, we don't think it'll > get us to a future we'll like, and nobody has a specific proposal or vision > for what future we might like or how to get there. sounds doomish to me. Hi Paul, The friendly folks over on the rrg at psg.com list have made several specific proposals for disentangling PI space from BGP including LISP, Ivip, eFIT-APT and my own entry TRRP. They change how PI is routed but they don't change its function. I can't speak for the others, but mine lays out an incremental implementation plan which doesn't require everyone to jump on board all at once and where the folks involved experience a direct benefit from each step: http://bill.herrin.us/network/trrp-implementation.html Proposals and visions for the future are on the table. Its just a question of picking one and seeing it through. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From arin-contact at dirtside.com Sat Aug 25 20:33:23 2007 From: arin-contact at dirtside.com (William Herrin) Date: Sat, 25 Aug 2007 20:33:23 -0400 Subject: [ppml] And as for assignments... In-Reply-To: <46D04BD0.505@qx.net> References: <46D04BD0.505@qx.net> Message-ID: <3c3e3fca0708251733r5a3b4d33i810468919425cf8d@mail.gmail.com> On 8/25/07, Jonathan Barker wrote: > Assigning a /64 to a home... or 2^64th addresses... which is the number > of IPv4 addreses available on the Internet today - SQUARED... Surely I'm > not the only person who thinks that's just crazy. You're not the only one. A /64 is 65000 times the number of addresses than all of the globally unique ethernet MAC addresses ever assigned. You can assign an IP address to the fridge and every piece of food in it and still have an insane amount left over. The idea as I understood it was some sort of attempt to fix the PI/PA problem by making the final 64 bits static and the first 64 bits dynamic. Those final 64 bits would always come up the same no matter what subnet the IPv6 host was plugged into. It was actually a pretty clever idea, but it doesn't appear to have worked in the sense that it doesn't actually solve the PI/PA problem. Or maybe it was intended to eliminate ARP but it doesn't manage to do that either. You still have to advertise your MAC to IP mapping since folks can still manually assign explicit IPv6 addresses to an interface. The criminal part, though, is it consumes so many bits that it forecloses the possibility of solutions to PI like http://bill.herrin.us/network/ermpi6.html . Its waste on a scale that surpasses even the IPv4 multicast mistake. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From randy at psg.com Sat Aug 25 20:46:55 2007 From: randy at psg.com (Randy Bush) Date: Sun, 26 Aug 2007 09:46:55 +0900 Subject: [ppml] And as for assignments... In-Reply-To: <3c3e3fca0708251733r5a3b4d33i810468919425cf8d@mail.gmail.com> References: <46D04BD0.505@qx.net> <3c3e3fca0708251733r5a3b4d33i810468919425cf8d@mail.gmail.com> Message-ID: <46D0CD7F.2030700@psg.com> William Herrin wrote: > maybe it was intended to eliminate ARP but it doesn't manage to do > that either. You still have to advertise your MAC to IP mapping since > folks can still manually assign explicit IPv6 addresses to an interface. and manually assign an explicit mac to an interface. > The criminal part, though, is it consumes so many bits yes, but it has been granted a royal pardon. randy From drc at virtualized.org Sat Aug 25 21:16:25 2007 From: drc at virtualized.org (David Conrad) Date: Sat, 25 Aug 2007 18:16:25 -0700 Subject: [ppml] Free Market In-Reply-To: <19779.1188076050@sa.vix.com> References: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> <46D03A0E.1080302@qx.net> <65206.1188059689@sa.vix.com> <19779.1188076050@sa.vix.com> Message-ID: <87196C45-5E2B-4937-8FB5-8773AB20F8DA@virtualized.org> [last post of the weekend, must be better things to do with my time] Paul, On Aug 25, 2007, at 2:07 PM, Paul Vixie wrote: >> ... and we're told we can handle "2M routes today, 10M with no >> change in technology" (if you believe your friendly router vendor). > noone believes router vendors who say that, ... Actually, some do. Many in the IETF, for example, including some on the IAB. Some even on NANOG. Perhaps not so many on this mailing list but preaching to the choir is easier I suppose. > those constraints will modify the meaning of PI sufficiently that > we'd be > discussing it as a third possibility. "All PI" and "all PA" are merely theoretical extremes of the aggregation continuum. Right now, political/economic pressure is pushing us towards the PI side. Once it gets far enough to that side that people begin to seriously worry about their routers falling over, ISPs will take what steps they feel appropriate to protect their own infrastructure. This isn't new -- we've been here before and some of us still have the t-shirts. It is no more "doomish" than the original bout of CIDRization was back in the mid-90s. Annoying? Yes. Distressing, particularly to folks at the end of long prefixes? Sure. "Internet is DOOMED!!" No. Can we please throttle back on the FUD? >> With oil, or rather carbon dioxide (and perhaps less >> controversially, with >> sulphur dioxide) emissions, governments have implemented 'tradable >> emission >> allowances', a reasonable short summary of one done in the US is at >> http://www.house.gov/jec/cost-gov/regs/cost/emission.htm. > > i also like 963.html>. (i > assume you meant the above as a joke, so i'm sharing one i find > funnier.) Before ridiculing, you might want to try to understand what is being suggested. Or not. Regards, -drc From paul at vix.com Sat Aug 25 22:22:59 2007 From: paul at vix.com (Paul Vixie) Date: Sun, 26 Aug 2007 02:22:59 +0000 Subject: [ppml] Free Market In-Reply-To: Your message of "Sat, 25 Aug 2007 19:33:57 -0400." <3c3e3fca0708251633l1e9a030al4f9f4ee45e7aecde@mail.gmail.com> References: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> <46D03A0E.1080302@qx.net> <65206.1188059689@sa.vix.com> <19779.1188076050@sa.vix.com> <3c3e3fca0708251633l1e9a030al4f9f4ee45e7aecde@mail.gmail.com> Message-ID: <91032.1188094979@sa.vix.com> > The friendly folks over on the rrg at psg.com list have made several specific > proposals for disentangling PI space from BGP including LISP, Ivip, eFIT-APT > and my own entry TRRP. They change how PI is routed but they don't change > its function. I can't speak for the others, but mine lays out an incremental > implementation plan which doesn't require everyone to jump on board all at > once and where the folks involved experience a direct benefit from each > step: http://bill.herrin.us/network/trrp-implementation.html > > Proposals and visions for the future are on the table. Its just a question > of picking one and seeing it through. i may have misspoken. from an ARIN policy standpoint, vision doesn't matter. we deal here with things as they are, not with things as they might have been if IPv6 LANs weren't /64's or if the A6 RR had survived, and not with things as they might be if TRRP comes along. what we, here, must do, now, is decide to wait for better technology and stop trying to develop policy for present technology, or develop the best policy we can with the technology we've got. we could also, as a group, petition IETF for better technology, telling "them" the ways in which current technology is hard to develop policies for. and we could also, as individuals, attend IETF meetings and try to help "them" come up with better technology. the important thing "we" can't do "here" is make policy decisions based on technology that isn't an internet standard. From arin-contact at dirtside.com Sun Aug 26 01:13:57 2007 From: arin-contact at dirtside.com (William Herrin) Date: Sun, 26 Aug 2007 01:13:57 -0400 Subject: [ppml] Free Market In-Reply-To: <91032.1188094979@sa.vix.com> References: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> <46D03A0E.1080302@qx.net> <65206.1188059689@sa.vix.com> <19779.1188076050@sa.vix.com> <3c3e3fca0708251633l1e9a030al4f9f4ee45e7aecde@mail.gmail.com> <91032.1188094979@sa.vix.com> Message-ID: <3c3e3fca0708252213y3f3a6301gbac9a5b7457a40be@mail.gmail.com> On 8/25/07, Paul Vixie wrote: > the important thing "we" can't do "here" is make > policy decisions based on technology that isn't an internet standard. Paul, You're correct, of course. But you complained that: > nobody has a specific proposal or vision for what future we > might like or how to get there. sounds doomish to me. I thought I should point out that its only true within the context of ARIN policy interoperating with existing standards and practices. Once you step outside that box, there are more attainable paths through the darkness. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From michael.dillon at bt.com Sun Aug 26 04:55:11 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 26 Aug 2007 09:55:11 +0100 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 In-Reply-To: <20070824194743.GB26958@ussenterprise.ufp.org> References: <46C5E72F.2080903@arin.net><20070824150700.GB3558@ussenterprise.ufp.org><20070824153607.GC6207@ussenterprise.ufp.org><46CF24D3.4080000@ca.afilias.info> <20070824194743.GB26958@ussenterprise.ufp.org> Message-ID: > My policy says, "Here's the objective criteria ARIN staff > will use 50 years from now to give you your second prefix." Quite frankly, if that is the intent of your proposal then I am opposed to it, regardless of what it says. In 50 years it is rather unlikley that your proposal will survive untampered with. > So all Michael's policy would do would be to change the > application to be on requests 3-n, where as without it it > would apply to 2-n. Then you misunderstand my SUGGESTION. I was suggesting that an LIR could come back to ARIN and say, "We messed up our earlier IPv6 applications and would like to RETURN all previous IPv6 allocations and receive one single new IPv6 allocation that meets our overall needs.". And ARIN would say, "OK, sign this promise and return the old allocations in 6 months. Here is a big shiny new block for you.". Efficiency of the previous allocations is irrelevant since we DO NOT WANT THE LIR TO WAIT UNTIL THEY ARE FULLY USED. We do want the LIR to return the previous allocations, renumber and REDUCE THE TOTAL NUMBER OF IPv6 announcements in the global routing table. --Michael Dillon From michael.dillon at bt.com Sun Aug 26 05:14:44 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 26 Aug 2007 10:14:44 +0100 Subject: [ppml] And as for assignments... In-Reply-To: <46D04BD0.505@qx.net> References: <46D04BD0.505@qx.net> Message-ID: > For an additional 2 cents... a /46, /52, /64 - all of these > are excessive for a home user. This is by design. The IPv6 designers created an architecture in which home users, businesses and other organizations were all given far more addresses than they would NEED. This allows the network to grow by adding layers of heirarchy at any point. In-law suites, neighborhood wireless, gaming party subnets, etc. > I know with my current DirecTV, XBOX, > PS3, Vista Media Centers at home all participating on my > network, they do not like being in separate subnets. Strange. Internet access always crosses a subnet boundary going through one or more routers. IP does this by design. > Assigning a /64 to a home... or 2^64th addresses... which is > the number of IPv4 addreses available on the Internet today - > SQUARED... Surely I'm not the only person who thinks that's > just crazy. Of course you are not the only person. There are lots of people who learned about networking with IPv4 as the main protocol and IPv6 as a footnote. Most of these people will listen to advice and buy a book or two on IPv6 to learn how it is different from IPv4. > My question is - What is wrong with my logic, in that most > people who are commenting don't think in these terms? 1) You don't understand how IPv6 works. 2) Your suggestions amount to a redesign of IPv6 which may be appropriate discussion material on an IETF mailing list, but not here on ARIN lists. --Michael Dillon From michael.dillon at bt.com Sun Aug 26 07:41:43 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 26 Aug 2007 12:41:43 +0100 Subject: [ppml] IPv6 addresses really are scarce after all In-Reply-To: <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <46C613E0.8010909@bogus.com><46C629D2.20009@cs.utk.edu><17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com><46C6B5BB.5000203@cs.utk.edu><200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: > The definition of a small network is pretty much "single > subnet". Yes, I understand very well that the average home of > the future will have a mixed wiring. Of course, my own home > does have Ethernet and Wi-Fi. In the not so distant future, > it will have several Wi-Fi networks operating on different > frequencies, some form of power-line networking, and some > rooms may have their own high speed wireless wiring using UWB > or some similar technology. But I am pretty much convinced > that all of these will be organized as a single subnet. You are remarkably trusting. You do all your homebanking on the same subnet as your teenage children who are studying Hacking 101 in the privacy of their bedroom? And when guests come over for dinner, you have no objection to them taking their laptop to the bathroom in order to surf for child porn over your wireless network. The fact is that a lot of people will WANT subnets in the home. They will want a router/firewall that will isolate each of the children's bedrooms so that they cannot mess with your bank account or with their brother's/sister's romantic chat sessions. Many people will want all wireless access to go through a router. Many will have an in-law suite, and want to seamlessly integrate their relative's existing network via a simple router connection. And the family jewels, that Raid 5 server cluster that holds all the family photos and videos, will be behind another router/firewall. When the kids host a LAN party, the gamers will connect to the family network via a router/firewall with limited Internet access for only the necessary protocols. Subnets multiply for architectural and security reasons. Multiple subnets per home is *NOT* a waste of anything. It is an invitation to dreamers and inventors to make better network things for the home market. It is an enabler of business activity, an enabler of competition. --Michael Dillon From iljitsch at muada.com Sun Aug 26 10:13:18 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 26 Aug 2007 16:13:18 +0200 Subject: [ppml] Free Market In-Reply-To: <87196C45-5E2B-4937-8FB5-8773AB20F8DA@virtualized.org> References: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> <46D03A0E.1080302@qx.net> <65206.1188059689@sa.vix.com> <19779.1188076050@sa.vix.com> <87196C45-5E2B-4937-8FB5-8773AB20F8DA@virtualized.org> Message-ID: On 26-aug-2007, at 3:16, David Conrad wrote: > "All PI" and "all PA" are merely theoretical extremes of the > aggregation continuum. Right now, political/economic pressure is > pushing us towards the PI side. Once it gets far enough to that side > that people begin to seriously worry about their routers falling > over, ISPs will take what steps they feel appropriate to protect > their own infrastructure. Unfortunately, the way things are set up now, the only way to do that is very destructive: by kicking prefixes out of the routing table. And since all PI and PA blocks sit at the top of the aggregation hierarchy, once you filter such a prefix, it becomes unreachable. However, if we start giving out address space hiearchically, it is then possible to choose a level at which filtering happens and it's still possible to have reachability, although obviously things will have to work slightly differently than we're used to now. On 26-aug-2007, at 2:33, William Herrin wrote: > The criminal part, though, is it consumes so many bits that it > forecloses the possibility of solutions to PI Then you're not trying hard enough. It's entirely possible to create a hierarchical addressing model with only a modest fraction of the IPv6 address space. In this, I'm using (basically) two levels within 32 bits, which gives between 1 out of 4 to 1 out of 10 people on the planet a /48 PI block using only a /16: http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt Cue objections to geography in routing... However, you get to ignore geography if you don't want to aggregate, so if you can afford those big routers, it costs you nothing and it provides some insurance against the possibility that you won't be able to afford the big routers in the future. From owen at delong.com Sun Aug 26 11:08:23 2007 From: owen at delong.com (Owen DeLong) Date: Sun, 26 Aug 2007 08:08:23 -0700 Subject: [ppml] Free Market In-Reply-To: <6B85F36E-FB48-457B-A02F-017AC39DAE6C@muada.com> References: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> <46D03A0E.1080302@qx.net> <65206.1188059689@sa.vix.com> <6B85F36E-FB48-457B-A02F-017AC39DAE6C@muada.com> Message-ID: > > Anyway, I don't buy all the "no authority" crap. If we can make > people change their address and change their phone number if > numbering plans change, there is precedence for touching legacy > address space. Not that it matters much, because even if you reclaim > EVERYTHING we'll still be out of IPv4 space before 2020 even ignoring > growth in address use. Well... I think you are missing some key elements here... Phone Number changes: In order to have a phone number, you either ARE or have a business relationship with a LEC. The LEC has as part of their contract a provision for renumbering you in certain circumstances. If you are a LEC, then, you have a contract with NANPA which specifies similar terms, but, generally, you would actually be the one driving the renumbering anyway. Street Address changes: Street Addresses are, generally assigned by the local municipality, county, or parish (Louisiana). In this case, there is an actual government body with the authority to renumber your parcel. There's law behind such an action. Internet Addresses assigned by pre-RIR registries: There is no contract. There is no law to support renumbering by a current registry. There is no clear inheritance to the RIR of any form of AUTHORITY over said assignments/allocations. There is a clear successor record-keeper role, but, that is not the same as authority. So, given those differences, I do not think your oversimplification of the issue to "if we can renumber telephones and streets, then, we must be able to renumber IP" holds water. Owen From iljitsch at muada.com Sun Aug 26 11:23:07 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 26 Aug 2007 17:23:07 +0200 Subject: [ppml] Free Market In-Reply-To: References: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> <46D03A0E.1080302@qx.net> <65206.1188059689@sa.vix.com> <6B85F36E-FB48-457B-A02F-017AC39DAE6C@muada.com> Message-ID: On 26-aug-2007, at 17:08, Owen DeLong wrote: > Phone Number changes: > In order to have a phone number, you either ARE or have a > business relationship with a LEC. The LEC has as part of their > contract a provision for renumbering you in certain circumstances. I somehow doubt that this has been in all the contracts since the Bell company started doing business in the 19th century. As I've said before, I don't think large scale reclaiming is going to do all that much for us, but if it would, I can't believe that lack of a few signatures would be enough to stiffle the growth of the world wide internet that has already become crucial to the economy of many countries. Not sure how it works in the US, but here in Holland if they want to build a railway through your property, the government CAN take that property away from you under some circumstances. From jonathan at qx.net Sun Aug 26 11:45:08 2007 From: jonathan at qx.net (Jonathan Barker) Date: Sun, 26 Aug 2007 11:45:08 -0400 Subject: [ppml] And as for assignments... In-Reply-To: References: <46D04BD0.505@qx.net> Message-ID: <46D1A004.2020402@qx.net> michael.dillon at bt.com wrote: > This is by design. The IPv6 designers created an architecture in which > home users, businesses and other organizations were all given far more > addresses than they would NEED. This allows the network to grow by > adding layers of heirarchy at any point. In-law suites, neighborhood > wireless, gaming party subnets, etc. > Michael, It's poor design then. As Iljitsch astutely observed, IPv6 was designed years ago, before DHCP came into widespread use. Stateless Autoconfiguration, While a nice thought - can be simply DHCP from the router you have to use at your home to terminate V6. Sparse host - You know - for years people have launched bots to scan the network for open hosts to infect. Now - they have infinitely more space to scan, and have to transmit more and larger packets to do it. With ever increasing processor power... Bot scanning and the massive number of packets now needed to scan for hosts could become a real problem. I think firewalls on those home routers are a better idea. Privacy Addresses - The US Government has a nice little law called the Communications Assistance for Law Enforcement Act. CALEA. I have to be able to wiretap my customers. It's the law. The privacy addresses will just make it a little more difficult to isolate what's what for big brother. >> I know with my current DirecTV, XBOX, >> PS3, Vista Media Centers at home all participating on my >> network, they do not like being in separate subnets. >> > > Strange. Internet access always crosses a subnet boundary going through > one or more routers. IP does this by design. > Broadcast traffic that allows Media Extenders to auto discover one another does not cross subnets. (no one would want it to.) Get an XBOX, PS3, Vista Media Center, and something from Sky and try it yourself. This is an example of Real World vs. Theory. It doesn't matter if you can connect to an XBOX media extender across continents using some customized programs / settings. If it's not easy, 99.9% of real people will be unable to use the feature. So - keep your XBOX in the same subnet as your Media Center. > > Of course you are not the only person. There are lots of people who > learned about networking with IPv4 as the main protocol and IPv6 as a > footnote. Most of these people will listen to advice and buy a book or > two on IPv6 to learn how it is different from IPv4. > A book that will be outdated in 3 years. >> My question is - What is wrong with my logic, in that most >> people who are commenting don't think in these terms? >> > > 1) You don't understand how IPv6 works. > > 2) Your suggestions amount to a redesign of IPv6 which may be > appropriate discussion material on an IETF mailing list, but not here on > ARIN lists. > 1) I understand how it *should* work with what technology we have today. 2) Ideas regarding the assignment and allocation of IP space - particularly when it pertains to providers needing 2nd or 3rd IPv6 allocations - simply due to wasteful subnet requirements - are perfectly suited to the ARIN mailing list. Jonathan From jonathan at qx.net Sun Aug 26 11:58:08 2007 From: jonathan at qx.net (Jonathan Barker) Date: Sun, 26 Aug 2007 11:58:08 -0400 Subject: [ppml] IPv6 addresses really are scarce after all In-Reply-To: References: <46C613E0.8010909@bogus.com><46C629D2.20009@cs.utk.edu><17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com><46C6B5BB.5000203@cs.utk.edu><200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <46D1A310.2030506@qx.net> michael.dillon at bt.com wrote: >> The definition of a small network is pretty much "single >> subnet". Yes, I understand very well that the average home of >> the future will have a mixed wiring. Of course, my own home >> does have Ethernet and Wi-Fi. In the not so distant future, >> it will have several Wi-Fi networks operating on different >> frequencies, some form of power-line networking, and some >> rooms may have their own high speed wireless wiring using UWB >> or some similar technology. But I am pretty much convinced >> that all of these will be organized as a single subnet. >> > > You are remarkably trusting. You do all your homebanking on the same > subnet as your teenage children who are studying Hacking 101 in the > privacy of their bedroom? And when guests come over for dinner, you have > no objection to them taking their laptop to the bathroom in order to > surf for child porn over your wireless network. > Umm.... Most people have trouble figuring out how to connect their HD TV systems. A media center is advanced... Subnetting a house to prevent sniffing? That will be reserved for the households headed by Mensa members, and or/ IT professionals who use encryption on their online banking sessions anyway. Besides, if someone in the house want the online banking info - they'll just go get the bankcard from the parent's wallet - then they'll have what they need to just reset the password themselves. Or better yet, just lift a few 20s out of there the old fashioned way. Laptop to the bathroom for porn... that made me lol. If they want that - they'll probably use their mobile broadband connection, rather than try to log on to the local wireless network. Of course, if my houseguest is taking a laptop to the bathroom - I'm going to be asking "What's up?" anyway. > The fact is that a lot of people will WANT subnets in the home. They > will want a router/firewall that will isolate each of the children's > bedrooms so that they cannot mess with your bank account or with their > brother's/sister's romantic chat sessions. Many people will want all > wireless access to go through a router. Many will have an in-law suite, > and want to seamlessly integrate their relative's existing network via a > simple router connection. And the family jewels, that Raid 5 server > cluster that holds all the family photos and videos, will be behind > another router/firewall. When the kids host a LAN party, the gamers will > connect to the family network via a router/firewall with limited > Internet access for only the necessary protocols. Subnets multiply for > architectural and security reasons. > No. People won't do that. Getting people to put WEP / WPA on their access points is hard enough. Firewall and password is all we can hope for there. > Multiple subnets per home is *NOT* a waste of anything. It is an > invitation to dreamers and inventors to make better network things for > the home market. It is an enabler of business activity, an enabler of > competition. > It's not a waste. If they're /124 subnets. :-) Jonathan From stephen at sprunk.org Sun Aug 26 11:54:38 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 26 Aug 2007 10:54:38 -0500 Subject: [ppml] Free Market References: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com><46D03A0E.1080302@qx.net> <65206.1188059689@sa.vix.com><6B85F36E-FB48-457B-A02F-017AC39DAE6C@muada.com> Message-ID: <067d01c7e7fa$be305fb0$6601a8c0@atlanta.polycom.com> Thus spake "Iljitsch van Beijnum" > As I've said before, I don't think large scale reclaiming is going > to do all that much for us, but if it would, I can't believe that lack > of a few signatures would be enough to stiffle the growth of the > world wide internet that has already become crucial to the > economy of many countries. > > Not sure how it works in the US, but here in Holland if they want > to build a railway through your property, the government CAN > take that property away from you under some circumstances. It's called "eminent domain" here; various governmental units (and a few private ones, like utilities and railroads) can forcibly acquire your property in return for the fair value if you refuse to sell. The use of eminent domain is sometimes called a "taking". However, ARIN does not have the power of eminent domain, and it's unclear anyways that the government has the power to forcibly acquire sets of integers, which are rather different than real estate. OTOH, there's also no law that says ARIN, as a registry, is required to "remember" the registrations of integers that it doesn't have a contract for. Since integers are not property, there's not really much parallel with eminent domain, since ARIN "forgetting" legacy registrations would not be a "taking". You can't take a number away from someone. How could anyone, even a government, revoke your right to use the number 13, for instance? ( There are interesting intersection with the AACS LA here: they claim ownership of an unspecified number of 128-bit integers, and they also claim they'll sue anyone who uses those numbers in certain ways. I doubt the courts will find that argument meritorious, especially since people can't know whether or not a particular integer is "owned" by the AACS LA because they refuse to list them. ) None of this stops people from litigating the matter, of course, if we do things they don't like. However, we've been told to make policy as if such things were not a problem and leave it to counsel to sort out. If we want to propose a policy that revokes all legacy registrations (not that I'm endorsing that), we can do that. The BoT is free to shoot it down if the legal risks outweigh the benefits, but that is not our problem here on PPML unless and until that happens. 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 arin-contact at dirtside.com Sun Aug 26 13:59:36 2007 From: arin-contact at dirtside.com (William Herrin) Date: Sun, 26 Aug 2007 13:59:36 -0400 Subject: [ppml] Free Market In-Reply-To: References: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> <46D03A0E.1080302@qx.net> <65206.1188059689@sa.vix.com> <19779.1188076050@sa.vix.com> <87196C45-5E2B-4937-8FB5-8773AB20F8DA@virtualized.org> Message-ID: <3c3e3fca0708261059g5a8efae0pa4c7291ba4a242cb@mail.gmail.com> On 8/26/07, Iljitsch van Beijnum wrote: > It's entirely possible to create > a hierarchical addressing model with only a modest fraction of the > IPv6 address space. [...] > Cue objections to geography in routing... However, you get to ignore > geography if you don't want to aggregate, so if you can afford those > big routers, it costs you nothing and it provides some insurance Iljitsch, The topology of the Internet hasn't been hierarchical since the dissolution of the NSFnet and every passing day sees greater geographic dispersion of connections in the graph. Its quickly getting to the point where even mere mortals can afford to lease transatlantic fiber. Even a decade ago it was naive to think that topological aggregation could be made to work, whether geographic or otherwise. With today's traffic engineering requirements (and the economic pressure for better traffic engineering if only it was possible), the argument that aggregation can still work is just plain intransigent. I read your geoaggregation paper. You don't give the multihomed end users or their ISPs any choice over which carrier moves their packets across the sea and you fail to address what economic structure allows the carrier who does move their packets across the ocean to get paid. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From arin-contact at dirtside.com Sun Aug 26 14:55:09 2007 From: arin-contact at dirtside.com (William Herrin) Date: Sun, 26 Aug 2007 14:55:09 -0400 Subject: [ppml] And as for assignments... In-Reply-To: <46D1A004.2020402@qx.net> References: <46D04BD0.505@qx.net> <46D1A004.2020402@qx.net> Message-ID: <3c3e3fca0708261155y7a8b18a4qb7d898796d12dd6f@mail.gmail.com> On 8/26/07, Jonathan Barker wrote: > for years people have launched bots to scan the network for open > hosts to infect. Now - they have infinitely more space to scan, and have > to transmit more and larger packets to do it. With ever increasing > processor power... Bot scanning and the massive number of packets now > needed to scan for hosts could become a real problem. Jonathan, I think you have this backwards. The massive size of the subnet will make it impractical to scan for hosts off the local subnet, regardless of the available bandwidth and processor power. Its an unintended but useful consequence of the large subnet size. Worms will have to look for other cues to find addresses to infect, such as publicly posted http transaction logs. That will tend to blunt their spread a bit. On the flip side, I can remotely identify the make and model of the ethernet card from the MAC address encoded in the IP address which ought to make it much easier to target driver bugs. For example, I can trivially tell that 6to4.nro.net (2001:dc0:2001:7:2d0:b7ff:feb7:f7f9) is using a NIC made by Intel (MAC 00-d0-b7-b7-f7-f9). With a better MAC database than what I found in 5 minutes of searching, I could figure out which model Intel NIC, when it was made and what revision of the firmware it shipped with. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From jonathan at qx.net Sun Aug 26 17:28:34 2007 From: jonathan at qx.net (Jonathan Barker) Date: Sun, 26 Aug 2007 17:28:34 -0400 Subject: [ppml] And as for assignments... In-Reply-To: <3c3e3fca0708261155y7a8b18a4qb7d898796d12dd6f@mail.gmail.com> References: <46D04BD0.505@qx.net> <46D1A004.2020402@qx.net> <3c3e3fca0708261155y7a8b18a4qb7d898796d12dd6f@mail.gmail.com> Message-ID: <46D1F082.1040204@qx.net> William, Today, you're completely right... It would be impractical to scan a /64. There are too many numbers for today's hardware, and internet connections. But, it was once very difficult to break 128 bit encryption, too. As years pass by, systems get ever more powerful, and people get Gig-E at home (Which with E-band wireless (I'm a big Bridgewave fan) and FiOS, actually gets easier by the day) maybe it'll get a little easier. Then, let's say you have a worm that only attacks Sun Solaris OS boxes. You can check online MAC databases and get this. Search results for "Sun Microsystems" * MAC Address Prefix Vendor* 00007D Sun Microsystems (was: Cray Research Superservers,Inc) 00015D Sun Microsystems, Inc. (was: Pirus Networks) 0003BA Sun Microsystems 00144F Sun Microsystems, Inc 0020F2 SUN MICROSYSTEMS, 080020 Sun Microsystems Inc. Or, maybe you have a vulnerability that affects Directv's new MPEG-4 set top boxes - 00189B Thomson Inc. It could take a little while, but you could find mine. 00:18:9B:F0:F0:E4 Or better yet, target my Playstation 3. It is sitting here in my living room, on Gig-E to the Internet via my Bridgewave, Folding proteins. With 7 blazing fast cores, and the ability to run Linux - it would be an excellent attack system. (I do firewall all this, btw...) Using the MAC database could narrow the /64 considerably, by giving you part of the address without needing to do a blanket scan. And if you add a few logical assumptions, like that ISPs will start allocating at the beginning of their /32 first, and go up a /62 at a time, it gets easier and easier. Viruses and worms could in theory methodically target the hardware they want more efficiently. Or by using the address of a known server, they could determine the make / model (which for the most part can be done today, anyway) and find a vulnerability specifically designed for it. I've brainstormed this one for a few minutes. There are hackers out there that will spend years on the problem. A well designed worm that replicates, and increases it's efficiency with each new installation by only scanning a pre-set area per infection could be devastating. Imagine a million networked Playstations targeting the Internet's core infrastructure all at once. We wouldn't stand a chance. Double edged sword, I guess. Much like cdp (Cisco Discovery Protocol)... Using autoconfiguration is useful now for diagnostics, and good against non-directed general DoS attacks like slammer, but may speed more directed, and more dangerous attacks in the future, by giving away more info than system administrators would like about their systems. Jonathan William Herrin wrote: > On 8/26/07, Jonathan Barker wrote: > >> for years people have launched bots to scan the network for open >> hosts to infect. Now - they have infinitely more space to scan, and have >> to transmit more and larger packets to do it. With ever increasing >> processor power... Bot scanning and the massive number of packets now >> needed to scan for hosts could become a real problem. >> > > Jonathan, > > I think you have this backwards. The massive size of the subnet will > make it impractical to scan for hosts off the local subnet, regardless > of the available bandwidth and processor power. Its an unintended but > useful consequence of the large subnet size. Worms will have to look > for other cues to find addresses to infect, such as publicly posted > http transaction logs. That will tend to blunt their spread a bit. > > On the flip side, I can remotely identify the make and model of the > ethernet card from the MAC address encoded in the IP address which > ought to make it much easier to target driver bugs. For example, I can > trivially tell that 6to4.nro.net (2001:dc0:2001:7:2d0:b7ff:feb7:f7f9) > is using a NIC made by Intel (MAC 00-d0-b7-b7-f7-f9). With a better > MAC database than what I found in 5 minutes of searching, I could > figure out which model Intel NIC, when it was made and what revision > of the firmware it shipped with. > > Regards, > Bill Herrin > > > > > From bmanning at vacation.karoshi.com Sun Aug 26 20:23:25 2007 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 27 Aug 2007 00:23:25 +0000 Subject: [ppml] what to do w/ the bottom 64bits Message-ID: <20070827002325.GA709@vacation.karoshi.com.> there are folks trying to figure out what to do w/ the bottom 64bits of an IPv6 address... Here is another one. www.cs.st-andrews.ac.uk/~saleem/papers/2006/lcs/ilnp/ab2006.pdf --bill From terry.l.davis at boeing.com Mon Aug 27 10:04:14 2007 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Mon, 27 Aug 2007 07:04:14 -0700 Subject: [ppml] IPv6 addresses really are scarce after all In-Reply-To: References: <46C613E0.8010909@bogus.com><46C629D2.20009@cs.utk.edu><17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com><46C6B5BB.5000203@cs.utk.edu><200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com><70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <0D090F1E0F5536449C7E6527AFFA280A03685B20@XCH-NW-8V1.nw.nos.boeing.com> Michael Agree. And don't forget that your: - power company - communication/entertainment provider/s - alarm/monitoring company - local government - EMS All have at least discussions in progress that would give each home/apartment a subnet (albeit possibly/probably on different networks) for there use as a home service provider. Take care Terry > -----Original Message----- > From: michael.dillon at bt.com [mailto:michael.dillon at bt.com] > Sent: Sunday, August 26, 2007 4:42 AM > To: ppml at arin.net; address-policy-wg at ripe.net; ietf at ietf.org > Subject: Re: [ppml] IPv6 addresses really are scarce after all > > > The definition of a small network is pretty much "single > > subnet". Yes, I understand very well that the average home of > > the future will have a mixed wiring. Of course, my own home > > does have Ethernet and Wi-Fi. In the not so distant future, > > it will have several Wi-Fi networks operating on different > > frequencies, some form of power-line networking, and some > > rooms may have their own high speed wireless wiring using UWB > > or some similar technology. But I am pretty much convinced > > that all of these will be organized as a single subnet. > > You are remarkably trusting. You do all your homebanking on the same > subnet as your teenage children who are studying Hacking 101 in the > privacy of their bedroom? And when guests come over for dinner, you have > no objection to them taking their laptop to the bathroom in order to > surf for child porn over your wireless network. > > The fact is that a lot of people will WANT subnets in the home. They > will want a router/firewall that will isolate each of the children's > bedrooms so that they cannot mess with your bank account or with their > brother's/sister's romantic chat sessions. Many people will want all > wireless access to go through a router. Many will have an in-law suite, > and want to seamlessly integrate their relative's existing network via a > simple router connection. And the family jewels, that Raid 5 server > cluster that holds all the family photos and videos, will be behind > another router/firewall. When the kids host a LAN party, the gamers will > connect to the family network via a router/firewall with limited > Internet access for only the necessary protocols. Subnets multiply for > architectural and security reasons. > > Multiple subnets per home is *NOT* a waste of anything. It is an > invitation to dreamers and inventors to make better network things for > the home market. It is an enabler of business activity, an enabler of > competition. > > --Michael Dillon > _______________________________________________ > 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 iljitsch at muada.com Mon Aug 27 10:43:30 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 27 Aug 2007 16:43:30 +0200 Subject: [ppml] Free Market In-Reply-To: <3c3e3fca0708261059g5a8efae0pa4c7291ba4a242cb@mail.gmail.com> References: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> <46D03A0E.1080302@qx.net> <65206.1188059689@sa.vix.com> <19779.1188076050@sa.vix.com> <87196C45-5E2B-4937-8FB5-8773AB20F8DA@virtualized.org> <3c3e3fca0708261059g5a8efae0pa4c7291ba4a242cb@mail.gmail.com> Message-ID: On 26-aug-2007, at 19:59, William Herrin wrote: > The topology of the Internet hasn't been hierarchical since the > dissolution of the NSFnet and every passing day sees greater > geographic dispersion of connections in the graph. That doesn't matter. The point is that you get to express the set of destinations that sit behind a particular connection with as few bits as possible. So if you have a prefix that means "Europe" then you can route that one prefix over your transatlantic link instead of 20000 prefixes for 20000 European destinations. In practice, it's not going to be _that_ simple, but even if you get to route one aggregate and you have to make 4000 exceptions, you've saved 80%. > Its quickly getting > to the point where even mere mortals can afford to lease transatlantic > fiber. But strangely, they can't afford to lease a fiber from their home or business to the place where the transatlantic fiber sticks out of the ocean... Still, it's incredibly inefficient to route all your traffic across an ocean so few people do it if they have the choice. > With today's traffic engineering requirements (and the economic > pressure for better traffic engineering if only it was possible), the > argument that aggregation can still work is just plain intransigent. We can argue about that, but it's not relevant to the problem of allowing millions of users to multihome. Those millions aren't going to lease intercontinental fibers or even do complex traffic engineering, they'll just get cable and DSL and type a router config from a book if they have to. > I read your geoaggregation paper. You don't give the multihomed end > users or their ISPs any choice over which carrier moves their packets > across the sea and you fail to address what economic structure allows > the carrier who does move their packets across the ocean to get paid. For outgoing traffic, nothing changes. For incoming traffic, you don't get to influence much today anyway so not much changes there either. The big difference (that I do talk about extensively) is that with this aggregation, you get "cold potato" routing rather than "hot potato" routing. Although this changes some things I don't think it's a fundamentally different economic model. You still have peering and transit the way we have today. From arin-contact at dirtside.com Mon Aug 27 11:45:40 2007 From: arin-contact at dirtside.com (William Herrin) Date: Mon, 27 Aug 2007 11:45:40 -0400 Subject: [ppml] Free Market In-Reply-To: References: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> <46D03A0E.1080302@qx.net> <65206.1188059689@sa.vix.com> <19779.1188076050@sa.vix.com> <87196C45-5E2B-4937-8FB5-8773AB20F8DA@virtualized.org> <3c3e3fca0708261059g5a8efae0pa4c7291ba4a242cb@mail.gmail.com> Message-ID: <3c3e3fca0708270845g3794432ds8788165a72eed93c@mail.gmail.com> On 8/27/07, Iljitsch van Beijnum wrote: > Although this changes some things I don't think it's > a fundamentally different economic model. You still have peering and > transit the way we have today. Iljitsch, Here's the economic problem you haven't adequately addressed: NL gets a regional route. Lets say 10.128.0.0/10 US gets a regional route. Lets say 10.192.0.0/10 Fred and George are NL customers with 10.128.0.0/24 and 10.128.1.0/24 respectively. Sam and Tom are US customers with 10.192.0.0/24 and 10.192.1.0/24 respectively. Alice and Becky are NL ISPs connecting Fred and George respectively. Christie and Debbie are US ISPs connecting Sam and Tom respectively. Jenny and Kim are transatlantic providers. Jenny connects Alice and Christie to each other while Kim connects Becky and Debbie to each other. Alice and Becky peer. Alice announces 10.128.0.0/24 to Becky. Becky announces 10.128.1.0/24 to Alice. Alice announces 10.128.0.0/10 to Jenny. Becky announces 10.128.0.0/10 to Kim. Christie and Debbie peer. Christie announces 10.192.0.0/24 to Debbie and Debbie announces 10.192.1.0/24 to Christie. Christie announces 10.192.0.0/10 to Jenny. Debbie announces 10.192.0.0/10 to Kim. This is a complete routing structure that works on a technical level as envisioned in your geoaggregation paper. Fred at 10.128.0.1 sends a packet to Tom at 10.192.1.1. Fred hands the packet to Alice. Alice hands the packet to Jenny. Jenny hands the packet to Christie. Christie hands the packet to Debbie. Debbie hands the packet to Tom. Fred pays Alice to transmit his packets. Alice pays Jenny to transmit Fred's packets. Tom pays Debbie to receive his packets. WHO PAYS CHRISTIE to transmit or receive packets associated with Tom and Fred? In every peering relationship on the Internet today, someone pays. Traffic doesn't come in one peer and then out another. Traffic never ever comes in a paid link and then out a reciprocal peer. For any given packet, at least one of the endpoints is associated with either the entity itself or one of its paying customers. Your proposal breaks this economic model and offers nothing with which to replace it. If that isn't problem enough, what happens if Christie and Jenny are low cost bottom feeders with bad packet loss while Debbie and Kim are a high-cost, high quality providers? Even though Tom is paying for quality, Fred won't pass his packets to George and then Kim... Unless they all ignore the aggregate routes and announce the longer prefixes too, making the whole thing a colossal waste of effort. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From iljitsch at muada.com Mon Aug 27 12:31:15 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 27 Aug 2007 18:31:15 +0200 Subject: [ppml] Free Market In-Reply-To: <3c3e3fca0708270845g3794432ds8788165a72eed93c@mail.gmail.com> References: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> <46D03A0E.1080302@qx.net> <65206.1188059689@sa.vix.com> <19779.1188076050@sa.vix.com> <87196C45-5E2B-4937-8FB5-8773AB20F8DA@virtualized.org> <3c3e3fca0708261059g5a8efae0pa4c7291ba4a242cb@mail.gmail.com> <3c3e3fca0708270845g3794432ds8788165a72eed93c@mail.gmail.com> Message-ID: <417064A5-1439-47B4-86A7-424C31C19A63@muada.com> On 27-aug-2007, at 17:45, William Herrin wrote: > Here's the economic problem you haven't adequately addressed: [...] Sorry, this is way too complex for me to be able to keep straight in my head. However, the point is that all ISPs announce to everyone everywhere where they peer all the prefixes of their customers and customer's customers. So the aggregation only happens inside an AS and is invisible from the outside. I suspect that in the topology you came up with, it's not possible to do aggregation on the transatlantic link because that way, the thing that you think happens would indeed happen: someone would have to carry the traffic for free. That's not an option, so this means you can't here. However, Christie and Debbie still get to direct all their traffic for NL to the routers in their networks that connect to transatlantic transits. I.e., a router in San Diego doesn't need NL prefixes. > making the whole thing a colossal waste of effort. There is no effort until you implement aggregation. Presumably, people will only start to implement the aggregation when it buys them something and not before. Without aggregation it's all just regular PI that customers like so much. From paul at vix.com Mon Aug 27 12:42:50 2007 From: paul at vix.com (Paul Vixie) Date: Mon, 27 Aug 2007 16:42:50 +0000 Subject: [ppml] Free Market In-Reply-To: Your message of "Mon, 27 Aug 2007 18:31:15 +0200." <417064A5-1439-47B4-86A7-424C31C19A63@muada.com> References: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> <46D03A0E.1080302@qx.net> <65206.1188059689@sa.vix.com> <19779.1188076050@sa.vix.com> <87196C45-5E2B-4937-8FB5-8773AB20F8DA@virtualized.org> <3c3e3fca0708261059g5a8efae0pa4c7291ba4a242cb@mail.gmail.com> <3c3e3fca0708270845g3794432ds8788165a72eed93c@mail.gmail.com> <417064A5-1439-47B4-86A7-424C31C19A63@muada.com> Message-ID: <42852.1188232970@sa.vix.com> > > Here's the economic problem you haven't adequately addressed: > > [...] > > Sorry, this is way too complex for me to be able to keep straight in > my head. > > [...] i suggest printing william's message out, taking it with you everywhere, diagramming the nodes and flows, and making every possible effort to understand it. the internet is a complicated place to make policy for. From michael.dillon at bt.com Mon Aug 27 16:01:41 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 27 Aug 2007 21:01:41 +0100 Subject: [ppml] IPv6 addresses really are scarce after all In-Reply-To: <46D1A310.2030506@qx.net> References: <46C613E0.8010909@bogus.com><46C629D2.20009@cs.utk.edu><17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com><46C6B5BB.5000203@cs.utk.edu><200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <46D1A310.2030506@qx.net> Message-ID: > Subnetting > a house to prevent sniffing? That will be reserved for the > households headed by Mensa members, and or/ IT professionals > who use encryption on their online banking sessions anyway. *WILL* be reserved? You are remarkably optimistic that people will continue to tolerate weak IT security on their home systems. As the number of horror stories about identity theft continues to climb, some companies will sense a demand for better security and will begin to supply it. I want IPv6 address assignments to SUPPORT those new businesses, not act as an anticompetitive barrier to entering the market. That is called addressing stewardship. > Besides, if someone in the house want the online banking info > - they'll just go get the bankcard from the parent's wallet - > then they'll have what they need to just reset the password > themselves. It's been about 10 years since I last did Internet banking in the USA with Bank of America, but I'm pretty sure that my banking password was *NOT* written on my debit card. Currently, I bank with a major British bank and I need my surname, the account number written only on my statements, a PIN code of more than 4 digits, and two random letters from a secret word which is entered by selecting from a drop-down list. Even a keylogger would need to record several sessions in order to get enough letters from the secret word. Of course a teenager at home, sniffing network every time the bills are paid, would easily be able to get all of this, but the only one of the 4 data items in my wallet is my surname. > Laptop to the bathroom for porn... > that made me lol. If they want that - they'll probably use > their mobile broadband connection, rather than try to log on > to the local wireless network. Of course, if my houseguest is > taking a laptop to the bathroom - I'm going to be asking > "What's up?" anyway. You monitor house guests that closely? Pat them down looking for pocket computers before letting them in the john? Basically, I am talking about someone hijacking the wireless connection to access illegal content. Since the signal is strongest in the house, especially if you use that WiFi barrier paint, and the police won't see you doing it inside, I expect that the subset of the population who is driven to access this stuff, will start doing it at dinner parties. Unless, of course, you have the wireless connected to a router/firewall that is centrally managed so the teenagers can't bypass it. > No. People won't do that. Getting people to put WEP / WPA on > their access points is hard enough. Firewall and password is > all we can hope for there. People won't do it, but businesses will offer packages which do this, either home networking hardware packages or after-sales installation and setup service. But the bottom line is that if you cannot imagine things being different, others can. And the IPv6 addressing architecture and RIR policies must serve both you and the creative dreamers. --Michael Dillon From michael.dillon at bt.com Mon Aug 27 16:52:48 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 27 Aug 2007 21:52:48 +0100 Subject: [ppml] IPv6 addresses really are scarce after all In-Reply-To: References: <46C613E0.8010909@bogus.com><46C629D2.20009@cs.utk.edu> <17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com> <46C6B5BB.5000203@cs.utk.edu> <200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: > (2) The many examples you give seem to be to be associated > with different domains of authorization and privilege for > different groups of people and functions within the home. My > impression of the experience and literature in the field is > that almost every time someone tries to create such a > typology, they conclude that these are much better modeled as > sometimes-overlapping domains rather than as discrete > partitions. The subnet-based model you posit requires that > people or devices switch addresses when they change functions > or activities. Up to a point, one can do it that way (and > many of us have, even with IPv4). The subtext here is Ethernet. People are talking about home networks based on Ethernet and whether or not they should be segmented by routers. In my experience Ethernet bridges and switches are not designed with security as a goal. When they fail to transmit all incoming frames on all interfaces, it is to prevent segment overload or broadcast storms. There are many cases where people have found ways, sometimes quite simple ways, to receive Ethernet frames that are not addressed to them. Given this backdrop, I am suggesting that a homeowner may have several reasons for inserting routers (and router/firewalls) into their home network, thus requiring the ability to have multiple /64 IPv6 subnets. Architecture aside, this is a pragmatic response to an information security issue. > But I suggest that trying to use subnetting as the primary > and only tool to accomplish those functions is > architecturally just wrong, _especially_ for the types of > authorization-limitation cases you list. Wouldn't you rather > have mechanisms within your home network, possibly bound to > your switches, that could associate authorization property > lists with each user or device > and then enforce those properties? This would be nice, but I believe this needs more work and not just in the IETF. Also, I believe that the IETF should tackle the basic requirements for a home and/or business IPv6 Internet gateway first, and then go on to the more advanced security issues. > (4) Which IETF WG is working on these things? :-( Or failing that, which area does it belong in? --Michael Dillon From dean at av8.com Mon Aug 27 17:06:33 2007 From: dean at av8.com (Dean Anderson) Date: Mon, 27 Aug 2007 17:06:33 -0400 (EDT) Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: <99A570AA-DDC8-4CCE-8C19-F134FDBDF784@muada.com> Message-ID: On Sat, 25 Aug 2007, Iljitsch van Beijnum wrote: > On 24-aug-2007, at 20:29, Dean Anderson wrote: > > >> Stretching IPv4 only means that people will delay the move to IPv6, > > > This seems to be the unproven assumption > > Hm, IPv4 addresses are still available and few people are using IPv6. > Maybe not "proof" Air is still available, and few people are using IPv6. Perhaps its not the air, or the IPv4, but rather IPv6 that is the problem. > but so far the facts are on my side. How's that??? I think perhaps you've miscounted the facts. Lets review that facts: Fact 1: The Available IP Pool (AIP) will be exhausted on or about March, 2010 if no changes are made. Fact 2: If the AIP is exhausted, it is unknown when address space will be returned that can be delegated. Fact 3: Disruptions of unknown duration are more harmful to business planning than disruptions of known duration. Corollary 3: Disruption of known duration can be managed by changes business plans. Fact 4: Hoarding and other anti-social behavior will increase as a limited resource nears exhaustion. The AIP has no special immunity from this feature of human behavior. Fact 5: Rationing any kind of limited resource inhibits hoarding, and mitigates the effect of exhaustion by creating gradually smaller and more predictable reductions in resource consumption. Fact 6: IPv4 usage will not end because of AIP exhaustion. Fact 7: IPv4 allocation will eventually resume after exhaustion, no matter what happens. However, after exhaustion, we won't be able to predict when allocation might resume. Your reason for objection is to promote IPv6. IPv6 should have nothing to do with IPv4 resource management. ARIN has an obligation to responsibly and prudently manage IPv4 resources. Avoidable resource exhaustion, and the consequently avoidable problems with exhaustion is not a responsible act. Perhaps we need to separate IPv6 address management from IPv4 management, especially if we can no longer trust ARIN to manage IPv4 responsibly and without sabotaging IPv4 to promote IPv6. > > IPv4 will continue after exhaustion of the Available pool. Address > > space will be returned or reclaimed, and allocations will eventually > > resume. Exhaustion in this case just creates a bump in IPv4 > > operations. That bump, and consequences of the bump, can be > > avoided. > > Yes, and after all the cars have been turned into big piles of rust, > you'll be able to get oil again, too. But that doesn't mean things > revert back to the way they were before. We won't have to wait thousands of years for IPv4 address to become available again. No doubt MERIT will be returning a great deal of its dialup pool soon, since they no longer operate a large dialup network. Etc. Others may also be able to return some space. Indeed, people have proposed all sorts of (unnecessary) things to get back space. > > However, there is no case where that bump greatly improves the > > transistion to IPv6. > > There are enough extremely pigheaded people in the world, it's > possible that they'll forego IPv6 even when IPv4 moves past its > expiration date. There is no expiration date for IPv4. That's your fallacy (or fantasy). > > Your scheme seems to be desperate and makes me more suspicious of > > IPv6. If IPv6 could stand on its own merits, you wouldn't need to > > try to wreck IPv4 to promote it. > > I'm not trying to wreck IPv4. I think you are. You are attempting to stop prudent action to avert a foreseeable and avoidable problem with a shortage in IPv4 IP Address Availability. That doesn't help keep it in a "usable state". Your justification for your view is that you want to get IPv4 'over and done with' to move onto IPv6. That's just sabotage of IPv4. If you need to sabotage IPv4 to get people to move to IPv6, there must obviously be something wrong with IPv6. > Right, and so many people are now running AppleTalk, IPX, DECNET and > so on. There are indeed. IPX is still a commercial product. > China has gotten 30 million addresses so far this year. That's more > than all year last year. Once China has caught up, the really poor > countries are next in line. IPv4 can't sustain our growing > communication needs, it's as simple as that. Then they'll be happy to move to IPv6. You won't have to mismanage IPv4 to encourage them. > > I'm going to have to look into IPv6, to find out what's wrong with > > it, that you would need to disrupt Ipv4. > I recommend reading a good book about it. Its kind of hard to find a good book that hasn't been obsolesced by the continuing changes to IPv6, judging by the RFC index. I've been following the IPv6 DNS changes for 10+ years. I can't say that all of IPv6 suffers these same problems. The DNS changes seem to work, but not well. Indeed, I think that is the slogan for IPv6: "It works, but not well". Here's one DNS example: Recently, a Country code (cctld) domain operator tried to add IPv6 AAAA record support to their cctld name service. If I recall correctly, they found that they could only have 6 A records, and 3 AAAA records before they ran out of the (IPv4) packet size limitations (512 bytes). Of course, the crazy question is "why mix IPv4 DNS and IPv6 DNS?" No one ever did that with IPX, Appletalk, DecNet, SNA, or anything else. Was this a stroke of genius? No. The one certain answer is that mixing is good for the existing root and TLD operators, since they can continue using their existing servers (cheap), and they don't have to worry about competition for a new set of IPv6 root and TLD server operators; No one else will be taking over their profitable franchises. There is no technical reason that IPv6 DNS should talk to an IPv4 nameserver. No more so than an IPX nameserver needs to talk to an IPv4 nameserver. So, there is a lot of cruft and limitation in IPv4 DNS that would be quite good to remove from IPv6. None of that happened. So, IPv6 DNS is a clusterf*ck of IPv4 limitations imposed on IPv6 computers, and the only reason for that is so that certain people keep their franchises. IPv6 is designed in someways to profit some people. That's part of the reason it sucks. The other part is that IPv6 seems to be so unstable (due to continuous changes) that nothing works very well. Its so bad that people don't choose IPv6 for off-net things they use RFC1918 space for. The DOD was supposed to move to IPv6. That seems to have stalled. Why? The IPv6 problems have nothing to do with lack of connectivity to the rest of the network. If that were the case, there would be a ton of users migrating their RFC1918 spaces to IPv6, and then complaining that they still had to use IPv4 with their ISP. But ISP get few or no such complaints. You're right that IPv4 will have problems with address space. We've known that for 20 years. People were supposed to be working on that problem. But instead of honest science, they put their own interests ahead of the science of a better protocol suite. I'm not certain what the solution is for IPv6. I think we can fix it and make it work. Just about anything can be made to work. On the other hand, maybe we have to start over with more honest people. But there is no reason to damage IPv4 in the meantime. > >> My assumption of what would happen when we run out (in the absense > >> of new policies) is that if a request comes in for more address > >> space than is available, the request is denied A request for a > >> smaller amount of address space that can still be accommodated > >> would be honored. If you want your policy to work like that, you > >> should say that in the proposal. > > > Well, this happens with or without rationing. > > You didn't specify that in your proposal. It doesn't need to be in the proposal because it's not relevant to rationing. ARIN, I think, handles this situation already quite well. In any case, its not a change particular to rationing. > > None of your arguments make any difference under rationing or not > > rationing. So, they don't have any relevance to rationing. > > If you are an ISP that is going to connect a million customers in the > next few months, you need a million addresses. If you only get 800000, > 80000, 8000 or 800, you have a problem. The severity of the problem > may differ slightly, but in each case, you have a problem that you > don't have if you get that million addresses. By giving out address > space while it lasts we don't start creating problems before we have > to so people have more time to be proactive. This also happens in March 2010 without rationing. Rationing mitigates the problem by creating smaller stoppages and a predictable slowdown. Businesses can deal with predictability. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From stephen at sprunk.org Mon Aug 27 17:08:14 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 27 Aug 2007 16:08:14 -0500 Subject: [ppml] IPv6 addresses really are scarce after all References: <46C613E0.8010909@bogus.com><46C629D2.20009@cs.utk.edu><17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com><46C6B5BB.5000203@cs.utk.edu><200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com><70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <018801c7e8f1$88990300$4d3816ac@atlanta.polycom.com> Thus spake > In my experience Ethernet bridges and switches are not > designed with security as a goal. When they fail to transmit > all incoming frames on all interfaces, it is to prevent segment > overload or broadcast storms. There are many cases where > people have found ways, sometimes quite simple ways, to > receive Ethernet frames that are not addressed to them. > Given this backdrop, I am suggesting that a homeowner > may have several reasons for inserting routers (and router / > firewalls) into their home network, thus requiring the ability > to have multiple /64 IPv6 subnets. Architecture aside, this > is a pragmatic response to an information security issue. Basically, because some people are too dense to use IPsec or SSL for traffic they don't want observed, you want to greatly complicate the average home network's design? That they should be more scared of, say, their spouse sniffing their credit card numbers at home than the NSA and FBI tapping their email and web browsing at the CO? Sorry, but that's the wrong response to the wrong problem. 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 iljitsch at muada.com Mon Aug 27 17:44:54 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 27 Aug 2007 23:44:54 +0200 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: References: Message-ID: On 27-aug-2007, at 23:06, Dean Anderson wrote: > Fact 1: The Available IP Pool (AIP) will be exhausted on or about > March, > 2010 if no changes are made. Geoff Huston predicts june 2010 for the IANA pool and march 2011 for the RIR reserves. This requires a rather significant increase in yearly address use. (2005 and 2006 were about 170 million addresses/ year, we are now at around 195 million for the last 12 months, running out in 3.6 years means 325 million/year average during that period.) In my opinion, the data is too volatile to support such a prediction. Something like 2012 - 2013 seems more reasonable. Then again, I'm not a mathematician. > Fact 2: If the AIP is exhausted, it is unknown when address space will > be returned that can be delegated. Address space is returned all the time. Last time I check was two years ago IIRC, and that was 11 million addresses in a year. I'd say it's likely that this will go down as we run out of IPv4 space because people will want to hang on to what they've got and returning a few small blocks for a larger one won't happen anymore. It goes without saying that the returned address space won't be nearly enough to cover the requests that come in. > Fact 3: Disruptions of unknown duration are more harmful to > business planning than disruptions of known duration. Even more harmful is thinking a disruption is temporary when it is in fact permanent. > Fact 5: Rationing any kind of limited resource inhibits hoarding No, it just makes it start sooner and the iterations as new blocks come available and assignments resume temporarily allow the hoarders to learn and become more effective. > Fact 6: IPv4 usage will not end because of AIP exhaustion. Growth will end, and many economic models require growth. > Fact 7: IPv4 allocation will eventually resume after exhaustion Not in any meaningful way. Sure, if you need a /24, you'll be able to get it at some point, but if you need a /12, that's simply not going to happen. > However, after exhaustion, we won't be able to > predict when allocation might resume. It's not a stop/wait/resume thing, what will happen is that large blocks will no longer be available but small blocks will continue to be assigned unless so many requests come in that seem legitimate enough to soak up all remaining space. > Your reason for objection is to promote IPv6. IPv6 should have > nothing > to do with IPv4 resource management. A smooth transition from IPv4 to IPv6 is in everyone's interest. IPv4 is a sinking ship. You don't have to jump in a life boat right this minute, but planning new trips is not a smart thing to do. >> Yes, and after all the cars have been turned into big piles of rust, >> you'll be able to get oil again, too. But that doesn't mean things >> revert back to the way they were before. > We won't have to wait thousands of years for IPv4 address to become > available again. Cars rust faster than that. I don't mean wait for new oil to be formed again (that would be a while) but there will always be SOME oil and without cars to burn it up, there will probably be enough for many other uses, such as making plastics. > There is no expiration date for IPv4. That's your fallacy (or > fantasy). Right, when 9 billion people are running IPv6, the 900 million people running IPv4 have no reason to change protocols. >> I'm not trying to wreck IPv4. > I think you are. You are attempting to stop prudent action to avert a > foreseeable and avoidable problem with a shortage in IPv4 IP Address > Availability. That doesn't help keep it in a "usable state". Your mistake is focussing on IPv4 exclusively. The point is that we have a working internet. Today, we need IPv4 for that. In a few years, IPv4 won't be able to provide this function for new users, so we need to move to IPv6. Making it harder for new users sooner doesn't help those IPv4 and the market forces are such that it also delays the real solution = moving to IPv6. > Your justification for your view is that you want to get IPv4 'over > and > done with' to move onto IPv6. That's just sabotage of IPv4. Absolutely not. I want IPv4 to remain useful as long as it can, which means NOT making it harder to get IPv4 address space, which is already relatively hard today. >> China has gotten 30 million addresses so far this year. That's more >> than all year last year. Once China has caught up, the really poor >> countries are next in line. IPv4 can't sustain our growing >> communication needs, it's as simple as that. > Then they'll be happy to move to IPv6. You won't have to mismanage > IPv4 > to encourage them. Oh so it's only the poor people that should use IPv6? >> I recommend reading a good book about it. > Its kind of hard to find a good book that hasn't been obsolesced by > the > continuing changes to IPv6, judging by the RFC index. Anything published in 2003 or later should be in reasonable shape in that department. My book is now 2 years old and I don't think there are significant issues in this area. Sometimes it helps that the IETF moves so slow. :-) > Here's one DNS example: Recently, a Country code (cctld) domain > operator > tried to add IPv6 AAAA record support to their cctld name service. > If I > recall correctly, they found that they could only have 6 A records, > and > 3 AAAA records before they ran out of the (IPv4) packet size > limitations > (512 bytes). EDNS0 is your friend, people who use stupid firewalls get what they deserve. I don' see a problem. (But then again, I'm not a root server operator.) > There is no technical reason that IPv6 DNS should talk to an IPv4 > nameserver. The DNS is used to determine if a remote system is reachable over IPv4 or IPv6. This means that address records for both protocols must be present in the same name space and then separating the two protocols makes no sense. > So, there is a lot of cruft and limitation in IPv4 DNS that > would be quite good to remove from IPv6. None of that happened. I'm with you on that one, they could have made EDNS0 mandatory for IPv6. Although I think the real issue here is the IPv6 socket API, which happily continues the layer violations that were unavoidable for IPv4 but could have been cleaned up when IPv6 required changes. > IPv6 is designed in someways to profit some people. Yeah right. People are making money off of IPv6 left and right... > The other part is that IPv6 seems to be so unstable (due to continuous > changes) that nothing works very well. Actually it works extremely well. There are lots of times when IPv4 requires hacks that are completely unnecessary with IPv6. Unfortunately, IPv6 doesn't (yet) do everything IPv4 does. For instance, you can't do dial-up over IPv6 in a mixed vendor environment. From dean at av8.com Mon Aug 27 19:02:41 2007 From: dean at av8.com (Dean Anderson) Date: Mon, 27 Aug 2007 19:02:41 -0400 (EDT) Subject: [ppml] IPv6 addresses really are scarce after all In-Reply-To: <018801c7e8f1$88990300$4d3816ac@atlanta.polycom.com> Message-ID: On Mon, 27 Aug 2007, Stephen Sprunk wrote: > Basically, because some people are too dense to use IPsec or SSL for traffic > they don't want observed, you want to greatly complicate the average home > network's design? That they should be more scared of, say, their spouse > sniffing their credit card numbers at home than the NSA and FBI tapping > their email and web browsing at the CO? It has nothing to do with IPsec or SSL. Your view of what people do at home is kind of narrow. Some people run businesses out of their house, and some have quite complicated home networks, with wifi for guests and and other parts they don't want guests to get into. If you have the space, give it out. (that was the point of a 16 byte IP address) The notion that a home user's subnetting makes any difference to the DFZ is just plain nonsense. Those sub-blocks are aggregated by their provider. The home user doesn't need or take a full view, either. They have just their subnets and a default route. At the other end, the notion that geographic aggregation reduces the DFZ is likewise nonsense. It just eases the job of the RIR and running multiple RIRs. But every block delegated by the RIR will probably make it into the DFZ, unless it is used for some kind of non-public routing, in which case perhaps it makes it into some DFZ's, but not others. There usually isn't any aggregation of blocks delegated by the RIR. --Dean > Sorry, but that's the wrong response to the wrong problem. > > 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. > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From tommy.perniciaro at thomson.net Mon Aug 27 19:38:48 2007 From: tommy.perniciaro at thomson.net (Tommy Perniciaro) Date: Mon, 27 Aug 2007 16:38:48 -0700 Subject: [ppml] IPv6 addresses really are scarce after all In-Reply-To: Message-ID: I agree with Dean entirely. On 8/27/07 4:02 PM, "Dean Anderson" wrote: > On Mon, 27 Aug 2007, Stephen Sprunk wrote: > >> > Basically, because some people are too dense to use IPsec or SSL for >> traffic >> > they don't want observed, you want to greatly complicate the average home >> > network's design? That they should be more scared of, say, their spouse >> > sniffing their credit card numbers at home than the NSA and FBI tapping >> > their email and web browsing at the CO? > > It has nothing to do with IPsec or SSL. Your view of what people do at > home is kind of narrow. Some people run businesses out of their house, > and some have quite complicated home networks, with wifi for guests and > and other parts they don't want guests to get into. > > If you have the space, give it out. (that was the point of a 16 byte IP > address) The notion that a home user's subnetting makes any difference > to the DFZ is just plain nonsense. Those sub-blocks are aggregated by > their provider. The home user doesn't need or take a full view, either. > They have just their subnets and a default route. > > At the other end, the notion that geographic aggregation reduces the DFZ > is likewise nonsense. It just eases the job of the RIR and running > multiple RIRs. But every block delegated by the RIR will probably make > it into the DFZ, unless it is used for some kind of non-public routing, > in which case perhaps it makes it into some DFZ's, but not others. There > usually isn't any aggregation of blocks delegated by the RIR. > > --Dean > >> > Sorry, but that's the wrong response to the wrong problem. >> > >> > 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. >> > >> > > > -- > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 > > > _______________________________________________ > 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 info at arin.net Tue Aug 28 10:33:01 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:33:01 -0400 Subject: [ppml] Policy Proposal 2007-16: IPv4 Soft Landing Message-ID: <46D4321D.1000608@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) concluded their initial review of "IPv4 Soft Landing" and accepted it as a formal policy proposal for discussion by the community. The AC accepted this proposal as written. The AC believes that further edits would clarify the proposal and enhance the chance of community consensus, and will be contacting the author with their suggestions within the next week. The Advisory Council recommends the author consider these changes, and submit them to policy at arin.net no later than 17 September 2007, which is suggested as a deadline for revisions for the upcoming public policy meeting. The proposal is designated Policy Proposal 2007-16: IPv4 Soft Landing. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_16.html All persons in the community are encouraged to discuss Policy Proposal 2007-16 prior to it being presented at the ARIN Public Policy Meeting in Albuquerque, New Mexico, 17-18 October 2007. 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-16 IPv4 Soft Landing Author: David Conrad Proposal type: New Policy term: Permanent Policy statement: This policy is intended to replace section 4.2.4.1 of the ARIN Number Resource Policy Manual with wording substantially along the lines of: --- begin modification --- 4.2.4.1 In order to encourage a smooth transition to IPv6, ARIN has instituted a set of IPv4 Address Allocation "phases" that vary the requirements for address allocation using the amount of address space remaining unallocated by IANA as a metric. As the amount of address space in the IANA free pool is reduced, the requirements for IPv4 address allocation are made more stringent. When requesting additional IPv4 address space, ISPs must meet the requirements of the IPv4 Address Allocation phase ARIN was in when the request was submitted. These phases will require the requester to demonstrate increasingly efficient utilization of previously allocated IPv4 address space, including all space reassigned to their customers. In addition, depending on the IPv4 Address Allocation phase ARIN was in when the request was submitted, there may be additional requirements that will need to be met by the requester such as completing a survey on IPv6 deployment plans, documentation of non-private address space used for internal infrastructure, documentation of IPv6 plans for offering connectivity and services, etc. The reassignment information section of the ARIN ISP Network Request Template should be completed for all address blocks that have been allocated to your organization. In the template, line 1b. Assigned: information will be verified via SWIP/RWHOIS and 1c. Reserved: should be used to indicate internal network information. Please note that until all requirements are met and your prior utilization is verified to meet the requirements specified in the IPv4 Address Allocation phase in which the request was received, ARIN can neither process nor approve a request for additional addresses. IPv4 Allocation Phases The thresholds and the requirements to justify an allocation of new IPv4 address space from ARIN are defined in this section. Phase: 0 Threshold: Greater than 40 /8s Requirements: Requesters must: * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 25% utilization - Demonstrate a one year requirement of 50% utilization Phase: 1 Threshold: 40 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 25% utilization - Demonstrate a one year requirement of 50% utilization * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used. Phase: 2 Threshold: 25 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 85% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 50% utilization - Demonstrate a one year requirement of 75% utilization * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used. * Provide plans for migrating all non-RFC 1918 address space used for internal infrastructure either to IPv6 (preferred) or to private addressing where possible. Where such migration is not possible, provide documentation listing the use of addresses that are not migratable and the reasons for the inability to migrate. * Demonstrate documented plans for availability of production IPv6 infrastructure and connectivity services within 6 months of submitting the request. Phase: 3 Threshold: 10 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 90% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 75% utilization - Demonstrate a one year requirement of 90% utilization * Provide documentation demonstrating migration (where possible) of non-RFC 1918 address space used for internal infrastructure to either IPv6 (preferred) or private addressing. * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure, how it is used, and why it is not possible to migrate those addresses to either IPv6 (preferred) or private addressing. * Demonstrate availability of production IPv6 infrastructure and connectivity services. Notes: * Phase 0 reflects current allocation requirements. * Phases 1 through 3 are to be implemented 30 days after IANA allocates address space from the IPv4 free pool that reduces that free pool to a number of /8s that are at or below the threshold specified. * If multiple thresholds should be crossed within a 30 day period, the requirements from the last threshold crossed will be applied to requesters for additional address space at the time of the request. --- end modification --- Rationale: The rationale for this proposal is threefold: * to prolong the availability of IPv4 addresses for requesters who can provide sufficient justification; * to encourage the deployment of IPv6 as an alternative to IPv4 by making the requirements to justify IPv4 allocations increasingly stringent over time; * to promote the more efficient use of increasingly scarce IPv4 resources. As the lack of significant deployment of IPv6 can attest, the cost of deploying IPv6 currently outweighs the benefits that protocol would appear to provide. This proposal aims to encourage the deployment of IPv6 by over time, making the allocation of IPv4 both more difficult and contingent on the requester demonstrating both support for IPv6 as well as requiring a demonstration that the IPv4 address space they administer is being used efficiently. The goal of these measures is to rebalance the IPv6 deployment cost/benefit ratio thereby encouraging greater uptake of IPv6 before the IPv4 free pool is exhausted. The "IPv4 Soft Landing" policy aims to provide for a smoother transition away from IPv4 towards IPv6 by imposing increasingly strict requirements for new address allocations as the amount of address space available in the IANA unallocated IPv4 address pool decreases. These increased requirements include both more stringent reassignment and utilization percentages as well as requiring documented IPv6 infrastructure services and connectivity provision and the documentation or reuse of public IPv4 address space used for internal infrastructure. The increased stringency in the allocation requirements is intended both to increase the efficiency of utilization of the IPv4 address space and to reduce the likelihood of a "run" on the remaining free pool of IPv4 address space. ARIN staff would be expected to use the same mechanisms in use today to verify conformance to the specified requirements. The requirements for demonstration of IPv6 infrastructure services and connectivity are intended to motivate ISPs to provide those services before the only address space they can offer their customers is IPv6, thereby offering an opportunity to break the "chicken-and-egg" problem limiting significant IPv6 deployment. Verification of these requirements can be done by ARIN staff by using IPv6 transport to connect to published services of the ISP (e.g., DNS servers, WWW URLs, etc.) as well as using IPv6 ping to identified addresses internal to the ISP. Obviously, false positive responses for most any objective mechanism for verifying the availability can be engineered, so ARIN staff may also consider subjective reports of an inability to obtain IPv6 services by customers as an indicator of (lack of) conformance to this requirement. The requirements to migrate internal infrastructure to either IPv6 or private (e.g., RFC 1918) addressing are intended to improve the efficiency of utilization of IPv4 address space, reserving the scarce IPv4 resources for purposes for which IPv6 or private addresses are not suitable. These requirements acknowledge that pragmatically, the use of IPv4 is absolutely essential only for servers in client-server architectures, machines engaged in peer-to-peer applications, and entry points for NAT/ALG devices. As such, use of IPv4 for purposes such as router interface numbering, client-only devices, and devices which should not be available from external networks should be discouraged. Since there can be circumstances in which migration of internal infrastructure addresses to private addressing would not be feasible, this policy allows for requesters to document those situations in which it is not possible to do the migration. The time for transition between phases of this policy are not fixed, rather they depend on the rate of consumption of IPv4 address space from the IANA free pool. Current RIR operational procedure is to request 2 /8s from the IANA when the RIR's current pool of free IPv4 address space is depleted. This procedure should ensure transitions between phases will have some lead-time, so organizations can prepare for the next phase of IPv4 address allocation. Given the highly volatile nature of IPv4 consumption and the inability to define a predictive model rooted in an underlying theory rather than extrapolating over existing data, the thresholds chosen are acknowledged to be somewhat arbitrary. The intent of the chosen values is to provide a "reasonable" amount of time, approximately 18 months, between transitions at current consumption rates (approximately 10 /8s per year). However, it should be explicitly noted that one of the intents of this policy is to extend the IPv4 free pool lifetime, thus as the policy becomes effective, the amount of time between phase transitions would presumably increase. Timetable for implementation: Immediately upon approval of this policy by the ARIN Board of Trustees. From info at arin.net Tue Aug 28 10:37:22 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:37:22 -0400 Subject: [ppml] Policy Proposal 2007-17: Legacy Outreach and Partial Reclamation Message-ID: <46D43322.6040907@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) concluded their initial review of "Legacy Outreach and Partial Reclamation" and accepted it as a formal policy proposal for discussion by the community. The AC accepted this proposal as written. The AC believes that further edits would clarify the proposal and enhance the chance of community consensus, and will be contacting the author with their suggestions within the next week. The Advisory Council recommends the author consider these changes, and submit them to policy at arin.net no later than 17 September 2007, which is suggested as a deadline for revisions for the upcoming public policy meeting. The proposal is designated Policy Proposal 2007-17: Legacy Outreach and Partial Reclamation. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_17.html All persons in the community are encouraged to discuss Policy Proposal 2007-17 prior to it being presented at the ARIN Public Policy Meeting in Albuquerque, New Mexico, 17-18 October 2007. 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-17 Legacy Outreach and Partial Reclamation Author: Owen DeLong Proposal type: modify Policy term: permanent Policy statement: Modify section 4.6 as follows: 4.6 Amnesty Requests ARIN will accept the return or relinquishment of any address space from any existing address holder. If the address holder wishes to aggregate into a single block, ARIN may work with the address holder to arrive at an allocation or assignment which is equal to or smaller than the sum of their existing blocks and which best meets the needs of the existing holder and the community. There shall be no fee for returning addresses under this policy. Further, organizations returning addresses under this policy shall receive the following benefits: 1. If the organization does not currently pay ARIN fees, they shall remain fee exempt. 2. If the organization currently pays ARIN fees, their fees shall be waived for two years for each /20 equivalent returned, with any fractional /20 equivalent resulting in a one-time single year waiver. 3. Any organization returning address space under this policy shall continue under their existing RSA or they may choose to sign the current RSA. For organizations which currently do not have an RSA, they may sign the current RSA, or, they may choose to remain without an RSA. 4. All organizations returning space under this policy shall, if they meet other eligibility requirements and so request, obtain an appropriate IPv6 end-user assignment or ISP allocation as applicable, with no fees for the first 5 years. Organizations electing to receive IPv6 allocation/assignment under this provision must sign a current RSA and must agree that all of their IPv4 resources are henceforth subject to the RSA. Organizations taking this election shall be subject to end-user fees for their IPv4 resources not previously under an ARIN RSA. If they are already an ARIN subscriber, then IPv4 resources affected by this process may, instead, be added to their existing subscriber agreement at the address holder's discretion. Rationale: The current amnesty policy does a nice job of facilitating aggregation, which was the intent when it was drafted. However, as we approach IPv4 free-space exhaustion, the community now has an additional need to facilitate address reclamation. A very high percentage of underutilized space is in the hands of legacy holders who currently have no benefit to joining the ARIN process. Further, there is an unfortunate perception that doing so will require force the legacy holder into certain future disadvantages. This proposal attempts to resolve both of those issues while also providing some incentive to legacy organizations to start using IPv6 resources and bring their IPv4 resources into the ARIN process. This policy attempts to provide some benefit and remove most of the costs of making partial IPv4 returns. It also attempts to provide an incentive for these IPv4 holders to join the ARIN process. Timetable for implementation: Immediate From info at arin.net Tue Aug 28 10:38:33 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:38:33 -0400 Subject: [ppml] Policy Proposal 2007-18: Global Policy for the Allocation of the Remaining IPv4 Address Space Message-ID: <46D43369.4020206@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) concluded their initial review of "Global Policy for the Allocation of the Remaining IPv4 Address Space" and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-18: Global Policy for the Allocation of the Remaining IPv4 Address Space. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_18.html All persons in the community are encouraged to discuss Policy Proposal 2007-18 prior to it being presented at the ARIN Public Policy Meeting in Albuquerque, New Mexico, 17-18 October 2007. 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-18 Global Policy for the Allocation of the Remaining IPv4 Address Space Author: Roque Gagliano Co-authors: Francisco Obispo, Hytham EL Nakhal, Didier Allain Kla Proposal type: new Policy term: permanent Policy statement: This policy describes the process for the allocation of the remaining IPv4 space from IANA to the RIRs. When a minimum amount of available space is reached, an identical number of IPv4 allocation units (/8s) will be allocated from IANA to each RIR, replacing the current IPv4 allocation policy. In order to fulfill the requirements of this policy, at the time it is adopted, an identical number of IPv4 allocation units (N units) will be reserved by IANA for each RIR. The number N is defined as: 5. The reserved allocation units will no longer be part of the available space at the IANA pool. The process for the allocation of the remaining IPv4 space is divided in two consecutive phases: 1. Existing Policy Phase: During this phase IANA will continue allocating IPv4 addresses to the RIRs using the existing allocation policy. This phase will continue until a request for IPv4 address space from any RIR to IANA cannot be fulfilled with the remaining IPv4 space available at the IANA pool. This will be the last IPv4 address space request that IANA will accept from any RIR. At this point the next phase of the process will be initiated. 2. Exhaustion Phase: IANA will automatically allocate the reserved IPv4 allocation units to each RIR (N units to each one) and respond to the last request with the remaining available allocation units at the IANA pool (M units). 2.1. Size of the final IPv4 allocations: During this phase IANA will automatically allocate N allocation units to each RIR from the reserved space defined in this policy. IANA will also allocate M allocation units to the RIR that submitted the last request for IPv4 addresses. 2.2. Allocation of the remaining IPv4 Address space: After the completion of the evaluation of the final request for IPv4 addresses, IANA MUST: A) Immediately notify the NRO about the activation of the second phase of this policy. B) Proceed to allocate M allocation units to the RIR that submitted the last request for IPv4 address space. C) Proceed to allocate N allocation units to each RIR from the reserved space. Rationale: The IANA pool of allocation units of IPv4 addresses (/8s) is decreasing rapidly. A new policy is proposed to replace the current "on demand" policy in order to bring certainty on how the remaining space will be allocated. This policy eliminates the pressure on the remaining central pool of addresses by allocating equal amount of allocation units (N) to each RIR. RIR may be studying slow-landing policies or the possibility to reserve specific address spaces for "critical infrastructure" or new companies in order to comply with anti-trust regulations in its region. This policy allows each RIR to adopt those policies through its PDP, which is simpler than a global policy discussion process. Each RIR will have the exact information on the amount of address spaces that they will be receiving as a last allocation from the IANA. The policy is written in such a way that the discussion could be split in two sections: first do we agree on the concept of the policy and second what is the appropriate value for the last allocation units N. Timetable for implementation: This is a Global policy that needs to be approved by all RIRs and then ratified by ASO/ICANN. It has already reached consensus at LACNIC meeting. From info at arin.net Tue Aug 28 10:39:44 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:39:44 -0400 Subject: [ppml] Policy Proposal 2007-19: IANA Policy for Allocation of ASN Blocks to RIRs Message-ID: <46D433B0.2070405@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) concluded their initial review of "IANA Policy for Allocation of ASN Blocks to RIRs" and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-19: IANA Policy for Allocation of ASN Blocks to RIRs. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_19.html All persons in the community are encouraged to discuss Policy Proposal 2007-19 prior to it being presented at the ARIN Public Policy Meeting in Albuquerque, New Mexico, 17-18 October 2007. 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-19 IANA Policy for Allocation of ASN Blocks to RIRs Author: Axel Pawlik Proposal type: New Policy term: renewable Policy statement: Abstract This document describes the policy governing the allocation of Autonomous System Numbers (ASNs) from the IANA to the Regional Internet Registries (RIRs). This policy document does not stipulate performance requirements in the provision of services by the IANA to an RIR. Such requirements will be specified by appropriate agreements between ICANN and the Number Resource Organization (NRO). 1. Allocation Principles IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2009, allocations of 2-byte only and 4-byte only ASN blocks will be made separately and independent of each other [1]. This means until 31 December 2009, RIRs can receive two separate ASN blocks, one for 2-byte only ASNs and one for 4-byte only ASNs from the IANA under this policy. After this date, IANA and the RIRs will cease to make any distinction between 2-byte only and 4-byte only ASNs, and will operate ASN allocations from an undifferentiated 4-byte ASN allocation pool. 2. Initial Allocations Each new RIR will be allocated a new ASN block. 3. Additional Allocations An RIR is eligible to receive (an) additional ASN block(s) from the IANA if one of the following conditions is met: 1. The RIR has assigned/allocated 80% of the previously received ASN block, or 2. The number of free ASNs currently held by the RIR is less than two months need. This projection is based on the monthly average number of ASNs assigned/allocated by the RIR over the previous six months. An RIR will be allocated as many ASN blocks as are needed to support their registration needs for the next 12 months, based on their average assignment/allocation rate over the previous six months, unless the RIR specifically requests fewer blocks than it qualifies for. 4. Announcement of IANA Allocations The IANA, the NRO and the RIRs will make announcements and update their respective websites/databases when an allocation is made by the IANA to an RIR. ICANN and the NRO will establish administrative procedures to manage this process. [1. http://www.ripe.net/ripe/policies/proposals/2005-12.html] Rationale: There are global policies governing the allocation of IPv4 and IPv6 blocks from the IANA to RIRs. At this point there is no specific policy regarding the allocation of Autonomous System Numbers from the IANA to the RIRs. This proposal will create a policy to fill this gap. The criteria being proposed has already been the practice between IANA and RIRs so far and it has been proven to work. It is designed to allow RIRs to request ASN blocks from the IANA in a timely fashion and maintain enough ASNs in holding to ensure that their registration services can be sustained. It is also proposed that the RIRs be allocated as many ASN blocks as are needed to support their registration needs for the next 12 months. This will generally mean that each RIR will only need to make one ASN request from the IANA each year, thus lowering operational overhead for the RIRs. Timetable for implementation: Immediate From info at arin.net Tue Aug 28 10:41:45 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:41:45 -0400 Subject: [ppml] Policy Proposal 2007-20: Definition of known ISP and changes to IPv6 initial allocation criteria Message-ID: <46D43429.1000306@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) concluded their initial review of "Definition of known ISP and changes to IPv6 initial allocation criteria" and accepted it as a formal policy proposal for discussion by the community. The AC accepted this proposal as written. The AC believes that further edits would clarify the proposal and enhance the chance of community consensus, and will be contacting the author with their suggestions within the next week. The Advisory Council recommends the author consider these changes, and submit them to policy at arin.net no later than 17 September 2007, which is suggested as a deadline for revisions for the upcoming public policy meeting. The proposal is designated Policy Proposal 2007-20: Definition of known ISP and changes to IPv6 initial allocation criteria. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_20.html All persons in the community are encouraged to discuss Policy Proposal 2007-20 prior to it being presented at the ARIN Public Policy Meeting in Albuquerque, New Mexico, 17-18 October 2007. 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-20 Definition of known ISP and changes to IPv6 initial allocation criteria Author: Kevin Loch Proposal type: new Policy term: permanent Policy statement: Add the following section 6.2.10: 6.2.10 Existing ISP An existing ISP is an organization which meets the following criteria: 1. Has IPv4 or IPv6 address space directly allocated by ARIN; or 2. Has at least a total of an IPv4 /23 or an IPv6 /44 of address space reallocated to them via SWIP by one or more upstream ISPs. Address space directly assigned from ARIN or reassigned from upstream ISPs does not count towards these requirements. Replace 6.5.1.1 (d) with the following text: d. be an existing ISP in the ARIN region or have a plan for making assignments to at least 200 separate organizations within five years. Rationale: This policy proposal would change two things in the IPv6 Initial allocation criteria. It adds a definition for "known ISP" and changes "200 /48 assignments" to 200 assignments of any size, but to separate organizations. Existing ISP: The term "existing, known ISP" in the IPv6 ISP qualification section is too vague and does not give ARIN staff sufficient guidance for evaluating qualifications. This text defines "existing, ISP" in a precise manner and removes the unnecessary and ambiguous word "known". It has come to the author's attention that several organizations have been refused IPv6 ISP allocations because they were not considered an existing, known ISP. At least one of these organizations has a /18 worth of IPv4 space reallocated to them by various upstream ISPs and over 200 IPv4 customers. An organization's choice to use provider addresses does not have any affect on whether or not they are in fact an ISP. Address space that has been reallocated (not reassigned) is a good indicato of an ISP as those SWIP templates are only supposed to be used for downstream ISPs. The IPv4 /23 value was selected to match the utilization requirement for the smallest direct IPv4 allocation from ARIN under current policy. The IPv6 /44 value was selected to represent a number of downstream customers comparable to the IPv4 requirements. Updates to IPv6 initial allocation criteria: Section 6.5.4.1 recommends /56 assignments in some cases and /48 assignments in others. The Initial allocation criteria should reflect the flexibility of these recommendations. An ISP should not have to provide an inefficient address plan on their application even though they expect to have over 200 IPv6 customers. Timetable for implementation: Immediate From info at arin.net Tue Aug 28 10:43:00 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:43:00 -0400 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with RSA and efficient use Message-ID: <46D43474.3040909@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) concluded their initial review of "PIv6 for legacy holders with RSA and efficient use" and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-21: PIv6 for legacy holders with RSA and efficient use. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_21.html All persons in the community are encouraged to discuss Policy Proposal 2007-21 prior to it being presented at the ARIN Public Policy Meeting in Albuquerque, New Mexico, 17-18 October 2007. 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-21 PIv6 for legacy holders with RSA and efficient use Author: Scott Leibrand Proposal type: new Policy term: permanent Policy statement: Modify NRPM section 6.5.8.1 (Direct assignments from ARIN to end-user organizations: Criteria), to read: To qualify for a direct assignment, an organization must: 1. not be an IPv6 LIR; and 2. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect, or demonstrate efficient utilization of a direct IPv4 assignment or allocation covered by a current ARIN RSA. Rationale: Current policy allows direct IPv6 allocations and assignments to nearly all organizations with IPv4 allocations or assignments from ARIN. As a result, such organizations can get IPv6 space just as easily as they can get IPv4 space, making it easy for them to transition to IPv6 as soon as they're ready to do so. However, there are some organizations who received IPv4 /23's and /24's prior to the formation of ARIN, and use that space in a multihomed, provider-independent fashion. Under current policy, such organizations cannot get IPv6 PI space without artificially inflating host counts, and are therefore discouraged from adopting IPv6. This policy proposal aims to remove this disincentive, and allow such organizations to easily adopt IPv6. In addition, pre-ARIN assignments were issued through an informal process, and many legacy resource holders have not yet entered into a formal agreement with ARIN, the manager of many such IP numbering resources. This policy proposal would require that such assignments be brought under a current ARIN Registration Services Agreement, thereby formalizing the relationship. Some pre-ARIN assignments may not be used efficiently. As unallocated IPv4 numbering resources are approaching exhaustion, it is important to ensure efficient utilization of IPv4 assignments, and to arrange for reclamation of unused space. Therefore, this policy would require that the organization wishing to receive IPv6 PI space demonstrate efficient utilization of their IPv4 assignment. (Efficient utilization is already defined elsewhere in policy, and the exact mechanism for achieving and determining efficient use is a matter of procedure, not of policy, so detailed procedures are not included in the policy statement above. The intent is that any organization with an assignment of /23 or larger which is less than 50% utilized would renumber and return whole unused CIDR blocks as necessary to bring the remaining CIDR block to 50% utilization or higher. A /24 should be considered efficiently utilized as long as it is in use for multihoming, as /25's and smaller are not routable for that purpose.) It has been suggested that this policy would be useful only until the growth of IPv6 exceeds the growth of IPv4. I would agree with this, and would further posit that the existing "qualify ... under the IPv4 policy currently in effect" language should also be modified at that time. I have therefore proposed this policy with a policy term of "permanent", with the expectation that this section of policy (6.5.8.1) will be rewritten at the appropriate time to entirely remove all IPv4 dependencies. Timetable for implementation: immediate From info at arin.net Tue Aug 28 10:44:21 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:44:21 -0400 Subject: [ppml] Policy Proposal 2007-22: Expand timeframe of Additional Requests Message-ID: <46D434C5.8070409@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) concluded their initial review of "Expand timeframe of Additional Requests" and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-22: Expand timeframe of Additional Requests. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_22.html All persons in the community are encouraged to discuss Policy Proposal 2007-22 prior to it being presented at the ARIN Public Policy Meeting in Albuquerque, New Mexico, 17-18 October 2007. 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-22 Expand timeframe of Additional Requests Author: Dan Alexander Proposal type: modify Policy term: permanent Policy statement: The proposal is to modify section 4.2.4.4 of the NRPM Current wording: "After a subscriber has been a member of ARIN for one year they may choose to request a six-month supply of IP addresses." Change to: "After an organization has been an ARIN member in good standing for one year, they may choose to request up to a 12 month supply of IP addresses." Rationale: Currently, all RIR's provide organizations with at least a 12 month supply of IPv4 address space when making subsequent requests, with the exception of the ARIN region. The primary reason for this change is for continuity among all RIR. In doing so, all established organizations have a more consistent access to IP resources. The adjustment does not change demand on IPv4 address space. It only changes the frequency in which established organizations need to request address space. This would allow for fewer potential aggregates allocated to an organization providing more consolidated routing announcements. This does not change the requirement on new organizations where established growth trends have yet to be established. Timetable for implementation: Immediate From info at arin.net Tue Aug 28 10:45:16 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:45:16 -0400 Subject: [ppml] Policy Proposal 2007-23: End Policy for IANA IPv4 allocations to RIRs Message-ID: <46D434FC.50208@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) concluded their initial review of "End Policy for IANA IPv4 allocations to RIRs" and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-23: End Policy for IANA IPv4 allocations to RIRs. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_23.html All persons in the community are encouraged to discuss Policy Proposal 2007-23 prior to it being presented at the ARIN Public Policy Meeting in Albuquerque, New Mexico, 17-18 October 2007. 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-23 End Policy for IANA IPv4 allocations to RIRs Author: JPNIC IPv4 countdown policy team; Akinori MAEMURA, Akira NAKAGAWA, Izumi OKUTANI, Kosuke ITO, Kuniaki KONDO, Shuji NAKAMURA, Susumu SATO, Takashi ARANO, Tomohiro FUJISAKI, Tomoya YOSHIDA, Toshiyuki HOSAKA Proposal type: new Policy term:renewable Policy statement: 1) Distribute a single /8 to each RIR at the point when new IANA free pool hits 5 */8. This date is defined as "IANA Exhaustion Date". 2) It should be completely left up to each RIR communities to define a regional policy on how to distribute the remaining RIR free pool to LIRs within their respective regions after "IANA Exhaustion Date". Note 1: It is fine for an RIR to continue operations with the existing policy if that is the consensus decision of the respective RIR community. Note 2: Address recovery and re-distribution of recovered address space is another important measure for considerations, but should be treated as a separate policy proposal from distribution of new IANA pool. 3) RIRs should provide an official projection on IANA Exhaustion Date to the community through their website, at their Policy Meetings and through any other effective means. Rationale: [current problem] There are two major issues in terms of address management if no measures are taken for IPv4 address exhaustion. 1) Continue applying a global coordinated policy for distribution of the last piece(s) of RIR's unallocated address block does not match the reality of the situation in each RIR region. Issues each RIR region will face during the exhaustion period vary by region as the level of development of IPv4 and IPv6 are widely different. As a result, applying a global co-ordinated policy may not adequately address issues in a certain region while it could be work for the others. For example, in a region where late comers desperately need even small blocks of IPv4 addresses to access to the IPv4 Internet, a policy that defines the target of allocations/assignments of IPv4 address space to be late comers would be appropriate in such region. This would allow availablilty of IPv4 address space for such requirements for more years. Another example comes from difference in IPv6 deployment rate. For a region where IPv6 deployment rate is low, measures may be necessary to prolong IPv4 address life for the existing business as well as for new businesses until networks are IPv6 ready. Some regions may have strong needs to secure IPv4 address space for translators. A globally coordinated policy which addresses all the issues listed above to meet the needs for all RIR regions may result in not solving issues in any of the regions. 2) LIRs and stakeholders remain unprepared for the situation if they are not informed If LIRs and the community are uninformed of the exhaustion, their services and networks remain unprepared to face the situation at the time of exhaustion. [Objective of the proposal] This proposal seeks to provide the following solutions to the problems listed above. 1) RIR community should be able to define their own regional policies on how to assign the last piece(s) of allocation block in order to address their own regional issues during the exhaustion period. 2) RIRs should provide official projection of the date when LIRs will be able to receive the allocations under the current criteria. The criteria should remain consistent until this date in order to avoid confusion. [Pros and Cons] Pros: + It allows each RIR community to define a policy on how to distribute the last piece(s) of allocations which best matches their situation. + It helps LIR better informed of the date when they are able to receive allocations from RIRs under the current criteria and prepare for the event. Cons: + Concerns could be raised about allocating a fixed size to all RIRs, that it artificially fastens the consumption rate of some RIR regions. However, its impact is kept to minimum by keeping the allocation size to a single /8 which makes merely 3-4 months difference. + Concerns could be raised that explicitly allowing regional policies will encourage RIR shopping. However, this should not happen if the requirements within each region is adequately reflected in each RIR's policy through PDP. RIR may also chose to add criteria to prevent LIRs from other regions submitting such requests. Timetable for implementation: Immediate after all 5 RIRs (and possibly ICANN) ratifies the policy. From info at arin.net Tue Aug 28 10:46:55 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:46:55 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 - AC postponed decision In-Reply-To: <46CDD840.1050001@arin.net> References: <46C5E72F.2080903@arin.net> <46CDD840.1050001@arin.net> Message-ID: <46D4355F.30000@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) postponed their decision regarding "IPv6 Assignment Guidelines" in order to work with the author on possible revisions. The AC will make their decision to accept or not accept the proposal as a formal policy proposal at a special AC meeting on 30 August 2007. 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) Member Services wrote: > The author submitted a revised version of their proposal. > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: IPv6 Assignment Guidelines > > Author: Leo Bicknell and Ed Lewis > > Proposal Version: 3.0 > > Submission Date: 8/23/2007 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Delete the text in 6.5.4.2 and Replace the text in section 6.5.4.1 > with the following text: > > Assignments by LIRs /48 or smaller will not be reviewed by ARIN. > Assignments greater than /48 will be reviewed to see if the additional > space is warranted according to the 0.94 HD ratio policy. If the > space is not warranted, ARIN will consider the excess space to be > available for a different assignment, lowering the overall utilization > score of the LIR. > > Rationale: > > The existing section 6.5.4.1 does not provide clear guidance on how > ARIN should treat prefixes allocated to a site should an ISP come > back for additional space in the future. This makes it difficult > for LIR's to know if they are allocating in accordance with the > rules under which they will be judged in the future. The existing > section also provides no guidence on what the LIR or ARIN should > do in the case a larger prefix is necessary. > > Timetable for implementation: immediate > > > > > 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 Guidelines >> >> Author: Leo Bicknell >> >> Proposal Version: 1.0 >> >> Submission Date: 8/17/2007 >> >> Proposal type: new >> >> Policy term: permanent >> >> Policy statement: >> >> Replace the text in section 6.5.4.1 with the following text: >> >> LIR's may assign blocks in the range of /48 to /64 to end sites. >> All assignments made by LIR's should meet a minimum HD-Ratio of .25. >> >> * /64 - Site needing only a single subnet. >> * /60 - Site with 2-3 subnets initially. >> * /56 - Site with 4-7 subnets initially. >> * /52 - Site with 8-15 subnets initially. >> * /48 - Site with 16+ subnets initially. >> >> 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. >> >> LIR's do not need to issue all 5 sizes of prefixes as long as the >> HD-Ratio requirement is met. >> >> Rationale: >> >> The existing section 6.5.4.1 does not provide clear guidance on how >> large of a prefix to allocate to a site. This makes it difficult for >> LIR's to know they are in compliance with the rules, and makes it harder >> for ARIN staff to evaluate requests per the communities wishes. >> >> This policy is based on an HD Ratio of .25 for end sites. The following >> table may be useful: >> >> Prefix Size Number of Subnets Required in Use to Meet .25 >> ----------- ----------------- --------------------------- >> /64 1 1 >> /60 16 2 >> /56 256 4 >> /52 4096 8 >> /48 65536 16 >> >> It is believed this policy provides clear guidance while allowing LIR's >> to make generous allocations to their end-sites. >> >> Timetable for implementation: immediate for new requests, 2 year grace >> period for all existing assignments. >> >> >> _______________________________________________ >> 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 Tue Aug 28 10:49:31 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:49:31 -0400 Subject: [ppml] Policy Proposal: ISP to LIR Clarification - version 1.1 - AC did not accept In-Reply-To: <46CDA832.7030709@arin.net> References: <46C5E745.5050708@arin.net> <46CDA832.7030709@arin.net> Message-ID: <46D435FB.4080506@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) concluded its review of the proposed policy 'ISP to LIR Clarification' and did not accept it as a formal policy proposal. The AC did not accept the proposal because the AC feels that this is not a policy matter, instead it should be incorporated into NRPM edit work that is being done by several members of the AC. 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 XX Public Policy Meeting is 23:59 EDT, 7 September 2007. 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) Member Services wrote: > The author submitted a revised version of their proposal. > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: ISP to LIR Clarification > > Author: Leo Bicknell > > Proposal Version: 1.1 > > Submission Date: 8/22/2007 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Replace all instances of the word "ISP" in the NRPM with the word > "LIR" and replace all instances of the phrase "LIR/ISP" with "LIR", > except for the following: > > * Leave section 2.4 unchanged. > * Leave section 2.7 unchanged. > * In section 4.1.1, replace "ISPs" with "requesters". > * In section 4.2.1.1, also remove "Internet Service Providers". > * Leave section 6.2.4 unchanged. > * Leave section 6.3.4 unchanged. > * In section 6.9, replace "ISPs and LIRs" with "LIRs" for all three > occurrence. > > Rationale: > > The NRPM is inconsistent. The terms ISP and LIR are used interchangeably > throughout the document, with the term ISP being predominant in the > IPv4 sections and the term LIR being predominant in the IPv6 sections. > > The use of the term ISP poses two different problems: > > 1) The term has meaning outside of ARIN's policy. Multiple discussions > on PPML have degenerated over people arguing what an ISP is with > regards to policy when the reality is that the relationship is > defined in the NRPM. As LIR has no meaning outside of policy > this confusion will be removed. > > 2) The other four RIRs have standardized on LIR. This change will make > it easier for those doing business with more than one LIR to use > consistent terms. > > This change does not alter any policy, it merely makes the policy easier > to understand. > > Timetable for implementation: immediate > > > > > 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: ISP to LIR Clarification >> >>Author: Leo Bicknell >> >>Proposal Version: 1.0 >> >>Submission Date: 8/17/2007 >> >>Proposal type: modify >> >>Policy term: permanent >> >>Policy statement: >> >>Replace all instances of the word "ISP" in the NRPM with the word "LIR" >>and replace all instances of the phrase "LIR/ISP" with "LIR", except for >>the following: >> >>* Leave section 2.4 unchanged. >>* Leave section 2.7 unchanged. >>* In section 4.1.1, replace "ISPs" with "requesters". >>* In section 4.2, also remove "Internet Service Providers". >>* Leave section 6.2.4 unchanged. >>* Leave section 6.3.4 unchanged. >>* In section 6.9, replace "ISPs and LIRs" with "LIRs" for all three >>occurrence. >> >>Rationale: >> >>The NRPM is inconsistent. The terms ISP and LIR are used >>interchangeably throughout the document, with the term ISP being >>predominant in the IPv4 sections and the term LIR being predominant in >>the IPv6 sections. >> >>The use of the term ISP poses two different problems: >> >>1) The term has meaning outside of ARIN's policy. Multiple discussions >> on PPML have degenerated over people arguing what an ISP is with >> regards to policy when the reality is that the relationship is >> defined in the NRPM. As LIR has no meaning outside of policy >> this confusion will be removed. >> >>2) The other four RIRs have standardized on LIR. This change will make >> it easier for those doing business with more than one LIR to use >> consistent terms. >> >>This change does not alter any policy, it merely makes the policy easier >>to understand. >> >>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. >> > > > > _______________________________________________ > 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 Tue Aug 28 10:55:14 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:55:14 -0400 Subject: [ppml] Policy Proposal: IPv6 Policy Housekeeping - AC postponed decision In-Reply-To: <46C5E767.6010406@arin.net> References: <46C5E767.6010406@arin.net> Message-ID: <46D43752.1070101@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) postponed their decision regarding "IPv6 Policy Housekeeping" in order to work with the author on possible revisions. The AC will make their decision to accept or not accept the proposal as a formal policy proposal at a special AC meeting on 30 August 2007. 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) 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 Policy Housekeeping > > Author: Leo Bicknell > > Proposal Version: 1.0 > > Submission Date: 8/17/2007 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Change A: > > Remove the text between the section 6 header and the section 6.1 > header. Remove section 6.1 entirely. Update all subsequent > sections to have new section numbers (6.[n-1]). > > Change B: > > Move the image in section 6.2 to section 2. > > Remove sections 6.2.1 to 6.2.6. > > Change C: > > Move section 6.2.7 to (new) section 2.8, subheading "IPv6". > > Create section 2.8, subheading "IPv4", containing the following text: > > In IPv4, utilization is the percentage of the address space > allocated or assigned relative to the total address space. > > Change D: > > Move section 6.2.8 to (new) section 2.8. > Move section 6.2.9 to (new) section 2.9. > > As this leaves section 6.2 empty, remove section 6.2. Update > all subsequent sections to have new section numbers (6.[n-1]). > > > Change E: > > Remove section 6.3. Update all subsequent sections to have new > section numbers (6.[n-1]). > > Change F: > > Remove section 6.4.1. Update all subsequent sections to have new > section numbers (6.4.[n-1]). > > Change G: > > Remove section 6.4.2. Update all subsequent sections to have new > section numbers (6.4.[n-1]). > > Change H: > > Remove section 6.4.4. > > Change I: > > In section 6.5.1.1.d, replace the existing statement with the new > statement: > > "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." > > Change J: > > Remove section 6.5.3 entirely. Update all subsequent sections to > have new section numbers (6.5.[n-1]). > > Replace part of the text as (new) section 6.5.4.4: > > "All /56 and larger assignments to end sites are required to be > registered either by the LIR or its subordinate ISPs in > such a way that the RIR/NIR can properly evaluate the > HD-Ratio when a subsequent allocation becomes necessary." > > Change K: > > Section 6.5.8.2, add the following sentence to the end of the first > paragraph: > > "An HD-Ratio of .94 must be met for all assignments larger than > a /48." > > Add to the end of the second paragraph: > > "This reservation may be assigned to other organizations > later, at ARIN's discretion." > > Change L: > > Section 6.5.8.3, add a sentence between the two existing sentences: > > "Justification will be determined based on the .94 HD-Ratio > metric." > > Change M: > > Remove section 6.6. Update all subsequent sections to have new > section numbers (6.[n-1]). > > Change N: > > Change the title of section 6.7 from "Appendix A: HD-Ratio" to > "HD-Ratio". > > Change O: > > Remove section 6.8. Update all subsequent sections to have new > section numbers (6.[n-1]). > > Rationale: > > When the IPv6 policy was passed, it was considered to be an "interim" > policy, and it was intended to be similar in all 5 RIR's. Since that > time it has become clear the policy is no longer interim (and proposal > 2007-4 was passed to change just that) and it has also been modified > separately in the different RIR's. > > It was brought to the ARIN AC's attention that there were a number of > problems with "Section 6" of the NRPM as a result of this legacy: > > * The policy contained a large number of items that were not policy. > * The policy contained a few items that were self contradictory. > * The added text was redundant in some cases with existing text. > * The policy was overly vague in a few areas, leaving ARIN staff to > have to make interpretations of what the policy intended. > * Policy changes made since the initial IPv6 policy was adopted have > not always updated all of the relevant sections due to the complexity > of section 6. > > The intent of these changes is not to change any existing policy, but > rather to remove all non-policy items, and update any ambiguous items > with the way that ARIN staff is currently interprets the policy. > > Change A: > > Not policy. Unnecessary. Confusing (policy is interim). > > Change B: > > Sections 6.2.1 to 6.2.6 are definitions that are already defined in > section 2.1 to 2.7 Repeating them here is unnecessary. The picture > is useful though, and should be moved to section 2 as part of the > definitions. > > Change C: > > This is a definition item, and should be in the definition section. > Also, the v4 versions should be defined at the same time. > > Change D: > > These are both definitions that should be in the definitions section. > > Change E: > > This is a manifesto, and is not address policy. If anything these > belong is ARIN's mission statement. > > Change F: > > Not policy; covered by the RSA as a legal matter. > > Change G: > > Not policy. A darn good warning though ARIN should include with > any other boilerplate when issuing address space. > > Change H: > > Not policy, and covered by actual policy statement 6.5.1.2. > > Change I: > > Proposal 2005-8 amended section 6.5.4.1 to allow /56 and /64 > allocations, but section 6.5.1.1.d was never updated to match > the change. It is believed the intent of the policy, and ARIN > staff's current interpretation of the policy match the updated > text. > > Change J: > > The first part is not policy, and incorrectly states there is no > policy as section 6.5.4 has the policy in it. Take the one useful > part and make it part of the 6.5.4 criteria. > > Change K: > > No metric is currently listed to justify a larger initial > assignment. It is believed ARIN staff is currently applying > the HD-Ratio similar to the ISP policy, this puts that in writing. > > Make it clear that the reservation may not exist in perpetuity. > > Change L: > > No metric is given to justify additional assignments. It is > believed that ARIN staff is currently applying the HD_Ratio > similar to the ISP policy, this puts that in writing. > > Change M: > > References, while useful on the web page and in template instructions > are not policy. > > Change N: > > It's not an appendix. It's not even at the end. > > Change O: > > The background information would be something nice to archive on the > ARIN web site somewhere, but is not policy and should be removed from > the policy manual. > > 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 Tue Aug 28 10:56:03 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:56:03 -0400 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses - AC did not accept In-Reply-To: <46C9A533.5090808@arin.net> References: <46C9A533.5090808@arin.net> Message-ID: <46D43783.9070205@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) concluded its review of the proposed policy 'Decreasing Exponential Rationing of IPv4 IP Addresses' and did not accept it as a formal policy proposal. The AC did not accept the proposal because it presents an approach, rather than defines a policy. There are no details around how or where it adds to, or alters, the current version of the NRPM. 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 XX Public Policy Meeting is 23:59 EDT, 7 September 2007. 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) 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: Decreasing Exponential Rationing of IPv4 IP Addresses > > Author: Dean Anderson > > Proposal Version: 1 > > Submission Date: 8/18/07 > > Proposal type: new > > Policy term: renewable > > Policy statement: > > ARIN will ration the remaining available IP Address Space according to a > decreasing exponential function in the family of e^(-x), where the > ultimate function and factors are chosen to ensure that the remaining IP > address space lasts for at least 10 years. > This function will be used to limit the IP Address space allocations. > If IP Address Space becomes available (e.g. via return), the ration can > be recalculated. However, Ration calculations will not be based on > projected or anticipated returns. Contested IP Address Space will also > be excluded from the amount of available Address Space for ration > calculations. > > Rationale: > > Two reports[1,2] project that IP Addresses will be exhausted around > March 2010. > > * Both reports agree that if IP Addresses continue to delegated at the > present rates, we will run out of space in March 2010. > > * Everyone seems to agree that depletion will be a very bad event. > > * It is therefore imperative to begin rationing to slow down the rate of > new delegations to conserve the available address space. > > * It is necessary to do this now. One can't start rationing after the > resources run out. > > Sudden IPv4 IP Address Exhaustion is expected to cause sudden disruption > and discontinuity in business operations and planning. As with other > limited resources, the mere anticipation of exhaustion will lead to > hoarding and other behaviors that increase the harm of a sudden exhaustion. > > Rationing on a decreasing exponential will essentially prevent total > exhaustion and will gradually decrease the rate of IP Address delegation > so to alleviate the harms of a sudden stop in IP Address delegation. > > Prevention of IPv4 IP Address Exhaustion will help ensure a smooth > transition to IPV6. > > Rationing helps ensures that IP Address space remains available to > future needs. > > > [1] http://www.potaroo.net/tools/ipv4/index.html > [2] http://www.tndh.net/~tony/ietf/ipv4-pool-combined-view.pdf > > 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 dean at av8.com Tue Aug 28 17:53:16 2007 From: dean at av8.com (Dean Anderson) Date: Tue, 28 Aug 2007 17:53:16 -0400 (EDT) Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: Message-ID: On Mon, 27 Aug 2007, Iljitsch van Beijnum wrote: > On 27-aug-2007, at 23:06, Dean Anderson wrote: > > > Fact 1: The Available IP Pool (AIP) will be exhausted on or about > > March, > > 2010 if no changes are made. > > Geoff Huston predicts june 2010 for the IANA pool and march 2011 for > the RIR reserves. This is a recent change in Huston's predictions. A few months difference from his previous prediction in July. Google cache of this page from Aug 4, shows April 16th, 2010. Tony Hain now says April 2010. This seems to be a lot of variation from July, when both said March 2010. This deserves further investigation. I suspect that in Huston's case, if he doesn't update the data from ARIN, etc, his program will see this as no new allocations and compute a new (but wrong) exhaustion date. I'll see if this is the case. It would be nice if these reports were archived somewhere. I can see about that, too. > > Fact 2: If the AIP is exhausted, it is unknown when address space > > will be returned that can be delegated. > > Address space is returned all the time. Last time I check was two > years ago IIRC, and that was 11 million addresses in a year. I'd say > it's likely that this will go down as we run out of IPv4 space because > people will want to hang on to what they've got and returning a few > small blocks for a larger one won't happen anymore. I agree. It is however, still unknown and unpredictable after exhaustion. > It goes without saying that the returned address space won't be nearly > enough to cover the requests that come in. I agree. > > Fact 3: Disruptions of unknown duration are more harmful to business > > planning than disruptions of known duration. > > Even more harmful is thinking a disruption is temporary when it is in > fact permanent. And how is this disruption permanent? > > Fact 5: Rationing any kind of limited resource inhibits hoarding > > No, it just makes it start sooner You are wrong: The start time for hoarding is the realization that a resource is running out. > and the iterations as new blocks come available and assignments resume > temporarily allow the hoarders to learn and become more effective. The people in charge of rationing also learn, and also become more effective. The hoarders incur smaller losses in the meantime. > > Fact 6: IPv4 usage will not end because of AIP exhaustion. > > Growth will end, and many economic models require growth. Nonsense. Dead applications like dialup are replaced by new applications. Growth of new business eventually resumes. It is merely disrupted, unnecessarilly. > > Fact 7: IPv4 allocation will eventually resume after exhaustion > > Not in any meaningful way. Sure, if you need a /24, you'll be able to > get it at some point, but if you need a /12, that's simply not going > to happen. Wrong again. Eventually, when the DoD converts to IPv6, some /8's will come back. When MERIT dismantles its dialup network, at least a /8 will come back. If MIT decides not to monetize its /8, that could come back. We just don't know when these things might happen. > > However, after exhaustion, we won't be able to predict when > > allocation might resume. > > It's not a stop/wait/resume thing, what will happen is that large > blocks will no longer be available but small blocks will continue to > be assigned unless so many requests come in that seem legitimate > enough to soak up all remaining space. It is a stop/wait/resume thing, if we exhaust the available pool: Allocation will _stop_, Then one will have to _wait_ until enough IP space comes back to fullfil their request, at which point, allocation will _resume_. > > Your reason for objection is to promote IPv6. IPv6 should have > > nothing to do with IPv4 resource management. > > A smooth transition from IPv4 to IPv6 is in everyone's interest. IPv4 > is a sinking ship. You don't have to jump in a life boat right this > minute, but planning new trips is not a smart thing to do. IPv4 is not a sinking ship at all. People said Fax would be totally obsolete in the 1990s, replaced by email. Now we use both. Likewise, we will continue to use both IPv4 and IPv6. There will continue to be IPv4 applications, because IPv6 is too heavy for some applications. Text messaging and cheap cell phones did not entirely replace pagers. Likewise, IPv6 will never, ever entirely replace IPv4. It may be that some applications only use IPv6, just like some applications only use cellphones. > > There is no expiration date for IPv4. That's your fallacy (or > > fantasy). > > Right, when 9 billion people are running IPv6, the 900 million people > running IPv4 have no reason to change protocols. Just like fax, and pager networks, IPv4 will still have utility. You don't seem to understand the concept of utility. > >> I'm not trying to wreck IPv4. > > > I think you are. You are attempting to stop prudent action to avert > > a foreseeable and avoidable problem with a shortage in IPv4 IP > > Address Availability. That doesn't help keep it in a "usable > > state". > > Your mistake is focussing on IPv4 exclusively. The point is that we > have a working internet. Today, we need IPv4 for that. In a few years, > IPv4 won't be able to provide this function for new users, so we need > to move to IPv6. Making it harder for new users sooner doesn't help > those IPv4 and the market forces are such that it also delays the real > solution = moving to IPv6. Nonsense. Market forces are such that a good, free solution always wins. There is no 'final solution'. There is a new, larger network, and an older, smaller network. Both will exist for as long as civilation finds them useful. And IPv4 will remain useful for a long time. > > Your justification for your view is that you want to get IPv4 'over > > and done with' to move onto IPv6. That's just sabotage of IPv4. > > Absolutely not. You and others said exactly that: 'get IPv4 over and done with' > I want IPv4 to remain useful as long as it can, which means NOT making > it harder to get IPv4 address space, which is already relatively hard > today. Interesting logic. However, the harms of exhaustion mean that we need to prudently restrain the consumption of IPv4 space until more space is returned to the free pool. I suppose if you push someone over a cliff, you'd say you were just helping them get a better view, too. The ill-intent of getting 'IPv4 over and done with' is already apparent. Your 'good intention' doesn't hold water. Just like a claim of helping your enemy 'get a better view' wouldn't hold water, either. > >> China has gotten 30 million addresses so far this year. That's more > >> than all year last year. Once China has caught up, the really poor > >> countries are next in line. IPv4 can't sustain our growing > >> communication needs, it's as simple as that. > > > Then they'll be happy to move to IPv6. You won't have to mismanage > > IPv4 to encourage them. > > Oh so it's only the poor people that should use IPv6? You are the only one making that assertion. I'm just pointing out that you still won't have to mismanage IPv4 to encourage them. Or anyone else. > >> I recommend reading a good book about it. > > > Its kind of hard to find a good book that hasn't been obsolesced by > > the continuing changes to IPv6, judging by the RFC index. > > Anything published in 2003 or later should be in reasonable shape in > that department. My book is now 2 years old and I don't think there > are significant issues in this area. Sometimes it helps that the IETF > moves so slow. :-) Apparently, you also need to review the RFC index, for the slew of changes since 2003. There have been 1500 RFCs published since then. Quite a few of those are for IPv6. I'd say anything published before 2007 is obsolete. And even that might not last long. > > Here's one DNS example: Recently, a Country code (cctld) domain > > operator tried to add IPv6 AAAA record support to their cctld name > > service. If I recall correctly, they found that they could only > > have 6 A records, and 3 AAAA records before they ran out of the > > (IPv4) packet size limitations (512 bytes). > > EDNS0 is your friend, Yes, EDNSO is so servers can send larger packets. However, many resolvers do not support EDNSO responses. Further, EDNSO packets may need to be fragmented, requiring state on the server for Path MTU discovery. So EDNSO is unsuitable for anycasted servers. Hmm. Haven't we discussed that before. Something about hardball came into play....Why do you suppose people play hardball? Do you suppose they just started that? But one could have dropped a lot of cruft in IPv6 for DNS. IPv4 DNS is one of the early, ugly protocols, that can't be changed easily because of the installed base. IPv6 didn't have an installed base. It _could_ have used a totally new and clean DNS protocol. Certain influential people associated with root and TLD operators didn't want to do that. They had their reasons, I'm sure. Those reasons just weren't in the public's best interest. > people who use stupid firewalls get what they deserve. I don' see a > problem. (But then again, I'm not a root server operator.) Its not the firewalls that prevent universal EDNSO. But there is a problem that you obviously "don't see". The market has a way of dealing with blindness such as yours; it doesn't adopt the product. And rather than 'open your eyes', you want to coerce the market to adopt your product by sabotaging the competition, IPv4. > > There is no technical reason that IPv6 DNS should talk to an IPv4 > > nameserver. > > The DNS is used to determine if a remote system is reachable over IPv4 > or IPv6. This means that address records for both protocols must be > present in the same name space and then separating the two protocols > makes no sense. Yep. That was a red-herring: An IPv6 application doesn't need to know if a system is reachable over IPv4. An IPv4 application doesn't need to know if a system is reachable via IPv6. There are no mixed applications, except for root and TLD DNS; there are no mixed applications for mixed root/TLD DNS to serve. So, there is still no technical reason for putting both in the same DNS server. The only people who even want to mix them are the Root and TLD operators. And the only reason is so that they can continue on the same IP address not have to compete to be new IPv6 operators. > > So, there is a lot of cruft and limitation in IPv4 DNS that would be > > quite good to remove from IPv6. None of that happened. > > I'm with you on that one, they could have made EDNS0 mandatory for > IPv6. Although I think the real issue here is the IPv6 socket API, > which happily continues the layer violations that were unavoidable for > IPv4 but could have been cleaned up when IPv6 required changes. API's have nothing to do with it. There were many API's for IPv4; many stacks. You can always write a new API. You can write a new API for IPv6, and even a new stack. Of course, which RFC's and protocol the stack implements is difficult, since the RFC's and protocol details keep changing. That's why different implementations of IPv6 stacks don't interoperate. > > IPv6 is designed in someways to profit some people. > > Yeah right. People are making money off of IPv6 left and right... Root server operators and TLD operators are selling anycast clones. I hear they get between $2k and $5k a month for servers. Multiply that times 47 (last number I had, about a year ago) for ISC, and Verisign announced it expected 70 a while back. The money adds up. But yes: Almost no one else is making money off IPv6; that was my point. > > The other part is that IPv6 seems to be so unstable (due to > > continuous changes) that nothing works very well. > > Actually it works extremely well. There are lots of times when IPv4 > requires hacks that are completely unnecessary with IPv6. > > Unfortunately, IPv6 doesn't (yet) do everything IPv4 does. For > instance, you can't do dial-up over IPv6 in a mixed vendor > environment. There you go, then. I'd say that is not working extremely well. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From dean at av8.com Tue Aug 28 17:54:34 2007 From: dean at av8.com (Dean Anderson) Date: Tue, 28 Aug 2007 17:54:34 -0400 (EDT) Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses - AC did not accept In-Reply-To: <46D43783.9070205@arin.net> Message-ID: I'll rewrite the proposal as a change to the policy manual, and resubmit it. --Dean On Tue, 28 Aug 2007, Member Services wrote: > On 23 August 2007, the ARIN Advisory Council (AC) concluded its review > of the proposed policy 'Decreasing Exponential Rationing of IPv4 IP > Addresses' and did not accept it as a formal policy proposal. The AC did > not accept the proposal because it presents an approach, rather than > defines a policy. There are no details around how or where it adds to, > or alters, the current version of the NRPM. > > 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 XX Public Policy Meeting is 23:59 EDT, 7 > September 2007. 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) > > > 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: Decreasing Exponential Rationing of IPv4 IP Addresses > > > > Author: Dean Anderson > > > > Proposal Version: 1 > > > > Submission Date: 8/18/07 > > > > Proposal type: new > > > > Policy term: renewable > > > > Policy statement: > > > > ARIN will ration the remaining available IP Address Space according to a > > decreasing exponential function in the family of e^(-x), where the > > ultimate function and factors are chosen to ensure that the remaining IP > > address space lasts for at least 10 years. > > This function will be used to limit the IP Address space allocations. > > If IP Address Space becomes available (e.g. via return), the ration can > > be recalculated. However, Ration calculations will not be based on > > projected or anticipated returns. Contested IP Address Space will also > > be excluded from the amount of available Address Space for ration > > calculations. > > > > Rationale: > > > > Two reports[1,2] project that IP Addresses will be exhausted around > > March 2010. > > > > * Both reports agree that if IP Addresses continue to delegated at the > > present rates, we will run out of space in March 2010. > > > > * Everyone seems to agree that depletion will be a very bad event. > > > > * It is therefore imperative to begin rationing to slow down the rate of > > new delegations to conserve the available address space. > > > > * It is necessary to do this now. One can't start rationing after the > > resources run out. > > > > Sudden IPv4 IP Address Exhaustion is expected to cause sudden disruption > > and discontinuity in business operations and planning. As with other > > limited resources, the mere anticipation of exhaustion will lead to > > hoarding and other behaviors that increase the harm of a sudden exhaustion. > > > > Rationing on a decreasing exponential will essentially prevent total > > exhaustion and will gradually decrease the rate of IP Address delegation > > so to alleviate the harms of a sudden stop in IP Address delegation. > > > > Prevention of IPv4 IP Address Exhaustion will help ensure a smooth > > transition to IPV6. > > > > Rationing helps ensures that IP Address space remains available to > > future needs. > > > > > > [1] http://www.potaroo.net/tools/ipv4/index.html > > [2] http://www.tndh.net/~tony/ietf/ipv4-pool-combined-view.pdf > > > > 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. > > > > > _______________________________________________ > 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. > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From michael.dillon at bt.com Wed Aug 29 05:10:12 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 29 Aug 2007 10:10:12 +0100 Subject: [ppml] Combining Forecasts In-Reply-To: References: Message-ID: > This is a recent change in Huston's predictions. A few months > difference from his previous prediction in July. Google > cache of this page from Aug 4, shows April 16th, 2010. Tony > Hain now says April 2010. > > This seems to be a lot of variation from July, when both said > March 2010. This deserves further investigation. I suspect > that in Huston's case, if he doesn't update the data from > ARIN, etc, his program will see this as no new allocations > and compute a new (but wrong) exhaustion date. I'll see if > this is the case. Combining forecasts by averaging them has been shown to improve the accuracy of forecasting. Perhaps it is time to dig some of the other forecasts out of the woodwork so that we have more than just Tony's and Geoff's work. If you are interested in the study of combining forecasts, then check this paper http://www.forecastingprinciples.com/paperpdf/Combining%20forecasts.pdf and the annotated bibliography mentioned in the references. > IPv4 is not a sinking ship at all. People said Fax would be > totally obsolete in the 1990s, replaced by email. Now we use > both. Likewise, we will continue to use both IPv4 and IPv6. > There will continue to be IPv4 applications, because IPv6 is > too heavy for some applications. Text messaging and cheap > cell phones did not entirely replace pagers. TV made radio obsolete. CDs made vinyl obsolete. The automobile made horses obsolete. If we can learn anything from history, it is that old technologies that were widespread almost always find a niche and hang around for a lot longer than people imagine. The ones that die out quickly are the ones which were never very widespread like Banyan VINES or vacuum tube computers or drum memory or 8-track tapes. If you want to run TCP/IP on a Z80 (remember those?) then you will probably keep on running IPv4 until they stop manufacturing Z80 chips. http://www.computer-solutions.co.uk/chipdev/micronet.htm And yes, you can still buy Z80s today http://www.zilog.com/products/family.asp?fam=220 --Michael Dillon From iljitsch at muada.com Wed Aug 29 06:21:05 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 29 Aug 2007 12:21:05 +0200 Subject: [ppml] Combining Forecasts In-Reply-To: References: Message-ID: On 29-aug-2007, at 11:10, wrote: > Combining forecasts by averaging them has been shown to improve the > accuracy of forecasting. Perhaps it is time to dig some of the other > forecasts out of the woodwork so that we have more than just Tony's > and > Geoff's work. Here's mine. Please note that the numbers I'm about to mention are based on the dayly RIR allocation reports that I download from their FTP servers a few times a week. You can peruse this information yourself at http://www.bgpexpert.com/addrspace.php but caveats apply; also see http://www.bgpexpert.com/addrspace2005.php and http:// www.bgpexpert.com/addrspace2006.php . On january first, 2005, the total free address space (= free in the global IANA pool and the space delegated to RIRs by IANA, but not to LIRs/ISPs/end-users by RIRs) was 97.4 /8s. A year later it was 87.5 and on january first, 2007, it was 77.5. So we've been using up pretty much exactly 10 /8s a year in 2005 and 2006. Today the free space is 69.8 /8s. And interestingly, earlier this year a legacy /8 was returned to the IANA pool, something that hasn't happened for many years. So in 8 months (2/3s of a year) we've been using up either 7.7 or 8.7 /8s, depending on how you count that reclaimed block while 6.7 would have been expected during such a period based on the last two years. So that's a 15 to 30 % increase in yearly address use. Let's project this into the future, and include a stable 11 /8s a year option just for kicks: 0% 15% 30% used free used free used free 2008-1-1: 11.0 67.5 11.5 66.0 13.0 64.5 2009-1-1: 11.0 56.5 13.2 52.8 16.9 47.6 2010-1-1: 11.0 45.5 15.2 37.6 21.9 25.7 2011-1-1: 11.0 34.5 17.5 20.1 28.4 -2.7 2012-1-1: 11.0 23.5 20.1 0.0 2013-1-1: 11.0 12.5 2014-1-1: 11.0 1.5 So if nothing happens, we have until about valentine's day 2014, but if we have a new trend on our hands it's either new year 2012 or late 2010. However, the yearly address consumption has never shown clear trends that keep going for more than a few years. What often happens is that there is a sudden increase from one year to the next, and then a decrease or stagnation in the year after. So I don't think we'll see a consistent 30% trend, or even a 15% one. I'd say there's a 25% chance we'll run out in 2011, a 40% chance that it's 2012 and a 25% chance it's 2013. From iljitsch at muada.com Wed Aug 29 07:31:07 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 29 Aug 2007 13:31:07 +0200 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: References: Message-ID: <1C57BC25-FF63-4482-8AAE-A6D837085844@muada.com> On 28-aug-2007, at 23:53, Dean Anderson wrote: >> Geoff Huston predicts june 2010 for the IANA pool and march 2011 for >> the RIR reserves. > This is a recent change in Huston's predictions. A few months > difference > from his previous prediction in July. Google cache of this page from > Aug 4, shows April 16th, 2010. Tony Hain now says April 2010. And I say during the London summer olympics. > This seems to be a lot of variation from July, when both said March > 2010. This deserves further investigation. It's very simple: the data is extremely inconsistent. You need to do a lot of smoothing to make the curves fit any particular model. So a small change in the data or the interpretation can make a big difference. > I suspect that in Huston's > case, if he doesn't update the data from ARIN, etc, I believe this happens daily, not sure though. >>> Fact 3: Disruptions of unknown duration are more harmful to business >>> planning than disruptions of known duration. >> Even more harmful is thinking a disruption is temporary when it is in >> fact permanent. > And how is this disruption permanent? The IPv4 address factory only built 3706.65 million usable ones, when those are gone, they're gone. When you pump the lake dry, you'll have rain from time to time but that doesn't mean you will be going swimming any time soon. >>> Fact 5: Rationing any kind of limited resource inhibits hoarding >> No, it just makes it start sooner > You are wrong: The start time for hoarding is the realization that a > resource is running out. Nothing sends that message better than a request turned down because there are no addresses available, regardless of whether this is artificial or real. >> and the iterations as new blocks come available and assignments >> resume >> temporarily allow the hoarders to learn and become more effective. > The people in charge of rationing also learn, and also become more > effective. They'll never be effective as long as address allocation is done based on information supplied by the organization that requests them, it's too simple to lie. >>> Fact 6: IPv4 usage will not end because of AIP exhaustion. >> Growth will end, and many economic models require growth. > Nonsense. Dead applications like dialup are replaced by new > applications. Growth of new business eventually resumes. It is merely > disrupted, unnecessarilly. With dial-up you only need one address per modem, which is something like one address per 4 - 10 customers. When dial-up is replaced by broadband, you need 1 address per customer. I don't understand how anyone can think IPv4 will be a viable long- term technology AFTER the IPv4 address space has been depleted. I agree that IPv4 won't go away over night because it will continue to function for those who already have addresses, but building networks based on the assumption that at some point, someone will return some addresses and you may be able to get some of those is very bad engineering. > Wrong again. Eventually, when the DoD converts to IPv6, some /8's will > come back. So? We burn /8s up in a month, currently. If the US government returns the ~ 10 /8s they have that's only one year worth of address space. > When MERIT dismantles its dialup network, at least a /8 will come > back. Right, because they operate 16 million dial-up modems right now. > It is a stop/wait/resume thing, if we exhaust the available pool: > Allocation will _stop_, Then one will have to _wait_ until enough IP > space comes back to fullfil their request, at which point, allocation > will _resume_. After we run out, there is simply NO WAY that enough address space comes back to continue current IPv4 practices. It's nice if 25% of the requests can still be fullfilled from reclaimed address space, but it still means that 75% of the requests will be denied so the people doing those requests will have to find some other way to address their needs. >> A smooth transition from IPv4 to IPv6 is in everyone's interest. IPv4 >> is a sinking ship. You don't have to jump in a life boat right this >> minute, but planning new trips is not a smart thing to do. > IPv4 is not a sinking ship at all. People said Fax would be totally > obsolete in the 1990s, replaced by email. Now we use both. Hm, I was just thinking the other day whether I needed to keep my fax number the other day since I hadn't received any faxes in almost a year. But this is not a good analogy. Email and fax provide a very different experience. For a user, IPv4 or IPv6 are completely identical. I can't tell whether I'm using IPv4 or IPv6, let alone users who can't even spell "RFC". But for the same reason that we don't use iron gall ink any more, IPv4 will go the way of the dinosaurs at some point. So will IPv6, or pretty much any technology that we use today. The reason why old technology sticks around longer than expected is usually because it has properties that are desireable in certain situations, but is effect deminishes as the technology is further removed from the user experience. > There will continue to be IPv4 applications, because IPv6 is too > heavy for some applications. No. That's not a consideration at all. > Just like fax, and pager networks, IPv4 will still have utility. You > don't seem to understand the concept of utility. The utility of IPv4 is that you can reach everything connected to the internet. As soon as you can also reach everything connected to the internet over IPv6, IPv4 has no use anymore. (Of course it's not going to happen like that: there will be a period when you can only reach everything connected to the internet if you have BOTH IPv4 and IPv6.) >> I want IPv4 to remain useful as long as it can, which means NOT >> making >> it harder to get IPv4 address space, which is already relatively hard >> today. > Interesting logic. However, the harms of exhaustion mean that we need > to prudently restrain the consumption of IPv4 space until more > space is > returned to the free pool. This way, we don't go from a model where there is a reasonable amount of IPv4 address space available to a model where there is an abundance of IPv6 space, but rather to a model where we stick to IPv4, but are starved for addresses. That would be very bad. > I suppose if you push someone over a cliff, > you'd say you were just helping them get a better view, too. What do you say when you push someone over a cliff? Personally, I've never had occasion to come up with a pithy cliff pushing line. > The ill-intent of getting 'IPv4 over and done with' is already > apparent. > Your 'good intention' doesn't hold water. My intent includes keeping IPv4 as useful as possible for as long as possible. But IPv4 has an expiration date, people need to realize that. >>> Its kind of hard to find a good book that hasn't been obsolesced by >>> the continuing changes to IPv6, judging by the RFC index. >> Anything published in 2003 or later should be in reasonable shape in >> that department. My book is now 2 years old and I don't think there >> are significant issues in this area. Sometimes it helps that the IETF >> moves so slow. :-) > Apparently, you also need to review the RFC index, for the slew of > changes since 2003. There have been 1500 RFCs published since then. > Quite a few of those are for IPv6. I'd say anything published before > 2007 is obsolete. And even that might not last long. A book from 2003 probably doesn't talk about the site local issue, but it should have the current situation for IPv6 in the DNS and DHCPv6. So I'd say "usable". As for my own book (late 2005), the only thing that I'm aware of that is missing in it is the whole RH0 issue. >> EDNS0 is your friend, > Yes, EDNSO is so servers can send larger packets. However, many > resolvers do not support EDNSO responses. Come on, this is the 21st century. EDNS0 is 8 years old, apply the same policy as you do to your tech books. > Further, EDNSO packets may > need to be fragmented, requiring state on the server for Path MTU > discovery. With IPv6 this is possible in theory but the minimum maximum packet size is 1280, which holds a very significant DNS response. The DNS/ UDP protocol doesn't support reducing its packet size so you can't do path MTU discovery for IPv4, you need to let fragmentation happen. This has been an IPv4 feature for 26 years so I don't see the problem with that. > So EDNSO is unsuitable for anycasted servers. No it isn't and that doesn't follow from your earlier claims. >> people who use stupid firewalls get what they deserve. I don' see a >> problem. (But then again, I'm not a root server operator.) > Its not the firewalls that prevent universal EDNSO. http://searchwinit.techtarget.com/tip/0,289483,sid1_gci991813,00.html > That was a red-herring: An IPv6 application doesn't need to know > if a system is reachable over IPv4. An IPv4 application doesn't > need to > know if a system is reachable via IPv6. Hm, let's see, how many applications are out there that work over IPv6 and not IPv4? Let me do a quick count... That would be two: ping6 and traceroute6. Applications that support IPv6 also support IPv4. > There are no mixed applications, Really? # ftp ftp.arin.net Trying 2001:500:4:1::21... # ftp -4 ftp.arin.net Trying 192.149.252.20... > the RFC's and protocol details keep > changing. That's why different implementations of IPv6 stacks don't > interoperate. They interoperate just fine. I've used Cisco, Juniper, MacOS X, Linux, Windows XP and FreeBSD and they all work together just fine except for IPv6 over PPP and there is some path MTU discovery blackholing if you make the XP machine an IPv6 router. From tme at multicasttech.com Wed Aug 29 07:38:44 2007 From: tme at multicasttech.com (Marshall Eubanks) Date: Wed, 29 Aug 2007 07:38:44 -0400 Subject: [ppml] Combining Forecasts In-Reply-To: References: Message-ID: Hello; On Aug 29, 2007, at 6:21 AM, Iljitsch van Beijnum wrote: > On 29-aug-2007, at 11:10, > wrote: > >> Combining forecasts by averaging them has been shown to improve the >> accuracy of forecasting. Perhaps it is time to dig some of the other >> forecasts out of the woodwork so that we have more than just Tony's >> and >> Geoff's work. > I think that the trouble with the forecasts is not the numbers, nor the math, nor even the approaches, but the assumptions. None of the forecasts that I am aware of have any price elasticity in them, and this will become critical as exhaustion nears. Let me explain this a little. Of course an address market is developing and will develop, and that will either - cause a land rush (which I see signs of developing now) and / or - supplant the existing mechanisms. Such developments are by their nature very hard to predict. However, I can make some meta-predictions - If nothing is done, there will be a land rush soon and once it starts the remaining addresses will disappear very suddenly, probably within a few months, starting at some time that is very hard if not impossible to predict in advance, because this is a psychological effect, much like stock market bubbles or crashes. - If requirements are increasingly tightened, or artificial restrictions are imposed like the exponential slowdown of assignments proposed earlier, or the assignments are stopped for "cooling off" once the land rush is underway, the market will gradually (or rapidly) supplant the assignment mechanisms, and it is conceivable that total exhaustion will not occur for some time. (At some point, it would be easier to buy / lease / rent addresses than to go to a RIR and obtain them through assignment, and so the pressure on assignments would relax, and you would expect that exhaustion would be approached asymptotically.) - it is entirely possible that a land rush will cause a spurt of market development and, as addresses start to become valuable, a lot will "come out of the woodwork" as people start to realize that they have some they can give up for cash, and then the system will convert to an asymptotic approach to exhaustion. Please note that I am not proposing a market here, I am just stating that I see it as inevitable given current trends. Note that once it forms (whether openly, or underground, or through some shadow play like the long term lease of PA space from a consolidator) there will be market forces opposing the adoption of IPv6 (as it will reduce the market value of their assets). My personal opinion is that it would be better to capture that market and de-nature it (say, by requiring IPv6 support to trade PI space). Is it useless to predict, then ? No, of course not. In fact, I think that predictions should be used to help evaluate policy proposals in this area (i.e., policy proposals should be included in predictions to see if they actually have the desired effects). This, frankly, sounds like a full time job for a professional statistician. I would be glad to discuss thus further off list and kibitz about ways to incorporate these ideas in forecasts. Regards Marshall > Here's mine. Please note that the numbers I'm about to mention are > based on the dayly RIR allocation reports that I download from their > FTP servers a few times a week. You can peruse this information > yourself at http://www.bgpexpert.com/addrspace.php but caveats apply; > also see http://www.bgpexpert.com/addrspace2005.php and http:// > www.bgpexpert.com/addrspace2006.php . > > On january first, 2005, the total free address space (= free in the > global IANA pool and the space delegated to RIRs by IANA, but not to > LIRs/ISPs/end-users by RIRs) was 97.4 /8s. A year later it was 87.5 > and on january first, 2007, it was 77.5. So we've been using up > pretty much exactly 10 /8s a year in 2005 and 2006. > > Today the free space is 69.8 /8s. And interestingly, earlier this > year a legacy /8 was returned to the IANA pool, something that hasn't > happened for many years. So in 8 months (2/3s of a year) we've been > using up either 7.7 or 8.7 /8s, depending on how you count that > reclaimed block while 6.7 would have been expected during such a > period based on the last two years. So that's a 15 to 30 % increase > in yearly address use. Let's project this into the future, and > include a stable 11 /8s a year option just for kicks: > > 0% 15% 30% > used free used free used free > 2008-1-1: 11.0 67.5 11.5 66.0 13.0 64.5 > 2009-1-1: 11.0 56.5 13.2 52.8 16.9 47.6 > 2010-1-1: 11.0 45.5 15.2 37.6 21.9 25.7 > 2011-1-1: 11.0 34.5 17.5 20.1 28.4 -2.7 > 2012-1-1: 11.0 23.5 20.1 0.0 > 2013-1-1: 11.0 12.5 > 2014-1-1: 11.0 1.5 > > So if nothing happens, we have until about valentine's day 2014, but > if we have a new trend on our hands it's either new year 2012 or late > 2010. However, the yearly address consumption has never shown clear > trends that keep going for more than a few years. What often happens > is that there is a sudden increase from one year to the next, and > then a decrease or stagnation in the year after. So I don't think > we'll see a consistent 30% trend, or even a 15% one. I'd say there's > a 25% chance we'll run out in 2011, a 40% chance that it's 2012 and a > 25% chance it's 2013. > _______________________________________________ > 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 jcurran at istaff.org Wed Aug 29 08:10:35 2007 From: jcurran at istaff.org (John Curran) Date: Wed, 29 Aug 2007 08:10:35 -0400 Subject: [ppml] Seeking additional participation in the Internet Resource Policy Evaluation Process? Message-ID: Folks - One of the most important aspects of our policy formation process is the role of the ARIN Advisory Council in review and evaluation of Internet resource policy proposals. Our success to date in maintaining clear and consistent policies is due to the remarkable efforts of those individuals who have given their time to the ARIN Advisory Council over the years. Each year, we have the opportunity to strengthen the ranks of the ARIN AC through the election of new members, and/or the reelection of existing members. That time of year is now upon us, and as it turns out, we are actively seeking additional nominees to serve on the ARIN AC. In fact, the deadline for nominations has been extended to 17:00 ET *today* in order to assure an adequate slate of candidates. Please take a moment to consider whether you or someone you know has the time and background to serve on the ARIN Advisory Council, and nominate accordingly. More information may be found at . Thank you, /John John Curran Chairman American Registry of Internet Numbers From owen at delong.com Wed Aug 29 09:11:57 2007 From: owen at delong.com (Owen DeLong) Date: Wed, 29 Aug 2007 06:11:57 -0700 Subject: [ppml] Combining Forecasts In-Reply-To: References: Message-ID: > >> IPv4 is not a sinking ship at all. People said Fax would be >> totally obsolete in the 1990s, replaced by email. Now we use >> both. Likewise, we will continue to use both IPv4 and IPv6. >> There will continue to be IPv4 applications, because IPv6 is >> too heavy for some applications. Text messaging and cheap >> cell phones did not entirely replace pagers. > > TV made radio obsolete. And yet, I hardly ever see a car without one, advertisers still buy time on radio, two companies launched completely new radio services long after TV had been around for several years (XM and Sirius). I would say TV did not make radio obsolete since radio is still going strong. Radio is not a niche. > CDs made vinyl obsolete. True to some extent, but, there is still a strong contingent of people who prefer vinyl and a resurgence of vinyl collectors occurs from time to time. > The automobile made > horses obsolete. As a primary mode of transportation, sure. OTOH, horse racing, and other recreational equestrian activities are still going strong. In fact, in many ranching applications, horses are still preferred over motor vehicles. > If we can learn anything from history, it is that old > technologies that were widespread almost always find a niche and hang > around for a lot longer than people imagine. The ones that die out > quickly are the ones which were never very widespread like Banyan > VINES > or vacuum tube computers or drum memory or 8-track tapes. > NetBEUI was pretty wide-spread at one point, and, has since died out _VERY_ quickly. If we can learn anything from history, it is that mass market moves are incredibly difficult to predict and planning the obsolescence of a high-demand technology is virtually impossible. Owen From narten at us.ibm.com Wed Aug 29 09:31:58 2007 From: narten at us.ibm.com (Thomas Narten) Date: Wed, 29 Aug 2007 09:31:58 -0400 Subject: [ppml] Combining Forecasts In-Reply-To: References: Message-ID: <200708291332.l7TDVwM4003675@cichlid.raleigh.ibm.com> The topic of predicting the exact time/date for IPv4 "exhaustion" is a complete waste of time. The only thing that really matters is that it's going to happen (with certainty) and soon enough that it is now foolish to push off preparing/planning for it. Whether it happens 6 months or a year earlier or later from a prediction made today just doesn't matter much, as the action to be done now is pretty much the same, regardless of the date: Get ready and make real plans. Thomas From jweyand at computerdata.com Wed Aug 29 16:12:41 2007 From: jweyand at computerdata.com (Jim Weyand) Date: Wed, 29 Aug 2007 16:12:41 -0400 Subject: [ppml] Multi-disciplinary Approach to IPv4 Address Space Exhaustion Message-ID: <1582DCBFF968F044A9A910C0AB177C902CE151@cliff.cdi.local> Several months ago somebody suggested that the community's needs might be well served by inviting some non-technology people to participate. In that spirit I sent emails to the Department Chairs of the Department of Economics at the University of Chicago, University of Michigan and Georgia Tech. I don't know any of these people and I have no idea if they will choose to participate. If you know anybody from one of these departments or you have your own favorite economist please invite somebody with an outsider's perspective. For your convenience I have included a copy of the email I sent to the various professors. Dear Professor XX: I am writing to invite you, your colleagues and your students to participate in an interesting discussion regarding IPv4 Address Space Exhaustion. IP Addresses are used to identify unique elements and groups of elements (or hosts and networks) on the Internet. A reasonably accurate description of the problem can be found at: http://en.wikipedia.org/wiki/IPv4_address_exhaustion There is an on-going discussion (via email) about how to best serve the needs of the Internet community which, at this point, is largely dominated by technologists. At least one participant has suggested that a multi-disciplinary approach may lead to a better solution. If you or somebody else from the University of XX are interested in this discussion you can subscribe to the email list by going to: http://www.arin.net/mailing_lists/index.html and subscribing to the ARIN Public Policy Mailing List or ppml at arin.net Participants in this list include many key players in the Internet governing bodies as well as interested persons like myself and I am sure your thoughts regarding distribution of scarce resources will be well received. If you have any questions you are welcome to contact me directly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Thu Aug 30 02:42:00 2007 From: randy at psg.com (Randy Bush) Date: Thu, 30 Aug 2007 15:42:00 +0900 Subject: [ppml] Combining Forecasts In-Reply-To: <200708291332.l7TDVwM4003675@cichlid.raleigh.ibm.com> References: <200708291332.l7TDVwM4003675@cichlid.raleigh.ibm.com> Message-ID: <46D666B8.6010309@psg.com> > The topic of predicting the exact time/date for IPv4 "exhaustion" is a > complete waste of time. except for how amusingly accurate frank solensky was over a decade ago. randy From michael.dillon at bt.com Thu Aug 30 05:24:34 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 30 Aug 2007 10:24:34 +0100 Subject: [ppml] Combining Forecasts In-Reply-To: <46D666B8.6010309@psg.com> References: <200708291332.l7TDVwM4003675@cichlid.raleigh.ibm.com> <46D666B8.6010309@psg.com> Message-ID: > except for how amusingly accurate frank solensky was over a > decade ago. Once upon a time, Frank said this: Frank Solensky: ...(my) estimates for maximum address space utilization have risen about 8% over the last 3 years. If one were to argue for extrapolating this over time as well, the resulting statement would be that "in the year 2019, the trend line will suggest that we will eventually run out of IPv4 addresses". Given that current projections point to 2010 as the date, what was so amusingly accurate about what Frank said? Note that given 10 years of quotes to trawl through, I expect that I could find "amusingly accurate" predictions on just about anything you care to mention. In any case, this thread is about combining forecasts which is an established way of dealing with multiple forecasts which give different answers to the same question. It's not about finding pinpoint accuracy, but about dealing with the variations between the different forecasts. One of the ways to deal with two forecasts (Geoff's and Tony's) which give different answers is to simply average the two answers. This isn't just an off the cuff suggestion to sweep the differences under the carpet and avoid the fact that one or both of them can't produce an accurate forecast. Instead, this is established forecasting best practice that is the result of numerous studies over the years. Averaging two forecasts may not give a very large increase in accuracy (about 12%), but it does narrow down the time period in which we will run out of the global free pool. Given the fact that combining forecasts is known to work best when using both METHODS and DATA that differ substantially http://www.forecastingprinciples.com/paperpdf/Combining.pdf should we actively try to solicit additional forecasts that can profitably be combined with the Tony/Geoff work? More on forecasting principles here for anyone who wants to follow up on this: http://www.forecastingprinciples.com/papers_page.html#Full_text_papers http://www.forecastingprinciples.com/researchers.html --Michael Dillon From Keith at jcc.com Thu Aug 30 09:03:46 2007 From: Keith at jcc.com (Keith W. Hare) Date: Thu, 30 Aug 2007 09:03:46 -0400 Subject: [ppml] Combining Forecasts Message-ID: How accurate to we need to be? The projection that we are likely to run out of available IP addresses sometime in 2010 should be enough motivation to push IPv6. Keith -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com Sent: Thursday, August 30, 2007 5:25 AM To: ppml at arin.net Subject: Re: [ppml] Combining Forecasts > except for how amusingly accurate frank solensky was over a > decade ago. Once upon a time, Frank said this: Frank Solensky: ...(my) estimates for maximum address space utilization have risen about 8% over the last 3 years. If one were to argue for extrapolating this over time as well, the resulting statement would be that "in the year 2019, the trend line will suggest that we will eventually run out of IPv4 addresses". Given that current projections point to 2010 as the date, what was so amusingly accurate about what Frank said? Note that given 10 years of quotes to trawl through, I expect that I could find "amusingly accurate" predictions on just about anything you care to mention. In any case, this thread is about combining forecasts which is an established way of dealing with multiple forecasts which give different answers to the same question. It's not about finding pinpoint accuracy, but about dealing with the variations between the different forecasts. One of the ways to deal with two forecasts (Geoff's and Tony's) which give different answers is to simply average the two answers. This isn't just an off the cuff suggestion to sweep the differences under the carpet and avoid the fact that one or both of them can't produce an accurate forecast. Instead, this is established forecasting best practice that is the result of numerous studies over the years. Averaging two forecasts may not give a very large increase in accuracy (about 12%), but it does narrow down the time period in which we will run out of the global free pool. Given the fact that combining forecasts is known to work best when using both METHODS and DATA that differ substantially http://www.forecastingprinciples.com/paperpdf/Combining.pdf should we actively try to solicit additional forecasts that can profitably be combined with the Tony/Geoff work? More on forecasting principles here for anyone who wants to follow up on this: http://www.forecastingprinciples.com/papers_page.html#Full_text_papers http://www.forecastingprinciples.com/researchers.html --Michael Dillon _______________________________________________ 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 jcurran at istaff.org Thu Aug 30 09:51:20 2007 From: jcurran at istaff.org (John Curran) Date: Thu, 30 Aug 2007 09:51:20 -0400 Subject: [ppml] Combining Forecasts In-Reply-To: References: Message-ID: At 9:03 AM -0400 8/30/07, Keith W. Hare wrote: >How accurate to we need to be? The projection that we are likely to run >out of available IP addresses sometime in 2010 should be enough >motivation to push IPv6. I doubt if a few months of uncertainty either way would matter for purposes of policy consideration, whereas a difference of a few years is definitely relevant since one wants to calibrate any policy changes against the need. For example, if we're looking at 2015 as an expected IPv4 depletion date, it's possible that IPv6 could have a sizable deployed base by then and be fairly mature (due to various initiatives and use in private network contexts) There could even be an agreed-upon set of functional transition mechanisms by such time. The overall IPv4 policy might simply be to maintain status quo till the forecasted date. If one considers a different scenario with a 2012 depletion date, we've got a different situation and need to explore how to increase conservation and encourage IPv6 deployment. Using an IPv4 depletion date of 2009 strongly suggests looking into aggressive conservation, proactive IPv6 deployment, and reclamation/reuse of legacy space, and assessing the usability of reserved space, and any other measure which maximizes IPv4 effective utilization without destroying the routing system. So, the accuracy of the projections matter, since businesses generally want the smallest possible change to the existing system which still allows us to keep it all running. /John From iljitsch at muada.com Thu Aug 30 10:47:20 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 30 Aug 2007 16:47:20 +0200 Subject: [ppml] Combining Forecasts In-Reply-To: References: Message-ID: <09791F14-850C-4763-9C9F-127EE016A5FD@muada.com> On 30-aug-2007, at 15:51, John Curran wrote: > I doubt if a few months of uncertainty either way would > matter for purposes of policy consideration, whereas a > difference of a few years is definitely relevant since one > wants to calibrate any policy changes against the need. No, one doesn't. The predictions are too inaccurate to base policy on. Just a few years ago, Geoff Huston told us IPv4 would last well into the 2020s. Now he says 2011. Both are reasonable projections based on the data available at the time, but I have little doubt that in another couple of years, things will look different once again. However, by that time we'll be that much closer to running out so maybe that one will stick. > For example, if we're looking at 2015 as an expected IPv4 > depletion date, it's possible that IPv6 could have a sizable > deployed base by then and be fairly mature Or people saw that things weren't that dire with IPv4 and shelved their IPv6 plans. > If one considers a different scenario with a 2012 depletion > date, we've got a different situation and need to explore how > to increase conservation and encourage IPv6 deployment. Increasing conservation is bad for people who need new IPv4 space. If it's bad enough, this may get them to move to IPv6, so then the net effect would be positive. But it's also possible that they stick with IPv4 and the bad effects translate in higher prices and fewer options for end-users, while the transition to IPv6 needs to happen a few years later anyway. > Using an IPv4 depletion date of 2009 strongly suggests looking > into aggressive conservation, Depletion by 2009 means 600 million addreses per year are used up. I think when we reach that, it's too late for conservation. > proactive IPv6 deployment, May want to do that regardless of the predictions. > and reclamation/reuse of legacy space, You need time for that, and at 600 million/year it buys you next to nothing. It's in the opposite situation, where we only burn 150 million addresses/year, where reclamation could be useful. From mksmith at adhost.com Thu Aug 30 11:54:16 2007 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 30 Aug 2007 08:54:16 -0700 Subject: [ppml] Combining Forecasts In-Reply-To: References: Message-ID: <17838240D9A5544AAA5FF95F8D52031602799B0B@ad-exh01.adhost.lan> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Keith W. Hare > Sent: Thursday, August 30, 2007 6:04 AM > To: ppml at arin.net > Subject: Re: [ppml] Combining Forecasts > > How accurate to we need to be? The projection that we are likely to > run > out of available IP addresses sometime in 2010 should be enough > motivation to push IPv6. > > Keith > If we are going to use the forecasts to incent people to move from IPv4 to IPv6 then we should be as accurate as possible. If we tell the community we won't run out until 2019 (or whenever) and we run out in 2010 there is likely to be an outcry from the community that we did not help them effectively prepare for the inevitable. If we tell them we're going to run out in 2010 and we don't run out until 2019, it looks like the boy who cried wolf, and then we'll have panic in 2019 because no one believes the forecasts. It seems to me that a historical look at the data from all of the RIR's (although we're most concerned with ARIN at this point), presented by the RIR's as a whole and in some official capacity, would go a long way in clarifying the historical assignment of addresses and the likely projections of a timeline for deployment and depletion of what's left. I would think we would need to look at the trends down to the minimum allocation level for each of the RIR's as a level of granularity for the data. Regards, Mike From drc at virtualized.org Thu Aug 30 12:31:32 2007 From: drc at virtualized.org (David Conrad) Date: Thu, 30 Aug 2007 09:31:32 -0700 Subject: [ppml] Combining Forecasts In-Reply-To: <17838240D9A5544AAA5FF95F8D52031602799B0B@ad-exh01.adhost.lan> References: <17838240D9A5544AAA5FF95F8D52031602799B0B@ad-exh01.adhost.lan> Message-ID: <604E921E-4E02-4399-896A-E45600E92F7C@virtualized.org> > If we are going to use the forecasts to incent people to move from > IPv4 > to IPv6 then we should be as accurate as possible. It is a bit challenging to model human behavior. How do you model a "run on the bank"? How do you model a transition of public space to NAT'd space as an effort towards conservation? Projections such as Geoff's and Tony's are useful, but I do not believe they are something you should bet your house on. Regards, -drc From michael.dillon at bt.com Thu Aug 30 12:44:37 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 30 Aug 2007 17:44:37 +0100 Subject: [ppml] Combining Forecasts In-Reply-To: <604E921E-4E02-4399-896A-E45600E92F7C@virtualized.org> References: <17838240D9A5544AAA5FF95F8D52031602799B0B@ad-exh01.adhost.lan> <604E921E-4E02-4399-896A-E45600E92F7C@virtualized.org> Message-ID: > How do you model a "run on the bank"? Hmmm... So we could run out of IPv4 addresses sooner than predicted. > How do you model a transition of public space to NAT'd space > as an effort towards conservation? Hmmm... Increased Capex and Opex could buy us time. But then we could be spending that money on IPv6 deployment instead. Which is the lower risk choice? > Projections such as Geoff's and Tony's are useful, but I do > not believe they are something you should bet your house on. Bet the house!? Oh, I understand. Companies who are not already budgeting FY 2008 Capex and Opex for IPv6 deployment, are betting the house that those wily Asians will shift to IPv6 by Christmas, thus freeing up the rest of the IPv4 space for plodding western companies for the next 20 years. Now all we have to do is to figure out whether Asia is really as far ahead in IPv6 as the pundits claim. What was that? There are no cheap commodity IPv6 home Internet routers/gateways on the market to date? Hmmm... --Michael Dillon From iljitsch at muada.com Thu Aug 30 12:42:48 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 30 Aug 2007 18:42:48 +0200 Subject: [ppml] Combining Forecasts In-Reply-To: <17838240D9A5544AAA5FF95F8D52031602799B0B@ad-exh01.adhost.lan> References: <17838240D9A5544AAA5FF95F8D52031602799B0B@ad-exh01.adhost.lan> Message-ID: <7929EEA4-8193-429C-A948-375183B66CA9@muada.com> On 30-aug-2007, at 17:54, Michael K. Smith - Adhost wrote: > If we tell them we're > going to run out in 2010 and we don't run out until 2019, it looks > like > the boy who cried wolf, and then we'll have panic in 2019 because > no one > believes the forecasts. We're already there: for a long time, we were supposed to run out in 2005, but obviously, that didn't happen. The US government was pushing GOSIP at one but that didn't go anywhere. From tme at multicasttech.com Thu Aug 30 13:05:13 2007 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 30 Aug 2007 13:05:13 -0400 Subject: [ppml] Combining Forecasts In-Reply-To: <604E921E-4E02-4399-896A-E45600E92F7C@virtualized.org> References: <17838240D9A5544AAA5FF95F8D52031602799B0B@ad-exh01.adhost.lan> <604E921E-4E02-4399-896A-E45600E92F7C@virtualized.org> Message-ID: On Aug 30, 2007, at 12:31 PM, David Conrad wrote: >> If we are going to use the forecasts to incent people to move from >> IPv4 >> to IPv6 then we should be as accurate as possible. > > It is a bit challenging to model human behavior. > > How do you model a "run on the bank"? Modeling it is possible; predicting it is almost impossible until it starts. What you could maybe do is predict the probability of it happening. It would help to have data to compare against, but I cannot really think of any suitable data or a previous case of a run on a registrar. There is of course a huge literature on financial panics - they seem to be currently modeled by Markov switching models, see http://www.fdic.gov/bank/analytical/working/wp2006_01/wp2006_01.pdf http://www.cambridge.org/resources/0521790182/1554_117089.ppt http://welch.econ.brown.edu/cascades/ How applicable this is is of course unclear. I must say that with the resources available I am not too sanguine that we would get useful predictions even of probabilities. Regards Marshall > > How do you model a transition of public space to NAT'd space as an > effort towards conservation? > > Projections such as Geoff's and Tony's are useful, but I do not > believe they are something you should bet your house on. > > Regards, > -drc > > _______________________________________________ > 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 mksmith at adhost.com Thu Aug 30 13:45:30 2007 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 30 Aug 2007 10:45:30 -0700 Subject: [ppml] Combining Forecasts In-Reply-To: <604E921E-4E02-4399-896A-E45600E92F7C@virtualized.org> References: <17838240D9A5544AAA5FF95F8D52031602799B0B@ad-exh01.adhost.lan> <604E921E-4E02-4399-896A-E45600E92F7C@virtualized.org> Message-ID: <17838240D9A5544AAA5FF95F8D52031602799B4B@ad-exh01.adhost.lan> > -----Original Message----- > From: David Conrad [mailto:drc at virtualized.org] > Sent: Thursday, August 30, 2007 9:32 AM > To: Michael K. Smith - Adhost > Cc: Public Policy Mailing List > Subject: Re: [ppml] Combining Forecasts > > > If we are going to use the forecasts to incent people to move from > > IPv4 > > to IPv6 then we should be as accurate as possible. > > It is a bit challenging to model human behavior. > > How do you model a "run on the bank"? > > How do you model a transition of public space to NAT'd space as an > effort towards conservation? > > Projections such as Geoff's and Tony's are useful, but I do not > believe they are something you should bet your house on. > > Regards, > -drc I think it's a matter of helping the community make informed decisions based upon accurate forecasts. Although we all have our specific desires about motivating people to move from IPv4 to IPv6 (or not, for some), ARIN is in a position to provide the data necessary to make those forecasts. I wouldn't bet the house on predictions and forecasts, but I would certainly use them to support my position on migration within my organization. It's one more tool in the tool belt, as it were. Regards, Mike From Lee.Howard at stanleyassociates.com Thu Aug 30 14:58:17 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 30 Aug 2007 14:58:17 -0400 Subject: [ppml] Combining Forecasts In-Reply-To: <17838240D9A5544AAA5FF95F8D52031602799B4B@ad-exh01.adhost.lan> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB406D926E4@CL-S-EX-1.stanleyassociates.com> > I think it's a matter of helping the community make informed > decisions based upon accurate forecasts. Although we all > have our specific desires about motivating people to move > from IPv4 to IPv6 (or not, for some), ARIN is in a position > to provide the data necessary to make those forecasts. I > wouldn't bet the house on predictions and forecasts, but I > would certainly use them to support my position on migration > within my organization. It's one more tool in the tool belt, > as it were. I guess that Geoff Huston's predictions are his own work, since they're on his potaroo site, not APNIC's site, but as an employee of APNIC, he is pretty well informed. Tony Li is not affiliated with any RIR, but is also well-informed. So, could you be specific about what data are missing that ARIN might provide? Lee From mksmith at adhost.com Thu Aug 30 15:35:32 2007 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 30 Aug 2007 12:35:32 -0700 Subject: [ppml] Combining Forecasts In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB406D926E4@CL-S-EX-1.stanleyassociates.com> References: <17838240D9A5544AAA5FF95F8D52031602799B4B@ad-exh01.adhost.lan> <369EB04A0951824ABE7D8BAC67AF9BB406D926E4@CL-S-EX-1.stanleyassociates.com> Message-ID: <17838240D9A5544AAA5FF95F8D52031602799B83@ad-exh01.adhost.lan> > -----Original Message----- > From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] > Sent: Thursday, August 30, 2007 11:58 AM > To: Michael K. Smith - Adhost; David Conrad > Cc: Public Policy Mailing List > Subject: RE: [ppml] Combining Forecasts > > > I think it's a matter of helping the community make informed > > decisions based upon accurate forecasts. Although we all > > have our specific desires about motivating people to move > > from IPv4 to IPv6 (or not, for some), ARIN is in a position > > to provide the data necessary to make those forecasts. I > > wouldn't bet the house on predictions and forecasts, but I > > would certainly use them to support my position on migration > > within my organization. It's one more tool in the tool belt, > > as it were. > > I guess that Geoff Huston's predictions are his own work, since > they're on his potaroo site, not APNIC's site, but as an > employee of APNIC, he is pretty well informed. Tony Li is not > affiliated with any RIR, but is also well-informed. > > So, could you be specific about what data are missing that > ARIN might provide? > > Lee If all of the RIR's officially published a historical allocation table showing the allocations and de-allocations down to the minimum allocation size for that RIR plus a date stamp that would be sufficient to do a complete analysis and projection. Perhaps this information already exists at each of the RIR's individually? Regards, Mike From iljitsch at muada.com Thu Aug 30 15:47:30 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 30 Aug 2007 21:47:30 +0200 Subject: [ppml] Combining Forecasts In-Reply-To: <17838240D9A5544AAA5FF95F8D52031602799B83@ad-exh01.adhost.lan> References: <17838240D9A5544AAA5FF95F8D52031602799B4B@ad-exh01.adhost.lan> <369EB04A0951824ABE7D8BAC67AF9BB406D926E4@CL-S-EX-1.stanleyassociates.com> <17838240D9A5544AAA5FF95F8D52031602799B83@ad-exh01.adhost.lan> Message-ID: <2D4BF39F-2057-4989-AF02-4AFE7B872EBF@muada.com> On 30-aug-2007, at 21:35, Michael K. Smith - Adhost wrote: > If all of the RIR's officially published a historical allocation table > showing the allocations and de-allocations down to the minimum > allocation size for that RIR plus a date stamp that would be > sufficient > to do a complete analysis and projection. Perhaps this information > already exists at each of the RIR's individually? Yes, they publish it daily on their FTP sites. Let me know if you want the php script to dump this info in a mysql database. From mksmith at adhost.com Thu Aug 30 16:03:03 2007 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 30 Aug 2007 13:03:03 -0700 Subject: [ppml] Combining Forecasts In-Reply-To: <2D4BF39F-2057-4989-AF02-4AFE7B872EBF@muada.com> References: <17838240D9A5544AAA5FF95F8D52031602799B4B@ad-exh01.adhost.lan> <369EB04A0951824ABE7D8BAC67AF9BB406D926E4@CL-S-EX-1.stanleyassociates.com> <17838240D9A5544AAA5FF95F8D52031602799B83@ad-exh01.adhost.lan> <2D4BF39F-2057-4989-AF02-4AFE7B872EBF@muada.com> Message-ID: <17838240D9A5544AAA5FF95F8D52031602799B8C@ad-exh01.adhost.lan> > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch at muada.com] > Sent: Thursday, August 30, 2007 12:48 PM > To: Michael K. Smith - Adhost > Cc: Howard, W. Lee; David Conrad; Public Policy Mailing List > Subject: Re: [ppml] Combining Forecasts > > On 30-aug-2007, at 21:35, Michael K. Smith - Adhost wrote: > > > If all of the RIR's officially published a historical allocation > table > > showing the allocations and de-allocations down to the minimum > > allocation size for that RIR plus a date stamp that would be > > sufficient > > to do a complete analysis and projection. Perhaps this information > > already exists at each of the RIR's individually? > > Yes, they publish it daily on their FTP sites. Let me know if you > want the php script to dump this info in a mysql database. Is this the same script that feeds http://www.bgpexpert.com/addrspace.php or something similar? If so I would greatly appreciate the tool so that I can munge the data at will. I should add that having the data is Step 1. What is the likelihood of the RIR's accepting a statistical analysis of that data with an attached projection and then officially announcing that timeline? It seems like this second step is required for someone to use it as a foundation for making corporate policy regarding IP (4/6) deployments. Regards, Mike From dean at av8.com Thu Aug 30 19:24:51 2007 From: dean at av8.com (Dean Anderson) Date: Thu, 30 Aug 2007 19:24:51 -0400 (EDT) Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: <1C57BC25-FF63-4482-8AAE-A6D837085844@muada.com> Message-ID: On Wed, 29 Aug 2007, Iljitsch van Beijnum wrote: > On 28-aug-2007, at 23:53, Dean Anderson wrote: > > >> Geoff Huston predicts june 2010 for the IANA pool and march 2011 for > >> the RIR reserves. > > > This is a recent change in Huston's predictions. A few months > > difference > > from his previous prediction in July. Google cache of this page from > > Aug 4, shows April 16th, 2010. Tony Hain now says April 2010. > > And I say during the London summer olympics. Ok. Except that you are just pulling your number out of your hat. The other two use some math to compute the rate and compute the remaining address space. When they agree or even nearly agree, that's probably a pretty good number. Certainly, its better than your approximate 'back of napkin' calculation. Unless you can come up with some flaw in their methods or basis of calculation, you really don't have any credible basis to dispute their numbers; So I don't think your number is very credible. > > This seems to be a lot of variation from July, when both said March > > 2010. This deserves further investigation. > > It's very simple: the data is extremely inconsistent. You need to do > a lot of smoothing to make the curves fit any particular model. So a > small change in the data or the interpretation can make a big > difference. The data doesn't seem to be very inconsistent. My read of Huston's graphs is that the rate of consumtion is remarkably steady, actually. More so than I would have thought. But, I do agree further investigation is called for. > > I suspect that in Huston's case, if he doesn't update the data from > > ARIN, etc, > > I believe this happens daily, not sure though. I'll report as soon I do some testing. > >>> Fact 3: Disruptions of unknown duration are more harmful to business > >>> planning than disruptions of known duration. > > >> Even more harmful is thinking a disruption is temporary when it is in > >> fact permanent. > > > And how is this disruption permanent? > > The IPv4 address factory only built 3706.65 million usable ones, when > those are gone, they're gone. When you pump the lake dry, you'll have > rain from time to time but that doesn't mean you will be going > swimming any time soon. So: 1) we shouldn't pump the lake dry. But 2) eventually, people will return IP addresses. So the disruption isn't permanent. When couple /8's come back in, it will be no problem allocating /12's, and lots and lots of /22s. As you said, the DoD alone has 10 or so /8's. > >>> Fact 5: Rationing any kind of limited resource inhibits hoarding > > >> No, it just makes it start sooner > > > You are wrong: The start time for hoarding is the realization that a > > resource is running out. > > Nothing sends that message better than a request turned down because > there are no addresses available, regardless of whether this is > artificial or real. This is true. Of course, the reports such as Hain's and Huston's also send out quite clear messages. And those reports predict the future so you don't have to wait until a request is turned down. Rationing or no rationing, people get the message that the resource is running out and start hoarding. That's why you are wrong with the claim that rationing causes hoarding. > >> and the iterations as new blocks come available and assignments > >> resume > >> temporarily allow the hoarders to learn and become more effective. > > > The people in charge of rationing also learn, and also become more > > effective. > > They'll never be effective as long as address allocation is done > based on information supplied by the organization that requests them, > it's too simple to lie. I agree that its all too easy to lie on the first allocation. Of course, the next time they apply, they need to demonstrate usage of the previous allocation. That lie is much more difficult to maintain, and evidence of fraud is easier to find. So the existing policy of partial allocations works pretty well for this case, and will continue to work well. > >>> Fact 6: IPv4 usage will not end because of AIP exhaustion. > > >> Growth will end, and many economic models require growth. > > > Nonsense. Dead applications like dialup are replaced by new > > applications. Growth of new business eventually resumes. It is merely > > disrupted, unnecessarilly. > > With dial-up you only need one address per modem, which is something > like one address per 4 - 10 customers. When dial-up is replaced by > broadband, you need 1 address per customer. Actually; Verizon seems to have worked out a way to use DHCP and PPPoE so that customers who aren't actively sending packets, lose their addresses. This probably makes DSL address usage more like dialup again. > I don't understand how anyone can think IPv4 will be a viable long- > term technology AFTER the IPv4 address space has been depleted. Plainly, you misunderstand the effects of depletion, and the economics of utility. I've been trying to explain that to you. > I agree that IPv4 won't go away over night because it will continue to > function for those who already have addresses, but building networks > based on the assumption that at some point, someone will return some > addresses and you may be able to get some of those is very bad > engineering. Its not an _assumption_ that people will return space. You agree that when people convert to IPv6, and no longer need IPv4 space that this space will be returned. There are other users who will also return space. Your problem on that count is merely a lack of self-consistency. Space will eventually be returned. All that is uncertain is the when this will happen. There is no bad engineering in keeping existing and useful networks running smoothly > > Wrong again. Eventually, when the DoD converts to IPv6, some /8's will > > come back. > > So? We burn /8s up in a month, currently. If the US government > returns the ~ 10 /8s they have that's only one year worth of address > space. Only one at the current rate. That would be the same rate that rationing will slow down. One year is not too bad though, considering it comes from just one source. But rationing would make that last longer, too. > > When MERIT dismantles its dialup network, at least a /8 will come > > back. > > Right, because they operate 16 million dial-up modems right now. Configure, perhaps. Operate? Doubtful. But at some point, those modem pools will be dismantled, and the address space will either be returned, or put to some other use---So either ARIN gets the space back or ARIN is relieved of demand. > > It is a stop/wait/resume thing, if we exhaust the available pool: > > Allocation will _stop_, Then one will have to _wait_ until enough IP > > space comes back to fullfil their request, at which point, allocation > > will _resume_. > > After we run out, there is simply NO WAY that enough address space > comes back to continue current IPv4 practices. It's nice if 25% of > the requests can still be fullfilled from reclaimed address space, > but it still means that 75% of the requests will be denied so the > people doing those requests will have to find some other way to > address their needs. Wrong. You don't seem to be listening, so it seems pointless to keep repeating why you are wrong. > >> A smooth transition from IPv4 to IPv6 is in everyone's interest. IPv4 > >> is a sinking ship. You don't have to jump in a life boat right this > >> minute, but planning new trips is not a smart thing to do. > > > IPv4 is not a sinking ship at all. People said Fax would be totally > > obsolete in the 1990s, replaced by email. Now we use both. > > Hm, I was just thinking the other day whether I needed to keep my fax > number the other day since I hadn't received any faxes in almost a > year. But this is not a good analogy. Email and fax provide a very > different experience. For a user, IPv4 or IPv6 are completely > identical. I can't tell whether I'm using IPv4 or IPv6, let alone > users who can't even spell "RFC". But for the same reason that we > don't use iron gall ink any more, IPv4 will go the way of the > dinosaurs at some point. So will IPv6, or pretty much any technology > that we use today. The reason why old technology sticks around longer > than expected is usually because it has properties that are > desireable in certain situations, but is effect deminishes as the > technology is further removed from the user experience. It sticks arournd because it is useful. Utility drives the market. > > There will continue to be IPv4 applications, because IPv6 is too > > heavy for some applications. > > No. That's not a consideration at all. Not for you, perhaps. Buried head in sand, I see. > > Just like fax, and pager networks, IPv4 will still have utility. You > > don't seem to understand the concept of utility. > > The utility of IPv4 is that you can reach everything connected to the > internet. As soon as you can also reach everything connected to the > internet over IPv6, IPv4 has no use anymore. Wrong analysis. Again. The utility of IPv4 is not that you can reach everyone on the planet. Maybe you daydream about having the 'world by the tail'. I don't. Others don't. I think part of your problem understanding this is that you can't see the world from anyone else's perspective. BTW, You can already reach everything connected to the internet. What you can't reach, isn't connected. Obviously, if you are connected, and they are connected, then by transitivity you can reach everything connected. Otherwise, one of you isn't connected, and the network is partitioned. > (Of course it's not going to happen like that: there will be a period > when you can only reach everything connected to the internet if you > have BOTH IPv4 and IPv6.) I think you have a problem with the definition of "the internet". There is the IPv4 network (an internet), and the IPv6 network (also an internet) > >> I want IPv4 to remain useful as long as it can, which means NOT > >> making it harder to get IPv4 address space, which is already > >> relatively hard today. > > > Interesting logic. However, the harms of exhaustion mean that we > > need to prudently restrain the consumption of IPv4 space until more > > space is returned to the free pool. > > This way, we don't go from a model where there is a reasonable amount > of IPv4 address space available to a model where there is an abundance > of IPv6 space, but rather to a model where we stick to IPv4, but are > starved for addresses. That would be very bad. I agree, starvation is bad. Rationing prevents starvation by making it more predictable when your next meal will be be. To continue the analogy, that allows your to plan how many calories you can burn, so that you don't die. > > I suppose if you push someone over a cliff, you'd say you were just > > helping them get a better view, too. > > What do you say when you push someone over a cliff? I don't push people over cliffs. I just write about them on a web page, and let others know what they did. > Personally, I've never had occasion to come up with a pithy cliff > pushing line. You already did. > > The ill-intent of getting 'IPv4 over and done with' is already > > apparent. Your 'good intention' doesn't hold water. > > My intent includes keeping IPv4 as useful as possible for as long as > possible. But IPv4 has an expiration date, people need to realize > that. You have given no reasons why there would be an expiration date. You've only tried to create the false impression that running out of IPv4 addresses is the end of IPv4. And you've tried to prevent prudent resource management to prevent that exhaustion. > > Yes, EDNSO is so servers can send larger packets. However, many > > resolvers do not support EDNSO responses. > > Come on, this is the 21st century. EDNS0 is 8 years old, apply the > same policy as you do to your tech books. > > > Further, EDNSO packets may need to be fragmented, requiring state on > > the server for Path MTU discovery. > > With IPv6 this is possible in theory but the minimum maximum packet > size is 1280, which holds a very significant DNS response. > The DNS/ UDP protocol doesn't support reducing its packet size so you > can't do path MTU discovery for IPv4 , you need to let fragmentation > happen. This has been an IPv4 feature for 26 years so I don't see the > problem with that. Absolutely wrong nonsense. RFC 1191 (Path MTU Discovery) applies to _IP_ datagrams for IPv4. That includes UDP, TCP and other protocols inside IP datagrams. DNS has nothing to do with MTU discovery. > > So EDNSO is unsuitable for anycasted servers. > > No it isn't and that doesn't follow from your earlier claims. I won't go into that argument here. But anycast isn't suitable for DNS, and that _does_ follow from my earlier claims. People resorted to hardball to suppress my claims and to promote false claims of stability. Since then, I have collected experimental evidence of stateful anycast instability that shows my analysis was correct. And I've also found further routing mechanisms where anycast fails for stateful protocols. But that's another story, and you don't appear very good in that story. I won't say any more about Anycast on this thread, except to the extent that the hardball on stateful Anycast was played by the same people, for essentially the same reasons: to keep the existing root and tld server operators for IPv6 so that they can keep profiting from selling those services. > >> people who use stupid firewalls get what they deserve. I don' see a > >> problem. (But then again, I'm not a root server operator.) > > > Its not the firewalls that prevent universal EDNSO. > > http://searchwinit.techtarget.com/tip/0,289483,sid1_gci991813,00.html Nice try. Just become someone had a problem with their firewall doesn't mean that's the only problem with universal EDNSO adoption. The fact is that resolvers doen't all support EDNSO. Even 8 years later. But, if firewalls _also_ cause a problem for EDNSO, that just weakens your case. It doesn't strengthen it. Another case of 'shooting your own foot'. > > That was a red-herring: An IPv6 application doesn't need to know if > > a system is reachable over IPv4. An IPv4 application doesn't need to > > know if a system is reachable via IPv6. > > Hm, let's see, how many applications are out there that work over > IPv6 and not IPv4? Let me do a quick count... That would be two: > ping6 and traceroute6. Dhcp6 comes to mind. I think there are more that use IPv6-specific features. > Applications that support IPv6 also support IPv4. The protocols you quote have no changes for IPv6 because they aren't specific to the underlying protocol that carries the payload. These protocols could work over Appletalk, DecNet, or Novell etc, too. Some do. > > There are no mixed applications, > > Really? > > # ftp ftp.arin.net > Trying 2001:500:4:1::21... > > # ftp -4 ftp.arin.net > Trying 192.149.252.20... This is an entirely contrived example. The 'combined' FTP program needs to link to both stacks and include a lot of extra and unnecessary code. This is usually cited as a disadvantage, and poor, monolithic design. This is not an example of a mixed application, but an example of _contrived_efforts_to_mix_ IPv4 and IPv6, after the fact. It would plainly be equal or better to have two programs: one ftp program for IPv4 and another ftp6 program for IPv6. Efforts to go out of your way to mix things unnecessarily do not count as mixed applications. Its just bad design and modularity to make a monolithic every-stack-combined program. It doesn't justify mixing DNS. It was just contrived to _try_ to justify mixing DNS. The FTP protocol isn't mixed. FTP requires only an error-free stream (such as TCP). Ethertalk, DecNet, etc also provided error-free streams. Many computers implemented those stacks. No one previously found it useful to have a single FTP program for all stacks. FTP isn't specific to IPv4 or IPv6; FTP is not a mixed protocol. All you've done is just mixed some code for no good reason. We do know the reason; it just isn't a good reason. Try again... > > the RFC's and protocol details keep changing. That's why different > > implementations of IPv6 stacks don't interoperate. > > They interoperate just fine. I've used Cisco, Juniper, MacOS X, Linux, > Windows XP and FreeBSD and they all work together just fine except for ++++++++++ > IPv6 over PPP and there is some path MTU discovery blackholing if you +++++++++++++++ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > make the XP machine an IPv6 router. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Oh, yes. Two more things that sound "just fine" (not really). Just like the other example _you_ gave of not being able to do multivendor dialup. What's becoming clear through this discussion is __exactly__ why no one is rushing to convert to IPv6. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From gih at apnic.net Thu Aug 30 20:16:23 2007 From: gih at apnic.net (Geoff Huston) Date: Fri, 31 Aug 2007 10:16:23 +1000 Subject: [ppml] Combining Forecasts In-Reply-To: References: Message-ID: <46D75DD7.40308@apnic.net> michael.dillon at bt.com wrote: >> This is a recent change in Huston's predictions. A few months >> difference from his previous prediction in July. Google >> cache of this page from Aug 4, shows April 16th, 2010. Tony >> Hain now says April 2010. >> >> This seems to be a lot of variation from July, when both said >> March 2010. This deserves further investigation. I suspect >> that in Huston's case, if he doesn't update the data from >> ARIN, etc, his program will see this as no new allocations >> and compute a new (but wrong) exhaustion date. I'll see if >> this is the case. The model used for http://ipv4.potaroo.net is based on daily data gathered from the 5 RIRs, the IANA IPv4 registry and the Ipv4 BGP routing table. The prediction changes over time as the predictive model is a sliding window model that uses data collected over the last 1095 days as the foundation of the prediction. In recent months the pace of IPv4 consumption has slowed down a little so the predictive model stretches out the predicted dates a little further - perhaps related to the summer break in the northern hemisphere? regards, Geoff From randy at psg.com Thu Aug 30 22:30:35 2007 From: randy at psg.com (Randy Bush) Date: Fri, 31 Aug 2007 11:30:35 +0900 Subject: [ppml] Combining Forecasts In-Reply-To: References: Message-ID: <46D77D4B.4040105@psg.com> >> except for how amusingly accurate frank solensky was over a >> decade ago. > > Once upon a time, Frank said this: > > Frank Solensky: ...(my) estimates for > maximum address space utilization > have risen about 8% over the last 3 > years. If one were to argue for > extrapolating this over time as well, > the resulting statement would be that > "in the year 2019, the trend line will > suggest that we will eventually run > out of IPv4 addresses". > > > Given that current projections point to 2010 as the date, what was so > amusingly accurate about what Frank said? because that excerpt was not all that he said randy From martin.hannigan at batelnet.bs Thu Aug 30 23:47:43 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Thu, 30 Aug 2007 23:47:43 -0400 Subject: [ppml] Combining Forecasts Message-ID: <46d78f5f.390.2455.26524@batelnet.bs> ----- Original Message ----- From: "Michael K. Smith - Adhost" To: "David Conrad" Cc: Public Policy Mailing List Subject: Re: [ppml] Combining Forecasts Date: Thu, 30 Aug 2007 10:45:30 -0700 > > -----Original Message----- > > From: David Conrad [mailto:drc at virtualized.org] > > Sent: Thursday, August 30, 2007 9:32 AM > > To: Michael K. Smith - Adhost > > Cc: Public Policy Mailing List > > Subject: Re: [ppml] Combining Forecasts > > > > > If we are going to use the forecasts to incent people > > > to move from IPv4 > > > to IPv6 then we should be as accurate as possible. > > > > It is a bit challenging to model human behavior. > > > > How do you model a "run on the bank"? > > > > How do you model a transition of public space to NAT'd > > space as an effort towards conservation? > > > > Projections such as Geoff's and Tony's are useful, but I > > do not believe they are something you should bet your > > house on. > > Regards, > > -drc > > I think it's a matter of helping the community make > informed decisions based upon accurate forecasts. I'm more concerned that policy changes will be implemented that shut out small to medium size networks long before exhaustion. -M< From iljitsch at muada.com Fri Aug 31 08:18:24 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 31 Aug 2007 14:18:24 +0200 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: References: Message-ID: <85975A4A-0077-4B71-B303-FD9FE27615F6@muada.com> On 31-aug-2007, at 1:24, Dean Anderson wrote: >>> Aug 4, shows April 16th, 2010. Tony Hain now says April 2010. >> And I say during the London summer olympics. > Ok. Except that you are just pulling your number out of your hat. The > other two use some math to compute the rate and compute the remaining > address space. It's not that simple. Tony and Geoff take their assumptions (why use the last 1095 days and 1250 or 943?) and put them into formulas which then produce results with many digits after the decimal point. I take several possibilities, see where they lead and then try to come up with something that seems reasonable based on my interpretation of the past. Tony and Geoff's approach would probably be better at projecting a trend into the future, but it's my contention that there is basically no trend so there's not much to project. The only thing that looks pretty solid is that there's almost always growth in the number of addresses used up per year. Anything else only persists for a few years and then changes. > When they agree or even nearly agree, that's probably a > pretty good number. Certainly, its better than your approximate > 'back of > napkin' calculation. Unless you can come up with some flaw in their > methods or basis of calculation, you really don't have any credible > basis to dispute their numbers; So I don't think your number is very > credible. I don't think my number is very credible either, but I'm far from convinced that the others are better. >> It's very simple: the data is extremely inconsistent. You need to do >> a lot of smoothing to make the curves fit any particular model. So a >> small change in the data or the interpretation can make a big >> difference. > The data doesn't seem to be very inconsistent. My read of Huston's > graphs is that the rate of consumtion is remarkably steady, actually. > More so than I would have thought. Really? This is the past 10 years (note that the ARIN figures are problematic because they often backdate new allocations which I can't compensate for automatically): 44.86 M 1997 60.00 M 1998 42.22 M 1999 77.71 M 2000 84.51 M 2001 68.49 M 2002 86.85 M 2003 127.50 M 2004 174.97 M 2005 172.81 M 2006 137.02 M 2007 Now have a look at the ARIN numbers: 26.30 M 1997 45.35 M 1998 18.96 M 1999 30.53 M 2000 28.03 M 2001 20.80 M 2002 21.38 M 2003 32.74 M 2004 51.00 M 2005 50.43 M 2006 20.28 M 2007 The theme seems to be either stick close to last year or jump by more than 50%. Not exactly smooth. >> The IPv4 address factory only built 3706.65 million usable ones, when >> those are gone, they're gone. When you pump the lake dry, you'll have >> rain from time to time but that doesn't mean you will be going >> swimming any time soon. > So: 1) we shouldn't pump the lake dry. So people should go thirsty even though there is still perfectly good water left in the lake? > But 2) eventually, people will return IP addresses. This year, for the first time in many years, a legacy /8 was returned, even though only half of them show up in the routing table. So apparently, people aren't in a hurry to return what they no longer need. Also, as long as there are people who don't want to move to IPv6 it's useful to keep your own IPv4 address to communicate with them. > So the disruption isn't permanent. Your logic is "after the depletion, SOMEONE will be able to get IPv4 space" (which is true) and then "if SOMEONE can get IPv4 space EVERYONE can get IPv4 space" (which is untrue). If you're an old tennis pro who had to stop because of injuries, you can heal and then play tennis again. That doesn't mean you can resume your career and win Wimbledon. >> With dial-up you only need one address per modem, which is something >> like one address per 4 - 10 customers. When dial-up is replaced by >> broadband, you need 1 address per customer. > Actually; Verizon seems to have worked out a way to use DHCP and PPPoE > so that customers who aren't actively sending packets, lose their > addresses. This probably makes DSL address usage more like dialup > again. I doubt this results in a significant reduction in address use today: you wouldn't want to use 1024 addresses for 1200 customers and then have support calls when the 1025th can't get online. This could change in the future to some degree, but I'm still 99% sure that more broadband and less dial-up means more addresses, not fewer. >> So? We burn /8s up in a month, currently. If the US government >> returns the ~ 10 /8s they have that's only one year worth of address >> space. > Only one at the current rate. That would be the same rate that > rationing will slow down. One year is not too bad though, > considering it > comes from just one source. It's about a quarter of the total /8 legacy space and a little over a tenth of the total legacy space if you also include the class B nets but those will likely be even harder to reclaim because you need 256 times as many to get the same amount of space. > But rationing would make that last longer, too. Whether you starve because there is no food or because it's rationed doesn't really make a difference... If you have significant long-term plans for IPv4, you may want to look into putting the class E space (240.0.0.0 - 255.255.255.254) into use. My conclusion was that by now, we don't have enough time to roll out software updates to stuff like Windows that won't accept those addresses to make them usable in time, but if you're thinking on timescales past the lifetime of the current Windows version, this would be viable. > But at some point, those modem > pools will be dismantled, and the address space will either be > returned, > or put to some other use---So either ARIN gets the space back or > ARIN is > relieved of demand. I think this has already been happening as modem pools have shrunk and broadband deployment grown the past years. I don't think there are heaps of IPv4 addresses waiting to be returned because modems are taken out of commission. >>> There will continue to be IPv4 applications, because IPv6 is too >>> heavy for some applications. >> No. That's not a consideration at all. > Not for you, perhaps. Buried head in sand, I see. A 10 year old computer can easily handle IPv6. I'm sure there are embedded systems that are sized such that they can just about run IPv4 but the extra code for IPv6 is the staw that breaks the camel's back, but that just means they'll have to use a 7 cent chip instead of a 5 cent one. Boo hoo. >>> Just like fax, and pager networks, IPv4 will still have utility. You >>> don't seem to understand the concept of utility. >> The utility of IPv4 is that you can reach everything connected to the >> internet. As soon as you can also reach everything connected to the >> internet over IPv6, IPv4 has no use anymore. > Wrong analysis. Again. I think this is the part where we have completely opposite views. You seem to think that there are some jobs that IPv4 can inherently do better than IPv6. The way I see it, and I'm positive this position is shared by pretty much the entire IETF, is that IPv4 and IPv6 are both mechanisms to move data from one system to another over the network, and apart from address-related issues that must be addressed in the relevant protocols/applications, IPv4 and IPv6 are functionally interchangeable. >> (Of course it's not going to happen like that: there will be a period >> when you can only reach everything connected to the internet if you >> have BOTH IPv4 and IPv6.) > I think you have a problem with the definition of "the internet". > There > is the IPv4 network (an internet), and the IPv6 network (also an > internet) So you are saying that www.arin.net (visited over IPv4) is something other than www.arin.net (visited over IPv6)? >> The DNS/ UDP protocol doesn't support reducing its packet size so you >> can't do path MTU discovery for IPv4 , you need to let fragmentation >> happen. This has been an IPv4 feature for 26 years so I don't see >> the >> problem with that. > Absolutely wrong nonsense. RFC 1191 (Path MTU Discovery) applies to > _IP_ > datagrams for IPv4. That includes UDP, TCP and other protocols > inside IP > datagrams. DNS has nothing to do with MTU discovery. When you use TCP and a "packet too big" ICMP message comes back, TCP reduces its packet size. So what do you suggest happens with a "packet too big" message comes back for an UDP packet so UDP needs to send packets that are no larger than 1476 bytes while the application wants to send a 2000-byte packet? > But anycast isn't suitable for DNS, > and that _does_ follow from my earlier claims. People resorted to > hardball to suppress my claims and to promote false claims of > stability. My opinion of anycast for the DNS isn't entirely favorable: over- using this mechanism means that too many eggs end up in too few baskets. It would be good to anycast only half or so of the root servers. But you can't argue with operational experience: so far, it has worked pretty well. >> Hm, let's see, how many applications are out there that work over >> IPv6 and not IPv4? Let me do a quick count... That would be two: >> ping6 and traceroute6. > Dhcp6 comes to mind. I think there are more that use IPv6-specific > features. I wouldn't exactly call that an "application", but yes, DHCPv6 only works over IPv6, DHCP only over IPv4. >> Applications that support IPv6 also support IPv4. > The protocols you quote have no changes for IPv6 because they aren't > specific to the underlying protocol that carries the payload. So? That's true for most protocols/applications. > The 'combined' FTP program needs > to link to both stacks and include a lot of extra and unnecessary > code. > This is usually cited as a disadvantage, and poor, monolithic design. > This is not an example of a mixed application, but an example of > _contrived_efforts_to_mix_ IPv4 and IPv6, after the fact. A few more examples: Apace 2, sendmail, UW IMAPd, Internet Explorer, Firefox, Safari, Thunderbird, Mail.app, Windows Media Player, iTunes, QuickTime Player. On most systems (most notable exception: Windows XP) you can write programs that only use the IPv6 API but can talk both to the IPv4 and IPv6 worlds. I haven't counted the bytes, but I'm pretty sure the code required to link both protocols is only very slightly larger than all the stuff you need for just one of them. All the work happens in the kernel anyway. > It would plainly be equal or better to have two programs: one ftp > program for IPv4 and another ftp6 program for IPv6. So how do users know which they should use? I normally read my mail over IPv6. But when I'm on the road, I usually don't have IPv6 connectivity so I find it rather helpful that my mail program automatically switches to IPv4 then. From cliffb at cjbsys.bdb.com Fri Aug 31 08:33:34 2007 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Fri, 31 Aug 2007 08:33:34 -0400 (EDT) Subject: [ppml] Policy Proposal: Definition of known ISP and changes to In-Reply-To: <52117.1187980881@sa.vix.com> from "Paul Vixie" at Aug 24, 2007 06:41:21 PM Message-ID: <200708311233.l7VCXYBj005107@cjbsys.bdb.com> > > > > because folk with too much time on their hands spend some of it telling > > > others how run their business? > > > > Clearly the solution to widespread IPv6 deployment is to give > > everyone who has a /29 of IPv4 space somewhere a /32 of IPv6 space. > > don't laugh. recreating the swamp may be our only way forward. In May, shortly after joining the is mailing list, I made the following suggestion "If there is really a desire to get v6 started, ARIN should give every entity that has existing IPv4 addresses equivalent IPv6 addresses under whatever provisions they are under now, including no fees for grandfathered PI addresses like mine." I took a few shots for that but it sound like you're offering the same thought. After reading the list over the last few months, I'd change my proposal to just offer it to those who want it rather than automatically give v6 to all and I guess I'd accept an RSA to officially recognize the legacy status of the v4 addresses and the new v6 assignment. Everybody keeps talking about the huge address space for v6 but all that space is wasted if nobody uses it. Cliff > _______________________________________________ > 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. > -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From iljitsch at muada.com Fri Aug 31 09:02:11 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 31 Aug 2007 15:02:11 +0200 Subject: [ppml] RIR allocation data parsing scripts, was: Re: Combining Forecasts In-Reply-To: <17838240D9A5544AAA5FF95F8D52031602799B8C@ad-exh01.adhost.lan> References: <17838240D9A5544AAA5FF95F8D52031602799B4B@ad-exh01.adhost.lan> <369EB04A0951824ABE7D8BAC67AF9BB406D926E4@CL-S-EX-1.stanleyassociates.com> <17838240D9A5544AAA5FF95F8D52031602799B83@ad-exh01.adhost.lan> <2D4BF39F-2057-4989-AF02-4AFE7B872EBF@muada.com> <17838240D9A5544AAA5FF95F8D52031602799B8C@ad-exh01.adhost.lan> Message-ID: <5C46CA79-6C98-4215-910C-CE56ED487640@muada.com> On 30-aug-2007, at 22:03, Michael K. Smith - Adhost wrote: >> Yes, they publish it daily on their FTP sites. Let me know if you >> want the php script to dump this info in a mysql database. > Is this the same script that feeds > http://www.bgpexpert.com/addrspace.php or something similar? Yes. > If so I > would greatly appreciate the tool so that I can munge the data at > will. Here you go: http://www.bgpexpert.com/rircountcode.tar.gz These are the scripts that put the data in the database, you'll have to think of queries to get it out of there yourself. :-) No implied warranty of fitness for a particular purpose etc and so forth ad nauseum et infinitum, you get the point. > I should add that having the data is Step 1. What is the > likelihood of > the RIR's accepting a statistical analysis of that data with an > attached > projection and then officially announcing that timeline? They've often said that they don't do that, which is understandable considering the difficulties. From paul at vix.com Fri Aug 31 09:34:18 2007 From: paul at vix.com (Paul Vixie) Date: Fri, 31 Aug 2007 13:34:18 +0000 Subject: [ppml] Policy Proposal: Definition of known ISP and changes to In-Reply-To: Your message of "Fri, 31 Aug 2007 08:33:34 -0400." <200708311233.l7VCXYBj005107@cjbsys.bdb.com> References: <200708311233.l7VCXYBj005107@cjbsys.bdb.com> Message-ID: <82435.1188567258@sa.vix.com> > I took a few shots for that but it sound like you're offering the same > thought. the important observation is that ipv4 its start through a swamp and if we want ipv6 to get a start we might have to allow a swamp also. remembering that the ipv4 swamp used to be a huge portion of the total ipv4 table, the most recent couple hundred thousand prefixes added have dwarfed the swamp. > Everybody keeps talking about the huge address space for v6 but all that > space is wasted if nobody uses it. yes. From Lee.Howard at stanleyassociates.com Fri Aug 31 09:55:39 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 31 Aug 2007 09:55:39 -0400 Subject: [ppml] Combining Forecasts In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB406D926E4@CL-S-EX-1.stanleyassociates.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB406D929D4@CL-S-EX-1.stanleyassociates.com> > an employee of APNIC, he is pretty well informed. Tony Li is > not affiliated with any RIR, but is also well-informed. Apologies to Tony Hain, who deserves credit for the work he has done. Tony Li deserves credit for completely different work. Search "Tony Hain IPv4" and you'll see some of the work I mean. Sorry, Tony. Lee From info at arin.net Fri Aug 31 10:18:19 2007 From: info at arin.net (Member Services) Date: Fri, 31 Aug 2007 10:18:19 -0400 Subject: [ppml] Policy Proposal: IPv6 Policy Housekeeping - version 2.0 In-Reply-To: <46C5E767.6010406@arin.net> References: <46C5E767.6010406@arin.net> Message-ID: <46D8232B.2090004@arin.net> The author submitted a revised version of their proposal. Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## 1. Policy Proposal Name: IPv6 Policy Housekeeping 2. Author 1. name: Leo Bicknell 2. email: bicknell at ufp.org 3. telephone: 901 853 9404 4. organization: Internet Systems Consortium, Inc. 3. Proposal Version: 2.0 4. Submission Date: 8/29/2007 5. Proposal type: modify 6. Policy term: permanent 7. Policy statement: Change I: In section 6.5.1.1.d, replace the existing statement with the new statement: "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." Change J: Remove section 6.5.3 entirely. Update all subsequent sections to have new section numbers (6.5.[n-1]). Replace part of the text as (new) section 6.5.4.4: "All /56 and larger assignments to end sites are required to be registered either by the LIR or its subordinate ISPs in such a way that the RIR/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary." Change K: Section 6.5.8.2, add the following sentence to the end of the first paragraph: "An HD-Ratio of .94 must be met for all assignments larger than a /48." Add to the end of the second paragraph: "This reservation may be assigned to other organizations later, at ARIN's discretion." Change L: Section 6.5.8.3, add a sentence between the two existing sentences: "Justification will be determined based on the .94 HD-Ratio metric." 8. Rationale: When the IPv6 policy was passed, it was considered to be an "interim" policy, and it was intended to be similar in all 5 RIR's. Since that time it has become clear the policy is no longer interim (and proposal 2007-4 was passed to change just that) and it has also been modified separately in the different RIR's. It was brought to the ARIN AC's attention that there were a number of problems with "Section 6" of the NRPM as a result of this legacy: * The policy contained a large number of items that were not policy. * The policy contained a few items that were self contradictory. * The added text was redundant in some cases with existing text. * The policy was overly vague in a few areas, leaving ARIN staff to have to make interpretations of what the policy intended. * Policy changes made since the initial IPv6 policy was adopted have not always updated all of the relevant sections due to the complexity of section 6. The intent of these changes is not to change any existing policy, but rather to remove all non-policy items, and update any ambiguous items with the way that ARIN staff is currently interprets the policy. Change I: Proposal 2005-8 amended section 6.5.4.1 to allow /56 and /64 allocations, but section 6.5.1.1.d was never updated to match the change. It is believed the intent of the policy, and ARIN staff's current interpretation of the policy match the updated text. Change J: The first part is not policy, and incorrectly states there is no policy as section 6.5.4 has the policy in it. Take the one useful part and make it part of the 6.5.4 criteria. Change K: No metric is currently listed to justify a larger initial assignment. It is believed ARIN staff is currently applying the HD-Ratio similar to the ISP policy, this puts that in writing. Make it clear that the reservation may not exist in perpetuity. Change L: No metric is given to justify additional assignments. It is believed that ARIN staff is currently applying the HD_Ratio similar to the ISP policy, this puts that in writing. 9. Timetable for implementation: Immediate. 10. Meeting presenter: Leo Bicknell END OF TEMPLATE 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 Policy Housekeeping > > Author: Leo Bicknell > > Proposal Version: 1.0 > > Submission Date: 8/17/2007 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Change A: > > Remove the text between the section 6 header and the section 6.1 > header. Remove section 6.1 entirely. Update all subsequent > sections to have new section numbers (6.[n-1]). > > Change B: > > Move the image in section 6.2 to section 2. > > Remove sections 6.2.1 to 6.2.6. > > Change C: > > Move section 6.2.7 to (new) section 2.8, subheading "IPv6". > > Create section 2.8, subheading "IPv4", containing the following text: > > In IPv4, utilization is the percentage of the address space > allocated or assigned relative to the total address space. > > Change D: > > Move section 6.2.8 to (new) section 2.8. > Move section 6.2.9 to (new) section 2.9. > > As this leaves section 6.2 empty, remove section 6.2. Update > all subsequent sections to have new section numbers (6.[n-1]). > > > Change E: > > Remove section 6.3. Update all subsequent sections to have new > section numbers (6.[n-1]). > > Change F: > > Remove section 6.4.1. Update all subsequent sections to have new > section numbers (6.4.[n-1]). > > Change G: > > Remove section 6.4.2. Update all subsequent sections to have new > section numbers (6.4.[n-1]). > > Change H: > > Remove section 6.4.4. > > Change I: > > In section 6.5.1.1.d, replace the existing statement with the new > statement: > > "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." > > Change J: > > Remove section 6.5.3 entirely. Update all subsequent sections to > have new section numbers (6.5.[n-1]). > > Replace part of the text as (new) section 6.5.4.4: > > "All /56 and larger assignments to end sites are required to be > registered either by the LIR or its subordinate ISPs in > such a way that the RIR/NIR can properly evaluate the > HD-Ratio when a subsequent allocation becomes necessary." > > Change K: > > Section 6.5.8.2, add the following sentence to the end of the first > paragraph: > > "An HD-Ratio of .94 must be met for all assignments larger than > a /48." > > Add to the end of the second paragraph: > > "This reservation may be assigned to other organizations > later, at ARIN's discretion." > > Change L: > > Section 6.5.8.3, add a sentence between the two existing sentences: > > "Justification will be determined based on the .94 HD-Ratio > metric." > > Change M: > > Remove section 6.6. Update all subsequent sections to have new > section numbers (6.[n-1]). > > Change N: > > Change the title of section 6.7 from "Appendix A: HD-Ratio" to > "HD-Ratio". > > Change O: > > Remove section 6.8. Update all subsequent sections to have new > section numbers (6.[n-1]). > > Rationale: > > When the IPv6 policy was passed, it was considered to be an "interim" > policy, and it was intended to be similar in all 5 RIR's. Since that > time it has become clear the policy is no longer interim (and proposal > 2007-4 was passed to change just that) and it has also been modified > separately in the different RIR's. > > It was brought to the ARIN AC's attention that there were a number of > problems with "Section 6" of the NRPM as a result of this legacy: > > * The policy contained a large number of items that were not policy. > * The policy contained a few items that were self contradictory. > * The added text was redundant in some cases with existing text. > * The policy was overly vague in a few areas, leaving ARIN staff to > have to make interpretations of what the policy intended. > * Policy changes made since the initial IPv6 policy was adopted have > not always updated all of the relevant sections due to the complexity > of section 6. > > The intent of these changes is not to change any existing policy, but > rather to remove all non-policy items, and update any ambiguous items > with the way that ARIN staff is currently interprets the policy. > > Change A: > > Not policy. Unnecessary. Confusing (policy is interim). > > Change B: > > Sections 6.2.1 to 6.2.6 are definitions that are already defined in > section 2.1 to 2.7 Repeating them here is unnecessary. The picture > is useful though, and should be moved to section 2 as part of the > definitions. > > Change C: > > This is a definition item, and should be in the definition section. > Also, the v4 versions should be defined at the same time. > > Change D: > > These are both definitions that should be in the definitions section. > > Change E: > > This is a manifesto, and is not address policy. If anything these > belong is ARIN's mission statement. > > Change F: > > Not policy; covered by the RSA as a legal matter. > > Change G: > > Not policy. A darn good warning though ARIN should include with > any other boilerplate when issuing address space. > > Change H: > > Not policy, and covered by actual policy statement 6.5.1.2. > > Change I: > > Proposal 2005-8 amended section 6.5.4.1 to allow /56 and /64 > allocations, but section 6.5.1.1.d was never updated to match > the change. It is believed the intent of the policy, and ARIN > staff's current interpretation of the policy match the updated > text. > > Change J: > > The first part is not policy, and incorrectly states there is no > policy as section 6.5.4 has the policy in it. Take the one useful > part and make it part of the 6.5.4 criteria. > > Change K: > > No metric is currently listed to justify a larger initial > assignment. It is believed ARIN staff is currently applying > the HD-Ratio similar to the ISP policy, this puts that in writing. > > Make it clear that the reservation may not exist in perpetuity. > > Change L: > > No metric is given to justify additional assignments. It is > believed that ARIN staff is currently applying the HD_Ratio > similar to the ISP policy, this puts that in writing. > > Change M: > > References, while useful on the web page and in template instructions > are not policy. > > Change N: > > It's not an appendix. It's not even at the end. > > Change O: > > The background information would be something nice to archive on the > ARIN web site somewhere, but is not policy and should be removed from > the policy manual. > > 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 michael.dillon at bt.com Fri Aug 31 10:55:04 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 31 Aug 2007 15:55:04 +0100 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationingof IPv4 IP Addresses In-Reply-To: <85975A4A-0077-4B71-B303-FD9FE27615F6@muada.com> References: <85975A4A-0077-4B71-B303-FD9FE27615F6@muada.com> Message-ID: > The only thing that looks pretty solid is that > there's almost always growth in the number of addresses used > up per year. Anything else only persists for a few years and > then changes. Those things that persist for a few years are the trends. And the changes have been explained due to macro events (CIDR introduction, telecoms collapse) so even though the trends go through step changes, they are still trends. One could still do a worst-case scenario based on the pre telecoms collapse trend and then estimate the probability that macroeconomic events will lead to that scenario. You then have an estimated runout date, and a probability that it will occur. > I don't think my number is very credible either, but I'm far > from convinced that the others are better. This is why I provided URLs to various forecasting methodology sites. There are some very learned people who have spent their entire life studying forecasting methodology. If someone were to point out flaws in Tony's or Geoff's methodology based on the published literature, that would be valuable. I would also expect Tony and Geoff to fix those flaws. In addition, given that there is an accepted methodology for combining multiple forecasts to improve accuracy and that combining forecasts has the most success when both the data sources and the methodology is different, I was hoping that someone like you would take up the challenge of finding another data source and producing yet another forecast. It's easy to wave your hands and be a sceptic but that doesn't lead us anywhere. > The theme seems to be either stick close to last year or jump > by more than 50%. Not exactly smooth. What is the frequency of the jumps? What is the average 5-age increase if you break the year-to-year increases into two classes, small ones, and bigger jumps. --Michael Dillon From bjohnson at drtel.com Fri Aug 31 11:24:05 2007 From: bjohnson at drtel.com (Brian Johnson) Date: Fri, 31 Aug 2007 10:24:05 -0500 Subject: [ppml] Policy Proposal: Definition of known ISP and changes to In-Reply-To: <200708311233.l7VCXYBj005107@cjbsys.bdb.com> References: <52117.1187980881@sa.vix.com> from "Paul Vixie" at Aug 24, 2007 06:41:21 PM <200708311233.l7VCXYBj005107@cjbsys.bdb.com> Message-ID: <29A54911243620478FF59F00EBB12F47B39873@ex01.drtel.lan> cliffb at cjbsys.bdb.com wrote: > > "If there is really a desire to get v6 started, ARIN should give every > entity that has existing IPv4 addresses equivalent IPv6 > addresses under > whatever provisions they are under now, including no fees for > grandfathered PI addresses like mine." > Isn't there already a prefix set aside for mapping ipv4 into ipv6? If there isn't, wouldn't doing this imply that anyone who has ipv4 space can simply map this into ipv6 and away you go? Example: I have an IPv4 allocation of 12.34/16. My IPv6 allocation would be XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:12.34.00.00/96. (since I am not sue off-hand if the prefix exists, or if it exists, what it is, I am using Xs) If such a prefix exists, it would be very easy to use a dual stack and assign the IPv6 address that matches the IPv4 address. Slap me if I'm crazy. :) - Brian From michael.dillon at bt.com Fri Aug 31 11:31:50 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 31 Aug 2007 16:31:50 +0100 Subject: [ppml] [address-policy-wg] Re: IPv6 addresses really are scarce after all In-Reply-To: <59D5CFF02CEE1D3C96D66409@p3.JCK.COM> References: <46C613E0.8010909@bogus.com> <46C629D2.20009@cs.utk.edu> <17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com> <46C6B5BB.5000203@cs.utk.edu> <200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <46D05897.5010906@cs.utk.edu> <59D5CFF02CEE1D3C96D66409@p3.JCK.COM> Message-ID: > Will all due respect, even if you assume a "home" with ten > occupants, a few hundred subnets based on functions, and > enough sensor-type devices to estimate several thousand of > them per occupant and a few thousand more per room, 2**64 is still a > _lot_ of addresses. This is hyperbole. All IPv6 subnets have the same minimum number of addresses (2**64) regardless of where they are used. > But I don't think hyperbole > helps the discussion. I agree. In any case, it doesn't make sense to discuss IPv6 in terms of hostcounts. It makes more sense to discuss numbers of subnets or numbers of aggregation levels. If a private home with two occupants and one PC, builds out an in-law suite for one mother-in-law with one PC, then it still makes sense to have at least two subnets in that private home, i.e. at least one level of aggregation. Hostcount is irrelevant. Note that if both mother-in-law and homeowner install 4 or five home media devices, the subnetted architecture will work better than a /64 per home scenario. Now that we have shown subnetting is useful in a private home, it is clear that a /64 per home is not enough. It still leaves open the question of whether a /48 is too much, i.e. too many subnets and/or too many levels of aggregation. If a /48 is not too much, then the IETF should issue guidance that states that. If some prefix length between /48 and /64 is OK under certain circumstances then the IETF should issue guidance which states that. I still have not seen any clear indication that there is a negative technical impact of assigning a /56 per home. To date, the only clear technical issue I have seen mentioned for subnet prefixes longer than /48 is that if they are not on a 4-bit hex nibble boundary, it makes IPv6 PTR delegation more complex. --Michael Dillon From drc at virtualized.org Fri Aug 31 11:30:53 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 31 Aug 2007 08:30:53 -0700 Subject: [ppml] Policy Proposal: Definition of known ISP and changes to In-Reply-To: <82435.1188567258@sa.vix.com> References: <200708311233.l7VCXYBj005107@cjbsys.bdb.com> <82435.1188567258@sa.vix.com> Message-ID: <6F089EC1-589B-4192-AE7E-9DAC2BE6ACC4@virtualized.org> On Aug 31, 2007, at 6:34 AM, Paul Vixie wrote: >> I took a few shots for that but it sound like you're offering the >> same >> thought. > > the important observation is that ipv4 its start through a swamp > and if we want ipv6 to get a start we might have to allow a swamp > also. I believe we're already on that path. Shall I dust off my suggestion of /48-on-demand? > remembering > that the ipv4 swamp used to be a huge portion of the total ipv4 > table, the > most recent couple hundred thousand prefixes added have dwarfed the > swamp. What is your definition of "the swamp"? >> Everybody keeps talking about the huge address space for v6 but >> all that >> space is wasted if nobody uses it. > > yes. I'm beginning to believe that IPv6 as it exists is so flawed and the business/economic/political factors are such that in the end, the only real hope that the routing system won't all come crashing down around our ears is some sort of "jack up" loc/id split solution like LISP (et al., see the RAM and RRG mailing list archives if this reference is unclear). As such, you could look at all IPv6 allocations to date as end point identifiers that will (somehow, someday) get mapped into provider aggregatable locators. It's sort of like assuming that we'll be switching in-flight to anti-gravity before we run out of jet fuel. Regards, -drc From cliffb at cjbsys.bdb.com Fri Aug 31 11:30:43 2007 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Fri, 31 Aug 2007 11:30:43 -0400 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with RSA Message-ID: <46D83423.1000908@cjbsys.bdb.com> If I understand this proposal correctly, I cannot support it as written. It says "To qualify for a direct assignment, an organization must: 1. not be an IPv6 LIR; and 2. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect, or demonstrate efficient utilization of a direct IPv4 assignment or allocation covered by a current ARIN RSA." As I understand this proposal, it is an attempt to get legacy v4 holders to come in under the ARIN umbrella and get started on v6. I could not find an exact definition of efficient utilization" but I think many (most?) of the legacy people not under an RSA might not qualify under that criteria. I expect that most of the legacy holders who have not had to sign an RSA with ARIN for additional space are companies/businesses that haven't had to grow to the point where they would meet the "efficient utilization" criteria. At the time these v4s were issued, we had 3 choices. a Class A (/8), Class B(/16) or Class C(/24). Except for the smallest of us home office types, most people estimated optimistically and got a bigger space than they needed. (Remember at that time, the internet was "infinite".) Those who morphed to ISPs and needed more later had to come under an RSA as they grew. The rest were relatively static and most probably didn't grow to "efficiently" fill the address space they were given. Since most of the ones who grew eventually came under an RSA, the group this policy proposal is aimed at would not be covered by it without having to trade in their existing v4 space or in the case of Class C/24s couldn't keep their /24. There certainly seems to be no incentive for them to come in from the cold and many reasons not to As a result, I don't see where this proposal as written will accomplish its stated goal and thus should not be adopted. Perhaps if it were worded "are actively using the legacy space", that would encourage more to join. I'm not sure what would be done with the /8s if they were using the equivalent of a /16 or less but if that were case, they might be able to give back some of the /8 without requiring any renumbering. As an example, I have a /24 and have 15-30 devices on my network. This might grow in the future but probably not to 128 Under existing and this proposed policy, I don't believe I would qualify for PI v6 space and thus see no reason to be in favor of it. (and frankly not much reason to continue to read through the sometimes prolific traffic on the group :-) ). I expect many of the mis-sent unsubscribe messages that have shown up were sent by those in a similar situation. Cliff -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From cliffb at cjbsys.bdb.com Fri Aug 31 11:58:39 2007 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Fri, 31 Aug 2007 11:58:39 -0400 (EDT) Subject: [ppml] Policy Proposal: Definition of known ISP and changes to In-Reply-To: <29A54911243620478FF59F00EBB12F47B39873@ex01.drtel.lan> from "Brian Johnson" at Aug 31, 2007 10:24:05 AM Message-ID: <200708311558.l7VFwd5D006385@cjbsys.bdb.com> > > > cliffb at cjbsys.bdb.com wrote: > > > > "If there is really a desire to get v6 started, ARIN should give every > > entity that has existing IPv4 addresses equivalent IPv6 > > addresses under > > whatever provisions they are under now, including no fees for > > grandfathered PI addresses like mine." > > > > Isn't there already a prefix set aside for mapping ipv4 into ipv6? If > there isn't, wouldn't doing this imply that anyone who has ipv4 space > can simply map this into ipv6 and away you go? > > Example: I have an IPv4 allocation of 12.34/16. My IPv6 allocation would > be XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:12.34.00.00/96. (since I am not sue > off-hand if the prefix exists, or if it exists, what it is, I am using > Xs) > > If such a prefix exists, it would be very easy to use a dual stack and > assign the IPv6 address that matches the IPv4 address. How would that work with routing. v6 only goes to /64 and thus I think there would be a lot of v4 tunneling to a gateway to get the v6 in and out. Cliff > > Slap me if I'm crazy. :) > > - 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. > -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From dlw+arin at tellme.com Fri Aug 31 12:01:58 2007 From: dlw+arin at tellme.com (David Williamson) Date: Fri, 31 Aug 2007 09:01:58 -0700 Subject: [ppml] Policy Proposal: Definition of known ISP and changes to In-Reply-To: <29A54911243620478FF59F00EBB12F47B39873@ex01.drtel.lan> References: <52117.1187980881@sa.vix.com> <200708311233.l7VCXYBj005107@cjbsys.bdb.com> <29A54911243620478FF59F00EBB12F47B39873@ex01.drtel.lan> Message-ID: <20070831160158.GG28312@shell01.cell.sv2.tellme.com> On Fri, Aug 31, 2007 at 10:24:05AM -0500, Brian Johnson wrote: > Isn't there already a prefix set aside for mapping ipv4 into ipv6? If > there isn't, wouldn't doing this imply that anyone who has ipv4 space > can simply map this into ipv6 and away you go? Do you mean the stuff defined in RFC 3513 section 2.5.5? I don't think anyone's routing that. I think the mechanism was even obsoleted by another RFC. Perhaps you are referring to the NAT-PT described in RFC 2766, which is obsoleted by RFC 4966. In either case, I don't think this will work as you think. -David From bjohnson at drtel.com Fri Aug 31 12:14:53 2007 From: bjohnson at drtel.com (Brian Johnson) Date: Fri, 31 Aug 2007 11:14:53 -0500 Subject: [ppml] Policy Proposal: Definition of known ISP and changes to In-Reply-To: <200708311558.l7VFwd5D006385@cjbsys.bdb.com> References: <29A54911243620478FF59F00EBB12F47B39873@ex01.drtel.lan> from "Brian Johnson" at Aug 31, 2007 10:24:05 AM <200708311558.l7VFwd5D006385@cjbsys.bdb.com> Message-ID: <29A54911243620478FF59F00EBB12F47B3987C@ex01.drtel.lan> cliffb at cjbsys.bdb.com wrote: > > > > > > > cliffb at cjbsys.bdb.com wrote: > > > > > > "If there is really a desire to get v6 started, ARIN > should give every > > > entity that has existing IPv4 addresses equivalent IPv6 > > > addresses under > > > whatever provisions they are under now, including no fees for > > > grandfathered PI addresses like mine." > > > > > > > Isn't there already a prefix set aside for mapping ipv4 > into ipv6? If > > there isn't, wouldn't doing this imply that anyone who has > ipv4 space > > can simply map this into ipv6 and away you go? > > > > Example: I have an IPv4 allocation of 12.34/16. My IPv6 > allocation would > > be XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:12.34.00.00/96. (since I am not sue > > off-hand if the prefix exists, or if it exists, what it is, > I am using > > Xs) > > > > If such a prefix exists, it would be very easy to use a > dual stack and > > assign the IPv6 address that matches the IPv4 address. > > How would that work with routing. v6 only goes to /64 and > thus I think there > would be a lot of v4 tunneling to a gateway to get the v6 in and out. > > > Cliff > I have no idea why there would need to be a limit to network routing prefix sizes other than the obvious bloviating over routing table size. Not that I don't care, but whenever new technology emerges there is always a delay to market with equipment that can handle it (at least in a free market there is). Is there a technical reason for the /64 barrier or is it just a policy decision? - Brian From sleibrand at internap.com Fri Aug 31 12:15:52 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 31 Aug 2007 09:15:52 -0700 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with RSA In-Reply-To: <46D83423.1000908@cjbsys.bdb.com> References: <46D83423.1000908@cjbsys.bdb.com> Message-ID: <46D83EB8.8040400@internap.com> Cliff, Thanks for your comments. I believe I addressed this issue in the Rationale section of the policy proposal, but I'm not sure if I was completely clear. Let me outline how I intended this to work: * If you have a /24, and are using it for multihoming, that should be considered efficient use, so you should be able to bring the /24 under an RSA and get an IPv6 PI block. * If you have anything larger than a /24, and are utilizing less than half of it, you should return as much of it as necessary (by bisecting your block, returning half of it, and repeating as necessary) to bring your usage up above 50%. The remaining block can then be brought under an RSA, and you can receive an IPv6 PI block. Would that work for you? If not, why not? If so, do you believe that the Rationale is sufficient guidance to ARIN as to how to evaluate "efficient utilization" in this context, or do you think the policy proposal requires clarification? Thanks for the feedback, Scott Cliff Bedore wrote: > If I understand this proposal correctly, I cannot support it as written. > > It says > > "To qualify for a direct assignment, an organization must: > > 1. not be an IPv6 LIR; and 2. qualify for an IPv4 assignment or > allocation from ARIN under the IPv4 policy currently in effect, or > demonstrate efficient utilization of a direct IPv4 assignment or > allocation covered by a current ARIN RSA." > > As I understand this proposal, it is an attempt to get legacy v4 holders > to come in under the ARIN umbrella and get started on v6. I could not > find an exact definition of efficient utilization" but I think many > (most?) of the legacy people not under an RSA might not qualify under > that criteria. I expect that most of the legacy holders who have not > had to sign an RSA with ARIN for additional space are > companies/businesses that haven't had to grow to the point where they > would meet the "efficient utilization" criteria. At the time these v4s > were issued, we had 3 choices. a Class A (/8), Class B(/16) or Class > C(/24). Except for the smallest of us home office types, most people > estimated optimistically and got a bigger space than they needed. > (Remember at that time, the internet was "infinite".) Those who morphed > to ISPs and needed more later had to come under an RSA as they grew. > The rest were relatively static and most probably didn't grow to > "efficiently" fill the address space they were given. Since most of the > ones who grew eventually came under an RSA, the group this policy > proposal is aimed at would not be covered by it without having to trade > in their existing v4 space or in the case of Class C/24s couldn't keep > their /24. There certainly seems to be no incentive for them to come in > from the cold and many reasons not to As a result, I don't see where > this proposal as written will accomplish its stated goal and thus should > not be adopted. > > Perhaps if it were worded "are actively using the legacy space", that > would encourage more to join. I'm not sure what would be done with the > /8s if they were using the equivalent of a /16 or less but if that were > case, they might be able to give back some of the /8 without requiring > any renumbering. > > As an example, I have a /24 and have 15-30 devices on my network. This > might grow in the future but probably not to 128 Under existing and > this proposed policy, I don't believe I would qualify for PI v6 space > and thus see no reason to be in favor of it. (and frankly not much > reason to continue to read through the sometimes prolific traffic on the > group :-) ). I expect many of the mis-sent unsubscribe messages that > have shown up were sent by those in a similar situation. > > Cliff > > -- > Cliff Bedore > 7403 Radcliffe Dr. College Park MD 20740 > cliffb at cjbsys.bdb.com http://www.bdb.com > Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ > > > _______________________________________________ > 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 arin-contact at dirtside.com Fri Aug 31 12:19:25 2007 From: arin-contact at dirtside.com (William Herrin) Date: Fri, 31 Aug 2007 12:19:25 -0400 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with RSA In-Reply-To: <46D83423.1000908@cjbsys.bdb.com> References: <46D83423.1000908@cjbsys.bdb.com> Message-ID: <3c3e3fca0708310919j76c3fd00k96e247368ec2694e@mail.gmail.com> On 8/31/07, Cliff Bedore wrote: > As I understand this proposal, it is an attempt to get legacy v4 holders > to come in under the ARIN umbrella and get started on v6. Cliff, The proposal is an attempt to make IPv6 provider-independent addresses available to multihomed folks with only /23's and /24's. Currently IPv6 PI space is only available to folks who qualify for an IPv4 /22 or larger regardless of whether they're multihomed. This means that there are existing multihomed IPv4 organizations who aren't able to multihome with IPv6 because they can't get PI space. Obviously this discourages their deployment of IPv6. More than a few content providers fall into this category as well as a number of hobbyist networks held by senior network administration staff. As a result, it creates a drag on IPv6 deployment overall. IPv6 deployment is moving slowly enough as it is; drag-effects due to ARIN policy are unhelpful. Signing the RSA for your /23 or /24 is merely the entry fee to gain this new privilege. If you don't want or need the new privilege then you don't have to sign. Given the structure of filtering in the DFZ, nothing longer than a /24 prefix is usable for multihomed organizations. I'm pretty sure that means any utilization of a /24 for a *multihomed* user is "efficient." Perhaps ARIN staff can comment on that when they present their evaluation of the proposal. I think it would also be helpful if ARIN staff would discuss potential procedures for dealing with a situation where a holder's use is not efficient. Does the holder return sufficient space to become efficient? Does he renumber into new smaller space selected from elsewhere in the swamp so that his new space is efficient? Those are operating procedures rather than policy questions, but it would be helpful to see how the policy would be implemented in order to determine if any of the policy language should be adjusted. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From arin-contact at dirtside.com Fri Aug 31 12:47:39 2007 From: arin-contact at dirtside.com (William Herrin) Date: Fri, 31 Aug 2007 12:47:39 -0400 Subject: [ppml] Policy Proposal: Definition of known ISP and changes to In-Reply-To: <29A54911243620478FF59F00EBB12F47B39873@ex01.drtel.lan> References: <52117.1187980881@sa.vix.com> <200708311233.l7VCXYBj005107@cjbsys.bdb.com> <29A54911243620478FF59F00EBB12F47B39873@ex01.drtel.lan> Message-ID: <3c3e3fca0708310947l1d617b4dr5b0f15645d4e9c00@mail.gmail.com> On 8/31/07, Brian Johnson wrote: > Isn't there already a prefix set aside for mapping ipv4 into ipv6? If > there isn't, wouldn't doing this imply that anyone who has ipv4 space > can simply map this into ipv6 and away you go? Brian, The short answer is: sort of but not exactly. There are several specifications that map existing IPv4 addresses into various portions of the IPv6 address space for specific purposes. For example, there is a mapping at the sockets API level that tells the IPv6 sockets API to use IPv4 instead. Another example is the 6to4 protocol which sets up dynamic tunnels to an IPv6 /48 for each IPv4 address that acts as a tunnel router. There is, however, no general-purpose mapping which specifies that a block of IPv4 addresses maps to a range of IPv6 addresses that are genericly routeable on the IPv6 Internet. I made a proposal to create such a mapping a few months back (IPv4 to IPv6 Migration Incentive Address Space) but got shot down hard. I followed up with a proposal that tweaked 6to4 so that its address space could be dual-purposed to the task but got shot down on that as well. The chief issue revolves around the table size in the default-free zone (the backbone). Each provider-independent prefix consumes a slot in the very expensive TCAM memory of every single router in the DFZ. To give a ballpark estimate, your slot costs something in the neighborhood of $0.10-$0.20 per router and there are somewhere north of 200,000 affected routers. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From mksmith at adhost.com Fri Aug 31 13:05:09 2007 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Fri, 31 Aug 2007 10:05:09 -0700 Subject: [ppml] Combining Forecasts In-Reply-To: <46d78f5f.390.2455.26524@batelnet.bs> References: <46d78f5f.390.2455.26524@batelnet.bs> Message-ID: <17838240D9A5544AAA5FF95F8D52031602799C79@ad-exh01.adhost.lan> > -----Original Message----- > From: martin.hannigan at batelnet.bs [mailto:martin.hannigan at batelnet.bs] > Sent: Thursday, August 30, 2007 8:48 PM > To: Michael K. Smith - Adhost; David Conrad > Cc: Public Policy Mailing List > Subject: Re: [ppml] Combining Forecasts > > > ----- Original Message ----- > From: "Michael K. Smith - Adhost" > To: "David Conrad" > Cc: Public Policy Mailing List > Subject: Re: [ppml] Combining Forecasts > Date: Thu, 30 Aug 2007 10:45:30 -0700 > > > > -----Original Message----- > > > From: David Conrad [mailto:drc at virtualized.org] > > > Sent: Thursday, August 30, 2007 9:32 AM > > > To: Michael K. Smith - Adhost > > > Cc: Public Policy Mailing List > > > Subject: Re: [ppml] Combining Forecasts > > > > > > > If we are going to use the forecasts to incent people > > > > to move from IPv4 > > > > to IPv6 then we should be as accurate as possible. > > > > > > It is a bit challenging to model human behavior. > > > > > > How do you model a "run on the bank"? > > > > > > How do you model a transition of public space to NAT'd > > > space as an effort towards conservation? > > > > > > Projections such as Geoff's and Tony's are useful, but I > > > do not believe they are something you should bet your > > > house on. > > > Regards, > > > -drc > > > > I think it's a matter of helping the community make > > informed decisions based upon accurate forecasts. > > I'm more concerned that policy changes will be implemented > that shut out small to medium size networks long before > exhaustion. > > -M< > Thinking out loud here. In order to accommodate the relative size of the organization and their associated use within the larger depletion forecasts, the model would have to be broken up to show utilization based upon organization size. So, in ARIN's case, what are the usage/depletion forecasts based upon utilization of: - Micro /24 - /19 - /16 - Large >/16 - /14 - X-Large >/14 Perhaps grouping Micro, Small and Medium into Small, so we have Small, Large and X-large, based upon the assumption that there is more mobility between the three lower tiers (Micro to Small, Small to Medium, etc.) than between the other two. This would simplify the model a bit and provide a basis for policies that reserve space for the small providers. Mike From cliffb at cjbsys.bdb.com Fri Aug 31 13:27:22 2007 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Fri, 31 Aug 2007 13:27:22 -0400 (EDT) Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with In-Reply-To: <46D83EB8.8040400@internap.com> from "Scott Leibrand" at Aug 31, 2007 09:15:52 AM Message-ID: <200708311727.l7VHRMnK006779@cjbsys.bdb.com> Scott See comments below > > Cliff, > > Thanks for your comments. > > I believe I addressed this issue in the Rationale section of the policy > proposal, but I'm not sure if I was completely clear. Let me outline > how I intended this to work: > > * If you have a /24, and are using it for multihoming, that should > be considered efficient use, so you should be able to bring the > /24 under an RSA and get an IPv6 PI block. > * If you have anything larger than a /24, and are utilizing less > than half of it, you should return as much of it as necessary (by > bisecting your block, returning half of it, and repeating as > necessary) to bring your usage up above 50%. The remaining block > can then be brought under an RSA, and you can receive an IPv6 PI > block. > > > Would that work for you? If not, why not? If so, do you believe that > the Rationale is sufficient guidance to ARIN as to how to evaluate > "efficient utilization" in this context, or do you think the policy > proposal requires clarification? > It would not work for me. I am not multi-homed. I have a single DSL line to my upstream provider. I know in the best of all worlds I would be but I'm not now. I think the problem is that there are a fair number of legacy people who are like me. They are probably /24s since that was what was given if you coouldn't justify a /16. Cliff > Thanks for the feedback, > Scott > > Cliff Bedore wrote: > > If I understand this proposal correctly, I cannot support it as written. > > > > It says > > > > "To qualify for a direct assignment, an organization must: > > > > 1. not be an IPv6 LIR; and 2. qualify for an IPv4 assignment or > > allocation from ARIN under the IPv4 policy currently in effect, or > > demonstrate efficient utilization of a direct IPv4 assignment or > > allocation covered by a current ARIN RSA." > > > > As I understand this proposal, it is an attempt to get legacy v4 holders > > to come in under the ARIN umbrella and get started on v6. I could not > > find an exact definition of efficient utilization" but I think many > > (most?) of the legacy people not under an RSA might not qualify under > > that criteria. I expect that most of the legacy holders who have not > > had to sign an RSA with ARIN for additional space are > > companies/businesses that haven't had to grow to the point where they > > would meet the "efficient utilization" criteria. At the time these v4s > > were issued, we had 3 choices. a Class A (/8), Class B(/16) or Class > > C(/24). Except for the smallest of us home office types, most people > > estimated optimistically and got a bigger space than they needed. > > (Remember at that time, the internet was "infinite".) Those who morphed > > to ISPs and needed more later had to come under an RSA as they grew. > > The rest were relatively static and most probably didn't grow to > > "efficiently" fill the address space they were given. Since most of the > > ones who grew eventually came under an RSA, the group this policy > > proposal is aimed at would not be covered by it without having to trade > > in their existing v4 space or in the case of Class C/24s couldn't keep > > their /24. There certainly seems to be no incentive for them to come in > > from the cold and many reasons not to As a result, I don't see where > > this proposal as written will accomplish its stated goal and thus should > > not be adopted. > > > > Perhaps if it were worded "are actively using the legacy space", that > > would encourage more to join. I'm not sure what would be done with the > > /8s if they were using the equivalent of a /16 or less but if that were > > case, they might be able to give back some of the /8 without requiring > > any renumbering. > > > > As an example, I have a /24 and have 15-30 devices on my network. This > > might grow in the future but probably not to 128 Under existing and > > this proposed policy, I don't believe I would qualify for PI v6 space > > and thus see no reason to be in favor of it. (and frankly not much > > reason to continue to read through the sometimes prolific traffic on the > > group :-) ). I expect many of the mis-sent unsubscribe messages that > > have shown up were sent by those in a similar situation. > > > > Cliff > > > > -- > > Cliff Bedore > > 7403 Radcliffe Dr. College Park MD 20740 > > cliffb at cjbsys.bdb.com http://www.bdb.com > > Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ > > > > > > _______________________________________________ > > 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. > > > -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From info at arin.net Fri Aug 31 13:20:31 2007 From: info at arin.net (Member Services) Date: Fri, 31 Aug 2007 13:20:31 -0400 Subject: [ppml] Policy Proposal 2007-15: Authentication of Legacy Resources - version 1.1 In-Reply-To: <46A65981.90004@arin.net> References: <46A65981.90004@arin.net> Message-ID: <46D84DDF.1030609@arin.net> The author submitted a revised version of Policy Proposal 2007-15: Authentication of Legacy Resources. Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 1. Policy Proposal Name: Authentication of Legacy Resources 2. Author a. name: Andrew Dul b. email: andrew.dul at quark.net c. telephone: +1 206-359-8130 d. organization: Perkins Coie LLP 3. Proposal Version: 1.1 4. Submission Date: 5. Proposal type: New 6. Policy term: Permanent 7. Policy statement: Add new NRPM section 4.9 - Legacy Records Legacy resource record holders shall be permitted to sign a registration services agreement which permits the legacy organization which is currently using the resources as of January 1, 2007 to continue to use those resources as long as a valid registration services agreement is in effect for the organization. ARIN will evaluate and verify the chain of custody of any resource records prior to executing a registration services agreement with an organization. ARIN shall use all reasonable methods to attempt to contact legacy record holders starting on January 1, 2008 to notify them of this change in policy. ARIN shall also post information on the public website regarding this outreach to legacy resource holders. No changes shall be made to legacy resource records which are not covered by a registration services agreement after December 31, 2007. If a legacy resource holder requests additional IPv4 resources all IPv4 resources (legacy and non-legacy) shall be evaluated to determine utilization for additional allocations or assignments under NRPM sections 4.2 or 4.3. 8. Rationale: An ARIN Legacy resource holder is an organization which was issued number resources prior to the formation of ARIN and whose registration information was not transferred to another RIR through the Early Registration Transfer Project (http://www.arin.net/registration/erx). Legacy resource holders were issued number resources through an informal process. This policy proposal attempts to bring these legacy resource holders into a formal agreement with ARIN, the manager of the IP numbering resources for many of the legacy record holders. This policy is similar to a policy which has been adopted in the APNIC region. (http://www.apnic.net/docs/policy/proposals/prop-018-v001.html) Some legacy resource holders have expressed concerns about committing to a registration service agreement (RSA) when the legacy resource holder cannot be assured that they will be permitted to retain their resources for the long-term. This policy proposal requests ARIN to develop a RSA which will allow legacy resource holders to continue to use IPv4 resources which were assigned or allocated prior to ARIN's formation. It is also suggested that the Board of Trustees formalize the annual maintenance fees for legacy resource holders at a level similar to the $100 USD per year for end-sites or provide fee-waivers as an incentive for legacy holders to sign a registration services agreement. The dates in this policy proposal were arbitrarily chosen based upon an expected ratification by the ARIN Board of Trustees by December 31, 2007. If this policy is implemented after December 31, 2007, the trigger dates in the policy should be adjusted appropriately. Given the informal relationship under which the resources were granted, ARIN currently maintains the records including WHOIS and in-addr.arpa delegations in a best-effort fashion. Some believe that ARIN may not be obligated to maintain these records. ARIN has also experienced some difficulty maintaining these records. Legacy records have been a popular target for hijackers, in part due to the out of date information contained in these records. Having up to date contact information and a formal relationship with legacy record holders would assist ARIN and ISP's in insuring these records are maintained accurately. Legacy resource holders who sign a RSA would continue to receive all the services that are currently provided by ARIN plus they would be eligible for any future services that ARIN may offer, such as cryptographic signing of resource records. 9. Timetable for implementation: As stated in policy 10. Meeting presenter: END OF TEMPLATE Member Services wrote: > On 19 July 2007, the ARIN Advisory Council (AC) concluded their initial > review of "Authentication of Legacy Resources" and accepted it as a > formal policy proposal for discussion by the community. > > The proposal is designated Policy Proposal 2007-15: Authentication of > Legacy Resources. The proposal text is below and can be found at: > http://www.arin.net/policy/proposals/2007_15.html > > All persons in the community are encouraged to discuss Policy Proposal > 2007-15 prior to it being presented at the ARIN Public Policy Meeting in > Albuquerque, New Mexico, 17-18 October 2007. 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-15 > Authentication of Legacy Resources > > Author: Andrew Dul > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Add new NRPM section 4.9 - Legacy Records > > Legacy resource record holders shall be permitted to sign an > registration services agreement which permits the organization which is > currently using the resources as of January 1, 2007 to continue to use > those resources as long as a registration services agreement is signed > by the organization and the organization is not past-due on their annual > maintenance fee. ARIN will evaluate and verify the chain of custody of > any resource records prior to executing a registration services > agreement with an organization. > > If a legacy resource holder requests additional IPv4 resources all IPv4 > resources (legacy and non-legacy) shall be evaluated to determine > utilization for additional assignments under NRPM sections 4.2 or 4.3. > > ARIN shall use all reasonable methods to attempt to contact legacy > record holders starting on January 1, 2008. > > ARIN shall also post information on the public website regarding this > outreach to legacy resource holders. > > No changes shall be made to legacy resource records which are not > covered by a registration services agreement after December 31, 2007. > > Add new NRPM section 7.3 - Legacy Reverse Delegation Records > > Legacy IP address record holders who have not signed a registration > services agreement with ARIN will have their name server delegations for > the in-addr.arpa zone removed starting on June 30, 2009. All name server > delegations shall be removed from the in-addr.arpa zone by December 31, > 2009. > > If an individual contacts ARIN and claims to represent a legacy record > holder after the removal of an organization's name server delegations, > the individual shall be permitted to request a one-time 6 month > reinstatement of their name server delegations. This 6 month period is > intended to allow an organization to work in good faith to establish a > registration services agreement. > > Policy Rationale > > An ARIN Legacy resource holder is an organization which was issued > number resources prior to the formation of ARIN and whose registration > information was not transferred to another RIR through the Early > Registration Transfer Project (http://www.arin.net/registration/erx). > Legacy resource holders were issued number resources through an informal > process. This policy proposal attempts to bring these legacy resource > holders into a formal agreement with ARIN, the manager of the IP > numbering resources for many of the legacy record holders. > > Some legacy resource holders have expressed concerns about committing to > a registration services agreement when the legacy resource holder cannot > be assured that they will be permitted to retain and their resources for > the long-term. This policy proposal also does not preclude existing > legacy space holders, who may have signed another version of the > registration services agreement from having the same commitment level. > It is suggested that the Board of Trustees formalize the annual > maintenance fees for legacy resource holders at a level similar to the > $100 USD per year for end-sites. > > This policy sets in place a notification period of 18 months to contact > all legacy resource holders and creates an incentive for the holders to > formalize their relationship with ARIN. The dates in this policy > proposal were arbitrarily chosen based upon an expected ratification by > the ARIN Board of Trustees by December 31, 2007. If this policy is > implemented after December 31, 2007, the trigger dates in the policy > should be adjusted appropriately. > > Given the informal relationship under which the resources were granted, > ARIN current maintains the records including WHOIS and in-addr.arpa > delegations in a best-effort fashion. Many believe that ARIN may not be > obligated to maintain these records. ARIN has experienced some > difficulty maintaining these records. Legacy records have been a popular > target for hijackers, in part due to the out of date information > contained in these records. Having up to date contact information would > assist ARIN and ISP's in insuring the stability of the Internet. > > This policy proposal sets a termination date for in-addr.arpa delegation > services for legacy resource record holders who have not formalized > their relationship with ARIN through a registration services agreement. > The 6 month period of delegation record removal was intended to provide > ARIN the flexibility of removing the records on a gradual plan during > second half of 2009 and to avoid a large change on a single day. > > Legacy resource holders who sign a registration services agreement would > continue to receive all the services that are currently provided by ARIN > plus they would be eligible for any future services that ARIN may offer, > such as cryptographic signing of resource records. > > Timetable for implementation: As stated in policy > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From sleibrand at internap.com Fri Aug 31 13:38:47 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 31 Aug 2007 10:38:47 -0700 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with In-Reply-To: <200708311727.l7VHRMnK006779@cjbsys.bdb.com> References: <200708311727.l7VHRMnK006779@cjbsys.bdb.com> Message-ID: <46D85227.3050206@internap.com> Cliff Bedore wrote: > It would not work for me. I am not multi-homed. I have a single DSL line to > my upstream provider. I know in the best of all worlds I would be but I'm not > now. I think the problem is that there are a fair number of legacy people who > are like me. They are probably /24s since that was what was given if you > coouldn't justify a /16. > Ok. In that case, would you be able to route an IPv6 PI block if you got one? Is the inability to get IPv6 PI space holding you back from adopting IPv6? I'm sure there are legacy /24 holders who wouldn't be able to get IPv6 PI space under this proposal, but what I'm really trying to address are people for whom that is holding them back from adopting IPv6. -Scott From sleibrand at internap.com Fri Aug 31 13:47:35 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 31 Aug 2007 10:47:35 -0700 Subject: [ppml] Policy Proposal 2007-15: Authentication of Legacy Resources - version 1.1 In-Reply-To: <46D84DDF.1030609@arin.net> References: <46A65981.90004@arin.net> <46D84DDF.1030609@arin.net> Message-ID: <46D85437.1060507@internap.com> I support this policy proposal. I think it strikes a good balance, encouraging legacy holders to sign an RSA in exchange for the right to continue using the space they were assigned. It does not, AFAICT, give legacy holders any new rights, and is narrowly constructed such that any future reclamation incentives (such as allowing address transfers) can be restricted only to record holders demonstrating efficient use of their space. -Scott Member Services wrote: > The author submitted a revised version of Policy Proposal 2007-15: > Authentication of Legacy Resources. > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 > 1. Policy Proposal Name: Authentication of Legacy Resources > 2. Author > a. name: Andrew Dul > b. email: andrew.dul at quark.net > c. telephone: +1 206-359-8130 > d. organization: Perkins Coie LLP > 3. Proposal Version: 1.1 > 4. Submission Date: > 5. Proposal type: New > 6. Policy term: Permanent > 7. Policy statement: > Add new NRPM section 4.9 - Legacy Records Legacy resource record holders > shall be permitted to sign a registration services agreement which > permits the legacy organization which is currently using the resources > as of January 1, 2007 to continue to use those resources as long as a > valid registration services agreement is in effect for the organization. > ARIN will evaluate and verify the chain of custody of any resource > records prior to executing a registration services agreement with an > organization. > > ARIN shall use all reasonable methods to attempt to contact legacy > record holders starting on January 1, 2008 to notify them of this change > in policy. ARIN shall also post information on the public website > regarding this outreach to legacy resource holders. > > No changes shall be made to legacy resource records which are not > covered by a registration services agreement after December 31, 2007. > > If a legacy resource holder requests additional IPv4 resources all IPv4 > resources (legacy and non-legacy) shall be evaluated to determine > utilization for additional allocations or assignments under NRPM > sections 4.2 or 4.3. > > 8. Rationale: > An ARIN Legacy resource holder is an organization which was issued > number resources prior to the formation of ARIN and whose registration > information was not transferred to another RIR through the Early > Registration Transfer Project (http://www.arin.net/registration/erx). > > Legacy resource holders were issued number resources through an informal > process. This policy proposal attempts to bring these legacy resource > holders into a formal agreement with ARIN, the manager of the IP > numbering resources for many of the legacy record holders. > > This policy is similar to a policy which has been adopted in the APNIC > region. (http://www.apnic.net/docs/policy/proposals/prop-018-v001.html) > > Some legacy resource holders have expressed concerns about committing to > a registration service agreement (RSA) when the legacy resource holder > cannot be assured that they will be permitted to retain their resources > for the long-term. This policy proposal requests ARIN to develop a RSA > which will allow legacy resource holders to continue to use IPv4 > resources which were assigned or allocated prior to ARIN's formation. > It is also suggested that the Board of Trustees formalize the annual > maintenance fees for legacy resource holders at a level similar to the > $100 USD per year for end-sites or provide fee-waivers as an incentive > for legacy holders to sign a registration services agreement. > > The dates in this policy proposal were arbitrarily chosen based upon an > expected ratification by the ARIN Board of Trustees by December 31, > 2007. If this policy is implemented after December 31, 2007, the > trigger dates in the policy should be adjusted appropriately. > > Given the informal relationship under which the resources were granted, > ARIN currently maintains the records including WHOIS and in-addr.arpa > delegations in a best-effort fashion. Some believe that ARIN may not be > obligated to maintain these records. ARIN has also experienced some > difficulty maintaining these records. Legacy records have been a > popular target for hijackers, in part due to the out of date information > contained in these records. Having up to date contact information and a > formal relationship with legacy record holders would assist ARIN and > ISP's in insuring these records are maintained accurately. > > Legacy resource holders who sign a RSA would continue to receive all the > services that are currently provided by ARIN plus they would be eligible > for any future services that ARIN may offer, such as cryptographic > signing of resource records. > > 9. Timetable for implementation: As stated in policy > 10. Meeting presenter: > END OF TEMPLATE > > > Member Services wrote: > >> On 19 July 2007, the ARIN Advisory Council (AC) concluded their initial >> review of "Authentication of Legacy Resources" and accepted it as a >> formal policy proposal for discussion by the community. >> >> The proposal is designated Policy Proposal 2007-15: Authentication of >> Legacy Resources. The proposal text is below and can be found at: >> http://www.arin.net/policy/proposals/2007_15.html >> >> All persons in the community are encouraged to discuss Policy Proposal >> 2007-15 prior to it being presented at the ARIN Public Policy Meeting in >> Albuquerque, New Mexico, 17-18 October 2007. 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-15 >> Authentication of Legacy Resources >> >> Author: Andrew Dul >> >> Proposal type: New >> >> Policy term: Permanent >> >> Policy statement: >> >> Add new NRPM section 4.9 - Legacy Records >> >> Legacy resource record holders shall be permitted to sign an >> registration services agreement which permits the organization which is >> currently using the resources as of January 1, 2007 to continue to use >> those resources as long as a registration services agreement is signed >> by the organization and the organization is not past-due on their annual >> maintenance fee. ARIN will evaluate and verify the chain of custody of >> any resource records prior to executing a registration services >> agreement with an organization. >> >> If a legacy resource holder requests additional IPv4 resources all IPv4 >> resources (legacy and non-legacy) shall be evaluated to determine >> utilization for additional assignments under NRPM sections 4.2 or 4.3. >> >> ARIN shall use all reasonable methods to attempt to contact legacy >> record holders starting on January 1, 2008. >> >> ARIN shall also post information on the public website regarding this >> outreach to legacy resource holders. >> >> No changes shall be made to legacy resource records which are not >> covered by a registration services agreement after December 31, 2007. >> >> Add new NRPM section 7.3 - Legacy Reverse Delegation Records >> >> Legacy IP address record holders who have not signed a registration >> services agreement with ARIN will have their name server delegations for >> the in-addr.arpa zone removed starting on June 30, 2009. All name server >> delegations shall be removed from the in-addr.arpa zone by December 31, >> 2009. >> >> If an individual contacts ARIN and claims to represent a legacy record >> holder after the removal of an organization's name server delegations, >> the individual shall be permitted to request a one-time 6 month >> reinstatement of their name server delegations. This 6 month period is >> intended to allow an organization to work in good faith to establish a >> registration services agreement. >> >> Policy Rationale >> >> An ARIN Legacy resource holder is an organization which was issued >> number resources prior to the formation of ARIN and whose registration >> information was not transferred to another RIR through the Early >> Registration Transfer Project (http://www.arin.net/registration/erx). >> Legacy resource holders were issued number resources through an informal >> process. This policy proposal attempts to bring these legacy resource >> holders into a formal agreement with ARIN, the manager of the IP >> numbering resources for many of the legacy record holders. >> >> Some legacy resource holders have expressed concerns about committing to >> a registration services agreement when the legacy resource holder cannot >> be assured that they will be permitted to retain and their resources for >> the long-term. This policy proposal also does not preclude existing >> legacy space holders, who may have signed another version of the >> registration services agreement from having the same commitment level. >> It is suggested that the Board of Trustees formalize the annual >> maintenance fees for legacy resource holders at a level similar to the >> $100 USD per year for end-sites. >> >> This policy sets in place a notification period of 18 months to contact >> all legacy resource holders and creates an incentive for the holders to >> formalize their relationship with ARIN. The dates in this policy >> proposal were arbitrarily chosen based upon an expected ratification by >> the ARIN Board of Trustees by December 31, 2007. If this policy is >> implemented after December 31, 2007, the trigger dates in the policy >> should be adjusted appropriately. >> >> Given the informal relationship under which the resources were granted, >> ARIN current maintains the records including WHOIS and in-addr.arpa >> delegations in a best-effort fashion. Many believe that ARIN may not be >> obligated to maintain these records. ARIN has experienced some >> difficulty maintaining these records. Legacy records have been a popular >> target for hijackers, in part due to the out of date information >> contained in these records. Having up to date contact information would >> assist ARIN and ISP's in insuring the stability of the Internet. >> >> This policy proposal sets a termination date for in-addr.arpa delegation >> services for legacy resource record holders who have not formalized >> their relationship with ARIN through a registration services agreement. >> The 6 month period of delegation record removal was intended to provide >> ARIN the flexibility of removing the records on a gradual plan during >> second half of 2009 and to avoid a large change on a single day. >> >> Legacy resource holders who sign a registration services agreement would >> continue to receive all the services that are currently provided by ARIN >> plus they would be eligible for any future services that ARIN may offer, >> such as cryptographic signing of resource records. >> >> Timetable for implementation: As stated in policy >> >> >> _______________________________________________ >> This message sent to you through the ARIN Public Policy Mailing List >> (PPML at arin.net). >> Manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml >> >> > _______________________________________________ > PPML > 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 arin-contact at dirtside.com Fri Aug 31 14:09:23 2007 From: arin-contact at dirtside.com (William Herrin) Date: Fri, 31 Aug 2007 14:09:23 -0400 Subject: [ppml] Policy Proposal 2007-15: Authentication of Legacy Resources - version 1.1 In-Reply-To: <46D84DDF.1030609@arin.net> References: <46A65981.90004@arin.net> <46D84DDF.1030609@arin.net> Message-ID: <3c3e3fca0708311109k72dc15fbicf62f04eff9d32cb@mail.gmail.com> On 8/31/07, Member Services wrote: > 1. Policy Proposal Name: Authentication of Legacy Resources > No changes shall be made to legacy resource records which are not > covered by a registration services agreement after December 31, 2007. I still oppose this. The time for punitive measures (however minor) against folks who registered IP addresses prior to ARIN's existence has not yet arrived and probably never will. If you absolutely must do something to give the outreach some teeth, consider something like this: "Changes to legacy resource records not covered by a registration services agreement after December 31, 2008 shall be made only if the registrant can be authenticated via electronic mail to an existing POC email address." That addresses ARIN's legitimate need for valid contact info without breaching the duty ARIN acknowledged and took on itself when it accepted authority for the legacy /8's. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From iljitsch at muada.com Fri Aug 31 15:26:49 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 31 Aug 2007 21:26:49 +0200 Subject: [ppml] IPv6 flawed? In-Reply-To: <6F089EC1-589B-4192-AE7E-9DAC2BE6ACC4@virtualized.org> References: <200708311233.l7VCXYBj005107@cjbsys.bdb.com> <82435.1188567258@sa.vix.com> <6F089EC1-589B-4192-AE7E-9DAC2BE6ACC4@virtualized.org> Message-ID: On 31-aug-2007, at 17:30, David Conrad wrote: > I'm beginning to believe that IPv6 as it exists is so flawed and the > business/economic/political factors are such that in the end, the > only real hope [...] What are those flaws, exactly? Please omit the ones that are either relatively trivial so they're not worth condemning the entire protocol, and also the ones that are fundamental to IP as it exists in general and would be so ambitious to fix that we can't reasonably expect to do so successfully within a reasonable timeframe. From bicknell at ufp.org Fri Aug 31 15:27:02 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 31 Aug 2007 15:27:02 -0400 Subject: [ppml] Policy Proposal: IPv6 Policy Housekeeping - version 2.0 In-Reply-To: <46D8232B.2090004@arin.net> References: <46C5E767.6010406@arin.net> <46D8232B.2090004@arin.net> Message-ID: <20070831192702.GC43118@ussenterprise.ufp.org> It's also probably not obvious what happened here. The AC is working with staff on making the NRPM more clear; the intention is to do some minor editing that does not change any policy. Things like improved defintions, better cross references, etc. The AC felt that my original proposal had both policy changes and these sorts of edits in it. The edits have been removed and put in the hopper with the larger editing project which will appear in the future. What's left below are the changes the AC belived are policy changes. Back to my original purpose. I actually don't want to change policy with this cleanup, however there are some places where the policy is ambiguous, or worse not self consisent. In the cases below the "fix" is to make policy, to make it consistent and clear. I have picked what I believe are the most straightforward ways of making the policy clear and consisent however since the isse has been brought up I suspect people will want to debate the points in more detail, and that's fine. To reduce confusion, I've left the change letters the same as before; however there are only now four in this policy. In a message written on Fri, Aug 31, 2007 at 10:18:19AM -0400, Member Services wrote: > The author submitted a revised version of their proposal. > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > 1. Policy Proposal Name: IPv6 Policy Housekeeping > 2. Author > 1. name: Leo Bicknell > 2. email: bicknell at ufp.org > 3. telephone: 901 853 9404 > 4. organization: Internet Systems Consortium, Inc. > 3. Proposal Version: 2.0 > 4. Submission Date: 8/29/2007 > 5. Proposal type: modify > 6. Policy term: permanent > 7. Policy statement: > > Change I: > > In section 6.5.1.1.d, replace the existing statement with the new > statement: > > "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." > > Change J: > > Remove section 6.5.3 entirely. Update all subsequent sections to > have new section numbers (6.5.[n-1]). > > Replace part of the text as (new) section 6.5.4.4: > > "All /56 and larger assignments to end sites are required to be > registered either by the LIR or its subordinate ISPs in > such a way that the RIR/NIR can properly evaluate the > HD-Ratio when a subsequent allocation becomes necessary." > > Change K: > > Section 6.5.8.2, add the following sentence to the end of the first > paragraph: > > "An HD-Ratio of .94 must be met for all assignments larger than > a /48." > > Add to the end of the second paragraph: > > "This reservation may be assigned to other organizations > later, at ARIN's discretion." > > Change L: > > Section 6.5.8.3, add a sentence between the two existing sentences: > > "Justification will be determined based on the .94 HD-Ratio > metric." > > 8. Rationale: > > When the IPv6 policy was passed, it was considered to be an "interim" > policy, and it was intended to be similar in all 5 RIR's. Since that > time it has become clear the policy is no longer interim (and proposal > 2007-4 was passed to change just that) and it has also been modified > separately in the different RIR's. > > It was brought to the ARIN AC's attention that there were a number of > problems with "Section 6" of the NRPM as a result of this legacy: > > * The policy contained a large number of items that were not policy. > * The policy contained a few items that were self contradictory. > * The added text was redundant in some cases with existing text. > * The policy was overly vague in a few areas, leaving ARIN staff to > have to make interpretations of what the policy intended. > * Policy changes made since the initial IPv6 policy was adopted have > not always updated all of the relevant sections due to the complexity > of section 6. > > The intent of these changes is not to change any existing policy, but > rather to remove all non-policy items, and update any ambiguous items > with the way that ARIN staff is currently interprets the policy. > > Change I: > > Proposal 2005-8 amended section 6.5.4.1 to allow /56 and /64 > allocations, but section 6.5.1.1.d was never updated to match > the change. It is believed the intent of the policy, and ARIN > staff's current interpretation of the policy match the updated > text. > > Change J: > > The first part is not policy, and incorrectly states there is no > policy as section 6.5.4 has the policy in it. Take the one useful > part and make it part of the 6.5.4 criteria. > > Change K: > > No metric is currently listed to justify a larger initial > assignment. It is believed ARIN staff is currently applying > the HD-Ratio similar to the ISP policy, this puts that in writing. > > Make it clear that the reservation may not exist in perpetuity. > > Change L: > > No metric is given to justify additional assignments. It is > believed that ARIN staff is currently applying the HD_Ratio > similar to the ISP policy, this puts that in writing. > > 9. Timetable for implementation: Immediate. > 10. Meeting presenter: Leo Bicknell > > END OF TEMPLATE > > > 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 Policy Housekeeping > > > > Author: Leo Bicknell > > > > Proposal Version: 1.0 > > > > Submission Date: 8/17/2007 > > > > Proposal type: modify > > > > Policy term: permanent > > > > Policy statement: > > > > Change A: > > > > Remove the text between the section 6 header and the section 6.1 > > header. Remove section 6.1 entirely. Update all subsequent > > sections to have new section numbers (6.[n-1]). > > > > Change B: > > > > Move the image in section 6.2 to section 2. > > > > Remove sections 6.2.1 to 6.2.6. > > > > Change C: > > > > Move section 6.2.7 to (new) section 2.8, subheading "IPv6". > > > > Create section 2.8, subheading "IPv4", containing the following text: > > > > In IPv4, utilization is the percentage of the address space > > allocated or assigned relative to the total address space. > > > > Change D: > > > > Move section 6.2.8 to (new) section 2.8. > > Move section 6.2.9 to (new) section 2.9. > > > > As this leaves section 6.2 empty, remove section 6.2. Update > > all subsequent sections to have new section numbers (6.[n-1]). > > > > > > Change E: > > > > Remove section 6.3. Update all subsequent sections to have new > > section numbers (6.[n-1]). > > > > Change F: > > > > Remove section 6.4.1. Update all subsequent sections to have new > > section numbers (6.4.[n-1]). > > > > Change G: > > > > Remove section 6.4.2. Update all subsequent sections to have new > > section numbers (6.4.[n-1]). > > > > Change H: > > > > Remove section 6.4.4. > > > > Change I: > > > > In section 6.5.1.1.d, replace the existing statement with the new > > statement: > > > > "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." > > > > Change J: > > > > Remove section 6.5.3 entirely. Update all subsequent sections to > > have new section numbers (6.5.[n-1]). > > > > Replace part of the text as (new) section 6.5.4.4: > > > > "All /56 and larger assignments to end sites are required to be > > registered either by the LIR or its subordinate ISPs in > > such a way that the RIR/NIR can properly evaluate the > > HD-Ratio when a subsequent allocation becomes necessary." > > > > Change K: > > > > Section 6.5.8.2, add the following sentence to the end of the first > > paragraph: > > > > "An HD-Ratio of .94 must be met for all assignments larger than > > a /48." > > > > Add to the end of the second paragraph: > > > > "This reservation may be assigned to other organizations > > later, at ARIN's discretion." > > > > Change L: > > > > Section 6.5.8.3, add a sentence between the two existing sentences: > > > > "Justification will be determined based on the .94 HD-Ratio > > metric." > > > > Change M: > > > > Remove section 6.6. Update all subsequent sections to have new > > section numbers (6.[n-1]). > > > > Change N: > > > > Change the title of section 6.7 from "Appendix A: HD-Ratio" to > > "HD-Ratio". > > > > Change O: > > > > Remove section 6.8. Update all subsequent sections to have new > > section numbers (6.[n-1]). > > > > Rationale: > > > > When the IPv6 policy was passed, it was considered to be an "interim" > > policy, and it was intended to be similar in all 5 RIR's. Since that > > time it has become clear the policy is no longer interim (and proposal > > 2007-4 was passed to change just that) and it has also been modified > > separately in the different RIR's. > > > > It was brought to the ARIN AC's attention that there were a number of > > problems with "Section 6" of the NRPM as a result of this legacy: > > > > * The policy contained a large number of items that were not policy. > > * The policy contained a few items that were self contradictory. > > * The added text was redundant in some cases with existing text. > > * The policy was overly vague in a few areas, leaving ARIN staff to > > have to make interpretations of what the policy intended. > > * Policy changes made since the initial IPv6 policy was adopted have > > not always updated all of the relevant sections due to the complexity > > of section 6. > > > > The intent of these changes is not to change any existing policy, but > > rather to remove all non-policy items, and update any ambiguous items > > with the way that ARIN staff is currently interprets the policy. > > > > Change A: > > > > Not policy. Unnecessary. Confusing (policy is interim). > > > > Change B: > > > > Sections 6.2.1 to 6.2.6 are definitions that are already defined in > > section 2.1 to 2.7 Repeating them here is unnecessary. The picture > > is useful though, and should be moved to section 2 as part of the > > definitions. > > > > Change C: > > > > This is a definition item, and should be in the definition section. > > Also, the v4 versions should be defined at the same time. > > > > Change D: > > > > These are both definitions that should be in the definitions section. > > > > Change E: > > > > This is a manifesto, and is not address policy. If anything these > > belong is ARIN's mission statement. > > > > Change F: > > > > Not policy; covered by the RSA as a legal matter. > > > > Change G: > > > > Not policy. A darn good warning though ARIN should include with > > any other boilerplate when issuing address space. > > > > Change H: > > > > Not policy, and covered by actual policy statement 6.5.1.2. > > > > Change I: > > > > Proposal 2005-8 amended section 6.5.4.1 to allow /56 and /64 > > allocations, but section 6.5.1.1.d was never updated to match > > the change. It is believed the intent of the policy, and ARIN > > staff's current interpretation of the policy match the updated > > text. > > > > Change J: > > > > The first part is not policy, and incorrectly states there is no > > policy as section 6.5.4 has the policy in it. Take the one useful > > part and make it part of the 6.5.4 criteria. > > > > Change K: > > > > No metric is currently listed to justify a larger initial > > assignment. It is believed ARIN staff is currently applying > > the HD-Ratio similar to the ISP policy, this puts that in writing. > > > > Make it clear that the reservation may not exist in perpetuity. > > > > Change L: > > > > No metric is given to justify additional assignments. It is > > believed that ARIN staff is currently applying the HD_Ratio > > similar to the ISP policy, this puts that in writing. > > > > Change M: > > > > References, while useful on the web page and in template instructions > > are not policy. > > > > Change N: > > > > It's not an appendix. It's not even at the end. > > > > Change O: > > > > The background information would be something nice to archive on the > > ARIN web site somewhere, but is not policy and should be removed from > > the policy manual. > > > > 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. > > > _______________________________________________ > 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. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From drc at virtualized.org Fri Aug 31 15:36:02 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 31 Aug 2007 12:36:02 -0700 Subject: [ppml] IPv6 flawed? In-Reply-To: References: <200708311233.l7VCXYBj005107@cjbsys.bdb.com> <82435.1188567258@sa.vix.com> <6F089EC1-589B-4192-AE7E-9DAC2BE6ACC4@virtualized.org> Message-ID: <4F2DB929-C3C4-475B-BAF6-7B6616FDC778@virtualized.org> Discussions about my personal views of how the IPv6 architecture is flawed probably aren't appropriate for the ARIN PPML list. Regards, -drc On Aug 31, 2007, at 12:26 PM, Iljitsch van Beijnum wrote: > On 31-aug-2007, at 17:30, David Conrad wrote: > >> I'm beginning to believe that IPv6 as it exists is so flawed and the >> business/economic/political factors are such that in the end, the >> only real hope > > [...] > > What are those flaws, exactly? > > Please omit the ones that are either relatively trivial so they're > not worth condemning the entire protocol, and also the ones that > are fundamental to IP as it exists in general and would be so > ambitious to fix that we can't reasonably expect to do so > successfully within a reasonable timeframe. > > > From sleibrand at internap.com Fri Aug 31 15:40:43 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 31 Aug 2007 12:40:43 -0700 Subject: [ppml] Policy Proposal: IPv6 Policy Housekeeping - version 2.0 In-Reply-To: <20070831192702.GC43118@ussenterprise.ufp.org> References: <46C5E767.6010406@arin.net> <46D8232B.2090004@arin.net> <20070831192702.GC43118@ussenterprise.ufp.org> Message-ID: <46D86EBB.2030606@internap.com> Thanks for the explanation. I support this proposal, as a good and useful cleanup. The only thing that seems even remotely controversial to me would be the clarifications that your 200 assignments to get an LIR /32 need to be to "other organizations". I think this is what was originally intended by the LIR /32 policy, and will close a loophole used by some organizations to get a /32 when they probably should have gotten IPv6 PI space instead. -Scott Leo Bicknell wrote: > It's also probably not obvious what happened here. > > The AC is working with staff on making the NRPM more clear; the > intention is to do some minor editing that does not change any > policy. Things like improved defintions, better cross references, > etc. The AC felt that my original proposal had both policy changes > and these sorts of edits in it. > > The edits have been removed and put in the hopper with the larger > editing project which will appear in the future. What's left below > are the changes the AC belived are policy changes. > > Back to my original purpose. I actually don't want to change policy > with this cleanup, however there are some places where the policy > is ambiguous, or worse not self consisent. In the cases below the > "fix" is to make policy, to make it consistent and clear. I have > picked what I believe are the most straightforward ways of making > the policy clear and consisent however since the isse has been > brought up I suspect people will want to debate the points in more > detail, and that's fine. > > To reduce confusion, I've left the change letters the same as before; > however there are only now four in this policy. > > In a message written on Fri, Aug 31, 2007 at 10:18:19AM -0400, Member Services wrote: > >> The author submitted a revised version of their proposal. >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> 1. Policy Proposal Name: IPv6 Policy Housekeeping >> 2. Author >> 1. name: Leo Bicknell >> 2. email: bicknell at ufp.org >> 3. telephone: 901 853 9404 >> 4. organization: Internet Systems Consortium, Inc. >> 3. Proposal Version: 2.0 >> 4. Submission Date: 8/29/2007 >> 5. Proposal type: modify >> 6. Policy term: permanent >> 7. Policy statement: >> >> Change I: >> >> In section 6.5.1.1.d, replace the existing statement with the new >> statement: >> >> "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." >> >> Change J: >> >> Remove section 6.5.3 entirely. Update all subsequent sections to >> have new section numbers (6.5.[n-1]). >> >> Replace part of the text as (new) section 6.5.4.4: >> >> "All /56 and larger assignments to end sites are required to be >> registered either by the LIR or its subordinate ISPs in >> such a way that the RIR/NIR can properly evaluate the >> HD-Ratio when a subsequent allocation becomes necessary." >> >> Change K: >> >> Section 6.5.8.2, add the following sentence to the end of the first >> paragraph: >> >> "An HD-Ratio of .94 must be met for all assignments larger than >> a /48." >> >> Add to the end of the second paragraph: >> >> "This reservation may be assigned to other organizations >> later, at ARIN's discretion." >> >> Change L: >> >> Section 6.5.8.3, add a sentence between the two existing sentences: >> >> "Justification will be determined based on the .94 HD-Ratio >> metric." >> >> 8. Rationale: >> >> When the IPv6 policy was passed, it was considered to be an "interim" >> policy, and it was intended to be similar in all 5 RIR's. Since that >> time it has become clear the policy is no longer interim (and proposal >> 2007-4 was passed to change just that) and it has also been modified >> separately in the different RIR's. >> >> It was brought to the ARIN AC's attention that there were a number of >> problems with "Section 6" of the NRPM as a result of this legacy: >> >> * The policy contained a large number of items that were not policy. >> * The policy contained a few items that were self contradictory. >> * The added text was redundant in some cases with existing text. >> * The policy was overly vague in a few areas, leaving ARIN staff to >> have to make interpretations of what the policy intended. >> * Policy changes made since the initial IPv6 policy was adopted have >> not always updated all of the relevant sections due to the complexity >> of section 6. >> >> The intent of these changes is not to change any existing policy, but >> rather to remove all non-policy items, and update any ambiguous items >> with the way that ARIN staff is currently interprets the policy. >> >> Change I: >> >> Proposal 2005-8 amended section 6.5.4.1 to allow /56 and /64 >> allocations, but section 6.5.1.1.d was never updated to match >> the change. It is believed the intent of the policy, and ARIN >> staff's current interpretation of the policy match the updated >> text. >> >> Change J: >> >> The first part is not policy, and incorrectly states there is no >> policy as section 6.5.4 has the policy in it. Take the one useful >> part and make it part of the 6.5.4 criteria. >> >> Change K: >> >> No metric is currently listed to justify a larger initial >> assignment. It is believed ARIN staff is currently applying >> the HD-Ratio similar to the ISP policy, this puts that in writing. >> >> Make it clear that the reservation may not exist in perpetuity. >> >> Change L: >> >> No metric is given to justify additional assignments. It is >> believed that ARIN staff is currently applying the HD_Ratio >> similar to the ISP policy, this puts that in writing. >> >> 9. Timetable for implementation: Immediate. >> 10. Meeting presenter: Leo Bicknell >> >> END OF TEMPLATE >> >> >> 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 Policy Housekeeping >>> >>> Author: Leo Bicknell >>> >>> Proposal Version: 1.0 >>> >>> Submission Date: 8/17/2007 >>> >>> Proposal type: modify >>> >>> Policy term: permanent >>> >>> Policy statement: >>> >>> Change A: >>> >>> Remove the text between the section 6 header and the section 6.1 >>> header. Remove section 6.1 entirely. Update all subsequent >>> sections to have new section numbers (6.[n-1]). >>> >>> Change B: >>> >>> Move the image in section 6.2 to section 2. >>> >>> Remove sections 6.2.1 to 6.2.6. >>> >>> Change C: >>> >>> Move section 6.2.7 to (new) section 2.8, subheading "IPv6". >>> >>> Create section 2.8, subheading "IPv4", containing the following text: >>> >>> In IPv4, utilization is the percentage of the address space >>> allocated or assigned relative to the total address space. >>> >>> Change D: >>> >>> Move section 6.2.8 to (new) section 2.8. >>> Move section 6.2.9 to (new) section 2.9. >>> >>> As this leaves section 6.2 empty, remove section 6.2. Update >>> all subsequent sections to have new section numbers (6.[n-1]). >>> >>> >>> Change E: >>> >>> Remove section 6.3. Update all subsequent sections to have new >>> section numbers (6.[n-1]). >>> >>> Change F: >>> >>> Remove section 6.4.1. Update all subsequent sections to have new >>> section numbers (6.4.[n-1]). >>> >>> Change G: >>> >>> Remove section 6.4.2. Update all subsequent sections to have new >>> section numbers (6.4.[n-1]). >>> >>> Change H: >>> >>> Remove section 6.4.4. >>> >>> Change I: >>> >>> In section 6.5.1.1.d, replace the existing statement with the new >>> statement: >>> >>> "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." >>> >>> Change J: >>> >>> Remove section 6.5.3 entirely. Update all subsequent sections to >>> have new section numbers (6.5.[n-1]). >>> >>> Replace part of the text as (new) section 6.5.4.4: >>> >>> "All /56 and larger assignments to end sites are required to be >>> registered either by the LIR or its subordinate ISPs in >>> such a way that the RIR/NIR can properly evaluate the >>> HD-Ratio when a subsequent allocation becomes necessary." >>> >>> Change K: >>> >>> Section 6.5.8.2, add the following sentence to the end of the first >>> paragraph: >>> >>> "An HD-Ratio of .94 must be met for all assignments larger than >>> a /48." >>> >>> Add to the end of the second paragraph: >>> >>> "This reservation may be assigned to other organizations >>> later, at ARIN's discretion." >>> >>> Change L: >>> >>> Section 6.5.8.3, add a sentence between the two existing sentences: >>> >>> "Justification will be determined based on the .94 HD-Ratio >>> metric." >>> >>> Change M: >>> >>> Remove section 6.6. Update all subsequent sections to have new >>> section numbers (6.[n-1]). >>> >>> Change N: >>> >>> Change the title of section 6.7 from "Appendix A: HD-Ratio" to >>> "HD-Ratio". >>> >>> Change O: >>> >>> Remove section 6.8. Update all subsequent sections to have new >>> section numbers (6.[n-1]). >>> >>> Rationale: >>> >>> When the IPv6 policy was passed, it was considered to be an "interim" >>> policy, and it was intended to be similar in all 5 RIR's. Since that >>> time it has become clear the policy is no longer interim (and proposal >>> 2007-4 was passed to change just that) and it has also been modified >>> separately in the different RIR's. >>> >>> It was brought to the ARIN AC's attention that there were a number of >>> problems with "Section 6" of the NRPM as a result of this legacy: >>> >>> * The policy contained a large number of items that were not policy. >>> * The policy contained a few items that were self contradictory. >>> * The added text was redundant in some cases with existing text. >>> * The policy was overly vague in a few areas, leaving ARIN staff to >>> have to make interpretations of what the policy intended. >>> * Policy changes made since the initial IPv6 policy was adopted have >>> not always updated all of the relevant sections due to the complexity >>> of section 6. >>> >>> The intent of these changes is not to change any existing policy, but >>> rather to remove all non-policy items, and update any ambiguous items >>> with the way that ARIN staff is currently interprets the policy. >>> >>> Change A: >>> >>> Not policy. Unnecessary. Confusing (policy is interim). >>> >>> Change B: >>> >>> Sections 6.2.1 to 6.2.6 are definitions that are already defined in >>> section 2.1 to 2.7 Repeating them here is unnecessary. The picture >>> is useful though, and should be moved to section 2 as part of the >>> definitions. >>> >>> Change C: >>> >>> This is a definition item, and should be in the definition section. >>> Also, the v4 versions should be defined at the same time. >>> >>> Change D: >>> >>> These are both definitions that should be in the definitions section. >>> >>> Change E: >>> >>> This is a manifesto, and is not address policy. If anything these >>> belong is ARIN's mission statement. >>> >>> Change F: >>> >>> Not policy; covered by the RSA as a legal matter. >>> >>> Change G: >>> >>> Not policy. A darn good warning though ARIN should include with >>> any other boilerplate when issuing address space. >>> >>> Change H: >>> >>> Not policy, and covered by actual policy statement 6.5.1.2. >>> >>> Change I: >>> >>> Proposal 2005-8 amended section 6.5.4.1 to allow /56 and /64 >>> allocations, but section 6.5.1.1.d was never updated to match >>> the change. It is believed the intent of the policy, and ARIN >>> staff's current interpretation of the policy match the updated >>> text. >>> >>> Change J: >>> >>> The first part is not policy, and incorrectly states there is no >>> policy as section 6.5.4 has the policy in it. Take the one useful >>> part and make it part of the 6.5.4 criteria. >>> >>> Change K: >>> >>> No metric is currently listed to justify a larger initial >>> assignment. It is believed ARIN staff is currently applying >>> the HD-Ratio similar to the ISP policy, this puts that in writing. >>> >>> Make it clear that the reservation may not exist in perpetuity. >>> >>> Change L: >>> >>> No metric is given to justify additional assignments. It is >>> believed that ARIN staff is currently applying the HD_Ratio >>> similar to the ISP policy, this puts that in writing. >>> >>> Change M: >>> >>> References, while useful on the web page and in template instructions >>> are not policy. >>> >>> Change N: >>> >>> It's not an appendix. It's not even at the end. >>> >>> Change O: >>> >>> The background information would be something nice to archive on the >>> ARIN web site somewhere, but is not policy and should be removed from >>> the policy manual. >>> >>> 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. >>> >>> >> _______________________________________________ >> 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. >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 mack at exchange.alphared.com Fri Aug 31 16:03:08 2007 From: mack at exchange.alphared.com (mack) Date: Fri, 31 Aug 2007 15:03:08 -0500 Subject: [ppml] Legacy /24s In-Reply-To: References: Message-ID: <859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local> I don't have the time to write it but I would support a proposal that gives legacy /24 holders a permanent IPv4 fee waiver, an efficient usage waiver so that they don't have to worry about reclamation, and allows assignment of an appropriate sized block of IPv6 if they start paying a fee after some specified date (ie. Jan 1, 2010) or whenever the regular IPv6 waiver expires if it is extended beyond this date. With the only contingency that the space be actively used in the DFZ or showing that the space is in use in a manner that cannot be readily replaced by 1918 space. I personally feel that the /24 space needs to be handled differently than the /16 and /8 space. 1) Because there are more of these than the others numerically. 2) Because there is no significant reclamation benefit if they are being used. 3) Most of these are individuals or small companies that don't have significant resources. The use contingency allows for private use in organizations that may find it difficult to convert to 1918 space. This would be neutral in overall effect. It cost them nothing unless they want IPv6 space. It will encourage adoption of IPv6 by these users. It will move a significant number of legacy blocks under a policy umbrella. This obviously would be for the 2008 timeframe. LR Mack McBride Network Administrator Alpha Red, Inc. From dlw+arin at tellme.com Fri Aug 31 16:04:57 2007 From: dlw+arin at tellme.com (David Williamson) Date: Fri, 31 Aug 2007 13:04:57 -0700 Subject: [ppml] Policy Proposal: IPv6 Policy Housekeeping - version 2.0 In-Reply-To: <46D86EBB.2030606@internap.com> References: <46C5E767.6010406@arin.net> <46D8232B.2090004@arin.net> <20070831192702.GC43118@ussenterprise.ufp.org> <46D86EBB.2030606@internap.com> Message-ID: <20070831200457.GI28312@shell01.cell.sv2.tellme.com> I agree entirely. This proposal simply makes sense of policy that was previously ambiguous or missing. I'll also agree that the only point of controversy is that that LIR language, although I also fully support that change. The loophole could be broadly interpreted as "if you are a big enough company, you can have IPv6 space - if you are a smaller org, too bad." (The implementation of the IPv6 PI policy finally put that specific concern to bed.) Closing the loophole will point large companies at the PI policy, which also seems like a good plan. Thanks, Leo, for the effort in driving this one! -David On Fri, Aug 31, 2007 at 12:40:43PM -0700, Scott Leibrand wrote: > Thanks for the explanation. > > I support this proposal, as a good and useful cleanup. The only thing > that seems even remotely controversial to me would be the clarifications > that your 200 assignments to get an LIR /32 need to be to "other > organizations". I think this is what was originally intended by the LIR > /32 policy, and will close a loophole used by some organizations to get > a /32 when they probably should have gotten IPv6 PI space instead. > > -Scott > > Leo Bicknell wrote: > > It's also probably not obvious what happened here. > > > > The AC is working with staff on making the NRPM more clear; the > > intention is to do some minor editing that does not change any > > policy. Things like improved defintions, better cross references, > > etc. The AC felt that my original proposal had both policy changes > > and these sorts of edits in it. > > > > The edits have been removed and put in the hopper with the larger > > editing project which will appear in the future. What's left below > > are the changes the AC belived are policy changes. > > > > Back to my original purpose. I actually don't want to change policy > > with this cleanup, however there are some places where the policy > > is ambiguous, or worse not self consisent. In the cases below the > > "fix" is to make policy, to make it consistent and clear. I have > > picked what I believe are the most straightforward ways of making > > the policy clear and consisent however since the isse has been > > brought up I suspect people will want to debate the points in more > > detail, and that's fine. > > > > To reduce confusion, I've left the change letters the same as before; > > however there are only now four in this policy. > > > > In a message written on Fri, Aug 31, 2007 at 10:18:19AM -0400, Member Services wrote: > > > >> The author submitted a revised version of their proposal. > >> > >> Regards, > >> > >> Member Services > >> American Registry for Internet Numbers (ARIN) > >> > >> > >> ## * ## > >> > >> 1. Policy Proposal Name: IPv6 Policy Housekeeping > >> 2. Author > >> 1. name: Leo Bicknell > >> 2. email: bicknell at ufp.org > >> 3. telephone: 901 853 9404 > >> 4. organization: Internet Systems Consortium, Inc. > >> 3. Proposal Version: 2.0 > >> 4. Submission Date: 8/29/2007 > >> 5. Proposal type: modify > >> 6. Policy term: permanent > >> 7. Policy statement: > >> > >> Change I: > >> > >> In section 6.5.1.1.d, replace the existing statement with the new > >> statement: > >> > >> "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." > >> > >> Change J: > >> > >> Remove section 6.5.3 entirely. Update all subsequent sections to > >> have new section numbers (6.5.[n-1]). > >> > >> Replace part of the text as (new) section 6.5.4.4: > >> > >> "All /56 and larger assignments to end sites are required to be > >> registered either by the LIR or its subordinate ISPs in > >> such a way that the RIR/NIR can properly evaluate the > >> HD-Ratio when a subsequent allocation becomes necessary." > >> > >> Change K: > >> > >> Section 6.5.8.2, add the following sentence to the end of the first > >> paragraph: > >> > >> "An HD-Ratio of .94 must be met for all assignments larger than > >> a /48." > >> > >> Add to the end of the second paragraph: > >> > >> "This reservation may be assigned to other organizations > >> later, at ARIN's discretion." > >> > >> Change L: > >> > >> Section 6.5.8.3, add a sentence between the two existing sentences: > >> > >> "Justification will be determined based on the .94 HD-Ratio > >> metric." > >> > >> 8. Rationale: > >> > >> When the IPv6 policy was passed, it was considered to be an "interim" > >> policy, and it was intended to be similar in all 5 RIR's. Since that > >> time it has become clear the policy is no longer interim (and proposal > >> 2007-4 was passed to change just that) and it has also been modified > >> separately in the different RIR's. > >> > >> It was brought to the ARIN AC's attention that there were a number of > >> problems with "Section 6" of the NRPM as a result of this legacy: > >> > >> * The policy contained a large number of items that were not policy. > >> * The policy contained a few items that were self contradictory. > >> * The added text was redundant in some cases with existing text. > >> * The policy was overly vague in a few areas, leaving ARIN staff to > >> have to make interpretations of what the policy intended. > >> * Policy changes made since the initial IPv6 policy was adopted have > >> not always updated all of the relevant sections due to the complexity > >> of section 6. > >> > >> The intent of these changes is not to change any existing policy, but > >> rather to remove all non-policy items, and update any ambiguous items > >> with the way that ARIN staff is currently interprets the policy. > >> > >> Change I: > >> > >> Proposal 2005-8 amended section 6.5.4.1 to allow /56 and /64 > >> allocations, but section 6.5.1.1.d was never updated to match > >> the change. It is believed the intent of the policy, and ARIN > >> staff's current interpretation of the policy match the updated > >> text. > >> > >> Change J: > >> > >> The first part is not policy, and incorrectly states there is no > >> policy as section 6.5.4 has the policy in it. Take the one useful > >> part and make it part of the 6.5.4 criteria. > >> > >> Change K: > >> > >> No metric is currently listed to justify a larger initial > >> assignment. It is believed ARIN staff is currently applying > >> the HD-Ratio similar to the ISP policy, this puts that in writing. > >> > >> Make it clear that the reservation may not exist in perpetuity. > >> > >> Change L: > >> > >> No metric is given to justify additional assignments. It is > >> believed that ARIN staff is currently applying the HD_Ratio > >> similar to the ISP policy, this puts that in writing. > >> > >> 9. Timetable for implementation: Immediate. > >> 10. Meeting presenter: Leo Bicknell > >> > >> END OF TEMPLATE > >> > >> > >> 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 Policy Housekeeping > >>> > >>> Author: Leo Bicknell > >>> > >>> Proposal Version: 1.0 > >>> > >>> Submission Date: 8/17/2007 > >>> > >>> Proposal type: modify > >>> > >>> Policy term: permanent > >>> > >>> Policy statement: > >>> > >>> Change A: > >>> > >>> Remove the text between the section 6 header and the section 6.1 > >>> header. Remove section 6.1 entirely. Update all subsequent > >>> sections to have new section numbers (6.[n-1]). > >>> > >>> Change B: > >>> > >>> Move the image in section 6.2 to section 2. > >>> > >>> Remove sections 6.2.1 to 6.2.6. > >>> > >>> Change C: > >>> > >>> Move section 6.2.7 to (new) section 2.8, subheading "IPv6". > >>> > >>> Create section 2.8, subheading "IPv4", containing the following text: > >>> > >>> In IPv4, utilization is the percentage of the address space > >>> allocated or assigned relative to the total address space. > >>> > >>> Change D: > >>> > >>> Move section 6.2.8 to (new) section 2.8. > >>> Move section 6.2.9 to (new) section 2.9. > >>> > >>> As this leaves section 6.2 empty, remove section 6.2. Update > >>> all subsequent sections to have new section numbers (6.[n-1]). > >>> > >>> > >>> Change E: > >>> > >>> Remove section 6.3. Update all subsequent sections to have new > >>> section numbers (6.[n-1]). > >>> > >>> Change F: > >>> > >>> Remove section 6.4.1. Update all subsequent sections to have new > >>> section numbers (6.4.[n-1]). > >>> > >>> Change G: > >>> > >>> Remove section 6.4.2. Update all subsequent sections to have new > >>> section numbers (6.4.[n-1]). > >>> > >>> Change H: > >>> > >>> Remove section 6.4.4. > >>> > >>> Change I: > >>> > >>> In section 6.5.1.1.d, replace the existing statement with the new > >>> statement: > >>> > >>> "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." > >>> > >>> Change J: > >>> > >>> Remove section 6.5.3 entirely. Update all subsequent sections to > >>> have new section numbers (6.5.[n-1]). > >>> > >>> Replace part of the text as (new) section 6.5.4.4: > >>> > >>> "All /56 and larger assignments to end sites are required to be > >>> registered either by the LIR or its subordinate ISPs in > >>> such a way that the RIR/NIR can properly evaluate the > >>> HD-Ratio when a subsequent allocation becomes necessary." > >>> > >>> Change K: > >>> > >>> Section 6.5.8.2, add the following sentence to the end of the first > >>> paragraph: > >>> > >>> "An HD-Ratio of .94 must be met for all assignments larger than > >>> a /48." > >>> > >>> Add to the end of the second paragraph: > >>> > >>> "This reservation may be assigned to other organizations > >>> later, at ARIN's discretion." > >>> > >>> Change L: > >>> > >>> Section 6.5.8.3, add a sentence between the two existing sentences: > >>> > >>> "Justification will be determined based on the .94 HD-Ratio > >>> metric." > >>> > >>> Change M: > >>> > >>> Remove section 6.6. Update all subsequent sections to have new > >>> section numbers (6.[n-1]). > >>> > >>> Change N: > >>> > >>> Change the title of section 6.7 from "Appendix A: HD-Ratio" to > >>> "HD-Ratio". > >>> > >>> Change O: > >>> > >>> Remove section 6.8. Update all subsequent sections to have new > >>> section numbers (6.[n-1]). > >>> > >>> Rationale: > >>> > >>> When the IPv6 policy was passed, it was considered to be an "interim" > >>> policy, and it was intended to be similar in all 5 RIR's. Since that > >>> time it has become clear the policy is no longer interim (and proposal > >>> 2007-4 was passed to change just that) and it has also been modified > >>> separately in the different RIR's. > >>> > >>> It was brought to the ARIN AC's attention that there were a number of > >>> problems with "Section 6" of the NRPM as a result of this legacy: > >>> > >>> * The policy contained a large number of items that were not policy. > >>> * The policy contained a few items that were self contradictory. > >>> * The added text was redundant in some cases with existing text. > >>> * The policy was overly vague in a few areas, leaving ARIN staff to > >>> have to make interpretations of what the policy intended. > >>> * Policy changes made since the initial IPv6 policy was adopted have > >>> not always updated all of the relevant sections due to the complexity > >>> of section 6. > >>> > >>> The intent of these changes is not to change any existing policy, but > >>> rather to remove all non-policy items, and update any ambiguous items > >>> with the way that ARIN staff is currently interprets the policy. > >>> > >>> Change A: > >>> > >>> Not policy. Unnecessary. Confusing (policy is interim). > >>> > >>> Change B: > >>> > >>> Sections 6.2.1 to 6.2.6 are definitions that are already defined in > >>> section 2.1 to 2.7 Repeating them here is unnecessary. The picture > >>> is useful though, and should be moved to section 2 as part of the > >>> definitions. > >>> > >>> Change C: > >>> > >>> This is a definition item, and should be in the definition section. > >>> Also, the v4 versions should be defined at the same time. > >>> > >>> Change D: > >>> > >>> These are both definitions that should be in the definitions section. > >>> > >>> Change E: > >>> > >>> This is a manifesto, and is not address policy. If anything these > >>> belong is ARIN's mission statement. > >>> > >>> Change F: > >>> > >>> Not policy; covered by the RSA as a legal matter. > >>> > >>> Change G: > >>> > >>> Not policy. A darn good warning though ARIN should include with > >>> any other boilerplate when issuing address space. > >>> > >>> Change H: > >>> > >>> Not policy, and covered by actual policy statement 6.5.1.2. > >>> > >>> Change I: > >>> > >>> Proposal 2005-8 amended section 6.5.4.1 to allow /56 and /64 > >>> allocations, but section 6.5.1.1.d was never updated to match > >>> the change. It is believed the intent of the policy, and ARIN > >>> staff's current interpretation of the policy match the updated > >>> text. > >>> > >>> Change J: > >>> > >>> The first part is not policy, and incorrectly states there is no > >>> policy as section 6.5.4 has the policy in it. Take the one useful > >>> part and make it part of the 6.5.4 criteria. > >>> > >>> Change K: > >>> > >>> No metric is currently listed to justify a larger initial > >>> assignment. It is believed ARIN staff is currently applying > >>> the HD-Ratio similar to the ISP policy, this puts that in writing. > >>> > >>> Make it clear that the reservation may not exist in perpetuity. > >>> > >>> Change L: > >>> > >>> No metric is given to justify additional assignments. It is > >>> believed that ARIN staff is currently applying the HD_Ratio > >>> similar to the ISP policy, this puts that in writing. > >>> > >>> Change M: > >>> > >>> References, while useful on the web page and in template instructions > >>> are not policy. > >>> > >>> Change N: > >>> > >>> It's not an appendix. It's not even at the end. > >>> > >>> Change O: > >>> > >>> The background information would be something nice to archive on the > >>> ARIN web site somewhere, but is not policy and should be removed from > >>> the policy manual. > >>> > >>> 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. > >>> > >>> > >> _______________________________________________ > >> 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. > >> > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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. > > > _______________________________________________ > 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 iljitsch at muada.com Fri Aug 31 16:10:46 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 31 Aug 2007 22:10:46 +0200 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationingof IPv4 IP Addresses In-Reply-To: References: <85975A4A-0077-4B71-B303-FD9FE27615F6@muada.com> Message-ID: <8CC5B9B8-FB3D-4C7F-BD6B-089E31979FAD@muada.com> On 31-aug-2007, at 16:55, wrote: >> The only thing that looks pretty solid is that >> there's almost always growth in the number of addresses used >> up per year. Anything else only persists for a few years and >> then changes. > Those things that persist for a few years are the trends. A few = generally 2 or 3 years. Is that enough to call a trend? > And the > changes have been explained due to macro events (CIDR introduction, > telecoms collapse) so even though the trends go through step changes, > they are still trends. If you can tell the trends from the macro events, please do so because as far as I know, nobody else has been able to. > One could still do a worst-case scenario based on > the pre telecoms collapse trend I guess that would be going from 86 million in 2001 to 69 million in 2002. > and then estimate the probability that > macroeconomic events will lead to that scenario. You then have an > estimated runout date, and a probability that it will occur. Worst case that we've seen is almost doubling from 43 million new addresses in 1999 to 81 million in 2000. Perspective: 1998 was 60 and 2001 86 million. You can arrive at pretty much any outcome by just selecting the right start date. From 98 million in 1996 to 170 in 2006 is 5.7% growth per year but starting in 1999 results in 21.7% and 2002 25.3%. Now if all of this had been going on for 100 or even 30 years it would probably be possible to see a long-year trend. But 1995 was the first year with growth after the introduction of CIDR so we only have 12 years. It's just not enough to come up with something better than 5 - 25 % growth per year = running out between Q3 2011 and Q3 2013. However, you can't predict a run on the bank, hoarding and all kinds of other interesting end games by looking at the past. > There are some very learned people who have spent their entire life > studying forecasting methodology. If someone were to point out > flaws in > Tony's or Geoff's methodology based on the published literature, that > would be valuable. I would also expect Tony and Geoff to fix those > flaws. Let me put it this way: would either of them care to publish an error margin to go along with their prediction? Or run the numbers on historical data and see how well the predictions fit what actually happened? > I was hoping that someone like you would take up the > challenge of finding another data source and producing yet another > forecast. I don't think there's another source of data. However, if you want I can split the difference between Q3 2011 and Q3 2013, which brings us back to my "London olympics" prediction from a few days ago. > It's easy to wave your hands and be a sceptic but that doesn't lead us > anywhere. Who says we're going anywhere, and if we are, whether we're actually getting there? :-) From iljitsch at muada.com Fri Aug 31 16:11:52 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 31 Aug 2007 22:11:52 +0200 Subject: [ppml] IPv6 flawed? In-Reply-To: <4F2DB929-C3C4-475B-BAF6-7B6616FDC778@virtualized.org> References: <200708311233.l7VCXYBj005107@cjbsys.bdb.com> <82435.1188567258@sa.vix.com> <6F089EC1-589B-4192-AE7E-9DAC2BE6ACC4@virtualized.org> <4F2DB929-C3C4-475B-BAF6-7B6616FDC778@virtualized.org> Message-ID: On 31-aug-2007, at 21:36, David Conrad wrote: > Discussions about my personal views of how the IPv6 architecture is > flawed probably aren't appropriate for the ARIN PPML list. They are if you're going to base your views about ARIN policies on them. From drc at virtualized.org Fri Aug 31 16:42:18 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 31 Aug 2007 13:42:18 -0700 Subject: [ppml] Policy Proposal 2007-15: Authentication of Legacy Resources - version 1.1 In-Reply-To: <46D84DDF.1030609@arin.net> References: <46A65981.90004@arin.net> <46D84DDF.1030609@arin.net> Message-ID: <740C7468-EFA0-4219-B6B0-D2D3C3803E4B@virtualized.org> On Aug 31, 2007, at 10:20 AM, Member Services wrote: > 1. Policy Proposal Name: Authentication of Legacy Resources > No changes shall be made to legacy resource records which are not > covered by a registration services agreement after December 31, 2007. I suspect that refusal to update registration information will likely not be very popular with folks trying to fight spam, phishing, fraud, etc. It could also have the effect of spurring the establishment of alternative registries that maintain "accurate" information. Regards, -drc From sleibrand at internap.com Fri Aug 31 16:54:16 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 31 Aug 2007 13:54:16 -0700 Subject: [ppml] Policy Proposal 2007-15: Authentication of Legacy Resources - version 1.1 In-Reply-To: <740C7468-EFA0-4219-B6B0-D2D3C3803E4B@virtualized.org> References: <46A65981.90004@arin.net> <46D84DDF.1030609@arin.net> <740C7468-EFA0-4219-B6B0-D2D3C3803E4B@virtualized.org> Message-ID: <46D87FF8.3020407@internap.com> David Conrad wrote: > On Aug 31, 2007, at 10:20 AM, Member Services wrote: > >> 1. Policy Proposal Name: Authentication of Legacy Resources >> No changes shall be made to legacy resource records which are not >> covered by a registration services agreement after December 31, 2007. >> > > I suspect that refusal to update registration information will likely > not be very popular with folks trying to fight spam, phishing, fraud, > etc. It could also have the effect of spurring the establishment of > alternative registries that maintain "accurate" information. Is requiring registrants to sign a contract that codifies their rights and responsibilities "refusal"? I don't see the requirements here as at all onerous, and wouldn't see alternate registries as viable. As an ISP, if a customer asked me to route space based on the information in some alternate registry because they were unwilling to sign an RSA and pay ARIN $100/year, I would consider that suspicious enough to have another abuse scrub run on the customer, and refuse to route the space. -Scott From Keith at jcc.com Fri Aug 31 17:47:50 2007 From: Keith at jcc.com (Keith W. Hare) Date: Fri, 31 Aug 2007 17:47:50 -0400 Subject: [ppml] Policy Proposal 2007-15: Authentication of Legacy Resources - version 1.1 Message-ID: <59bca099a787ac5b0479b5655fda49b446d88cd4@jcc.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Scott Leibrand > Sent: Friday, August 31, 2007 4:54 PM > To: David Conrad > Cc: Public Policy Mailing List > Subject: Re: [ppml] Policy Proposal 2007-15: Authentication > of Legacy Resources - version 1.1 > > David Conrad wrote: > > On Aug 31, 2007, at 10:20 AM, Member Services wrote: > > > >> 1. Policy Proposal Name: Authentication of Legacy Resources > >> No changes shall be made to legacy resource records which are not > >> covered by a registration services agreement after > December 31, 2007. > >> > > > > I suspect that refusal to update registration information > will likely > > not be very popular with folks trying to fight spam, > phishing, fraud, > > etc. It could also have the effect of spurring the > establishment of > > alternative registries that maintain "accurate" information. > > Is requiring registrants to sign a contract that codifies > their rights > and responsibilities "refusal"? I don't see the requirements > here as at > all onerous, and wouldn't see alternate registries as viable. As an > ISP, if a customer asked me to route space based on the > information in > some alternate registry because they were unwilling to sign > an RSA and > pay ARIN $100/year, I would consider that suspicious enough to have > another abuse scrub run on the customer, and refuse to route > the space. By the time the RSA for legacy resource holders is available, and ARIN starts an outreach to legacy resoure holders, it is going to be December, 2007. How about saying "No changes shall be made to legacy resource records which are not covered by a registration services agreement after December 31, 2008." This gives another year for the RSA and the outreach and for legacy resource holders to work whatever fees through what ever budget processes and the RSA through whatever legal review. Keith Hare ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ From sleibrand at internap.com Fri Aug 31 17:57:32 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 31 Aug 2007 14:57:32 -0700 Subject: [ppml] Policy Proposal 2007-15: Authentication of Legacy Resources - version 1.1 In-Reply-To: <59bca099a787ac5b0479b5655fda49b446d88c87@jcc.com> References: <59bca099a787ac5b0479b5655fda49b446d88c87@jcc.com> Message-ID: <46D88ECC.6070300@internap.com> Keith W. Hare wrote: > By the time the RSA for legacy resource holders is available, and ARIN > starts an outreach to legacy resoure holders, it is going to be > December, 2007. > The policy states that the RSA should be ready on January 1, 2008. If that doesn't happen until December, then the following section of the policy proposal will apply: > If this policy is > implemented after December 31, 2007, the trigger dates in the policy > should be adjusted appropriately. The intent of the policy proposal is to provide 1 year from the date the RSA becomes available and the date that it becomes required for all updates to legacy registrations. > How about saying "No changes shall be made to legacy resource records > which are not covered by a registration services agreement after > December 31, 2008." > > This gives another year for the RSA and the outreach and for legacy > resource holders to work whatever fees through what ever budget > processes and the RSA through whatever legal review. Are you worried that less than a year would be provided (the concern I addressed above), or that legacy resource record holders need more than a year to get an RSA signed? -Scott From drc at virtualized.org Fri Aug 31 18:08:24 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 31 Aug 2007 15:08:24 -0700 Subject: [ppml] Policy Proposal 2007-15: Authentication of Legacy Resources - version 1.1 In-Reply-To: <46D87FF8.3020407@internap.com> References: <46A65981.90004@arin.net> <46D84DDF.1030609@arin.net> <740C7468-EFA0-4219-B6B0-D2D3C3803E4B@virtualized.org> <46D87FF8.3020407@internap.com> Message-ID: <3051F6B1-1ADA-42E9-8C08-034DBAE1FE8B@virtualized.org> Scott, On Aug 31, 2007, at 1:54 PM, Scott Leibrand wrote: > David Conrad wrote: >> On Aug 31, 2007, at 10:20 AM, Member Services wrote: >> >>> 1. Policy Proposal Name: Authentication of Legacy Resources >>> No changes shall be made to legacy resource records which are not >>> covered by a registration services agreement after December 31, >>> 2007. >> >> I suspect that refusal to update registration information will >> likely not be very popular with folks trying to fight spam, >> phishing, fraud, etc. It could also have the effect of spurring >> the establishment of alternative registries that maintain >> "accurate" information. > > Is requiring registrants to sign a contract that codifies their > rights and responsibilities "refusal"? Refusing to update registration information would be... well... refusal. > I don't see the requirements here as at all onerous, and wouldn't > see alternate registries as viable. But you're part of the ARIN community (as evidenced by your participation on this list) so neither of these are particularly surprising. You're talking about folks who, for the most part, aren't and have little to no incentive to change that. They might have a different view. > As an ISP, if a customer asked me to route space based on the > information in some alternate registry because they were unwilling > to sign an RSA and pay ARIN $100/year, I would consider that > suspicious enough to have another abuse scrub run on the customer, > and refuse to route the space. And they'd go someplace else (e.g., perhaps the same place that is originating the ridiculously bouncey prefixes out of AS14906 and AS14201). You're out the revenue, the prefix still gets announced, and folks trying to track down spam, phishing, fraud, etc. have more trouble trying to track down who to point the authorities (or whatever) at. Who wins? Regards, -drc P.S. I remember when domains went from $0 to $100 per year and the ruckus that caused. And I also see how things are now. Not sure this is a direction the RIRs will want to go... From bicknell at ufp.org Fri Aug 31 15:22:09 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 31 Aug 2007 15:22:09 -0400 Subject: [ppml] Policy Proposal: Definition of known ISP and changes to In-Reply-To: <82435.1188567258@sa.vix.com> References: <200708311233.l7VCXYBj005107@cjbsys.bdb.com> <82435.1188567258@sa.vix.com> Message-ID: <20070831192209.GB43118@ussenterprise.ufp.org> In a message written on Fri, Aug 31, 2007 at 01:34:18PM +0000, Paul Vixie wrote: > the important observation is that ipv4 its start through a swamp and if we > want ipv6 to get a start we might have to allow a swamp also. remembering > that the ipv4 swamp used to be a huge portion of the total ipv4 table, the > most recent couple hundred thousand prefixes added have dwarfed the swamp. Emphasis on the "might". I've thought long and hard about the "recreate the swamp" issue. At this point I think both sides of the coin have equal arguments. In the "pro new swamp camp": - It gives early adopters a way to get in without having to get the big wheels of their company churning. An individual or research group can get a small block to play with and not have to disturb marketing for a full roll out plan. - It provides a mechanism for the network to organically grow. Interesting parties will dual stack simply because they can. - At the end of the day it will end up being a small number of routes. In the "con new swamp camp": - Organic growth is not the issue this time. We're not trying to create something new, but rather transition to something different. - Most businesses have been able to get a /32 for a few years for free and it hasn't made a difference, why will giving out /48's (/56's, /64's, whatever) make any difference? - We had the 6bone as a place for eary adopters to experiment. (Did it go away too soon?) - We're trying to do something better this time around than we did last time. - Addresses are not part of the problem. I also think there are two arguments that frequently get mixed up. Several people have argued "anyone who has PI now should be able to get PI in v6", and others have argued "we need to give out IPv6 to anyone who wants it." The latter is "recreating the swamp" in my opinion. The former does not have to have the same effect. Somewhere between 25-50% of the "swamp" prefixes are not routed today, depending on your view. I think it's possible to give everyone who has PI today PI in IPv6 without creating all of these latent unused allocations which may pop up far in the future (e.g. as may happen in IPv4, if they get value). I think the last part in the con category is the most interesting to me. I'm not sure it's completely true, but there is some truth about it. There have been many long discussions on PPML of "my router can't hold that many prefixes" or "we have no money to upgrade gear to IPv6" or "I can't get the manpower to transition before it's needed", etc. All of these are business reasons people can't get IPv6 out the door, and most of the people making these arguments have IPv6 addressing! -- 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 iljitsch at muada.com Fri Aug 31 19:05:36 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sat, 1 Sep 2007 01:05:36 +0200 Subject: [ppml] [address-policy-wg] Re: IPv6 addresses really are scarce after all In-Reply-To: References: <46C613E0.8010909@bogus.com> <46C629D2.20009@cs.utk.edu> <17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com> <46C6B5BB.5000203@cs.utk.edu> <200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <46D05897.5010906@cs.utk.edu> <59D5CFF02CEE1D3C96D66409@p3.JCK.COM> Message-ID: On 31-aug-2007, at 17:31, wrote: > I still have not seen > any clear indication that there is a negative technical impact of > assigning a /56 per home. Then you haven't been paying attention, I've been saying /56 is the wrong size for some time now. > To date, the only clear technical issue I have > seen mentioned for subnet prefixes longer than /48 is that if they are > not on a 4-bit hex nibble boundary, it makes IPv6 PTR delegation more > complex. Then you have to delegate 2, 4 or 8 zones rather than 1, big deal. From dean at av8.com Fri Aug 31 19:06:55 2007 From: dean at av8.com (Dean Anderson) Date: Fri, 31 Aug 2007 19:06:55 -0400 (EDT) Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses In-Reply-To: <85975A4A-0077-4B71-B303-FD9FE27615F6@muada.com> Message-ID: On Fri, 31 Aug 2007, Iljitsch van Beijnum wrote: > On 31-aug-2007, at 1:24, Dean Anderson wrote: > > >>> Aug 4, shows April 16th, 2010. Tony Hain now says April 2010. > > >> And I say during the London summer olympics. > > > Ok. Except that you are just pulling your number out of your hat. The > > other two use some math to compute the rate and compute the remaining > > address space. > > It's not that simple. It is that simple: Your claim "no trend" is an assertion which isn't based on any fact. You've made no study, no statistical calculation (which could show 'no trend'), nor anything else to support your claims. In otherwords, You have no basis for disputing their claim. > Tony and Geoff take their assumptions (why use the last 1095 days and > 1250 or 943?) and put them into formulas which then produce results > with many digits after the decimal point. You are free to recalculate their results using different periods. However, using different periods may not produce greatly different results. It would of course be interesting if it did. I'm looking into some things, but I have nothing to report yet. > I take several possibilities, see where they lead and then try to come > up with something that seems reasonable based on my interpretation of > the past. > > Tony and Geoff's approach would probably be better at projecting a > trend into the future, That's the goal of their work... The rest of this doesn't seem to be going anywhere that is in anyway relevant to rationing policy for IPv4, and no one else seems to be interested in debating these issues. I look forward to debating them again sometime. Have a good weekend. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From cliffb at cjbsys.bdb.com Fri Aug 31 21:03:07 2007 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Fri, 31 Aug 2007 21:03:07 -0400 (EDT) Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with In-Reply-To: <46D85227.3050206@internap.com> from "Scott Leibrand" at Aug 31, 2007 10:38:47 AM Message-ID: <200709010103.l81138Vk008834@cjbsys.bdb.com> > > Cliff Bedore wrote: > > It would not work for me. I am not multi-homed. I have a single DSL line to > > my upstream provider. I know in the best of all worlds I would be but I'm not > > now. I think the problem is that there are a fair number of legacy people who > > are like me. They are probably /24s since that was what was given if you > > coouldn't justify a /16. > > > > Ok. In that case, would you be able to route an IPv6 PI block if you > got one? Is the inability to get IPv6 PI space holding you back from > adopting IPv6? Frankly, I'm sure I'll be at least semi-retired and maybe dead before IPv4 disappears. ( and while I'm 60, my folks are 90 and my grandmother will be 107 in September so we're looking at a long time. :-) ) I would have to get my current upstream ISP to start routing IPv6 and their comment so far has been "We'll be ready when IPv6 gets here". I'm simply willing to start looking at v6 and start a push from the bottom to get v6 adopted and available. If ARIN has no desire to give legacy v4 holders such as me IPv6 space, I'll just stay with v4 and give up trying to keep up with the PPML mailing list. > > I'm sure there are legacy /24 holders who wouldn't be able to get IPv6 > PI space under this proposal, but what I'm really trying to address are > people for whom that is holding them back from adopting IPv6. > > -Scott > -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From cliffb at cjbsys.bdb.com Fri Aug 31 21:36:13 2007 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Fri, 31 Aug 2007 21:36:13 -0400 (EDT) Subject: [ppml] Policy Proposal 2007-15: Authentication of Legacy In-Reply-To: <3c3e3fca0708311109k72dc15fbicf62f04eff9d32cb@mail.gmail.com> from "William Herrin" at Aug 31, 2007 02:09:23 PM Message-ID: <200709010136.l811aD0e009016@cjbsys.bdb.com> > > On 8/31/07, Member Services wrote: > > 1. Policy Proposal Name: Authentication of Legacy Resources > > > No changes shall be made to legacy resource records which are not > > covered by a registration services agreement after December 31, 2007. > I also oppose this proposal. I agree with Bill's thoughts below. Frankly, I don't think ARIN has the authority to require an RSA from legacy holders and I think it would be a waste of ARIN resources to fight any attempt to change legacy records. Remember that "IPv4 is going away" and "IPv6 is the future". Spending time on things such as forcing an RSA on legacy users not already covered is like rearranging the deck chairs on the Titanic. Note that I am not at all convinced that IPv6 is going to replace IPv4 any time in the near and probably far future based on what I read here. However ARIN's charter seems to require that they work to get it adopted and the community would be better served if they worked toward positive actions rather than punitive/negative actions. Cliff > I still oppose this. The time for punitive measures (however minor) > against folks who registered IP addresses prior to ARIN's existence > has not yet arrived and probably never will. > > If you absolutely must do something to give the outreach some teeth, > consider something like this: > > "Changes to legacy resource records not covered by a registration > services agreement after December 31, 2008 shall be made only if the > registrant can be authenticated via electronic mail to an existing POC > email address." > > That addresses ARIN's legitimate need for valid contact info without > breaching the duty ARIN acknowledged and took on itself when it > accepted authority for the legacy /8's. > > Regards, > Bill Herrin > > > > > -- > William D. Herrin herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. Web: > Falls Church, VA 22042-3004 > _______________________________________________ > 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. > -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From owen at delong.com Fri Aug 31 22:55:48 2007 From: owen at delong.com (Owen DeLong) Date: Fri, 31 Aug 2007 19:55:48 -0700 Subject: [ppml] Policy Proposal 2007-15: Authentication of Legacy Resources - version 1.1 In-Reply-To: <46D84DDF.1030609@arin.net> References: <46A65981.90004@arin.net> <46D84DDF.1030609@arin.net> Message-ID: <5C388AF7-4223-4892-BF47-71F88A1EA6BA@delong.com> I still oppose this policy. It implies that ARIN has some authority to force legacy holders into an RSA. I do not believe it is in the ARIN community's interest to discontinue updates to whois for legacy holders who choose not to sign an RSA. I do believe we should provide whatever encouragement and incentives we can towards getting legacy holders to sign an RSA. Owen From Lee at Dilkie.com Fri Aug 31 23:10:50 2007 From: Lee at Dilkie.com (Lee Dilkie) Date: Fri, 31 Aug 2007 23:10:50 -0400 Subject: [ppml] Legacy /24s In-Reply-To: <859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local> References: <859D2283FD04CA44986CC058E06598F84B1D9AA7AC@exchange4.exchange.alphared.local> Message-ID: <46D8D83A.7020306@Dilkie.com> What? no restrictive RSA? no outrageous $100/yr scalper fee? no justification of usage? You're daft man! A common sense proposal like this has no place on ppml. {pardon my sarcasm, been here too long I guess. But being a /24 legacy holder in the same shoes as probably many, this would fit the bill but I wouldn't hold my breath} -lee mack wrote: > I don't have the time to write it but I would support a > proposal that gives legacy /24 holders a permanent IPv4 fee waiver, > an efficient usage waiver so that they don't have to worry about reclamation, > and allows assignment of an appropriate sized block of IPv6 if they > start paying a fee after some specified date (ie. Jan 1, 2010) or whenever > the regular IPv6 waiver expires if it is extended beyond this date. > With the only contingency that the space be actively used in the DFZ > or showing that the space is in use in a manner that cannot be readily > replaced by 1918 space. > > I personally feel that the /24 space needs to be handled differently than > the /16 and /8 space. > > 1) Because there are more of these than the others numerically. > 2) Because there is no significant reclamation benefit if they are being used. > 3) Most of these are individuals or small companies that don't have significant resources. > > The use contingency allows for private use in organizations that may find > it difficult to convert to 1918 space. > > This would be neutral in overall effect. It cost them nothing unless they want IPv6 space. > It will encourage adoption of IPv6 by these users. It will move a significant number of > legacy blocks under a policy umbrella. > > This obviously would be for the 2008 timeframe. > > > LR Mack McBride > Network Administrator > Alpha Red, Inc. > _______________________________________________ > 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 celestea at usc.edu Fri Aug 31 23:16:23 2007 From: celestea at usc.edu (Celeste Anderson) Date: Fri, 31 Aug 2007 20:16:23 -0700 Subject: [ppml] Policy Proposal 2007-15: Authentication of Legacy Resources - version 1.1 In-Reply-To: <5C388AF7-4223-4892-BF47-71F88A1EA6BA@delong.com> References: <46A65981.90004@arin.net> <46D84DDF.1030609@arin.net> <5C388AF7-4223-4892-BF47-71F88A1EA6BA@delong.com> Message-ID: I concur with Owen. Celeste. ----- Original Message ----- From: Owen DeLong Date: Friday, August 31, 2007 7:54 pm Subject: Re: [ppml] Policy Proposal 2007-15: Authentication of Legacy Resources - version 1.1 To: Member Services Cc: ppml at arin.net > I still oppose this policy. It implies that ARIN has some > authority > to force > legacy holders into an RSA. I do not believe it is in the ARIN > community's > interest to discontinue updates to whois for legacy holders who choose > not to sign an RSA. I do believe we should provide whatever > encouragement > and incentives we can towards getting legacy holders to sign an RSA. > > Owen > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: celestea.vcf Type: text/x-vcard Size: 294 bytes Desc: Card for Celeste Anderson URL: