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