From info at arin.net Mon Mar 3 13:41:02 2008 From: info at arin.net (Member Services) Date: Mon, 03 Mar 2008 13:41:02 -0500 Subject: [ppml] =?windows-1252?q?ARIN_XXI=3A_It_Won=92t_Be_The_Same_Withou?= =?windows-1252?q?t_You!?= Message-ID: <47CC463E.9070609@arin.net> We are looking forward to the ARIN XXI Public Policy and Members Meeting, taking place 6-9 April 2008, in Denver, Colorado, and we hope you are too. Come be a part of the community in action, and don?t let your voice go unheard! Register today to take advantage of the early registration fee of $100. It increases to $150 on 24 March. The meeting will take place at the Grand Hyatt Denver. ARIN XXI attendees are eligible for a special room rate of $189 (USD), based on availability, if reservations are made before 14 March. In addition to the Public Policy and Members Meeting, there will be a number of informative events, including a session on Sunday, 6 April entitled ?Understanding ARIN?s Legacy Registration Services Agreement? presented by ARIN General Counsel Steven M. Ryan. Other Sunday activities include a luncheon for first time ARIN meeting attendees, the Open Policy Hour, and the 9th Annual Foosball Tournament. Immediately preceding the Open Policy Hour, there will also be a brief session offering an introduction to the ARIN policy development process. Hotel and travel information, meeting registration, and an agenda overview are available through http://www.arin.net/ARIN-XXI/. A more detailed agenda will be posted as we get closer to the meeting. As always, please contact ARIN Member Services at info at arin.net with any questions. We look forward to seeing you in Denver! Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Tue Mar 4 11:06:51 2008 From: info at arin.net (Member Services) Date: Tue, 04 Mar 2008 11:06:51 -0500 Subject: [ppml] Policy Proposal 2008-3: Community Networks IPv6 Allocation Message-ID: <47CD739B.3060905@arin.net> On 21 February 2008, the ARIN Advisory Council (AC) concluded its review of "Community Networks IPv6 Allocation" and accepted it as a formal policy proposal with the condition that the policy text be revised by the author so that it can be put into the ARIN Number Resource Policy Manual. The author submitted a revised version of the proposal. The proposal is designated Policy Proposal 2008-3: Community Networks IPv6 Allocation. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2008_3.html All persons in the community are encouraged to discuss Policy Proposal 2008-3 prior to it being presented at the upcoming ARIN XXI Public Policy Meeting. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2008-3 Community Networks IPv6 Allocation Author: Joshua King Proposal Version: 1 Date: 4 March 2008 Proposal type: new Policy term: permanent Policy statement: [Add Section 2.8 to the NRPM.] 2.8 Community Network A community network is a generic reference to any network that is operated by a group of people living in a particular local area organized for the purposes of delivery or provision of network services to the residents of an incorporated or unincorporated regional municipality, city, town, village, rural municipality, township, county, district or other municipality or other such geographic space, however designated. [Modify 6.5.8.1b as follows.] b. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect or be a Community Network as defined in Section 2.8. Rationale: There are currently a number of projects globally that aim to develop community network infrastructure and related technologies. These are usually coordinated by volunteer-run, grassroots organizations which lack many of the resources of traditional internet service providers and other network operators. They have diverse goals, including public policy, software development, and implementation of community services and resources. Many of them provide services free of charge, and thus lack any paying user base. However, in order to create and maintain community networks that are often composed of hundreds if not thousands of inexpensive, commodity hosts and devices, a significant amount of address space will be required. Current-generation workarounds to this problem, such as NAT, not only make it difficult to develop next-generation decentralized network technology by segmenting the community's architecture from the Internet as a whole, but will cease to be as viable a stopgap as the Internet moves towards IPv6 integration. Even now, common community networking software solutions such as CUWiNware (http://www.cuwin.net) and Freifunk (http://www.freifunk.at) have nascent IPv6 addressing support, but participating organizations lack the address space for widespread testing or adoption. As such, it is necessary to implement an procedure as soon as possible for these segregated networks to acquire address space. These organizations do not meet the criteria traditionally defined for LIR's, and thus cannot acquire address allocations through existing templates. By establishing a procedure by which these organizations can seek to acquire the resources they require for further development, ARIN can reach out to this active community and establish a small but definite space for them in the future of Internet. Timetable for implementation: Immediate. From sleibrand at internap.com Tue Mar 4 11:49:29 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 04 Mar 2008 08:49:29 -0800 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal Message-ID: <47CD7D99.9000108@internap.com> Jim Weyand wrote (in a message not posted to PPML): > My real concern is that the community has not considered the costs > associated with the proposed constraints. I can dream up a number of > scenarios that may occur. > > > > Scenario 1 > > An ISP has a /16 but determines they really only need a much smaller > block - maybe a /20. They look at the market price for a /16 and > determine that it is a high enough price to put up with the pain of > moving all of their addresses to new space. In an unrestricted market a > /16 is probably worth more than an equivalent number of /20s so the ISP > would be motivated to transfer out the whole /16 and transfer in a /20. > > > > The problem is, under ?Policy Proposal 2008-2: IPv4 Transfer Policy > Proposal?, our ISP cannot acquire new addresses. So, to make the sale, > the /16 gets broken up into pieces and all parties are net losers. The > seller was unable to maximize their profit, the original buyer was > unable to participate in this transaction (because they are prequalified > for a /16) and the routing table is increased. > > > > Scenario 2 > > Our ISP with the /16 thinks they only need a /17. They look at the > market rate for the remaining /17 and think, ?hmmm? that?s pretty > good?. The ISP reasons that they can get cash now and, if they really > need it, they can go buy more addresses later. > > > > The ISP is pretty excited about this idea and investigates what is > involved with transferring out IP Address space under ARIN?s new rules. > They read the rules and realize, down in the fine print, that they can?t > get any more IP Address space for another two years. The risk is too > great and the ISP decides not to transfer out any addresses and the > market price of a /17 is artificially inflated. > > > > The constraints will have real costs ? probably not the kind of costs > that will make the front page of the Wall Street Journal but nonetheless > real costs that will affect ISPs. I agree completely. Perhaps one way to address your concerns would be to look to NRPM section 4.6 Amnesty Requests (http://www.arin.net/policy/nrpm.html#four6), and include text in the transfer policy to accomplish similar objectives. But the more I look at it, the more I wonder if the same objective could be accomplished more simply by striking the words ", or through this Simple Transfer policy" from the condition that "The transferor may not request any IPv4 allocations or assignments from ARIN (through ordinary allocations or assignments, or through this Simple Transfer policy) within the subsequent 24 months." Under the standard transferee conditions, any subsequent requests to receive IPv4 addresses through this Simple Transfer policy would have to be justified and pre-qualified, just as with any other potential transferee. The only thing this doesn't address is the desire to allow someone to get and renumber into a smaller block (say /20) and then transfer their larger block (say /16). Under the current proposed policy, such an organization would be able to keep the first or last /20 out of their /16, and transfer the remaining /17, /18, /19, and /20. While I could see a renumbering being slightly better, I think the existing policy is adequate, so I'm not sure if we need to allow people to renumber into a completely different block, and deal with all the complexities of timing that entails. > I have struggled to fully understand the latter part of Scott?s second > paragraph: > > > > > but that further restricting transferors from > > deaggregating to meet legitimate demand from pre-qualified transferees > > will have a negative effect of increasing the price of small blocks > > while decreasing the price (and supply) of larger blocks. > > > > As I understand this if we make it too difficult to split a block we could: > > 1) Artificially raise the price of smaller blocks since there may be > demand for smaller blocks that cannot be met while there are larger > blocks that sit unused. Yes, that is my main concern. > 2) Unintentionally decrease the supply of larger blocks because a > buyer will look at the lower price of the larger blocks and lobby for an > exemption to the pre-qualification requirement. I hadn't thought of that aspect of it, but yes, that would be another negative consequence of not allowing enough deaggregation. > Do I understand this correctly? > > Assuming I do, isn?t this another argument for not introducing any > market constraints other than minimum block size? Or at least for reducing the number of market constraints. As I outlined above, and in a separate proposed modification under discussion (to allow ARIN discretion to allow enough deaggregation to ensure adequate supply of smaller blocks), I'm open to reconsidering any aspects of the policy that might do more harm than good, and either eliminating or changing those aspects, or introducing compensatory language to deal with the negative side effects. Do you have any feedback on any of the proposals above, or any other suggested improvements? The 30-day cutoff for submissions of revised proposals for Denver is fast approaching. Thanks, Scott > *From: *"Jim Weyand" > > > *Date: *February 29, 2008 9:14:04 AM PST (CA) > > *To: *"arin ppml" > > > *Subject: **Re: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy > Proposal* > > > > Does our economist monitor this list? There is a lot of language in the > rationale section that says that many of the restrictions on trade are > designed to limit speculation. Is speculation worse than living with > the restrictions imposed by this proposal? > > For example one restriction is that if you transfer address space to > another party you may not receive address space for another 24 months. > This means that if you have a nice large block you are prevented from > transferring the entire block to another party and getting a more > suitable block in return. > > This restriction will also artificially increase the "market price" of a > block of addresses since I will only take the risk of running out of > addresses in next 24 months if it is very rewarding. > > I'd like to hear our economist's (Ben?) comments on the cost to the > community of the restrictions v. speculation. > > Even with these restrictions I can support this policy, however I think > it is worthwhile to consider the "hidden" costs associated with these > restrictions. > > -Jim Weyand > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Leo Bicknell > Sent: Friday, February 29, 2008 10:50 AM > To: arin ppml > Subject: Re: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy > Proposal > > In a message written on Fri, Feb 29, 2008 at 10:27:02AM -0500, Cliff > Bedore wrote: > > I think we need to make sure the ARIN attorneys look at this from the > >> standpoint of "How can I beat the system". I expect they are >> > honorable and > > above board and that's probably a disadvantage when trying to ensure > > all the > > i's are dotted and the t's are crossed and the vultures are kept at > > bay. > > The ARIN AC has worked closely with both Steve Ryan, ARIN Council > and Ben Edelman, who many saw at the last meeting for his Economics > background, but in addition to his PhD in economics also has a J.D. > from Harvard Law and is admitted to the Massachusetts Bar. They > both provided significant input that the AC used to better craft > the policy language to strengthen ARIN's legal position were this > policy to be adopted. > > That's not to say they don't have some concerns. Nothing is 100% > in law, particularly when there is limited case law on the subject. > I believe both will be at the Denver meeting able to answer questions > about legal risk. As with all policies, ARIN Council will generate > a legal review of the policy prior to the meeting which should both > be posted to PPML and reviewed at the meeting. > > I strongly urge anyone with legal concerns to either come to Denver, > or participate remotely. > > -- > Leo Bicknell - bicknell at ufp.org - > CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the > ARIN Public Policy > Mailing List (PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. > > > From owen at delong.com Tue Mar 4 12:27:09 2008 From: owen at delong.com (Owen DeLong) Date: Tue, 4 Mar 2008 09:27:09 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF Message-ID: As most of you already know, members of the ARIN AC conducted a BoF session at NANOG 42 to try and gather additional community feedback about IPv4 Exhaustion, and, specifically, the AC Authored IPv4 transfer policy. Due to last minute scheduling, the BoF was held at a time which conflicted with the Peering BoF and the IPv6 Tutorial. Despite these conflicts, the BoF was surprisingly well attended and we were able to have a good and productive discussion. Early in the discussion, it was discovered that most present had not come to a clear understanding of the Transfer Policy Proposal. Some explanation and clarification was provided by various members of the AC. Some key provisions that were discussed were: + Requirement for both parties in a transfer to sign an RSA This is in keeping with preserving contractual parity in the transfer process. + Intent of the listing service The details of the listing service were omitted from the policy proposal due to time constraints and to preserve some flexibility to work with ARIN staff on the design and criteria to fully meet the needs of ARIN and the community. Generally, the expectation is that the listing service data will be as open and public as possible with the intent of allowing as much information as possible to potential transferors/transferees prior to engaging in the process. + Effects on Current policy Current merger/acquisition/divestiture policy remains unchanged. The proposed re-titling of the policy focused on merger/acquisition merely as an oversight, not in an intent to change the handling of such transfers. Hopefully this will be addressed in the next revision of the policy proposal. + Implementation date IANA Free pool runout was chosen because it is objectively factual. ARIN runout will be staggered with ARIN unable to issue larger blocks before it runs out of smaller ones. Additionally, using IANA runout allows the policy and associated market to kind of spin up and gain some experience before ARIN runs out. + Potential Legal Issues Nobody present at the BoF was prepared or qualified to speak on behalf of ARIN from a legal perspective. As a result, questions regarding legal ramifications were deferred as out of scope for the BoF session. ARIN Counsel will present a review of the proposed policy at the ARIN meeting in Denver. It will also be posted to the PPML. In general, the idea of a transfer policy was received with a neutral to positive response. There were no strong negative reactions expressed. There were several questions about likely efficacy and whether this policy would actually accomplish anything. Leo Bicknell made the point that without this policy or something like it, the world becomes set in stone after IPv4 runout. Haves have and have nots have not and there's no way for that to change. With this proposal, there's at least the possibility if folks can come to agreement on the subject. Thanks to everyone who attended the BoF. Your input was very useful to the AC. I encourage anyone interested in further participating in the policy process to subscribe to the ARIN PPML (http://lists.arin.net/mailman/listinfo/ppml) and post your comments there. Respectfully submitted, Owen DeLong ARIN AC From cliffb at cjbsys.bdb.com Tue Mar 4 14:04:12 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Tue, 04 Mar 2008 14:04:12 -0500 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <47CD7D99.9000108@internap.com> References: <47CD7D99.9000108@internap.com> Message-ID: <47CD9D2C.3090201@cjbsys.bdb.com> Scott Leibrand wrote: > Jim Weyand wrote (in a message not posted to PPML): > > >> My real concern is that the community has not considered the costs >> associated with the proposed constraints. I can dream up a number of >> scenarios that may occur. >> >> >> >> Scenario 1 >> >> An ISP has a /16 but determines they really only need a much smaller >> block - maybe a /20. They look at the market price for a /16 and >> determine that it is a high enough price to put up with the pain of >> moving all of their addresses to new space. In an unrestricted market a >> /16 is probably worth more than an equivalent number of /20s so the ISP >> would be motivated to transfer out the whole /16 and transfer in a /20. >> >> >> >> The problem is, under ?Policy Proposal 2008-2: IPv4 Transfer Policy >> Proposal?, our ISP cannot acquire new addresses. So, to make the sale, >> the /16 gets broken up into pieces and all parties are net losers. The >> seller was unable to maximize their profit, the original buyer was >> unable to participate in this transaction (because they are prequalified >> for a /16) and the routing table is increased. >> Perhaps the wording should be changed to allow a three-way (n-way?) trade where several transactions can be made at one time and only count as one transaction.i.e. A sells the /16 to B and buys the /20 from C. Like data base changes, it would be an atomic action and would be considered either all completed or nothing completed. Kind of like some of the sports team trades you read about >> >> >> Scenario 2 >> >> Our ISP with the /16 thinks they only need a /17. They look at the >> market rate for the remaining /17 and think, ?hmmm? that?s pretty >> good?. The ISP reasons that they can get cash now and, if they really >> need it, they can go buy more addresses later. >> >> >> >> The ISP is pretty excited about this idea and investigates what is >> involved with transferring out IP Address space under ARIN?s new rules. >> They read the rules and realize, down in the fine print, that they can?t >> get any more IP Address space for another two years. The risk is too >> great and the ISP decides not to transfer out any addresses and the >> market price of a /17 is artificially inflated. >> >> >> >> The constraints will have real costs ? probably not the kind of costs >> that will make the front page of the Wall Street Journal but nonetheless >> real costs that will affect ISPs. >> This seems to me to be in the area of business decisions and I'm not sure if ARIN should be responsible for someone's bad business decisions. The sale is being made for a profit and the risks and benefits of that sale should be weighed by the company before they make that sale. Having said that, maybe the benefits to ARIN of letting sales take place more often outweigh the problems. Perhaps there could be higher fees for excess transactions to cut down on trading too often. Like broker fees tend to keep most people from trading all the time. I.e. One transaction per 24 (x?) months is free, the second one is $xxxx, the third is 2 * $xxxx and so on. This would put a damper on churning of addresses while allowing those who really need to get more within a 24 month (or other) period to do so at some increased cost. And of course there may not be enough trading to make this worth worrying about. :-) But I guess better safe than sorry. Cliff > > I agree completely. Perhaps one way to address your concerns would be > to look to NRPM section 4.6 Amnesty Requests > (http://www.arin.net/policy/nrpm.html#four6), and include text in the > transfer policy to accomplish similar objectives. > > But the more I look at it, the more I wonder if the same objective could > be accomplished more simply by striking the words ", or through this > Simple Transfer policy" from the condition that "The transferor may not > request any IPv4 allocations or assignments from ARIN (through ordinary > allocations or assignments, or through this Simple Transfer policy) > within the subsequent 24 months." Under the standard transferee > conditions, any subsequent requests to receive IPv4 addresses through > this Simple Transfer policy would have to be justified and > pre-qualified, just as with any other potential transferee. > > The only thing this doesn't address is the desire to allow someone to > get and renumber into a smaller block (say /20) and then transfer their > larger block (say /16). Under the current proposed policy, such an > organization would be able to keep the first or last /20 out of their > /16, and transfer the remaining /17, /18, /19, and /20. While I could > see a renumbering being slightly better, I think the existing policy is > adequate, so I'm not sure if we need to allow people to renumber into a > completely different block, and deal with all the complexities of timing > that entails. > > > > >> I have struggled to fully understand the latter part of Scott?s second >> paragraph: >> >> >> >> >>> but that further restricting transferors from >>> deaggregating to meet legitimate demand from pre-qualified transferees >>> will have a negative effect of increasing the price of small blocks >>> while decreasing the price (and supply) of larger blocks. >>> >> >> >> As I understand this if we make it too difficult to split a block we could: >> >> 1) Artificially raise the price of smaller blocks since there may be >> demand for smaller blocks that cannot be met while there are larger >> blocks that sit unused. >> > > Yes, that is my main concern. > > >> 2) Unintentionally decrease the supply of larger blocks because a >> buyer will look at the lower price of the larger blocks and lobby for an >> exemption to the pre-qualification requirement. >> > > I hadn't thought of that aspect of it, but yes, that would be another > negative consequence of not allowing enough deaggregation. > > >> Do I understand this correctly? >> >> Assuming I do, isn?t this another argument for not introducing any >> market constraints other than minimum block size? >> > > Or at least for reducing the number of market constraints. As I > outlined above, and in a separate proposed modification under discussion > (to allow ARIN discretion to allow enough deaggregation to ensure > adequate supply of smaller blocks), I'm open to reconsidering any > aspects of the policy that might do more harm than good, and either > eliminating or changing those aspects, or introducing compensatory > language to deal with the negative side effects. > > Do you have any feedback on any of the proposals above, or any other > suggested improvements? The 30-day cutoff for submissions of revised > proposals for Denver is fast approaching. > > Thanks, > Scott > > > >> *From: *"Jim Weyand" > > >> >> *Date: *February 29, 2008 9:14:04 AM PST (CA) >> >> *To: *"arin ppml" > >> >> *Subject: **Re: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy >> Proposal* >> >> >> >> Does our economist monitor this list? There is a lot of language in the >> rationale section that says that many of the restrictions on trade are >> designed to limit speculation. Is speculation worse than living with >> the restrictions imposed by this proposal? >> >> For example one restriction is that if you transfer address space to >> another party you may not receive address space for another 24 months. >> This means that if you have a nice large block you are prevented from >> transferring the entire block to another party and getting a more >> suitable block in return. >> >> This restriction will also artificially increase the "market price" of a >> block of addresses since I will only take the risk of running out of >> addresses in next 24 months if it is very rewarding. >> >> I'd like to hear our economist's (Ben?) comments on the cost to the >> community of the restrictions v. speculation. >> >> Even with these restrictions I can support this policy, however I think >> it is worthwhile to consider the "hidden" costs associated with these >> restrictions. >> >> -Jim Weyand >> >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of >> Leo Bicknell >> Sent: Friday, February 29, 2008 10:50 AM >> To: arin ppml >> Subject: Re: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy >> Proposal >> >> In a message written on Fri, Feb 29, 2008 at 10:27:02AM -0500, Cliff >> Bedore wrote: >> >> I think we need to make sure the ARIN attorneys look at this from the >> >> >>> standpoint of "How can I beat the system". I expect they are >>> >>> >> honorable and >> >> above board and that's probably a disadvantage when trying to ensure >> >> all the >> >> i's are dotted and the t's are crossed and the vultures are kept at >> >> bay. >> >> The ARIN AC has worked closely with both Steve Ryan, ARIN Council >> and Ben Edelman, who many saw at the last meeting for his Economics >> background, but in addition to his PhD in economics also has a J.D. >> from Harvard Law and is admitted to the Massachusetts Bar. They >> both provided significant input that the AC used to better craft >> the policy language to strengthen ARIN's legal position were this >> policy to be adopted. >> >> That's not to say they don't have some concerns. Nothing is 100% >> in law, particularly when there is limited case law on the subject. >> I believe both will be at the Denver meeting able to answer questions >> about legal risk. As with all policies, ARIN Council will generate >> a legal review of the policy prior to the meeting which should both >> be posted to PPML and reviewed at the meeting. >> >> I strongly urge anyone with legal concerns to either come to Denver, >> or participate remotely. >> >> -- >> Leo Bicknell - bicknell at ufp.org - >> CCIE 3440 >> PGP keys at http://www.ufp.org/~bicknell/ >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the >> ARIN Public Policy >> Mailing List (PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml >> Please contact the ARIN Member Services Help Desk at info at arin.net >> if you experience any issues. >> >> >> >> > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > > From michael.dillon at bt.com Tue Mar 4 14:13:27 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 4 Mar 2008 19:13:27 -0000 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: Message-ID: > Generally, the expectation is that the listing > service data will be as open and public as possible > with the intent of allowing as much information as > possible to potential transferors/transferees prior > to engaging in the process. Will this be a real-time listing service to minimise the risk that an insider would have access to data about available blocks before the general public? If so, then that is considered to be an OTC (Over-The-Counter) bulletin board and it may be subject to SEC regulation, depending on just what is being traded. It seems to me that the IP address contracts being traded might be considered to be some kind of OTC derivative. Since the traders in this market would not be considered to be sophisticated investors by the SEC, this could fall under one of the Congressional Acts that regulate trading under the jurisdiction of the SEC. > Nobody present at the BoF was prepared or qualified > to speak on behalf of ARIN from a legal perspective. Is ARIN Counsel qualified to speak about the legal ramifications as far as the SEC are concerned? Not all lawyers deal with all areas of law. > There were several questions about likely efficacy and > whether this policy would actually accomplish anything. Indeed! > Leo Bicknell made the point that without this policy or > something like it, the world becomes set in stone after IPv4 > runout. That's funny, I though that change was the only constant in our universe. Now you want to convince me that IPv4 runout is such a momentous event that it will change the laws of the universe!? > Haves have and have nots have not and there's no way > for that to change. Companies will build out IPv6 networks and eventually begin retiring their IPv4 addresses. And as far as the "have nots" are concerned, there is no law preventing them from simply carving up 126/8, a large block that was given to a Japanese cable company. Or any other large block that seems relatively unused on the North American Internet. --Michael Dillon From sleibrand at internap.com Tue Mar 4 14:22:42 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 04 Mar 2008 11:22:42 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: Message-ID: <47CDA182.80502@internap.com> michael.dillon at bt.com wrote: >> Generally, the expectation is that the listing >> service data will be as open and public as possible >> with the intent of allowing as much information as >> possible to potential transferors/transferees prior >> to engaging in the process. > > Will this be a real-time listing service to minimise the risk > that an insider would have access to data about available blocks > before the general public? > > If so, then that is considered to be an OTC (Over-The-Counter) bulletin > board and it may be subject to SEC regulation, depending on just > what is being traded. It seems to me that the IP address contracts > being traded might be considered to be some kind of OTC derivative. > Since the traders in this market would not be considered to be > sophisticated > investors by the SEC, this could fall under one of the Congressional > Acts > that regulate trading under the jurisdiction of the SEC. > >> Nobody present at the BoF was prepared or qualified >> to speak on behalf of ARIN from a legal perspective. > > Is ARIN Counsel qualified to speak about the legal ramifications > as far as the SEC are concerned? Not all lawyers deal with all > areas of law. I personally am confident that ARIN Counsel will be able to speak to this issue. If the individual lawyers we've been dealing with so far (Steve and Ben) don't deal with that area of law, I know they have the resources to engage someone who does. > Companies will build out IPv6 networks and eventually begin > retiring their IPv4 addresses. And as far as the "have nots" > are concerned, there is no law preventing them from simply > carving up 126/8, a large block that was given to a Japanese > cable company. Or any other large block that seems relatively > unused on the North American Internet. There is no law preventing them from utilizing addresses uniquely registered to another party, but there is pretty strong policy in place that will prevent them from being able to announce a route covering those addresses into the DFZ. That basically makes such addresses equivalent to RFC 1918 space. If you think additional private IPv4 space is needed, there was a policy proposal in APNIC to reserve a /8 for shared use by LIRs that is being taken to the IETF. But the problem we're trying to solve with transfer policy is different: providing for the continued availability of unique global IPv4 addresses after free pool exhaustion. -Scott From michael.dillon at bt.com Tue Mar 4 15:46:02 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 4 Mar 2008 20:46:02 -0000 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47CDA182.80502@internap.com> References: <47CDA182.80502@internap.com> Message-ID: > I personally am confident that ARIN Counsel will be able to > speak to this issue. If the individual lawyers we've been > dealing with so far (Steve and Ben) don't deal with that area > of law, I know they have the resources to engage someone who does. I doubt that they have the resources to engage someone else. My understanding is that lawyers do not work for free, they charge their clients more-or-less on a time and materials basis. Therefore, if the client (ARIN BoT and President) do not ask ARIN's counsel to look into the possibility that these transfer plans are stepping into the area regulated by the SEC, then they won't engage someone to look into that. So far, from the discussion that I have seen, it does not appear that anyone seriously considered the possibility that the IP address market proposals are getting rather close to the territory that the SEC regulates. That's why I'm raising the issue here, in hopes that some of the people on this list will discuss it with the BoT, and with some sort of legal advisor who has expertise in the right area of law. It could be the current counsel or some other lawyer. That is up to the BoT. > > Companies will build out IPv6 networks and eventually begin > retiring > > their IPv4 addresses. And as far as the "have nots" > > are concerned, there is no law preventing them from simply > carving up > > 126/8, a large block that was given to a Japanese cable company. Or > > any other large block that seems relatively unused on the North > > American Internet. > > There is no law preventing them from utilizing addresses > uniquely registered to another party, but there is pretty > strong policy in place that will prevent them from being able > to announce a route covering those addresses into the DFZ. And just what policy is that? We regularly see incidents where organizations announce addresses into the DMZ that are not registered to the organization. If you talk to the operational folks you will learn that it is not a simple matter to figure out whether a particular route announcement is proper or not. > That basically makes such addresses equivalent to RFC 1918 > space. Tell that to the people who couldn't get to YouTube a week ago. Now imagine what would have happened if Pakistani Telecom made a typo and accidentally announced address space used by a German ISP for their modem dial customers. Instead of knocking out a high traffic site due to blocking their nameservers, it would cause intermittent outages to a few customers, many of whom would redial and solve the problem. The fact is that there are big impact address blocks and small impact address blocks. Not all are equal in their importance to North American ISPs. --Michael Dillon From drc at virtualized.org Tue Mar 4 16:01:23 2008 From: drc at virtualized.org (David Conrad) Date: Tue, 4 Mar 2008 13:01:23 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: Message-ID: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> Hi, On Mar 4, 2008, at 9:27 AM, Owen DeLong wrote: > Leo Bicknell made the point that without this policy or something > like it, the world becomes set in stone after IPv4 runout. Haves > have and have nots have not and there's no way for that to change. To be blunt, this strikes me as astoundingly hallucinatory. Without some form of transfer policy, ARIN simply becomes irrelevant as address consumers go to the "black" market in order to meet their requirements. With a transfer policy, ARIN _may_ retain some relevance as a source of "title" information, but a lot depends on the restrictions ARIN attempts to impose. Make the policy too restrictive, and people will go elsewhere. In the end, with or without a transfer policy, you're still out of "free" IPv4 addresses and businesses will do what they feel is necessary to get around unenforceable bureaucratic rules. Regards, -drc From iljitsch at muada.com Wed Mar 5 04:31:17 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 5 Mar 2008 10:31:17 +0100 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> Message-ID: <6430B9BE-E8DA-4DDE-B5B2-5A6A45DB6CD7@muada.com> On 4 mrt 2008, at 22:01, David Conrad wrote: >> Leo Bicknell made the point that without this policy or something >> like it, the world becomes set in stone after IPv4 runout. Haves >> have and have nots have not and there's no way for that to change. > To be blunt, this strikes me as astoundingly hallucinatory. Your bluntness is duly noted. > Without some form of transfer policy, ARIN simply becomes irrelevant > as address consumers go to the "black" market in order to meet their > requirements. Let me try to be blunt as well: Who the **** cares what happens when we're out of IPv4 space? Because then we'll be out of IPv4 space, and the if THAT isn't enough to get people to adopt IPv6, we might as well all go home and read up on the X.25 specs because this internet thing will be over and done with very quickly. There is one message and one message only: IPv6. Learn it. Love it, don't love it, but either way, make sure you RUN it 4 years from now if there is even the slightest chance that you may need new IP addresses after that. > With a transfer policy, ARIN _may_ retain some relevance as a source > of "title" information, but a lot depends on the restrictions ARIN > attempts to impose. Make the policy too restrictive, and people will > go elsewhere. The part that I'm still waiting to see answered is how the rest of the world gets access to the excess IPv4 legacy space that exists in the ARIN region. A policy that only allows transfer of space between entities in the ARIN region certainly won't fly with the likes of the WTO. From michael.dillon at bt.com Wed Mar 5 07:47:53 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 5 Mar 2008 12:47:53 -0000 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <6430B9BE-E8DA-4DDE-B5B2-5A6A45DB6CD7@muada.com> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> <6430B9BE-E8DA-4DDE-B5B2-5A6A45DB6CD7@muada.com> Message-ID: > The part that I'm still waiting to see answered is how the > rest of the world gets access to the excess IPv4 legacy space > that exists in the ARIN region. Just take it. If you have no need to communicate with North American sites, then just use whatever addresses you want. It would be a good idea to first make sure that you don't see any regional traffic to the address range that you pick, and that the range does not contain some internationally important hosts like, for instance, the DNS servers of a major video hosting site. Outside of the former British colonies, there is less and less interest in exchanging traffic with North America. The needs of travellers and emigrant communities are not big enough for EVERY foreign ISP to maintain universal connecity. In fact, it's not really possible to measure how universal your connectivity is so we don't even know how many ISPs already survive quite well without it. Even in such a fundamental category as search engines, French, Germans and Russians are more likely to use www.voila.fr, www.abacho.com and www.rambler.ru than they are to use www.google.fr, www.google.de and www.google.ru. If people find that there is value in prolonging the life of the IPv4 Internet in order to delay deploying IPv6, then it will not be the IPv4 Internet as we know it from the 1990s. It will be a more fragmented Internet, but still increasingly useful to the individual users who depend on it. > A policy that only allows > transfer of space between entities in the ARIN region > certainly won't fly with the likes of the WTO. In Europe, all of the largest ISPs are members of an organization called ETNO, and they are unanimous that there should be no IP marketplace. Here is what they presented at RIPE 55 No IP Marketplace - ETNO believes that a marketplace in IP addressing is contrary to the principles of fair play and conservation through which IP addresses have been allocated in the past - Development of a market for IP addresses should be strongly discouraged - Legal, informal and illegal trading of IP addresses should be strongly discouraged - RIPE - as well as its membership - should identify strategic actions that would help meet this goal If ARIN allows transfer of address blocks for money, it will likely be the only RIR to do so. --Michael Dillon From iljitsch at muada.com Wed Mar 5 09:35:32 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 5 Mar 2008 15:35:32 +0100 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47CE98E6.3080606@ttec.com> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> <6430B9BE-E8DA-4DDE-B5B2-5A6A45DB6CD7@muada.com> <47CE98E6.3080606@ttec.com> Message-ID: <3C4726EC-678E-4D89-AAD8-D9362AFC04E1@muada.com> On 5 mrt 2008, at 13:58, Joe Maimon wrote: >> Who the **** cares what happens when we're out of IPv4 space? >> Because then we'll be out of IPv4 space, and the if THAT isn't >> enough to get people to adopt IPv6, we might as well all go home >> and read up on the X.25 specs because this internet thing will be >> over and done with very quickly. > Yes, that was the prevailing group-think after the whole "we will > build it and they will migrate" thing didnt work out. So what are you saying here? That IPv6 is never going to fly, because if it would, it had done so immediately after its creation? > ipv4 will "run out" and the whole world will wake up the next > morning and mass migrate to ipv6. This is your viewpoint, one you > have been consistent about. > This is a pipe dream. Or a nightmare. Or a pipe nightmare. If it happens when you're awake it's generally not a dream or a nightmare. People who have all the IPv4 address space they need won't be doing much around the time we run out. But those who need an influx of new address space to keep their business running (i.e., ISPs) and those who want to start something new will have to do something different than they've been doing so far. If that something is not IPv6, that means the something won't be sustainable in the long run. > Here is another viewpoint. > ipv4 wont run out. It will just become scarce (and scarcer), and > resultingly, valuable (and more valuable). Sure, if you want to have a service hosted, you only need a few IP addresses, which you'll be able to get one way or another. However, we just saw pretty pictures that indicate 83% of all ARIN IPv4 address space is held by 1% of the ARIN members. Those few dozen organizations use up millions of addresses each year. They pay less than a cent per address per year for that now. For them, the prospect of having to pay (say) $1/address the first year after the v4 exhaustion will be an unattractive one, but then having to work harder and pay more each year is what makes this completely unworkable. So either they'll collapse their existing address space by putting more users behind a single address, or they'll go to IPv6. > Nobody will mass migrate to ipv6 because: > - it doesnt work well enough for their needs > - they dont understand it > - they cant afford the equipment forklifts > - they cant support it > - they cant afford to support it > - its a network without anything compelling on it > The last point is the one that makes or breaks. These are all things that can only be attributed to IPv6 AS IT IS TODAY. They are not inherent properties of the protocol. At some point, we'll need to jump over our own shadow and stop demanding that IPv6 has the same usefulness as IPv4 from the very first day it's adopted. (That is not to say that ARIN shouldn't fix its IPv6 path MTU discovery and routing issues...) I've written enough on why trading address space is a bad idea, but I also wrote a lot about why PI for IPv6 was a bad idea, and that went through anyway. So I'm not wasting my time trying to convince the unconvincable. But to the would-be IPv4 traders: depending on how exactly this happens, it can be merely a waste of time and money, or it can blow up in our collective faces. Please make sure you get it right. From jmaimon at chl.com Wed Mar 5 09:56:11 2008 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 05 Mar 2008 09:56:11 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <3C4726EC-678E-4D89-AAD8-D9362AFC04E1@muada.com> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> <6430B9BE-E8DA-4DDE-B5B2-5A6A45DB6CD7@muada.com> <47CE98E6.3080606@ttec.com> <3C4726EC-678E-4D89-AAD8-D9362AFC04E1@muada.com> Message-ID: <47CEB48B.9000001@chl.com> Iljitsch van Beijnum wrote: > On 5 mrt 2008, at 13:58, Joe Maimon wrote: > > > So what are you saying here? That IPv6 is never going to fly, because > if it would, it had done so immediately after its creation? ipv6 will fly when it has wings that can carry the weight people will want to place on it. > People who have all the IPv4 address space they need won't > be doing much around the time we run out. But those who need an influx > of new address space to keep their business running (i.e., ISPs) and > those who want to start something new will have to do something > different than they've been doing so far. If that something is not > IPv6, that means the something won't be sustainable in the long run. The long run might be a long time off, and we need a plan for the short run. > > However, we just saw pretty pictures that indicate 83% of all ARIN > IPv4 address space is held by 1% of the ARIN members. Those few dozen > organizations use up millions of addresses each year. They pay less > than a cent per address per year for that now. For them, the prospect > of having to pay (say) $1/address the first year after the v4 > exhaustion will be an unattractive one, but then having to work harder > and pay more each year is what makes this completely unworkable. So > either they'll collapse their existing address space by putting more > users behind a single address, or they'll go to IPv6. Or they will do both. Which means they will be able to reuse 30-60% of ipv4 space they use currently. Nice room for network growth. Or they can sell it. New revenue stream. So long as somebody is willing to pay for the addresses they have decided they need, it is completely workable. > > > These are all things that can only be attributed to IPv6 AS IT IS > TODAY. And possibly things that can be attributed to ipv6 as it will be when ipv4 "runs out", so relying on everybody to mass-migrate over a few months or even a year or two is most likely out of tune with reality. > > They are not inherent properties of the protocol. At some > point, we'll need to jump over our own shadow and stop demanding that > IPv6 has the same usefulness as IPv4 from the very first day it's > adopted. (That is not to say that ARIN shouldn't fix its IPv6 path MTU > discovery and routing issues...) Its the people who we want to use it who demand it, not neccessarily the engineers who designed it. Thats actually the cause for its failure to be mass adopted as of yet. > > I've written enough on why trading address space is a bad idea, but I > also wrote a lot about why PI for IPv6 was a bad idea, and that went > through anyway. People who you want to use it want to use it that way. > So I'm not wasting my time trying to convince the > unconvincable. But to the would-be IPv4 traders: depending on how > exactly this happens, it can be merely a waste of time and money, or > it can blow up in our collective faces. Please make sure you get it > right. It will happen with or without the registries, so ignoring it or "outlawing" it are exactly the wrong courses of action. Doesnt mean the current attempt of not ignoring it is the correct one, but at least it is an attempt. From dlw+arin at tellme.com Wed Mar 5 12:12:11 2008 From: dlw+arin at tellme.com (David Williamson) Date: Wed, 5 Mar 2008 09:12:11 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> Message-ID: <20080305171211.GI12712@shell01.cell.sv2.tellme.com> On Tue, Mar 04, 2008 at 01:01:23PM -0800, David Conrad wrote: > Hi, > > On Mar 4, 2008, at 9:27 AM, Owen DeLong wrote: > > Leo Bicknell made the point that without this policy or something > > > like it, the world becomes set in stone after IPv4 runout. Haves > > have and have nots have not and there's no way for that to change. > > To be blunt, this strikes me as astoundingly hallucinatory. > > Without some form of transfer policy, ARIN simply becomes irrelevant > as address consumers go to the "black" market in order to meet their > requirements. > > With a transfer policy, ARIN _may_ retain some relevance as a source > of "title" information, but a lot depends on the restrictions ARIN > attempts to impose. Make the policy too restrictive, and people will > go elsewhere. > > In the end, with or without a transfer policy, you're still out of > "free" IPv4 addresses and businesses will do what they feel is > necessary to get around unenforceable bureaucratic rules. Let me clarify the context of the "set in stone" comment, since I was involved in that discussion. At IPv4 runout in the ARIN region, the world does not get set in stone, but ARIN's records become set in stone, since there is, at present, no way to transfer those records between parties. Since there will clearly be transfers, regardless of what ARIN policies exist, it would be very poor stewardship of the IPv4 space. Availability of new space, or the lack thereof, does not terminate ARIN's responsibility to this community, nor does it end the stewardship role. I entirely concur that businesses will do what they need to do. I think it is up to us to make it easy for businisses to do what they need to do, so that the Right Thing naturally occurs. More specifialy, I support this policy as written. I think there are some flaws in it, but those can be corrected as the actual implementation time approaches, and before demand gets very large. We need some sort of transfer policy that balances corporate needs with the tendency towards a speculative market. This might be a good start at that. -David From jcurran at istaff.org Wed Mar 5 12:27:45 2008 From: jcurran at istaff.org (John Curran) Date: Wed, 5 Mar 2008 12:27:45 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <47CDA182.80502@internap.com> Message-ID: At 8:46 PM +0000 3/4/08, wrote: > >So far, from the discussion that I have seen, it does not appear that >anyone seriously considered the possibility that the IP address >market proposals are getting rather close to the territory that the >SEC regulates. That's why I'm raising the issue here, in hopes that >some of the people on this list will discuss it with the BoT, >and with some sort of legal advisor who has expertise in the right >area of law. It could be the current counsel or some other lawyer. >That is up to the BoT. It has been raised as an issue and discussed. At first review by our counsel, there does not appear to be an issue here. The Board will ask for a more formal opinion of the legal ramifications (as we always do) if/when a recommendation for new policy comes before it. /John Chair, ARIN Board of Trustees From raul at lacnic.net Wed Mar 5 14:08:19 2008 From: raul at lacnic.net (Raul Echeberria) Date: Wed, 05 Mar 2008 16:08:19 -0300 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> Message-ID: <7.0.1.0.1.20080305153724.03a022a0@lacnic.net> At 06:01 p.m. 04/03/2008, David Conrad wrote: >Hi, > >On Mar 4, 2008, at 9:27 AM, Owen DeLong wrote: > > Leo Bicknell made the point that without this policy or something > > > like it, the world becomes set in stone after IPv4 runout. Haves > > have and have nots have not and there's no way for that to change. > > >To be blunt, this strikes me as astoundingly hallucinatory. > >Without some form of transfer policy, ARIN simply becomes irrelevant >as address consumers go to the "black" market in order to meet their >requirements. Or they adopt IPv6. Which are the factors that will make take one decision or other is an interesting discussion. Ra?l >With a transfer policy, ARIN _may_ retain some relevance as a source >of "title" information, but a lot depends on the restrictions ARIN >attempts to impose. Make the policy too restrictive, and people will >go elsewhere. > >In the end, with or without a transfer policy, you're still out of >"free" IPv4 addresses and businesses will do what they feel is >necessary to get around unenforceable bureaucratic rules. > >Regards, >-drc > >_______________________________________________ >PPML >You are receiving this message because you are >subscribed to the ARIN Public Policy >Mailing List (PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/ppml >Please contact the ARIN Member Services Help >Desk at info at arin.net if you experience any issues. > > >-- >No virus found in this incoming message. >Checked by AVG Free Edition. >Version: 7.5.516 / Virus Database: 269.21.4/1310 >- Release Date: 04/03/2008 08:35 a.m. From sleibrand at internap.com Wed Mar 5 13:12:48 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 05 Mar 2008 10:12:48 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <7.0.1.0.1.20080305153724.03a022a0@lacnic.net> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> <7.0.1.0.1.20080305153724.03a022a0@lacnic.net> Message-ID: <47CEE2A0.1080806@internap.com> Raul Echeberria wrote: >> Without some form of transfer policy, ARIN simply becomes irrelevant >> as address consumers go to the "black" market in order to meet their >> requirements. > > Or they adopt IPv6. > Which are the factors that will make take one > decision or other is an interesting discussion. Don't forget that, until the entire rest of the world adopts IPv6, organizations doing so will still need IPv4 addresses/connectivity to run dual-stack or some sort of (yet to be standardized or commercialized) protocol translation. If nothing else, a legitimate market for IPv4 transfers will ensure that new entrants can get the IPv4 addresses they need to support whatever technology they choose to use to communicate with the rest of the IPv4 Internet. -Scott From drc at virtualized.org Wed Mar 5 13:34:17 2008 From: drc at virtualized.org (David Conrad) Date: Wed, 5 Mar 2008 10:34:17 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <6430B9BE-E8DA-4DDE-B5B2-5A6A45DB6CD7@muada.com> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> <6430B9BE-E8DA-4DDE-B5B2-5A6A45DB6CD7@muada.com> Message-ID: Iljitsch, On Mar 5, 2008, at 1:31 AM, Iljitsch van Beijnum wrote: > Who the **** cares what happens when we're out of IPv4 space? You seem to answer your own question: > The part that I'm still waiting to see answered is how the rest of > the world gets access to the excess IPv4 legacy space that exists in > the ARIN region. A policy that only allows transfer of space between > entities in the ARIN region certainly won't fly with the likes of > the WTO. (I agree that the focus should be on moving to IPv6) Regards, -drc From drc at virtualized.org Wed Mar 5 13:59:52 2008 From: drc at virtualized.org (David Conrad) Date: Wed, 5 Mar 2008 10:59:52 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <7.0.1.0.1.20080305153724.03a022a0@lacnic.net> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> <7.0.1.0.1.20080305153724.03a022a0@lacnic.net> Message-ID: Raul, On Mar 5, 2008, at 11:08 AM, Raul Echeberria wrote: >> > like it, the world becomes set in stone after IPv4 runout. Haves >> > have and have nots have not and there's no way for that to change. >> To be blunt, this strikes me as astoundingly hallucinatory. >> >> Without some form of transfer policy, ARIN simply becomes irrelevant >> as address consumers go to the "black" market in order to meet their >> requirements. > > Or they adopt IPv6. Ah, if it were only that easy... :-) More seriously, as can be seen from some of the discussion here, it isn't clear to me that there is consensus within the RIR membership that this is the right way to go. It seems some feel IPv4+NAT(+NAT+NAT +...) is a reasonable model for the future of the Internet. In such a world, making the assumption that "the world becomes set in stone" after the last unallocated address is allocated just seems crazy to me. But perhaps I'm confused. > Which are the factors that will make take one decision or other is > an interesting discussion. Indeed. However past discussions appear to have established that "good stewardship" does not include taking _active_ steps in encouraging one technology or the other, so the role of the RIRs is quite limited... Regards, -drc From JBallerini at copsmonitoring.com Wed Mar 5 14:21:39 2008 From: JBallerini at copsmonitoring.com (John Ballerini) Date: Wed, 05 Mar 2008 14:21:39 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> <7.0.1.0.1.20080305153724.03a022a0@lacnic.net> Message-ID: <47CEAC70.EF1A.0093.0@copsmonitoring.com> Hi...anyone out here know the ATT AS? Thanks, John From kkargel at polartel.com Wed Mar 5 14:48:02 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 5 Mar 2008 13:48:02 -0600 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47CEAC70.EF1A.0093.0@copsmonitoring.com> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org><7.0.1.0.1.20080305153724.03a022a0@lacnic.net> <47CEAC70.EF1A.0093.0@copsmonitoring.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410660104F41F@mail> Which one? They have many.. You can go to ARIN and look it up.. > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of John Ballerini > Sent: Wednesday, March 05, 2008 1:22 PM > To: Raul Echeberria; David Conrad > Cc: Public Policy Mailing List > Subject: Re: [ppml] NANOG IPv4 Exhaustion BoF > > Hi...anyone out here know the ATT AS? Thanks, John > > > > _______________________________________________ > 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 BillD at cait.wustl.edu Wed Mar 5 14:54:28 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Wed, 5 Mar 2008 13:54:28 -0600 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47CEE2A0.1080806@internap.com> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org><7.0.1.0.1.20080305153724.03a022a0@lacnic.net> <47CEE2A0.1080806@internap.com> Message-ID: > > Raul Echeberria wrote: > >> Without some form of transfer policy, ARIN simply becomes > irrelevant > >> as address consumers go to the "black" market in order to > meet their > >> requirements. > > > > Or they adopt IPv6. > > Which are the factors that will make take one decision or > other is an > > interesting discussion. > > > Don't forget that, until the entire rest of the world adopts > IPv6, organizations doing so will still need IPv4 > addresses/connectivity to run dual-stack or some sort of (yet > to be standardized or > commercialized) protocol translation. If nothing else, a > legitimate market for IPv4 transfers will ensure that new > entrants can get the IPv4 addresses they need to support > whatever technology they choose to use to communicate with > the rest of the IPv4 Internet. > > -Scott Well, we'd like to think that such market would 'ensure' that they would get the addresses they 'need'. I'd say that this may be probable, but uncertain.... bd From michael.dillon at bt.com Wed Mar 5 14:57:07 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 5 Mar 2008 19:57:07 -0000 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <20080305171211.GI12712@shell01.cell.sv2.tellme.com> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> Message-ID: > At IPv4 runout in the ARIN region, the world does not get set > in stone, but ARIN's records become set in stone, since there > is, at present, no way to transfer those records between > parties. Give your head a shake... At present there are two mechanisms that are regularly used to transfer ARIN records between two parties. The most common one is acquisition, where one company buys all or part of another company. The second mechanism, is where a company returns unneeded IP addresses to ARIN, who then pass them on to someone who needs them. This last mechanism is not broken and can be expected to be used more frequently as IPv6 deployment picks up steam. Before that point in time, I can't see why any organization would want to sell address blocks to someone else, and after that point in time I can't see why anyone would want to buy address blocks. How are you gonna have a market when you start with zero supply and then suddenly shift to zero demand when the supply begins to appear. Futures contracts? If so then you are smack dab in SEC regulatory territory. > More specifialy, I support this policy as written. I think > there are some flaws in it, but those can be corrected as the > actual implementation time approaches, and before demand gets > very large. We need some sort of transfer policy that > balances corporate needs with the tendency towards a > speculative market. No, we don't need a transfer policy. We need to make it clear that IPv4 addresses have no value except when used in the network, and that as the global free pool nears exhaustion, so does the supply of unused IPv4 adddresses. When we run out of free addresses for ARIN to allocate, then nobody else will have any addresses to spare. Unless, of course, some of the AC members or BoT members have legacy allocations that they don't actually need. Given that this transfer policy only benefits the legacy holders whose allocations are not technically justified, I think that it is time for ARIN AC members and ARIN BoT members to come clean, and individually, one by one, issue public statements as to whether or not they hold legacy allocations, either directly or indirectly through corporate ownerships. Also, whether or not their employer holds such legacy blocks, directly or indirectly. --Michael Dillon From michael.dillon at bt.com Wed Mar 5 14:59:42 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 5 Mar 2008 19:59:42 -0000 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47CEAC70.EF1A.0093.0@copsmonitoring.com> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org><7.0.1.0.1.20080305153724.03a022a0@lacnic.net> <47CEAC70.EF1A.0093.0@copsmonitoring.com> Message-ID: > Hi...anyone out here know the ATT AS? Thanks, John Yes, ARIN does. Both of them. You can too if you use the tools provided. --Michael Dillon P.S. Give a man a fish... From sleibrand at internap.com Wed Mar 5 15:12:13 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 05 Mar 2008 12:12:13 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> Message-ID: <47CEFE9D.5020307@internap.com> michael.dillon at bt.com wrote: > This last mechanism is not broken and can be expected to be used > more frequently as IPv6 deployment picks up steam. Before that > point in time, I can't see why any organization would want to > sell address blocks to someone else, and after that point in time > I can't see why anyone would want to buy address blocks. There's this concept called an incentive, and in our capitalist economy one of the most common and effective incentives is a monetary one. If an organization can get paid to renumber out of some of their address space and transfer it, that is a good incentive to do so. > How are you gonna have a market when you start with zero supply > and then suddenly shift to zero demand when the supply begins to > appear. Again, there's an economic concept of a supply curve and a demand curve that pertain here. Right now, supply is zero because the price is zero. As price start to rise, supply will increase and demand will decrease, it's just a question of how much, and at what price they'll reach equilibrium. > Futures contracts? If so then you are smack dab in SEC > regulatory territory. I don't see how futures contracts would be useful in this kind of market. >> More specifialy, I support this policy as written. I think >> there are some flaws in it, but those can be corrected as the >> actual implementation time approaches, and before demand gets >> very large. We need some sort of transfer policy that >> balances corporate needs with the tendency towards a >> speculative market. > > No, we don't need a transfer policy. We need to make it clear that > IPv4 addresses have no value except when used in the network, and > that as the global free pool nears exhaustion, so does the supply > of unused IPv4 adddresses. When we run out of free addresses for > ARIN to allocate, then nobody else will have any addresses to > spare. Yes, free (as in $$) addresses will run out. But I can assure you that if they can make a profit doing so, many businesses will find that they can do without some of their IPv4 addresses, perhaps as part of a transition to IPv6, and/or by using NAT for remaining IPv4 connectivity. Therefore, addresses can remain available: they just won't be free. > Unless, of course, some of the AC members or BoT members have legacy > allocations that they don't actually need. Given that this transfer > policy only benefits the legacy holders whose allocations are > not technically justified, I think that it is time for ARIN AC > members and ARIN BoT members to come clean, and individually, one > by one, issue public statements as to whether or not they hold legacy > allocations, either directly or indirectly through corporate ownerships. > Also, whether or not their employer holds such legacy blocks, directly > or indirectly. I don't believe that any of the advocates of this proposal are doing so out of any interest in selling off their own IPv4 address holdings. I personally do not hold any IP addresses. My employer is an LIR, holds a number of non-legacy allocations from ARIN, and continues to receive additional allocations to support continued growth. If I have any personal interest in an IPv4 transfer market, it is in ensuring that companies with continued need for IPv4 addresses will be able to continue obtaining them after free pool exhaustion. I believe that this is a shared interest of most of ARIN's membership and the wider community. -Scott From drc at virtualized.org Wed Mar 5 15:42:57 2008 From: drc at virtualized.org (David Conrad) Date: Wed, 5 Mar 2008 12:42:57 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> Message-ID: <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org> Michael, On Mar 5, 2008, at 11:57 AM, wrote: > How are you gonna have a market when you start with zero supply > and then suddenly shift to zero demand when the supply begins to > appear. It doesn't appear you've been paying attention. The discussions about "transfers" are between folks who have IPv4 addresses and don't need them (the "supply") and those who need them but can't get them because the IPv4 free pool has been emptied (the "demand"). In the ideal world, if you had IPv4 addresses and didn't need them, you'd return them to the RIR. Alternatively, you could just turn on IPv6 and be done with it. However, we don't live in the ideal world last I checked. The folks who have IPv4 addresses but don't need them currently have no incentive to do anything with those addresses. If "transfers" were liberalized, these folks could have an incentive (e.g., cash, services, cattle, whatever) to transfer those addresses to those folks who continue to need IPv4 addresses. If the incentive is high enough, folks who have addresses but are using them inefficiently could see it in their best interests to increase utilization efficiency and offer the recovered address space to those who need it. On the other side, if the cost gets too high to continue obtaining IPv4 addresses, it may be easier to justify the costs of migrating to IPv6. Currently, there are "transfer" policy proposals in 3 RIRs. They range from the APNIC proposal which I would characterize as imposing minimal constraint/regulation to the ARIN proposal which I would say has maximal constraint/regulation. From my personal perspective, I would imagine the APNIC model could result in attempts by some folk to "corner the market" while the ARIN model (in particular, the restriction against subdividing) could result in the creation of more liberal alternative registries, further eroding the role ARIN plays in its role within the addressing community. Much of the discussion to date has been the equivalent of rearranging deck chairs on the Titanic. IPv4 is sinking. Fast. You can create a fractal maze in front of people trying to get to lifeboats (the ARIN model) or you can facilitate a stampede (the APNIC model). If the goal is to get folks to use IPv6, the APNIC model has certain advantages. If the goal is to encourage the creation of alternative registries, the ARIN model has certain advantages. However, it should be noted that in either case, the core aspect of the end result is the same: people are going to be fighting for seats on lifeboats and the ship will be on the bottom of the ocean. Regards, -drc From drc at virtualized.org Wed Mar 5 15:46:19 2008 From: drc at virtualized.org (David Conrad) Date: Wed, 5 Mar 2008 12:46:19 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47CDA182.80502@internap.com> References: <47CDA182.80502@internap.com> Message-ID: <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> Scott, On Mar 4, 2008, at 11:22 AM, Scott Leibrand wrote: > There is no law preventing them from utilizing addresses uniquely > registered to another party, but there is pretty strong policy in > place > that will prevent them from being able to announce a route covering > those addresses into the DFZ. Like the strong policy that prevented Pakistan Telecom from announcing Youtube's /24. There are conventions and practices that most ISPs abide by most of the time, all essentially outside the realm of ARIN policies. > But the problem > we're trying to solve with transfer policy is different: providing for > the continued availability of unique global IPv4 addresses after free > pool exhaustion. This isn't quite accurate (at least from the empirical evidence). What you appear to be attempting to do is to maintain the policy status quo in the face of a different source of supply of addresses. It isn't clear to me that this is actually all that desirable, particularly since the main beneficiaries of the current policy (the large ISPs) aren't actually going to be helped that much -- their consumption rate is too high. Regards, -drc From sleibrand at internap.com Wed Mar 5 15:54:35 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 05 Mar 2008 12:54:35 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> Message-ID: <47CF088B.5060809@internap.com> David Conrad wrote: > Scott, > > On Mar 4, 2008, at 11:22 AM, Scott Leibrand wrote: >> There is no law preventing them from utilizing addresses uniquely >> registered to another party, but there is pretty strong policy in place >> that will prevent them from being able to announce a route covering >> those addresses into the DFZ. > > Like the strong policy that prevented Pakistan Telecom from announcing > Youtube's /24. Or at least, the policies that prevented them from continuing to do so... But I take your point. >> But the problem >> we're trying to solve with transfer policy is different: providing for >> the continued availability of unique global IPv4 addresses after free >> pool exhaustion. > > This isn't quite accurate (at least from the empirical evidence). What > you appear to be attempting to do is to maintain the policy status quo > in the face of a different source of supply of addresses. I don't know if I'd call it empirical evidence, but I think your perception is also a fairly accurate one. > It isn't clear to me that this is actually all that desirable, > particularly since the main beneficiaries of the current policy (the > large ISPs) aren't actually going to be helped that much -- their > consumption rate is too high. Do you have any suggestions for how we can improve the policy proposal to eliminate unnecessary restrictions while avoiding the negative impacts likely from a completely unrestricted transfer policy? Thanks, Scott From drc at virtualized.org Wed Mar 5 18:02:20 2008 From: drc at virtualized.org (David Conrad) Date: Wed, 5 Mar 2008 15:02:20 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47CF088B.5060809@internap.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> Message-ID: Scott, On Mar 5, 2008, at 12:54 PM, Scott Leibrand wrote: > Do you have any suggestions for how we can improve the policy > proposal to eliminate unnecessary restrictions while avoiding the > negative impacts likely from a completely unrestricted transfer > policy? What are 'negative impacts'? I have a couple more fundamental questions: a) What is the overarching goal the transfer policy is trying to achieve? b) What tools exist (or can be expected to exist given reasonable time/ resources) to enforce that policy? The answers to these questions would shape my answer. A couple of observations: - the 6 month restriction could force folks to go outside the policy in desperation (e.g., the amount of address space available via transfers is likely to be hard to predict. You could be in a situation where at one point in time, the only option is a small block even though you know it won't last 6 months. What option do you have?) - restrictions on sub-division beyond what is imposed within the routing system are unlikely to be effective Regards, -drc From sleibrand at internap.com Wed Mar 5 18:29:23 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 05 Mar 2008 15:29:23 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> Message-ID: <47CF2CD3.6090706@internap.com> David Conrad wrote: > Scott, > > On Mar 5, 2008, at 12:54 PM, Scott Leibrand wrote: >> Do you have any suggestions for how we can improve the policy proposal >> to eliminate unnecessary restrictions while avoiding the negative >> impacts likely from a completely unrestricted transfer policy? > > What are 'negative impacts'? I think you outlined a few of them earlier today, but they would include the results of a number of different types of speculation (unnecessary volatile prices, scarcity, etc.), hoarding of addresses for various reasons (speculation, attempts to starve out competitors, etc.), and unnecessary deaggregation. > I have a couple more fundamental questions: > > a) What is the overarching goal the transfer policy is trying to achieve? If there were just one goal, this would be easy. We're trying to ensure the continued availability of IP resources after IPv4 free pool exhaustion, minimizing disruption, minimizing unnecessary deaggregation, preserving some level of fairness, etc... > b) What tools exist (or can be expected to exist given reasonable > time/resources) to enforce that policy? The main tool is that, as the recognized authority in registration of IPv4 addresses in North America, recognition as valid of any transfers by ARIN has considerable value to both transferors and transferees. > The answers to these questions would shape my answer. > > A couple of observations: > > - the 6 month restriction could force folks to go outside the policy in > desperation (e.g., the amount of address space available via transfers > is likely to be hard to predict. You could be in a situation where at > one point in time, the only option is a small block even though you know > it won't last 6 months. What option do you have?) You could get PA space from your ISP or another LIR. The intent of a the transfer policy is that it would ensure the availability of blocks of all sizes legitimately demanded by transferees. Therefore, if we do it right, there should always be an appropriately sized block available at some price. > - restrictions on sub-division beyond what is imposed within the routing > system are unlikely to be effective It is not our intention to prevent advertisements of deaggregates within the routing system, as people do today down to /24, regardless of the size of their allocation/assignment. Rather, we hope to prevent the transfer of large numbers of small blocks when a larger one would do, as we don't want networks to be cobbling together their IP space from multiple sources and then being forced to announce extra routes for all the different blocks. FYI, we'll be posting version 1.1 of this policy shortly, which IMO includes some improvements on this front. -Scott From jcurran at istaff.org Wed Mar 5 19:02:30 2008 From: jcurran at istaff.org (John Curran) Date: Wed, 5 Mar 2008 19:02:30 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <292DCB81-EAD1-4774-8913- 998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> Message-ID: At 7:57 PM +0000 3/5/08, wrote: > >Unless, of course, some of the AC members or BoT members have legacy >allocations that they don't actually need. Given that this transfer >policy only benefits the legacy holders whose allocations are >not technically justified, I think that it is time for ARIN AC >members and ARIN BoT members to come clean, and individually, one >by one, issue public statements as to whether or not they hold legacy >allocations, either directly or indirectly through corporate ownerships. >Also, whether or not their employer holds such legacy blocks, directly >or indirectly. Michael - Board members complete such statements (which are reviewed with the rest of the Board). This information is used to avoid Conflict of Interest situations, so that Board members recuse themselves at appropriate times (e.g. this has happened recently with respect to Legacy RSA discussions). Public disclosure of this information for Board or AC members has not been required in the past, but could be made a requirement if desired by the community. This would be a very good item to discuss at the upcoming Denver public meeting, as it would be a material change in expectations for those running for the AC or Board. /John P.S. I am not a holder of any legacy address space, either directly or indirectly. I don't believe that my employer (ServerVault) is a holder of any legacy assignments either (and I am precluded from SV's interactions with ARIN due to my position as Chair). From randy at psg.com Wed Mar 5 20:57:35 2008 From: randy at psg.com (Randy Bush) Date: Wed, 05 Mar 2008 17:57:35 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> Message-ID: <47CF4F8F.2030504@psg.com> > a) What is the overarching goal the transfer policy is trying to > achieve? dunno. but, imiho, what it should be is a few things o allow newcomers into the game, albeit probably at a higher cost than the early entrants o flush out underutilized space o see that space migrates to what is termed 'best use' > b) What tools exist (or can be expected to exist given reasonable time/ > resources) to enforce that policy? what is needed? in talking to economics and market folk these last days, i got no clear indication of "must haves." i would be interested in hearing if speculative purchasing would have a signature we could detect and use to ameliorate speculation in some fashion. randy From bmanning at vacation.karoshi.com Wed Mar 5 23:28:53 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 6 Mar 2008 04:28:53 +0000 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47CF2CD3.6090706@internap.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF2CD3.6090706@internap.com> Message-ID: <20080306042853.GA26365@vacation.karoshi.com.> >On Wed, Mar 05, 2008 at 03:29:23PM -0800, Scott Leibrand wrote: > > David Conrad wrote: > > Scott, > > > > I have a couple more fundamental questions: > > > > a) What is the overarching goal the transfer policy is trying to achieve? > > If there were just one goal, this would be easy. We're trying to ensure > the continued availability of IP resources after IPv4 free pool > exhaustion, minimizing disruption, minimizing unnecessary deaggregation, > preserving some level of fairness, etc... Scott: er... thats a list of goals :) how about... "maintaining the stewardship role for IP space". > > b) What tools exist (or can be expected to exist given reasonable > > time/resources) to enforce that policy? David: are you refering to the proposed policy in the ARIN region on transfers? if so, whats wrong with the existing tools? > > A couple of observations: > > > FYI, we'll be posting version 1.1 of this policy shortly, which IMO > includes some improvements on this front. this is useful and productive dialog, helping to refine the proposal. thanks. --bill From gih at apnic.net Thu Mar 6 01:43:58 2008 From: gih at apnic.net (Geoff Huston) Date: Thu, 06 Mar 2008 17:43:58 +1100 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org> Message-ID: <47CF92AE.7070806@apnic.net> > Currently, there are "transfer" policy proposals in 3 RIRs. They > range from the APNIC proposal which I would characterize as imposing > minimal constraint/regulation to the ARIN proposal which I would say > has maximal constraint/regulation. The RIPE policy proposal is very similar to APNIC in terms of the constraints applied to the parties of a transfer. > From my personal perspective, I > would imagine the APNIC model could result in attempts by some folk to > "corner the market" while the ARIN model (in particular, the > restriction against subdividing) could result in the creation of more > liberal alternative registries, further eroding the role ARIN plays in > its role within the addressing community. I have wondered about "cornering the market", and I suspect that there are a number of views of the future that may incent certain behaviours. Some folk may be of the view that IPv4 + NATs is a long term viable proposition, and may believe that in such a long term scenario the value of IPv4 addresses may rise steadily over time. Others may be of the view that one of the major elements in an IPv6 transition is the incentive to stop deploying IPv4 and that may well be based in an escalating value of IPv4 addresses, which would increasingly provide economic incentives for entities to deploy IPv6 as their mainstream technology base with minimal IPv4 translation services. The diversity of views abot scenarios and timings will drive different behaviours - some entities may act on the view that once the shock of exhaustion wears off and the related market price has factored in scarcity premiums as well as the initial shock, the drive to IPv6 will assume a new level of momentum, and the IPv4 demand will drop, and with declining demand so will market prices - i.e. some folk would see no value in hoarding and believe that maximal value will be seen in the initial operation of short term market that will be overtaken by IPv6 relatively quickly. Other entities may be of the view that the inertia of this industry is sufficiently large, and the capability of dense NAT deployments sufficiently tenable that an IPv4 market may be used for a long period. If this is accompanied by a view that demand will continue to outpace supply then an escalating price is an obvious outcome. Personally, I would tend to the first view - that escalating price in an Ipv4 address market would rapidly drive the industry into IPv6. This tends to gather its own momentum given the observation that while initial Ipv6 deployments have the added cost imposition of also having to provide mechanisms to access IPv4 networks, as the mass of the Ipv6 deployment increases there is a natural cost transfer and it would be likely that we see a tipping point whereby Ipv6 deployments could be undertaken with no legacy access provisions, thereby effectively transferring the burden of translation to the legacy IPv4 network. In either case the major benefit of this approach of leaving this to the actions of the market itself is that it does not require oracle-like behavior of regulators or even industry players - rather than attempting to drive the industry to certain outcomes, with an historical success rate that one could only describe as stunningly poor (remember GOSIP, remember X.25, remember even QoS...) such an approach of exposing potential suppliers and recipients to each other in the context of an open competitive market place essentially allows each actor to make their own decisions as to technology choices based on their own guesses about the future. > Much of the discussion to date has been the equivalent of rearranging > deck chairs on the Titanic. IPv4 is sinking. Fast. You can create a > fractal maze in front of people trying to get to lifeboats (the ARIN > model) or you can facilitate a stampede (the APNIC model). Firstly I have to say that the combination of references to fractal mazes, lifeboats and stampedes all crammed into one sentence is an achievement all of its own. Well done! :-) I'd hardly characterize the APNIC policy proposal in such dramatic terms. The APNIC model as it stands leaves the operation of any associated market to the industry players themselves. If such a market forces prices up to astronomical heights then the incentive to head immediately to IPv6 becomes all the greater, and the prospects of any Ipv4 address market quickly losing relevance also becomes greater, simply because the industry has been forced to undertake a transition that it has been deferring previously. For many such a long anticipated outcome of actual transition rather than oblique lip service to a token IPv6 effort is not exactly a disaster. Some would say its a fine outcome as long as you're not part of any collateral damage in the associated blame game in the aftermath. So its not as if there is absolutely no alternative here. And its not as if such forms of market outcomes spell doom and disaster of an out of control stampede. This is not quite the wild days of 2000 and the GSM auction debacle appears to have hosed down some of the more insane players in this industry. This is a relatively low margin commodity business down at the plumbing side and it may well be that market pricing may well be influenced by the limited amounts of capital that are within the industry these days. One could say that the ARIN model attempts to constrain demand, and in so doing one possible interpretation is that such a degree of externally imposed constraint effectively lengthens the pain of attempting to stretch IPv4 well beyond its originally assumed deployment scope. This may not be the wisest course of action if you want to provide some form of natural incentives to get over this somewhat strange and distorted scenario of IPv4 address exhaustion tht we are facing. > If the > goal is to get folks to use IPv6, the APNIC model has certain > advantages. If the goal is to encourage the creation of alternative > registries, the ARIN model has certain advantages. > > However, it should be noted that in either case, the core aspect of > the end result is the same: people are going to be fighting for seats > on lifeboats and the ship will be on the bottom of the ocean. Hmm - lets see, on this topic we've now gone through airplane crashes, steam train wrecks, stampedes and now sinking ships. What next? Meteor strike? :-) Geoff From tony.li at tony.li Thu Mar 6 03:47:58 2008 From: tony.li at tony.li (Tony Li) Date: Thu, 6 Mar 2008 00:47:58 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47CF4F8F.2030504@psg.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> Message-ID: <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> |i would be interested in hearing if speculative purchasing would have a |signature we could detect and use to ameliorate speculation in some |fashion. If I remember my econ classes (from oh so long ago ;-), speculative trading is actually beneficial to the market in that it helps provide a buffer for supply. Hoarding is the behavior that we would want to really detect and avoid. Someone trying to corner the market in v4 space would be bad. Tony From tvest at pch.net Thu Mar 6 09:21:42 2008 From: tvest at pch.net (Tom Vest) Date: Thu, 6 Mar 2008 06:21:42 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> Message-ID: <50D4EA12-F786-49CD-A4BC-6F8D65F22851@pch.net> On Mar 6, 2008, at 12:47 AM, Tony Li wrote: > |i would be interested in hearing if speculative purchasing would > have a > |signature we could detect and use to ameliorate speculation in some > |fashion. > > If I remember my econ classes (from oh so long ago ;-), speculative > trading > is actually beneficial to the market in that it helps provide a > buffer for > supply. Hoarding is the behavior that we would want to really > detect and > avoid. Someone trying to corner the market in v4 space would be bad. > > Tony Hoarding in the behavior you should expect. This will be true unless/ until IPv6 is actually fully substitutable for IPv4, for both existing and aspiring number resources users. Until then any "rational" IPv4 seller will know that they'll be able to sell the same, if not a shorter prefix at a higher price tomorrow, and also that they will have to pay even more if they find they they need the IPv4 back again after that. So the only people who might contribute to IPv4 liquidity (i.e., after the first/last sale of truly idled address space) are going to network operators that know they'll never need more IPv4 ever again. For them however, the prospect of empowering new/existing competitors by making essential inputs available is going to provide an additional gating factor influencing number and length of prefixes offered, as well as asking price (c.f., the market for dark fiber). Reposting below from NANOG, with apologies to those who will be seeing this for the second time. TV Begin forwarded message: > From: Tom Vest > Date: February 18, 2008 9:26:03 PM PST > To: nanog at merit.edu > Cc: Rod Beck , Iljitsch van Beijnum > , David Conrad , Brandon > Galbraith > Subject: Re: IPV4 as a Commodity for Profit > > It's good that this discussion is happening now. > To make the discussion as productive as possible, it's probably a > good idea to clarify assumptions and terms. > We all know what "market" means -- but in all likelihood many of > the things we all "know" do not overlap, and some are probably > mutually contradictory. > > If thinking about IPv4 addresses as a "commodity" has any validity, > it comes from the assumption that making them subject to "market > pricing" will increase supply, i.e., incentive current surplus > holders to make that surplus available to would-be buyers. > > In other "commodity" markets, the connection between market pricing > and increased supply is *production* -- i.e., when the revealed > price of a commodity goes up, those who are capable of making it > are motivated to make more, or to jump into the market for the > first time. In other commodity markets, that motivation is bounded > by the threat of alternative suppliers, by the impracticality of > hoarding, and by the inability of the potential seller to use more > of the commodity directly. In other words, the existence or > potential emergence of alternative producers/suppliers tends to > discourage hoarding to maximize prices (because there's no > guarantee that prices will stay high, much less go even higher), > and the lack of direct "use value" reduces any countervailing > incentive that the prospective seller to just hold the assets in > perpetuity, until they can be used in-house. > > In the case of IPv4 addressing, none of these bounding conditions > apply. No more IPv4 addresses can be produced, and they're almost > certain to have unique (if not irreplaceable) use value, at least > for some classes of ISPs that exist today, for at least a decade or > more (or as long as those kinds of ISPs exist, whichever is > shortest). That means the potential price is always going to be > higher tomorrow than it is today, right up to the day before the > last day that IPv4 becomes useless. Which means hoarding is going > to continue to be the most sensible behavior for all surplus > holders -- even those that no longer have any Internet-related ops > or business interests. > > This countervailing incentive is much stronger for surplus holders > that *do* still have such interests. Knowing that IPv4 addresses > that they might need in the future will certainly cost more (maybe > lots more) than whatever price they could command for surplus IPv4 > today, growing ISPs are not likely to contribute much to the > salable, "liquid" address pool. Worse still, so long as IPv4 > continues to be a non-substitutable, must-have input for certain > kinds of ISPs, ISPs like that will know that the threat of > competition from existing or hypothetical future competitors will > be absolutely limited by the availability of IPv4 address space. > For them, making IPv4 address space unavailable to competitors is a > perfectly sensible "use", and one with quite a lot of value. > > An unmediated market is not going to "work", for almost any meaning > of that term. Get over it. From info at arin.net Thu Mar 6 09:27:15 2008 From: info at arin.net (Member Services) Date: Thu, 06 Mar 2008 09:27:15 -0500 Subject: [ppml] Lame Delegations Message-ID: <47CFFF43.5080608@arin.net> ARIN has elected to remove the Lame Delegation identification and notification software from production. Following several months of periodic issues, ARIN determined it is best to take the software offline, review, and retest several components. One recent problem resulted in blank e-mail messages being sent to approximately one hundred organizations. We apologize for this inconvenience. The software is expected to be back online in early April 2008. If you have any further questions or comments, please contact info at arin.net. Regards, Mark Kosters Chief Technology Officer From jweyand at computerdata.com Thu Mar 6 10:54:37 2008 From: jweyand at computerdata.com (Jim Weyand) Date: Thu, 6 Mar 2008 10:54:37 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoF Message-ID: <1582DCBFF968F044A9A910C0AB177C902CE61A@cliff.cdi.local> Tom- This is an interesting example, but instead of using a market of a produced commodity like grain or steel do the same thought experiment with a market for something fixed like farmland in Iowa. It isn't a perfect analogy but it eliminates the producer incentive. Tony- I agree 100%, as counter-intuitive as it sounds, we need speculators in this market. Hopefully we can attract a reasonable number of speculators that will compete with one another and actually deliver lower prices. In an active, vibrant market the price for a block of addresses will be quickly and fairly determined. It is my belief that open market with minimal constraints will result in the best balance and fairness between sellers and buyers of address space. That said I continue to support Scott's proposal, Policy Proposal 2008-2: IPv4 Transfer Policy Proposal with its constraints and the resulting additional costs because that may prove to be more politically acceptable. Even a constrained market is far better than no market at all. -Jim Weyand > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Tom Vest > Sent: Thursday, March 06, 2008 9:22 AM > To: tony.li at tony.li > Cc: 'Randy Bush'; 'Public Policy Mailing List' > Subject: Re: [ppml] NANOG IPv4 Exhaustion BoF > > > On Mar 6, 2008, at 12:47 AM, Tony Li wrote: > > > |i would be interested in hearing if speculative purchasing would > > have a > > |signature we could detect and use to ameliorate speculation in some > > |fashion. > > > > If I remember my econ classes (from oh so long ago ;-), speculative > > trading > > is actually beneficial to the market in that it helps provide a > > buffer for > > supply. Hoarding is the behavior that we would want to really > > detect and > > avoid. Someone trying to corner the market in v4 space would be bad. > > > > Tony > > Hoarding in the behavior you should expect. This will be true unless/ > until IPv6 is actually fully substitutable for IPv4, for both > existing and aspiring number resources users. Until then any > "rational" IPv4 seller will know that they'll be able to sell the > same, if not a shorter prefix at a higher price tomorrow, and also > that they will have to pay even more if they find they they need the > IPv4 back again after that. So the only people who might contribute > to IPv4 liquidity (i.e., after the first/last sale of truly idled > address space) are going to network operators that know they'll never > need more IPv4 ever again. > > For them however, the prospect of empowering new/existing competitors > by making essential inputs available is going to provide an > additional gating factor influencing number and length of prefixes > offered, as well as asking price (c.f., the market for dark fiber). > > Reposting below from NANOG, with apologies to those who will be > seeing this for the second time. > > TV > > Begin forwarded message: > > From: Tom Vest > > Date: February 18, 2008 9:26:03 PM PST > > To: nanog at merit.edu > > Cc: Rod Beck , Iljitsch van Beijnum > > , David Conrad , Brandon > > Galbraith > > Subject: Re: IPV4 as a Commodity for Profit > > > > It's good that this discussion is happening now. > > To make the discussion as productive as possible, it's probably a > > good idea to clarify assumptions and terms. > > We all know what "market" means -- but in all likelihood many of > > the things we all "know" do not overlap, and some are probably > > mutually contradictory. > > > > If thinking about IPv4 addresses as a "commodity" has any validity, > > it comes from the assumption that making them subject to "market > > pricing" will increase supply, i.e., incentive current surplus > > holders to make that surplus available to would-be buyers. > > > > In other "commodity" markets, the connection between market pricing > > and increased supply is *production* -- i.e., when the revealed > > price of a commodity goes up, those who are capable of making it > > are motivated to make more, or to jump into the market for the > > first time. In other commodity markets, that motivation is bounded > > by the threat of alternative suppliers, by the impracticality of > > hoarding, and by the inability of the potential seller to use more > > of the commodity directly. In other words, the existence or > > potential emergence of alternative producers/suppliers tends to > > discourage hoarding to maximize prices (because there's no > > guarantee that prices will stay high, much less go even higher), > > and the lack of direct "use value" reduces any countervailing > > incentive that the prospective seller to just hold the assets in > > perpetuity, until they can be used in-house. > > > > In the case of IPv4 addressing, none of these bounding conditions > > apply. No more IPv4 addresses can be produced, and they're almost > > certain to have unique (if not irreplaceable) use value, at least > > for some classes of ISPs that exist today, for at least a decade or > > more (or as long as those kinds of ISPs exist, whichever is > > shortest). That means the potential price is always going to be > > higher tomorrow than it is today, right up to the day before the > > last day that IPv4 becomes useless. Which means hoarding is going > > to continue to be the most sensible behavior for all surplus > > holders -- even those that no longer have any Internet-related ops > > or business interests. > > > > This countervailing incentive is much stronger for surplus holders > > that *do* still have such interests. Knowing that IPv4 addresses > > that they might need in the future will certainly cost more (maybe > > lots more) than whatever price they could command for surplus IPv4 > > today, growing ISPs are not likely to contribute much to the > > salable, "liquid" address pool. Worse still, so long as IPv4 > > continues to be a non-substitutable, must-have input for certain > > kinds of ISPs, ISPs like that will know that the threat of > > competition from existing or hypothetical future competitors will > > be absolutely limited by the availability of IPv4 address space. > > For them, making IPv4 address space unavailable to competitors is a > > perfectly sensible "use", and one with quite a lot of value. > > > > An unmediated market is not going to "work", for almost any meaning > > of that term. Get over it. > _______________________________________________ > 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 tvest at pch.net Thu Mar 6 12:07:25 2008 From: tvest at pch.net (Tom Vest) Date: Thu, 6 Mar 2008 09:07:25 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <1582DCBFF968F044A9A910C0AB177C902CE61A@cliff.cdi.local> References: <1582DCBFF968F044A9A910C0AB177C902CE61A@cliff.cdi.local> Message-ID: On Mar 6, 2008, at 7:54 AM, Jim Weyand wrote: > Tom- > > This is an interesting example, but instead of using a market of a > produced commodity like grain or steel do the same thought experiment > with a market for something fixed like farmland in Iowa. It isn't a > perfect analogy but it eliminates the producer incentive. > > Tony- Hi Jim, Thanks for the response. Neither Iowa farmland, nor farmland nor land more generally are good analogies, at least not in the present age. Unless you postulate a situation in which potential buyers and sellers are (almost) completely immobile -- e.g., in the pre-modern era -- all of the above are "substitutable" -- i.e., you can still be an agro producer without it, you can still be an agro consumer without it. And unless you postulate a time in which land had some unique, extra-economic significance -- e.g., in the pre-modern era -- then possession of it doesn't confer any special significance that is not substitutable with some other economic asset/activity. In the end, if landowners in Iowa have to compete for investment dollars with landholders (and other asset owners) elsewhere, then that puts an upper bound on the demand, and hence the price, and hence the appeal of hoarding rather than immediately selling, for Iowa land. On the other hand, if Iowa land was the last land on Earth, and not completely substitutable for any aspiring agro producer or consumer on Earth, then you'd probably rarely see it on the market, and never see it at all at a price or in tracts big enough to permit new farmers to enter the market. Making this even worse, if you happened to know that agro production would be getting much more efficient in the near future, so that smaller and smaller parcels might be economically viable (and hence marketable), you'd be even less likely to sell at any price now. (we actually covered this in the course of the NANOG thread -- apologies again for duplication) TV > I agree 100%, as counter-intuitive as it sounds, we need > speculators in > this market. Hopefully we can attract a reasonable number of > speculators that will compete with one another and actually deliver > lower prices. In an active, vibrant market the price for a block of > addresses will be quickly and fairly determined. > > It is my belief that open market with minimal constraints will > result in > the best balance and fairness between sellers and buyers of address > space. > > That said I continue to support Scott's proposal, Policy Proposal > 2008-2: IPv4 Transfer Policy Proposal with its constraints and the > resulting additional costs because that may prove to be more > politically > acceptable. Even a constrained market is far better than no market at > all. > > -Jim Weyand > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf > Of >> Tom Vest >> Sent: Thursday, March 06, 2008 9:22 AM >> To: tony.li at tony.li >> Cc: 'Randy Bush'; 'Public Policy Mailing List' >> Subject: Re: [ppml] NANOG IPv4 Exhaustion BoF >> >> >> On Mar 6, 2008, at 12:47 AM, Tony Li wrote: >> >>> |i would be interested in hearing if speculative purchasing would >>> have a >>> |signature we could detect and use to ameliorate speculation in some >>> |fashion. >>> >>> If I remember my econ classes (from oh so long ago ;-), speculative >>> trading >>> is actually beneficial to the market in that it helps provide a >>> buffer for >>> supply. Hoarding is the behavior that we would want to really >>> detect and >>> avoid. Someone trying to corner the market in v4 space would be > bad. >>> >>> Tony >> >> Hoarding in the behavior you should expect. This will be true unless/ >> until IPv6 is actually fully substitutable for IPv4, for both >> existing and aspiring number resources users. Until then any >> "rational" IPv4 seller will know that they'll be able to sell the >> same, if not a shorter prefix at a higher price tomorrow, and also >> that they will have to pay even more if they find they they need the >> IPv4 back again after that. So the only people who might contribute >> to IPv4 liquidity (i.e., after the first/last sale of truly idled >> address space) are going to network operators that know they'll never >> need more IPv4 ever again. >> >> For them however, the prospect of empowering new/existing competitors >> by making essential inputs available is going to provide an >> additional gating factor influencing number and length of prefixes >> offered, as well as asking price (c.f., the market for dark fiber). >> >> Reposting below from NANOG, with apologies to those who will be >> seeing this for the second time. >> >> TV >> >> Begin forwarded message: >>> From: Tom Vest >>> Date: February 18, 2008 9:26:03 PM PST >>> To: nanog at merit.edu >>> Cc: Rod Beck , Iljitsch van Beijnum >>> , David Conrad , Brandon >>> Galbraith >>> Subject: Re: IPV4 as a Commodity for Profit >>> >>> It's good that this discussion is happening now. >>> To make the discussion as productive as possible, it's probably a >>> good idea to clarify assumptions and terms. >>> We all know what "market" means -- but in all likelihood many of >>> the things we all "know" do not overlap, and some are probably >>> mutually contradictory. >>> >>> If thinking about IPv4 addresses as a "commodity" has any validity, >>> it comes from the assumption that making them subject to "market >>> pricing" will increase supply, i.e., incentive current surplus >>> holders to make that surplus available to would-be buyers. >>> >>> In other "commodity" markets, the connection between market pricing >>> and increased supply is *production* -- i.e., when the revealed >>> price of a commodity goes up, those who are capable of making it >>> are motivated to make more, or to jump into the market for the >>> first time. In other commodity markets, that motivation is bounded >>> by the threat of alternative suppliers, by the impracticality of >>> hoarding, and by the inability of the potential seller to use more >>> of the commodity directly. In other words, the existence or >>> potential emergence of alternative producers/suppliers tends to >>> discourage hoarding to maximize prices (because there's no >>> guarantee that prices will stay high, much less go even higher), >>> and the lack of direct "use value" reduces any countervailing >>> incentive that the prospective seller to just hold the assets in >>> perpetuity, until they can be used in-house. >>> >>> In the case of IPv4 addressing, none of these bounding conditions >>> apply. No more IPv4 addresses can be produced, and they're almost >>> certain to have unique (if not irreplaceable) use value, at least >>> for some classes of ISPs that exist today, for at least a decade or >>> more (or as long as those kinds of ISPs exist, whichever is >>> shortest). That means the potential price is always going to be >>> higher tomorrow than it is today, right up to the day before the >>> last day that IPv4 becomes useless. Which means hoarding is going >>> to continue to be the most sensible behavior for all surplus >>> holders -- even those that no longer have any Internet-related ops >>> or business interests. >>> >>> This countervailing incentive is much stronger for surplus holders >>> that *do* still have such interests. Knowing that IPv4 addresses >>> that they might need in the future will certainly cost more (maybe >>> lots more) than whatever price they could command for surplus IPv4 >>> today, growing ISPs are not likely to contribute much to the >>> salable, "liquid" address pool. Worse still, so long as IPv4 >>> continues to be a non-substitutable, must-have input for certain >>> kinds of ISPs, ISPs like that will know that the threat of >>> competition from existing or hypothetical future competitors will >>> be absolutely limited by the availability of IPv4 address space. >>> For them, making IPv4 address space unavailable to competitors is a >>> perfectly sensible "use", and one with quite a lot of value. >>> >>> An unmediated market is not going to "work", for almost any meaning >>> of that term. Get over it. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy >> Mailing List (PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml >> Please contact the ARIN Member Services Help Desk at info at arin.net if > you >> experience any issues. From sleibrand at internap.com Thu Mar 6 12:11:08 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 06 Mar 2008 09:11:08 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <1582DCBFF968F044A9A910C0AB177C902CE61A@cliff.cdi.local> Message-ID: <47D025AC.4040708@internap.com> In the past I've used the analogy of Manhattan real estate: it's definitely unique, and has only imperfect substitutes elsewhere, as IPv4 is unique, with its own unique demand, and IPv6 is an imperfect substitute. -Scott Tom Vest wrote: > On Mar 6, 2008, at 7:54 AM, Jim Weyand wrote: > >> Tom- >> >> This is an interesting example, but instead of using a market of a >> produced commodity like grain or steel do the same thought experiment >> with a market for something fixed like farmland in Iowa. It isn't a >> perfect analogy but it eliminates the producer incentive. >> >> Tony- > > Hi Jim, > > Thanks for the response. > Neither Iowa farmland, nor farmland nor land more generally are good > analogies, at least not in the present age. > Unless you postulate a situation in which potential buyers and > sellers are (almost) completely immobile -- e.g., in the pre-modern > era -- all of the above are "substitutable" -- i.e., you can still be > an agro producer without it, you can still be an agro consumer > without it. And unless you postulate a time in which land had some > unique, extra-economic significance -- e.g., in the pre-modern era > -- then possession of it doesn't confer any special significance that > is not substitutable with some other economic asset/activity. > > In the end, if landowners in Iowa have to compete for investment > dollars with landholders (and other asset owners) elsewhere, then > that puts an upper bound on the demand, and hence the price, and > hence the appeal of hoarding rather than immediately selling, for > Iowa land. On the other hand, if Iowa land was the last land on > Earth, and not completely substitutable for any aspiring agro > producer or consumer on Earth, then you'd probably rarely see it on > the market, and never see it at all at a price or in tracts big > enough to permit new farmers to enter the market. Making this even > worse, if you happened to know that agro production would be getting > much more efficient in the near future, so that smaller and smaller > parcels might be economically viable (and hence marketable), you'd be > even less likely to sell at any price now. > > (we actually covered this in the course of the NANOG thread -- > apologies again for duplication) > > TV > >> I agree 100%, as counter-intuitive as it sounds, we need >> speculators in >> this market. Hopefully we can attract a reasonable number of >> speculators that will compete with one another and actually deliver >> lower prices. In an active, vibrant market the price for a block of >> addresses will be quickly and fairly determined. >> >> It is my belief that open market with minimal constraints will >> result in >> the best balance and fairness between sellers and buyers of address >> space. >> >> That said I continue to support Scott's proposal, Policy Proposal >> 2008-2: IPv4 Transfer Policy Proposal with its constraints and the >> resulting additional costs because that may prove to be more >> politically >> acceptable. Even a constrained market is far better than no market at >> all. >> >> -Jim Weyand >> >>> -----Original Message----- >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf >> Of >>> Tom Vest >>> Sent: Thursday, March 06, 2008 9:22 AM >>> To: tony.li at tony.li >>> Cc: 'Randy Bush'; 'Public Policy Mailing List' >>> Subject: Re: [ppml] NANOG IPv4 Exhaustion BoF >>> >>> >>> On Mar 6, 2008, at 12:47 AM, Tony Li wrote: >>> >>>> |i would be interested in hearing if speculative purchasing would >>>> have a >>>> |signature we could detect and use to ameliorate speculation in some >>>> |fashion. >>>> >>>> If I remember my econ classes (from oh so long ago ;-), speculative >>>> trading >>>> is actually beneficial to the market in that it helps provide a >>>> buffer for >>>> supply. Hoarding is the behavior that we would want to really >>>> detect and >>>> avoid. Someone trying to corner the market in v4 space would be >> bad. >>>> Tony >>> Hoarding in the behavior you should expect. This will be true unless/ >>> until IPv6 is actually fully substitutable for IPv4, for both >>> existing and aspiring number resources users. Until then any >>> "rational" IPv4 seller will know that they'll be able to sell the >>> same, if not a shorter prefix at a higher price tomorrow, and also >>> that they will have to pay even more if they find they they need the >>> IPv4 back again after that. So the only people who might contribute >>> to IPv4 liquidity (i.e., after the first/last sale of truly idled >>> address space) are going to network operators that know they'll never >>> need more IPv4 ever again. >>> >>> For them however, the prospect of empowering new/existing competitors >>> by making essential inputs available is going to provide an >>> additional gating factor influencing number and length of prefixes >>> offered, as well as asking price (c.f., the market for dark fiber). >>> >>> Reposting below from NANOG, with apologies to those who will be >>> seeing this for the second time. >>> >>> TV >>> >>> Begin forwarded message: >>>> From: Tom Vest >>>> Date: February 18, 2008 9:26:03 PM PST >>>> To: nanog at merit.edu >>>> Cc: Rod Beck , Iljitsch van Beijnum >>>> , David Conrad , Brandon >>>> Galbraith >>>> Subject: Re: IPV4 as a Commodity for Profit >>>> >>>> It's good that this discussion is happening now. >>>> To make the discussion as productive as possible, it's probably a >>>> good idea to clarify assumptions and terms. >>>> We all know what "market" means -- but in all likelihood many of >>>> the things we all "know" do not overlap, and some are probably >>>> mutually contradictory. >>>> >>>> If thinking about IPv4 addresses as a "commodity" has any validity, >>>> it comes from the assumption that making them subject to "market >>>> pricing" will increase supply, i.e., incentive current surplus >>>> holders to make that surplus available to would-be buyers. >>>> >>>> In other "commodity" markets, the connection between market pricing >>>> and increased supply is *production* -- i.e., when the revealed >>>> price of a commodity goes up, those who are capable of making it >>>> are motivated to make more, or to jump into the market for the >>>> first time. In other commodity markets, that motivation is bounded >>>> by the threat of alternative suppliers, by the impracticality of >>>> hoarding, and by the inability of the potential seller to use more >>>> of the commodity directly. In other words, the existence or >>>> potential emergence of alternative producers/suppliers tends to >>>> discourage hoarding to maximize prices (because there's no >>>> guarantee that prices will stay high, much less go even higher), >>>> and the lack of direct "use value" reduces any countervailing >>>> incentive that the prospective seller to just hold the assets in >>>> perpetuity, until they can be used in-house. >>>> >>>> In the case of IPv4 addressing, none of these bounding conditions >>>> apply. No more IPv4 addresses can be produced, and they're almost >>>> certain to have unique (if not irreplaceable) use value, at least >>>> for some classes of ISPs that exist today, for at least a decade or >>>> more (or as long as those kinds of ISPs exist, whichever is >>>> shortest). That means the potential price is always going to be >>>> higher tomorrow than it is today, right up to the day before the >>>> last day that IPv4 becomes useless. Which means hoarding is going >>>> to continue to be the most sensible behavior for all surplus >>>> holders -- even those that no longer have any Internet-related ops >>>> or business interests. >>>> >>>> This countervailing incentive is much stronger for surplus holders >>>> that *do* still have such interests. Knowing that IPv4 addresses >>>> that they might need in the future will certainly cost more (maybe >>>> lots more) than whatever price they could command for surplus IPv4 >>>> today, growing ISPs are not likely to contribute much to the >>>> salable, "liquid" address pool. Worse still, so long as IPv4 >>>> continues to be a non-substitutable, must-have input for certain >>>> kinds of ISPs, ISPs like that will know that the threat of >>>> competition from existing or hypothetical future competitors will >>>> be absolutely limited by the availability of IPv4 address space. >>>> For them, making IPv4 address space unavailable to competitors is a >>>> perfectly sensible "use", and one with quite a lot of value. >>>> >>>> An unmediated market is not going to "work", for almost any meaning >>>> of that term. Get over it. >>> _______________________________________________ >>> 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 jweyand at computerdata.com Thu Mar 6 12:21:44 2008 From: jweyand at computerdata.com (Jim Weyand) Date: Thu, 6 Mar 2008 12:21:44 -0500 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal Message-ID: <1582DCBFF968F044A9A910C0AB177C902CE61C@cliff.cdi.local> Scott- Sorry about the delay, I know you are under time pressure. This is in response to your post on Tuesday, 03-04-08. > I agree completely. Perhaps one way to address your concerns would be > to look to NRPM section 4.6 Amnesty Requests > (http://www.arin.net/policy/nrpm.html#four6), and include text in the > transfer policy to accomplish similar objectives. > > But the more I look at it, the more I wonder if the same objective could > be accomplished more simply by striking the words ", or through this > Simple Transfer policy" from the condition that "The transferor may not > request any IPv4 allocations or assignments from ARIN (through ordinary > allocations or assignments, or through this Simple Transfer policy) > within the subsequent 24 months." Under the standard transferee > conditions, any subsequent requests to receive IPv4 addresses through > this Simple Transfer policy would have to be justified and > pre-qualified, just as with any other potential transferee. As I understand you this will at least allow an ISP that sold address space and then found themselves short, to buy more. If that is your intent then I believe this is a very good idea. > > The only thing this doesn't address is the desire to allow someone to > get and renumber into a smaller block (say /20) and then transfer their > larger block (say /16). Under the current proposed policy, such an > organization would be able to keep the first or last /20 out of their > /16, and transfer the remaining /17, /18, /19, and /20. While I could > see a renumbering being slightly better, I think the existing policy is > adequate, so I'm not sure if we need to allow people to renumber into a > completely different block, and deal with all the complexities of timing > that entails. OK, it is probably more of a technology issue and I really brought it up as an example of the unintended consequences of the proposed market constraints. Once again thank you for your patience and taking on a leadership role in this discussion. -Jim Weyand From bicknell at ufp.org Thu Mar 6 12:20:59 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 6 Mar 2008 12:20:59 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47D025AC.4040708@internap.com> References: <1582DCBFF968F044A9A910C0AB177C902CE61A@cliff.cdi.local> <47D025AC.4040708@internap.com> Message-ID: <20080306172059.GA46497@ussenterprise.ufp.org> In a message written on Thu, Mar 06, 2008 at 09:11:08AM -0800, Scott Leibrand wrote: > In the past I've used the analogy of Manhattan real estate: it's > definitely unique, and has only imperfect substitutes elsewhere, as IPv4 > is unique, with its own unique demand, and IPv6 is an imperfect substitute. While we're tossing out all of our analogies, I think a better one is Super Bowl tickets. Some people get in early at relatively low prices, as the big day gets closer the prise rises, scalpers appear, etc. Once the kick off starts any tickets still in your hands are worthless. IPv4 is fixed like the number of seats. Once most of the Internet is on IPv6 it will be worthless. In the mean time the price, white, grey, or black market will continue to rise bounded only be the desire to "be there." That desire has little to do with policy; a popular team, network, or application could all drive demand. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From drc at virtualized.org Thu Mar 6 12:32:10 2008 From: drc at virtualized.org (David Conrad) Date: Thu, 6 Mar 2008 09:32:10 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> Message-ID: Tony, On Mar 6, 2008, at 12:47 AM, Tony Li wrote: > Hoarding is the behavior that we would want to really detect and > avoid. Someone trying to corner the market in v4 space would be bad. It is probably worthwhile remembering that (at least in the ARIN case) we're talking about life after the exhaustion of the IANA IPv4 free pool. The definition of "hoarding" will likely be subject to some debate. For example, there is a well known university sitting on a /8. Is that hoarding? Regards, -drc From tvest at pch.net Thu Mar 6 13:29:30 2008 From: tvest at pch.net (Tom Vest) Date: Thu, 6 Mar 2008 13:29:30 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <20080306172059.GA46497@ussenterprise.ufp.org> References: <1582DCBFF968F044A9A910C0AB177C902CE61A@cliff.cdi.local> <47D025AC.4040708@internap.com> <20080306172059.GA46497@ussenterprise.ufp.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 6, 2008, at 9:20 AM, Leo Bicknell wrote: > In a message written on Thu, Mar 06, 2008 at 09:11:08AM -0800, > Scott Leibrand wrote: >> In the past I've used the analogy of Manhattan real estate: it's >> definitely unique, and has only imperfect substitutes elsewhere, >> as IPv4 >> is unique, with its own unique demand, and IPv6 is an imperfect >> substitute. > > While we're tossing out all of our analogies, I think a better one > is Super Bowl tickets. Some people get in early at relatively low > prices, as the big day gets closer the prise rises, scalpers appear, > etc. Once the kick off starts any tickets still in your hands are > worthless. > > IPv4 is fixed like the number of seats. Once most of the Internet > is on IPv6 it will be worthless. In the mean time the price, white, > grey, or black market will continue to rise bounded only be the > desire to "be there." > > That desire has little to do with policy; a popular team, network, > or application could all drive demand. Hi Leo, That's somewhat better, but still incomplete and more than a bit misleading IMHO. Consider: First of all, a scalper can only use one ticket her/himself, and there's only one game to see, so there's no upside to her/him to holding the surplus tickets forever. Not so in this case. Second, what if the timing of the kickoff and the status of the next season is uncertain, and the scalpers know that they might have some influence on what happens? Would they have any interest in getting the game started quickly, and guaranteeing the next season (when they may or may not have tickets to scalp), or would they prefer to hold out as long as possible to squeeze every possible penny out of every seat now? If people are really desperate, maybe they could multiplex the tickets, selling each to groups that are willing to sit on each others' laps... Finally, what if the people without tickets knew that buying off the scalpers today could disrupt the scheduling and pricing model of future games? How much are tickets to this one game really worth? TV > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > _______________________________________________ > 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFH0DgKUHTO4sHEFsERArxMAKCkxqr2b2LssowbcpTDxAuaUWGX1ACfXvN5 gQYj+UwV0OLz4thcUpgOf7o= =Vkq5 -----END PGP SIGNATURE----- From tony.li at tony.li Thu Mar 6 13:31:22 2008 From: tony.li at tony.li (Tony Li) Date: Thu, 6 Mar 2008 10:31:22 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> Message-ID: <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> |It is probably worthwhile remembering that (at least in the ARIN case) |we're talking about life after the exhaustion of the IANA IPv4 free |pool. The definition of "hoarding" will likely be subject to some |debate. | |For example, there is a well known university sitting on a /8. Is |that hoarding? Of course not. But say if Warren Buffet decided to buy up every prefix, drive up prices and then dole them out with an eye dropper, that would distort the market. Tony From BillD at cait.wustl.edu Thu Mar 6 13:42:10 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Thu, 6 Mar 2008 12:42:10 -0600 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com><47CF4F8F.2030504@psg.com><000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> Message-ID: > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of David Conrad > Sent: Thursday, March 06, 2008 11:32 AM > To: tony.li at tony.li > Cc: 'Randy Bush'; 'Public Policy Mailing List' > Subject: Re: [ppml] NANOG IPv4 Exhaustion BoF > > Tony, > > On Mar 6, 2008, at 12:47 AM, Tony Li wrote: > > Hoarding is the behavior that we would want to really detect and > > avoid. Someone trying to corner the market in v4 space > would be bad. > > It is probably worthwhile remembering that (at least in the > ARIN case) we're talking about life after the exhaustion of > the IANA IPv4 free pool. The definition of "hoarding" will > likely be subject to some debate. > > For example, there is a well known university sitting on a > /8. Is that hoarding? Yes! > > Regards, > -drc > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at > info at arin.net if you experience any issues. > From tvest at pch.net Thu Mar 6 13:56:12 2008 From: tvest at pch.net (Tom Vest) Date: Thu, 6 Mar 2008 13:56:12 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> Message-ID: <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> On Mar 6, 2008, at 1:31 PM, Tony Li wrote: > > > |It is probably worthwhile remembering that (at least in the ARIN > case) > |we're talking about life after the exhaustion of the IANA IPv4 free > |pool. The definition of "hoarding" will likely be subject to some > |debate. > | > |For example, there is a well known university sitting on a /8. Is > |that hoarding? > > > Of course not. But say if Warren Buffet decided to buy up every > prefix, > drive up prices and then dole them out with an eye dropper, that would > distort the market. You seem to be postulating a market, and a market norm, and an ethic which does not exist in the absence of "effective" rules. If the largest ISPs rush out and buy up as much IPv4 as they can today, in anticipation of "need" they know they'll have in the future -- but also thereby get out ahead other operators that also have "need" today -- isn't that a kind of hoarding? When any buying today exceeds "need" today, it has a distorting -- inflationary and anticompetitive -- effect regardless of whether that was the primary goal or just a convenient side-effect. Anyone who assumes the kind of operator behavior that makes markets absolutely inevitable, should also assume that hoarding for profiteering or simply to keep down the competition will be the norm. Anyone who assumes the kind of operator behavior that makes markets absolutely inevitable, should also assume that any countervailing rules that can be easily bypassed without consequence (i.e., "ineffective" rules) will be ignored. (that's not being critical of operators, just being internally consistent with assumptions) TV From tvest at pch.net Thu Mar 6 14:33:50 2008 From: tvest at pch.net (Tom Vest) Date: Thu, 6 Mar 2008 14:33:50 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47D025AC.4040708@internap.com> References: <1582DCBFF968F044A9A910C0AB177C902CE61A@cliff.cdi.local> <47D025AC.4040708@internap.com> Message-ID: Hi Scott, I agree that you got the substitutability comparison right -- the same could be said about real estate in any one place that you really cared about -- but it's a trivial comparison. Manhattan real estate is not really essential to anything important. Even a diehard New Yorker couldn't credibly claim that living/working in NYC is equivalent in importance to preserving/growing the Internet through a difficult transition. However, if everyone strongly disagrees I imagine we could get Donald Trump to help refine the transfer proposal ;-) TV On Mar 6, 2008, at 12:11 PM, Scott Leibrand wrote: > In the past I've used the analogy of Manhattan real estate: it's > definitely unique, and has only imperfect substitutes elsewhere, as > IPv4 is unique, with its own unique demand, and IPv6 is an > imperfect substitute. > > -Scott > > Tom Vest wrote: >> On Mar 6, 2008, at 7:54 AM, Jim Weyand wrote: >>> Tom- >>> >>> This is an interesting example, but instead of using a market of a >>> produced commodity like grain or steel do the same thought >>> experiment >>> with a market for something fixed like farmland in Iowa. It isn't a >>> perfect analogy but it eliminates the producer incentive. >>> >>> Tony- >> Hi Jim, >> Thanks for the response. >> Neither Iowa farmland, nor farmland nor land more generally are >> good analogies, at least not in the present age. >> Unless you postulate a situation in which potential buyers and >> sellers are (almost) completely immobile -- e.g., in the pre- >> modern era -- all of the above are "substitutable" -- i.e., you >> can still be an agro producer without it, you can still be an >> agro consumer without it. And unless you postulate a time in >> which land had some unique, extra-economic significance -- e.g., >> in the pre-modern era -- then possession of it doesn't confer any >> special significance that is not substitutable with some other >> economic asset/activity. >> In the end, if landowners in Iowa have to compete for investment >> dollars with landholders (and other asset owners) elsewhere, then >> that puts an upper bound on the demand, and hence the price, and >> hence the appeal of hoarding rather than immediately selling, for >> Iowa land. On the other hand, if Iowa land was the last land on >> Earth, and not completely substitutable for any aspiring agro >> producer or consumer on Earth, then you'd probably rarely see it >> on the market, and never see it at all at a price or in tracts >> big enough to permit new farmers to enter the market. Making this >> even worse, if you happened to know that agro production would be >> getting much more efficient in the near future, so that smaller >> and smaller parcels might be economically viable (and hence >> marketable), you'd be even less likely to sell at any price now. >> (we actually covered this in the course of the NANOG thread -- >> apologies again for duplication) >> TV >>> I agree 100%, as counter-intuitive as it sounds, we need >>> speculators in >>> this market. Hopefully we can attract a reasonable number of >>> speculators that will compete with one another and actually deliver >>> lower prices. In an active, vibrant market the price for a block of >>> addresses will be quickly and fairly determined. >>> >>> It is my belief that open market with minimal constraints will >>> result in >>> the best balance and fairness between sellers and buyers of address >>> space. >>> >>> That said I continue to support Scott's proposal, Policy Proposal >>> 2008-2: IPv4 Transfer Policy Proposal with its constraints and the >>> resulting additional costs because that may prove to be more >>> politically >>> acceptable. Even a constrained market is far better than no >>> market at >>> all. >>> >>> -Jim Weyand >>> >>>> -----Original Message----- >>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>>> Behalf >>> Of >>>> Tom Vest >>>> Sent: Thursday, March 06, 2008 9:22 AM >>>> To: tony.li at tony.li >>>> Cc: 'Randy Bush'; 'Public Policy Mailing List' >>>> Subject: Re: [ppml] NANOG IPv4 Exhaustion BoF >>>> >>>> >>>> On Mar 6, 2008, at 12:47 AM, Tony Li wrote: >>>> >>>>> |i would be interested in hearing if speculative purchasing would >>>>> have a >>>>> |signature we could detect and use to ameliorate speculation in >>>>> some >>>>> |fashion. >>>>> >>>>> If I remember my econ classes (from oh so long ago ;-), >>>>> speculative >>>>> trading >>>>> is actually beneficial to the market in that it helps provide a >>>>> buffer for >>>>> supply. Hoarding is the behavior that we would want to really >>>>> detect and >>>>> avoid. Someone trying to corner the market in v4 space would be >>> bad. >>>>> Tony >>>> Hoarding in the behavior you should expect. This will be true >>>> unless/ >>>> until IPv6 is actually fully substitutable for IPv4, for both >>>> existing and aspiring number resources users. Until then any >>>> "rational" IPv4 seller will know that they'll be able to sell the >>>> same, if not a shorter prefix at a higher price tomorrow, and also >>>> that they will have to pay even more if they find they they need >>>> the >>>> IPv4 back again after that. So the only people who might contribute >>>> to IPv4 liquidity (i.e., after the first/last sale of truly idled >>>> address space) are going to network operators that know they'll >>>> never >>>> need more IPv4 ever again. >>>> >>>> For them however, the prospect of empowering new/existing >>>> competitors >>>> by making essential inputs available is going to provide an >>>> additional gating factor influencing number and length of prefixes >>>> offered, as well as asking price (c.f., the market for dark fiber). >>>> >>>> Reposting below from NANOG, with apologies to those who will be >>>> seeing this for the second time. >>>> >>>> TV >>>> >>>> Begin forwarded message: >>>>> From: Tom Vest >>>>> Date: February 18, 2008 9:26:03 PM PST >>>>> To: nanog at merit.edu >>>>> Cc: Rod Beck , Iljitsch van Beijnum >>>>> , David Conrad , Brandon >>>>> Galbraith >>>>> Subject: Re: IPV4 as a Commodity for Profit >>>>> >>>>> It's good that this discussion is happening now. >>>>> To make the discussion as productive as possible, it's probably a >>>>> good idea to clarify assumptions and terms. >>>>> We all know what "market" means -- but in all likelihood many of >>>>> the things we all "know" do not overlap, and some are probably >>>>> mutually contradictory. >>>>> >>>>> If thinking about IPv4 addresses as a "commodity" has any >>>>> validity, >>>>> it comes from the assumption that making them subject to "market >>>>> pricing" will increase supply, i.e., incentive current surplus >>>>> holders to make that surplus available to would-be buyers. >>>>> >>>>> In other "commodity" markets, the connection between market >>>>> pricing >>>>> and increased supply is *production* -- i.e., when the revealed >>>>> price of a commodity goes up, those who are capable of making it >>>>> are motivated to make more, or to jump into the market for the >>>>> first time. In other commodity markets, that motivation is bounded >>>>> by the threat of alternative suppliers, by the impracticality of >>>>> hoarding, and by the inability of the potential seller to use more >>>>> of the commodity directly. In other words, the existence or >>>>> potential emergence of alternative producers/suppliers tends to >>>>> discourage hoarding to maximize prices (because there's no >>>>> guarantee that prices will stay high, much less go even higher), >>>>> and the lack of direct "use value" reduces any countervailing >>>>> incentive that the prospective seller to just hold the assets in >>>>> perpetuity, until they can be used in-house. >>>>> >>>>> In the case of IPv4 addressing, none of these bounding conditions >>>>> apply. No more IPv4 addresses can be produced, and they're almost >>>>> certain to have unique (if not irreplaceable) use value, at least >>>>> for some classes of ISPs that exist today, for at least a >>>>> decade or >>>>> more (or as long as those kinds of ISPs exist, whichever is >>>>> shortest). That means the potential price is always going to be >>>>> higher tomorrow than it is today, right up to the day before the >>>>> last day that IPv4 becomes useless. Which means hoarding is going >>>>> to continue to be the most sensible behavior for all surplus >>>>> holders -- even those that no longer have any Internet-related ops >>>>> or business interests. >>>>> >>>>> This countervailing incentive is much stronger for surplus holders >>>>> that *do* still have such interests. Knowing that IPv4 addresses >>>>> that they might need in the future will certainly cost more (maybe >>>>> lots more) than whatever price they could command for surplus IPv4 >>>>> today, growing ISPs are not likely to contribute much to the >>>>> salable, "liquid" address pool. Worse still, so long as IPv4 >>>>> continues to be a non-substitutable, must-have input for certain >>>>> kinds of ISPs, ISPs like that will know that the threat of >>>>> competition from existing or hypothetical future competitors will >>>>> be absolutely limited by the availability of IPv4 address space. >>>>> For them, making IPv4 address space unavailable to competitors >>>>> is a >>>>> perfectly sensible "use", and one with quite a lot of value. >>>>> >>>>> An unmediated market is not going to "work", for almost any >>>>> meaning >>>>> of that term. Get over it. >>>> _______________________________________________ >>>> 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 kkargel at polartel.com Thu Mar 6 15:08:08 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 6 Mar 2008 14:08:08 -0600 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <1582DCBFF968F044A9A910C0AB177C902CE61A@cliff.cdi.local><47D025AC.4040708@internap.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410660104F430@mail> But if it is known that the real estate in Manhatten is going to be abandoned because a new island with much better real estate popped up out of the ocean and nobody is going to live in Manhatten anymore and we aren't going to talk to anyone there anymore do we really care if anyone hoards the Manhatten real estate? Wouldn't it even be more ecologically feasible if some hanger on continued to upkeep the old real estate? Would we even care or notice if it went in to disrepair? > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Tom Vest > Sent: Thursday, March 06, 2008 1:34 PM > To: Scott Leibrand > Cc: Randy Bush; Public Policy Mailing List > Subject: Re: [ppml] NANOG IPv4 Exhaustion BoF > > Hi Scott, > > I agree that you got the substitutability comparison right -- > the same could be said about real estate in any one place > that you really cared about -- but it's a trivial comparison. > Manhattan real estate is not really essential to anything > important. Even a diehard New Yorker couldn't credibly claim > that living/working in NYC is equivalent in importance to > preserving/growing the Internet through a difficult transition. > > However, if everyone strongly disagrees I imagine we could > get Donald Trump to help refine the transfer proposal ;-) > > TV > > On Mar 6, 2008, at 12:11 PM, Scott Leibrand wrote: > > > In the past I've used the analogy of Manhattan real estate: it's > > definitely unique, and has only imperfect substitutes elsewhere, as > > IPv4 is unique, with its own unique demand, and IPv6 is an > imperfect > > substitute. > > > > -Scott > > > > Tom Vest wrote: > >> On Mar 6, 2008, at 7:54 AM, Jim Weyand wrote: > >>> Tom- > >>> > >>> This is an interesting example, but instead of using a > market of a > >>> produced commodity like grain or steel do the same thought > >>> experiment with a market for something fixed like > farmland in Iowa. > >>> It isn't a perfect analogy but it eliminates the producer > incentive. > >>> > >>> Tony- > >> Hi Jim, > >> Thanks for the response. > >> Neither Iowa farmland, nor farmland nor land more > generally are good > >> analogies, at least not in the present age. > >> Unless you postulate a situation in which potential buyers and > >> sellers are (almost) completely immobile -- e.g., in the > pre- modern > >> era -- all of the above are "substitutable" -- i.e., you > can still be > >> an agro producer without it, you can still be an agro consumer > >> without it. And unless you postulate a time in which land > had some > >> unique, extra-economic significance -- e.g., in the > pre-modern era > >> -- then possession of it doesn't confer any special > significance that > >> is not substitutable with some other economic asset/activity. > >> In the end, if landowners in Iowa have to compete for investment > >> dollars with landholders (and other asset owners) > elsewhere, then > >> that puts an upper bound on the demand, and hence the price, and > >> hence the appeal of hoarding rather than immediately > selling, for > >> Iowa land. On the other hand, if Iowa land was the last land on > >> Earth, and not completely substitutable for any aspiring agro > >> producer or consumer on Earth, then you'd probably rarely > see it on > >> the market, and never see it at all at a price or in tracts big > >> enough to permit new farmers to enter the market. Making > this even > >> worse, if you happened to know that agro production would > be getting > >> much more efficient in the near future, so that smaller > and smaller > >> parcels might be economically viable (and hence > marketable), you'd be > >> even less likely to sell at any price now. > >> (we actually covered this in the course of the NANOG thread -- > >> apologies again for duplication) > >> TV > >>> I agree 100%, as counter-intuitive as it sounds, we need > >>> speculators in > >>> this market. Hopefully we can attract a reasonable number of > >>> speculators that will compete with one another and > actually deliver > >>> lower prices. In an active, vibrant market the price for > a block of > >>> addresses will be quickly and fairly determined. > >>> > >>> It is my belief that open market with minimal constraints will > >>> result in > >>> the best balance and fairness between sellers and buyers > of address > >>> space. > >>> > >>> That said I continue to support Scott's proposal, Policy Proposal > >>> 2008-2: IPv4 Transfer Policy Proposal with its constraints and the > >>> resulting additional costs because that may prove to be more > >>> politically > >>> acceptable. Even a constrained market is far better than > no market > >>> at all. > >>> > >>> -Jim Weyand > >>> > >>>> -----Original Message----- > >>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > >>>> Behalf > >>> Of > >>>> Tom Vest > >>>> Sent: Thursday, March 06, 2008 9:22 AM > >>>> To: tony.li at tony.li > >>>> Cc: 'Randy Bush'; 'Public Policy Mailing List' > >>>> Subject: Re: [ppml] NANOG IPv4 Exhaustion BoF > >>>> > >>>> > >>>> On Mar 6, 2008, at 12:47 AM, Tony Li wrote: > >>>> > >>>>> |i would be interested in hearing if speculative > purchasing would > >>>>> have a > >>>>> |signature we could detect and use to ameliorate speculation in > >>>>> some > >>>>> |fashion. > >>>>> > >>>>> If I remember my econ classes (from oh so long ago ;-), > >>>>> speculative trading is actually beneficial to the > market in that > >>>>> it helps provide a buffer for supply. Hoarding is the behavior > >>>>> that we would want to really detect and avoid. Someone > trying to > >>>>> corner the market in v4 space would be > >>> bad. > >>>>> Tony > >>>> Hoarding in the behavior you should expect. This will be true > >>>> unless/ until IPv6 is actually fully substitutable for IPv4, for > >>>> both existing and aspiring number resources users. > Until then any > >>>> "rational" IPv4 seller will know that they'll be able to > sell the > >>>> same, if not a shorter prefix at a higher price > tomorrow, and also > >>>> that they will have to pay even more if they find they they need > >>>> the > >>>> IPv4 back again after that. So the only people who might > contribute > >>>> to IPv4 liquidity (i.e., after the first/last sale of > truly idled > >>>> address space) are going to network operators that know they'll > >>>> never need more IPv4 ever again. > >>>> > >>>> For them however, the prospect of empowering new/existing > >>>> competitors by making essential inputs available is going to > >>>> provide an additional gating factor influencing number > and length > >>>> of prefixes offered, as well as asking price (c.f., the > market for > >>>> dark fiber). > >>>> > >>>> Reposting below from NANOG, with apologies to those who will be > >>>> seeing this for the second time. > >>>> > >>>> TV > >>>> > >>>> Begin forwarded message: > >>>>> From: Tom Vest > >>>>> Date: February 18, 2008 9:26:03 PM PST > >>>>> To: nanog at merit.edu > >>>>> Cc: Rod Beck , Iljitsch > van Beijnum > >>>>> , David Conrad > , Brandon > >>>>> Galbraith > >>>>> Subject: Re: IPV4 as a Commodity for Profit > >>>>> > >>>>> It's good that this discussion is happening now. > >>>>> To make the discussion as productive as possible, it's > probably a > >>>>> good idea to clarify assumptions and terms. > >>>>> We all know what "market" means -- but in all > likelihood many of > >>>>> the things we all "know" do not overlap, and some are probably > >>>>> mutually contradictory. > >>>>> > >>>>> If thinking about IPv4 addresses as a "commodity" has any > >>>>> validity, it comes from the assumption that making them > subject to > >>>>> "market pricing" will increase supply, i.e., incentive current > >>>>> surplus holders to make that surplus available to > would-be buyers. > >>>>> > >>>>> In other "commodity" markets, the connection between market > >>>>> pricing and increased supply is *production* -- i.e., when the > >>>>> revealed price of a commodity goes up, those who are capable of > >>>>> making it are motivated to make more, or to jump into > the market > >>>>> for the first time. In other commodity markets, that > motivation is > >>>>> bounded by the threat of alternative suppliers, by the > >>>>> impracticality of hoarding, and by the inability of the > potential > >>>>> seller to use more of the commodity directly. In other > words, the > >>>>> existence or potential emergence of alternative > >>>>> producers/suppliers tends to discourage hoarding to maximize > >>>>> prices (because there's no guarantee that prices will > stay high, > >>>>> much less go even higher), and the lack of direct "use value" > >>>>> reduces any countervailing incentive that the > prospective seller > >>>>> to just hold the assets in perpetuity, until they can be used > >>>>> in-house. > >>>>> > >>>>> In the case of IPv4 addressing, none of these bounding > conditions > >>>>> apply. No more IPv4 addresses can be produced, and > they're almost > >>>>> certain to have unique (if not irreplaceable) use > value, at least > >>>>> for some classes of ISPs that exist today, for at least > a decade > >>>>> or more (or as long as those kinds of ISPs exist, whichever is > >>>>> shortest). That means the potential price is always going to be > >>>>> higher tomorrow than it is today, right up to the day > before the > >>>>> last day that IPv4 becomes useless. Which means > hoarding is going > >>>>> to continue to be the most sensible behavior for all surplus > >>>>> holders -- even those that no longer have any > Internet-related ops > >>>>> or business interests. > >>>>> > >>>>> This countervailing incentive is much stronger for > surplus holders > >>>>> that *do* still have such interests. Knowing that IPv4 > addresses > >>>>> that they might need in the future will certainly cost > more (maybe > >>>>> lots more) than whatever price they could command for > surplus IPv4 > >>>>> today, growing ISPs are not likely to contribute much to the > >>>>> salable, "liquid" address pool. Worse still, so long as IPv4 > >>>>> continues to be a non-substitutable, must-have input > for certain > >>>>> kinds of ISPs, ISPs like that will know that the threat of > >>>>> competition from existing or hypothetical future > competitors will > >>>>> be absolutely limited by the availability of IPv4 address space. > >>>>> For them, making IPv4 address space unavailable to > competitors is > >>>>> a perfectly sensible "use", and one with quite a lot of value. > >>>>> > >>>>> An unmediated market is not going to "work", for almost any > >>>>> meaning of that term. Get over it. > >>>> _______________________________________________ > >>>> 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 martinw at mvssol.com Thu Mar 6 15:30:32 2008 From: martinw at mvssol.com (Martin Wills) Date: Thu, 6 Mar 2008 15:30:32 -0500 Subject: [ppml] Abuse address Message-ID: <004301c87fc8$edad6650$5b01a8c0@mvs1domain.mvssol.com> I know this has been discussed before, but I notice Arin still does not enforce the use of an Abuse address. I administer the email in my company and periodically - usually when I get annoyed at too many spam and phishing messages from an ISP - send a report to their abuse address. This works fine with many companies and most other registrars. Why does Arin not insist on some address showing up in a Whois for these situations? Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleibrand at internap.com Thu Mar 6 16:09:28 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 06 Mar 2008 13:09:28 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> Message-ID: <47D05D88.4050400@internap.com> Tom Vest wrote: > If the largest ISPs rush out and buy up as much IPv4 as they can > today, in anticipation of "need" they know they'll have in the future > -- but also thereby get out ahead other operators that also have > "need" today -- isn't that a kind of hoarding? When any buying today > exceeds "need" today, it has a distorting -- inflationary and > anticompetitive -- effect regardless of whether that was the primary > goal or just a convenient side-effect. > > Anyone who assumes the kind of operator behavior that makes markets > absolutely inevitable, should also assume that hoarding for > profiteering or simply to keep down the competition will be the norm. > Anyone who assumes the kind of operator behavior that makes markets > absolutely inevitable, should also assume that any countervailing > rules that can be easily bypassed without consequence (i.e., > "ineffective" rules) will be ignored. This is definitely one of the problems we're trying to avoid with the conditions in the transfer policy proposal. It's clear to me that ARIN's current need-based policies are doing a good job of preventing ISPs from rushing out and getting (for free) a lot more IPv4 addresses than they need, so I believe that requiring similar justification to get IPv4 addresses via transfer will also work well. Do you see any of transfer conditions in the proposal as "countervailing rules that can be easily bypassed without consequence (i.e., "ineffective" rules)"? If so, why do you think they'd be ineffective? Thanks, Scott From gih at apnic.net Thu Mar 6 16:26:56 2008 From: gih at apnic.net (Geoff Huston) Date: Fri, 07 Mar 2008 08:26:56 +1100 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> Message-ID: <47D061A0.4040104@apnic.net> Tony Li wrote: > > |It is probably worthwhile remembering that (at least in the ARIN case) > |we're talking about life after the exhaustion of the IANA IPv4 free > |pool. The definition of "hoarding" will likely be subject to some > |debate. > | > |For example, there is a well known university sitting on a /8. Is > |that hoarding? > > > Of course not. But say if Warren Buffet decided to buy up every prefix, > drive up prices and then dole them out with an eye dropper, that would > distort the market. And drive the industry to IPv6 deployment. Geoff From gih at apnic.net Thu Mar 6 16:43:33 2008 From: gih at apnic.net (Geoff Huston) Date: Fri, 07 Mar 2008 08:43:33 +1100 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> Message-ID: <47D06585.2020402@apnic.net> Tom Vest wrote: > > Anyone who assumes the kind of operator behavior that makes markets > absolutely inevitable, should also assume that hoarding for > profiteering or simply to keep down the competition will be the norm. > Anyone who assumes the kind of operator behavior that makes markets > absolutely inevitable, should also assume that any countervailing > rules that can be easily bypassed without consequence (i.e., > "ineffective" rules) will be ignored. But whats the goal here Tom? We all share a common view that post unallocated pool exhaustion there will be aa period where demand outstrips supply and in a market situation the price of IPv4 escalates, while the price of IPv6 remains relative constant and relatively insignificant. Ultimately consumers are exposed to the price differential as is conventional when prices of supply shift, and it is reasonable to anticipate that most consumders would express a preference for a lower priced service. Perhaps the objective here is NOT "to try and construct a perfect Ipv4 market". Perhaps it is more along the lines of "to try and expose some basic economic signals about the relative scarcity of Ipv4 and Ipv6 addresses to provide more direct and focussed impetus for industry-wide IPv6 adoption" Geoff From tvest at pch.net Thu Mar 6 16:55:21 2008 From: tvest at pch.net (Tom Vest) Date: Thu, 6 Mar 2008 16:55:21 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47D061A0.4040104@apnic.net> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <47D061A0.4040104@apnic.net> Message-ID: On Mar 6, 2008, at 4:26 PM, Geoff Huston wrote: > Tony Li wrote: >> >> |It is probably worthwhile remembering that (at least in the ARIN >> case) >> |we're talking about life after the exhaustion of the IANA IPv4 free >> |pool. The definition of "hoarding" will likely be subject to some >> |debate. >> | >> |For example, there is a well known university sitting on a /8. Is >> |that hoarding? >> >> >> Of course not. But say if Warren Buffet decided to buy up every >> prefix, >> drive up prices and then dole them out with an eye dropper, that >> would >> distort the market. > > And drive the industry to IPv6 deployment. > > Geoff I think we all wish this is how things will go. But it could just as easily go the other way, and either vector could easily be pre-empted by major unwelcome surprises. Randy's very educational demonstrations have revealed that there's a long way to go before anything is 100% certain. In the mean time, new entrants are not going to be the ones to pioneer this effort, because they'd still have to wait for the big guys to get their act together in order to be able to benefit much from entering the business. So if anyone is to lead, it will be the big guys. Do we believe that they're holding out until they know they can monetize their future IPv4 surplus assets? Do we believe that they're simply unable to afford the transition unless they can extract large sums from the IPv4 trade? Who is going to provide those sums, if not other big operators? Or do we think that adding a seven digit number to the cost of starting up will fill the gap without sparking internal rebellions and external interventions? One could also say that OPEC and increasing "real" oil scarcity is leading to the adoption of hydrogen fuel cell technology. In fact one could have said that back in the early 1970s too; we could still be saying in 20-30 years from now. Burning bridges behind you when the future is still uncertain just doesn't seem like prudent planning to me... TV From Ed.Lewis at neustar.biz Thu Mar 6 16:01:07 2008 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 6 Mar 2008 16:01:07 -0500 Subject: [ppml] Lame Delegations In-Reply-To: <47CFFF43.5080608@arin.net> References: <47CFFF43.5080608@arin.net> Message-ID: To Mark, If you need a hand, let me know...even if it isn't code I had a hand in. If anyone knows "lame" - it's me. Ed At 9:27 -0500 3/6/08, Member Services wrote: >ARIN has elected to remove the Lame Delegation identification and >notification software from production. Following several months of >periodic issues, ARIN determined it is best to take the software >offline, review, and retest several components. One recent problem >resulted in blank e-mail messages being sent to approximately one >hundred organizations. We apologize for this inconvenience. > >The software is expected to be back online in early April 2008. If >you have any further questions or comments, please contact info at arin.net. > >Regards, > >Mark Kosters >Chief Technology Officer > > >_______________________________________________ >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. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Mail archives, backups. Sometimes I think the true beneficiaries of standards work are the suppliers of disk drives. From gih at apnic.net Thu Mar 6 18:23:04 2008 From: gih at apnic.net (Geoff Huston) Date: Fri, 07 Mar 2008 10:23:04 +1100 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <47D061A0.4040104@apnic.net> Message-ID: <47D07CD8.6070402@apnic.net> Tom Vest wrote: >> >> And drive the industry to IPv6 deployment. >> >> Geoff > > I think we all wish this is how things will go. > But it could just as easily go the other way, and either vector could > easily be pre-empted by major unwelcome surprises. > Randy's very educational demonstrations have revealed that there's a > long way to go before anything is 100% certain. > > In the mean time, new entrants are not going to be the ones to pioneer > this effort, because they'd still have to wait for the big guys to get > their act together in order to be able to benefit much from entering the > business. So if anyone is to lead, it will be the big guys. Do we > believe that they're holding out until they know they can monetize their > future IPv4 surplus assets? Do we believe that they're simply unable to > afford the transition unless they can extract large sums from the IPv4 > trade? Who is going to provide those sums, if not other big operators? > Or do we think that adding a seven digit number to the cost of starting > up will fill the gap without sparking internal rebellions and external > interventions? > > One could also say that OPEC and increasing "real" oil scarcity is > leading to the adoption of hydrogen fuel cell technology. In fact one > could have said that back in the early 1970s too; we could still be > saying in 20-30 years from now. Burning bridges behind you when the > future is still uncertain just doesn't seem like prudent planning to me... About the only time we had a choice in this particular saga was around 4 - 5 years back when the post-bust economic recovery lifted the Ipv4 address consumption rate from around 4 /8's per year to around 10 /8's per year. At that time there was still sufficient space in the unallocated address pool to support a dual stack transition without undue escalation of the pain barrier. But there were no economic signals whereby this could be expressed. The cost of IPv4 deployments continued to fall in unit cost terms so its little wonder than there was no serious deployment of IPv6 - the underlying differential pricing signals were simply not present and IPv6 was additional cost without any incremental revenue opportunities. But, like it or not Tom, the bridge behind us is already in cinders (I suppose I should be thankful that the analogy has moved on from sinking ships, stampedes, and train crashes to burning bridges ! :-) ). However, I find it hard to sift through your words here to extract what you are simply stating as a preferred outcome, so instead let me restate my perspective here. Scarcity in IPv4 addresses will be reflected in price in any market scenario. When demand outstrips supply this is an entirely conventional outcome. The market also has characteristics that lead to expectations of high volatility. Again, this is not uncommon and frankly really cannot be avoided. However, there is a form of substitution that in and of itself is not without cost, but when the price of IPv4 in such a market exceeds the substitution cost of deployment of IPv6 then the market signal regarding IPv6 deployment would be clear to all. So one can either say "the future is this big scary unknown place that we shouldn't tamper with", or you can do what you can to mitigate some of the more destructive potential outcomes and attempt to encourage some of the more beneficial ones. Now if your aim is to make IPv4 last forever then obviously we disagree about what is a net beneficial outcome for this Internet. Geoff From alh-ietf at tndh.net Thu Mar 6 20:13:43 2008 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 6 Mar 2008 17:13:43 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47D07CD8.6070402@apnic.net> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <47D061A0.4040104@apnic.net> <47D07CD8.6070402@apnic.net> Message-ID: <12c201c87ff0$7fc27c70$7f477550$@net> Geoff Huston wrote: > ... > So one can either say "the future is this big scary unknown place that > we shouldn't tamper with", or you can do what you can to mitigate some > of the more destructive potential outcomes and attempt to encourage > some > of the more beneficial ones. Now if your aim is to make IPv4 last > forever then obviously we disagree about what is a net beneficial > outcome for this Internet. "this big scary unknown place" is one of the economic factors that has lead us past the point where we could avoid the looming pain. There is a cost to learning something new, and those that have not learned it will not be able to justify their high salaries in the new world order. This makes it very self-serving to seek out any excuse to maintain the status quo. The warped part of most of these discussions is that they are only concerned with the address-assignment/routing part of the system, and they completely ignore the costs associated with deploying and managing the end-system/application environment. The perception that the edge network can live with only one version is propagated by those in the core that have no concept of what it costs at the edge. There will be an extended period of overlap, despite exhaustion of the free pool. The space will fragment, with or without transfer policies, and the cost for operating the IPv4 network will rise. This will happen no matter what the price is for a block of space. While I agree there needs to be a mechanism to keep the records straight, it is not at all clear that there is any way to impose a historical perspective of 'need' onto a trading market. For starters, the measure of 'need' is not based on the amount of space, it is on the ability to get that routed. Just as now, a site may need a /30, but if routing says that the smallest thing that will pass a filter is a /24, then the site will not pass the test without inflating their claim to the smallest routable block. If you are really going to spend time on designing a market, design a market for routing slots, then the addressing market will take care of itself. Unfortunately, the RIRs are not in the business of routing, and the big ISPs are more interested in killing off the little guys than building a market that would sustain competition. BGP based TE is a prime example of artificially raising the barrier to entry, and complete fragmentation of the IPv4 pool only magnifies that effect. Before spending too much time on an optimal market design, look at the winners and losers in each scenario, then look at who has influence over which scenario gets picked. When you find the match between those with influence and the scenario where they win, you will know which path we are on... Tony From sleibrand at internap.com Thu Mar 6 20:27:30 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 06 Mar 2008 17:27:30 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <12c201c87ff0$7fc27c70$7f477550$@net> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <47D061A0.4040104@apnic.net> <47D07CD8.6070402@apnic.net> <12c201c87ff0$7fc27c70$7f477550$@net> Message-ID: <47D09A02.6090707@internap.com> Tony Hain wrote: > While I agree there needs to be a mechanism to keep the records straight, it > is not at all clear that there is any way to impose a historical perspective > of 'need' onto a trading market. For starters, the measure of 'need' is not > based on the amount of space, it is on the ability to get that routed. Not exclusively. At the low end, what you say (and the example you give) is correct. But most IPs are not used by organizations getting a /24 to multihome. They are being used by actual devices (computers, home NAT boxes, whatever) with a single public IP per device. > Just as now, a site may need a /30, but if routing says that the smallest thing > that will pass a filter is a /24, then the site will not pass the test > without inflating their claim to the smallest routable block. If you are > really going to spend time on designing a market, design a market for > routing slots, then the addressing market will take care of itself. > > Unfortunately, the RIRs are not in the business of routing Exactly. I have designed a routing slot market, and I'm sure you've designed several (and spent more time on it than I). That isn't sufficient, though, since you and I have no leverage to actually implement such a market. So, given that we can create an IPv4 transfer market, and we can't create a routing slot market, I think it behooves us to do the former in such a way as to permit the latter to be done later, if and when it's needed. But I think we need to design our IPv4 transfer market in such a way as to manage externalities through policy until such a time as they can be managed directly through other mechanisms. > Before spending too much time on an optimal market design, look at the > winners and losers in each scenario, then look at who has influence over > which scenario gets picked. When you find the match between those with > influence and the scenario where they win, you will know which path we are > on... That sounds rather fatalistic, but another reading is that all of us have a great deal of influence over which scenario gets picked (through the public policy process), so we should do our best to pick the best one (i.e. the one with the most winners and fewest losers). -Scott From tvest at pch.net Thu Mar 6 22:19:30 2008 From: tvest at pch.net (Tom Vest) Date: Thu, 6 Mar 2008 22:19:30 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47D05D88.4050400@internap.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D05D88.4050400@internap.com> Message-ID: <23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net> On Mar 6, 2008, at 4:09 PM, Scott Leibrand wrote: > Tom Vest wrote: >> If the largest ISPs rush out and buy up as much IPv4 as they can >> today, in anticipation of "need" they know they'll have in the >> future -- but also thereby get out ahead other operators that >> also have "need" today -- isn't that a kind of hoarding? When any >> buying today exceeds "need" today, it has a distorting -- >> inflationary and anticompetitive -- effect regardless of whether >> that was the primary goal or just a convenient side-effect. >> Anyone who assumes the kind of operator behavior that makes >> markets absolutely inevitable, should also assume that hoarding >> for profiteering or simply to keep down the competition will be >> the norm. Anyone who assumes the kind of operator behavior that >> makes markets absolutely inevitable, should also assume that any >> countervailing rules that can be easily bypassed without >> consequence (i.e., "ineffective" rules) will be ignored. > > This is definitely one of the problems we're trying to avoid with > the conditions in the transfer policy proposal. It's clear to me > that ARIN's current need-based policies are doing a good job of > preventing ISPs from rushing out and getting (for free) a lot more > IPv4 addresses than they need, so I believe that requiring similar > justification to get IPv4 addresses via transfer will also work well. > > Do you see any of transfer conditions in the proposal as > "countervailing rules that can be easily bypassed without > consequence (i.e., "ineffective" rules)"? If so, why do you think > they'd be ineffective. An excellent question. First the deductive answer. Every claim that I've ever heard that a decentralized, every-operator-for-itself resource transfer policy is inevitable starts with the assertion that any rule (and any rulemaker) that gets in the way of maximum self-help will be irrelevant in the post-free pool world. Perhaps some people quietly believe that address resources should always have been available only to the highest bidder, but I've never heard anyone admit to that belief, now or in the past. In any case, on this view any of the proposed transfer rules that actually did anything, i.e., that stood to actually impede any operator from obtaining any address resource that they could pay for at any time, would be ignored regardless of the consequences. Now the "real world" answer. If RIR-rooted sidr is universally adopted and continues to be used by all RIR members, then for as long as that remains true it's possible to imagine that non-compliant transactions between two RSA signatories might have "consequences." It's much harder to imagine what consequence noncompliance could possibly have in any other context (e.g., legacy -> RSA, RSA -> legacy, legacy -> legacy). Do you think that legacy and non-RSA signatories will forebear from advertising or selling address space to "unqualified" RIR members for a little extra? What would prevent them from doing so? How credible is even that one (RSA->RSA transactions) kind of assurance? If everyone that advocated markets also publicly embraced sidr, and was keen to implement sidr as a prerequisite to engaging the market, then I would find it easier to believe that enthusiasm for markets and willingness to abide by market-limiting rules are correlated attitudes. In practice, enthusiasm for one often seems to be associated with deep antipathy for the other. Why won't voluntary compliance "just work" as it largely has under the old RIR system? I think that operators and the RIRs have been most effective at sustaining "voluntary compliance" or ("voluntary coordination" if you prefer) in cases where compliance has been easy/ reflexive/automatic, and/or not entirely voluntary. I think that much has depended on the long-term relationship/membership model, which in turn has been predicated on the incremental, needs-based delegation of number resources over time. PDP input and feedback, maintenance of whois, the preservation of at least some common interests among large operators, small operators, new entrants, and entrants-to-be through the "needs-based" allocation rules, and the notion of "membership" itself, along with the ability to collect fees to maintain services (and reaffirm contact info) -- most or all of these one might think are "naturally" aligned with individual operator self-interest -- but most didn't work at all until CIDR + RIRs provided the glue to hold it all together. I think whois provides a good benchmark. Most people seem to think that the quality of whois is fairly low. Most would say that data quality (completeness + accuracy) is substantially higher among current RSA signatories, but low among legacy resource holders (with a few giant/obvious exceptions). Setting aside for a moment the "actual facts", why do people believe this? Assuming that the facts largely bear this out, I would reckon that the gap between actual and "perfect" data quality, and the delta between RSA signatories and legacies provides some indication of the *max upper threshold* of compliance that one might realistically expect. After all, when the cost of compliance is so very low, but many people still decline to go along, then how much lower is it going to be when the stakes are very very high? I'll wrap by simply stating that even if all of the above proves to be wrong or fixable, and the market works "perfectly" but effectively prices aspiring new entrants out of the industry, then I believe that would be grounds enough to reject it. An RIR may avoid antitrust scrutiny by divesting all interest and involvement in delegation transactions, but that antitrust scrutiny will only be diverted to the industry as a whole. We already know that a single disaffected community member can exact a heavy toll on the entire system, and that external allies are standing by to assist when it serves their own interests. We'd better get ready for lots of them... TV From tvest at pch.net Thu Mar 6 22:55:01 2008 From: tvest at pch.net (Tom Vest) Date: Thu, 6 Mar 2008 22:55:01 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47D07CD8.6070402@apnic.net> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <47D061A0.4040104@apnic.net> <47D07CD8.6070402@apnic.net> Message-ID: On Mar 6, 2008, at 6:23 PM, Geoff Huston wrote: > Tom Vest wrote: > >>> >>> And drive the industry to IPv6 deployment. >>> >>> Geoff >> I think we all wish this is how things will go. >> But it could just as easily go the other way, and either vector >> could easily be pre-empted by major unwelcome surprises. >> Randy's very educational demonstrations have revealed that there's >> a long way to go before anything is 100% certain. >> In the mean time, new entrants are not going to be the ones to >> pioneer this effort, because they'd still have to wait for the big >> guys to get their act together in order to be able to benefit much >> from entering the business. So if anyone is to lead, it will be >> the big guys. Do we believe that they're holding out until they >> know they can monetize their future IPv4 surplus assets? Do we >> believe that they're simply unable to afford the transition unless >> they can extract large sums from the IPv4 trade? Who is going to >> provide those sums, if not other big operators? Or do we think >> that adding a seven digit number to the cost of starting up will >> fill the gap without sparking internal rebellions and external >> interventions? >> One could also say that OPEC and increasing "real" oil scarcity is >> leading to the adoption of hydrogen fuel cell technology. In fact >> one could have said that back in the early 1970s too; we could >> still be saying in 20-30 years from now. Burning bridges behind >> you when the future is still uncertain just doesn't seem like >> prudent planning to me... > > About the only time we had a choice in this particular saga was > around 4 - 5 years back when the post-bust economic recovery lifted > the Ipv4 address consumption rate from around 4 /8's per year to > around 10 /8's per year. At that time there was still sufficient > space in the unallocated address pool to support a dual stack > transition without undue escalation of the pain barrier. But there > were no economic signals whereby this could be expressed. The cost > of IPv4 deployments continued to fall in unit cost terms so its > little wonder than there was no serious deployment of IPv6 - the > underlying differential pricing signals were simply not present and > IPv6 was additional cost without any incremental revenue > opportunities. > > But, like it or not Tom, the bridge behind us is already in cinders > (I suppose I should be thankful that the analogy has moved on from > sinking ships, stampedes, and train crashes to burning > bridges ! :-) ). However, I find it hard to sift through your words > here to extract what you are simply stating as a preferred outcome, > so instead let me restate my perspective here. I believe that there are still credible alternatives to a decentralized market that could do better on all of the important short-term fronts: sustain some level of IPv4 liquidity (mostly for new entrants, 6/4 gateways, xTRs, etc.), keep the industry open to new entrants, preserve needs-based allocation principles, preserve the central registry function, resist internal manipulation and external intervention, etc. -- to basically do all of the things necessary to sustain an orderly, incremental, self-governed (i.e., "successful") transition. For me that is the only goal that matters. > Scarcity in IPv4 addresses will be reflected in price in any market > scenario. Yes. But your statement is a restricted form of the incontrovertible general fact: scarcity will affect availability in any/every kind of system for allocating values, including "markets". > When demand outstrips supply this is an entirely conventional outcome. Markets are not inevitable. Demand for IPv4 outstripped "sustainable supply" at almost every moment since it was invented. Why weren't markets for Class B space inevitable back the last time we visited this territory? > The market also has characteristics that lead to expectations of > high volatility. Again, this is not uncommon and frankly really > cannot be avoided. If markets lead to high volatility, but other allocation systems may not, then does it make sense to just accept volatility as inevitable? Who benefits from volatility? If markets also lead to expectations of loss of other important collateral values (e.g., openness, industry solidarity/competence, independence, etc.), who benefits from that? > However, there is a form of substitution that in and of itself is > not without cost, but when the price of IPv4 in such a market > exceeds the substitution cost of deployment of IPv6 then the market > signal regarding IPv6 deployment would be clear to all. My concern is that there is a very high probability that the "critical infrastructure self-governance failure" signal will be much clearer to a much broader audience long before the other kind of signal percolates up and down far enough. > So one can either say "the future is this big scary unknown place > that we shouldn't tamper with", or you can do what you can to > mitigate some of the more destructive potential outcomes and > attempt to encourage some of the more beneficial ones. Oh I agree 100%, and am acting on that belief, just as I believe you are. We just seem to be scared and reassured by different things. > Now if your aim is to make IPv4 last forever then obviously we > disagree about what is a net beneficial outcome for this Internet. Come on Geoff ;-) I am not going to tax the patience/credulity of the audience by insinuating that you have some silly or sinister ulterior motive. But I will look forward to continuing the discussion, and hopefully contribute to some set of policies that we can have (some)(more) confidence in. TV From sleibrand at internap.com Thu Mar 6 23:03:05 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 06 Mar 2008 20:03:05 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <47D061A0.4040104@apnic.net> <47D07CD8.6070402@apnic.net> Message-ID: <47D0BE79.9090508@internap.com> Tom Vest wrote: > I believe that there are still credible alternatives to a > decentralized market that could do better on all of the important > short-term fronts: sustain some level of IPv4 liquidity (mostly for > new entrants, 6/4 gateways, xTRs, etc.), keep the industry open to > new entrants, preserve needs-based allocation principles, preserve > the central registry function, resist internal manipulation and > external intervention, etc. -- to basically do all of the things > necessary to sustain an orderly, incremental, self-governed (i.e., > "successful") transition. For me that is the only goal that matters. I think we agree on the goal, but I'm not aware of the credible alternatives of which you speak. Could you enumerate some of them so we can discuss whether there are truly viable alternatives to a market? A lot of us are advocating a market approach because we don't see any better alternatives. Thanks, Scott From McNuttJ at missouri.edu Thu Mar 6 23:07:34 2008 From: McNuttJ at missouri.edu (McNutt, Justin M.) Date: Thu, 6 Mar 2008 22:07:34 -0600 Subject: [ppml] Lame Delegations In-Reply-To: References: <47CFFF43.5080608@arin.net> Message-ID: Interesting. I wasn't aware that anyone other than me had attempted to address this issue. Even if we just consider the reverse name space, the number of lame - and RFC1918 - delegations in existence is pretty sad. Couple that with a lack of any kind of automated way to detect the proper contact for an address space (via SOA record or WHOIS data) and you get a nearly intractable problem. Though the general public (me) likely shouldn't have direct programmatic access to WHOIS information (for obvious anti-spam reasons), I should think that ARIN would be in a unique position to have access to this data and be able to respond effectively to both incorrect/unusable contact information as well as lame reverse delegations. As such, I for one would like to see such a project continue. If manpower is the issue, I submit myself as a resource. Put generally, I see a widespread lack of knowledge of how DNS works, to the point that I am honestly amazed that it works at all. Any project that serves to make the overall system better AND educate DNS admins is worth my personal time and effort. We will soon be hiring another tech capable of light programming duties, and I'd be willing to donate some of *his* time as well. Let us know if we can help. Thx! --J > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Edward Lewis > Sent: Thursday, March 06, 2008 3:01 PM > To: Member Services > Cc: ppml at arin.net > Subject: Re: [ppml] Lame Delegations > > To Mark, > > If you need a hand, let me know...even if it isn't code I had > a hand in. > > If anyone knows "lame" - it's me. > > Ed > > At 9:27 -0500 3/6/08, Member Services wrote: > >ARIN has elected to remove the Lame Delegation identification and > >notification software from production. Following several months of > >periodic issues, ARIN determined it is best to take the software > >offline, review, and retest several components. One recent problem > >resulted in blank e-mail messages being sent to approximately one > >hundred organizations. We apologize for this inconvenience. > > > >The software is expected to be back online in early April 2008. If > >you have any further questions or comments, please contact > info at arin.net. > > > >Regards, > > > >Mark Kosters > >Chief Technology Officer > > > > > >_______________________________________________ > >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. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > -=-=-=-=-=-=- > Edward Lewis > +1-571-434-5468 > NeuStar > > Mail archives, backups. Sometimes I think the true beneficiaries of > standards work are the suppliers of disk drives. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at > info at arin.net if you experience any issues. > From sleibrand at internap.com Thu Mar 6 23:29:25 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 06 Mar 2008 20:29:25 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D05D88.4050400@internap.com> <23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net> Message-ID: <47D0C4A5.3000402@internap.com> Tom Vest wrote: > Now the "real world" answer. If RIR-rooted sidr is universally adopted > and continues to be used by all RIR members, then for as long as that > remains true it's possible to imagine that non-compliant transactions > between two RSA signatories might have "consequences." It's much harder > to imagine what consequence noncompliance could possibly have in any > other context (e.g., legacy -> RSA, RSA -> legacy, legacy -> legacy). Do > you think that legacy and non-RSA signatories will forebear from > advertising or selling address space to "unqualified" RIR members for a > little extra? What would prevent them from doing so? I think the main reason legitimate transfers (ones recognized by the recognized authority on who holds a resource, the RIR) will be favored by most potential participants due to the reduced risk of using such a system. For example, if I need IPv4 space after exhaustion, I could either go to ARIN, demonstrate to them that I need the space, and have access to a centralized listing service of transferors, all of whom ARIN has vouched for as being the legitimate holders of the addresses they're transferring. Or, I could go to some other black market, where I have no assurance that the organization I'm "buying" the addresses from is the legitimate holder of those addresses, and that they haven't or won't "sell" the same addresses to someone else in addition to me. I also have no way to update the authoritative registry if I "buy" the addresses on the black market, and therefore I have a harder time demonstrating (to my ISP or more importantly my customers) that I have any legitimate claim to the space. > I think whois provides a good benchmark. Most people seem to think that > the quality of whois is fairly low. Most would say that data quality > (completeness + accuracy) is substantially higher among current RSA > signatories, but low among legacy resource holders (with a few > giant/obvious exceptions). Setting aside for a moment the "actual > facts", why do people believe this? Assuming that the facts largely bear > this out, I would reckon that the gap between actual and "perfect" data > quality, and the delta between RSA signatories and legacies provides > some indication of the *max upper threshold* of compliance that one > might realistically expect. After all, when the cost of compliance is so > very low, but many people still decline to go along, then how much lower > is it going to be when the stakes are very very high? I think that a legitimate transfer market will actually result in a large improvement in the quality of records reflected in whois. In order for an address holder to transfer addresses, they'll first need to demonstrate to ARIN that they are the legitimate holder of those addresses (through documentation of their relationship to the original recipient listed in whois), and then sign an RSA or legacy RSA. I anticipate that this will prompt a large number of resource holders to update out-of-date contact information, and will prompt a number of legacy holders to sign legacy RSAs. > I'll wrap by simply stating that even if all of the above proves to be > wrong or fixable, and the market works "perfectly" but effectively > prices aspiring new entrants out of the industry, then I believe that > would be grounds enough to reject it. I don't anticipate that a market will price out new entrants. In fact, I favor the transfer policy proposal precisely because it provides an avenue for new and growing networks who need IPv4 space to get it after free pool exhaustion. In my opinion, the supply curve for IPv4 addresses will be somewhat elastic, meaning that as the price goes up many IPv4 address holders will begin to free up IPv4 addresses and make them available. Demand will be elastic as well (quantity demanded will go down as the price increases), but I think supply will be more elastic than demand simply because there are so many netblocks out there already, so address conservation efforts will have more effect on freeing up supply to be transferred than on reducing the demands for new space. -Scott From mksmith at adhost.com Fri Mar 7 00:09:18 2008 From: mksmith at adhost.com (Michael Smith) Date: Thu, 6 Mar 2008 21:09:18 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47D0C4A5.3000402@internap.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D05D88.4050400@internap.com> <23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net> <47D0C4A5.3000402@internap.com> Message-ID: <1A97CDA0-3ABC-4567-A7F7-C07B3BEE94E8@adhost.com> Hello Scott: On Mar 6, 2008, at 8:29 PM, Scott Leibrand wrote: > >> I think whois provides a good benchmark. Most people seem to think >> that >> the quality of whois is fairly low. Most would say that data quality >> (completeness + accuracy) is substantially higher among current RSA >> signatories, but low among legacy resource holders (with a few >> giant/obvious exceptions). Setting aside for a moment the "actual >> facts", why do people believe this? Assuming that the facts largely >> bear >> this out, I would reckon that the gap between actual and "perfect" >> data >> quality, and the delta between RSA signatories and legacies provides >> some indication of the *max upper threshold* of compliance that one >> might realistically expect. After all, when the cost of compliance >> is so >> very low, but many people still decline to go along, then how much >> lower >> is it going to be when the stakes are very very high? > > I think that a legitimate transfer market will actually result in a > large improvement in the quality of records reflected in whois. In > order for an address holder to transfer addresses, they'll first > need to > demonstrate to ARIN that they are the legitimate holder of those > addresses (through documentation of their relationship to the original > recipient listed in whois), and then sign an RSA or legacy RSA. I > anticipate that this will prompt a large number of resource holders to > update out-of-date contact information, and will prompt a number of > legacy holders to sign legacy RSAs. > I think that the legacy holders with a sense of the Internet "community' have already returned, or are in the process of actively returning their unused space. I don't think we should even worry about the rest of those folks because I can't think of a single reason it is in their best interests to return their space, given the present state of ARIN policy. >> I'll wrap by simply stating that even if all of the above proves to >> be >> wrong or fixable, and the market works "perfectly" but effectively >> prices aspiring new entrants out of the industry, then I believe that >> would be grounds enough to reject it. > > I don't anticipate that a market will price out new entrants. In > fact, > I favor the transfer policy proposal precisely because it provides an > avenue for new and growing networks who need IPv4 space to get it > after > free pool exhaustion. > > In my opinion, the supply curve for IPv4 addresses will be somewhat > elastic, meaning that as the price goes up many IPv4 address holders > will begin to free up IPv4 addresses and make them available. Demand > will be elastic as well (quantity demanded will go down as the price > increases), but I think supply will be more elastic than demand simply > because there are so many netblocks out there already, so address > conservation efforts will have more effect on freeing up supply to be > transferred than on reducing the demands for new space. If a consortium is formed of the holder of legacy space, in particular, then supply will be regulated by the consortium, not by market forces. Then, if they're smart, they will regulate prices to the highest level the market will bear and sell them off a bit at a time. Think OPEC. The only way to make any of this a moot point is to make IPv4 irrelevant because IPv6 is fully embraced by the community. One way or the other, ARIN will lose control of the IPv4 space, whether by natural deprecation in favor of IPv6 or by continuous end-runs around ARIN policy through legal and illegal means. Unless ARIN wants to spend a large portion of its budget in legal battles my guess is there is not very much we can do. I know that ARIN says that they/we don't support one protocol over another, but it seems to me that we spend an inordinate amount of time working on policies that continue to buttress IPv4 with no comparative policies in "support of" IPv6. If ARIN doesn't support IPv6 then who will? If we don't make the ARIN community believe IPv6 is coming and that ARIN is more concerned with promoting IPv6 than trying to breath a little extra life into IPv4 then who will? It seems to me that the policy direction seems to be overly concerned with the latter. Regards, Mike From drc at virtualized.org Fri Mar 7 00:12:41 2008 From: drc at virtualized.org (David Conrad) Date: Thu, 6 Mar 2008 21:12:41 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47CF92AE.7070806@apnic.net> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org> <47CF92AE.7070806@apnic.net> Message-ID: <054258CF-4B5D-4A1B-98BA-35E26EC386C9@virtualized.org> Geoff, On Mar 5, 2008, at 10:43 PM, Geoff Huston wrote: > Some folk may be of the view that IPv4 + NATs is a long term viable > proposition, and may believe that in such a long term scenario the > value of IPv4 addresses may rise steadily over time. ... > Others may be of the view that one of the major elements in an IPv6 > transition is the incentive to stop deploying IPv4 and that may well > be based in an escalating value of IPv4 addresses, which would > increasingly provide economic incentives for entities to deploy IPv6 > as their mainstream technology base with minimal IPv4 translation > services. ... > Personally, I would tend to the first view - that escalating price > in an Ipv4 address market would rapidly drive the industry into IPv6. I think you meant that you tend to the second view. :-) I would agree this scenario is far preferable to the first. What actually comes about is, of course, hard to determine at this point in time. I personally believe that policies should be explicitly oriented towards promotion of the second view as one outcome of transfers could be a market encouraging increased address space utilization efficiency via NATs, which could reduce the pressure for IPv6 deployment. > I'd hardly characterize the APNIC policy proposal in such dramatic > terms. I thought the motto of RIR policy discussions was characterized by the following quote: "A little rudeness and disrespect can elevate a meaningless interaction to a battle of wills and add drama to an otherwise dull day." -- Calvin & Hobbes :-) > The APNIC model as it stands leaves the operation of any associated > market to the industry players themselves. I understand and in general agree with this approach. However, the implication of minimal constraint/regulation is that it gives actors free reign to pursue what they believe to be their best interests without regard to the more global implications of their actions. For example, as I understand it (correct me if I'm wrong), nothing in APNIC policy proposal deters (say) NIRs from efforts to corner the market for their members nor would it appear to discourage a raiding party from Sweden in Viking Long Boats to become an APNIC member and start acquiring address space for use elsewhere. To be clear, I am not necessarily saying this will happen, rather I was describing what I saw as extremes in the spectrum of the current proposals. Regards, -drc From sleibrand at internap.com Fri Mar 7 00:31:02 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 06 Mar 2008 21:31:02 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <1A97CDA0-3ABC-4567-A7F7-C07B3BEE94E8@adhost.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D05D88.4050400@internap.com> <23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net> <47D0C4A5.3000402@internap.com> <1A97CDA0-3ABC-4567-A7F7-C07B3BEE94E8@adhost.com> Message-ID: <47D0D316.5090006@internap.com> Michael Smith wrote: > Hello Scott: > > On Mar 6, 2008, at 8:29 PM, Scott Leibrand wrote: > >> I think that a legitimate transfer market will actually result in a >> large improvement in the quality of records reflected in whois. In >> order for an address holder to transfer addresses, they'll first need to >> demonstrate to ARIN that they are the legitimate holder of those >> addresses (through documentation of their relationship to the original >> recipient listed in whois), and then sign an RSA or legacy RSA. I >> anticipate that this will prompt a large number of resource holders to >> update out-of-date contact information, and will prompt a number of >> legacy holders to sign legacy RSAs. >> > I think that the legacy holders with a sense of the Internet "community' > have already returned, or are in the process of actively returning their > unused space. I don't think we should even worry about the rest of > those folks because I can't think of a single reason it is in their best > interests to return their space, given the present state of ARIN policy. I didn't say anything about community-minded legacy holders returning space to ARIN. I was talking about profit-minded legacy holders contacting ARIN to update their records and sign legacy RSAs, so they could then turn around and transfer some of the IPv4 addresses they hold to parties needing (and willing to pay) for them. >> In my opinion, the supply curve for IPv4 addresses will be somewhat >> elastic, meaning that as the price goes up many IPv4 address holders >> will begin to free up IPv4 addresses and make them available. Demand >> will be elastic as well (quantity demanded will go down as the price >> increases), but I think supply will be more elastic than demand simply >> because there are so many netblocks out there already, so address >> conservation efforts will have more effect on freeing up supply to be >> transferred than on reducing the demands for new space. > > If a consortium is formed of the holder of legacy space, in particular, > then supply will be regulated by the consortium, not by market forces. > Then, if they're smart, they will regulate prices to the highest level > the market will bear and sell them off a bit at a time. Think OPEC. That's a mighty big *if*. Generally suppliers in markets compete rather than collude, particularly when the number of suppliers is large, and each supplier controls a small fraction of supply. Those conditions are both met in this case: no address holder controls more than 1% of the IPv4 addresses, and there are thousands of different holders who might participate in the market. > > The only way to make any of this a moot point is to make IPv4 irrelevant > because IPv6 is fully embraced by the community. One way or the other, > ARIN will lose control of the IPv4 space, whether by natural deprecation > in favor of IPv6 or by continuous end-runs around ARIN policy through > legal and illegal means. Unless ARIN wants to spend a large portion of > its budget in legal battles my guess is there is not very much we can do. I think everyone is fully in favor of making IPv4 irrelevant through widespread adoption of IPv6. It's just a question of how quickly that can happen, and how we can make the transition less painful and costly for everyone involved. I believe that a transfer policy is necessary to get us from here to there as smoothly as possible. > I know that ARIN says that they/we don't support one protocol over > another, but it seems to me that we spend an inordinate amount of time > working on policies that continue to buttress IPv4 with no comparative > policies in "support of" IPv6. If ARIN doesn't support IPv6 then who > will? If we don't make the ARIN community believe IPv6 is coming and > that ARIN is more concerned with promoting IPv6 than trying to breath a > little extra life into IPv4 then who will? It seems to me that the > policy direction seems to be overly concerned with the latter. > I think the reason you don't see much policy work on IPv6 is that there aren't a lot of problems with IPv6 policy. Since there's no shortage of IPv6 addresses, we have the liberty of a very liberal IPv6 policy, providing huge blocks of addresses to just about any applicant who asks. If you can identify any policy areas where ARIN could better support IPv6, please share them. I for one believe we've addressed all the issues identified to date. -Scott From gih at apnic.net Fri Mar 7 00:38:26 2008 From: gih at apnic.net (Geoff Huston) Date: Fri, 07 Mar 2008 16:38:26 +1100 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <054258CF-4B5D-4A1B-98BA-35E26EC386C9@virtualized.org> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org> <47CF92AE.7070806@apnic.net> <054258CF-4B5D-4A1B-98BA-35E26EC386C9@virtualized.org> Message-ID: <47D0D4D2.4030909@apnic.net> David Conrad wrote: > Geoff, > > On Mar 5, 2008, at 10:43 PM, Geoff Huston wrote: >> Some folk may be of the view that IPv4 + NATs is a long term viable >> proposition, and may believe that in such a long term scenario the >> value of IPv4 addresses may rise steadily over time. > > ... >> Others may be of the view that one of the major elements in an IPv6 >> transition is the incentive to stop deploying IPv4 and that may well >> be based in an escalating value of IPv4 addresses, which would >> increasingly provide economic incentives for entities to deploy IPv6 >> as their mainstream technology base with minimal IPv4 translation >> services. > ... >> Personally, I would tend to the first view - that escalating price in >> an Ipv4 address market would rapidly drive the industry into IPv6. > > I think you meant that you tend to the second view. :-) just as well I added the extra text then - yes I can see escalating IPv4 prices providing clear price signals to players about the relative costs of Ipv4 and Ipv6 deployments > > I would agree this scenario is far preferable to the first. What > actually comes about is, of course, hard to determine at this point in > time. obviously. I personally believe that policies should be explicitly oriented > towards promotion of the second view as one outcome of transfers could > be a market encouraging increased address space utilization efficiency > via NATs, which could reduce the pressure for IPv6 deployment. Yes, I think we are on much the same page here. I can't see much point in attempting to suppress or distort an otherwise clear signal of scarcity by creating artificial impediments. Not only does it call into question the legitimacy of the party attempting to impose such constraints, and raise the question of whether such impositions should be accepted by the actors, it seems to me that it leads to no particularly useful space. > >> I'd hardly characterize the APNIC policy proposal in such dramatic terms. > > I thought the motto of RIR policy discussions was characterized by the > following quote: > > "A little rudeness and disrespect can elevate a meaningless interaction > to a battle of wills and add drama to an otherwise dull day." > -- Calvin & Hobbes > > :-) Well, in that case I'm obviously indebted to your dramatic contribution :-) > >> The APNIC model as it stands leaves the operation of any associated >> market to the industry players themselves. > > I understand and in general agree with this approach. > > However, the implication of minimal constraint/regulation is that it > gives actors free reign to pursue what they believe to be their best > interests without regard to the more global implications of their > actions. You know, I have this suspicion thats what this industry does best, and has perfected this approach with more than a century of practice. Indeed thats what I thought was encompassed in a economic study of this situation where we have managed to get to where we are now by precisely this behaviour of each actor diligently pursuing their (of their shareholders') interests. For example, as I understand it (correct me if I'm wrong), > nothing in APNIC policy proposal deters (say) NIRs from efforts to > corner the market for their members nor would it appear to discourage a > raiding party from Sweden in Viking Long Boats to become an APNIC member > and start acquiring address space for use elsewhere. This is correct - The proposal states that as long as the parties are members of APNIC, and the resource is a current resource in the APNIC database then APNIC will recognise a transfer of resource holding between the two parties. Geoff From drc at virtualized.org Fri Mar 7 00:51:20 2008 From: drc at virtualized.org (David Conrad) Date: Thu, 6 Mar 2008 21:51:20 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47CF2CD3.6090706@internap.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF2CD3.6090706@internap.com> Message-ID: <5BC5F153-9C9B-45D9-9C13-CD62E828191E@virtualized.org> Scott, On Mar 5, 2008, at 3:29 PM, Scott Leibrand wrote: >> What are 'negative impacts'? > > I think you outlined a few of them earlier today, but they would > include the results of a number of different types of speculation > (unnecessary volatile prices, scarcity, etc.), hoarding of addresses > for various reasons (speculation, attempts to starve out > competitors, etc.), and unnecessary deaggregation. With the exception of the last, all of these consequences are part and parcel of the fact that the IPv4 free pool is exhausted. Put enough constraints on transfers and people won't bother. End result: hoarding (for some value of that variable), speculation via a black market, etc. The only thing the policy will have done is decrease ARIN's relevance in the post IPv4 free pool exhaustion world since the registration database will become less and less useful over time. As far as I can tell, the whole point of allowing transfers is to get allocated-but-unused address space back into play. If people hoard or buy it all up as a speculative effort, we're no worse off than we are when the IPv4 free pool is emptied, right? As for unnecessary deaggregation, what is or is not necessary is likely a matter of opinion. I firmly believe ISPs will look after themselves as they have done in the past and are doing so today by applying filters if they feel their infrastructure is at risk. In this particular respect, we've been here before and some folks still have the T-shirts (hopefully they've been washed). I'd be curious to understand why past solutions would not apply. >> I have a couple more fundamental questions: >> a) What is the overarching goal the transfer policy is trying to >> achieve? > > If there were just one goal, this would be easy. We're trying to > ensure the continued availability of IP resources after IPv4 free > pool exhaustion, minimizing disruption, minimizing unnecessary > deaggregation, preserving some level of fairness, etc... By this description, it would seem the policy is attempting to put ARIN in the position of being an arbiter of quite a few thing things it hasn't taken on before, e.g., "fairness" (fair to whom?), "availability" (for whom?), "unnecessary deaggregation" (from whose perspective), etc. I might suggest there are many, many mines in that particular field and that ARIN is not necessarily in the best position to blaze a path there. >> b) What tools exist (or can be expected to exist given reasonable >> time/resources) to enforce that policy? > > The main tool is that, as the recognized authority in registration > of IPv4 addresses in North America, recognition as valid of any > transfers by ARIN has considerable value to both transferors and > transferees. So it would seem a core criteria in any policy would be to minimize effects that would force folks to go elsewhere to have their transfers recognized, no? >> - the 6 month restriction could force folks to go outside the >> policy in desperation (e.g., the amount of address space available >> via transfers is likely to be hard to predict. You could be in a >> situation where at one point in time, the only option is a small >> block even though you know it won't last 6 months. What option do >> you have?) > > You could get PA space from your ISP or another LIR. I am assuming the folks most interested in getting address space will be ISPs so they can continue adding customers. Is the assumption of this policy that the consumers of address space are end users? > The intent of a the transfer policy is that it would ensure the > availability of blocks of all sizes legitimately demanded by > transferees. Therefore, if we do it right, there should always be > an appropriately sized block available at some price. ... > Rather, we hope to prevent the transfer of large numbers of small > blocks when a larger one would do, as we don't want networks to be > cobbling together their IP space from multiple sources and then > being forced to announce extra routes for all the different blocks. I fear the restrictions you are imposing will make it essentially impossible to "do it right" and will result in folks with address space finding other outlets in which to meet the needs of those who need address space. However, perhaps I misjudge the situation. Regards, -drc From tvest at pch.net Fri Mar 7 01:12:21 2008 From: tvest at pch.net (Tom Vest) Date: Fri, 7 Mar 2008 01:12:21 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47D0C4A5.3000402@internap.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D05D88.4050400@internap.com> <23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net> <47D0C4A5.3000402@internap.com> Message-ID: <266485D2-F010-49BB-B576-AFBFE5D329DC@pch.net> On Mar 6, 2008, at 11:29 PM, Scott Leibrand wrote: > Tom Vest wrote: > >> Now the "real world" answer. If RIR-rooted sidr is universally >> adopted and continues to be used by all RIR members, then for as >> long as that remains true it's possible to imagine that non- >> compliant transactions between two RSA signatories might have >> "consequences." It's much harder to imagine what consequence >> noncompliance could possibly have in any other context (e.g., >> legacy -> RSA, RSA -> legacy, legacy -> legacy). Do you think that >> legacy and non-RSA signatories will forebear from advertising or >> selling address space to "unqualified" RIR members for a little >> extra? What would prevent them from doing so? > > I think the main reason legitimate transfers (ones recognized by > the recognized authority on who holds a resource, the RIR) will be > favored by most potential participants due to the reduced risk of > using such a system. For example, if I need IPv4 space after > exhaustion, I could either go to ARIN, demonstrate to them that I > need the space, and have access to a centralized listing service of > transferors, all of whom ARIN has vouched for as being the > legitimate holders of the addresses they're transferring. Okay, all of this holds, but only for (RSA->RSA) transactions, which seem to me to be fairly low probability events until some/many large members are well into IPv6 migration. Of course I could turn out to be wrong, esp. is sidr is very widely adopted by current RSA non- signatories (thereby presumably becoming ARIN members)... > Or, I could go to some other black market, where I have no > assurance that the organization I'm "buying" the addresses from is > the legitimate holder of those addresses, and that they haven't or > won't "sell" the same addresses to someone else in addition to me. > I also have no way to update the authoritative registry if I "buy" > the addresses on the black market, and therefore I have a harder > time demonstrating (to my ISP or more importantly my customers) > that I have any legitimate claim to the space. If it's currently in production, I doubt that there will be many takers. If it's not, then I would reckon that some kind of incremental payment plan (i.e., like the kind the black hats always use in the movies) would solve most of these problems. >> I think whois provides a good benchmark. Most people seem to think >> that the quality of whois is fairly low. Most would say that data >> quality (completeness + accuracy) is substantially higher among >> current RSA signatories, but low among legacy resource holders >> (with a few giant/obvious exceptions). Setting aside for a moment >> the "actual facts", why do people believe this? Assuming that the >> facts largely bear this out, I would reckon that the gap between >> actual and "perfect" data quality, and the delta between RSA >> signatories and legacies provides some indication of the *max >> upper threshold* of compliance that one might realistically >> expect. After all, when the cost of compliance is so very low, but >> many people still decline to go along, then how much lower is it >> going to be when the stakes are very very high? > > I think that a legitimate transfer market will actually result in a > large improvement in the quality of records reflected in whois. In > order for an address holder to transfer addresses, they'll first > need to demonstrate to ARIN that they are the legitimate holder of > those addresses (through documentation of their relationship to the > original recipient listed in whois), and then sign an RSA or legacy > RSA. I think what you mean is, "in order for an address holder to transfer addresses by means of the approved transfer mechanism" ... > I anticipate that this will prompt a large number of resource > holders to update out-of-date contact information, and will prompt > a number of legacy holders to sign legacy RSAs. Although there are probably a few real Rip Van Winkles out there, I think it is more reasonable to assume that most remaining legacy non- signatories are motivated by something other than ignorance of the opportunity to follow the rules. Perhaps the proposed transfer process will achieve such prominence and critical mass that legacy resource holders will waive their self-declared right to do whatever they want with their resources. Perhaps none of them will find it more convenient/profitable to sell around the official mechanism and its rules. I wonder how high "white market" prices will have to go for all of these assumptions to hold true (note: foreshadowing for the new entrants point below)... Perhaps no RSA signatory will be tempted to jump the queue and trawl the gray market. Perhaps all are willing to continue abiding by needs- based allocation rules, even if that means that the wait for address space could be very long. But if that's so, there are probably better mechanisms to leverage this will to coordination that are less risky and volatile and unpredictable... >> I'll wrap by simply stating that even if all of the above proves >> to be wrong or fixable, and the market works "perfectly" but >> effectively prices aspiring new entrants out of the industry, then >> I believe that would be grounds enough to reject it. > > I don't anticipate that a market will price out new entrants. In > fact, I favor the transfer policy proposal precisely because it > provides an avenue for new and growing networks who need IPv4 space > to get it after free pool exhaustion. I concede that Richard Branson will always be able to start a new ISP if he wants to, so in principle the industry will always remain "open" in some trivial sense. The kind of "open" I was referring to was the more functional/pragmatic kind -- i.e., the kind that mollifies internal critics and makes them more likely to identify their interests with community and its institutions rather than an aspiring competitor, the kind that persuades anti-trust authorities to move on, because there's nothing to see here... > In my opinion, the supply curve for IPv4 addresses will be somewhat > elastic, meaning that as the price goes up many IPv4 address > holders will begin to free up IPv4 addresses and make them available. I agree, but I believe that there are better, less volatile, more sustainable methods to leverage that elasticity, so that the needs- based allocation regime and all of the collateral values that have gotten a (largely unnoticed) free ride on it over the last decade can be preserved. > Demand will be elastic as well (quantity demanded will go down as > the price increases), I agree here too, but I believe that there are better, less volatile, more sustainable methods to manage that elasticity so that it is spread across all resource users rather than killing the newest/ smallest first. > but I think supply will be more elastic than demand simply because > there are so many netblocks out there already, (in the gray) > so address conservation efforts will have more effect on freeing up > supply to be transferred than on reducing the demands for new space. We are in 100% agreement here again. The trick is to marshall price signals to induce this kind of behavior sooner rather than later, and to keep the resulting address recirculation process more effectively tied to needs-based delegation principles. So long as the price/heat continues to go up evenly across all resource users, the effects on migration out of v4 should be the same. Given that, all that's really necessary is to keep everyone approximately equally happy/unhappy but *together* through the full (long) transition -- e.g., from gated v4/v6 coexistence to LISP or some other, similarly durable/scalable future arrangement. TV From drc at virtualized.org Fri Mar 7 01:14:05 2008 From: drc at virtualized.org (David Conrad) Date: Thu, 6 Mar 2008 22:14:05 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> Message-ID: <881EF36A-A09A-4606-A52B-71E46DE2120E@virtualized.org> Tony, On Mar 6, 2008, at 10:31 AM, Tony Li wrote: > |It is probably worthwhile remembering that (at least in the ARIN > case) > |we're talking about life after the exhaustion of the IANA IPv4 free > |pool. The definition of "hoarding" will likely be subject to some > |debate. > | > |For example, there is a well known university sitting on a /8. Is > |that hoarding? > > Of course not. It would seem others disagree. > But say if Warren Buffet decided to buy up every prefix, > drive up prices and then dole them out with an eye dropper, that would > distort the market. Very true. I believe one theory is that such a course of action would _strongly_ encourage IPv6 deployment and hence, would not necessarily be a bad thing. The implication being that if you believe IPv6 is the right way to go, minimal restrictions would have the most positive long term effect, albeit it may result in a bit of initial "discomfort"... Regards, -drc From tvest at pch.net Fri Mar 7 01:25:46 2008 From: tvest at pch.net (Tom Vest) Date: Fri, 7 Mar 2008 01:25:46 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47D0D4D2.4030909@apnic.net> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org> <47CF92AE.7070806@apnic.net> <054258CF-4B5D-4A1B-98BA-35E26EC386C9@virtualized.org> <47D0D4D2.4030909@apnic.net> Message-ID: <95F06EFB-BAA6-449F-B020-3E61372A0DBE@pch.net> On Mar 7, 2008, at 12:38 AM, Geoff Huston wrote: > You know, I have this suspicion thats what this industry does best, > and > has perfected this approach with more than a century of practice. > Indeed > thats what I thought was encompassed in a economic study of this > situation where we have managed to get to where we are now by > precisely > this behaviour of each actor diligently pursuing their (of their > shareholders') interests. Sometimes that best practice leads to global or near-global collapse. It has happened twice in our industries/careers already, with costs that I believe you both know well. Sometimes what follows the collapse is better, sometimes it's not that obvious. Regardless, many people and companies suffer badly, for a long time if not permanently. If you wish to claim that this transition poses no such risks, then I will try very hard to just move on to other points. If you acknowledge that risk, however, I think it's worth considering less risky/volatile options. TV From gih at apnic.net Fri Mar 7 01:39:10 2008 From: gih at apnic.net (Geoff Huston) Date: Fri, 07 Mar 2008 17:39:10 +1100 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <95F06EFB-BAA6-449F-B020-3E61372A0DBE@pch.net> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org> <47CF92AE.7070806@apnic.net> <054258CF-4B5D-4A1B-98BA-35E26EC386C9@virtualized.org> <47D0D4D2.4030909@apnic.net> <95F06EFB-BAA6-449F-B020-3E61372A0DBE@pch.net> Message-ID: <47D0E30E.2050508@apnic.net> Tom Vest wrote: > > On Mar 7, 2008, at 12:38 AM, Geoff Huston wrote: > >> You know, I have this suspicion thats what this industry does best, and >> has perfected this approach with more than a century of practice. Indeed >> thats what I thought was encompassed in a economic study of this >> situation where we have managed to get to where we are now by precisely >> this behaviour of each actor diligently pursuing their (of their >> shareholders') interests. > > Sometimes that best practice leads to global or near-global collapse. > It has happened twice in our industries/careers already, with costs that > I believe you both know well. > > Sometimes what follows the collapse is better, sometimes it's not that > obvious. > Regardless, many people and companies suffer badly, for a long time if > not permanently. > > If you wish to claim that this transition poses no such risks, then I > will try very hard to just move on to other points. > > If you acknowledge that risk, however, I think it's worth considering > less risky/volatile options. Tom, as Scott has already requested from you, we haven't seen any other options from you yet! Once the unallocated space is exhausted then if you still want IPv4 addresses you are going to have get addresses from someone who already has them. Now I must admit that the escalation of events from airplane crashes, to ships sinking, to bridges burning to now global collapse is all riveting reading, but lets put this into some realistic proportion. Yes, the situation the this industry has driven itself into is messy, but I'm pretty sure that global collapse is not exactly on the agenda. In such situations you hare going to have a number of responses -some will wait for as long as possible and try to take a lead from others who they think have steered an appropriate course through this. Others will adopt a position of early adoption in the hope that it will lead to an advantaged position as the progress. And others will fall somewhere in between the two. Some of these choices that actors make will play out to the benefit of the actors, other will not. Some vendors will produce product ahead of market demand, most will not. Thats not new news now or in the past. Thats just the way we operate as an industry. What I would claim is that this transition is just another risk factor in an industry that has its fair share already and doubtless will continue to have its fair share in the future. Geoff From jcurran at istaff.org Fri Mar 7 02:59:53 2008 From: jcurran at istaff.org (John Curran) Date: Fri, 7 Mar 2008 02:59:53 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47D0E30E.2050508@apnic.net> References: <292DCB81-EAD1-4774-8913- 998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org> <47CF92AE.7070806@apnic.net> <054258CF-4B5D-4A1B-98BA-35E26EC386C9@virtualized.org> <47D0D4D2.4030909@apnic.net> <95F06EFB-BAA6-449F-B020-3E61372A0DBE@pch.net> <47D0E30E.2050508@apnic.net> Message-ID: At 5:39 PM +1100 3/7/08, Geoff Huston wrote: >Yes, the situation the this industry has driven itself into is messy, but >I'm pretty sure that global collapse is not exactly on the agenda. >... >What I would claim is that this transition is just another risk factor >in an industry that has its fair share already and doubtless will >continue to have its fair share in the future. I'd agree with you if there were anything resembling a useful feedback mechanism on the global routing table. As it is, the only knob available is route filtering, and while that works fine as a tool against needless deaggregation, it really doesn't work well filtering lots of new unique routes from your peers all of which are necessary to cover their new customers... The costs of injecting new routes are borne by third parties (i.e. all other DFZ participants). Without direct predictable routing costs, there is no counter-pressure to fragmentation in the presence of a high demand marketplace. If ISP's continue to attempt to globally connect new customers via IPv4 after depletion, one had best hope they do it by finding and obtaining very large underutilized blocks; the usage model would closely resemble today's RIR-provided blocks, and the resulting routing demand when announced would at least be comparable to today's (manageable) situation. If ISP's can't obtain large blocks post depletion and we instead see customers having to BYOB ("Bring Your Own Block") to get IPv4 connectivity, then new routes will be introduced at a much greater rate, and with very real uncertainty regarding whether these routes will be filtered outside of their originating ISP. Despite such filtering, ISP's are motivated to keep connecting customers and refer connectivity issues to the filtering peer, since such filtering is "voluntarily". Some organizations would consider connections to the majority of the DFZ ISP backbones so that their public servers can have at least one address on the same "Carrier Internet" backbone as any new customer site. That end state isn't global collapse, but it also isn't global connectivity. /John Disclaimer: my opinions only; discard or forward as desired. From gih at apnic.net Fri Mar 7 03:17:53 2008 From: gih at apnic.net (Geoff Huston) Date: Fri, 07 Mar 2008 19:17:53 +1100 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <292DCB81-EAD1-4774-8913- 998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org> <47CF92AE.7070806@apnic.net> <054258CF-4B5D-4A1B-98BA-35E26EC386C9@virtualized.org> <47D0D4D2.4030909@apnic.net> <95F06EFB-BAA6-449F-B020-3E61372A0DBE@pch.net> <47D0E30E.2050508@apnic.net> Message-ID: <47D0FA31.8050105@apnic.net> John Curran wrote: > At 5:39 PM +1100 3/7/08, Geoff Huston wrote: >> Yes, the situation the this industry has driven itself into is messy, but >> I'm pretty sure that global collapse is not exactly on the agenda. >> ... >> What I would claim is that this transition is just another risk factor >> in an industry that has its fair share already and doubtless will >> continue to have its fair share in the future. > > I'd agree with you if there were anything resembling a useful > feedback mechanism on the global routing table. The sad fact is that the global routing table has been under concentrated assault by the legions of /24s for many years now. Since 2001 50% of the routing table is more specifics - and now there are 135,208 of them. My supposition is that TE is the major factor - when you look at highly deaggregated prefixes you tend to see a collection of upstreams and load spreading across the upstreams. So in many ways the routing system is already under this "fragmentation" pressure and will remain so whether its IPv4 or IPv6 (and I suspect at a more meta level, efforts to reintroduce aggregation into the routing system, if adopted would not have much impact in changing the current numbers by very much simply because of these TE pressures). What we route across is the cross product of the number of distinct entites, the level of interconnection between entities and the desired/imposed level of diversity of path. And as the network expands the value of this cross product will rise, transfers, minimum size limits, or any other factor nowithstanding, and the routing table will continue to inflate at a rate that is higher than the number of distinct routing entities. So what I'm saying is that the routing system is an expression of a more basic metric of the network's interconnection, and that this value will be expressed in the routing system irregardless of the particular routing technology and irrespective of the varioous address policies that we may state. As I understand your argument here John its that fragmented address supply won't make it any better, but it could make it worse, and that could trigger responses such as selective filtering, threatening global connectivity. Yes, thats a valid concern. Without much data to quantify the risk its hard to assess how critical this factor will be. Geoff From michael.dillon at bt.com Fri Mar 7 06:06:41 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 7 Mar 2008 11:06:41 -0000 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47D0E30E.2050508@apnic.net> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org><47CF92AE.7070806@apnic.net><054258CF-4B5D-4A1B-98BA-35E26EC386C9@virtualized.org><47D0D4D2.4030909@apnic.net><95F06EFB-BAA6-449F-B020-3E61372A0DBE@pch.net> <47D0E30E.2050508@apnic.net> Message-ID: > Tom, as Scott has already requested from you, we haven't seen > any other options from you yet! Once the unallocated space is > exhausted then if you still want IPv4 addresses you are going > to have get addresses from someone who already has them. Not so. You can also NOT GET ANY new IP addresses, and suffer the consequences. That could mean bankruptcy or it could mean increased costs to transfer to IPv6 in a hurry. The increased costs would mainly be lost opportunities while you fix the problem, and increased churn rates as some customers treat your company like a leper. The fact is that nobody needs to be dependent on new IPv4 addresses after the runout date. There is plenty of time for companies to make their businesses work with a mix of IPv6 and IPv4. There have been some very public demonstrations of this mixture at the last ARIN and NANOG meetings. There will be another demo at the upcoming IETF meeting. So far, if you examine the results of these demonstrations, there are no serious problems that could not be fixed within a two year timeframe. And we do have two years, probably more, to fix these issues. Once it is demonstrably possible to run a fully mixed IPv4 and IPv6 network, the need for transfers disappears. Note that I am not referring here to dual-stack networks. When I say MIXED I mean that you have some endpoints that are IPv4 and some endpoints that are IPV6 and that they can both communicate with each other over infrastructure that has at least one pure IPv6 section in it. > Yes, the situation the this industry > has driven itself into is messy, but I'm pretty sure that > global collapse is not exactly on the agenda. Indeed. The situation is more like the telecom collapse era when companies that were not sufficiently robust went out of business or were bought out or shrunk. This is a good thing for the economy since it is part of the process of natural selection of business models. > What I would claim is that this transition is just another > risk factor in an industry that has its fair share already > and doubtless will continue to have its fair share in the future. Exactly. There is no need for RIRs to take any special actions to prepare for IPv4 runout. No transfer policy is needed. Just keep running the RIR as normal and keep reporting status so that we can see how much time is left. --Michael Dillon Don't forget that ARIN has a wiki with info (and pointers to resources) for network providers who want to add IPv6 to their networks. http://www.getipv6.info From leo.vegoda at icann.org Fri Mar 7 06:26:05 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 7 Mar 2008 03:26:05 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: Message-ID: On 07/03/2008 12:06, "michael.dillon at bt.com" wrote: [...] > Exactly. There is no need for RIRs to take any special actions > to prepare for IPv4 runout. No transfer policy is needed. Just > keep running the RIR as normal and keep reporting status so that > we can see how much time is left. Plan A. Because there is no Plan B. I'm sure it will be exciting. Leo From randy at psg.com Fri Mar 7 07:19:59 2008 From: randy at psg.com (Randy Bush) Date: Fri, 07 Mar 2008 04:19:59 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoFRe: NANOG IPv4 Exhaustion BoF In-Reply-To: <23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D05D88.4050400@internap.com> <23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net> Message-ID: <47D132EF.7080604@psg.com> Tom Vest wrote: > Every claim that I've ever heard that a decentralized, > every-operator-for-itself resource transfer policy is inevitable > starts with the assertion that any rule (and any rulemaker) that gets > in the way of maximum self-help will be irrelevant in the post-free > pool world. see a doctor about your ears > Markets are not inevitable. a market already exists, so the inevitability is irrelevant Scott Leibrand wrote: > I think everyone is fully in favor of making IPv4 irrelevant through > widespread adoption of IPv6. there are at least three other camps, lisp, nat-for-all, and rabid-anything-but-ipv6. and they are not insignificant. this discussion makes their points well. Michael Smith wrote: > If a consortium is formed of the holder of legacy space, in > particular, then supply will be regulated by the consortium, not by > market forces. Then, if they're smart, they will regulate prices to > the highest level the market will bear and sell them off a bit at a > time. Think OPEC. they would have to. black helicopters are extremely expensive, especially the invisible ones. the bogeyperson play, whether the bogeyperson is the igf, the itu, the evil legacy holders, or whatever is getting pretty childish and boring, and i now severely discount anyone who tries to play it as a threat. i suspect i will like the bogeypeople about as well as the folk here. there are good apples in every barrel. and if they think a bit differently, then it will be an opportunity for me to learn a different view of the world, always a good thing. Geoff Huston wrote: > an april day fools effort (rejected by the RFC Editor, by the way) > that rewrote the Kyoto Protocol to talk about BGP Update credits > (http://www.potaroo.net/drafts/draft-bert-kyoto-protocol-00.html). > The really scary bit is that it has been the closest I've ever seen > to the imposition of economic controls on the routing system that > could possibly fly. i take it seriously lucy makes a strong case that carbon like pool markets best model what we have here. > I can't see much point in attempting to suppress or distort an > otherwise clear signal of scarcity by creating artificial > impediments. Not only does it call into question the legitimacy of > the party attempting to impose such constraints, and raise the > question of whether such impositions should be accepted by the > actors, it seems to me that it leads to no particularly useful space. at layer 11, i am hearing a lot of noise on the line of "registries desperately trying to assure a continuing income stream," and "amateur over- regulators are worse than most markets." i do not think either is completely true. but discussions such as on this list are being read by folk who wear different and expensive clothes and they are not impressed. heck, i am not impressed. "guns in the hands of children." and guns on which more and more of our economies and societies are increasingly dependent. Scott Leibrand wrote: > But most IPs are not used by organizations getting a /24 to > multihome. They are being used by actual devices (computers, home > NAT boxes, whatever) with a single public IP per device. if true, and i have not seen actual measurement, then this is productive use of a scarce resource. cool. how can we increase it? hint: the grown-up economists i heard earlier this week said a benefit of a market is that it finds "best use" for the goods (not magically, of course). but most routing table slots are being used by TE and asocial pollution of the commons. this behavior is non-productive. i want to stomp it. John Curran wrote: > I'd agree with you if there were anything resembling a useful > feedback mechanism on the global routing table. As it is, the only > knob available is route filtering, and while that works fine as a > tool against needless deaggregation, it really doesn't work well > filtering lots of new unique routes from your peers all of which are > necessary to cover their new customers... the latter represents real business and folk with real packets. the TE and intentional fragging represents non-product and is worth stomping. drc wrote: > Put enough constraints on transfers and people won't bother. End > result: hoarding (for some value of that variable), speculation via a > black market, etc. The only thing the policy will have done is > decrease ARIN's relevance in the post IPv4 free pool exhaustion world > since the registration database will become less and less useful > over time. bingo! much of this discussion is about how best to shoot ourselves, as an organization and an industry, in the foot. i suspect we will succeed in killing ourselves as amateur over-regulators, but the guns will be removed from our hands before we do serious damage to the industry. > it would seem the policy is attempting to put ARIN in the position of > being an arbiter of quite a few thing things it hasn't taken on > before, e.g., "fairness" (fair to whom?), "availability" (for whom?), > "unnecessary deaggregation" (from whose perspective), etc. I might > suggest there are many, many mines in that particular field and that > ARIN is not necessarily in the best position to blaze a path there. from listening to some economic grown-ups early this week, one of the take-aways was that these are not simple issues and even the language we seem to be using is a far from productive. we amateur regulators are in way way over our heads, and thrashing is not gonna make us float any better. what it will likely do is bring in the professionals, and i am starting to look forward to that as preferable to all this. randy From woody at pch.net Fri Mar 7 07:32:01 2008 From: woody at pch.net (Bill Woodcock) Date: Fri, 7 Mar 2008 04:32:01 -0800 (PST) Subject: [ppml] Abuse address In-Reply-To: <004301c87fc8$edad6650$5b01a8c0@mvs1domain.mvssol.com> References: <004301c87fc8$edad6650$5b01a8c0@mvs1domain.mvssol.com> Message-ID: On Thu, 6 Mar 2008, Martin Wills wrote: > Why does Arin not insist on some abuse address showing up in Whois? You are ARIN. If you want the ARIN staff to revise the templates to make an abuse address mandatory, please follow the policy proposal process to suggest that, and see if the other members agree with you. http://www.arin.net/policy/irpep_template.html -Bill From tvest at pch.net Fri Mar 7 07:35:18 2008 From: tvest at pch.net (Tom Vest) Date: Fri, 7 Mar 2008 07:35:18 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoFRe: NANOG IPv4 Exhaustion BoF In-Reply-To: <47D132EF.7080604@psg.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D05D88.4050400@internap.com> <23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net> <47D132EF.7080604@psg.com> Message-ID: <2E24AD52-C9C3-4BE6-ADCC-33F242251362@pch.net> On Mar 7, 2008, at 7:19 AM, Randy Bush wrote: > Tom Vest wrote: >> Every claim that I've ever heard that a decentralized, >> every-operator-for-itself resource transfer policy is inevitable >> starts with the assertion that any rule (and any rulemaker) that gets >> in the way of maximum self-help will be irrelevant in the post-free >> pool world. > > see a doctor about your ears > >> Markets are not inevitable. > > a market already exists, so the inevitability is irrelevant > > Scott Leibrand wrote: >> I think everyone is fully in favor of making IPv4 irrelevant through >> widespread adoption of IPv6. > > there are at least three other camps, lisp, nat-for-all, and > rabid-anything-but-ipv6. and they are not insignificant. this > discussion makes their points well. > > Michael Smith wrote: >> If a consortium is formed of the holder of legacy space, in >> particular, then supply will be regulated by the consortium, not by >> market forces. Then, if they're smart, they will regulate prices to >> the highest level the market will bear and sell them off a bit at a >> time. Think OPEC. > > they would have to. black helicopters are extremely expensive, > especially the invisible ones. > > the bogeyperson play, whether the bogeyperson is the igf, the itu, the > evil legacy holders, or whatever is getting pretty childish and > boring, > and i now severely discount anyone who tries to play it as a > threat. i > suspect i will like the bogeypeople about as well as the folk here. > there are good apples in every barrel. and if they think a bit > differently, then it will be an opportunity for me to learn a > different > view of the world, always a good thing. > > Geoff Huston wrote: >> an april day fools effort (rejected by the RFC Editor, by the way) >> that rewrote the Kyoto Protocol to talk about BGP Update credits >> (http://www.potaroo.net/drafts/draft-bert-kyoto-protocol-00.html). >> The really scary bit is that it has been the closest I've ever seen >> to the imposition of economic controls on the routing system that >> could possibly fly. > > i take it seriously lucy makes a strong case that carbon like pool > markets best model what we have here. > >> I can't see much point in attempting to suppress or distort an >> otherwise clear signal of scarcity by creating artificial >> impediments. Not only does it call into question the legitimacy of >> the party attempting to impose such constraints, and raise the >> question of whether such impositions should be accepted by the >> actors, it seems to me that it leads to no particularly useful space. > > at layer 11, i am hearing a lot of noise on the line of "registries > desperately trying to assure a continuing income stream," and "amateur > over- regulators are worse than most markets." i do not think > either is > completely true. but discussions such as on this list are being > read by > folk who wear different and expensive clothes and they are not > impressed. heck, i am not impressed. "guns in the hands of > children." > and guns on which more and more of our economies and societies are > increasingly dependent. > > Scott Leibrand wrote: >> But most IPs are not used by organizations getting a /24 to >> multihome. They are being used by actual devices (computers, home >> NAT boxes, whatever) with a single public IP per device. > > if true, and i have not seen actual measurement, then this is > productive > use of a scarce resource. cool. how can we increase it? hint: the > grown-up economists i heard earlier this week said a benefit of a > market > is that it finds "best use" for the goods (not magically, of course). Maybe we can get a volume discount on hearing intervention then... clearly I am not the only potential customer. None of the "grown-ups" you heard earlier this week actually said *one word* about how to establish a viable market. Lots of talk about how nice a viable market might be, and some about how one could be cleanly administered after it had been established, assuming all of the conveniently skirted bootstrap problems are solved and has already agreed about what values should be maximized. I thought we had all agreed that whitewashing/marketing-speak wasn't all that constructive for promoting constructive adaptation? You certainly seem to have embraced that philosophy for IPv6, and I think we're all better off for it. Why the complete about-face here? TV > but most routing table slots are being used by TE and asocial > pollution > of the commons. this behavior is non-productive. i want to stomp it. > > John Curran wrote: >> I'd agree with you if there were anything resembling a useful >> feedback mechanism on the global routing table. As it is, the only >> knob available is route filtering, and while that works fine as a >> tool against needless deaggregation, it really doesn't work well >> filtering lots of new unique routes from your peers all of which are >> necessary to cover their new customers... > > the latter represents real business and folk with real packets. > the TE > and intentional fragging represents non-product and is worth stomping. > > drc wrote: >> Put enough constraints on transfers and people won't bother. End >> result: hoarding (for some value of that variable), speculation via a >> black market, etc. The only thing the policy will have done is >> decrease ARIN's relevance in the post IPv4 free pool exhaustion world >> since the registration database will become less and less useful >> over time. > > bingo! much of this discussion is about how best to shoot > ourselves, as > an organization and an industry, in the foot. i suspect we will > succeed > in killing ourselves as amateur over-regulators, but the guns will be > removed from our hands before we do serious damage to the industry. > >> it would seem the policy is attempting to put ARIN in the position of >> being an arbiter of quite a few thing things it hasn't taken on >> before, e.g., "fairness" (fair to whom?), "availability" (for whom?), >> "unnecessary deaggregation" (from whose perspective), etc. I might >> suggest there are many, many mines in that particular field and that >> ARIN is not necessarily in the best position to blaze a path there. > > from listening to some economic grown-ups early this week, one of the > take-aways was that these are not simple issues and even the > language we > seem to be using is a far from productive. we amateur regulators > are in > way way over our heads, and thrashing is not gonna make us float any > better. what it will likely do is bring in the professionals, and > i am > starting to look forward to that as preferable to all this. > > randy > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the > ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. From randy at psg.com Fri Mar 7 08:00:18 2008 From: randy at psg.com (Randy Bush) Date: Fri, 07 Mar 2008 05:00:18 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoFRe: NANOG IPv4 Exhaustion BoF In-Reply-To: <2E24AD52-C9C3-4BE6-ADCC-33F242251362@pch.net> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D05D88.4050400@internap.com> <23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net> <47D132EF.7080604@psg.com> <2E24AD52-C9C3-4BE6-ADCC-33F242251362@pch.net> Message-ID: <47D13C62.3050504@psg.com> > None of the "grown-ups" you heard earlier this week actually said *one > word* about how to establish a viable market. considering you seem to have problems with your ears, perhaps you might not tell me what mine heard. > Lots of talk about how nice a viable market might be, and some about how > one could be cleanly administered after it had been established, > assuming all of the conveniently skirted bootstrap problems are solved > and has already agreed about what values should be maximized. heard that stuff too. > I thought we had all agreed that whitewashing/marketing-speak wasn't all > that constructive for promoting constructive adaptation? > You certainly seem to have embraced that philosophy for IPv6, and I > think we're all better off for it. > Why the complete about-face here? i suggest you show the whitewash about face before slinging mud in a knee-jerk reaction. nowhere in my message did i say that there was a magic solution, markets were perfect, ... if things were simple, we would not be having discussions in this and other fora. but knee-jerk fanboy reactions make cause much of this forum to be increasingly discounted. randy From jcurran at istaff.org Fri Mar 7 08:00:17 2008 From: jcurran at istaff.org (John Curran) Date: Fri, 7 Mar 2008 08:00:17 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoFRe: NANOG IPv4 Exhaustion BoF In-Reply-To: <47D132EF.7080604@psg.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D05D88.4050400@internap.com> <23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net> <47D132EF.7080604@psg.com> Message-ID: At 4:19 AM -0800 3/7/08, Randy Bush wrote: >at layer 11, i am hearing a lot of noise on the line of "registries >desperately trying to assure a continuing income stream," Registries have a function to perform (technical administration of numbering resources) which right now doesn't appear to be readily automatable. This is mostly because the semantics on the resources include both uniqueness and hierarchy/topology, with the result being historically lots of wrangling over allocation policy and routing implications. As IPv4 availability decreases, the expectation appears to be even more policy work to 'best' administration the remaining free pool. If the semantics were changed to be only uniqueness (such as you might have in the IPv6 domain after any successful endpoint/location split, or IPv4 post-depletion if it's felt that the routing implications of IPv4 xfers are simply beyond RIR scope), this core function of the RIR becomes much simpler and one can imagine a greatly reduced need for policy administration and a high degree of automation on the resource administration side. When considering implications of a potential 'market', one of the points raised by the ARIN AC to the ARIN Board was best summed up as follows: * Preserving ARIN's reason to exist, should not enter the calculus of this decision. If the path to a better Internet involves the dissolution of ARIN, then so be it. I don't know about the thoughts of other RIR's on this topic (and the ARIN Board hasn't expressed a formal position) but personally I feel that the RIR's exist to serve the need of technical administration of the resources, and most definitely not the other way around. /John From jcurran at istaff.org Fri Mar 7 08:44:26 2008 From: jcurran at istaff.org (John Curran) Date: Fri, 7 Mar 2008 08:44:26 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47D0FA31.8050105@apnic.net> References: <292DCB81-EAD1-4774-8913- 998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org> <47CF92AE.7070806@apnic.net> <054258CF-4B5D-4A1B-98BA-35E26EC386C9@virtualized.org> <47D0D4D2.4030909@apnic.net> <95F06EFB-BAA6-449F-B020-3E61372A0DBE@pch.net> <47D0E30E.2050508@apnic.net> <47D0FA31.8050105@apnic.net> Message-ID: At 7:17 PM +1100 3/7/08, Geoff Huston wrote: > >The sad fact is that the global routing table has been under concentrated assault by the legions of /24s for many years now. > >Since 2001 50% of the routing table is more specifics - and now there are 135,208 of them. My supposition is that TE is the major factor - when you look at highly deaggregated prefixes you tend to see a collection of upstreams and load spreading across the upstreams. > >So in many ways the routing system is already under this "fragmentation" pressure and will remain so whether its IPv4 or IPv6 Agreed, but I'll note that every day hundreds of new entities connect up to the Internet via PA space with no fragmentation as a result. Further, ISP's can make conscience decisions to inject routes for TE and to filter others TE more specifics. In a post-depletion scenario where customers want IPv4 connectivity and bring their own blocks, ISPs have little choice but to accept the customers (and inject the route) rather than sending them to a competitor. This includes customers showing up with just a /30 and NAT CPE... There's no reason to think that the number of new sites per unit time is declining, so it's really a question of the number of new routes to cover the same growth rate. >As I understand your argument here John its that fragmented address supply won't make it any better, but it could make it worse, and that could trigger responses such as selective filtering, threatening global connectivity. Yes, thats a valid concern. Without much data to quantify the risk its hard to assess how critical this factor will be. To rephrase slightly: a fragmented IPv4 address supply, made available to individual end sites via transfer policy, *will* make it much, much worse, and inevitably require a high degree of selective filtering. It still remains to be seen whether any RIR adopts a transfer policy which creates such an address supply. /John From jmaimon at chl.com Fri Mar 7 09:16:31 2008 From: jmaimon at chl.com (Joe Maimon) Date: Fri, 07 Mar 2008 09:16:31 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <054258CF-4B5D-4A1B-98BA-35E26EC386C9@virtualized.org> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org> <47CF92AE.7070806@apnic.net> <054258CF-4B5D-4A1B-98BA-35E26EC386C9@virtualized.org> Message-ID: <47D14E3F.1090301@chl.com> David Conrad wrote: > I would agree this scenario is far preferable to the first. What > actually comes about is, of course, hard to determine at this point in > time. I personally believe that policies should be explicitly > oriented towards promotion of the second view as one outcome of > transfers could be a market encouraging increased address space > utilization efficiency via NATs, which could reduce the pressure for > IPv6 deployment. This would actually be a best case scenario, where access to ipv4 internet is through ipv4 nat, but ipv6 is end-to-end. Thus ipv6 service (which is plentiful and cheap) now has a clear advantage to it, one that will only grow as the rfc1918-ing of "consumer" customers picks up speed, and dual stack can actually work as a practical migration strategy. This is actually the path of least resistance for ISP's wishing to migrate their customer base to ipv6 in the face of ipv4 shortage, whether or not ipv4 is available for whatever price. Switch your users to pop boundaried rfc1918 natted to give "normal" access to ipv4 net, offer them all ipv6, offer the holdouts and content/service providers inbound ipv4 either sold by the port or by the address for a premium. Market pressures and network effect should take care of the rest. Without this approach, the pressure becomes all about enabling access to ipv4 from ipv6 (and ipv4 to ipv6), because otherwise ipv6 is useless. So which is the better technology and outcome, dual stack of nat ipv4 and end to end ipv6 or single stack ipv6 with {proxy | nat | undefined} solutions for ipv4 interop? The situation for content providers is likely a bit more problematic than for ISP's. From bicknell at ufp.org Fri Mar 7 09:57:41 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 7 Mar 2008 09:57:41 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoFRe: NANOG IPv4 Exhaustion BoF In-Reply-To: <47D132EF.7080604@psg.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D05D88.4050400@internap.com> <23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net> <47D132EF.7080604@psg.com> Message-ID: <20080307145741.GA43339@ussenterprise.ufp.org> In a message written on Fri, Mar 07, 2008 at 04:19:59AM -0800, Randy Bush wrote: > > Markets are not inevitable. > > a market already exists, so the inevitability is irrelevant I keep seeing a bunch of engineers argue these two points using rather fine points of the English language, and all sides are avoiding the real issue. A black market exists for /everything/. From IP's to toilet paper there are people selling it "outside the system". Thus Randy's quote of "a market already exists" is technically true. But, most black markets are /insignificant/. It doesn't matter if you measure by number of transactions, or dollar value, or any other measure in most cases the black market doesn't even come close to a rounding error. For most goods (e.g. toilet paper) people selling on the black market are doing so either to support illegal activity (e.g. TP'ing someone's house with "untraceable" paper) or because they have some problem with the system (e.g. don't want to pay sales tax on their TP). I would argue at this stage the black market in Internet Resources is insignificant in that it is both small in number of transactions and small in dollar value. I would also argue most of the transactions are supporting illegal activity (spam, malware, etc). What's really interesting is if the black market turns into something where a significant percentage of law abiding citizens turn to the black market. For one of the largest black markets ever think prohibition; many ordinary citizens who would otherwise obey the law turned to "illegal" producers. In this respect Randy totally misses the boat with "inevitability is irrelevant" because he ignored the the original poster intent, which was something more like this: Black markets that gain wide acceptance between otherwise rule following participants are not inevitable. Is such a market inevitable? I don't think so. Today we have a system where most major ISP's want to see documentation you can use the IP space you want to route. Whois, LOA from the holder, we've all seen the various checks. Yes, I realize not 100% of the networks check, but enough do that it is common. We all see technical value in these checks. Those who fail to hold their customers to the checks generally get the wrath of the community (witness the Youtube event, for the most recent case) because we know this is a sort of mutually assured destruction. While we would all like to be able to announce any prefix we want if we all did that and trounced over each others customers the Internet would quite literally fall apart. In short, it's my belief that even if there was no way to transfer resources the black market would never rise above a rounding error (although it may get somewhat larger than it is today); and is thus not an issue. However, if we're going to have a real discussion this issue people need to grow up. The fact that 10 people bought and sold hijacked netblocks last year is a complete non sequitur to the discussion at hand. The interesting discussion is if there will be a market where AT&T, VerizonBusiness, Qwest, Level 3, Cox, Comcast, Cablevision, and other large companies will purchase IP resources. Would the situation get so bad that these large corporations would risk punishment by the law, regulators, and their peers for turning to a black market. I think not. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From bicknell at ufp.org Fri Mar 7 10:10:06 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 7 Mar 2008 10:10:06 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <881EF36A-A09A-4606-A52B-71E46DE2120E@virtualized.org> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <881EF36A-A09A-4606-A52B-71E46DE2120E@virtualized.org> Message-ID: <20080307151006.GB43339@ussenterprise.ufp.org> In a message written on Thu, Mar 06, 2008 at 10:14:05PM -0800, David Conrad wrote: > > But say if Warren Buffet decided to buy up every prefix, > > drive up prices and then dole them out with an eye dropper, that would > > distort the market. > > Very true. I believe one theory is that such a course of action would > _strongly_ encourage IPv6 deployment and hence, would not necessarily > be a bad thing. The implication being that if you believe IPv6 is the > right way to go, minimal restrictions would have the most positive > long term effect, albeit it may result in a bit of initial > "discomfort"... This statement is true, but potentially misleading. There are a number of scenarios under which the price for resources in a market would skyrocket. I think there is wide agreement that if the price is high enough it is less pain to move to IPv6. The issue for many though is how we "hit the wall". One of the major arguments for a transfer policy is that having a "hard stop" date is painful to the industry. We can't just run out of IPv4 and switch to IPv6. However, if speculators were to enter the market, that's exactly what could happen. Over the course of a very short period of time (perhaps a month, maybe less) speculators could drive the price to a point where no ISP can afford it, and there is a rapid migration to IPv6. Thus if your motivation is that hitting the wall is bad, then the speculator's driving up prices and causing a switch is likely to seem in the same league, if not worse as people may have been lulled into a false sense of security by the existence of a white market. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From drc at virtualized.org Fri Mar 7 10:56:30 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 7 Mar 2008 07:56:30 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoFRe: NANOG IPv4 Exhaustion BoF In-Reply-To: <20080307145741.GA43339@ussenterprise.ufp.org> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D05D88.4050400@internap.com> <23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net> <47D132EF.7080604@psg.com> <20080307145741.GA43339@ussenterprise.ufp.org> Message-ID: Leo, On Mar 7, 2008, at 6:57 AM, Leo Bicknell wrote: > What's really interesting is if the black market turns into something > where a significant percentage of law abiding citizens turn to the > black market. Very true. And the reason folks turn to a black market is generally because the white market is unable to meet their requirements. The reason this would be the case is typically because restrictions/ constraints/regulations make it too hard/expensive to obtain what you need from the white market. > In short, it's my belief that even if there was no way to transfer > resources the black market would never rise above a rounding error > (although it may get somewhat larger than it is today); and is thus > not an issue. A lot depends on the continued demand for IPv4 post free pool exhaustion and the level of restriction that is applied in efforts to increase utilization efficiency. If IPv4 post free pool exhaustion demand is a reasonable percentage of current demand and there is no way for that demand to be met through transfers, do you still posit a black market would be insignificant? > Would the > situation get so bad that these large corporations would risk > punishment by the law, regulators, and their peers for turning to > a black market. Last I checked, ARIN did not have force of law or regulation and had little control over what peers do amongst themselves. Perhaps more interestingly, it may be useful to remember that ARIN is not a monopoly in IPv4 address registration services. There are already two other potential venues for transfer registration services (with proposed transfer policies that are significantly less onerous) and those venues are already viewed as legitimate by large corporations (I imagine the ones you speak of are already members). Regards, -drc From mksmith at adhost.com Fri Mar 7 10:58:01 2008 From: mksmith at adhost.com (Michael Smith) Date: Fri, 7 Mar 2008 07:58:01 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoFRe: NANOG IPv4 Exhaustion BoF In-Reply-To: <47D132EF.7080604@psg.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D05D88.4050400@internap.com> <23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net> <47D132EF.7080604@psg.com> Message-ID: <26BF00DA-8F11-4073-B446-B66DC843226E@adhost.com> > Michael Smith wrote: >> If a consortium is formed of the holder of legacy space, in >> particular, then supply will be regulated by the consortium, not by >> market forces. Then, if they're smart, they will regulate prices to >> the highest level the market will bear and sell them off a bit at a >> time. Think OPEC. > > they would have to. black helicopters are extremely expensive, > especially the invisible ones. > > the bogeyperson play, whether the bogeyperson is the igf, the itu, the > evil legacy holders, or whatever is getting pretty childish and > boring, > and i now severely discount anyone who tries to play it as a > threat. i > suspect i will like the bogeypeople about as well as the folk here. > there are good apples in every barrel. and if they think a bit > differently, then it will be an opportunity for me to learn a > different > view of the world, always a good thing. No tin foil hats here. I am not an economist and I'm not a lawyer and it seems a lot of these discussions should include a lot more of both. There will probably be a lot of different markets and models and competing theories as to what type of resource IPv4 is and, thus, what model it's scarcity will follow. >> it would seem the policy is attempting to put ARIN in the position of >> being an arbiter of quite a few thing things it hasn't taken on >> before, e.g., "fairness" (fair to whom?), "availability" (for whom?), >> "unnecessary deaggregation" (from whose perspective), etc. I might >> suggest there are many, many mines in that particular field and that >> ARIN is not necessarily in the best position to blaze a path there. > > from listening to some economic grown-ups early this week, one of the > take-aways was that these are not simple issues and even the > language we > seem to be using is a far from productive. we amateur regulators > are in > way way over our heads, and thrashing is not gonna make us float any > better. what it will likely do is bring in the professionals, and i > am > starting to look forward to that as preferable to all this. Is the recommendation then to; 1) hold fast with our existing policies, 2) pare down what we have, or 3) who cares because, as you say, it's just a matter of time before the professionals get involved? Serious question. I tend to opt for number 2, although the safe bet might be "do nothing" because we're having limited success "doing something." Regards, Mike From drc at virtualized.org Fri Mar 7 11:11:48 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 7 Mar 2008 08:11:48 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47D14E3F.1090301@chl.com> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org> <47CF92AE.7070806@apnic.net> <054258CF-4B5D-4A1B-98BA-35E26EC386C9@virtualized.org> <47D14E3F.1090301@chl.com> Message-ID: <37E2478E-15C7-4ED0-83D5-66ED74A98179@virtualized.org> Joe, On Mar 7, 2008, at 6:16 AM, Joe Maimon wrote: > This would actually be a best case scenario, where access to ipv4 > internet is through ipv4 nat, but ipv6 is end-to-end. While I might agree, the tricky bit is having IPv6 end-to-end. This is obviously neither plentiful nor cheap at this point in time and if ISPs aren't paying attention to longer term realities of IPv4 exhaustion, this won't change. > The situation for content providers is likely a bit more problematic > than for ISP's. Yep. I imagine it is hard for content providers to make the business case to even look at IPv6 right now. And if content isn't available over IPv6, few ISP customers will ask for it, making it hard for ISPs to make their business case. And around we go. Regards, -drc From randy at psg.com Fri Mar 7 11:14:30 2008 From: randy at psg.com (Randy Bush) Date: Fri, 07 Mar 2008 08:14:30 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoFRe: NANOG IPv4 Exhaustion BoF In-Reply-To: <26BF00DA-8F11-4073-B446-B66DC843226E@adhost.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D05D88.4050400@internap.com> <23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net> <47D132EF.7080604@psg.com> <26BF00DA-8F11-4073-B446-B66DC843226E@adhost.com> Message-ID: <47D169E6.6090804@psg.com> > Is the recommendation then to; 1) hold fast with our existing policies, > 2) pare down what we have, or 3) who cares because, as you say, it's > just a matter of time before the professionals get involved? i think the current proposals in apnic and arin are fair starting points, and are honest attempts to move forward. i suspect both are too restrictive for my taste, e.g. apnic's nir shield. but geoff's change (at the meeting) to allow inter-region trading was a step forward. and i know nirs are weird and twisty passages. and i have asked scott re the issues that give me pause with his. but they're probably a good start, and could be the basis of gaining experience for a year or two. randy From michael.dillon at bt.com Fri Mar 7 11:27:19 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 7 Mar 2008 16:27:19 -0000 Subject: [ppml] NANOG IPv4 Exhaustion BoFRe: NANOG IPv4 Exhaustion BoF In-Reply-To: <47D132EF.7080604@psg.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com><507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net><47D05D88.4050400@internap.com><23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net> <47D132EF.7080604@psg.com> Message-ID: > at layer 11, i am hearing a lot of noise on the line of > "registries desperately trying to assure a continuing income > stream," and "amateur > over- regulators are worse than most markets." i do not > think either is completely true. but discussions such as on > this list are being read by folk who wear different and > expensive clothes and they are not impressed. heck, i am not > impressed. "guns in the hands of children." > and guns on which more and more of our economies and > societies are increasingly dependent. Then these layer 11 people should ensure that their legal and regulatory people get involved in their ARIN relationship instead of leaving it entirely to the technologists or clerical administrators who often fill the role today. Not that they should replace these people, but I get the sense that not many ARIN representatives have a full dialog within their companies. > hint: the grown-up economists i heard earlier > this week said a benefit of a market is that it finds "best > use" for the goods (not magically, of course). IP addresses are not goods. It costs money to posess goods because they consumer space which must be paid for. There is also a risk involved in possessing goods because they could be stolen by thieves or destroyed by floods which would cause you to lose your investment. IP addresses cost nothing to hold onto, and there is no real risk of damage or loss of your investment, which is probably less than $1000 even if you count up all the manpower costs involved in getting the addresses in the first place. > bingo! much of this discussion is about how best to shoot > ourselves, as an organization and an industry, in the foot. > i suspect we will succeed in killing ourselves as amateur > over-regulators, but the guns will be removed from our hands > before we do serious damage to the industry. I agree with the first, disagree with the second. Yes, just about all the discussion of introducing soft-landing or transfer policies is an amateur attempt at creating a regulatory regime. But, no I don't think we will succeed at killing ourselves because I believe that most of these initiatives will ultimately be rejected. Or perhaps watered down so that they fail upon implementation. > from listening to some economic grown-ups early this week, > one of the take-aways was that these are not simple issues > and even the language we seem to be using is a far from > productive. It's not just the language, it is the perspective from which these proposals come. It smacks of people playing one of those civilization building games on a computer where the player has the powers of God. In the real world, nobody has that kind of power, and you cannot attain significant change in a short period of time. > what it will likely do is bring in the professionals, and i > am starting to look forward to that as preferable to all this. I think that we should take more initiative to invite the professionals in so that they can educate us. Over time, ARIN has added regular presentations by legal counsel, and recently an economist. Perhaps we could also find an expert on the SEC and market regulation, as well as somebody who could speak about the FCC regulatory regime. And it wouldn't hurt to look for a university which could do some cooperative research between their high-speed network research people and their economics department, to get a sense of the real costs of stretching the lifetime of IPv4 and deploying IPv6 services. --Michael Dillon From drc at virtualized.org Fri Mar 7 11:37:48 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 7 Mar 2008 08:37:48 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <292DCB81-EAD1-4774-8913- 998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org> <47CF92AE.7070806@apnic.net> <054258CF-4B5D-4A1B-98BA-35E26EC386C9@virtualized.org> <47D0D4D2.4030909@apnic.net> <95F06EFB-BAA6-449F-B020-3E61372A0DBE@pch.net> <47D0E30E.2050508@apnic.net> <47D0FA31.8050105@apnic.net> Message-ID: John, On Mar 7, 2008, at 5:44 AM, John Curran wrote: > In a post-depletion scenario where customers want IPv4 > connectivity and bring their own blocks, ISPs have little > choice but to accept the customers (and inject the route) > rather than sending them to a competitor. This includes > customers showing up with just a /30 and NAT CPE... Obviously, the fact that you announce a route does not imply your peers or their peers will accept that route. Ignoring the fact that the vast majority of customers will not be bringing their own blocks (they will instead be connecting via a (perhaps multi-layered) NAT and thus not contribute to the routing load), there will be back pressure on "transfers" of such long prefixes simply because they won't get you where you need to go. For your nightmare scenario to be made reality the following would need to occur: 1) origin ISP accepts long prefix 2) origin ISP announces long prefix to direct peers 3) direct peers ISPs accept long prefix 4) direct peers ISPs announce long prefix to their peers 5) Peers of peers accept long prefix 6) Peers of peers announce long prefix n) etc. At any point, if one of these does not hold true, you get some unreachability, leaving the customer (or perhaps the origin ISP if the customer is paying enough) to go try to negotiate (pay for) acceptance of the long prefix by the ISPs that are refusing it. All for the privilege of having only a single layer of NAT? Riiiight. Regards, -drc From jcurran at istaff.org Fri Mar 7 11:47:47 2008 From: jcurran at istaff.org (John Curran) Date: Fri, 7 Mar 2008 11:47:47 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <292DCB81-EAD1-4774-8913- 998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org> <47CF92AE.7070806@apnic.net> <054258CF-4B5D-4A1B-98BA-35E26EC386C9@virtualized.org> <47D0D4D2.4030909@apnic.net> <95F06EFB-BAA6-449F-B020-3E61372A0DBE@pch.net> <47D0E30E.2050508@apnic.net> <47D0FA31.8050105@apnic.net> Message-ID: At 8:37 AM -0800 3/7/08, David Conrad wrote: >Ignoring the fact that the vast majority of customers will not be bringing their own blocks (they will instead be connecting via a (perhaps multi-layered) NAT and thus not contribute to the routing load), there will be back pressure on "transfers" of such long prefixes simply because they won't get you where you need to go. If the customers servers requiring unique addresses are covered by some PA assigned space, that's true. When ISP's can't find more address space to use for this purpose, then you'll see customer-provided blocks being routed instead or customers being turned down for IPv4 services, which will lead them to an ISP which will accept & try to route them... The ISP's who try not to pollute end up having to reject the new customer, and then again not accept their route when another ISP takes up the same customer. The ISP who takes the customer and tries to route them to the peers gets the revenue and simply redirects any connectivity blame to the well-behaved ISP for 'needlessly' filtering. (This, btw, is mirrors the dialog that went down during some of the earlier peering/filtering ISP wars...) /John From michael.dillon at bt.com Fri Mar 7 11:57:51 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 7 Mar 2008 16:57:51 -0000 Subject: [ppml] NANOG IPv4 Exhaustion BoFRe: NANOG IPv4 Exhaustion BoF In-Reply-To: <20080307145741.GA43339@ussenterprise.ufp.org> References: <47CDA182.80502@internap.com><435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org><47CF4F8F.2030504@psg.com><000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com><00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com><507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net><47D05D88.4050400@internap.com><23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net><47D132EF.7080604@psg.com> <20080307145741.GA43339@ussenterprise.ufp.org> Message-ID: > Would the situation get so bad > that these large corporations would risk punishment by the > law, regulators, and their peers for turning to a black market. I'm not aware of any laws against buying IP addresses on the "black" market, or any regulators who would take an interest in such activity. Also, since it is relatively easy for large corporations to hide this in a web of subsidiary corporations and holding companies, who would ever find out what they did? A few years ago, when the Enron affair was in the news, I had an interesting conversation with someone who was an insider in the large corporate finance area. He explained how Enron was merely the tip of the iceberg and how there were actually quite a lot more companies doing the same kind of debt-hiding. He claimed that a major driver behind many corporate acquisitions and bankruptcies was to hide what had been done and protect people from the same kind of fate as the Enron executives. The scale of this was huge with banks and bondholders involved as well, loaning money to clean companies to buy dirty ones, and forcing the dirty ones to sell or fail. It is still regular corporate finance practice to maintain a webwork of interlocking corporations in order to optimize their finances. Employees work for one company, all sales go to another one, a 3rd owns the network assets, a 4th one operates the network and so on. And that's just in one country. Add countries and it gets even more interesting. When JBC Ventures PLC buys an address block and books it as an expense, then nobody is breaking the law because IP addresses are not an asset and have no value. How are you going to find who ultimately controls JBC Ventures AO? Big ISP will claim that they are a customer in Lower Slobovia with a paid peering contract. If ARIN is not a lawmaker and has no regulatory powers under the law, then ARIN has no ability to "police" the organizations who hold allocations from ARIN ranges. Rather than pretend that ARIN does have such powers, we should accept the situation as it is, and focus on other activities in its charter. 1. to increase and diffuse knowledge to the general public about the Internet in its broadest sense; 2. to educate industry and the Internet community in order to further their technical understanding of the Internet; 3. to secure united action and to represent the Internet community nationally and internationally; 4. 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; 5. to do all and everything necessary to enhance the growth of the Internet and the prospects for competition among Internet Service Providers by encouraging the exploration and implementation of solutions to Internet Protocol number scarcity issues; 6. to encourage the exploration of new addressing and routing technologies that reduce or eliminate the costs or in some cases the need for renumbering when an Internet Service Provider or end user changes to a new Internet Service Provider; and, when such alternatives are developed, to work with its members to facilitate the assignment of portable addresses and/or the elimination of the cost of Internet Protocol renumbering; 7. to encourage allocation policy changes for Internet Service Providers in order to enhance competition by providing mobility of Internet Service Providers among upstream Internet Service Providers when it is generally agreed that the technology is available for portable addressing; 8. to manage the allocation and registration of Internet resources; 9. to promote and facilitate the expansion, development, and growth of the infrastructure of the Internet for the general public and members by any means consistent with the public interest through other activities, including, but not limited to, publications, meetings, conferences, training, educational seminars, and the issuance of grants and other financial support to educational institutions, foundations and other organizations exclusively for educational, charitable, and scientific purposes. --Michael Dillon From bicknell at ufp.org Fri Mar 7 12:15:19 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 7 Mar 2008 12:15:19 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoFRe: NANOG IPv4 Exhaustion BoF In-Reply-To: References: <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D05D88.4050400@internap.com> <23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net> <47D132EF.7080604@psg.com> <20080307145741.GA43339@ussenterprise.ufp.org> Message-ID: <20080307171519.GA55931@ussenterprise.ufp.org> In a message written on Fri, Mar 07, 2008 at 07:56:30AM -0800, David Conrad wrote: > If IPv4 post free pool exhaustion demand is a reasonable percentage of > current demand and there is no way for that demand to be met through > transfers, do you still posit a black market would be insignificant? Yes. How does an ISP tell the difference between a hijacked route (even accidently, think YouTube recently) and a route for a resource sold by YouTube on the black market? The answer is, they don't. ISP's today check whois and ask for LOA's to route space because they know without doing it hijacking may be more widespread and affect their customers. In the black market case this problem actually gets worse. Don't like ProvderX? Find all their customers, chop up the space, sell it on the black market. Wait for chaos. People sell ocean front property in Arizona, bridges in new york, people will sell things they do not have any relationship with at all, and someone will buy it. For ISP's to open this up is mutually assured destruction. If I accept a route that takes your customer offline, you'll do the same to me. A few months later and none of our customers will want anything to do with us, or the IPv4 internet. No, the only path forward for large, legitimate ISP's is to continue to treat the black market space as they do today, poisoned and unroutable. Remember too, successful black markets (illegal drugs, moonshine, even fake CD's and DVD's) generally have strong branding. The guy buying from a street corner has even more reason to suspect he's going to get ripped off and is more cautious than a standard consumer. Large black markets brand their products, monkeys on the E tablets, moonshine with elaborate labels, CD's and DVD's with intros stating "warezed by cOoLd00d23" to build consumer confidence. I'm not seeing how a black market IP dealer could develop brand loyalty in this way. > Last I checked, ARIN did not have force of law or regulation and had > little control over what peers do amongst themselves. Perhaps more > interestingly, it may be useful to remember that ARIN is not a > monopoly in IPv4 address registration services. There are already two > other potential venues for transfer registration services (with > proposed transfer policies that are significantly less onerous) and > those venues are already viewed as legitimate by large corporations (I > imagine the ones you speak of are already members). I never said ARIN would enforce law or regulation. I suspect if I offered DoD address space for sale on eBay someone would pay me a visit right quick. I bet I'd be charged with a crime too, or at least sent to Guantanamo. If the number of hijackings increase the government will step in and arrest people for fraud, "hacking", tax evasion, or the litany of other things they use to control crime. Deals will go bad and people will sue each other over them; or in another form of regulation send Bruno over with a baseball bat. As for other RIR's, if ARIN has no transfer policy and APNIC does, more power to companies who can go off and participate in APNIC's system. I do not see the existence, or lack of a transfer policy in APNIC making any significant difference in the black market in the ARIN region either way. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From jmaimon at chl.com Fri Mar 7 12:42:23 2008 From: jmaimon at chl.com (Joe Maimon) Date: Fri, 07 Mar 2008 12:42:23 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoFRe: NANOG IPv4 Exhaustion BoF In-Reply-To: <20080307171519.GA55931@ussenterprise.ufp.org> References: <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D05D88.4050400@internap.com> <23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net> <47D132EF.7080604@psg.com> <20080307145741.GA43339@ussenterprise.ufp.org> <20080307171519.GA55931@ussenterprise.ufp.org> Message-ID: <47D17E7F.4050101@chl.com> Leo Bicknell wrote: > In a message written on Fri, Mar 07, 2008 at 07:56:30AM -0800, David Conrad wrote: > >>If IPv4 post free pool exhaustion demand is a reasonable percentage of >>current demand and there is no way for that demand to be met through >>transfers, do you still posit a black market would be insignificant? > > > Yes. > > How does an ISP tell the difference between a hijacked route (even > accidently, think YouTube recently) and a route for a resource sold by > YouTube on the black market? > > The answer is, they don't. ISP's today check whois and ask for > LOA's to route space because they know without doing it hijacking > may be more widespread and affect their customers. Why wouldnt you receive a LOA as part of your black market transaction? From drc at virtualized.org Fri Mar 7 12:59:12 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 7 Mar 2008 09:59:12 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoFRe: NANOG IPv4 Exhaustion BoF In-Reply-To: <20080307171519.GA55931@ussenterprise.ufp.org> References: <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D05D88.4050400@internap.com> <23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net> <47D132EF.7080604@psg.com> <20080307145741.GA43339@ussenterprise.ufp.org> <20080307171519.GA55931@ussenterprise.ufp.org> Message-ID: <4FCC1821-FFF5-4553-8F24-CB3489AA8AE4@virtualized.org> Leo, On Mar 7, 2008, at 9:15 AM, Leo Bicknell wrote: > In a message written on Fri, Mar 07, 2008 at 07:56:30AM -0800, David > Conrad wrote: >> If IPv4 post free pool exhaustion demand is a reasonable percentage >> of >> current demand and there is no way for that demand to be met through >> transfers, do you still posit a black market would be insignificant? > > Yes. Hmm. Well, OK. A bit hard to argue with this position. Regards, -drc From drc at virtualized.org Fri Mar 7 13:23:11 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 7 Mar 2008 10:23:11 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <292DCB81-EAD1-4774-8913- 998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org> <47CF92AE.7070806@apnic.net> <054258CF-4B5D-4A1B-98BA-35E26EC386C9@virtualized.org> <47D0D4D2.4030909@apnic.net> <95F06EFB-BAA6-449F-B020-3E61372A0DBE@pch.net> <47D0E30E.2050508@apnic.net> <47D0FA31.8050105@apnic.net> Message-ID: John, On Mar 7, 2008, at 8:47 AM, John Curran wrote: > The ISP's who try not to pollute end up having to reject the > new customer, and then again not accept their route when > another ISP takes up the same customer. The ISP who > takes the customer and tries to route them to the peers > gets the revenue and simply redirects any connectivity > blame to the well-behaved ISP for 'needlessly' filtering. Yeah, and? The "well-behaved" ISP is receiving no revenue from the customer that went to the "badly-behaved" ISP so redirected blame will fall on deaf ears. The Internet gripe ratio goes up. Not a big deal as far as I can tell. > (This, btw, is mirrors the dialog that went down during > some of the earlier peering/filtering ISP wars...) And if I remember correctly, the fact that a few ISPs actually implemented filters were sufficient to help drive the solution that kept everybody's routers from falling over. I'm not sure I understand why you think this won't happen again. ISPs already filter. ISPs that continue to use old hardware that maxes out around 240K routes are reportedly filtering somewhat aggressively. ISPs I've spoken with have said they'll do what they need to when they need to if their routers are about to fall over. I guess I'm just not smart enough to see why ISPs would threaten their own infrastructures just so somebody else's customers can gain connectivity. Regards, -drc From jcurran at istaff.org Fri Mar 7 13:34:18 2008 From: jcurran at istaff.org (John Curran) Date: Fri, 7 Mar 2008 13:34:18 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <292DCB81-EAD1-4774-8913- 998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org> <47CF92AE.7070806@apnic.net> <054258CF-4B5D-4A1B-98BA-35E26EC386C9@virtualized.org> <47D0D4D2.4030909@apnic.net> <95F06EFB-BAA6-449F-B020-3E61372A0DBE@pch.net> <47D0E30E.2050508@apnic.net> <47D0FA31.8050105@apnic.net> Message-ID: At 10:23 AM -0800 3/7/08, David Conrad wrote: >And if I remember correctly, the fact that a few ISPs actually implemented filters were sufficient to help drive the solution that kept everybody's routers from falling over. I'm not sure I understand why you think this won't happen again. Ah, I wasn't clear... I believe it will happen again. Unfortunately, it won't be TE more-specifics being filtered this time, it will be routes covering unique end-site locations. >ISPs already filter. ISPs that continue to use old hardware that maxes out around 240K routes are reportedly filtering somewhat aggressively. ISPs I've spoken with have said they'll do what they need to when they need to if their routers are about to fall over. I guess I'm just not smart enough to see why ISPs would threaten their own infrastructures just so somebody else's customers can gain connectivity. They won't... hence my statement that the end state isn't global collapse, but it also isn't global connectivity. /John From bicknell at ufp.org Fri Mar 7 13:34:56 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 7 Mar 2008 13:34:56 -0500 Subject: [ppml] NANOG IPv4 Exhaustion BoFRe: NANOG IPv4 Exhaustion BoF In-Reply-To: <47D17E7F.4050101@chl.com> References: <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D05D88.4050400@internap.com> <23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net> <47D132EF.7080604@psg.com> <20080307145741.GA43339@ussenterprise.ufp.org> <20080307171519.GA55931@ussenterprise.ufp.org> <47D17E7F.4050101@chl.com> Message-ID: <20080307183456.GA63445@ussenterprise.ufp.org> In a message written on Fri, Mar 07, 2008 at 12:42:23PM -0500, Joe Maimon wrote: > Why wouldnt you receive a LOA as part of your black market transaction? You may, but that system rapidly breaks down. I think if you ask the people where the rubber meets the road today's system is cumbersome at best. And it's a system based around a series of assumptions: 1) The supernet is held by the granting entity for the duration of the subnet's existance. That is, I can look up the parent, call them, and verify the LOA is good. 2) The granting entity is willing to verify the LOA. People do call and check them. People who get a "UUNet" LOA call "VerzionBusiness" and ask if it's still valid. Someone has to make, and take the calls. The first criteria is easily violated when an entire block is transferred. Now it's just a block with the wrong name on it. Transfer it twice and the entity on the record can't verify the transaction history at all, someone would have to walk through it step by step. The second criteria is easily violated by multiple transfers. Party A transferrs a /16 to Party B, Party B then turns it into /24's to Parties C-M. Party F shows up at an ISP who looks in whois and calls party A. They can't verify, and probably do not want to handle the call volume for C-M. They may refuse to answer as a result. There's some hope certificates could make this all easier. On the one hand I think they could; all of the cases I've described could be easily captured in certificates. However, when it goes wrong, it really goes wrong. Consider when Provider A goes chaper 11, and is bought by Provider B. What are the chances party B gets the key, and the secret phrase to unlock it? What are the chances they have enough history to sign things with the new Provider A key? Who's going to take the time to do all that work? In a really bad scenario you have an entire subtree of the space that is certified, certified wrong. Could these problems be solved? I think so. There are ways to mitigate all of these concerns. Can they be solved in time to save IPv4? I don't think so. Time to look towards IPv6. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From randy at psg.com Fri Mar 7 16:16:50 2008 From: randy at psg.com (Randy Bush) Date: Fri, 07 Mar 2008 13:16:50 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <292DCB81-EAD1-4774-8913- 998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org> <47CF92AE.7070806@apnic.net> <054258CF-4B5D-4A1B-98BA-35E26EC386C9@virtualized.org> <47D0D4D2.4030909@apnic.net> <95F06EFB-BAA6-449F-B020-3E61372A0DBE@pch.net> <47D0E30E.2050508@apnic.net> <47D0FA31.8050105@apnic.net> Message-ID: <47D1B0C2.3010103@psg.com> > Unfortunately, it won't be TE more-specifics being > filtered this time, it will be routes covering unique > end-site locations. why do you think that? seems to me that TE and other defragging is non-product, and end sites are product. as the former are a very large portion of the table, it would seem more productive to stomp them. randy From sleibrand at internap.com Fri Mar 7 16:25:57 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 07 Mar 2008 13:25:57 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47D1B0C2.3010103@psg.com> References: <292DCB81-EAD1-4774-8913- 998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org> <47CF92AE.7070806@apnic.net> <054258CF-4B5D-4A1B-98BA-35E26EC386C9@virtualized.org> <47D0D4D2.4030909@apnic.net> <95F06EFB-BAA6-449F-B020-3E61372A0DBE@pch.net> <47D0E30E.2050508@apnic.net> <47D0FA31.8050105@apnic.net> <47D1B0C2.3010103@psg.com> Message-ID: <47D1B2E5.1040707@internap.com> Randy Bush wrote: >> Unfortunately, it won't be TE more-specifics being >> filtered this time, it will be routes covering unique >> end-site locations. > > why do you think that? seems to me that TE and other defragging is > non-product, and end sites are product. as the former are a very large > portion of the table, it would seem more productive to stomp them. I agree that TE deaggregates will be first to be filtered, but I think it's important that any policy we put in place doesn't create a whole bunch more small unique routes covering end-sites. That will both reduce the need for filtering, and make sure that there can actually be covering aggregates that can make it safe to filter distant deaggregates. -Scott From jhframe at dcn.org Fri Mar 7 16:46:22 2008 From: jhframe at dcn.org (Jim Frame) Date: Fri, 07 Mar 2008 13:46:22 -0800 Subject: [ppml] Legacy RSAs signed In-Reply-To: <47BE755E.3010305@dcn.org> References: <200802212301.m1LN1C6q012697@cjbsys.bdb.com> <47BE755E.3010305@dcn.org> Message-ID: <47D1B7AE.4030302@dcn.org> Jim Frame wrote: > Davis Community Network has signed, though not without reservations. In light of some of the responses to my 02/21 post, DCN has reconsidered the matter and has reviewed the terms of the RSA. Although I wish we had a more perfect understanding of the manner in which IP address space will be treated in a legal sense, I'm comfortable that our decision to sign the RSA was the right one. I'm encouraged by the proposals for transfer policies that I've seen, and am hopeful that in the end the RSA will provide us with a good framework in which to manage a resource that we -- a very small 501(c)(3) -- like to regard as ours. Thanks to all who took the time to contact me offline and offer their insights. -- --------------------------------------------------------------------- Jim Frame jhframe at dcn.org (530) 756-8584 756-8201 (FAX) Frame Surveying & Mapping 609 A Street Davis, CA 95616 -----------------------< Davis Community Network >------------------- From randy at psg.com Fri Mar 7 16:52:31 2008 From: randy at psg.com (Randy Bush) Date: Fri, 07 Mar 2008 13:52:31 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47D1B2E5.1040707@internap.com> References: <292DCB81-EAD1-4774-8913- 998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org> <47CF92AE.7070806@apnic.net> <054258CF-4B5D-4A1B-98BA-35E26EC386C9@virtualized.org> <47D0D4D2.4030909@apnic.net> <95F06EFB-BAA6-449F-B020-3E61372A0DBE@pch.net> <47D0E30E.2050508@apnic.net> <47D0FA31.8050105@apnic.net> <47D1B0C2.3010103@psg.com> <47D1B2E5.1040707@internap.com> Message-ID: <47D1B91F.3030403@psg.com> > I agree that TE deaggregates will be first to be filtered and intentional de-aggs that are not even TE > but I think it's important that any policy we put in place doesn't > create a whole bunch more small unique routes covering end-sites. oh? what if those are legitimate users and new entrants who need unique routing because they are multi-homed or whatever? somehow i do not think that intentionally preventing them by policy is going to stand up for very long. ipv6 and nat-pt (or whatever the tvtf calls it to save face) or massive ipv4/ipv4 nat, whichever way it goes (or it goes both ways!) is gonna cause many *legitimate* small prefixes to be injected in slowly increasing numbers. get over it. this is simply what happens when ostriches pretend there is no need for architectural change in routing given a world where the scale is ever-increasing. the result is you need to handle more routes. this is far from new. welcome to the new line card every year club. what is needed is not policy preventing entrants into the market, but rather router vendors to supply routers that can carry the load. and you can push it out a few years by beating on the vendors to give us knobs to stomp non-product deagg. i have cases filed with j & c for years, and a mailbox of excuses to match. or you can go down the path of lisp. watch out, on the third step there is a sign "magic will happen here". but at least dino is working on the problem a opposed to blowing glossy paper at us. or you can go down the path of multi-natting from PA space with a policy of giving all the PI space to the largest providers. and if you think you can do the latter without having to explain it all to lawyers and politicians (which may not be a bad thing. it can't be all that much harder than explaining it to amateur policy-making friends, and it sure will be more effective), please share what you are smoking. randy From sleibrand at internap.com Fri Mar 7 16:56:50 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 07 Mar 2008 13:56:50 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47D1B91F.3030403@psg.com> References: <292DCB81-EAD1-4774-8913- 998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org> <47CF92AE.7070806@apnic.net> <054258CF-4B5D-4A1B-98BA-35E26EC386C9@virtualized.org> <47D0D4D2.4030909@apnic.net> <95F06EFB-BAA6-449F-B020-3E61372A0DBE@pch.net> <47D0E30E.2050508@apnic.net> <47D0FA31.8050105@apnic.net> <47D1B0C2.3010103@psg.com> <47D1B2E5.1040707@internap.com> <47D1B91F.3030403@psg.com> Message-ID: <47D1BA22.4010805@internap.com> My own proposal is not to slow down the rate of new entrants who need routing slots to multihome. The number of those is growing, but IMO is still manageable. Rather, I want to help prevent the unnecessary addition of multiple non-aggregatable routes per ASN, i.e. by requiring that transferees get 6-12+ months worth of IP space at a time, rather than allowing them to pick up multiple smaller blocks one by one. -Scott Randy Bush wrote: >> I agree that TE deaggregates will be first to be filtered > > and intentional de-aggs that are not even TE > >> but I think it's important that any policy we put in place doesn't >> create a whole bunch more small unique routes covering end-sites. > > oh? what if those are legitimate users and new entrants who need unique > routing because they are multi-homed or whatever? somehow i do not > think that intentionally preventing them by policy is going to stand up > for very long. > > ipv6 and nat-pt (or whatever the tvtf calls it to save face) or massive > ipv4/ipv4 nat, whichever way it goes (or it goes both ways!) is gonna > cause many *legitimate* small prefixes to be injected in slowly > increasing numbers. get over it. > > this is simply what happens when ostriches pretend there is no need for > architectural change in routing given a world where the scale is > ever-increasing. the result is you need to handle more routes. > > this is far from new. welcome to the new line card every year club. > what is needed is not policy preventing entrants into the market, but > rather router vendors to supply routers that can carry the load. > > and you can push it out a few years by beating on the vendors to give us > knobs to stomp non-product deagg. i have cases filed with j & c for > years, and a mailbox of excuses to match. > > or you can go down the path of lisp. watch out, on the third step there > is a sign "magic will happen here". but at least dino is working on the > problem a opposed to blowing glossy paper at us. > > or you can go down the path of multi-natting from PA space with a policy > of giving all the PI space to the largest providers. and if you think > you can do the latter without having to explain it all to lawyers and > politicians (which may not be a bad thing. it can't be all that much > harder than explaining it to amateur policy-making friends, and it sure > will be more effective), please share what you are smoking. > > randy From info at arin.net Fri Mar 7 17:19:07 2008 From: info at arin.net (Member Services) Date: Fri, 07 Mar 2008 17:19:07 -0500 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal - Revised Text Message-ID: <47D1BF5B.9030707@arin.net> Policy Proposal 2008-2, IPv4 Transfer Policy Proposal, has been revised. This proposal is open for discussion on this mailing list and will be on the agenda at the upcoming ARIN Public Policy Meeting in Denver. The current policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2008_2.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2008-2 IPv4 Transfer Policy Proposal Author: ARIN Advisory Council Proposal Version: 1.1 Date: 7 March 2008 Proposal type: modify Policy term: permanent Policy statement: Replace the current NRPM section 8 with the following -- 8. Transfers [8.1. Transfers ? retain as is: Number resources are non-transferable and are not assignable to any other organization unless ARIN has expressly and in writing approved a request for transfer. ARIN is tasked with making prudent decisions on whether to approve the transfer of number resources. It should be understood that number resources are not "sold" under ARIN administration. Rather, number resources are assigned to an organization for its exclusive use for the purpose stated in the request, provided the terms of the Registration Services Agreement continue to be met and the stated purpose for the number resources remains the same. Number resources are administered and assigned according to ARIN's published policies. Number resources are issued, based on justified need, to organizations, not to individuals representing those organizations. Thus, if a company goes out of business, regardless of the reason, the point of contact (POC) listed for the number resource does not have the authority to sell, transfer, assign, or give the number resource to any other person or organization. The POC must notify ARIN if a business fails so the assigned number resources can be returned to the available pool of number resources if a transfer is not requested and justified.] [8.2 ? remove the word ?only?, and retitle to ?Transfers as an Artifact of Change in Resource Holder Ownership?: 8.2. Transfers as an Artifact of Change in Resource Holder Ownership ARIN will consider requests for the transfer of number resources upon receipt of evidence that the new entity has acquired the assets which had, as of the date of the acquisition or proposed reorganization, justified the current entity's use of the number resource. Examples of assets that justify use of the number resource include, but are not limited to: ? Existing customer base ? Qualified hardware inventory ? Specific software requirements.] [Renumber existing 8.3 to 8.2.1 and retitle to ?Documentation Requirements for Transfers as an Artifact of Change in Resource Holder Ownership?: 8.2.1. Documentation Requirements for Transfers as an Artifact of Change in Resource Holder Ownership In evaluating a request for transfer, ARIN may require the requesting organization to provide any of the following documents, as applicable, plus any other documents deemed appropriate: ? An authenticated copy of the instrument(s) effecting the transfer of assets, e.g., bill of sale, certificate of merger, contract, deed, or court decree ? A detailed inventory of all assets utilized by the requesting party in maintaining and using the number resource ? A list of the requesting party's customers using the number resource. If further justification is required, the requesting party may be asked to provide any of the following, or other supporting documentation, as applicable: ? A general listing of the assets or components acquired ? A specific description of acquisitions, including: o Type and quantity of equipment o Customer base ? A description of how number resources are being utilized ? Network engineering plans, including: o Host counts o Subnet masking o Network diagrams o Reassignments to customers] 8.3. Simple Transfer of IPv4 Addresses After the exhaustion of the IANA IPv4 free pool (when IANA allocates its last unallocated unicast IPv4 address block), ARIN will also process IPv4 address transfer requests subject to the following conditions. These conditions apply only to Simple IPv4 transfers, not to transfers performed according to section 8.2. 8.3.1 Conditions on the transferor (the organization providing addresses for transfer): ? The transferor resides in the ARIN service area. ? The transferor has signed an RSA and/or a legacy RSA covering the IPv4 addresses transferred. ? The transferor has no outstanding balances with ARIN. ? The transferor has not received any IPv4 allocations or assignments from ARIN (through ordinary allocations or assignments, or through this Simple Transfer policy) within the preceding 24 months. ? The transferor may not request any IPv4 allocations or assignments from ARIN (through ordinary allocations or assignments, or through this Simple Transfer policy) within the subsequent 24 months. 8.3.2 Conditions on the transferee (the organization receiving the transferred addresses): ? The transferee resides in the ARIN service area and intends to use the transferred IPv4 addresses within the ARIN service area. ? The transferee has no outstanding balances with ARIN. ? The transferee?s need is confirmed by ARIN, according to current ARIN policies, including but not limited to confirmation of utilization rate of any prior IPv4 allocations, assignments, or previously transferred IPv4 addresses held by the transferee. ? The transferee signs (or has previously signed) an RSA covering the IPv4 addresses transferred. ? The transferee has not provided any IPv4 addresses for transfer through this Simple Transfer process within the preceding 24 months. ? The transferee may not provide any IPv4 addresses for transfer through this Simple Transfer process within the subsequent 24 months, except in the case of business failure. ? The transferee may request and receive a contiguous CIDR block large enough to provide a 12 month supply of IPv4 addresses. ? The transferee may only receive one IPv4 address transfer through this Simple Transfer process every 6 months. 8.3.3 Conditions on the IPv4 address block to be transferred: ? The IPv4 block must comply with applicable ARIN requirements, including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4., 4.3.2., 4.3.6.). However, an IPv4 allocation or assignment of /24 or larger, but smaller than the current minimum allocation size, may be transferred as a whole resource, but may not be subdivided. ? The IPv4 block must currently be registered for use within the ARIN service area, either as part of an address block assigned by IANA to ARIN, or as part of a legacy address block allocated within the ARIN service area. ? There must exist no dispute as to the status of the IPv4 block or regarding the allocation or assignment of such block to the transferor. ? The transferor may retain one contiguous address range out of their original allocation or assignment for their own use, and transfer the other contiguous address range. If the address range to be transferred consists of multiple non-aggregatable CIDR blocks, each may be transferred to a different transferee. The retained address range may not be further subdivided or transferred for a period of 12 months. Notwithstanding the preceding, the block may be subdivided as provided in section 8.3.6. 8.3.4 Fees ? Completion of a transfer requires payment of a transfer fee according to ARIN?s schedule of fees. ? The transferee will be subject to all future ARIN membership and service fees according to the transferee?s total address holdings. 8.3.5 Pre-qualification ? An interested transferee must seek pre-qualification from ARIN to confirm its eligibility to receive a transfer (including satisfaction of need according to current ARIN policies) before making any solicitation for transfer. Upon pre-qualification, ARIN will provide the transferee with documentation of the pre-qualification, including the size (CIDR prefix length) of the largest IPv4 address block the transferee is eligible to receive, and the expiration date of the pre-qualification. ? An interested transferor must seek pre-qualification from ARIN to confirm its eligibility to offer a transfer (including lack of outstanding balances and having signed an RSA) before offering IPv4 address resources for transfer. Upon pre-qualification, ARIN will provide the transferor with documentation of the pre-qualification, including the network block and the expiration date of the pre-qualification. 8.3.6 Deaggregation when Permitted by ARIN If ARIN determines that there is an inadequate supply of small blocks, ARIN may allow transferors to subdivide network blocks beyond the limited subdivision permitted under 8.3.3. ARIN will attempt to ensure an adequate supply of small blocks while minimizing deaggregation. 8.3.7. Safe Harbor for IPv4 Transfers through this Simple Transfer Process When an IPv4 address resource is made available for transfer, it shall be deemed exempt from ARIN utilization audit until 90 days after its transfer pre-qualification or until the transfer is completed, whichever comes first. In the event that a transfer is not consummated within the prequalification time period, the block may be immediately re-prequalified for transfer. Notwithstanding the current offered state of the address resource, however, the audit exemption period shall expire untolled 90 days after the expiration of the first pre-qualification period. After the expiration of any utilization audit exemption period, ARIN shall have 90 days in which to initiate a utilization audit. In no event shall non-exempt time be construed to extend the end of the next exemption period. 8.3.8. Simple IPv4 Transfers to or from Organizations Under Common Ownership or Control If an IPv4 transferor or transferee is under common ownership or control with any other organization that holds one or more IPv4 blocks, the IPv4 transfer request must report all such organizations under common ownership or control. When evaluating compliance with IPv4 Simple Transfer conditions, ARIN may consider a transferor?s transfer request in light of requests from other organizations under common ownership or control with the transferor. Similarly, ARIN may consider a transferee?s request in light of requests from other organizations under common ownership or control with the transferee. In evaluating requests from other organizations under common ownership or control, ARIN staff will consider the relationship between the organizations, the degree of coordination between the organizations, and the bona fide use of the addresses at issue to determine whether all appropriate conditions are met. 8.3.9. Record-keeping and Publication of Simple Transfers of IPv4 Addresses ARIN will develop and operate a listing service to assist interested transferors and transferees by providing them a centralized location to post information about IPv4 blocks available from prequalified transferors and IPv4 blocks needed by prequalified transferees. Participation in the listing service is voluntary. After completion of the transfer, ARIN will update the registration records pertaining to the IPv4 block at issue. ARIN will adjust its records as to the holdings of the transferor and transferee. After the transfer, ARIN will publish WHOIS data that reflects the current allocation or assignment of the transferred block. ARIN will also make available information about any prior recipient(s) of such block. ARIN will also publish a log of all transfers, including block, transferor, transferee, and date. Rationale: The ARIN Board of Trustees asked the Advisory Council to consider a set of questions around the depletion of the free pool of IPv4 addresses, the transition to IPv6 for Internet address needs in the future, and ARIN's possible role in easing the transition. Over the past few years the AC has spent a great deal of time reflecting on these issues ? as a group, as individuals, and in consultation with the community. One outcome of this process is this policy proposal, which the AC is submitting for consideration at the next meeting. We are proposing some changes to existing ARIN policy regarding the transfer of IP address block registrations between subscribers, which will allow for the emergence of trade in IPv4 address space, with ARIN to provide a listing service for address blocks available for transfer under the liberalized policy. We are aware that this proposal, if adopted, will mark a major change in ARIN's role in the community and the Internet. This policy proposal would create a transfer mechanism for IPv4 number resources between those who have excess resources and those who have a need, thereby allowing ARIN to continue to serve its mission after IANA free pool exhaustion. This proposal would also set conditions on such transfers intended to preserve as much as possible the existing policy related to efficient, needs-based resource issuance, and would leverage ARIN's extensive control systems, audit trails, and recognized position as a trusted agent to avoid speculation and hoarding and diminish the likelihood and extent of an uncontrolled 'black market' where the risk and potential for fraud is immeasurably higher. Many of the transfer conditions are self-explanatory, but some worth highlighting are that: ? To discourage speculation, a waiting period (proposed at 24 months) is required before a transferee (or ordinary resource recipient) can become a transferor, or vice versa. ? Transferees must qualify for IPv4 space (just as they do today when getting it from ARIN) before they can receive address space by transfer, or solicit space on a listing service. ? To discourage unnecessarily rapid growth of routing tables, an allocation or assignment may not be arbitrarily deaggregated. To allow a transferor to downsize within their existing space, they may split off a contiguous address range, once every 12 months, and transfer the resulting netblock(s), which are subject to ARIN?s minimum allocation size, to one or more transferee(s). ? A transferee may receive one transfer every 6 months, so they?ll be incented to transfer a block appropriately sized for their needs, which will further discourage deaggregation and keep smaller blocks available for smaller organizations. The proposal would also have ARIN develop and operate a listing service to facilitate transfers and provide an authoritative central source of information on space available and requested for transfer. It would not prohibit private party transactions, but would require that potential transferors and transferees be pre-qualified first, so that neither party will encounter any unexpected surprises when they ask ARIN to process the transfer. Timetable for implementation: Immediately, with most aspects of policy taking effect upon IANA exhaustion, per the policy text. From sleibrand at internap.com Fri Mar 7 17:19:28 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 07 Mar 2008 14:19:28 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <5BC5F153-9C9B-45D9-9C13-CD62E828191E@virtualized.org> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF2CD3.6090706@internap.com> <5BC5F153-9C9B-45D9-9C13-CD62E828191E@virtualized.org> Message-ID: <47D1BF70.9080402@internap.com> David Conrad wrote: > As for unnecessary deaggregation, what is or is not necessary is likely > a matter of opinion. I firmly believe ISPs will look after themselves > as they have done in the past and are doing so today by applying filters > if they feel their infrastructure is at risk. In this particular > respect, we've been here before and some folks still have the T-shirts > (hopefully they've been washed). I'd be curious to understand why past > solutions would not apply. The type of unnecessary deaggregation I'm trying to avoid is this: Organization A's IPv4 needs are growing, but their budget is tight. In order to meet this quarter's needs, they transfer a block from org B. Next quarter, they again need new addresses, so they transfer another block from org C. Before the year is out, they have at least 3 extra routes in the routing table, which can't be aggregated, nor can they be filtered without breaking connectivity. Rather, I'd like to require A to get a large enough block up front to meet their needs for 6-12+ months, thereby reducing the amount of deaggregation and the externality effects on the rest of the Internet. (And if they really can't afford 6 months of space, they can always lease PA space from their ISP or another LIR.) >>> b) What tools exist (or can be expected to exist given reasonable >>> time/resources) to enforce that policy? >> >> The main tool is that, as the recognized authority in registration of >> IPv4 addresses in North America, recognition as valid of any transfers >> by ARIN has considerable value to both transferors and transferees. > > So it would seem a core criteria in any policy would be to minimize > effects that would force folks to go elsewhere to have their transfers > recognized, no? I don't think those effects have to be minimized, if the limitations help meet other goals. But we do need to make sure that the costs of those effects is less than the benefits of using the white market. >>> - the 6 month restriction could force folks to go outside the policy >>> in desperation (e.g., the amount of address space available via >>> transfers is likely to be hard to predict. You could be in a >>> situation where at one point in time, the only option is a small >>> block even though you know it won't last 6 months. What option do >>> you have?) >> >> You could get PA space from your ISP or another LIR. > > I am assuming the folks most interested in getting address space will be > ISPs so they can continue adding customers. Is the assumption of this > policy that the consumers of address space are end users? Agreed. Most end users will get their space from ISPs. Most ISPs would probably prefer to "own" their own IPv4 space, but in a pinch they could get addresses from an upstream or a non-connected LIR (say a /8 holder who'd rather lease out space than transfer it). > I fear the restrictions you are imposing will make it essentially > impossible to "do it right" and will result in folks with address space > finding other outlets in which to meet the needs of those who need > address space. However, perhaps I misjudge the situation. Can you identify which restrictions are onerous and would force people to go elsewhere? We just submitted version 1.1 (which should be posted to PPML today), which allows deaggregation of transfered blocks to the level required to ensure adequate supply at smaller block sizes. -Scott From sleibrand at internap.com Fri Mar 7 17:38:36 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 07 Mar 2008 14:38:36 -0800 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal - Revised Text In-Reply-To: <47D1BF5B.9030707@arin.net> References: <47D1BF5B.9030707@arin.net> Message-ID: <47D1C3EC.9070405@internap.com> Here's a list of changes we made between 1.0 and 1.1: - Removed undefined "M&A" from the new title of the existing policy, and retitled it "Transfers as an Artifact of Change in Resource Holder Ownership" - Per staff suggestion, renumbered existing 8.3 to 8.2.1, to make it clear it goes with the other existing policy, and is separate from the new policy. - Per staff suggestion, renumbered all of the new policy text under a single policy section, 8.3. - At staff request, defined IANA exhaustion (when IANA allocates its last unallocated unicast IPv4 address block) in 8.3. - Per thread with Jason on PPML, added clarifying statement in 8.3 that "These conditions apply only to Simple IPv4 transfers, not to transfers performed according to section 8.2." - At staff request, defined transferor in 8.3.1 and transferee in 8.3.2. - Per PPML discussion, added "The transferee may request and receive a contiguous CIDR block large enough to provide a 12 month supply of IPv4 addresses." under 8.3.2. - In response to staff comment, added "through this Simple Transfer process" to clarify the 8.3.2 condition that "The transferee may only receive one IPv4 address transfer through this Simple Transfer process every 6 months." - In order to avoid having an inadequate supply of smaller blocks, added section 8.3.6 to allow limited deaggregation of transfered blocks at ARIN discretion, to the level required to "ensure an adequate supply of small blocks while minimizing deaggregation." - Re-worded the 8.3.7 Safe Harbor statement for clarity. - In response to staff comment, added clarification to 8.3.8 that "Participation in the listing service is voluntary." -Scott Member Services wrote: > Policy Proposal 2008-2, IPv4 Transfer Policy Proposal, has been revised. > This proposal is open for discussion on this mailing list and will be on > the agenda at the upcoming ARIN Public Policy Meeting in Denver. > > The current policy proposal text is provided below and is also available > at: http://www.arin.net/policy/proposals/2008_2.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ### * ### > > > Policy Proposal 2008-2 > IPv4 Transfer Policy Proposal > > Author: ARIN Advisory Council > > Proposal Version: 1.1 > > Date: 7 March 2008 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Replace the current NRPM section 8 with the following -- > > 8. Transfers > > [8.1. Transfers ? retain as is: > > Number resources are non-transferable and are not assignable to any > other organization unless ARIN has expressly and in writing approved a > request for transfer. ARIN is tasked with making prudent decisions on > whether to approve the transfer of number resources. > > It should be understood that number resources are not "sold" under ARIN > administration. Rather, number resources are assigned to an organization > for its exclusive use for the purpose stated in the request, provided > the terms of the Registration Services Agreement continue to be met and > the stated purpose for the number resources remains the same. Number > resources are administered and assigned according to ARIN's published > policies. > > Number resources are issued, based on justified need, to organizations, > not to individuals representing those organizations. Thus, if a company > goes out of business, regardless of the reason, the point of contact > (POC) listed for the number resource does not have the authority to > sell, transfer, assign, or give the number resource to any other person > or organization. The POC must notify ARIN if a business fails so the > assigned number resources can be returned to the available pool of > number resources if a transfer is not requested and justified.] > > [8.2 ? remove the word ?only?, and retitle to ?Transfers as an Artifact > of Change in Resource Holder Ownership?: > > 8.2. Transfers as an Artifact of Change in Resource Holder Ownership > ARIN will consider requests for the transfer of number resources upon > receipt of evidence that the new entity has acquired the assets which > had, as of the date of the acquisition or proposed reorganization, > justified the current entity's use of the number resource. Examples of > assets that justify use of the number resource include, but are not > limited to: > ? Existing customer base > ? Qualified hardware inventory > ? Specific software requirements.] > [Renumber existing 8.3 to 8.2.1 and retitle to ?Documentation > Requirements for Transfers as an Artifact of Change in Resource Holder > Ownership?: > > 8.2.1. Documentation Requirements for Transfers as an Artifact of Change > in Resource Holder Ownership In evaluating a request for transfer, ARIN > may require the requesting organization to provide any of the following > documents, as applicable, plus any other documents deemed appropriate: > ? An authenticated copy of the instrument(s) effecting the transfer of > assets, e.g., bill of sale, certificate of merger, contract, deed, or > court decree > ? A detailed inventory of all assets utilized by the requesting party in > maintaining and using the number resource > ? A list of the requesting party's customers using the number resource. > If further justification is required, the requesting party may be asked > to provide any of the following, or other supporting documentation, as > applicable: > ? A general listing of the assets or components acquired > ? A specific description of acquisitions, including: > o Type and quantity of equipment > o Customer base > ? A description of how number resources are being utilized > ? Network engineering plans, including: > o Host counts > o Subnet masking > o Network diagrams > o Reassignments to customers] > > 8.3. Simple Transfer of IPv4 Addresses > > After the exhaustion of the IANA IPv4 free pool (when IANA allocates its > last unallocated unicast IPv4 address block), ARIN will also process > IPv4 address transfer requests subject to the following conditions. > These conditions apply only to Simple IPv4 transfers, not to transfers > performed according to section 8.2. > > 8.3.1 Conditions on the transferor (the organization providing addresses > for transfer): > ? The transferor resides in the ARIN service area. > ? The transferor has signed an RSA and/or a legacy RSA covering the IPv4 > addresses transferred. > ? The transferor has no outstanding balances with ARIN. > ? The transferor has not received any IPv4 allocations or assignments > from ARIN (through ordinary allocations or assignments, or through this > Simple Transfer policy) within the preceding 24 months. > ? The transferor may not request any IPv4 allocations or assignments > from ARIN (through ordinary allocations or assignments, or through this > Simple Transfer policy) within the subsequent 24 months. > > 8.3.2 Conditions on the transferee (the organization receiving the > transferred addresses): > ? The transferee resides in the ARIN service area and intends to use the > transferred IPv4 addresses within the ARIN service area. > ? The transferee has no outstanding balances with ARIN. > ? The transferee?s need is confirmed by ARIN, according to current ARIN > policies, including but not limited to confirmation of utilization rate > of any prior IPv4 allocations, assignments, or previously transferred > IPv4 addresses held by the transferee. > ? The transferee signs (or has previously signed) an RSA covering the > IPv4 addresses transferred. > ? The transferee has not provided any IPv4 addresses for transfer > through this Simple Transfer process within the preceding 24 months. > ? The transferee may not provide any IPv4 addresses for transfer through > this Simple Transfer process within the subsequent 24 months, except in > the case of business failure. > ? The transferee may request and receive a contiguous CIDR block large > enough to provide a 12 month supply of IPv4 addresses. > ? The transferee may only receive one IPv4 address transfer through this > Simple Transfer process every 6 months. > > 8.3.3 Conditions on the IPv4 address block to be transferred: > ? The IPv4 block must comply with applicable ARIN requirements, > including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4., 4.3.2., > 4.3.6.). However, an IPv4 allocation or assignment of /24 or larger, but > smaller than the current minimum allocation size, may be transferred as > a whole resource, but may not be subdivided. > ? The IPv4 block must currently be registered for use within the ARIN > service area, either as part of an address block assigned by IANA to > ARIN, or as part of a legacy address block allocated within the ARIN > service area. > ? There must exist no dispute as to the status of the IPv4 block or > regarding the allocation or assignment of such block to the transferor. > ? The transferor may retain one contiguous address range out of their > original allocation or assignment for their own use, and transfer the > other contiguous address range. If the address range to be transferred > consists of multiple non-aggregatable CIDR blocks, each may be > transferred to a different transferee. The retained address range may > not be further subdivided or transferred for a period of 12 months. > Notwithstanding the preceding, the block may be subdivided as provided > in section 8.3.6. > > 8.3.4 Fees > ? Completion of a transfer requires payment of a transfer fee according > to ARIN?s schedule of fees. > ? The transferee will be subject to all future ARIN membership and > service fees according to the transferee?s total address holdings. > > 8.3.5 Pre-qualification > > ? An interested transferee must seek pre-qualification from ARIN to > confirm its eligibility to receive a transfer (including satisfaction of > need according to current ARIN policies) before making any solicitation > for transfer. Upon pre-qualification, ARIN will provide the transferee > with documentation of the pre-qualification, including the size (CIDR > prefix length) of the largest IPv4 address block the transferee is > eligible to receive, and the expiration date of the pre-qualification. > ? An interested transferor must seek pre-qualification from ARIN to > confirm its eligibility to offer a transfer (including lack of > outstanding balances and having signed an RSA) before offering IPv4 > address resources for transfer. Upon pre-qualification, ARIN will > provide the transferor with documentation of the pre-qualification, > including the network block and the expiration date of the > pre-qualification. > > 8.3.6 Deaggregation when Permitted by ARIN > > If ARIN determines that there is an inadequate supply of small blocks, > ARIN may allow transferors to subdivide network blocks beyond the > limited subdivision permitted under 8.3.3. ARIN will attempt to ensure > an adequate supply of small blocks while minimizing deaggregation. > > 8.3.7. Safe Harbor for IPv4 Transfers through this Simple Transfer Process > > When an IPv4 address resource is made available for transfer, it shall > be deemed exempt from ARIN utilization audit until 90 days after its > transfer pre-qualification or until the transfer is completed, whichever > comes first. > > In the event that a transfer is not consummated within the > prequalification time period, the block may be immediately > re-prequalified for transfer. Notwithstanding the current offered state > of the address resource, however, the audit exemption period shall > expire untolled 90 days after the expiration of the first > pre-qualification period. After the expiration of any utilization audit > exemption period, ARIN shall have 90 days in which to initiate a > utilization audit. In no event shall non-exempt time be construed to > extend the end of the next exemption period. > > 8.3.8. Simple IPv4 Transfers to or from Organizations Under Common > Ownership or Control > > If an IPv4 transferor or transferee is under common ownership or control > with any other organization that holds one or more IPv4 blocks, the IPv4 > transfer request must report all such organizations under common > ownership or control. > > When evaluating compliance with IPv4 Simple Transfer conditions, ARIN > may consider a transferor?s transfer request in light of requests from > other organizations under common ownership or control with the > transferor. Similarly, ARIN may consider a transferee?s request in light > of requests from other organizations under common ownership or control > with the transferee. In evaluating requests from other organizations > under common ownership or control, ARIN staff will consider the > relationship between the organizations, the degree of coordination > between the organizations, and the bona fide use of the addresses at > issue to determine whether all appropriate conditions are met. > > 8.3.9. Record-keeping and Publication of Simple Transfers of IPv4 Addresses > > ARIN will develop and operate a listing service to assist interested > transferors and transferees by providing them a centralized location to > post information about IPv4 blocks available from prequalified > transferors and IPv4 blocks needed by prequalified transferees. > Participation in the listing service is voluntary. > > After completion of the transfer, ARIN will update the registration > records pertaining to the IPv4 block at issue. ARIN will adjust its > records as to the holdings of the transferor and transferee. > > After the transfer, ARIN will publish WHOIS data that reflects the > current allocation or assignment of the transferred block. ARIN will > also make available information about any prior recipient(s) of such > block. ARIN will also publish a log of all transfers, including block, > transferor, transferee, and date. > > > > Rationale: > The ARIN Board of Trustees asked the Advisory Council to consider a set > of questions around the depletion of the free pool of IPv4 addresses, > the transition to IPv6 for Internet address needs in the future, and > ARIN's possible role in easing the transition. > > Over the past few years the AC has spent a great deal of time reflecting > on these issues ? as a group, as individuals, and in consultation with > the community. One outcome of this process is this policy proposal, > which the AC is submitting for consideration at the next meeting. We are > proposing some changes to existing ARIN policy regarding the transfer of > IP address block registrations between subscribers, which will allow for > the emergence of trade in IPv4 address space, with ARIN to provide a > listing service for address blocks available for transfer under the > liberalized policy. We are aware that this proposal, if adopted, will > mark a major change in ARIN's role in the community and the Internet. > > This policy proposal would create a transfer mechanism for IPv4 number > resources between those who have excess resources and those who have a > need, thereby allowing ARIN to continue to serve its mission after IANA > free pool exhaustion. This proposal would also set conditions on such > transfers intended to preserve as much as possible the existing policy > related to efficient, needs-based resource issuance, and would leverage > ARIN's extensive control systems, audit trails, and recognized position > as a trusted agent to avoid speculation and hoarding and diminish the > likelihood and extent of an uncontrolled 'black market' where the risk > and potential for fraud is immeasurably higher. > > Many of the transfer conditions are self-explanatory, but some worth > highlighting are that: > ? To discourage speculation, a waiting period (proposed at 24 months) is > required before a transferee (or ordinary resource recipient) can become > a transferor, or vice versa. > ? Transferees must qualify for IPv4 space (just as they do today when > getting it from ARIN) before they can receive address space by transfer, > or solicit space on a listing service. > ? To discourage unnecessarily rapid growth of routing tables, an > allocation or assignment may not be arbitrarily deaggregated. To allow a > transferor to downsize within their existing space, they may split off a > contiguous address range, once every 12 months, and transfer the > resulting netblock(s), which are subject to ARIN?s minimum allocation > size, to one or more transferee(s). > ? A transferee may receive one transfer every 6 months, so they?ll be > incented to transfer a block appropriately sized for their needs, which > will further discourage deaggregation and keep smaller blocks available > for smaller organizations. > The proposal would also have ARIN develop and operate a listing service > to facilitate transfers and provide an authoritative central source of > information on space available and requested for transfer. It would not > prohibit private party transactions, but would require that potential > transferors and transferees be pre-qualified first, so that neither > party will encounter any unexpected surprises when they ask ARIN to > process the transfer. > > Timetable for implementation: Immediately, with most aspects of policy > taking effect upon IANA exhaustion, per the policy text. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From drc at virtualized.org Fri Mar 7 19:10:27 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 7 Mar 2008 16:10:27 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47D1BF70.9080402@internap.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF2CD3.6090706@internap.com> <5BC5F153-9C9B-45D9-9C13-CD62E828191E@virtualized.org> <47D1BF70.9080402@internap.com> Message-ID: Scott, On Mar 7, 2008, at 2:19 PM, Scott Leibrand wrote: > Organization A's IPv4 needs are growing, but their budget is tight. > In order to meet this quarter's needs, they transfer a block from > org B. Next quarter, they again need new addresses, so they transfer > another block from org C. Before the year is out, they have at > least 3 extra routes in the routing table, which can't be > aggregated, nor can they be filtered without breaking connectivity. Sounds plausible. > Rather, I'd like to require A to get a large enough block up front > to meet their needs for 6-12+ months, thereby reducing the amount of > deaggregation and the externality effects on the rest of the > Internet. (And if they really can't afford 6 months of space, they > can always lease PA space from their ISP or another LIR.) Assuming they can find it. You presume there are options available to organization A that I'm somewhat skeptical will actually exist. There will always be incentive to minimize the number of number of blocks being announced if you have to go out and find those blocks and then convince your ISP(s) to actually route them so if folk are having to go find address space, they're presumably doing it for a good reason. I suppose we'll see. > Can you identify which restrictions are onerous and would force > people to go elsewhere? We just submitted version 1.1 (which should > be posted to PPML today), which allows deaggregation of transfered > blocks to the level required to ensure adequate supply at smaller > block sizes. Will review and comment, hopefully by Monday, but I would point out that people go to the purely black market today so the restrictions folks face today would appear to be too onerous. Adding vast tracts of new regulation would seem likely to increase the number of folks forced into the black market. Regards, -drc From sleibrand at internap.com Fri Mar 7 19:29:59 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 07 Mar 2008 16:29:59 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF2CD3.6090706@internap.com> <5BC5F153-9C9B-45D9-9C13-CD62E828191E@virtualized.org> <47D1BF70.9080402@internap.com> Message-ID: <47D1DE07.7090002@internap.com> David Conrad wrote: > Scott, > > On Mar 7, 2008, at 2:19 PM, Scott Leibrand wrote: >> Rather, I'd like to require A to get a large enough block up front to >> meet their needs for 6-12+ months, thereby reducing the amount of >> deaggregation and the externality effects on the rest of the >> Internet. (And if they really can't afford 6 months of space, they >> can always lease PA space from their ISP or another LIR.) > > Assuming they can find it. You presume there are options available to > organization A that I'm somewhat skeptical will actually exist. There > will always be incentive to minimize the number of number of blocks > being announced if you have to go out and find those blocks and then > convince your ISP(s) to actually route them so if folk are having to go > find address space, they're presumably doing it for a good reason. Yes, I do think that once the market gets started (shortly after IANA exhaustion), transferors will begin offering blocks of every size. If/when those blocks get transferred, additional blocks will be offered. I don't foresee supply drying up: there should always be blocks available at a price that's not too different (on a per-IP basis) between different block sizes. In order to make sure this happens, we do need to allow some level of deaggregation of offered netblocks down to the size level demanded by new entrants. I think we could simply allow deaggregation by transferors, and keep the 6-month-supply restriction on transferees. Others feel that this would result in excessive deaggregation at the beginning, and would leave too few larger blocks later on. As a compromise, the 1.1 draft gives ARIN discretion to gradually adjust the level of deaggregation permitted, to ensure that blocks of all sizes are always available at comparable prices. > I suppose we'll see. Yes, we definitely will, and can adjust policy later as needed, but hopefully we can also foresee enough to put decent policy in place before free pool exhaustion. >> Can you identify which restrictions are onerous and would force people >> to go elsewhere? We just submitted version 1.1 (which should be >> posted to PPML today), which allows deaggregation of transfered blocks >> to the level required to ensure adequate supply at smaller block sizes. > > Will review and comment, hopefully by Monday, Thanks. > but I would point out that > people go to the purely black market today so the restrictions folks > face today would appear to be too onerous. Adding vast tracts of new > regulation would seem likely to increase the number of folks forced into > the black market. We seem to be operating off different assumptions here. As far as I can tell the level of black market transfers today is very small in comparison to the white market (addresses acquired from ARIN). I also don't see the transfer policy as "adding vast tracts of new regulation": most of the restrictions in the transfer policy mirror restrictions in existing ARIN policy for space acquired out of the free pool. There are a few new restrictions, but generally they take the place of other (more complex) restrictions in existing free-pool-allocation policy. -Scott From sleibrand at internap.com Fri Mar 7 19:40:25 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 07 Mar 2008 16:40:25 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> <20080305171211.GI12712@shell01.cell.sv2.tellme.com> <447C2865-04A1-4680-BEE1-3974ADE3ADD3@virtualized.org><47CF92AE.7070806@apnic.net><054258CF-4B5D-4A1B-98BA-35E26EC386C9@virtualized.org><47D0D4D2.4030909@apnic.net><95F06EFB-BAA6-449F-B020-3E61372A0DBE@pch.net> <47D0E30E.2050508@apnic.net> Message-ID: <47D1E079.6000203@internap.com> michael.dillon at bt.com wrote: > The fact is that nobody needs to be dependent on new IPv4 > addresses after the runout date. There is plenty of time for > companies to make their businesses work with a mix of IPv6 and > IPv4. There have been some very public demonstrations of this > mixture at the last ARIN and NANOG meetings. There will be > another demo at the upcoming IETF meeting. So far, if you > examine the results of these demonstrations, there are no > serious problems that could not be fixed within a two year > timeframe. And we do have two years, probably more, to fix > these issues. I hope you're right, but I'm not willing to bet the industry on it. I for one haven't even seen *plans* for supporting line-rate translation at the scale required (10Gbps+). > Once it is demonstrably possible to run a fully mixed IPv4 > and IPv6 network, the need for transfers disappears. Note > that I am not referring here to dual-stack networks. When > I say MIXED I mean that you have some endpoints that are > IPv4 and some endpoints that are IPV6 and that they can > both communicate with each other over infrastructure that > has at least one pure IPv6 section in it. I agree with your conditional statement, but I don't believe that such mixed networking will be possible across-the-board before IPv4 free pool exhaustion. If I'm wrong, great: we've just wasted some time planning for a disaster that didn't occur. But if you're wrong, and we don't have a plan B, then we'll have a big problem on our hands. -Scott From paul at vix.com Fri Mar 7 20:42:33 2008 From: paul at vix.com (Paul Vixie) Date: Sat, 08 Mar 2008 01:42:33 +0000 Subject: [ppml] it's sort of pretty when you see it this way Message-ID: <45572.1204940553@sa.vix.com> it seems possible to me that a thread dominated by the usual suspects isn't getting any attention from anybody. the usual suspects are pounding the table from their usual position, and lurkers are using kill-by-thread to avoid hearing it all again. but, the way my reader chooses to render it is by indenting direct replies, which in this case ended up with a rather pretty pattern. before i killed-by- thread, that is. you guys need to stop worrying about getting the last word, or something. re: Geoff Huston ] Re: [ppml] NANOG IPv4 Exhaustion BoF < 65: Tom Vest > [ 79: Geoff Huston ] [ 61: "Tony Hain" ] [ 52: Scott Leibrand ] [ 125: Tom Vest ] [ 28: Scott Leibrand ] < 117: Tom Vest > [ 80: Scott Leibrand ] [ 100: Michael Smith ] [ 90: Scott Leibrand ] [ 161: Tom Vest ] [ 126: Randy Bush ] Re: [ppml] NANOG IPv4 Exhaustion BoF [ 172: Tom Vest ] [ 35: Randy Bush ] [ 45: John Curran ] [ 116: Leo Bicknell ] [ 51: David Conrad ] [ 113: Leo Bicknell ] [ 30: Joe Maimon ] [ 97: Leo Bicknell ] [ 25: David Conrad ] [ 84: michael.dillon at bt.co] [ 62: Michael Smith ] [ 25: Randy Bush ] [ 83: michael.dillon at bt.co] < 70: David Conrad > Re: [ppml] NANOG IPv4 Exhaustion BoF [ 104: Geoff Huston ] [ 37: Tom Vest ] [ 65: Geoff Huston ] [ 56: John Curran ] [ 55: Geoff Huston ] [ 39: John Curran ] [ 49: David Conrad ] [ 28: John Curran ] [ 43: David Conrad ] [ 23: John Curran ] [ 17: Randy Bush [ 24: Scott Leibrand [ 49: Randy Bush [ 59: Scott [ 65: michael.dillon at bt.co] [ 23: Leo Vegoda ] [ 42: Scott Leibrand ] [ 53: Joe Maimon ] [ 30: David Conrad ] < 102: David Conrad > [ 76: Scott Leibrand ] [ 50: David Conrad ] [ 73: Scott Leibrand ] < 38: David Conrad > [ 81: Leo Bicknell ] From sleibrand at internap.com Fri Mar 7 20:52:42 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 07 Mar 2008 17:52:42 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <266485D2-F010-49BB-B576-AFBFE5D329DC@pch.net> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D05D88.4050400@internap.com> <23785B40-BAA3-4A06-9DB9-EB82FA0F0885@pch.net> <47D0C4A5.3000402@internap.com> <266485D2-F010-49BB-B576-AFBFE5D329DC@pch.net> Message-ID: <47D1F16A.1050107@internap.com> Tom Vest wrote: > > On Mar 6, 2008, at 11:29 PM, Scott Leibrand wrote: > >> I think the main reason legitimate transfers (ones recognized by the >> recognized authority on who holds a resource, the RIR) will be favored >> by most potential participants due to the reduced risk of using such a >> system. For example, if I need IPv4 space after exhaustion, I could >> either go to ARIN, demonstrate to them that I need the space, and have >> access to a centralized listing service of transferors, all of whom >> ARIN has vouched for as being the legitimate holders of the addresses >> they're transferring. > > Okay, all of this holds, but only for (RSA->RSA) transactions, which > seem to me to be fairly low probability events until some/many large > members are well into IPv6 migration. Of course I could turn out to be > wrong, esp. is sidr is very widely adopted by current RSA > non-signatories (thereby presumably becoming ARIN members)... Are you familiar with the legacy RSA? It's a new version of the RSA specifically designed to recognize and preserve most of the rights of legacy holders. I believe that the opportunity to transfer addresses will be a strong incentive for many legacy holders (like Jim Frame) to sign the legacy RSA. >> I anticipate that this will prompt a large number of resource holders >> to update out-of-date contact information, and will prompt a number of >> legacy holders to sign legacy RSAs. > > Although there are probably a few real Rip Van Winkles out there, I > think it is more reasonable to assume that most remaining legacy > non-signatories are motivated by something other than ignorance of the > opportunity to follow the rules. Perhaps the proposed transfer process > will achieve such prominence and critical mass that legacy resource > holders will waive their self-declared right to do whatever they want > with their resources. Perhaps none of them will find it more > convenient/profitable to sell around the official mechanism and its > rules. I wonder how high "white market" prices will have to go for all > of these assumptions to hold true (note: foreshadowing for the new > entrants point below)... > > Perhaps no RSA signatory will be tempted to jump the queue and trawl the > gray market. I think the incentive for legacy holders to use the white market will be, quite simply, that prices are higher and there are more buyers there. The reason for this will be because potential transferees have a strong incentive to ensure that they are recognized as the proper holder of the addresses they've paid for. The black market won't be able to provide that, so prices will be lower there, and the only addresses supplied at lower prices on the black market will be from address holders who can't prove to ARIN that they're the legitimate holder of the addresses. > Perhaps all are willing to continue abiding by needs-based > allocation rules, even if that means that the wait for address space > could be very long. Why would anyone have to wait for address space? If they're willing to pay the market price for it, there should always be space available. > But if that's so, there are probably better > mechanisms to leverage this will to coordination that are less risky and > volatile and unpredictable... There definitely will be some volatility to a market solution, but I think it actually manages risk and predictability pretty well. There certainly are a lot of economists and financial folks who've developed all the tools we could possibly need to understand the market and predict what it's likely to do, especially as things actually start to play out. >> I don't anticipate that a market will price out new entrants. In >> fact, I favor the transfer policy proposal precisely because it >> provides an avenue for new and growing networks who need IPv4 space to >> get it after free pool exhaustion. > > > I concede that Richard Branson will always be able to start a new ISP if > he wants to, so in principle the industry will always remain "open" in > some trivial sense. The kind of "open" I was referring to was the more > functional/pragmatic kind -- i.e., the kind that mollifies internal > critics and makes them more likely to identify their interests with > community and its institutions rather than an aspiring competitor, the > kind that persuades anti-trust authorities to move on, because there's > nothing to see here... I think you're making an unsubstantiated assumption that prices in a transfer market will get extremely high. But as long as decent substitutes (IPv6, NAT, etc.) exist for some fraction of the IPv4 address holders, the price will never get higher than the marginal cost of freeing up IPv4 addresses. >> In my opinion, the supply curve for IPv4 addresses will be somewhat >> elastic, meaning that as the price goes up many IPv4 address holders >> will begin to free up IPv4 addresses and make them available. > > I agree, but I believe that there are better, less volatile, more > sustainable methods to leverage that elasticity, so that the needs-based > allocation regime and all of the collateral values that have gotten a > (largely unnoticed) free ride on it over the last decade can be preserved. > >> Demand will be elastic as well (quantity demanded will go down as the >> price increases), > > I agree here too, but I believe that there are better, less volatile, > more sustainable methods to manage that elasticity so that it is spread > across all resource users rather than killing the newest/smallest first. As per above, I don't think a transfer market will price out ("kill") new/small entrants. Rather, their cost of acquiring new IPv4 addresses should be about what it costs the next legacy holder or IPv6-adopting ISP to free up addresses. I'm still not convinced that there exists a better way to make additional supply of IPv4 addresses available. >> but I think supply will be more elastic than demand simply because >> there are so many netblocks out there already, > > (in the gray) Many of which are held by legacy holders, yes, but as I argue above, a transfer policy will give them a strong incentive to sign a legacy RSA so they can transfer the space without having to fake a corporate acquisition. >> so address conservation efforts will have more effect on freeing up >> supply to be transferred than on reducing the demands for new space. > > We are in 100% agreement here again. > The trick is to marshall price signals to induce this kind of behavior > sooner rather than later, and to keep the resulting address > recirculation process more effectively tied to needs-based delegation > principles. So long as the price/heat continues to go up evenly across > all resource users, the effects on migration out of v4 should be the > same. Given that, all that's really necessary is to keep everyone > approximately equally happy/unhappy but *together* through the full > (long) transition -- e.g., from gated v4/v6 coexistence to LISP or some > other, similarly durable/scalable future arrangement. Unfortunately, I think we have too many disparate types of IPv4 address holders (particularly legacy and non-legacy) to put everyone back in the same boat. Therefore, we're stuck with the next best thing, which is providing everyone the same incentive to free up addresses. -Scott From leo.vegoda at icann.org Sun Mar 9 04:21:21 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Sun, 9 Mar 2008 00:21:21 -0800 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47D1F16A.1050107@internap.com> Message-ID: On 08/03/2008 02:52, "Scott Leibrand" wrote: [...] > Why would anyone have to wait for address space? If they're willing to > pay the market price for it, there should always be space available. That's a very bold statement. Is it based on research? Leo From owen at delong.com Mon Mar 10 01:37:03 2008 From: owen at delong.com (Owen DeLong) Date: Sun, 9 Mar 2008 22:37:03 -0700 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> References: <292DCB81-EAD1-4774-8913-998B3F2E39E7@virtualized.org> Message-ID: On Mar 4, 2008, at 1:01 PM, David Conrad wrote: > Hi, > > On Mar 4, 2008, at 9:27 AM, Owen DeLong wrote: >> Leo Bicknell made the point that without this policy or something > >> like it, the world becomes set in stone after IPv4 runout. Haves >> have and have nots have not and there's no way for that to change. > > > To be blunt, this strikes me as astoundingly hallucinatory. > > Without some form of transfer policy, ARIN simply becomes irrelevant > as address consumers go to the "black" market in order to meet their > requirements. > > With a transfer policy, ARIN _may_ retain some relevance as a source > of "title" information, but a lot depends on the restrictions ARIN > attempts to impose. Make the policy too restrictive, and people > will go elsewhere. > > In the end, with or without a transfer policy, you're still out of > "free" IPv4 addresses and businesses will do what they feel is > necessary to get around unenforceable bureaucratic rules. > > Regards, > -drc I am not as convinced as you are that routing of black-market IP will be so readily available from service providers. Owen From leo.vegoda at icann.org Mon Mar 10 05:17:25 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 10 Mar 2008 02:17:25 -0700 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: <47D3FCF3.6040600@opus1.com> Message-ID: On 09/03/2008 16:06, "Joel Snyder" wrote: [...] >>> Why would anyone have to wait for address space? If they're willing to >>> pay the market price for it, there should always be space available. >> >> That's a very bold statement. Is it based on research? > > Yeah, about 200 years of economics research. It turns out to be true > for anything, ranging from "true love" to "oil" to "IP addresses." Are you suggesting that there will be a steady flow of prefixes of all sizes or making a comment on economic theory? Leo From bmanning at vacation.karoshi.com Mon Mar 10 05:34:18 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 10 Mar 2008 09:34:18 +0000 Subject: [ppml] NANOG IPv4 Exhaustion BoF In-Reply-To: References: <47D3FCF3.6040600@opus1.com> Message-ID: <20080310093418.GA25932@vacation.karoshi.com.> On Mon, Mar 10, 2008 at 02:17:25AM -0700, Leo Vegoda wrote: > On 09/03/2008 16:06, "Joel Snyder" wrote: > > [...] > > >>> Why would anyone have to wait for address space? If they're willing to > >>> pay the market price for it, there should always be space available. > >> > >> That's a very bold statement. Is it based on research? > > > > Yeah, about 200 years of economics research. It turns out to be true > > for anything, ranging from "true love" to "oil" to "IP addresses." > > Are you suggesting that there will be a steady flow of prefixes of all sizes > or making a comment on economic theory? it could be, leo, that for the right price, there might be a "steady flow" of prefixes. at least this is what i think Geoff and David have argued. --bill From sleibrand at internap.com Mon Mar 10 13:05:52 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 10 Mar 2008 10:05:52 -0700 Subject: [ppml] Prefix availability under 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: References: Message-ID: <47D56A70.7040903@internap.com> Leo Vegoda wrote: > On 09/03/2008 16:06, "Joel Snyder" wrote: > > [...] > >>>> Why would anyone have to wait for address space? If they're willing to >>>> pay the market price for it, there should always be space available. >>> That's a very bold statement. Is it based on research? >> Yeah, about 200 years of economics research. It turns out to be true >> for anything, ranging from "true love" to "oil" to "IP addresses." > > Are you suggesting that there will be a steady flow of prefixes of all sizes > or making a comment on economic theory? I took his comment as a general comment on economic theory. With regards to availability of different prefix sizes, that is definitely a concern, and was the reason for the addition of the section "8.3.6 Deaggregation when Permitted by ARIN" to version 1.1 of 2008-2: IPv4 Transfer Policy Proposal. Under that proposal, ARIN would allow deaggregation of larger blocks as needed to meet demand for smaller blocks. This should ensure that, if an organization is willing to pay the market price for it, there should be prefixes available of every size up to /8. If you think there is a better way to solve the problem than the current 8.3.6 text, I'd love to hear it. That text was proposed as a compromise, so it'd be great to get more input to see whether the community feels it strikes the right balance. -Scott From leo.vegoda at icann.org Mon Mar 10 16:16:24 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 10 Mar 2008 13:16:24 -0700 Subject: [ppml] Prefix availability under 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <47D56A70.7040903@internap.com> Message-ID: On 10/03/2008 18:05, "Scott Leibrand" wrote: [...] >>>>> Why would anyone have to wait for address space? If they're willing to >>>>> pay the market price for it, there should always be space available. >>>> That's a very bold statement. Is it based on research? >>> Yeah, about 200 years of economics research. It turns out to be true >>> for anything, ranging from "true love" to "oil" to "IP addresses." >> >> Are you suggesting that there will be a steady flow of prefixes of all sizes >> or making a comment on economic theory? > > I took his comment as a general comment on economic theory. I suppose everyone can interpret the phrase "steady flow" differently. Maybe I should have been more precise. I am not aware of any published research on what the churn rate is likely to be and would be grateful for pointers. Thanks, Leo From sleibrand at internap.com Mon Mar 10 18:28:08 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 10 Mar 2008 15:28:08 -0700 Subject: [ppml] Prefix availability under 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: References: Message-ID: <47D5B5F8.90609@internap.com> Leo Vegoda wrote: > On 10/03/2008 18:05, "Scott Leibrand" wrote: > > [...] > >>>>>> Why would anyone have to wait for address space? If they're willing to >>>>>> pay the market price for it, there should always be space available. >>>>> That's a very bold statement. Is it based on research? >>>> Yeah, about 200 years of economics research. It turns out to be true >>>> for anything, ranging from "true love" to "oil" to "IP addresses." >>> Are you suggesting that there will be a steady flow of prefixes of all sizes >>> or making a comment on economic theory? >> I took his comment as a general comment on economic theory. > > I suppose everyone can interpret the phrase "steady flow" differently. Maybe > I should have been more precise. I am not aware of any published research on > what the churn rate is likely to be and would be grateful for pointers. I don't think anyone has published research on IPv4 transfer markets. Ben is ARIN's expert on the subject, perhaps he can comment. My own amateur-economist take on it is that, initially, supply (of currently unrouted space) will exceed demand, so price will stay low, and the quantity demanded (your "churn rate") will be only slightly lower than it is today (with price ~= 0). Price will then start to rise as the easy supply is put into production, bringing new, more expensive supply online, and reducing demand. -Scott From michael.dillon at bt.com Tue Mar 11 11:27:42 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 11 Mar 2008 15:27:42 -0000 Subject: [ppml] Securities Act 15 U.S.C. 77b(a)(1) Message-ID: The Securities Act defines some terms in order to state what is and is not covered by the act. The definition of the term "security" is found in the section referred to in the subject. I used Cornell's online copy of the U.S. Code in order to read what I hope is the current definition. You can check that out here: or if you want to knock yourself out, you can find all of Title 15 here: It seems to me that the definition does not clearly exclude the trading of IP address contracts as some members of this list envision it. That means, that ARIN policy in this area could potentially create a new type of security or security derivative whose trading is regulated by the SEC. It would be interesting for ARIN to find a legal expert in the area of Title 15, particularly Chapter 2, who could explain what the definition means, and where there might be boundaries which ARIN policy must NOT cross if ARIN wishes to avoid regulatory scrutiny by the SEC. In addition, depending on how clear the case law is in this area, the legal expert could explain whether or not ARIN should ask the SEC for a ruling on the situation before proceeding with policies about IP address trading. The definition of "security" from Title 15 is as follows: (1) The term "security" means any note, stock, treasury stock, security future, bond, debenture, evidence of indebtedness, certificate of interest or participation in any profit-sharing agreement, collateral-trust certificate, preorganization certificate or subscription, transferable share, investment contract, voting-trust certificate, certificate of deposit for a security, fractional undivided interest in oil, gas, or other mineral rights, any put, call, straddle, option, or privilege on any security, certificate of deposit, or group or index of securities (including any interest therein or based on the value thereof), or any put, call, straddle, option, or privilege entered into on a national securities exchange relating to foreign currency, or, in general, any interest or instrument commonly known as a "security", or any certificate of interest or participation in, temporary or interim certificate for, receipt for, guarantee of, or warrant or right to subscribe to or purchase, any of the foregoing. --Michael Dillon P.S. In case you hadn't noticed, I am not a lawyer. From BillD at cait.wustl.edu Tue Mar 11 11:43:34 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 11 Mar 2008 10:43:34 -0500 Subject: [ppml] Securities Act 15 U.S.C. 77b(a)(1) In-Reply-To: References: Message-ID: > > The Securities Act defines some terms in order to state what > is and is not covered by the act. The definition of the term > "security" is found in the section referred to in the > subject. I used Cornell's online copy of the U.S. Code in > order to read what I hope is the current definition. > You can check that out here: > > or if you want to knock yourself out, you can find all of > Title 15 here: > > > It seems to me that the definition does not clearly exclude > the trading of IP address contracts as some members of this > list envision it. That means, that ARIN policy in this area > could potentially create a new type of security or security > derivative whose trading is regulated by the SEC. > > It would be interesting for ARIN to find a legal expert in > the area of Title 15, particularly Chapter 2, who could > explain what the definition means, and where there might be > boundaries which ARIN policy must NOT cross if ARIN wishes to > avoid regulatory scrutiny by the SEC. In addition, depending > on how clear the case law is in this area, the legal expert > could explain whether or not ARIN should ask the SEC for a > ruling on the situation before proceeding with policies about > IP address trading. > > The definition of "security" from Title 15 is as follows: > > (1) The term "security" means any note, stock, treasury > stock, security future, bond, debenture, evidence of > indebtedness, certificate of interest or participation in any > profit-sharing agreement, collateral-trust certificate, > preorganization certificate or subscription, transferable > share, investment contract, voting-trust certificate, > certificate of deposit for a security, fractional undivided > interest in oil, gas, or other mineral rights, any put, call, > straddle, option, or privilege on any security, certificate > of deposit, or group or index of securities (including any > interest therein or based on the value thereof), or any put, > call, straddle, option, or privilege entered into on a > national securities exchange relating to foreign currency, > or, in general, any interest or instrument commonly known as > a "security", or any certificate of interest or participation > in, temporary or interim certificate for, receipt for, > guarantee of, or warrant or right to subscribe to or > purchase, any of the foregoing. > > --Michael Dillon > > P.S. In case you hadn't noticed, I am not a lawyer. Then why are you playing one on TV...I mean ppml.... I am also not a lawyer, but see nothing in the definition that comes close to what I see being proposed in the transfer policy update proposal. And, ARIN Counsel, who is a lawyer has already weighed in on this in an informal way suggesting a similar opinion that the SEC is unlikely to take interest. Bill Darte > > _______________________________________________ > 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 Mar 11 11:44:18 2008 From: info at arin.net (Member Services) Date: Tue, 11 Mar 2008 11:44:18 -0400 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with RSA and efficient use - Revised Text Message-ID: <47D6A8D2.50405@arin.net> Policy Proposal 2007-21, PIv6 for legacy holders with RSA and efficient use, has been revised. After ARIN XX this proposal was remanded to the ARIN Advisory Council by the ARIN Board of Trustees. The AC asked the author to revise the text and present the propsal again. The proposal is open for discussion on this mailing list and is on the agenda at the upcoming Public Policy Meeting in Denver. The current policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_21.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2007-21 PIv6 for legacy holders with RSA and efficient use Author: Scott Leibrand Proposal Version: 2.0 Date: 11 March 2008 Proposal type: modify 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 all direct IPv4 assignments and allocations, each of which must be covered by a current ARIN RSA. Rationale: Current policy allows direct IPv6 allocations and assignments to nearly all organizations with IPv4 allocations or assignments from ARIN. As a result, such organizations can get IPv6 space just as easily as they can get IPv4 space, making it easy for them to transition to IPv6 as soon as they're ready to do so. However, there are some organizations who received IPv4 /23's and /24's prior to the formation of ARIN, and use that space in a multihomed, provider-independent fashion. Under current policy, such organizations cannot get IPv6 PI space without artificially inflating host counts, and are therefore discouraged from adopting IPv6. This policy proposal aims to remove this disincentive, and allow such organizations to easily adopt IPv6. In addition, pre-ARIN assignments were issued through an informal process, and many legacy resource holders have not yet entered into a formal agreement with ARIN, the manager of many such IP numbering resources. This policy proposal would require that such assignments be brought under a current ARIN Registration Services Agreement, thereby formalizing the relationship. Some pre-ARIN assignments may not be used efficiently. As unallocated IPv4 numbering resources are approaching exhaustion, it is important to ensure efficient utilization of IPv4 assignments, and to arrange for reclamation of unused space. Therefore, this policy would require that the organization wishing to receive IPv6 PI space demonstrate efficient utilization of their IPv4 assignment. (Efficient utilization is already defined elsewhere in policy, and the exact mechanism for achieving and determining efficient use is a matter of procedure, not of policy, so detailed procedures are not included in the policy statement above. The intent is that any organization with an assignment of /23 or larger which is less than 50% utilized would renumber and return whole unused CIDR blocks as necessary to bring the remaining CIDR block to 50% utilization or higher. A /24 should be considered efficiently utilized as long as it is in use for multihoming, as /25's and smaller are not routable for that purpose.) It has been suggested that this policy would be useful only until the growth of IPv6 exceeds the growth of IPv4. I would agree with this, and would further posit that the existing "qualify ... under the IPv4 policy currently in effect" language should also be modified at that time. I have therefore proposed this policy with a policy term of "permanent", with the expectation that this section of policy (6.5.8.1) will be rewritten at the appropriate time to entirely remove all IPv4 dependencies. Timetable for implementation: immediate From jrhett at svcolo.com Tue Mar 11 12:01:07 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Tue, 11 Mar 2008 09:01:07 -0700 Subject: [ppml] Securities Act 15 U.S.C. 77b(a)(1) In-Reply-To: References: Message-ID: <47D6ACC3.6090707@svcolo.com> To argue that an IP address meets that definition requires a stretch of imagination that even lawyers can't handle. Only network engineers are capable of that stretch. I forget the legal term offhand (and I'm not going to waste working day time looking it up) -- something like "intended use". It's a legal idea widely used by judges to toss out complaints/motions which basically says that the law must have been intended to cover the issue. That one cannot reread a law and try to make it cover something it clearly was never intended to cover. To say that IP addresses (location identifiers at best) are monetary securities is a stretch only a network engineer could imagine. michael.dillon at bt.com wrote: > The Securities Act defines some terms in order to state what is and is > not covered by the act. The definition of the term "security" is found > in the section referred to in the subject. I used Cornell's online copy > of the U.S. Code in order to read what I hope is the current definition. > You can check that out here: > > or if you want to knock yourself out, you can find all of Title 15 here: > > > It seems to me that the definition does not clearly exclude the trading > of IP address contracts as some members of this list envision it. That > means, that ARIN policy in this area could potentially create a new type > of security or security derivative whose trading is regulated by the > SEC. > > It would be interesting for ARIN to find a legal expert in the area of > Title 15, particularly Chapter 2, who could explain what the definition > means, and where there might be boundaries which ARIN policy must NOT > cross if ARIN wishes to avoid regulatory scrutiny by the SEC. In > addition, depending on how clear the case law is in this area, the legal > expert could explain whether or not ARIN should ask the SEC for a ruling > on the situation before proceeding with policies about IP address > trading. > > The definition of "security" from Title 15 is as follows: > > (1) The term "security" means any note, stock, treasury stock, security > future, bond, debenture, evidence of indebtedness, certificate of > interest or participation in any profit-sharing agreement, > collateral-trust certificate, preorganization certificate or > subscription, transferable share, investment contract, voting-trust > certificate, certificate of deposit for a security, fractional undivided > interest in oil, gas, or other mineral rights, any put, call, straddle, > option, or privilege on any security, certificate of deposit, or group > or index of securities (including any interest therein or based on the > value thereof), or any put, call, straddle, option, or privilege entered > into on a national securities exchange relating to foreign currency, or, > in general, any interest or instrument commonly known as a "security", > or any certificate of interest or participation in, temporary or interim > certificate for, receipt for, guarantee of, or warrant or right to > subscribe to or purchase, any of the foregoing. > > --Michael Dillon > > P.S. In case you hadn't noticed, I am not a lawyer. > > _______________________________________________ > 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 Mar 11 12:31:01 2008 From: info at arin.net (Member Services) Date: Tue, 11 Mar 2008 12:31:01 -0400 Subject: [ppml] ARIN XXI - Policy Proposals and Draft Agenda Message-ID: <47D6B3C5.7030601@arin.net> The following policy proposals have been under discussion on the ARIN Public Policy Mailing List and will be presented for consideration at the upcoming ARIN XXI Public Policy Meeting in Denver on 7-8 April 2008. 2008-3: Community Networks IPv6 Allocation 2008-2: IPv4 Transfer Policy Proposal 2008-1: SWIP support for smaller than /29 assignments 2007-27: Cooperative distribution of the end of the IPv4 free pool 2007-23: End Policy for IANA IPv4 allocations to RIRs 2007-21: PIv6 for legacy holders with RSA and efficient use 2007-17: Legacy Outreach and Partial Reclamation 2007-14: Resource Review Process The full text for each proposal can be found at: http://www.arin.net/policy/proposal_archive.html Agenda information has been updated. Find the draft agenda as well as hotel information at: http://www.arin.net/ARIN-XXI/ ARIN XXI attendees are eligible for a special room rate of $189 (USD), based on availability, if reservations are made before THIS Friday, 14 March. So make your hotel reservation and register for the meeting today! Regards, Member Services American Registry for Internet Numbers (ARIN) From michael.dillon at bt.com Tue Mar 11 12:34:52 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 11 Mar 2008 16:34:52 -0000 Subject: [ppml] Securities Act 15 U.S.C. 77b(a)(1) In-Reply-To: <47D6ACC3.6090707@svcolo.com> References: <47D6ACC3.6090707@svcolo.com> Message-ID: > To argue that an IP address meets that definition requires a > stretch of imagination that even lawyers can't handle. Only > network engineers are capable of that stretch. I didn't say that. We all know that IP addresses are not property and cannot be bought and sold. But now people are proposing that contracts, bearing the right to use certain IP addresses, can be bought and sold. That looks a lot like commodities contracts (which are promises of delivery) and some derivatives contracts and even things like re-insurance contracts. You and I are not experts in the law and really can't say one way or other, whether IP address contract trading would fall under the area regulated by the SEC. In fact, since the law in this area is quite complex, there probably are some situations that would clearly be covered, and some that would clearly not be covered. Before people write the policy that defines the situation, it would be nice to know what these boundaries are, before we cross them. And if the question is sufficiently fuzzy, then ARIN could ask the SEC for a ruling, before we take the action which has unintended consequences. Many of the people promoting IP address transfers have also spoken in favor of a scenario which sounds and awful lot like a securities exchange scenario. They hold this forth as a carrot to entice supporters. But can they actually deliver all the features of that carrot without attracting SEC regulatory oversight? I don't know and I don't think that anyone in ARIN, (BoT, staff, AC, members, hangers-on) really has the specialist knowledge to make that determination. --Michael Dillon From jrhett at svcolo.com Tue Mar 11 12:56:32 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Tue, 11 Mar 2008 09:56:32 -0700 Subject: [ppml] Securities Act 15 U.S.C. 77b(a)(1) In-Reply-To: References: <47D6ACC3.6090707@svcolo.com> Message-ID: <47D6B9C0.1050305@svcolo.com> michael.dillon at bt.com wrote: >> To argue that an IP address meets that definition requires a >> stretch of imagination that even lawyers can't handle. Only >> network engineers are capable of that stretch. > > I didn't say that. We all know that IP addresses are not property and > cannot be bought and sold. But now people are proposing that contracts, > bearing the right to use certain IP addresses, can be bought and sold. > That looks a lot like commodities contracts (which are promises of > delivery) and some derivatives contracts and even things like > re-insurance contracts. Question: does my rental property fall under SEC regulation? No. And I sell contracts to use that property. Go back to your act and read it again. It clearly says a lot of words, but the only direct nouns in play are clearly those representing interest in monetary items *or* mineral rights. Interest in commodities other than mineral rights are not included. And please stop playing lawyer. From jcurran at istaff.org Tue Mar 11 13:01:43 2008 From: jcurran at istaff.org (John Curran) Date: Tue, 11 Mar 2008 13:01:43 -0400 Subject: [ppml] Securities Act 15 U.S.C. 77b(a)(1) In-Reply-To: References: <47D6ACC3.6090707@svcolo.com> Message-ID: At 4:34 PM +0000 3/11/08, wrote: >Many of the people promoting IP address transfers have also spoken in >favor of a scenario which sounds and awful lot like a securities >exchange scenario. They hold this forth as a carrot to entice >supporters. But can they actually deliver all the features of that >carrot without attracting SEC regulatory oversight? I don't know and I >don't think that anyone in ARIN, (BoT, staff, AC, members, hangers-on) >really has the specialist knowledge to make that determination. Michael - It's possible that you didn't see my response below: We have had ARIN Counsel look into this possibility per your request, and it does not appear to be an issue. If a specific policy proposal comes before the Board, we will seek an in-depth legal review at that time. /John Chair, ARIN Board of Trustees === >To: >From: John Curran >Subject: Re: [ppml] NANOG IPv4 Exhaustion BoF >Cc: >Bcc: >X-Attachments: > >At 8:46 PM +0000 3/4/08, wrote: >> >>So far, from the discussion that I have seen, it does not appear that >>anyone seriously considered the possibility that the IP address >>market proposals are getting rather close to the territory that the >>SEC regulates. That's why I'm raising the issue here, in hopes that >>some of the people on this list will discuss it with the BoT, >>and with some sort of legal advisor who has expertise in the right >>area of law. It could be the current counsel or some other lawyer. >>That is up to the BoT. > >It has been raised as an issue and discussed. At first review by our >counsel, there does not appear to be an issue here. > >The Board will ask for a more formal opinion of the legal ramifications >(as we always do) if/when a recommendation for new policy comes >before it. > >/John >Chair, ARIN Board of Trustees From arin-contact at dirtside.com Tue Mar 11 13:05:10 2008 From: arin-contact at dirtside.com (William Herrin) Date: Tue, 11 Mar 2008 13:05:10 -0400 Subject: [ppml] Securities Act 15 U.S.C. 77b(a)(1) In-Reply-To: <47D6ACC3.6090707@svcolo.com> References: <47D6ACC3.6090707@svcolo.com> Message-ID: <3c3e3fca0803111005x441027ccn679f5bb196d14fb2@mail.gmail.com> On Tue, Mar 11, 2008 at 12:01 PM, Jo Rhett wrote: > To argue that an IP address meets that definition requires a stretch of > imagination that even lawyers can't handle. Only network engineers are > capable of that stretch. Jo, Meaning no disrespect, but if that were true we wouldn't need to remind folks at every turn that "IP addresses aren't property." The fact is, they look like property and they're used like property. You say that they're just "location identifiers" but what is a land deed if not a location identifier? So far the courts have sided with the position that IP address are not property but this position is based in no little part on the fact that that the policy structure makes it impossible to buy or sell IP addresses in any formal sense. It can't be property unless you can buy and sell it. Change the rules on sales and the precedent may not hold. > I forget the legal term offhand (and I'm not going to waste working day > time looking it up) -- something like "intended use". It's a legal idea > widely used by judges to toss out complaints/motions which basically > says that the law must have been intended to cover the issue. That's not quite the way it works in the US, though strict constructionists often argue that it should be. There's another interesting function of US common law whose legal term I don't recall, but it goes something like this: if it looks like a duck and it quacks like a duck, its a duck. I don't think address assignments in the proposed transfer policy look like securities, but they look close enough that Michael's concern is not unreasonable. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From owen at delong.com Tue Mar 11 13:13:57 2008 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Mar 2008 10:13:57 -0700 Subject: [ppml] Securities Act 15 U.S.C. 77b(a)(1) In-Reply-To: <47D6B9C0.1050305@svcolo.com> References: <47D6ACC3.6090707@svcolo.com> <47D6B9C0.1050305@svcolo.com> Message-ID: <07526C86-A620-4633-A0C6-77313EAD018A@delong.com> On Mar 11, 2008, at 9:56 AM, Jo Rhett wrote: > michael.dillon at bt.com wrote: >>> To argue that an IP address meets that definition requires a >>> stretch of imagination that even lawyers can't handle. Only >>> network engineers are capable of that stretch. >> >> I didn't say that. We all know that IP addresses are not property and >> cannot be bought and sold. But now people are proposing that >> contracts, >> bearing the right to use certain IP addresses, can be bought and >> sold. >> That looks a lot like commodities contracts (which are promises of >> delivery) and some derivatives contracts and even things like >> re-insurance contracts. > > Question: does my rental property fall under SEC regulation? No. > And > I sell contracts to use that property. > > Go back to your act and read it again. It clearly says a lot of > words, > but the only direct nouns in play are clearly those representing > interest in monetary items *or* mineral rights. Interest in > commodities > other than mineral rights are not included. > > And please stop playing lawyer. > Actually, I believe what is under discussion is not contracts conveying the right to use the addresses, but, rather contracts which convey the right to have your name attached to the recorded registration of those addresses in a particular registry. The fact that ISPs generally tend to respect that registry above others in that region and that said registry is part of a cooperative of 5 registries that have each agreed to operate in non-overlapping geographic regions is somewhat coincidental to the contracts being discussed. It is my opinion that the securities discussion is a rathole. We have already heard from at least one person much more qualified than anyone else participating in the discussion so far that it is unlikely the SEC would view this as a securities transaction. Owen From stephen at sprunk.org Tue Mar 11 13:06:37 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 11 Mar 2008 12:06:37 -0500 Subject: [ppml] Securities Act 15 U.S.C. 77b(a)(1) References: <47D6ACC3.6090707@svcolo.com> Message-ID: <013d01c8839b$b6846a80$5e3816ac@atlanta.polycom.com> Thus spake >> To argue that an IP address meets that definition requires a >> stretch of imagination that even lawyers can't handle. Only >> network engineers are capable of that stretch. > > I didn't say that. We all know that IP addresses are not property and > cannot be bought and sold. But now people are proposing that > contracts, bearing the right to use certain IP addresses, can be > bought and sold. Perhaps I missed a message, but I haven't seen that proposed. What I've seen proposed so far is that people would be able to qualify for addresses for their own use with ARIN and pay a third party to provide those addresses. That is _not_ trading contracts to use addresses, and it's not even remotely similar. > In fact, since the law in this area is quite complex, there probably > are some situations that would clearly be covered, and some that > would clearly not be covered. Before people write the policy that > defines the situation, it would be nice to know what these > boundaries are, before we cross them. And if the question is > sufficiently fuzzy, then ARIN could ask the SEC for a ruling, before > we take the action which has unintended consequences. That is not how we've been told the process works. We have been explicitly told to make proposals based on what we think is best for the community and, if there are legal ramifications, those will be presented to the BoT for their consideration before a proposal is adopted. I would fully expect that if counsel determined that a proposal (which had passed the consensus process) would incur SEC regulation, the BoT would remand it back to the community for modification or use the ACSP to determine if we really want to go down that path. We should not play armchair lawyer here. We have real lawyers that will look at the results of the process and let us know if there are problems or unintended consequences. In fact, comments by counsel are part of the "staff assessment" that comes out before the meeting, and we'll see what, if any, concerns are there at that time. > I don't know and I don't think that anyone in ARIN, (BoT, staff, AC, > members, hangers-on) really has the specialist knowledge to make > that determination. ARIN pays lawyers for that specialist knowledge. I'm confident that our general counsel is quite capable of bringing in whatever outside resources are needed to get definitive answers if he doesn't have them himself, and in fact is obligated to do so or be guilty of malpractice. Michael, you need to accept that you're not a lawyer and let the experts do their job. It's nice that you're concerned, but you've already been told repeatedly that counsel is already aware of your concern. Drop it until we're told there's an actual problem, so that we can get back to arguing about the actual goals of the proposal and whether we want a market in the first place. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From owen at delong.com Tue Mar 11 13:21:21 2008 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Mar 2008 10:21:21 -0700 Subject: [ppml] Securities Act 15 U.S.C. 77b(a)(1) In-Reply-To: <3c3e3fca0803111005x441027ccn679f5bb196d14fb2@mail.gmail.com> References: <47D6ACC3.6090707@svcolo.com> <3c3e3fca0803111005x441027ccn679f5bb196d14fb2@mail.gmail.com> Message-ID: <66C3F902-CA33-48CE-9586-EA6DD7CD5370@delong.com> On Mar 11, 2008, at 10:05 AM, William Herrin wrote: > On Tue, Mar 11, 2008 at 12:01 PM, Jo Rhett wrote: >> To argue that an IP address meets that definition requires a >> stretch of >> imagination that even lawyers can't handle. Only network engineers >> are >> capable of that stretch. > > Jo, > > Meaning no disrespect, but if that were true we wouldn't need to > remind folks at every turn that "IP addresses aren't property." The > fact is, they look like property and they're used like property. You > say that they're just "location identifiers" but what is a land deed > if not a location identifier? > An address (for example, 2594 Rebecca Dr., El Sobrante, CA 94806) is a location identifier. A land deed is title in some piece of physical real estate. Addresses are a commonly used location identifier referenced in deeds, but, not all deeds use addresses. Indeed, some use very precise survey coordinates to describe the boundaries of the property rather than an address. IP addresses are like lattitude and longitude. Nobody owns any particular lattitude or longitude, but, no two objects of matter can occupy exactly the same lat/long/alt combination at the exact same time. > So far the courts have sided with the position that IP address are not > property but this position is based in no little part on the fact that > that the policy structure makes it impossible to buy or sell IP > addresses in any formal sense. It can't be property unless you can buy > and sell it. Change the rules on sales and the precedent may not hold. > That is an interesting question. However, our intent here is expressly not to permit the buying and selling of IP addresses, but, the trading in the registration of IP addresses. Definitely, this will be reviewed by counsel before being implemented as policy. I believe it has already been reviewed at least in part. > >> I forget the legal term offhand (and I'm not going to waste working >> day >> time looking it up) -- something like "intended use". It's a legal >> idea >> widely used by judges to toss out complaints/motions which basically >> says that the law must have been intended to cover the issue. > > That's not quite the way it works in the US, though strict > constructionists often argue that it should be. There's another > interesting function of US common law whose legal term I don't recall, > but it goes something like this: if it looks like a duck and it quacks > like a duck, its a duck. And therefore because it floats, it is made of wood and is, therefore, a witch. Burn her. Owen (With apologies to Python, M.) From jrhett at svcolo.com Tue Mar 11 13:24:02 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Tue, 11 Mar 2008 10:24:02 -0700 Subject: [ppml] Securities Act 15 U.S.C. 77b(a)(1) In-Reply-To: <3c3e3fca0803111005x441027ccn679f5bb196d14fb2@mail.gmail.com> References: <47D6ACC3.6090707@svcolo.com> <3c3e3fca0803111005x441027ccn679f5bb196d14fb2@mail.gmail.com> Message-ID: <47D6C032.8090307@svcolo.com> William Herrin wrote: > Meaning no disrespect, but if that were true we wouldn't need to > remind folks at every turn that "IP addresses aren't property." The > fact is, they look like property and they're used like property. You > say that they're just "location identifiers" but what is a land deed > if not a location identifier? *sigh* Do you consider yourself a trained professional? That what you know took years of learning and experience? Then why insist that you can do a lawyer's job with no such experience? Go ask a lawyer what a deed is, and how a deed describes the property. Now try to describe an IP address in the same sense. (this answer was provided by a lawyer beside me, laughing) From arin-contact at dirtside.com Tue Mar 11 13:35:43 2008 From: arin-contact at dirtside.com (William Herrin) Date: Tue, 11 Mar 2008 13:35:43 -0400 Subject: [ppml] Securities Act 15 U.S.C. 77b(a)(1) In-Reply-To: <47D6C032.8090307@svcolo.com> References: <47D6ACC3.6090707@svcolo.com> <3c3e3fca0803111005x441027ccn679f5bb196d14fb2@mail.gmail.com> <47D6C032.8090307@svcolo.com> Message-ID: <3c3e3fca0803111035v1af7d810ob9b75f3c60cae34a@mail.gmail.com> On Tue, Mar 11, 2008 at 1:24 PM, Jo Rhett wrote: > *sigh* Do you consider yourself a trained professional? That what you > know took years of learning and experience? Then why insist that you can > do a lawyer's job with no such experience? Jo, Seems to me the only one insisting whether I can or can't do a lawyer's job is you. All I did was say I thought Michael's question was interesting and why I thought it was interesting. In your esteemed and educated view, is it permissible for a mere layman to inquire into the law? Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From awahid at cwgo.com Tue Mar 11 13:39:21 2008 From: awahid at cwgo.com (Aamir Wahid) Date: Tue, 11 Mar 2008 13:39:21 -0400 Subject: [ppml] PPML Digest, Vol 33, Issue 25 Message-ID: <946564330@mail.cwgo.com> From jrhett at svcolo.com Tue Mar 11 13:44:48 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Tue, 11 Mar 2008 10:44:48 -0700 Subject: [ppml] Securities Act 15 U.S.C. 77b(a)(1) In-Reply-To: <3c3e3fca0803111035v1af7d810ob9b75f3c60cae34a@mail.gmail.com> References: <47D6ACC3.6090707@svcolo.com> <3c3e3fca0803111005x441027ccn679f5bb196d14fb2@mail.gmail.com> <47D6C032.8090307@svcolo.com> <3c3e3fca0803111035v1af7d810ob9b75f3c60cae34a@mail.gmail.com> Message-ID: <47D6C510.3050508@svcolo.com> William Herrin wrote: > Seems to me the only one insisting whether I can or can't do a > lawyer's job is you. All I did was say I thought Michael's question > was interesting and why I thought it was interesting. In your esteemed > and educated view, is it permissible for a mere layman to inquire into > the law? It seems to me that the ARIN lists -- which I "should" read because they directly relate to my job, become unreadable/unusable if you actually work at said job, and that is entirely due to people making all sorts of unsubstantiated claims about things they know very little about. If people were to stop * making legal claims when they aren't lawyers * making claims about router/switch consumption when they work at an outfit too small (or too large) to know much about real life limitations of the big (or small) iron in question * making claims about burden to large/small entities when they work in the opposite (or neither) ...etc If we could all stick to discussing things we know something about, this list would be a lot more useful. (and 99% quieter) From sleibrand at internap.com Tue Mar 11 13:53:48 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 11 Mar 2008 10:53:48 -0700 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 Transfer Policy Proposal Message-ID: <47D6C72C.2070604@internap.com> First of all, thanks to everyone for their feedback and discussion of the 2008-2 policy proposal. One item that I still think needs further discussion is the question of whether and how to restrict transferor deaggregation in an IPv4 Transfer Policy. The question is, should we place restrictions on both the transferee and transferor to limit deaggregation, or would a more limited set of restrictions be sufficient? Some background (or skip down to the bottom if you want): In 8.3.2 Conditions on the transferee, there are two bullet points permitting and requiring transferees to get a larger block than they might otherwise, to help prevent deaggregation: ? The transferee may request and receive a contiguous CIDR block large enough to provide a 12 month supply of IPv4 addresses. ? The transferee may only receive one IPv4 address transfer through this Simple Transfer process every 6 months. In 8.3.3 Conditions on the IPv4 address block to be transferred, a transferor is permitted to split their block into two pieces, keeping one and transferring the other. This could be an even split into two CIDR blocks, or at the other extreme it could mean splitting a /8, keeping a /22, and transferring the remaining /9, /10, /11, /12, /13, /14, /15, /16, /17, /18, /19, /21, and /22. However, it also means that a holder of a large IPv4 address block cannot simply transfer it off as 16,384 /22's. In 8.3.6 Deaggregation when Permitted by ARIN, further deaggregation beyond 8.3.3 is allowed, at ARIN's discretion, in order to deal with any shortage of smaller blocks resulting from the restrictions above. The conditions in 8.3.3 and 8.3.6 above represent a compromise between two views. On the one hand, there is the view that the transferee conditions in 8.3.2 are sufficient to recreate an environment very similar to the one we have today, in that recipients must justify their need for addresses, and then they receive a block large enough to meet their needs for a certain number of months. Today that block comes out of a /8 allocated from IANA to ARIN, so each such allocation generates at least one additional route in the routing table. There is little reason to believe that the number of prefixes demanded will change significantly, so there would be no incentive for transferors to deaggregate more than we do today, and therefore in this view the 8.3.2 conditions are adequate, and the last bullet of 8.3.3 and section 8.3.6 are unnecessary. The other view is that, without conditions restricting them from doing so, transferors of large netblocks will deaggregate their holdings to a large degree and transfer off the resulting pieces, resulting in a shortage of larger blocks. Under this view, the transfer policy should restrict the degree to which deaggregation is permitted, thereby encouraging transfer of larger blocks instead of smaller ones. In version 1.0 of the proposal, section 8.3.6 Deaggregation when Permitted by ARIN did not exist. Without it, a convincing argument was made that supply of small netblocks would be restricted, thereby driving up the price of small netblocks and driving down the price of large ones. To address this, we added section 8.3.6 in version 1.1. So, a few questions to discuss: Do you think that the IPv4 Transfer Policy should restrict deaggregation of transferred netblocks? Why or why not? If so, what restrictions should be placed on deaggregation, and what types of deaggregation should be allowed to provide supply of smaller netblocks? Should any restrictions on deaggregation be written into the policy, or should ARIN staff be given discretion to adjust the restrictions as needed to best serve the interests of the community (section 8.3.6)? Thanks, Scott From BillD at cait.wustl.edu Tue Mar 11 14:05:15 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 11 Mar 2008 13:05:15 -0500 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <47D6C72C.2070604@internap.com> References: <47D6C72C.2070604@internap.com> Message-ID: And while you are answering these questions, or just browsing, please state plainly whether you are 'in favor' of this policy proposal, or 'opposed'. This will help the AC determine the extent to which consensus exists...and we thank you for that as well! Bill Darte > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Scott Leibrand > Sent: Tuesday, March 11, 2008 12:54 PM > To: arin ppml > Subject: [ppml] Restrictions on transferor deaggregation in > 2008-2: IPv4 Transfer Policy Proposal > > First of all, thanks to everyone for their feedback and > discussion of the 2008-2 policy proposal. > > One item that I still think needs further discussion is the > question of whether and how to restrict transferor > deaggregation in an IPv4 Transfer Policy. The question is, > should we place restrictions on both the transferee and > transferor to limit deaggregation, or would a more limited > set of restrictions be sufficient? > > Some background (or skip down to the bottom if you want): > > In 8.3.2 Conditions on the transferee, there are two bullet > points permitting and requiring transferees to get a larger > block than they might otherwise, to help prevent deaggregation: > * The transferee may request and receive a contiguous > CIDR block large > enough to provide a 12 month supply of IPv4 addresses. > * The transferee may only receive one IPv4 address > transfer through this > Simple Transfer process every 6 months. > > In 8.3.3 Conditions on the IPv4 address block to be > transferred, a transferor is permitted to split their block > into two pieces, keeping one and transferring the other. > This could be an even split into two CIDR blocks, or at the > other extreme it could mean splitting a /8, keeping a /22, > and transferring the remaining /9, /10, /11, /12, /13, /14, > /15, /16, /17, /18, /19, /21, and /22. However, it also > means that a holder of a large IPv4 address block cannot > simply transfer it off as > 16,384 /22's. > > In 8.3.6 Deaggregation when Permitted by ARIN, further > deaggregation beyond 8.3.3 is allowed, at ARIN's discretion, > in order to deal with any shortage of smaller blocks > resulting from the restrictions above. > > The conditions in 8.3.3 and 8.3.6 above represent a > compromise between two views. On the one hand, there is the > view that the transferee conditions in 8.3.2 are sufficient > to recreate an environment very similar to the one we have > today, in that recipients must justify their need for > addresses, and then they receive a block large enough to meet > their needs for a certain number of months. Today that block > comes out of a /8 allocated from IANA to ARIN, so each such > allocation generates at least one additional route in the > routing table. There is little reason to believe that the > number of prefixes demanded will change significantly, so > there would be no incentive for transferors to deaggregate > more than we do today, and therefore in this view the 8.3.2 > conditions are adequate, and the last bullet of 8.3.3 and > section 8.3.6 are unnecessary. > > The other view is that, without conditions restricting them > from doing so, transferors of large netblocks will > deaggregate their holdings to a large degree and transfer off > the resulting pieces, resulting in a shortage of larger > blocks. Under this view, the transfer policy should restrict > the degree to which deaggregation is permitted, thereby > encouraging transfer of larger blocks instead of smaller ones. > > In version 1.0 of the proposal, section 8.3.6 Deaggregation > when Permitted by ARIN did not exist. Without it, a > convincing argument was made that supply of small netblocks > would be restricted, thereby driving up the price of small > netblocks and driving down the price of large ones. To > address this, we added section 8.3.6 in version 1.1. > > > > So, a few questions to discuss: > > Do you think that the IPv4 Transfer Policy should restrict > deaggregation of transferred netblocks? Why or why not? > > If so, what restrictions should be placed on deaggregation, > and what types of deaggregation should be allowed to provide > supply of smaller netblocks? > > Should any restrictions on deaggregation be written into the > policy, or should ARIN staff be given discretion to adjust > the restrictions as needed to best serve the interests of the > community (section 8.3.6)? > > Thanks, > 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. > From owen at delong.com Tue Mar 11 14:14:30 2008 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Mar 2008 11:14:30 -0700 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <47D6C72C.2070604@internap.com> References: <47D6C72C.2070604@internap.com> Message-ID: <1297F495-7F0E-49E3-9FFA-F9A3487C659C@delong.com> > So, a few questions to discuss: > > Do you think that the IPv4 Transfer Policy should restrict > deaggregation > of transferred netblocks? Why or why not? > Yes. While in the longer term, loosening or removing such restrictions may prove to be a desirable thing to do, I believe we should see how things work with the restrictions initially and gain some experience with the policy before completely turning things loose. We can always deaggregate later, whereas re-aggregation is virtually impossible. > If so, what restrictions should be placed on deaggregation, and what > types of deaggregation should be allowed to provide supply of smaller > netblocks? > Personally, I think the original restrictions were a good starting point. I think that the compromise offered in the current 8.3.6 is an acceptable compromise, but, I do not feel we should go any further at this time. > Should any restrictions on deaggregation be written into the policy, > or > should ARIN staff be given discretion to adjust the restrictions as > needed to best serve the interests of the community (section 8.3.6)? > I prefer policy-based restrictions with the knowledge that policy can be adjusted later if necessary. However, I do think that the more dynamic ability of ARIN staff to respond to need and permit any needed deaggregation in the best interests of the community is a reasonable compromise which would pose acceptable risk. All of this is, of course, assuming that a transfer policy is a good idea at all. Frankly, the more we look at the various problems and attempts to tweak this policy to balance the various risks, the more convinced I become that it's just a bad idea and we should let IPv4 run its course and move on to IPv6 without creating policies to allow previously unanticipated address transfers. Indeed, people holding excess address space are always welcome to return said address space to ARIN under current policy, and, by many interpretations are actually required to do so. Owen From jweyand at computerdata.com Tue Mar 11 14:23:35 2008 From: jweyand at computerdata.com (Jim Weyand) Date: Tue, 11 Mar 2008 14:23:35 -0400 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 Transfer Policy Proposal Message-ID: <1582DCBFF968F044A9A910C0AB177C902CE64B@cliff.cdi.local> Scott- Is there any quantitative data on the effect of deaggregation? The proposal relies on ARIN staff to make decisions regarding deaggregation. What skills and experience will be required of staff members to make reasonable decisions? -Jim Weyand > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Scott Leibrand > Sent: Tuesday, March 11, 2008 12:54 PM > To: arin ppml > Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 > Transfer Policy Proposal > > First of all, thanks to everyone for their feedback and discussion of > the 2008-2 policy proposal. > > One item that I still think needs further discussion is the question of > whether and how to restrict transferor deaggregation in an IPv4 Transfer > Policy. The question is, should we place restrictions on both the > transferee and transferor to limit deaggregation, or would a more > limited set of restrictions be sufficient? > > Some background (or skip down to the bottom if you want): > > In 8.3.2 Conditions on the transferee, there are two bullet points > permitting and requiring transferees to get a larger block than they > might otherwise, to help prevent deaggregation: > * The transferee may request and receive a contiguous CIDR block large > enough to provide a 12 month supply of IPv4 addresses. > * The transferee may only receive one IPv4 address transfer through > this > Simple Transfer process every 6 months. > > In 8.3.3 Conditions on the IPv4 address block to be transferred, a > transferor is permitted to split their block into two pieces, keeping > one and transferring the other. This could be an even split into two > CIDR blocks, or at the other extreme it could mean splitting a /8, > keeping a /22, and transferring the remaining /9, /10, /11, /12, /13, > /14, /15, /16, /17, /18, /19, /21, and /22. However, it also means that > a holder of a large IPv4 address block cannot simply transfer it off as > 16,384 /22's. > > In 8.3.6 Deaggregation when Permitted by ARIN, further deaggregation > beyond 8.3.3 is allowed, at ARIN's discretion, in order to deal with any > shortage of smaller blocks resulting from the restrictions above. > > The conditions in 8.3.3 and 8.3.6 above represent a compromise between > two views. On the one hand, there is the view that the transferee > conditions in 8.3.2 are sufficient to recreate an environment very > similar to the one we have today, in that recipients must justify their > need for addresses, and then they receive a block large enough to meet > their needs for a certain number of months. Today that block comes out > of a /8 allocated from IANA to ARIN, so each such allocation generates > at least one additional route in the routing table. There is little > reason to believe that the number of prefixes demanded will change > significantly, so there would be no incentive for transferors to > deaggregate more than we do today, and therefore in this view the 8.3.2 > conditions are adequate, and the last bullet of 8.3.3 and section 8.3.6 > are unnecessary. > > The other view is that, without conditions restricting them from doing > so, transferors of large netblocks will deaggregate their holdings to a > large degree and transfer off the resulting pieces, resulting in a > shortage of larger blocks. Under this view, the transfer policy should > restrict the degree to which deaggregation is permitted, thereby > encouraging transfer of larger blocks instead of smaller ones. > > In version 1.0 of the proposal, section 8.3.6 Deaggregation when > Permitted by ARIN did not exist. Without it, a convincing argument was > made that supply of small netblocks would be restricted, thereby driving > up the price of small netblocks and driving down the price of large > ones. To address this, we added section 8.3.6 in version 1.1. > > > > So, a few questions to discuss: > > Do you think that the IPv4 Transfer Policy should restrict deaggregation > of transferred netblocks? Why or why not? > > If so, what restrictions should be placed on deaggregation, and what > types of deaggregation should be allowed to provide supply of smaller > netblocks? > > Should any restrictions on deaggregation be written into the policy, or > should ARIN staff be given discretion to adjust the restrictions as > needed to best serve the interests of the community (section 8.3.6)? > > Thanks, > 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. From sleibrand at internap.com Tue Mar 11 14:34:09 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 11 Mar 2008 11:34:09 -0700 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <1582DCBFF968F044A9A910C0AB177C902CE64B@cliff.cdi.local> References: <1582DCBFF968F044A9A910C0AB177C902CE64B@cliff.cdi.local> Message-ID: <47D6D0A1.6010202@internap.com> Yes, there have been some numbers produced by ARIN staff (http://www.arin.net/statistics/index.html), which the AC has been using (along with some data from whois) to judge the likely demand and supply of larger and smaller blocks. In addition, I would anticipate that ARIN staff will also be able to use the prices on the listing service to decide whether/when to adjust deaggregation thresholds. If the per-IP price for smaller blocks gets to be higher than that for larger blocks, for example, that may mean that more deaggregation needs to be permitted. Fortunately, ARIN not only has a very smart staff, but also has the engaged the services of an economics expert with experience in a wide range of Internet issues (Ben), so I have confidence that they will be well prepared to make the decisions required to ensure smooth functioning of the market. -Scott Jim Weyand wrote: > Scott- > Is there any quantitative data on the effect of deaggregation? > > The proposal relies on ARIN staff to make decisions regarding > deaggregation. What skills and experience will be required of staff > members to make reasonable decisions? > > -Jim Weyand > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf > Of >> Scott Leibrand >> Sent: Tuesday, March 11, 2008 12:54 PM >> To: arin ppml >> Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: > IPv4 >> Transfer Policy Proposal >> >> First of all, thanks to everyone for their feedback and discussion of >> the 2008-2 policy proposal. >> >> One item that I still think needs further discussion is the question > of >> whether and how to restrict transferor deaggregation in an IPv4 > Transfer >> Policy. The question is, should we place restrictions on both the >> transferee and transferor to limit deaggregation, or would a more >> limited set of restrictions be sufficient? >> >> Some background (or skip down to the bottom if you want): >> >> In 8.3.2 Conditions on the transferee, there are two bullet points >> permitting and requiring transferees to get a larger block than they >> might otherwise, to help prevent deaggregation: >> * The transferee may request and receive a contiguous CIDR block > large >> enough to provide a 12 month supply of IPv4 addresses. >> * The transferee may only receive one IPv4 address transfer > through >> this >> Simple Transfer process every 6 months. >> >> In 8.3.3 Conditions on the IPv4 address block to be transferred, a >> transferor is permitted to split their block into two pieces, keeping >> one and transferring the other. This could be an even split into two >> CIDR blocks, or at the other extreme it could mean splitting a /8, >> keeping a /22, and transferring the remaining /9, /10, /11, /12, /13, >> /14, /15, /16, /17, /18, /19, /21, and /22. However, it also means > that >> a holder of a large IPv4 address block cannot simply transfer it off > as >> 16,384 /22's. >> >> In 8.3.6 Deaggregation when Permitted by ARIN, further deaggregation >> beyond 8.3.3 is allowed, at ARIN's discretion, in order to deal with > any >> shortage of smaller blocks resulting from the restrictions above. >> >> The conditions in 8.3.3 and 8.3.6 above represent a compromise between >> two views. On the one hand, there is the view that the transferee >> conditions in 8.3.2 are sufficient to recreate an environment very >> similar to the one we have today, in that recipients must justify > their >> need for addresses, and then they receive a block large enough to meet >> their needs for a certain number of months. Today that block comes > out >> of a /8 allocated from IANA to ARIN, so each such allocation generates >> at least one additional route in the routing table. There is little >> reason to believe that the number of prefixes demanded will change >> significantly, so there would be no incentive for transferors to >> deaggregate more than we do today, and therefore in this view the > 8.3.2 >> conditions are adequate, and the last bullet of 8.3.3 and section > 8.3.6 >> are unnecessary. >> >> The other view is that, without conditions restricting them from doing >> so, transferors of large netblocks will deaggregate their holdings to > a >> large degree and transfer off the resulting pieces, resulting in a >> shortage of larger blocks. Under this view, the transfer policy > should >> restrict the degree to which deaggregation is permitted, thereby >> encouraging transfer of larger blocks instead of smaller ones. >> >> In version 1.0 of the proposal, section 8.3.6 Deaggregation when >> Permitted by ARIN did not exist. Without it, a convincing argument > was >> made that supply of small netblocks would be restricted, thereby > driving >> up the price of small netblocks and driving down the price of large >> ones. To address this, we added section 8.3.6 in version 1.1. >> >> >> >> So, a few questions to discuss: >> >> Do you think that the IPv4 Transfer Policy should restrict > deaggregation >> of transferred netblocks? Why or why not? >> >> If so, what restrictions should be placed on deaggregation, and what >> types of deaggregation should be allowed to provide supply of smaller >> netblocks? >> >> Should any restrictions on deaggregation be written into the policy, > or >> should ARIN staff be given discretion to adjust the restrictions as >> needed to best serve the interests of the community (section 8.3.6)? >> >> Thanks, >> 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 tedm at ipinc.net Tue Mar 11 14:38:18 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 11 Mar 2008 11:38:18 -0700 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <47D6C72C.2070604@internap.com> Message-ID: <000601c883a7$131305d0$6fce4b41@tedsdesk> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Scott Leibrand > Sent: Tuesday, March 11, 2008 10:54 AM > To: arin ppml > Subject: [ppml] Restrictions on transferor deaggregation in > 2008-2: IPv4 Transfer Policy Proposal > > > First of all, thanks to everyone for their feedback and discussion of > the 2008-2 policy proposal. > > One item that I still think needs further discussion is the > question of > whether and how to restrict transferor deaggregation in an > IPv4 Transfer > Policy. The question is, should we place restrictions on both the > transferee and transferor to limit deaggregation, No. However, the deaggregation should be performed by the "seller" not by the "buyer" It should also not be any longer than a /20 If a "transferor" AKA "seller" has a block longer than a /20 they should be prohibited from participating in this policy at all - they should return it to ARIN if they are going to give it up. If they have a /20 they should not be allowed to deaggregate it. If they have a /19 or shorter, they should complete the deaggregation PRIOR to transfer. You see, it may happen that a "transferor" may have a large block, like a /8 for example, that they have a "buyer" for only part of this - and their choice is either they deaggregate the large block and sell part of it now for cash now, or they hold off, expecting that later on someone who needs the complete undeaggregated block will come along and want to buy it. The liklihood is that over time the demand will be for smaller blocks. The reason being is that the cost of large blocks will be so high that the networks that can afford to buy them (and can provide justification for buying them) will find it cheaper to go to IPv6. It is the small fry that will be clinging to IPv4 the longest, and will be resisting the move to IPv6 for as long as possible - simply because putting in IPv6<->IPv4 gateways and other infrastructure to support old legacy IPv4 customers will be a much larger percentage of cost of their infrastructure. Of course, from a public good point of view, this is a bad thing because it essentially means that if a transfer policy goes into place that over time we will see more and more deaggregated IPv4 blocks as more and more of the large block holders abandon and split apart and sell off their large holdings. However, it really depends on what you want. If your goal is to prolong IPv4 lifespan, then your going to have to accept more and more deaggregation within the IPv4 routing table. If your goal is to reduce the global route table entry and your against more deaggregation, then to be consistent you should be completely against this transfer policy from the get-go. What you CANNOT have, is your cake and eat it to. You CANNOT have prolonged IPv4 lifespan without an increase in deaggregation. In any case, I am completely against this transfer policy proposal, and always have been. Ted From BillD at cait.wustl.edu Tue Mar 11 14:43:28 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 11 Mar 2008 13:43:28 -0500 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <47D6D0A1.6010202@internap.com> References: <1582DCBFF968F044A9A910C0AB177C902CE64B@cliff.cdi.local> <47D6D0A1.6010202@internap.com> Message-ID: I will piggy back upon Scott's praise of the ARIN staff. I think it would be hard to find a more trustworthy, knowledgeable, competent and dedicated group than ARIN staff. Policy reliance upon them to 'do the right thing' is not an issue of whether they have the talent and ability to do it, but rather is it appropriate to express policy in that generalized way. The risk of being too expressive in giving guidance on how they may do these the task runs the risk of missing something necessary or bleeding over into operations...whereas being to general runs the risk of lack of transparency and perceived fairness. Bill Darte > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Scott Leibrand > Sent: Tuesday, March 11, 2008 1:34 PM > To: Jim Weyand > Cc: arin ppml > Subject: Re: [ppml] Restrictions on transferor deaggregation > in 2008-2: IPv4 Transfer Policy Proposal > > Yes, there have been some numbers produced by ARIN staff > (http://www.arin.net/statistics/index.html), which the AC has > been using (along with some data from whois) to judge the > likely demand and supply of larger and smaller blocks. > > In addition, I would anticipate that ARIN staff will also be > able to use the prices on the listing service to decide > whether/when to adjust deaggregation thresholds. If the > per-IP price for smaller blocks gets to be higher than that > for larger blocks, for example, that may mean that more > deaggregation needs to be permitted. > > Fortunately, ARIN not only has a very smart staff, but also > has the engaged the services of an economics expert with > experience in a wide range of Internet issues (Ben), so I > have confidence that they will be well prepared to make the > decisions required to ensure smooth functioning of the market. > > -Scott > > Jim Weyand wrote: > > Scott- > > Is there any quantitative data on the effect of deaggregation? > > > > The proposal relies on ARIN staff to make decisions regarding > > deaggregation. What skills and experience will be required of staff > > members to make reasonable decisions? > > > > -Jim Weyand > > > >> -----Original Message----- > >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] > On Behalf > > Of > >> Scott Leibrand > >> Sent: Tuesday, March 11, 2008 12:54 PM > >> To: arin ppml > >> Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: > > IPv4 > >> Transfer Policy Proposal > >> > >> First of all, thanks to everyone for their feedback and > discussion of > >> the 2008-2 policy proposal. > >> > >> One item that I still think needs further discussion is > the question > > of > >> whether and how to restrict transferor deaggregation in an IPv4 > > Transfer > >> Policy. The question is, should we place restrictions on both the > >> transferee and transferor to limit deaggregation, or would a more > >> limited set of restrictions be sufficient? > >> > >> Some background (or skip down to the bottom if you want): > >> > >> In 8.3.2 Conditions on the transferee, there are two > bullet points > >> permitting and requiring transferees to get a larger block > than they > >> might otherwise, to help prevent deaggregation: > >> * The transferee may request and receive a contiguous CIDR block > > large > >> enough to provide a 12 month supply of IPv4 addresses. > >> * The transferee may only receive one IPv4 address transfer > > through > >> this > >> Simple Transfer process every 6 months. > >> > >> In 8.3.3 Conditions on the IPv4 address block to be > transferred, a > >> transferor is permitted to split their block into two > pieces, keeping > >> one and transferring the other. This could be an even > split into two > >> CIDR blocks, or at the other extreme it could mean splitting a /8, > >> keeping a /22, and transferring the remaining /9, /10, > /11, /12, /13, > >> /14, /15, /16, /17, /18, /19, /21, and /22. However, it also means > > that > >> a holder of a large IPv4 address block cannot simply > transfer it off > > as > >> 16,384 /22's. > >> > >> In 8.3.6 Deaggregation when Permitted by ARIN, further > deaggregation > >> beyond 8.3.3 is allowed, at ARIN's discretion, in order to > deal with > > any > >> shortage of smaller blocks resulting from the restrictions above. > >> > >> The conditions in 8.3.3 and 8.3.6 above represent a compromise > >> between two views. On the one hand, there is the view that the > >> transferee conditions in 8.3.2 are sufficient to recreate an > >> environment very similar to the one we have today, in that > recipients > >> must justify > > their > >> need for addresses, and then they receive a block large enough to > >> meet their needs for a certain number of months. Today that block > >> comes > > out > >> of a /8 allocated from IANA to ARIN, so each such allocation > >> generates at least one additional route in the routing > table. There > >> is little reason to believe that the number of prefixes > demanded will > >> change significantly, so there would be no incentive for > transferors > >> to deaggregate more than we do today, and therefore in > this view the > > 8.3.2 > >> conditions are adequate, and the last bullet of 8.3.3 and section > > 8.3.6 > >> are unnecessary. > >> > >> The other view is that, without conditions restricting them from > >> doing so, transferors of large netblocks will deaggregate their > >> holdings to > > a > >> large degree and transfer off the resulting pieces, resulting in a > >> shortage of larger blocks. Under this view, the transfer policy > > should > >> restrict the degree to which deaggregation is permitted, thereby > >> encouraging transfer of larger blocks instead of smaller ones. > >> > >> In version 1.0 of the proposal, section 8.3.6 Deaggregation when > >> Permitted by ARIN did not exist. Without it, a convincing argument > > was > >> made that supply of small netblocks would be restricted, thereby > > driving > >> up the price of small netblocks and driving down the price > of large > >> ones. To address this, we added section 8.3.6 in version 1.1. > >> > >> > >> > >> So, a few questions to discuss: > >> > >> Do you think that the IPv4 Transfer Policy should restrict > > deaggregation > >> of transferred netblocks? Why or why not? > >> > >> If so, what restrictions should be placed on > deaggregation, and what > >> types of deaggregation should be allowed to provide supply > of smaller > >> netblocks? > >> > >> Should any restrictions on deaggregation be written into > the policy, > > or > >> should ARIN staff be given discretion to adjust the > restrictions as > >> needed to best serve the interests of the community > (section 8.3.6)? > >> > >> Thanks, > >> Scott > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed > to the ARIN > >> Public Policy Mailing List (PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/ppml > >> Please contact the ARIN Member Services Help Desk at > info at arin.net if > > you > >> experience any issues. > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed > to the ARIN > > Public Policy Mailing List (PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml > > Please contact the ARIN Member Services Help Desk at > info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at > info at arin.net if you experience any issues. > From arin-contact at dirtside.com Tue Mar 11 14:45:47 2008 From: arin-contact at dirtside.com (William Herrin) Date: Tue, 11 Mar 2008 14:45:47 -0400 Subject: [ppml] Securities Act 15 U.S.C. 77b(a)(1) In-Reply-To: <47D6C510.3050508@svcolo.com> References: <47D6ACC3.6090707@svcolo.com> <3c3e3fca0803111005x441027ccn679f5bb196d14fb2@mail.gmail.com> <47D6C032.8090307@svcolo.com> <3c3e3fca0803111035v1af7d810ob9b75f3c60cae34a@mail.gmail.com> <47D6C510.3050508@svcolo.com> Message-ID: <3c3e3fca0803111145o49c9116enbf32d46988c03312@mail.gmail.com> On Tue, Mar 11, 2008 at 1:44 PM, Jo Rhett wrote: > If we could all stick to discussing things we know something about, this > list would be a lot more useful. (and 99% quieter) Jo, Who decides which things I get to know something about? You? Do I need to have passed the bar in a dozen states before I'm qualified to discuss the law? Perhaps it's enough that I aced the couple law courses I took in college. No, surely not. Perhaps I need also have worked for years at the DNC, hand in hand with folks who actually write the laws. The list would exceptionally useful (though perhaps not quieter) if interesting questions were met with well-reasoned answers instead of being derided as ignorant and given a cursory response. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From tedm at ipinc.net Tue Mar 11 14:58:02 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 11 Mar 2008 11:58:02 -0700 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4Transfer Policy Proposal In-Reply-To: Message-ID: <000701c883a9$d53b15b0$6fce4b41@tedsdesk> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Bill Darte > Sent: Tuesday, March 11, 2008 11:43 AM > To: Scott Leibrand; Jim Weyand > Cc: arin ppml > Subject: Re: [ppml] Restrictions on transferor deaggregation > in 2008-2: IPv4Transfer Policy Proposal > > > The risk of being too expressive in giving guidance on how > they may do these the task runs the risk of missing something > necessary or bleeding over into operations...whereas being to > general runs the risk of lack of transparency and perceived fairness. > The goal should not be to try to strike a balance between specific policy and giving ARIN staff their heads. The goal of policy should be to immunize ARIN as much as possible from a successful legal challenge that would destroy ARIN and replace it with some government-run organization that will use the legal system to remake the Internet to it's own ends. That will likely produce policy in some areas that is rather restrictive in what the ARIN staff can do. The recent unpleasantness with Pakistan blocking Youtube over a religious video that the Pakistan government didn't like should have well illustrated the dangers of allowing the world's governments more of a hand in running the Internet. Ted From kkargel at polartel.com Tue Mar 11 15:10:38 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 11 Mar 2008 14:10:38 -0500 Subject: [ppml] Securities Act 15 U.S.C. 77b(a)(1) In-Reply-To: <3c3e3fca0803111145o49c9116enbf32d46988c03312@mail.gmail.com> References: <47D6ACC3.6090707@svcolo.com><3c3e3fca0803111005x441027ccn679f5bb196d14fb2@mail.gmail.com><47D6C032.8090307@svcolo.com><3c3e3fca0803111035v1af7d810ob9b75f3c60cae34a@mail.gmail.com><47D6C510.3050508@svcolo.com> <3c3e3fca0803111145o49c9116enbf32d46988c03312@mail.gmail.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410660104F451@mail> The interesting thing to me about the whole "IP as property" concept is that the only way to dictate it is by making an unenforceable rule. The whole concept is almost impossible to police at layer three or higher unless you are going to tie the IP address to a MAC ID or a physical port (route?) or an identity key. Tacking in the overhead to globally route with authorization in every packet would be unfeasible. Making a rule you can't enforce is really bad parenting and tends to destroy your authority. > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of William Herrin > Sent: Tuesday, March 11, 2008 1:46 PM > To: Jo Rhett > Cc: ppml at arin.net > Subject: Re: [ppml] Securities Act 15 U.S.C. 77b(a)(1) > > On Tue, Mar 11, 2008 at 1:44 PM, Jo Rhett wrote: > > If we could all stick to discussing things we know > something about, > > this list would be a lot more useful. (and 99% quieter) > > Jo, > > Who decides which things I get to know something about? You? > > Do I need to have passed the bar in a dozen states before I'm > qualified to discuss the law? Perhaps it's enough that I aced > the couple law courses I took in college. No, surely not. > Perhaps I need also have worked for years at the DNC, hand in > hand with folks who actually write the laws. > > The list would exceptionally useful (though perhaps not > quieter) if interesting questions were met with well-reasoned > answers instead of being derided as ignorant and given a > cursory response. > > Regards, > Bill Herrin > > > -- > William D. Herrin herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. Web: Falls Church, VA > 22042-3004 _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at > info at arin.net if you experience any issues. > From jrhett at svcolo.com Tue Mar 11 15:18:47 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Tue, 11 Mar 2008 12:18:47 -0700 Subject: [ppml] Securities Act 15 U.S.C. 77b(a)(1) In-Reply-To: <3c3e3fca0803111145o49c9116enbf32d46988c03312@mail.gmail.com> References: <47D6ACC3.6090707@svcolo.com> <3c3e3fca0803111005x441027ccn679f5bb196d14fb2@mail.gmail.com> <47D6C032.8090307@svcolo.com> <3c3e3fca0803111035v1af7d810ob9b75f3c60cae34a@mail.gmail.com> <47D6C510.3050508@svcolo.com> <3c3e3fca0803111145o49c9116enbf32d46988c03312@mail.gmail.com> Message-ID: <47D6DB17.6060207@svcolo.com> William Herrin wrote: > The list would exceptionally useful (though perhaps not quieter) if > interesting questions were met with well-reasoned answers instead of > being derided as ignorant and given a cursory response. It *HAS* been given a well-reasoned answer by ARIN's legal counsel. *YOU* are one who is continuing to argue against his professional expertise. To which I owe you nothing, and a cursory response to stick to your own field is certainly not out of line. *blonk* -- Jo Rhett senior geek Silicon Valley Colocation From stephen at sprunk.org Tue Mar 11 15:00:08 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 11 Mar 2008 14:00:08 -0500 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4Transfer Policy Proposal References: <1582DCBFF968F044A9A910C0AB177C902CE64B@cliff.cdi.local><47D6D0A1.6010202@internap.com> Message-ID: <01b401c883ac$ebac2480$5e3816ac@atlanta.polycom.com> Thus spake "Bill Darte" > Policy reliance upon [ARIN staff] to 'do the right thing' is not an > issue of whether they have the talent and ability to do it, but rather > is it appropriate to express policy in that generalized way. > > The risk of being too expressive in giving guidance on how they may do > these the task runs the risk of missing something necessary or bleeding > over into operations...whereas being to general runs the risk of lack of > transparency and perceived fairness. I agree, and it's a tough balancing act. In addition to your points, it's been expressed in the past that being too general makes it difficult for staff to determine the intent of the policy or deny a request that's questionable. A perfect example would be the vague "justification" for IPv6 SWIPs and PI blocks shorter than /48: staff has to approve all requests because they don't have any policy basis to deny any, which was not the intent. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From woody at pch.net Tue Mar 11 15:23:28 2008 From: woody at pch.net (Bill Woodcock) Date: Tue, 11 Mar 2008 11:23:28 -0800 (PST) Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <47D6C72C.2070604@internap.com> References: <47D6C72C.2070604@internap.com> Message-ID: On Tue, 11 Mar 2008, Scott Leibrand wrote: > One item that I still think needs further discussion is the question of > whether and how to restrict transferor deaggregation in an IPv4 Transfer > Policy. The question is, should we place restrictions on both the > transferee and transferor to limit deaggregation, or would a more > limited set of restrictions be sufficient? It is not in the interests of the Internet community to put any limitations whatsoever on transferors. Doing so would restrict supply, which we don't want, since, all else being equal, it raises the cost of the addresses. We do want to place restrictions on the tranferees, since doing so restricts demand, which, all else being equal, lowers the cost of the addresses. -Bill From arin-contact at dirtside.com Tue Mar 11 15:24:20 2008 From: arin-contact at dirtside.com (William Herrin) Date: Tue, 11 Mar 2008 15:24:20 -0400 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <47D6C72C.2070604@internap.com> References: <47D6C72C.2070604@internap.com> Message-ID: <3c3e3fca0803111224u5be00b79w4ddbe911a0cacc33@mail.gmail.com> On Tue, Mar 11, 2008 at 1:53 PM, Scott Leibrand wrote: > Do you think that the IPv4 Transfer Policy should restrict deaggregation > of transferred netblocks? Why or why not? Scott, Yes, the policy should restrict deaggregation. Why? Allow me to spin a hypothetical scenario: ScottNet, an ISP serving the eastern seaboard, goes bankrupt and the pieces get auctioned off by the court. The customer base is sold by locality to a dozen distinct ISPs who agree to honor some portion of the remaining contracts in order to gain the customers. ScottNet held 3 /12's. In its infinite wisdom, it allocated /24's to its individual POPs as needed and then assigned customer prefixes out of those /24's. Without a restriction on deaggregation, the /24's assigned to each POP are transferred to the purchasing ISP for that POP. Those ISPs aggregate where possible but mostly have to announce the individual /24's. The net impact of ScottNet's dissolution is that as many as 12,000 prefixes are added to the DFZ RIB and FIB at a systemic cost that could exceed $74M/year (http://bill.herrin.us/network/bgpcost.html). I think we can all agree that would be an unfortunate outcome. On Tue, Mar 11, 2008 at 2:05 PM, Bill Darte wrote: > And while you are answering these questions, or just browsing, please > state plainly whether you are 'in favor' of this policy proposal, or > 'opposed'. Opposed at this point, but I do agree that an address market is inevitable and ARIN should act to regulate it intelligently. You're asking good questions and working towards a policy I could support. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From jrhett at svcolo.com Tue Mar 11 15:26:14 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Tue, 11 Mar 2008 12:26:14 -0700 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <000601c883a7$131305d0$6fce4b41@tedsdesk> References: <000601c883a7$131305d0$6fce4b41@tedsdesk> Message-ID: <47D6DCD6.6070308@svcolo.com> Ted Mittelstaedt wrote: > What you CANNOT have, is your cake and eat it to. You CANNOT have prolonged > IPv4 lifespan without an increase in deaggregation. I don't often find myself 100% agreeing with Ted, but this is one of those cases. I don't believe that preventing deaggregation is plausible. I suspect that attempts to do so with move parties interested in using the transfer policy (if approved) into the black market to avoid dealing with the policy limitations. Note: "I don't believe" and "I suspect" are key to understanding my PoV on this issue. I welcome enlightened argument to the contrary, at the cost of one beer at local pub. If you are an interesting talker, I'll buy the second round ;-) -- Jo Rhett senior geek Silicon Valley Colocation From arin-contact at dirtside.com Tue Mar 11 15:43:24 2008 From: arin-contact at dirtside.com (William Herrin) Date: Tue, 11 Mar 2008 15:43:24 -0400 Subject: [ppml] Securities Act 15 U.S.C. 77b(a)(1) In-Reply-To: <47D6DB17.6060207@svcolo.com> References: <47D6ACC3.6090707@svcolo.com> <3c3e3fca0803111005x441027ccn679f5bb196d14fb2@mail.gmail.com> <47D6C032.8090307@svcolo.com> <3c3e3fca0803111035v1af7d810ob9b75f3c60cae34a@mail.gmail.com> <47D6C510.3050508@svcolo.com> <3c3e3fca0803111145o49c9116enbf32d46988c03312@mail.gmail.com> <47D6DB17.6060207@svcolo.com> Message-ID: <3c3e3fca0803111243x6d3fe407h716bf27d53810964@mail.gmail.com> On Tue, Mar 11, 2008 at 3:18 PM, Jo Rhett wrote: > William Herrin wrote: > > The list would exceptionally useful (though perhaps not quieter) if > > interesting questions were met with well-reasoned answers instead of > > being derided as ignorant and given a cursory response. > > It *HAS* been given a well-reasoned answer by ARIN's legal counsel. Jo, That response is at best premature and at worst flat wrong: "ARIN Counsel [..] has already weighed in on this in an _informal_ way" (Bill Darte) and "If a specific policy proposal comes before the Board, we will seek an in-depth legal review at that time." (John Curran). I understand this to mean that at a quick glance there is probably no legal problem but the matter will be more thoroughly researched once specific policy language passes consensus. This was a satisfactory answer to Michael's question. Your derision was and is not. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From michael.dillon at bt.com Tue Mar 11 20:29:42 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 12 Mar 2008 00:29:42 -0000 Subject: [ppml] Securities Act 15 U.S.C. 77b(a)(1) In-Reply-To: References: <47D6ACC3.6090707@svcolo.com> Message-ID: > It's possible that you didn't see my response below: We have had > ARIN Counsel look into this possibility per your request, > and it does > not appear to be an issue. If a specific policy proposal > comes before > the Board, we will seek an in-depth legal review at that time. What is it that isn't an issue? We have had at least one suggestion here that once transfers are allowed, ARIN should provide a listing service which quotes all transactions that take place in order to provide market transparency. I can believe that the policy proposal which simply allows transfers doesn't slide into the SEC regulatory area. But real-time listing services just like the NYSE and CBOT? Somewhere there is a line which we should know about so that we don't waste our time pushing the policy in a direction that attracts government regulation. The possibility of FCC regulation has been well and truly put behind us by work that ICANN and the DOC did, but the SEC is a different ballgame. Since we don't have a really clear case-law ruling that IP addresses are not property, even that could change if and when people start buying and selling address blocks. --Michael Dillon From sleibrand at internap.com Tue Mar 11 20:41:22 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 11 Mar 2008 17:41:22 -0700 Subject: [ppml] Securities Act 15 U.S.C. 77b(a)(1) In-Reply-To: References: <47D6ACC3.6090707@svcolo.com> Message-ID: <47D726B2.6030704@internap.com> Michael, We understand your concern, as does ARIN, the BoT, President, and counsel. Thank you for raising the issue. As others have explained, the way we've been asked to make policy is to first come up with the policy that makes the most sense for the community. ARIN counsel will provide a legal assessment of each policy proposal when it comes before a public policy meeting. If there are areas of particular concern, they will be addressed before any policy proposal is adopted by the BoT. The legal and economic issues surrounding the IPv4 Transfer Policy Proposal will be also be discussed at the Denver meeting, so I think that would be the best forum to continue this particular discussion if you wish to do so. -Scott michael.dillon at bt.com wrote: >> It's possible that you didn't see my response below: We have had >> ARIN Counsel look into this possibility per your request, >> and it does >> not appear to be an issue. If a specific policy proposal >> comes before >> the Board, we will seek an in-depth legal review at that time. > > What is it that isn't an issue? > > We have had at least one suggestion here that once transfers are > allowed, ARIN should provide a listing service which quotes all > transactions that take place in order to provide market transparency. > > I can believe that the policy proposal which simply allows transfers > doesn't slide into the SEC regulatory area. But real-time listing > services just like the NYSE and CBOT? Somewhere there is a line > which we should know about so that we don't waste our time > pushing the policy in a direction that attracts government regulation. > The possibility of FCC regulation has been well and truly put > behind us by work that ICANN and the DOC did, but the SEC is a different > ballgame. > > Since we don't have a really clear case-law ruling that IP addresses are > not property, even that could change if and when people start buying > and selling address blocks. > > --Michael Dillon > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From michael.dillon at bt.com Tue Mar 11 20:46:10 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 12 Mar 2008 00:46:10 -0000 Subject: [ppml] Securities Act 15 U.S.C. 77b(a)(1) In-Reply-To: References: Message-ID: > > P.S. In case you hadn't noticed, I am not a lawyer. > > Then why are you playing one on TV...I mean ppml.... Really? Did I give you legal advice? Did I claim to be a lawyer? Or did I suggest that it would be a wise move to consult expert legal advice in a specific area of law which sounds like it may cover the buying and selling of contracts which bear the right to use a specific IP address block. > I am also not a lawyer, but see nothing in the definition > that comes close to what I see being proposed in the transfer > policy update proposal. During the discussion, others have claimed that the transfer policy is just the first step to enabling an IP address trading market. If such a market would attract SEC regulation, I think that it is a good idea to find out what are the boundaries to ARIN policy, assuming that we do not want to give up our industry self-regulatory regime. If legal advice from a lawyer specializing in SEC Regulations and Title 15 Chapter 2, tells us that there are some real limits and we are close to overstepping them, then people might want to reject the transfer policy entirely and take a different tack. For instance, organizations with a surplus of IPv4 addresses could be required to return them to ARIN, and ARIN could continue to allocate on a needs basis with first-come first-served to decide any supply issues. > And, ARIN Counsel, who is a lawyer has already weighed in on > this in an informal way suggesting a similar opinion that the > SEC is unlikely to take interest. I am assuming, that since ARIN Counsel has been retained for many years by a non-profit organization, that said counsel's expertise is in corporate and general law, not in the specialized area of the SEC and financial markets. To date I have seen no indication that ARIN has consulted with a lawyer whose area of expertise is precisely financial markets. There has been a lot of discussion in which several participants have suggested that the transfer policy is the first step to enabling a market in contracts bearing the right of use of a specific IP address range. Like the New York Stock Exchange or the Chicago commodities markets or NASDAQ etc, etc. That is not ordinary corporate law since ordinary companies do not directly participate in the financial markets, they retain specialists (pension funds, stock brokers, banks) to do it on their behalf. --Michael Dillon From michael.dillon at bt.com Tue Mar 11 20:56:18 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 12 Mar 2008 00:56:18 -0000 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <47D6D0A1.6010202@internap.com> References: <1582DCBFF968F044A9A910C0AB177C902CE64B@cliff.cdi.local> <47D6D0A1.6010202@internap.com> Message-ID: > In addition, I would anticipate that ARIN staff will also be > able to use the prices on the listing service to decide > whether/when to adjust deaggregation thresholds. If the > per-IP price for smaller blocks gets to be higher than that > for larger blocks, for example, that may mean that more > deaggregation needs to be permitted. So, not only will ARIN staff run the registry, and the quotation service, but they will also play a role analogous to the Fed's role in setting the discount rate? And the SEC will just stand by and let you do this because of an untested claim that IP addresses are not property, even though you are now running a market in pseudo-equity derivatives? You do realize that this will all happen at a time when IPv4 address supply will be hard to get which means that some orgs who need addresses will suffer real financial pain either due to inability to get addresses or due to the high price they need to pay for a block. It's almost guaranteed that one or more of these organizations is going to either sue ARIN or file an official complaint with the SEC or lobby Congress to outlaw ARIN. Probably all three. Are you certain that this libertarian/anarchist fantasy market can withstand the test of such legal actions? And that it can be correctly built by a bunch of non-lawyers who so far have not sought expert legal advice? --Michael Dillon From michael.dillon at bt.com Tue Mar 11 20:57:35 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 12 Mar 2008 00:57:35 -0000 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4Transfer Policy Proposal In-Reply-To: <000601c883a7$131305d0$6fce4b41@tedsdesk> References: <47D6C72C.2070604@internap.com> <000601c883a7$131305d0$6fce4b41@tedsdesk> Message-ID: > What you CANNOT have, is your cake and eat it to. You CANNOT > have prolonged > IPv4 lifespan without an increase in deaggregation. > > In any case, I am completely against this transfer policy > proposal, and always have been. For the record, this is also my position. --Michael Dillon From sleibrand at internap.com Tue Mar 11 21:17:09 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 11 Mar 2008 18:17:09 -0700 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: References: <1582DCBFF968F044A9A910C0AB177C902CE64B@cliff.cdi.local> <47D6D0A1.6010202@internap.com> Message-ID: <47D72F15.7040806@internap.com> Michael, Thank you for your input, and for (separately) clearly registering your opposition to the proposal as written. FWIW, ARIN counsel Steve Ryan provided expert legal advice to the AC when we were formulating this proposal, as did Ben Edelman, an economics professor and lawyer hired by ARIN to consult on these matters. (If you were at ABQ, he was one of the ones on the market panel.) I acknowledge that we are not experts in law or economics, but we are doing our best to engage such experts, and to consider their opinion, as well as that of the community, in formulating, revising, and considering this and other policy proposals. If you have any input as to how the IPv4 Transfer Policy Proposal could be made to better serve the needs of the community, I'd love to hear it. If your objections center around legal risk, then I would encourage you to trust (for the sake of policy development) that ARIN will appropriately manage that risk, and address whether the policy would be good or bad for the Internet community, and why. Thanks, Scott michael.dillon at bt.com wrote: >> In addition, I would anticipate that ARIN staff will also be >> able to use the prices on the listing service to decide >> whether/when to adjust deaggregation thresholds. If the >> per-IP price for smaller blocks gets to be higher than that >> for larger blocks, for example, that may mean that more >> deaggregation needs to be permitted. > > So, not only will ARIN staff run the registry, and the quotation > service, but they will also play a role analogous to the Fed's > role in setting the discount rate? > > And the SEC will just stand by and let you do this because of > an untested claim that IP addresses are not property, even > though you are now running a market in pseudo-equity derivatives? > > You do realize that this will all happen at a time when IPv4 address > supply will be hard to get which means that some orgs who need addresses > will suffer real financial pain either due to inability to get addresses > or due to the high price they need to pay for a block. It's almost > guaranteed that one or more of these organizations is going to either > sue ARIN or file an official complaint with the SEC or lobby Congress > to outlaw ARIN. Probably all three. > > Are you certain that this libertarian/anarchist fantasy market can > withstand the test of such legal actions? And that it can be correctly > built by a bunch of non-lawyers who so far have not sought expert legal > advice? > > --Michael Dillon > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From kevin at your.org Wed Mar 12 00:50:12 2008 From: kevin at your.org (Kevin Day) Date: Tue, 11 Mar 2008 23:50:12 -0500 Subject: [ppml] Practical alternatives to v6 deaggregation for ISP/NSPs Message-ID: <85724681-B522-428B-BA90-F906D023EC9B@your.org> I've brought this up a long while back, and while we got some interesting discussion... I still don't have a solution to this for our network. Bringing this up to some other operators with similar networks who haven't even begun to deploy v6 has brought out comments like "I'm totally screwed if that's the case, that would require changing my network and/or business model." For simplicity, I'll describe the (slightly modified for simplicity's sake) case of my own network, and I'd love some suggestions for alternatives. I'm pretty much stuck with not being able to deploy v6 any further until I get some kind of resolution to this, so any advice would be appreciated. If policy changes are necessary because situations like this weren't known when some of the original v6 allocation/use policies were created, I'd like to solicit this community's opinions before proposing changes. Some may ask why this is a discussion for ARIN at all. ARIN's policies strongly suggest that v6 space isn't to be deaggregated at all: 6.3.8 "In IPv6 address policy, the goal of aggregation is considered to be the most important." 6.4.3 "RIRs will apply a minimum size for IPv6 allocations, to facilitate prefix-based filtering. The minimum allocation size for IPv6 address space is /32." and most importantly: 6.5.1.1 "advertising that connectivity through its single aggregated address allocation" Based off this (and other RIR's policies) many networks are already filtering on RIR assignment boundaries - meaning if you get a /32, you won't be heard from a sizable chunk of the internet if you announce less than that. Our network: Consists of several unconnected geographically separate Points of Presence. Each POP has peering and transit through different upstreams than the others. There is no single transit provider that has service in all the locations we're in. What we do now in v4: We have a /19. One /24 is reserved for anycast, and announced from all our POPs. One /23 is announced at each POP. This works really well for us. Nearly everyone will accept announcements down to a /24, and for those that don't we announce the full /19 as well. In v6: We have a /32. We cannot deaggregate this at all. This causes the problem that I can't direct incoming traffic to the correct POP. Possible solution #1 - Deaggregate to our upstreams and let them sort it out. Some people suggested that I announce the full /32, and announce deaggregates with no-export set to my upstreams to let them direct inbound traffic to the correct POP. If I had all the same transit providers at every POP, I could announce the /32 to them and announce a /36s per POP. This breaks if you have a transit provider that isn't connected to *every* POP I have. As an example, assume I have transit provider A at my POP in NYC, and transit provider B at my POP in Los Angeles. To Provider A I announce at our connection in NYC: 2001:1234::/32 (covering prefix for my whole space) 2001:1234:1000::/36 (space I'm using only in NYC) To Provider B I announce at our connection in Los Angeles: 2001:1234::/32 (covering prefix for my whole space) 2001:1234:2000::/36 (space I'm using only in Los Angeles) This works until Provider B receives a packet destined for 2001:1234:1000::/36. They haven't received that /36 route (since it's smaller than the /32 RIR boundry, and a network between A and B is filtering it out), so they deliver it to me in Los Angeles because of the /32. That either causes a routing loop between us, or I'm forced to tunnel it back to New York. Possible solution #2 - Get more address space. A few suggested that we get more address space. ARIN policy doesn't allow us to get any additional space until we've reached a 0.94 HD ratio. I'll never reach that amount if I'm only running my network out of one POP. I'd also like to deploy v6 everywhere now. We don't qualify for micro-allocations, despite some suggestions that we might be able to. We're not "critical infrastructure" as much as I'd like to think we are, and "Internal Infrastructure" micro- allocations are intended to be non-routed. The suggestion that we should start multiple corporations and get a / 32 for each one is creative, but I don't see that as a fair solution. Possible solution #3 - Announce the /32 from all of our POPs and haul the bits around ourselves This really doesn't work either. Some of our POPs are really tiny and have 1/100th the bandwidth of the others. I'd be required to be able to support receiving a lot more inbound at *all* POPs just to handle inbound traffic that I'm going to bounce right out. We'd either have to invest in expensive transport between all of our POPs, or waste a lot of bandwidth tunneling things around. If we have 8 pops, roughly 7/8ths of the packets coming into each one would be for the wrong POP and have to be bounced right back out. This would make our network fragile (any POP being temporarily unable to talk to another one would cause outages), and dramatically increase our costs of doing business. It also seems very unnecessary, endpoints like us shouldn't really be involved in routing at that level. While I'm not saying every ASN works like this, a lot of hosting/colo/ content companies operate in this manner. Forcing them all to change how they do things is going to really increase the struggle-factor of getting them on board with v6. I also have no solution for anycast. I saw talk of a proposal a while back for v6 anycast allocations, did that die off? For those reading this far... If this were your network, what would you do if you needed to deploy v6 immediately? How many people here are strongly opposed to the idea of a TINY amount of deaggregation being explicitly allowed, but discouraged? Something along the lines of "/32 networks may be deaggregated down to /36 announcements. Deaggregation may only be done if other methods to avoid deaggregation have been considered, etc etc etc" Or allow someone who qualifies for a /32 to obtain multiple smaller allocations if they choose? I'm not asking to allow every network to deaggregate their /32 into 65536 /48s, but rather a small amount of deaggregation ONLY where there really are multiple routes to different places. -- Kevin From sleibrand at internap.com Wed Mar 12 01:14:48 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 11 Mar 2008 22:14:48 -0700 Subject: [ppml] Practical alternatives to v6 deaggregation for ISP/NSPs In-Reply-To: <85724681-B522-428B-BA90-F906D023EC9B@your.org> References: <85724681-B522-428B-BA90-F906D023EC9B@your.org> Message-ID: <47D766C8.7000105@internap.com> Kevin, A couple thoughts: You could try announcing your deaggregates (/36 or whatever), in addition to announcing the /32, and *without* no-export set. This is what I envision we'll do when we deploy IPv6. Most people I've talked to agree that, as long as you're announcing the /32, that should be allowed, and it's up to everyone to decide whether or not to accept the more-specifics. If you're paying a transit provider to do so, they should accept them, and should accept the same more-specifics from their peers. As long as your ISPs (or their transit providers) peer with each other, and accept the more-specifics from each other, you should have full reachability, and you shouldn't have to transport the packets yourself (you're paying your ISPs to do that). Alternately, you could perhaps give back your /32, and instead get a PI /48 from ARIN (under the end user policy) for each site (or perhaps a contiguous /44 to get you a /48 per site). I'm not sure if that policy applies in your case, or if that would be a better idea overall in your situation than using a /32, but it seems more reasonable than trying to get additional /32's or "critical infrastructure" blocks. -Scott Kevin Day wrote: > I've brought this up a long while back, and while we got some > interesting discussion... I still don't have a solution to this for > our network. Bringing this up to some other operators with similar > networks who haven't even begun to deploy v6 has brought out comments > like "I'm totally screwed if that's the case, that would require > changing my network and/or business model." > > For simplicity, I'll describe the (slightly modified for simplicity's > sake) case of my own network, and I'd love some suggestions for > alternatives. I'm pretty much stuck with not being able to deploy v6 > any further until I get some kind of resolution to this, so any advice > would be appreciated. If policy changes are necessary because > situations like this weren't known when some of the original v6 > allocation/use policies were created, I'd like to solicit this > community's opinions before proposing changes. > > Some may ask why this is a discussion for ARIN at all. ARIN's policies > strongly suggest that v6 space isn't to be deaggregated at all: > > 6.3.8 "In IPv6 address policy, the goal of aggregation is considered > to be the most important." > > 6.4.3 "RIRs will apply a minimum size for IPv6 allocations, to > facilitate prefix-based filtering. The minimum allocation size for > IPv6 address space is /32." > > and most importantly: > > 6.5.1.1 "advertising that connectivity through its single aggregated > address allocation" > > Based off this (and other RIR's policies) many networks are already > filtering on RIR assignment boundaries - meaning if you get a /32, you > won't be heard from a sizable chunk of the internet if you announce > less than that. > > > Our network: > > Consists of several unconnected geographically separate Points of > Presence. > Each POP has peering and transit through different upstreams than the > others. There is no single transit provider that has service in all > the locations we're in. > > > What we do now in v4: > > We have a /19. > One /24 is reserved for anycast, and announced from all our POPs. > One /23 is announced at each POP. > > This works really well for us. Nearly everyone will accept > announcements down to a /24, and for those that don't we announce the > full /19 as well. > > > In v6: > > We have a /32. > We cannot deaggregate this at all. > > This causes the problem that I can't direct incoming traffic to the > correct POP. > > > Possible solution #1 - Deaggregate to our upstreams and let them sort > it out. > > Some people suggested that I announce the full /32, and announce > deaggregates with no-export set to my upstreams to let them direct > inbound traffic to the correct POP. If I had all the same transit > providers at every POP, I could announce the /32 to them and announce > a /36s per POP. This breaks if you have a transit provider that isn't > connected to *every* POP I have. As an example, assume I have transit > provider A at my POP in NYC, and transit provider B at my POP in Los > Angeles. > > To Provider A I announce at our connection in NYC: > > 2001:1234::/32 (covering prefix for my whole space) > 2001:1234:1000::/36 (space I'm using only in NYC) > > To Provider B I announce at our connection in Los Angeles: > > 2001:1234::/32 (covering prefix for my whole space) > 2001:1234:2000::/36 (space I'm using only in Los Angeles) > > This works until Provider B receives a packet destined for > 2001:1234:1000::/36. They haven't received that /36 route (since it's > smaller than the /32 RIR boundry, and a network between A and B is > filtering it out), so they deliver it to me in Los Angeles because of > the /32. That either causes a routing loop between us, or I'm forced > to tunnel it back to New York. > > > Possible solution #2 - Get more address space. > > A few suggested that we get more address space. ARIN policy doesn't > allow us to get any additional space until we've reached a 0.94 HD > ratio. I'll never reach that amount if I'm only running my network out > of one POP. I'd also like to deploy v6 everywhere now. > > We don't qualify for micro-allocations, despite some suggestions that > we might be able to. We're not "critical infrastructure" as much as > I'd like to think we are, and "Internal Infrastructure" micro- > allocations are intended to be non-routed. > > The suggestion that we should start multiple corporations and get a / > 32 for each one is creative, but I don't see that as a fair solution. > > > Possible solution #3 - Announce the /32 from all of our POPs and haul > the bits around ourselves > > This really doesn't work either. Some of our POPs are really tiny and > have 1/100th the bandwidth of the others. I'd be required to be able > to support receiving a lot more inbound at *all* POPs just to handle > inbound traffic that I'm going to bounce right out. > > We'd either have to invest in expensive transport between all of our > POPs, or waste a lot of bandwidth tunneling things around. If we have > 8 pops, roughly 7/8ths of the packets coming into each one would be > for the wrong POP and have to be bounced right back out. This would > make our network fragile (any POP being temporarily unable to talk to > another one would cause outages), and dramatically increase our costs > of doing business. It also seems very unnecessary, endpoints like us > shouldn't really be involved in routing at that level. > > > While I'm not saying every ASN works like this, a lot of hosting/colo/ > content companies operate in this manner. Forcing them all to change > how they do things is going to really increase the struggle-factor of > getting them on board with v6. > > I also have no solution for anycast. I saw talk of a proposal a while > back for v6 anycast allocations, did that die off? > > For those reading this far... If this were your network, what would > you do if you needed to deploy v6 immediately? > > How many people here are strongly opposed to the idea of a TINY amount > of deaggregation being explicitly allowed, but discouraged? Something > along the lines of "/32 networks may be deaggregated down to /36 > announcements. Deaggregation may only be done if other methods to > avoid deaggregation have been considered, etc etc etc" Or allow > someone who qualifies for a /32 to obtain multiple smaller allocations > if they choose? > > I'm not asking to allow every network to deaggregate their /32 into > 65536 /48s, but rather a small amount of deaggregation ONLY where > there really are multiple routes to different places. > > -- Kevin > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From kevin at your.org Wed Mar 12 02:22:58 2008 From: kevin at your.org (Kevin Day) Date: Wed, 12 Mar 2008 01:22:58 -0500 Subject: [ppml] Practical alternatives to v6 deaggregation for ISP/NSPs In-Reply-To: <47D766C8.7000105@internap.com> References: <85724681-B522-428B-BA90-F906D023EC9B@your.org> <47D766C8.7000105@internap.com> Message-ID: <13C24D93-2BBC-4C01-8A3A-20E895C6454D@your.org> On Mar 12, 2008, at 12:14 AM, Scott Leibrand wrote: > Kevin, > > A couple thoughts: > > You could try announcing your deaggregates (/36 or whatever), in > addition to announcing the /32, and *without* no-export set. This > is what I envision we'll do when we deploy IPv6. Most people I've > talked to agree that, as long as you're announcing the /32, that > should be allowed, and it's up to everyone to decide whether or not > to accept the more-specifics. If you're paying a transit provider > to do so, they should accept them, and should accept the same more- > specifics from their peers. As long as your ISPs (or their transit > providers) peer with each other, and accept the more-specifics from > each other, you should have full reachability, and you shouldn't > have to transport the packets yourself (you're paying your ISPs to > do that). > That doesn't work though... Imagine this scenario: POP A = 2001:1234:1000/36. POP B = 2001:1234:2000/36. POP A <---> Transit 1 <--> Big NSP 1 <---> Big NSP 2 <--> Transit 2 <---> POP B POP A announces to Transit 1 2001:1234:1000/36. I convince Transit 1 to accept that, because I'm paying them to. They in turn announce it to Big NSP 1. Transit 1 may or may not have enough pull with the Big NSP 1 to make them make exceptions to their filters. Even in the most optimistic case, assume they do. Big NSP 2 probably isn't going to accept deaggregates of all of Big NSP 1's customers, so Big NSP 2 doesn't accept it. POP B advertises that /32 and 2001:1234:2000/36 to Transit 2. Transit 2's view of the world is: 2001:1234::/32 -> POP B. 2001:1234:2000/36 -> POP B. The /36 for POP A got filtered out several hops before it reached Transit 2, so Transit 2 has no choice but to send traffic for 2001:1234:1000/36 to POP B. I can ensure that my direct upstreams accept all my deaggregates, I can't ensure that they get propagated to all my other upstreams at other POPs. There are any number of intermediaries between the transit providers at each POP, and if ALL of them accept the deaggregates then it means that nobody is doing any filtering at all. If you don't believe my example with just two "Big NSPs", add 5 of them.. do you really believe that many of them are going to accept deaggregates from customers of customers of customers....? (And no, that's not entirely unreasonable, even in v4 right now, our path from our Amsterdam POP to our Tokyo POP is 7 ASNs long) You are right, if all of our upstreams peer with each other then it probably does work. But, for example, our small upstream provider in Sydney probably doesn't peer with our upstream provider in Berlin. There are a lot of networks between those two, and there's no way every one is going to accept deaggregates from everyone else unless they just aren't filtering at all. Personal experience and views from the SIxXS GRH pages seem to indicate that people are filtering already. I'm also not really that comfortable in basing my network on unrelated party's peering. If one gets into a peering war with another, I don't want my network to go down. > Alternately, you could perhaps give back your /32, and instead get a > PI /48 from ARIN (under the end user policy) for each site (or > perhaps a contiguous /44 to get you a /48 per site). I'm not sure > if that policy applies in your case, or if that would be a better > idea overall in your situation than using a /32, but it seems more > reasonable than trying to get additional /32's or "critical > infrastructure" blocks. > Well... For one, we need to be able to assign /48's to our customers, so I'm not sure an end-user allocation is going to work for us. Secondly, I don't believe current policy allows for getting more than one /48 without using up the first. We could ask for a /44, but from the sounds of it, that will cause people who are filtering on RIR allocations to filter at /44. I went through the same lines of thinking myself when I started with this... It's only when actually trying to do it that I'm running into these problems. I really appreciate your reply though, it shows others are coming up with the same potential solutions that I did. -- Kevin From michael.dillon at bt.com Wed Mar 12 06:50:55 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 12 Mar 2008 10:50:55 -0000 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <47D72F15.7040806@internap.com> References: <1582DCBFF968F044A9A910C0AB177C902CE64B@cliff.cdi.local> <47D6D0A1.6010202@internap.com> <47D72F15.7040806@internap.com> Message-ID: > If your objections center around legal risk, then I would > encourage you to trust (for the sake of policy development) > that ARIN will appropriately manage that risk, and address > whether the policy would be good or bad for the Internet > community, and why. My objections center around wasted time. In other words, if the laws governing "markets" prevent ARIN from creating the kind of market in IP address blocks that many people are promoting, I believe it is a waste of time to put any effort into the groundwork such as the transfer policy. If this policy passes, it amounts to holding out a carrot which turns out to be a piece of dyed silicon rubber. In other words, it is misleading to the public and to the holders of ARIN's IP address allocations. I would rather see more effort put into other areas of ARIN's charter such as education and work on things like the route registry. How about building and documenting a model IPv6 deployment architecture for ISPs showing how a network can begin using IPv6 addresses for growth while maintaining transparent access to IPv4 Internet resources. --Michael Dillon From kevin at your.org Wed Mar 12 07:06:18 2008 From: kevin at your.org (Kevin Day) Date: Wed, 12 Mar 2008 06:06:18 -0500 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <47D6DCD6.6070308@svcolo.com> References: <000601c883a7$131305d0$6fce4b41@tedsdesk> <47D6DCD6.6070308@svcolo.com> Message-ID: On Mar 11, 2008, at 2:26 PM, Jo Rhett wrote: > Ted Mittelstaedt wrote: >> What you CANNOT have, is your cake and eat it to. You CANNOT have >> prolonged >> IPv4 lifespan without an increase in deaggregation. > > I don't often find myself 100% agreeing with Ted, but this is one of > those cases. I don't believe that preventing deaggregation is > plausible. I suspect that attempts to do so with move parties > interested in using the transfer policy (if approved) into the black > market to avoid dealing with the policy limitations. Okay, either I'm missing something completely here or everyone else has gotten so wrapped up in the idea of transferring space that nobody's considering the alternative that I think is a whole heck of a lot more likely... which is already possible and going to cause deaggregation wether we want it or not. Why sell when you can rent and keep collecting cash? Right now I can go to any colo provider and say "I want a half dozen racks, power, and connectivity for my 150 servers." and pretty easily get a /23 or larger. Now what happens if I say "You know, why don't you forget about the racks, power, bandwidth and everything else... How much would just the /23 be per month?" This is possible right now, and as far as I can tell not breaking any policies. A big hosting or colo provider with excess v4 space can SWIP space to the highest bidder for a large monthly check, and have the security that if they end up needing more v4 later they can pull it back. There's no need for a black market, no need for complying with a complicated transfer policy, no need to give up space irrevocably, and it becomes a continuing revenue stream instead of a one off payment. As v4 space gets more and more scarce, the market price goes up along with the asking price. I don't think there's any way this can be prevented under current policies, and even though it feels wrong I don't know how you can prevent this without preventing other more "legitimate" business. Require that the address space come with some kind of service? Okay, throw in a dialup PPP line with it. Where do you draw the line that won't take more time to verify than it's worth? Rather than a stock-market like service of selling IP space, I think it's a lot more likely that we're going to see ISPs offering IP space as a standalone monthly service. This will cause deaggregation. This is possible already, with no policy changes. I'd actually be surprised if it's not happening already for networks that were denied by their RIR. -- Kevin From Lee.Howard at stanleyassociates.com Wed Mar 12 10:09:43 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 12 Mar 2008 10:09:43 -0400 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4Transfer Policy Proposal In-Reply-To: Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB408E4C2D0@CL-S-EX-1.stanleyassociates.com> > Right now I can go to any colo provider and say "I want a > half dozen racks, power, and connectivity for my 150 > servers." and pretty easily get a /23 or larger. Now what > happens if I say "You know, why don't you forget about the > racks, power, bandwidth and everything else... > How much would just the /23 be per month?" NRPM 4.2.3.4 Downstream customer adherence ISPs must require their downstream customers to adhere to the following criteria: 4.2.3.4.1 Utilization Reassignment information for prior allocations must show that each customer meets the 80% utilization criteria and must be available via SWIP/RHWOIS prior to your issuing them additional space. . . . 4.2.3.6 Reassignments to multihomed downstream customers Under normal circumstances an ISP is required to determine the prefix size of their reassignment to a downstream customer according to the guidelines set forth in RFC 2050. Specifically, a downstream customer justifies their reassignment by demonstrating they have an immediate requirement for 25% of the IP addresses being assigned, and that they have a plan to utilize 50% of their assignment within one year of its receipt. . . . > > This is possible right now, and as far as I can tell not > breaking any policies. Looks like it breaks at least one of the above policies. You can't get a /23 because you're getting rack space. You can get a /23 because you're hosting a bunch of equipment with several subnets (for various, inversely proportional values of "bunch" and "several"). > Require that the address space come with some kind of > service? Okay, throw in a dialup PPP line with it. Where do > you draw the line that won't take more time to verify than it's worth? Every time you need more space, either under existing policy or under the proposed transfer policy. > This is possible already, with no policy changes. Not the way I read it. > I'd actually be surprised if it's not happening already for > networks that were denied by their RIR. If it is, it's in small pockets around the industry. The reputable carriers don't do this. Lee > -- Kevin > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at > info at arin.net if you experience any issues. > From BillD at cait.wustl.edu Wed Mar 12 10:12:43 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Wed, 12 Mar 2008 09:12:43 -0500 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4Transfer Policy Proposal In-Reply-To: References: <000601c883a7$131305d0$6fce4b41@tedsdesk><47D6DCD6.6070308@svcolo.com> Message-ID: > > On Mar 11, 2008, at 2:26 PM, Jo Rhett wrote: > > > Ted Mittelstaedt wrote: > >> What you CANNOT have, is your cake and eat it to. You CANNOT have > >> prolonged > >> IPv4 lifespan without an increase in deaggregation. > > > > I don't often find myself 100% agreeing with Ted, but this > is one of > > those cases. I don't believe that preventing deaggregation is > > plausible. I suspect that attempts to do so with move parties > > interested in using the transfer policy (if approved) into > the black > > market to avoid dealing with the policy limitations. > > > Okay, either I'm missing something completely here or > everyone else has gotten so wrapped up in the idea of > transferring space that nobody's considering the alternative > that I think is a whole heck of a lot more likely... which is > already possible and going to cause deaggregation wether we > want it or not. > > Why sell when you can rent and keep collecting cash? Kevin, I agree. This is a fear I have of the whole loosened transfer policy. Given that the policy were put in place, this loosens not just the transfer policy, but the notion of who's in charge. I see that legacy block holders and those that can free up sizeable blocks can become local registries and who's to stop that? > > Right now I can go to any colo provider and say "I want a > half dozen racks, power, and connectivity for my 150 > servers." and pretty easily get a /23 or larger. Now what > happens if I say "You know, why don't you forget about the > racks, power, bandwidth and everything else... > How much would just the /23 be per month?" > > This is possible right now, and as far as I can tell not > breaking any policies. A big hosting or colo provider with > excess v4 space can SWIP space to the highest bidder for a > large monthly check, and have the security that if they end > up needing more v4 later they can pull it back. There's no > need for a black market, no need for complying with a > complicated transfer policy, no need to give up space > irrevocably, and it becomes a continuing revenue stream > instead of a one off payment. > As v4 space gets more and more scarce, the market price goes > up along with the asking price. > > I don't think there's any way this can be prevented under > current policies, and even though it feels wrong I don't know > how you can prevent this without preventing other more > "legitimate" business. > Require that the address space come with some kind of > service? Okay, throw in a dialup PPP line with it. Where do > you draw the line that won't take more time to verify than it's worth? > > Rather than a stock-market like service of selling IP space, > I think it's a lot more likely that we're going to see ISPs > offering IP space as a standalone monthly service. > > This will cause deaggregation. > > This is possible already, with no policy changes. > > I'd actually be surprised if it's not happening already for > networks that were denied by their RIR. > > -- Kevin > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at > info at arin.net if you experience any issues. > From kevin at your.org Wed Mar 12 13:18:35 2008 From: kevin at your.org (Kevin - Your.Org) Date: Wed, 12 Mar 2008 12:18:35 -0500 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4Transfer Policy Proposal In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB408E4C2D0@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB408E4C2D0@CL-S-EX-1.stanleyassociates.com> Message-ID: <238024D2-2AF6-461D-A16F-31EE62CB0415@your.org> On Mar 12, 2008, at 9:09 AM, Howard, W. Lee wrote: >> Right now I can go to any colo provider and say "I want a >> half dozen racks, power, and connectivity for my 150 >> servers." and pretty easily get a /23 or larger. Now what >> happens if I say "You know, why don't you forget about the >> racks, power, bandwidth and everything else... >> How much would just the /23 be per month?" > > NRPM > 4.2.3.4 Downstream customer adherence > ISPs must require their downstream customers to adhere to the > following criteria: > 4.2.3.4.1 Utilization > Reassignment information for prior allocations must show that each > customer meets the 80% utilization criteria and must be available > via SWIP/RHWOIS prior to your issuing them additional space. > . . . > 4.2.3.6 Reassignments to multihomed downstream customers > Under normal circumstances an ISP is required to determine the prefix > size of their reassignment to a downstream customer according to the > guidelines set forth in RFC 2050. Specifically, a downstream customer > justifies their reassignment by demonstrating they have an immediate > requirement for 25% of the IP addresses being assigned, and that they > have a plan to utilize 50% of their assignment within one year of its > receipt. > . . . > > Who said anything about not being utilized? The space will be utilized, just not on a network directly connected. Renter: "I would like to rent a /20." ISP: "Okay, can you document and justify it?" Renter: "Sure, here's my paperwork and network diagrams of how I plan to use this space." ISP: "Great, That will be $x/month." Renter goes an announces the /20 through their existing transit connections. If ISP doesn't want to appear to be renting the space out, they might work out a deal where they'll announce it too, but prepended to death. For the record, I'm not saying I *support* doing this, and have absolutely no plans to attempt this from either side. Just that I don't see why it's not possible now. -- Kevin From kevin at your.org Wed Mar 12 13:30:49 2008 From: kevin at your.org (Kevin - Your.Org) Date: Wed, 12 Mar 2008 12:30:49 -0500 Subject: [ppml] Practical alternatives to v6 deaggregation for ISP/NSPs In-Reply-To: <20080312162321.E9E62A0A44E@mail.your.org> References: <85724681-B522-428B-BA90-F906D023EC9B@your.org> <20080312162321.E9E62A0A44E@mail.your.org> Message-ID: <18AD1E7E-3762-4AE1-A8FD-05C49D36CD39@your.org> On Mar 12, 2008, at 11:16 AM, mcr at simtone.net wrote: > >>>>>> "Kevin" == Kevin Day writes: > Kevin> What we do now in v4: > > Kevin> We have a /19. One /24 is reserved for anycast, and > Kevin> announced from all our POPs. One /23 is announced at each > Kevin> POP. > > Kevin> This works really well for us. Nearly everyone will accept > Kevin> announcements down to a /24, and for those that don't we > Kevin> announce the full /19 as well. > > So, if your /19 attracts traffic to the wrong POP's ISP, you are > depending upon each of the POP's transit ISP to also have accepted > your > /24s, and that those ISPs either peer directly, or do so through ISPs > that will transit those /24s. Right now, in v4, we have zero problem with transit networks accepting deaggregates. That's what's different in v6. There's no problem where traffic is coming into the wrong POP because the deaggregates are being propagated pretty much globally. All of our transit providers in v4 accept deaggregates, and all of THEIR providers do as well, etc. For the most part, the only networks that are filtering on RIR boundaries are more towards the edges. Withdrawing the covering /19 doesn't even make a perceptible difference in traffic coming in to us, so the number of networks doing it is tiny. > > The second (more architecturally pure) answer is that perhaps you > should have asked for and received PA /48s from each ISP for each POP > and/or end-user PI /48s from ARIN. You'd want at least one PI /48 for > your anycast announcement, I think. We multihome in every POP, so PA space isn't possible for us. > > Kevin> Possible solution #2 - Get more address space. > > well, you need different address space, not more. > Exactly my point, but something that the current policy doesn't allow. > > Fundamentally, ASNs are supposed to convex, and yours are concave. > Possibly, but I don't think our network is unique or doing anything "wrong". None of our transit providers, peers or other entities we do business with have had any issues with the way we're running our network, the only resistance I'm getting is policy based. :) -- Kevin From arin-contact at dirtside.com Wed Mar 12 13:41:21 2008 From: arin-contact at dirtside.com (William Herrin) Date: Wed, 12 Mar 2008 13:41:21 -0400 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4Transfer Policy Proposal In-Reply-To: <238024D2-2AF6-461D-A16F-31EE62CB0415@your.org> References: <369EB04A0951824ABE7D8BAC67AF9BB408E4C2D0@CL-S-EX-1.stanleyassociates.com> <238024D2-2AF6-461D-A16F-31EE62CB0415@your.org> Message-ID: <3c3e3fca0803121041k388511bcv916257330edf58a3@mail.gmail.com> On Wed, Mar 12, 2008 at 1:18 PM, Kevin - Your.Org wrote: > Renter: "I would like to rent a /20." > ISP: "Okay, can you document and justify it?" > Renter: "Sure, here's my paperwork and network diagrams of how I plan > to use this space." > ISP: "Great, That will be $x/month." Hi Kevin, We talked about this last year. You might be interested in http://lists.arin.net/pipermail/ppml/2007-July/008275.html > For the record, I'm not saying I *support* doing this, and have > absolutely no plans to attempt this from either side. Just that I > don't see why it's not possible now. It is possible now. It's just not economically practical. In a post-exhaustion it could quickly become economically practical. The solution might be an operations-level thing with minor support from the RIRs: NRO could offer some kind of feed (perhaps via BGP) of allocated and assigned CIDR blocks. Operators would then be able to filter their BGP neighbors' announcements by discarding those which do not conform. That has other problems (severe ones) but if exhaustion induces a table explosion there may not be many alternatives. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From tedm at ipinc.net Wed Mar 12 14:08:34 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 12 Mar 2008 11:08:34 -0700 Subject: [ppml] Securities Act 15 U.S.C. 77b(a)(1) In-Reply-To: <47D726B2.6030704@internap.com> Message-ID: <000501c8846c$167dd9a0$6fce4b41@tedsdesk> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Scott Leibrand > Sent: Tuesday, March 11, 2008 5:41 PM > To: michael.dillon at bt.com > Cc: ppml at arin.net > Subject: Re: [ppml] Securities Act 15 U.S.C. 77b(a)(1) > > > Michael, > > We understand your concern, as does ARIN, the BoT, President, and > counsel. Thank you for raising the issue. As others have explained, > the way we've been asked to make policy is to first come up with the > policy that makes the most sense for the community. ARIN > counsel will > provide a legal assessment of each policy proposal when it > comes before > a public policy meeting. If there are areas of particular > concern, they > will be addressed before any policy proposal is adopted by the BoT. > Scott, I understand your point of view but... When making policy you don't go out and make the policy the way you want it then ask a bunch of lawyers to try to cudgel it around to fit within existing law or find a bunch of loopholes you can use. What you do is get educated as to ALL of the issues surrounding a particular policy choice BEFORE you make policy. Michael's got a valid point, although I think he's not properly making it. I'll try to reframe this here. Michael's trying to say that if ARIN sets itself up as a "market oversee'r" they are in effect putting themselves into a position where they are judge and jury and sentence executioner. You and others may claim that use of language like "Paying a bounty to a current registrar of an IP block is not buying that IP block it is merely adjusting the mechanism ARIN uses to assign an IP block so the paying organization is then registered with a particular IP block" is lightyears different than "orgs buying the property of an IP block" but this is a baloney argument - if it looks, walks, and quacks like a duck, it's a duck. Any IPv4 "market" that is created is going to resemble every other commodities futures market in existence because that is the only way that you can run such things successfully, that is WHY all of those commodities futures markets resemble each other. And it's only a short step from "resembling" to "is" for a regulatory agency to make. Michael is saying that if ARIN creates a commodities futures market, that all the protesting in the world that their commodities futures market "isn't really a commodities futures market, it's something special" is going to fall on deaf governmental ears - it is tanasmount to waving a red flag in front of a bull and begging for the government (SEC in this case) to come in and regulate it. Your only defense is that the lawyer who is on retainer by the organization that is going to benefit from this market is saying it's OK so SFU - well please stop insulting our intelligence, we weren't born yesterday. If you really, really want this thing, you had better now start accepting that creating a secondary IPv4 "market" whether legal with current law or not, is likely going to attract undesirable governmental attention. Your task here in defending this IPv4 market proposal is not to play a George Bush and tell us not to worry there's no problem. Your job is to justify WHY the benefits of creating this secondary IPv4 trading market will outweigh any headaches that may come with that undesirable regulatory attention that Michael is saying is a sure thing to come. Michael's arguments are speculation of what MIGHT happen should this market come into existence. Your argument is speculation of what WILL happen if this market comes into existence. You have a much easier argument to make, so quit taking the lazy man's way out of just pulling a George (there's no recession) Bush and start actually adressing the concerns. Ted From tedm at ipinc.net Wed Mar 12 14:21:38 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 12 Mar 2008 11:21:38 -0700 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4Transfer Policy Proposal In-Reply-To: Message-ID: <000601c8846d$e9b1e270$6fce4b41@tedsdesk> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Kevin Day > Sent: Wednesday, March 12, 2008 4:06 AM > To: Jo Rhett > Cc: 'arin ppml' > Subject: Re: [ppml] Restrictions on transferor deaggregation > in 2008-2: IPv4Transfer Policy Proposal > > > > On Mar 11, 2008, at 2:26 PM, Jo Rhett wrote: > > > Ted Mittelstaedt wrote: > >> What you CANNOT have, is your cake and eat it to. You CANNOT have > >> prolonged > >> IPv4 lifespan without an increase in deaggregation. > > > > I don't often find myself 100% agreeing with Ted, but this > is one of > > those cases. I don't believe that preventing deaggregation is > > plausible. I suspect that attempts to do so with move parties > > interested in using the transfer policy (if approved) into > the black > > market to avoid dealing with the policy limitations. > > > Okay, either I'm missing something completely here or everyone else > has gotten so wrapped up in the idea of transferring space that > nobody's considering the alternative that I think is a whole > heck of a > lot more likely... which is already possible and going to cause > deaggregation wether we want it or not. > > Why sell when you can rent and keep collecting cash? > > Right now I can go to any colo provider and say "I want a half dozen > racks, power, and connectivity for my 150 servers." and > pretty easily > get a /23 or larger. Now what happens if I say "You know, why don't > you forget about the racks, power, bandwidth and everything else... > How much would just the /23 be per month?" > We ARE a colo provider (among other things) We HAVE an unused /23 (among our other assignments). If you came to us and asked this I would say "why would we rent you the /23 for less money than we can make by renting out our racks, power, connectivity + the /23 to some other customer?" > > I don't think there's any way this can be prevented under current > policies, and even though it feels wrong I don't know how you can > prevent this without preventing other more "legitimate" business. It can't except that it's stupid business. Fundamentally, all of us Internet Service Providers are in this business for the money, right? Well, if we own the infrastructure to justify having the numbers in the first place, we are going to make more money using those numbers for selling that infrastructure, than if we just sell those numbers. You could take your broken car to an auto mechanic, for example, and ask him "how much is it going to cost me for you to diagnose the problem in my car so that I can go fix it myself" If this auto mechanic is worth his salt, he's going to be a good enough businessman to simply tell you that he would be willing to look at it and tell you how much it will cost to fix - but he's not going to tell you what is broken and exactly how to fix it. If he was actually willing to diagnose it and tell you exactly how to fix it, he would be a pretty poor mechanic in which case his advice wouldn't be worth what it cost to start with. What your talking about is ONLY applicable to ISP's or colo providers who have far MORE numbers than they can use - and that's a violation of the RSA in which case ARIN can take the numbers away, or to legacy holders who it's been said many times on the list, that there's too few resources tied up in the legacy holders for them selling them off to make any significant difference in IPv4 runout. Ted From jrhett at svcolo.com Wed Mar 12 16:31:42 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Wed, 12 Mar 2008 13:31:42 -0700 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: References: <000601c883a7$131305d0$6fce4b41@tedsdesk> <47D6DCD6.6070308@svcolo.com> Message-ID: <079AA711-30FF-476F-8489-57C80BEBC01E@svcolo.com> On Mar 12, 2008, at 4:06 AM, Kevin Day wrote: > Right now I can go to any colo provider and say "I want a half > dozen racks, power, and connectivity for my 150 servers." and > pretty easily get a /23 or larger. Now what happens if I say "You > know, why don't you forget about the racks, power, bandwidth and > everything else... How much would just the /23 be per month?" Not here you won't. You start with a /29 and you justify everything else, using a form which is basically the ARIN justification rewritten clearly for normal people. You must know someone special. I'm pretty sure I know every other IP- assigning admin in the bay area, and all of us commiserate about how hard it is to get people to fill out the documentation properly. And none of us give IPs away, since we're going to have to justify that to ARIN when we go back to the pond for more. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From stephen at sprunk.org Wed Mar 12 16:34:30 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 12 Mar 2008 15:34:30 -0500 Subject: [ppml] Practical alternatives to v6 deaggregation for ISP/NSPs References: <85724681-B522-428B-BA90-F906D023EC9B@your.org><47D766C8.7000105@internap.com> <13C24D93-2BBC-4C01-8A3A-20E895C6454D@your.org> Message-ID: <042001c88480$bac01550$5e3816ac@atlanta.polycom.com> Thus spake "Kevin Day" > On Mar 12, 2008, at 12:14 AM, Scott Leibrand wrote: >> You could try announcing your deaggregates (/36 or whatever), in >> addition to announcing the /32, and *without* no-export set. This >> is what I envision we'll do when we deploy IPv6. Most people I've >> talked to agree that, as long as you're announcing the /32, that >> should be allowed, and it's up to everyone to decide whether or not >> to accept the more-specifics. If you're paying a transit provider >> to do so, they should accept them, and should accept the same more- >> specifics from their peers. As long as your ISPs (or their transit >> providers) peer with each other, and accept the more-specifics from >> each other, you should have full reachability, and you shouldn't >> have to transport the packets yourself (you're paying your ISPs to >> do that). > > That doesn't work though... Imagine this scenario: > > POP A = 2001:1234:1000/36. > POP B = 2001:1234:2000/36. > > POP A <---> Transit 1 <--> Big NSP 1 <---> Big NSP 2 <--> Transit 2 > <---> POP B AFAIK, if your POPs are completely independent, i.e. you have no backside network connecting them, then they're two different networks and you qualify for two /32s -- preferably a /31 in case you ever do connect them together. (I assume reality is a lot more than two sites, though, which makes this a very ugly "solution", but I don't see anything better. Most ARIN policy is based around the assumption that each org operates a single network or a group of networks with complete internal reachability.) >> Alternately, you could perhaps give back your /32, and instead get a >> PI /48 from ARIN (under the end user policy) for each site (or >> perhaps a contiguous /44 to get you a /48 per site). I'm not sure >> if that policy applies in your case, or if that would be a better >> idea overall in your situation than using a /32, but it seems more >> reasonable than trying to get additional /32's or "critical >> infrastructure" blocks. >> > > Well... For one, we need to be able to assign /48's to our customers, > so I'm not sure an end-user allocation is going to work for us. > Secondly, I don't believe current policy allows for getting more than > one /48 without using up the first. If you need to assign space to customers, you are an LIR and do not qualify for end-user PI space. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From stephen at sprunk.org Wed Mar 12 16:47:22 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 12 Mar 2008 15:47:22 -0500 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4Transfer Policy Proposal References: <000601c883a7$131305d0$6fce4b41@tedsdesk><47D6DCD6.6070308@svcolo.com> Message-ID: <045d01c88485$086f7c60$5e3816ac@atlanta.polycom.com> Thus spake "Kevin Day" > Why sell when you can rent and keep collecting cash? You may well get more income by selling an asset and investing the proceeds in other things than you would renting it out. Also, some folks aren't willing to rent assets they consider critical; they want to own them, and will either pay whatever price is necessary for someone to sell them those assets or find a way to do without entirely (i.e. move to v6). > Right now I can go to any colo provider and say "I want a half dozen > racks, power, and connectivity for my 150 servers." and pretty easily > get a /23 or larger. Now what happens if I say "You know, why don't > you forget about the racks, power, bandwidth and everything else... > How much would just the /23 be per month?" Aside from the provider's obvious problem with their next round of ARIN justification? This is a case of trying to multihome with PA space except that you (in theory) would not be buying connectivity to them. My guess is that in practice, they'd designate a port for you and simply not turn it up -- and make your bill the same as if you were using them and the entire exercise pointless. If you're stuck with all the downsides of PA multihoming, you might as well have connectivity to that provider and at least having things mostly work most of the time... > This is possible right now, and as far as I can tell not breaking any > policies. A big hosting or colo provider with excess v4 space can SWIP > space to the highest bidder for a large monthly check, and have the > security that if they end up needing more v4 later they can pull it > back. You can bet if I'm paying someone for space under your model, I'd have the contract written so that they couldn't take it back. Also, the concept of folks with "excess" space is one of several reasons for 2007-14. If that passes, expect that supply to diminish quickly, at least the non-legacy parts of it. > This will cause deaggregation. Everything causes deaggregation. Isn't that one of the laws of thermodynamics? Net entropy always increases. :) S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From kevin at your.org Wed Mar 12 17:26:12 2008 From: kevin at your.org (Kevin - Your.Org) Date: Wed, 12 Mar 2008 16:26:12 -0500 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4Transfer Policy Proposal In-Reply-To: <045d01c88485$086f7c60$5e3816ac@atlanta.polycom.com> References: <000601c883a7$131305d0$6fce4b41@tedsdesk><47D6DCD6.6070308@svcolo.com> <045d01c88485$086f7c60$5e3816ac@atlanta.polycom.com> Message-ID: <492C0D30-B758-45C4-9C30-FA4D81E8F00F@your.org> On Mar 12, 2008, at 3:47 PM, Stephen Sprunk wrote: >> Right now I can go to any colo provider and say "I want a half dozen >> racks, power, and connectivity for my 150 servers." and pretty easily >> get a /23 or larger. Now what happens if I say "You know, why don't >> you forget about the racks, power, bandwidth and everything else... >> How much would just the /23 be per month?" > > Aside from the provider's obvious problem with their next round of > ARIN justification? > First, I'm only seeing this happening after v4 is exhausted, so I'm not sure some organizations really care about having to justify space again. v4 has run out, and the /32 they have will probably last them forever. Second, if done "by the books" why would there be a problem? I'm not talking about companies hiding this... The customer would have to properly justify the space being used SOMEWHERE, just not necessarily within the walls of that ISP's datacenter. Imagine a scenario like William Herrin brought up ( http://lists.arin.net/pipermail/ppml/2007-July/008275.html ). Fully document this like it were an in-house customer, they're just not using you for transit or rack space. I don't think it's right, but I also don't see how it violates any policy. > This is a case of trying to multihome with PA space except that you > (in theory) would not be buying connectivity to them. My guess is > that in practice, they'd designate a port for you and simply not > turn it up -- and make your bill the same as if you were using them > and the entire exercise pointless. If you're stuck with all the > downsides of PA multihoming, you might as well have connectivity to > that provider and at least having things mostly work most of the > time... > Why would they have to do that? If an ISP in South Africa lucks out with AFRINIC's expected "last to run out" place in v4 and gets a ton of space... I'm sure there will be people desperate enough for v4 space at some point to pay them enough to be worth doing. As long as they're making the same amount in profit at the end of the month, not having to worry about SLAs or other bandwidth issues might make it preferable to selling bandwidth. If v4 demand gets as bad as I'm fearing after exhaustion, I don't doubt that people will be offering more money for v4 space than what some colo companies are making off their traditional products. > > You can bet if I'm paying someone for space under your model, I'd > have the contract written so that they couldn't take it back. > > Also, the concept of folks with "excess" space is one of several > reasons for 2007-14. If that passes, expect that supply to diminish > quickly, at least the non-legacy parts of it. I think if anything, 2007-14 is going to push MORE people into doing this. If I'm sitting on unused space right now and I want to keep it or monetize it, the first thing I'll do is find "customers" I can SWIP it to, so that it no longer is "unused". Fully justified, documented customers that have given us network diagrams and planned use documents. They just aren't buying transit from us. And just to try to further emphasize this since s couple of off-list replies have seemed to misunderstand this... I'm not going to do this myself, I'm playing devil's advocate by bringing this up because I'm concerned others will. I'm not sitting on unused space, and wouldn't do this even if I was. -- Kevin From jrhett at svcolo.com Wed Mar 12 18:01:32 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Wed, 12 Mar 2008 15:01:32 -0700 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4Transfer Policy Proposal In-Reply-To: <000601c8846d$e9b1e270$6fce4b41@tedsdesk> References: <000601c8846d$e9b1e270$6fce4b41@tedsdesk> Message-ID: <57661D7C-F579-413C-B456-71559598D746@svcolo.com> On Mar 12, 2008, at 11:21 AM, Ted Mittelstaedt wrote: > You could take your broken car to an auto mechanic, for example, > and ask him "how much is it going to cost me for you to diagnose > the problem in my car so that I can go fix it myself" If this > auto mechanic is worth his salt, he's going to be a good enough > businessman to simply tell you that he would be willing to look at > it and tell you how much it will cost to fix - but he's not going to > tell you what is broken and exactly how to fix it. If he was actually > willing to diagnose it and tell you exactly how to fix it, he would > be a pretty poor mechanic in which case his advice wouldn't be worth > what it cost to start with. Not the best analogy. Many really talented mechanics would rather tell you how if you can fix it yourself, make you happy and send you on your way. They are too busy for easy stuff. My mechanic fits that description. Race engine builders are an extreme example of that. If they diagnose that it can be fixed by someone else, they'll return the bike/engine with details notes of how to fix, no charge. They're too busy to bother working on stuff that doesn't need them. (no useful content here, just saying that your analogy doesn't work in real world) -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From JOHN at egh.com Wed Mar 12 20:37:36 2008 From: JOHN at egh.com (John Santos) Date: Wed, 12 Mar 2008 20:37:36 -0400 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: Message-ID: <1080312203034.2385B-100000@Ives.egh.com> This doesn't work. You would either need to put your equipment on the colo's premises (that's what "colo" means") or you would have to install a circuit between the colo and your own premises. No on is going to route the colo's network to anywhere but the colo's network. Sure, anyone with spare v4 address space could just become an ISP and lease you "permanent" v4 addresses (permanent for as long as you and the "ISP" maintain a business relationship and you pay your bill), but they would have to set up their own network to reach you. (I haven't read the 40 or so messages that have piled up today, I'm sure someone else has already said the same thing.) On Wed, 12 Mar 2008, Kevin Day wrote: > > On Mar 11, 2008, at 2:26 PM, Jo Rhett wrote: > > > Ted Mittelstaedt wrote: > >> What you CANNOT have, is your cake and eat it to. You CANNOT have > >> prolonged > >> IPv4 lifespan without an increase in deaggregation. > > > > I don't often find myself 100% agreeing with Ted, but this is one of > > those cases. I don't believe that preventing deaggregation is > > plausible. I suspect that attempts to do so with move parties > > interested in using the transfer policy (if approved) into the black > > market to avoid dealing with the policy limitations. > > > Okay, either I'm missing something completely here or everyone else > has gotten so wrapped up in the idea of transferring space that > nobody's considering the alternative that I think is a whole heck of a > lot more likely... which is already possible and going to cause > deaggregation wether we want it or not. > > Why sell when you can rent and keep collecting cash? > > Right now I can go to any colo provider and say "I want a half dozen > racks, power, and connectivity for my 150 servers." and pretty easily > get a /23 or larger. Now what happens if I say "You know, why don't > you forget about the racks, power, bandwidth and everything else... > How much would just the /23 be per month?" > > This is possible right now, and as far as I can tell not breaking any > policies. A big hosting or colo provider with excess v4 space can SWIP > space to the highest bidder for a large monthly check, and have the > security that if they end up needing more v4 later they can pull it > back. There's no need for a black market, no need for complying with a > complicated transfer policy, no need to give up space irrevocably, and > it becomes a continuing revenue stream instead of a one off payment. > As v4 space gets more and more scarce, the market price goes up along > with the asking price. > > I don't think there's any way this can be prevented under current > policies, and even though it feels wrong I don't know how you can > prevent this without preventing other more "legitimate" business. > Require that the address space come with some kind of service? Okay, > throw in a dialup PPP line with it. Where do you draw the line that > won't take more time to verify than it's worth? > > Rather than a stock-market like service of selling IP space, I think > it's a lot more likely that we're going to see ISPs offering IP space > as a standalone monthly service. > > This will cause deaggregation. > > This is possible already, with no policy changes. > > I'd actually be surprised if it's not happening already for networks > that were denied by their RIR. > > -- Kevin > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From gih at apnic.net Thu Mar 13 07:52:23 2008 From: gih at apnic.net (Geoff Huston) Date: Thu, 13 Mar 2008 22:52:23 +1100 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4Transfer Policy Proposal In-Reply-To: References: <000601c883a7$131305d0$6fce4b41@tedsdesk><47D6DCD6.6070308@svcolo.com> Message-ID: <47D91577.9090109@apnic.net> Bill Darte wrote: > >> On Mar 11, 2008, at 2:26 PM, Jo Rhett wrote: >> >>> Ted Mittelstaedt wrote: >>>> What you CANNOT have, is your cake and eat it to. You CANNOT have >>>> prolonged >>>> IPv4 lifespan without an increase in deaggregation. >>> I don't often find myself 100% agreeing with Ted, but this >> is one of >>> those cases. I don't believe that preventing deaggregation is >>> plausible. I suspect that attempts to do so with move parties >>> interested in using the transfer policy (if approved) into >> the black >>> market to avoid dealing with the policy limitations. >> >> Okay, either I'm missing something completely here or >> everyone else has gotten so wrapped up in the idea of >> transferring space that nobody's considering the alternative >> that I think is a whole heck of a lot more likely... which is >> already possible and going to cause deaggregation wether we >> want it or not. >> >> Why sell when you can rent and keep collecting cash? > > Kevin, I agree. This is a fear I have of the whole loosened transfer > policy. > Given that the policy were put in place, this loosens not just the > transfer policy, but the notion of who's in charge. > I see that legacy block holders and those that can free up sizeable > blocks can become local registries and who's to stop that? Bill, Have you considered the implications of the non-permanent transfers described in the RIPE policy proposal. The problem with the rental and sublease approach is that it places the leasee at some risk for the leasor still remains complete control over the resource. As I understand it the RIPE non-permanent transfer allows the two parties to request a transfer of registration details from RIPE for a period of time, at the expiration of which the registration details revert. This allows both parties to enter into such arrangements without placing one in a relatively disadvantaged position with respect to the other. As far as I can see this aspect of the RIPE transfer proposal allows parties to express their own views of this transition structure - some parties may feel that this is a short term arrangement and that IPv6 adoption will gather sufficient momentum to obviate longer term need for for further IPv4 addresses, and while IPv4 networking may be around for a long time, the growth factors of the Internet will be expressed in IPv6 within a short time. Others may be of the view that this will not be the case, and see some advantage in expressing a longer term benefit in hanging on to IPv4 address resources, while not having an immediate need to use them in a network deployment. In other words, if you are of the view that "rental" or other forms of short term use may be an aspect of the industry in the period following Ipv4 unallocated pool exhaustion then perhaps the question could be rephrased as: what forms of policy would allow the RIR registry system to accommodate such arrangements while preserving the accuracy, integrity and common utility of the RIR registry itself? regards, Geoff From jmaimon at chl.com Thu Mar 13 09:09:23 2008 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 13 Mar 2008 09:09:23 -0400 Subject: [ppml] Restrictions on transferor deaggregation in 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <1080312203034.2385B-100000@Ives.egh.com> References: <1080312203034.2385B-100000@Ives.egh.com> Message-ID: <47D92783.20004@chl.com> John Santos wrote: > This doesn't work. You would either need to put your equipment on the > colo's premises (that's what "colo" means") or you would have to install > a circuit between the colo and your own premises. No on is going to > route the colo's network to anywhere but the colo's network. Yes they would and they do. > > Sure, anyone with spare v4 address space could just become an ISP and > lease you "permanent" v4 addresses (permanent for as long as you and > the "ISP" maintain a business relationship and you pay your bill), but > they would have to set up their own network to reach you. Its called tunneling, which a properly designed network would do anyways to catch traffic that goes to parent prefix instead of the "leased" one. From cliffb at cjbsys.bdb.com Thu Mar 13 10:09:34 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Thu, 13 Mar 2008 10:09:34 -0400 (EDT) Subject: [ppml] 2008-2 IPv4 transfer policy Message-ID: <200803131409.m2DE9ZMh005636@cjbsys.bdb.com> After reading lots (and LOTS) of comments on this proposal, it seems to me that a lot of the problems people have with it revolve around ARIN becoming actively involved in the transfer(sale) of v4 addresses. I was concerned about this also and the only analogy I could come up with was comparing it to setting up your sister with a blind date versus pimping her out on 14th St. That's a little extreme but I truly don't think ARIN should actively be involved in the selling. I would propose that ARIN not be actively involved in providing lists of available addresses but only in approving transfers between private parties. If the proposal was modified to allow ARIN to approve transfers between private parties but have nothing to do with the details of the "sale", they would avoid many of the concerns about property. In some ways, it would be like the Motor Vehicle Administration certifying the transfer of an automobile by issuing a new title. They are not involved in any of the details of how the parties met, pricing, financing or anything like that, they just certify the title transfer as valid. (I know, I know automobiles are property but I think the idea is still valid.) People who want addresses will find a way to let the world know they need some and people who have some to sell will have a way to let buyers know they have some available (eBay, Craig's list......) ARIN would still provide the functions of looking at need, determining validity of the transferees right to the numbers being transferred etc. (i.e. like MVA saying the sellor has a valid right to sell). I think this simplifies ARIN's job and keeps them out of the commodities business. Cliff -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From michael.dillon at bt.com Thu Mar 13 11:05:13 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 13 Mar 2008 15:05:13 -0000 Subject: [ppml] 2008-2 IPv4 transfer policy In-Reply-To: <200803131409.m2DE9ZMh005636@cjbsys.bdb.com> References: <200803131409.m2DE9ZMh005636@cjbsys.bdb.com> Message-ID: > I would propose that ARIN not be actively involved in > providing lists of available addresses but only in approving > transfers between private parties. That's basically the system that we have now. One company acquires another and then tells ARIN what happened and asks permission to keep using the IP addresses. ARIN makes the decision along the same lines, more or less, as new allocations. If a company buys an address block on the grey market, and has a real use for it in a real network which they are building, I don't believe ARIN would deny any transfer under current policy. Of course, I'm assuming that the grey market deal is for the right size of block and that they purchaser doesn't tell ARIN until they are within days of going live with their new network (or renumbering from PA space). --Michael Dillon From paul at vix.com Thu Mar 13 13:19:23 2008 From: paul at vix.com (Paul Vixie) Date: Thu, 13 Mar 2008 17:19:23 +0000 Subject: [ppml] ipv6 in the news Message-ID: <72435.1205428763@sa.vix.com> in http://www.betanews.com/article/The_IPv6_experience_Are_you_experienced_yet/1205269666 we see The IPv6 experience: Are you experienced yet? By Tim Conneally, BetaNews March 11, 2008, 5:07 PM Now that ICANN is in the process of upgrading its root servers to handle IPv6 records, somebody has to get the word out to businesses about the benefits of the updated protocol. ... From cliffb at cjbsys.bdb.com Thu Mar 13 13:31:55 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Thu, 13 Mar 2008 13:31:55 -0400 (EDT) Subject: [ppml] 2008-2 IPv4 transfer policy In-Reply-To: from "michael.dillon@bt.com" at Mar 13, 2008 03:05:13 PM Message-ID: <200803131731.m2DHVtdu008013@cjbsys.bdb.com> > > > > I would propose that ARIN not be actively involved in > > providing lists of available addresses but only in approving > > transfers between private parties. > > That's basically the system that we have now. One company acquires > another and then tells ARIN what happened and asks permission to > keep using the IP addresses. ARIN makes the decision along the same > lines, more or less, as new allocations. I'm not saying buy the company to get the addresses, I'm saying buy the right to use the addresses(the non-property thing). I would see this happening in a couple of ways. Company A needs more addresses. They go to ARIN and ARIN says we don't have any but if you can find a legitmate seller, you have demonstrated the need and we'll approve the transfer (no resubmit of justification for n months, n to be decided) Company A needs more addresses. Their network person mentions to Company B's network person that they need some more address space. Company B's network guy says "we've got some we'd like to sell". All the right people from Companies A and B agree and A goes to ARIN and says we need X and Company B has agreed to allow transfer. ARIN reviews and either agrees or disagrees and the deal proceeds from there. ARIN would change its policy to add this method of address acquisition. It would be just another way for addresses to be provided but ARIN would not be involved in the details of the "sale". Again like the DMV issuing a valid title. Cliff > > If a company buys an address block on the grey market, and has a > real use for it in a real network which they are building, > I don't believe ARIN would deny any transfer under current > policy. Of course, I'm assuming that the grey market deal > is for the right size of block and that they purchaser > doesn't tell ARIN until they are within days of going > live with their new network (or renumbering from PA space). > > --Michael Dillon > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From cliffb at cjbsys.bdb.com Thu Mar 13 13:35:22 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Thu, 13 Mar 2008 13:35:22 -0400 (EDT) Subject: [ppml] 2008-2 IPv4 transfer policy In-Reply-To: from "Bill Woodcock" at Mar 13, 2008 06:18:36 AM Message-ID: <200803131735.m2DHZMr7008071@cjbsys.bdb.com> > > > After reading lots (and LOTS) of comments on this proposal, it seems to me > > that a lot of the problems people have with it revolve around ARIN becoming > > actively involved in the transfer(sale) of v4 addresses. > > I would propose that ARIN not be actively involved in providing lists of > > available addresses but only in approving transfers between private parties. > > If the proposal was modified to allow ARIN to approve transfers between > > private parties but have nothing to do with the details of the "sale"... > > Yep, that's my thought exactly, and I suspect a lot of other people agree. > > Any chance of your putting up a policy proposal that says that? Bill I was kind of hoping the 2008-2 could be modified to say this rather than do another policy proposal. If it requires another proposal to get this idea in, then I'm against 2008-2 and will try to get another proposal for the next meeting. (I assume it's to late for this one) Cliff > > -Bill > -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From woody at pch.net Thu Mar 13 15:35:33 2008 From: woody at pch.net (Bill Woodcock) Date: Thu, 13 Mar 2008 11:35:33 -0800 (PST) Subject: [ppml] 2008-2 IPv4 transfer policy In-Reply-To: <200803131735.m2DHZMr7008071@cjbsys.bdb.com> References: <200803131735.m2DHZMr7008071@cjbsys.bdb.com> Message-ID: > I was kind of hoping the 2008-2 could be modified to say this rather than do > another policy proposal. If it requires another proposal to get this idea in, > then I'm against 2008-2 and will try to get another proposal for the next > meeting. (I assume it's to late for this one) Well, I think the AC is looking at a lot of different things, and it's their job to consolidate and reconcile multiple proposals on related topics. But they need input from the community. -Bill From jrhett at svcolo.com Thu Mar 13 15:35:19 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Thu, 13 Mar 2008 12:35:19 -0700 Subject: [ppml] 2008-2 IPv4 transfer policy In-Reply-To: References: <200803131409.m2DE9ZMh005636@cjbsys.bdb.com> Message-ID: <47D981F7.1050502@svcolo.com> michael.dillon at bt.com wrote: > If a company buys an address block on the grey market, and has a > real use for it in a real network which they are building, > I don't believe ARIN would deny any transfer under current > policy. Of course, I'm assuming that the grey market deal Show me the forms for this transfer and registration of the transferred block? AFAIK right now ARIN would only allow the original entity to return the block, and separately allow the new entity to acquire a block of the same size. This proposal covers the ability for the new assignee to be assured of receiving the given block. Direct transfer, not a SWIPE. -- Jo Rhett senior geek Silicon Valley Colocation From arin-contact at dirtside.com Thu Mar 13 16:05:35 2008 From: arin-contact at dirtside.com (William Herrin) Date: Thu, 13 Mar 2008 16:05:35 -0400 Subject: [ppml] 2008-2 IPv4 transfer policy In-Reply-To: <47D981F7.1050502@svcolo.com> References: <200803131409.m2DE9ZMh005636@cjbsys.bdb.com> <47D981F7.1050502@svcolo.com> Message-ID: <3c3e3fca0803131305v237ac034l8495ae809d4919aa@mail.gmail.com> On Thu, Mar 13, 2008 at 3:35 PM, Jo Rhett wrote: > michael.dillon at bt.com wrote: > > If a company buys an address block on the grey market, and has a > > real use for it in a real network which they are building, > > I don't believe ARIN would deny any transfer under current > > policy. Of course, I'm assuming that the grey market deal > > Show me the forms for this transfer and registration of the transferred > block? Jo, You mean http://www.arin.net/registration/templates/transfer.txt ? Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From jrhett at svcolo.com Thu Mar 13 16:21:49 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Thu, 13 Mar 2008 13:21:49 -0700 Subject: [ppml] 2008-2 IPv4 transfer policy In-Reply-To: <3c3e3fca0803131305v237ac034l8495ae809d4919aa@mail.gmail.com> References: <200803131409.m2DE9ZMh005636@cjbsys.bdb.com> <47D981F7.1050502@svcolo.com> <3c3e3fca0803131305v237ac034l8495ae809d4919aa@mail.gmail.com> Message-ID: <47D98CDD.2080907@svcolo.com> William Herrin wrote: > On Thu, Mar 13, 2008 at 3:35 PM, Jo Rhett wrote: >> michael.dillon at bt.com wrote: >> > If a company buys an address block on the grey market, and has a >> > real use for it in a real network which they are building, >> > I don't believe ARIN would deny any transfer under current >> > policy. Of course, I'm assuming that the grey market deal >> >> Show me the forms for this transfer and registration of the transferred >> block? > > You mean http://www.arin.net/registration/templates/transfer.txt ? Section 8.2 of the NRPM covers the only reason that ARIN will allow transfers, and it does not allow this. Why is why it is being discussed. -- Jo Rhett senior geek Silicon Valley Colocation From arin-contact at dirtside.com Thu Mar 13 17:20:03 2008 From: arin-contact at dirtside.com (William Herrin) Date: Thu, 13 Mar 2008 17:20:03 -0400 Subject: [ppml] 2008-2 IPv4 transfer policy In-Reply-To: <47D98CDD.2080907@svcolo.com> References: <200803131409.m2DE9ZMh005636@cjbsys.bdb.com> <47D981F7.1050502@svcolo.com> <3c3e3fca0803131305v237ac034l8495ae809d4919aa@mail.gmail.com> <47D98CDD.2080907@svcolo.com> Message-ID: <3c3e3fca0803131420m1f05f35dk4892c40b19bdb77b@mail.gmail.com> On Thu, Mar 13, 2008 at 4:21 PM, Jo Rhett wrote: > William Herrin wrote: > > On Thu, Mar 13, 2008 at 3:35 PM, Jo Rhett wrote: > >> Show me the forms for this transfer and registration of the transferred > >> block? > > > You mean http://www.arin.net/registration/templates/transfer.txt ? > > Section 8.2 of the NRPM covers the only reason that ARIN will allow > transfers, and it does not allow this. Sure it does Jo. You might have to "partner" with the existing registrant for a few months while you build the system (their contribution being the IP address space and the cheering squad) before you could then justify a transfer under 8.2. In what practical way does that hinder the gray-market transfer of the block? Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From jrhett at svcolo.com Thu Mar 13 17:24:40 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Thu, 13 Mar 2008 14:24:40 -0700 Subject: [ppml] 2008-2 IPv4 transfer policy In-Reply-To: <3c3e3fca0803131420m1f05f35dk4892c40b19bdb77b@mail.gmail.com> References: <200803131409.m2DE9ZMh005636@cjbsys.bdb.com> <47D981F7.1050502@svcolo.com> <3c3e3fca0803131305v237ac034l8495ae809d4919aa@mail.gmail.com> <47D98CDD.2080907@svcolo.com> <3c3e3fca0803131420m1f05f35dk4892c40b19bdb77b@mail.gmail.com> Message-ID: <47D99B98.5000705@svcolo.com> William Herrin wrote: > Sure it does Jo. You might have to "partner" with the existing > registrant for a few months while you build the system (their > contribution being the IP address space and the cheering squad) before > you could then justify a transfer under 8.2. In what practical way > does that hinder the gray-market transfer of the block? Look, this topic has been cleared defined by ARIN numerous times, I'm not going to waste my time with more of your "how much can I deliberately misread the existing documentation" nonsense. You should try getting a real job, working in the industry. Maybe then you'll have less time to imagine all sorts of nonsense for things which are very clearly spelled out. -- Jo Rhett senior geek Silicon Valley Colocation From michael.dillon at bt.com Fri Mar 14 08:44:26 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 14 Mar 2008 12:44:26 -0000 Subject: [ppml] 2008-2 IPv4 transfer policy In-Reply-To: <47D99B98.5000705@svcolo.com> References: <200803131409.m2DE9ZMh005636@cjbsys.bdb.com> <47D981F7.1050502@svcolo.com> <3c3e3fca0803131305v237ac034l8495ae809d4919aa@mail.gmail.com> <47D98CDD.2080907@svcolo.com><3c3e3fca0803131420m1f05f35dk4892c40b19bdb77b@mail.gmail.com> <47D99B98.5000705@svcolo.com> Message-ID: > > Sure it does Jo. You might have to "partner" with the existing > > registrant for a few months while you build the system (their > > contribution being the IP address space and the cheering > squad) before > > you could then justify a transfer under 8.2. In what practical way > > does that hinder the gray-market transfer of the block? > > Look, this topic has been cleared defined by ARIN numerous > times, I'm not going to waste my time with more of your "how > much can I deliberately misread the existing documentation" nonsense. I think this discussion illustrates how policymaking is different from network design and operations. In the technology world, you either do things correctly, according to the documentation, or it just doesn't work. Black or white. In the world of policymaking, there is no black and white. Everything is various shades of grey, so a grey market sale of IP addresses will work, even though it goes against the documentation. Sometimes you need to add a white lie or two to make it the right shade of grey, but that is exactly how people operate. And policy is all about people and processes, not really about technology at all. Which implies that if you want to make successful policies, you shouldn't strive for black and white solutions, because you will just end up introducing loopholes that could make your policy entirely ineffective. Accept that policy has some grey areas, and work like an artist, to blend various shades of grey into a multichromatic work of art. --Michael Dillon From cliffb at cjbsys.bdb.com Fri Mar 14 09:20:30 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Fri, 14 Mar 2008 09:20:30 -0400 Subject: [ppml] 2008-2 IPv4 transfer policy In-Reply-To: <47D9782C.3020707@internap.com> References: <200803131735.m2DHZMr7008071@cjbsys.bdb.com> <47D9782C.3020707@internap.com> Message-ID: <47DA7B9E.1070802@cjbsys.bdb.com> Scott Leibrand wrote: > Cliff, > > Would 2008-2 do what you want if the "ARIN will create a listing > service" and related text were removed? > > -Scott Scott Not without additional changes. I'll list them below Delete the following from 8.3.1 ? The transferor has not received any IPv4 allocations or assignments from ARIN (through ordinary allocations or assignments, or through this Simple Transfer policy) within the preceding 24 months. ? The transferor may not request any IPv4 allocations or assignments from ARIN (through ordinary allocations or assignments, or through this Simple Transfer policy) within the subsequent 24 months. Rationale At the time these changes would be valid, things will likely be changing rapidly and businesses will need flexibility to meet business requirements without being hamstrung by unneeded regulation by ARIN Delete the following from 8.3.2 ? The transferee has not provided any IPv4 addresses for transfer through this Simple Transfer process within the preceding 24 months. ? The transferee may not provide any IPv4 addresses for transfer through this Simple Transfer process within the subsequent 24 months, except in the case of business failure. ? The transferee may request and receive a contiguous CIDR block large enough to provide a 12 month supply of IPv4 addresses. ? The transferee may only receive one IPv4 address transfer through this Simple Transfer process every 6 months. Rationale Same s for 8.3.1 above. I guess I think the market and business requirements should dictate requirements. I think that ARIN could use a fee structure to slow down excessive transfers. 8.3.5 Change the words "must seek" to "may seek" pre-qualification. or delete the section entirely. Rationale. It shouldn't matter to ARIN if the requests are pre-qualified or not since ARIN would not be involved in anything regarding finding addresses for sale or wanted. The same amount of work will be involved in either case. 8.3.8 It seems like this should be covered by existing policy or it seems to be expanding ARIN's role in a company's business operations. Again this may not be a good idea considering this is at a time when companies need to be more nimble in their ability to use IPv4. 8.3.9 Obviously delete this section. The requirements of the second and third paragraphs should be covered by existing policy/procedures. After all the discussions on this, I guess my opinion is that it's better to have ARIN retain loose control and at least keep track of what changes are being made rather than have tight controls that will be ignored which will cause greater chaos as IPv4 winds down. Hope this makes sense to people. Cliff > > Cliff Bedore wrote: >>> > After reading lots (and LOTS) of comments on this proposal, it >>> seems to me >>> > that a lot of the problems people have with it revolve around ARIN >>> becoming >>> > actively involved in the transfer(sale) of v4 addresses. > I would >>> propose that ARIN not be actively involved in providing lists of >>> > available addresses but only in approving transfers between >>> private parties. > If the proposal was modified to allow ARIN to >>> approve transfers between >>> > private parties but have nothing to do with the details of the >>> "sale"... >>> >>> Yep, that's my thought exactly, and I suspect a lot of other people >>> agree. >>> >>> Any chance of your putting up a policy proposal that says that? >> >> Bill >> >> I was kind of hoping the 2008-2 could be modified to say this rather >> than do >> another policy proposal. If it requires another proposal to get this >> idea in, >> then I'm against 2008-2 and will try to get another proposal for the >> next >> meeting. (I assume it's to late for this one) >> >> Cliff >>> -Bill >>> >> >> > From tvest at pch.net Sun Mar 16 16:07:31 2008 From: tvest at pch.net (Tom Vest) Date: Sun, 16 Mar 2008 16:07:31 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <47D06585.2020402@apnic.net> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D06585.2020402@apnic.net> Message-ID: Looking over the various threads on 2008-2 over the last couple of weeks, it seems that many people are counting on price signals to accomplish a variety of different things, e.g., incentivize IPv4 surplus address space holders to offer their surplus for sale, incentivize other IPv4 holders to create surplus (e.g., by migrating some requirements to NAT or IPv6), encourage at least some nonzero supply of IPv4 prefixes of various sizes, encourage aggregation, etc. As far as I can tell, nothing currently in 2008-02 supports any persuasive argument about how any of these price signals will achieve any the stated goals. It may be that Section 8.3.9 permits such details to be worked out in the course of the policy's "implementation", but I think they're far too important to set aside until then... A brief and incomplete survey of pricing beliefs/doubts follows: On Mar 6, 2008, at 4:43 PM, Geoff Huston wrote: > We all share a common view that post unallocated pool exhaustion > there will be aa period where demand outstrips supply and in a > market situation the price of IPv4 escalates, while the price of > IPv6 remains relative constant and relatively insignificant. > Ultimately consumers are exposed to the price differential as is > conventional when prices of supply shift, and it is reasonable to > anticipate that most consumders would express a preference for a > lower priced service. > > Perhaps the objective here is NOT "to try and construct a perfect > Ipv4 market". Perhaps it is more along the lines of "to try and > expose some basic economic signals about the relative scarcity of > Ipv4 and Ipv6 addresses to provide more direct and focussed impetus > for industry-wide IPv6 adoption" Hi Geoff, That's a very reasonable argument, but sometimes even the best argument can be undermined by its context. Today many of us operate in a competitive, "relatively low margin commodity" market (a paraphrase of your own description from another message). However, it's fair to say that not every operator agrees with that description, much less embraces it as inevitable or appropriate. In the places where the industry actually does fit that description, it only arrived at that state fairly recently, and (for many operators) quite reluctantly, and (for all but a handful of the world's largest networks) very gradually, as price signals revealing the actual state of supply in the marketplace slowly trickled out beyond the veil of NDAs and strategic vendor relationships. Even today, there are many passionate market advocates that reject this outcome as illegitimate, precisely because it was precipitated by regulatory interventions that either restricted or compelled some commercial behavior by incumbents. However, you never hear them criticize this development because it undercut monopoly rent seeking -- instead the critics suggest that by forcing the incumbents to make network inputs available for less than monopoly-maximum-$, such rules obscured "basic economic signals" and undermined incentives for non-incumbents to invest in constructing their own vertically integrated end-to-end platforms. By implication, they suggested that incumbents that withheld critical bottleneck inputs, or sold them only at absurd prices, were actually doing a noble and highly principled thing; they were promoting investment, and a transition to a more sustainable market! Now, no doubt there are some staunch libertarians that would make that argument "on principle" regardless of any relevant personal stakes that might be advanced or harmed as a result. But when the incumbents themselves and/or their agents are making the argument, non-incumbents and the general public tend to be a little more skeptical -- and rightly so. I am concerned that the market-based IPv4 transfer proposals are heading down a very similar path, and that the results are also likely to be similar -- and not much to anyone's liking. We do have a real supply challenge to overcome in the near term, and I concede that market-based mechanisms may be a good way to meet that challenge. But given the lessons of the past, I think that any market mechanisms adopted this time should require full transparency from all parties involved, e.g., public disclosure of non-anonymized identities of buyers and sellers, actual prefix exchanged, price paid, etc. Without transparency, there can be no "market price", at least not for the first 4-5 years -- e.g., until enough address traders have whispered enough stories to each other at some *OG, perhaps enabling someone to write a white paper about it ;-). Without transparency, it will never be possible to know or demonstrate how the costs and the benefits of this major policy turn have been distributed. With transparency, however, these "facts" will remain accessible to the whole community, thereby permitting the address transfer policies to be sensibly adjusted later as necessary, and preserving the "lessons" that come out of this experience for future policy deliberations. On Mar 10, 2008, at 5:34 AM, bmanning at vacation.karoshi.com wrote: > it could be, leo, that for the right price, there might be a > "steady flow" of prefixes. at least this is what i think > Geoff and David have argued. How will the community know if there is a steady flow, or if the price is "right"? If prices *and* involved parties are not completely transparent (and the transaction costs are not a large share of the sales prices), it will be trivially easy for anyone with IPv4 to pollute any partial/anonymized market information, making it less than useless. On Mar 10, 2008, at 6:28 PM, Scott Leibrand wrote: > My own amateur-economist take on it is that, initially, supply (of > currently unrouted space) will exceed demand, so price will stay low, > and the quantity demanded (your "churn rate") will be only slightly > lower than it is today (with price ~= 0). Price will then start to > rise > as the easy supply is put into production, bringing new, more > expensive > supply online, and reducing demand. If there is transparency in the marketplace, then all of these things may happen -- in any case you'll be able to know whether they did or not. Without transparency no one will ever know. On Mar 6, 2008, at 1:43 AM, Geoff Huston wrote: > ...Others may be of the view that one of the major elements in an IPv6 > transition is the incentive to stop deploying IPv4 and that may > well be > based in an escalating value of IPv4 addresses, which would > increasingly > provide economic incentives for entities to deploy IPv6 as their > mainstream technology base with minimal IPv4 translation services. That may be true, but as noted above, historical (and current) precedent doesn't provide much confidence. At one time many people made the same argument about international telecom settlement flows; just send us more, some countries said, and we'll use it to bankroll our own network rollout, and thereby gradually offset the settlement imbalances over time. Needless to say, no one ever found any evidence that this actually worked -- usually it worked the other way round. Some incumbent access facilities owners make the exact same argument today (and every day since 1984): just permit us to charge end uses more, or charge other indirect beneficiaries lots more, or change our pricing model with the same overall effect, and we'll deliver the latest/fastest/most advanced platform ever. Needless to say, in places where they had their way no one has ever found any evidence that this actually works, much less works better than current/viable alternatives. Bottom line: revenue is revenue; just because an incumbent operator makes additional revenue from IPv4 sales does not mean that that marginal addition to the bottom line will be used to fund IPv6 transition. In fact, if incumbent IPv4 address holders stand to earn lots of revenue from IPv4 holdings in an IPv4 & IPv6 scarce environment, it's not clear to me that (or when) the incentives to capitalize on that arrangement are surpassed by the incentives to do their part to make IPv6 ubiquitous. Out of curiosity, would you support making that linkage between IPv4 revenues and IPv6 investment an explicit requirement in APNIC's proposal? On Mar 6, 2008, at 1:43 AM, Geoff Huston wrote: > ...The diversity of views abot scenarios and timings will drive > different > behaviours - some entities may act on the view that once the shock of > exhaustion wears off and the related market price has factored in > scarcity premiums as well as the initial shock, the drive to IPv6 will > assume a new level of momentum, and the IPv4 demand will drop, and > with > declining demand so will market prices - i.e. some folk would see no > value in hoarding and believe that maximal value will be seen in the > initial operation of short term market that will be overtaken by IPv6 > relatively quickly. Other entities may be of the view that the inertia > of this industry is sufficiently large, and the capability of dense > NAT > deployments sufficiently tenable that an IPv4 market may be used for a > long period. If this is accompanied by a view that demand will > continue > to outpace supply then an escalating price is an obvious outcome. These are reasonable and useful speculations -- no doubt we could hypothesize a wide variety of stakeholder views, and maybe even model the weighted results of their behavior on average prices, collateral growth of NAT, IPv6 substitution, etc. Maybe we could then bootstrap that model, and tweak the parameters, and see how different kinds of market arrangements lead to different kinds of outcomes. If we actually had a model like that, then maybe some community members would be more persuaded that markets would, under some set of arrangements, be quite likely to lead to a particular outcome (e.g., IPv6/industry growth and diversity) and not to others (e.g., perma- NAT/industry consolidation). Unfortunately we don't have a model like that, and we're only going to have one opportunity to try this out in reality once. If we engineer transparency into the transfers mechanisms, however, maybe the resulting real-time window onto how things are really working will be good enough... On Mar 6, 2008, at 1:43 AM, Geoff Huston wrote: > And its not as if such forms of market outcomes spell > doom and disaster of an out of control stampede. This is not quite the > wild days of 2000 and the GSM auction debacle appears to have hosed > down > some of the more insane players in this industry. This is a relatively > low margin commodity business down at the plumbing side and it may > well > be that market pricing may well be influenced by the limited > amounts of > capital that are within the industry these days. Ahh, right back where we started ;-) TV From sleibrand at internap.com Sun Mar 16 17:04:23 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Sun, 16 Mar 2008 14:04:23 -0700 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D06585.2020402@apnic.net> Message-ID: <47DD8B57.6090205@internap.com> Tom, To summarize, you are suggesting that we need to have ARIN collect and publish price information on each IPv4 transfer transaction, correct? Currently 8.3.9 reads, in part, "ARIN will also publish a log of all transfers, including block, transferor, transferee, and date", and you want to add "price paid" to that list, right? Do you have any suggestions as to whether/how ARIN should concern itself whether the price reported by the transferor and transferee is accurate? An assumption we made in the proposal was that transparency would be achievable through the ARIN-operated listing service: both transferees and transferors would choose to list there, and would provide a listing/offered price on each entry. This would provide ARIN and the public information as to the prices people are willing to pay/accept, and one could assume that most transactions would occur between those two prices (i.e. that most people wouldn't pass up a better deal). Can you clarify how you'd propose to enforce transparency, and what impact you think such enforcement would have? Thanks for your input, Scott Tom Vest wrote: > Looking over the various threads on 2008-2 over the last couple of > weeks, it seems that many people are counting on price signals to > accomplish a variety of different things, e.g., incentivize IPv4 > surplus address space holders to offer their surplus for sale, > incentivize other IPv4 holders to create surplus (e.g., by migrating > some requirements to NAT or IPv6), encourage at least some nonzero > supply of IPv4 prefixes of various sizes, encourage aggregation, etc. > > As far as I can tell, nothing currently in 2008-02 supports any > persuasive argument about how any of these price signals will achieve > any the stated goals. It may be that Section 8.3.9 permits such > details to be worked out in the course of the policy's > "implementation", but I think they're far too important to set aside > until then... > > A brief and incomplete survey of pricing beliefs/doubts follows: > > On Mar 6, 2008, at 4:43 PM, Geoff Huston wrote: > >> We all share a common view that post unallocated pool exhaustion >> there will be aa period where demand outstrips supply and in a >> market situation the price of IPv4 escalates, while the price of >> IPv6 remains relative constant and relatively insignificant. >> Ultimately consumers are exposed to the price differential as is >> conventional when prices of supply shift, and it is reasonable to >> anticipate that most consumders would express a preference for a >> lower priced service. >> >> Perhaps the objective here is NOT "to try and construct a perfect >> Ipv4 market". Perhaps it is more along the lines of "to try and >> expose some basic economic signals about the relative scarcity of >> Ipv4 and Ipv6 addresses to provide more direct and focussed impetus >> for industry-wide IPv6 adoption" > > Hi Geoff, > > That's a very reasonable argument, but sometimes even the best > argument can be undermined by its context. Today many of us operate > in a competitive, "relatively low margin commodity" market (a > paraphrase of your own description from another message). However, > it's fair to say that not every operator agrees with that > description, much less embraces it as inevitable or appropriate. In > the places where the industry actually does fit that description, it > only arrived at that state fairly recently, and (for many operators) > quite reluctantly, and (for all but a handful of the world's largest > networks) very gradually, as price signals revealing the actual state > of supply in the marketplace slowly trickled out beyond the veil of > NDAs and strategic vendor relationships. Even today, there are many > passionate market advocates that reject this outcome as illegitimate, > precisely because it was precipitated by regulatory interventions > that either restricted or compelled some commercial behavior by > incumbents. However, you never hear them criticize this development > because it undercut monopoly rent seeking -- instead the critics > suggest that by forcing the incumbents to make network inputs > available for less than monopoly-maximum-$, such rules obscured > "basic economic signals" and undermined incentives for non-incumbents > to invest in constructing their own vertically integrated end-to-end > platforms. By implication, they suggested that incumbents that > withheld critical bottleneck inputs, or sold them only at absurd > prices, were actually doing a noble and highly principled thing; they > were promoting investment, and a transition to a more sustainable > market! > > Now, no doubt there are some staunch libertarians that would make > that argument "on principle" regardless of any relevant personal > stakes that might be advanced or harmed as a result. But when the > incumbents themselves and/or their agents are making the argument, > non-incumbents and the general public tend to be a little more > skeptical -- and rightly so. > > I am concerned that the market-based IPv4 transfer proposals are > heading down a very similar path, and that the results are also > likely to be similar -- and not much to anyone's liking. We do have a > real supply challenge to overcome in the near term, and I concede > that market-based mechanisms may be a good way to meet that > challenge. But given the lessons of the past, I think that any market > mechanisms adopted this time should require full transparency from > all parties involved, e.g., public disclosure of non-anonymized > identities of buyers and sellers, actual prefix exchanged, price > paid, etc. Without transparency, there can be no "market price", at > least not for the first 4-5 years -- e.g., until enough address > traders have whispered enough stories to each other at some *OG, > perhaps enabling someone to write a white paper about it ;-). Without > transparency, it will never be possible to know or demonstrate how > the costs and the benefits of this major policy turn have been > distributed. With transparency, however, these "facts" will remain > accessible to the whole community, thereby permitting the address > transfer policies to be sensibly adjusted later as necessary, and > preserving the "lessons" that come out of this experience for future > policy deliberations. > > > On Mar 10, 2008, at 5:34 AM, bmanning at vacation.karoshi.com wrote: > >> it could be, leo, that for the right price, there might be a >> "steady flow" of prefixes. at least this is what i think >> Geoff and David have argued. > > > How will the community know if there is a steady flow, or if the > price is "right"? If prices *and* involved parties are not completely > transparent (and the transaction costs are not a large share of the > sales prices), it will be trivially easy for anyone with IPv4 to > pollute any partial/anonymized market information, making it less > than useless. > > On Mar 10, 2008, at 6:28 PM, Scott Leibrand wrote: > >> My own amateur-economist take on it is that, initially, supply (of >> currently unrouted space) will exceed demand, so price will stay low, >> and the quantity demanded (your "churn rate") will be only slightly >> lower than it is today (with price ~= 0). Price will then start to >> rise >> as the easy supply is put into production, bringing new, more >> expensive >> supply online, and reducing demand. > > > If there is transparency in the marketplace, then all of these things > may happen -- in any case you'll be able to know whether they did or > not. Without transparency no one will ever know. > > > On Mar 6, 2008, at 1:43 AM, Geoff Huston wrote: > >> ...Others may be of the view that one of the major elements in an IPv6 >> transition is the incentive to stop deploying IPv4 and that may >> well be >> based in an escalating value of IPv4 addresses, which would >> increasingly >> provide economic incentives for entities to deploy IPv6 as their >> mainstream technology base with minimal IPv4 translation services. > > > That may be true, but as noted above, historical (and current) > precedent doesn't provide much confidence. At one time many people > made the same argument about international telecom settlement flows; > just send us more, some countries said, and we'll use it to bankroll > our own network rollout, and thereby gradually offset the settlement > imbalances over time. Needless to say, no one ever found any evidence > that this actually worked -- usually it worked the other way round. > Some incumbent access facilities owners make the exact same argument > today (and every day since 1984): just permit us to charge end uses > more, or charge other indirect beneficiaries lots more, or change our > pricing model with the same overall effect, and we'll deliver the > latest/fastest/most advanced platform ever. Needless to say, in > places where they had their way no one has ever found any evidence > that this actually works, much less works better than current/viable > alternatives. > > Bottom line: revenue is revenue; just because an incumbent operator > makes additional revenue from IPv4 sales does not mean that that > marginal addition to the bottom line will be used to fund IPv6 > transition. In fact, if incumbent IPv4 address holders stand to earn > lots of revenue from IPv4 holdings in an IPv4 & IPv6 scarce > environment, it's not clear to me that (or when) the incentives to > capitalize on that arrangement are surpassed by the incentives to do > their part to make IPv6 ubiquitous. > > Out of curiosity, would you support making that linkage between IPv4 > revenues and IPv6 investment an explicit requirement in APNIC's > proposal? > > On Mar 6, 2008, at 1:43 AM, Geoff Huston wrote: > >> ...The diversity of views abot scenarios and timings will drive >> different >> behaviours - some entities may act on the view that once the shock of >> exhaustion wears off and the related market price has factored in >> scarcity premiums as well as the initial shock, the drive to IPv6 will >> assume a new level of momentum, and the IPv4 demand will drop, and >> with >> declining demand so will market prices - i.e. some folk would see no >> value in hoarding and believe that maximal value will be seen in the >> initial operation of short term market that will be overtaken by IPv6 >> relatively quickly. Other entities may be of the view that the inertia >> of this industry is sufficiently large, and the capability of dense >> NAT >> deployments sufficiently tenable that an IPv4 market may be used for a >> long period. If this is accompanied by a view that demand will >> continue >> to outpace supply then an escalating price is an obvious outcome. > > These are reasonable and useful speculations -- no doubt we could > hypothesize a wide variety of stakeholder views, and maybe even model > the weighted results of their behavior on average prices, collateral > growth of NAT, IPv6 substitution, etc. Maybe we could then bootstrap > that model, and tweak the parameters, and see how different kinds of > market arrangements lead to different kinds of outcomes. If we > actually had a model like that, then maybe some community members > would be more persuaded that markets would, under some set of > arrangements, be quite likely to lead to a particular outcome (e.g., > IPv6/industry growth and diversity) and not to others (e.g., perma- > NAT/industry consolidation). > > Unfortunately we don't have a model like that, and we're only going > to have one opportunity to try this out in reality once. If we > engineer transparency into the transfers mechanisms, however, maybe > the resulting real-time window onto how things are really working > will be good enough... > > On Mar 6, 2008, at 1:43 AM, Geoff Huston wrote: > >> And its not as if such forms of market outcomes spell >> doom and disaster of an out of control stampede. This is not quite the >> wild days of 2000 and the GSM auction debacle appears to have hosed >> down >> some of the more insane players in this industry. This is a relatively >> low margin commodity business down at the plumbing side and it may >> well >> be that market pricing may well be influenced by the limited >> amounts of >> capital that are within the industry these days. > > > Ahh, right back where we started ;-) > > TV > > _______________________________________________ > 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 tvest at pch.net Mon Mar 17 01:53:56 2008 From: tvest at pch.net (Tom Vest) Date: Mon, 17 Mar 2008 01:53:56 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <47DD8B57.6090205@internap.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D06585.2020402@apnic.net> <47DD8B57.6090205@internap.com> Message-ID: <9DC9F13A-CECE-43FB-B786-B35371F41339@pch.net> On Mar 16, 2008, at 5:04 PM, Scott Leibrand wrote: > Tom, > > To summarize, you are suggesting that we need to have ARIN collect > and publish price information on each IPv4 transfer transaction, > correct? Currently 8.3.9 reads, in part, "ARIN will also publish a > log of all transfers, including block, transferor, transferee, and > date", and you want to add "price paid" to that list, right? Do > you have any suggestions as to whether/how ARIN should concern > itself whether the price reported by the transferor and transferee > is accurate? > > An assumption we made in the proposal was that transparency would > be achievable through the ARIN-operated listing service: both > transferees and transferors would choose to list there, and would > provide a listing/offered price on each entry. This would provide > ARIN and the public information as to the prices people are willing > to pay/accept, and one could assume that most transactions would > occur between those two prices (i.e. that most people wouldn't pass > up a better deal). > > Can you clarify how you'd propose to enforce transparency, and what > impact you think such enforcement would have? > > Thanks for your input, > Scott Hi Scott, Thanks -- that's the right question to focus on, I think: how to enforce transparency, and what impact enforcement (and/or non- enforceability) would have. However, I think my suggested addition, pricing information, shares fate with the all of the other facts to be reported under the existing text of 8.3.9. How should ARIN concern itself with accuracy on any of those points, or with adherence to 2008-02 at all, as opposed to executing number resource transfers on a purely ad hoc, bilaterally defined, and completely opaque/ unreported basis? I think when last we broached this subject, you suggested that adherence would be automatic/self-reinforcing, because following the prescribed mechanism would provide buyers with better, more valuable (because more assured) address resources, and the concentration of buyers willing to pay higher prices would bring sellers into compliance with the policy-defined framework also. In order for that natural attraction dynamic to work, won't prospective sellers need to know what prices are being taken by policy-compliant buyers (e.g., as opposed to black market trawlers)? Conversely, even if the assurance of RIR-approved resources is a strong enough attractor to deter buyers for trawling the black market, won't aspiring buyers want to know what prices were considered "customary and reasonable" by previous buyers? In short, I think the addition of pricing information to the list won't encumber or otherwise affect current compliance/enforcement assumptions at all. If these assumptions do hold, and transparency of pricing information can be preserved as well, then I think the market has a much greater chance of be sustainable for however long it's needed -- i.e., fewer buyers will be, or believe that they were cheated; deceptive "show transactions" will be discouraged, if not eliminated; and any changes in supply, demand, and/or price trends that may be indicative of weaknesses in the transfer mechanism will remain visible to all and thus, hopefully, subject to correction down the line. If, however, current assumptions about incentives to comply do not hold, or are not strong enough to support the addition of pricing information, then I think that that says something significant about the viability of decentralized resource transfers in general. To date, automatic (i.e., uncoerced if not purely voluntary) compliance with any/all policies has been an artifact of a unitary resource distribution mechanism -- the most recent version of which is the RIR system. That kind of mechanism has a proven track record in maintaining a "good enough" central registry of address resource transactions, dates, and recipients, while sustaining transparency on questions of pricing, supply, etc. At present I cannot think of any decentralized mechanism that is likely to deliver any of these things sustainably over any length of time, without substantial (i.e., unrealistic) out-of-band enforcement costs. If there were some way to leverage that unitary distribution model to execute the same kind of incentive-driven redistribution envisioned by 2008-02 and its counterparts, then perhaps we could satisfy the transitional supply requirement without sacrificing transparency or any of the information exchanges that help to keep the central registry (at least) "good enough". But that means more/continued, not less, community-driven collective action -- so the impact depends entirely on the perceptions of the members of the community. What does the rest of the community think? TV > Tom Vest wrote: >> Looking over the various threads on 2008-2 over the last couple >> of weeks, it seems that many people are counting on price signals >> to accomplish a variety of different things, e.g., incentivize >> IPv4 surplus address space holders to offer their surplus for >> sale, incentivize other IPv4 holders to create surplus (e.g., by >> migrating some requirements to NAT or IPv6), encourage at least >> some nonzero supply of IPv4 prefixes of various sizes, encourage >> aggregation, etc. >> As far as I can tell, nothing currently in 2008-02 supports any >> persuasive argument about how any of these price signals will >> achieve any the stated goals. It may be that Section 8.3.9 >> permits such details to be worked out in the course of the >> policy's "implementation", but I think they're far too important >> to set aside until then... >> A brief and incomplete survey of pricing beliefs/doubts follows: >> On Mar 6, 2008, at 4:43 PM, Geoff Huston wrote: >>> We all share a common view that post unallocated pool exhaustion >>> there will be aa period where demand outstrips supply and in a >>> market situation the price of IPv4 escalates, while the price of >>> IPv6 remains relative constant and relatively insignificant. >>> Ultimately consumers are exposed to the price differential as is >>> conventional when prices of supply shift, and it is reasonable >>> to anticipate that most consumders would express a preference >>> for a lower priced service. >>> >>> Perhaps the objective here is NOT "to try and construct a >>> perfect Ipv4 market". Perhaps it is more along the lines of "to >>> try and expose some basic economic signals about the relative >>> scarcity of Ipv4 and Ipv6 addresses to provide more direct and >>> focussed impetus for industry-wide IPv6 adoption" >> Hi Geoff, >> That's a very reasonable argument, but sometimes even the best >> argument can be undermined by its context. Today many of us >> operate in a competitive, "relatively low margin commodity" >> market (a paraphrase of your own description from another >> message). However, it's fair to say that not every operator >> agrees with that description, much less embraces it as inevitable >> or appropriate. In the places where the industry actually does >> fit that description, it only arrived at that state fairly >> recently, and (for many operators) quite reluctantly, and (for >> all but a handful of the world's largest networks) very >> gradually, as price signals revealing the actual state of supply >> in the marketplace slowly trickled out beyond the veil of NDAs >> and strategic vendor relationships. Even today, there are many >> passionate market advocates that reject this outcome as >> illegitimate, precisely because it was precipitated by regulatory >> interventions that either restricted or compelled some >> commercial behavior by incumbents. However, you never hear them >> criticize this development because it undercut monopoly rent >> seeking -- instead the critics suggest that by forcing the >> incumbents to make network inputs available for less than >> monopoly-maximum-$, such rules obscured "basic economic signals" >> and undermined incentives for non-incumbents to invest in >> constructing their own vertically integrated end-to-end >> platforms. By implication, they suggested that incumbents that >> withheld critical bottleneck inputs, or sold them only at absurd >> prices, were actually doing a noble and highly principled thing; >> they were promoting investment, and a transition to a more >> sustainable market! >> Now, no doubt there are some staunch libertarians that would make >> that argument "on principle" regardless of any relevant personal >> stakes that might be advanced or harmed as a result. But when the >> incumbents themselves and/or their agents are making the >> argument, non-incumbents and the general public tend to be a >> little more skeptical -- and rightly so. >> I am concerned that the market-based IPv4 transfer proposals are >> heading down a very similar path, and that the results are also >> likely to be similar -- and not much to anyone's liking. We do >> have a real supply challenge to overcome in the near term, and I >> concede that market-based mechanisms may be a good way to meet >> that challenge. But given the lessons of the past, I think that >> any market mechanisms adopted this time should require full >> transparency from all parties involved, e.g., public disclosure >> of non-anonymized identities of buyers and sellers, actual prefix >> exchanged, price paid, etc. Without transparency, there can be no >> "market price", at least not for the first 4-5 years -- e.g., >> until enough address traders have whispered enough stories to >> each other at some *OG, perhaps enabling someone to write a white >> paper about it ;-). Without transparency, it will never be >> possible to know or demonstrate how the costs and the benefits of >> this major policy turn have been distributed. With transparency, >> however, these "facts" will remain accessible to the whole >> community, thereby permitting the address transfer policies to be >> sensibly adjusted later as necessary, and preserving the >> "lessons" that come out of this experience for future policy >> deliberations. >> On Mar 10, 2008, at 5:34 AM, bmanning at vacation.karoshi.com wrote: >>> it could be, leo, that for the right price, there might be a >>> "steady flow" of prefixes. at least this is what i think >>> Geoff and David have argued. >> How will the community know if there is a steady flow, or if the >> price is "right"? If prices *and* involved parties are not >> completely transparent (and the transaction costs are not a large >> share of the sales prices), it will be trivially easy for anyone >> with IPv4 to pollute any partial/anonymized market information, >> making it less than useless. >> On Mar 10, 2008, at 6:28 PM, Scott Leibrand wrote: >>> My own amateur-economist take on it is that, initially, supply (of >>> currently unrouted space) will exceed demand, so price will stay >>> low, >>> and the quantity demanded (your "churn rate") will be only slightly >>> lower than it is today (with price ~= 0). Price will then start >>> to rise >>> as the easy supply is put into production, bringing new, more >>> expensive >>> supply online, and reducing demand. >> If there is transparency in the marketplace, then all of these >> things may happen -- in any case you'll be able to know whether >> they did or not. Without transparency no one will ever know. >> On Mar 6, 2008, at 1:43 AM, Geoff Huston wrote: >>> ...Others may be of the view that one of the major elements in an >>> IPv6 >>> transition is the incentive to stop deploying IPv4 and that may >>> well be >>> based in an escalating value of IPv4 addresses, which would >>> increasingly >>> provide economic incentives for entities to deploy IPv6 as their >>> mainstream technology base with minimal IPv4 translation services. >> That may be true, but as noted above, historical (and current) >> precedent doesn't provide much confidence. At one time many >> people made the same argument about international telecom >> settlement flows; just send us more, some countries said, and >> we'll use it to bankroll our own network rollout, and thereby >> gradually offset the settlement imbalances over time. Needless to >> say, no one ever found any evidence that this actually worked -- >> usually it worked the other way round. Some incumbent access >> facilities owners make the exact same argument today (and every >> day since 1984): just permit us to charge end uses more, or >> charge other indirect beneficiaries lots more, or change our >> pricing model with the same overall effect, and we'll deliver the >> latest/fastest/most advanced platform ever. Needless to say, in >> places where they had their way no one has ever found any >> evidence that this actually works, much less works better than >> current/viable alternatives. >> Bottom line: revenue is revenue; just because an incumbent >> operator makes additional revenue from IPv4 sales does not mean >> that that marginal addition to the bottom line will be used to >> fund IPv6 transition. In fact, if incumbent IPv4 address holders >> stand to earn lots of revenue from IPv4 holdings in an IPv4 & >> IPv6 scarce environment, it's not clear to me that (or when) the >> incentives to capitalize on that arrangement are surpassed by the >> incentives to do their part to make IPv6 ubiquitous. >> Out of curiosity, would you support making that linkage between >> IPv4 revenues and IPv6 investment an explicit requirement in >> APNIC's proposal? >> On Mar 6, 2008, at 1:43 AM, Geoff Huston wrote: >>> ...The diversity of views abot scenarios and timings will drive >>> different >>> behaviours - some entities may act on the view that once the >>> shock of >>> exhaustion wears off and the related market price has factored in >>> scarcity premiums as well as the initial shock, the drive to IPv6 >>> will >>> assume a new level of momentum, and the IPv4 demand will drop, >>> and with >>> declining demand so will market prices - i.e. some folk would see no >>> value in hoarding and believe that maximal value will be seen in the >>> initial operation of short term market that will be overtaken by >>> IPv6 >>> relatively quickly. Other entities may be of the view that the >>> inertia >>> of this industry is sufficiently large, and the capability of >>> dense NAT >>> deployments sufficiently tenable that an IPv4 market may be used >>> for a >>> long period. If this is accompanied by a view that demand will >>> continue >>> to outpace supply then an escalating price is an obvious outcome. >> These are reasonable and useful speculations -- no doubt we could >> hypothesize a wide variety of stakeholder views, and maybe even >> model the weighted results of their behavior on average prices, >> collateral growth of NAT, IPv6 substitution, etc. Maybe we could >> then bootstrap that model, and tweak the parameters, and see how >> different kinds of market arrangements lead to different kinds of >> outcomes. If we actually had a model like that, then maybe some >> community members would be more persuaded that markets would, >> under some set of arrangements, be quite likely to lead to a >> particular outcome (e.g., IPv6/industry growth and diversity) and >> not to others (e.g., perma- NAT/industry consolidation). >> Unfortunately we don't have a model like that, and we're only >> going to have one opportunity to try this out in reality once. If >> we engineer transparency into the transfers mechanisms, however, >> maybe the resulting real-time window onto how things are really >> working will be good enough... >> On Mar 6, 2008, at 1:43 AM, Geoff Huston wrote: >>> And its not as if such forms of market outcomes spell >>> doom and disaster of an out of control stampede. This is not >>> quite the >>> wild days of 2000 and the GSM auction debacle appears to have >>> hosed down >>> some of the more insane players in this industry. This is a >>> relatively >>> low margin commodity business down at the plumbing side and it >>> may well >>> be that market pricing may well be influenced by the limited >>> amounts of >>> capital that are within the industry these days. >> Ahh, right back where we started ;-) >> TV >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the >> ARIN Public Policy >> Mailing List (PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml >> Please contact the ARIN Member Services Help Desk at info at arin.net >> if you experience any issues. From randy at psg.com Mon Mar 17 02:01:14 2008 From: randy at psg.com (Randy Bush) Date: Mon, 17 Mar 2008 15:01:14 +0900 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <9DC9F13A-CECE-43FB-B786-B35371F41339@pch.net> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D06585.2020402@apnic.net> <47DD8B57.6090205@internap.com> <9DC9F13A-CECE-43FB-B786-B35371F41339@pch.net> Message-ID: <47DE092A.9020503@psg.com> sorry to be picky, but ... perhaps we should try to facilitate, foster, and incent, as opposed to enforce? perhaps the customer/member is not our enemy? randy From tvest at pch.net Mon Mar 17 02:33:12 2008 From: tvest at pch.net (Tom Vest) Date: Mon, 17 Mar 2008 02:33:12 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <47DE092A.9020503@psg.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D06585.2020402@apnic.net> <47DD8B57.6090205@internap.com> <9DC9F13A-CECE-43FB-B786-B35371F41339@pch.net> <47DE092A.9020503@psg.com> Message-ID: On Mar 17, 2008, at 2:01 AM, Randy Bush wrote: > sorry to be picky, but ... > > perhaps we should try to facilitate, foster, and incent, as opposed to > enforce? perhaps the customer/member is not our enemy? > > randy Hi Randy, I agree 100% -- that's why I ended with the question. But I was answering a question that used the term "enforcement". Perhaps the question would have been better asked and answered using different terms, but that doesn't really get at your point. This does, I think: What things (rules/norms/goals) can be advanced "automatically" simply because they are restatements of existing practice, vs. what can be advanced through encouragement, incentives, etc. vs. what can be achieved only by coercion and enforcement is totally determined by what the members of a community value. If they value a particular goal, then maybe the inducements to comply don't need to be so big, and the penalties for noncompliance don't really matter. For goals that they don't support, artificial incentives have to be large, and penalties severe, and even so the compliance rate is likely to be low. It is nice (and eminently practical) to assume that the customer/ member is never our enemy -- we being fellow community members -- but that shifts the burden of critical scrutiny to the rules/norms/goals themselves. I guess the thing that makes individuals members of a shared community is the opportunity for them to talk to each other, with some chance of informing and persuading each other about the relative merits of different proposed (rules/norms/goals). So long as we're still doing that, I think that we're voting "not my enemy" with our actions -- even if we occasionally make small errors with our words ;-) TV From randy at psg.com Mon Mar 17 04:04:36 2008 From: randy at psg.com (Randy Bush) Date: Mon, 17 Mar 2008 17:04:36 +0900 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D06585.2020402@apnic.net> <47DD8B57.6090205@internap.com> <9DC9F13A-CECE-43FB-B786-B35371F41339@pch.net> <47DE092A.9020503@psg.com> Message-ID: <47DE2614.6090103@psg.com> Tom Vest wrote: > For goals that they ["members"] don't support, artificial incentives > have to be large, and penalties severe, and even so the compliance > rate is likely to be low. please reconcile this with the flags we salute and tout, bottom-up and self-regulation. if there are goals the members do not support, then whose goals are they? do you mean to imply that there likely exist societal goods which the membership does not support? if so, what is the implication for the sustainability of our supposedly bottom-up model of self-regulation? being raised on the west side of the cascades and coast range, i kinda like models which expect water to flow downhill, and being lazy, i try to avoid designing systems where it needs to flow uphill. what's the easy stuff here? i keep saying, set up an ebay-like system. run by a fourth party, not buyers and sellers or the registries. make the product, bidding, and prices visible. make it easy for buyers to be sure sellers actually have the right to sell. associate with an escrow service. sorry, i'm from ops. randy From michael.dillon at bt.com Mon Mar 17 05:32:09 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 17 Mar 2008 09:32:09 -0000 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <9DC9F13A-CECE-43FB-B786-B35371F41339@pch.net> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D06585.2020402@apnic.net><47DD8B57.6090205@internap.com> <9DC9F13A-CECE-43FB-B786-B35371F41339@pch.net> Message-ID: > > Can you clarify how you'd propose to enforce transparency, and what > > impact you think such enforcement would have? I think that the SEC's Fair Disclosure rules apply here, and these are ultimately enforced by the SEC. This means that if the two parties to a transaction collude to misreport the final price paid, then the principals of those two organizations can be charged with securities fraud and go to jail. ARIN is not the enforcer here. How many of you have spent some time at http://www.sec.gov reading about how properly run listing services operate? --Michael Dillon From jcurran at istaff.org Mon Mar 17 06:08:34 2008 From: jcurran at istaff.org (John Curran) Date: Mon, 17 Mar 2008 06:08:34 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D06585.2020402@apnic.net> <47DD8B57.6090205@internap.com> <9DC9F13A-CECE-43FB-B786-B35371F41339@pch.net> Message-ID: At 9:32 AM +0000 3/17/08, wrote: > > > Can you clarify how you'd propose to enforce transparency, and what >> > impact you think such enforcement would have? > >I think that the SEC's Fair Disclosure rules apply here, and these >are ultimately enforced by the SEC. This means that if the two parties >to a transaction collude to misreport the final price paid, then the >principals of those two organizations can be charged with securities >fraud and go to jail. ARIN is not the enforcer here. Michael - Are you saying that these principles should apply (and ARIN should embody these in any system it proposes) or that it's your preference that ARIN should seek to have the SEC rules apply, and specifically encourage SEC enforcement? As mentioned early, it does not appear that the security or commodities market regulations would govern anything in this space (but we will, of course, get a formal opinion of any recommended policy proposal). If you are recommending the answer to transparency *should be* SEC enforcement, please be explicit. Thanks, /John From michael.dillon at bt.com Mon Mar 17 06:39:49 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 17 Mar 2008 10:39:49 -0000 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D06585.2020402@apnic.net> <47DD8B57.6090205@internap.com> <9DC9F13A-CECE-43FB-B786-B35371F41339@pch.net> Message-ID: > >I think that the SEC's Fair Disclosure rules apply here, and > Michael - Are you saying that these principles should apply > (and ARIN should embody these in any system it proposes) or > that it's your preference that ARIN should seek to have the > SEC rules apply, and specifically encourage SEC enforcement? I'm saying that if you are going to design a market, it makes sense to follow best practices, and design one similar to other SEC-regulated markets. So, yes, ARIN should embody these principles if it designs such a system, and I agree with Randy, that the enforcement body should be a 4th party. In the real world, you have a buyer, a seller, a stock/commodities exchange, and the SEC as regulator. As far as seeking to have SEC rules apply and encouraging SEC enforcement, I would rather not do that and not have a forma market at all. However, given that some people want to have a market, if this is ultimately the decision taken by ARIN, then I believe that the *ONLY* way to reasonably avoid having SEC regulatory oversight is to understand the applicable law, design around it, and ask the SEC for a ruling that the ARIN market is outside of SEC regulatory responsibility. Of course, if someone gets a court decision saying that IP addresses are property, then all bets are off because if an IP address is an asset, then the holder of an IP address block has an equity, which means the contracts being sold on the market are equity derivatives, and these are explicitly mentioned in the law. > As mentioned early, it does not appear that the security or > commodities market regulations would govern anything in this > space (but we will, of course, get a formal opinion of any > recommended policy proposal). If you are recommending the > answer to transparency *should be* SEC enforcement, please be > explicit. Explicitly, I am recommending that the answer to transparency is to have listing rules similar to those of organizations like the NYSE, NSX, NASDAQ, CBOT, etc., along with enforcement of the rules by a 4th party, which may or may not be the SEC. In fact, the market may or may not be in the USA. As I understand it, Canada offers 10 separate provincial regulatory regimes, and there are a number of Caribbean countries in ARIN as well. Or, since ARIN does have a formal working relationship with ICANN, and ICANN already has an oversight role in regard to addressing, it is conceivable that they could fill the enforcement role. In the absence of a law which all must follow (SEC), it would be necessary for all buyers and sellers to contract for enforcement, either by contracting with ICANN prior to engaging in transactions, or by including some kind of mandatory arbitration provision in their contracts. It would be interesting to look back in history to see how this type of enforcement was handled prior to the existence of regulators like the SEC. Also, Randy's ebay suggestion is not that crazy. In a stock exchange, typically buyers and sellers do not simply arrange a deal and then publish it. Instead, the seller publishes and offer, the buyer publishes a bid, and then at some point, a deal is made and the result is published. This way observers see not only the final price, but also the movement of bids and offers prior to the deal. I'm still against moving towards a market since I don't think it is needed and I don't think there is enough time to create a proper transparent market. --Michael Dillon From ppml at rs.seastrom.com Mon Mar 17 07:38:03 2008 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Mon, 17 Mar 2008 07:38:03 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: (michael dillon's message of "Mon, 17 Mar 2008 10:39:49 -0000") References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D06585.2020402@apnic.net> <47DD8B57.6090205@internap.com> <9DC9F13A-CECE-43FB-B786-B35371F41339@pch.net> Message-ID: <86hcf5r36s.fsf@seastrom.com> writes: > Of course, if someone gets a court decision saying that IP > addresses are property, then all bets are off because if an > IP address is an asset, then the holder of an IP address block > has an equity, which means the contracts being sold on the market > are equity derivatives, and these are explicitly mentioned in > the law. No, if there is a court ruling that IP addresses are property (note that this has not happened to date, and I wouldn't hold your breath) then that is exactly what people have - property. An equity is stock in a corporation. There is no ownership position in any corporation conveyed by holding an IP address assignment. You _might_ argue that IP addresses were a commodity, but that would be a stretch indeed, and the Washington Post classifieds section (for instance) is not regulated by the SEC or any other government agency. While I agree that we ought to run any market according to best current practices (which might include such models as your local gas station with big signs posting the prevailing and variable price, eBay with realtime bid reporting, or Craig's List which is simply a forum where people advertise that they have stuff for sale with no price reporting whatsoever), that does not mean getting the SEC involved preemptively. It also should not mean sitting around worrying that the SEC will decide that it doesn't have enough to do and wants to start regulating a market where the market-maker (ARIN) is neither making a profit on the transaction nor holding the resource that it's trading for its own account and thus has no incentive to manipulate prices or otherwise do bad stuff. Absent significant misbehavior, government regulatory bodies don't have a history of getting involved. I think the entire list would appreciate you giving the SEC angle a rest, as I mentioned to you in private email a couple of days ago. Best, ---Rob From michael.dillon at bt.com Mon Mar 17 08:22:46 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 17 Mar 2008 12:22:46 -0000 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <86hcf5r36s.fsf@seastrom.com> References: <47CDA182.80502@internap.com><435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org><47CF088B.5060809@internap.com><47CF4F8F.2030504@psg.com><000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com><00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com><507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net><47D06585.2020402@apnic.net><47DD8B57.6090205@internap.com><9DC9F13A-CECE-43FB-B786-B35371F41339@pch.net> <86hcf5r36s.fsf@seastrom.com> Message-ID: > I think the entire list would appreciate you giving the SEC > angle a rest, as I mentioned to you in private email a couple > of days ago. Let me remind you that this is the PUBLIC policy mailing list, not the ARIN AC's policy mailing list. As a member of the ARIN AC you have no special rights on this list. In fact, as you so graciously pointed out, I gave the issue a rest for a couple of days. I think that I speak for the entire list in wondering why the ARIN AC, are pushing this transfer proposal so hard? In the past, the ARIN AC did not attempt to run the public policy process, instead they responded to proposals from others. Something is not right... --Michael Dillon From jcurran at istaff.org Mon Mar 17 08:37:03 2008 From: jcurran at istaff.org (John Curran) Date: Mon, 17 Mar 2008 08:37:03 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: References: <47CDA182.80502@internap.com><435DE256-44B8-48FC-9F4B-AC3BC8D70D65@vir tualized.org><47CF088B.5060809@internap.com><47CF4F8F.2030504@psg.com><000301c87f66$c7a4fed0$6e00a8c0@ad.re dback.com><00b801c87 fb8$4ddf77e0$6e00a8c0@ad.redback.com><507B4D6C-D2BC-44BF-843E-CDCDF1708BED @pch.net><47D06585.2020402@apnic.net><47DD8B57.6090205@internap.com><9DC9F13A-CECE-43FB-B786-B35371F41 339@pch.net> <86hcf5r36s.fsf@seastrom.com> Message-ID: At 12:22 PM +0000 3/17/08, wrote: >I think that I speak for the entire list in wondering why the >ARIN AC, are pushing this transfer proposal so hard? > >In the past, the ARIN AC did not attempt to run the public policy >process, instead they responded to proposals from others. Something >is not right... Michael - The ARIN Board did ask the ARIN AC to look into the matter of whether some form of transfer policy would be useful, under what conditions, and make any recommendations or proposals as needed. This explains why the ARIN AC is active on this topic. Folks should feel free to submit alternative proposals, and/or speak out against the transfer policy proposal if they feel that it is a mistake. It is, as you noted, the *public* policy mailing list. /John From tvest at pch.net Mon Mar 17 08:42:15 2008 From: tvest at pch.net (Tom Vest) Date: Mon, 17 Mar 2008 08:42:15 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <47DE2614.6090103@psg.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D06585.2020402@apnic.net> <47DD8B57.6090205@internap.com> <9DC9F13A-CECE-43FB-B786-B35371F41339@pch.net> <47DE092A.9020503@psg.com> <47DE2614.6090103@psg.com> Message-ID: <2B45F3C3-30D3-4D4D-9290-2BE3B58D1192@pch.net> On Mar 17, 2008, at 4:04 AM, Randy Bush wrote: > Tom Vest wrote: >> For goals that they ["members"] don't support, artificial incentives >> have to be large, and penalties severe, and even so the compliance >> rate is likely to be low. > > please reconcile this with the flags we salute and tout, bottom-up and > self-regulation. Sorry it wasn't obvious. I included this for contrast and completeness, but the implication was that if the community does not support it, then self-regulation cannot deliver it. That's why I closed the previous message this way: On Mar 17, 2008, at 1:53 AM, Tom Vest wrote: > If there were some way to leverage that unitary distribution model > to execute the same kind of incentive-driven redistribution > envisioned by 2008-02 and its counterparts, then perhaps we could > satisfy the transitional supply requirement without sacrificing > transparency or any of the information exchanges that help to keep > the central registry (at least) "good enough". But that means more/ > continued, not less, community-driven collective action -- so the > impact depends entirely on the perceptions of the members of the > community. > > What does the rest of the community think? > > TV On Mar 17, 2008, at 4:04 AM, Randy Bush wrote: > being raised on the west side of the cascades and coast range, i kinda > like models which expect water to flow downhill, and being lazy, i try > to avoid designing systems where it needs to flow uphill. That sounds like a pretty smart side. I hear they use a lot of dams and canals out there to make sure that water flows downhill -- e.g., from the mountains to the deserts -- but in ways that are constructive and not harmful. They don't dig the canals a mile deep -- after all, laziness is perfectly natural -- so they tolerate some infrequent-to-rare flooding. But I guess they figure that long-term laziness is better served by doing at least a little advance work. > what's the easy stuff here? i keep saying, set up an ebay-like > system. > run by a fourth party, not buyers and sellers or the registries. make > the product, bidding, and prices visible. make it easy for buyers > to be > sure sellers actually have the right to sell. associate with an > escrow > service. A trusted fourth party could be designed on the "unitary distribution model". A trusted fourth party could provide the required transparency, including not only product, bidding, and prices but also the identity of buyers and sellers -- once again, without which gaming the system will be trivially easy. No escrow service would be able to stay in business without this information, and no central registry would be able to remain accurate without this, and no self- regulating body would be able to govern itself on market day +1 without this. The question is, how to assure that the "ebay" function reinforces rather than kills the central registry requirement and self- governance requirement? TV From owen at delong.com Mon Mar 17 09:56:34 2008 From: owen at delong.com (Owen DeLong) Date: Mon, 17 Mar 2008 06:56:34 -0700 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: References: <47CDA182.80502@internap.com><435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org><47CF088B.5060809@internap.com><47CF4F8F.2030504@psg.com><000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com><00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com><507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net><47D06585.2020402@apnic.net><47DD8B57.6090205@internap.com><9DC9F13A-CECE-43FB-B786-B35371F41339@pch.net> <86hcf5r36s.fsf@seastrom.com> Message-ID: On Mar 17, 2008, at 5:22 AM, wrote: > >> I think the entire list would appreciate you giving the SEC >> angle a rest, as I mentioned to you in private email a couple >> of days ago. > > Let me remind you that this is the PUBLIC policy mailing list, not > the ARIN AC's policy mailing list. As a member of the ARIN AC you > have no special rights on this list. In fact, as you so graciously > pointed out, I gave the issue a rest for a couple of days. > Well, as a member of the PUBLIC, not just a member of the AC, I would also appreciate it if you gave the SEC angle a rest. > I think that I speak for the entire list in wondering why the > ARIN AC, are pushing this transfer proposal so hard? > I don't believe that the AC is pushing the proposal so hard. I believe that one member of the AC is pushing rather hard for the proposal. OTOH, I, for one, am somewhere between neutral and opposed to the proposal at this point. I know that there are other members of the AC who are also not necessarily in favor of this proposal. > In the past, the ARIN AC did not attempt to run the public policy > process, instead they responded to proposals from others. Something > is not right... > Indeed, the following are not right: 1. Assuming that a member of the AC posting to this list is posting as spokesperson for the AC and not as a member of the public is not right. 2. Assuming that once elected, members of the AC are not members of the public and have less right to be involved in authoring policy than any other member of the public is not right. 3. Regarding a request to stop beating a dead horse as an attempt to "run the public policy process" is also not right. Just so we're clear here, the above is strictly my personal opinion as a member of the public. As a member of the AC, I will say that there is no official AC position in favor of 2008-2, nor is there any official AC position against 2008-2. I am not sure what portion of the AC supports or opposes the proposal. I know that during the development process, several of us were using the approach of "assume that we need some sort of transfer proposal, what's the best one we can come up with." The AC has not held significant discussion about whether or not a such a transfer proposal is something we actually want. Finally, this proposal is a response to requests from others. Among others, it is a response to the ARIN Board of Trustees. Owen From packetgrrl at gmail.com Mon Mar 17 10:39:34 2008 From: packetgrrl at gmail.com (cja@daydream.com) Date: Mon, 17 Mar 2008 08:39:34 -0600 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: References: <47D06585.2020402@apnic.net> <47DD8B57.6090205@internap.com> <9DC9F13A-CECE-43FB-B786-B35371F41339@pch.net> <86hcf5r36s.fsf@seastrom.com> Message-ID: I have to agree with Owen. I believe that we even said what is outlined below on February 7th when the AC sent out a note to ppml. It included: " We are aware that this proposal, if adopted, will mark a major change in ARIN's role in the community and the Internet. While the AC as a whole believes the policy proposal to be well written and carefully considered, we are not unanimous in all aspects of the policy proposal, nor even are we united in the view that the proposed policy should be adopted. We hope this policy proposal will spark debate and discussion, and we look forward to getting additional community input on the topic. The AC as members of the ARIN community believe in the bottom up process, and we urge the community to give this proposal the same consideration and discussion they would give any other proposal." At the current time I am personally not in favor of this policy as written. I look forward to the discussion at the meeting and I have been following closely the discussion on this list. If after evaluating all the discussion I feel that this policy is the best thing for the community then I will be in favor. The most important thing about this policy proposal and the reason that I supported writing it.. is that it is essential that the ARIN community has detailed discussions of this issue and how we as a community are going to deal with it. Thanks! ----Cathy On Mon, Mar 17, 2008 at 7:56 AM, Owen DeLong wrote: > > On Mar 17, 2008, at 5:22 AM, wrote: > > > > >> I think the entire list would appreciate you giving the SEC > >> angle a rest, as I mentioned to you in private email a couple > >> of days ago. > > > > Let me remind you that this is the PUBLIC policy mailing list, not > > the ARIN AC's policy mailing list. As a member of the ARIN AC you > > have no special rights on this list. In fact, as you so graciously > > pointed out, I gave the issue a rest for a couple of days. > > > Well, as a member of the PUBLIC, not just a member of the AC, > I would also appreciate it if you gave the SEC angle a rest. > > > I think that I speak for the entire list in wondering why the > > ARIN AC, are pushing this transfer proposal so hard? > > > I don't believe that the AC is pushing the proposal so hard. > I believe that one member of the AC is pushing rather hard > for the proposal. OTOH, I, for one, am somewhere between > neutral and opposed to the proposal at this point. > > I know that there are other members of the AC who are > also not necessarily in favor of this proposal. > > > In the past, the ARIN AC did not attempt to run the public policy > > process, instead they responded to proposals from others. Something > > is not right... > > > Indeed, the following are not right: > > 1. Assuming that a member of the AC posting to this list > is posting as spokesperson for the AC and not as a > member of the public is not right. > > 2. Assuming that once elected, members of the AC are > not members of the public and have less right to be > involved in authoring policy than any other member > of the public is not right. > > 3. Regarding a request to stop beating a dead horse as > an attempt to "run the public policy process" is also > not right. > > Just so we're clear here, the above is strictly my personal > opinion as a member of the public. > > As a member of the AC, I will say that there is no official > AC position in favor of 2008-2, nor is there any official > AC position against 2008-2. I am not sure what portion > of the AC supports or opposes the proposal. I know > that during the development process, several of us were > using the approach of "assume that we need some sort of > transfer proposal, what's the best one we can come up with." > > The AC has not held significant discussion about whether > or not a such a transfer proposal is something we actually > want. > > Finally, this proposal is a response to requests from others. > Among others, it is a response to the ARIN Board of > Trustees. > > Owen > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlw+arin at tellme.com Mon Mar 17 11:39:29 2008 From: dlw+arin at tellme.com (David Williamson) Date: Mon, 17 Mar 2008 08:39:29 -0700 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: References: <47D06585.2020402@apnic.net> <47DD8B57.6090205@internap.com> <9DC9F13A-CECE-43FB-B786-B35371F41339@pch.net> <86hcf5r36s.fsf@seastrom.com> Message-ID: <20080317153929.GU24095@shell01.cell.sv2.tellme.com> On Mon, Mar 17, 2008 at 08:39:34AM -0600, cja at daydream.com wrote: > I have to agree with Owen. I believe that we even said what is outlined > below on February 7th when the AC sent out a note to ppml. > > The most important thing about this policy proposal and the > reason that I supported writing it.. is that it is essential that the ARIN > community has detailed discussions of this issue and how we as a community > are going to deal with it. As a member of nothing at all, I also agree with Owen. It would seem unwise to elect some of our most notable contributors to the AC, and then muzzle them. I'm happy to see the AC have a more vocal role in the development process for this policy. I fully expect them to play by the same rules as everyone else, and for the Board to act in its role as an auditor of the process. If either of those bodies fail to stick with established and documented process, I'll be voting people off at the next election. Then again, I voted for most of the exisitng groups based on my trust in them to act in an appropriate fashion. I would further agree with Cathy that this is an extremely important topic for the entire community. I'm personally mildly in favor of the exisitng proposal. I think it has several flaws, but it's a darn good start. I would much prefer something that is overly restrictive as an initial starting point, versus something extremely liberal. (Hard to put that genie back in the bottle!) I would like to see the SEC thing laid to rest for a while. It would appear that it is a non-issue, but it could be a point for concern. The SEC thing will make a good topic once we get a legal opinion from an actual lawyer. I think we all understand that several folks are very worried about it. Noted and logged: let's discuss this further *after* the lawyers do. -David From Fred.Wettling at Bechtel.com Mon Mar 17 12:12:02 2008 From: Fred.Wettling at Bechtel.com (Wettling, Fred) Date: Mon, 17 Mar 2008 12:12:02 -0400 Subject: [ppml] 2008-2 IPv4 transfer policy In-Reply-To: <47DA7B9E.1070802@cjbsys.bdb.com> References: <200803131735.m2DHZMr7008071@cjbsys.bdb.com><47D9782C.3020707@internap.com> <47DA7B9E.1070802@cjbsys.bdb.com> Message-ID: I oppose Policy Proposal 2008-2 IPv4 Transfer Policy Proposal - Policy Section 8 Transfers is currently adequate - Transfer policy should continue to be protocol-agnostic. - 2008-2 does not reinforce the 7-May-07 ARIN resolution on "Internet Protocol Numbering Resources Availability" encouraging " migration to IPv6 numbering resources where possible" Fred Wettling - Bechtel Fellow From cliffb at cjbsys.bdb.com Mon Mar 17 12:16:04 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Mon, 17 Mar 2008 12:16:04 -0400 (EDT) Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 Message-ID: <200803171616.m2HGG54f029086@cjbsys.bdb.com> At the risk of repeating myself, I think 8.3.9 should be deleted in its entirety. All ARIN needs to do in the process is allow 3rd parties to transfer IP addresses directly from one party to another without being returned to ARIN first. The numbers must be properly registered to the transferor and the transferee must justify the need. Other than that, ARIN should have nothing to do with the dealings of the two parties. They can trade money, resort properties or pork futures and it's nobody's business what the transaction is. In a prior message, I commented on other changes I think need to be made to 2008-2 but they mostly deal with the idea of ARIN having as little to do with negotiations between the 2(or more) parties and only certify the validity of the transfer. Remember that this policy will only take effect when ARIN is likely not to be able to meet some requirements for addresses. Why would someone pay money for something they can get for free from ARIN. If ARIN doesn't have it, the seekers of addresses should be able to get the addresses from any legitimate provider and there should be no need to make any details of the transaction public. As an aside, I also agree that the SEC discussion has been noted, the AC and BoT have indicated they will look at it in further detail if 2008-2 proceeds. Cliff -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From farmer at umn.edu Mon Mar 17 12:32:53 2008 From: farmer at umn.edu (David Farmer) Date: Mon, 17 Mar 2008 11:32:53 -0500 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <47DE2614.6090103@psg.com> References: , , <47DE2614.6090103@psg.com> Message-ID: <47DE56E5.16499.1310A2EE@farmer.umn.edu> This got me thinking a bit, thanks Randy and Tom, I was hoping to avoid doing that today :) At least one supposed source of address that I've heard talked about in this is Legacy Holders. Many Legacy holders are end user entities, yes there are other types of entities, but lets discuss end user entities for a moment. It is possible that a end user would enter into a cash transaction, then your pricing and transparency questions are probably valid. However, it is also possible that an end user might prefer to enter into a barter transaction, this could be for any number of non-cash considerations, or a combination of cash and non-cash considerations. An easy example would be an end user trading address-space with an ISP for service. However, there are many other possibilities. In this case what value should be recorded? The retail value of the service, or the marginal cost of the providing the service by the ISP? The cost to the buyer or the value to the seller, which may or may not be exactly the same. Another example would be a end user group transferring address space to another end user group for no cost at all and with no expectation other than community good. Further these transactions may or may not take place through a listing service. It would be a shame if we only think about the market in terms of cash transactions, especially given the longer term history of the Internet community. Please leave room for the better angles too. The later example probablly doesn't need to be accounted for within the market, it is probablly outside the market anyway, but barter transactions should be accounted for in some way within the market. On 17 Mar 2008 Randy Bush wrote: > Tom Vest wrote: > > For goals that they ["members"] don't support, artificial incentives > > have to be large, and penalties severe, and even so the compliance > > rate is likely to be low. > > please reconcile this with the flags we salute and tout, bottom-up and > self-regulation. > > if there are goals the members do not support, then whose goals are > they? do you mean to imply that there likely exist societal goods which > the membership does not support? if so, what is the implication for the > sustainability of our supposedly bottom-up model of self-regulation? > > being raised on the west side of the cascades and coast range, i kinda > like models which expect water to flow downhill, and being lazy, i try > to avoid designing systems where it needs to flow uphill. > > what's the easy stuff here? i keep saying, set up an ebay-like system. > run by a fourth party, not buyers and sellers or the registries. make > the product, bidding, and prices visible. make it easy for buyers to be > sure sellers actually have the right to sell. associate with an escrow > service. > > sorry, i'm from ops. > > randy ================================================= David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 ================================================= From BillD at cait.wustl.edu Mon Mar 17 12:35:45 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Mon, 17 Mar 2008 11:35:45 -0500 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: References: <47CDA182.80502@internap.com><435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org><47CF088B.5060809@internap.com><47CF4F8F.2030504@psg.com><000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com><00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com><507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net><47D06585.2020402@apnic.net><47DD8B57.6090205@internap.com><9DC9F13A-CECE-43FB-B786-B35371F41339@pch.net><86hcf5r36s.fsf@seastrom.com> Message-ID: Let me, too, add my voice here. As a member of the AC I can also assure that the AC is divided on this issue and have responded to need and request for this proposal to be crafted and published to guage sentiment related to the topic of an expanded transfer policy. It was and is intended to be a 'strawman' that is explicit so that people are not bogged down in trying to discuss generalities. In no other way could we expect to get concrete and specific input and a sense of consensus. And, I think that it is wise for people to read how AC members address the community through ppml participation. I know that when I speak with a voice that conveys my thoughts as an AC member I express this directly or sign my post as an ARIN AC member. When I post as a representative of Washington University in St. Louis, I say so, but when I interact as an individual I generally sign as bd or not at all. This is of course MY convention....I suggest that if anyone ever is unclear under what 'hat' and AC member is posting...to simply ask them public to declare their position. Bill Darte ARIN AC > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of michael.dillon at bt.com > Sent: Monday, March 17, 2008 7:23 AM > To: ppml at arin.net > Subject: Re: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 > > > > I think the entire list would appreciate you giving the SEC angle a > > rest, as I mentioned to you in private email a couple of days ago. > > Let me remind you that this is the PUBLIC policy mailing > list, not the ARIN AC's policy mailing list. As a member of > the ARIN AC you have no special rights on this list. In fact, > as you so graciously pointed out, I gave the issue a rest for > a couple of days. > > I think that I speak for the entire list in wondering why the > ARIN AC, are pushing this transfer proposal so hard? > > In the past, the ARIN AC did not attempt to run the public > policy process, instead they responded to proposals from > others. Something is not right... > > --Michael Dillon > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at > info at arin.net if you experience any issues. > From tvest at pch.net Mon Mar 17 12:45:55 2008 From: tvest at pch.net (Tom Vest) Date: Mon, 17 Mar 2008 12:45:55 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <200803171616.m2HGG54f029086@cjbsys.bdb.com> References: <200803171616.m2HGG54f029086@cjbsys.bdb.com> Message-ID: <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> I believe that the requirements for which successive address delegation regimes -- the RIRs included, but also each of their successors -- were established, and were supported by the community over time, include more than just the simple/blind distribution of IP addresses. I believe that the community actually had the *unique* *historically unprecedented* opportunity to exercise judgment over such matters *only* because they fulfilled those other requirements competently. Since I cannot see how this suggestion would permit continued delivery on any of the other non-optional requirements, I believe it would lead either to the end of the community itself, and/or the erosion and, ultimately, irretrievable loss the community's historically unprecedented privilege of industry self-governance. Therefore I strongly recommend that the community reject this suggestion and get on with more realistic, sustainable alternatives. TV On Mar 17, 2008, at 12:16 PM, Cliff Bedore wrote: > At the risk of repeating myself, I think 8.3.9 should be deleted in > its > entirety. All ARIN needs to do in the process is allow 3rd parties to > transfer IP addresses directly from one party to another without being > returned to ARIN first. The numbers must be properly registered to > the > transferor and the transferee must justify the need. Other than > that, ARIN > should have nothing to do with the dealings of the two parties. > They can > trade money, resort properties or pork futures and it's nobody's > business what > the transaction is. > > In a prior message, I commented on other changes I think need to be > made to > 2008-2 but they mostly deal with the idea of ARIN having as little > to do with > negotiations between the 2(or more) parties and only certify the > validity of > the transfer. > > Remember that this policy will only take effect when ARIN is likely > not to be > able to meet some requirements for addresses. Why would someone > pay money for > something they can get for free from ARIN. If ARIN doesn't have > it, the > seekers of addresses should be able to get the addresses from any > legitimate > provider and there should be no need to make any details of the > transaction > public. > > As an aside, I also agree that the SEC discussion has been noted, > the AC and > BoT have indicated they will look at it in further detail if 2008-2 > proceeds. > > Cliff > > -- > Cliff Bedore > 7403 Radcliffe Dr. College Park MD 20740 > cliffb at cjbsys.bdb.com http://www.bdb.com > Amateur Radio Call Sign W3CB For info on ham radio, http:// > www.arrl.org/ > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the > ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. From farmer at umn.edu Mon Mar 17 12:57:17 2008 From: farmer at umn.edu (David Farmer) Date: Mon, 17 Mar 2008 11:57:17 -0500 Subject: [ppml] Transfer Dispute Resolution, 2008-2 Message-ID: <47DE5C9D.5473.1326FD0A@farmer.umn.edu> Even if this is a successful proposal and turns out to be successful in practice. This will create a whole new class of disputes that ARIN will be involved in. Even if there are no bad actors, there will be honest disputes that will arise out of these transfers. People are people, and nothing involving people is perfect. I would suggest some thought be given to a dispute process. If nothing else who should disputes be reported to at ARIN and then some attempt at arbitration. If nothing else, checks every so often do actually get lost in the mail. ================================================= David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 ================================================= From sleibrand at internap.com Mon Mar 17 13:06:56 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 17 Mar 2008 10:06:56 -0700 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: References: <47CDA182.80502@internap.com><435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org><47CF088B.5060809@internap.com><47CF4F8F.2030504@psg.com><000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com><00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com><507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net><47D06585.2020402@apnic.net><47DD8B57.6090205@internap.com><9DC9F13A-CECE-43FB-B786-B35371F41339@pch.net> <86hcf5r36s.fsf@seastrom.com> Message-ID: <47DEA530.2040408@internap.com> Owen DeLong wrote: > On Mar 17, 2008, at 5:22 AM, wrote: > >> I think that I speak for the entire list in wondering why the >> ARIN AC, are pushing this transfer proposal so hard? >> > I don't believe that the AC is pushing the proposal so hard. > I believe that one member of the AC is pushing rather hard > for the proposal. OTOH, I, for one, am somewhere between > neutral and opposed to the proposal at this point. > > I know that there are other members of the AC who are > also not necessarily in favor of this proposal. Correct. And to clarify my position, I strongly believe (as an individual) that some sort of transfer policy that supports a market will be necessary for the continued smooth functioning of the IPv4 portion of the Internet as we transition to IPv6. I'm not necessarily 100% in favor of all the aspects of 2008-2 (such as the restrictions on deaggregation), and I could support a number of variations on 2008-2 (such as Tom's transparency provisions) if the community thinks they would improve the policy. As Owen correctly states, there are a wide variety of views on this topic, and some very good arguments for many of them. By participating in this discussion on PPML (and at the meeting in Denver), I hope that we (as a community) can bring out all the good arguments on all sides, and begin coming together around a consensus position. >> In the past, the ARIN AC did not attempt to run the public policy >> process, instead they responded to proposals from others. Something >> is not right... I believe there will be an opportunity to discuss the ARIN AC's role in the policy development process at the Denver meeting. > 1. Assuming that a member of the AC posting to this list > is posting as spokesperson for the AC and not as a > member of the public is not right. And to expound on this point, communication from the AC as a whole will always come from Member Services to PPML. The only such messages I see on the topic of the IPv4 transfer policy have been the letter of February 7 announcing that the AC would be presenting a policy proposal, and the standard announcements posting the policy proposal text, policy number, etc. > 2. Assuming that once elected, members of the AC are > not members of the public and have less right to be > involved in authoring policy than any other member > of the public is not right. ARIN AC members are elected by the ARIN community based on their contributions to and knowledge of the public policy process, and the issues addressed by policy. In order to make sure that the community receives the maximum benefit out of such knowledge, I believe it is important that AC members be encouraged to continue participating in the public policy process. > Just so we're clear here, the above is strictly my personal > opinion as a member of the public. And as I mentioned above, *all* public statements (including this one) made directly by AC members should be considered personal opinions unless stated otherwise. > As a member of the AC, I will say that there is no official > AC position in favor of 2008-2, nor is there any official > AC position against 2008-2. I am not sure what portion > of the AC supports or opposes the proposal. I know > that during the development process, several of us were > using the approach of "assume that we need some sort of > transfer proposal, what's the best one we can come up with." Agreed. > The AC has not held significant discussion about whether > or not a such a transfer proposal is something we actually > want. And it's also important to note that it doesn't really matter (in the context of the public policy process) whether the AC believes that a transfer proposal is desirable. Regardless of what we think personally or collectively, the AC must respect the will of the community in advancing or rejecting any policy proposal. Even if I believe a policy proposal is a good idea, and in the best interest of the community, I can't/won't vote to send it to the Board for adoption unless the community has expressed consensus in favor of the proposal. I haven't seen a consensus yet (for or against), so I'm continuing to work to see if we can develop a proposal that achieves consensus. Thanks, to you and everyone else who has contributed to the discussions so far, for sharing your opinion and helping move that process forward. -Scott From jcurran at istaff.org Mon Mar 17 13:15:15 2008 From: jcurran at istaff.org (John Curran) Date: Mon, 17 Mar 2008 13:15:15 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> References: <200803171616.m2HGG54f029086@cjbsys.bdb.com> <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> Message-ID: At 12:45 PM -0400 3/17/08, Tom Vest wrote: > >Therefore I strongly recommend that the community reject this >suggestion and get on with more realistic, sustainable alternatives. Tom - Could you succinctly express such an alternative? /John From cliffb at cjbsys.bdb.com Mon Mar 17 13:34:39 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Mon, 17 Mar 2008 13:34:39 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> References: <200803171616.m2HGG54f029086@cjbsys.bdb.com> <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> Message-ID: <47DEABAF.4050109@cjbsys.bdb.com> Tom Vest wrote: > I believe that the requirements for which successive address > delegation regimes -- the RIRs included, but also each of their > successors -- were established, and were supported by the community > over time, include more than just the simple/blind distribution of IP > addresses. I believe that the community actually had the *unique* > *historically unprecedented* opportunity to exercise judgment over > such matters *only* because they fulfilled those other requirements > competently. I'm not sure of what any of that really means. Can you explain in more detail what these other things are? > > Since I cannot see how this suggestion would permit continued delivery > on any of the other non-optional requirements, I believe it would lead > either to the end of the community itself, and/or the erosion and, > ultimately, irretrievable loss the community's historically > unprecedented privilege of industry self-governance. Frankly the community has already lost a great deal of that. When I got my /24 in 1992, it was in a letter without even a return address. When I got the BDB.COM domain, it was done with a simple email. It might be argued that ARIN is a somewhat logical follow-on to SRI, I see no way that Network Solutions is in any way a community oriented organization. Every time I have to renew my domain name, I hold my nose and pray that the 23 pages of things I am agreeing to don't commit met to being forced to sell or give up my domain because somebody else wants a short domain. > > Therefore I strongly recommend that the community reject this > suggestion and get on with more realistic, sustainable alternatives. I normally don't get real excited about things but who appointed you God of what is realistic and sustainable and have you actually offered any such alternatives? Cliff > > > TV > > On Mar 17, 2008, at 12:16 PM, Cliff Bedore wrote: > >> At the risk of repeating myself, I think 8.3.9 should be deleted in its >> entirety. All ARIN needs to do in the process is allow 3rd parties to >> transfer IP addresses directly from one party to another without being >> returned to ARIN first. The numbers must be properly registered to the >> transferor and the transferee must justify the need. Other than >> that, ARIN >> should have nothing to do with the dealings of the two parties. They >> can >> trade money, resort properties or pork futures and it's nobody's >> business what >> the transaction is. >> >> In a prior message, I commented on other changes I think need to be >> made to >> 2008-2 but they mostly deal with the idea of ARIN having as little to >> do with >> negotiations between the 2(or more) parties and only certify the >> validity of >> the transfer. >> >> Remember that this policy will only take effect when ARIN is likely >> not to be >> able to meet some requirements for addresses. Why would someone pay >> money for >> something they can get for free from ARIN. If ARIN doesn't have it, the >> seekers of addresses should be able to get the addresses from any >> legitimate >> provider and there should be no need to make any details of the >> transaction >> public. >> >> As an aside, I also agree that the SEC discussion has been noted, the >> AC and >> BoT have indicated they will look at it in further detail if 2008-2 >> proceeds. >> >> Cliff >> >> -- >> Cliff Bedore >> 7403 Radcliffe Dr. College Park MD 20740 >> cliffb at cjbsys.bdb.com http://www.bdb.com >> Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy >> Mailing List (PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml >> Please contact the ARIN Member Services Help Desk at info at arin.net if >> you experience any issues. > From tvest at pch.net Mon Mar 17 14:07:50 2008 From: tvest at pch.net (Tom Vest) Date: Mon, 17 Mar 2008 14:07:50 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <47DEABAF.4050109@cjbsys.bdb.com> References: <200803171616.m2HGG54f029086@cjbsys.bdb.com> <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> <47DEABAF.4050109@cjbsys.bdb.com> Message-ID: <2C265646-1164-4AC0-8E0C-7A8888D4DBC3@pch.net> On Mar 17, 2008, at 1:34 PM, Cliff Bedore wrote: > Tom Vest wrote: >> I believe that the requirements for which successive address >> delegation regimes -- the RIRs included, but also each of their >> successors -- were established, and were supported by the community >> over time, include more than just the simple/blind distribution of IP >> addresses. I believe that the community actually had the *unique* >> *historically unprecedented* opportunity to exercise judgment over >> such matters *only* because they fulfilled those other requirements >> competently. > > I'm not sure of what any of that really means. Can you explain in > more > detail what these other things are? Hi Cliff, I have, at great length, in previous messages here and on NANOG, using terms like "central registry" and "self-sustaining mechanisms", et al. I'll try to provide a complete and coherent summary for those interested ASAP -- certainly before the Denver meeting. >> Since I cannot see how this suggestion would permit continued >> delivery >> on any of the other non-optional requirements, I believe it would >> lead >> either to the end of the community itself, and/or the erosion and, >> ultimately, irretrievable loss the community's historically >> unprecedented privilege of industry self-governance. > > Frankly the community has already lost a great deal of that. When > I got > my /24 in 1992, it was in a letter without even a return address. I think that matters have improved since 1992, although obviously they have not recovered the glory of the earliest days, when the universe of relevant parties was just a few dozen network operators, all but a handful of which resided in the same country. I don't think that's a reasonable benchmark however. > When I got the BDB.COM domain, it was done with a simple email. It > might be > argued that ARIN is a somewhat logical follow-on to SRI, I see no way > that Network Solutions is in any way a community oriented > organization. > Every time I have to renew my domain name, I hold my nose and pray > that > the 23 pages of things I am agreeing to don't commit met to being > forced > to sell or give up my domain because somebody else wants a short > domain. Actually, I think the contrast -- and the personal response that you described below -- are very illuminating. The mechanism for distributing (esp. top-level names) has been a source of eternal, unrelenting, impassioned, existential criticism every day since day one. The institutions that have administered names allocation have probably spent 50-75% of their total man-hours to date simply justifying their existence and actions. We may end up in the same situation -- it may even be unavoidable -- but I personally think it would be better if we could avoid that kind of overhead. >> Therefore I strongly recommend that the community reject this >> suggestion and get on with more realistic, sustainable alternatives. > > I normally don't get real excited about things but who appointed > you God > of what is realistic and sustainable and have you actually offered any > such alternatives? I'm just a community member, same as you. I just made a recommendation, same as you did. I have passed a very different looking straw man proposal around, but I'm not ready to introduce it into the formal policy development process at this time. In any case, since the resource transfer proposals seem to have generated great interest, it seems to me that working in that context (if/ for as long as possible) makes a lot more sense than trying to entice people to start speaking a whole different language. TV >> On Mar 17, 2008, at 12:16 PM, Cliff Bedore wrote: >> >>> At the risk of repeating myself, I think 8.3.9 should be deleted >>> in its >>> entirety. All ARIN needs to do in the process is allow 3rd >>> parties to >>> transfer IP addresses directly from one party to another without >>> being >>> returned to ARIN first. The numbers must be properly registered >>> to the >>> transferor and the transferee must justify the need. Other than >>> that, ARIN >>> should have nothing to do with the dealings of the two parties. >>> They >>> can >>> trade money, resort properties or pork futures and it's nobody's >>> business what >>> the transaction is. >>> >>> In a prior message, I commented on other changes I think need to be >>> made to >>> 2008-2 but they mostly deal with the idea of ARIN having as >>> little to >>> do with >>> negotiations between the 2(or more) parties and only certify the >>> validity of >>> the transfer. >>> >>> Remember that this policy will only take effect when ARIN is likely >>> not to be >>> able to meet some requirements for addresses. Why would someone pay >>> money for >>> something they can get for free from ARIN. If ARIN doesn't have >>> it, the >>> seekers of addresses should be able to get the addresses from any >>> legitimate >>> provider and there should be no need to make any details of the >>> transaction >>> public. >>> >>> As an aside, I also agree that the SEC discussion has been noted, >>> the >>> AC and >>> BoT have indicated they will look at it in further detail if 2008-2 >>> proceeds. >>> >>> Cliff >>> >>> -- >>> Cliff Bedore >>> 7403 Radcliffe Dr. College Park MD 20740 >>> cliffb at cjbsys.bdb.com http://www.bdb.com >>> Amateur Radio Call Sign W3CB For info on ham radio, http:// >>> www.arrl.org/ >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to the >>> ARIN >>> Public Policy >>> Mailing List (PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/ppml >>> Please contact the ARIN Member Services Help Desk at >>> info at arin.net if >>> you experience any issues. >> > > _______________________________________________ > 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 Derya.Cansever at si-intl.com Mon Mar 17 14:57:32 2008 From: Derya.Cansever at si-intl.com (Cansever, Derya) Date: Mon, 17 Mar 2008 14:57:32 -0400 Subject: [ppml] 2008-2 IPv4 transfer policy In-Reply-To: References: <200803131735.m2DHZMr7008071@cjbsys.bdb.com><47D9782C.3020707@internap.com> <47DA7B9E.1070802@cjbsys.bdb.com> Message-ID: <1F9BA83F11C39A48926E3142EF4640F229A1EE63D5@us01mbx01.si.siroot.com> I completely agree with all the points that Fred has raised. In particular, we need to keep the 7 May resolution in mind when evaluating policy proposals. Derya Cansever Program Director, Advanced Internet Technologies SI International -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Wettling, Fred Sent: Monday, March 17, 2008 12:12 PM To: ppml at arin.net Subject: Re: [ppml] 2008-2 IPv4 transfer policy I oppose Policy Proposal 2008-2 IPv4 Transfer Policy Proposal - Policy Section 8 Transfers is currently adequate - Transfer policy should continue to be protocol-agnostic. - 2008-2 does not reinforce the 7-May-07 ARIN resolution on "Internet Protocol Numbering Resources Availability" encouraging " migration to IPv6 numbering resources where possible" Fred Wettling - Bechtel Fellow _______________________________________________ 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 tvest at pch.net Mon Mar 17 15:44:48 2008 From: tvest at pch.net (Tom Vest) Date: Mon, 17 Mar 2008 15:44:48 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: References: <200803171616.m2HGG54f029086@cjbsys.bdb.com> <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> Message-ID: On Mar 17, 2008, at 1:15 PM, John Curran wrote: > At 12:45 PM -0400 3/17/08, Tom Vest wrote: >> >> Therefore I strongly recommend that the community reject this >> suggestion and get on with more realistic, sustainable alternatives. > > Tom - > > Could you succinctly express such an alternative? > > /John Hi John, I'll try to be as succinct as possible. To be viable, any solution will have to be able to maintain the "central registry" function over time. (by this I mean basically reverse delegations accurately associated with whois entries that are accurately associated with real-world institutions). There are multiple reasons why this is not optional, but I don't think they're particularly controversial (e.g., Geoff Huston also leads his presentation on APNIC's resource transfer proposal with the same requirement), so I'll skip them for now. In order to maintain this function over time -- at least at the "good enough" level -- the address delegation function must either be self- maintaining, as it is currently thanks to the unitary/hierarchical address distribution chain, RIR membership model, incremental address delegations, annual membership renewals, and surrounding community activities,* or else there must be some top-heavy post-facto verification and enforcement mechanisms. No sensible person would want the latter whenever the former can do the job. So, the trick is to design a mechanism that will deliver the desired outcome -- in this case I am assuming only some productive recirculation of relatively underused IPv4 address space -- and also permit the preservation of that critical registry function, all using only the kind of levers/overhead that the community can embrace (e.g., the ones in place now), and not the kind that it will rejected outright (e.g., the kind that Randy will scold me about). What sort of mechanisms might achieve this? Some kinds of implementations of Randy's oft-mentioned IP ebay might be able to do the job, e.g., if transparency can be maintained across all** resource transactions, and the data on all** transactions can be captured in the central registry. I happen to think that such a system would probably have unfortunate side effects (e.g., rapid deaggregation, pricing of many operator segments out of the existence, et al.), which may or may not be fatal. But those risks are understood and accepted, aren't they? I mean, wasn't the whole point of having all** delegation actions governed by the same rules and policies precisely to mitigate the risk that one community member's activities might undermine the whole system, or that some aspect of the aggregate results of all delegations might prompt community members to withdraw their support for the system, rather than trying to fix it? Once the checks go, the balances cannot hold, so I'm assuming that these risks are considered acceptable by advocates of market-based resource transfers. If the risks are not acceptable, then I can imagine a community policy-driven mechanism of centralized IPv4 recirculation that is driven by, alternately, increased recurring membership fees that increment based on actual IPv4 holdings, which could be wholly offset by much larger bounties that resource holders might earn by returning fractional portions of their IPv4 stocks back to the central pool for re-delegation.*** Such a system cannot be described any more succinctly than the 2008-02 system, so I'll hold off on details pending expressions of actual interest. But I do think that such a system could be much more effective at providing transitional IPv4 liquidity over the medium term, and also at preserving the central registry, while at the same time discouraging hoarding, speculation, massive inflation, closure of the industry to new entrants, external intervention, massive industry consolidation -- and also preserve the community/policy feedback loop -- and maybe even add marginally to the odds/pace of incremental IPv6 deployment. The thing that makes this approach quite politically challenging is that it would require that we all accept -- and literally start "recognizing" the costs of the reality of IPv4 free pool exhaustion somewhat before the last day that denial is still possible. By design, the first and greatest costs would fall on the largest resource holders, but presumably as a group they are much better capable of absorbing those costs, and certainly more capable of numbering out of some sub-critical segments and thereby reducing the cash cost of participating in the system to zero*** (note: one has to assume this anyway in order to believe that they're still going to be around and growing after IPv4 exhaustion, so this shouldn't be especially controversial). So, that's my alternative. I'm hoping that we can leverage the political/community capital that we've accumulated over the last decade-plus to avoid the economic mess that, I believe, is almost certainly waiting around the corner. I may be selectively naive about the political prospects of anything like this being acceptable. But even if that turns out to be true I'll consider the time well spent I can to help offset naivete about the economic prospects of decentralized, market-based resource transfers working as advertised. TV *Economists would describe these collateral activities as mechanisms that reduce or eliminate the need for expensive post-facto enforcement, and thereby help to reduce the overall "transaction costs" associated with maintenance of the central registry. **In real world this always means "mostly all", but if you don't set the bar somewhere, the only realistic goal is "random outcome". ***I haven't tried to work out exact ratios, but for the moment imagine an arrangement where the added renewal cost for a /8 could be completely offset by the bounty for returning a /16. From ipgoddess at gmail.com Mon Mar 17 16:09:27 2008 From: ipgoddess at gmail.com (Stacy Taylor) Date: Mon, 17 Mar 2008 13:09:27 -0700 Subject: [ppml] 2008-2 IPv4 transfer policy In-Reply-To: <1F9BA83F11C39A48926E3142EF4640F229A1EE63D5@us01mbx01.si.siroot.com> References: <200803131735.m2DHZMr7008071@cjbsys.bdb.com> <47D9782C.3020707@internap.com> <47DA7B9E.1070802@cjbsys.bdb.com> <1F9BA83F11C39A48926E3142EF4640F229A1EE63D5@us01mbx01.si.siroot.com> Message-ID: <1c16a4870803171309h4c74b31dx616b4189b669689e@mail.gmail.com> Derya and Fred, and Everyone Else,We did take both of your points into account in our discussions around the crafting of this policy. We decided not to ratchet up requirements for new v4 space, allowing it to 'just run out'. We also recommended to the Board that v6 fees continue to be waived to encourage v6 adoption. Hope this helps, Stacy On Mon, Mar 17, 2008 at 11:57 AM, Cansever, Derya < Derya.Cansever at si-intl.com> wrote: > I completely agree with all the points that Fred has raised. In > particular, we need to keep the 7 May resolution in mind when evaluating > policy proposals. > > Derya Cansever > Program Director, Advanced Internet Technologies SI International > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Wettling, Fred > Sent: Monday, March 17, 2008 12:12 PM > To: ppml at arin.net > Subject: Re: [ppml] 2008-2 IPv4 transfer policy > > I oppose Policy Proposal 2008-2 IPv4 Transfer Policy Proposal > - Policy Section 8 Transfers is currently adequate > - Transfer policy should continue to be protocol-agnostic. > - 2008-2 does not reinforce the 7-May-07 ARIN resolution on "Internet > Protocol Numbering Resources Availability" encouraging " migration to > IPv6 numbering resources where possible" > > Fred Wettling - Bechtel Fellow > _______________________________________________ > 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. > -- :):) /S -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrhett at svcolo.com Mon Mar 17 17:48:06 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Mon, 17 Mar 2008 14:48:06 -0700 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: References: <200803171616.m2HGG54f029086@cjbsys.bdb.com> <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> Message-ID: <484B8E2E-89AF-40B6-AF1C-07C50EFF4FE1@svcolo.com> On Mar 17, 2008, at 12:44 PM, Tom Vest wrote: > driven by, alternately, increased recurring membership fees that > increment based on actual IPv4 holdings, which could be wholly offset A large portion of the reasoning behind this policy was to get legacy IP holders to free up space. 1. They don't pay fees today, and wouldn't if we increased fees. 2. They would have less incentive to participate, as when they do this deal they have to sign the RSA. If the costs for their IP space increase, then they have less incentive to sign the RSA and thus, to participate. I think that a nice side effect of the proposed policy (might be) that we'd get more legacy holders to sign the RSA ;-) -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From tvest at pch.net Mon Mar 17 18:50:50 2008 From: tvest at pch.net (Tom Vest) Date: Mon, 17 Mar 2008 18:50:50 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <484B8E2E-89AF-40B6-AF1C-07C50EFF4FE1@svcolo.com> References: <200803171616.m2HGG54f029086@cjbsys.bdb.com> <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> <484B8E2E-89AF-40B6-AF1C-07C50EFF4FE1@svcolo.com> Message-ID: <09FC4D0A-8C3E-44FA-99A7-3D578E9F7F2F@pch.net> On Mar 17, 2008, at 5:48 PM, Jo Rhett wrote: > On Mar 17, 2008, at 12:44 PM, Tom Vest wrote: >> driven by, alternately, increased recurring membership fees that >> increment based on actual IPv4 holdings, which could be wholly offset > > A large portion of the reasoning behind this policy was to get > legacy IP holders to free up space. > > 1. They don't pay fees today, and wouldn't if we increased fees. > > 2. They would have less incentive to participate, as when they do > this deal they have to sign the RSA. If the costs for their IP > space increase, then they have less incentive to sign the RSA and > thus, to participate. > > I think that a nice side effect of the proposed policy (might be) > that we'd get more legacy holders to sign the RSA ;-) Hi Jo, Thanks for the feedback! I agree that that increasing formal participation in the community, including increased acceptance/ reduced rejection rates for the RSA, would be a good thing. My proto- proposal attempts to do this also, albeit coming from the other direction. Consider: anyone who has rejected the RSA to date, but intends to sign on to monetize their address resources, is probably motivated only by that revenue opportunity. If that's all they want, and the community and/or the law has determined that their wishes prevail, then I think we should acknowledge and grant that wish. Although the proto-proposal only obliges RSA signatories, and allows only RSA signatories to earn address return bounties, nothing precludes them from earning those bounties by buying up resources from RSA refuseniks, as opposed to internally renumbering. In other words, the idea sort of deputizes RSA signatories to do presumably exactly what they'll be doing anyway in the absence of some ironclad (i.e., probably expensive and heavy-handed) policy modifications -- i.e., scouring the Earth for purchasable address resources, as broadly and as vigorously as their size and budget permits. Thus, under the proto-proposal, RSA signatories could help to improve the participation rates by, in effect, buying up all of the idle resources held by operational and non-operational non-participants, and help to move those resources either back into the free pool for possible redelegation, or at least into the scope of RSAs of the bounty collectors themselves. In this sense, the imposition of "artificial"*, policy-determined bounties could help to set set the upper limit on prices that could be credibly demanded by non-signatories, thereby further reducing the potential for runaway inflation, speculation, hoarding, etc. So to me this seems like a feature and not a bug. Very grateful for any/all responses :-) TV *Private responders have suggested that that this way of setting prices is somehow "artificial", but given the fact that, to date, the idea of pricing address resources has no precedent makes this criticism ring a little hollow. Today, *all* price-related ideas are equally artificial -- so maybe the goal should be selecting the right artificial pricing mechanism to achieve the community's goals...? From jrhett at svcolo.com Mon Mar 17 19:15:16 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Mon, 17 Mar 2008 16:15:16 -0700 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <09FC4D0A-8C3E-44FA-99A7-3D578E9F7F2F@pch.net> References: <200803171616.m2HGG54f029086@cjbsys.bdb.com> <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> <484B8E2E-89AF-40B6-AF1C-07C50EFF4FE1@svcolo.com> <09FC4D0A-8C3E-44FA-99A7-3D578E9F7F2F@pch.net> Message-ID: <63CA1DAB-4F48-4955-B86E-1FDF4BD73BA0@svcolo.com> On Mar 17, 2008, at 3:50 PM, Tom Vest wrote: > In this sense, the imposition of "artificial"*, policy-determined > bounties could help to set set the upper limit on prices that could > be credibly demanded by non-signatories, thereby further reducing > the potential for runaway inflation, speculation, hoarding, etc. So > to me this seems like a feature and not a bug. I don't think that trying to control this market is possible. I certainly don't think that ARIN should waste time attempting to do so. If we do this, let's facilitate the process not encumber it. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From sleibrand at internap.com Mon Mar 17 20:35:27 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 17 Mar 2008 17:35:27 -0700 Subject: [ppml] Listing services In-Reply-To: References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D06585.2020402@apnic.net><47DD8B57.6090205@internap.com> <9DC9F13A-CECE-43FB-B786-B35371F41339@pch.net> Message-ID: <47DF0E4F.9040308@internap.com> michael.dillon at bt.com wrote: > How many of you have spent some time at http://www.sec.gov reading about > how properly run listing services operate? One other type of real-world listing service (that might be a better approximation of what we'd want for an IPv4 listing service) would be the various Multiple Listing Services (MLS) set up to list real estate. In fact, although I don't see anything on sec.gov about the subject, a quick Google search for "how a listing service operates" brings up the Wikipedia page for Multiple Listing Service as the first hit, as well as some other examples of listing services, such as apartments, commercial real estate, etc. I agree that we have a lot to learn about listing services before we set one up. Part of the reason 2008-02 was written the way it was, with just a single statement that "ARIN will develop and operate a listing service ..." was that any attempts to define how the listing service might operate at this point would be premature. In addition, how the listing service would operate is probably more an operational matter than a matter of policy. Of course, that doesn't detract from the importance of doing it right, so I would expect that ARIN would hire experts on the topic to make sure they take advantage of the expertise of someone who has set up a similar system before. -Scott From tvest at pch.net Mon Mar 17 20:41:12 2008 From: tvest at pch.net (Tom Vest) Date: Mon, 17 Mar 2008 20:41:12 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <63CA1DAB-4F48-4955-B86E-1FDF4BD73BA0@svcolo.com> References: <200803171616.m2HGG54f029086@cjbsys.bdb.com> <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> <484B8E2E-89AF-40B6-AF1C-07C50EFF4FE1@svcolo.com> <09FC4D0A-8C3E-44FA-99A7-3D578E9F7F2F@pch.net> <63CA1DAB-4F48-4955-B86E-1FDF4BD73BA0@svcolo.com> Message-ID: <5727B05F-A3FA-4EC6-B2C2-C87A86B5DE86@pch.net> On Mar 17, 2008, at 7:15 PM, Jo Rhett wrote: > On Mar 17, 2008, at 3:50 PM, Tom Vest wrote: >> In this sense, the imposition of "artificial"*, policy-determined >> bounties could help to set set the upper limit on prices that >> could be credibly demanded by non-signatories, thereby further >> reducing the potential for runaway inflation, speculation, >> hoarding, etc. So to me this seems like a feature and not a bug. > > I don't think that trying to control this market is possible. I > certainly don't think that ARIN should waste time attempting to do so. > > If we do this, let's facilitate the process not encumber it. Hi Jo, Since you chose to extract that lone passage to respond to, and to leave out my *explanatory note*, I feel obliged to respond: Which "market" exactly are you referring to? Since no market has been commissioned yet, and none of any size is apparent to me at the moment, which "market" specifically are you seeing, or predicting to be absolutely inevitable and uncontrollable? Why should other community members adopt such a fatalistic attitude in this particular case, rather then doing what they have always done in the past, i.e., try to adopt to changing circumstances in a way that best preserves the goals and values of an open Internet, and leaves the open possibility of additional adjustments and/or improvements and/or corrections down the line? It makes sense to say something like this if you actively embrace whichever "market" you foresee as the future of choice for yourself. But if that's the case, clarity would be better served by simply declaring your support for it (and clearly bracketing what "it" is), rather than claiming that it's inevitable without some supporting reasoning. TV, who regrets all past ambiguities and pledges to be as clear as possible for the remainder of this debate... From jrhett at svcolo.com Mon Mar 17 21:08:21 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Mon, 17 Mar 2008 18:08:21 -0700 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <5727B05F-A3FA-4EC6-B2C2-C87A86B5DE86@pch.net> References: <200803171616.m2HGG54f029086@cjbsys.bdb.com> <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> <484B8E2E-89AF-40B6-AF1C-07C50EFF4FE1@svcolo.com> <09FC4D0A-8C3E-44FA-99A7-3D578E9F7F2F@pch.net> <63CA1DAB-4F48-4955-B86E-1FDF4BD73BA0@svcolo.com> <5727B05F-A3FA-4EC6-B2C2-C87A86B5DE86@pch.net> Message-ID: <130DB240-8896-4EFE-854F-E4DF6CDAE4E9@svcolo.com> On Mar 17, 2008, at 5:41 PM, Tom Vest wrote: > Since you chose to extract that lone passage to respond to, and to > leave out my *explanatory note*, I feel obliged to respond: Because I hate people that quote 70+ lines of text. If someone wants to read everything you wrote they can find the original in their mailer. And in this case, it doesn't matter. This lone paragraph said exactly what concerned me -- trying to dictate pricing to the market. That's all I was responding to. > Which "market" exactly are you referring to? Since no market has > been commissioned yet, and [snip] No idea. I didn't give your proposal much consideration after I saw that you wanted to dictate pricing to whatever market you imagined. At that point I knew it made no sense. > It makes sense to say something like this if you actively embrace > whichever "market" you foresee as the future of choice for > yourself. But if that's the case, clarity would be better served by > simply declaring your support for it (and clearly bracketing what > "it" is), rather than claiming that it's inevitable without some > supporting reasoning. I haven't the vaguest idea what you are babbling about here, sorry. I am not defining a market, nor do I support a market, etc etc etc. All I said was that if we ran out of IP space and ARIN decided to facilitate transfers of allocated space, that trying to mandate pricing to the participants was madness. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From mpetach at netflight.com Mon Mar 17 21:20:57 2008 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 17 Mar 2008 18:20:57 -0700 Subject: [ppml] Policy Proposal 2008-3: Community Networks IPv6 Allocation In-Reply-To: <47CD739B.3060905@arin.net> References: <47CD739B.3060905@arin.net> Message-ID: <63ac96a50803171820n6b24d9dax9d59de98209a4dd1@mail.gmail.com> On 3/4/08, Member Services wrote: > On 21 February 2008, the ARIN Advisory Council (AC) concluded its review > of "Community Networks IPv6 Allocation" and accepted it as a formal > policy proposal with the condition that the policy text be revised by > the author so that it can be put into the ARIN Number Resource Policy > Manual. The author submitted a revised version of the proposal. ... > Policy Proposal 2008-3 > Community Networks IPv6 Allocation > Author: Joshua King > Proposal Version: 1 > Date: 4 March 2008 > Proposal type: new > Policy term: permanent > Policy statement: > > [Add Section 2.8 to the NRPM.] > 2.8 Community Network > > A community network is a generic reference to any network that is > operated by a group of people living in a particular local area > organized for the purposes of delivery or provision of network services > to the residents of an incorporated or unincorporated regional > municipality, city, town, village, rural municipality, township, county, > district or other municipality or other such geographic space, however > designated. > > [Modify 6.5.8.1b as follows.] > > b. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 > policy currently in effect or be a Community Network as defined in > Section 2.8. > > Rationale: > > There are currently a number of projects globally that aim to develop > community network infrastructure and related technologies. These are > usually coordinated by volunteer-run, grassroots organizations which > lack many of the resources of traditional internet service providers and > other network operators. They have diverse goals, including public > policy, software development, and implementation of community services > and resources. Many of them provide services free of charge, and thus > lack any paying user base. However, in order to create and maintain > community networks that are often composed of hundreds if not thousands > of inexpensive, commodity hosts and devices, a significant amount of > address space will be required. Current-generation workarounds to this > problem, such as NAT, not only make it difficult to develop > next-generation decentralized network technology by segmenting the > community's architecture from the Internet as a whole, but will cease to > be as viable a stopgap as the Internet moves towards IPv6 integration. > > Even now, common community networking software solutions such as > CUWiNware (http://www.cuwin.net) and Freifunk (http://www.freifunk.at) > have nascent IPv6 addressing support, but participating organizations > lack the address space for widespread testing or adoption. As such, it > is necessary to implement an procedure as soon as possible for these That should be "implement a procedure" rather than "an procedure". > segregated networks to acquire address space. These organizations do not > meet the criteria traditionally defined for LIR's, and thus cannot > acquire address allocations through existing templates. By establishing > a procedure by which these organizations can seek to acquire the > resources they require for further development, ARIN can reach out to > this active community and establish a small but definite space for them > in the future of Internet. If they are "segregated networks", would they require globally routable addresses, or would non-routed space be adequate for them? It would seem that if they are obtaining external connectivity from an upstream provider, it would be more appropriate for their upstream provider to provide space for them; if they're not going to obtain external connectivity, but really are going to remain a "segregated network", then would they really need to obtain a public allocation from ARIN, or could they simply make use of the FC00::/7 prefix for Unique Local IPv6 Address space (ULA) and the SixXS registry to track their ULA space per RFC 4193 ? It seems like this issue has already been solved; I'm not understanding why a new policy is needed to differentiate community networks from any other type of networks. > Timetable for implementation: Immediate. Matt From tvest at pch.net Mon Mar 17 21:28:52 2008 From: tvest at pch.net (Tom Vest) Date: Mon, 17 Mar 2008 21:28:52 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <130DB240-8896-4EFE-854F-E4DF6CDAE4E9@svcolo.com> References: <200803171616.m2HGG54f029086@cjbsys.bdb.com> <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> <484B8E2E-89AF-40B6-AF1C-07C50EFF4FE1@svcolo.com> <09FC4D0A-8C3E-44FA-99A7-3D578E9F7F2F@pch.net> <63CA1DAB-4F48-4955-B86E-1FDF4BD73BA0@svcolo.com> <5727B05F-A3FA-4EC6-B2C2-C87A86B5DE86@pch.net> <130DB240-8896-4EFE-854F-E4DF6CDAE4E9@svcolo.com> Message-ID: <8B4988BE-BAAB-4BE4-B2AF-B4113E5EB037@pch.net> On Mar 17, 2008, at 9:08 PM, Jo Rhett wrote: > On Mar 17, 2008, at 5:41 PM, Tom Vest wrote: >> Since you chose to extract that lone passage to respond to, and to >> leave out my *explanatory note*, I feel obliged to respond: > > Because I hate people that quote 70+ lines of text. If someone > wants to read everything you wrote they can find the original in > their mailer. And in this case, it doesn't matter. This lone > paragraph said exactly what concerned me -- trying to dictate > pricing to the market. That's all I was responding to. > >> Which "market" exactly are you referring to? Since no market has >> been commissioned yet, and > [snip] > > No idea. I didn't give your proposal much consideration after I > saw that you wanted to dictate pricing to whatever market you > imagined. At that point I knew it made no sense. > >> It makes sense to say something like this if you actively embrace >> whichever "market" you foresee as the future of choice for >> yourself. But if that's the case, clarity would be better served >> by simply declaring your support for it (and clearly bracketing >> what "it" is), rather than claiming that it's inevitable without >> some supporting reasoning. > > I haven't the vaguest idea what you are babbling about here, > sorry. I am not defining a market, nor do I support a market, etc > etc etc. > > All I said was that if we ran out of IP space and ARIN decided to > facilitate transfers of allocated space, that trying to mandate > pricing to the participants was madness. I think you got it just about right. If we run out of address space and ARIN decides to legitimize decentralized number resource transfers, then trying to maintain any policies, or policy processes or oversight of any kind would be madness. I agree with you -- which is why I'm suggesting something entirely different which, I believe, does not suffer from that same fatal flaw. TV From jrhett at svcolo.com Mon Mar 17 21:31:34 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Mon, 17 Mar 2008 18:31:34 -0700 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <8B4988BE-BAAB-4BE4-B2AF-B4113E5EB037@pch.net> References: <200803171616.m2HGG54f029086@cjbsys.bdb.com> <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> <484B8E2E-89AF-40B6-AF1C-07C50EFF4FE1@svcolo.com> <09FC4D0A-8C3E-44FA-99A7-3D578E9F7F2F@pch.net> <63CA1DAB-4F48-4955-B86E-1FDF4BD73BA0@svcolo.com> <5727B05F-A3FA-4EC6-B2C2-C87A86B5DE86@pch.net> <130DB240-8896-4EFE-854F-E4DF6CDAE4E9@svcolo.com> <8B4988BE-BAAB-4BE4-B2AF-B4113E5EB037@pch.net> Message-ID: <24726FDD-0CFD-4520-9DF2-2AE258090382@svcolo.com> On Mar 17, 2008, at 6:28 PM, Tom Vest wrote: > I think you got it just about right. If we run out of address space > and ARIN decides to legitimize decentralized number resource > transfers, then trying to maintain any policies, or policy > processes or oversight of any kind would be madness. I agree with > you -- which is why I'm suggesting something entirely different > which, I believe, does not suffer from that same fatal flaw. I don't agree with this statement. And you've given no explanation for why you feel this wouldn't work, either. Perhaps you should elaborate on your meaning of that. And if you want to suggest something entirely different, provide a draft. (and change the subject line) -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From randy at psg.com Mon Mar 17 21:36:16 2008 From: randy at psg.com (Randy Bush) Date: Tue, 18 Mar 2008 10:36:16 +0900 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <484B8E2E-89AF-40B6-AF1C-07C50EFF4FE1@svcolo.com> References: <200803171616.m2HGG54f029086@cjbsys.bdb.com> <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> <484B8E2E-89AF-40B6-AF1C-07C50EFF4FE1@svcolo.com> Message-ID: <47DF1C90.4070204@psg.com> > A large portion of the reasoning behind this policy was to get legacy > IP holders to free up space. precisely. the goal of a market is to get goods to 'best use.' and despite fred's assertion, the current transfer policy does not do that. if it did, folk such as arin's lawyer would not be vilifying legacy holders from the nanog stage. randy From tvest at pch.net Mon Mar 17 21:47:18 2008 From: tvest at pch.net (Tom Vest) Date: Mon, 17 Mar 2008 21:47:18 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <24726FDD-0CFD-4520-9DF2-2AE258090382@svcolo.com> References: <200803171616.m2HGG54f029086@cjbsys.bdb.com> <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> <484B8E2E-89AF-40B6-AF1C-07C50EFF4FE1@svcolo.com> <09FC4D0A-8C3E-44FA-99A7-3D578E9F7F2F@pch.net> <63CA1DAB-4F48-4955-B86E-1FDF4BD73BA0@svcolo.com> <5727B05F-A3FA-4EC6-B2C2-C87A86B5DE86@pch.net> <130DB240-8896-4EFE-854F-E4DF6CDAE4E9@svcolo.com> <8B4988BE-BAAB-4BE4-B2AF-B4113E5EB037@pch.net> <24726FDD-0CFD-4520-9DF2-2AE258090382@svcolo.com> Message-ID: <20543AF9-7A69-4F5D-91CC-3B7C7D86B2CF@pch.net> On Mar 17, 2008, at 9:31 PM, Jo Rhett wrote: > On Mar 17, 2008, at 6:28 PM, Tom Vest wrote: >> I think you got it just about right. If we run out of address >> space and ARIN decides to legitimize decentralized number resource >> transfers, then trying to maintain any policies, or policy >> processes or oversight of any kind would be madness. I agree with >> you -- which is why I'm suggesting something entirely different >> which, I believe, does not suffer from that same fatal flaw. > > I don't agree with this statement. And you've given no explanation > for why you feel this wouldn't work, either. Perhaps you should > elaborate on your meaning of that. Well played ;-) Actually, I gave detailed reasoning for this in my response to John a few hours ago. I could quote that message back to you at length, but I hear that some people don't like that -- and anyway I know you already have that email; it was the one you responded to, briefly, at 5:48:06 PM EDT... > And if you want to suggest something entirely different, provide a > draft. (and change the subject line) I am not going to waste my time doing that unless there is some expression of genuine interest. Reading back a little, you may note that I introduced this idea only reluctantly, at John's explicit request. If there is no further interest I am quite happy to return to the regularly scheduled discussion of 2008-02 -- which is where this thread began. TV From cliffb at cjbsys.bdb.com Mon Mar 17 22:20:13 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Mon, 17 Mar 2008 22:20:13 -0400 (EDT) Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 Message-ID: <200803180220.m2I2KDqb003250@cjbsys.bdb.com> Regarding a "market" for IPv4 addresses, I still have not heard any disadvantage to ARIN staying completely out of the market part and just have a policy that allows one more method of acquiring addresses. As I understand current policy, there are basically two ways to get addresses 1) Ask ARIN with appropriate justification 2) Buy/merge with a company and get the addresses as a part of that transaction (again with some justification to ARIN It seems to me that all that 2008-2 needs to do is add a third method once the IANA free pool is gone. 3) Party 1 offers to transfer to Party 2 some block of addresses. Party 1 has the right to offer and Party 2 justifies the right to receive the addresses. No market, no ARIN involvement with SEC, just ARIN approving use of a block of addresses. Why is this not a simple way to handle the end of life address management of v4 addresses? ARIN gets their fees just like now so they remain viable but have no interaction with the "market" and its associated problems. Cliff -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From jcurran at istaff.org Tue Mar 18 00:32:23 2008 From: jcurran at istaff.org (John Curran) Date: Tue, 18 Mar 2008 00:32:23 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <47DF1C90.4070204@psg.com> References: <200803171616.m2HGG54f029086@cjbsys.bdb.com> <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> <484B8E2E-89AF-40B6-AF1C-07C50EFF4FE1@svcolo.com> <47DF1C90.4070204@psg.com> Message-ID: At 10:36 AM +0900 3/18/08, Randy Bush wrote: > > A large portion of the reasoning behind this policy was to get legacy >> IP holders to free up space. > >precisely. the goal of a market is to get goods to 'best use.' and >despite fred's assertion, the current transfer policy does not do that. >if it did, folk such as arin's lawyer would not be vilifying legacy >holders from the nanog stage. That's not necessarily a defect in the current transfer policy as much as a failing (of those who have more address space than they require) not returning the excess to the IANA. /John From randy at psg.com Tue Mar 18 00:45:04 2008 From: randy at psg.com (Randy Bush) Date: Tue, 18 Mar 2008 13:45:04 +0900 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: References: <200803171616.m2HGG54f029086@cjbsys.bdb.com> <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> <484B8E2E-89AF-40B6-AF1C-07C50EFF4FE1@svcolo.com> <47DF1C90.4070204@psg.com> Message-ID: <47DF48D0.9080201@psg.com> >>> A large portion of the reasoning behind this policy was to get legacy >>> IP holders to free up space. >> precisely. the goal of a market is to get goods to 'best use.' and >> despite fred's assertion, the current transfer policy does not do that. >> if it did, folk such as arin's lawyer would not be vilifying legacy >> holders from the nanog stage. > That's not necessarily a defect in the current transfer policy as > much as a failing (of those who have more address space than > they require) not returning the excess to the IANA. ahhh, the socialist economy planners know best. cool! randy From tvest at pch.net Tue Mar 18 00:21:11 2008 From: tvest at pch.net (Tom Vest) Date: Tue, 18 Mar 2008 00:21:11 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <200803180220.m2I2KDqb003250@cjbsys.bdb.com> References: <200803180220.m2I2KDqb003250@cjbsys.bdb.com> Message-ID: <074A54DA-B52F-49B7-9376-3026BFFD1615@pch.net> On Mar 17, 2008, at 10:20 PM, Cliff Bedore wrote: > Regarding a "market" for IPv4 addresses, I still have not heard any > disadvantage to ARIN staying completely out of the market part and > just have a > policy that allows one more method of acquiring addresses. > > As I understand current policy, there are basically two ways to get > addresses > > 1) Ask ARIN with appropriate justification > > 2) Buy/merge with a company and get the addresses as a part of that > transaction (again with some justification to ARIN > > It seems to me that all that 2008-2 needs to do is add a third > method once the > IANA free pool is gone. > > 3) Party 1 offers to transfer to Party 2 some block of addresses. > Party 1 > has the right to offer and Party 2 justifies the right to receive the > addresses. No market, no ARIN involvement with SEC, just ARIN > approving use > of a block of addresses. > > Why is this not a simple way to handle the end of life address > management of > v4 addresses? ARIN gets their fees just like now so they remain > viable but > have no interaction with the "market" and its associated problems. > > Cliff Basically this is the simple way, but it will not work -- technically it cannot work. This is because the arrangement you describe requires the same incentives to operate in multiple, simultaneous, but mutually contradictory ways -- more or less like this: 1. First, eliminate the single source mechanism for address delegation. Henceforth anyone may potentially be a buyer or seller of address resources, as they see fit. 2. Next, allow market forces to govern the address delegation function -- i.e., engage everyone's well-honed instincts to spend less and profit more, and allow the overall distribution of address resource be determined and legitimated by that market process. 3. Having empowered everyone this way, and fired up those competitive juices, also make sure that under certain defined circumstances, everyone always ignores both their new sovereign prerogatives and their newly engaged, otherwise-unrestricted market instincts, and voluntarily accept extra costs, restrictions on when and under what circumstances they may act, etc. 4. Make sure that they follow these rules and pay these extra costs in 100% of the required circumstances. Also assure that everyone takes the extra effort to inform some now distant, formerly critical institution of the results of their actions -- for whatever reason. 5. This is a decentralized, market-driven system, but unlike every other market in human history all rules are purely voluntary, and no other enforcement mechanisms will ever exist. Make it work anyway. If that illustration doesn't work, maybe this one will: Basically the arrangement you describe would be like vehicle insurance in the US. We all know that, if we can afford it, auto insurance tends to protect us from somewhat from extreme risks. We also probably have a vague sense that the insurance we pay for also helps to protect other drivers too -- although that's hardly a motivating factor for us to buy in. But some people simply can't afford it, and some are forgetful and let their coverage lapse, and some people just like to live dangerously, damn the consequences for themselves and everyone else. The Insurance Research Council estimates that 15-16% of all vehicles on US roads at any given time (c. 2007) were uninsured. Lucky for US drivers, there is no Department of Homeland Insurance that might be called in to rectify the situation in case uninsured, anonymous motorists start crashing into important things, or if that compliance rate drops too low. We do not enjoy the same luxury. I can't make the case any more clearly. I would also like the simple way to work, but wishing it will not make it so. TV From owen at delong.com Tue Mar 18 00:59:57 2008 From: owen at delong.com (Owen DeLong) Date: Mon, 17 Mar 2008 21:59:57 -0700 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <47DF1C90.4070204@psg.com> References: <200803171616.m2HGG54f029086@cjbsys.bdb.com> <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> <484B8E2E-89AF-40B6-AF1C-07C50EFF4FE1@svcolo.com> <47DF1C90.4070204@psg.com> Message-ID: <58833B78-3D50-4B75-9D34-4ED318C3140F@delong.com> > precisely. the goal of a market is to get goods to 'best use.' and > despite fred's assertion, the current transfer policy does not do > that. > if it did, folk such as arin's lawyer would not be vilifying legacy > holders from the nanog stage. I would not characterize anything Steve or Ben have said as vilifying legacy holders. I believe most of the vilification has come from sources primarily external to ARIN. Owen From mike at mathbox.com Tue Mar 18 02:30:04 2008 From: mike at mathbox.com (Michael Thomas - Mathbox) Date: Tue, 18 Mar 2008 02:30:04 -0400 Subject: [ppml] 2008-2 Message-ID: <00cc01c888c1$80aebca0$033045d0@mathbox.net> Hi All, Let me see if I understand this policy proposal. During discussions of the fairness to members of IP address allocation cost brackets, it was argued by various people that: - IP addresses were just a resource and had no intrinsic value - ARIN fees reflected the cost to support services required by the members A few months ago ARIN had 70 plus members holding approximately 79% of all ARIN non-legacy resources or approximately 970,000 /24. Of those 970,000 /24, those 70 plus X-Large members have to pay fees on only approximately 140,000 /24. Which means that approximately 730,000 /24 are controlled by those X-Large members are free of charge. In the X-Large bracket, those 140,000 /24 cost about $.34 each. In the highest cost bracket, a /24 costs about $324.00 each. Although I will not claim knowledge of exact dates, but it seems to me that several individuals have been predicting IPv4 exhaustion for more than 10 years. Now a policy should exist for the marketing of those IP resource which have no intrinsic value and which are still being allocated free of charge. If it wasn't so funny, I might be irritated. Michael Thomas Mathbox 978-687-3300 1-877-MATHBOX (Toll Free) From michael.dillon at bt.com Tue Mar 18 07:03:42 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 18 Mar 2008 11:03:42 -0000 Subject: [ppml] Listing services In-Reply-To: <47DF0E4F.9040308@internap.com> References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D06585.2020402@apnic.net><47DD8B57.6090205@internap.com> <9DC9F13A-CECE-43FB-B786-B35371F41339@pch.net> <47DF0E4F.9040308@internap.com> Message-ID: > One other type of real-world listing service (that might be a > better approximation of what we'd want for an IPv4 listing > service) would be the various Multiple Listing Services (MLS) > set up to list real estate. Those listing services sell real property. If IP addresses are to considered as real property, then the owners of those addresses can choose to sell them privately or through whatever listing service that they wish. Interestingly, in Canada west of Ontario, there is no such thing as a real-estate deed or title document. The legal owner of a piece of property is the person who is recorded in the land registry, and when real-estate is sold, the key moment is when the lawyers exchange the money *AND* change the listing in the official registry. If you want to know who owns a piece of land, simply give the provincial government agent ten bucks (probably more by now) for a copy of the entry in the land registry. Liens against the property and rights-of-way (electric power lines, gas lines) are all recorded in the registry. So, given that IPv6 now exists and has an ABUNDANT supply of addresses, it may be reasonable to declare all IP addresses to be property which can be bought and sold. IPv4 addresses might be valued at 5 bucks apiece while IPv6 addresses are valued at 10,000 per penny. > I agree that we have a lot to learn about listing services > before we set one up. This is the main reason why I think that it is too late to implement some kind of market with the prime, or only goal of mitigating the impact of IPv4 runout. > Of course, that doesn't detract > from the importance of doing it right, so I would expect that > ARIN would hire experts on the topic to make sure they take > advantage of the expertise of someone who has set up a > similar system before. It is all too easy to either hire the wrong sort of experts, or to give them the wrong instructions because you don't fully understand the implications of your plans. In fact if you don't already have expertise in an area, it's all too common to hire conmen rather than true experts. My point here is that we all need to bring ourselves up to a certain minimum level of competence in regards to "markets" in order to make reasonable decisions about creating one. I believe the current proposal was created with much too narrow a viewpoint. --Michael Dillon From sascha at aya.yale.edu Tue Mar 18 09:36:57 2008 From: sascha at aya.yale.edu (Sascha Meinrath) Date: Tue, 18 Mar 2008 09:36:57 -0400 Subject: [ppml] Policy Proposal 2008-3: Community Networks IPv6 Allocation In-Reply-To: References: Message-ID: <47DFC579.4090300@aya.yale.edu> Hi Matthew, Thanks for the feedback. Some comments are below. > Date: Mon, 17 Mar 2008 18:20:57 -0700 > From: "Matthew Petach" > Subject: Re: [ppml] Policy Proposal 2008-3: Community Networks IPv6 > Allocation > To: "Member Services" > Cc: ppml at arin.net > > On 3/4/08, Member Services wrote: >> On 21 February 2008, the ARIN Advisory Council (AC) concluded its review >> of "Community Networks IPv6 Allocation" and accepted it as a formal >> policy proposal with the condition that the policy text be revised by >> the author so that it can be put into the ARIN Number Resource Policy >> Manual. The author submitted a revised version of the proposal. > ... >> Policy Proposal 2008-3 >> Community Networks IPv6 Allocation >> Author: Joshua King >> Proposal Version: 1 >> Date: 4 March 2008 >> Proposal type: new >> Policy term: permanent >> Policy statement: >> >> [Add Section 2.8 to the NRPM.] >> 2.8 Community Network >> >> A community network is a generic reference to any network that is >> operated by a group of people living in a particular local area >> organized for the purposes of delivery or provision of network services >> to the residents of an incorporated or unincorporated regional >> municipality, city, town, village, rural municipality, township, county, >> district or other municipality or other such geographic space, however >> designated. >> >> [Modify 6.5.8.1b as follows.] >> >> b. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 >> policy currently in effect or be a Community Network as defined in >> Section 2.8. >> >> Rationale: >> >> There are currently a number of projects globally that aim to develop >> community network infrastructure and related technologies. These are >> usually coordinated by volunteer-run, grassroots organizations which >> lack many of the resources of traditional internet service providers and >> other network operators. They have diverse goals, including public >> policy, software development, and implementation of community services >> and resources. Many of them provide services free of charge, and thus >> lack any paying user base. However, in order to create and maintain >> community networks that are often composed of hundreds if not thousands >> of inexpensive, commodity hosts and devices, a significant amount of >> address space will be required. Current-generation workarounds to this >> problem, such as NAT, not only make it difficult to develop >> next-generation decentralized network technology by segmenting the >> community's architecture from the Internet as a whole, but will cease to >> be as viable a stopgap as the Internet moves towards IPv6 integration. >> >> Even now, common community networking software solutions such as >> CUWiNware (http://www.cuwin.net) and Freifunk (http://www.freifunk.at) >> have nascent IPv6 addressing support, but participating organizations >> lack the address space for widespread testing or adoption. As such, it >> is necessary to implement an procedure as soon as possible for these > > That should be "implement a procedure" rather than "an procedure". Correct. >> segregated networks to acquire address space. These organizations do not >> meet the criteria traditionally defined for LIR's, and thus cannot >> acquire address allocations through existing templates. By establishing >> a procedure by which these organizations can seek to acquire the >> resources they require for further development, ARIN can reach out to >> this active community and establish a small but definite space for them >> in the future of Internet. > > If they are "segregated networks", would they require globally routable > addresses, or would non-routed space be adequate for them? One of the (admittedly myriad) reasons for globally routable addresses is that these segregated networks are rapidly being interconnected to form larger and larger systems. Two examples of this process include the COMMONS Project (see: http://www.caida.org/projects/commons) and the Intercity VPN Project (see: http://wiki.freifunk.net/IC-VPN). Globally routable addresses would greatly facilitate interconnectivity since internal IP space can conflict. > It would seem that if they are obtaining external connectivity from > an upstream provider, it would be more appropriate for their upstream > provider to provide space for them; if they're not going to obtain > external connectivity, but really are going to remain a "segregated > network", then would they really need to obtain a public > allocation from ARIN, or could they simply make use of the > FC00::/7 prefix for Unique Local IPv6 Address space (ULA) > and the SixXS registry to track their ULA space per RFC 4193 > ? Community wireless networks (CWNs) are often both standalone _and_ interconnected (i.e., they function as large-scale geographically-based LANS and integrate with the larger Internet). Furthermore, CWNs often receive bandwidth from several (sometimes numerous) different ISPs -- as multi-gateway support gets proofed out (it's already being trialed on several networks), this will certainly increase. Because of this, reliance on ISP-allocated IPs won't work. In addition, device-as-infrastructure networking technologies are rapidly being developed that will automatically bridge between ad-hoc and interconnected (with the CWN) modes. In ad-hoc mode these devices need a way to automatically assign IPs (thus also the reason for unique IPs) -- one can't always assume external connectivity (or stable external connectivity). > It seems like this issue has already been solved; I'm not > understanding why a new policy is needed to differentiate > community networks from any other type of networks. I hope this helps address your feedback, but let me know. --Sascha >> Timetable for implementation: Immediate. > > Matt From info at arin.net Tue Mar 18 10:45:09 2008 From: info at arin.net (Member Services) Date: Tue, 18 Mar 2008 10:45:09 -0400 Subject: [ppml] ARIN XXI Remote Participation and Webcast Message-ID: <47DFD575.2070207@arin.net> Are you unable to join us in Denver for ARIN XXI? We have a solution! To facilitate community participation, ARIN offers free remote participation to any individual. Registered remote participants may post questions or comments, via e-mail, which will be moderated and presented during normal question and answer periods throughout the agenda. All ARIN XXI activities involving public participation and comment, including the Sunday sessions on the Legacy RSA, Introduction to IRPEP and the Open Policy Hour, as well as the ARIN Public Policy and Members Meetings will be webcast, but only remote registrants will be able to submit questions and comments. All remote participants are subject to the Remote Participation Acceptable Use Policy (AUP). Registration for remote participation is available through our online meeting registration system. To register, please visit the ARIN XXI home page: http://www.arin.net/ARIN-XXI/, click the "Register for the Meeting" button at the top of the page, choose "ARIN XXI Remote Participant" from the drop-down box, and complete the subsequent form. The live meeting webcast is available without registering as a remote participant. Additional information about remote participation and the webcast, including the Remote Participation AUP, is available at: http://www.arin.net/ARIN-XXI/webcast.html Webcast access details will be posted through the link above before the meeting. The webcast will begin Sunday, 6 April 2008 at 3:00 PM MDT (UTC/GMT -6 hours). Regards, Member Services American Registry for Internet Numbers (ARIN) From cliffb at cjbsys.bdb.com Tue Mar 18 11:11:47 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Tue, 18 Mar 2008 11:11:47 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <074A54DA-B52F-49B7-9376-3026BFFD1615@pch.net> References: <200803180220.m2I2KDqb003250@cjbsys.bdb.com> <074A54DA-B52F-49B7-9376-3026BFFD1615@pch.net> Message-ID: <47DFDBB3.4070009@cjbsys.bdb.com> Tom Vest wrote: > > On Mar 17, 2008, at 10:20 PM, Cliff Bedore wrote: > >> Regarding a "market" for IPv4 addresses, I still have not heard any >> disadvantage to ARIN staying completely out of the market part and >> just have a >> policy that allows one more method of acquiring addresses. >> >> As I understand current policy, there are basically two ways to get >> addresses >> >> 1) Ask ARIN with appropriate justification >> >> 2) Buy/merge with a company and get the addresses as a part of that >> transaction (again with some justification to ARIN >> >> It seems to me that all that 2008-2 needs to do is add a third method >> once the >> IANA free pool is gone. >> >> 3) Party 1 offers to transfer to Party 2 some block of addresses. >> Party 1 >> has the right to offer and Party 2 justifies the right to receive the >> addresses. No market, no ARIN involvement with SEC, just ARIN >> approving use >> of a block of addresses. >> >> Why is this not a simple way to handle the end of life address >> management of >> v4 addresses? ARIN gets their fees just like now so they remain >> viable but >> have no interaction with the "market" and its associated problems. >> >> Cliff > > Basically this is the simple way, but it will not work -- technically > it cannot work. This is because the arrangement you describe requires > the same incentives to operate in multiple, simultaneous, but mutually > contradictory ways -- more or less like this: > > 1. First, eliminate the single source mechanism for address > delegation. Henceforth anyone may potentially be a buyer or seller of > address resources, as they see fit. We're not eliminating the single source. Like the title for your car from the DMV, it goes through one and only one place. > > 2. Next, allow market forces to govern the address delegation function > -- i.e., engage everyone's well-honed instincts to spend less and > profit more, and allow the overall distribution of address resource be > determined and legitimated by that market process. SO? > > 3. Having empowered everyone this way, and fired up those competitive > juices, also make sure that under certain defined circumstances, > everyone always ignores both their new sovereign prerogatives and > their newly engaged, otherwise-unrestricted market instincts, and > voluntarily accept extra costs, restrictions on when and under what > circumstances they may act, etc. Doesn't happen in what I describe. > > 4. Make sure that they follow these rules and pay these extra costs in > 100% of the required circumstances. Also assure that everyone takes > the extra effort to inform some now distant, formerly critical > institution of the results of their actions -- for whatever reason. Doesn't happen in what I describe > > 5. This is a decentralized, market-driven system, but unlike every > other market in human history all rules are purely voluntary, and no > other enforcement mechanisms will ever exist. Make it work anyway. Not decentralized. Not a market. Simply one more way in which addresses may be obtained from/through ARIN > > If that illustration doesn't work, maybe this one will: > > Basically the arrangement you describe would be like vehicle insurance > in the US. We all know that, if we can afford it, auto insurance tends > to protect us from somewhat from extreme risks. We also probably have > a vague sense that the insurance we pay for also helps to protect > other drivers too -- although that's hardly a motivating factor for us > to buy in. But some people simply can't afford it, and some are > forgetful and let their coverage lapse, and some people just like to > live dangerously, damn the consequences for themselves and everyone else. Not like insurance. Much more like the DMV. > > The Insurance Research Council estimates that 15-16% of all vehicles > on US roads at any given time (c. 2007) were uninsured. Lucky for US > drivers, there is no Department of Homeland Insurance that might be > called in to rectify the situation in case uninsured, anonymous > motorists start crashing into important things, or if that compliance > rate drops too low. We do not enjoy the same luxury. People hijack addresses now for various reasons. I even had one of mine hijacked years ago. But it got fixed within the existing system. > > I can't make the case any more clearly. I would also like the simple > way to work, but wishing it will not make it so. Then I guess I give up because I still don't understand your examples or why what I put forth won't work. > > TV > Cliff From tvest at pch.net Tue Mar 18 12:19:58 2008 From: tvest at pch.net (Tom Vest) Date: Tue, 18 Mar 2008 12:19:58 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <47DFDBB3.4070009@cjbsys.bdb.com> References: <200803180220.m2I2KDqb003250@cjbsys.bdb.com> <074A54DA-B52F-49B7-9376-3026BFFD1615@pch.net> <47DFDBB3.4070009@cjbsys.bdb.com> Message-ID: <60A6E5EE-337D-4C6A-B38D-D1E163663CCD@pch.net> On Mar 18, 2008, at 11:11 AM, Cliff Bedore wrote: > Tom Vest wrote: >> >> On Mar 17, 2008, at 10:20 PM, Cliff Bedore wrote: >> >>> Regarding a "market" for IPv4 addresses, I still have not heard any >>> disadvantage to ARIN staying completely out of the market part and >>> just have a >>> policy that allows one more method of acquiring addresses. >>> >>> As I understand current policy, there are basically two ways to get >>> addresses >>> >>> 1) Ask ARIN with appropriate justification >>> >>> 2) Buy/merge with a company and get the addresses as a part of that >>> transaction (again with some justification to ARIN >>> >>> It seems to me that all that 2008-2 needs to do is add a third >>> method >>> once the >>> IANA free pool is gone. >>> >>> 3) Party 1 offers to transfer to Party 2 some block of addresses. >>> Party 1 >>> has the right to offer and Party 2 justifies the right to receive >>> the >>> addresses. No market, no ARIN involvement with SEC, just ARIN >>> approving use >>> of a block of addresses. >>> >>> Why is this not a simple way to handle the end of life address >>> management of >>> v4 addresses? ARIN gets their fees just like now so they remain >>> viable but >>> have no interaction with the "market" and its associated problems. >>> >>> Cliff >> >> Basically this is the simple way, but it will not work -- technically >> it cannot work. This is because the arrangement you describe requires >> the same incentives to operate in multiple, simultaneous, but >> mutually >> contradictory ways -- more or less like this: >> >> 1. First, eliminate the single source mechanism for address >> delegation. Henceforth anyone may potentially be a buyer or seller of >> address resources, as they see fit. > > We're not eliminating the single source. Like the title for your car > from the DMV, it goes through one and only one place. You got the title to your car from the DMV? Gosh, I thought that chain started with something (i.e., a "pink slip") that came from the car seller and/or financer. You have to *report* title transfers to the DMV after the fact, after which they replace the old one with an updated one. But you have to report it first. But we all know how much everyone loves to take time off from work/ fun and go visit the DMV, right? I bet we'd all go visit them religiously even if all licensing and vehicle registration were voluntary, and police did not exist. It kind of makes one wonder why all of that taxpayer money is wasted on police in the first place ;-\ You live in California right? http://www.dmv.ca.gov/vr/vr_info.htm#BM2523 >> 2. Next, allow market forces to govern the address delegation >> function >> -- i.e., engage everyone's well-honed instincts to spend less and >> profit more, and allow the overall distribution of address >> resource be >> determined and legitimated by that market process. > > SO? The point is not that markets or the profit motive are bad. The point is that once you subject some system to those motives, you have to assume that they will be applied consistently and vigorously, not just enough but not too much, not just in ways that you think are nice. >> 3. Having empowered everyone this way, and fired up those competitive >> juices, also make sure that under certain defined circumstances, >> everyone always ignores both their new sovereign prerogatives and >> their newly engaged, otherwise-unrestricted market instincts, and >> voluntarily accept extra costs, restrictions on when and under what >> circumstances they may act, etc. > > Doesn't happen in what I describe. No, I agree it doesn't. >> 4. Make sure that they follow these rules and pay these extra >> costs in >> 100% of the required circumstances. Also assure that everyone takes >> the extra effort to inform some now distant, formerly critical >> institution of the results of their actions -- for whatever reason. > > Doesn't happen in what I describe No, I agree it doesn't. >> 5. This is a decentralized, market-driven system, but unlike every >> other market in human history all rules are purely voluntary, and no >> other enforcement mechanisms will ever exist. Make it work anyway. > > Not decentralized. Not a market. Simply one more way in which > addresses may be obtained from/through ARIN "Decentralized" means the individual transactions that affect the quality of the "central registry" and the overall (next-level) distribution of address resources happen outside of the direct purview of the maintainer of the central registry. Don't blame me man, I didn't make the word up. >> If that illustration doesn't work, maybe this one will: >> >> Basically the arrangement you describe would be like vehicle >> insurance >> in the US. We all know that, if we can afford it, auto insurance >> tends >> to protect us from somewhat from extreme risks. We also probably have >> a vague sense that the insurance we pay for also helps to protect >> other drivers too -- although that's hardly a motivating factor >> for us >> to buy in. But some people simply can't afford it, and some are >> forgetful and let their coverage lapse, and some people just like to >> live dangerously, damn the consequences for themselves and >> everyone else. > > Not like insurance. Much more like the DMV. Yes, like the magical, police-free, self-enforcing DMV. >> The Insurance Research Council estimates that 15-16% of all vehicles >> on US roads at any given time (c. 2007) were uninsured. Lucky for US >> drivers, there is no Department of Homeland Insurance that might be >> called in to rectify the situation in case uninsured, anonymous >> motorists start crashing into important things, or if that compliance >> rate drops too low. We do not enjoy the same luxury. > > People hijack addresses now for various reasons. I even had one of > mine > hijacked years ago. But it got fixed within the existing system. Well, if we can import some of that auto-enforcing DMV magic, I'm sure that successor central registry maintainers will have no trouble correcting similar problems in the future, because that magic will compel everyone to voluntarily keep their entries complete, accurate, and up to date, or perhaps magic will simply cause missing and erroneous entries to spontaneously correct themselves. >> I can't make the case any more clearly. I would also like the simple >> way to work, but wishing it will not make it so. > > Then I guess I give up because I still don't understand your > examples or > why what I put forth won't work. That is definitely the right response; I am going to follow your lead on this. TV From cliffb at cjbsys.bdb.com Tue Mar 18 13:30:50 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Tue, 18 Mar 2008 13:30:50 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <60A6E5EE-337D-4C6A-B38D-D1E163663CCD@pch.net> References: <200803180220.m2I2KDqb003250@cjbsys.bdb.com> <074A54DA-B52F-49B7-9376-3026BFFD1615@pch.net> <47DFDBB3.4070009@cjbsys.bdb.com> <60A6E5EE-337D-4C6A-B38D-D1E163663CCD@pch.net> Message-ID: <47DFFC4A.7030101@cjbsys.bdb.com> Tom Vest wrote: > >> ......... >> We're not eliminating the single source. Like the title for your car >> from the DMV, it goes through one and only one place. > > You got the title to your car from the DMV? Actually yes. That's how it's done here in Maryland > Gosh, I thought that chain started with something (i.e., a "pink > slip") that came from the car seller and/or financer. > You have to *report* title transfers to the DMV after the fact, after > which they replace the old one with an updated one. > But you have to report it first. > > But we all know how much everyone loves to take time off from work/fun > and go visit the DMV, right? > I bet we'd all go visit them religiously even if all licensing and > vehicle registration were voluntary, and police did not exist. > It kind of makes one wonder why all of that taxpayer money is wasted > on police in the first place ;-\ Most of our stuff with the DMV can be done over the internet. :-) > > You live in California right? No > > http://www.dmv.ca.gov/vr/vr_info.htm#BM2523 > > >>> 2. Next, allow market forces to govern the address delegation function >>> -- i.e., engage everyone's well-honed instincts to spend less >>> andprofit more, and allow the overall distribution of address >>> resource be >>> determined and legitimated by that market process. >> >> SO? > > The point is not that markets or the profit motive are bad. > The point is that once you subject some system to those motives, you > have to assume that they will be applied consistently and vigorously, > not just enough but not too much, not just in ways that you think are > nice. Again, there's a big market here for cars but all the titles go through the DMV and the rules are applied "consistently and vigorously" > > >> ........... >> Not decentralized. Not a market. Simply one more way in which >> addresses may be obtained from/through ARIN > > "Decentralized" means the individual transactions that affect the > quality of the "central registry" and the overall (next-level) > distribution of address resources happen outside of the direct purview > of the maintainer of the central registry. Don't blame me man, I > didn't make the word up. > >> ..................... >> Not like insurance. Much more like the DMV. > > Yes, like the magical, police-free, self-enforcing DMV. Actually yes except for the magical part. > > ............... >>> I can't make the case any more clearly. I would also like the simple >>> way to work, but wishing it will not make it so. >> >> Then I guess I give up because I still don't understand your examples or >> why what I put forth won't work. > > That is definitely the right response; I am going to follow your lead > on this. I bet you won't. :-) > > TV > Cliff From oberman at es.net Tue Mar 18 16:44:27 2008 From: oberman at es.net (Kevin Oberman) Date: Tue, 18 Mar 2008 13:44:27 -0700 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: Your message of "Tue, 18 Mar 2008 13:45:04 +0900." <47DF48D0.9080201@psg.com> Message-ID: <20080318204427.1FACD45019@ptavv.es.net> > Date: Tue, 18 Mar 2008 13:45:04 +0900 > From: Randy Bush > Sender: ppml-bounces at arin.net > > >>> A large portion of the reasoning behind this policy was to get legacy > >>> IP holders to free up space. > >> precisely. the goal of a market is to get goods to 'best use.' and > >> despite fred's assertion, the current transfer policy does not do that. > >> if it did, folk such as arin's lawyer would not be vilifying legacy > >> holders from the nanog stage. > > That's not necessarily a defect in the current transfer policy as > > much as a failing (of those who have more address space than > > they require) not returning the excess to the IANA. > > ahhh, the socialist economy planners know best. cool! Speaking only for myself and not my employer. While my instinct is to agree, even in a capitalistic economy, there tends to be a fair amount of "socialistic" meddling to try to maintain reasonable stability. Note the recent actions of the federal reserve to inject cheap cash into the economy and to "rescue" Bear Sterns. That said, I still need to be convinced that a fairly free market is not the best solution. -- R. Kevin Oberman, Network Engineer Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From bmanning at vacation.karoshi.com Tue Mar 18 17:12:28 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 18 Mar 2008 21:12:28 +0000 Subject: [ppml] IANA and the great unwashed... or - 2008-2 / 8.3.9 In-Reply-To: References: <200803171616.m2HGG54f029086@cjbsys.bdb.com> <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> <484B8E2E-89AF-40B6-AF1C-07C50EFF4FE1@svcolo.com> <47DF1C90.4070204@psg.com> Message-ID: <20080318211228.GA14954@vacation.karoshi.com.> On Tue, Mar 18, 2008 at 12:32:23AM -0400, John Curran wrote: > > ... [as] much as a failing (of those who have more address space than > they require) not returning the excess to the IANA. > > /John interesting assertion (and based on RFC 2050, seems to be the course of action one should take...) however, I have also heard that the IANA is not prepared to accept anything smaller than their current allocation size - and the number of IPv4 /8 prefixes is a small and (mostly) known quantity. would the IANA be willing to take back a sparse matrix of IPv4 /28's from my /20 delegation or would they encourage me to use my RIR, with whom I already have a relationship? If they were willing to take them back, would they need to establish a relationship with me so that I could accrue "credits" and/or establish my credentials? I'm pretty convinced that the IANA really does not want any part of a relationship where they deal directly with the address delegate... they like having a relationship with the RIR's in the form of the NRO letters. Too many direct relationships could/would prove messy... IMHO of course. perhaps you could ask the IANA to weigh in on this matter. --bill From tvest at pch.net Tue Mar 18 19:17:04 2008 From: tvest at pch.net (Tom Vest) Date: Tue, 18 Mar 2008 19:17:04 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <47DF48D0.9080201@psg.com> References: <200803171616.m2HGG54f029086@cjbsys.bdb.com> <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> <484B8E2E-89AF-40B6-AF1C-07C50EFF4FE1@svcolo.com> <47DF1C90.4070204@psg.com> <47DF48D0.9080201@psg.com> Message-ID: randy this is really beneath you. If ARIN office holders are socialist planners, does that make you some kind of heroic Objectivist freedom fighter, or maybe a weasely post-Soviet kleptocrat trying to loot the public trust before anyone notices? I don't happen to believe that any of these three taunts are true, but even if I did I don't think that injecting them here would serve any constructive purpose. Last time I checked ARIN office holders were network professionals volunteering their time -- i.e., members of the community. A wise man once recommended that we try to resist treating other members of the community as the enemy. That sounds like good advice to live by :-) TV On Mar 18, 2008, at 12:45 AM, Randy Bush wrote: >>>> A large portion of the reasoning behind this policy was to get >>>> legacy >>>> IP holders to free up space. >>> precisely. the goal of a market is to get goods to 'best use.' and >>> despite fred's assertion, the current transfer policy does not do >>> that. >>> if it did, folk such as arin's lawyer would not be vilifying legacy >>> holders from the nanog stage. >> That's not necessarily a defect in the current transfer policy as >> much as a failing (of those who have more address space than >> they require) not returning the excess to the IANA. > > ahhh, the socialist economy planners know best. cool! > > randy > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the > ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. From randy at psg.com Tue Mar 18 19:35:53 2008 From: randy at psg.com (Randy Bush) Date: Wed, 19 Mar 2008 08:35:53 +0900 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: References: <200803171616.m2HGG54f029086@cjbsys.bdb.com> <1CA157EF-4A9D-424D-B43B-EC2F19258139@pch.net> <484B8E2E-89AF-40B6-AF1C-07C50EFF4FE1@svcolo.com> <47DF1C90.4070204@psg.com> <47DF48D0.9080201@psg.com> Message-ID: <47E051D9.4090206@psg.com> Tom Vest wrote: > randy this is really beneath you. > If ARIN office holders are socialist planners, does that make you some > kind of heroic Objectivist freedom fighter, or maybe a weasely > post-Soviet kleptocrat trying to loot the public trust before anyone > notices? I don't happen to believe that any of these three taunts are > true, but even if I did I don't think that injecting them here would > serve any constructive purpose. > > Last time I checked ARIN office holders were network professionals > volunteering their time -- i.e., members of the community. > A wise man once recommended that we try to resist treating other members > of the community as the enemy. That sounds like good advice to live by :-) >> ahhh, the socialist economy planners know best. cool! foolish top-posting boy. i was a red diaper baby. randy From randy at psg.com Tue Mar 18 19:49:57 2008 From: randy at psg.com (Randy Bush) Date: Wed, 19 Mar 2008 08:49:57 +0900 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <20080318204427.1FACD45019@ptavv.es.net> References: <20080318204427.1FACD45019@ptavv.es.net> Message-ID: <47E05525.9020709@psg.com> Kevin Oberman wrote: > even in a capitalistic economy, there tends to be a fair amount of > "socialistic" meddling to try to maintain reasonable stability. Note > the recent actions of the federal reserve to inject cheap cash into > the economy and to "rescue" Bear Sterns. it has been demonstrated that this path leads to wheelbarrow fulls of currency to buy a loaf of bread. but let's stick to our own little disaster. let's get real here and look at over-inflated selves in the mirror. our "self regulation" has led to 75% of recent allocations going to just ten organizations (and they keep merging!), a barrier to entry at the low end which we justify with words about routing table bloat, and a routing table that is half crap, i.e. severely bloated. i, for one, ain't proud. we are on the same exhaustion curve frank solensky drew in the early '90s, before arin etc. i.e. all our "self regulation" has not significantly affected consumption of the resource we are supposedly conserving. the only thing which affected things was cidr [0]. i, for one, ain't proud. like icann, we have managed to create a global self-perpetuating expensive bureaucracy to do the job which used to be done by one computer scientist working part time [1]. i, for one, ain't proud. btw, the graph is not the same in all regions, for example, lacnic, ripe, ... randy --- [0] - hypothesis, we're good at technical solutions but not at social. i guess this should not be a big surprise. [1] - sure it would take more than dr. postel today. but a thousand times more? From sleibrand at internap.com Tue Mar 18 21:03:07 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 18 Mar 2008 18:03:07 -0700 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <200803180220.m2I2KDqb003250@cjbsys.bdb.com> References: <200803180220.m2I2KDqb003250@cjbsys.bdb.com> Message-ID: <47E0664B.3050808@internap.com> Cliff Bedore wrote: > Regarding a "market" for IPv4 addresses, I still have not heard any > disadvantage to ARIN staying completely out of the market part and just have a > policy that allows one more method of acquiring addresses. > > As I understand current policy, there are basically two ways to get addresses > > 1) Ask ARIN with appropriate justification > > 2) Buy/merge with a company and get the addresses as a part of that > transaction (again with some justification to ARIN > > It seems to me that all that 2008-2 needs to do is add a third method once the > IANA free pool is gone. > > 3) Party 1 offers to transfer to Party 2 some block of addresses. Party 1 > has the right to offer and Party 2 justifies the right to receive the > addresses. No market, no ARIN involvement with SEC, just ARIN approving use > of a block of addresses. What you're describing here seems pretty similar to the APNIC and RIPE proposals. Personally I feel that those proposals go a bit too far, in that they will encourage excessive deaggregation and impose externality costs on everyone holding a full routing table. Specifically, the cost of acquiring IPv4 addresses will encourage transferees to acquire just enough addresses to meet their immediate needs, and transferors will be able to arbitrarily subdivide their netblocks to meet that demand. This will likely result in a large and unnecessary uptick in the rate at which new routes are added to the DFZ. Without some sort of backpressure (a market in routing slots) I think that some form of deaggregation restriction, such as that proposed in 2008-2, is needed to constrain that. > Why is this not a simple way to handle the end of life address management of > v4 addresses? ARIN gets their fees just like now so they remain viable but > have no interaction with the "market" and its associated problems. Another option, that you may be alluding to, would be to have ARIN do the transfer policy, but leave the listing services to others (i.e. eBay). That would certainly be one viable option. Personally I prefer to do both: have ARIN develop an optional listing service, making it voluntary so that organizations can engage in private party transactions or use another listing service (eBay if they want). -Scott From sleibrand at internap.com Tue Mar 18 21:09:49 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 18 Mar 2008 18:09:49 -0700 Subject: [ppml] Listing services In-Reply-To: References: <47CDA182.80502@internap.com> <435DE256-44B8-48FC-9F4B-AC3BC8D70D65@virtualized.org> <47CF088B.5060809@internap.com> <47CF4F8F.2030504@psg.com> <000301c87f66$c7a4fed0$6e00a8c0@ad.redback.com> <00b801c87fb8$4ddf77e0$6e00a8c0@ad.redback.com> <507B4D6C-D2BC-44BF-843E-CDCDF1708BED@pch.net> <47D06585.2020402@apnic.net><47DD8B57.6090205@internap.com> <9DC9F13A-CECE-43FB-B786-B35371F41339@pch.net> <47DF0E4F.9040308@internap.com> Message-ID: <47E067DD.1050900@internap.com> michael.dillon at bt.com wrote: >> I agree that we have a lot to learn about listing services >> before we set one up. > > This is the main reason why I think that it is too late to > implement some kind of market with the prime, or only goal > of mitigating the impact of IPv4 runout. > >> Of course, that doesn't detract >> from the importance of doing it right, so I would expect that >> ARIN would hire experts on the topic to make sure they take >> advantage of the expertise of someone who has set up a >> similar system before. > > It is all too easy to either hire the wrong sort of experts, > or to give them the wrong instructions because you don't fully > understand the implications of your plans. In fact if you > don't already have expertise in an area, it's all too common > to hire conmen rather than true experts. My point here is that > we all need to bring ourselves up to a certain minimum level > of competence in regards to "markets" in order to make reasonable > decisions about creating one. I believe the current proposal > was created with much too narrow a viewpoint. I think we are operating under different assumptions. You seem to be assuming that ARIN is (or would need to) "create" and "implement" the market, which in my mind translates to ARIN being the sole listing service. (Please correct me if I'm misunderstanding your position here.) My assumption, on the other hand, is that ARIN need only liberalize transfer policy and *allow* transactions, and that will allow a market to form. I think (and 2008-02 states) that ARIN should facilitate some degree of centralization and transparency by operating a listing service, but that the use of the listing service should be voluntary. Given the voluntary nature of the ARIN listing service, any mis-steps by ARIN in setting it up would have limited impact, as anyone would be free to use any alternative listing service they preferred if the ARIN one doesn't meet their needs. Does that address your concerns? Thanks for your continued input, Scott From bicknell at ufp.org Tue Mar 18 21:14:00 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 18 Mar 2008 20:14:00 -0500 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <47E05525.9020709@psg.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> Message-ID: <20080319011400.GA9421@ussenterprise.ufp.org> In a message written on Wed, Mar 19, 2008 at 08:49:57AM +0900, Randy Bush wrote: > let's get real here and look at over-inflated selves in the mirror. Sounds like a plan. Do you have your mirror handy? > our "self regulation" has led to 75% of recent allocations going to just > ten organizations (and they keep merging!), a barrier to entry at the > low end which we justify with words about routing table bloat, and a > routing table that is half crap, i.e. severely bloated. i, for one, > ain't proud. I don't think the reasons that ten organizations in the ARIN region have 90%+ of the eyeballs has anything to do with IP allocation policies. Phone and cable companies had a monopoly on wires in the ground prior to the IP thing being of interest. I am disappointed that the Internet wasn't able to change that, but that was a long shot anyway. As for the barrier to entry; I think we could have done a better job with IPv4 and should be doing a better job with IPv6. There are allocation strategies that make it easier to give out small blocks now and insure they can grow into larger blocks later and we seem to mostly not use them. Sadly, it's probably (10 years?) too late for IPv4. > we are on the same exhaustion curve frank solensky drew in the early > '90s, before arin etc. i.e. all our "self regulation" has not > significantly affected consumption of the resource we are supposedly > conserving. the only thing which affected things was cidr [0]. i, for > one, ain't proud. Looking at what both socialist and democratic countries do to our natural resources does not lead me to believe we are good at conversation as a society. That aside, conservation costs money. Could someone create SSL based web sites that don't need an IP per site? Sure. Could someone design a DHCPeqsue system that allowed prefixes for end users to move around in response to need for things like WiFi hotspot networks? Sure. But someone has to fund it. Call it the tragedy of the commons if you like, but I'm not sure what ARIN could do to prevent it. I'm also not even sure that "regulation" = "conservation" in this case either. Let's look at what our best minds came up with, from RFC 2050: 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. Color me confused, but conservation = fair distribution? Clearly the way to conserve oil then is to just divide it all up fairly. Humm, that doesn't seem right. Truth be told I don't think conservation was ever a goal. Consider this paper from 2000: http://user.it.uu.se/~pekka/ip-over-anything.pdf IP over everything. The mantra was get this in the hands of everyone. It will solve world hunger, eliminate poverty, topple oppressive governments, and cure diseases. I don't know that it's done any of that; but now people living in poverty can pirate pop music and get plenty of porn, that's still a quality of live improvement, isn't it? The only thing this industry ever made any serious effort to conserve was routing slots, because they cost money. IP's enabled revenue. IP's grew the number of interconnected parties increasing value. > like icann, we have managed to create a global self-perpetuating > expensive bureaucracy to do the job which used to be done by one > computer scientist working part time [1]. i, for one, ain't proud. > [1] - sure it would take more than dr. postel today. but a thousand > times more? As bureaucracies go I'd say ARIN is pretty cheap. However, you're way off the mark. ARIN's "fact sheet" (http://www.arin.net/about_us/fact_sheet.pdf) says ARIN has a "professional staff of about 40". I'm not sure how going from 1 person to 40 people is "a thousand times more". Another interesting measure may be hosts on the internet: http://www.isc.org/index.pl?/ops/ds/host-count-history.php In 1997, the year ARIN was founded, there were by this measure 26,053,000 (end of year, adjusted) hosts on the network. The last measure is 541,677,360, a growth factor of 20x. Considering Jon never had a public policy meeting, never processed a SWIP template, and didn't maintain a web site full of information in multiple languages. I doubt he had to respond to subpoenas about file sharing, spam, child porn and who knows what else. Now you'll probably cry foul that I didn't include APNIC, RIPE, LACNIC, and AfriNIC. In the time Jon was doing what he did many of these regions did not have significant Internet infrastructure. He never had to deal with the language issues in some of these regions. I think a Jon to ARIN compairson is the most fair. But least you don't, the numbers: APNIC: 48 RIPE: 100 LacNIC: 16 AfriNIC: 10 Total: 214 So, we still don't make your thousand times more, and that's without factoring that many of these groups have taken on additional roles, like ripe developing their database software or running the RIS project, LACNIC administering a scholarship program, etc. > btw, the graph is > not the same in all regions, for example, lacnic, ripe, ... Back to your original question; it would take a fairly over-inflated view of the importance of addressing to think the graph should be the same for all regions. Monopoly ownership of wirelines, government censorship, per capita GDP, localization of software; these are factors that change the demand for networks, and in turn IP's. ARIN could constrict demand (new policy proposal: no one gets IP's anymore, thanks!), but can't grow it beyond giving IP's to anyone who needs them, which is the current state. Networks are not constrained by ARIN, they are constrained by other forces. In short, the graphs are different for reasons wholely unrelated to addressing policy. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From randy at psg.com Tue Mar 18 21:38:37 2008 From: randy at psg.com (Randy Bush) Date: Wed, 19 Mar 2008 10:38:37 +0900 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <20080319011400.GA9421@ussenterprise.ufp.org> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319011400.GA9421@ussenterprise.ufp.org> Message-ID: <47E06E9D.70704@psg.com> >> our "self regulation" has led to 75% of recent allocations going to just >> ten organizations (and they keep merging!) > I don't think the reasons that ten organizations in the ARIN region > have 90%+ of the eyeballs has anything to do with IP allocation > policies. Phone and cable companies had a monopoly on wires in the > ground prior to the IP thing being of interest. I am disappointed > that the Internet wasn't able to change that, but that was a long > shot anyway. if we really were a pubic policy planning culture, we would have at least had the conversation of whether ip resources should have been allocated proportionally to wealth, or whether they should have been tilted toward new entry, rural, poor, ... even the telco industry had that conversation, and it resulted in universal service, not to hold that up as an ideal trade-off from a modern perspective. what might have been decided is certainly open to endless, and questionably productive, conjecture. but it is extremely notable that we did not have the discussion. randy From bicknell at ufp.org Tue Mar 18 21:58:02 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 18 Mar 2008 20:58:02 -0500 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <47E06E9D.70704@psg.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319011400.GA9421@ussenterprise.ufp.org> <47E06E9D.70704@psg.com> Message-ID: <20080319015802.GA18605@ussenterprise.ufp.org> In a message written on Wed, Mar 19, 2008 at 10:38:37AM +0900, Randy Bush wrote: > if we really were a pubic policy planning culture, we would have at > least had the conversation of whether ip resources should have been > allocated proportionally to wealth, or whether they should have been > tilted toward new entry, rural, poor, ... even the telco industry had > that conversation, and it resulted in universal service, not to hold > that up as an ideal trade-off from a modern perspective. (Un)fortuantely ARIN is not the FCC. The problem with defining society is society wants a say. Were ARIN to have said "IP's cost $500 in Urban areas and $1 in rural areas", and then offered to pay the other $450 in subsidies (keeping $49 to "administer the program") to rural ISP's the government would have taken over ARIN's function a long time ago. Even if you believe that was a good idea from a social policy perspective, you must admit the only effect could have been to delay the deployment of the Internet. Such a scheme increases costs across the board (IP's in cheap to build locations cost more, ISP's are compelled to build more in areas where it's costly to build), which results in slower deployment. I suppose from a conservation perspective that seems sexy; if we'd deployed half as much infrastructure we'd not have this IPv4 problem right now. If the goal is to have everyone connected, IPv4 is a failure. In a world with close to 6 billion people and only around 4 billion IP's we can't get the job done. We have to move to IPv6 at some point. On the surface putting it off seems rather sexy, saving all the money to transition; the effort, the down time. But the reality is putting it off can do nothing but increase the overall job. We deploy more and more network every day, making the conversion problem larger and larger every day. In hindsight, the right thing to do was to convert to 128 bit addressing back in 1990 when a flag day was still possible. If we had done that we'd have enough addressing to give everyone on the planet Internet connectivity, and the overall conversion cost would have been a teeny fraction of what it will cost to covert today, or 5 years from now. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From cliffb at cjbsys.bdb.com Tue Mar 18 22:13:32 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Tue, 18 Mar 2008 22:13:32 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <47E0664B.3050808@internap.com> References: <200803180220.m2I2KDqb003250@cjbsys.bdb.com> <47E0664B.3050808@internap.com> Message-ID: <47E076CC.10108@cjbsys.bdb.com> Scott Leibrand wrote: > Cliff Bedore wrote: >> Regarding a "market" for IPv4 addresses, I still have not heard any >> disadvantage to ARIN staying completely out of the market part and >> just have a >> policy that allows one more method of acquiring addresses. >> >> As I understand current policy, there are basically two ways to get >> addresses >> >> 1) Ask ARIN with appropriate justification >> >> 2) Buy/merge with a company and get the addresses as a part of that >> transaction (again with some justification to ARIN >> >> It seems to me that all that 2008-2 needs to do is add a third method >> once the >> IANA free pool is gone. >> >> 3) Party 1 offers to transfer to Party 2 some block of addresses. >> Party 1 >> has the right to offer and Party 2 justifies the right to receive the >> addresses. No market, no ARIN involvement with SEC, just ARIN >> approving use >> of a block of addresses. > > What you're describing here seems pretty similar to the APNIC and RIPE > proposals. Personally I feel that those proposals go a bit too far, > in that they will encourage excessive deaggregation and impose > externality costs on everyone holding a full routing table. > Specifically, the cost of acquiring IPv4 addresses will encourage > transferees to acquire just enough addresses to meet their immediate > needs, and transferors will be able to arbitrarily subdivide their > netblocks to meet that demand. This will likely result in a large and > unnecessary uptick in the rate at which new routes are added to the > DFZ. Without some sort of backpressure (a market in routing slots) I > think that some form of deaggregation restriction, such as that > proposed in 2008-2, is needed to constrain that. I'm not saying ARIN can't use some judgement in the approval process to help with deaggregation but remember, there may not be a lot of "big" blocks available in this time frame. I think there could be problems with routing tables but there will also be problems with routing tables if people go to v6. Also think about the fact that if all the legacy /24s not currently visible are sold, there will be a terrible impact on the routing table. > >> Why is this not a simple way to handle the end of life address >> management of >> v4 addresses? ARIN gets their fees just like now so they remain >> viable but >> have no interaction with the "market" and its associated problems. > > Another option, that you may be alluding to, would be to have ARIN do > the transfer policy, but leave the listing services to others (i.e. > eBay). That would certainly be one viable option. Personally I > prefer to do both: have ARIN develop an optional listing service, > making it voluntary so that organizations can engage in private party > transactions or use another listing service (eBay if they want). Yes. If that wasn't clear, (I expounded more in a prior email) ARIN will do all the transfer policy and approvals but would just stay out of the market. I think ARIN will be better off staying out of the listing business. There are many outlets for that type of activity. Cliff > > -Scott > From bmanning at vacation.karoshi.com Tue Mar 18 22:59:01 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 19 Mar 2008 02:59:01 +0000 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <47E05525.9020709@psg.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> Message-ID: <20080319025901.GB17899@vacation.karoshi.com.> On Wed, Mar 19, 2008 at 08:49:57AM +0900, Randy Bush wrote: > like icann, we have managed to create a global self-perpetuating > expensive bureaucracy to do the job which used to be done by one > computer scientist working part time [1]. i, for one, ain't proud. > > randy > > --- > > [1] - sure it would take more than dr. postel today. but a thousand > times more? > _______________________________________________ this assertion, that the IANA was a part time job by one computer scientist is false and has been since it was postulated. Postel had Joyce, SRI, DDN, NSI, Suzanne, Anne, Walt, myself, RIPE, and then a committee for transition, which included someone named Randy Bush. What might be a reasonable postualte is that the IANA of yore had two attributes that are absent in todays models: a) the ability to act unilaterally and subjectively and have the actions stick w/ the community... and b) not be bound by a bottom up -only- process. So the IANA of yore could "balance" the concentrations of resources and protect/enable the paths of entry for the divergent business/operational model. Now if I remember that committee for transition included a guy named Randy Bush, who either actively or tactitly approved a set of processes which encouraged/fostered a bottom-up, community driven structures for a new start up, called ARIN. Did you forget to include methods for protecting access for non-commercial IP use in the design of ARIN? That said, If you feel that change is desired, ARIN does have an open policy process in place for you to use to change the way we, as a community, manage the stewardship we have been entrusted with. all that said, I am convinced that this is not the best of all possible worlds and am not proud of some choices that have been made, HOWEVER, I am proud of (most of) what we have done thus far, think we can do better and am not ready to throw in the towel. And I don't think you are either. --bill From randy at psg.com Tue Mar 18 23:20:02 2008 From: randy at psg.com (Randy Bush) Date: Wed, 19 Mar 2008 12:20:02 +0900 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <20080319025901.GB17899@vacation.karoshi.com.> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> Message-ID: <47E08662.1040701@psg.com> [ from what i said to someone else privately, but politified a bit ] yes, i was there for the start of arin. and a very clueful guy from the fcc explained to me and the other founding board members what the fcc would have done for a board, i.e. have consumers on it etc. but i was the only one even interested. the general focus was on getting it away from the usg and nsi, and we would know what was right better for this new internet thing than anyone else. hubris. yes, i was there for the start of icann and talking to the decision makers. i tried to get folk such as a librarian and a 15 year old with a modem on the initial board, as well as a real global statesperson. they did not think me serious. well, dr. postel did, but merely thought me unrealistic. arin is not directly not concerned with the end customer. we are mostly self-serving medium and large isps because that is who can afford and is motivated to keep sending people to these meetings and reading drivel such as this message. it's not an evil plot, it's economics. who can afford the time and energy? to whom is it worth the cost? and many of us know where the person-hours went at the iana in those years, and how many of them went to cleaning up whose messes. randy From sleibrand at internap.com Wed Mar 19 01:31:16 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 18 Mar 2008 22:31:16 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <47E08662.1040701@psg.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> Message-ID: <47E0A524.8090506@internap.com> Randy Bush wrote: > > arin is not directly not concerned with the end customer. we are mostly > self-serving medium and large isps because that is who can afford and is > motivated to keep sending people to these meetings and reading drivel > such as this message. it's not an evil plot, it's economics. who can > afford the time and energy? to whom is it worth the cost? So let's discuss some policies to help the end consumer. I, for one, spend my time and energy reading and writing this drivel because I have an overactive sense of altruism, or something, and enjoy it. My employer doesn't particularly care if I do or don't. One policy proposal that might help consumers is 2008-3, Community Networks IPv6 Allocation. I think I support that proposal, since in my own work on mesh networks I can definitely see the need for PI space at the community network layer. Does anyone else have any thoughts on whether adding a community networks criterion to get a PI /48 is a good idea? What about shifting the minimum allocation size? Should we reopen that discussion and consider /24 or /23 instead of /22? I'm not sure what else the "little guys" need as far as policy. Does anyone else have any other suggestions? -Scott From dlw+arin at tellme.com Wed Mar 19 02:38:40 2008 From: dlw+arin at tellme.com (David Williamson) Date: Tue, 18 Mar 2008 23:38:40 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <47E0A524.8090506@internap.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> Message-ID: <20080319063840.GR24095@shell01.cell.sv2.tellme.com> On Tue, Mar 18, 2008 at 10:31:16PM -0700, Scott Leibrand wrote: > What about shifting the minimum allocation size? Should we reopen that > discussion and consider /24 or /23 instead of /22? I'd be in favor of that. I still think there's a lot of demand for multi-homed sites that have a legitimate need for PI. Forcing small multi-homed sites to lie to get PI space seems less than ideal given the constraints of IPv4 availability. If you can get a PA /24 for multi-homing, and anyone can, why can't you get PI? It's not like it's going to pollute the routing table any more than the PA /24. The only "advantage" to the PA /24 is that you get stuck with one of your upstreams, whether you like it or not. I'll also note that the other RIRs already have made this shift. Not encouraging more efficient allocations strikes me as very odd. -David From randy at psg.com Wed Mar 19 02:51:12 2008 From: randy at psg.com (Randy Bush) Date: Wed, 19 Mar 2008 15:51:12 +0900 Subject: [ppml] Policy to help the little guys In-Reply-To: <20080319063840.GR24095@shell01.cell.sv2.tellme.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> Message-ID: <47E0B7E0.6060903@psg.com> David Williamson wrote: > If you can get a PA /24 for multi-homing, and anyone can, why can't > you get PI? as a gedanken experiment, and maintaining my reputation as a notorious trouble-maker, why not longer than /24? e.g. take a /16 and create a well-known micro-swam of say /29s for multi-homed content sites. i am not necessarily advocating this. but i think the exercise of discussing the pros and cons might be good for us. randy From dlw+arin at tellme.com Wed Mar 19 02:59:33 2008 From: dlw+arin at tellme.com (David Williamson) Date: Tue, 18 Mar 2008 23:59:33 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <47E0B7E0.6060903@psg.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <47E0B7E0.6060903@psg.com> Message-ID: <20080319065933.GT24095@shell01.cell.sv2.tellme.com> On Wed, Mar 19, 2008 at 03:51:12PM +0900, Randy Bush wrote: > David Williamson wrote: > > If you can get a PA /24 for multi-homing, and anyone can, why can't > > you get PI? > > as a gedanken experiment, and maintaining my reputation as a notorious > trouble-maker, why not longer than /24? e.g. take a /16 and create a > well-known micro-swam of say /29s for multi-homed content sites. Sure, why not? You could easily claim that market forces will take care of it. If my site has no useful interaction with somewhereistan, I can simply block the short prefixes from them. Or, at a higher level, I could just block all of the /8s associated with a specific RIR, based on my business model/needs. On the flip side, I could accept a bunch of /28s or /29s from sites important to me. All it would take is some hard to maintain filters. Oh, and the assumption that all of the transit providers between me and those end points provide transit down to the /29 level. They'll do that if they also see value in those routes, which might be in the form of income provided by them or me. I'm sure that most ISPs would gladly provide a routing slot for a long prefix if they were appropriately compensated for the trouble of doing so. The price might be high, but I'm sure that one could be found. I think it unlikely that providing routes longer than $current_std_longest_prefix will be very useful. But it might. I actually almost proposed that - see the rationale for 2007-6. For the moment, I'd be happy with /24. -David From randy at psg.com Wed Mar 19 03:11:26 2008 From: randy at psg.com (Randy Bush) Date: Wed, 19 Mar 2008 16:11:26 +0900 Subject: [ppml] Policy to help the little guys In-Reply-To: <20080319065933.GT24095@shell01.cell.sv2.tellme.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <47E0B7E0.6060903@psg.com> <20080319065933.GT24095@shell01.cell.sv2.tellme.com> Message-ID: <47E0BC9E.2000100@psg.com> i was presuming the use of a well known /16 would be so that isps could allow the long prefixes in that space. as it would be the same number of prefixes if we gave them /24s, what's the loss? btw, i remember an arin meeting in denver when cja tore my head off and bad mouthed me behind my back for proposing /24s. so watch out! randy From bmanning at vacation.karoshi.com Wed Mar 19 05:20:02 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 19 Mar 2008 09:20:02 +0000 Subject: [ppml] Policy to help the little guys In-Reply-To: <47E0BC9E.2000100@psg.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <47E0B7E0.6060903@psg.com> <20080319065933.GT24095@shell01.cell.sv2.tellme.com> <47E0BC9E.2000100@psg.com> Message-ID: <20080319092002.GA21546@vacation.karoshi.com.> On Wed, Mar 19, 2008 at 04:11:26PM +0900, Randy Bush wrote: > i was presuming the use of a well known /16 would be so that isps could > allow the long prefixes in that space. as it would be the same number > of prefixes if we gave them /24s, what's the loss? > > btw, i remember an arin meeting in denver when cja tore my head off and > bad mouthed me behind my back for proposing /24s. so watch out! cja -is- the micro-allocation grrl. /29's should not be a problem for her, neither should /30's or even /32's. But I suspect no one, other than Kim or yourself is ever going to get a /33 out of IPv4 space again. cja? --bill > > randy > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From plzak at arin.net Wed Mar 19 06:44:48 2008 From: plzak at arin.net (Ray Plzak) Date: Wed, 19 Mar 2008 06:44:48 -0400 Subject: [ppml] Policy to help the little guys In-Reply-To: <47E0B7E0.6060903@psg.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <47E0B7E0.6060903@psg.com> Message-ID: Randy, If you think something is worthwhile to discuss as a possible policy idea then I see that you have two paths. You can use either or both. First, you can always start such a discussion on the ppml. Second you can present the idea at the Open Policy Hour which occurs the evening before the public policy meeting. Ray > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Randy Bush > Sent: Wednesday, March 19, 2008 2:51 AM > To: David Williamson > Cc: arin ppml > Subject: Re: [ppml] Policy to help the little guys > > David Williamson wrote: > > If you can get a PA /24 for multi-homing, and anyone can, why can't > > you get PI? > > as a gedanken experiment, and maintaining my reputation as a notorious > trouble-maker, why not longer than /24? e.g. take a /16 and create a > well-known micro-swam of say /29s for multi-homed content sites. > > i am not necessarily advocating this. but i think the exercise of > discussing the pros and cons might be good for us. > > randy > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if > you experience any issues. From randy at psg.com Wed Mar 19 07:05:02 2008 From: randy at psg.com (Randy Bush) Date: Wed, 19 Mar 2008 20:05:02 +0900 Subject: [ppml] Policy to help the little guys In-Reply-To: References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <47E0B7E0.6060903@psg.com> Message-ID: <47E0F35E.6000508@psg.com> hi ray, > If you think something is worthwhile to discuss as a possible policy > idea then I see that you have two paths. You can use either or both. > First, you can always start such a discussion on the ppml. i am doing that in my way. > Second you can present the idea at the Open Policy Hour which occurs > the evening before the public policy meeting. i will not be in denver. randy From owen at delong.com Wed Mar 19 08:46:10 2008 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Mar 2008 21:46:10 +0900 Subject: [ppml] Policy to help the little guys In-Reply-To: References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <47E0B7E0.6060903@psg.com> Message-ID: <1096E645-F89B-4F2A-AF1F-44A4E3891BB4@delong.com> There is also the third option of filling out a template and submitting a proposed policy to policy at arin.net. Owen On Mar 19, 2008, at 7:44 PM, Ray Plzak wrote: > Randy, > > If you think something is worthwhile to discuss as a possible policy > idea then I see that you have two paths. You can use either or both. > First, you can always start such a discussion on the ppml. Second > you can present the idea at the Open Policy Hour which occurs the > evening before the public policy meeting. > > Ray > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >> Behalf Of >> Randy Bush >> Sent: Wednesday, March 19, 2008 2:51 AM >> To: David Williamson >> Cc: arin ppml >> Subject: Re: [ppml] Policy to help the little guys >> >> David Williamson wrote: >>> If you can get a PA /24 for multi-homing, and anyone can, why can't >>> you get PI? >> >> as a gedanken experiment, and maintaining my reputation as a >> notorious >> trouble-maker, why not longer than /24? e.g. take a /16 and create a >> well-known micro-swam of say /29s for multi-homed content sites. >> >> i am not necessarily advocating this. but i think the exercise of >> discussing the pros and cons might be good for us. >> >> 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. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the > ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. From bicknell at ufp.org Wed Mar 19 09:14:30 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 19 Mar 2008 08:14:30 -0500 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <47E08662.1040701@psg.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> Message-ID: <20080319131430.GB62017@ussenterprise.ufp.org> In a message written on Wed, Mar 19, 2008 at 12:20:02PM +0900, Randy Bush wrote: > arin is not directly not concerned with the end customer. we are mostly > self-serving medium and large isps because that is who can afford and is > motivated to keep sending people to these meetings and reading drivel > such as this message. it's not an evil plot, it's economics. who can > afford the time and energy? to whom is it worth the cost? Directly to your last question, no one. I actually rather like your consumer advocacy position here, but I'm afraid it's misplaced. To use a really bad analogy, but one I think makes my point. Consumers have been quite involved in Telco politics, PUC's, FCC, FTC, elected officials passing special laws, there's really no end to how consumers and lawmakers have gotten involved. But what about NANPA? How many consumers or consumer advocacy groups show up to discuss number plan administration? Virtually none. The few times the do say anything it's a statement about the cosmetics of phone numbers (e.g. selecting particular area codes for overlays). The group that runs numbering can only do two things for consumers, raise costs. ARIN could raise fees, ARIN could withhold addresses (which indirectly raises cost). Consumers pretty much never like more cost. As long as ARIN keeps the cost of the IP's a consumer needs low enough, they simply won't care....the situation we're in today. By contrast, ARIN's policy costs ISP's a lot. Some is direct cost (fees), but most of it is indirect cost; how easy it is for them to turn up customers, how much memory and CPU routers need. It's no surprise the are quite interested. I do think more consumer advocacy in this industry would be a good thing; but for ARIN to have any role it would have to be part of a larger organization doing other things (domain names? a PUC type role?) to have any effect. Last, but not least, some of the larger consumer advocacy groups have budgets that make ARIN look like a mom and pop. If the AARP, for instance, thought that they could make a difference for seniors by changing ARIN policy they would be here in a heartbeat, have people running for the AC and the Board, make sure many seniors showed up to every meeting. They are one of but many well funded groups. Why don't any of them ever show up? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From tvest at pch.net Wed Mar 19 10:04:54 2008 From: tvest at pch.net (Tom Vest) Date: Wed, 19 Mar 2008 10:04:54 -0400 Subject: [ppml] Policy to help the little guys In-Reply-To: <47E0A524.8090506@internap.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> Message-ID: On Mar 19, 2008, at 1:31 AM, Scott Leibrand wrote: > Randy Bush wrote: > >> >> arin is not directly not concerned with the end customer. we are >> mostly >> self-serving medium and large isps because that is who can afford >> and is >> motivated to keep sending people to these meetings and reading drivel >> such as this message. it's not an evil plot, it's economics. who >> can >> afford the time and energy? to whom is it worth the cost? > > So let's discuss some policies to help the end consumer. I, for one, > spend my time and energy reading and writing this drivel because I > have > an overactive sense of altruism, or something, and enjoy it. My > employer doesn't particularly care if I do or don't. > > One policy proposal that might help consumers is 2008-3, Community > Networks IPv6 Allocation. I think I support that proposal, since > in my > own work on mesh networks I can definitely see the need for PI > space at > the community network layer. Does anyone else have any thoughts on > whether adding a community networks criterion to get a PI /48 is a > good > idea? > > What about shifting the minimum allocation size? Should we reopen > that > discussion and consider /24 or /23 instead of /22? > > I'm not sure what else the "little guys" need as far as policy. Does > anyone else have any other suggestions? > > -Scott Question for ARIN stats folks: Historically -- say over the last 5-6 years -- what share of all subsequent allocations involves prefixes equal to or longer than the average or max. prefix length for all (concurrent policy era) initial allocations? That could help to suggest the degree to which new entrants and incumbents will be competing for the same IPv4 resources in a post-free pool environment, even if "convex pricing" emerges in any market for such resources. Depending on the answer to that question, I might have a few suggestions. Thanks, TV From plzak at arin.net Wed Mar 19 10:14:44 2008 From: plzak at arin.net (Ray Plzak) Date: Wed, 19 Mar 2008 10:14:44 -0400 Subject: [ppml] Policy to help the little guys In-Reply-To: References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> Message-ID: Not sure what you are asking for, and then, don't know how long it will take to produce it. Ray > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Tom Vest > Sent: Wednesday, March 19, 2008 10:05 AM > To: Scott Leibrand > Cc: Randy Bush; arin ppml > Subject: Re: [ppml] Policy to help the little guys > > > On Mar 19, 2008, at 1:31 AM, Scott Leibrand wrote: > > > Randy Bush wrote: > > > >> > >> arin is not directly not concerned with the end customer. we are > >> mostly > >> self-serving medium and large isps because that is who can afford > >> and is > >> motivated to keep sending people to these meetings and reading > drivel > >> such as this message. it's not an evil plot, it's economics. who > >> can > >> afford the time and energy? to whom is it worth the cost? > > > > So let's discuss some policies to help the end consumer. I, for one, > > spend my time and energy reading and writing this drivel because I > > have > > an overactive sense of altruism, or something, and enjoy it. My > > employer doesn't particularly care if I do or don't. > > > > One policy proposal that might help consumers is 2008-3, Community > > Networks IPv6 Allocation. I think I support that proposal, since > > in my > > own work on mesh networks I can definitely see the need for PI > > space at > > the community network layer. Does anyone else have any thoughts on > > whether adding a community networks criterion to get a PI /48 is a > > good > > idea? > > > > What about shifting the minimum allocation size? Should we reopen > > that > > discussion and consider /24 or /23 instead of /22? > > > > I'm not sure what else the "little guys" need as far as policy. Does > > anyone else have any other suggestions? > > > > -Scott > > Question for ARIN stats folks: > > Historically -- say over the last 5-6 years -- what share of all > subsequent allocations involves prefixes equal to or longer than the > average or max. prefix length for all (concurrent policy era) initial > allocations? That could help to suggest the degree to which new > entrants and incumbents will be competing for the same IPv4 resources > in a post-free pool environment, even if "convex pricing" emerges in > any market for such resources. > > Depending on the answer to that question, I might have a few > suggestions. > > Thanks, > > TV > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if > you experience any issues. From michael.dillon at bt.com Wed Mar 19 10:27:14 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 19 Mar 2008 14:27:14 -0000 Subject: [ppml] Policy to help the little guys In-Reply-To: References: <20080318204427.1FACD45019@ptavv.es.net><47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.><47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> Message-ID: > Not sure what you are asking for, and then, don't know how > long it will take to produce it. To me, it sounded like this, or perhaps a subset of this. For every ARIN IPv4 ISP/LIR, record the size of the base allocation that they first received and the date. Call this B. Then go through all the B's and figure the average size of B for each month. Call this A. The go through all the ISP/LIR subsequent allocations and record the date the size called S and two calculated values PB and PA. PB = S as a percent of B, and PA = S as a percent of A. Provide this data as a table in CSV format ISP #, B, A, Base Date, Subsequent Date, S, PA, PB That should be sufficiently parseable that people can do some charts with it. For instance charting the average of PA and/or PB over time would show if subsequent allocations are trending larger compared to the base allocation or compared to all other allocations made at the time the base allocation was made. Or perhaps Tom could suggest a slightly different algorithm. --Michael Dillon From spetty at iconnect-corp.com Wed Mar 19 10:45:39 2008 From: spetty at iconnect-corp.com (Steven E. Petty) Date: Wed, 19 Mar 2008 10:45:39 -0400 Subject: [ppml] Policy to help the little guys In-Reply-To: <47E0B7E0.6060903@psg.com> Message-ID: <402EB9414506BC40BB42CD47317FD1B302FBE4D9A8@Maggie.iconnect-corp.com> At this point, either of these would provide a better solution for my company. Though the /29 would require segmenting some non-critical hosts to (presumably PA) other IP space. A /28 would fit all that require external visibility. So, I suppose the first complication would be whether our theoretical new /29 multihomed allocation had rules for justifying larger blocks... -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Randy Bush Sent: Wednesday, March 19, 2008 2:51 AM To: David Williamson Cc: arin ppml Subject: Re: [ppml] Policy to help the little guys David Williamson wrote: > If you can get a PA /24 for multi-homing, and anyone can, why can't > you get PI? as a gedanken experiment, and maintaining my reputation as a notorious trouble-maker, why not longer than /24? e.g. take a /16 and create a well-known micro-swam of say /29s for multi-homed content sites. i am not necessarily advocating this. but i think the exercise of discussing the pros and cons might be good for us. randy _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From bicknell at ufp.org Wed Mar 19 10:49:43 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 19 Mar 2008 09:49:43 -0500 Subject: [ppml] Policy to help the little guys In-Reply-To: <47E0B7E0.6060903@psg.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <47E0B7E0.6060903@psg.com> Message-ID: <20080319144943.GA72982@ussenterprise.ufp.org> In a message written on Wed, Mar 19, 2008 at 03:51:12PM +0900, Randy Bush wrote: > as a gedanken experiment, and maintaining my reputation as a notorious > trouble-maker, why not longer than /24? e.g. take a /16 and create a > well-known micro-swam of say /29s for multi-homed content sites. RIPE allocates prefixes from /25-/32, I do believe. I know at least two people with /26's from RIPE. Perhaps we could learn something from their experience. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From dsd at servervault.com Wed Mar 19 11:26:54 2008 From: dsd at servervault.com (Divins, David) Date: Wed, 19 Mar 2008 11:26:54 -0400 Subject: [ppml] Policy to help the little guys In-Reply-To: <20080319144943.GA72982@ussenterprise.ufp.org> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com><20080319025901.GB17899@vacation.karoshi.com.><47E08662.1040701@psg.com> <47E0A524.8090506@internap.com><20080319063840.GR24095@shell01.cell.sv2.tellme.com><47E0B7E0.6060903@psg.com> <20080319144943.GA72982@ussenterprise.ufp.org> Message-ID: <8A3DE12E408BBC499E40C0BE733C86031F1E51@mail1.dulles.sv.int> Think of the routing table! That said, I could see supporting a micro-swamp. -dsd David Divins Principal Engineer ServerVault Corp. From dlw+arin at tellme.com Wed Mar 19 11:58:06 2008 From: dlw+arin at tellme.com (David Williamson) Date: Wed, 19 Mar 2008 08:58:06 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <47E0B7E0.6060903@psg.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <47E0B7E0.6060903@psg.com> Message-ID: <20080319155806.GV24095@shell01.cell.sv2.tellme.com> On Wed, Mar 19, 2008 at 03:51:12PM +0900, Randy Bush wrote: > i am not necessarily advocating this. but i think the exercise of > discussing the pros and cons might be good for us. I'll include the text of 2007-6 below, just for fun. Given that opinion on that proposal was sharply divided, perhaps it's time to pull it out again for discussion. I'd be happy to resubmit it for the LA meeting. Indeed, I'd be happy to submit a modified version if we can get enough feedback on this list. I think /24s are the right direction. 2007-6 was focused on PI, but why not PA space, too? If there's positive feedback, I'll submit a proposal for moving both to a /24 minimum. -David (policy text below) Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 1. Policy Proposal Name: IPv4 PI minimum size change 2. Author 1. name: David Williamson 2. email: dlw+arin at tellme.com 3. telephone: 650-930-9180 4. organization: Tellme Networks 3. Proposal Version: 1.0 4. Submission Date: 2/14/2007 5. Proposal type: modify 6. Policy term: permanent 7. Policy statement: In section 4.3.2.2 of the NRPM, change all occurences of "/22" to "/24". (That is, replace the existing 4.3.2.2 with this text: For end-users who demonstrate an intent to announce the requested space in a multihomed fashion, the minimum block of IP address space assigned is a /24. If assignments smaller than a /24 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose. Remove references to IPv4 in section 4.4, as they are no longer relevant. Section 4.4 could be moved, at the discretion of the NRPM editors, to somewhere in section 6, for clarity. 8. Rationale: The rationale for moving the allocation "edge" for IPv4 PI space to /24 has three fundamental points: routing slot consumption would be unchanged, it reflects widespread routing practices, and it discourages waste. While experiments indicate that a few ISPs still try to filter at the /22 boundary, I have been repeatedly told that most don't filter anything shorter than a /24. While routing policy and allocation policies don't need to necessarily match, it is not unreasonable to have them in alignment. In addition, by keeping the PI allocation size for multi-homed organizations at /22, organizations seeking PI space that don't meet the requirements may be encouraged to exaggerate their address usage. This is something that should clearly not be encouraged. On the topic of routing slots, I would like to note that any org qualifying under the PI policies in 4.3.2.2 would also qualify for PA space, and would likely have an interest in multi-homing regardless of the usage of PA vs. PI space. In either instance, a routing slot is consumed by a /24. This policy change should therefore have minimal, if any, impact on the size of the global routing table. It merely gives organizations more options at a slightly smaller network size. Remember that for consideration under 4.3.2.2, an organiztion *must* be multi-homed. On a side note, it's tempting to remove the restriction entirely. If an organization only qualifies for a /28 (for example), they could receive an allocation of that size. Market forces would decide if that /28 was worth a routing slot. If the /28 contained my personal website, I suspect it would not be routable. If that /28 contained Microsoft Update, I suspect it would. In the interest of operational sanity and simplicity, I am not making a proposal to remove the restriction. (Note that section 4.1.1 explicitly notes that PI addresses are not guaranteed to be globally routable.) There is fundamental conflict between the urge for aggregation and the desire for conservation. The latter would prefer that organizations not have any excess space, while the former would prefer that fewer networks exist in the DFZ, regardless of wastage. Since the DFZ already permits deaggregation to /24, the conservation urge should be allowed to push to that edge. As noted in 4.1.5, "determination of IP address allocation size is the responsibility of ARIN." This proposal simply allows the community to request appropriately sized blocks, and ARIN to allocate prefixes of a size that is commensurate with established need. 9. Timetable for implementation: immediate 10. Meeting presenter: David Williamson END OF TEMPLATE From ipgoddess at gmail.com Wed Mar 19 12:03:35 2008 From: ipgoddess at gmail.com (Stacy Taylor) Date: Wed, 19 Mar 2008 09:03:35 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <47E0A524.8090506@internap.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> Message-ID: <1c16a4870803190903n63e9d79bhd1ebfbd6359d1cb2@mail.gmail.com> Okay, A) it's not drivel and if you think it is you need to step down.B) If 'helping the little guys" means routing table bloat we need to be against that. and C) I will always oppose "I want a pony" microallocation proposals in the v4 space. Stacy On Tue, Mar 18, 2008 at 10:31 PM, Scott Leibrand wrote: > Randy Bush wrote: > > > > > arin is not directly not concerned with the end customer. we are mostly > > self-serving medium and large isps because that is who can afford and is > > motivated to keep sending people to these meetings and reading drivel > > such as this message. it's not an evil plot, it's economics. who can > > afford the time and energy? to whom is it worth the cost? > > So let's discuss some policies to help the end consumer. I, for one, > spend my time and energy reading and writing this drivel because I have > an overactive sense of altruism, or something, and enjoy it. My > employer doesn't particularly care if I do or don't. > > One policy proposal that might help consumers is 2008-3, Community > Networks IPv6 Allocation. I think I support that proposal, since in my > own work on mesh networks I can definitely see the need for PI space at > the community network layer. Does anyone else have any thoughts on > whether adding a community networks criterion to get a PI /48 is a good > idea? > > What about shifting the minimum allocation size? Should we reopen that > discussion and consider /24 or /23 instead of /22? > > I'm not sure what else the "little guys" need as far as policy. Does > anyone else have any other suggestions? > > -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. > -- :):) /S -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlw+arin at tellme.com Wed Mar 19 12:16:00 2008 From: dlw+arin at tellme.com (David Williamson) Date: Wed, 19 Mar 2008 09:16:00 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <1c16a4870803190903n63e9d79bhd1ebfbd6359d1cb2@mail.gmail.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <1c16a4870803190903n63e9d79bhd1ebfbd6359d1cb2@mail.gmail.com> Message-ID: <20080319161600.GX24095@shell01.cell.sv2.tellme.com> On Wed, Mar 19, 2008 at 09:03:35AM -0700, Stacy Taylor wrote: > B) If > 'helping the little guys" means routing table bloat we need to be against > that. > and C) I will always oppose "I want a pony" microallocation proposals in the > v4 space. > Stacy I'm also against bloat and ponies, but I am in favor of efficient utilization of the remaining IPv4 space. To be clear, any proposal that I'm likely to support would require the recipient of a PI /24 to be multihomed. Heck, I'd be happy if there was no non-multihomed PI available. I don't quite get why large singlehomed PI space is permitted under the current policy. If you don't need to be multihomed, get space from an ISP. Perhaps I'm overly simplifying the world, but I see organizations in one of three roles: * ISPs * end sites that are multihomed * end sites that are singlehomed The first two have much in common, networking wise. The last of the three is what the first would call a "customer". The only difference between the first two is that the second one doesn't have downstreams in the third class. In theory, under current policy, an ISP could deaggregate their entire space down to /24s, and hand them out to downstream multihomed customers as part of their service bundle. I don't see how that's any worse for the routing table than permitting PI /24s. -David From mksmith at adhost.com Wed Mar 19 12:27:35 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 19 Mar 2008 09:27:35 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <47E0A524.8090506@internap.com> References: <20080318204427.1FACD45019@ptavv.es.net><47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.><47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> Message-ID: <17838240D9A5544AAA5FF95F8D520316037A7952@ad-exh01.adhost.lan> Hello Scott: > I'm not sure what else the "little guys" need as far as policy. Does > anyone else have any other suggestions? > How about a reservation of some block of space for allocations of /20's to Members that only meet those requirements? Regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 475 bytes Desc: not available URL: From bmanning at vacation.karoshi.com Wed Mar 19 12:45:03 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 19 Mar 2008 16:45:03 +0000 Subject: [ppml] Policy to help the little guys In-Reply-To: <20080319155806.GV24095@shell01.cell.sv2.tellme.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <47E0B7E0.6060903@psg.com> <20080319155806.GV24095@shell01.cell.sv2.tellme.com> Message-ID: <20080319164503.GA26447@vacation.karoshi.com.> if you have the gonadanal fortituted - go for a minimum allocation of /32 - for all IP address families :) bonus points for abolishing the distinction btwn PI and PA space. (but that would have to be an independent action, imho) --bill On Wed, Mar 19, 2008 at 08:58:06AM -0700, David Williamson wrote: > > I'll include the text of 2007-6 below, just for fun. Given that > opinion on that proposal was sharply divided, perhaps it's time to pull > it out again for discussion. I'd be happy to resubmit it for the LA > meeting. Indeed, I'd be happy to submit a modified version if we can > get enough feedback on this list. I think /24s are the right direction. > 2007-6 was focused on PI, but why not PA space, too? > > If there's positive feedback, I'll submit a proposal for moving both to > a /24 minimum. > > -David > > (policy text below) > > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 > > 1. Policy Proposal Name: IPv4 PI minimum size change > 2. Author > 1. name: David Williamson > 2. email: dlw+arin at tellme.com > 3. telephone: 650-930-9180 > 4. organization: Tellme Networks > 3. Proposal Version: 1.0 > 4. Submission Date: 2/14/2007 > 5. Proposal type: modify > 6. Policy term: permanent > 7. Policy statement: > > In section 4.3.2.2 of the NRPM, change all occurences of "/22" to "/24". > > (That is, replace the existing 4.3.2.2 with this text: > > For end-users who demonstrate an intent to announce the requested space > in a multihomed fashion, the minimum block of IP address space assigned > is a /24. If assignments smaller than a /24 are needed, multihomed > end-users should contact their upstream providers. When prefixes are > assigned which are longer than /20, they will be from a block reserved > for that purpose. > > Remove references to IPv4 in section 4.4, as they are no longer > relevant. Section 4.4 could be moved, at the discretion of the NRPM > editors, to somewhere in section 6, for clarity. > > 8. Rationale: > > The rationale for moving the allocation "edge" for IPv4 PI space to /24 > has three fundamental points: routing slot consumption would be > unchanged, it reflects widespread routing practices, and it discourages > waste. > > While experiments indicate that a few ISPs still try to filter at the > /22 boundary, I have been repeatedly told that most don't filter > anything shorter than a /24. While routing policy and allocation > policies don't need to necessarily match, it is not unreasonable to > have them in alignment. > > In addition, by keeping the PI allocation size for multi-homed > organizations at /22, organizations seeking PI space that don't meet > the requirements may be encouraged to exaggerate their address usage. > This is something that should clearly not be encouraged. > > On the topic of routing slots, I would like to note that any org > qualifying under the PI policies in 4.3.2.2 would also qualify for PA > space, and would likely have an interest in multi-homing regardless of > the usage of PA vs. PI space. In either instance, a routing slot is > consumed by a /24. This policy change should therefore have minimal, > if any, impact on the size of the global routing table. It merely > gives organizations more options at a slightly smaller network size. > Remember that for consideration under 4.3.2.2, an organiztion *must* be > multi-homed. > > On a side note, it's tempting to remove the restriction entirely. If > an organization only qualifies for a /28 (for example), they could > receive an allocation of that size. Market forces would decide if that > /28 was worth a routing slot. If the /28 contained my personal > website, I suspect it would not be routable. If that /28 contained > Microsoft Update, I suspect it would. In the interest of operational > sanity and simplicity, I am not making a proposal to remove the > restriction. (Note that section 4.1.1 explicitly notes that PI > addresses are not guaranteed to be globally routable.) > > There is fundamental conflict between the urge for aggregation and the > desire for conservation. The latter would prefer that organizations > not have any excess space, while the former would prefer that fewer > networks exist in the DFZ, regardless of wastage. Since the DFZ already > permits deaggregation to /24, the conservation urge should be allowed > to push to that edge. > > As noted in 4.1.5, "determination of IP address allocation size is the > responsibility of ARIN." This proposal simply allows the community to > request appropriately sized blocks, and ARIN to allocate prefixes of a > size that is commensurate with established need. > > 9. Timetable for implementation: immediate > 10. Meeting presenter: David Williamson > > END OF TEMPLATE > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From arin-contact at dirtside.com Wed Mar 19 13:03:31 2008 From: arin-contact at dirtside.com (William Herrin) Date: Wed, 19 Mar 2008 13:03:31 -0400 Subject: [ppml] Policy to help the little guys In-Reply-To: <20080319063840.GR24095@shell01.cell.sv2.tellme.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> Message-ID: <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> On Wed, Mar 19, 2008 at 2:38 AM, David Williamson wrote: > I'd be in favor of that. I still think there's a lot of demand for > multi-homed sites that have a legitimate need for PI. Forcing small > multi-homed sites to lie to get PI space seems less than ideal given > the constraints of IPv4 availability. If you can get a PA /24 for > multi-homing, and anyone can, why can't you get PI? It's not like it's > going to pollute the routing table any more than the PA /24. The only > "advantage" to the PA /24 is that you get stuck with one of your > upstreams, whether you like it or not. I'll also note that the other > RIRs already have made this shift. Hi David, The main problem with PI assignments is the systemic cost of announcing a BGP prefix ( http://bill.herrin.us/network/bgpcost.html ). If you look at the things from a different perspective, the problem is the lack of mechanisms by which the 27000 active AS's can recover the BGP cost directly from the folks announcing a prefix. The prefix length restriction at the RIRs is a somewhat upside-down way of assuring that few who aren't putting lots of money into the infrastructure can consume the expensive resource. To justify a /22 you must document a fairly sizable IT operation, one whose nature will require spending at least tens of thousands of dollars a year on Internet transit. Solve either variant of the BGP cost problem first (cut the cost or figure out how to bill for it) and there'll be no reason for ARIN to maintain a limit on minimum assignment size. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From danny at tcb.net Wed Mar 19 13:49:14 2008 From: danny at tcb.net (Danny McPherson) Date: Wed, 19 Mar 2008 11:49:14 -0600 Subject: [ppml] Policy to help the little guys In-Reply-To: <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> Message-ID: <9AAEA4D2-C4B3-414E-BC5A-E9441EADCFFD@tcb.net> On Mar 19, 2008, at 11:03 AM, William Herrin wrote: > > Hi David, > > The main problem with PI assignments is the systemic cost of > announcing a BGP prefix > http://bill.herrin.us/network/bgpcost.html If you boil this down you get something like: bgp_route_cost == (router_cost / num_dfz_prefixes) If it were only that simple. You're assuming single FIB routers, no interconnection devices, disregarding number and speed of ports, inter-domain devices, that folks actually amortize and toss after 36 months, et cetera, etc, etc... I'm certainly not an economist (though I do have a background similar to many of those here who now believe they are), but I think trivializing in such a manner is a bit disingenuous. -danny From bmanning at vacation.karoshi.com Wed Mar 19 14:25:44 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 19 Mar 2008 18:25:44 +0000 Subject: [ppml] Policy to help the little guys In-Reply-To: References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <47E0B7E0.6060903@psg.com> <20080319155806.GV24095@shell01.cell.sv2.tellme.com> <20080319164503.GA26447@vacation.karoshi.com.> Message-ID: <20080319182544.GB27987@vacation.karoshi.com.> i'll admit to not seeing a whole lot of value in a /32 delegation, BUT I'm not as creative as some. I can see some value in a /31 - for those P2P links across the legacy v4 internet, hooking up the otherwise unconnected v6 "galaxies"... and to be sure, the arin community would have to take a very long critical look at how to enable growth. this is where a robust, painless, lowoverhead renumbering scheme would come in real handy. (wishing ISC had not expunged the A6 code when the IETF made A6 experimental... its a real pain to have to keep puting it back in) --bill On Wed, Mar 19, 2008 at 01:04:27PM -0500, Ray Weber wrote: > Well /24 would have helped us "small guys" a lot before we got > big enough and had the fortitude to need and request more.... > but Im not sure you need to go as crazy as /32. > > Ray Weber > VP Network Operations > SNEWISP llc > > > > -----Original Message----- > From: bmanning at vacation.karoshi.com > To: David Williamson > Cc: ppml at arin.net > Date: Wed, 19 Mar 2008 16:45:03 +0000 > Subject: Re: [ppml] Policy to help the little guys > > > > if you have the gonadanal fortituted - go for a minimum allocation of > /32 - for all IP address families :) > > bonus points for abolishing the distinction btwn PI and PA space. (but > that would have to be an independent action, imho) > > --bill > > > On Wed, Mar 19, 2008 at 08:58:06AM -0700, David Williamson wrote: > > > > I'll include the text of 2007-6 below, just for fun. Given that > > opinion on that proposal was sharply divided, perhaps it's time to pull > > it out again for discussion. I'd be happy to resubmit it for the LA > > meeting. Indeed, I'd be happy to submit a modified version if we can > > get enough feedback on this list. I think /24s are the right direction. > > 2007-6 was focused on PI, but why not PA space, too? > > > > If there's positive feedback, I'll submit a proposal for moving both to > > a /24 minimum. > > > > -David > > > > (policy text below) > > > > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 > > > > 1. Policy Proposal Name: IPv4 PI minimum size change > > 2. Author > > 1. name: David Williamson > > 2. email: dlw+arin at tellme.com > > 3. telephone: 650-930-9180 > > 4. organization: Tellme Networks > > 3. Proposal Version: 1.0 > > 4. Submission Date: 2/14/2007 > > 5. Proposal type: modify > > 6. Policy term: permanent > > 7. Policy statement: > > > > In section 4.3.2.2 of the NRPM, change all occurences of "/22" to "/24". > > > > (That is, replace the existing 4.3.2.2 with this text: > > > > For end-users who demonstrate an intent to announce the requested space > > in a multihomed fashion, the minimum block of IP address space assigned > > is a /24. If assignments smaller than a /24 are needed, multihomed > > end-users should contact their upstream providers. When prefixes are > > assigned which are longer than /20, they will be from a block reserved > > for that purpose. > > > > Remove references to IPv4 in section 4.4, as they are no longer > > relevant. Section 4.4 could be moved, at the discretion of the NRPM > > editors, to somewhere in section 6, for clarity. > > > > 8. Rationale: > > > > The rationale for moving the allocation "edge" for IPv4 PI space to /24 > > has three fundamental points: routing slot consumption would be > > unchanged, it reflects widespread routing practices, and it discourages > > waste. > > > > While experiments indicate that a few ISPs still try to filter at the > > /22 boundary, I have been repeatedly told that most don't filter > > anything shorter than a /24. While routing policy and allocation > > policies don't need to necessarily match, it is not unreasonable to > > have them in alignment. > > > > In addition, by keeping the PI allocation size for multi-homed > > organizations at /22, organizations seeking PI space that don't meet > > the requirements may be encouraged to exaggerate their address usage. > > This is something that should clearly not be encouraged. > > > > On the topic of routing slots, I would like to note that any org > > qualifying under the PI policies in 4.3.2.2 would also qualify for PA > > space, and would likely have an interest in multi-homing regardless of > > the usage of PA vs. PI space. In either instance, a routing slot is > > consumed by a /24. This policy change should therefore have minimal, > > if any, impact on the size of the global routing table. It merely > > gives organizations more options at a slightly smaller network size. > > Remember that for consideration under 4.3.2.2, an organiztion *must* be > > multi-homed. > > > > On a side note, it's tempting to remove the restriction entirely. If > > an organization only qualifies for a /28 (for example), they could > > receive an allocation of that size. Market forces would decide if that > > /28 was worth a routing slot. If the /28 contained my personal > > website, I suspect it would not be routable. If that /28 contained > > Microsoft Update, I suspect it would. In the interest of operational > > sanity and simplicity, I am not making a proposal to remove the > > restriction. (Note that section 4.1.1 explicitly notes that PI > > addresses are not guaranteed to be globally routable.) > > > > There is fundamental conflict between the urge for aggregation and the > > desire for conservation. The latter would prefer that organizations > > not have any excess space, while the former would prefer that fewer > > networks exist in the DFZ, regardless of wastage. Since the DFZ already > > permits deaggregation to /24, the conservation urge should be allowed > > to push to that edge. > > > > As noted in 4.1.5, "determination of IP address allocation size is the > > responsibility of ARIN." This proposal simply allows the community to > > request appropriately sized blocks, and ARIN to allocate prefixes of a > > size that is commensurate with established need. > > > > 9. Timetable for implementation: immediate > > 10. Meeting presenter: David Williamson > > > > END OF TEMPLATE > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN > Public Policy > > Mailing List (PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml > > Please contact the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. > _______________________________________________ > 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 dlw+arin at tellme.com Wed Mar 19 14:34:38 2008 From: dlw+arin at tellme.com (David Williamson) Date: Wed, 19 Mar 2008 11:34:38 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> Message-ID: <20080319183438.GZ24095@shell01.cell.sv2.tellme.com> On Wed, Mar 19, 2008 at 01:03:31PM -0400, William Herrin wrote: > The main problem with PI assignments is the systemic cost of > announcing a BGP prefix ( http://bill.herrin.us/network/bgpcost.html > ). If you look at the things from a different perspective, the problem > is the lack of mechanisms by which the 27000 active AS's can recover > the BGP cost directly from the folks announcing a prefix. Can you explain to me how a PI /24 would be in any way different from an otherwise identical PA /24? If an end-site is multi-homed with a /24, it seems to me that the cost is the same for PA or PI. I can get a PA /24 for multihoming pretty easily. Why can't I get PI? Your analysis points out the cost of announcing *any* route. A route is a route is a route, regardless of the arbitrary distinction between PI and PA. I think what you really want is to not see multihomed end sites...that would really save costs in the DFZ, but is entirely impractical for many organizations. For those orgs that have a legitimate need for multihoming, why force them to either be contractually obligated to a provider or, alternatively, exaggerate their needs to ARIN to get a /22? PI isn't the problem for DFZ costs, deaggregation is. The latter, however, is going to be of increasing interest as space gets tight and the entwork continues to grow. If nothing else, it allows more efficient allocations to be made. -David From sleibrand at internap.com Wed Mar 19 14:41:26 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 19 Mar 2008 11:41:26 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <47E0B7E0.6060903@psg.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <47E0B7E0.6060903@psg.com> Message-ID: <47E15E56.1000006@internap.com> Randy Bush wrote: > David Williamson wrote: >> If you can get a PA /24 for multi-homing, and anyone can, why can't >> you get PI? > > as a gedanken experiment, and maintaining my reputation as a notorious > trouble-maker, why not longer than /24? e.g. take a /16 and create a > well-known micro-swamp of say /29s for multi-homed content sites. > > i am not necessarily advocating this. but i think the exercise of > discussing the pros and cons might be good for us. I can think of a few reasons to stop at /24 for now, but I think the most important is that IMO policy shouldn't force ISPs to liberalize filter policy, but rather should respond to it. To date, most ISPs accept PA /24's, so allowing PI blocks down to /24 won't change things much. But giving out PI blocks smaller than /24 would create a lot of additional pressure on ISPs to accept the smaller blocks. I would rather focus on matching PI policy to what ISPs have already demonstrated they're ok with for PA space, rather than having PI lead the way. If ISPs decide in a year or two to start relaxing the /24 boundary, then I think it would be appropriate to adjust the PI minimum as well. -Scott From sleibrand at internap.com Wed Mar 19 14:45:01 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 19 Mar 2008 11:45:01 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <17838240D9A5544AAA5FF95F8D520316037A7952@ad-exh01.adhost.lan> References: <20080318204427.1FACD45019@ptavv.es.net><47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.><47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <17838240D9A5544AAA5FF95F8D520316037A7952@ad-exh01.adhost.lan> Message-ID: <47E15F2D.1030401@internap.com> Michael K. Smith - Adhost wrote: > Hello Scott: > >> I'm not sure what else the "little guys" need as far as policy. Does >> anyone else have any other suggestions? >> > How about a reservation of some block of space for allocations of /20's to Members that only meet those requirements? Not sure I follow. Meet which requirements? -Scott From danny at tcb.net Wed Mar 19 14:48:40 2008 From: danny at tcb.net (Danny McPherson) Date: Wed, 19 Mar 2008 12:48:40 -0600 Subject: [ppml] Policy to help the little guys In-Reply-To: <20080319183438.GZ24095@shell01.cell.sv2.tellme.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> <20080319183438.GZ24095@shell01.cell.sv2.tellme.com> Message-ID: On Mar 19, 2008, at 12:34 PM, David Williamson wrote: > > PI isn't the problem for DFZ costs, deaggregation is. The latter, > however, is going to be of increasing interest as space gets tight and > the entwork continues to grow. If nothing else, it allows more > efficient allocations to be made. Although if it's not PA and aggregated and instead PI with multi-homing then the impact to the routing system grows super-linearly as a factor of both number of multi-homing instances and routing system interconnection denseness. That is, while the sum of unique FIB entries may not increase, the existence of more unique paths and more churn require more FIB IO, processor memory, CPU, etc.. -danny From mksmith at adhost.com Wed Mar 19 15:56:59 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 19 Mar 2008 12:56:59 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <47E15F2D.1030401@internap.com> References: <20080318204427.1FACD45019@ptavv.es.net><47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.><47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <17838240D9A5544AAA5FF95F8D520316037A7952@ad-exh01.adhost.lan> <47E15F2D.1030401@internap.com> Message-ID: <17838240D9A5544AAA5FF95F8D520316037A79CC@ad-exh01.adhost.lan> > -----Original Message----- > From: Scott Leibrand [mailto:sleibrand at internap.com] > Sent: Wednesday, March 19, 2008 11:45 AM > To: Michael K. Smith - Adhost > Cc: arin ppml > Subject: Re: [ppml] Policy to help the little guys > > Michael K. Smith - Adhost wrote: > > Hello Scott: > > > >> I'm not sure what else the "little guys" need as far as policy. > Does > >> anyone else have any other suggestions? > >> > > How about a reservation of some block of space for allocations of > /20's to Members that only meet those requirements? > > Not sure I follow. Meet which requirements? Reserve a block (/8, /16, whatever) for allocation in /20 or more specific increments to Members who meet the requirements for receiving a /20. Basically, just reserve some space for smaller providers so that they can get their /20 even if the larger blocks have been exhausted. But, you wouldn't assign a /19 from that block, nor would you assign multiple /20's to someone who normally gets a /16. That is, you have to be "Small to Medium" to get an allocation from that block. Regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 475 bytes Desc: not available URL: From owen at delong.com Wed Mar 19 16:06:47 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 20 Mar 2008 05:06:47 +0900 Subject: [ppml] Policy to help the little guys In-Reply-To: <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> Message-ID: <81D0F51E-6961-4980-B408-A7895D56AA83@delong.com> On Mar 20, 2008, at 2:03 AM, William Herrin wrote: > On Wed, Mar 19, 2008 at 2:38 AM, David Williamson +arin at tellme.com> wrote: >> I'd be in favor of that. I still think there's a lot of demand for >> multi-homed sites that have a legitimate need for PI. Forcing small >> multi-homed sites to lie to get PI space seems less than ideal given >> the constraints of IPv4 availability. If you can get a PA /24 for >> multi-homing, and anyone can, why can't you get PI? It's not like >> it's >> going to pollute the routing table any more than the PA /24. The >> only >> "advantage" to the PA /24 is that you get stuck with one of your >> upstreams, whether you like it or not. I'll also note that the other >> RIRs already have made this shift. > > Hi David, > > The main problem with PI assignments is the systemic cost of > announcing a BGP prefix ( http://bill.herrin.us/network/bgpcost.html > ). If you look at the things from a different perspective, the problem > is the lack of mechanisms by which the 27000 active AS's can recover > the BGP cost directly from the folks announcing a prefix. > The cost of a PI assignment and a multi-homed PA /24 is identical from a routing table perspective. Both end up announced into the routing table. In fact, for "TE", Verizon and others announce (or forward the announcement of) many PA more specifics that are not even connected to more than one independent AS. > The prefix length restriction at the RIRs is a somewhat upside-down > way of assuring that few who aren't putting lots of money into the > infrastructure can consume the expensive resource. To justify a /22 > you must document a fairly sizable IT operation, one whose nature will > require spending at least tens of thousands of dollars a year on > Internet transit. > Not true. One can easily support sufficient IT infrastructure to legitimately utilize more than 512 host addresses for just over $100/month if one is frugal and has a relatively low traffic per host footprint. > Solve either variant of the BGP cost problem first (cut the cost or > figure out how to bill for it) and there'll be no reason for ARIN to > maintain a limit on minimum assignment size. > Since the BGP cost problem is identical in the case of a multi-homed end-site whether they get their space from PA or PI, I don't see how this is a legitimate argument. Indeed, instead, it seems to me that the current restrictions constitute a Pony for the incumbent ISPs supporting provider lock-in. Owen From arin-contact at dirtside.com Wed Mar 19 16:17:32 2008 From: arin-contact at dirtside.com (William Herrin) Date: Wed, 19 Mar 2008 16:17:32 -0400 Subject: [ppml] Policy to help the little guys In-Reply-To: <9AAEA4D2-C4B3-414E-BC5A-E9441EADCFFD@tcb.net> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> <9AAEA4D2-C4B3-414E-BC5A-E9441EADCFFD@tcb.net> Message-ID: <3c3e3fca0803191317nd031da3id84670f2c3de85a6@mail.gmail.com> On Wed, Mar 19, 2008 at 1:49 PM, Danny McPherson wrote: > > http://bill.herrin.us/network/bgpcost.html > > I'm certainly not an economist (though I do have a background > similar to many of those here who now believe they are), but > I think trivializing in such a manner is a bit disingenuous. Hi Danny, I'm not a cost analyst but I have the advantage of having an award-winning cost analyst in the family. I asked him to vet the analysis for me. The short version of his answer is that my analysis uses appropriate methodology, so if the individual source numbers hold then so does the result. The long version included about an hour's discussion explaining how estimating the cost of fighter aircraft was reduced to a formula which considered only three simple input numbers. It was truly fascinating and I couldn't accurately repeat it to save my life. On Wed, Mar 19, 2008 at 2:34 PM, David Williamson wrote: > Can you explain to me how a PI /24 would be in any way different from > an otherwise identical PA /24? If an end-site is multi-homed with a /24, > it seems to me that the cost is the same for PA or PI. I can get a PA > /24 for multihoming pretty easily. Why can't I get PI? Hi David, The difference between PA and PI is an artificial result of the RIRs' upside down solution to the BGP cost problem. You can't get PI because you probably won't put enough money into the backbone infrastructure to fairly cover the cost of your being there while someone getting PA probably will. Barring a better solution to BGP cost, it doesn't really help to point out what we already know: that the difference between PI and PA is arbitrary and artificial. However goofy, that distinction has kept the ever-threatening BGP table explosion down to a steady creep. We need it as a crutch, a placeholder until someone comes up with a better solution. If you're interested in tackling the problem from the "reduce BGP cost until it's moot" angle, you should catch up with the folks involved in the IRTF RRG and join the mailing list. Details at http://www.irtf.org/charter?gtype=rg&group=rrg I'm not aware of anyone actively working on a way to fairly bill those announcing a route for carrying that announcement. Perhaps you'd like to get something started? Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From owen at delong.com Wed Mar 19 16:18:47 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 20 Mar 2008 05:18:47 +0900 Subject: [ppml] Policy to help the little guys In-Reply-To: <47E15E56.1000006@internap.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <47E0B7E0.6060903@psg.com> <47E15E56.1000006@internap.com> Message-ID: On Mar 20, 2008, at 3:41 AM, Scott Leibrand wrote: > Randy Bush wrote: >> David Williamson wrote: >>> If you can get a PA /24 for multi-homing, and anyone can, why can't >>> you get PI? >> >> as a gedanken experiment, and maintaining my reputation as a >> notorious >> trouble-maker, why not longer than /24? e.g. take a /16 and create a >> well-known micro-swamp of say /29s for multi-homed content sites. >> >> i am not necessarily advocating this. but i think the exercise of >> discussing the pros and cons might be good for us. > > I can think of a few reasons to stop at /24 for now, but I think the > most important is that IMO policy shouldn't force ISPs to liberalize > filter policy, but rather should respond to it. To date, most ISPs > accept PA /24's, so allowing PI blocks down to /24 won't change things > much. But giving out PI blocks smaller than /24 would create a lot of > additional pressure on ISPs to accept the smaller blocks. > Scott, ARIN policy cannot force ISPs to do anything with regard to routing, so, this argument is specious at best. ISPs can filter on whatever boundary they was, and, if you don't believe that, I point you back to your statement that "MOST" ISPs accept PA /24s. If ARIN policy were "forcing", then, the ARIN policy allowing a PA /24 strictly on the basis of being multi-homed would require that ALL ISPs accepted PA /24s. I don't pretend to know what the best stopping point is, but, I will say that the disconnect in prefix size between 4.2.3.6 and 4.3.2.2 strikes me as nothing short of hypocrisy. > I would rather focus on matching PI policy to what ISPs have already > demonstrated they're ok with for PA space, rather than having PI lead > the way. If ISPs decide in a year or two to start relaxing the /24 > boundary, then I think it would be appropriate to adjust the PI > minimum > as well. > I would rather focus on having policies that meet the needs of legitimate multi-homed end-users and let ISPs manage their routing tables. Owen From danny at tcb.net Wed Mar 19 16:43:07 2008 From: danny at tcb.net (Danny McPherson) Date: Wed, 19 Mar 2008 14:43:07 -0600 Subject: [ppml] Policy to help the little guys In-Reply-To: <3c3e3fca0803191317nd031da3id84670f2c3de85a6@mail.gmail.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> <9AAEA4D2-C4B3-414E-BC5A-E9441EADCFFD@tcb.net> <3c3e3fca0803191317nd031da3id84670f2c3de85a6@mail.gmail.com> Message-ID: <6CDAFA66-EBAA-49BC-84D6-176405CAE1D9@tcb.net> On Mar 19, 2008, at 2:17 PM, William Herrin wrote: > > Hi Danny, > > I'm not a cost analyst but I have the advantage of having an > award-winning cost analyst in the family. I asked him to vet the > analysis for me. The short version of his answer is that my analysis > uses appropriate methodology, so if the individual source numbers hold > then so does the result. I'm not saying it's not a worthwhile exercise, I'm simply saying that for anyone that has attempted to compute the cost of bit carriage on an IP packet network based on distance carried, or destination network class (e.g., peer v. customer), or class of service, or router platform redundancy requirements, or rack space, or power consumption, or AC, or amount of required resilience (e.g., SRLGs), access platform redundancy, network management infrastructure, much less OPEX, etc..., or been through similar pricing models, it's just not that simple. Adding global variables to this such as global routing system interconnection denseness, degree of multi-homing, churn(?), etc.. all have implications, as the number of paths increase, which impacts all the previously stated resources, and is mostly non-deterministic given the dynamics of the routing system itself. Put it this way, had I told our product management folks to bill customers based strictly on the number of IPs they used, rather than based on some algorithm that factors all OPEX and CAPEX associated with service delivery, well, I know where that would have ended :-) -danny From dlw+arin at tellme.com Wed Mar 19 16:54:17 2008 From: dlw+arin at tellme.com (David Williamson) Date: Wed, 19 Mar 2008 13:54:17 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <3c3e3fca0803191317nd031da3id84670f2c3de85a6@mail.gmail.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> <9AAEA4D2-C4B3-414E-BC5A-E9441EADCFFD@tcb.net> <3c3e3fca0803191317nd031da3id84670f2c3de85a6@mail.gmail.com> Message-ID: <20080319205417.GD24095@shell01.cell.sv2.tellme.com> On Wed, Mar 19, 2008 at 04:17:32PM -0400, William Herrin wrote: > The difference between PA and PI is an artificial result of the RIRs' > upside down solution to the BGP cost problem. You can't get PI because > you probably won't put enough money into the backbone infrastructure > to fairly cover the cost of your being there while someone getting PA > probably will. I'm entirely baffled by this assertion. My site uses PI space, but we're highly multihomed and default-free. We clearly pay the same costs to participate in the DFZ as anyone else. Our upstream peers charge us for bandwidth and the privilege of peering with them. We have routers of sufficient scale to support our existence in the DFZ. Your assertion seems to imply that any org like mine isn't paying it's fair share, but we would be with the exact same setup in PA space. In other words, if we got space from one of our upstreams, we'd magically be paying our share. I don't doubt your analysis shows that inserting a route in the DFZ causes a bit of expense for everyone else in the DFZ, but I don't see how PA versus PI has anything to do with it. The only way I see PI as destructive in the way you describe is for a PI site to be singlehomed with a default route to their upstream and an announcement of their AS and IP space. In that case, you need a Cisco 2514, and you are probably not bearing your fair share of the costs of your route. I've already stated that I don't understand the utility of singlehomed PI. In the multihomed case, however, I think your assertion in the quoted message is entirely incorrect. I've also hit my own quota for posts in one day, so I think I'll let others chat on these topics for a bit. -David From lsc at prgmr.com Wed Mar 19 09:11:46 2008 From: lsc at prgmr.com (Luke S Crawford) Date: 19 Mar 2008 09:11:46 -0400 Subject: [ppml] Policy to help the little guys In-Reply-To: <20080319161600.GX24095@shell01.cell.sv2.tellme.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <1c16a4870803190903n63e9d79bhd1ebfbd6359d1cb2@mail.gmail.com> <20080319161600.GX24095@shell01.cell.sv2.tellme.com> Message-ID: David Williamson writes: > To be clear, any proposal that I'm likely to support would require the > recipient of a PI /24 to be multihomed. Heck, I'd be happy if there > was no non-multihomed PI available. I don't quite get why large > singlehomed PI space is permitted under the current policy. If you > don't need to be multihomed, get space from an ISP. >From a end-user or ISP perspective, assuming you have the technical resources on hand to deal with it, having your own IP space is advantageous even when you are single-homed because it makes changing transit providers much easier. IP addresses, if they are owned by your provider, function to a greater or lesser degree as 'lock-in' - if renumbering is expensive (and depending on what sort of services you sell (and if you or your customers control the dns) it can go from trivial to crushingly expensive) The idea is that a profit-seeking service provider, if they know it is expensive for you to move, is likely to increase the price (or decrease service, etc..) until they are just under the industry standard cost plus the cost of renumbering. I'm not arguing that you should hand out PI space to smaller operators at the expense of larger operators (who then need to maintain larger routers.) Clearly there is a balance that needs to be struck and I'm not claiming to know where that balance should be. I am just trying to explain why the smaller operators strongly prefer PI space rather than addresses tied to the transit they buy. From randy at psg.com Wed Mar 19 18:26:57 2008 From: randy at psg.com (Randy Bush) Date: Thu, 20 Mar 2008 07:26:57 +0900 Subject: [ppml] Policy to help the little guys In-Reply-To: <20080319183438.GZ24095@shell01.cell.sv2.tellme.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> <20080319183438.GZ24095@shell01.cell.sv2.tellme.com> Message-ID: <47E19331.20001@psg.com> > Can you explain to me how a PI /24 would be in any way different from > an otherwise identical PA /24? If an end-site is multi-homed with a /24, > it seems to me that the cost is the same for PA or PI. induce that this is also independent of prefix length randy From arin-contact at dirtside.com Wed Mar 19 18:27:28 2008 From: arin-contact at dirtside.com (William Herrin) Date: Wed, 19 Mar 2008 18:27:28 -0400 Subject: [ppml] Policy to help the little guys In-Reply-To: <6CDAFA66-EBAA-49BC-84D6-176405CAE1D9@tcb.net> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> <9AAEA4D2-C4B3-414E-BC5A-E9441EADCFFD@tcb.net> <3c3e3fca0803191317nd031da3id84670f2c3de85a6@mail.gmail.com> <6CDAFA66-EBAA-49BC-84D6-176405CAE1D9@tcb.net> Message-ID: <3c3e3fca0803191527n40a6bb40i19d9041ec68bb451@mail.gmail.com> On Wed, Mar 19, 2008 at 4:43 PM, Danny McPherson wrote: > I'm not saying it's not a worthwhile exercise, I'm simply > saying that for anyone that has attempted to compute the > cost of bit carriage on an IP packet network based on > distance carried, or destination network class (e.g., peer v. > customer), or class of service, or router platform redundancy > requirements, or rack space, or power consumption, or AC, > or amount of required resilience (e.g., SRLGs), access > platform redundancy, network management infrastructure, > much less OPEX, etc..., or been through similar pricing > models, it's just not that simple. Hi Danny, The nice thing about all of those factors is that they intersect at two easily measured junctions: the price you'd pay to run with devices that do all of it and the price you'd pay to run with devices that do all of it except the required large routing table. The art to cost analysis is finding those junctions so that you can eliminate the subfactors from the equation. Personally, I'm more interested in looking for creative solutions to the BGP cost problem that would moot the whole PI/PA issue than I am rehashing the semi-annual "PI folks are treated unfairly" debate. Suppose you did something like this: 1. ARIN takes a /16 and lets it be known that only /25 or longer PI prefixes will be assigned from this /16 (nothing /24 or shorter). 2. Each registrant tells ARIN exactly what routes they intend to announce out of their PI prefixes. 3. Transit ASes which want to participate can register the number of DFZ routers they have with ARIN. ARIN will pay them a monthly amount that works out to $0.04 per router in the AS per registered route in the /16 per year. So, if there are 4096 /28's coming from the /16 and Verizon has 400 DFZ routers, ARIN will pay Verizon (4096*400*0.04)/12 =$5500/mo to carry those routes. In return, participating ASes agree to either filter no routes they receive or transmit within the /16 or filter only those routes which don't match ARIN's list. 4. ARIN then collects that same fee plus a handling surcharge from each of the PI registrants who registered a route announcement within the /16. So, if transit ASes with a total of 50,000 routers have signed up and you've registered to announce one /26 route for your /26 assignment then you pay ARIN (($0.04*50,000)/12)*1.1 = $183/mo for the BGP announcements, thereby guaranteeing that they're carried by 50,000 of the DFZ routers. 5. Each year, ARIN solicits bids for an ISP to serve as a "catchall" tunnel broker for the whole /16. The tunnel broker announces the whole /16 and (if you pay him) then tunnels any traffic to you via GRE in order to cover whatever sections of the 'net decided to filter the /25 and longer routes instead of accepting payments from ARIN. Each year the registrants within the /16 get to vote on which tunnel broker bid to accept. Note that if enough of the DFZ routers are carrying the small routes (including your local ISPs) there is a very good chance that packets for you will navigate via the /16 route in non-participating ASes and then latch on to your /25 or longer route once they reach a participating AS. Now, that could let folks announcing routes pay for those announcements so that ARIN could get out of the business of setting minimum PI assignment length. Workable? Maybe, maybe not. But at least it's trying to solve the problem which led to PA/PI instead of complaining about how unfair it is. Here's an entirely different tack: 1. ARIN takes a /16 and lets it be known that only /25 or longer PI prefixes will be assigned from this /16. 2. Each year, ARIN solicits bids for a tier-1 backbone to announce a /16 route which covers the prefix. The registrants within the /16 vote on which tier-1 bid to accept. 3. Each registrant makes private arrangements (or hires an agent to do so) between himself and a reasonable set of ISPs that lie between him and the tier-1 announcing the /16 so that they carry his route. For a dual-homed network, this will typically be less than 10 companies including the tier-1 itself. On Wed, Mar 19, 2008 at 4:54 PM, David Williamson wrote: > I'm entirely baffled by this assertion. [...] > I don't doubt your analysis shows that inserting a route in the DFZ > causes a bit of expense for everyone else in the DFZ, but I don't see > how PA versus PI has anything to do with it. David, The answer, of course, is that PI and PA shouldn't have anything to do with it. Everyone announcing a route should pay for announcing that route directly. Unfortunately, no one has figured out how to make that work so PA/PI serves as a poorly fitting proxy that's been good enough to keep the system stable. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From randy at psg.com Wed Mar 19 18:29:48 2008 From: randy at psg.com (Randy Bush) Date: Thu, 20 Mar 2008 07:29:48 +0900 Subject: [ppml] Policy to help the little guys In-Reply-To: <47E15E56.1000006@internap.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <47E0B7E0.6060903@psg.com> <47E15E56.1000006@internap.com> Message-ID: <47E193DC.5090708@psg.com> > I can think of a few reasons to stop at /24 for now, but I think the > most important is that IMO policy shouldn't force ISPs to liberalize > filter policy, but rather should respond to it. the /19 filter length was negotiated between registries and isps in danvers as a cooperation. the extensions down to today's lengths similarly, though thank the ghodesses not in danvers. i think it is safe to assume that, given sufficient warning, if a micro-swamp was created, folk would open a filter hole for it. after all, we did not used to allow /24s. randy From mack at exchange.alphared.com Wed Mar 19 18:31:33 2008 From: mack at exchange.alphared.com (mack) Date: Wed, 19 Mar 2008 17:31:33 -0500 Subject: [ppml] Policy to help the little guys In-Reply-To: References: Message-ID: <859D2283FD04CA44986CC058E06598F85F28D8F169@exchange4.exchange.alphared.local> > ------------------------------ > > Message: 2 > Date: Thu, 20 Mar 2008 05:06:47 +0900 > From: Owen DeLong > Subject: Re: [ppml] Policy to help the little guys > To: William Herrin > Cc: Randy Bush , arin ppml > Message-ID: <81D0F51E-6961-4980-B408-A7895D56AA83 at delong.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > [snip] > > The cost of a PI assignment and a multi-homed PA /24 is identical > from a routing table perspective. Both end up announced into > the routing table. The /24s are in the routing table one way or the other. > > In fact, for "TE", Verizon and others announce (or forward the > announcement of) many PA more specifics that are not even > connected to more than one independent AS. > > > The prefix length restriction at the RIRs is a somewhat upside-down > > way of assuring that few who aren't putting lots of money into the > > infrastructure can consume the expensive resource. To justify a /22 > > you must document a fairly sizable IT operation, one whose nature > will > > require spending at least tens of thousands of dollars a year on > > Internet transit. > > > Not true. One can easily support sufficient IT infrastructure to > legitimately utilize more than 512 host addresses for just over > $100/month if one is frugal and has a relatively low traffic per > host footprint. > Current policy still allows for IP based hosting for a number of things including SSL certs (which older computers still don't support properly). ($12/cert + $6/domain)* 512 = $768/mo. Not exactly frugal and throw in a pair of cheap T1s ($200/mo). So yes it is very possible to contribute very little and still use up a routing slot. > > Solve either variant of the BGP cost problem first (cut the cost or > > figure out how to bill for it) and there'll be no reason for ARIN to > > maintain a limit on minimum assignment size. > > > Since the BGP cost problem is identical in the case of > a multi-homed end-site whether they get their space > from PA or PI, I don't see how this is a legitimate argument. > > Indeed, instead, it seems to me that the current restrictions > constitute a Pony for the incumbent ISPs supporting provider > lock-in. > > Owen PA vs PI division does support provider lock in. So in that sense it is a Pony for the ISPs. It also means that the PA customers are paying for a lot of routers for the ISPs. I am not sure which way to go on this proposal. It does cost a lot per routing slot and discouraging indiscriminant use of routing slots is a good goal. Some TE is necessary and unavoidable. Anyone with a sufficient business case for being multi-homed is going to be multi-homed. Cost is not a big barrier. -- LR Mack McBride Network Administrator Alpha Red, Inc. From jrhett at svcolo.com Wed Mar 19 19:49:23 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Wed, 19 Mar 2008 16:49:23 -0700 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <200803180220.m2I2KDqb003250@cjbsys.bdb.com> References: <200803180220.m2I2KDqb003250@cjbsys.bdb.com> Message-ID: Cliff, my reading of 2008-2 does exactly that. You're restating pretty clear the goal of the proposal. The "market" would and does exist independant of ARIN. The only question was whether ARIN should provide a listing service. On Mar 17, 2008, at 7:20 PM, Cliff Bedore wrote: > It seems to me that all that 2008-2 needs to do is add a third > method once the > IANA free pool is gone. > > 3) Party 1 offers to transfer to Party 2 some block of addresses. > Party 1 > has the right to offer and Party 2 justifies the right to receive the > addresses. No market, no ARIN involvement with SEC, just ARIN > approving use > of a block of addresses. > > Why is this not a simple way to handle the end of life address > management of > v4 addresses? ARIN gets their fees just like now so they remain > viable but > have no interaction with the "market" and its associated problems. > > Cliff > > -- > Cliff Bedore > 7403 Radcliffe Dr. College Park MD 20740 > cliffb at cjbsys.bdb.com http://www.bdb.com > Amateur Radio Call Sign W3CB For info on ham radio, http:// > www.arrl.org/ > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the > ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From jrhett at svcolo.com Wed Mar 19 19:55:53 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Wed, 19 Mar 2008 16:55:53 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <20080319065933.GT24095@shell01.cell.sv2.tellme.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <47E0B7E0.6060903@psg.com> <20080319065933.GT24095@shell01.cell.sv2.tellme.com> Message-ID: On Mar 18, 2008, at 11:59 PM, David Williamson wrote: > If my site has no useful interaction with somewhereistan, > I can simply block the short prefixes from them. Or, at a higher > level, I could just block all of the /8s associated with a specific > RIR, based on my business model/needs. On the flip side, I could > accept a bunch of /28s or /29s from sites important to me. > > All it would take is some hard to maintain filters. One assumes you are no longer using those purple boxes in production? Because the memory usage of a blocked route and the memory usage of an accepted route are identical in that case. Filtering the prefixes won't help you there. It's not as bad, but nearly so with Cisco last time I checked. So if we accept a /16 of /29 routes, you're looking at adding 8192k new entries to the table. Most of our peers are currently advertising 244k routes to us. That brings it to 252k routes, which is very *very* near the max table size of most production equipment out there. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From tony.li at tony.li Wed Mar 19 20:08:52 2008 From: tony.li at tony.li (Tony Li) Date: Wed, 19 Mar 2008 17:08:52 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <20080319205417.GD24095@shell01.cell.sv2.tellme.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com><20080319025901.GB17899@vacation.karoshi.com.><47E08662.1040701@psg.com> <47E0A524.8090506@internap.com><20080319063840.GR24095@shell01.cell.sv2.tellme.com><3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com><9AAEA4D2-C4B3-414E-BC5A-E9441EADCFFD@tcb.net><3c3e3fca0803191317nd031da3id84670f2c3de85a6@mail.gmail.com> <20080319205417.GD24095@shell01.cell.sv2.tellme.com> Message-ID: <000001c88a1e$9c0def30$bb2b359b@ad.redback.com> David, |Your assertion seems to imply that any org like mine isn't paying it's |fair share, but we would be with the exact same setup in PA space. In |other words, if we got space from one of our upstreams, we'd magically |be paying our share. More precisely, if you were using PA without deaggregating it into a global advertisement, then you wouldn't cause others to incurr costs. |The only way I see PI as destructive in the way you describe is for a |PI site to be singlehomed with a default route to their upstream and an |announcement of their AS and IP space. In that case, you need a Cisco |2514, and you are probably not bearing your fair share of the costs of |your route. I've already stated that I don't understand the utility of |singlehomed PI. In the multihomed case, however, I think your |assertion |in the quoted message is entirely incorrect. Being multihomed does not decrease the costs associated with a global advertisement. Certainly, it's more rational, but regardless of the motivations, a global advertisement costs everyone the same. Tony From tony.li at tony.li Wed Mar 19 20:08:52 2008 From: tony.li at tony.li (Tony Li) Date: Wed, 19 Mar 2008 17:08:52 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <20080319183438.GZ24095@shell01.cell.sv2.tellme.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com><20080319025901.GB17899@vacation.karoshi.com.><47E08662.1040701@psg.com> <47E0A524.8090506@internap.com><20080319063840.GR24095@shell01.cell.sv2.tellme.com><3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> <20080319183438.GZ24095@shell01.cell.sv2.tellme.com> Message-ID: <000101c88a1e$a22784d0$bb2b359b@ad.redback.com> |PI isn't the problem for DFZ costs, deaggregation is. The latter, |however, is going to be of increasing interest as space gets tight and |the entwork continues to grow. If nothing else, it allows more |efficient allocations to be made. Deaggregation is the self-inflicted portion of the DFZ costs. Those who are affected are those who deaggregate and their peers. In the very long term, mutual pain _should_ cause folks to suppress deaggregation. PI is the portion of the DFZ costs that we can and should fix at an architectural level. Regards, Tony From tvest at pch.net Wed Mar 19 20:13:24 2008 From: tvest at pch.net (Tom Vest) Date: Wed, 19 Mar 2008 20:13:24 -0400 Subject: [ppml] Policy to help the little guys In-Reply-To: References: <20080318204427.1FACD45019@ptavv.es.net><47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.><47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> Message-ID: Hi Ray, Sorry for delayed response -- laptop failure this morning :-| Michael's suggestion is interesting, and would probably be very useful for a variety of questions , but I have something fairly specific in mind. Imagine that all of the IPv4 entries in the ARIN "delegated" file had two additional columns. For PA IPv4 allocations, the first new column for each of the entries would contain an "i" or an "s", to indicate whether they were an initial or a subsequent allocation. PI allocations would be marked with an "i" also. In the second column, each entry would be annotated with the policy-defined minimum size initial allocation for that particular time period (note: this second data point is far less important than the first, and could probably be guessed fairly easily using the other delegated data plus that s/i flag). Once the entries were so annotated, all of the "delegated" entries would be sorted/counted, ideally by year and by "policy period" (e.g., the entries corresponding to the /19 min. allocation era would be grouped together, separately from the entries for the /20 min., et al. periods). If this proved to be too difficult, annual groupings would be almost as helpful. For each time period or policy era, the counts of interest would be: (A) Number, PA initial or PI allocations (of prefix length i) (B) Number, PA subsequent allocations (of prefix length i or longer). (C) Number, PA subsequent allocations (of prefix length i minus one). (D) Number, PA subsequent allocations (shorter than (i minus one)). With these data points, you could make rough statements about the frequency of occasions when "new entrants" and "incumbents" were seeking prefixes of roughly the same length. For example, if ARIN staff had to make these calculations (e.g., to preserve confidentiality, etc.), they might come back with statements/graphs that show: Obs1: "In years (x,y,z...), for every initial allocation transaction, there were (B/A) subsequent allocations for prefixes of equal length or longer. Obs2: In years (x,y,z...), of the (A+B+C+D) total IPv4 delegations, (one - (C+D)/(A+B+C+D)) percent involved operators seeking roughly the same (initial-alloc) size prefix. Obs3: In years (x,y,z...), of the (A+B+C=D) total IPv4 delegations, (C) delegations or (C/(A+B+C+D)) percent of the total were subsequent allocations that could have been satisfied by two initial-alloc sized prefixes. Here's why I think this data would be illuminating. If I'm interpreting 2008-02 correctly, many of the limitations in deaggregation, exact "need" to prefix length matching, etc. are included in part to foster the emergence of "convex pricing", wherein each /32 that's part of a shorter prefix is worth more the equivalent in a longer prefix -- so for example, a single /20 would always command a higher price than would 2x /21. Over the course of multiple conversations with 2008-02 supporters over the last couple of weeks, this "convex pricing" pattern has been repeatedly identified as the primary mechanism to help "the little guys". If I followed those conversations correctly, the reasoning is that if such a pattern emerges, and a supply of long-ish prefixes persists, then those resources would remain accessible to new entrants and small operators, and thereby keep the industry open. Here's where the data request comes in. If either or both (Obs1, Obs2) are large numbers, then history would suggest that even if all address seekers want to follow the 2008-02 process, there could be frequent contention for prefixes of the same size. If convex pricing does emerge for other (e.g., policy-driven) reasons, prefixes of the same size will be priced roughly the same -- at least in the sense that they'll cost more than 2x (next longest prefix) and less than (0.5* next shortest prefix). However, if those (Obs1, Obs2) numbers are large, that suggests that operators are going to be frequently confronting temptation, e.g., to engage in bidding wars that might undermine the convex pricing pattern, or alternately to seek address space outside of the approved process -- e.g., the "gray market" for prefixes of the same size or longer. Obs3 would also provide some insight on how much more this pressure might affect "the littlest guys", i.e., new entrants. Granted history proves nothing, and historical lessons are doubly questionable across periods of radical change, but I think all of these observations would be useful as indications of how much/often the approved process (and/or the process administrators) might be subject to major stresses, and how often commercial operators might have to resist strong incentives to seek address space in ways that would undermine the quality of the ARIN registry. If the decentralized resource transfers are legitimized, and no other compliance-promoting mechanisms are instituted, then "convex pricing" and the intrinsic appeal of the 2008-02 process may have to carry most/all of the weight to keep the industry open and the ARIN central registry viable. Thus I think the community ought to have as much relevant information and analysis as possible before they have to make that choice. Needless to say, I'd be happy to help with the data crunching... Thanks, Tom On Mar 19, 2008, at 10:27 AM, wrote: >> Not sure what you are asking for, and then, don't know how >> long it will take to produce it. > > To me, it sounded like this, or perhaps a subset of this. > > For every ARIN IPv4 ISP/LIR, record the size of the base allocation > that > they first received and the date. Call this B. > > Then go through all the B's and figure the average size of B for each > month. Call this A. > > The go through all the ISP/LIR subsequent allocations and record the > date the size called S and two calculated values PB and PA. PB = S > as a > percent of B, and PA = S as a percent of A. > > Provide this data as a table in CSV format > > ISP #, B, A, Base Date, Subsequent Date, S, PA, PB > > That should be sufficiently parseable that people can do some charts > with it. For instance charting the average of PA and/or PB over time > would show if subsequent allocations are trending larger compared to > the > base allocation or compared to all other allocations made at the time > the base allocation was made. > > Or perhaps Tom could suggest a slightly different algorithm. > > --Michael Dillon > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the > ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. From jrhett at svcolo.com Wed Mar 19 20:18:14 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Wed, 19 Mar 2008 17:18:14 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <3c3e3fca0803191527n40a6bb40i19d9041ec68bb451@mail.gmail.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> <9AAEA4D2-C4B3-414E-BC5A-E9441EADCFFD@tcb.net> <3c3e3fca0803191317nd031da3id84670f2c3de85a6@mail.gmail.com> <6CDAFA66-EBAA-49BC-84D6-176405CAE1D9@tcb.net> <3c3e3fca0803191527n40a6bb40i19d9041ec68bb451@mail.gmail.com> Message-ID: <75C1242A-FA1F-4752-B663-8E17AF7F8C9A@svcolo.com> On Mar 19, 2008, at 3:27 PM, William Herrin wrote: > Personally, I'm more interested in looking for creative solutions to > the BGP cost problem that would moot the whole PI/PA issue than I am > rehashing the semi-annual "PI folks are treated unfairly" debate. > Suppose you did something like this: > > 1. ARIN takes a /16 and lets it be known that only /25 or longer PI > prefixes will be assigned from this /16 (nothing /24 or shorter). > ..... > 5. Each year, ARIN solicits bids for an ISP to serve as a "catchall" > tunnel broker for the whole /16. The tunnel broker announces the whole > /16 and (if you pay him) then tunnels any traffic to you via GRE in FYI I see nothing about this proposal that requires ARIN. It could be implemented by any current or future holder of /16 or whatever size space. It sounds like an ingenious marketing opportunity that if implemented in advance could become really valuable when IPv4 exhaustion occurs. Why don't you do this? Note: I'm not being sarcastic, but I do think it's overly complex for the required goal and likely won't be accepted by a majority of the market because they couldn't figure out how to debug it. But hey, assuming I'm wrong you get the best I Told You So, one you can use all the way to the bank. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From arin-contact at dirtside.com Wed Mar 19 21:12:46 2008 From: arin-contact at dirtside.com (William Herrin) Date: Wed, 19 Mar 2008 21:12:46 -0400 Subject: [ppml] Policy to help the little guys In-Reply-To: <75C1242A-FA1F-4752-B663-8E17AF7F8C9A@svcolo.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> <9AAEA4D2-C4B3-414E-BC5A-E9441EADCFFD@tcb.net> <3c3e3fca0803191317nd031da3id84670f2c3de85a6@mail.gmail.com> <6CDAFA66-EBAA-49BC-84D6-176405CAE1D9@tcb.net> <3c3e3fca0803191527n40a6bb40i19d9041ec68bb451@mail.gmail.com> <75C1242A-FA1F-4752-B663-8E17AF7F8C9A@svcolo.com> Message-ID: <3c3e3fca0803191812n1e904f92gc3bcb6f2af751f94@mail.gmail.com> On Wed, Mar 19, 2008 at 8:18 PM, Jo Rhett wrote: > On Mar 19, 2008, at 3:27 PM, William Herrin wrote: > > 5. Each year, ARIN solicits bids for an ISP to serve as a "catchall" > > tunnel broker for the whole /16. The tunnel broker announces the whole > > /16 and (if you pay him) then tunnels any traffic to you via GRE in > > FYI I see nothing about this proposal that requires ARIN. It could > be implemented by any current or future holder of /16 or whatever > size space. It sounds like an ingenious marketing opportunity that > if implemented in advance could become really valuable when IPv4 > exhaustion occurs. Why don't you do this? Hi Jo, Six reasons: 1. It is, as you say, overly complex. My second variant is more practical. 2. To be perceived as fair, the registry component must be handled by a neutral non-profit. There's no money in that. 3. The payment processor and tunnel broker components are more interesting as additions to an existing business than as a startup. I sold my last business some time ago and this idea doesn't sing sweetly enough for me to start another. 4. My hunch is that most of the folks disgruntled about the unavailability of PI space would not be willing to pay the actual cost of announcing a route into the entire DFZ. Again, my second variant is more practical. 5. No funding. And if a VC with a checkbook and pen is reading this, I have more interesting projects I'd like to discuss with you off-list. 6. This problem has been a problem for a long time. I'm really just trying to get people to think creatively about solving it instead of devolving into yet another round of "PI guys are treated so unfairly." Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From jrhett at svcolo.com Wed Mar 19 21:48:02 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Wed, 19 Mar 2008 18:48:02 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <3c3e3fca0803191812n1e904f92gc3bcb6f2af751f94@mail.gmail.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> <9AAEA4D2-C4B3-414E-BC5A-E9441EADCFFD@tcb.net> <3c3e3fca0803191317nd031da3id84670f2c3de85a6@mail.gmail.com> <6CDAFA66-EBAA-49BC-84D6-176405CAE1D9@tcb.net> <3c3e3fca0803191527n40a6bb40i19d9041ec68bb451@mail.gmail.com> <75C1242A-FA1F-4752-B663-8E17AF7F8C9A@svcolo.com> <3c3e3fca0803191812n1e904f92gc3bcb6f2af751f94@mail.gmail.com> Message-ID: On Mar 19, 2008, at 6:12 PM, William Herrin wrote: > 1. It is, as you say, overly complex. My second variant is more > practical. > .... > 6. This problem has been a problem for a long time. I'm really just > trying to get people to think creatively about solving it instead of > devolving into yet another round of "PI guys are treated so unfairly." I don't think that this kind of solution is relevant or requires ARIN in any form. I'd certainly vote against that. And while I cede you the "creative thought" thing, it just returns to "imagination masturbation" in my mind. The problem is *very* well known, and there ain't much we can do about it other than try to contain it until we can afford to upgrade all of our hardware to accept that many routes. This problem isn't new, and I would rather avoid listening to newbies rethink an old problem (unless they are all willing to read 16+ years of arguement about this on this and other mailing lists before posting) -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From randy at psg.com Wed Mar 19 21:57:46 2008 From: randy at psg.com (Randy Bush) Date: Thu, 20 Mar 2008 10:57:46 +0900 Subject: [ppml] Policy to help the little guys In-Reply-To: References: <20080318204427.1FACD45019@ptavv.es.net> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> <9AAEA4D2-C4B3-414E-BC5A-E9441EADCFFD@tcb.net> <3c3e3fca0803191317nd031da3id84670f2c3de85a6@mail.gmail.com> <6CDAFA66-EBAA-49BC-84D6-176405CAE1D9@tcb.net> <3c3e3fca0803191527n40a6bb40i19d9041ec68bb451@mail.gmail.com> <75C1242A-FA1F-4752-B663-8E17AF7F8C9A@svcolo.com> <3c3e3fca0803191812n1e904f92gc3bcb6f2af751f94@mail.gmail.com> Message-ID: <47E1C49A.8030009@psg.com> > The problem is *very* well known, and there ain't much we can do > about it other than try to contain it until we can afford to upgrade > all of our hardware to accept that many routes. how many additional routes does pi multihoming cause over pa? how many additional routes does /29 multihoming cause over /24? randy From arin-contact at dirtside.com Wed Mar 19 23:23:02 2008 From: arin-contact at dirtside.com (William Herrin) Date: Wed, 19 Mar 2008 23:23:02 -0400 Subject: [ppml] Policy to help the little guys In-Reply-To: References: <20080318204427.1FACD45019@ptavv.es.net> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> <9AAEA4D2-C4B3-414E-BC5A-E9441EADCFFD@tcb.net> <3c3e3fca0803191317nd031da3id84670f2c3de85a6@mail.gmail.com> <6CDAFA66-EBAA-49BC-84D6-176405CAE1D9@tcb.net> <3c3e3fca0803191527n40a6bb40i19d9041ec68bb451@mail.gmail.com> <75C1242A-FA1F-4752-B663-8E17AF7F8C9A@svcolo.com> <3c3e3fca0803191812n1e904f92gc3bcb6f2af751f94@mail.gmail.com> Message-ID: <3c3e3fca0803192023r3a372b28x27bdd2e50f0ff441@mail.gmail.com> On Wed, Mar 19, 2008 at 9:48 PM, Jo Rhett wrote: > And while I cede you the "creative thought" thing, it just returns to > "imagination masturbation" in my mind. That's nice. Do you think you could go three, maybe even four posts without tossing in a gratuitous insult? If not, I'd appreciate it if you'd make good on your promise to killfile my address. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From oberman at es.net Wed Mar 19 23:45:22 2008 From: oberman at es.net (Kevin Oberman) Date: Wed, 19 Mar 2008 20:45:22 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: Your message of "Thu, 20 Mar 2008 10:57:46 +0900." <47E1C49A.8030009@psg.com> Message-ID: <20080320034522.166264500F@ptavv.es.net> > Date: Thu, 20 Mar 2008 10:57:46 +0900 > From: Randy Bush > Sender: ppml-bounces at arin.net > > > The problem is *very* well known, and there ain't much we can do > > about it other than try to contain it until we can afford to upgrade > > all of our hardware to accept that many routes. > > how many additional routes does pi multihoming cause over pa? how many > additional routes does /29 multihoming cause over /24? 1. None. PI/PA is a total red herring. A route in the FIB is the same and the router has no idea if it came from the upstream or via direct allocation from an RIR. 2. None, but it you had out /29s, you will probably many prefixes in the DMZ from the same space that would otherwise be only one. The reality is that extending life of IPv4 address space and controlling the size of the DMZ are in direct opposition. The only real answer is to stop expanding the IPv4 network and the only way I see that happening is general use of IPv6 by end systems. That's both servers and eyeballs. Dual stack is worse than where we are today. *Sigh* Until then we will need to pick our poison and I suspect that growth of the FIB a bigger short term concern than the address space shortage. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From vixie at isc.org Wed Mar 19 23:47:38 2008 From: vixie at isc.org (Paul Vixie) Date: 20 Mar 2008 03:47:38 +0000 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: References: <200803180220.m2I2KDqb003250@cjbsys.bdb.com> Message-ID: jrhett at svcolo.com (Jo Rhett) writes: > ... > The "market" would and does exist independant of ARIN. ... can you give us a ferinstance? -- Paul Vixie From randy at psg.com Wed Mar 19 23:55:13 2008 From: randy at psg.com (Randy Bush) Date: Thu, 20 Mar 2008 12:55:13 +0900 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: References: <200803180220.m2I2KDqb003250@cjbsys.bdb.com> Message-ID: <47E1E021.1080900@psg.com> >> The "market" would and does exist independant of ARIN. ... > can you give us a ferinstance? and then have net.vigilantes descend on them? you're kidding, right? randy From paul at vix.com Wed Mar 19 23:58:38 2008 From: paul at vix.com (Paul Vixie) Date: Thu, 20 Mar 2008 03:58:38 +0000 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: Your message of "Thu, 20 Mar 2008 12:55:13 +0900." <47E1E021.1080900@psg.com> References: <200803180220.m2I2KDqb003250@cjbsys.bdb.com> <47E1E021.1080900@psg.com> Message-ID: <22272.1205985518@sa.vix.com> > >> The "market" would and does exist independant of ARIN. ... > > > can you give us a ferinstance? > > and then have net.vigilantes descend on them? it's hard to make policy in the current information vacuum. > you're kidding, right? i wasn't. i'm not doubting jo's word. i'm trying to understand the magnitude of the described market. i'd like to know whether it's the kind of thing that will move into an ARIN framework if any, or whether it'll die if ARIN adopts a framework. i'd like to know if it's dozens of "trades" per hour, per day, per year, or what. From randy at psg.com Thu Mar 20 00:05:13 2008 From: randy at psg.com (Randy Bush) Date: Thu, 20 Mar 2008 13:05:13 +0900 Subject: [ppml] Policy to help the little folk In-Reply-To: <20080320034522.166264500F@ptavv.es.net> References: <20080320034522.166264500F@ptavv.es.net> Message-ID: <47E1E279.6060109@psg.com> Kevin Oberman wrote: >> how many additional routes does /29 multihoming cause over /24? > 2. None, but it you had out /29s, you will probably many prefixes in the > DMZ from the same space that would otherwise be only one. i.e. if we lower the barrier to entry, more folk will enter. some may think it a feature not a bug. the fib collection is gonna grow if we remove barriers to entry, and some thing we should do so. but at least this does not also eat increasingly rare ipv4 space as badly. > The reality is that extending life of IPv4 address space and controlling > the size of the DMZ are in direct opposition. not necessarily. we could go further in the direction we are already seriously in, and give the rest of the address space to the giants. some may think this a bug not a feature. [ btw, though i started this sub-discussion, i am still listening and am of no firm opinion. as i said, i thought it important to at least discuss it. ] randy From farmer at umn.edu Thu Mar 20 00:22:06 2008 From: farmer at umn.edu (David Farmer) Date: Wed, 19 Mar 2008 23:22:06 -0500 Subject: [ppml] Newbie Questions In-Reply-To: References: <20080318204427.1FACD45019@ptavv.es.net>, <3c3e3fca0803191812n1e904f92gc3bcb6f2af751f94@mail.gmail.com>, Message-ID: <47E1A01E.7650.5E6128D@farmer.umn.edu> On 19 Mar 2008 Jo Rhett wrote: > The problem is *very* well known, and there ain't much we can do > about it other than try to contain it until we can afford to upgrade > all of our hardware to accept that many routes. This problem isn't > new, and I would rather avoid listening to newbies rethink an old > problem (unless they are all willing to read 16+ years of arguement > about this on this and other mailing lists before posting) As an admitted newbie to this discussion and the mailing list I have a few questions. A little more background first however; I'm not a newbie to big networking and to big network problems. I just haven't paid attention to addressing issues for a long time, especially IPv4. The network I work for has 5 Legacy /16, and a few Legacy /24s from the dawn of time, our first /16 was assigned over 20 years ago, long before ARIN. At one time we had other address space from some early providers, but we retruned most of that 9 or 10 years ago, providers were to much of a pain to deal with and it was not really justified for us to have more than our direct assignments anyway. In case your thinking "oh one of those Legacy address hogs". Well maybe, but we have over 70,000 access ports of GigE, with a 20G MPLS Backbone, servicing over 175 on-net buildings, with over 22,000,000 assignable square feet of space in one campus served by 3 of those /16s. We purchase over a total of 2Gb of transit on 4G of circuits and last year finished building our own 100Gb long-haul (1500 miles) optical transport network, it is shared with a few friends, and we are already planing the upgrade to the next 100G. Enough chest thumping; So with IPv6 becoming real and maybe even actually deployable for real people other than just network engineers (hey you can get to Google with it again and they say it will stay up this time), IPv4 exhaustion coming (and I don't think we're crying wolf this time), with things like the Legacy RSA and 2008-2 being kicked around, I thought it was time to start paying attention to ARIN, and more importantly so did my bosses. Finally to my questions; 1. You guys are batting around PI and PA, Provider Independent and Provider Aggregatable, the basic definitions I find in the RIPE FAQ and then the ancient RIPE-127. Any better or more recent references? 2. I see nothing about PA in the ARIN policy documentation, and ever so little about PI. If these are such important concepts to ARIN Policy why are they not defined better? Or at least some references, even one 13 year old would help. 3. If these are such fundamental concepts why do they seem to be so misunderstood by so many people? Could it be that they are not properly defined in ARIN policy? 4. Other than "read 16+ years of argument ... on this and other mailing lists" (the bosses didn't give me that much time to spend on this), is there a newbie FAQ or suggested reading list? I'm well versed in the Internet just haven't paid much attention to addressing policy. ================================================= David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 ================================================= From arin-contact at dirtside.com Thu Mar 20 00:39:05 2008 From: arin-contact at dirtside.com (William Herrin) Date: Thu, 20 Mar 2008 00:39:05 -0400 Subject: [ppml] Newbie Questions In-Reply-To: <47E1A01E.7650.5E6128D@farmer.umn.edu> References: <20080318204427.1FACD45019@ptavv.es.net> <3c3e3fca0803191812n1e904f92gc3bcb6f2af751f94@mail.gmail.com> <47E1A01E.7650.5E6128D@farmer.umn.edu> Message-ID: <3c3e3fca0803192139i21a99660xf3df59d533bd3ca7@mail.gmail.com> On Thu, Mar 20, 2008 at 12:22 AM, David Farmer wrote: > 2. I see nothing about PA in the ARIN policy documentation, and ever so > little about PI. If these are such important concepts to ARIN Policy why are > they not defined better? Or at least some references, even one 13 year old > would help. Hi David, ARIN doesn't define the types as PA or PI. It defines them as "allocations to LIRs" (PA) and "assignments to end users" (PI). I think we've taken to using PI and PA in discussions because when we talk about allocations and assignments, even folks who've been around a while get confused. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From farmer at umn.edu Thu Mar 20 00:51:06 2008 From: farmer at umn.edu (David Farmer) Date: Wed, 19 Mar 2008 23:51:06 -0500 Subject: [ppml] Newbie Questions In-Reply-To: <3c3e3fca0803192137t78b957d8sdd7a95a690751b@mail.gmail.com> References: <20080318204427.1FACD45019@ptavv.es.net>, <47E1A01E.7650.5E6128D@farmer.umn.edu>, <3c3e3fca0803192137t78b957d8sdd7a95a690751b@mail.gmail.com> Message-ID: <47E1A6EA.17278.600A633@farmer.umn.edu> On 20 Mar 2008 William Herrin wrote: > On Thu, Mar 20, 2008 at 12:22 AM, David Farmer wrote: > > 2. I see nothing about PA in the ARIN policy documentation, and ever so > > little about PI. If these are such important concepts to ARIN Policy why are > > they not defined better? Or at least some references, even one 13 year old > > would help. > > Hi David, > > ARIN doesn't define the types as PA or PI. It defines them as > "allocations to LIRs" (PA) and "assignments to end users" (PI). I > think we've taken to using PI and PA in discussions because when we > talk about allocations and assignments, even folks who've been around > a while get confused. Then why confuse things by using the term in 4.1.1 4.1.1. Routability - Provider independent (portable) addresses issued directly from ARIN or other Regional Registries are not guaranteed to be globally routable. Therefore, ISPs should consider the following order of priority when requesting IP address space: * Request IP address space from upstream provider * Request IP address space from provider?s provider * Request IP address space from ARIN (not guaranteed to be globally routable) And this is using PI in the context of ISPs not End Users too. So it's not quite as clean as you say. ================================================= David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 ================================================= From jlewis at lewis.org Thu Mar 20 01:00:17 2008 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 20 Mar 2008 01:00:17 -0400 (EDT) Subject: [ppml] Policy to help the little guys In-Reply-To: <47E0BC9E.2000100@psg.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <47E0B7E0.6060903@psg.com> <20080319065933.GT24095@shell01.cell.sv2.tellme.com> <47E0BC9E.2000100@psg.com> Message-ID: On Wed, 19 Mar 2008, Randy Bush wrote: > i was presuming the use of a well known /16 would be so that isps could > allow the long prefixes in that space. as it would be the same number > of prefixes if we gave them /24s, what's the loss? > > btw, i remember an arin meeting in denver when cja tore my head off and > bad mouthed me behind my back for proposing /24s. so watch out! Too many places likely have filters for longer than /24. Trying to announce /29s, even with RIR blessing from a "special" /16 would likely be worse than getting the first allocation from 69/8. I'm guessing a lot worse. According to https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html RIPE has 3 /8s worth of space in which the longest prefix given out is /29. Are any of you accepting up to /29 in 193/8 and 194/7? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From tedm at ipinc.net Thu Mar 20 03:21:13 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 20 Mar 2008 00:21:13 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: Message-ID: <006901c88a5a$faad99f0$6fce4b41@tedsdesk> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Jo Rhett > Sent: Wednesday, March 19, 2008 4:56 PM > To: David Williamson > Cc: Randy Bush; arin ppml > Subject: Re: [ppml] Policy to help the little guys > > > On Mar 18, 2008, at 11:59 PM, David Williamson wrote: > > If my site has no useful interaction with somewhereistan, > > I can simply block the short prefixes from them. Or, at a higher > > level, I could just block all of the /8s associated with a specific > > RIR, based on my business model/needs. On the flip side, I could > > accept a bunch of /28s or /29s from sites important to me. > > > > All it would take is some hard to maintain filters. > > One assumes you are no longer using those purple boxes in > production? Because the memory usage of a blocked route and the > memory usage of an accepted route are identical in that case. > Filtering the prefixes won't help you there. > > It's not as bad, but nearly so with Cisco last time I checked. > > So if we accept a /16 of /29 routes, you're looking at adding 8192k > new entries to the table. Most of our peers are currently > advertising 244k routes to us. That brings it to 252k routes, which > is very *very* near the max table size of most production equipment > out there. > OK I think I'm missing something in this discussion - could someone fill me in. My understanding is that a "little guy" multihomed ISP accepts routes fundamentally to allow himself to balance his OUTBOUND traffic. (his inbound traffic is a function of how other people are choosing to send traffic to him, based possibly on his advertisements and prepends he might be sending out, which may or may not be paid attention to, thus have nothing to do with the size of his route table) Now, I would further assume that networks out there advertising /29's don't have a lot of hosts in them - thus they are likely a teensy, tiny speck of the "little guy's" -outbound- traffic. Thus, the little guy ISP doesen't need to bother with accepting their advertisements (or more properly, having his upstreams modify their filters to send him longer prefixes than /24) he can just pick one of his feeds and default route whatever outbound traffic he is sending to these /29's. Sure, you lose redundancy for those /29s - but there's few people on 'em so what? I mean, the scenario of thousands of hosts that can generate millions of http or whatever requests into little guy's servers all behind a /29 seems to me to be extremely farfetched. Does such a network even exist at all? The scenario also seems unlikely that most "little guy" ISPs are even going to have a large amount of outbound traffic anyway. "little guy" companies that tend to generate a large amount of outbound traffic seem to me to be mainly in the hosting business - in which case their servers are very likely in a colocate facility somewhere and their outbound connectivity consists of a gigabit ethernet connection to their colocate host who has to bother with concerning themselves with all this traffic balancing stuff. I guess what I'm asking is in an Internet with the majority of users mostly behind a handful of superbig AS's, all little guy really needs to pay any attention to for effective load balancing is the large prefix advertisements, since the small under /24 prefixes are not the ones with the large numbers of users where the bulk of his traffic is flowing to. So, is this policy discussion actually solving a real problem, or are we all doing someone's theoretical CCIE homework question for them? Ted From tedm at ipinc.net Thu Mar 20 03:28:05 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 20 Mar 2008 00:28:05 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: Message-ID: <006a01c88a5b$efef3ef0$6fce4b41@tedsdesk> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Jon Lewis > Sent: Wednesday, March 19, 2008 10:00 PM > To: Randy Bush > Cc: arin ppml > Subject: Re: [ppml] Policy to help the little guys > > > According to > https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html > RIPE has 3 /8s worth of space in which the longest prefix > given out is > /29. Are any of you accepting up to /29 in 193/8 and 194/7? Not here we filter anything longer than a /24 Ted From michael.dillon at bt.com Thu Mar 20 06:02:57 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 20 Mar 2008 10:02:57 -0000 Subject: [ppml] Policy to help the little guys In-Reply-To: <20080319205417.GD24095@shell01.cell.sv2.tellme.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com><20080319025901.GB17899@vacation.karoshi.com.><47E08662.1040701@psg.com> <47E0A524.8090506@internap.com><20080319063840.GR24095@shell01.cell.sv2.tellme.com><3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com><9AAEA4D2-C4B3-414E-BC5A-E9441EADCFFD@tcb.net><3c3e3fca0803191317nd031da3id84670f2c3de85a6@mail.gmail.com> <20080319205417.GD24095@shell01.cell.sv2.tellme.com> Message-ID: > Your assertion seems to imply that any org like mine isn't > paying it's fair share, but we would be with the exact same > setup in PA space. In other words, if we got space from one > of our upstreams, we'd magically be paying our share. The argument boils down to the fact that smaller ISPs announcing into the DFZ, have not been able to achieve the same economies of scale as larger ISPs, therefore these smaller ISPs are unfairly pushing the costs onto the larger ISPs. I don't buy that argument, by the way. In addition, people seem to think that if the larger ISPs were able to impose a centrally-managed economy for DFZ announcements, this would be overall, more efficient than the current regime. However they are forgetting to account for the costs of the central management regime itself. Past experience with both communist economies, and with telco billing infrastructure, shows that the costs of the central management regime often can and do far outweigh the benefits that they achieve. --Michael Dillon From plzak at arin.net Thu Mar 20 06:27:43 2008 From: plzak at arin.net (Ray Plzak) Date: Thu, 20 Mar 2008 06:27:43 -0400 Subject: [ppml] Policy to help the little guys In-Reply-To: References: <20080318204427.1FACD45019@ptavv.es.net><47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.><47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> Message-ID: Tom, Taking this offline. Sent you a message. Ray > -----Original Message----- > From: Tom Vest [mailto:tvest at pch.net] > Sent: Wednesday, March 19, 2008 8:13 PM > To: Ray Plzak > Cc: arin ppml; michael.dillon at bt.com> > Subject: Re: [ppml] Policy to help the little guys > > Hi Ray, > > Sorry for delayed response -- laptop failure this morning :-| > Michael's suggestion is interesting, and would probably be very useful > for a variety of questions , but I have something fairly specific in > mind. > > Imagine that all of the IPv4 entries in the ARIN "delegated" file had > two additional columns. For PA IPv4 allocations, the first new column > for each of the entries would contain an "i" or an "s", to indicate > whether they were an initial or a subsequent allocation. PI > allocations would be marked with an "i" also. In the second column, > each entry would be annotated with the policy-defined minimum size > initial allocation for that particular time period (note: this second > data point is far less important than the first, and could probably be > guessed fairly easily using the other delegated data plus that s/i > flag). > > Once the entries were so annotated, all of the "delegated" entries > would be sorted/counted, ideally by year and by "policy period" (e.g., > the entries corresponding to the /19 min. allocation era would be > grouped together, separately from the entries for the /20 min., et al. > periods). If this proved to be too difficult, annual groupings would > be almost as helpful. > > For each time period or policy era, the counts of interest would be: > > (A) Number, PA initial or PI allocations (of prefix length i) > (B) Number, PA subsequent allocations (of prefix length i or longer). > (C) Number, PA subsequent allocations (of prefix length i minus one). > (D) Number, PA subsequent allocations (shorter than (i minus one)). > > > With these data points, you could make rough statements about the > frequency of occasions when "new entrants" and "incumbents" were > seeking prefixes of roughly the same length. For example, if ARIN > staff had to make these calculations (e.g., to preserve > confidentiality, etc.), they might come back with statements/graphs > that show: > > Obs1: "In years (x,y,z...), for every initial allocation transaction, > there were (B/A) subsequent allocations for prefixes of equal length > or longer. > Obs2: In years (x,y,z...), of the (A+B+C+D) total IPv4 delegations, > (one - (C+D)/(A+B+C+D)) percent involved operators seeking roughly the > same (initial-alloc) size prefix. > Obs3: In years (x,y,z...), of the (A+B+C=D) total IPv4 delegations, > (C) delegations or (C/(A+B+C+D)) percent of the total were subsequent > allocations that could have been satisfied by two initial-alloc sized > prefixes. > > Here's why I think this data would be illuminating. > > If I'm interpreting 2008-02 correctly, many of the limitations in > deaggregation, exact "need" to prefix length matching, etc. are > included in part to foster the emergence of "convex pricing", wherein > each /32 that's part of a shorter prefix is worth more the equivalent > in a longer prefix -- so for example, a single /20 would always > command a higher price than would 2x /21. Over the course of multiple > conversations with 2008-02 supporters over the last couple of weeks, > this "convex pricing" pattern has been repeatedly identified as the > primary mechanism to help "the little guys". If I followed those > conversations correctly, the reasoning is that if such a pattern > emerges, and a supply of long-ish prefixes persists, then those > resources would remain accessible to new entrants and small operators, > and thereby keep the industry open. > > Here's where the data request comes in. If either or both (Obs1, Obs2) > are large numbers, then history would suggest that even if all address > seekers want to follow the 2008-02 process, there could be frequent > contention for prefixes of the same size. If convex pricing does > emerge for other (e.g., policy-driven) reasons, prefixes of the same > size will be priced roughly the same -- at least in the sense that > they'll cost more than 2x (next longest prefix) and less than (0.5* > next shortest prefix). However, if those (Obs1, Obs2) numbers are > large, that suggests that operators are going to be frequently > confronting temptation, e.g., to engage in bidding wars that might > undermine the convex pricing pattern, or alternately to seek address > space outside of the approved process -- e.g., the "gray market" for > prefixes of the same size or longer. Obs3 would also provide some > insight on how much more this pressure might affect "the littlest > guys", i.e., new entrants. > > Granted history proves nothing, and historical lessons are doubly > questionable across periods of radical change, but I think all of > these observations would be useful as indications of how much/often > the approved process (and/or the process administrators) might be > subject to major stresses, and how often commercial operators might > have to resist strong incentives to seek address space in ways that > would undermine the quality of the ARIN registry. If the decentralized > resource transfers are legitimized, and no other compliance-promoting > mechanisms are instituted, then "convex pricing" and the intrinsic > appeal of the 2008-02 process may have to carry most/all of the weight > to keep the industry open and the ARIN central registry viable. Thus I > think the community ought to have as much relevant information and > analysis as possible before they have to make that choice. > > Needless to say, I'd be happy to help with the data crunching... > > Thanks, > > Tom > > > > > > > > > On Mar 19, 2008, at 10:27 AM, > > wrote: > >> Not sure what you are asking for, and then, don't know how > >> long it will take to produce it. > > > > To me, it sounded like this, or perhaps a subset of this. > > > > For every ARIN IPv4 ISP/LIR, record the size of the base allocation > > that > > they first received and the date. Call this B. > > > > Then go through all the B's and figure the average size of B for each > > month. Call this A. > > > > The go through all the ISP/LIR subsequent allocations and record the > > date the size called S and two calculated values PB and PA. PB = S > > as a > > percent of B, and PA = S as a percent of A. > > > > Provide this data as a table in CSV format > > > > ISP #, B, A, Base Date, Subsequent Date, S, PA, PB > > > > That should be sufficiently parseable that people can do some charts > > with it. For instance charting the average of PA and/or PB over time > > would show if subsequent allocations are trending larger compared to > > the > > base allocation or compared to all other allocations made at the time > > the base allocation was made. > > > > Or perhaps Tom could suggest a slightly different algorithm. > > > > --Michael Dillon > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the > > ARIN Public Policy > > Mailing List (PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml > > Please contact the ARIN Member Services Help Desk at info at arin.net > > if you experience any issues. > From jmaimon at chl.com Thu Mar 20 08:23:11 2008 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 20 Mar 2008 08:23:11 -0400 Subject: [ppml] Policy to help the little guys In-Reply-To: <20080319183438.GZ24095@shell01.cell.sv2.tellme.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> <20080319183438.GZ24095@shell01.cell.sv2.tellme.com> Message-ID: <47E2572F.9040109@chl.com> David Williamson wrote: > On Wed, Mar 19, 2008 at 01:03:31PM -0400, William Herrin wrote: > >>The main problem with PI assignments is the systemic cost of >>announcing a BGP prefix ( http://bill.herrin.us/network/bgpcost.html >>). If you look at the things from a different perspective, the problem >>is the lack of mechanisms by which the 27000 active AS's can recover >>the BGP cost directly from the folks announcing a prefix. > > > Can you explain to me how a PI /24 would be in any way different from > an otherwise identical PA /24? In theory, filtering on RIR boundaries should be much safer if multihoming with smaller prefixes was done with PA space. From cliffb at cjbsys.bdb.com Thu Mar 20 08:57:09 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Thu, 20 Mar 2008 08:57:09 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: References: <200803180220.m2I2KDqb003250@cjbsys.bdb.com> Message-ID: <47E25F25.4030703@cjbsys.bdb.com> Jo Rhett wrote: > Cliff, my reading of 2008-2 does exactly that. You're restating > pretty clear the goal of the proposal. > The "market" would and does exist independant of ARIN. The only > question was whether ARIN should provide a listing service. Jo Yes. What I was trying to do was get ARIN out of the listing/pricing business part of 2008-2. In a prior post, I also suggested removing some of the transfer time restrictions and prior approval requirements. The intent is to allow a more timely response to what will quite likely be a more active time in v4 address usage/change as people (hopefully) will be working to change to v6. I think ARIN needs to allow for private transfers during this time frame but should only be involved in certifying the transfer, not the details of how the two (or more) parties got together Cliff > From dlw+arin at tellme.com Thu Mar 20 12:08:34 2008 From: dlw+arin at tellme.com (David Williamson) Date: Thu, 20 Mar 2008 09:08:34 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <000101c88a1e$a22784d0$bb2b359b@ad.redback.com> References: <20080318204427.1FACD45019@ptavv.es.net> <20080319183438.GZ24095@shell01.cell.sv2.tellme.com> <000101c88a1e$a22784d0$bb2b359b@ad.redback.com> Message-ID: <20080320160834.GF24095@shell01.cell.sv2.tellme.com> On Wed, Mar 19, 2008 at 05:08:52PM -0700, Tony Li wrote: > PI is the portion of the DFZ costs that we can and should fix at an > architectural level. I agree with this. I might generalize it to say that the costs associated with non-transit leaf nodes should be fixed by a new architecture. That covers PI and end site PA, since they seem to be fundamentally identical. For those on this list who haven't yet taken a look at what the RRG mailing list is doing, I strongly urge you to do so. This is extrememly important work, and the current best chance for solving some of the scaling issues. (Thanks, Tony!) -David From dlw+arin at tellme.com Thu Mar 20 12:11:21 2008 From: dlw+arin at tellme.com (David Williamson) Date: Thu, 20 Mar 2008 09:11:21 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <47E2572F.9040109@chl.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> <20080319183438.GZ24095@shell01.cell.sv2.tellme.com> <47E2572F.9040109@chl.com> Message-ID: <20080320161121.GG24095@shell01.cell.sv2.tellme.com> On Thu, Mar 20, 2008 at 08:23:11AM -0400, Joe Maimon wrote: > > > David Williamson wrote: > >On Wed, Mar 19, 2008 at 01:03:31PM -0400, William Herrin wrote: > > > >>The main problem with PI assignments is the systemic cost of > >>announcing a BGP prefix ( http://bill.herrin.us/network/bgpcost.html > >>). If you look at the things from a different perspective, the problem > >>is the lack of mechanisms by which the 27000 active AS's can recover > >>the BGP cost directly from the folks announcing a prefix. > > > > > >Can you explain to me how a PI /24 would be in any way different from > >an otherwise identical PA /24? > > In theory, filtering on RIR boundaries should be much safer if > multihoming with smaller prefixes was done with PA space. So, you simply repeated the assertion I was questioning, but with the words "in theory" in front of it. Please explain this theory, as I'm not familiar with it. (Or provide a reference, please.) If you can show that there is a real and useful difference between PA and PI, well, that would be news to several folks on this list, including me. That might change the nature of some of the discussions. I look forward to an explanation of this theory. Thanks! -David From jmaimon at chl.com Thu Mar 20 12:35:39 2008 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 20 Mar 2008 12:35:39 -0400 Subject: [ppml] Policy to help the little guys In-Reply-To: <20080320161121.GG24095@shell01.cell.sv2.tellme.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> <20080319183438.GZ24095@shell01.cell.sv2.tellme.com> <47E2572F.9040109@chl.com> <20080320161121.GG24095@shell01.cell.sv2.tellme.com> Message-ID: <47E2925B.70004@chl.com> David Williamson wrote: >>>Can you explain to me how a PI /24 would be in any way different from >>>an otherwise identical PA /24? >>> >>> >>In theory, filtering on RIR boundaries should be much safer if >>multihoming with smaller prefixes was done with PA space. >> >> > >So, you simply repeated the assertion I was questioning, but with the >words "in theory" in front of it. Please explain this theory, as I'm >not familiar with it. > The difference would be in the likelyhood that the PA /24 is reachable through the PA aggregate prefix even if it filtered. Hence, safer to filter. This can probably be analyzed and I think actually was fairly recently. From jmaimon at chl.com Thu Mar 20 13:32:15 2008 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 20 Mar 2008 13:32:15 -0400 Subject: [ppml] Policy to help the little guys In-Reply-To: <3c3e3fca0803201014s52c3d6abj434013884e12ed13@mail.gmail.com> References: <20080318204427.1FACD45019@ptavv.es.net> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> <20080319183438.GZ24095@shell01.cell.sv2.tellme.com> <47E2572F.9040109@chl.com> <20080320161121.GG24095@shell01.cell.sv2.tellme.com> <47E2925B.70004@chl.com> <3c3e3fca0803201014s52c3d6abj434013884e12ed13@mail.gmail.com> Message-ID: <47E29F9F.3050109@chl.com> William Herrin wrote: >On Thu, Mar 20, 2008 at 12:35 PM, Joe Maimon wrote: > > >> >>>Can you explain to me how a PI /24 would be in any way different from >> >>>an otherwise identical PA /24? >> >>In theory, filtering on RIR boundaries should be much safer if >> >>multihoming with smaller prefixes was done with PA space. >> >> The difference would be in the likelyhood that the PA /24 is reachable >> through the PA aggregate prefix even if it filtered. Hence, safer to filter. >> >> > >Joe, > >Would not such filtering would defeat the purpose of multihoming in >the first place? > >Regards, >Bill Herrin > > For the filtered, yes. But not for the filterer. That means a few things. - PA /24 is encouraged to maintain connectivity with the P from the PA - PI /24 is more desirable to the site that wants true multihoming - PA /24 is more desirable for the sites that want to filter all those pesky multihomers - Filtering PA /24 is more legitimate than PI /24, so that changes the "its broken, fix it" dynamic > > > From jlewis at lewis.org Thu Mar 20 15:24:11 2008 From: jlewis at lewis.org (Jon Lewis) Date: Thu, 20 Mar 2008 15:24:11 -0400 (EDT) Subject: [ppml] Policy to help the little guys In-Reply-To: <75C1242A-FA1F-4752-B663-8E17AF7F8C9A@svcolo.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> <9AAEA4D2-C4B3-414E-BC5A-E9441EADCFFD@tcb.net> <3c3e3fca0803191317nd031da3id84670f2c3de85a6@mail.gmail.com> <6CDAFA66-EBAA-49BC-84D6-176405CAE1D9@tcb.net> <3c3e3fca0803191527n40a6bb40i19d9041ec68bb451@mail.gmail.com> <75C1242A-FA1F-4752-B663-8E17AF7F8C9A@svcolo.com> Message-ID: On Wed, 19 Mar 2008, Jo Rhett wrote: > On Mar 19, 2008, at 3:27 PM, William Herrin wrote: >> >> 1. ARIN takes a /16 and lets it be known that only /25 or longer PI >> prefixes will be assigned from this /16 (nothing /24 or shorter). >> ..... >> 5. Each year, ARIN solicits bids for an ISP to serve as a "catchall" >> tunnel broker for the whole /16. The tunnel broker announces the whole >> /16 and (if you pay him) then tunnels any traffic to you via GRE in > > FYI I see nothing about this proposal that requires ARIN. It could > be implemented by any current or future holder of /16 or whatever > size space. It sounds like an ingenious marketing opportunity that > if implemented in advance could become really valuable when IPv4 > exhaustion occurs. Why don't you do this? AFAIK, there have been companies doing this sort of business model for years. I suspect the typical customer is a "power user" who can't get static IP on their home connection for reasonable $ or at all. I'm not sure I can see businesses relying on such a service...due to the added latency and the fact that you're then relying on all your traffic crossing "the internet" multiple times to get to you. Unlike directly connecting to a provider, you have little control over reachability or QoS between your network and your IP space provider. Maybe as IPv4 becomes scarce, some legacy /16 holders will step forward and offer this...and because they just can't reasonably get IPs otherwise, businesses will have little choice but to accept such a model if they want more v4 IPs. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From kkargel at polartel.com Thu Mar 20 17:24:16 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 20 Mar 2008 16:24:16 -0500 Subject: [ppml] Policy to help the little guys In-Reply-To: References: <20080318204427.1FACD45019@ptavv.es.net> <47E05525.9020709@psg.com><20080319025901.GB17899@vacation.karoshi.com.><47E08662.1040701@psg.com> <47E0A524.8090506@internap.com><20080319063840.GR24095@shell01.cell.sv2.tellme.com><3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com><9AAEA4D2-C4B3-414E-BC5A-E9441EADCFFD@tcb.net><3c3e3fca0803191317nd031da3id84670f2c3de85a6@mail.gmail.com><6CDAFA66-EBAA-49BC-84D6-176405CAE1D9@tcb.net><3c3e3fca0803191527n40a6bb40i19d9041ec68bb451@mail.gmail.com><75C1242A-FA1F-4752-B663-8E17AF7F8C9A@svcolo.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410660104F4AD@mail> > >> 5. Each year, ARIN solicits bids for an ISP to serve as a > "catchall" > >> tunnel broker for the whole /16. The tunnel broker announces the > >> whole > >> /16 and (if you pay him) then tunnels any traffic to you via GRE in > > So what we are talking about is really just an IP proxy service. There are a number of "anonymizer" services out there that do pretty much exactly this for different reasons From jrhett at svcolo.com Thu Mar 20 18:16:44 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Thu, 20 Mar 2008 15:16:44 -0700 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <22272.1205985518@sa.vix.com> References: <200803180220.m2I2KDqb003250@cjbsys.bdb.com> <47E1E021.1080900@psg.com> <22272.1205985518@sa.vix.com> Message-ID: <96C7FD47-3DA8-464C-BF74-13286C285EE7@svcolo.com> On Mar 19, 2008, at 8:58 PM, Paul Vixie wrote: >>>> The "market" would and does exist independant of ARIN. ... >> >>> can you give us a ferinstance? >> >> and then have net.vigilantes descend on them? > > it's hard to make policy in the current information vacuum. > >> you're kidding, right? > > i wasn't. i'm not doubting jo's word. i'm trying to understand the > magnitude of the described market. i'd like to know whether it's the > kind of thing that will move into an ARIN framework if any, or whether > it'll die if ARIN adopts a framework. i'd like to know if it's dozens > of "trades" per hour, per day, per year, or what. okay, sorry, let me clarify. I have personally had people try to sell me swamp space before on several occasions. I took that to mean that probably many other people out there were doing it, which may or may not be true. I don't know how large or diverse the market is. I *assume* it would grow after exhaustion. The only reason I said "The market would and does exist independant of ARIN" was an attempt to correct a statement by someone that ARIN would be creating a market. It is my belief that this market would exist without any assistance from ARIN, and probably even if ARIN tried to squash it. 2008-2 wouldn't "create" a market in my mind. Enable, Validate, lots of other words might apply. I don't think "create" applies. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From jrhett at svcolo.com Thu Mar 20 18:18:52 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Thu, 20 Mar 2008 15:18:52 -0700 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <47E25F25.4030703@cjbsys.bdb.com> References: <200803180220.m2I2KDqb003250@cjbsys.bdb.com> <47E25F25.4030703@cjbsys.bdb.com> Message-ID: <51E4D57A-4AE8-4618-949F-FEB51EDCE535@svcolo.com> On Mar 20, 2008, at 5:57 AM, Cliff Bedore wrote: > What I was trying to do was get ARIN out of the listing/pricing > business > part of 2008-2. I have no problem with that. > In a prior post, I also suggested removing some of the > transfer time restrictions and prior approval requirements. The > intent ... > working to change to v6. I think ARIN needs to allow for private > transfers during this time frame but should only be involved in > certifying the transfer, not the details of how the two (or more) > parties got together This is where you and I disagree. 2008-2 if I read it correctly requires the receiver to be able to justify the space required according to ARIN's guidelines. In short, they could get space if ARIN had any to give them. I don't agree at all with your idea of removing those restrictions. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From jrhett at svcolo.com Thu Mar 20 18:20:20 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Thu, 20 Mar 2008 15:20:20 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <47E1C49A.8030009@psg.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> <9AAEA4D2-C4B3-414E-BC5A-E9441EADCFFD@tcb.net> <3c3e3fca0803191317nd031da3id84670f2c3de85a6@mail.gmail.com> <6CDAFA66-EBAA-49BC-84D6-176405CAE1D9@tcb.net> <3c3e3fca0803191527n40a6bb40i19d9041ec68bb451@mail.gmail.com> <75C1242A-FA1F-4752-B663-8E17AF7F8C9A@svcolo.com> <3c3e3fca0803191812n1e904f92gc3bcb6f2af751f94@mail.gmail.com> <47E1C49A.8030009@psg.com> Message-ID: <2BF3E9FF-DCEB-4A3B-8F90-D1145BF8EFEF@svcolo.com> On Mar 19, 2008, at 6:57 PM, Randy Bush wrote: >> The problem is *very* well known, and there ain't much we can do >> about it other than try to contain it until we can afford to upgrade >> all of our hardware to accept that many routes. > > how many additional routes does pi multihoming cause over pa? how > many > additional routes does /29 multihoming cause over /24? Well if I thought you were serious, I would ask for more details as not *every* route would be one of those. But I suspect you're trying to make another point, so why don't you spell it out? -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From jrhett at svcolo.com Thu Mar 20 18:22:33 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Thu, 20 Mar 2008 15:22:33 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <3c3e3fca0803192023r3a372b28x27bdd2e50f0ff441@mail.gmail.com> References: <20080318204427.1FACD45019@ptavv.es.net> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> <9AAEA4D2-C4B3-414E-BC5A-E9441EADCFFD@tcb.net> <3c3e3fca0803191317nd031da3id84670f2c3de85a6@mail.gmail.com> <6CDAFA66-EBAA-49BC-84D6-176405CAE1D9@tcb.net> <3c3e3fca0803191527n40a6bb40i19d9041ec68bb451@mail.gmail.com> <75C1242A-FA1F-4752-B663-8E17AF7F8C9A@svcolo.com> <3c3e3fca0803191812n1e904f92gc3bcb6f2af751f94@mail.gmail.com> <3c3e3fca0803192023r3a372b28x27bdd2e50f0ff441@mail.gmail.com> Message-ID: <020C2F43-5907-4294-BCBD-B6A133D35328@svcolo.com> On Mar 19, 2008, at 8:23 PM, William Herrin wrote: > On Wed, Mar 19, 2008 at 9:48 PM, Jo Rhett wrote: >> And while I cede you the "creative thought" thing, it just >> returns to >> "imagination masturbation" in my mind. > > That's nice. Do you think you could go three, maybe even four posts > without tossing in a gratuitous insult? No insult intended. I actually use that phrase to refer to a working mode that I participate in quite often. I'm sorry you took offense. (not unsaying anything I said in previous conversation -- just saying that this comment was not intended as an insult or derogatory in any way) -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From randy at psg.com Thu Mar 20 18:24:48 2008 From: randy at psg.com (Randy Bush) Date: Fri, 21 Mar 2008 07:24:48 +0900 Subject: [ppml] Policy to help the little guys In-Reply-To: <2BF3E9FF-DCEB-4A3B-8F90-D1145BF8EFEF@svcolo.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> <9AAEA4D2-C4B3-414E-BC5A-E9441EADCFFD@tcb.net> <3c3e3fca0803191317nd031da3id84670f2c3de85a6@mail.gmail.com> <6CDAFA66-EBAA-49BC-84D6-176405CAE1D9@tcb.net> <3c3e3fca0803191527n40a6bb40i19d9041ec68bb451@mail.gmail.com> <75C1242A-FA1F-4752-B663-8E17AF7F8C9A@svcolo.com> <3c3e3fca0803191812n1e904f92gc3bcb6f2af751f94@mail.gmail.com> <47E1C49A.8030009@psg.com> <2BF3E9FF-DCEB-4A3B-8F90-D1145BF8EFEF@svcolo.com> Message-ID: <47E2E430.207@psg.com> >>> The problem is *very* well known, and there ain't much we can do >>> about it other than try to contain it until we can afford to upgrade >>> all of our hardware to accept that many routes. >> how many additional routes does pi multihoming cause over pa? how many >> additional routes does /29 multihoming cause over /24? > Well if I thought you were serious, I would ask for more details as not > *every* route would be one of those. But I suspect you're trying to make > another point, so why don't you spell it out? the answers are "negligible with the way folk do things currently[0]," and "none." randy --- [0] - and good luck getting them to change From jrhett at svcolo.com Thu Mar 20 18:28:17 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Thu, 20 Mar 2008 15:28:17 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <006901c88a5a$faad99f0$6fce4b41@tedsdesk> References: <006901c88a5a$faad99f0$6fce4b41@tedsdesk> Message-ID: On Mar 20, 2008, at 12:21 AM, Ted Mittelstaedt wrote: > So, is this policy discussion actually solving a real problem, or are > we all doing someone's theoretical CCIE homework question for them? Not all big (or small) iron vendors do well with not using memory for refused routes. One of those is the largest deployed vendor with no caps in their name. So your small guy may have a filter to drop anything longer than a / 24, but it's still eating up memory in his unit. Unless the upstream is willing to filter it for him, *boom* goes his router one day. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From jrhett at svcolo.com Thu Mar 20 18:37:52 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Thu, 20 Mar 2008 15:37:52 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <47E2E430.207@psg.com> References: <20080318204427.1FACD45019@ptavv.es.net> <47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <20080319063840.GR24095@shell01.cell.sv2.tellme.com> <3c3e3fca0803191003k3de2914h105d8188747e2952@mail.gmail.com> <9AAEA4D2-C4B3-414E-BC5A-E9441EADCFFD@tcb.net> <3c3e3fca0803191317nd031da3id84670f2c3de85a6@mail.gmail.com> <6CDAFA66-EBAA-49BC-84D6-176405CAE1D9@tcb.net> <3c3e3fca0803191527n40a6bb40i19d9041ec68bb451@mail.gmail.com> <75C1242A-FA1F-4752-B663-8E17AF7F8C9A@svcolo.com> <3c3e3fca0803191812n1e904f92gc3bcb6f2af751f94@mail.gmail.com> <47E1C49A.8030009@psg.com> <2BF3E9FF-DCEB-4A3B-8F90-D1145BF8EFEF@svcolo.com> <47E2E430.207@psg.com> Message-ID: On Mar 20, 2008, at 3:24 PM, Randy Bush wrote: >>>> The problem is *very* well known, and there ain't much we can do >>>> about it other than try to contain it until we can afford to >>>> upgrade >>>> all of our hardware to accept that many routes. >>> how many additional routes does pi multihoming cause over pa? >>> how many >>> additional routes does /29 multihoming cause over /24? >> Well if I thought you were serious, I would ask for more details >> as not >> *every* route would be one of those. But I suspect you're trying >> to make >> another point, so why don't you spell it out? > > the answers are "negligible with the way folk do things currently[0]," > and "none." Hm, that's funny. I was thinking the reverse -- 'none' for the first, and... /29 could cause routing table growth if it wasn't filtered near the edges/ignored by the core, etc. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From sleibrand at internap.com Thu Mar 20 18:58:53 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 20 Mar 2008 15:58:53 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: <17838240D9A5544AAA5FF95F8D520316037A79CC@ad-exh01.adhost.lan> References: <20080318204427.1FACD45019@ptavv.es.net><47E05525.9020709@psg.com> <20080319025901.GB17899@vacation.karoshi.com.><47E08662.1040701@psg.com> <47E0A524.8090506@internap.com> <17838240D9A5544AAA5FF95F8D520316037A7952@ad-exh01.adhost.lan> <47E15F2D.1030401@internap.com> <17838240D9A5544AAA5FF95F8D520316037A79CC@ad-exh01.adhost.lan> Message-ID: <47E2EC2D.3070301@internap.com> Michael K. Smith - Adhost wrote: >>> How about a reservation of some block of space for allocations of >>> /20's to Members that only meet those requirements? > > Reserve a block (/8, /16, whatever) for allocation in /20 or more > specific increments to Members who meet the requirements for receiving a > /20. Basically, just reserve some space for smaller providers so that > they can get their /20 even if the larger blocks have been exhausted. > But, you wouldn't assign a /19 from that block, nor would you assign > multiple /20's to someone who normally gets a /16. That is, you have to > be "Small to Medium" to get an allocation from that block. A very interesting idea, and one that I think would be worth putting together as a policy proposal to submit and discuss after Denver. This is part of a larger set of discussions that we'll likely be having as free pool exhaustion nears, centered around the question: What policy changes, if any, should go into effect upon IANA free pool exhaustion to conserve the remaining IPv4 addresses for certain uses? -Scott From peter at boku.net Thu Mar 20 19:15:18 2008 From: peter at boku.net (Peter Eisch) Date: Thu, 20 Mar 2008 18:15:18 -0500 Subject: [ppml] Policy to help the little guys In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A0631410660104F4AD@mail> Message-ID: On 3/20/08 4:24 PM, "Kevin Kargel" wrote: >>>> 5. Each year, ARIN solicits bids for an ISP to serve as a >> "catchall" >>>> tunnel broker for the whole /16. The tunnel broker announces the >>>> whole >>>> /16 and (if you pay him) then tunnels any traffic to you via GRE in >>> > So what we are talking about is really just an IP proxy service. There > are a number of "anonymizer" services out there that do pretty much > exactly this for different reasons To the contrary, I believe he's describing the exact opposite of an anonymizer in function. The problem with #5 is that the little guy now has to pay two ISPs for hauling the traffic and still use a PA address to terminate the tunnel. Back to the topic though, I have to say that I'm aware of more than a handful of organizations that desired ISP autonomy. Along the path it's fair to say that when their desires for independence were blocked by current process of need justification, they manufactured the need for address space in order to achieve their independence. It's out there, it happens. If they had the option to get a PI /28 they never would have manufactured the need for a /23. They got their routing slot. It just took them a little longer to get there. Their intent wasn't to squander address space. It was a casualty on the road to achieve their ISP autonomy. The longer you, the ARIN membership, choose to believe that these "little guys" are too stupid to play the game of utilization, the longer it will take to get back PI. While you wait, the routing slots will continue to increase regardless. Back to a post I made last July (I think) regarding routing slot growth: there's no shame in not being able to carry fully routes. There's no shame in being an aggregator. Sure, it's harder to craft as-path filters so you can best optimize your hardware's capacity. It's not the end of the world to add a default to a connected peer to handle routes that you can't afford to keep. peter From cliffb at cjbsys.bdb.com Thu Mar 20 19:57:07 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Thu, 20 Mar 2008 19:57:07 -0400 Subject: [ppml] Markets, pricing, transparency, 2008-2 / 8.3.9 In-Reply-To: <51E4D57A-4AE8-4618-949F-FEB51EDCE535@svcolo.com> References: <200803180220.m2I2KDqb003250@cjbsys.bdb.com> <47E25F25.4030703@cjbsys.bdb.com> <51E4D57A-4AE8-4618-949F-FEB51EDCE535@svcolo.com> Message-ID: <47E2F9D3.30209@cjbsys.bdb.com> Jo Rhett wrote: > On Mar 20, 2008, at 5:57 AM, Cliff Bedore wrote: >> What I was trying to do was get ARIN out of the listing/pricing business >> part of 2008-2. > > I have no problem with that. > >> In a prior post, I also suggested removing some of the >> transfer time restrictions and prior approval requirements. The intent > ... >> working to change to v6. I think ARIN needs to allow for private >> transfers during this time frame but should only be involved in >> certifying the transfer, not the details of how the two (or more) >> parties got together > > This is where you and I disagree. 2008-2 if I read it correctly > requires the receiver to be able to justify the space required > according to ARIN's guidelines. In short, they could get space if > ARIN had any to give them. Jo I had left out some of the details from some of my prior posts. On 3/17, I wrote "At the risk of repeating myself, I think 8.3.9 should be deleted in its entirety. All ARIN needs to do in the process is allow 3rd parties to transfer IP addresses directly from one party to another without being returned to ARIN first. The numbers must be properly registered to the transferor and the transferee must justify the need. Other than that, ARIN should have nothing to do with the dealings of the two parties. They can trade money, resort properties or pork futures and it's nobody's business what the transaction is." Since people must justify the need in both cases, I assumed they would check with ARIN first before searching the "marketplace" since this in theory should save them money. ARIN might publish a list of what they have so people know when to search outside ARIN. > > I don't agree at all with your idea of removing those restrictions. If you are talking about the transferee having to justify to ARIN, per the above, I agree with that and just didn't state it clearly in that last post. (And if not please let me know which ones you are referring to.) Cliff From stephen at sprunk.org Thu Mar 20 19:04:00 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 20 Mar 2008 18:04:00 -0500 Subject: [ppml] Policy to help the little guys References: <006901c88a5a$faad99f0$6fce4b41@tedsdesk> Message-ID: <01ac01c88ae2$e2fad330$5a3816ac@atlanta.polycom.com> Thus spake "Jo Rhett" > On Mar 20, 2008, at 12:21 AM, Ted Mittelstaedt wrote: >> So, is this policy discussion actually solving a real problem, or are >> we all doing someone's theoretical CCIE homework question for them? > > Not all big (or small) iron vendors do well with not using memory for > refused routes. One of those is the largest deployed vendor with no > caps in their name. > > So your small guy may have a filter to drop anything longer than a / > 24, but it's still eating up memory in his unit. Unless the upstream > is willing to filter it for him, *boom* goes his router one day. There's several different types of memory. The route will eat up BGP RIB memory, but it won't eat up FIB or main RIB memory. Being short on FIB memory is generally the biggest problem, since fixing that generally requires totally new linecards or even routers; today, there's generally enough BGP RIB and main RIB memory, and if not it only takes replacing one or two cards per router -- not that one wants that expense either, but it's a lot lower than replacing everything. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From tedm at ipinc.net Fri Mar 21 01:18:59 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 20 Mar 2008 22:18:59 -0700 Subject: [ppml] Policy to help the little guys In-Reply-To: Message-ID: <001f01c88b13$11b7b230$6fce4b41@tedsdesk> > -----Original Message----- > From: Jo Rhett [mailto:jrhett at svcolo.com] > Sent: Thursday, March 20, 2008 3:28 PM > To: Ted Mittelstaedt > Cc: 'David Williamson'; 'Randy Bush'; 'arin ppml' > Subject: Re: [ppml] Policy to help the little guys > > > On Mar 20, 2008, at 12:21 AM, Ted Mittelstaedt wrote: > > So, is this policy discussion actually solving a real > problem, or are > > we all doing someone's theoretical CCIE homework question for them? > > Not all big (or small) iron vendors do well with not using > memory for > refused routes. One of those is the largest deployed vendor with no > caps in their name. > > So your small guy may have a filter to drop anything longer than a / > 24, but it's still eating up memory in his unit. Unless the > upstream > is willing to filter it for him, Why exactly would a skilled "small guy ISP" who is running, for the sake of example, a Cisco 7206 non-VXR with an NPE 100 running IOS version 11.1 (I'm just thinking of something really nasty and restrictive) and multihoming with it, be willing to purchase bandwidth from upstream feeds too lazy to bother putting route filters into their circuits to him? The last time we bought bandwidth I had to argue with the salesguy to get them to understand we wanted a full unrestricted table sent to us. By default, they filtered their outgoing table at the /24 boundary, and that was just the beginning, they sent a worksheet listing all of the default filters they put in additionally to this. Yes I guess there's networks out there who are still in the Dark Ages. I would submit that when the fertilizer impacts the rotating air-moving device that they and their customers will get a very rapid education in the Correct Way to do things. And if they and their customers are too incompetent to understand what is going on, they will go bankrupt and the rest of us will be well rid of them. So, my question still stands - are we discussing theory or practice? Ted From info at arin.net Fri Mar 21 14:46:13 2008 From: info at arin.net (Member Services) Date: Fri, 21 Mar 2008 14:46:13 -0400 Subject: [ppml] Policy Proposal 2008-2 - Staff Assessment Message-ID: <47E40275.3000601@arin.net> Policy Proposal 2008-2 Title: IPv4 Transfer Policy (authors ARIN AC) Revision Submitted: Mar 7, 2008 Date of Assessment: March 21, 2008 ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2008_2.html II. Understanding of the proposal: ARIN staff understands that this proposal introduces a new set of criteria to justify transfers of the available IANA IPv4 unicast address pool following the depletion of this space. Specifically, the existing Transfer Policy sections are consolidated from three sections to two (8.1 and 8.2) and a new section 8.3 is added that defines criteria for ?Simple Transfers?, which allow an organization with excess IPv4 addresses to transfer those addresses to an organization with a need for additional IPv4 addresses, and creates a listing service to bring the two parties together. III. Issues and Concerns A. ARIN Staff Comments: 8.0 Transfers General Observations ? Policy language and stated criteria are generally broad and subjective (most criteria contain words like ?may? and ?should? vs concrete words like ?will? and ?must?). This leads requestors to believe that they are not obligated to provide documentation and justification for their transfer. The author should consider using a reference such as RFC 2119 to define how these words are generally interpreted. 8.1 Transfers ? This policy does not cover those Internet Number Resources that are neither covered the ARIN Registration Services Agreement or the ARIN Legacy Registration Services Agreement. ? The stated purpose for the original allocation may be difficult for an organization to provide given the requester may not be the original holder of the number resources. ? It is unclear from the text whether all resources being transferred have to be re-justified according to current ARIN policy. 8.2 Transfers as an Artifact of Change in Resource Holder Ownership It is difficult if not impossible for a new requestor to provide ?evidence that the new entity has acquired the assets which had, as of the date of the acquisition or proposed reorganization, justified the current entity's use of the number resource." Again, the requestor may not be the original holder of the number resources. 8.2.1 Documentation Requirements ? It maybe difficult for some requestors to obtain the legal instrument that effected the transfer ? Legal documents may be unavailable, particularly when the transactions occurred years before ? Transactions between small private entities are often difficult to authenticate or verify due to lack of support documentation. Some are based on an anecdotal ?gentleman?s agreement. ? Legal documents are often difficult to authenticate because parties to maybe unreachable. 8.3. Simple Transfer of IPv4 Addresses ? 8.3.2 "business failure" is a nebulous term and could represent an avenue of abuse. Staff recommends removal of this term from the policy text. ? 8.3.6 puts a great deal of responsibility into ARIN staff hands to control the supply in the listing service. This will require a significant amount of work to develop procedures, communication practices, and staff training. This will take approximately 3 to 6 months for this to occur. ? 8.3.7 provides for an audit exemption. Under the current RSA, ARIN has the right to audit a block at any given time. B. ARIN General Counsel This policy is a major departure from existing ARIN policy which has generally prohibited transfers except in specific, limited circumstances. We therefore address the overall intent of the policy from a legal perspective. No matter what policy ARIN implements, it seems likely that there will be more disputes, and hence more legal risk, once ARIN can no longer satisfy requests for v4 resources. But if ARIN attempted to continue its existing policy to prohibit most transfers, counsel anticipates that widespread transfers would nonetheless occur -- imposing significant future legal costs including the costs of investigation, arbitration, and litigation. By providing a realistic mechanism for transfers to occur, a broader and more permissive transfer policy would likely relieve ARIN of many such costs. We therefore consider risks under the proposed policy compared to the risks of retaining the current policy. We now turn to more specific concerns. The first legal concern in evaluating the specifics of any transfer policy is whether it is consistent with antitrust law. Currently, this policy does not create concerns. By creating a white market for transfer of v4 resources, the policy arguably advances competition. Second, a serious risk implicit in the creation of a transfer policy is that it will lead to additional litigation if ARIN, for example, refuses to permit a transfer it finds inconsistent with any policy eventually adopted. However, we believe this risk is adequately managed in the current draft, particularly because concern over this issue must be seen the context of the likelihood of expensive litigation to enforce the current policy if a new transfer policy is not adopted in some form. Third, the new policy will have to be carefully reviewed to ensure it supports to the legal theory of the Internet community that numbers are not "owned." In particular, ARIN will continue to claim that it does not grant "ownership," and that what is being transferred is the right to make beneficial use of number resources consistent with applicable policy. Poorly drafted transfer policies could undercut this current clear understanding. However, we currently have no serious concerns about the language of this proposal. IV. Resource Impact ? Moderate The resource impact of implementing this policy is moderate. Barring any unforeseen resource requirements, this policy could be implemented within 180 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: ? Updates to guidelines will be required ? Staff training will be required ? A new template will be required ? Software will be needed ? New hardware may be required ? Details of the systems to implement the request, pre-qualification certification, transfer and listing service would need to be identified. This would require additional information about the form of the document to certify the pre-qualification and the mechanism and access restrictions for the listing service. Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) #### Annex A Policy Proposal 2008-2 IPv4 Transfer Policy Proposal Author: ARIN Advisory Council Proposal Version: 1.1 Date: 7 March 2008 Proposal type: modify Policy term: permanent Policy statement: Replace the current NRPM section 8 with the following -- 8. Transfers [8.1. Transfers ? retain as is: Number resources are non-transferable and are not assignable to any other organization unless ARIN has expressly and in writing approved a request for transfer. ARIN is tasked with making prudent decisions on whether to approve the transfer of number resources. It should be understood that number resources are not "sold" under ARIN administration. Rather, number resources are assigned to an organization for its exclusive use for the purpose stated in the request, provided the terms of the Registration Services Agreement continue to be met and the stated purpose for the number resources remains the same. Number resources are administered and assigned according to ARIN's published policies. Number resources are issued, based on justified need, to organizations, not to individuals representing those organizations. Thus, if a company goes out of business, regardless of the reason, the point of contact (POC) listed for the number resource does not have the authority to sell, transfer, assign, or give the number resource to any other person or organization. The POC must notify ARIN if a business fails so the assigned number resources can be returned to the available pool of number resources if a transfer is not requested and justified.] [8.2 ? remove the word ?only?, and retitle to ?Transfers as an Artifact of Change in Resource Holder Ownership?: 8.2. Transfers as an Artifact of Change in Resource Holder Ownership ARIN will consider requests for the transfer of number resources upon receipt of evidence that the new entity has acquired the assets which had, as of the date of the acquisition or proposed reorganization, justified the current entity's use of the number resource. Examples of assets that justify use of the number resource include, but are not limited to: ? Existing customer base ? Qualified hardware inventory ? Specific software requirements.] [Renumber existing 8.3 to 8.2.1 and retitle to ?Documentation Requirements for Transfers as an Artifact of Change in Resource Holder Ownership?: 8.2.1. Documentation Requirements for Transfers as an Artifact of Change in Resource Holder Ownership In evaluating a request for transfer, ARIN may require the requesting organization to provide any of the following documents, as applicable, plus any other documents deemed appropriate: ? An authenticated copy of the instrument(s) effecting the transfer of assets, e.g., bill of sale, certificate of merger, contract, deed, or court decree ? A detailed inventory of all assets utilized by the requesting party in maintaining and using the number resource ? A list of the requesting party's customers using the number resource. If further justification is required, the requesting party may be asked to provide any of the following, or other supporting documentation, as applicable: ? A general listing of the assets or components acquired ? A specific description of acquisitions, including: o Type and quantity of equipment o Customer base ? A description of how number resources are being utilized ? Network engineering plans, including: o Host counts o Subnet masking o Network diagrams o Reassignments to customers] 8.3. Simple Transfer of IPv4 Addresses After the exhaustion of the IANA IPv4 free pool (when IANA allocates its last unallocated unicast IPv4 address block), ARIN will also process IPv4 address transfer requests subject to the following conditions. These conditions apply only to Simple IPv4 transfers, not to transfers performed according to section 8.2. 8.3.1 Conditions on the transferor (the organization providing addresses for transfer): ? The transferor resides in the ARIN service area. ? The transferor has signed an RSA and/or a legacy RSA covering the IPv4 addresses transferred. ? The transferor has no outstanding balances with ARIN. ? The transferor has not received any IPv4 allocations or assignments from ARIN (through ordinary allocations or assignments, or through this Simple Transfer policy) within the preceding 24 months. ? The transferor may not request any IPv4 allocations or assignments from ARIN (through ordinary allocations or assignments, or through this Simple Transfer policy) within the subsequent 24 months. 8.3.2 Conditions on the transferee (the organization receiving the transferred addresses): ? The transferee resides in the ARIN service area and intends to use the transferred IPv4 addresses within the ARIN service area. ? The transferee has no outstanding balances with ARIN. ? The transferee?s need is confirmed by ARIN, according to current ARIN policies, including but not limited to confirmation of utilization rate of any prior IPv4 allocations, assignments, or previously transferred IPv4 addresses held by the transferee. ? The transferee signs (or has previously signed) an RSA covering the IPv4 addresses transferred. ? The transferee has not provided any IPv4 addresses for transfer through this Simple Transfer process within the preceding 24 months. ? The transferee may not provide any IPv4 addresses for transfer through this Simple Transfer process within the subsequent 24 months, except in the case of business failure. ? The transferee may request and receive a contiguous CIDR block large enough to provide a 12 month supply of IPv4 addresses. ? The transferee may only receive one IPv4 address transfer through this Simple Transfer process every 6 months. 8.3.3 Conditions on the IPv4 address block to be transferred: ? The IPv4 block must comply with applicable ARIN requirements, including minimum allocation size (i.e. NRPM 4.2.2., 4.2.4., 4.3.2., 4.3.6.). However, an IPv4 allocation or assignment of /24 or larger, but smaller than the current minimum allocation size, may be transferred as a whole resource, but may not be subdivided. ? The IPv4 block must currently be registered for use within the ARIN service area, either as part of an address block assigned by IANA to ARIN, or as part of a legacy address block allocated within the ARIN service area. ? There must exist no dispute as to the status of the IPv4 block or regarding the allocation or assignment of such block to the transferor. ? The transferor may retain one contiguous address range out of their original allocation or assignment for their own use, and transfer the other contiguous address range. If the address range to be transferred consists of multiple non-aggregatable CIDR blocks, each may be transferred to a different transferee. The retained address range may not be further subdivided or transferred for a period of 12 months. Notwithstanding the preceding, the block may be subdivided as provided in section 8.3.6. 8.3.4 Fees ? Completion of a transfer requires payment of a transfer fee according to ARIN?s schedule of fees. ? The transferee will be subject to all future ARIN membership and service fees according to the transferee?s total address holdings. 8.3.5 Pre-qualification ? An interested transferee must seek pre-qualification from ARIN to confirm its eligibility to receive a transfer (including satisfaction of need according to current ARIN policies) before making any solicitation for transfer. Upon pre-qualification, ARIN will provide the transferee with documentation of the pre-qualification, including the size (CIDR prefix length) of the largest IPv4 address block the transferee is eligible to receive, and the expiration date of the pre-qualification. ? An interested transferor must seek pre-qualification from ARIN to confirm its eligibility to offer a transfer (including lack of outstanding balances and having signed an RSA) before offering IPv4 address resources for transfer. Upon pre-qualification, ARIN will provide the transferor with documentation of the pre-qualification, including the network block and the expiration date of the pre-qualification. 8.3.6 Deaggregation when Permitted by ARIN If ARIN determines that there is an inadequate supply of small blocks, ARIN may allow transferors to subdivide network blocks beyond the limited subdivision permitted under 8.3.3. ARIN will attempt to ensure an adequate supply of small blocks while minimizing deaggregation. 8.3.7. Safe Harbor for IPv4 Transfers through this Simple Transfer Process When an IPv4 address resource is made available for transfer, it shall be deemed exempt from ARIN utilization audit until 90 days after its transfer pre-qualification or until the transfer is completed, whichever comes first. In the event that a transfer is not consummated within the prequalification time period, the block may be immediately re-prequalified for transfer. Notwithstanding the current offered state of the address resource, however, the audit exemption period shall expire untolled 90 days after the expiration of the first pre-qualification period. After the expiration of any utilization audit exemption period, ARIN shall have 90 days in which to initiate a utilization audit. In no event shall non-exempt time be construed to extend the end of the next exemption period. 8.3.8. Simple IPv4 Transfers to or from Organizations Under Common Ownership or Control If an IPv4 transferor or transferee is under common ownership or control with any other organization that holds one or more IPv4 blocks, the IPv4 transfer request must report all such organizations under common ownership or control. When evaluating compliance with IPv4 Simple Transfer conditions, ARIN may consider a transferor?s transfer request in light of requests from other organizations under common ownership or control with the transferor. Similarly, ARIN may consider a transferee?s request in light of requests from other organizations under common ownership or control with the transferee. In evaluating requests from other organizations under common ownership or control, ARIN staff will consider the relationship between the organizations, the degree of coordination between the organizations, and the bona fide use of the addresses at issue to determine whether all appropriate conditions are met. 8.3.9. Record-keeping and Publication of Simple Transfers of IPv4 Addresses ARIN will develop and operate a listing service to assist interested transferors and transferees by providing them a centralized location to post information about IPv4 blocks available from prequalified transferors and IPv4 blocks needed by prequalified transferees. Participation in the listing service is voluntary. After completion of the transfer, ARIN will update the registration records pertaining to the IPv4 block at issue. ARIN will adjust its records as to the holdings of the transferor and transferee. After the transfer, ARIN will publish WHOIS data that reflects the current allocation or assignment of the transferred block. ARIN will also make available information about any prior recipient(s) of such block. ARIN will also publish a log of all transfers, including block, transferor, transferee, and date. Rationale: The ARIN Board of Trustees asked the Advisory Council to consider a set of questions around the depletion of the free pool of IPv4 addresses, the transition to IPv6 for Internet address needs in the future, and ARIN's possible role in easing the transition. Over the past few years the AC has spent a great deal of time reflecting on these issues ? as a group, as individuals, and in consultation with the community. One outcome of this process is this policy proposal, which the AC is submitting for consideration at the next meeting. We are proposing some changes to existing ARIN policy regarding the transfer of IP address block registrations between subscribers, which will allow for the emergence of trade in IPv4 address space, with ARIN to provide a listing service for address blocks available for transfer under the liberalized policy. We are aware that this proposal, if adopted, will mark a major change in ARIN's role in the community and the Internet. This policy proposal would create a transfer mechanism for IPv4 number resources between those who have excess resources and those who have a need, thereby allowing ARIN to continue to serve its mission after IANA free pool exhaustion. This proposal would also set conditions on such transfers intended to preserve as much as possible the existing policy related to efficient, needs-based resource issuance, and would leverage ARIN's extensive control systems, audit trails, and recognized position as a trusted agent to avoid speculation and hoarding and diminish the likelihood and extent of an uncontrolled 'black market' where the risk and potential for fraud is immeasurably higher. Many of the transfer conditions are self-explanatory, but some worth highlighting are that: ? To discourage speculation, a waiting period (proposed at 24 months) is required before a transferee (or ordinary resource recipient) can become a transferor, or vice versa. ? Transferees must qualify for IPv4 space (just as they do today when getting it from ARIN) before they can receive address space by transfer, or solicit space on a listing service. ? To discourage unnecessarily rapid growth of routing tables, an allocation or assignment may not be arbitrarily deaggregated. To allow a transferor to downsize within their existing space, they may split off a contiguous address range, once every 12 months, and transfer the resulting netblock(s), which are subject to ARIN?s minimum allocation size, to one or more transferee(s). ? A transferee may receive one transfer every 6 months, so they?ll be incented to transfer a block appropriately sized for their needs, which will further discourage deaggregation and keep smaller blocks available for smaller organizations. The proposal would also have ARIN develop and operate a listing service to facilitate transfers and provide an authoritative central source of information on space available and requested for transfer. It would not prohibit private party transactions, but would require that potential transferors and transferees be pre-qualified first, so that neither party will encounter any unexpected surprises when they ask ARIN to process the transfer. Timetable for implementation: Immediately, with most aspects of policy taking effect upon IANA exhaustion, per the policy text. From info at arin.net Fri Mar 21 14:46:27 2008 From: info at arin.net (Member Services) Date: Fri, 21 Mar 2008 14:46:27 -0400 Subject: [ppml] Policy Proposal 2008-1 - Staff Assessment Message-ID: <47E40283.6010707@arin.net> Policy Proposal 2008-1 Title: SWIP Support for smaller than /29 Assignments Proposal Submitted: Feb 26, 2008 Date of Assessment: Mar 21, 2008 ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2008_1.html II. Understanding of the proposal Staff understands that this policy will allow upstream ISPs to report utilization to ARIN by submitting their customer and/or internal assignments of /29 or smaller via SWIP and RWHOIS server in addition to the current accepted method which is a flat file in the form of an excel spreadsheet of similar. This will allow customers to use SWIP or RWHOIS server as a single source for reporting their utilization data back to ARIN. III. Issues and concerns A. ARIN Staff Comments Staff foresees no problems with the implementation of this policy and no conflicts with current policy. B. ARIN General Counsel Counsel sees no significant legal or litigation issues related to this policy. IV. Resource Impact ? Minimal The resource impact of implementing this policy is minimal. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: ? Changes to the registration software to accept the submission of /29s and smaller via the various reassignment templates. ? Changes to Guidelines ? Minor template changes ? May increase RSD?s workload if an overwhelming number of people choose to swip allocations smaller than /29 ? Staff anticipates no major issues with Whois (performance, storage, gen, etc.) Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2008-1 SWIP Support for smaller than /29 Assignments Author: Joe Maimon Proposal Version: 1 Submission Date: 26 February 2008 Proposal type: modify Policy term: permanent Policy statement: 4.2.2.1.2.) " ISPs must provide reassignment information on the entire previously allocated block(s) via SWIP or RWHOIS server for /29 or larger blocks. For blocks smaller than /29 and for internal space, ISPs should provide utilization data using the table format described in Section 4.2.3.7.5. " Replace with " ISPs must provide reassignment information on the entire previously allocated block(s) via SWIP or RWHOIS server for /29 or larger blocks. For blocks smaller than /29 and for internal space, ISPs should provide utilization data either via SWIP or RWHOIS server or by using the table format described in Section 4.2.3.7.5. " 4.2.2.2.1.) " Utilization for blocks smaller than /29 can be documented using the format described in Section 4.2.3.7.5. " Replace with " Utilization for blocks smaller than /29 can be documented via SWIP or RWHOIS server or by using the format described in Section 4.2.3.7.5. " 4.2.3.7.2.) " For blocks smaller than /29 and for internal space, ISPs should provide utilization data using the format described in Section 4.2.3.7.5. " Replace with " For blocks smaller than /29 and for internal space, ISPs should provide utilization data via SWIP or RWHOIS server or by using the format described in Section 4.2.3.7.5. " 4.2.3.7.5.) Accounting for additional utilization " The following format should be used to provide the required information for utilization of blocks smaller than /29 and for describing internal networks: " Replace with " The following format should be used to provide the required information for utilization of blocks smaller than /29 and for describing internal networks when either SWIP or RWHOIS server is not used: " Rationale: With increasing frequency of smaller than /29 assignements to customers, the ability for ISP's to utilize SWIP or RWHOIS as a single comprehensive source of their utilization data should be supported. To implement this policy change, ARIN SWIP would need to no longer reject SWIP templates smaller then /29. Timetable for implementation: Immediate From info at arin.net Fri Mar 21 14:47:08 2008 From: info at arin.net (Member Services) Date: Fri, 21 Mar 2008 14:47:08 -0400 Subject: [ppml] Policy Proposal 2007-21 - Staff Assessment Message-ID: <47E402AC.3080009@arin.net> Policy Proposal 2007-21 Title: PIv6 for legacy holders with RSA and efficient use Revision Submitted: Mar 11, 2008 Date of Assessment: Mar 21, 2008 ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_21.html II. Understanding of the proposal ARIN staff understands that this proposal would make direct assignments of IPv6 space available to any organization with an efficiently utilized v4 assignment or allocation covered under an RSA. III. Issues and concerns A. ARIN Staff ? General Comment The revised policy text is clear and could be implemented as written. B. ARIN General Counsel This policy does not create any significant legal or litigation concerns. IV. Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 30 ? 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: ? Updates to Guidelines will be required ? Staff training will be required ? New process to manually add RSA coverage will be required Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-21 PIv6 for legacy holders with RSA and efficient use Author: Scott Leibrand Proposal Version: 2.0 Date: 11 March 2008 Proposal type: modify 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 all direct IPv4 assignments and allocations, each of which must be covered by a current ARIN RSA. Rationale: Current policy allows direct IPv6 allocations and assignments to nearly all organizations with IPv4 allocations or assignments from ARIN. As a result, such organizations can get IPv6 space just as easily as they can get IPv4 space, making it easy for them to transition to IPv6 as soon as they're ready to do so. However, there are some organizations who received IPv4 /23's and /24's prior to the formation of ARIN, and use that space in a multihomed, provider-independent fashion. Under current policy, such organizations cannot get IPv6 PI space without artificially inflating host counts, and are therefore discouraged from adopting IPv6. This policy proposal aims to remove this disincentive, and allow such organizations to easily adopt IPv6. In addition, pre-ARIN assignments were issued through an informal process, and many legacy resource holders have not yet entered into a formal agreement with ARIN, the manager of many such IP numbering resources. This policy proposal would require that such assignments be brought under a current ARIN Registration Services Agreement, thereby formalizing the relationship. Some pre-ARIN assignments may not be used efficiently. As unallocated IPv4 numbering resources are approaching exhaustion, it is important to ensure efficient utilization of IPv4 assignments, and to arrange for reclamation of unused space. Therefore, this policy would require that the organization wishing to receive IPv6 PI space demonstrate efficient utilization of their IPv4 assignment. (Efficient utilization is already defined elsewhere in policy, and the exact mechanism for achieving and determining efficient use is a matter of procedure, not of policy, so detailed procedures are not included in the policy statement above. The intent is that any organization with an assignment of /23 or larger which is less than 50% utilized would renumber and return whole unused CIDR blocks as necessary to bring the remaining CIDR block to 50% utilization or higher. A /24 should be considered efficiently utilized as long as it is in use for multihoming, as /25's and smaller are not routable for that purpose.) It has been suggested that this policy would be useful only until the growth of IPv6 exceeds the growth of IPv4. I would agree with this, and would further posit that the existing "qualify ... under the IPv4 policy currently in effect" language should also be modified at that time. I have therefore proposed this policy with a policy term of "permanent", with the expectation that this section of policy (6.5.8.1) will be rewritten at the appropriate time to entirely remove all IPv4 dependencies. Timetable for implementation: immediate From info at arin.net Fri Mar 21 14:47:38 2008 From: info at arin.net (Member Services) Date: Fri, 21 Mar 2008 14:47:38 -0400 Subject: [ppml] Policy Proposal 2007-23 - Staff Assessment Message-ID: <47E402CA.6030308@arin.net> Policy Proposal 2007-23 (Global) Title: End Policy for IANA IPv4 allocations to RIRs Revision Submitted: Feb 8, 2008 Date of Assessment: Mar 21, 2008 ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_23.html II. Understanding of the proposal ARIN staff understands that this policy would have IANA allocate a single /8 to each of the 5 RIRs ?at the point when the IANA free pool is more than 5 /8s, but too small to fulfill a request from an RIR without using part of the final 5 /8s? or the point of imminent exhaustion. III. Comments A. ARIN Staff 1. The policy conflicts with the spirit of RFC 2050 in which fairness and efficiency of allocation by IANA to the RIRs is cited. 2. Author did not indicate placement in the NRPM. It would go in to Section 10. B. ARIN General Counsel This policy presents no significant legal issues. It seeks to substitute a different mechanism than actual utilization to allocate the last 5 unallocated blocs of IPV4 resources, one each to each RIR. It might be arguably discriminatory against ARIN, or any other RIR which has a high 'burn rate' for a slash 8, compared to those RIRs with a slower burn rate; it also could be more discriminatory if the low burn rate RIR's are provided a slash 8 just before the trigger event and consequently end up with 2 slash 8's, with a lower burn rate. However, Counsel sees these as political/policy considerations and not legal issues. IV. Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 30 -90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: ? Updates to Guidelines will be required ? Staff training will be required Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-23 (Global) End Policy for IANA IPv4 allocations to RIRs Proposal Version: Version 2 Date: 8 February 2008 Author: Roque Gagliano, ANTEL; Francisco Obispo, CENIT; Haitham EL Nakhal, MCIT; Didier Allain Kla, ISOC Cote d'Ivoire; JPNIC IPv4 countdown policy team: - Akinori Maemura - Akira Nakagawa - Izumi Okutani - Kosuke Ito - Kuniaki Kondo - Shuji Nakamura - Susumu Sato - Takashi Arano - Tomohiro Fujisaki - Tomoya Yoshida - Toshiyuki Hosaka Proposal type: new Policy term: temporary Policy statement: This is a revised version of; prop-046: IPv4 countdown policy proposal prop-051: Global policy for the allocation of the remaining IPv4 address space This policy describes the process for the allocation of the remaining IPv4 space from IANA to the RIRs. When a minimum amount of available space is reached, one /8 will be allocated from IANA to each RIR, replacing the current IPv4 allocation policy. In order to fulfill the requirements of this policy, at the time it is adopted, one /8 will be reserved by IANA for each RIR. The reserved allocation units will no longer be part of the available space at the IANA pool. IANA will also reserve one /8 to any new RIR at the time it is recognized. The process for the allocation of the remaining IPv4 space is divided in two consecutive phases: 4.1. Existing Policy Phase: During this phase IANA will continue allocating IPv4 addresses to the RIRs using the existing allocation policy. This phase will continue until a request for IPv4 address space from any RIR to IANA either cannot be fulfilled with the remaining IPv4 space available at the IANA pool or can be fulfilled but leaving the IANA remaining IPv4 pool empty. This will be the last IPv4 address space request that IANA will accept from any RIR. At this point the next phase of the process will be initiated. 4.2. Exhaustion Phase: IANA will automatically allocate the reserved IPv4 allocation units to each RIR (one /8 to each one) and respond to the last request with the remaining available allocation units at the IANA pool (M units). 4.2.1. Size of the final IPv4 allocations: During this phase IANA will automatically allocate one /8 to each RIR from the reserved space defined in this policy. IANA will also allocate M allocation units to the RIR that submitted the last request for IPv4 addresses. 4.2.2. Allocation of the remaining IPv4 Address space: After the completion of the evaluation of the final request for IPv4 addresses, IANA MUST: A) Immediately notify the NRO about the activation of the second phase of this policy. B) Proceed to allocate M allocation units to the RIR that submitted the last request for IPv4 address space. C) Proceed to allocate one /8 to each RIR from the reserved space. Rationale: The exhaustion of IPv4 address space is projected to take place within the next few years. This proposal seeks to focus on measures that should be taken globally in the address management area in order to prepare for the situation in all RIR regions. To continue applying a global coordinated policy for distribution of the last piece(s) of each RIR's unallocated address block does not match the reality of the situation in each RIR region. Issues each RIR region will face during the exhaustion period vary by region as the level of development of IPv4 and IPv6 are widely different. As a result, applying a global co-ordinated policy may not adequately address issues in a certain region while it could be work for the others. For example, in a region where late comers desperately need even small blocks of IPv4 addresses to access to the IPv4 Internet, a policy that defines the target of allocations/assignments of IPv4 address space to be late comers would be appropriate in such region. This would allow availablilty of IPv4 address space for such requirements for more years. Another example comes from difference in IPv6 deployment rate. For a region where IPv6 deployment rate is low, measures may be necessary to prolong IPv4 address life for the existing business as well as for new businesses until networks are IPv6 ready. Some regions may have strong needs to secure IPv4 address space for translators. A globally coordinated policy which addresses all the issues listed above to meet the needs for all RIR regions may result in not solving issues in any of the regions. Timetable for implementation: after approval by ICANN board From info at arin.net Fri Mar 21 14:48:01 2008 From: info at arin.net (Member Services) Date: Fri, 21 Mar 2008 14:48:01 -0400 Subject: [ppml] Policy Proposal 2007-14 - Staff Assessment Message-ID: <47E402E1.6080903@arin.net> Policy Proposal 2007-14 Title: Resource Review Process Proposal Submitted: Feb 21, 2008 Date of Assessment: Mar 21, 2008 ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_14.html II. Understanding of the proposal This policy proposal provides clear policy authority to audit or reclaim resources, guidelines for how it shall be done, and a guarantee of a (minimum) six-month grace period so that the current user shall have time to stop using any resources to be reclaimed. III. Comments A. ARIN Staff 1. 2c does not reconcile with the RSA, which grants ARIN authority to request any data necessary and does not specify any sort of limitation to frequency. 2. Item 3 requires staff to share the results of an audit of an organization?s resources. Staff often reviews an organization?s transaction history and resources during fraud or suspicious activity investigations and feels that it is not always prudent to share those results. 3. Point 4b uses the term ?single aggregate block? Does this refer to a single CIDR prefix, or to ?a contiguous range of addresses?? B. ARIN General Counsel This policy will be looked at very carefully in those instances where ARIN demands data, or seeks to terminate and revoke resources previously granted. It will guide ARIN, and any reviewing adjudication court who may be required to evaluate a dispute, review it because it sets up procedures for revocation, and requires production of data. Writing down such policies may be important support for ARIN's application of such policies. However, the same benefit can become a problem if the language is not carefully constructed. Counsel supports a version of this policy being enacted and believes adoption of this policy could reduce future legal fees. Some language tweaks may help. For this reason I am suggesting the author and AC consider language that tightens the policy from a legal perspective but is consistent with the perceived intent of the author. Some language changes are more important than others. Please note: Outlook doesn't permit redlining to show; it automatically accepts the redlined changes. Therefore, the redlines have been accepted in 1-8 below. 1. ARIN may review the current usage of any resources issued by ARIN to an organization. The organization shall furnish whatever records are believed to be necessary by ARIN to perform this review. 2. ARIN may conduct such reviews: a. when any new resource is requested, b. whenever ARIN has reason to believe that the resources originally were obtained fraudulently, or in contravention of existing policies, c. at any other time, without cause having to be established, unless a prior review has been completed in the preceding 24 months. 3. ARIN shall communicate the results of the review to the organization. 4. Organizations found by ARIN to be substantially out of compliance with current ARIN policy shall be requested or required to return resources to bring them into (or reasonably close to) compliance. 4a. The extent to which an organization may remain out of compliance shall be based on the reasonable judgment of the ARIN staff and shall balance all facts known, including the organizations utilization rate, available address pool, and other factors as appropriate so as to avoid forcing returns which will result in near-term additional requests or unnecessary route de- aggregation. 4b. To the extent possible, entire blocks should be returned. Partial address blocks shall be returned in such a way that the portion retained will comprise a single aggregate block. 5. If the organization does not voluntarily return resources as requested, ARIN may revoke any resources issued by ARIN as required to bring the organization into overall compliance. ARIN shall follow the same guidelines for revocation that are required for voluntary return in the previous paragraph. 6. Except in cases of fraud, or intentional violations of policy, an organization shall be provided a reasonable period of time to effect a return. ARIN shall agree to a longer term with the organization if ARIN believes the organization is working in good faith to restore compliance and has a valid need for additional time to renumber out of the affected blocks. 7. ARIN shall continue to maintain the resource(s) while their return or revocation is pending, except no new maintenance fees shall be assessed for the resource(s). (?) 8. Legacy resources in active use, regardless of utilization, are not subject to revocation by ARIN, pursuant to this subsection. However, the utilization of legacy resources shall be considered during a review to assess overall compliance. Counsel continues not to agree with the first sentence of the rationale which states ARIN "feels that current policy does not give them the power to review or reclaim resources except in cases of fraud...." Counsel requests this be rewritten to reflect that such powers need to be carefully delineated for application and ease of understanding. IV. Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimal. Barring any unforeseen resource requirements, this policy could be implemented within 30 ? 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Depending on the impact to RSD this may require additional staff. It will require the following: ? Guidelines Changes ? Registration System Changes ? Staff training ? May increase RSD workload ? May increase turnaround times Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-14 Resource Review Process Author: Owen DeLong, Stephen Sprunk Date: 21 February 2008 Proposal type: modify Policy term: permanent Policy statement: Add the following to the NRPM: Resource Review 1. ARIN may review the current usage of any resources issued by ARIN to an organization. The organization shall furnish whatever records are necessary to perform this review. 2. ARIN may conduct such reviews: a. when any new resource is requested, b. whenever ARIN has cause to believe that the resources had originally been obtained fraudulently, or c. at any other time without cause unless a prior review has been completed in the preceding 24 months. 3. ARIN shall communicate the results of the review to the organization. 4. Organizations shown to be substantially out of compliance with current ARIN policy shall return resources as needed to bring them into (or reasonably close to) compliance. 4a. The extent to which an organization may remain out of compliance shall be based on the best judgment of the ARIN staff and shall balance the organizations utilization rate, available address pool, and other factors as appropriate so as to avoid forcing returns which will result in near-term additional requests or unnecessary route de- aggregation. 4b. To the extent possible, entire blocks should be returned. Partial address blocks shall be returned in such a way that the portion retained will comprise a single aggregate block. 5. If the organization does not voluntarily return resources as required, ARIN may revoke any resources issued by ARIN as required to bring the organization into overall compliance. ARIN shall follow the same guidelines for revocation that are required for voluntary return in the previous paragraph. 6. Except in cases of fraud, an organization shall be given a minimum of six months to effect a return. ARIN shall negotiate a longer term with the organization if ARIN believes the organization is working in good faith to substantially restore compliance and has a valid need for additional time to renumber out of the affected blocks. 7. ARIN shall continue to maintain the resource(s) while their return or revocation is pending, except no new maintenance fees shall be assessed for the resource(s). 8. Legacy resources in active use, regardless of utilization, are not subject to revocation by ARIN. However, the utilization of legacy resources shall be considered during a review to assess overall compliance. 9. In considering compliance with policies which allow a timeframe (such as a requirement to assign some number of prefixes within 5 years) failure to comply cannot be measured until after the timeframe specified in the applicable policy has elapsed. Blocks subject to such a policy shall be assumed in compliance with that policy until such time as the specified time since issuance has elapsed. Delete NRPM sections 4.1.2, 4.1.3, 4.1.4 Remove the sentence "In extreme cases, existing allocations may be affected." from NRPM section 4.2.3.1. Rationale: ARIN feels that current policy does not give them the power to review or reclaim resources except in cases of fraud, despite this being mentioned in the Registration Services Agreement. This policy proposal provides clear policy authority to do so, guidelines for how and under what conditions it shall be done, and a guarantee of a (minimum) six- month grace period so that the current user shall have time to renumber out of any resources to be reclaimed. The nature of the "review" is to be of the same form as is currently done when an organization requests new resources, i.e. the documentation required and standards should be the same. The intent of paragraph 2c is to prevent ARIN from doing more than one without-cause review in a 24 month period. The renumbering period does not affect any "hold" period that ARIN may apply after return or revocation of resources is complete. The deleted sections/text would be redundant with the adoption of this proposal. Timetable for implementation: Immediate From info at arin.net Fri Mar 21 14:48:14 2008 From: info at arin.net (Member Services) Date: Fri, 21 Mar 2008 14:48:14 -0400 Subject: [ppml] Policy Proposal 2007-17 - Staff Assessment Message-ID: <47E402EE.20104@arin.net> Policy Proposal 2007-17 Title: Legacy Outreach and Partial Reclamation Date Submitted: Feb. 21, 2008 Date of Assessment: Mar 21, 2008 ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_17.html The proposal was revised, current version dated 21 February 2008. II. Understanding of the proposal ARIN staff understands that this proposal would replace the existing amnesty policy in NRPM Section 4.6. III. Comments A. ARIN Staff 1. There is currently an amnesty policy (NRPM 4.6) and an aggregation policy (NRPM 4.7). Both policies contain clear and concise criteria and have been used successfully by the ARIN community since implementation. 2. This proposal seems to be combining both of these policies into one policy. If that is the case, it needs to explicitly state that. 3. The proposed policy text implies that ARIN will issue new addresses to organizations in exchange for returned addresses, but does not explicitly state that. 4. The proposed policy text removes the 12 month renumbering timeframe, creating significant abuse potential. Since there's no renumbering timeframe, nothing prevents the requestor from keeping both the smaller aggregates and the large aggregate indefinitely. 5. The proposed policy text requires ARIN to accept all amnesty or aggregation returns without prejudice, creating more avenues for abuse. For example, a spammer would be able to use this policy to repeatedly exchange blacklisted space for clean space. 6. If anyone is allowed to exchange their space without limitation, this could affect the remaining supply of IPv4 address space. B. ARIN General Counsel The policy creates no significant legal or litigation concerns. Comment for author or AC to consider, but not in a binding way: if ARIN label's some set of resources as in the control of someone 'unreachable' in whois, do we inadvertently encourage hijacking and spamming during the waiting period before revocation? The prior expressed concerns about binding board or inappropriately getting into fee setting of board have been addressed by changes. IV. Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 30 - 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: ? Updates to Registration Services Guidelines will be required ? Staff training will be required ? Tracking tools for the return of the space and for the yearly contact requirement Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-17 Legacy Outreach and Partial Reclamation Author: Owen DeLong Date: 21 February 2008 Proposal type: modify Policy term: permanent Policy statement: Replace section 4.6 as follows: 4.6 Amnesty and Aggregation requests 4.6.1 Intent of this policy This policy is intended to allow the community and ARIN staff to work together with holders of address resources in the best interests of the community by facilitating the return of unused address space and the aggregation of existing space in a manner which is in the best interests of both parties. 4.6.2 No penalty for returning or aggregating ARIN shall seek to make the return of address space as convenient and risk-free to the returning organization as possible. An organization with several non-contiguous blocks seeking to aggregate and return space at the same time should be accommodated if possible. If it is possible to expand one block, for example, to facilitate the return of other blocks, ARIN should do that where possible. 4.6.3 Return should not force renumbering An organization shall be allowed to return a partial block of any size to ARIN. For any return greater than a /24, ARIN shall not require that the non-returned portion of the block be renumbered unless the returning organization wishes to do so. 4.6.4 Incentives The Board of Trustees should consider creating incentives for organizations to return addresses under this policy. 4.6.5 RSA Required if new addresses received Any organization which receives any additional addresses under this policy shall be required to sign an ARIN RSA which will apply to all new addresses issued and to any retained blocks which are expanded under this policy. 4.6.6 Annual contact required Any organization which participates in this policy shall be required to sign an agreement stipulating that ARIN will attempt contact at least once per year via the contact mechanisms registered for the organization in whois. Should ARIN fail to make contact, after reasonable effort the organization shall be flagged as "unreachable" in whois. After six months in "unreachable" status, the organization agrees that ARIN may consider all resources held by the organization to be abandoned and reclaim such resources. Should the organization make contact with ARIN prior to the end of the aforementioned six month period and update their contact information appropriately, ARIN shall remove the "unreachable" status and the annual contact cycle shall continue as normal. If the organization pays annual fees to ARIN, the payment of annual fees shall be considered sufficient contact. Rationale: Existing policy supports aggregation (4.7) and provides some amnesty (existing 4.6) for returning blocks. However, a number of resource holders have expressed discomfort with the current section 4.6 believing that they will be forced to return their entire address space and renumber rather than being able to make partial returns and retain some of their existing space. This policy seeks to eliminate those concerns and make the return of unused address space more desirable to the resource holders. A very high percentage of underutilized space is in the hands of legacy holders who currently have no benefit to joining the ARIN process and no way to return any portion of their address space without incurring significant disadvantage as a result. A suggestion to the board would be to adopt benefits along the following lines for people returning space. These benefits would provide additional incentive for resource holders to make appropriate returns and for legacy holders to join the ARIN process: 1. If the organization does not currently pay ARIN fees, they shall remain fee exempt. 2. If the organization currently pays ARIN fees, their fees shall be waived for two years for each /20 returned, with any fractional /20 resulting in a one-time single year waiver. 3. Any organization returning address space under this policy shall continue under their existing RSA or they may choose to sign the current RSA. For organizations which currently do not have an RSA, they may sign the current RSA, or, they may choose to remain without an RSA. 4. All organizations returning space under this policy shall, if they meet other eligibility requirements and so request, obtain an appropriate IPv6 end-user assignment or ISP allocation as applicable, with no fees for the first 5 years. Organizations electing to receive IPv6 allocation/assignment under this provision must sign a current RSA and must agree that their IPv4 resources are henceforth subject to the RSA. Timetable for implementation: Immediate From info at arin.net Fri Mar 21 14:48:33 2008 From: info at arin.net (Member Services) Date: Fri, 21 Mar 2008 14:48:33 -0400 Subject: [ppml] Policy Proposal 2007-27 - Staff Assessment Message-ID: <47E40301.9070405@arin.net> Policy Proposal 2007-27 Title: Cooperative distribution of the end of the IPv4 free pool Proposal Submitted: Nov 20, 2007 Date of Assessment: Mar 21, 2008 ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_27.html II. Understanding of the proposal Staff understands that this policy will establish a mechanism for the allocation of IPv4 address blocks between RIR's once the IANA global pool of addresses has been depleted. III. Issues and concerns A. ARIN Staff 1. This policy would have to adopted as an Inter-RIR policy and would have to remain the same in each region for it to work properly. 2. There is no way of reliably predicting when an RIR is within 30 days of depleting their remaining pool of IPv4 addresses since this is dependent upon the number and size of the resource requests they receive. 3. This policy would require constant monitoring of the available IPv4 inventory of all the RIRs. To be timely, a software tool would need to be developed that monitored all RIR available IPv4 inventory and produced a daily report. This same tool would need to be used by all 5 of the RIRs for consistency and accuracy. 4. When the recipient RIR approaches the source RIR for a 3 month supply of addresses, will fees be charged to the recipient RIR? 5. It is likely that AfriNIC and LACNIC will be the two RIRs who typically would have the largest inventory of IPv4 at any given time since they currently allocate address space at a slow rate and in lessor amounts than the other three RIRs. If the three larger RIRs consistently approach them for address space, it is likely that their remaining supply will quickly dwindle. 6. If one RIR will be required to review requests from another region, all such requests must be made in an agreed upon common language. 7. Process and procedures training may be required for those parties making requests to an RIR in a region other than their own. 8. If the source RIR reviews and approves requests from the recipient RIR?s customers, there are likely to be business, legal, and other administrative issues that arise. For example: - Which RIR would the requestor pay? - In what currency would the fee paid? - Which RIR would have to report the registration fee as income? - Which RIR would the requestor sign a contract with? - Which RIR would maintain the record? - Will the requestor become a member of the source RIR and if so, will they be required to pay an annual fee to the source RIR? B. ARIN General Counsel Counsel sees no significant legal or litigation issues related to this policy. IV. Resource Impact ? Major The resource impact of implementing this policy is viewed as major. Barring any unforeseen resource requirements, this policy could be implemented within 180 days from the date of the ratification of the policy by the ARIN Board of Trustees. It would also be dependent upon the policy being adopted in all other RIRs. ? Tracking tool with built in metrics needed to attempt to estimate the 30 day depletion mark ? Survey needs to be created to ask other RIR to estimate their remaining available space ? Inter RIR coordination process needs to be established for this process of surveying and follow up actions. ? New guidelines ? Staff training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-27 Cooperative distribution of the end of the IPv4 free pool Author: Tony Hain Date: 20 November 2007 Proposal type: new Policy term: permanent Policy summary: This policy will establish a process for RIR-to-RIR redistribution of the tail-end of the IPv4 pool, taking effect after the IANA Reserve is exhausted. Each redistribution Allocation will be triggered by the recipient RIR depleting its reserve to a 30 day supply, and will result in up to a 3 month supply being transferred from the RIR with the longest remaining time before it exhausts its own pool. Policy statement: At the point when any given RIR is within 30 days of depleting its remaining IPv4 pool, a survey will be taken of the other 4 to determine the remaining time before each of them exhausts their pool (including both member use and recent redistribution allocations to other RIRs). The one with the longest window before exhausting its pool will be designated as the source RIR. The recipient RIR will follow procedures for an LIR in the source RIR region to request a block that is expected to be sufficient for up to 3 months, but is no larger than 1/8th of the source RIR's remaining pool. At the point where no RIR can supply a block that is less than 1/8th of their remaining pool that will sustain the recipient RIR for 30 days, the recipient RIR will collect its requests each week, and forward those individual requests to the source RIR designated that week. Rationale: This policy will establish a mechanism for the Allocation of IPv4 address blocks between RIR's, but will not go into effect until the IANA pool has been depleted. It is really bizarre to watch the maneuvering as the global RIR community grapples with 'fairness' of distributing the last few IANA Reserve /8 blocks. On one level this just appears to be petty sibling rivalry, as people are bickering over who gets the last cookie and whimpering about 'fairness'. At the same time, each RIR is chartered to look after the interests of its membership so it is to be expected that they will each want to get as much as possible to meet the needs of their respective membership. Existing practice requires RIR's to acquire blocks from IANA, which leads to the current round of nonsense about optimal distribution of the remaining pool based on elaborate mathematical models. This globally submitted policy proposal attempts to resolve the issue by shifting to an RIR-to-RIR Allocation model after the IANA pool is depleted. This policy would effectively result in each RIR becoming a virtual LIR member of all of the other RIR's for the sole purpose of managing the tail-end of the IPv4 pool. Timetable for implementation: Before 1/1/2009 From owen at delong.com Sat Mar 22 18:34:08 2008 From: owen at delong.com (Owen DeLong) Date: Sun, 23 Mar 2008 07:34:08 +0900 Subject: [ppml] Revised 2007-14 Message-ID: <434C0D36-B948-4226-A5F4-37EFEE29B504@delong.com> The following revisions to 2007-14 are being submitted in order to address some concerns expressed to the authors by ARIN counsel. The authors do not believe that these changes alter the meaning or intent of the proposal. This is the version that will be presented at the Denver meeting. Version: 2.1 Policy statement: Add the following to the NRPM: Resource Review 1. ARIN may review the current usage of any resources issued by ARIN to an organization. The organization shall furnish whatever records are believed to be necessary by ARIN to perform this review. 2. ARIN may conduct such reviews: a. when any new resource is requested, b. whenever ARIN has reason to believe that the resources were originally obtained fraudulently, or c. at any other time without having to establish cause unless a prior review has been completed in the preceding 24 months. 3. ARIN shall communicate the results of the review to the organization. 4. Organizations found by ARIN to be substantially out of compliance with current ARIN policy shall be requested or required to return resources as needed to bring them into (or reasonably close to) compliance. 4a. The extent to which an organization may remain out of compliance shall be based on the reasonable judgment of the ARIN staff and shall balance all facts known, including the organizations utilization rate, available address pool, and other factors as appropriate so as to avoid forcing returns which will result in near-term additional requests or unnecessary route de-aggregation. 4b. To the extent possible, entire blocks should be returned. Partial address blocks shall be returned in such a way that the portion retained will comprise a single aggregate block. 5. If the organization does not voluntarily return resources as requested, ARIN may revoke any resources issued by ARIN as required to bring the organization into overall compliance. ARIN shall follow the same guidelines for revocation that are required for voluntary return in the previous paragraph. 6. Except in cases of fraud, or intentional violations of policy, an organization shall be given a minimum of six months to effect a return. ARIN shall negotiate a longer term with the organization if ARIN believes the organization is working in good faith to substantially restore compliance and has a valid need for additional time to renumber out of the affected blocks. 7. ARIN shall continue to maintain the resource(s) while their return or revocation is pending, except no any maintenance fees assessed during that period shall be calculated as if the return or revocation was complete. 8. Legacy resources in active use, regardless of utilization, are not subject to revocation by ARIN. pursuant to this subsection. However, the utilization of legacy resources shall be considered during a review to assess overall compliance. 9. In considering compliance with policies which allow a timeframe (such as a requirement to assign some number of prefixes within 5 years) failure to comply cannot be measured until after the timeframe specified in the applicable policy has elapsed. Blocks subject to such a policy shall be assumed in compliance with that policy until such time as the specified time since issuance has elapsed. Delete NRPM sections 4.1.2, 4.1.3, 4.1.4 Remove the sentence "In extreme cases, existing allocations may be affected." from NRPM section 4.2.3.1. Rationale: The authors have been told that current policy does not clearly give ARIN the power to review or reclaim resources except in cases of fraud, despite this being mentioned in the Registration Services Agreement. This policy proposal provides clear policy authority to do so, guidelines for how and under what conditions it shall be done, and a guarantee of a (minimum) six- month grace period so that the current user shall have time to renumber out of any resources to be reclaimed. The nature of the "review" is to be of the same form as is currently done when an organization requests new resources, i.e. the documentation required and standards should be the same. The intent of paragraph 2c is to prevent ARIN from doing more than one without-cause review in a 24 month period. The renumbering period does not affect any "hold" period that ARIN may apply after return or revocation of resources is complete. The deleted sections/text would be redundant with the adoption of this proposal. Timetable for implementation: Immediate From owen at delong.com Sat Mar 22 19:02:56 2008 From: owen at delong.com (Owen DeLong) Date: Sun, 23 Mar 2008 08:02:56 +0900 Subject: [ppml] Policy Proposal 2007-14 - Staff Assessment In-Reply-To: <47E402E1.6080903@arin.net> References: <47E402E1.6080903@arin.net> Message-ID: <07FBD8D9-A66F-47D2-AF63-A76A5D3770AE@delong.com> On Mar 22, 2008, at 3:48 AM, Member Services wrote: > Policy Proposal 2007-14 > Title: Resource Review Process > Proposal Submitted: Feb 21, 2008 > Date of Assessment: Mar 21, 2008 > > III. Comments > > A. ARIN Staff > > 1. 2c does not reconcile with the RSA, which grants ARIN authority to > request any data necessary and does not specify any sort of limitation > to frequency. > This is somewhat intentional, and, the authors believe that the RSA would likely be revised to reflect this change in policy. In part, however, the "any data necessary" clause was an unintentional modificiation and has been corrected with today's 2.1 version of the policy. > 2. Item 3 requires staff to share the results of an audit of an > organization?s resources. Staff often reviews an organization?s > transaction history and resources during fraud or suspicious activity > investigations and feels that it is not always prudent to share those > results. > While this may be true under some circumstances, the authors feel that transparency is the overriding concern here. Further, the "results" which must be shared are not intended to go beyond the level of "a review was conducted and ARIN will be taking XYZ action as a result." where XYZ would be one of "NO" or "further steps to reclaim" or other appropriate phrase. We did not expect results to include detailed internal data about the process or any privileged work product of any investigation. If staff feels that the current language does not achieve this intent, the authors would welcome recommended language from staff or any other source which achieves this stated intent. > 3. Point 4b uses the term ?single aggregate block? Does this refer > to a > single CIDR prefix, or to ?a contiguous range of addresses?? > Where possible, a single CIDR prefix, but, if, for example, the required return would be 1.5 /16s, authors believe that a contiguous range is desirable in cases where the return cannot be satisfied from existing /16 and /17 . The real goal of this statement is to avoid having someone who has, say, a /16 from returning something like every other /26 out of their block to effect the return of a /17 worth of addresses. The authors believe that staff and the organizations in question can come to reasonable agreement in the best interests of the community using the language specified. However, if better language can be provided, we could adopt that. > > B. ARIN General Counsel > > This policy will be looked at very carefully in those instances where > ARIN demands data, or seeks to terminate and revoke resources > previously > granted. It will guide ARIN, and any reviewing adjudication court who > may be required to evaluate a dispute, review it because it sets up > procedures for revocation, and requires production of data. Writing > down > such policies may be important support for ARIN's application of such > policies. However, the same benefit can become a problem if the > language > is not carefully constructed. Counsel supports a version of this > policy > being enacted and believes adoption of this policy could reduce future > legal fees. > > Some language tweaks may help. For this reason I am suggesting the > author and AC consider language that tightens the policy from a legal > perspective but is consistent with the perceived intent of the author. > Some language changes are more important than others. Please note: > Outlook doesn't permit redlining to show; it automatically accepts the > redlined changes. Therefore, the redlines have been accepted in 1-8 > below. > All of these changes were incorporated into the 2.1 version of the proposal. Indeed, this request was the driving motivation to the creation of the 2.1 version of the proposal. As one of the authors, I apologize for the late change to accommodate this request, but, we felt it was best to get the changes out as soon as possible while still addressing the concerns raised by counsel. As a member of the AC, I will be looking for ways that staff and counsel can work better with proposal authors to get this kind of feedback in the hands of the authors earlier in the process to better facilitate changes with more notice prior to the meeting. Owen From info at arin.net Mon Mar 24 11:13:57 2008 From: info at arin.net (Member Services) Date: Mon, 24 Mar 2008 11:13:57 -0400 Subject: [ppml] Revised 2007-14 In-Reply-To: <434C0D36-B948-4226-A5F4-37EFEE29B504@delong.com> References: <434C0D36-B948-4226-A5F4-37EFEE29B504@delong.com> Message-ID: <47E7C535.8070305@arin.net> Policy Proposal 2007-14: Resource Review Process has been revised. This proposal is open for discussion on this mailing list and will be on the agenda at the upcoming ARIN Public Policy Meeting. The current policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_14.html Regards, Member Services American Registry for Internet Numbers (ARIN) Owen DeLong wrote: > The following revisions to 2007-14 are being submitted in order > to address some concerns expressed to the authors by ARIN > counsel. The authors do not believe that these changes alter > the meaning or intent of the proposal. > > This is the version that will be presented at the Denver meeting. > > Version: 2.1 > Policy statement: > > Add the following to the NRPM: > > Resource Review > > 1. ARIN may review the current usage of any resources issued by ARIN > to an organization. The organization shall furnish whatever records > are believed to be necessary by ARIN to perform this review. > > 2. ARIN may conduct such reviews: > > a. when any new resource is requested, > b. whenever ARIN has reason to believe that the resources > were originally obtained fraudulently, or > c. at any other time without having to establish cause unless a > prior review has been completed in the preceding 24 months. > > 3. ARIN shall communicate the results of the review to the organization. > > 4. Organizations found by ARIN to be substantially out of compliance > with > current ARIN policy shall be requested or required to return resources > as > needed to bring them into (or reasonably close to) compliance. > > 4a. The extent to which an organization may remain out of compliance > shall be based on the reasonable judgment of the ARIN staff and shall > balance all facts known, including the organizations utilization rate, > available address pool, and other factors as appropriate so as to avoid > forcing returns which will result in near-term additional requests or > unnecessary route de-aggregation. > > 4b. To the extent possible, entire blocks should be returned. Partial > address blocks shall be returned in such a way that the portion > retained will comprise a single aggregate block. > > 5. If the organization does not voluntarily return resources as > requested, ARIN may revoke any resources issued by ARIN as required to > bring the organization into overall compliance. ARIN shall follow the > same guidelines for revocation that are required for voluntary return > in the previous paragraph. > > 6. Except in cases of fraud, or intentional violations of policy, an > organization shall be given a minimum of six months to effect a > return. ARIN shall negotiate a longer term with the organization > if ARIN believes the organization is working in good faith to > substantially > restore compliance and has a valid need for additional time to > renumber out of the affected blocks. > > 7. ARIN shall continue to maintain the resource(s) while their return > or revocation is pending, except no any maintenance fees assessed > during that period shall be calculated as if the return or revocation > was complete. > > 8. Legacy resources in active use, regardless of utilization, are not > subject to revocation by ARIN. pursuant to this subsection. However, > the utilization of legacy resources shall be considered during a > review to assess overall compliance. > > 9. In considering compliance with policies which allow a timeframe > (such as a requirement to assign some number of prefixes within 5 > years) failure to comply cannot be measured until after the timeframe > specified in the applicable policy has elapsed. Blocks subject to such > a policy shall be assumed in compliance with that policy until such > time as the specified time since issuance has elapsed. > > > > Delete NRPM sections 4.1.2, 4.1.3, 4.1.4 > > Remove the sentence "In extreme cases, existing allocations may be > affected." from NRPM section 4.2.3.1. > > Rationale: > > The authors have been told that current policy does not clearly give > ARIN the power to review or reclaim resources except in cases of > fraud, despite this being mentioned in the Registration Services > Agreement. This policy proposal provides clear policy authority to > do so, guidelines for how and under what conditions it shall be > done, and a guarantee of a (minimum) six- month grace period > so that the current user shall have time to renumber out of any > resources to be reclaimed. > > The nature of the "review" is to be of the same form as is currently > done when an organization requests new resources, i.e. the > documentation required and standards should be the same. > > The intent of paragraph 2c is to prevent ARIN from doing more than one > without-cause review in a 24 month period. > > The renumbering period does not affect any "hold" period that ARIN may > apply after return or revocation of resources is complete. > > The deleted sections/text would be redundant with the adoption of this > proposal. > > Timetable for implementation: Immediate > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > From bicknell at ufp.org Mon Mar 24 11:28:53 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 24 Mar 2008 10:28:53 -0500 Subject: [ppml] Policy Proposal 2007-14 - Staff Assessment In-Reply-To: <07FBD8D9-A66F-47D2-AF63-A76A5D3770AE@delong.com> References: <47E402E1.6080903@arin.net> <07FBD8D9-A66F-47D2-AF63-A76A5D3770AE@delong.com> Message-ID: <20080324152853.GC45188@ussenterprise.ufp.org> In a message written on Sun, Mar 23, 2008 at 08:02:56AM +0900, Owen DeLong wrote: > > 2. Item 3 requires staff to share the results of an audit of an > > organization?s resources. Staff often reviews an organization?s > > transaction history and resources during fraud or suspicious activity > > investigations and feels that it is not always prudent to share those > > results. > > > While this may be true under some circumstances, the authors feel > that transparency is the overriding concern here. Further, the "results" > which must be shared are not intended to go beyond the level of > "a review was conducted and ARIN will be taking XYZ action > as a result." where XYZ would be one of "NO" or "further steps > to reclaim" or other appropriate phrase. > > We did not expect results to include detailed internal data about > the process or any privileged work product of any investigation. > > If staff feels that the current language does not achieve this intent, > the authors would welcome recommended language from staff > or any other source which achieves this stated intent. I'd like to echo Owen's statement. In this case we're talking about an existing resource holder; and while they may be a bad actor they are still a resource holder and deserve some information as to the result of the audit. Providing some feedback is really our only hope of having a bad actor realize the error of their ways and come back into the fold. That said, I don't think ARIN needs to identify methods and sources; full disclosure of why the conclusion was reached is not necessary. The current language to me allows ARIN staff to chart such a course, but obviously with the staff concern such a course is not clearly marked in this case. I urge staff and the author to find a way to update item 3 to remove this staff concern prior to the Denver meeting. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From info at arin.net Mon Mar 24 16:54:58 2008 From: info at arin.net (Member Services) Date: Mon, 24 Mar 2008 16:54:58 -0400 Subject: [ppml] ARIN XXI - Open Policy Hour Message-ID: <47E81522.3080107@arin.net> Questions about the Policy Process: 1. Do you want to know what policy proposals will be discussed at the upcoming ARIN Public Policy Meeting? 2. Do you have an idea about how ARIN should manage Internet Number Resources? 3. Do you think that a current policy should be enhanced or changed, or even retired? 4. Are you hesitant about making a formal proposal on the Public Policy Mail List (PPML)? 5. Are you new to the Policy Development Process? If you answered ?yes? to any of these questions, then you should attend the Open Policy Hour! Come and get a better understanding of what will be discussed during the upcoming Public Policy Meeting, or discuss and receive feedback on your ideas in an open, informal forum. The Open Policy Hour consists of two parts. Part One is the Policy Proposal Background Briefing. ARIN staff will provide an overview of the policy proposals on the meeting agenda. Members of the ARIN Advisory Council will be present to answer general questions about these proposals. The proposal content will not be discussed. This session offers general information on the nature of the proposals. Part Two is the Policy Proposal BoF. This is where you can "test drive" a policy idea. How can you participate? Bring your ideas and questions. If you have a policy suggestion, but would like to receive feedback prior to submitting it to the community on the PPML, here is your opportunity. Preference will be given to individuals with prepared short (3-minute) presentations. To sign up in advance please send an e-mail to policy at arin.net by 2 April 2008 with your name, organization, and a brief description of your policy subject. Walk-up presenters are also welcome. Join your colleagues for this informal session. The Open Policy Hour for ARIN XXI will be held on Sunday, 6 April, from 4:30 - 5:30 PM. If you are not familiar with the way policies are developed in the ARIN region, join ARIN staff a half hour earlier, at 4:00 PM, for a review of the Internet Resource Policy Evaluation Process. Registration and hotel information for ARIN XXI is available at: http://www.arin.net/ARIN-XXI/ Contact Member Services at info at arin.net if you have any questions. Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Tue Mar 25 10:11:03 2008 From: info at arin.net (Member Services) Date: Tue, 25 Mar 2008 10:11:03 -0400 Subject: [ppml] ARIN XXI: Check Out The Agenda! Message-ID: <47E907F7.4000903@arin.net> We look forward to your participation at the ARIN XXI Public Policy and Members Meeting, taking place 6-9 April 2008, in Denver, Colorado. The meeting will take place at the Grand Hyatt Denver. Hotel and travel information, meeting registration, and agenda details, are available through http://www.arin.net/ARIN-XXI/. In addition to ARIN policy proposal and member discussions, the meeting will also feature the following: Sunday, 6 April ? First Timer Luncheon ? The IPv6 Pre-Game Show (no registration required) ? A session entitled ?Understanding ARIN?s Legacy Registration Services Agreement? presented by ARIN General Counsel Steven Ryan. ? Introduction to the Internet Resource Policy Evaluation Process and Open Policy Hour ? The 9th Annual Foosball Tournament Monday, 7 April ? The ARIN XXI Social Event. More information is available at: http://www.arin.net/ARIN-XXI/social.html Tuesday, 8 April ? The IPv6 Main Event (no registration required) Select the events you plan to attend on your registration form. If you have already registered, but would like to modify your selections, click on the "Update Existing Registration" link available through http://www.arin.net/ARIN-XXI/. You can always contact ARIN Member Services at info at arin.net with any questions. We look forward to seeing you in Denver! Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Thu Mar 27 09:55:22 2008 From: info at arin.net (Member Services) Date: Thu, 27 Mar 2008 09:55:22 -0400 Subject: [ppml] NRPM version 2008.2 - New Policy Implementation Message-ID: <47EBA74A.1020505@arin.net> On 10 March 2008, the ARIN Board of Trustees, acting on the recommendation of the Advisory Council and noting that the Internet Resource Policy Evaluation Process had been followed, adopted the following policy proposal: Policy Proposal 2007-22: Expand timeframe of Additional Requests This policy proposal has been incorporated into version 2008.2 of the ARIN Number Resource Policy Manual (NRPM). The Board also voted to remove the Mailing Lists section from the NRPM (Section 9). This section described the acceptable use policies of ARIN mail lists. The section was an artifact of the creation of the NRPM and was not number resource policy. NRPM version 2008.2 is effective 27 March 2008 and supersedes previous versions. See Appendix A of the NRPM for information regarding changes to the manual. The NRPM can be found at: http://www.arin.net/policy/nrpm.html Appendix A can be found at: http://www.arin.net/policy/nrpm_changelog.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Thu Mar 27 10:31:26 2008 From: info at arin.net (Member Services) Date: Thu, 27 Mar 2008 10:31:26 -0400 Subject: [ppml] New ARIN Mailing List Acceptable Use Policy Message-ID: <47EBAFBE.3000803@arin.net> This message is being sent to all ARIN mailing lists. If you are subscribed to more than one ARIN managed mailing list, you will receive multiple copies of this announcement. At its 10 March meeting, the ARIN Board of Trustees adopted a new Mailing List Acceptable Use Policy (AUP) for all ARIN public mailing lists. The AUP sets forth general guidelines of acceptable list conduct and calls out a number of specifically prohibited activities. A section on reporting violations and enforcement is included, along with procedures on how both are to be accomplished. The full text is available on the ARIN website as a link off the main mailing list page at: http://www.arin.net/mailing_lists/aup.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Thu Mar 27 14:45:07 2008 From: info at arin.net (Member Services) Date: Thu, 27 Mar 2008 14:45:07 -0400 Subject: [ppml] Policy Proposal 2008-3 - Staff Assessment Message-ID: <47EBEB33.2060601@arin.net> Policy Proposal 2008-3 Title: Community Networks IPv6 Allocation Proposal Submitted: March 4, 2008 Date of Assessment: March 27, 2008 ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2008_3.html II. Understanding of the proposal ARIN staff understands this policy would provide IPv6 addresses to any organization considered to be a community network. III. Issues and concerns A. ARIN Staff Comments This proposal defines a ?community network? which is a new term in the ARIN region. The community should take a close look at this definition to explore whether its rather broad definition might make it subject to abuse or exploitation by people who may not otherwise qualify for IPv6 address space. This proposal does not state a minimum number of actual or planned customers for the community network. Staff recommends that a minimum number of customers be specified to help determine qualification. There is no minimum allocation size specified in this policy. Staff recommends that a minimum allocation size be specified. In addition, staff recommends that criteria for requests larger than the minimum allocation size and for requests for additional allocations be specified. Staff believes that a community network does not fit either LIR or end-user descriptions exactly and therefore recommends that this policy be inserted into NRPM as section 6.5.9 B. ARIN General Counsel Counsel sees no significant legal or litigation risk regarding this policy. IV. Resource Impact - Moderate The resource impact of implementing this policy is moderate. Barring any unforeseen resource requirements, this policy could be implemented within 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - New template - Registration software changes - New set of guidelines - Staff training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2008-3 Community Networks IPv6 Allocation Author: Joshua King Proposal Version: 1 Date: 4 March 2008 Proposal type: new Policy term: permanent Policy statement: [Add Section 2.8 to the NRPM.] 2.8 Community Network A community network is a generic reference to any network that is operated by a group of people living in a particular local area organized for the purposes of delivery or provision of network services to the residents of an incorporated or unincorporated regional municipality, city, town, village, rural municipality, township, county, district or other municipality or other such geographic space, however designated. [Modify 6.5.8.1b as follows.] b. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect or be a Community Network as defined in Section 2.8. Rationale: There are currently a number of projects globally that aim to develop community network infrastructure and related technologies. These are usually coordinated by volunteer-run, grassroots organizations which lack many of the resources of traditional internet service providers and other network operators. They have diverse goals, including public policy, software development, and implementation of community services and resources. Many of them provide services free of charge, and thus lack any paying user base. However, in order to create and maintain community networks that are often composed of hundreds if not thousands of inexpensive, commodity hosts and devices, a significant amount of address space will be required. Current-generation workarounds to this problem, such as NAT, not only make it difficult to develop next-generation decentralized network technology by segmenting the community's architecture from the Internet as a whole, but will cease to be as viable a stopgap as the Internet moves towards IPv6 integration. Even now, common community networking software solutions such as CUWiNware (http://www.cuwin.net) and Freifunk (http://www.freifunk.at) have nascent IPv6 addressing support, but participating organizations lack the address space for widespread testing or adoption. As such, it is necessary to implement an procedure as soon as possible for these segregated networks to acquire address space. These organizations do not meet the criteria traditionally defined for LIR's, and thus cannot acquire address allocations through existing templates. By establishing a procedure by which these organizations can seek to acquire the resources they require for further development, ARIN can reach out to this active community and establish a small but definite space for them in the future of Internet. Timetable for implementation: Immediate. From owen at delong.com Thu Mar 27 18:17:45 2008 From: owen at delong.com (Owen DeLong) Date: Fri, 28 Mar 2008 07:17:45 +0900 Subject: [ppml] Revision to 2007-17 Message-ID: <0A63064A-3AEA-4A0D-BD77-ED16D08E0E75@delong.com> The following revised version of 2007-17 is submitted for consideration. The amendments are being made to address concerns expressed by staff in the "staff assessment" of the policy proposal. I ran these changes by staff prior to submitting them here. The changes do address the concerns expressed by staff, but, staff may wish to revise their "impact" statement. Beyond this statement, I'll leave it to staff to comment further if they wish. Apologies for the late date on this amendment. Look forward to upcoming changes to the IRPEP to improve this situation. Owen Modifications: Extended 4.6.1 to allow ARIN to reject transactions of no benefit to the community. (Hopefully this closes most of the abuse loopholes) Renumbered 4.6.6 to 4.6.7 Annual contact required Renumbered 4.6.5 to 4.6.6 RSA Required if new addresses received Inserted new 4.6.5 to spell out requirement for ARIN to work with resource holders to specify a return timeframe in contract. Added text to rationale to clarify overriding intent and Policy Proposal 2007-17 Legacy Outreach and Partial Reclamation Author: Owen DeLong Date: 21 February 2008 Proposal type: modify Policy term: permanent Policy statement: Replace section 4.6 as follows: 4.6 Amnesty and Aggregation requests 4.6.1 Intent of this policy This policy is intended to allow the community and ARIN staff to work together with holders of address resources in the best interests of the community by facilitating the return of unused address space and the aggregation of existing space in a manner which is in the best interests of both parties. All transactions under this policy must either create greater aggregation (a reduction in the number of prefixes) or the return of address space. ARIN should reject any transaction which staff judges is not in the interests of the community. 4.6.2 No penalty for returning or aggregating ARIN shall seek to make the return of address space as convenient and risk-free to the returning organization as possible. An organization with several non-contiguous blocks seeking to aggregate and return space at the same time should be accommodated if possible. If it is possible to expand one block, for example, to facilitate the return of other blocks, ARIN should do th.6.3 Return should not force renumbering An organization shall be allowed to return a partial block of any size to ARIN. For any return greater than a /24, ARIN shall not require that the non-returned portion of the block be renumbered unless the returning organization wishes to do so. 4.6.4 Incentives The Board of Trustees should consider creating incentives for organizations to return addresses under this policy. 4.6.5 Timeframe for return Any organization which is returning addresses under this policy shall negotiate with ARIN an appropriate timeframe in which to return the addresses after any new resources are received under this policy. In the case of a simple return, the timeframe shall be immediate. In the case where renumbering into new addresses out of existing addresses to be returned is required, the returning organization shall sign a contract with ARIN which stipulates a final return date not less than 6 months nor more than 18 months after the receipt of new addresses. If an organization misses this return date, but, ARIN believes the organization is working in good faith to complete the renumbering, ARIN may grant a single extension of 6-12 months as staff deems appropriate to the situation. Such an extension must be requested in writing (email to hostmaster at arin.net) by the organization at least 15 days prior to the original expiration date. 4.6.6 RSA Required if new addresses received Any organization which receives any additional addresses under this policy shall be required to sign an ARIN RSA which will apply to all new addresses issued and to any retained blocks which are expanded under this policy. 4.6.7 Annual contact required Any organization which participates in this policy shall be required to sign an agreement stipulating that ARIN will attempt contact at least once per year via the contact mechanisms registered for the organization in whois. Should ARIN fail to make contact, after reasonable effort the organization shall be flagged as "unreachable" in whois. After six months in "unreachable" status, the organization agrees that ARIN may consider all resources held by the organization to be abandoned and reclaim such resources. Should the organization make contact with ARIN prior to the end of the aforementioned six month period and update their contact information appropriately, ARIN shall remove the "unreachable" status and the annual contact cycle shall continue as normal. If the organization pays annual fees to ARIN, the payment of annual fees shall be considered sufficient contact. Rationale: Existing policy supports aggregation (4.7) and provides some amnesty (existing 4.6) for returning blocks. However, a number of resource holders have expressed discomfort with the current section 4.6 believing that they will be forced to return their entire address space and renumber rather than being able to make partial returns and retain some of their existing space. This policy seeks to eliminate those concerns and make the return of unused address space more desirable to the resource holders. A very high percentage of underutilized space is in the hands of legacy holders who currently have no benefit to joining the ARIN process and no way to return any portion of their address space without incurring significant disadvantage as a result. A suggestion to the board would be to adopt benefits along the following lines for people returning space. These benefits would provide additional incentive for resource holders to make appropriate returns and for legacy holders to join the ARIN process: 1. If the organization does not currently pay ARIN fees, they shall remain fee exempt. 2. If the organization currently pays ARIN fees, their fees shall be waived for two years for each /20 returned, with any fractional /20 resulting in a one-time single year waiver. 3. Any organization returning address space under this policy shall continue under their existing RSA or they may choose to sign the current RSA. For organizations which currently do not have an RSA, they may sign the current RSA, or, they may choose to remain without an RSA. 4. All organizations returning space under this policy shall, if they meet other eligibility requirements and so request, obtain an appropriate IPv6 end-user assignment or ISP allocation as applicable, with no fees for the first 5 years. Organizations electing to receive IPv6 allocation/assignment under this provision must sign a current RSA and must agree that their IPv4 resources are henceforth subject to the RSA. The overriding intent of this policy proposal is to make it as easy as possible for both ARIN and resource holders to "do the right thing" with regard to excess resources or dis-aggregated (fragmented) address blocks. It is the desire of the author that staff make any judgment calls necessary under this policy with that ideal clearly in mind. While the author has made a concerted effort to make the policy as clear as possible and as concrete as can be, the reality is that these types of transactions must rely heavily on the judgment and expertise of the ARIN staff in determining what is in the best interests of the community. Timetable for implementation: Immediate -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Fri Mar 28 11:16:50 2008 From: info at arin.net (Member Services) Date: Fri, 28 Mar 2008 11:16:50 -0400 Subject: [ppml] Revision to 2007-17 In-Reply-To: <0A63064A-3AEA-4A0D-BD77-ED16D08E0E75@delong.com> References: <0A63064A-3AEA-4A0D-BD77-ED16D08E0E75@delong.com> Message-ID: <47ED0BE2.7070204@arin.net> Policy Proposal 2007-17, Legacy Outreach and Partial Reclamation, has been revised. This proposal is open for discussion on this mailing list and will be on the agenda at the upcoming ARIN Public Policy Meeting. The current policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_17.html Regards, Member Services American Registry for Internet Numbers (ARIN) Owen DeLong wrote: > > The following revised version of 2007-17 is submitted for consideration. > The amendments are being made to address concerns expressed by staff > in the "staff assessment" of the policy proposal. > > I ran these changes by staff prior to submitting them here. The changes > do address the concerns expressed by staff, but, staff may wish to revise > their "impact" statement. Beyond this statement, I'll leave it to staff > to comment further if they wish. > > Apologies for the late date on this amendment. Look forward to upcoming > changes to the IRPEP to improve this situation. > > Owen > > > Modifications: > > Extended 4.6.1 to allow ARIN to reject transactions of no benefit > to the community. (Hopefully this closes most of the abuse loopholes) > > Renumbered 4.6.6 to 4.6.7 Annual contact required > > Renumbered 4.6.5 to 4.6.6 RSA Required if new addresses received > > Inserted new 4.6.5 to spell out requirement for ARIN to work with > resource holders to specify a return timeframe in contract. > > Added text to rationale to clarify overriding intent and > > Policy Proposal 2007-17 > Legacy Outreach and Partial Reclamation > > Author: Owen DeLong > > Date: 21 February 2008 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Replace section 4.6 as follows: > > 4.6 Amnesty and Aggregation requests > > 4.6.1 Intent of this policy > > This policy is intended to allow the community and ARIN staff to work > together with holders of address resources in the best interests of > the community by facilitating the return of unused address space and > the aggregation of existing space in a manner which is in the best > interests of both parties. > > All transactions under this policy must either create greater > aggregation (a reduction in the number of prefixes) or the return of > address space. ARIN should reject any transaction which staff judges > is not in the interests of the community. > > 4.6.2 No penalty for returning or aggregating > > ARIN shall seek to make the return of address space as convenient and > risk-free to the returning organization as possible. An organization > with several non-contiguous blocks seeking to aggregate and return > space at the same time should be accommodated if possible. If it is > possible to expand one block, for example, to facilitate the return of > other blocks, ARIN should do th.6.3 Return should not force renumbering > > An organization shall be allowed to return a partial block of any size > to ARIN. For any return greater than a /24, ARIN shall not require > that the non-returned portion of the block be renumbered unless the > returning organization wishes to do so. > > 4.6.4 Incentives > > The Board of Trustees should consider creating incentives for > organizations to return addresses under this policy. > > 4.6.5 Timeframe for return > > Any organization which is returning addresses under this policy shall > negotiate with ARIN an appropriate timeframe in which to return the > addresses after any new resources are received under this policy. In > the case of a simple return, the timeframe shall be immediate. In the > case where renumbering into new addresses out of existing addresses to > be returned is required, the returning organization shall sign a > contract with ARIN which stipulates a final return date not less than > 6 months nor more than 18 months after the receipt of new addresses. > If an organization misses this return date, but, ARIN believes the > organization is working in good faith to complete the renumbering, > ARIN may grant a single extension of 6-12 months as staff deems > appropriate to the situation. Such an extension must be requested in > writing (email to hostmaster at arin.net ) by > the organization at least 15 > days prior to the original expiration date. > > 4.6.6 RSA Required if new addresses received > > Any organization which receives any additional addresses under this > policy shall be required to sign an ARIN RSA which will apply to all > new addresses issued and to any retained blocks which are expanded > under this policy. > > 4.6.7 Annual contact required > > Any organization which participates in this policy shall be required > to sign an agreement stipulating that ARIN will attempt contact at > least once per year via the contact mechanisms registered for the > organization in whois. Should ARIN fail to make contact, after > reasonable effort the organization shall be flagged as "unreachable" > in whois. After six months in "unreachable" status, the organization > agrees that ARIN may consider all resources held by the organization > to be abandoned and reclaim such resources. Should the organization > make contact with ARIN prior to the end of the aforementioned six > month period and update their contact information appropriately, ARIN > shall remove the "unreachable" status and the annual contact cycle > shall continue as normal. If the organization pays annual fees to > ARIN, the payment of annual fees shall be considered sufficient contact. > > Rationale: > > Existing policy supports aggregation (4.7) and provides some amnesty > (existing 4.6) for returning blocks. However, a number of resource > holders have expressed discomfort with the current section 4.6 > believing that they will be forced to return their entire address > space and renumber rather than being able to make partial returns and > retain some of their existing space. > > This policy seeks to eliminate those concerns and make the return of > unused address space more desirable to the resource holders. > > A very high percentage of underutilized space is in the hands of > legacy holders who currently have no benefit to joining the ARIN > process and no way to return any portion of their address space > without incurring significant disadvantage as a result. > > A suggestion to the board would be to adopt benefits along the > following lines for people returning space. These benefits would > provide additional incentive for resource holders to make appropriate > returns and for legacy holders to join the ARIN process: > > 1. If the organization does not currently pay ARIN fees, they shall > remain fee exempt. > > 2. If the organization currently pays ARIN fees, their fees shall be > waived for two years for each /20 returned, with any fractional /20 > resulting in a one-time single year waiver. > > 3. Any organization returning address space under this policy shall > continue under their existing RSA or they may choose to sign the > current RSA. For organizations which currently do not have an RSA, > they may sign the current RSA, or, they may choose to remain without > an RSA. > > 4. All organizations returning space under this policy shall, if they > meet other eligibility requirements and so request, obtain an > appropriate IPv6 end-user assignment or ISP allocation as applicable, > with no fees for the first 5 years. Organizations electing to receive > IPv6 allocation/assignment under this provision must sign a current > RSA and must agree that their IPv4 resources are henceforth subject to > the RSA. > > The overriding intent of this policy proposal is to make it as easy as > possible for both ARIN and resource holders to "do the right thing" > with regard to excess resources or dis-aggregated (fragmented) address > blocks. It is the desire of the author that staff make any judgment > calls necessary under this policy with that ideal clearly in mind. > While the author has made a concerted effort to make the policy as > clear as possible and > as concrete as can be, the reality is that these types of transactions > must rely heavily on the judgment and expertise of the ARIN staff in > determining what is in the best interests of the community. > > > Timetable for implementation: Immediate > > > ------------------------------------------------------------------------ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From info at arin.net Mon Mar 31 09:28:23 2008 From: info at arin.net (Member Services) Date: Mon, 31 Mar 2008 09:28:23 -0400 Subject: [ppml] Reminder: ARIN XXI Open Policy Hour and Remote Participation Message-ID: <47F0E6F7.1060108@arin.net> Sign up today to present your ideas at the ARIN XXI Open Policy Hour, Sunday, 6 April, from 4:30-5:30 PM (MDT). The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you?d like to debut, prior to formally submitting it, here is your opportunity. Sign up by Wednesday, 2 April to ensure your chance to take the microphone. Send an e-mail to policy at arin.net with your name, organization, and a general description of the policy subject you wish to present. Everyone is invited to attend the session and raise ideas and suggestions. You do not need to have a formal presentation in order to participate. Signing up in advance allows us to confirm your turn to present your policy idea. Information on this and other sessions is available at: http://www.arin.net/ARIN-XXI/agenda.html For the first time ever, the OPH will be available as part of our live meeting webcast and remote participants may submit comments and questions. To register for remote participation, click the ?Meeting Registration? button available at http://www.arin.net/ARIN-XXI/ and choose "ARIN XXI Remote Participant" from the drop-down. Registration is not required to view the webcast. Comments received from remote participants will be moderated and presented during normal question and answer periods. ARIN will use e-mail to provide the interactive portion of the remote participation effort. All remote participants are subject to the Remote Participation Acceptable Use Policy (AUP). Additional information about remote participation, including the Remote Participation AUP, is available at: http://www.arin.net/ARIN-XXI/webcast.html We look forward to your participation in ARIN XXI. Meeting details are available at http://www.arin.net/ARIN-XXI/. Please contact Member Services at info at arin.net if you have any questions. Regards, Member Services Department American Registry for Internet Numbers (ARIN) From info at arin.net Mon Mar 31 11:59:01 2008 From: info at arin.net (Member Services) Date: Mon, 31 Mar 2008 11:59:01 -0400 Subject: [ppml] Poll - Transfer Policy Message-ID: <47F10A45.70001@arin.net> The ARIN Advisory Council is conducting a poll. The poll contains five questions. You will receive five e-mails, one question per message. Every e-mail address subscribed to the Public Policy Mailing List (PPML) will be e-mailed individually with instructions on how to participate in the poll. If an alias is subscribed to the PPML that is then distributed to several individuals, only the first opinion registered will be counted. Only those who are already subscribed when the poll starts may participate. The poll ends at noon EDT on Thursday, 3 April 2008. The results will be sent to PPML. Regards, Member Services American Registry for Internet Numbers (ARIN) From josh at acornactivemedia.com Mon Mar 31 17:57:36 2008 From: josh at acornactivemedia.com (Josh King) Date: Mon, 31 Mar 2008 16:57:36 -0500 Subject: [ppml] Revision to 2008-3 Message-ID: <47F15E50.9020005@acornactivemedia.com> Hello, Here's a revision of the 2008-3 policy proposal based upon the staff recommendations. Sorry for the extreme lateness, I did not receive the staff recommendations until yesterday due to problems with my email. I've attempted to address the concerns expressed by staff, but some points I've expressed may require further clarification, and I look forward to further staff comments. Changes: Added section 6.5.9 as per recommendation, listing allocation and user requirements for Community Networks allocations. Largely based upon 6.5.8.2 and .3, with revisions to attempt to reflect the fact that a Community Network is neither an end-user or LIR. Modified section 6.5.8.1b to refer to section 6.5.9. -- Policy Proposal 2008-3 Community Networks IPv6 Allocation Author: Joshua King Proposal Version: 1 Date: 4 March 2008 Proposal type: new Policy term: permanent Policy statement: [Add Section 2.8 to the NRPM.] 2.8 Community Network A community network is a generic reference to any network that is operated by a group of people living in a particular local area organized for the purposes of delivery or provision of network services to the residents of an incorporated or unincorporated regional municipality, city, town, village, rural municipality, township, county, district or other municipality or other such geographic space, however designated. [Modify 6.5.8.1b as follows.] b. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect or be a Community Network as defined in Section 2.8, with allocation criteria defined in section 6.5.9. [Add Section 6.5.9 to the NRPM.] 6.5.9 Community Network Allocations 6.5.9.1. Initial assignment size Organizations defined as Community Networks under section 2.8 are eligible to receive a direct assignment. The minimum size of the assignment is /48. Organizations requesting a larger assignment must provide documentation of the characteristics of the Community Network's size and architecture that require the use of additional subnets. An HD-Ratio of .94 with respect to subnet utilization within the network must be met for all assignments larger than a /48. These assignments shall be made from a distinctly identified prefix and shall be made with a reservation for growth of at least a /44. This reservation may be assigned to other organizations later, at ARIN's discretion. 6.5.9.2. Subsequent assignment size Additional assignments may be made when the need for additional subnets is justified. Justification will be determined based on a detailed plan of the network's architecture and the .94 HD-Ratio metric. When possible, assignments will be made from an adjacent address block. 6.5.9.3. Number of customers Community Networks seeking an allocation must demonstrate that they provide for a user base of at least 100 through connectivity to homes and businesses, public facilities, public access points, or mobile users. Community Networks with user bases of under 200 must also submit a plan for doubling their service base over the next year. Rationale: There are currently a number of projects globally that aim to develop community network infrastructure and related technologies. These are usually coordinated by volunteer-run, grassroots organizations which lack many of the resources of traditional internet service providers and other network operators. They have diverse goals, including public policy, software development, and implementation of community services and resources. Many of them provide services free of charge, and thus lack any paying user base. However, in order to create and maintain community networks that are often composed of hundreds if not thousands of inexpensive, commodity hosts and devices, a significant amount of address space will be required. Current-generation workarounds to this problem, such as NAT, not only make it difficult to develop next-generation decentralized network technology by segmenting the community's architecture from the Internet as a whole, but will cease to be as viable a stopgap as the Internet moves towards IPv6 integration. Even now, common community networking software solutions such as CUWiNware (http://www.cuwin.net) and Freifunk (http://www.freifunk.at) have nascent IPv6 addressing support, but participating organizations lack the address space for widespread testing or adoption. As such, it is necessary to implement an procedure as soon as possible for these segregated networks to acquire address space. These organizations do not meet the criteria traditionally defined for LIR's, and thus cannot acquire address allocations through existing templates. By establishing a procedure by which these organizations can seek to acquire the resources they require for further development, ARIN can reach out to this active community and establish a small but definite space for them in the future of Internet. Timetable for implementation: Immediate. Josh King -- josh at acornactivemedia.com -- Senior Network Engineer, Acorn Active Media (http://www.acornactivemedia.com) System Administrator, Chambana.net (http://www.chambana.net) -- "I am an Anarchist not because I believe Anarchism is the final goal, but because there is no such thing as a final goal." -Rudolf Rocker -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From farmer at umn.edu Mon Mar 31 20:06:23 2008 From: farmer at umn.edu (David Farmer) Date: Mon, 31 Mar 2008 19:06:23 -0500 Subject: [ppml] Revision to 2008-3 In-Reply-To: <47F15E50.9020005@acornactivemedia.com> References: <47F15E50.9020005@acornactivemedia.com> Message-ID: <47F1362F.13833.F8CD14B@farmer.umn.edu> On 31 Mar 2008 Josh King wrote: > Changes: > Added section 6.5.9 as per recommendation, listing allocation and user > requirements for Community Networks allocations. Largely based upon > 6.5.8.2 and .3, with revisions to attempt to reflect the fact that a > Community Network is neither an end-user or LIR. If they are neither an end-uesr or an LIR, then what are they? I guess I'm not clear if a Community Network will be assigning address space to end-users of the Community Network or if the Community Network will be responsible for abuse etc for the end-users? How do you see that working? Also I've been thinking about Community Networks in general. Should their be a non-profit, not-for-profit, or government sponsorship requirement, or a restriction from providing commercial services on a Community Network. If a Community Network is allowed to be a commercial entity and/or provide commercial services then in what way is it different from any other ISP? If a Community Network is an ISP then it should have to play by the rules of an ISP. If a Community Network is not an ISP, then it needs to be clear how it is different from an ISP, and simply giving it another name doesn't make it different. I personally don't have an opinion, if a Community Network should be simply consider an ISP or if they are really something different, but with the current definition it is not clear to me what the difference is. Is there some kind of association of Community Networks, that has defined what a Community Network is? Could they help? ================================================= David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 ================================================= From steven.feldman at cnet.com Mon Mar 31 20:32:05 2008 From: steven.feldman at cnet.com (Steve Feldman) Date: Mon, 31 Mar 2008 17:32:05 -0700 Subject: [ppml] Revision to 2008-3 In-Reply-To: <47F15E50.9020005@acornactivemedia.com> References: <47F15E50.9020005@acornactivemedia.com> Message-ID: <519DC8EB-A13C-4AFF-A988-20D0426744FA@cnet.com> > > 2.8 Community Network > > A community network is a generic reference to any network that is > operated by a group of people living in a particular local area > organized for the purposes of delivery or provision of network > services > to the residents of an incorporated or unincorporated regional > municipality, city, town, village, rural municipality, township, > county, > district or other municipality or other such geographic space, however > designated. I'm not entirely comfortable with this definition. First, what if I want to donate my help operating a network in some other community? Would that disqualify them? Second, I think there does have to be some notion of not-for-profit, or some other way to prevent a community network from competing with regular ISPs using a more favorable set of rules. Also, I'd like to see more explanation of why the current rules for LIRs and end users either don't apply or are unworkable for community networks. I do think the idea has some merit, but I can't support this proposal it in its current form. Steve From sleibrand at internap.com Mon Mar 31 22:05:30 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 31 Mar 2008 19:05:30 -0700 Subject: [ppml] Revision to 2008-3 In-Reply-To: <519DC8EB-A13C-4AFF-A988-20D0426744FA@cnet.com> References: <47F15E50.9020005@acornactivemedia.com> <519DC8EB-A13C-4AFF-A988-20D0426744FA@cnet.com> Message-ID: <47F1986A.8010302@internap.com> So under existing policy and with the revised proposal: - LIRs (any network with a plan to assign space to 200 customers) can get a /32. - End users (any multihomed network with ~1000 devices) can get a /48. - Community networks (locally-operated networks providing service to local residents, with 100 customers and a plan to grow to 200 customers) can get a /48. Under my reading of 6.5.1.1, a community network meeting the criteria of this policy proposal would probably also meet the criteria for getting an LIR /32. Likewise, any local/regional ISP could probably qualify as a community network if they chose. I think the main difference between LIRs and Community networks is the distinction between an allocation and an assignment. Per 6.5.1.2, LIRs get an allocation. By definition and by policy, that means that they are expected to reassign address space to end users, updating whois with SWIPs or running an rwhois server as appropriate. By contrast, Community networks under this policy would get an assignment. Assignments cannot be reallocated to downstreams, so no SWIP updates or rwhois server would be necessary, and the community network would be the only point of contact for all issues with their /48. It seems to me that the policy, as revised, does a good job of creating a level playing field while also allowing local/regional networks to qualify for and receive, if they choose, a smaller allocation and reduced set of services more appropriate to their needs. Based on this reduced set of services, I suspect that anyone choosing to qualify for space as a Community network would be charged a fee closer to that of an End User, rather than the higher fee charged to LIRs for the larger set of reallocation/reassignment services provided. In summary, I can now fully support 2008-3. -Scott Steve Feldman wrote: >> 2.8 Community Network >> >> A community network is a generic reference to any network that is >> operated by a group of people living in a particular local area >> organized for the purposes of delivery or provision of network >> services >> to the residents of an incorporated or unincorporated regional >> municipality, city, town, village, rural municipality, township, >> county, >> district or other municipality or other such geographic space, however >> designated. > > I'm not entirely comfortable with this definition. > > First, what if I want to donate my help operating a network in some > other community? Would that disqualify them? > > Second, I think there does have to be some notion of not-for-profit, > or some other way to prevent a community network from competing with > regular ISPs using a more favorable set of rules. > > Also, I'd like to see more explanation of why the current rules for > LIRs and end users either don't apply or are unworkable for community > networks. > > I do think the idea has some merit, but I can't support this proposal > it in its current form. > Steve > > _______________________________________________ > 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 mpetach at netflight.com Mon Mar 31 22:37:00 2008 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 31 Mar 2008 19:37:00 -0700 Subject: [ppml] Revision to 2008-3 In-Reply-To: <519DC8EB-A13C-4AFF-A988-20D0426744FA@cnet.com> References: <47F15E50.9020005@acornactivemedia.com> <519DC8EB-A13C-4AFF-A988-20D0426744FA@cnet.com> Message-ID: <63ac96a50803311937t30bdbb1cga34fb38fd50db545@mail.gmail.com> On 3/31/08, Steve Feldman wrote: > > 2.8 Community Network > > > > A community network is a generic reference to any network that is > > operated by a group of people living in a particular local area > > organized for the purposes of delivery or provision of network > > services > > to the residents of an incorporated or unincorporated regional > > municipality, city, town, village, rural municipality, township, > > county, > > district or other municipality or other such geographic space, however > > designated. > > I'm not entirely comfortable with this definition. > > First, what if I want to donate my help operating a network in some > other community? Would that disqualify them? > > Second, I think there does have to be some notion of not-for-profit, > or some other way to prevent a community network from competing with > regular ISPs using a more favorable set of rules. > > Also, I'd like to see more explanation of why the current rules for > LIRs and end users either don't apply or are unworkable for community > networks. > > I do think the idea has some merit, but I can't support this proposal > it in its current form. > > Steve I'd likewise like to indicate my non-support for the current proposal as I think the definition of a "community network" is too easily abused. Any individual can claim to represent a "community network" simply by having a WiFi access point in their house that their neighbor sometimes hops on. if we can clarify that a community network must meet all of the following requirements to quality: a) be a recognized not-for-profit entity b) consist of multiple people organized together to provide no-fee, free network access within a well-defined, network-contiguous region (such that there will be no deaggregation of the announcement across multiple non-connected egress points) c) have a documented plan to provide the aforementioned free service to at least N sites (can't really say "customers" since we're forcing them to be not-for-profit). My temptation is to set 'N' below the LIR threshold--we're not talking about organizations that will rival the local ISP for the most part, so I'd suggest 50 as a reasonable starting number. For me, the not-for-profit portion is crucial--otherwise, they're either an ISP/LIR, or an enterprise/end user network, and should apply under those rules. Also, the 'more than one person, more than one "customer"' portion is pretty key; setting up your wireless access point so that your neighbor can use it shouldn't allow you to qualify as a "community network"; in my book, you're still an end user. If we can address those concerns, I think I'd be able to consider supporting it; but without some clear rules on what a "community network" is, I think this policy would be too wide open for abuse. Matt From sleibrand at internap.com Mon Mar 31 22:57:24 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 31 Mar 2008 19:57:24 -0700 Subject: [ppml] Revision to 2008-3 In-Reply-To: <63ac96a50803311937t30bdbb1cga34fb38fd50db545@mail.gmail.com> References: <47F15E50.9020005@acornactivemedia.com> <519DC8EB-A13C-4AFF-A988-20D0426744FA@cnet.com> <63ac96a50803311937t30bdbb1cga34fb38fd50db545@mail.gmail.com> Message-ID: <47F1A494.9070607@internap.com> Matthew Petach wrote: > I'd likewise like to indicate my non-support for the current proposal > as I think the definition of a "community network" is too easily > abused. Any individual can claim to represent a "community network" > simply by having a WiFi access point in their house that their neighbor > sometimes hops on. Did you notice the proposal's section 6.5.9.3. Number of customers, which requires a user base of at least 100, with plans to grow to 200? Does that address your "more than one person" concern? > if we can clarify that a community network must meet all of the > following requirements to quality: > a) be a recognized not-for-profit entity > b) consist of multiple people organized together to provide no-fee, > free network access within a well-defined, network-contiguous > region (such that there will be no deaggregation of the > announcement across multiple non-connected egress points) > c) have a documented plan to provide the aforementioned free service > to at least N sites (can't really say "customers" since we're > forcing them to be not-for-profit). My temptation is to set 'N' > below the LIR threshold--we're not talking about organizations > that will rival the local ISP for the most part, so I'd suggest 50 > as a reasonable starting number. Do you really want ARIN micro-managing not-for-profit entities' business models by preventing them from charging for service, even on a cost recovery basis? > For me, the not-for-profit portion is crucial--otherwise, they're > either an ISP/LIR, or an enterprise/end user network, and > should apply under those rules. Also, the 'more than one > person, more than one "customer"' portion is pretty key; > setting up your wireless access point so that your neighbor > can use it shouldn't allow you to qualify as a "community > network"; in my book, you're still an end user. > > If we can address those concerns, I think I'd be able to > consider supporting it; but without some clear rules on > what a "community network" is, I think this policy > would be too wide open for abuse. I'm agnostic as to whether we should require not-for-profit status. It seems to me that any for-profit ISP with any ambition wouldn't want a non-reassignable /48 if they could just as easily qualify for an LIR /32, so I think the process will allow everyone to self-select the appropriate category. And as long as a community network needs plans for 200 customers just like an LIR does, it doesn't seem to change the threshold for potential abuse. -Scott