From dean at av8.com Fri Feb 1 18:17:03 2008 From: dean at av8.com (Dean Anderson) Date: Fri, 1 Feb 2008 18:17:03 -0500 (EST) Subject: [ppml] /29 limit for ARIN SWIP whois (fwd) Message-ID: ---------- Forwarded message ---------- Date: Sun, 13 Jan 2008 23:28:40 -0500 (EST) From: Dean Anderson To: Subject: Re: [ppml] ***POSSIBLE SPAM*** Re: /29 limit for ARIN SWIP whois On Sun, 13 Jan 2008, xxx wrote: > Dean Anderson wrote: > > > BTW, Legacy block's don't have to comply with the RSA. "No SWIP" is just > > one of the many rights that one loses under the Legacy RSA. Don't sign > > the Legacy RSA. Contact me, instead. > > It's too late for my organization (xxx), as we've already signed the > Legacy RSA. We were concerned about losing control over our Class x > address space if we didn't, It may not be too late. But spread the word not to sign the Legacy RSA. The agreement is probably too unfair to enforce. You should contact your lawyer immediately though. Your reasoning (fear of losing control) indicates that you may have been extorted into signing an unfavorable agreement improperly transferring your property rights to ARIN. This probably a violation of the Hobbs Act. See this page on the Hobbs Act: 2403 Hobbs Act -- Extortion By Force, Violence, or Fear http://www.usdoj.gov/usao/eousa/foia_reading_room/usam/title9/crm02403.htm The defense of 'right' is prevented by the previous performance by ARIN, Network Solutions, and SRI (DDN-NIC) of in-addr services and whois services. ARIN was also asked by ARIN members to get a formal legal opinion on its right before taking applications or contracts, but ARIN refused to do so. ARIN has no reason to think its actions are lawful. It seems that ARIN has no right to induce such fear, and no right to transfer rights under such circumstances. The case Kremen v. Cohen [337 F.3d 1024; (2003) See also http://www.nyls.edu/pages/1806.asp] established that domain names are intangible property subject to conversion. By the same reasoning, IP blocks are similarly intangible property. There's more though. Also, In Kremen v. Cohen, Kremen asserted Network Solutions violated a third party beneficial contract with the Government. They lost on that claim. There are stricter standards to meet in order for finding that the government (as opposed to private parties) created a third party beneficial contract. ARIN, by contrast with Network Solutions, took over operations from ICANN (a private corporation operating IANA). ICANN is not a government agency, so finding that ARIN has a third party beneficial contract with ICANN is easier than the case with Network Solutions, which took over from the government. > and the legacy terms seem pretty reasonable to me. However, I'd be > interested in learning why you think it's not a good idea. I think you didn't read the contract closely, and didn't know what your legacy rights were to begin with. Here are some few highlights: 1. The Legacy RSA (LRSA) gives ARIN the right to remove the Class B from you. They didn't have that privilege before. 2. ARIN can demand information on your customers. They didn't have that right before. 3. "If Legacy Applicant does not provide ARIN with required information, assistance, or cooperation that ARIN requests, ARIN may [not give you more space or may terminate the agreement and keep the class B (see Section 14(e) termination for cause by ARIN--arin gets the number resources.)] 4. You "agree" that there are no property rights in IP Blocks. You didn't have that before the agreement; you had property rights in intangible property. 5. Section 15(i): "This Legacy Agreement will be construed as if it was jointly drafted by both parties and may not be construed against either one" Basically, you "agree" not to challenge the agreement as unfair. [I think this provision demonstrates unfairness, actually.] It goes on and on. ARIN had no rights over Legacy space before. Instead, ARIN had obligations that it undertook to obtain the privileges of operating the registry. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From maier1 at us.ibm.com Fri Feb 1 19:03:38 2008 From: maier1 at us.ibm.com (Robert Maier) Date: Fri, 1 Feb 2008 17:03:38 -0700 Subject: [ppml] Robert Maier is currently out of the office until 2/4 Message-ID: I will be out of the office starting 02/01/2008 and will not return until 02/04/2008. Hello, I'll be out of the office Friday 2/1, returning Monday 2/4. If you have an urgent matter, please contact the AOD service center at 877-737-3700. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Mon Feb 4 10:47:45 2008 From: info at arin.net (Member Services) Date: Mon, 04 Feb 2008 10:47:45 -0500 Subject: [ppml] Deadline for Policy Proposals - 7 February 2008 Message-ID: <47A733A1.7000506@arin.net> The ARIN XXI Public Policy Meeting will take place 7-8 April 2008 in Denver. New policy proposals must be submitted by 23:59 EST, 7 February 2008, in order to be considered by the ARIN Advisory Council for possible inclusion on the ARIN XXI agenda. The ARIN Internet Resource Policy Evaluation Process requires that proposed policies must be submitted at least 60 days prior to the meeting. Those who wish to propose new ARIN number resource policies or modifications to existing policies must submit a Policy Proposal Template. Send the template via e-mail to policy at arin.net. The Policy Proposal Template can be found at: http://www.arin.net/policy/irpep_template.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Wed Feb 6 10:28:16 2008 From: info at arin.net (Member Services) Date: Wed, 06 Feb 2008 10:28:16 -0500 Subject: [ppml] ARIN Mailing Lists Message-ID: <47A9D210.4020409@arin.net> Dean Anderson's privilege to post and participate in ARIN's various mail lists has been suspended until April 7, 2008, 8:00am EST. This decision was taken in accordance with the procedures in ARIN's Acceptable Use Policy (AUP). Mr. Anderson was previously warned, in writing, in November to stop making per se defamatory comments. He recently made another "untrue and per se defamatory posting alleging criminal activity." Regards, Raymond A. Plzak President & CEO The American Registry for Internet Numbers (ARIN) From Ed.Lewis at neustar.biz Wed Feb 6 13:50:25 2008 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 6 Feb 2008 13:50:25 -0500 Subject: [ppml] [arin-discuss] Justifiable Censorship? In-Reply-To: References: Message-ID: At 12:02 -0600 2/6/08, Kyle Ackerman wrote: >We live in a country where people can burn flags, where protesters can >waste considerable time and money, where we have the right to voice our >opinion. Prior to the past few ARIN Open Policy Meetings there were long discussions on the many proposals put before us, all germane to the task ARIN has set out to fulfill. 13 proposals were covered, 12 of them new. We are about 24 or 48 hours before the deadline for new proposals to get discussed at the next OPM. There are currently 8 open proposals, 6 of them carried forward from the previous meeting. Just 2 of them new. It's not conclusive evidence of anything, it's not a scientific poll, but something seems to have derailed the functioning of ARIN. I looked up these because, it seemed to me, that there's a lot less to read in preparation for the next OPM, less that any meeting in recent years. Yet there are so many posts to the ARIN lists. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 stephen at sprunk.org Wed Feb 6 14:26:34 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 6 Feb 2008 13:26:34 -0600 Subject: [ppml] [arin-discuss] Justifiable Censorship? References: Message-ID: <00bc01c868f8$c6ce0df0$543816ac@atlanta.polycom.com> Thus spake "Edward Lewis" > Prior to the past few ARIN Open Policy Meetings there were long > discussions on the many proposals put before us, all germane to the > task ARIN has set out to fulfill. 13 proposals were covered, 12 of > them new. > > We are about 24 or 48 hours before the deadline for new proposals to > get discussed at the next OPM. There are currently 8 open proposals, > 6 of them carried forward from the previous meeting. Just 2 of them > new. > > It's not conclusive evidence of anything, it's not a scientific poll, > but something seems to have derailed the functioning of ARIN. I > looked up these because, it seemed to me, that there's a lot less to > read in preparation for the next OPM, less that any meeting in recent > years. > > Yet there are so many posts to the ARIN lists. In contrast, I find that PPML has been comparatively dead for the last couple of months. There were a large number of controversial proposals (as well as many editorial ones from the AC or staff) in the last cycle which generated quite a bit of discussion, but they were largely dealt with in ABQ. There's only been a few proposals since, which generated a fair bit of debate (much of it tangential). Unless someone's secretly screening proposals before they get to PPML (which I do not believe), it just seems that everyone decided to take a break for the holidays or we've simply run out of new things to propose for a while. One might consider the latter to be a sign that there's no remaining significant problems the community sees with the NPRM. I'm sure that claim will generate some comments of its own, but IMHO that's a good thing: if you disagree with my statement, please speak up so that someone can help you get a proposal in the works, hopefully before the deadline. 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 Wed Feb 6 14:57:31 2008 From: owen at delong.com (Owen DeLong) Date: Wed, 6 Feb 2008 11:57:31 -0800 Subject: [ppml] Proposal for SWIP/RWHOIS extension beyond /29 Message-ID: The ARIN AC is about to consider the next steps for the proposal at the end of this message. In light of that, we would like to get any feedback from the community on this proposal and especially whether it has support or not from members of the community. In your messages, please indicate if you support the proposal and make any comments you wish as to why/why not. Thanks, Owen DeLong ARIN AC > ## * ## > > > Policy Proposal Name: SWIP support for smaller than /29 assignments > > Author: Joe Maimon > > Proposal Version: 1 > > Submission Date: Jan 16, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsd at servervault.com Wed Feb 6 15:05:02 2008 From: dsd at servervault.com (Divins, David) Date: Wed, 6 Feb 2008 15:05:02 -0500 Subject: [ppml] Proposal for SWIP/RWHOIS extension beyond /29 In-Reply-To: References: Message-ID: Can I please get a clarification, is the following an accurate statement: This policy simply allows SWIP longer than /29 but does not manadate such reporting. Thanks, dsd David Divins Principal Engineer ServerVault Corp. (703) 652-5955 ________________________________ From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Wednesday, February 06, 2008 2:58 PM To: Public Policy Mailing List Subject: ***POSSIBLE SPAM*** [ppml] Proposal for SWIP/RWHOIS extension beyond /29 The ARIN AC is about to consider the next steps for the proposal at the end of this message. In light of that, we would like to get any feedback from the community on this proposal and especially whether it has support or not from members of the community. In your messages, please indicate if you support the proposal and make any comments you wish as to why/why not. Thanks, Owen DeLong ARIN AC ## * ## Policy Proposal Name: SWIP support for smaller than /29 assignments Author: Joe Maimon Proposal Version: 1 Submission Date: Jan 16, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Feb 6 15:15:52 2008 From: owen at delong.com (Owen DeLong) Date: Wed, 6 Feb 2008 12:15:52 -0800 Subject: [ppml] Proposal for SWIP/RWHOIS extension beyond /29 In-Reply-To: References: Message-ID: <9E33F99A-2B97-4BFD-95C6-57576B83ED8A@delong.com> Yes... That is my understanding of it as well. Owen On Feb 6, 2008, at 12:05 PM, Divins, David wrote: > Can I please get a clarification, is the following an accurate > statement: > > This policy simply allows SWIP longer than /29 but does not manadate > such reporting. > > Thanks, > dsd > David Divins > Principal Engineer > ServerVault Corp. > (703) 652-5955 > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf > Of Owen DeLong > Sent: Wednesday, February 06, 2008 2:58 PM > To: Public Policy Mailing List > Subject: ***POSSIBLE SPAM*** [ppml] Proposal for SWIP/RWHOIS > extension beyond /29 > > The ARIN AC is about to consider the next steps for the proposal at > the end of this > message. > > In light of that, we would like to get any feedback from the > community on this > proposal and especially whether it has support or not from members > of the > community. > > In your messages, please indicate if you support the proposal and make > any comments you wish as to why/why not. > > Thanks, > > Owen DeLong > ARIN AC > >> ## * ## >> >> >> Policy Proposal Name: SWIP support for smaller than /29 assignments >> >> Author: Joe Maimon >> >> Proposal Version: 1 >> >> Submission Date: Jan 16, 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 > > _______________________________________________ > 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 jmaimon at chl.com Wed Feb 6 15:49:54 2008 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 06 Feb 2008 15:49:54 -0500 Subject: [ppml] Proposal for SWIP/RWHOIS extension beyond /29 In-Reply-To: <9E33F99A-2B97-4BFD-95C6-57576B83ED8A@delong.com> References: <9E33F99A-2B97-4BFD-95C6-57576B83ED8A@delong.com> Message-ID: <47AA1D72.8090007@chl.com> Yes, that was the intent behind the proposal. Thanks, Joe Owen DeLong wrote: > Yes... That is my understanding of it as well. > > Owen > > On Feb 6, 2008, at 12:05 PM, Divins, David wrote: > >> Can I please get a clarification, is the following an accurate statement: >> >> This policy simply allows SWIP longer than /29 but does not manadate >> such reporting. >> >> Thanks, >> dsd >> >> David Divins >> Principal Engineer >> ServerVault Corp. >> (703) 652-5955 >> >> ------------------------------------------------------------------------ >> *From:* ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] *On >> Behalf Of *Owen DeLong >> *Sent:* Wednesday, February 06, 2008 2:58 PM >> *To:* Public Policy Mailing List >> *Subject:* ***POSSIBLE SPAM*** [ppml] Proposal for SWIP/RWHOIS >> extension beyond /29 >> >> The ARIN AC is about to consider the next steps for the proposal at >> the end of this >> message. >> >> In light of that, we would like to get any feedback from the community >> on this >> proposal and especially whether it has support or not from members of the >> community. >> >> In your messages, please indicate if you support the proposal and make >> any comments you wish as to why/why not. >> >> Thanks, >> >> Owen DeLong >> ARIN AC >> >>> ## * ## >> >>> >>> >>> Policy Proposal Name: SWIP support for smaller than /29 assignments >> >>> >>> Author: Joe Maimon >> >>> >>> Proposal Version: 1 >> >>> >>> Submission Date: Jan 16, 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 >> >> >> _______________________________________________ >> 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 stephen at sprunk.org Wed Feb 6 16:13:32 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 6 Feb 2008 15:13:32 -0600 Subject: [ppml] Proposal for SWIP/RWHOIS extension beyond /29 References: <9E33F99A-2B97-4BFD-95C6-57576B83ED8A@delong.com> Message-ID: <011e01c86906$5c90c190$543816ac@atlanta.polycom.com> Thus spake "Owen DeLong" > On Feb 6, 2008, at 12:05 PM, Divins, David wrote: >> Can I please get a clarification, is the following an accurate >> statement: >> >> This policy simply allows SWIP longer than /29 but does not manadate >> such reporting. > > Yes... That is my understanding of it as well. Based on that, I support the proposal. I think the wording is suboptimal, but it appears to achieve the stated goal, which I agree with. I'm interested in staff's assessment of whether it would result in a non-trivial expense increase due to additional server load, since that appears to be the reason that longer SWIPs weren't allowed in the first place. That wouldn't necessarily change my mind, but it's something we should know. 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 briand at ca.afilias.info Wed Feb 6 16:29:03 2008 From: briand at ca.afilias.info (Brian Dickson) Date: Wed, 06 Feb 2008 16:29:03 -0500 Subject: [ppml] Proposal for SWIP/RWHOIS extension beyond /29 In-Reply-To: <011e01c86906$5c90c190$543816ac@atlanta.polycom.com> References: <9E33F99A-2B97-4BFD-95C6-57576B83ED8A@delong.com> <011e01c86906$5c90c190$543816ac@atlanta.polycom.com> Message-ID: <47AA269F.5020901@ca.afilias.info> Stephen Sprunk wrote: > Thus spake "Owen DeLong" > >> On Feb 6, 2008, at 12:05 PM, Divins, David wrote: >> >>> Can I please get a clarification, is the following an accurate >>> statement: >>> >>> This policy simply allows SWIP longer than /29 but does not manadate >>> such reporting. >>> >> Yes... That is my understanding of it as well. >> > > Based on that, I support the proposal. I think the wording is suboptimal, > but it appears to achieve the stated goal, which I agree with. > > Ditto. > I'm interested in staff's assessment of whether it would result in a > non-trivial expense increase due to additional server load, since that > appears to be the reason that longer SWIPs weren't allowed in the first > place. That wouldn't necessarily change my mind, but it's something we > should know. > > +1 Brian Dickson > S > > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > From tedm at ipinc.net Wed Feb 6 16:42:13 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 6 Feb 2008 13:42:13 -0800 Subject: [ppml] [arin-discuss] Justifiable Censorship? In-Reply-To: Message-ID: >-----Original Message----- >From: arin-discuss-bounces at arin.net >[mailto:arin-discuss-bounces at arin.net]On Behalf Of Kyle Ackerman >Sent: Wednesday, February 06, 2008 10:02 AM >To: arin-discuss at arin.net >Cc: ppml at arin.net >Subject: [arin-discuss] Justifiable Censorship? > > >Mr. Plzak, > >Many of us would have to agree that Dean Anderson can be outright >annoying. He appears to have a significant amount of time to pursue Just a FYI for anyone considering to post to this thread - Dean's right to POST has been suspended. I'm sure he is still getting mail from the list and is no doubt tickled pink with all the concern shown over this. Just keep in mind that by arguing over the suspension your merely feeding a personality that craves attention. Ted From info at arin.net Thu Feb 7 12:21:40 2008 From: info at arin.net (Member Services) Date: Thu, 07 Feb 2008 12:21:40 -0500 Subject: [ppml] ARIN XXI Registration Open Message-ID: <47AB3E24.8060607@arin.net> ARIN invites you to join us 6-9 April 2008 in Denver, Colorado for the ARIN XXI Public Policy and Members Meeting. The meeting will be held at the Grand Hyatt Denver and registration is now open. Links to meeting, hotel, and remote participation information, as well as other meeting information is available at http://www.arin.net/ARIN-XXI/. The special room rate of $189(USD) single/double occupancy is available until 14 March 2008. Reserve your room now as space is limited. ARIN holds open, biannual Public Policy and Members Meetings, to provide an opportunity for the entire Internet community to contribute to Internet number resource policy discussion and development, network with colleagues, and attend workshops and tutorials. Current policy proposals up for discussion at this meeting are available at: http://www.arin.net/policy/proposals/proposal_archive.html ARIN XXI Overview * Sunday, 6 April- Sunday activities will include a luncheon for first time ARIN meeting attendees, a session entitled ?Understanding ARIN?s Legacy Registration Services Agreement? presented by ARIN General Counsel Steven M. Ryan ESQ., the Open Policy Hour, and the 9th Annual Foosball Tournament. * Monday, 7 April ? ARIN Public Policy Meeting, Day 1, evening ARIN Social * Tuesday, 8 April - ARIN Public Policy Meeting, Day 2 * Wednesday, 9 April - ARIN Members Meeting (open to all ARIN XXI attendees) ARIN will once again offer remote participation via webcast for those that are unable to attend. Remote participation includes the ability to send comments to the Public Policy Meeting. Additional agenda details and more information about ARIN XXI will be posted on our website as we get closer to the meeting, so check back often! Regards, Member Services Department American Registry for Internet Numbers(ARIN) From info at arin.net Thu Feb 7 12:36:21 2008 From: info at arin.net (Member Services) Date: Thu, 07 Feb 2008 12:36:21 -0500 Subject: [ppml] Policy Proposal 2007-22: Expand timeframe of Additional Requests - Second Last Call Message-ID: <47AB4195.6050904@arin.net> Policy Proposal 2007-22 Expand timeframe of Additional Requests It has come to the ARIN Advisory Council's (AC) attention that the wrong version of policy proposal 2007-22 was reviewed in last call. The history of the proposal is: Original version: http://lists.arin.net/pipermail/ppml/2007-August/008838.html Staff assessment: http://lists.arin.net/pipermail/ppml/2007-October/009473.html Presented at ARIN XX: http://www.arin.net/meetings/minutes/ARIN_XX/PDF/thursday/dan_alexander_2007-22.pdf Posted for Last Call: http://lists.arin.net/pipermail/ppml/2007-October/009612.html The version posed for last call should have included the updated text presented at ARIN XX. The three versions of text are: Current Policy statement: "After a subscriber has been a member of ARIN for one year they may choose to request a six-month supply of IP addresses." Original text of proposal mistakenly posted during last call:: "After an organization has been an ARIN member in good standing for one year, they may choose to request up to a 12 month supply of IP addresses." Changed text presented and polled upon in Albuquerque: "After an organization has been a subscriber member of ARIN for one year, they may choose to request up to a 12 month supply of IP addresses." Due to this error the AC has decided to send the correct text to the PPML mailing list for a second Last Call period to ensure the correct version of the propoal has been considered. Please accept the AC's apoligies for this mistake. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_22.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 20 February 2008. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-22 Expand timeframe of Additional Requests Author: Dan Alexander Proposal type: modify Policy term: permanent Policy statement: The proposal is to modify section 4.2.4.4 of the NRPM Current wording: "After a subscriber has been a member of ARIN for one year they may choose to request a six-month supply of IP addresses." Change to: "After an organization has been a subscriber member of ARIN for one year, they may choose to request up to a 12 month supply of IP addresses." Rationale: Currently, all RIR's provide organizations with at least a 12 month supply of IPv4 address space when making subsequent requests, with the exception of the ARIN region. The primary reason for this change is for continuity among all RIR. In doing so, all established organizations have a more consistent access to IP resources. The adjustment does not change demand on IPv4 address space. It only changes the frequency in which established organizations need to request address space. This would allow for fewer potential aggregates allocated to an organization providing more consolidated routing announcements. This does not change the requirement on new organizations where established growth trends have yet to be established. Timetable for implementation: Immediate From jmorrison at bogomips.com Thu Feb 7 14:26:37 2008 From: jmorrison at bogomips.com (John Paul Morrison) Date: Thu, 07 Feb 2008 11:26:37 -0800 Subject: [ppml] patching bigmama Message-ID: <47AB5B6D.5050301@bogomips.com> putting some patches on, no reboot required From info at arin.net Thu Feb 7 16:31:27 2008 From: info at arin.net (Member Services) Date: Thu, 07 Feb 2008 16:31:27 -0500 Subject: [ppml] ARIN Advisory Council Policy Proposal Message-ID: <47AB78AF.9050303@arin.net> In October of 2007 the ARIN Board of Trustees asked the Advisory Council to consider a set of broad 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 output from this process is a policy proposal the AC will be 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. This will allow for the emergence of transfers in IPv4 address space, with ARIN to provide a listing service for address blocks available for transfer under the revised transfer policy. 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. We expect the AC's policy proposal to appear on ppml on Monday February 11th. We encourage all members of the community to carefully read the proposal and post comments. Respectfully, Leo Bicknell, Chair For the ARIN Advisory Council From info at arin.net Fri Feb 8 15:11:12 2008 From: info at arin.net (Member Services) Date: Fri, 08 Feb 2008 15:11:12 -0500 Subject: [ppml] Policy Proposal: 200-reduction-6.5.1.1.d - Withdrawn by author Message-ID: <47ACB760.3040302@arin.net> Policy Proposal Name: 200-reduction-6.5.1.1.d The author withdrew their proposal. The proposal is closed. The policy proposal text is provided below and is also available at: http://lists.arin.net/pipermail/ppml/2007-October/009581.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: 200-reduction-6.5.1.1.d Author: Brian Dickson Proposal Version: 1 Submission Date: Oct 18, 2007 Proposal type: modify Policy term: permanent Policy statement: In 6.5.1.1 d), where 2007-25 proposes: "be an existing, known ISP in the ARIN region or have a plan for making at least 200 end-site assignments to other organizations within 5 years." replace with" "be an existing, known ISP in the ARIN region or have a plan for making at least 20 end-site assignments to other organizations, or for providing IPv6 transit to one or more IPv6 PI blocks belonging to other organizations, within 5 years." Rationale: The purpose of the text is to establish reasonable ways for an ISP to demonstrate that it is in fact an ISP. Any of the above listed conditions satisfy that need, and the intent is to avoid having the text of the policy prevent any legitimate ISP from receiving an initial IPv6 allocation. It does lower the bar, but in a justifiable fashion. It is not necessary for an ISP to have lots of PA assignments. It is necessary for an ISP to be announcing PA *or* PI blocks to the internet, and relaxing the criteria to recognize both possibilities jointly, makes the policy reflect the actual realities for any number of large regional ISPs, who may have sold off portions of their business but who still operate significant infrastructure. Timetable for implementation: Immediate From info at arin.net Fri Feb 8 15:18:02 2008 From: info at arin.net (Member Services) Date: Fri, 08 Feb 2008 15:18:02 -0500 Subject: [ppml] Policy Proposal 2007-23: End Policy for IANA IPv4 allocations to RIRs - Revised Text Message-ID: <47ACB8FA.4090002@arin.net> Policy Proposal 2007-23, End Policy for IANA IPv4 allocations to RIRs, 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_23.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2007-23 End Policy for IANA IPv4 allocations to RIRs Proposal Version: Version 2 (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 he 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 michael.dillon at bt.com Fri Feb 8 16:00:30 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 8 Feb 2008 21:00:30 -0000 Subject: [ppml] Policy Proposal 2007-23: End Policy for IANA IPv4 allocations to RIRs - Revised Text In-Reply-To: <47ACB8FA.4090002@arin.net> References: <47ACB8FA.4090002@arin.net> Message-ID: > 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. This is a deeply unfair policy. It means that when we near the point of exhaustion of IPv4, IANA will give some people a 3 year supply and some people a 3 month supply. It would be much fairer to reduce the size of IANA allocations from a full /8 to a smaller block size. In this way IANA can ensure that everyone runs out of IPv4 addresses at the same time. I suggest that the block size be based on the RIR whose yearly allocation of IPv4 addresses is the smallest, and be some defined fraction of that RIR's yearly fraction. For instance, if the 5 RIRs have the following annual allocation rates: A. /7 B. /8 C. /16 D. /10 E. /9 Then the smallest RIR issues a /16 in one year. For instance we could say that when there are no more than 5 full /8 blocks left in the IANA free pool (an easy and unambiguous measure) that we would change the IANA allocation size from /8 to x times the minimal of the 5 RIR yearly allocation rates. In this case it would be x times /16. We could either define x as a constant or have some formula to define x. If we decide that x should be 1, the the IANA allocation size shifts from /8 to /16. This does not mean that an RIR cannot receive more than a single /16 from IANA. It means that we move to a system more like the RIR allocations to ISPs/LIRs. If RIR A can show that it needs 5 /16s to handle the next half-year of allocations then that is what they should receive. Blocks would be adjacent to previous ones whenever possible. But 2007-23 is bad policy, and inherently unfair. I strongly oppose it. --Michael Dillon From arin-contact at dirtside.com Fri Feb 8 18:02:49 2008 From: arin-contact at dirtside.com (William Herrin) Date: Fri, 8 Feb 2008 18:02:49 -0500 Subject: [ppml] Policy Proposal 2007-23: End Policy for IANA IPv4 allocations to RIRs - Revised Text In-Reply-To: <47ACB8FA.4090002@arin.net> References: <47ACB8FA.4090002@arin.net> Message-ID: <3c3e3fca0802081502l43465e50oed16c816376ae097@mail.gmail.com> On Feb 8, 2008 3:18 PM, Member Services wrote: > Policy Proposal 2007-23 > End Policy for IANA IPv4 allocations to RIRs As with the prior versions, I support this proposal. However slightly, it yields more warning at the end. If we can't have the free pool last forever, at least we can have an extra couple of months forewarning when it finally hits. On Feb 8, 2008 4:00 PM, wrote: > This is a deeply unfair policy. It means that when we near the point > of exhaustion of IPv4, IANA will give some people a 3 year supply > and some people a 3 month supply. With the sole exception of AfriNIC, the difference in supply won't extend IPv4 long enough for any of the RIRs to care about This was discussed ad nauseam in the last go-round. I for one have no problem with the folks in Africa catching a mild break this once. > I suggest that the block size be based on the RIR whose yearly > allocation of IPv4 addresses is the smallest, and be some defined > fraction of that RIR's yearly fraction. For instance, if the > 5 RIRs have the following annual allocation rates: This is neither more nor less fair than the authors' proposal of exactly one /8 per RIR. It is more complicated and if offers an extra formula whose fairness we'd have to argue about. Shouldn't registries who've taken action to slow the consumption of IP addresses for, lets call it less critical needs, shouldn't those registries have the privilege of running out later than the rest? Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From drc at virtualized.org Fri Feb 8 21:34:43 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 8 Feb 2008 18:34:43 -0800 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." Message-ID: http://www.networkworld.com/news/2008/020608-ipv4-address-depletion.html Regards, -drc From jcurran at istaff.org Fri Feb 8 22:34:14 2008 From: jcurran at istaff.org (John Curran) Date: Fri, 8 Feb 2008 22:34:14 -0500 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: References: Message-ID: At 6:34 PM -0800 2/8/08, David Conrad wrote: >http://www.networkworld.com/news/2008/020608-ipv4-address-depletion.html The article highlights results of a 2007 survey of network managers' views on IPv6; one interesting data point is: "The number of survey respondents who said IPv6 does not provide benefits to their network infrastructures rose from 33% in 2005 to 49% in 2007." Certainly reflects reality today, so the real question is when does the carrier community tell their customers that increasing numbers of new Internet sites are likely to be reachable only via IPv6? They might want to resurvey the same network managers immediately after that announcement. /John From randy at psg.com Fri Feb 8 22:48:49 2008 From: randy at psg.com (Randy Bush) Date: Sat, 09 Feb 2008 12:48:49 +0900 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: References: Message-ID: <47AD22A1.4060803@psg.com> John Curran wrote: > when does the carrier community tell their customers that increasing > numbers of new Internet sites are likely to be reachable only via > IPv6? i am sure our marketing departments will all be in a rush to be the first to tell our customers we can not serve them. randy From drc at virtualized.org Fri Feb 8 23:34:27 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 8 Feb 2008 20:34:27 -0800 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: References: Message-ID: John, On Feb 8, 2008, at 7:34 PM, John Curran wrote: > when does the carrier community tell their customers that increasing > numbers of new Internet sites are likely to be reachable only > via IPv6? When there actually are sites their customers might care about that are only reachable via IPv6? Regards, -drc From jcurran at istaff.org Fri Feb 8 23:36:32 2008 From: jcurran at istaff.org (John Curran) Date: Fri, 8 Feb 2008 23:36:32 -0500 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: References: Message-ID: At 8:34 PM -0800 2/8/08, David Conrad wrote: >On Feb 8, 2008, at 7:34 PM, John Curran wrote: >>when does the carrier community tell their customers that increasing >>numbers of new Internet sites are likely to be reachable only >>via IPv6? > >When there actually are sites their customers might care about that are only reachable via IPv6? Wouldn't you actually want to tell them before, so that they could have enough time to plan accordingly? /John From drc at virtualized.org Fri Feb 8 23:40:04 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 8 Feb 2008 20:40:04 -0800 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: References: Message-ID: <4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org> On Feb 8, 2008, at 8:36 PM, John Curran wrote: > Wouldn't you actually want to tell them before, so that they could > have enough time to plan accordingly? See Randy's comment. Regards, -drc From gih at apnic.net Fri Feb 8 23:42:52 2008 From: gih at apnic.net (Geoff Huston) Date: Sat, 09 Feb 2008 15:42:52 +1100 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: References: Message-ID: <47AD2F4C.3040108@apnic.net> John Curran wrote: > At 8:34 PM -0800 2/8/08, David Conrad wrote: >> On Feb 8, 2008, at 7:34 PM, John Curran wrote: >>> when does the carrier community tell their customers that increasing >>> numbers of new Internet sites are likely to be reachable only >>> via IPv6? >> When there actually are sites their customers might care about that are only reachable via IPv6? > > Wouldn't you actually want to tell them before, so that > they could have enough time to plan accordingly? As far as I can tell right now there is a large amount of faith out there that all of this is just a beat up and that NATs will do the protocol translation magic without any major fuss. The reality injection will take some time in the face of the accumulated inertia we've accreted with IPv4. Geoff From jcurran at istaff.org Fri Feb 8 23:48:23 2008 From: jcurran at istaff.org (John Curran) Date: Fri, 8 Feb 2008 23:48:23 -0500 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: <4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org> References: <4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org> Message-ID: At 8:40 PM -0800 2/8/08, David Conrad wrote: >On Feb 8, 2008, at 8:36 PM, John Curran wrote: >>Wouldn't you actually want to tell them before, so that they could have enough time to plan accordingly? > >See Randy's comment. > >(randy) "i am sure our marketing departments will all be in a rush to be the first to tell our customers we can not serve them." It impacts everyone at the same time; i.e. it doesn't matter if it's your ISP or another one now using IPv6 for new customers, you won't be able to reach them without IPv6 connectivity (or transition mechanism). That's not telling customers you can't serve them, only that they may need to also have IPv6 if they want to reach the entire Internet, since pieces of it are using IPv6 to connect. /John From randy at psg.com Sat Feb 9 00:10:18 2008 From: randy at psg.com (Randy Bush) Date: Sat, 09 Feb 2008 14:10:18 +0900 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: References: <4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org> Message-ID: <47AD35BA.3030807@psg.com> can we get real here? what is the likelihood of someone *major* putting up a service only reachable over ipv6? people will move when it is in their business interest to do so. what does it take to make your enterprise dual stack? john, how far have you progressed? given the government is your big customer, i presume you have gone in early and big. care to tell us how easy it was and how much it really benefits beyond a check-box? we went in early, in fact the earliest commercial roll. and we have regressed, i.e. some services are not maintained over ipv6 that used to be because no one used them and they caused pain. try an smtp service with no ipv6 dnsbl, etc.. we're working on changing that, but it's not easy to justify. drc, with great political and bureaucratic pain, has been rolling ipv6. so he has his money where his mouth is. how are the rest of the mouths here? roam.psg.com:/usr/home/randy> dig +short arin.net. mx 10 smtp2.arin.net. 20 smtp1.arin.net. 30 smtp3.arin.net. roam.psg.com:/usr/home/randy> host smtp1.arin.net smtp1.arin.net has address 192.149.252.33 roam.psg.com:/usr/home/randy> host smtp2.arin.net smtp2.arin.net has address 192.149.252.32 roam.psg.com:/usr/home/randy> host smtp3.arin.net smtp3.arin.net has address 199.43.0.197 before getting on high horse, check for saddle or be damned good at bareback on a damned tough horse. randy From bicknell at ufp.org Sat Feb 9 08:39:43 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 9 Feb 2008 08:39:43 -0500 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: References: Message-ID: <20080209133943.GA54068@ussenterprise.ufp.org> In a message written on Fri, Feb 08, 2008 at 06:34:43PM -0800, David Conrad wrote: > http://www.networkworld.com/news/2008/020608-ipv4-address-depletion.html I've posted similar comments elsewhere, but why not here as well.... IPv6 is not a flag day; there is a dual stack transition period and ALG's can easily bridge the two. There are more than a few enterprise networks designed with RFC1918 space internally and a small DMZ network with dual homed mail servers, VPN servers, web proxy servers, and the like. At least in the short term these enterprises will be well served by getting a /48 from their upstream, putting IPv6 on the outside interfaces of the 10 or so boxes in the DMZ, and leaving the rest of their 10,000 internal systems alone on IPv4 RFC1918 space. They will be able to send e-mail and browse web sites on IPv6 only boxes just fine. The VPN servers will allow someone with IPv6 only at home to create an IPv4 tunnel back to the internal corporate network. I think we need to be careful with our message. IPv6 is a "right now" problem for ISP's and for major content providers. However IPv6 may also be a "in another couple of years" problem for an Enterprise in the situation I describe above. We need to focus our efforts where they will do the most good. -- 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 jcurran at istaff.org Sat Feb 9 08:45:47 2008 From: jcurran at istaff.org (John Curran) Date: Sat, 9 Feb 2008 08:45:47 -0500 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: <47AD35BA.3030807@psg.com> References: <4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org> <47AD35BA.3030807@psg.com> Message-ID: At 2:10 PM +0900 2/9/08, Randy Bush wrote: >can we get real here? what is the likelihood of someone *major* putting up a service only reachable over ipv6? I expect the likelihood is pretty high, once they have no other choice? >people will move when it is in their business interest to do so. what does it take to make your enterprise dual stack? john, how far have you progressed? given the government is your big customer, i presume you have gone in early and big. care to tell us how easy it was and how much it really benefits beyond a check-box? >... >before getting on high horse, check for saddle or be damned good at bareback on a damned tough horse. >(queries over at arin.net) Randy - My day job is over here, thanks... [...:~] jcurran% dig +short servervault.com aaaa 2610:60::1002:203:47ff:fe73:b1f7 2610:60::1002:203:47ff:fe73:b21f We haven't put the MX records in yet, but that is in progress. And to answer your specific question, IPv6 enablement has been painless so far. /John From jcurran at istaff.org Sat Feb 9 08:53:58 2008 From: jcurran at istaff.org (John Curran) Date: Sat, 9 Feb 2008 08:53:58 -0500 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: <20080209133943.GA54068@ussenterprise.ufp.org> References: <20080209133943.GA54068@ussenterprise.ufp.org> Message-ID: At 8:39 AM -0500 2/9/08, Leo Bicknell wrote: >IPv6 is not a flag day; there is a dual stack transition period and >ALG's can easily bridge the two. There are more than a few enterprise >networks designed with RFC1918 space internally and a small DMZ >network with dual homed mail servers, VPN servers, web proxy servers, >and the like. At least in the short term these enterprises will >be well served by getting a /48 from their upstream, putting IPv6 >on the outside interfaces of the 10 or so boxes in the DMZ, and >leaving the rest of their 10,000 internal systems alone on IPv4 >RFC1918 space. > >They will be able to send e-mail and browse web sites on IPv6 only >boxes just fine. The VPN servers will allow someone with IPv6 only >at home to create an IPv4 tunnel back to the internal corporate >network. Complete agreement. In fact, there's an I-D out there where I outline this sort of overall Internet transition. >I think we need to be careful with our message. IPv6 is a "right >now" problem for ISP's and for major content providers. However >IPv6 may also be a "in another couple of years" problem for an >Enterprise in the situation I describe above. We need to focus our >efforts where they will do the most good. Alas, "being careful" with the message doesn't actually sell newpapers or generate webclicks... (which is what we see from the referenced article). The loss of availability of large contiguous address blocks from the free pool is most certainly not an issue for the enterprise network manager, it's an issue the ISP community. The catch is that unless the ISP starts advocacy of IPv6 enablement of their existing customers edge servers (web, mail), then they won't have the ability to use to use IPv6 to connect new clients when they need to... /John From randy at psg.com Sat Feb 9 08:56:42 2008 From: randy at psg.com (Randy Bush) Date: Sat, 09 Feb 2008 22:56:42 +0900 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: References: <4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org> <47AD35BA.3030807@psg.com> Message-ID: <47ADB11A.3070409@psg.com> > We haven't put the MX records in yet, but that is in progress. and you don't seem to have the AAAAs for the nameservers. when you do, you may have some hope of getting glue at the parent, as you use netsol as a registrar. but do tell how that one goes. > And to answer your specific question, IPv6 enablement has > been painless so far. i am impressed. i think most of the rest of us have hit speedbumps. we got over them, but we're glad we did not assign it to a grad student. i suspect that we just have a different definition of painless. randy From jcurran at istaff.org Sat Feb 9 09:14:10 2008 From: jcurran at istaff.org (John Curran) Date: Sat, 9 Feb 2008 09:14:10 -0500 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: <47ADB11A.3070409@psg.com> References: <4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org> <47AD35BA.3030807@psg.com> <47ADB11A.3070409@psg.com> Message-ID: At 10:56 PM +0900 2/9/08, Randy Bush wrote: >>We haven't put the MX records in yet, but that is in progress. > >and you don't seem to have the AAAAs for the nameservers. when you do, you may have some hope of getting glue at the parent, as you use netsol as a registrar. but do tell how that one goes. >From the Nanog thread, it's clear the versign/registry can handle such, so if it's just phone loops with netsol/registrar to get them to push the glue, I've got quite a bit of patience... I'll make sure to provide any updates/insights to Jeroen for the Sixxs-IPv6glue page. Who knows, if we end up changing registrars over it, it'll be one more data point for netsol to consider support. >>And to answer your specific question, IPv6 enablement has >>been painless so far. > >i am impressed. i think most of the rest of us have hit speedbumps. we got over them, but we're glad we did not assign it to a grad student. i suspect that we just have a different definition of painless. I expect it's going to be several years before any of this can be safely delegated. /John From randy at psg.com Sat Feb 9 09:35:26 2008 From: randy at psg.com (Randy Bush) Date: Sat, 09 Feb 2008 23:35:26 +0900 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: References: <4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org> <47AD35BA.3030807@psg.com> <47ADB11A.3070409@psg.com> Message-ID: <47ADBA2E.9030303@psg.com> > From the Nanog thread, it's clear the versign/registry can handle > such, so if it's just phone loops with netsol/registrar to get them > to push the glue, I've got quite a bit of patience. i flagged as a the nanog posting that started the thread because, though i know i can subvert or manipulate the system to my needs, that is neither a fair or useful exercise. we need to make the system work for everyone. and simply and easily. so i am gonna sit here and sulk and whine loud and long until the iana and opensrs/tucows fix it. :) > I expect it's going to be several years before any of this can be > safely delegated. the key thing we, who have some handle on the administrative and technical infrastructure, can do to ease transition is to remove the administrative obstacles to transition. e.g. bleeping glue records. we need more folk to tell the tales of their transition and the bumps they hit which could be removed so that we can look at smoothing them. [ and no i do not mean encouraging routing table pollution because i deserve my own /32 so i will not have to renumber some day ] randy From Lee.Howard at stanleyassociates.com Sat Feb 9 10:05:26 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Sat, 9 Feb 2008 10:05:26 -0500 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently noone." In-Reply-To: Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of David Conrad > > when does the carrier community tell their customers that > increasing > > numbers of new Internet sites are likely to be reachable only via > > IPv6? > > When there actually are sites their customers might care > about that are only reachable via IPv6? Isn't it incumbent on the network newly connecting to the Internet to be able to communicate with the networks already on it? I'm an ISP customer. My IPv4 network isn't growing (maybe I add a /28 per year). Tell me why I care about IPv6. Devils need advocates, too. Lee From jcurran at istaff.org Sat Feb 9 10:16:01 2008 From: jcurran at istaff.org (John Curran) Date: Sat, 9 Feb 2008 10:16:01 -0500 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently noone." In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com> Message-ID: At 10:05 AM -0500 2/9/08, Howard, W. Lee wrote: >I'm an ISP customer. My IPv4 network isn't growing (maybe >I add a /28 per year). Tell me why I care about IPv6. You don't, until some ISP is wedged in such a tight corner that they need to connect new customers with just IPv6 (because they can't seem to obtain&route additional IPv4 space at any realistic cost). Your organization is likely to be able to get email to and from new-co-IPv6-only and hopefully have them reach your website via proxy (if the ISP is making an effort to minimize the pain), but they won't be able to run any other applications which need end-to-end IP... Does this matter to you? I guess it depends on how a given business interacts with its suppliers and customers. /John From vixie at isc.org Sat Feb 9 12:35:05 2008 From: vixie at isc.org (Paul Vixie) Date: 09 Feb 2008 17:35:05 +0000 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently noone." In-Reply-To: References: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com> Message-ID: jcurran at istaff.org (John Curran) writes: > At 10:05 AM -0500 2/9/08, Howard, W. Lee wrote: > >I'm an ISP customer. My IPv4 network isn't growing (maybe > >I add a /28 per year). Tell me why I care about IPv6. > > You don't, until some ISP is wedged in such a tight corner that > they need to connect new customers with just IPv6 (because > they can't seem to obtain&route additional IPv4 space at any > realistic cost). > ... so there's an opportunity here for IPv4-rich ISP's to delay their own IPv6 transition, including dual-stack, so as to acquire customers and cash flows from IPv4-poor ISP's, during a transition period that can be deliberately extended by such delay? -- Paul Vixie From jcurran at istaff.org Sat Feb 9 12:52:54 2008 From: jcurran at istaff.org (John Curran) Date: Sat, 9 Feb 2008 12:52:54 -0500 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: References: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com> Message-ID: At 5:35 PM +0000 2/9/08, Paul Vixie wrote: >so there's an opportunity here for IPv4-rich ISP's to delay their >own IPv6 transition, including dual-stack, so as to acquire customers >and cash flows from IPv4-poor ISP's, during a transition period that >can be deliberately extended by such delay? Interesting thought... the answer is likely yes, but it actually may be more likely an opportunity for smaller ISP's as it's the ratio of supply over usage rate that determines how long one can stretch an IPv4-only connectivity model. It changes to more of an opportunity for deeply-funded entities in the presence of a market-like transfer policies. /John From bmanning at vacation.karoshi.com Sat Feb 9 14:11:40 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 9 Feb 2008 19:11:40 +0000 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: <20080209133943.GA54068@ussenterprise.ufp.org> References: <20080209133943.GA54068@ussenterprise.ufp.org> Message-ID: <20080209191140.GA18897@vacation.karoshi.com.> > IPv6 is not a flag day; there is a dual stack transition period and > ALG's can easily bridge the two. There are more than a few enterprise > networks designed with RFC1918 space internally and a small DMZ > network with dual homed mail servers, VPN servers, web proxy servers, > and the like. At least in the short term these enterprises will > be well served by getting a /48 from their upstream, putting IPv6 > on the outside interfaces of the 10 or so boxes in the DMZ, and > leaving the rest of their 10,000 internal systems alone on IPv4 > RFC1918 space. > > They will be able to send e-mail and browse web sites on IPv6 only > boxes just fine. The VPN servers will allow someone with IPv6 only > at home to create an IPv4 tunnel back to the internal corporate > network. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ right model, but (imho) 180 degrees out of phase. think IPv6 only islands w/ a thin veneer of IPv4 (say a /28) on the outside. the ALG's to support this are not well defined, with the IETF reconsidering work in this area. some call this NAT-PT, my favorite is the CERN-IVI box... which might see the light of day 3q08... --bill From jcurran at istaff.org Sat Feb 9 14:36:31 2008 From: jcurran at istaff.org (John Curran) Date: Sat, 9 Feb 2008 14:36:31 -0500 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: <20080209191140.GA18897@vacation.karoshi.com.> References: <20080209133943.GA54068@ussenterprise.ufp.org> <20080209191140.GA18897@vacation.karoshi.com.> Message-ID: At 7:11 PM +0000 2/9/08, bmanning at vacation.karoshi.com wrote: > > right model, but (imho) 180 degrees out of phase. > think IPv6 only islands w/ a thin veneer of IPv4 > (say a /28) on the outside. the ALG's to support > this are not well defined, with the IETF reconsidering > work in this area. some call this NAT-PT, my favorite > is the CERN-IVI box... which might see the light of > day 3q08... Bill - Is it safe to presume that these are architectures proposed for new customer connections? It is hard to imagine an existing Internet connected (via IPv4) site having any reason to evolve its internal network into an IPv6 island intentionally in the near future... /John From jcurran at istaff.org Sat Feb 9 15:19:34 2008 From: jcurran at istaff.org (John Curran) Date: Sat, 9 Feb 2008 15:19:34 -0500 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: <47AE0648.6090108@bogus.com> References: <20080209133943.GA54068@ussenterprise.ufp.org> <20080209191140.GA18897@vacation.karoshi.com.> <47AE0648.6090108@bogus.com> Message-ID: At 12:00 PM -0800 2/9/08, Joel Jaeggli wrote: >John Curran wrote: > >>Is it safe to presume that these are architectures proposed for >>new customer connections? It is hard to imagine an existing >>Internet connected (via IPv4) site having any reason to evolve >>its internal network into an IPv6 island intentionally in the near >>future... > >Actually if you recover the v4 address currently consumed by your infrastructure you can continue to provide them to your customers which may by a substantial incentive to produce a network which is subtantially ipv6 only. Interesting; this presumes that that one's willing to depart from 'ships in the night' IPv4/IPv6 backbone approach, and "transparently" alter the transport of your existing production IPv4 customer traffic... I'm not saying it won't happen (as depletion will eventually force some very hard decisions) but it's not the traditional risk-adverse approach used by the carriers, who loathe to do anything that could result in even a small percentage of their business customers complaining/switching/leaving. Of course, it's opportunities like that which nimble/brave firms use to gain advantage (and not dissimilar to the recent switch that some carriers did with production POTS trunks to VoIP for cost advantages...), and if there's sufficient IPv4 address space to be to recovered, it could be one possible route which allows IPv4 growth while also making progress on transition. /John From bmanning at vacation.karoshi.com Sat Feb 9 17:56:08 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 9 Feb 2008 22:56:08 +0000 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: References: <20080209133943.GA54068@ussenterprise.ufp.org> <20080209191140.GA18897@vacation.karoshi.com.> Message-ID: <20080209225608.GA20753@vacation.karoshi.com.> On Sat, Feb 09, 2008 at 02:36:31PM -0500, John Curran wrote: > At 7:11 PM +0000 2/9/08, bmanning at vacation.karoshi.com wrote: > > > > right model, but (imho) 180 degrees out of phase. > > think IPv6 only islands w/ a thin veneer of IPv4 > > (say a /28) on the outside. the ALG's to support > > this are not well defined, with the IETF reconsidering > > work in this area. some call this NAT-PT, my favorite > > is the CERN-IVI box... which might see the light of > > day 3q08... > > Bill - > > Is it safe to presume that these are architectures proposed for > new customer connections? It is hard to imagine an existing > Internet connected (via IPv4) site having any reason to evolve > its internal network into an IPv6 island intentionally in the near > future... > > /John i think a safe presumption is that this may be a predominant structure as long as there are "arrogant twits" who maintain the fiction that only IPv4 transport is needed to get to their content/eyeballs. e.g. if facebook never supports IPv6 transport, this will be common. Facebook will never see IPv6 demand and claim "all is well" with IPv4 and the IPv6 hype is just that. I expect it will be common for new builds - so they can participate with that "other" address family. Less common for existing builds - in part because the clients/content are already there. UNTIL ... some compelling new content or feature is brought up ONLY on IPv6... then the installed base has to decide how to move. the middle ground, that you have espoused, where some content/ applications are available over -both- address families - will be the predominant mode - but such will be an operational suite from outerdarkness... because the transports are non-overlapping. --bill From jcurran at istaff.org Sat Feb 9 18:34:53 2008 From: jcurran at istaff.org (John Curran) Date: Sat, 9 Feb 2008 18:34:53 -0500 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: <20080209225608.GA20753@vacation.karoshi.com.> References: <20080209133943.GA54068@ussenterprise.ufp.org> <20080209191140.GA18897@vacation.karoshi.com.> <20080209225608.GA20753@vacation.karoshi.com.> Message-ID: At 10:56 PM +0000 2/9/08, bmanning at vacation.karoshi.com wrote: > > i think a safe presumption is that this may be a > predominant structure as long as there are "arrogant > twits" who maintain the fiction that only IPv4 transport > is needed to get to their content/eyeballs. e.g. if > facebook never supports IPv6 transport, this will be common. > Facebook will never see IPv6 demand and claim "all is well" > with IPv4 and the IPv6 hype is just that. Facebook, Yahoo!, Google, MSN, Youtube, .... the list goes on and on. I wouldn't expect any of them to see measurable demand for IPv6 until there's a sizable IPv6-only user community. An IPv6-only user community is definitely going to happen (my own opinion) but it's years away and occurs when ISP's have no real cost- effective alternative for extending growth via IPv4. Even if some user communities go dual-stack before then, that's not exactly a compelling reason for content providers to invest in IPv6 infrastructure since dual- stack implies that they can already get the same users over IPv4. Can you explain why there will be a significant base of IPv6-only users before then? Without IPv6-only users or some compelling benefits for IPv6 versus IPv4 transport, it's hard to see why the content community would invest ahead of time. Existing enterprises, consumers, and content providers all have working infrastructure that still meets their needs once there is no readily available free pool; it's the ISP business growth model that gets impacted and hence the ISP community that needs to drive any desired transition. /John From dwhite at olp.net Sat Feb 9 18:51:06 2008 From: dwhite at olp.net (Dan White) Date: Sat, 09 Feb 2008 17:51:06 -0600 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: <20080209225608.GA20753@vacation.karoshi.com.> References: <20080209133943.GA54068@ussenterprise.ufp.org> <20080209191140.GA18897@vacation.karoshi.com.> <20080209225608.GA20753@vacation.karoshi.com.> Message-ID: <47AE3C6A.3050605@olp.net> bmanning at vacation.karoshi.com wrote: > i think a safe presumption is that this may be a > predominant structure as long as there are "arrogant > twits" who maintain the fiction that only IPv4 transport > is needed to get to their content/eyeballs. e.g. if > facebook never supports IPv6 transport, this will be common. > Facebook will never see IPv6 demand and claim "all is well" > with IPv4 and the IPv6 hype is just that. > > I expect it will be common for new builds - so they can > participate with that "other" address family. Less common > for existing builds - in part because the clients/content > are already there. UNTIL ... some compelling new content > or feature is brought up ONLY on IPv6... then the installed > base has to decide how to move. > > the middle ground, that you have espoused, where some content/ > applications are available over -both- address families - will > be the predominant mode - but such will be an operational > suite from outerdarkness... because the transports are non-overlapping. It's interesting that you should pick facebook as your example popular site: http://slashdot.org/article.pl?sid=08/02/08/1627201 I believe the focus on the PC access paradigm might be missing the potential for IPv6 adoption. As an ISP admin, I expect it will be years after the exhaustion of the IPv4 pool before most of my customers will be concerned about dual stacking, even though they may not be able to access some content. The potential for IPv6 probably rests in the hands of mobile, embedded and networking devices. If providers build these types of devices, and the next generation of services, on IPv6 and the advantages it provides, then those services will bootstrap the rest of the industry - "You mean I can do *that* on my PC?". As someone who gets excited about tech, I hope it's not the stick (IPv4 is running out!) that moves us along but rather the potential services and devices that we create that get us there. - Dan White From Nathan.Nieblas at quebecorworld.com Sat Feb 9 18:58:20 2008 From: Nathan.Nieblas at quebecorworld.com (Nathan.Nieblas at quebecorworld.com) Date: Sat, 9 Feb 2008 17:58:20 -0600 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: References: <20080209133943.GA54068@ussenterprise.ufp.org> <20080209191140.GA18897@vacation.karoshi.com.> <20080209225608.GA20753@vacation.karoshi.com.>, Message-ID: Is the reserved Class E address space not being considered? Would it take to much effort vs. the effort of implementing IPv6? Nathan -----ppml-bounces at arin.net wrote: ----- To: bmanning at vacation.karoshi.com From: John Curran Sent by: ppml-bounces at arin.net Date: 02/09/2008 03:34PM cc: Public Policy Mailing List Subject: Re: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." At 10:56 PM +0000 2/9/08, bmanning at vacation.karoshi.com wrote: > > i think a safe presumption is that this may be a > predominant structure as long as there are "arrogant > twits" who maintain the fiction that only IPv4 transport > is needed to get to their content/eyeballs. e.g. if > facebook never supports IPv6 transport, this will be common. > Facebook will never see IPv6 demand and claim "all is well" > with IPv4 and the IPv6 hype is just that. Facebook, Yahoo!, Google, MSN, Youtube, .... the list goes on and on. I wouldn't expect any of them to see measurable demand for IPv6 until there's a sizable IPv6-only user community. An IPv6-only user community is definitely going to happen (my own opinion) but it's years away and occurs when ISP's have no real cost- effective alternative for extending growth via IPv4. Even if some user communities go dual-stack before then, that's not exactly a compelling reason for content providers to invest in IPv6 infrastructure since dual- stack implies that they can already get the same users over IPv4. Can you explain why there will be a significant base of IPv6-only users before then? Without IPv6-only users or some compelling benefits for IPv6 versus IPv4 transport, it's hard to see why the content community would invest ahead of time. Existing enterprises, consumers, and content providers all have working infrastructure that still meets their needs once there is no readily available free pool; it's the ISP business growth model that gets impacted and hence the ISP community that needs to drive any desired transition. /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 michael at rancid.berkeley.edu Sat Feb 9 19:13:35 2008 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Sat, 09 Feb 2008 16:13:35 -0800 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: References: <20080209133943.GA54068@ussenterprise.ufp.org> <20080209191140.GA18897@vacation.karoshi.com.> <20080209225608.GA20753@vacation.karoshi.com.>, Message-ID: <47AE41AF.6050504@rancid.berkeley.edu> Nathan.Nieblas at quebecorworld.com wrote: > Is the reserved Class E address space not being considered? Would it take > to much effort vs. the effort of implementing IPv6? It is being considered in some corners for things like private addressing[1]. IMO, to make that space useful for globally-routable unicast services, it would take enough work and extend the life of the IPv4 free pool for a short enough time that our efforts are better spent in deploying IPv6. michael [1]http://www.ietf.org/internet-drafts/draft-wilson-class-e-01.txt From bmanning at vacation.karoshi.com Sat Feb 9 19:19:00 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 10 Feb 2008 00:19:00 +0000 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: References: <20080209133943.GA54068@ussenterprise.ufp.org> <20080209191140.GA18897@vacation.karoshi.com.> <20080209225608.GA20753@vacation.karoshi.com.> Message-ID: <20080210001900.GA21368@vacation.karoshi.com.> On Sat, Feb 09, 2008 at 06:34:53PM -0500, John Curran wrote: > At 10:56 PM +0000 2/9/08, bmanning at vacation.karoshi.com wrote: > > > > i think a safe presumption is that this may be a > > predominant structure as long as there are "arrogant > > twits" who maintain the fiction that only IPv4 transport > > is needed to get to their content/eyeballs. e.g. if > > facebook never supports IPv6 transport, this will be common. > > Facebook will never see IPv6 demand and claim "all is well" > > with IPv4 and the IPv6 hype is just that. > > Facebook, Yahoo!, Google, MSN, Youtube, .... the list goes on and on. > I wouldn't expect any of them to see measurable demand for IPv6 > until there's a sizable IPv6-only user community. actually, I never expect them to see a demand for IPv6 - at least from the trenches. Folks will "wrap" IPv6 access in/around NAT-PT or IVI and all they will see is IPv4 access requests. > An IPv6-only user community is definitely going to happen (my own > opinion) but it's years away and occurs when ISP's have no real cost- > effective alternative for extending growth via IPv4. Even if some user > communities go dual-stack before then, that's not exactly a compelling > reason for content providers to invest in IPv6 infrastructure since dual- > stack implies that they can already get the same users over IPv4. > > Can you explain why there will be a significant base of IPv6-only users > before then? some communities are already in that situation... at least on a global scale. and they are the ones active in the development and fine tuning of the ALG's that provide "seamless" migration btwn address families. and in this situation, the content providers will -never- see IPv6 demand as a groundswell. > Without IPv6-only users or some compelling benefits for IPv6 versus IPv4 > transport, it's hard to see why the content community would invest ahead > of time. Existing enterprises, consumers, and content providers all have > working infrastructure that still meets their needs once there is no readily > available free pool; it's the ISP business growth model that gets impacted > and hence the ISP community that needs to drive any desired transition. I expect the content community will be complacent in their rich IPv4 mesh. And at some point, in one of those IPv6 only enclaves, something new will emerge that is available on IPv6 only. Folks will want that feature/capability. And low'n'behold, the ALG that lets the IPv6 only crowd out to the IPv4 world will let the IPv4 world into the IPv6 world. Then the question will be one of ALG scalability. :) > /John --bill (my own opinions as well) From bmanning at vacation.karoshi.com Sat Feb 9 19:23:26 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 10 Feb 2008 00:23:26 +0000 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: <47AE3C6A.3050605@olp.net> References: <20080209133943.GA54068@ussenterprise.ufp.org> <20080209191140.GA18897@vacation.karoshi.com.> <20080209225608.GA20753@vacation.karoshi.com.> <47AE3C6A.3050605@olp.net> Message-ID: <20080210002326.GB21368@vacation.karoshi.com.> On Sat, Feb 09, 2008 at 05:51:06PM -0600, Dan White wrote: > bmanning at vacation.karoshi.com wrote: > > {picking on facebook as a typical content provider} > > It's interesting that you should pick facebook as your example > popular site: > > http://slashdot.org/article.pl?sid=08/02/08/1627201 > > I believe the focus on the PC access paradigm might be missing > the potential for IPv6 adoption. As an ISP admin, I expect it > will be years after the exhaustion of the IPv4 pool before most > of my customers will be concerned about dual stacking, even > though they may not be able to access some content. amen. > > The potential for IPv6 probably rests in the hands of mobile, > embedded and networking devices. If providers build these types > of devices, and the next generation of services, on IPv6 and the > advantages it provides, then those services will bootstrap the > rest of the industry - "You mean I can do *that* on my PC?". er... surely you intended, "...You mean I CAN'T to *that on my PC?" I'm persuaded that you have identified the next round of connectable devices. > As someone who gets excited about tech, I hope it's not the stick > (IPv4 is running out!) that moves us along but rather the > potential services and devices that we create that get us there. i beleive that both carrot and stick are needed for this beast'o'burden to get moving. > > - Dan White --bill From michael at rancid.berkeley.edu Sat Feb 9 19:25:01 2008 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Sat, 09 Feb 2008 16:25:01 -0800 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: References: <20080209133943.GA54068@ussenterprise.ufp.org> <20080209191140.GA18897@vacation.karoshi.com.> <20080209225608.GA20753@vacation.karoshi.com.> Message-ID: <47AE445D.6010202@rancid.berkeley.edu> John Curran wrote: > Without IPv6-only users or some compelling benefits for IPv6 versus IPv4 > transport, it's hard to see why the content community would invest ahead > of time. Existing enterprises, consumers, and content providers all have > working infrastructure that still meets their needs once there is no readily > available free pool; it's the ISP business growth model that gets impacted > and hence the ISP community that needs to drive any desired transition. In the R&E community, there is still a credible belief that we will see IPv6-only resources in the fairly near future. For example, the Large Tokamak project in Asia is reputed to be IPv6-only once it becomes operational. Researchers elsewhere who need data from it will need v6 or some sort of proxy. I do believe that we will see IPv6-only users in parts of the developing world, where they won't be able to afford increasing prices for IPv4 addresses once the free pool run-out occurs and we (maybe) move to a market system. In the R&E community, there are a bunch of us who believe we need to make our resources available to that segment, but, like any other sector, do not speak with one voice. I am glad to see that John has had good luck in his conversion, but I agree with Randy that there are many bumps in the road. See: http://events.internet2.edu/2008/jt-hawaii/sessionDetails.cfm?session=3607&event=278 (video stream at http://winmedia.internet2.edu/jointtechs-w08/jtw08-18.wmv ) My point in that talk is that there are bumps even in places where you don't expect them, such as applications that _do_ support IPv6 (but not easy dual-stack) or registrars that, to their credit, have implemented AAAA glue for years (but had some bugs in their implementation and there hasn't been sufficient use of the registration system to tickle those bugs). However, for me and my organization, that has been justification for moving ahead now. It's precisely because with think there WILL be some pain, bumps, and delays in converting to dual-stack that we feel we need to get started now. We still have a little bit of time before the crunch comes; if we move now, we believe we will be in a much better position than if we wait until we absolutely have to migrate. As for transitions, given the cloud that now hangs over NAT-PT (via RFC 4966), and Iljitsch van Beijnum's point in "Running IPv6"--that applications that support IPv6 will tend to have ALGs and proxies that those that don't have ALGs and proxies won't support IPv6 from the client side anyway--I am moving toward a combined v4-NAT and v6 model. My idea (for large workstation lans and residence services) is to have a one-armed NAT gateway to do the v4 translation, while v6 would be just routed through the regular routing infrastructure, with no middleboxes. I am in the process of a POC now. (If anyone else has tried this let me know off-list, as that's more of an ops issue.) This still requires clients to be dual-stack and it still has the yuckiness of v4 NAT, but it does give clients an end-to-end transparency option (and thus an incentive to use IPv6) plus a v4 fallback option, and it could reduce pressure on IPv4 address space in the future. It seems like it might be useful on large client networks, WiFi nets, residential nets, etc. michael From paul at vix.com Sat Feb 9 21:24:15 2008 From: paul at vix.com (Paul Vixie) Date: Sun, 10 Feb 2008 02:24:15 +0000 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: Your message of "Sat, 09 Feb 2008 12:52:54 EST." References: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com> Message-ID: <5384.1202610255@sa.vix.com> > >so there's an opportunity here for IPv4-rich ISP's to delay their > >own IPv6 transition, including dual-stack, so as to acquire customers > >and cash flows from IPv4-poor ISP's, during a transition period that > >can be deliberately extended by such delay? > > Interesting thought... the answer is likely yes, but it actually may > be more likely an opportunity for smaller ISP's as it's the ratio of > supply over usage rate that determines how long one can stretch an > IPv4-only connectivity model. It changes to more of an opportunity > for deeply-funded entities in the presence of a market-like transfer > policies. i wasn't saying large vs. small, which is often unrelated to ipv4-rich vs. ipv4-small (think cogent). in the absence of a market-like transfer policy, ipv4-rich means latently-larger whereas ipv4-poor means latenyly- smaller, unless and only unless the ipv4-poor start out so large that they make a "voting bloc" that content providers will pander do by dual-stacking. at the moment i don't see any ipv4-poor. and, alain durand's mechanisms may work so well that ipv6-only endpoints can work as well as ipv4-natted endpoints work now, but with the added advantage of using ipv6 where the other end speaks it (think gaming and peer-to-peer, where both-ends-natted is painful, and where there is no content provider per se). there may in other words be a soft landing in spite of the things we all don't do, and the routing table growth will continue to be nonexplosively incremental the way it has been for the last ten years. the networks who have to grow to live are not going to wait for IETF or ARIN to save them, and they aren't going to come to ARIN with proposals that would save them, they're just going to engineer their way around it, exactly as happened with NAT. From rjoffe at centergate.com Sun Feb 10 09:50:54 2008 From: rjoffe at centergate.com (Rodney Joffe) Date: Sun, 10 Feb 2008 07:50:54 -0700 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: <47AE445D.6010202@rancid.berkeley.edu> References: <20080209133943.GA54068@ussenterprise.ufp.org> <20080209191140.GA18897@vacation.karoshi.com.> <20080209225608.GA20753@vacation.karoshi.com.> <47AE445D.6010202@rancid.berkeley.edu> Message-ID: To throw a little accelerant on the fire.... http://www.icann.org/announcements/announcement-2-10feb08.htm "ICANN Recovers Large Block of Internet Address Space 16 million unused IPv4 address now available for use on the Internet 10 February 2008 MARINA DEL REY, Calif.: The Internet Corporation for Assigned Names and Numbers has found a little breathing room in the IPv4 address space with its recovery of a block of 16 million IPv4 addresses. The IP addresses recovered were once used to connect older protocol packet-data networks with the fledgling Internet. The block of addresses, technically referred to as 14.0.0.0/8, is also known as Net-14. " ... Perhaps we'll begin to see a little more of this. From leo.vegoda at icann.org Sun Feb 10 10:43:51 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Sun, 10 Feb 2008 07:43:51 -0800 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: References: <20080209133943.GA54068@ussenterprise.ufp.org> <20080209191140.GA18897@vacation.karoshi.com.> <20080209225608.GA20753@vacation.karoshi.com.> <47AE445D.6010202@rancid.berkeley.edu>, Message-ID: <5751D739B8779944939698FBC816B7CE214F9889C9@EXVMBX016-2.exch016.msoutlookonline.net> Hi, Rodney Joffe wrote: > MARINA DEL REY, Calif.: The Internet Corporation for Assigned Names > and Numbers has found a little breathing room in the IPv4 address > space with its recovery of a block of 16 million IPv4 addresses. > > The IP addresses recovered were once used to connect older protocol > packet-data networks with the fledgling Internet. The block of > addresses, technically referred to as 14.0.0.0/8, is also known as > Net-14. " ... > > Perhaps we'll begin to see a little more of this. I think it is unlikely that we'll see any more whole /8s returned to the IANA, although it's possible that longer prefixes could be returned to a free pool and be made available for allocation to someone else. But as I wrote here, that address recovery is unlikely to extend the free pools' lifetimes by more than a few months. http://blog.icann.org/?p=271 Regards, Leo From michael.dillon at bt.com Sun Feb 10 16:25:35 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 10 Feb 2008 21:25:35 -0000 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: <47AD35BA.3030807@psg.com> References: <4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org> <47AD35BA.3030807@psg.com> Message-ID: > what does it take to make your enterprise dual stack? Where will your enterprise get the IPv4 addresses required to go dual stack? There are many companies whose networks are not growing and for these companies, dual-stacking is a possibility although it does tend to lock them into not growing their network. But for ISPs, whose network is constantly growing, and for whom growth is a part of the network model, dual-stack is a risky approach. Of course, if you lose IPv4 customers then you can use those addresses to continue growing your network but this cannibalisation strategy is complex and risky. If a network operator has already moved to MPLS in the core, or is in a position to implement MPLS without great pain over the next couple of years, then they can painlessly implement IPv6 services using 6PE with no requirement to dual-stack. And even if a network does not go to MPLS, you can implement something similar to 6PE using GRE tunnels or PWE3 to interconnect IPv6 edge routers across an IPv4 core. These strategies using 6PE, GRE or PWE3 allow you to limit the impact of IPv6 to only those PoPs and devices that are needed to provide IPv6 service. This makes it easier to incrementally add IPv6 to the network as and when needed. > we went in early, in fact the earliest commercial roll. and > we have regressed, i.e. some services are not maintained over > ipv6 that used to be because no one used them and they caused > pain. We have done similar, i.e. shutting down the UK6x exchange because there was no business case to keep it going. Also because it was research and there is no need for basic IPv6 networking research any more. It's ready for production and we had customers wanting to buy commercial IPv6 services, so we are in the process of migrating the IPv6 services to a proper commercial footing. Right now the demand is for IPv6 access to the IPv6 Internet so that is what we are providing. The demand is not there to provide SMTP over IPv6 so we don't bother with that right now. I expect that within a couple of years there will be customer demand for email delivery over IPv6 and we will provide some kind of SMTP proxy service with DNSBL etc. A lot of people are complaining that IPv6 is a problem because there are still some IPv4 services that are not usable over IPv6 yet. This is a red herring, since these kinds are services are easy to make available, once the demand is there. --Michael Dillon From michael.dillon at bt.com Sun Feb 10 16:32:48 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 10 Feb 2008 21:32:48 -0000 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparentlynoone." In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com> Message-ID: > I'm an ISP customer. My IPv4 network isn't growing (maybe I > add a /28 per year). Tell me why I care about IPv6. A) If your ISP does not have IPv6 services ready when they can't get IPv4 addresses any more, they will be unable to add new customers. When word of this gets out, and it will, then they will begin to lose customers who are nervous about the whole situation, and that could lead to bankruptcy, and to you losing your upstream connection on short notice. B) You probably don't need to care a whole lot about IPv6 yet. For an end customer whose network is not growing and who can rely on their ISP for gateway services to the IPv6 Internet, there is no big crisis looming. There will be rough waters in two years, but many companies will keep on trucking without being IPv6 pioneers. --Michael Dillon From ppml at rs.seastrom.com Sun Feb 10 16:51:57 2008 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Sun, 10 Feb 2008 16:51:57 -0500 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: <47ADBA2E.9030303@psg.com> (Randy Bush's message of "Sat, 09 Feb 2008 23:35:26 +0900") References: <4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org> <47AD35BA.3030807@psg.com> <47ADB11A.3070409@psg.com> <47ADBA2E.9030303@psg.com> Message-ID: <86tzkga39e.fsf@seastrom.com> Randy Bush writes: > so i am gonna sit here and sulk and whine loud and long until the iana > and opensrs/tucows fix it. :) Amen. I want @!$^@%$ v6 glue for my nameservers to go with my v6 hostnames. This is not rocket science. d75:~ rs$ dig +short seastrom.com. mx 10 valhalla.seastrom.com. d75:~ rs$ dig +short valhalla.seastrom.com. aaaa 2610:178:1:1:203:47ff:fe94:2c10 d75:~ rs$ dig +short seastrom.com. ns asgard.seastrom.com. alfheim.seastrom.com. bifrost.seastrom.com. d75:~ rs$ dig +short asgard.seastrom.com. aaaa d75:~ rs$ dig +short bifrost.seastrom.com. aaaa d75:~ rs$ dig +short alfheim.seastrom.com. aaaa d75:~ rs$ This is holding up progress. Elliott, Ross, are you guys with the program or do I need to find a new registrar and tell all my friends to do the same? ---rob From mksmith at adhost.com Sun Feb 10 17:11:36 2008 From: mksmith at adhost.com (Michael Smith) Date: Sun, 10 Feb 2008 14:11:36 -0800 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently noone." In-Reply-To: References: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com> Message-ID: <0ECB41A1-17E9-49E7-8011-85925869ABE8@adhost.com> On Feb 9, 2008, at 9:35 AM, Paul Vixie wrote: > jcurran at istaff.org (John Curran) writes: > >> At 10:05 AM -0500 2/9/08, Howard, W. Lee wrote: >>> I'm an ISP customer. My IPv4 network isn't growing (maybe >>> I add a /28 per year). Tell me why I care about IPv6. >> >> You don't, until some ISP is wedged in such a tight corner that >> they need to connect new customers with just IPv6 (because >> they can't seem to obtain&route additional IPv4 space at any >> realistic cost). >> ... > > so there's an opportunity here for IPv4-rich ISP's to delay their > own IPv6 transition, including dual-stack, so as to acquire customers > and cash flows from IPv4-poor ISP's, during a transition period that > can be deliberately extended by such delay? > -- > Paul Vixie Indeed. As a smaller hosting company, I have need for a /19 every 12 months or so. My guess is I *might* be able to get one more before the pool is gone, given the rate of uptake from the big guys. I'm implementing IPv6 now across our network, but no one is requesting IPv6 services (well, one guy for testing). So, here's the scenario I see. 1) None of the big content players implement IPv6 because "there is no demand." 2) None of the big eyeball providers get full-on IPv6 support for any number of reasons. 3) IPv4 addresses run out 4) (1) and (2) above have a reasonable reserve to carry them for some period of time. 5) Smaller content providers have to start putting hosts on IPv6 only because they're out of addresses. New customer doesn't sign up because they know that they are not reachable by most folks. Since most of our sites are SSL-enabled, we really can't use shared-IP resources for these hosts, so this is a very real problem. 6) Little provider tanks or is purchased for pennies on the dollar. The is not a problem that is going to be solved by a bunch of small to medium size providers taking up the torches and threatening to burn down the village. If the big players, both on the network and content side don't take the lead and start implementing and espousing the benefits of IPv6 it's going to be hell for the rest of us. I hope this is not the business plan of bigger players. Regards, Mike Smith Adhost Internet, LLC From jmaimon at chl.com Sun Feb 10 17:12:57 2008 From: jmaimon at chl.com (Joe Maimon) Date: Sun, 10 Feb 2008 17:12:57 -0500 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparentlynoone." In-Reply-To: References: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com> Message-ID: <47AF76E9.8010805@chl.com> michael.dillon at bt.com wrote: >>I'm an ISP customer. My IPv4 network isn't growing (maybe I >>add a /28 per year). Tell me why I care about IPv6. > > > A) If your ISP does not have IPv6 services ready when they can't > get IPv4 addresses any more, they will be unable to add new > customers. There are more than enough tricks for an ISP to keep going in the face of global ipv4 shortage crunch, which will probably happen akin to a series of ever higher brick walls that will be hit and then scaled over. 1) Loosen up allocation requirements now 2) Churn will free them up when they are needed more 3) Scavenge all /30 public serial assignments 4) Offer unnumbered serial networking, possibly one public Loopback. 5) Offer only loopback public IP addresses or one to one natted over a barrier private network for the most common case of deployment. 6) customer firewalls become more uniformly usable with the only public ip addresses on loopback interfaces 7) Bring your own IP. Lots of different examples for this, I am specificaly referring to situations where ISP A has the customers and turns them up through ISP B, who up to the crunch was kind enough to address them out of B space, but will most likely not do that anymore. 8) /24 will likely cease to be a de-facto cutoff point from the BGP table if this continues past a certain point 8) Cross ISP tunneling of customer-carried-with IP blocks will likely become more common, if/when burden of providing anything more than de-minimis ipv4 addresses falls to the customer. So for an example, an ISP who normal mode of assignment works like this. T1/Leased line Customer, one /30 for WAN and one /29 for LAN, where the customer has its own firewall, can conceivably replace this inefficient waste of space with a couple /32's routed to loopback or over rfc1918 barrier networks. Scavenge/Churn one customer, turn up three to six more. Broadband aggregation? Convert all your applicable users (all broadband agg ISP's have large percentages of these) to rfc1918, stick them behind a nat. Offer them ipv6 if they even want it. Easily done with pppoe customers. Offer inbound port by port incoming service for that class of customer. Pain? Effort? Aggravation? Greater turnup complexity? Yes to all of the above. But if resistance to ipv6 conversion continues, it may well prove to be worth it, for at least some ISP's. And if most ISP's are in the same boat at the same time, then it wont be the huge competitive advantage it might otherwise be. Globaly, there will be plenty of scavenging opportunities. And when the first brick wall in ipv4 availability is hit, allocation guidelines will probably change dramatically. The resulting scavenging will then have a much higher impact then, than it were, would it be done now, with current allocation guidelines. Those with space from before will conceivably get much greater ground from these scavenging and miserly assignemnt strategies after the first brick wall is hit. I think its unlikely that global ipv4 shortage would result in any technicaly proficient ISP from being able to turn up most new customers. As a side benefit, the more pain involved in continuing with ipv4 deployments, the more traction ipv6 will gain. The real question I see, is does it become a good idea to preempt the scavenging neccessity and clamp the allocations and guidelines to produce scavenging sooner rather than later? Sorta like highway driving while running low on gas, looking for that gas station open late night....when do you put the higher mpg tricks into effect, before or after you are in high adrenalin mode? Joe From jcurran at istaff.org Sun Feb 10 21:08:05 2008 From: jcurran at istaff.org (John Curran) Date: Sun, 10 Feb 2008 21:08:05 -0500 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently noone." In-Reply-To: <0ECB41A1-17E9-49E7-8011-85925869ABE8@adhost.com> References: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com> <0ECB41A1-17E9-49E7-8011-85925869ABE8@adhost.com> Message-ID: At 2:11 PM -0800 2/10/08, Michael Smith wrote: >... >So, here's the scenario I see. > >1) None of the big content players implement IPv6 because "there is no >demand." >2) None of the big eyeball providers get full-on IPv6 support for any >number of reasons. >3) IPv4 addresses run out >4) (1) and (2) above have a reasonable reserve to carry them for some >period of time. >5) Smaller content providers have to start putting hosts on IPv6 only >because they're out of addresses. So, (obligatory question), is there a change to allocation policy which would address your concern? /John From kloch at kl.net Sun Feb 10 21:29:38 2008 From: kloch at kl.net (Kevin Loch) Date: Sun, 10 Feb 2008 21:29:38 -0500 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: References: <4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org> <47AD35BA.3030807@psg.com> <47ADB11A.3070409@psg.com> Message-ID: <47AFB312.7020200@kl.net> John Curran wrote: > At 10:56 PM +0900 2/9/08, Randy Bush wrote: >>> We haven't put the MX records in yet, but that is in progress. >> and you don't seem to have the AAAAs for the nameservers. when you do, you may have some hope of getting glue at the parent, as you use netsol as a registrar. but do tell how that one goes. > >>From the Nanog thread, it's clear the versign/registry can handle such, > so if it's just phone loops with netsol/registrar to get them to push the > glue, I've got quite a bit of patience... I'll make sure to provide any > updates/insights to Jeroen for the Sixxs-IPv6glue page. Who knows, > if we end up changing registrars over it, it'll be one more data point > for netsol to consider support. I just went through this with Enom. Their web app lets you set IPv6 OR IPv4 address glue for nameservers but not both at the same time. A support ticket was resolved within 24 hours with some engineer manually adding the AAAA record. - Kevin From jlewis at lewis.org Sun Feb 10 21:45:37 2008 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 10 Feb 2008 21:45:37 -0500 (EST) Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently noone." In-Reply-To: References: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com> <0ECB41A1-17E9-49E7-8011-85925869ABE8@adhost.com> Message-ID: On Sun, 10 Feb 2008, John Curran wrote: > At 2:11 PM -0800 2/10/08, Michael Smith wrote: >> ... >> So, here's the scenario I see. >> >> 1) None of the big content players implement IPv6 because "there is no >> demand." Some of them will/already have because they have massive deployments of "back-end" servers and not enough IPv4 addresses to easily manage them all, yet they don't use IPv6 for public facing machines. >> 3) IPv4 addresses run out >> 5) Smaller content providers have to start putting hosts on IPv6 only >> because they're out of addresses. Before that happens, as mentioned, we're going to get awfully stingy and creative with IP assignments, and use more NAT. But eventually, we're going to hit the wall and unless there are significant changes to the way IPv4 addressing/utilization is handled, we just won't be able to get more IPv4. Interestingly, at an interview I had just months ago with a senior network engineer with a household name .com who's stock has never split, I was told the above scenario will never happen...that we're just not going to run out of IPv4 addresses and that there's never going to be a need for IPv6 in general on the internet. I don't know where he thinks we're going to get IPv4 addresses from when ARIN and the other RIRs tell us they have no more to give us. Maybe he thinks that'll never happen either. > So, (obligatory question), is there a change to allocation > policy which would address your concern? I don't see how that's going to affect the top content providers as long as they have enough public IPv4 to keep their public facing systems online. I don't know how you get their heads out of the sand. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From plzak at arin.net Mon Feb 11 00:19:08 2008 From: plzak at arin.net (Ray Plzak) Date: Mon, 11 Feb 2008 00:19:08 -0500 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently noone." In-Reply-To: References: <369EB04A0951824ABE7D8BAC67AF9BB408841969@CL-S-EX-1.stanleyassociates.com> Message-ID: > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > John Curran > Sent: Saturday, February 09, 2008 10:16 AM > To: Howard, W. Lee > Cc: Public Policy Mailing List > Subject: Re: [ppml] "Who's afraid of IPv4 address depletion? Apparently > noone." > > end-to-end IP... Does this matter to you? I guess it depends on > how a given business interacts with its suppliers and customers. It might matter to grandma who wants to webcam/chat with the grandkids or the person who wants to do uTube or etc. Ray > > /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 mje at pop.co.za Mon Feb 11 03:14:53 2008 From: mje at pop.co.za (Mark Elkins) Date: Mon, 11 Feb 2008 10:14:53 +0200 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: <86tzkga39e.fsf@seastrom.com> References: <4E6BB0C5-1E43-41A5-B0C7-08A38296868B@virtualized.org> <47AD35BA.3030807@psg.com> <47ADB11A.3070409@psg.com> <47ADBA2E.9030303@psg.com> <86tzkga39e.fsf@seastrom.com> Message-ID: <1202717693.2836.18.camel@localhost> On Sun, 2008-02-10 at 16:51 -0500, Robert E. Seastrom wrote: > Randy Bush writes: > > > so i am gonna sit here and sulk and whine loud and long until the iana > > and opensrs/tucows fix it. :) > > Amen. I want @!$^@%$ v6 glue for my nameservers to go with my v6 > hostnames. This is not rocket science. > > d75:~ rs$ dig +short seastrom.com. mx > 10 valhalla.seastrom.com. > d75:~ rs$ dig +short valhalla.seastrom.com. aaaa > 2610:178:1:1:203:47ff:fe94:2c10 > d75:~ rs$ dig +short seastrom.com. ns > asgard.seastrom.com. > alfheim.seastrom.com. > bifrost.seastrom.com. > d75:~ rs$ dig +short asgard.seastrom.com. aaaa > d75:~ rs$ dig +short bifrost.seastrom.com. aaaa > d75:~ rs$ dig +short alfheim.seastrom.com. aaaa > d75:~ rs$ > > This is holding up progress. Elliott, Ross, are you guys with the > program or do I need to find a new registrar and tell all my friends > to do the same? As CO.ZA (Commercial, South Africa) has added the facility for adding IPv6 glue (without excluding IPv4 at the same time!), doing all the same checks over IPv6 transport for IPv6 nameservers in the same way checks are done to IPv4 nameservers, I see no reason that other registry systems can not do the same. I agree - like (dual-stack) access to content, registries need to be both IPv6 accessible and able to deal with both IPv4 and IPv6 glue. (One issue left is its 2001:43f8:30::/48 address is only 87% visible - according to www.sixxs.net tools.. - but thats another problem) -- . . ___. .__ Posix Systems - Sth Africa /| /| / /__ mje at posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 From info at arin.net Mon Feb 11 10:58:40 2008 From: info at arin.net (Member Services) Date: Mon, 11 Feb 2008 10:58:40 -0500 Subject: [ppml] Policy Proposal: Loophole Closure for 2007-21 Message-ID: <47B070B0.8090901@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision via the PPML. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC shepherds for this proposal are Owen DeLong and Suzanne Woolf. The AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Loophole Closure for 2007-21 Author: Scott Leibrand, Owen DeLong Proposal Version: 1.0 Submission Date: 2008-02-07 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: The adopted wording of 2007-21 created a loophole allowing a resource holder to qualify under the policy with only one resource subject to RSA. This small change would close that loophole and bring policy in line with the original intent of the author. Timetable for implementation: immediate From info at arin.net Mon Feb 11 10:59:24 2008 From: info at arin.net (Member Services) Date: Mon, 11 Feb 2008 10:59:24 -0500 Subject: [ppml] Policy Proposal: Community Networks IPv6 Allocation Message-ID: <47B070DC.2020606@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision via the PPML. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC shepherds for this proposal are Lea Roberts and Stacy Taylor. The AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Community Networks IPv6 Allocation Author: Joshua King Proposal Version:1.0 Submission Date:February 7th, 2008 Proposal type:new Policy term:permanent Policy statement: Under this policy, ARIN would adopt a new IPv6 address allocation policy that allows community networking projects to acquire space in a straightforward and affordable manner. The policy will establish an allocation template modeled on the experimental allocation template, with all applicable ARIN fees aimed at affordability (for instance, totaling not more than $500 USD). The aim is to prevent this policy from becoming a less-expensive option for for-profit ISPs, and tailor it to address the concerns of the kinds of organizations that run these projects. Organizations would have the option of either acquiring blocks for their own use, or distributing address space to other community networks that are unable to deal with the administrative and technical overhead of address management. A community network prefix would need to be established, providing a subnet of sufficient size to serve such projects for the foreseeable future. Block sizes of /48 and larger would be available on the basis of a justification of project goals, with an eye towards: 1. Use by non-profit organizations. 2. Projects aimed at low-income users. 3. Open-source software development. 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 info at arin.net Mon Feb 11 11:02:32 2008 From: info at arin.net (Member Services) Date: Mon, 11 Feb 2008 11:02:32 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal Message-ID: <47B07198.2050106@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision via the PPML. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC shepherds for this proposal are Scott Leibrand and Stacy Taylor. The AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv4 Transfer Policy Proposal Author: ARIN Advisory Council Proposal Version: 1.0 Submission Date: 02/07/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 ?M&A Transfer Requirements?: 8.2. M&A Transfer Requirements 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.] [8.3 ? retitle to ?M&A Transfer Documentation Requirements?: 8.3. M&A Transfer Documentation Requirements 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.4. Requirements for Simple Transfer of IPv4 Addresses After the exhaustion of the IANA IPv4 free pool, ARIN will also process IPv4 address transfer requests subject to the following conditions. 8.4.1 Conditions on the transferor: * 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.4.2 Conditions on the transferee: * 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 2 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 only receive one IPv4 address transfer every 6 months. 8.4.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. 8.4.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.4.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 exact network address and size (CIDR prefix length) the transferor is eligible to provide, and the expiration date of the pre-qualification. 8.5. Safe Harbor for IPv4 Transfers through this Simple Transfer Process IPv4 address resources being made available for transfer shall be exempt from ARIN audit until expiration of the transfer pre-qualification or completion of the transfer. In the event that a transfer pre-qualification expires, ARIN shall have up to 90 days to initiate an audit prior to this exemption being reinstated through subsequent transfer pre-qualification. This will not extend the end of the exemption. 8.6. 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.7. 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. 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 bicknell at ufp.org Mon Feb 11 11:09:31 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 11 Feb 2008 11:09:31 -0500 Subject: [ppml] Policy Proposal 2007-22: Expand timeframe of Additional Requests - Second Last Call In-Reply-To: <47AB4195.6050904@arin.net> References: <47AB4195.6050904@arin.net> Message-ID: <20080211160931.GB33688@ussenterprise.ufp.org> Typically proposals in last call receive very few comments. I would like to think this is a result of our policy process being quite successful and leaving very little to discuss during the last call time. In this particular case there was some confusion over language. This was due to changes at the meeting and due to a mistake in getting the text posted to PPML. Because of this, the AC would find it useful in this particular case for several people to chime in with "yes, we believe that was the proposal we discussed, and yes, we believe there was community support." Of course, if you believe that was not the case, feel free to post your opinion as well. We're working behind the scenes to try and make sure this never happens again. Our apologies for the mix 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 info at arin.net Mon Feb 11 11:35:27 2008 From: info at arin.net (Member Services) Date: Mon, 11 Feb 2008 11:35:27 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal Message-ID: <47B0794F.40205@arin.net> Resending with a typo that has been corrected in 8.4.2 below. The original text is supposed to have "24 months" twice in that section. Member Services American Registry for Internet Numbers (ARIN) ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision via the PPML. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC shepherds for this proposal are Scott Leibrand and Stacy Taylor. The AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv4 Transfer Policy Proposal Author: ARIN Advisory Council Proposal Version: 1.0 Submission Date: 02/07/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 ?M&A Transfer Requirements?: 8.2. M&A Transfer Requirements 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.] [8.3 ? retitle to ?M&A Transfer Documentation Requirements?: 8.3. M&A Transfer Documentation Requirements 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.4. Requirements for Simple Transfer of IPv4 Addresses After the exhaustion of the IANA IPv4 free pool, ARIN will also process IPv4 address transfer requests subject to the following conditions. 8.4.1 Conditions on the transferor: * 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.4.2 Conditions on the transferee: * 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 only receive one IPv4 address transfer every 6 months. 8.4.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. 8.4.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.4.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 exact network address and size (CIDR prefix length) the transferor is eligible to provide, and the expiration date of the pre-qualification. 8.5. Safe Harbor for IPv4 Transfers through this Simple Transfer Process IPv4 address resources being made available for transfer shall be exempt from ARIN audit until expiration of the transfer pre-qualification or completion of the transfer. In the event that a transfer pre-qualification expires, ARIN shall have up to 90 days to initiate an audit prior to this exemption being reinstated through subsequent transfer pre-qualification. This will not extend the end of the exemption. 8.6. 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.7. 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. 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 Lee.Howard at stanleyassociates.com Mon Feb 11 11:56:29 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Mon, 11 Feb 2008 11:56:29 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B0794F.40205@arin.net> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB408841E6E@CL-S-EX-1.stanleyassociates.com> I'm not commenting on the merit of the proposal, but on its clarity. > 8.4.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. Is this intended to mean swamp space can remain swampy, but other space can't be subdivided in /24? It looks like it says the block must meet minimum transfer size, unless it's a /24 or larger. > * 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. I can transfer my hypothetical /16 as 254 /24s and keep one for myself? Lee From dlw+arin at tellme.com Mon Feb 11 12:06:26 2008 From: dlw+arin at tellme.com (David Williamson) Date: Mon, 11 Feb 2008 09:06:26 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB408841E6E@CL-S-EX-1.stanleyassociates.com> References: <47B0794F.40205@arin.net> <369EB04A0951824ABE7D8BAC67AF9BB408841E6E@CL-S-EX-1.stanleyassociates.com> Message-ID: <20080211170626.GN8368@shell01.cell.sv2.tellme.com> On Mon, Feb 11, 2008 at 11:56:29AM -0500, Howard, W. Lee wrote: > > 8.4.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. > > Is this intended to mean swamp space can remain swampy, but other > space can't be subdivided in /24? It looks like it says the block > must meet minimum transfer size, unless it's a /24 or larger. I'm also a bit confused by this. It does seem to imply that I cannot get a PI /24 from ARIN directly, but I could get one transferred to me. That seems unexpected. If the intent is to permit resources already allocated at some size that is presently below the minimum requirements (i.e., the swamp), this should get some different verbiage. If the intent is really to permit transfers down to the /24 limit, we should go ahead and change the minimum allocation and assignment sizes to match. For the record, I still think that multi-homed PI users would really like a smaller minimum size than /22. It would certainly promote greater efficiency, albeit at the expense of routing slots, which are going to get consumed anyway for most multi-homed sites. So, what is this supposed to be? -David From owen at delong.com Mon Feb 11 12:09:47 2008 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Feb 2008 09:09:47 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB408841E6E@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB408841E6E@CL-S-EX-1.stanleyassociates.com> Message-ID: <1AF7D7C2-4AF3-431E-9A58-34F81649C5C6@delong.com> On Feb 11, 2008, at 8:56 AM, Howard, W. Lee wrote: > I'm not commenting on the merit of the proposal, but on its > clarity. > > >> 8.4.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. > > Is this intended to mean swamp space can remain swampy, but other > space can't be subdivided in /24? It looks like it says the block > must meet minimum transfer size, unless it's a /24 or larger. > It is meant to prevent the subdivision of anything smaller than the current minimum, but, allow transfers only of /24s or larger. >> * 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. > > I can transfer my hypothetical /16 as 254 /24s and keep one for > myself? > No. You can transfer your hypothetical /16 as follows: Keep 1 /24 Transfer the remaining /24 /23 /22 /21 /20 /19 /18 /17 as separate blocks. That is why we specified "multiple non-aggregatable" blocks. Owen > Lee > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the > ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. From bicknell at ufp.org Mon Feb 11 12:15:23 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 11 Feb 2008 12:15:23 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB408841E6E@CL-S-EX-1.stanleyassociates.com> References: <47B0794F.40205@arin.net> <369EB04A0951824ABE7D8BAC67AF9BB408841E6E@CL-S-EX-1.stanleyassociates.com> Message-ID: <20080211171523.GA37775@ussenterprise.ufp.org> I think you went right to the part of the proposal that's been one of the hardest for the AC to craft. Indeed, there are some discussions going on inside the AC we might have liked to finish before the proposal deadline, but it did not work that way. There are several competing forces under the general umbrella of prefix length size. In no particular order: - Preventing massive deaggregation. We would like to prevent a /8 from showing up in the routing table as 65536 /24's. - Allowing deaggregation. A /8 is not a desireable element on its own, as few would pass the requirements to justify need, and we may have the problem of few being able to afford it. - What role does existing ARIN criteria play? Should we allow deaggregation simply to ARIN's current limits? - What rules are applied to blocks that no longer meet current policy? There were /24's given out in the past, but you can't get one today. - If we limit the amount of deaggregation does that limit the liquidity of the market? Rather than nitpick the language of the current proposal I think the AC would find it more useful if the community could articulate how they want it to work. We have just under 30 more days to adjust the language before 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 tedm at ipinc.net Mon Feb 11 13:05:29 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 11 Feb 2008 10:05:29 -0800 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >John Curran >Sent: Saturday, February 09, 2008 3:35 PM >To: bmanning at vacation.karoshi.com >Cc: Public Policy Mailing List >Subject: Re: [ppml] "Who's afraid of IPv4 address depletion? Apparently >no one." > > >At 10:56 PM +0000 2/9/08, bmanning at vacation.karoshi.com wrote: >> >> i think a safe presumption is that this may be a >> predominant structure as long as there are "arrogant >> twits" who maintain the fiction that only IPv4 transport >> is needed to get to their content/eyeballs. e.g. if >> facebook never supports IPv6 transport, this will be common. >> Facebook will never see IPv6 demand and claim "all is well" >> with IPv4 and the IPv6 hype is just that. > >Facebook, Yahoo!, Google, MSN, Youtube, .... the list goes on and on. >I wouldn't expect any of them to see measurable demand for IPv6 >until there's a sizable IPv6-only user community. > This is the classic chicken-and-egg program or catch-22 as you would have it. And it's an argument easily sidestepped. Yahoo and Facebook don't configure the IPv4 and IPv6 stacks of our customers, so what they have to say about IPv6 deployment is of no consequence. What -I- as the ISP say to my customers is the only thing of any real consequence. When we have a business customer connect to us, 9/10's of the time we are doing the configuration on their routers, and 1/2 of the time we are specing to them what -new- router to buy. I've had customers with perfectly good Cisco devices leftover from their prior ISP tell me they still want to buy a new router, even though I tell them we could reconfigure their old device. That's beside the point, though. If an end-user comes to me and says they want to connect to us via DSL or Dialup or whatever, I'll direct them to the how-to's on our website as to how to configure their system. When the time is ready for IPv6 those how-to's will be re-written to enable all the IPv6 stuff on their system. The end users will blindly follow whatever I or my tech support group tells them to do, and if that means enable IPv6 they will do it. As they don't really understand how IPv4 works, the fact that they don't understand how IPv6 works is of no consequence - none of them are in the position to question my instructions in the first place. For my corporate customers, if I start telling them they have to get new routers to support IPv6, most of them will simply say no problem and do it. Maybe not immediately but eventually. These are customers that are paying me to tell them what they need to do to connect to the Internet, so if I tell them they need to be IPv6 compliant to their firewall (at least) they will do it. I think people are really making this IPv4 <-> IPv6 transition sound far more difficult than it really needs to be. Customers come in 2 categories, informed or ignorant. The vast number are ignorant and they are happy to stay that way - they no more want to know how to configure a router than they want to know how to change the sparkplugs in their car engine. The informed customer, on the other hand, merely needs to be told the cons of remaining IPv4 and left alone to their own devices. The sum fact of it is that the vast majority of customers are just going to do what their ISP tells them to do. If all the ISP's start telling customers to switch over to IPv6, the very small minority of informed customers who want to fight against it based on whatever cost/benefit they come up with, are going to find themselves outnumbered. Much like the network admins who argued against 10BaseT claiming it was no faster than 10Base2, they will be snowed over by the herd. Ted From dlw+arin at tellme.com Mon Feb 11 13:47:36 2008 From: dlw+arin at tellme.com (David Williamson) Date: Mon, 11 Feb 2008 10:47:36 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <20080211171523.GA37775@ussenterprise.ufp.org> References: <47B0794F.40205@arin.net> <369EB04A0951824ABE7D8BAC67AF9BB408841E6E@CL-S-EX-1.stanleyassociates.com> <20080211171523.GA37775@ussenterprise.ufp.org> Message-ID: <20080211184736.GO8368@shell01.cell.sv2.tellme.com> On Mon, Feb 11, 2008 at 12:15:23PM -0500, Leo Bicknell wrote: > Rather than nitpick the language of the current proposal I think > the AC would find it more useful if the community could articulate > how they want it to work. We have just under 30 more days to adjust > the language before the Denver meeting. I'm still contemplating the overall impact of the entire proposal, so this is, at best, a preliminary thought. *If* ARIN is going to get into the transfer process, I agree that the tension between deaggregation and policy is going to be a key problem. I think the intent of the proposal as Owen has outlined it is a reasonable compromise, for now. That is, blocks smaller than the current minimum limits should not be transferred unless they already exist as a unique resource record with ARIN at that sub-minimum size. Additionally, in no case should a block smaller than /24 be transferred. At some point, I suspect the /24 limit will get fuzzy, and we'll need to revisit that. Then again, I think the existing limits are too large. :) I'm not sure that taking a hypothetical /16 and breaking it into completely deaggregated /22s should be against the transfer rules, though. Much as a /16 isn't very useful for most entities, nor is a /17. I think I'm broadly in favor of this proposal at this time, but I need to give it some more thought. -David From raul at lacnic.net Mon Feb 11 15:52:23 2008 From: raul at lacnic.net (Raul Echeberria) Date: Mon, 11 Feb 2008 17:52:23 -0300 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B0794F.40205@arin.net> References: <47B0794F.40205@arin.net> Message-ID: <7.0.1.0.1.20080211164859.05618d40@lacnic.net> Could the author of the proposal explain what is the justification for requiring that the transferee should also belong to ARIN's region? It is only a question and it doesn't imply any specific opinion about the topic. Ra?l At 01:35 p.m. 11/02/2008, Member Services wrote: >Resending with a typo that has been corrected in 8.4.2 below. The >original text is supposed to have "24 months" twice in that section. > >Member Services >American Registry for Internet Numbers (ARIN) > > > > >ARIN received the following policy proposal. In accordance with the ARIN >Internet Resource Policy Evaluation Process, the proposal is being >posted to the ARIN Public Policy Mailing List (PPML) and being placed on >ARIN's website. > >The ARIN Advisory Council (AC) will review this proposal at their next >regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as written. If the AC accepts the proposal, it >will be posted as a formal policy proposal to PPML and it will be >presented at a Public Policy Meeting. > > 2. Not accept the proposal. If the AC does not accept the proposal, >the AC will explain their decision via the PPML. If a proposal is not >accepted, then the author may elect to use the petition process to >advance their proposal. If the author elects not to petition or the >petition fails, then the proposal will be closed. > >The AC shepherds for this proposal are Scott Leibrand and Stacy Taylor. > >The AC invites everyone to comment on this proposal on the PPML, >particularly their support or non-support and the reasoning behind their >opinion. Such participation contributes to a thorough vetting and >provides important guidance to the AC in their deliberations. > >The ARIN Internet Resource Policy Evaluation Process can be found at: >http://www.arin.net/policy/irpep.html > >Mailing list subscription information can be found at: >http://www.arin.net/mailing_lists/ > >Regards, > >Member Services >American Registry for Internet Numbers (ARIN) > > >## * ## > > >Policy Proposal Name: IPv4 Transfer Policy Proposal > >Author: ARIN Advisory Council > >Proposal Version: 1.0 > >Submission Date: 02/07/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 ?M&A Transfer Requirements?: > >8.2. M&A Transfer Requirements > >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.] > > >[8.3 ? retitle to ?M&A Transfer Documentation Requirements?: > >8.3. M&A Transfer Documentation Requirements > >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.4. Requirements for Simple Transfer of IPv4 Addresses > >After the exhaustion of the IANA IPv4 free pool, ARIN will also process >IPv4 address transfer requests subject to the following conditions. > >8.4.1 Conditions on the transferor: > > * 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.4.2 Conditions on the transferee: > > * 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 only receive one IPv4 address transfer every 6 > months. > > > >8.4.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. > >8.4.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.4.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 exact network address and size > (CIDR prefix length) the transferor is eligible to provide, and > the expiration date of the pre-qualification. > >8.5. Safe Harbor for IPv4 Transfers through this Simple Transfer >Process > >IPv4 address resources being made available for transfer shall be exempt >from ARIN audit until expiration of the transfer pre-qualification or >completion of the transfer. In the event that a transfer >pre-qualification expires, ARIN shall have up to 90 days to initiate an >audit prior to this exemption being reinstated through subsequent >transfer pre-qualification. This will not extend the end of the exemption. > >8.6. 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.7. 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. > >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. > > >-- >No virus found in this incoming message. >Checked by AVG Free Edition. >Version: 7.5.516 / Virus Database: 269.20.2/1271 >- Release Date: 11/02/2008 08:16 a.m. From sleibrand at internap.com Mon Feb 11 15:15:54 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 11 Feb 2008 14:15:54 -0600 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <7.0.1.0.1.20080211164859.05618d40@lacnic.net> References: <47B0794F.40205@arin.net> <7.0.1.0.1.20080211164859.05618d40@lacnic.net> Message-ID: <47B0ACFA.5070202@internap.com> Raul, I can speak as an author, but not for the entire AC (which, collectively, are the authors): The global policy framework basically allows three types of policies: local to a single RIR, globally coordinated, or global. The latter require consensus among multiple RIRs as to a course of action, which tends to be an extended process that only moves forward if there is significant consensus around an issue, and even then fairly slowly. For that reason, we didn't want to make this a globally coordinated or global policy at this time. If we were to allow transferees from outside ARIN's service region, and not make this a globally coordinated policy (to coordinate transfer of the registration to the local RIR), we would open up the possibility of "registry shopping", encouraging organizations to go to RIRs outside their region to get IPv4 space. This would defeat the purpose of having a local RIR in the first place. My own personal crystal ball shows a possible future where several RIRs each adopt their own transfer policy, with somewhat different conditions and requirements, to meet their own membership's needs. We would then need to do some inter-RIR coordination to enable some sort of inter-region transfer, and work out all the details of how records would be kept current in such a scenario, and which RIR each organization would deal with. So, in summary, this is a first attempt at getting something reasonable in place in the ARIN region, and I fully expect to work with other RIRs to make arrangements for transferring space between regions as well. -Scott Raul Echeberria wrote: > Could the author of the proposal explain what is > the justification for requiring that the > transferee should also belong to ARIN's region? > It is only a question and it doesn't imply any > specific opinion about the topic. > > Ra?l > > > > > > At 01:35 p.m. 11/02/2008, Member Services wrote: > >> Resending with a typo that has been corrected in 8.4.2 below. The >> original text is supposed to have "24 months" twice in that section. >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> >> >> ARIN received the following policy proposal. In accordance with the ARIN >> Internet Resource Policy Evaluation Process, the proposal is being >> posted to the ARIN Public Policy Mailing List (PPML) and being placed on >> ARIN's website. >> >> The ARIN Advisory Council (AC) will review this proposal at their next >> regularly scheduled meeting. The AC may decide to: >> >> 1. Accept the proposal as written. If the AC accepts the proposal, it >> will be posted as a formal policy proposal to PPML and it will be >> presented at a Public Policy Meeting. >> >> 2. Not accept the proposal. If the AC does not accept the proposal, >> the AC will explain their decision via the PPML. If a proposal is not >> accepted, then the author may elect to use the petition process to >> advance their proposal. If the author elects not to petition or the >> petition fails, then the proposal will be closed. >> >> The AC shepherds for this proposal are Scott Leibrand and Stacy Taylor. >> >> The AC invites everyone to comment on this proposal on the PPML, >> particularly their support or non-support and the reasoning behind their >> opinion. Such participation contributes to a thorough vetting and >> provides important guidance to the AC in their deliberations. >> >> The ARIN Internet Resource Policy Evaluation Process can be found at: >> http://www.arin.net/policy/irpep.html >> >> Mailing list subscription information can be found at: >> http://www.arin.net/mailing_lists/ >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Policy Proposal Name: IPv4 Transfer Policy Proposal >> >> Author: ARIN Advisory Council >> >> Proposal Version: 1.0 >> >> Submission Date: 02/07/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 ?M&A Transfer Requirements?: >> >> 8.2. M&A Transfer Requirements >> >> 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.] >> >> >> [8.3 ? retitle to ?M&A Transfer Documentation Requirements?: >> >> 8.3. M&A Transfer Documentation Requirements >> >> 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.4. Requirements for Simple Transfer of IPv4 Addresses >> >> After the exhaustion of the IANA IPv4 free pool, ARIN will also process >> IPv4 address transfer requests subject to the following conditions. >> >> 8.4.1 Conditions on the transferor: >> >> * 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.4.2 Conditions on the transferee: >> >> * 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 only receive one IPv4 address transfer every 6 >> months. >> >> >> >> 8.4.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. >> >> 8.4.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.4.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 exact network address and size >> (CIDR prefix length) the transferor is eligible to provide, and >> the expiration date of the pre-qualification. >> >> 8.5. Safe Harbor for IPv4 Transfers through this Simple Transfer >> Process >> >> IPv4 address resources being made available for transfer shall be exempt >> > >from ARIN audit until expiration of the transfer pre-qualification or > >> completion of the transfer. In the event that a transfer >> pre-qualification expires, ARIN shall have up to 90 days to initiate an >> audit prior to this exemption being reinstated through subsequent >> transfer pre-qualification. This will not extend the end of the exemption. >> >> 8.6. 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.7. 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. >> >> 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. >> >> >> -- >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.516 / Virus Database: 269.20.2/1271 >> - Release Date: 11/02/2008 08:16 a.m. >> > > > _______________________________________________ > 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 gih at apnic.net Mon Feb 11 16:51:52 2008 From: gih at apnic.net (Geoff Huston) Date: Tue, 12 Feb 2008 08:51:52 +1100 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <7.0.1.0.1.20080211164859.05618d40@lacnic.net> References: <47B0794F.40205@arin.net> <7.0.1.0.1.20080211164859.05618d40@lacnic.net> Message-ID: <47B0C378.8090401@apnic.net> Raul Echeberria wrote: > Could the author of the proposal explain what is > the justification for requiring that the > transferee should also belong to ARIN's region? > It is only a question and it doesn't imply any > specific opinion about the topic. > > Ra?l > Raul has not asked this more generally, but as the proposer of a similar address transfer policy in APNIC that also has a similar restriction (APNIC members only) I should add a note about why this restriction is present in the APNIC transfer policy proposal. In the APNIC case its about the regional address policy group being able to define policy for themselves. In this case the policy proposal has not been submitted as a coordinated policy across the RIRs nor as a proposed global polic. It was submitted to the APNIC policy development process as a proposed APNIC policy that would apply to APNIC members. That said, I now notice that there are similar proposals in both the ARIN and RIPE regions, so it may be possible during the course of the consideration of these proposals to assess to what extent such transfer mechanisms could be extended to encompass transfers across RIRs, as Scott Leibrand has already indicated in his response to Raul. Geoff From sleibrand at internap.com Mon Feb 11 16:57:33 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 11 Feb 2008 15:57:33 -0600 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B0C378.8090401@apnic.net> References: <47B0794F.40205@arin.net> <7.0.1.0.1.20080211164859.05618d40@lacnic.net> <47B0C378.8090401@apnic.net> Message-ID: <47B0C4CD.1010005@internap.com> Geoff Huston wrote: > That said, I now notice that there are similar proposals in both the > ARIN and RIPE regions, so it may be possible during the course of the > consideration of these proposals to assess to what extent such transfer > mechanisms could be extended to encompass transfers across RIRs, as > Scott Leibrand has already indicated in his response to Raul. > Do you think that the consideration of transfer mechanisms should occur now, during the initial consideration of the separate proposals, or after the adoption of two or more transfer policy proposals (but hopefully before IANA exhaustion)? Given how complex the issue is just within each RIR, I can definitely see arguments for the latter, but am wondering if others see compelling reasons to consider those issues now... Thanks, Scott From raul at lacnic.net Mon Feb 11 18:31:34 2008 From: raul at lacnic.net (Raul Echeberria) Date: Mon, 11 Feb 2008 20:31:34 -0300 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B0C378.8090401@apnic.net> References: <47B0794F.40205@arin.net> <7.0.1.0.1.20080211164859.05618d40@lacnic.net> <47B0C378.8090401@apnic.net> Message-ID: <7.0.1.0.1.20080211202317.04fe9300@lacnic.net> Geoff. One observation. Accepting transfers only within the region is a way to keep the IP addresses within the regions in which they were originally allocated. I don't know if it is good or not, but a fact. If the transfer of legacy space is also admited, it has a great impact in other regions, since most of the unused space belonging to the legacy blocks, will feed regional markets in the developed countries. This is the promotion of regional markets instead of global markets. My opinion is that the regional approach to a global poblem that is the IPv4 deployment is not the right approach. Ra?l At 06:51 p.m. 11/02/2008, Geoff Huston wrote: >Raul Echeberria wrote: > > Could the author of the proposal explain what is > > the justification for requiring that the > > transferee should also belong to ARIN's region? > > It is only a question and it doesn't imply any > > specific opinion about the topic. > > > > Ra?l > > > >Raul has not asked this more generally, but as >the proposer of a similar address transfer >policy in APNIC that also has a similar >restriction (APNIC members only) I should add a >note about why this restriction is present in >the APNIC transfer policy proposal. > >In the APNIC case its about the regional address >policy group being able to define policy for >themselves. In this case the policy proposal has >not been submitted as a coordinated policy >across the RIRs nor as a proposed global polic. >It was submitted to the APNIC policy development >process as a proposed APNIC policy that would apply to APNIC members. > >That said, I now notice that there are similar >proposals in both the ARIN and RIPE regions, so >it may be possible during the course of the >consideration of these proposals to assess to >what extent such transfer mechanisms could be >extended to encompass transfers across RIRs, as >Scott Leibrand has already indicated in his response to Raul. > >Geoff > > > > >-- >No virus found in this incoming message. >Checked by AVG Free Edition. Version: 7.5.516 / >Virus Database: 269.20.2/1271 - Release Date: 11/02/2008 08:16 a.m. From tedm at ipinc.net Mon Feb 11 17:39:25 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 11 Feb 2008 14:39:25 -0800 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparentlynoone." In-Reply-To: <0ECB41A1-17E9-49E7-8011-85925869ABE8@adhost.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Michael Smith >Sent: Sunday, February 10, 2008 2:12 PM >To: Paul Vixie >Cc: ppml at arin.net >Subject: Re: [ppml] "Who's afraid of IPv4 address depletion? >Apparentlynoone." > > Since >most of our sites are SSL-enabled, we really can't use shared-IP >resources for these hosts, so this is a very real problem. This isn't true. You can use a single SSL certificate for multiple domains on a virtual host using mod_rewrite. The technique is here: http://sweon.net/2008/01/hosting-multiple-ssl-vhosts-on-a-single-ipportcerti ficate-with-apache2 You can simply buy your own SSL cert and charge the customers each a bit for the use of it. Of course, if your business model includes you making a profit by buying SSL certificates in bulk for pennies then selling them to your customers for tons of money, then I can see how you might be a little annoyed. I might also point out that historically, retailers that merely buy and resell add extremely little value and as a result customers tend to find ways around them - you might look at a different business model that has more value add? Ted From bicknell at ufp.org Mon Feb 11 17:42:31 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 11 Feb 2008 17:42:31 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <7.0.1.0.1.20080211202317.04fe9300@lacnic.net> References: <47B0794F.40205@arin.net> <7.0.1.0.1.20080211164859.05618d40@lacnic.net> <47B0C378.8090401@apnic.net> <7.0.1.0.1.20080211202317.04fe9300@lacnic.net> Message-ID: <20080211224231.GA60722@ussenterprise.ufp.org> In a message written on Mon, Feb 11, 2008 at 08:31:34PM -0300, Raul Echeberria wrote: > If the transfer of legacy space is also admited, > it has a great impact in other regions, since > most of the unused space belonging to the legacy > blocks, will feed regional markets in the > developed countries. This is the promotion of > regional markets instead of global markets. Here are a few of the talking points the AC has considered. - Since most of the legacy space is inside the ARIN region if it is kept inside the ARIN region then the ARIN region will have a much longer lifetime for IPv4 than other regions. - Since legacy space is believed to be one of the larger sources of IPv4 resources allowing it to be transferred around the world would do the most good. - If transfers between regions were allowed those in first world countries would likely buy all of the space from second and third world countries, as they have the money to do so. This would shift the cost of transition to IPv6 onto those least likely to have the money to make the transition. It also has a great potential to get world governments involved in the transfer process. The last point is particularly interesting when you look at the various RIR's. Some have a mix of economies in them, others do not. Personally I am quite troubled by the results either way. If someone in a third world country can't get IP's because we don't allow them to be transferred out of our region, that's bad. If some large, rich US corporation comes along and buys up all the IP's from a third world country because it can, I think that's bad too. -- 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 mksmith at adhost.com Mon Feb 11 17:53:11 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Mon, 11 Feb 2008 14:53:11 -0800 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparentlynoone." In-Reply-To: References: <0ECB41A1-17E9-49E7-8011-85925869ABE8@adhost.com> Message-ID: <17838240D9A5544AAA5FF95F8D52031603554FC9@ad-exh01.adhost.lan> Hello: > -----Original Message----- > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > Sent: Monday, February 11, 2008 2:39 PM > To: Michael K. Smith - Adhost; Paul Vixie > Cc: ppml at arin.net > Subject: RE: [ppml] "Who's afraid of IPv4 address depletion? > Apparentlynoone." > > > > >-----Original Message----- > >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > >Michael Smith > >Sent: Sunday, February 10, 2008 2:12 PM > >To: Paul Vixie > >Cc: ppml at arin.net > >Subject: Re: [ppml] "Who's afraid of IPv4 address depletion? > >Apparentlynoone." > > > > > Since > >most of our sites are SSL-enabled, we really can't use shared-IP > >resources for these hosts, so this is a very real problem. > > This isn't true. You can use a single SSL certificate for multiple > domains on a virtual host using mod_rewrite. The technique is here: > > http://sweon.net/2008/01/hosting-multiple-ssl-vhosts-on-a-single- > ipportcerti > ficate-with-apache2 > > You can simply buy your own SSL cert and charge the customers each a > bit for the use of it. > > Of course, if your business model includes you making a profit by > buying SSL certificates in bulk for pennies then selling them to > your customers for tons of money, then I can see how you might be > a little annoyed. I might also point out that historically, retailers > that merely buy and resell add extremely little value and as a result > customers tend to find ways around them - you might look at a different > business model that has more value add? > > Ted I punted to Ted off list about the finer technical points of the above hack. But, I think it does point out an excellent, urm, point. We have more IPv6 addresses than we know what to do with and I'm already well down the path of being able to provide them to my customers. I would gladly do so. And yet, we have to come up with all of these various ways to hack our way into extending the life of IPv4. Why? Regards, Mike Adhost Internet, LLC -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 475 bytes Desc: not available URL: From gih at apnic.net Mon Feb 11 18:04:54 2008 From: gih at apnic.net (Geoff Huston) Date: Tue, 12 Feb 2008 10:04:54 +1100 Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <7.0.1.0.1.20080211202317.04fe9300@lacnic.net> References: <47B0794F.40205@arin.net> <7.0.1.0.1.20080211164859.05618d40@lacnic.net> <47B0C378.8090401@apnic.net> <7.0.1.0.1.20080211202317.04fe9300@lacnic.net> Message-ID: <47B0D496.2030800@apnic.net> Raul Echeberria wrote: > Geoff. > > One observation. > > Accepting transfers only within the region is a > way to keep the IP addresses within the regions > in which they were originally allocated. > I don't know if it is good or not, but a fact. > > If the transfer of legacy space is also admited, > it has a great impact in other regions, since > most of the unused space belonging to the legacy > blocks, will feed regional markets in the > developed countries. This is the promotion of > regional markets instead of global markets. > > My opinion is that the regional approach to a > global poblem that is the IPv4 deployment is not the right approach. > There are two issues that I can readily see here - the first is the issue of defining the mechanics of a cross-rir transfer. and the second is the assessment of the value of the intended outcomes and the risk of other unintended outcomes. Concerning mechanics, in looking at the APNIC and ARIN proposals they both take the approach of "qualification" of the two parties to a transfer. One approach would be to 'recognise' the qualification from another region - i.e. taking an ARIN perspective a "transferor" (is that really an english word? ;-)) meets the criteria listed in section 8.4.1. To extend this to allow cross-RIR transfers it would be a case of adding "or meets the criteria as listed (insert reference to the transfer policy of another RIR) for members of (RIR). Similarly the conditions of the transferee could be augmented by reference to the relevant qualifications in the policies of other RIRs. So in terms of extending the mechanics of the policy proposals to encompass cross-RIR transfers then I'd suggest that there are ways to achieve this though the use of mutual recognition of each RIR's qualification processes. (I should note a slight inaccuracy here from my previous posting - I thought that the presentation at the October 2007 RIPE meeting : http://www.ripe.net/ripe/meetings/ripe-55/presentations/vanmook-v4policy-change.pdf had been submitted into the RIPE policy process as a proposal, but it looks like this has not happened as yet as there is no proposal listed at http://www.ripe.net/ripe/policies/proposals/index.html) The second issue is perhaps the one that deserves further consideration. There is a strong argument in favour of looking at this issues of transfers from a global rather than regional perspective. The regional distribution of IPv4 addresses today, the regional levels of demand for IPv4 addresses, and the projections of demand within each region do not appear to be well-aligned, and an imposition of a regional 'containment' of transfers may well lead to less than desireable outcomes. One question I have is whether a global transfer model would run the risk of unintended outcomes. Would a global transfer domain create inequities and imbalances in the residual IPv4 internet that may require some other form of intervention or mediation to redress? What are the risks of such outcomes, and it is possible to propose some policy mechanisms that may mitigate such risks? regards, Geoff From randy at psg.com Mon Feb 11 18:51:37 2008 From: randy at psg.com (Randy Bush) Date: Tue, 12 Feb 2008 08:51:37 +0900 Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <7.0.1.0.1.20080211202317.04fe9300@lacnic.net> References: <47B0794F.40205@arin.net> <7.0.1.0.1.20080211164859.05618d40@lacnic.net> <47B0C378.8090401@apnic.net> <7.0.1.0.1.20080211202317.04fe9300@lacnic.net> Message-ID: <47B0DF89.9020506@psg.com> > My opinion is that the regional approach to a global problem that is > the IPv4 deployment is not the right approach. bingo! as we joked in the verio days of acquiring many small isps, many seemed to think locally and act globally. randy From stephen at sprunk.org Mon Feb 11 18:34:12 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 11 Feb 2008 17:34:12 -0600 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal References: <47B0794F.40205@arin.net> <7.0.1.0.1.20080211164859.05618d40@lacnic.net><47B0C378.8090401@apnic.net> <47B0C4CD.1010005@internap.com> Message-ID: <01b301c86d0a$7c5f73b0$493816ac@atlanta.polycom.com> Thus spake "Scott Leibrand" > Geoff Huston wrote: >> That said, I now notice that there are similar proposals in both the >> ARIN and RIPE regions, so it may be possible during the course of the >> consideration of these proposals to assess to what extent such transfer >> mechanisms could be extended to encompass transfers across RIRs, as >> Scott Leibrand has already indicated in his response to Raul. > > Do you think that the consideration of transfer mechanisms should occur > now, during the initial consideration of the separate proposals, or > after the adoption of two or more transfer policy proposals (but > hopefully before IANA exhaustion)? Given how complex the issue is just > within each RIR, I can definitely see arguments for the latter, but am > wondering if others see compelling reasons to consider those issues now... The global policy process is difficult at best when everyone agrees on what needs to be done -- and probably with good reason. IMHO, there is little hope of us getting through that by the time IANA exhaustion hits if it were to be the primary route because this issue is so contentious. We don't know if we want to do this. If we decide to do it, we don't know the right method or rules to go about it. Every region is going to come up with different answers to the salient questions, and that's their right. Personally, I think we're all going to get it wrong on the first try, but in interestingly different ways. We'll learn from each others' mistakes and perhaps, one day, come to some sort of global policy that everyone can live with. Or perhaps we'll decide that even if every region allows internal transfers, we don't want to allow them between regions for some reason. Trying to answer that question today is premature, as we're all blind men groping at different parts of the elephant at this point. More importantly, a global coordination is not a pressing matter; we can solve that after IANA exhaustion -- but the regional debate definitely needs to be settled before then one way or the other. At this time I have no comments on this particular proposal other than to say I am against it being adopted _at the upcoming meeting_. I hope that it sparks thoughtful debate on the topic and that it spurs alternative proposals in the following policy cycle(s). This is too big an issue to be resolved in a couple months with only one option in front of us. 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 Mon Feb 11 19:20:27 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 11 Feb 2008 16:20:27 -0800 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparentlynoone." In-Reply-To: <17838240D9A5544AAA5FF95F8D52031603554FC9@ad-exh01.adhost.lan> Message-ID: >-----Original Message----- >From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com] >Sent: Monday, February 11, 2008 2:53 PM >To: Ted Mittelstaedt; Paul Vixie >Cc: ppml at arin.net >Subject: RE: [ppml] "Who's afraid of IPv4 address depletion? >Apparentlynoone." > > >I punted to Ted off list about the finer technical points of the >above hack. But, I think it does point out an excellent, urm, >point. We have more IPv6 addresses than we know what to do with >and I'm already well down the path of being able to provide them >to my customers. I would gladly do so. And yet, we have to come >up with all of these various ways to hack our way into extending >the life of IPv4. > Why? Sigh. There are still too many "2nd tier" ie: transit AS ISPs/networks out there who can't route IPv6 yet (you can look at my AS-path list for an example) although I'm told it's "real soon now" Maybe in a few years someone could setup an "IPv6 hall O shame" kind of like the pizza place near here that posts all the bounced checks they get on a bulletin board, which might spur the last ones to start routing it? Ted From tedm at ipinc.net Mon Feb 11 19:36:31 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 11 Feb 2008 16:36:31 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B0794F.40205@arin.net> Message-ID: I have some concerns with this proposal. This policy seems to undermine the idea that IP addressing is assigned on the basis of proving need. It lends credibility to the idea that IP addressing is property, and could open the door to any number of lawsuits based on this. For example if an organization "purchases" IPv4 they could then file a lawsuit against a large provider which decided to block access from that purchased block, claiming discriminatory behavior. Is there any reason that extending the lifetime of IPv4 will be of any benefit to the Internet community? It seems that the projected runout date is now well after all network operating systems, both router and host-based, will be IPv6 compliant. By contrast, it has been said repeatedly that the uptake of new addressing is so fast that any schemes to "mine" IPv4 from legacy holders who aren't using it, or any other sources, would be nothing more than a drop in the bucket, and thus, not worth pursuing. Furthermore, every day that passes increases the number of hosts on the Internet, thus the sooner that IPv4 is abandonded the fewer hosts will need to be renumbered and the less work will be required to switch to it. This is also at odds with the ARIN board's statement that organizations need to switch to IPv6 at http://www.arin.net/v6/v6-resolution.html rather than try extending IPv4. Specifically: "...Board of Trustees hereby requests the ARIN Advisory Council to consider Internet Numbering Resource Policy changes advisable to encourage migration to IPv6 numbering resources where possible...." is in direct contrast to: "...We (the AC) 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...." I will grant the AC's contention that the emergence of a trade in IPv4 is inevitable. I think though that ARIN needs to take the high road and stay out of the grimy, gross, and messy mechanisms that such a trade may entail. If an organization comes to ARIN demanding as a result of a "buy" that they "deserve" such and such a block of IP numbers is "theirs" then I see no benefit to the Internet community for deviating from the standard mechanism of requiring the "buyer" to submit the SAME justification for new IP addressing that any other submitter would have to provide, and issuing IPv4 using the same criteria. If that results in a denial or some or all of the IP allocation the "buyer" is requesting, then that is the gamble that the "buyer" has to take. As for a mechanism to get the same numbers as the "buyer" claims they "bought", that sort of thing is what we pay ARIN to do for us - there is no reason that the details of any internal resevation system ARIN might have for this needs to be brought out into policy. I would prefer to give the ARIN staff free-hand as to how to solve these on a case-by-case basis - as they have now, as they used when Cable & Wireless abandonded their North American IP holdings, etc. etc. etc. Ted >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Member Services >Sent: Monday, February 11, 2008 8:35 AM >To: ppml at arin.net >Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal > > >Resending with a typo that has been corrected in 8.4.2 below. The >original text is supposed to have "24 months" twice in that section. > >Member Services >American Registry for Internet Numbers (ARIN) > > > > >ARIN received the following policy proposal. In accordance with the ARIN >Internet Resource Policy Evaluation Process, the proposal is being >posted to the ARIN Public Policy Mailing List (PPML) and being placed on >ARIN's website. > >The ARIN Advisory Council (AC) will review this proposal at their next >regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as written. If the AC accepts the proposal, it >will be posted as a formal policy proposal to PPML and it will be >presented at a Public Policy Meeting. > > 2. Not accept the proposal. If the AC does not accept the proposal, >the AC will explain their decision via the PPML. If a proposal is not >accepted, then the author may elect to use the petition process to >advance their proposal. If the author elects not to petition or the >petition fails, then the proposal will be closed. > >The AC shepherds for this proposal are Scott Leibrand and Stacy Taylor. > >The AC invites everyone to comment on this proposal on the PPML, >particularly their support or non-support and the reasoning behind their >opinion. Such participation contributes to a thorough vetting and >provides important guidance to the AC in their deliberations. > >The ARIN Internet Resource Policy Evaluation Process can be found at: >http://www.arin.net/policy/irpep.html > >Mailing list subscription information can be found at: >http://www.arin.net/mailing_lists/ > >Regards, > >Member Services >American Registry for Internet Numbers (ARIN) > > >## * ## > > >Policy Proposal Name: IPv4 Transfer Policy Proposal > >Author: ARIN Advisory Council > >Proposal Version: 1.0 > >Submission Date: 02/07/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 ?M&A Transfer Requirements?: > >8.2. M&A Transfer Requirements > >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.] > > >[8.3 ? retitle to ?M&A Transfer Documentation Requirements?: > >8.3. M&A Transfer Documentation Requirements > >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.4. Requirements for Simple Transfer of IPv4 Addresses > >After the exhaustion of the IANA IPv4 free pool, ARIN will also process >IPv4 address transfer requests subject to the following conditions. > >8.4.1 Conditions on the transferor: > > * 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.4.2 Conditions on the transferee: > > * 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 only receive one IPv4 address transfer every 6 > months. > > > >8.4.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. > >8.4.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.4.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 exact network address and size > (CIDR prefix length) the transferor is eligible to provide, and > the expiration date of the pre-qualification. > >8.5. Safe Harbor for IPv4 Transfers through this Simple Transfer >Process > >IPv4 address resources being made available for transfer shall be exempt >from ARIN audit until expiration of the transfer pre-qualification or >completion of the transfer. In the event that a transfer >pre-qualification expires, ARIN shall have up to 90 days to initiate an >audit prior to this exemption being reinstated through subsequent >transfer pre-qualification. This will not extend the end of the exemption. > >8.6. 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.7. 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. > >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 plzak at arin.net Mon Feb 11 19:57:06 2008 From: plzak at arin.net (Ray Plzak) Date: Mon, 11 Feb 2008 19:57:06 -0500 Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <7.0.1.0.1.20080211202317.04fe9300@lacnic.net> References: <47B0794F.40205@arin.net> <7.0.1.0.1.20080211164859.05618d40@lacnic.net> <47B0C378.8090401@apnic.net> <7.0.1.0.1.20080211202317.04fe9300@lacnic.net> Message-ID: Any discussion of a globally coordinated policy must include an agreement between the RIRs that all will adhere to the policy as globally coordinated and that regional changes cannot and will not be accepted or this policy will unravel like the globally coordinated IPv6 policy of 2002. The ink was not dry on that policy before the first RIR modified it thus negating the efforts of a great number of individuals over a great many months. Ray > -----Original Message----- > From: sig-policy-bounces at lists.apnic.net [mailto:sig-policy- > bounces at lists.apnic.net] On Behalf Of Raul Echeberria > Sent: Monday, February 11, 2008 6:32 PM > To: ppml at arin.net; sig-policy at apnic.net > Subject: Re: [sig-policy] [ppml] Policy Proposal: IPv4 Transfer Policy > Proposal > > > Geoff. > > One observation. > > Accepting transfers only within the region is a > way to keep the IP addresses within the regions > in which they were originally allocated. > I don't know if it is good or not, but a fact. > > If the transfer of legacy space is also admited, > it has a great impact in other regions, since > most of the unused space belonging to the legacy > blocks, will feed regional markets in the > developed countries. This is the promotion of > regional markets instead of global markets. > > My opinion is that the regional approach to a > global poblem that is the IPv4 deployment is not the right approach. > > > Ra?l > > > > At 06:51 p.m. 11/02/2008, Geoff Huston wrote: > >Raul Echeberria wrote: > > > Could the author of the proposal explain what is > > > the justification for requiring that the > > > transferee should also belong to ARIN's region? > > > It is only a question and it doesn't imply any > > > specific opinion about the topic. > > > > > > Ra?l > > > > > > >Raul has not asked this more generally, but as > >the proposer of a similar address transfer > >policy in APNIC that also has a similar > >restriction (APNIC members only) I should add a > >note about why this restriction is present in > >the APNIC transfer policy proposal. > > > >In the APNIC case its about the regional address > >policy group being able to define policy for > >themselves. In this case the policy proposal has > >not been submitted as a coordinated policy > >across the RIRs nor as a proposed global polic. > >It was submitted to the APNIC policy development > >process as a proposed APNIC policy that would apply to APNIC members. > > > >That said, I now notice that there are similar > >proposals in both the ARIN and RIPE regions, so > >it may be possible during the course of the > >consideration of these proposals to assess to > >what extent such transfer mechanisms could be > >extended to encompass transfers across RIRs, as > >Scott Leibrand has already indicated in his response to Raul. > > > >Geoff > > > > > > > > > >-- > >No virus found in this incoming message. > >Checked by AVG Free Edition. Version: 7.5.516 / > >Virus Database: 269.20.2/1271 - Release Date: 11/02/2008 08:16 a.m. > > > * sig-policy: APNIC SIG on resource management policy > * > _______________________________________________ > sig-policy mailing list > sig-policy at lists.apnic.net > http://mailman.apnic.net/mailman/listinfo/sig-policy From jcurran at istaff.org Mon Feb 11 20:02:42 2008 From: jcurran at istaff.org (John Curran) Date: Mon, 11 Feb 2008 20:02:42 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: Message-ID: At 4:36 PM -0800 2/11/08, Ted Mittelstaedt wrote: >... >This is also at odds with the ARIN board's statement that organizations >need to switch to IPv6 at http://www.arin.net/v6/v6-resolution.html >rather than try extending IPv4. Specifically: > >"...Board of Trustees hereby requests the ARIN Advisory Council to consider >Internet Numbering Resource Policy changes advisable to encourage migration >to IPv6 numbering resources where possible...." "Changes to encourage migration to IPv6 *where possible*" does not preclude changes that make IPv4 available for those for whom it may not be possible to migrate in a timely manner. The resolution states that availability IPv4 space "cannot be assured indefinitely", which is not the same as saying "shall not be efficiently managed now that IPv6 is here"... Each entity using address space faces its own set of business and technical issues with migration, and to not consider the possibility of transfer policies which would improve the overall utilization of IPv4 address space would presume we know what's best on behalf of every ISP, hosting company, content provider, enterprise, etc. /John From tedm at ipinc.net Mon Feb 11 20:34:29 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 11 Feb 2008 17:34:29 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: Message-ID: >-----Original Message----- >From: John Curran [mailto:jcurran at istaff.org] >Sent: Monday, February 11, 2008 5:03 PM >To: Ted Mittelstaedt >Cc: ppml at arin.net >Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal > > >At 4:36 PM -0800 2/11/08, Ted Mittelstaedt wrote: >>... >>This is also at odds with the ARIN board's statement that organizations >>need to switch to IPv6 at http://www.arin.net/v6/v6-resolution.html >>rather than try extending IPv4. Specifically: >> >>"...Board of Trustees hereby requests the ARIN Advisory Council >to consider >>Internet Numbering Resource Policy changes advisable to encourage >migration >>to IPv6 numbering resources where possible...." > >"Changes to encourage migration to IPv6 *where possible*" does >not preclude changes that make IPv4 available for those for whom >it may not be possible to migrate in a timely manner. >The resolution >states that availability IPv4 space "cannot be assured indefinitely", >which is not the same as saying "shall not be efficiently managed >now that IPv6 is here"... > Your relying on semantic games. The intent and thrust of the Board statement is pretty clear. The intent and thrust of this policy change is also pretty clear. The two are at odds. >Each entity using address space faces its own set of business and >technical issues with migration, and to not consider the possibility >of transfer policies which would improve the overall utilization of >IPv4 address space Nothing in the CURRENT method of return-issue blocks improvements of the overall utilization of IPv4. Transfers can also make it easier for problems with badly-utilized space to be perpetuated, rather than addressed. >would presume we know what's best on behalf >of every ISP, hosting company, content provider, enterprise, etc. > That is irrelevant. The highest incidents of color blindness in the general population is red-green color blindness. However, traffic control devices use the colors red and green. This makes your ordinary stop light definitely not "the best" color choice for these individuals. However, red and green have the highest recognition among the general population as "danger" and "safe" and as a result, we have "presumed that we know the best" traffic control device color for every ISP, hosting company, content provider, enterprise, etc. It is unavoidable that any rule will affect some groups negatively. That is not a reason for either implementing, or not implementing it. We need to be looking at what is best for the Internet, not for a subgroup of ISPs. Your welcome to argue that migrating to IPv6 is not in the best interest of the Internet. Maybe it isn't, and we should forget it and be concentrating on schemes to extend IPv4 indefinitely. Ted From bicknell at ufp.org Mon Feb 11 20:41:20 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 11 Feb 2008 20:41:20 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: <47B0794F.40205@arin.net> Message-ID: <20080212014120.GB70018@ussenterprise.ufp.org> In a message written on Mon, Feb 11, 2008 at 04:36:31PM -0800, Ted Mittelstaedt wrote: > This policy seems to undermine the idea that IP addressing is assigned on > the > basis of proving need. It lends credibility to the idea that IP addressing > is property, and could open the door to any number of lawsuits based > on this. For example if an organization "purchases" IPv4 they could > then file a lawsuit against a large provider which decided to block > access from that purchased block, claiming discriminatory behavior. Two things to consider: - The AC felt that need should still be a factor, hence the desire to pre-qualify based on existing policies. I believe in general we wanted to retain as much need based addressing as seemed practical to do. - The AC worked closely with legal council to try and find the right words and phrasing. The transfer is not on IPv4 numbers; it is on a bundle of services that ARIN provides. I don't want to dismiss your worry completely, as even with input from council many AC members still have a concern in this area. > "...We (the AC) 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...." In the same statement you will also find... ] "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." The AC has not endorsed this policy as something that should be done. Indeed, there are members of the AC who share your concern and that no transfer policy should pass. Our primary goal was to spark discussion on that very point. Until now it's been "there's a proposal in APNIC" or "transfers may work like this..." We wanted to put forth a straw man of what we considered to be a well thought out transfer policy to spark real community discussion, and we very much welcome your comments. -- 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 jcurran at istaff.org Mon Feb 11 20:57:13 2008 From: jcurran at istaff.org (John Curran) Date: Mon, 11 Feb 2008 20:57:13 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: Message-ID: At 5:34 PM -0800 2/11/08, Ted Mittelstaedt wrote: > >The resolution > >states that availability IPv4 space "cannot be assured indefinitely", >>which is not the same as saying "shall not be efficiently managed > >now that IPv6 is here"... > >Your relying on semantic games. The intent and thrust of the >Board statement is pretty clear. No games - The intent of the Board statement is exactly what it states: IPv4 space "cannot be assured indefinitely". >The intent and thrust of this policy change is also pretty clear. >The two are at odds. Interesting... It didn't appear that way to the ARIN Board, which specifically asked the ARIN AC to look into the IPv4 IPv6 transition issues and whether any changes to policy needed to be considered. In that spirit, it would be good to get your feedback on whether the proposal is in the best interest of the Internet or not. >It is unavoidable that any rule will affect some groups negatively. >That is not a reason for either implementing, or not implementing it. >We need to be looking at what is best for the Internet, not for >a subgroup of ISPs. 100% agreement. The policy proposal is exactly that, a proposal. It's possible that there is no safe transfer policy that doesn't have side effects worse than any benefit... The point is that now there is a cohesive proposal on the table, and the community can discuss the benefits and risks in concrete terms rather than the abstract. >Your welcome to argue that migrating to IPv6 is not in the best interest >of the Internet. Maybe it isn't, and we should forget it and be >concentrating on schemes to extend IPv4 indefinitely. I'm here to help make sure that open discussion occurs, and not much else. My particular opinion on this proposal is moot (unless it reaches the ARIN Board and needs to be considered at that time based on the community's support, openness of discussion, and ARIN's overall mission). /John From drc at virtualized.org Mon Feb 11 21:33:27 2008 From: drc at virtualized.org (David Conrad) Date: Mon, 11 Feb 2008 18:33:27 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: Message-ID: > Nothing in the CURRENT method of return-issue blocks improvements > of the overall utilization of IPv4. Except there is currently no incentive to return blocks and there will be less over time. > Transfers can also make it easier for problems with badly-utilized > space to be perpetuated, rather than addressed. How is that worse than the situation as it exists now? Regards, -drc From sleibrand at internap.com Mon Feb 11 23:33:49 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 11 Feb 2008 22:33:49 -0600 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <20080211170626.GN8368@shell01.cell.sv2.tellme.com> References: <47B0794F.40205@arin.net> <369EB04A0951824ABE7D8BAC67AF9BB408841E6E@CL-S-EX-1.stanleyassociates.com> <20080211170626.GN8368@shell01.cell.sv2.tellme.com> Message-ID: <47B121AD.9040807@internap.com> David Williamson wrote: > On Mon, Feb 11, 2008 at 11:56:29AM -0500, Howard, W. Lee wrote: > >>> 8.4.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. >>> >> Is this intended to mean swamp space can remain swampy, but other >> space can't be subdivided in /24? It looks like it says the block >> must meet minimum transfer size, unless it's a /24 or larger. >> > > I'm also a bit confused by this. It does seem to imply that I cannot > get a PI /24 from ARIN directly, but I could get one transferred to > me. That seems unexpected. If the intent is to permit resources > already allocated at some size that is presently below the minimum > requirements (i.e., the swamp), this should get some different > verbiage. If the intent is really to permit transfers down to the /24 > limit, we should go ahead and change the minimum allocation and > assignment sizes to match. > Yes, that is the intent: to encourage efficient use of unused swamp space by allowing it to be transferred after IANA exhaustion. This policy does not do anything to change the minimum allocation size: that may be a good idea, but should be a separate policy proposal IMO. -Scott From sleibrand at internap.com Mon Feb 11 23:53:36 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 11 Feb 2008 22:53:36 -0600 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: Message-ID: <47B12650.2060107@internap.com> Ted Mittelstaedt wrote: > I have some concerns with this proposal. > > This policy seems to undermine the idea that IP addressing is assigned on the > basis of proving need. As Leo mentioned, the intent here is to continue requiring applicants to prove they need IPv4 addresses, and simply provide them with another way to get those addresses they've qualified for once ARIN runs out. > It lends credibility to the idea that IP addressing > is property, and could open the door to any number of lawsuits based > on this. For example if an organization "purchases" IPv4 they could > then file a lawsuit against a large provider which decided to block > access from that purchased block, claiming discriminatory behavior. > That is a valid concern. ARIN counsel has been consulting with the AC on this policy proposal. In addition to the legal risks to ARIN itself that he's been considering thus far, it may be a good idea to ask whether he feels this policy proposal would create any substantial legal risk for ARIN members individually. > Is there any reason that extending the lifetime of IPv4 will be of any > benefit to the Internet community? Yes. There is a large installed base for whom migrating to IPv6 may be painful (expensive). Reducing the community's total expense for operating their IP networks is a benefit to the Internet community. > It seems that the projected runout date > is now well after all network operating systems, both router and host-based, > will be IPv6 compliant. > > By contrast, it has been said repeatedly that the uptake of new addressing > is so fast that any schemes to "mine" IPv4 from legacy holders who > aren't using it, or any other sources, would be nothing more than a > drop in the bucket, and thus, not worth pursuing. That assumes that we are only trying to reclaim existing unused IPv4 space, without providing any incentive for people to renumber out of IPv4 space that, while not strictly unused, is easy to move out of. For example, if I run a consumer ISP, I might decide that I could migrate my DHCP customers to IPv6 + NAT'd IPv4, thereby freeing up IPv4 addresses that I can then transfer to a slower adopter, and use the proceeds to fund my entire IPv6 migration. > Furthermore, every > day that passes increases the number of hosts on the Internet, thus > the sooner that IPv4 is abandonded the fewer hosts will need to be > renumbered and the less work will be required to switch to it. > Money is a powerful motivator. If an organization can choose to save money by putting new hosts on IPv6 with NAT'd IPv4 or a proxy for reaching the remaining IPv4 Internet, they'll likely do so. If a different organization with different issues can save more money by paying someone else to migrate and use their space to delay migrating until all their systems are ready, they'll likely do that. This policy proposal allows organizations to choose what's best for them, rather than forcing a one-size-fits-all solution. > I will grant the AC's contention that the emergence of a trade in IPv4 is > inevitable. I think though that ARIN needs to take the high road and stay > out of the grimy, gross, and messy mechanisms that such a trade may > entail. ARIN is in the stewardship business, no matter how grimy, gross, or messy that business becomes. I believe it is our responsibility to the community to minimize the grime and messiness, and I believe that a transfer policy along the lines proposed is one of the best ways available to do so. > If an organization comes to ARIN demanding as a result of a "buy" > that they "deserve" such and such a block of IP numbers is "theirs" then > I see no benefit to the Internet community for deviating from the standard > mechanism of requiring the "buyer" to submit the SAME justification for > new IP addressing that any other submitter would have to provide, and > issuing IPv4 using the same criteria. If that results in a denial or some or > all of the IP allocation the "buyer" is requesting, then that is the gamble > that the "buyer" has to take. That is exactly what this policy proposal attempts to accomplish: it requires that any potential transferee justify their need for IP space, exactly as they have to do today. They can then get IPv4 space from ARIN, if ARIN has any to give, or they can go out and find a transferor willing to part with some space. > As for a mechanism to get the same numbers > as the "buyer" claims they "bought", that sort of thing is what we pay ARIN > to do for us - there is no reason that the details of any internal resevation > system ARIN might have for this needs to be brought out into policy. I > would prefer to give the ARIN staff free-hand as to how to solve these on a > case-by-case basis - as they have now, as they used when Cable & Wireless abandonded > their North American IP holdings, etc. etc. etc. > One important point I'll reiterate: we're not talking about just "abandoned" or "unused" IP space here. We're talking about providing organizations a financial incentive to reduce their usage of IPv4 space (such as by adopting IPv6), thereby freeing up space for other organizations who still need it. To enable that, we need a new policy, such as the one we've proposed. -Scott > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >> Member Services >> Sent: Monday, February 11, 2008 8:35 AM >> To: ppml at arin.net >> Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal >> >> >> Resending with a typo that has been corrected in 8.4.2 below. The >> original text is supposed to have "24 months" twice in that section. >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> >> >> ARIN received the following policy proposal. In accordance with the ARIN >> Internet Resource Policy Evaluation Process, the proposal is being >> posted to the ARIN Public Policy Mailing List (PPML) and being placed on >> ARIN's website. >> >> The ARIN Advisory Council (AC) will review this proposal at their next >> regularly scheduled meeting. The AC may decide to: >> >> 1. Accept the proposal as written. If the AC accepts the proposal, it >> will be posted as a formal policy proposal to PPML and it will be >> presented at a Public Policy Meeting. >> >> 2. Not accept the proposal. If the AC does not accept the proposal, >> the AC will explain their decision via the PPML. If a proposal is not >> accepted, then the author may elect to use the petition process to >> advance their proposal. If the author elects not to petition or the >> petition fails, then the proposal will be closed. >> >> The AC shepherds for this proposal are Scott Leibrand and Stacy Taylor. >> >> The AC invites everyone to comment on this proposal on the PPML, >> particularly their support or non-support and the reasoning behind their >> opinion. Such participation contributes to a thorough vetting and >> provides important guidance to the AC in their deliberations. >> >> The ARIN Internet Resource Policy Evaluation Process can be found at: >> http://www.arin.net/policy/irpep.html >> >> Mailing list subscription information can be found at: >> http://www.arin.net/mailing_lists/ >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Policy Proposal Name: IPv4 Transfer Policy Proposal >> >> Author: ARIN Advisory Council >> >> Proposal Version: 1.0 >> >> Submission Date: 02/07/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 ?M&A Transfer Requirements?: >> >> 8.2. M&A Transfer Requirements >> >> 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.] >> >> >> [8.3 ? retitle to ?M&A Transfer Documentation Requirements?: >> >> 8.3. M&A Transfer Documentation Requirements >> >> 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.4. Requirements for Simple Transfer of IPv4 Addresses >> >> After the exhaustion of the IANA IPv4 free pool, ARIN will also process >> IPv4 address transfer requests subject to the following conditions. >> >> 8.4.1 Conditions on the transferor: >> >> * 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.4.2 Conditions on the transferee: >> >> * 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 only receive one IPv4 address transfer every 6 >> months. >> >> >> >> 8.4.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. >> >> 8.4.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.4.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 exact network address and size >> (CIDR prefix length) the transferor is eligible to provide, and >> the expiration date of the pre-qualification. >> >> 8.5. Safe Harbor for IPv4 Transfers through this Simple Transfer >> Process >> >> IPv4 address resources being made available for transfer shall be exempt >> > >from ARIN audit until expiration of the transfer pre-qualification or > >> completion of the transfer. In the event that a transfer >> pre-qualification expires, ARIN shall have up to 90 days to initiate an >> audit prior to this exemption being reinstated through subsequent >> transfer pre-qualification. This will not extend the end of the exemption. >> >> 8.6. 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.7. 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. >> >> 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. >> >> >> > > _______________________________________________ > 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 heldal at eml.cc Tue Feb 12 04:04:18 2008 From: heldal at eml.cc (Per Heldal) Date: Tue, 12 Feb 2008 10:04:18 +0100 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: Message-ID: <1202807058.11775.13.camel@obelix.sandbu> On Mon, 2008-02-11 at 16:36 -0800, Ted Mittelstaedt wrote: > I have some concerns with this proposal. > > This policy seems to undermine the idea that IP addressing is assigned on > the > basis of proving need. It lends credibility to the idea that IP addressing > is property, and could open the door to any number of lawsuits based > on this. For example if an organization "purchases" IPv4 they could > then file a lawsuit against a large provider which decided to block > access from that purchased block, claiming discriminatory behavior. The suggested policy also seems to be in conflict with the RIR principle of not being involved in routing. Wherever there's money to be made there's greed and that can't be contained by simply telling people to "be nice". The value of this kind of policy is questionable if it cannot be enforced. To regulate other people's use of resources is fundamentally different from the task of coordinating handouts from a resource-pool. //per From michael.dillon at bt.com Tue Feb 12 05:02:59 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 12 Feb 2008 10:02:59 -0000 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <20080211224231.GA60722@ussenterprise.ufp.org> References: <47B0794F.40205@arin.net><7.0.1.0.1.20080211164859.05618d40@lacnic.net><47B0C378.8090401@apnic.net><7.0.1.0.1.20080211202317.04fe9300@lacnic.net> <20080211224231.GA60722@ussenterprise.ufp.org> Message-ID: > Personally I am quite troubled by the results either way. If > someone in a third world country can't get IP's because we > don't allow them to be transferred out of our region, that's > bad. If some large, rich US corporation comes along and buys > up all the IP's from a third world country because it can, I > think that's bad too. Please get your head out of the clouds. IPv6 addresses are available from all RIRs. The need for Transparent Internet Acess will mean that once the IPv6 transition has begun in some countries, there will no longer be any value in maintaining growth of IPv4 networks because whether you use IPv4 or IPV6, you will still have to operate transition mechanisms. Considering that you can't escape spending money to live with IPv6, it is smarter to begin your IPv6 transition earlier, rather than hanging on to IPv4 until the bitter end. If you hang on until the end, then you will have to spend money again, at a time when your comptetitors have already broken free of IPv4. There will never be a time when 3rd world countries can't get IPs. And no rich companies will ever corner the market on IPs because there are simply too many addresses in the IPv6 address space. --Michael Dillon From michael.dillon at bt.com Tue Feb 12 05:22:23 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 12 Feb 2008 10:22:23 -0000 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B12650.2060107@internap.com> References: <47B12650.2060107@internap.com> Message-ID: > Yes. There is a large installed base for whom migrating to > IPv6 may be painful (expensive). Reducing the community's > total expense for operating their IP networks is a benefit to > the Internet community. RED HERRING! Given the fact that ISPs who implement IPv6 transit service will also have to implement transition mechanisms such as Teredo, 6to4, etc., there is no imperative for any part of the installed base to migrate to IPv6 before they are ready. The imperative today is for those organizations with steadily growing networks at the heart of their business model (ISPs) to begin transitioning. Whether it is painful or not, they must do it or die because network growth is fundamental to their being. If an ISP decided to try and avoid implementing IPv6 by getting IPv4 addresses from other sources, they are simply backing themselves into a corner and relying on their competitors to operate transition mechanisms for them. This is a risky strategy since the market segment who are willing to buy IPv4 network access will be steadily shrinking. In addition, their existing customers will begin to move away because the ISP is perceived as being incompetent and at risk of hitting a brick wall. > This policy > proposal allows organizations to choose what's best for them, > rather than forcing a one-size-fits-all solution. I disagree that this policy does what you say. In fact this policy is trying to set up a market for buying and selling IP addresses. Under current policy, an ISP who migrates infrastructure to IPv6 can return their IPv4 addresses to ARIN. And an ISP who is not migrating can continue to apply to ARIN for more IPv4 addresses and receive the returned ones. This is clear and simple and easy to understand. It is the way that IPv4 allocation has always been done and is fully understood by everybody who deals with IP networking. Any new policy like the one proposed, simply muddies the waters and creates confusion. --Michael Dillon From raul at lacnic.net Tue Feb 12 08:37:47 2008 From: raul at lacnic.net (Raul Echeberria) Date: Tue, 12 Feb 2008 10:37:47 -0300 Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: <47B0794F.40205@arin.net> <7.0.1.0.1.20080211164859.05618d40@lacnic.net> <47B0C378.8090401@apnic.net> <7.0.1.0.1.20080211202317.04fe9300@lacnic.net> Message-ID: <7.0.1.0.1.20080212102939.04fec760@lacnic.net> Ray: Certainly it is a good point, but I am not necessarily claiming for a global or a coordinated policy (maybe yes), but for a global "and" coordinated strategy for dealing with a global problem. Ra?l At 09:57 p.m. 11/02/2008, Ray Plzak wrote: >Any discussion of a globally coordinated policy >must include an agreement between the RIRs that >all will adhere to the policy as globally >coordinated and that regional changes cannot and >will not be accepted or this policy will unravel >like the globally coordinated IPv6 policy of >2002. The ink was not dry on that policy before >the first RIR modified it thus negating the >efforts of a great number of individuals over a great many months. > >Ray > > > -----Original Message----- > > From: sig-policy-bounces at lists.apnic.net [mailto:sig-policy- > > bounces at lists.apnic.net] On Behalf Of Raul Echeberria > > Sent: Monday, February 11, 2008 6:32 PM > > To: ppml at arin.net; sig-policy at apnic.net > > Subject: Re: [sig-policy] [ppml] Policy Proposal: IPv4 Transfer Policy > > Proposal > > > > > > Geoff. > > > > One observation. > > > > Accepting transfers only within the region is a > > way to keep the IP addresses within the regions > > in which they were originally allocated. > > I don't know if it is good or not, but a fact. > > > > If the transfer of legacy space is also admited, > > it has a great impact in other regions, since > > most of the unused space belonging to the legacy > > blocks, will feed regional markets in the > > developed countries. This is the promotion of > > regional markets instead of global markets. > > > > My opinion is that the regional approach to a > > global poblem that is the IPv4 deployment is not the right approach. > > > > > > Ra?l > > > > > > > > At 06:51 p.m. 11/02/2008, Geoff Huston wrote: > > >Raul Echeberria wrote: > > > > Could the author of the proposal explain what is > > > > the justification for requiring that the > > > > transferee should also belong to ARIN's region? > > > > It is only a question and it doesn't imply any > > > > specific opinion about the topic. > > > > > > > > Ra?l > > > > > > > > > >Raul has not asked this more generally, but as > > >the proposer of a similar address transfer > > >policy in APNIC that also has a similar > > >restriction (APNIC members only) I should add a > > >note about why this restriction is present in > > >the APNIC transfer policy proposal. > > > > > >In the APNIC case its about the regional address > > >policy group being able to define policy for > > >themselves. In this case the policy proposal has > > >not been submitted as a coordinated policy > > >across the RIRs nor as a proposed global polic. > > >It was submitted to the APNIC policy development > > >process as a proposed APNIC policy that would apply to APNIC members. > > > > > >That said, I now notice that there are similar > > >proposals in both the ARIN and RIPE regions, so > > >it may be possible during the course of the > > >consideration of these proposals to assess to > > >what extent such transfer mechanisms could be > > >extended to encompass transfers across RIRs, as > > >Scott Leibrand has already indicated in his response to Raul. > > > > > >Geoff > > > > > > > > > > > > > > >-- > > >No virus found in this incoming message. > > >Checked by AVG Free Edition. Version: 7.5.516 / > > >Virus Database: 269.20.2/1271 - Release Date: 11/02/2008 08:16 a.m. > > > > > > * sig-policy: APNIC SIG on resource management policy > > * > > _______________________________________________ > > sig-policy mailing list > > sig-policy at lists.apnic.net > > http://mailman.apnic.net/mailman/listinfo/sig-policy > >* sig-policy: APNIC SIG on >resource management policy * >_______________________________________________ >sig-policy mailing list >sig-policy at lists.apnic.net >http://mailman.apnic.net/mailman/listinfo/sig-policy > > >-- >No virus found in this incoming message. >Checked by AVG Free Edition. >Version: 7.5.516 / Virus Database: 269.20.2/1273 >- Release Date: 12/02/2008 09:31 a.m. From randy at psg.com Tue Feb 12 07:38:28 2008 From: randy at psg.com (Randy Bush) Date: Tue, 12 Feb 2008 21:38:28 +0900 Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <7.0.1.0.1.20080212102939.04fec760@lacnic.net> References: <47B0794F.40205@arin.net> <7.0.1.0.1.20080211164859.05618d40@lacnic.net> <47B0C378.8090401@apnic.net> <7.0.1.0.1.20080211202317.04fe9300@lacnic.net> <7.0.1.0.1.20080212102939.04fec760@lacnic.net> Message-ID: <47B19344.7040707@psg.com> > I am not necessarily claiming for a global or a coordinated policy > (maybe yes), but for a global "and" coordinated strategy for dealing > with a global problem. too radical. it is our right to think locally while acting globally. that's why there are five rirs, right? randy From randy at psg.com Tue Feb 12 07:40:53 2008 From: randy at psg.com (Randy Bush) Date: Tue, 12 Feb 2008 21:40:53 +0900 Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B19344.7040707@psg.com> References: <47B0794F.40205@arin.net> <7.0.1.0.1.20080211164859.05618d40@lacnic.net> <47B0C378.8090401@apnic.net> <7.0.1.0.1.20080211202317.04fe9300@lacnic.net> <7.0.1.0.1.20080212102939.04fec760@lacnic.net> <47B19344.7040707@psg.com> Message-ID: <47B193D5.2060708@psg.com> >> I am not necessarily claiming for a global or a coordinated policy >> (maybe yes), but for a global "and" coordinated strategy for dealing >> with a global problem. > too radical. it is our right to think locally while acting globally. > that's why there are five rirs, right? apologies. sarcasm does not translate well. i am in strong agreement with raul. randy From plzak at arin.net Tue Feb 12 07:45:43 2008 From: plzak at arin.net (Ray Plzak) Date: Tue, 12 Feb 2008 07:45:43 -0500 Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B19344.7040707@psg.com> References: <47B0794F.40205@arin.net> <7.0.1.0.1.20080211164859.05618d40@lacnic.net> <47B0C378.8090401@apnic.net> <7.0.1.0.1.20080211202317.04fe9300@lacnic.net> <7.0.1.0.1.20080212102939.04fec760@lacnic.net> <47B19344.7040707@psg.com> Message-ID: Merely pointing out that there are implications to the use of the term globally coordinated policy, a term that has been used many times over the past several months, perhaps a little to glibly. Even a global and coordinated strategy will require commitments, once made, must not be subject to disassembly by the subsequent actions of a single RIR. Once that happens the global and coordinated strategy is neither global or coordinated. Think locally while acting globally is more than just a catchy phrase. Ray > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Tuesday, February 12, 2008 7:38 AM > To: Raul Echeberria > Cc: Ray Plzak; ppml at arin.net; sig-policy at apnic.net > Subject: Re: [sig-policy] [ppml] Policy Proposal: IPv4 Transfer Policy > Proposal > > > I am not necessarily claiming for a global or a coordinated policy > > (maybe yes), but for a global "and" coordinated strategy for dealing > > with a global problem. > > too radical. it is our right to think locally while acting globally. > that's why there are five rirs, right? > > randy From raul at lacnic.net Tue Feb 12 09:10:41 2008 From: raul at lacnic.net (Raul Echeberria) Date: Tue, 12 Feb 2008 11:10:41 -0300 Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: <47B0794F.40205@arin.net> <7.0.1.0.1.20080211164859.05618d40@lacnic.net> <47B0C378.8090401@apnic.net> <7.0.1.0.1.20080211202317.04fe9300@lacnic.net> <7.0.1.0.1.20080212102939.04fec760@lacnic.net> <47B19344.7040707@psg.com> Message-ID: <7.0.1.0.1.20080212110845.05a8bb50@lacnic.net> Ray My point is that we first need a global strategy and later probably global and/or coordinated policies for implementing that strategy. And of course, I agree with you regarding commitments, and rest that you said. Raul At 09:45 a.m. 12/02/2008, Ray Plzak wrote: >Merely pointing out that there are implications to the use of the >term globally coordinated policy, a term that has been used many >times over the past several months, perhaps a little to glibly. > >Even a global and coordinated strategy will require commitments, >once made, must not be subject to disassembly by the subsequent >actions of a single RIR. Once that happens the global and >coordinated strategy is neither global or coordinated. Think locally >while acting globally is more than just a catchy phrase. > >Ray > > > -----Original Message----- > > From: Randy Bush [mailto:randy at psg.com] > > Sent: Tuesday, February 12, 2008 7:38 AM > > To: Raul Echeberria > > Cc: Ray Plzak; ppml at arin.net; sig-policy at apnic.net > > Subject: Re: [sig-policy] [ppml] Policy Proposal: IPv4 Transfer Policy > > Proposal > > > > > I am not necessarily claiming for a global or a coordinated policy > > > (maybe yes), but for a global "and" coordinated strategy for dealing > > > with a global problem. > > > > too radical. it is our right to think locally while acting globally. > > that's why there are five rirs, right? > > > > randy > >* sig-policy: APNIC SIG on resource management >policy * >_______________________________________________ >sig-policy mailing list >sig-policy at lists.apnic.net >http://mailman.apnic.net/mailman/listinfo/sig-policy > > >-- >No virus found in this incoming message. >Checked by AVG Free Edition. >Version: 7.5.516 / Virus Database: 269.20.2/1273 - Release Date: >12/02/2008 09:31 a.m. From BillD at cait.wustl.edu Tue Feb 12 08:23:35 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 12 Feb 2008 07:23:35 -0600 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: <47B0794F.40205@arin.net> Message-ID: The intent of the modified transfer policy is to provide order in the interim between now, through IPv4 exhaustion and toward a pervasive IPv6 adoption. As has been stated before, the AC was not in favor of this policy as a singular effort. It was in context of a number of suggestions that would provide stability and promote migration and the acceptance that transfers will take place in the future to meet needs. The AC chose to make this proposal to begin a concrete dialog about this issue in the ARIN region and to prescribe a means to mitigate an uncoordinated and unjustified transfer system...one that is likely to exhibit most of the bad characteristics of unregulated exchanges of limited resources. It is easy to misuse the term 'buying' of resources when discussing this policy. It is not a policy that accepts that IP addresses will become property, nor that acquisition of number resources will take place outside of justification by whichever source (free pool or transfer). Bill Darte ARIN AC > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Sent: Monday, February 11, 2008 6:37 PM > To: Member Services; ppml at arin.net > Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal > > > I have some concerns with this proposal. > > This policy seems to undermine the idea that IP addressing is > assigned on the basis of proving need. It lends credibility > to the idea that IP addressing is property, and could open > the door to any number of lawsuits based on this. For > example if an organization "purchases" IPv4 they could then > file a lawsuit against a large provider which decided to > block access from that purchased block, claiming > discriminatory behavior. > > Is there any reason that extending the lifetime of IPv4 will > be of any benefit to the Internet community? It seems that > the projected runout date is now well after all network > operating systems, both router and host-based, will be IPv6 compliant. > > By contrast, it has been said repeatedly that the uptake of > new addressing is so fast that any schemes to "mine" IPv4 > from legacy holders who aren't using it, or any other > sources, would be nothing more than a drop in the bucket, and > thus, not worth pursuing. Furthermore, every day that passes > increases the number of hosts on the Internet, thus the > sooner that IPv4 is abandonded the fewer hosts will need to > be renumbered and the less work will be required to switch to it. > > This is also at odds with the ARIN board's statement that > organizations need to switch to IPv6 at > http://www.arin.net/v6/v6-resolution.html > rather than try extending IPv4. Specifically: > > "...Board of Trustees hereby requests the ARIN Advisory > Council to consider Internet Numbering Resource Policy > changes advisable to encourage migration to IPv6 numbering > resources where possible...." > > is in direct contrast to: > > "...We (the AC) 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...." > > I will grant the AC's contention that the emergence of a > trade in IPv4 is inevitable. I think though that ARIN needs > to take the high road and stay out of the grimy, gross, and > messy mechanisms that such a trade may entail. If an > organization comes to ARIN demanding as a result of a "buy" > that they "deserve" such and such a block of IP numbers is > "theirs" then I see no benefit to the Internet community for > deviating from the standard mechanism of requiring the > "buyer" to submit the SAME justification for new IP > addressing that any other submitter would have to provide, > and issuing IPv4 using the same criteria. If that results in > a denial or some or all of the IP allocation the "buyer" is > requesting, then that is the gamble that the "buyer" has to > take. As for a mechanism to get the same numbers as the > "buyer" claims they "bought", that sort of thing is what we > pay ARIN to do for us - there is no reason that the details > of any internal resevation system ARIN might have for this > needs to be brought out into policy. I would prefer to give > the ARIN staff free-hand as to how to solve these on a > case-by-case basis - as they have now, as they used when > Cable & Wireless abandonded their North American IP holdings, > etc. etc. etc. > > > Ted > > >-----Original Message----- > >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On > Behalf Of > >Member Services > >Sent: Monday, February 11, 2008 8:35 AM > >To: ppml at arin.net > >Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal > > > > > >Resending with a typo that has been corrected in 8.4.2 below. The > >original text is supposed to have "24 months" twice in that section. > > > >Member Services > >American Registry for Internet Numbers (ARIN) > > > > > > > > > >ARIN received the following policy proposal. In accordance with the > >ARIN Internet Resource Policy Evaluation Process, the > proposal is being > >posted to the ARIN Public Policy Mailing List (PPML) and > being placed > >on ARIN's website. > > > >The ARIN Advisory Council (AC) will review this proposal at > their next > >regularly scheduled meeting. The AC may decide to: > > > > 1. Accept the proposal as written. If the AC accepts the > proposal, > >it will be posted as a formal policy proposal to PPML and it will be > >presented at a Public Policy Meeting. > > > > 2. Not accept the proposal. If the AC does not accept the > proposal, > >the AC will explain their decision via the PPML. If a > proposal is not > >accepted, then the author may elect to use the petition process to > >advance their proposal. If the author elects not to petition or the > >petition fails, then the proposal will be closed. > > > >The AC shepherds for this proposal are Scott Leibrand and > Stacy Taylor. > > > >The AC invites everyone to comment on this proposal on the PPML, > >particularly their support or non-support and the reasoning behind > >their opinion. Such participation contributes to a thorough > vetting and > >provides important guidance to the AC in their deliberations. > > > >The ARIN Internet Resource Policy Evaluation Process can be found at: > >http://www.arin.net/policy/irpep.html > > > >Mailing list subscription information can be found at: > >http://www.arin.net/mailing_lists/ > > > >Regards, > > > >Member Services > >American Registry for Internet Numbers (ARIN) > > > > > >## * ## > > > > > >Policy Proposal Name: IPv4 Transfer Policy Proposal > > > >Author: ARIN Advisory Council > > > >Proposal Version: 1.0 > > > >Submission Date: 02/07/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 "M&A Transfer > Requirements": > > > >8.2. M&A Transfer Requirements > > > >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.] > > > > > >[8.3 - retitle to "M&A Transfer Documentation Requirements": > > > >8.3. M&A Transfer Documentation Requirements > > > >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.4. Requirements for Simple Transfer of IPv4 Addresses > > > >After the exhaustion of the IANA IPv4 free pool, ARIN will > also process > >IPv4 address transfer requests subject to the following conditions. > > > >8.4.1 Conditions on the transferor: > > > > * 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.4.2 Conditions on the transferee: > > > > * 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 only receive one IPv4 address > transfer every 6 > > months. > > > > > > > >8.4.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. > > > >8.4.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.4.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 exact network > address and size > > (CIDR prefix length) the transferor is eligible to > provide, and > > the expiration date of the pre-qualification. > > > >8.5. Safe Harbor for IPv4 Transfers through this Simple Transfer > >Process > > > >IPv4 address resources being made available for transfer shall be > >exempt from ARIN audit until expiration of the transfer > >pre-qualification or completion of the transfer. In the > event that a > >transfer pre-qualification expires, ARIN shall have up to 90 days to > >initiate an audit prior to this exemption being reinstated through > >subsequent transfer pre-qualification. This will not extend > the end of the exemption. > > > >8.6. 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.7. 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. > > > >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. > > > > > > _______________________________________________ > 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 Tue Feb 12 08:41:28 2008 From: plzak at arin.net (Ray Plzak) Date: Tue, 12 Feb 2008 08:41:28 -0500 Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <7.0.1.0.1.20080212110845.05a8bb50@lacnic.net> References: <47B0794F.40205@arin.net> <7.0.1.0.1.20080211164859.05618d40@lacnic.net> <47B0C378.8090401@apnic.net> <7.0.1.0.1.20080211202317.04fe9300@lacnic.net> <7.0.1.0.1.20080212102939.04fec760@lacnic.net> <47B19344.7040707@psg.com> <7.0.1.0.1.20080212110845.05a8bb50@lacnic.net> Message-ID: Raul, The policies that have been proposed in the various regions thus far are all regional only. None attempt to bring in the global community. I see nothing that precludes these policies from moving forward in their respective regions. Certainly in the discussions that take place in the individual regions, global implications have been and will be continued to be discussed. The communities should not have to wait for a global strategy in order to discuss the merits of various aspects of these proposals as they will have to be discussed in any event. Ray > -----Original Message----- > From: Raul Echeberria [mailto:raul at lacnic.net] > Sent: Tuesday, February 12, 2008 9:11 AM > To: Ray Plzak; Randy Bush > Cc: ppml at arin.net; sig-policy at apnic.net > Subject: Re: [sig-policy] [ppml] Policy Proposal: IPv4 Transfer Policy > Proposal > > > Ray > > My point is that we first need a global strategy and later probably > global and/or coordinated policies for implementing that strategy. > And of course, I agree with you regarding commitments, and rest that > you said. > > Raul > > > At 09:45 a.m. 12/02/2008, Ray Plzak wrote: > >Merely pointing out that there are implications to the use of the > >term globally coordinated policy, a term that has been used many > >times over the past several months, perhaps a little to glibly. > > > >Even a global and coordinated strategy will require commitments, > >once made, must not be subject to disassembly by the subsequent > >actions of a single RIR. Once that happens the global and > >coordinated strategy is neither global or coordinated. Think locally > >while acting globally is more than just a catchy phrase. > > > >Ray > > > > > -----Original Message----- > > > From: Randy Bush [mailto:randy at psg.com] > > > Sent: Tuesday, February 12, 2008 7:38 AM > > > To: Raul Echeberria > > > Cc: Ray Plzak; ppml at arin.net; sig-policy at apnic.net > > > Subject: Re: [sig-policy] [ppml] Policy Proposal: IPv4 Transfer > Policy > > > Proposal > > > > > > > I am not necessarily claiming for a global or a coordinated > policy > > > > (maybe yes), but for a global "and" coordinated strategy for > dealing > > > > with a global problem. > > > > > > too radical. it is our right to think locally while acting > globally. > > > that's why there are five rirs, right? > > > > > > randy > > > >* sig-policy: APNIC SIG on resource management > >policy * > >_______________________________________________ > >sig-policy mailing list > >sig-policy at lists.apnic.net > >http://mailman.apnic.net/mailman/listinfo/sig-policy > > > > > >-- > >No virus found in this incoming message. > >Checked by AVG Free Edition. > >Version: 7.5.516 / Virus Database: 269.20.2/1273 - Release Date: > >12/02/2008 09:31 a.m. > > From raul at lacnic.net Tue Feb 12 10:56:49 2008 From: raul at lacnic.net (Raul Echeberria) Date: Tue, 12 Feb 2008 12:56:49 -0300 Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: <47B0794F.40205@arin.net> <7.0.1.0.1.20080211164859.05618d40@lacnic.net> <47B0C378.8090401@apnic.net> <7.0.1.0.1.20080211202317.04fe9300@lacnic.net> <7.0.1.0.1.20080212102939.04fec760@lacnic.net> <47B19344.7040707@psg.com> <7.0.1.0.1.20080212110845.05a8bb50@lacnic.net> Message-ID: <7.0.1.0.1.20080212125257.04dba050@lacnic.net> At 10:41 a.m. 12/02/2008, Ray Plzak wrote: >Raul, > >The policies that have been proposed in the >various regions thus far are all regional only. That's clear. > None attempt to bring in the global community. That's clear. >I see nothing that precludes these policies >from moving forward in their respective regions. > Certainly in the discussions that take place > in the individual regions, global implications > have been and will be continued to be > discussed. The communities should not have to > wait for a global strategy in order to discuss > the merits of various aspects of these > proposals as they will have to be discussed in any event. I don't see your point. Who proposed to stop?de discussion? I only gave my opinion and that is that global problems need of global aproaches. Ra?l From sleibrand at internap.com Tue Feb 12 10:07:34 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 12 Feb 2008 09:07:34 -0600 Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <7.0.1.0.1.20080212125257.04dba050@lacnic.net> References: <47B0794F.40205@arin.net> <7.0.1.0.1.20080211164859.05618d40@lacnic.net> <47B0C378.8090401@apnic.net> <7.0.1.0.1.20080211202317.04fe9300@lacnic.net> <7.0.1.0.1.20080212102939.04fec760@lacnic.net> <47B19344.7040707@psg.com> <7.0.1.0.1.20080212110845.05a8bb50@lacnic.net> <7.0.1.0.1.20080212125257.04dba050@lacnic.net> Message-ID: <47B1B636.1060407@internap.com> In the short term, I think Ray is correct that we need to move forward with considering these policy proposals independently at each RIR. In the long term, I think Raul is correct that we need to consider more global approaches, either in terms of a globally coordinated policy on inter-RIR transfers, or on a bilateral adjustment of policies between two RIRs to allow transfers between them. IOW, I think we're in violent agreement. :-) -Scott Raul Echeberria wrote: > At 10:41 a.m. 12/02/2008, Ray Plzak wrote: > >> Raul, >> >> The policies that have been proposed in the >> various regions thus far are all regional only. >> > > That's clear. > > >> None attempt to bring in the global community. >> > > That's clear. > > >> I see nothing that precludes these policies >> > >from moving forward in their respective regions. > >> Certainly in the discussions that take place >> in the individual regions, global implications >> have been and will be continued to be >> discussed. The communities should not have to >> wait for a global strategy in order to discuss >> the merits of various aspects of these >> proposals as they will have to be discussed in any event. >> > > I don't see your point. > Who proposed to stop?de discussion? > I only gave my opinion and that is that global > problems need of global aproaches. > > > Ra?l > > > _______________________________________________ > 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 Tue Feb 12 10:26:13 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 12 Feb 2008 10:26:13 -0500 Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B0D496.2030800@apnic.net> References: <47B0794F.40205@arin.net> <7.0.1.0.1.20080211164859.05618d40@lacnic.net> <47B0C378.8090401@apnic.net> <7.0.1.0.1.20080211202317.04fe9300@lacnic.net> <47B0D496.2030800@apnic.net> Message-ID: <20080212152613.GB14759@ussenterprise.ufp.org> In a message written on Tue, Feb 12, 2008 at 10:04:54AM +1100, Geoff Huston wrote: > Concerning mechanics, in looking at the APNIC and ARIN proposals they > both take the approach of "qualification" of the two parties to a > transfer. One approach would be to 'recognise' the qualification from > another region - i.e. taking an ARIN perspective a "transferor" (is that > really an english word? ;-)) meets the criteria listed in section 8.4.1. > To extend this to allow cross-RIR transfers it would be a case of > adding "or meets the criteria as listed (insert reference to the > transfer policy of another RIR) for members of (RIR). Similarly the > conditions of the transferee could be augmented by reference to the > relevant qualifications in the policies of other RIRs. So in terms of > extending the mechanics of the policy proposals to encompass cross-RIR > transfers then I'd suggest that there are ways to achieve this though > the use of mutual recognition of each RIR's qualification processes. I'd like to agree with Geoff's analysis. I think the mechanics of doing this across RIR are relatively simple as he explains. We also have experience from the ERX effort in actually getting the database entries to the right place. Rather than trying to pass a global policy having each region pass a reciprocity policy of sorts. This has two advantages. First, it should be faster than a true global policy. Second, it can create a stalemate that prevents change. The problem of a "globally coordinated policy" has been discussed. Rather than have everyone agree not to make changes it's easier to enforce if ARIN's policy says "we'll grant reciprocity to any RIR's policy that contains a requirement to do x, y, and z." A change away from x, y, or z would automatically stop the reciprocity, which is a far greater consequence than having the global policy no longer be coordinated. However, I also agree with Geoff that the larger issue is the potential for unintended consequences. -- 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 michael.dillon at bt.com Tue Feb 12 10:55:07 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 12 Feb 2008 15:55:07 -0000 Subject: [ppml] [sig-policy] Policy Proposal: IPv4 TransferPolicy Proposal In-Reply-To: <20080212152613.GB14759@ussenterprise.ufp.org> References: <47B0794F.40205@arin.net><7.0.1.0.1.20080211164859.05618d40@lacnic.net><47B0C378.8090401@apnic.net><7.0.1.0.1.20080211202317.04fe9300@lacnic.net><47B0D496.2030800@apnic.net> <20080212152613.GB14759@ussenterprise.ufp.org> Message-ID: > Rather than trying to pass a global policy having each region > pass a reciprocity policy of sorts. What's the point? Most of the time, when IP addresses are transferred, it is coupled to the sale of network assets. Two and a half years ago, I worked for an American company that was acquired by a British company. The addresses transferred to the new owner but we do not want to shift them to RIPE. They are still used by the same network assests. It means that we have to pay a bit more money, e.g. $12,000 annual fees to ARIN, but this is peanuts compared to the cost of transferring them to RIPE and making sure that the internal systems and people are ready to cope with this. I don't think we are alone here. Many ISPs maintain several RIR relationships, especially when they have network assets in multiple RIR regions. In fact, is there currently a barrier to doing an ERX style transfer? For instance, imagine that a European ISP built a network in the USA, using RIPE addresses, and then decided to pull out of the USA and sell it to another ISP. The new owner, whether located in the EU or the US, decides that it wants to maintain an ARIN relationship for the address blocks used in its American network. Assume that the ownership transfer of IP addresses within RIPE has already been done. Can this ISP transfer these addresses to ARIN under current rules? If not, why not? What are the specific barriers? If this was a US incorporated owner would it make a difference? > However, I also agree with Geoff that the larger issue is the > potential for unintended consequences. That's what happens when you try to fix something that ain't broke. Quite frankly, I have not seen anything yet which sets out the issues and shows that there is clearly a concrete problem that needs to be fixed. So far it seems more like a game of "me too!" but I'm not convinced that any of the participants have clearly explained what problem they are trying to solve. I'm not interested in policies whose rationale is jumping on someone else's bandwagon when I don't even know where that wagon is headed. --Michael Dillon From sleibrand at internap.com Tue Feb 12 11:24:16 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 12 Feb 2008 10:24:16 -0600 Subject: [ppml] [sig-policy] Policy Proposal: IPv4 TransferPolicy Proposal In-Reply-To: References: <47B0794F.40205@arin.net><7.0.1.0.1.20080211164859.05618d40@lacnic.net><47B0C378.8090401@apnic.net><7.0.1.0.1.20080211202317.04fe9300@lacnic.net><47B0D496.2030800@apnic.net> <20080212152613.GB14759@ussenterprise.ufp.org> Message-ID: <47B1C830.9060309@internap.com> michael.dillon at bt.com wrote: > In fact, is there currently a barrier to doing an ERX style > transfer? For instance, imagine that a European ISP built > a network in the USA, using RIPE addresses, and then decided > to pull out of the USA and sell it to another ISP. The new owner, > whether located in the EU or the US, decides that it wants > to maintain an ARIN relationship for the address blocks used > in its American network. Assume that the ownership transfer of > IP addresses within RIPE has already been done. Can this ISP > transfer these addresses to ARIN under current rules? > > If not, why not? What are the specific barriers? If this was > a US incorporated owner would it make a difference? > My understanding of ERX is that it allows legacy (classful) blocks to be transferred between registries. I think it would be possible to ERX-transfer a Class A /8 or a Class B /16 to another RIR, and then transfer that space under that RIR's transfer policy. However, I don't think there are any good mechanisms for delegating whois and DNS authority for arbitrary CIDR blocks, so I'm not sure the same thing would be possible for a non-legacy non-classful allocation or assignment received from an RIR. > > That's what happens when you try to fix something that ain't broke. > > Quite frankly, I have not seen anything yet which sets out the > issues and shows that there is clearly a concrete problem that > needs to be fixed. So far it seems more like a game of "me too!" > but I'm not convinced that any of the participants have clearly > explained what problem they are trying to solve. > > I'm not interested in policies whose rationale is jumping on > someone else's bandwagon when I don't even know where that > wagon is headed. > The problem that needs to be fixed is that in a couple years we'll no longer be able to assign IPv4 addresses, and it doesn't appear that all the technology will be in place to allow everyone to switch to IPv6 at that point. Given that dual-stack will be required, there will be a continued requirement to be able to get IPv4 addresses. Unless we provide an incentive to encourage organizations to free up IPv4 space, there will not be sufficient IPv4 addresses returned to RIRs to meet that demand. Conversely, if we create a transfer policy that enables a market, that will provide IPv4 holders the necessary incentive to free up IPv4 space (increasing IPv4 supply), and will encourage organizations needing IP addresses to use IPv6 or otherwise reduce their IPv4 needs (reducing IPv4 demand). By balancing supply and demand, a transfer market reduces the overall disruption (cost) to the community of transitioning from IPv4 to IPv6. -Scott From jweyand at computerdata.com Tue Feb 12 12:04:03 2008 From: jweyand at computerdata.com (Jim Weyand) Date: Tue, 12 Feb 2008 12:04:03 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal Message-ID: <1582DCBFF968F044A9A910C0AB177C902CE55A@cliff.cdi.local> Well done! However I see one small issue that probably reflects my lack of understanding: Section 8.4.3 of the proposal below references NRPM 4.2.2. regarding minimum allocation size and section 8.4.1 says, "The transferee may only receive one IPv4 address transfer every 6 months." However NRPM 4.2.2.2.2. says, " Provide information showing that the requested IP address space will be utilized within three months and demonstrating..." Which of course would mean that, to be consistent with the NRPM, a transferee could only buy a three month supply of addresses every six months. -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Member Services Sent: Monday, February 11, 2008 11:35 AM To: ppml at arin.net Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal Resending with a typo that has been corrected in 8.4.2 below. The original text is supposed to have "24 months" twice in that section. Member Services American Registry for Internet Numbers (ARIN) ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision via the PPML. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC shepherds for this proposal are Scott Leibrand and Stacy Taylor. The AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv4 Transfer Policy Proposal Author: ARIN Advisory Council Proposal Version: 1.0 Submission Date: 02/07/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 "M&A Transfer Requirements": 8.2. M&A Transfer Requirements 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.] [8.3 - retitle to "M&A Transfer Documentation Requirements": 8.3. M&A Transfer Documentation Requirements 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.4. Requirements for Simple Transfer of IPv4 Addresses After the exhaustion of the IANA IPv4 free pool, ARIN will also process IPv4 address transfer requests subject to the following conditions. 8.4.1 Conditions on the transferor: * 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.4.2 Conditions on the transferee: * 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 only receive one IPv4 address transfer every 6 months. 8.4.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. 8.4.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.4.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 exact network address and size (CIDR prefix length) the transferor is eligible to provide, and the expiration date of the pre-qualification. 8.5. Safe Harbor for IPv4 Transfers through this Simple Transfer Process IPv4 address resources being made available for transfer shall be exempt from ARIN audit until expiration of the transfer pre-qualification or completion of the transfer. In the event that a transfer pre-qualification expires, ARIN shall have up to 90 days to initiate an audit prior to this exemption being reinstated through subsequent transfer pre-qualification. This will not extend the end of the exemption. 8.6. 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.7. 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. 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 sleibrand at internap.com Tue Feb 12 12:06:39 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 12 Feb 2008 11:06:39 -0600 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <1582DCBFF968F044A9A910C0AB177C902CE55A@cliff.cdi.local> References: <1582DCBFF968F044A9A910C0AB177C902CE55A@cliff.cdi.local> Message-ID: <47B1D21F.5030807@internap.com> No, I think that reflects my failure to actually re-read 4.2.2 when writing 8.4.3. :-) I'll look into that and see what revisions are needed are needed to make them consistent. Good catch. Thanks, Scott Jim Weyand wrote: > Well done! However I see one small issue that probably reflects my lack > of understanding: > > Section 8.4.3 of the proposal below references NRPM 4.2.2. regarding > minimum allocation size and section 8.4.1 says, "The transferee may only > receive one IPv4 address transfer every 6 months." > > However NRPM 4.2.2.2.2. says, " Provide information showing that the > requested IP address space will be utilized within three months and > demonstrating..." > > Which of course would mean that, to be consistent with the NRPM, a > transferee could only buy a three month supply of addresses every six > months. > > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Member Services > Sent: Monday, February 11, 2008 11:35 AM > To: ppml at arin.net > Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal > > Resending with a typo that has been corrected in 8.4.2 below. The > original text is supposed to have "24 months" twice in that section. > > Member Services > American Registry for Internet Numbers (ARIN) > > > > > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as written. If the AC accepts the proposal, it > will be posted as a formal policy proposal to PPML and it will be > presented at a Public Policy Meeting. > > 2. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision via the PPML. If a proposal is not > accepted, then the author may elect to use the petition process to > advance their proposal. If the author elects not to petition or the > petition fails, then the proposal will be closed. > > The AC shepherds for this proposal are Scott Leibrand and Stacy Taylor. > > The AC invites everyone to comment on this proposal on the PPML, > particularly their support or non-support and the reasoning behind their > opinion. Such participation contributes to a thorough vetting and > provides important guidance to the AC in their deliberations. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: IPv4 Transfer Policy Proposal > > Author: ARIN Advisory Council > > Proposal Version: 1.0 > > Submission Date: 02/07/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 "M&A Transfer > Requirements": > > 8.2. M&A Transfer Requirements > > 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.] > > > [8.3 - retitle to "M&A Transfer Documentation Requirements": > > 8.3. M&A Transfer Documentation Requirements > > 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.4. Requirements for Simple Transfer of IPv4 Addresses > > After the exhaustion of the IANA IPv4 free pool, ARIN will also process > IPv4 address transfer requests subject to the following conditions. > > 8.4.1 Conditions on the transferor: > > * 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.4.2 Conditions on the transferee: > > * 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 only receive one IPv4 address transfer every 6 > months. > > > > 8.4.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. > > 8.4.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.4.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 exact network address and size > (CIDR prefix length) the transferor is eligible to provide, and > the expiration date of the pre-qualification. > > 8.5. Safe Harbor for IPv4 Transfers through this Simple Transfer > Process > > IPv4 address resources being made available for transfer shall be exempt > from ARIN audit until expiration of the transfer pre-qualification or > completion of the transfer. In the event that a transfer > pre-qualification expires, ARIN shall have up to 90 days to initiate an > audit prior to this exemption being reinstated through subsequent > transfer pre-qualification. This will not extend the end of the > exemption. > > 8.6. 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.7. 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. > > 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. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > From stephen at sprunk.org Tue Feb 12 11:59:56 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 12 Feb 2008 10:59:56 -0600 Subject: [ppml] [sig-policy] Policy Proposal: IPv4TransferPolicy Proposal References: <47B0794F.40205@arin.net><7.0.1.0.1.20080211164859.05618d40@lacnic.net><47B0C378.8090401@apnic.net><7.0.1.0.1.20080211202317.04fe9300@lacnic.net><47B0D496.2030800@apnic.net><20080212152613.GB14759@ussenterprise.ufp.org> Message-ID: <00bb01c86d9a$249c3fb0$4b3816ac@atlanta.polycom.com> Thus spake > In fact, is there currently a barrier to doing an ERX style > transfer? ERX was only for legacy registrations, which were all on convenient classful boundaries, limited in number, and in specific /8s that were already a mess from a DNS perspective; supporting an unknown number of transfers on arbitrary boundaries in any /8 is a rather more complex and painful undertaking. > For instance, imagine that a European ISP built a network in the USA, > using RIPE addresses, They're not supposed to do that; while it's not written into the policies anywhere I can find, it seems to be accepted that addresses are only to be used in the region of the RIR that issued them, minus incidental use like a large network on one continent dropping a handful of routers at IXes on another continent. If you've got actual customers in a given region, you should be getting addresses for them from the respective RIR, not the one where your headquarters is arbitrarily located this year. How well the above is enforced in practice, I can't tell; my guess is that we don't see much "registry shopping" today because most members of the community voluntarily do the right thing, the RIRs' policies are largely equivalent, and the RIRs' staffs are doing a bit of enforcement via internal policies _not_ voted on by their members. This probably needs fixing, but it doesn't seem urgent at this point. > Assume that the ownership transfer of IP addresses within RIPE has > already been done. Can this ISP transfer these addresses to ARIN > under current rules? > > If not, why not? What are the specific barriers? If this was > a US incorporated owner would it make a difference? AFAIK, there is no process in place to transfer non-legacy blocks from one RIR to another. If you have addresses in a /8 delegated by IANA to a given RIR, status quo is that they'll be registered with that RIR forever. Perhaps that needs to be changed, but we'd need a global policy to do it and AFAIK there is no such proposal on the table at present -- and we're past the deadline for any new proposals in the current ARIN cycle. 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 Feb 12 13:47:46 2008 From: owen at delong.com (Owen DeLong) Date: Tue, 12 Feb 2008 10:47:46 -0800 Subject: [ppml] [sig-policy] Policy Proposal: IPv4TransferPolicy Proposal In-Reply-To: <00bb01c86d9a$249c3fb0$4b3816ac@atlanta.polycom.com> References: <47B0794F.40205@arin.net><7.0.1.0.1.20080211164859.05618d40@lacnic.net><47B0C378.8090401@apnic.net><7.0.1.0.1.20080211202317.04fe9300@lacnic.net><47B0D496.2030800@apnic.net><20080212152613.GB14759@ussenterprise.ufp.org> <00bb01c86d9a$249c3fb0$4b3816ac@atlanta.polycom.com> Message-ID: >> For instance, imagine that a European ISP built a network in the USA, >> using RIPE addresses, > > They're not supposed to do that; while it's not written into the > policies > anywhere I can find, it seems to be accepted that addresses are only > to be > used in the region of the RIR that issued them, minus incidental use > like a > large network on one continent dropping a handful of routers at IXes > on > another continent. If you've got actual customers in a given > region, you > should be getting addresses for them from the respective RIR, not > the one > where your headquarters is arbitrarily located this year. > This isn't entirely true. For example, an international organization with a backbone connecting their various sites could get a single delegation from a single RIR for their global network. It is possible (although not common) to obtain and advertise a single aggregate worldwide. > How well the above is enforced in practice, I can't tell; my guess > is that > we don't see much "registry shopping" today because most members of > the > community voluntarily do the right thing, the RIRs' policies are > largely > equivalent, and the RIRs' staffs are doing a bit of enforcement via > internal > policies _not_ voted on by their members. This probably needs > fixing, but > it doesn't seem urgent at this point. > Actually, the registries do a pretty good job of enforcing what should be enforced. That is, if the addresses aren't going to be advertised at least from the source region, then, they should be obtained from an RIR that covers at least one of the locations where they will be advertised. There isn't much RIR shopping today, primarily because there aren't that many organizations with the international backbone resources necessary to make it feasible, and, the few that do don't really have a need to RIR-shop. Secondarily, the RIR policies and practices are similar enough that there isn't really any major advantage to be obtained by RIR shopping. >> Assume that the ownership transfer of IP addresses within RIPE has >> already been done. Can this ISP transfer these addresses to ARIN >> under current rules? >> >> If not, why not? What are the specific barriers? If this was >> a US incorporated owner would it make a difference? > > AFAIK, there is no process in place to transfer non-legacy blocks > from one > RIR to another. If you have addresses in a /8 delegated by IANA to > a given > RIR, status quo is that they'll be registered with that RIR forever. > Perhaps that needs to be changed, but we'd need a global policy to > do it and > AFAIK there is no such proposal on the table at present -- and we're > past > the deadline for any new proposals in the current ARIN cycle. > That reflects my understanding as well. I'm not convinced that there is significant benefit to providing for inter-regional transfers of non-legacy space compared to the overhead of creating the policies and, more importantly the processes to do such a thing. Owen From BillD at cait.wustl.edu Tue Feb 12 13:50:12 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 12 Feb 2008 12:50:12 -0600 Subject: [ppml] [sig-policy] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <7.0.1.0.1.20080212110845.05a8bb50@lacnic.net> References: <47B0794F.40205@arin.net><7.0.1.0.1.20080211164859.05618d40@lacnic.net><47B0C378.8090401@apnic.net><7.0.1.0.1.20080211202317.04fe9300@lacnic.net><7.0.1.0.1.20080212102939.04fec760@lacnic.net><47B19344.7040707@psg.com> <7.0.1.0.1.20080212110845.05a8bb50@lacnic.net> Message-ID: I wish that a global strategy were more understandable and within reach. What are we talking about....global strategy to what? The problem (a problem) is more localized than the RIR. Need and acquistion of address space (of whatever type) is localized within the requestor.... The RIR and global mission is to make fair and relatively inexpensive allocations and assignments of those resources. That strategy could be to try and force organizations to request 1 type of resource vs another or to encourage it or to, whatever. Please define the need against which a global strategy may be applied and how does it differ what appears to be similar policy proposals emerging from RIRs? Bill Darte > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Raul Echeberria > Sent: Tuesday, February 12, 2008 8:11 AM > To: Ray Plzak; Randy Bush > Cc: ppml at arin.net; sig-policy at apnic.net > Subject: Re: [ppml] [sig-policy] Policy Proposal: IPv4 > Transfer Policy Proposal > > > Ray > > My point is that we first need a global strategy and later > probably global and/or coordinated policies for implementing > that strategy. > And of course, I agree with you regarding commitments, and > rest that you said. > > Raul > > > At 09:45 a.m. 12/02/2008, Ray Plzak wrote: > >Merely pointing out that there are implications to the use > of the term > >globally coordinated policy, a term that has been used many > times over > >the past several months, perhaps a little to glibly. > > > >Even a global and coordinated strategy will require > commitments, once > >made, must not be subject to disassembly by the subsequent > actions of a > >single RIR. Once that happens the global and coordinated strategy is > >neither global or coordinated. Think locally while acting > globally is > >more than just a catchy phrase. > > > >Ray > > > > > -----Original Message----- > > > From: Randy Bush [mailto:randy at psg.com] > > > Sent: Tuesday, February 12, 2008 7:38 AM > > > To: Raul Echeberria > > > Cc: Ray Plzak; ppml at arin.net; sig-policy at apnic.net > > > Subject: Re: [sig-policy] [ppml] Policy Proposal: IPv4 Transfer > > > Policy Proposal > > > > > > > I am not necessarily claiming for a global or a > coordinated policy > > > > (maybe yes), but for a global "and" coordinated strategy for > > > > dealing with a global problem. > > > > > > too radical. it is our right to think locally while > acting globally. > > > that's why there are five rirs, right? > > > > > > randy > > > >* sig-policy: APNIC SIG on resource management > >policy * > >_______________________________________________ > >sig-policy mailing list > >sig-policy at lists.apnic.net > >http://mailman.apnic.net/mailman/listinfo/sig-policy > > > > > >-- > >No virus found in this incoming message. > >Checked by AVG Free Edition. > >Version: 7.5.516 / Virus Database: 269.20.2/1273 - Release Date: > >12/02/2008 09:31 a.m. > > > _______________________________________________ > 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 Tue Feb 12 14:12:10 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 12 Feb 2008 13:12:10 -0600 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <1202807058.11775.13.camel@obelix.sandbu> References: <1202807058.11775.13.camel@obelix.sandbu> Message-ID: > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Per Heldal > Sent: Tuesday, February 12, 2008 3:04 AM > To: Ted Mittelstaedt > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal > > > On Mon, 2008-02-11 at 16:36 -0800, Ted Mittelstaedt wrote: > > I have some concerns with this proposal. > > > > This policy seems to undermine the idea that IP addressing > is assigned > > on the basis of proving need. It lends credibility to the > idea that > > IP addressing is property, and could open the door to any number of > > lawsuits based on this. For example if an organization "purchases" > > IPv4 they could then file a lawsuit against a large provider which > > decided to block access from that purchased block, claiming > > discriminatory behavior. > > The suggested policy also seems to be in conflict with the > RIR principle of not being involved in routing. Wherever > there's money to be made there's greed and that can't be > contained by simply telling people to "be nice". The value of > this kind of policy is questionable if it cannot be enforced. > To regulate other people's use of resources is fundamentally > different from the task of coordinating handouts from a resource-pool. The transfer policy proposal does not attempt to eliminate greed, nor does it try and enforce people to be nice. It trys to coordinate transfers in such a way that does not abandon the notion of 'justified need' and also provides continuing stability in the industry and confidence that the address resources and associated ARIN services that are being transferred are as close to the free-pool precedent as possible, by way of thinking... The policy does not restrict people from transferring resource in some other way and with whatever conditions and qualifications are made... I intends to give the ARIN region an alternative and clear set of conditions under which transfers are made and recognized. The expected value is that people with TRUST this process more if ARIN contributes to or coordinates it. Bill Darte > > //per > > > > _______________________________________________ > 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 Tue Feb 12 14:34:04 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 12 Feb 2008 14:34:04 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <1202807058.11775.13.camel@obelix.sandbu> References: <1202807058.11775.13.camel@obelix.sandbu> Message-ID: <20080212193404.GB32279@ussenterprise.ufp.org> In a message written on Tue, Feb 12, 2008 at 10:04:18AM +0100, Per Heldal wrote: > The suggested policy also seems to be in conflict with the RIR principle > of not being involved in routing. Wherever there's money to be made I don't believe there is any such RIR principle. All of the RIR's take a lot of input from those who do routing. Many of the allocation policies were written by those familar with routing in an effort to lead to an efficient, stable routing system. What the RIR's have said repeatedly is that they cannot guarantee routeability. No RIR can promise that some ISP will get your route in a table somewhere. -- 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 plzak at arin.net Tue Feb 12 14:46:54 2008 From: plzak at arin.net (Ray Plzak) Date: Tue, 12 Feb 2008 14:46:54 -0500 Subject: [ppml] [sig-policy] Policy Proposal: IPv4 TransferPolicy Proposal In-Reply-To: <47B1C830.9060309@internap.com> References: <47B0794F.40205@arin.net><7.0.1.0.1.20080211164859.05618d40@lacnic.net><47B0C378.8090401@apnic.net><7.0.1.0.1.20080211202317.04fe9300@lacnic.net><47B0D496.2030800@apnic.net> <20080212152613.GB14759@ussenterprise.ufp.org> <47B1C830.9060309@internap.com> Message-ID: The purpose of the ERX (Early Registration Transfer) project was to align the administration of the DNS of a legacy netblock to the region in which that recipient was resident. Prior to this, holders of address space that they received from the InterNIC had all of the attributes of their record in the database of the RIR where they resided (for example a European legacy holder's whois record was in the RIPE database) except for those attributes that pertained to the DNS. All DNS records were maintained by ARIN as ARIN was the administrator for all legacy address space zones. This caused the holder of such address space to have to deal with two RIRs for routine database maintenance. ERX changed this so that the holder only had to interact with one RIR. DNS maintenance was accomplished by production of the zone file by all the RIRs concerned with the servers being operated by the RIR holding the most records in the /8. The ERX process is not a means by which holders of address space may transfer holding between RIRs. It is a strictly a means by which to administer the DNS of a /8 zone when more than 1 RIR has holdings in that zone. Ray > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Scott Leibrand > Sent: Tuesday, February 12, 2008 11:24 AM > To: michael.dillon at bt.com > Cc: ppml at arin.net > Subject: Re: [ppml] [sig-policy] Policy Proposal: IPv4 TransferPolicy > Proposal > > michael.dillon at bt.com wrote: > > In fact, is there currently a barrier to doing an ERX style > > transfer? For instance, imagine that a European ISP built > > a network in the USA, using RIPE addresses, and then decided > > to pull out of the USA and sell it to another ISP. The new owner, > > whether located in the EU or the US, decides that it wants > > to maintain an ARIN relationship for the address blocks used > > in its American network. Assume that the ownership transfer of > > IP addresses within RIPE has already been done. Can this ISP > > transfer these addresses to ARIN under current rules? > > > > If not, why not? What are the specific barriers? If this was > > a US incorporated owner would it make a difference? > > > > My understanding of ERX is that it allows legacy (classful) blocks to > be > transferred between registries. I think it would be possible to > ERX-transfer a Class A /8 or a Class B /16 to another RIR, and then > transfer that space under that RIR's transfer policy. However, I don't > think there are any good mechanisms for delegating whois and DNS > authority for arbitrary CIDR blocks, so I'm not sure the same thing > would be possible for a non-legacy non-classful allocation or > assignment > received from an RIR. > > > > > That's what happens when you try to fix something that ain't broke. > > > > Quite frankly, I have not seen anything yet which sets out the > > issues and shows that there is clearly a concrete problem that > > needs to be fixed. So far it seems more like a game of "me too!" > > but I'm not convinced that any of the participants have clearly > > explained what problem they are trying to solve. > > > > I'm not interested in policies whose rationale is jumping on > > someone else's bandwagon when I don't even know where that > > wagon is headed. > > > > The problem that needs to be fixed is that in a couple years we'll no > longer be able to assign IPv4 addresses, and it doesn't appear that all > the technology will be in place to allow everyone to switch to IPv6 at > that point. Given that dual-stack will be required, there will be a > continued requirement to be able to get IPv4 addresses. Unless we > provide an incentive to encourage organizations to free up IPv4 space, > there will not be sufficient IPv4 addresses returned to RIRs to meet > that demand. Conversely, if we create a transfer policy that enables a > market, that will provide IPv4 holders the necessary incentive to free > up IPv4 space (increasing IPv4 supply), and will encourage > organizations > needing IP addresses to use IPv6 or otherwise reduce their IPv4 needs > (reducing IPv4 demand). By balancing supply and demand, a transfer > market reduces the overall disruption (cost) to the community of > transitioning from IPv4 to IPv6. > > -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 heldal at eml.cc Tue Feb 12 14:48:30 2008 From: heldal at eml.cc (Per Heldal) Date: Tue, 12 Feb 2008 20:48:30 +0100 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: <1202807058.11775.13.camel@obelix.sandbu> Message-ID: <1202845710.11775.22.camel@obelix.sandbu> On Tue, 2008-02-12 at 13:12 -0600, Bill Darte wrote: > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > Behalf Of Per Heldal > > Sent: Tuesday, February 12, 2008 3:04 AM > > To: Ted Mittelstaedt > > Cc: ppml at arin.net > > Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal > > > > > > On Mon, 2008-02-11 at 16:36 -0800, Ted Mittelstaedt wrote: > > > I have some concerns with this proposal. > > > > > > This policy seems to undermine the idea that IP addressing > > is assigned > > > on the basis of proving need. It lends credibility to the > > idea that > > > IP addressing is property, and could open the door to any number of > > > lawsuits based on this. For example if an organization "purchases" > > > IPv4 they could then file a lawsuit against a large provider which > > > decided to block access from that purchased block, claiming > > > discriminatory behavior. > > > > The suggested policy also seems to be in conflict with the > > RIR principle of not being involved in routing. Wherever > > there's money to be made there's greed and that can't be > > contained by simply telling people to "be nice". The value of > > this kind of policy is questionable if it cannot be enforced. > > To regulate other people's use of resources is fundamentally > > different from the task of coordinating handouts from a resource-pool. > > > The transfer policy proposal does not attempt to eliminate greed, nor > does it try and enforce people to be nice. > It trys to coordinate transfers in such a way that does not abandon the > notion of 'justified need' and also provides continuing stability in the > industry and confidence that the address resources and associated ARIN > services that are being transferred are as close to the free-pool > precedent as possible, by way of thinking... > You define conditions which must be met to approve transfer, yet claim to place no restrictions on the process transfer ??? > The policy does not restrict people from transferring resource in some > other way and with whatever conditions and qualifications are made... I > intends to give the ARIN region an alternative and clear set of > conditions under which transfers are made and recognized. The expected > value is that people with TRUST this process more if ARIN contributes to > or coordinates it. I agree with the motive, but think it's naive to expect the desired effect unless there are sanctions in place to deal with offenders (LIRs required to drop/filter disputed blocks or similar), but then you're back in conflict with the traditional hands-off-approach to routing again. //per From heldal at eml.cc Tue Feb 12 15:10:40 2008 From: heldal at eml.cc (Per Heldal) Date: Tue, 12 Feb 2008 21:10:40 +0100 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <20080212193404.GB32279@ussenterprise.ufp.org> References: <1202807058.11775.13.camel@obelix.sandbu> <20080212193404.GB32279@ussenterprise.ufp.org> Message-ID: <1202847040.11775.42.camel@obelix.sandbu> On Tue, 2008-02-12 at 14:34 -0500, Leo Bicknell wrote: > In a message written on Tue, Feb 12, 2008 at 10:04:18AM +0100, Per Heldal wrote: > > The suggested policy also seems to be in conflict with the RIR principle > > of not being involved in routing. Wherever there's money to be made > > I don't believe there is any such RIR principle. > Not to say what is right or wrong, but there has been a general attitude against operational involvement in routing. At least within the RIRs I know (RIPE, ARIN and APNIC) going back to the late 90's. That has translated into e.g.: - weak or missing mechanisms to deal with policy offenders. - weak and mainly unofficial recommendations wrt various aspects of prefix filtering. The general expression communicated has been "we're not the routing police" ... which may be ok, until you create policies that make no sense unenforced. > All of the RIR's take a lot of input from those who do routing. > Many of the allocation policies were written by those familar with > routing in an effort to lead to an efficient, stable routing system. > > What the RIR's have said repeatedly is that they cannot guarantee > routeability. No RIR can promise that some ISP will get your route > in a table somewhere. All the RIRs can guarantee under current policies is uniqueness wrt the allocations they make from the blocks they've been delegated authority for. ("RIR" is here the ops-unit that do the actual work. For the RIR-community things can quickly change if there's political motivation within the community for change.) //per From david.kessens at nsn.com Tue Feb 12 16:49:34 2008 From: david.kessens at nsn.com (David Kessens) Date: Tue, 12 Feb 2008 13:49:34 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <7.0.1.0.1.20080211202317.04fe9300@lacnic.net> References: <47B0794F.40205@arin.net> <7.0.1.0.1.20080211164859.05618d40@lacnic.net> <47B0C378.8090401@apnic.net> <7.0.1.0.1.20080211202317.04fe9300@lacnic.net> Message-ID: <20080212214934.GF6961@nsn.com> Raul, On Mon, Feb 11, 2008 at 08:31:34PM -0300, Raul Echeberria wrote: > > One observation. > > Accepting transfers only within the region is a > way to keep the IP addresses within the regions > in which they were originally allocated. > I don't know if it is good or not, but a fact. I would formulate this slightly different: Accepting transfers within the region is a way to keep the IP addresses *registered* within the same region. When the problems are big enough, people will find ways around arbritrary and restrictive procedures that are designed to keep addresses within a certain region. In addition, liquidity is key to providing a viable and vibrant marketplace. Barriers to this usually only benefit people in the arbitrage business in addition to larger corporations that have a much easier time to operate across borders. David Kessens --- From schiller at uu.net Tue Feb 12 16:52:18 2008 From: schiller at uu.net (Jason Schiller) Date: Tue, 12 Feb 2008 16:52:18 -0500 (EST) Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal - 24 month freeze In-Reply-To: <47B07198.2050106@arin.net> Message-ID: I have concerns about section 8.4.1 and 8.4.2. At a high level these sections say if you receive a transfer (act as a transferee) or transfer a block (act as a transferor) then you will be prevented from requesting additional address space for 24 months. This may be problematic if one of the following occurs: 1. Sell or spin off a portion of the network that is less profitable, (this includes some network assets, all of its customers on those assets, and a transfer of the associated addresses) but continue to grow the remaining network thereby requiring additional addresses. 2. Purchase another company that represents a profitable niche market or profitable niche service, (this includes some of its network assets, all of its customers on those assets and transfer of the associated addresses) but continue to grow the pre-exist network thereby requiring additional addresses, while maintaining the purchased customer base or services and their associated address utilization 3. Performing two or more spin offs or acquisitions with a 24 month period with no need for additional addresses. Is this 24 month freeze the intention of the policy, or an over sight? ___Jason On Tue, 12 Feb 2008 michael.dillon at bt.com wrote: > Most of the time, when IP addresses are transferred, it is > coupled to the sale of network assets. On Mon, 11 Feb 2008, Member Services wrote: > 8.4. Requirements for Simple Transfer of IPv4 Addresses > > After the exhaustion of the IANA IPv4 free pool, ARIN will also process > IPv4 address transfer requests subject to the following conditions. > > 8.4.1 Conditions on the transferor: > > * 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.4.2 Conditions on the transferee: > > * 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 2 > 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 only receive one IPv4 address transfer every 6 > months. > > > From sleibrand at internap.com Tue Feb 12 17:12:07 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 12 Feb 2008 16:12:07 -0600 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal - 24 month freeze In-Reply-To: References: Message-ID: <47B219B7.9070209@internap.com> Jason Schiller wrote: > I have concerns about section 8.4.1 and 8.4.2. At a high level these > sections say if you receive a transfer (act as a transferee) or transfer a > block (act as a transferor) then you will be prevented from requesting > additional address space for 24 months. > The 24 month timeframe is only if you want to switch from being a transferor to a transferee, or vice versa. That is to prevent speculation. If you perform an M&A transfer (the kind allowed by current policy), those restrictions do not apply, and you can still get addresses as a transferee through the Simple IPv4 transfer policy. There is a 6-month restriction on getting additional address space, which is intended to make sure you get a big enough block the first time to meet your needs for that timeframe, rather than scraping up lots of smaller netblocks. However, it doesn't sound like that's what you're referring to. -Scott > This may be problematic if one of the following occurs: > > 1. Sell or spin off a portion of the network that is less profitable, > (this includes some network assets, all of its customers on those assets, > and a transfer of the associated addresses) but continue to grow the > remaining network thereby requiring additional addresses. > > 2. Purchase another company that represents a profitable niche market or > profitable niche service, (this includes some of its network assets, all > of its customers on those assets and transfer of the associated > addresses) but continue to grow the pre-exist network thereby requiring > additional addresses, while maintaining the purchased customer base or > services and their associated address utilization > > 3. Performing two or more spin offs or acquisitions with a 24 month period > with no need for additional addresses. > > Is this 24 month freeze the intention of the policy, or an over sight? > > ___Jason > > On Tue, 12 Feb 2008 michael.dillon at bt.com wrote: > >> Most of the time, when IP addresses are transferred, it is >> coupled to the sale of network assets. >> > > On Mon, 11 Feb 2008, Member Services wrote: > > >> 8.4. Requirements for Simple Transfer of IPv4 Addresses >> >> After the exhaustion of the IANA IPv4 free pool, ARIN will also process >> IPv4 address transfer requests subject to the following conditions. >> >> 8.4.1 Conditions on the transferor: >> >> * 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.4.2 Conditions on the transferee: >> >> * 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 2 >> 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 only receive one IPv4 address transfer every 6 >> months. >> >> >> >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 JOHN at egh.com Tue Feb 12 17:14:43 2008 From: JOHN at egh.com (John Santos) Date: Tue, 12 Feb 2008 17:14:43 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal - 24 month freeze In-Reply-To: Message-ID: <1080212170120.549A-100000@Ives.egh.com> On Tue, 12 Feb 2008, Jason Schiller wrote: > I have concerns about section 8.4.1 and 8.4.2. At a high level these > sections say if you receive a transfer (act as a transferee) or transfer a > block (act as a transferor) then you will be prevented from requesting > additional address space for 24 months. > > This may be problematic if one of the following occurs: > > 1. Sell or spin off a portion of the network that is less profitable, > (this includes some network assets, all of its customers on those assets, > and a transfer of the associated addresses) but continue to grow the > remaining network thereby requiring additional addresses. > > 2. Purchase another company that represents a profitable niche market or > profitable niche service, (this includes some of its network assets, all > of its customers on those assets and transfer of the associated > addresses) but continue to grow the pre-exist network thereby requiring > additional addresses, while maintaining the purchased customer base or > services and their associated address utilization > > 3. Performing two or more spin offs or acquisitions with a 24 month period > with no need for additional addresses. > > Is this 24 month freeze the intention of the policy, or an over sight? > > ___Jason > My understanding is that is has always been possible to transfer address space when companies merge or are acquired by other companies, (or presumably when part of a company is spun off.) The physical network with its addresses intact is transfered to the new company. For example, HP now controls the DEC /8 because DEC merged with Compaq and HP then bought the combined Compaq/DEC. And a million other examples. I think the theory is if the original company had demonstrated need for the address space, and the new company is continuing to operate the original network, then it clearly has need for the (same) address space. As I understand it, the new policy here is intended to deal with cases where there is *no* ongoing business relationship between the transferor and the transferee, one just has available address space which the other needs, and they've come to an agreement (pending ARIN approval), presumably for cash or other consideration. So Jason's scenario would fall under existing policies and the new policy would not apply. Please correct me if I'm wrong. (Maybe DEC isn't a good example above because it's most likely a legacy, but I'm sure there are a hundreds if not thousands of other examples.) -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From sleibrand at internap.com Wed Feb 13 10:33:28 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 13 Feb 2008 10:33:28 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: <47B12650.2060107@internap.com> Message-ID: <47B30DC8.5020907@internap.com> michael.dillon at bt.com wrote: >> Yes. There is a large installed base for whom migrating to >> IPv6 may be painful (expensive). Reducing the community's >> total expense for operating their IP networks is a benefit to >> the Internet community. >> > > RED HERRING! > > Given the fact that ISPs who implement IPv6 transit service > will also have to implement transition mechanisms such as > Teredo, 6to4, etc., there is no imperative for any part of > the installed base to migrate to IPv6 before they are ready. > > The imperative today is for those organizations with steadily > growing networks at the heart of their business model (ISPs) > to begin transitioning. Whether it is painful or not, they must > do it or die because network growth is fundamental to their > being. > I think you make an unjustified assumption that ISPs will be able to deploy IPv6-only service to new customers and operate transition mechanisms such as Teredo, 6to4, etc. An alternative, and IMO more likely, transition mechanism is to use two much more familiar technologies: dual stack and NAT. Many consumer ISPs will be able to start providing IPv6 support, provide the ability for their customers to dual-stack, and then start providing NAT'd RFC1918 addresses to their DHCP customers instead of public IPs. This will be fairly easy for some ISPs, and more difficult for others (such as business ISPs, with more static-IP customers and smaller DHCP pools). In addition, there will be a great diversity of IPv6 support in middleboxes (home routers, enterprise firewalls, etc.) Given this diversity in cost of migrating to IPv6 (dual-stack) and reducing IPv4 demand, there is an opportunity to allow organizations for whom the migration cost is higher to delay migration until IPv6 technology is better developed/deployed, and in the mean time get IPv4 addresses from other organizations for whom the migration cost is lower. Additionally, such a transfer policy would provide an incentive to encourage organizations to migrate their installed base to some form of IPv6 where it's easier to do so, rather than requiring growing networks to do so if it's more expensive for them. > If an ISP decided to try and avoid implementing IPv6 by getting > IPv4 addresses from other sources, they are simply backing > themselves into a corner and relying on their competitors to > operate transition mechanisms for them. This is a risky strategy > since the market segment who are willing to buy IPv4 network > access will be steadily shrinking. In addition, their existing > customers will begin to move away because the ISP is perceived > as being incompetent and at risk of hitting a brick wall. > I suspect that after ARIN free pool exhaustion, all ISPs will offer some form of IPv6 service. To do so successfully, and support dual-stack, however, there will be a continued need for IPv4 addresses. In some cases, a network may be able to free up enough IPv4 addresses to allow them to transfer them to other organizations. In other cases, they'll be able to free up some, but not all, of their existing IPv4 addresses and use the remainder for growth. In other cases, growth may overtake the ability of a network to cost-effectively reclaim IPv4 addresses (possibly due to a small install base), so continued availability of addresses from other organizations will be essential to avoiding much higher transition costs than are necessary. > >> This policy >> proposal allows organizations to choose what's best for them, >> rather than forcing a one-size-fits-all solution. >> > > I disagree that this policy does what you say. In fact this policy > is trying to set up a market for buying and selling IP addresses. > I don't think we're in disagreement here. This policy proposal allows organizations to choose what's best for them by setting up a market for transferring IP addresses. The addresses aren't property, so no one will be buying and selling the addresses themselves, but the underlying market economics will be similar. > Under current policy, an ISP who migrates infrastructure to IPv6 > can return their IPv4 addresses to ARIN. And an ISP who is not > migrating can continue to apply to ARIN for more IPv4 addresses > and receive the returned ones. > > This is clear and simple and easy to understand. It is the way > that IPv4 allocation has always been done and is fully understood > by everybody who deals with IP networking. Any new policy like > the one proposed, simply muddies the waters and creates confusion. > Yes, it is clear and simple, but it is not sufficient. If a network has no incentive to go to the trouble of renumbering out of IPv4 addresses, they won't return them, and there won't be enough IPv4 addresses to meet the needs of those who need more addresses. However, if the transfer process can cover the cost of renumbering, many more organizations will choose to do so. To put it in basic economic terms, if we fix the price of scarce IPv4 addresses at zero (by leaving policy unchanged), supply will be insufficient to meet demand after the free pool is exhausted. If we allow price to be set by a market, the price will rise to the point where it increases supply and reduces demand enough to get them into balance. -Scott From schiller at uu.net Wed Feb 13 10:36:17 2008 From: schiller at uu.net (Jason Schiller) Date: Wed, 13 Feb 2008 10:36:17 -0500 (EST) Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal - 24 month freeze In-Reply-To: <47B219B7.9070209@internap.com> Message-ID: Scott, Thanks for the clarification... It wasn't clear to me from the text that section 8.4 does not apply to M&A transfers even after IANA exhaustion. Maybe that could be a bit more specific? __Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Tue, 12 Feb 2008, Scott Leibrand wrote: > Date: Tue, 12 Feb 2008 16:12:07 -0600 > From: Scott Leibrand > To: Jason Schiller > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal - 24 > month freeze > > Jason Schiller wrote: > > I have concerns about section 8.4.1 and 8.4.2. At a high level these > > sections say if you receive a transfer (act as a transferee) or transfer a > > block (act as a transferor) then you will be prevented from requesting > > additional address space for 24 months. > > > > The 24 month timeframe is only if you want to switch from being a > transferor to a transferee, or vice versa. That is to prevent > speculation. If you perform an M&A transfer (the kind allowed by current > policy), those restrictions do not apply, and you can still get > addresses as a transferee through the Simple IPv4 transfer policy. > > There is a 6-month restriction on getting additional address space, > which is intended to make sure you get a big enough block the first time > to meet your needs for that timeframe, rather than scraping up lots of > smaller netblocks. However, it doesn't sound like that's what you're > referring to. > > -Scott > > > This may be problematic if one of the following occurs: > > > > 1. Sell or spin off a portion of the network that is less profitable, > > (this includes some network assets, all of its customers on those assets, > > and a transfer of the associated addresses) but continue to grow the > > remaining network thereby requiring additional addresses. > > > > 2. Purchase another company that represents a profitable niche market or > > profitable niche service, (this includes some of its network assets, all > > of its customers on those assets and transfer of the associated > > addresses) but continue to grow the pre-exist network thereby requiring > > additional addresses, while maintaining the purchased customer base or > > services and their associated address utilization > > > > 3. Performing two or more spin offs or acquisitions with a 24 month period > > with no need for additional addresses. > > > > Is this 24 month freeze the intention of the policy, or an over sight? > > > > ___Jason > > > > On Tue, 12 Feb 2008 michael.dillon at bt.com wrote: > > > >> Most of the time, when IP addresses are transferred, it is > >> coupled to the sale of network assets. > >> > > > > On Mon, 11 Feb 2008, Member Services wrote: > > > > > >> 8.4. Requirements for Simple Transfer of IPv4 Addresses > >> > >> After the exhaustion of the IANA IPv4 free pool, ARIN will also process > >> IPv4 address transfer requests subject to the following conditions. > >> > >> 8.4.1 Conditions on the transferor: > >> > >> * 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.4.2 Conditions on the transferee: > >> > >> * 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 2 > >> 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 only receive one IPv4 address transfer every 6 > >> months. > >> > >> > >> > >> > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN Public Policy > > Mailing List (PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml > > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > > > From sleibrand at internap.com Wed Feb 13 10:42:44 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 13 Feb 2008 10:42:44 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal - 24 month freeze In-Reply-To: References: Message-ID: <47B30FF4.30409@internap.com> Ok. How about adding this last sentence to the first paragraph of 8.4: 8.4. Requirements for Simple Transfer of IPv4 Addresses After the exhaustion of the IANA IPv4 free pool, ARIN will also process IPv4 address transfer requests subject to the following conditions. These conditions apply only to Simple IPv4 transfers, not to M&A transfers performed according to section 8.3. -Scott Jason Schiller wrote: > Scott, > > Thanks for the clarification... > > It wasn't clear to me from the text that section 8.4 does not apply to M&A > transfers even after IANA exhaustion. Maybe that could be a bit more > specific? > > __Jason > > ========================================================================== > Jason Schiller (703)886.6648 > Senior Internet Network Engineer fax:(703)886.0512 > Public IP Global Network Engineering schiller at uu.net > UUNET / Verizon jason.schiller at verizonbusiness.com > > The good news about having an email address that is twice as long is that > it increases traffic on the Internet. > > On Tue, 12 Feb 2008, Scott Leibrand wrote: > > >> Date: Tue, 12 Feb 2008 16:12:07 -0600 >> From: Scott Leibrand >> To: Jason Schiller >> Cc: ppml at arin.net >> Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal - 24 >> month freeze >> >> Jason Schiller wrote: >> >>> I have concerns about section 8.4.1 and 8.4.2. At a high level these >>> sections say if you receive a transfer (act as a transferee) or transfer a >>> block (act as a transferor) then you will be prevented from requesting >>> additional address space for 24 months. >>> >>> >> The 24 month timeframe is only if you want to switch from being a >> transferor to a transferee, or vice versa. That is to prevent >> speculation. If you perform an M&A transfer (the kind allowed by current >> policy), those restrictions do not apply, and you can still get >> addresses as a transferee through the Simple IPv4 transfer policy. >> >> There is a 6-month restriction on getting additional address space, >> which is intended to make sure you get a big enough block the first time >> to meet your needs for that timeframe, rather than scraping up lots of >> smaller netblocks. However, it doesn't sound like that's what you're >> referring to. >> >> -Scott >> >> >>> This may be problematic if one of the following occurs: >>> >>> 1. Sell or spin off a portion of the network that is less profitable, >>> (this includes some network assets, all of its customers on those assets, >>> and a transfer of the associated addresses) but continue to grow the >>> remaining network thereby requiring additional addresses. >>> >>> 2. Purchase another company that represents a profitable niche market or >>> profitable niche service, (this includes some of its network assets, all >>> of its customers on those assets and transfer of the associated >>> addresses) but continue to grow the pre-exist network thereby requiring >>> additional addresses, while maintaining the purchased customer base or >>> services and their associated address utilization >>> >>> 3. Performing two or more spin offs or acquisitions with a 24 month period >>> with no need for additional addresses. >>> >>> Is this 24 month freeze the intention of the policy, or an over sight? >>> >>> ___Jason >>> >>> On Tue, 12 Feb 2008 michael.dillon at bt.com wrote: >>> >>> >>>> Most of the time, when IP addresses are transferred, it is >>>> coupled to the sale of network assets. >>>> >>>> >>> On Mon, 11 Feb 2008, Member Services wrote: >>> >>> >>> >>>> 8.4. Requirements for Simple Transfer of IPv4 Addresses >>>> >>>> After the exhaustion of the IANA IPv4 free pool, ARIN will also process >>>> IPv4 address transfer requests subject to the following conditions. >>>> >>>> 8.4.1 Conditions on the transferor: >>>> >>>> * 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.4.2 Conditions on the transferee: >>>> >>>> * 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 2 >>>> 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 only receive one IPv4 address transfer every 6 >>>> months. >>>> >>>> >>>> >>>> >>>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to the ARIN Public Policy >>> Mailing List (PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/ppml >>> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. >>> >>> > > From sleibrand at internap.com Wed Feb 13 11:13:22 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 13 Feb 2008 11:13:22 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B1D21F.5030807@internap.com> References: <1582DCBFF968F044A9A910C0AB177C902CE55A@cliff.cdi.local> <47B1D21F.5030807@internap.com> Message-ID: <47B31722.5080600@internap.com> Jim, Reading over 4.2 and 4.3 of the NRPM, I see lots of different conditions for different types of networks. Specifically, the text in 4.2.2.1.3 and 4.2.2.2.2 requiring that the requested IP address space will be utilized within three months refers to organizations justifying an initial allocation on the basis of their use of PA space, and is intended to minimize delay in renumbering out of PA space (if applicable) and beginning to use and route the new space. As I read those sections, they don't require 100% utilization within three months. However, in 4.2.4.3 and 4.2.4.4, it does appear that a new ISP that needs additional space before they've been an ARIN member for a year can only justify a three-month supply of addresses. After that, they can get six months' worth. In the case of end users, they can get over a year's worth of space according to 4.3.3. Given all this confusion, I'd like to decouple the 8.4 transfer policy's transfer sizes somewhat from the allocation and assignment sizes in 4.2 and 4.3, by adding the following bullet point to 8.4.2: * The transferee may request and receive a contiguous CIDR block large enough to provide a 12 month supply of IPv4 addresses. That will preserve the requirement that need and efficient use are justified, but would bypass the sections of 4.2 and 4.3 concerned with preventing hoarding (intentional or otherwise). My assumption here is that the cost of transferring addresses and a 12-month supply rule would act as a sufficient brake to prevent anyone from getting more addresses than they need for that timeframe. The 12-month supply should also be sufficient, in concert with the one-block-every-6-months condition, to ensure that transferees get enough address space to limit unnecessary deaggregation. Thoughts? -Scott > > > 4.2.2.1.3. Three months > > Provide detailed information showing specifically how a /20 will be > utilized within three months. > > > 4.2.2.2.2. Three months > > Provide information showing that the requested IP address space will > be utilized within three months and demonstrating an intent to > announce the requested space in a multihomed fashion. > > > 4.2.2.2.4. Additional requests following the initial > allocation > > To receive additional address space following the initial allocation, > multihomed organizations must have returned the original IP address > space to its provider in its entirety and must provide justification > for a new allocation as described above in the section titled > Requirements for Requesting Initial Address Space. > > > 4.2.4.3. Three months > > Provide detailed information showing specifically that the address > space will be utilized within three months. Determination of the > appropriate allocation to be issued is based on efficient utilization > of space within this three-month time frame. > > > 4.2.4.4. Six months > > After a subscriber has been a member of ARIN for one year they may > choose to request a six-month supply of IP addresses. > > > 4.3.3. Utilization rate > > Utilization rate of address space is a key factor in justifying a new > assignment of IP address space. Requesters must show exactly how > previous address assignments have been utilized and must provide > appropriate details to verify their one-year growth projection. The > basic criteria that must be met are: > > * A 25% immediate utilization rate, and > * A 50% utilization rate within one year. > Scott Leibrand wrote: > No, I think that reflects my failure to actually re-read 4.2.2 when > writing 8.4.3. :-) I'll look into that and see what revisions are > needed are needed to make them consistent. Good catch. > > Thanks, > Scott > > Jim Weyand wrote: > >> Well done! However I see one small issue that probably reflects my lack >> of understanding: >> >> Section 8.4.3 of the proposal below references NRPM 4.2.2. regarding >> minimum allocation size and section 8.4.1 says, "The transferee may only >> receive one IPv4 address transfer every 6 months." >> >> However NRPM 4.2.2.2.2. says, " Provide information showing that the >> requested IP address space will be utilized within three months and >> demonstrating..." >> >> Which of course would mean that, to be consistent with the NRPM, a >> transferee could only buy a three month supply of addresses every six >> months. >> >> >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of >> Member Services >> Sent: Monday, February 11, 2008 11:35 AM >> To: ppml at arin.net >> Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal >> >> Resending with a typo that has been corrected in 8.4.2 below. The >> original text is supposed to have "24 months" twice in that section. >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> >> >> ARIN received the following policy proposal. In accordance with the ARIN >> Internet Resource Policy Evaluation Process, the proposal is being >> posted to the ARIN Public Policy Mailing List (PPML) and being placed on >> ARIN's website. >> >> The ARIN Advisory Council (AC) will review this proposal at their next >> regularly scheduled meeting. The AC may decide to: >> >> 1. Accept the proposal as written. If the AC accepts the proposal, it >> will be posted as a formal policy proposal to PPML and it will be >> presented at a Public Policy Meeting. >> >> 2. Not accept the proposal. If the AC does not accept the proposal, >> the AC will explain their decision via the PPML. If a proposal is not >> accepted, then the author may elect to use the petition process to >> advance their proposal. If the author elects not to petition or the >> petition fails, then the proposal will be closed. >> >> The AC shepherds for this proposal are Scott Leibrand and Stacy Taylor. >> >> The AC invites everyone to comment on this proposal on the PPML, >> particularly their support or non-support and the reasoning behind their >> opinion. Such participation contributes to a thorough vetting and >> provides important guidance to the AC in their deliberations. >> >> The ARIN Internet Resource Policy Evaluation Process can be found at: >> http://www.arin.net/policy/irpep.html >> >> Mailing list subscription information can be found at: >> http://www.arin.net/mailing_lists/ >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Policy Proposal Name: IPv4 Transfer Policy Proposal >> >> Author: ARIN Advisory Council >> >> Proposal Version: 1.0 >> >> Submission Date: 02/07/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 "M&A Transfer >> Requirements": >> >> 8.2. M&A Transfer Requirements >> >> 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.] >> >> >> [8.3 - retitle to "M&A Transfer Documentation Requirements": >> >> 8.3. M&A Transfer Documentation Requirements >> >> 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.4. Requirements for Simple Transfer of IPv4 Addresses >> >> After the exhaustion of the IANA IPv4 free pool, ARIN will also process >> IPv4 address transfer requests subject to the following conditions. >> >> 8.4.1 Conditions on the transferor: >> >> * 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.4.2 Conditions on the transferee: >> >> * 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 only receive one IPv4 address transfer every 6 >> months. >> >> >> >> 8.4.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. >> >> 8.4.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.4.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 exact network address and size >> (CIDR prefix length) the transferor is eligible to provide, and >> the expiration date of the pre-qualification. >> >> 8.5. Safe Harbor for IPv4 Transfers through this Simple Transfer >> Process >> >> IPv4 address resources being made available for transfer shall be exempt >> from ARIN audit until expiration of the transfer pre-qualification or >> completion of the transfer. In the event that a transfer >> pre-qualification expires, ARIN shall have up to 90 days to initiate an >> audit prior to this exemption being reinstated through subsequent >> transfer pre-qualification. This will not extend the end of the >> exemption. >> >> 8.6. 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.7. 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. >> >> 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. >> _______________________________________________ >> 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 Wed Feb 13 12:19:07 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 13 Feb 2008 11:19:07 -0600 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B30DC8.5020907@internap.com> References: <47B12650.2060107@internap.com> <47B30DC8.5020907@internap.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> Just to give some feedback FROM one the ISP's you are talking about.. Our plan is to go dual stack as soon as ANY of our upstream providers can feed us dual stack. We are already working on the enterprise dual stack routing, and have actually established an IPv6 tunnel connection (that I don't want to route real traffic over and abuse the network that was so kind as to let us connect). Luckily, we use exclusively Cisco routing hardware, which has dual stack funtionality built in. There is no way we will be able to go IPv6 only until ALL of the major content providers are IPv6 functional, and ALL of the email providers are compliant. Think of how you would complain if your ISP went IPv6 and told you that you could now email to "some" places.. or even "most" places. There are a lot of things that need to be functional before IPv6 is a reality for ISP's.. little stuff like IPv6 RBL's, bug free IPv6 VPN compatibility with ALL of the major VPN hardware and software vendors, IPv6 connectivity for entertainment networks like Xbox Live and PS3, gaming sites, IM protocols, and a host of other applications that consumers rightfully demand. Any one of these "trivial" services not working is a deal killer for an ISP converting to IPv6 only. So whether or not it is more expensive, more work, or otherwise more painful, ISP's will be forced to maintain IPv4 connectivity until content there is obsoleted. What tends to be forgotten, is that for the little guys IPv6 will not be a complete solution until EVERYTHING that is available on IPv4 is also available on IPv6 and the use is just as transparant to the end user. Kevin > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Scott Leibrand > Sent: Wednesday, February 13, 2008 9:33 AM > To: michael.dillon at bt.com > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal > > michael.dillon at bt.com wrote: > >> Yes. There is a large installed base for whom migrating to > >> IPv6 may be painful (expensive). Reducing the community's total > >> expense for operating their IP networks is a benefit to > the Internet > >> community. > >> > > > > RED HERRING! > > > > Given the fact that ISPs who implement IPv6 transit service > will also > > have to implement transition mechanisms such as Teredo, 6to4, etc., > > there is no imperative for any part of the installed base > to migrate > > to IPv6 before they are ready. > > > > The imperative today is for those organizations with > steadily growing > > networks at the heart of their business model (ISPs) to begin > > transitioning. Whether it is painful or not, they must do it or die > > because network growth is fundamental to their being. > > > > I think you make an unjustified assumption that ISPs will be > able to deploy IPv6-only service to new customers and operate > transition mechanisms such as Teredo, 6to4, etc. > > An alternative, and IMO more likely, transition mechanism is > to use two much more familiar technologies: dual stack and > NAT. Many consumer ISPs will be able to start providing IPv6 > support, provide the ability for their customers to > dual-stack, and then start providing NAT'd RFC1918 addresses > to their DHCP customers instead of public IPs. This will be > fairly easy for some ISPs, and more difficult for others > (such as business ISPs, with more static-IP customers and > smaller DHCP pools). > In addition, there will be a great diversity of IPv6 support > in middleboxes (home routers, enterprise firewalls, etc.) > > Given this diversity in cost of migrating to IPv6 > (dual-stack) and reducing IPv4 demand, there is an > opportunity to allow organizations for whom the migration > cost is higher to delay migration until IPv6 technology is > better developed/deployed, and in the mean time get IPv4 > addresses from other organizations for whom the migration > cost is lower. Additionally, such a transfer policy would > provide an incentive to encourage organizations to migrate > their installed base to some form of IPv6 where it's easier > to do so, rather than requiring growing networks to do so if > it's more expensive for them. > > > If an ISP decided to try and avoid implementing IPv6 by getting > > IPv4 addresses from other sources, they are simply backing > themselves > > into a corner and relying on their competitors to operate > transition > > mechanisms for them. This is a risky strategy since the > market segment > > who are willing to buy IPv4 network access will be steadily > shrinking. > > In addition, their existing customers will begin to move > away because > > the ISP is perceived as being incompetent and at risk of hitting a > > brick wall. > > > > I suspect that after ARIN free pool exhaustion, all ISPs will > offer some form of IPv6 service. To do so successfully, and > support dual-stack, however, there will be a continued need > for IPv4 addresses. In some cases, a network may be able to > free up enough IPv4 addresses to allow them to transfer them > to other organizations. In other cases, they'll be able to > free up some, but not all, of their existing IPv4 addresses > and use the remainder for growth. In other cases, growth may > overtake the ability of a network to cost-effectively reclaim > IPv4 addresses (possibly due to a small install base), so > continued availability of addresses from other organizations > will be essential to avoiding much higher transition costs > than are necessary. > > > > >> This policy > >> proposal allows organizations to choose what's best for > them, rather > >> than forcing a one-size-fits-all solution. > >> > > > > I disagree that this policy does what you say. In fact this > policy is > > trying to set up a market for buying and selling IP addresses. > > > > I don't think we're in disagreement here. This policy > proposal allows organizations to choose what's best for them > by setting up a market for transferring IP addresses. The > addresses aren't property, so no one will be buying and > selling the addresses themselves, but the underlying market > economics will be similar. > > Under current policy, an ISP who migrates infrastructure to > IPv6 can > > return their IPv4 addresses to ARIN. And an ISP who is not > migrating > > can continue to apply to ARIN for more IPv4 addresses and > receive the > > returned ones. > > > > This is clear and simple and easy to understand. It is the way that > > IPv4 allocation has always been done and is fully understood by > > everybody who deals with IP networking. Any new policy like the one > > proposed, simply muddies the waters and creates confusion. > > > > Yes, it is clear and simple, but it is not sufficient. If a > network has no incentive to go to the trouble of renumbering > out of IPv4 addresses, they won't return them, and there > won't be enough IPv4 addresses to meet the needs of those who > need more addresses. However, if the transfer process can > cover the cost of renumbering, many more organizations will > choose to do so. To put it in basic economic terms, if we > fix the price of scarce IPv4 addresses at zero (by leaving > policy unchanged), supply will be insufficient to meet demand > after the free pool is exhausted. > If we allow price to be set by a market, the price will rise > to the point where it increases supply and reduces demand > enough to get them into balance. > > -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 michael.dillon at bt.com Wed Feb 13 12:37:14 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 13 Feb 2008 17:37:14 -0000 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B30DC8.5020907@internap.com> References: <47B12650.2060107@internap.com> <47B30DC8.5020907@internap.com> Message-ID: > > The imperative today is for those organizations with > steadily growing > > networks at the heart of their business model (ISPs) to begin > > transitioning. Whether it is painful or not, they must do it or die > > because network growth is fundamental to their being. > Given this diversity in cost of migrating to IPv6 > (dual-stack) and reducing IPv4 demand, there is an > opportunity to allow organizations for whom the migration > cost is higher to delay migration until IPv6 technology is > better developed/deployed, and in the mean time get IPv4 > addresses from other organizations for whom the migration > cost is lower. Additionally, such a transfer policy would > provide an incentive to encourage organizations to migrate > their installed base to some form of IPv6 where it's easier > to do so, rather than requiring growing networks to do so if > it's more expensive for them. I agree that there will be diverse scenarios playing out, but as I said, the pioneers of IPv6 deployment, not migration, wil be ISPs since network growth is at the core of their business model. This does not mean that they will be shrinking their IPv4 networks, and even if they do recover some IPv4 address space, there is no benefit to them to transfer it to someone else. In fact, the benefit to ISPs is to reuse those IPv4 address to continue selling IPv4 services to the market segment which demands that. Given that this whole thing plays out at a time when there is a worldwide scarcity of IPv4 addresses, I can't see any reason for anyone to give up the IPv4 addresses that they have until they are absolutely sure that doing so does not risk serious business losses. That will take years after IANA runs out of IPv4 addresses. An then there is the technical issue of having a usable aggregate of IPv4 addresses to transfer and not scattered small blocks. An ISP has a number of ways of using scattered small blocks, including carrying many long prefixes in their iBGP, but in the global Internet, only large blocks/short prefixes are usable. > I suspect that after ARIN free pool exhaustion, all ISPs will > offer some form of IPv6 service. To do so successfully, and > support dual-stack, however, there will be a continued need > for IPv4 addresses. That's why I don't believe many ISPs will go to dual stack on any kind of scale. It is simpler to use MPLS with 6PE at the edge, or build an IPv6 mesh over GRE or PWE3 on an IPv4 core. This isolates the impact of IPv6 to the edge, and only to those edge routers which are needed for IPv6 services. > > I disagree that this policy does what you say. In fact this > policy is > > trying to set up a market for buying and selling IP addresses. > > I don't think we're in disagreement here. This policy > proposal allows organizations to choose what's best for them > by setting up a market for transferring IP addresses. As I have said in the past, you can't have a market without liquidity and a resource that is not only scarce, but has a cap on supply, simply cannot provide that liquidity. I have no doubt that there will be a few sales of IP address blocks, regardless of whether or not any RIR implements policies to allow it, but the prices will not follow a pattern, and will not be predictable. In general asking prices will be astronomically high, and some sales will actually take place at very high prices. But other sales will go through at a fraction of the asking price because the only reason the address block is on the market is because the seller genuinely has no use for them any more. > Yes, it is clear and simple, but it is not sufficient. If a > network has no incentive to go to the trouble of renumbering > out of IPv4 addresses, they won't return them, and there > won't be enough IPv4 addresses to meet the needs of those who > need more addresses. Since when is it our job to provide incentives to install NAT or IPv6? People have been warned by the RIRs and ICANN that IPv4 is running out. There will be more warnings. Those who don't heed the warnings will get what they deserve. IPv6 and IPv4 are amazingly flexible technologies and with the two to three years of advance warning there is no need for anyone to suffer. If an organization knows that they are absolutely dependent on IPv4 for some part of their network where inflexible devices are attached, they should begin now to make the rest of their network usable without IPv4. In the worst case, where an org needs a steady supply of globally unique IPv4 addresses, they can borrow a block like 126/8 by ensuring that they filter out any route announcements from Softbank Japan. Or similar with another /8. It is not against the law to use IP addresses allocated to another organization if you have no need to communicate with that other organization. If you talk to systems integrators you will learn that this is common practice, not just in the enterprise, but you even run across it inside telecom companies. Running out of IPv4 addresses is not like hitting a brick wall. It's more like colliding with a giant marshmallow and wondering how to get out of the sticky mess. --Michael Dillon From BillD at cait.wustl.edu Wed Feb 13 13:08:35 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Wed, 13 Feb 2008 12:08:35 -0600 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> References: <47B12650.2060107@internap.com><47B30DC8.5020907@internap.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> Message-ID: > > There is no way we will be able to go IPv6 only until ALL of > the major content providers are IPv6 functional, and ALL of > the email providers are compliant. Think of how you would > complain if your ISP went IPv6 and told you that you could > now email to "some" places.. or even "most" > places. > > There are a lot of things that need to be functional before > IPv6 is a reality for ISP's.. little stuff like IPv6 RBL's, > bug free IPv6 VPN compatibility with ALL of the major VPN > hardware and software vendors, > IPv6 connectivity for entertainment networks like Xbox Live > and PS3, gaming sites, IM protocols, and a host of other > applications that consumers rightfully demand. Any one of > these "trivial" services not working is a deal killer for an > ISP converting to IPv6 only. > (Snip) > > What tends to be forgotten, is that for the little guys IPv6 > will not be a complete solution until EVERYTHING that is > available on IPv4 is also available on IPv6 and the use is > just as transparant to the end user. > > Kevin > Thanks for this list of things that you feel must become 'real' before there can be a significant adoption of IPv6 by the industry. I would like to call for others to consider what among this listing of things may NOT be a problem in your experience, and ALSO other serious items that Kevin may have missed including applications. I believe it is important to identify all the stumbling blocks (perhaps as a checklist) that may exist so potential adopters can get a heads up and importantly begin to apply leverage to their vendors for support...in order to reduce the number of hurdles. Or perhaps a comprehensive checklist already exists that I'm unaware of... Finally, I'm interested in initiatives that you know exist or could/should exist (open source projects, research needed, etc.) that would help reduce these stumbling blocks. It would be nice to consider what ARIN (beyond policy and within its charter and mission) could support to promote adoption. Bill Darte ARIN AC From sleibrand at internap.com Wed Feb 13 13:36:25 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 13 Feb 2008 13:36:25 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> References: <47B12650.2060107@internap.com> <47B30DC8.5020907@internap.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> Message-ID: <47B338A9.4010500@internap.com> Thanks for that perspective, Kevin. Do you see a transfer policy like this one as necessary to maintain IPv4 connectivity during the transition? If not, how do you think ISPs like you will deal with the continued need for IPv4 addressing after free pool exhaustion? If so, do you think that this proposed transfer policy strikes a good balance between providing the conditions for a liquid market and preventing unnecessary routing table growth and speculative market behavior? Thanks, Scott Kevin Kargel wrote: > Just to give some feedback FROM one the ISP's you are talking about.. > Our plan is to go dual stack as soon as ANY of our upstream providers > can feed us dual stack. We are already working on the enterprise dual > stack routing, and have actually established an IPv6 tunnel connection > (that I don't want to route real traffic over and abuse the network that > was so kind as to let us connect). Luckily, we use exclusively Cisco > routing hardware, which has dual stack funtionality built in. > > There is no way we will be able to go IPv6 only until ALL of the major > content providers are IPv6 functional, and ALL of the email providers > are compliant. Think of how you would complain if your ISP went IPv6 > and told you that you could now email to "some" places.. or even "most" > places. > > There are a lot of things that need to be functional before IPv6 is a > reality for ISP's.. little stuff like IPv6 RBL's, bug free IPv6 VPN > compatibility with ALL of the major VPN hardware and software vendors, > IPv6 connectivity for entertainment networks like Xbox Live and PS3, > gaming sites, IM protocols, and a host of other applications that > consumers rightfully demand. Any one of these "trivial" services not > working is a deal killer for an ISP converting to IPv6 only. > > So whether or not it is more expensive, more work, or otherwise more > painful, ISP's will be forced to maintain IPv4 connectivity until > content there is obsoleted. > > What tends to be forgotten, is that for the little guys IPv6 will not be > a complete solution until EVERYTHING that is available on IPv4 is also > available on IPv6 and the use is just as transparant to the end user. > > Kevin > > > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >> Behalf Of Scott Leibrand >> Sent: Wednesday, February 13, 2008 9:33 AM >> To: michael.dillon at bt.com >> Cc: ppml at arin.net >> Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal >> >> michael.dillon at bt.com wrote: >> >>>> Yes. There is a large installed base for whom migrating to >>>> IPv6 may be painful (expensive). Reducing the community's total >>>> expense for operating their IP networks is a benefit to >>>> >> the Internet >> >>>> community. >>>> >>>> >>> RED HERRING! >>> >>> Given the fact that ISPs who implement IPv6 transit service >>> >> will also >> >>> have to implement transition mechanisms such as Teredo, 6to4, etc., >>> there is no imperative for any part of the installed base >>> >> to migrate >> >>> to IPv6 before they are ready. >>> >>> The imperative today is for those organizations with >>> >> steadily growing >> >>> networks at the heart of their business model (ISPs) to begin >>> transitioning. Whether it is painful or not, they must do it or die >>> because network growth is fundamental to their being. >>> >>> >> I think you make an unjustified assumption that ISPs will be >> able to deploy IPv6-only service to new customers and operate >> transition mechanisms such as Teredo, 6to4, etc. >> >> An alternative, and IMO more likely, transition mechanism is >> to use two much more familiar technologies: dual stack and >> NAT. Many consumer ISPs will be able to start providing IPv6 >> support, provide the ability for their customers to >> dual-stack, and then start providing NAT'd RFC1918 addresses >> to their DHCP customers instead of public IPs. This will be >> fairly easy for some ISPs, and more difficult for others >> (such as business ISPs, with more static-IP customers and >> smaller DHCP pools). >> In addition, there will be a great diversity of IPv6 support >> in middleboxes (home routers, enterprise firewalls, etc.) >> >> Given this diversity in cost of migrating to IPv6 >> (dual-stack) and reducing IPv4 demand, there is an >> opportunity to allow organizations for whom the migration >> cost is higher to delay migration until IPv6 technology is >> better developed/deployed, and in the mean time get IPv4 >> addresses from other organizations for whom the migration >> cost is lower. Additionally, such a transfer policy would >> provide an incentive to encourage organizations to migrate >> their installed base to some form of IPv6 where it's easier >> to do so, rather than requiring growing networks to do so if >> it's more expensive for them. >> >> >>> If an ISP decided to try and avoid implementing IPv6 by getting >>> IPv4 addresses from other sources, they are simply backing >>> >> themselves >> >>> into a corner and relying on their competitors to operate >>> >> transition >> >>> mechanisms for them. This is a risky strategy since the >>> >> market segment >> >>> who are willing to buy IPv4 network access will be steadily >>> >> shrinking. >> >>> In addition, their existing customers will begin to move >>> >> away because >> >>> the ISP is perceived as being incompetent and at risk of hitting a >>> brick wall. >>> >>> >> I suspect that after ARIN free pool exhaustion, all ISPs will >> offer some form of IPv6 service. To do so successfully, and >> support dual-stack, however, there will be a continued need >> for IPv4 addresses. In some cases, a network may be able to >> free up enough IPv4 addresses to allow them to transfer them >> to other organizations. In other cases, they'll be able to >> free up some, but not all, of their existing IPv4 addresses >> and use the remainder for growth. In other cases, growth may >> overtake the ability of a network to cost-effectively reclaim >> IPv4 addresses (possibly due to a small install base), so >> continued availability of addresses from other organizations >> will be essential to avoiding much higher transition costs >> than are necessary. >> >> >>> >>> >>>> This policy >>>> proposal allows organizations to choose what's best for >>>> >> them, rather >> >>>> than forcing a one-size-fits-all solution. >>>> >>>> >>> I disagree that this policy does what you say. In fact this >>> >> policy is >> >>> trying to set up a market for buying and selling IP addresses. >>> >>> >> I don't think we're in disagreement here. This policy >> proposal allows organizations to choose what's best for them >> by setting up a market for transferring IP addresses. The >> addresses aren't property, so no one will be buying and >> selling the addresses themselves, but the underlying market >> economics will be similar. >> >>> Under current policy, an ISP who migrates infrastructure to >>> >> IPv6 can >> >>> return their IPv4 addresses to ARIN. And an ISP who is not >>> >> migrating >> >>> can continue to apply to ARIN for more IPv4 addresses and >>> >> receive the >> >>> returned ones. >>> >>> This is clear and simple and easy to understand. It is the way that >>> IPv4 allocation has always been done and is fully understood by >>> everybody who deals with IP networking. Any new policy like the one >>> proposed, simply muddies the waters and creates confusion. >>> >>> >> Yes, it is clear and simple, but it is not sufficient. If a >> network has no incentive to go to the trouble of renumbering >> out of IPv4 addresses, they won't return them, and there >> won't be enough IPv4 addresses to meet the needs of those who >> need more addresses. However, if the transfer process can >> cover the cost of renumbering, many more organizations will >> choose to do so. To put it in basic economic terms, if we >> fix the price of scarce IPv4 addresses at zero (by leaving >> policy unchanged), supply will be insufficient to meet demand >> after the free pool is exhausted. >> If we allow price to be set by a market, the price will rise >> to the point where it increases supply and reduces demand >> enough to get them into balance. >> >> -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 jaitken at aitken.com Wed Feb 13 13:45:50 2008 From: jaitken at aitken.com (Jeff Aitken) Date: Wed, 13 Feb 2008 18:45:50 +0000 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> Message-ID: <20080213184550.GB64078@eagle.aitken.com> On Wed, Feb 13, 2008 at 12:08:35PM -0600, Bill Darte wrote: > I believe it is important to identify all the stumbling blocks (perhaps > as a checklist) that may exist so potential adopters can get a heads up > and importantly begin to apply leverage to their vendors for > support...in order to reduce the number of hurdles. > > Or perhaps a comprehensive checklist already exists that I'm unaware > of... Hi Bill, >From Randy's presentation in Albuquerque: http://www.civil-tongue.net/clusterf/ Is that what you were looking for? --Jeff From sleibrand at internap.com Wed Feb 13 13:56:17 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 13 Feb 2008 13:56:17 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: <47B12650.2060107@internap.com> <47B30DC8.5020907@internap.com> Message-ID: <47B33D51.5020503@internap.com> michael.dillon at bt.com wrote: > > I agree that there will be diverse scenarios playing out, but > as I said, the pioneers of IPv6 deployment, not migration, wil > be ISPs since network growth is at the core of their business > model. This does not mean that they will be shrinking their > IPv4 networks, and even if they do recover some IPv4 address > space, there is no benefit to them to transfer it to someone > else. In fact, the benefit to ISPs is to reuse those IPv4 > address to continue selling IPv4 services to the market segment > which demands that. > Of course there will be a benefit to transferring the IPv4 addresses to someone else: that someone else will pay you for them. If they're willing to pay you more than you could make by continuing to sell IPv4 services, you take the deal. If not, someone else does. > Given that this whole thing plays out at a time when there is > a worldwide scarcity of IPv4 addresses, I can't see any reason > for anyone to give up the IPv4 addresses that they have until > they are absolutely sure that doing so does not risk serious > business losses. That will take years after IANA runs out of > IPv4 addresses. > Is there a scarcity of land on Manhattan? There certainly is a fixed pool of land there, which is fully utilized. However, that doesn't stop developers from buying land and putting it to more productive use. No one selling land on Manhattan is risking serious business losses, because they can lease or buy the land they need on the real estate market. If, however, the transfer of land on Manhattan (or IPv4 addresses) were prohibited, then what you said would be very true. > An then there is the technical issue of having a usable aggregate > of IPv4 addresses to transfer and not scattered small blocks. > An ISP has a number of ways of using scattered small blocks, > including carrying many long prefixes in their iBGP, but in > the global Internet, only large blocks/short prefixes are usable. > Yes, which is why transferors will likely have an asking price high enough to fund the renumbering out of a block large enough to transfer. > >> I suspect that after ARIN free pool exhaustion, all ISPs will >> offer some form of IPv6 service. To do so successfully, and >> support dual-stack, however, there will be a continued need >> for IPv4 addresses. >> > > That's why I don't believe many ISPs will go to dual stack on > any kind of scale. It is simpler to use MPLS with 6PE at the > edge, or build an IPv6 mesh over GRE or PWE3 on an IPv4 core. > This isolates the impact of IPv6 to the edge, and only to those > edge routers which are needed for IPv6 services. > You're missing my point. It doesn't matter what the ISP does with their infrastructure: that's not the bulk of their addresses. What matters is how they provide services to their customers, each of which needs IPv4 and IPv6 addresses for decent interconnectivity. I predict that many ISPs will offer their customers dual stack service at the edge, and that the IPv4 portion of that service will become a NAT'd private address in a lot of cases. > > As I have said in the past, you can't have a market without > liquidity and a resource that is not only scarce, but has a > cap on supply, simply cannot provide that liquidity. I have > no doubt that there will be a few sales of IP address blocks, > regardless of whether or not any RIR implements policies to > allow it, but the prices will not follow a pattern, and > will not be predictable. In general asking prices will be > astronomically high, and some sales will actually take > place at very high prices. But other sales will go through at > a fraction of the asking price because the only reason the > address block is on the market is because the seller genuinely > has no use for them any more. > It's possible that an IPv4 transfer market will be somewhat illiquid. That will certainly be true if it's a black market. However, I think this proposed transfer policy moves us in the direction of improving the liquidity of the market, by legitimizing transfers and allowing a central listing service (order book) so that potential transferors and transferees can see prices and behave accordingly. One such behavior, IMO, will be address holders freeing up additional addresses to transfer as a rising price makes it worth their while. Therefore, I think the market created by this transfer policy would be sufficiently liquid to ensure a continued supply of IPv4 address resources at reasonable cost. >> Yes, it is clear and simple, but it is not sufficient. If a >> network has no incentive to go to the trouble of renumbering >> out of IPv4 addresses, they won't return them, and there >> won't be enough IPv4 addresses to meet the needs of those who >> need more addresses. >> > > Since when is it our job to provide incentives to install NAT > or IPv6? People have been warned by the RIRs and ICANN that IPv4 > is running out. There will be more warnings. Those who don't heed > the warnings will get what they deserve. IPv6 and IPv4 are amazingly > flexible technologies and with the two to three years of advance > warning there is no need for anyone to suffer. If an organization > knows that they are absolutely dependent on IPv4 for some part > of their network where inflexible devices are attached, they should > begin now to make the rest of their network usable without IPv4. > Our job is to provide responsible stewardship of Internet number resources. In my opinion, denying organizations access to IPv4 resources so they will "get what they deserve" is the antithesis of stewardship. And don't forget that not all organizations who will need IPv4 resources in 2010 will have existing IPv4 assignments or allocations. Any new business that wants to provide services to the general Internet will need to get IPv4 addresses: how do you propose we meet their needs? > In the worst case, where an org needs a steady supply of globally > unique IPv4 addresses, they can borrow a block like 126/8 by > ensuring that they filter out any route announcements from Softbank > Japan. Or similar with another /8. > > It is not against the law to use IP addresses allocated to another > organization if you have no need to communicate with that other > organization. If you talk to systems integrators you will learn that > this is common practice, not just in the enterprise, but you even run > across it inside telecom companies. > Ouch. Do you really think such hacks are better than a policy allowing the transfer of IPv4 resources? It seems to me we should be encouraging responsible behavior conducive to ensuring continued global uniqueness of uniquely assigned IPv4 addresses. > Running out of IPv4 addresses is not like hitting a brick wall. > It's more like colliding with a giant marshmallow and wondering how > to get out of the sticky mess. > And in this analogy this transfer policy is like a garden hose: an essential tool to allow everyone (not just those carrying water) to clean up the sticky mess. -Scott From BillD at cait.wustl.edu Wed Feb 13 14:04:06 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Wed, 13 Feb 2008 13:04:06 -0600 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 TransferPolicy Proposal In-Reply-To: <20080213184550.GB64078@eagle.aitken.com> References: <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> <20080213184550.GB64078@eagle.aitken.com> Message-ID: Thanks Jeff, knew one had to exist. bd > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Jeff Aitken > Sent: Wednesday, February 13, 2008 12:46 PM > To: ppml at arin.net > Subject: Re: [ppml] IPv6 getting real: was Policy Proposal: > IPv4 TransferPolicy Proposal > > On Wed, Feb 13, 2008 at 12:08:35PM -0600, Bill Darte wrote: > > I believe it is important to identify all the stumbling blocks > > (perhaps as a checklist) that may exist so potential > adopters can get > > a heads up and importantly begin to apply leverage to their vendors > > for support...in order to reduce the number of hurdles. > > > > Or perhaps a comprehensive checklist already exists that > I'm unaware > > of... > > Hi Bill, > > >From Randy's presentation in Albuquerque: > > http://www.civil-tongue.net/clusterf/ > > Is that what you were looking for? > > > --Jeff > > _______________________________________________ > 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 andrew.dul at quark.net Wed Feb 13 14:44:10 2008 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Wed, 13 Feb 2008 11:44:10 -0800 Subject: [ppml] public policy proposal in network world Message-ID: <20080213194410.7142.qmail@hoster908.com> http://www.networkworld.com/news/2008/021308-ipv6-delay.html From michael.dillon at bt.com Wed Feb 13 14:47:10 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 13 Feb 2008 19:47:10 -0000 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B33D51.5020503@internap.com> References: <47B12650.2060107@internap.com> <47B30DC8.5020907@internap.com> <47B33D51.5020503@internap.com> Message-ID: > Is there a scarcity of land on Manhattan? There certainly is > a fixed pool of land there, which is fully utilized. > However, that doesn't stop developers from buying land and > putting it to more productive use. No one selling land on > Manhattan is risking serious business losses, because they > can lease or buy the land they need on the real estate market. But there are many companies in Manhattan who are *NOT* selling land because they can't afford to take the risk to their business of not being in Manhattan. Sometimes events change the level of risk such as 9-11 making it clear to the financial services industry that there was a lower risk if they moved SOME of their operations away from Manhattan. But NYSE is still there and many companies stay in Manhattan to arbitrage the advantage of a few microseconds less network latency to NYSE. To date, nobody has show that there is any clear business advantage for an ISP to stop selling IPv4 services if they have the resources to do so. The IPv4 runout means that ISPs MUST begin offering IPv6 services, but if they can provide such a good transparent 4-to-6 and 6-to-4 Internet gateway service, that IPv4 customers begin to move to pure v6 service, there is still no clear reason for the ISP to NOT use those IPv4 addresses to sell service to customers who still demand v4. > However, > I think this proposed transfer policy moves us in the > direction of improving the liquidity of the market, Moving from an extremely illiquid market to a very illiquid market really doesn't change things. In either case you will find it hard to sell IP addresses, hard to figure out what price to ask, and hard to know if an offered price is reasonable. > One such behavior, > IMO, will be address holders freeing up additional addresses > to transfer as a rising price makes it worth their while. How many hundred thousand dollars per /24 does the price have to reach before it is worthwhile? > Our job is to provide responsible stewardship of Internet > number resources. In my opinion, denying organizations > access to IPv4 resources so they will "get what they deserve" > is the antithesis of stewardship. You're right. We should be denying them access to IPv4 address blocks because we have run out of them. It's not our fault that they are running out and we have essentially zero influence on the decision makers that might return unused addresses to the pool, regardless of whether they can earn 6 figures by doing so. > Any new business that wants to provide services > to the general Internet will need to get IPv4 addresses: how > do you propose we meet their needs? Now you are off in cloud cuckoo land. We need to start with a basic understanding of the technology here. An IPv4 connected host can communicate with an IPv6 connected host in the usual way, through one or more intermediaries. In the IPv4 Internet we call these intermediaries routers, load-balancers, NAT-boxes. Adding IPv6 to the mix also adds NAT-PT boxes, Teredo tunnel servers, 6to4 tunnel servers, tunnel brokers, ISATAP and ALGs (Application Layer Gateways). These are all things that network operators provide for their customers whether in the enterprise or in the telecom space. So it will be possible for IPv6-connected servers to provide a service to the general Internet, as well as vice versa. If an ISP can't make the Internet a basically seamless service, regardless of IPv6 or IPv4, then they simply won't survive against their more nimble competition. One thing that ARIN staff could do to help this process would be to run a v6/v4 agnostic and fully transparent meeting network. By this I mean that you should be able to bring a pure IPv4 laptop or a pure IPv6 laptop to the meetings, and get equivalent service including access to any v6 or v4 Internet sites. By fully transparent I mean that all the technical details of how this service is supplied should be on display for people to copy and adapt to their own networks. Yes, it would mean some development work on NAT-PT and ALGs to finish the job so that they actually work in the wild, but this is not an insurmountable task and it fits in with ARIN's education mandate. > > It is not against the law to use IP addresses allocated to another > > organization if you have no need to communicate with that other > > organization. If you talk to systems integrators you will > learn that > > this is common practice, not just in the enterprise, but > you even run > > across it inside telecom companies. > > Ouch. Do you really think such hacks are better than a > policy allowing the transfer of IPv4 resources? Irrelevant. People have been doing this stuff for years and will undoubtedly continue to do so regardless of what policies ARIN may enact. --Michael Dillon From martin.hannigan at batelnet.bs Wed Feb 13 15:17:58 2008 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Wed, 13 Feb 2008 15:17:58 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal Message-ID: <47b35076.179.10ad.4724@batelnet.bs> > > Moving from an extremely illiquid market to a very > illiquid market really doesn't change things. In either > case you will find it hard to sell IP addresses, hard to > figure out what price to ask, and hard to know if an > offered price is reasonable. This is wrong. Right now, a unit of IP addresses is worth about $200,000 not including associated expenses. -M< From sleibrand at internap.com Wed Feb 13 16:11:30 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 13 Feb 2008 16:11:30 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: <47B12650.2060107@internap.com> <47B30DC8.5020907@internap.com> <47B33D51.5020503@internap.com> Message-ID: <47B35D02.4030206@internap.com> michael.dillon at bt.com wrote: >> Is there a scarcity of land on Manhattan? There certainly is >> a fixed pool of land there, which is fully utilized. >> However, that doesn't stop developers from buying land and >> putting it to more productive use. No one selling land on >> Manhattan is risking serious business losses, because they >> can lease or buy the land they need on the real estate market. >> > > But there are many companies in Manhattan who are *NOT* selling > land because they can't afford to take the risk to their business > of not being in Manhattan. Sometimes events change the level of risk > such as 9-11 making it clear to the financial services industry > that there was a lower risk if they moved SOME of their operations > away from Manhattan. But NYSE is still there and many companies > stay in Manhattan to arbitrage the advantage of a few microseconds > less network latency to NYSE. > Does that stop a new financial services firm from opening a Manhattan office, or a new employee of that firm from buying a Manhattan condo? An effective market does not require many/most asset holders be willing to sell, just enough to meet the demand at the market price. > Moving from an extremely illiquid market to a very > illiquid market really doesn't change things. In either case > you will find it hard to sell IP addresses, hard to figure > out what price to ask, and hard to know if an offered price > is reasonable. > I acknowledge that there is a risk of an IPv4 transfer market being insufficiently liquid to make a significant difference. However, in that scenario, we're right back to the way things would be without this policy. Do you foresee any risks of this policy making things worse, or do you just not think it will make things much better? >> One such behavior, >> IMO, will be address holders freeing up additional addresses >> to transfer as a rising price makes it worth their while. >> > > How many hundred thousand dollars per /24 does the price have > to reach before it is worthwhile? > I think that can be calculated based on the cost of setting up NAT in your network, changing your DHCP pools to use private addresses, and the support costs of giving static public IPs to whatever percentage of your customers have problems due to NAT and want to opt out. If this was done in the context of enabling IPv6, I would give a hand-wavy estimate that it would cost somewhere in the single-digit thousands of dollars to renumber a /24's worth of customers. That would indicate that at a price of $20,000 per /24, significant supply would be available. (In the initial period, I would expect the price to be much lower, as unused legacy space comes out of the woodwork.) If we compare that with Marty's estimate of $200,000 on the current (black) market, that means that a liberalized transfer policy would be at least 10x better than the black market from the perspective of someone needing new IPv4 addresses. >> Our job is to provide responsible stewardship of Internet >> number resources. In my opinion, denying organizations >> access to IPv4 resources so they will "get what they deserve" >> is the antithesis of stewardship. >> > > You're right. We should be denying them access to IPv4 > address blocks because we have run out of them. It's not > our fault that they are running out and we have essentially > zero influence on the decision makers that might return > unused addresses to the pool, regardless of whether they > can earn 6 figures by doing so. > If we enable decision makers to earn 6 figures for transferring address space, I believe there will be significant numbers of addresses available at that price. In fact, I don't foresee the price getting anywhere near that high, as demand will significantly fall at lower prices, until supply and demand come into balance. > We need to start with > a basic understanding of the technology here. An IPv4 connected > host can communicate with an IPv6 connected host in the usual > way, through one or more intermediaries. In the IPv4 Internet > we call these intermediaries routers, load-balancers, NAT-boxes. > Adding IPv6 to the mix also adds NAT-PT boxes, Teredo tunnel servers, > 6to4 tunnel servers, tunnel brokers, ISATAP and ALGs (Application > Layer Gateways). These are all things that network operators > provide for their customers whether in the enterprise or in the > telecom space. So it will be possible for IPv6-connected servers > to provide a service to the general Internet, as well as vice versa. > Where can I buy these NAT-PT and Teredo boxes and ALGs? How much do they cost, particularly at scale? And where can I get all of the middleboxes (firewalls, network management systems, VPN concentrators, load balancers, etc.) to support native IPv6? It's pretty clear to me that we are *not* ready to do IPv6-only networking without dual-stack. > If an ISP can't make the Internet a basically seamless service, > regardless of IPv6 or IPv4, then they simply won't survive against > their more nimble competition. > You are arguing that some networks will run IPv6, some will run IPv4, and there will be devices that happily translate between the two. I am arguing that no one will go IPv6-only right away, everyone who does IPv6 will want do dual-stack, and that they'll need IPv4 addresses to do so. Both approaches would satisfy the requirement of providing seamless service to the entire Internet, but I don't believe that ISPs will be able to make such a seamless service work cost-effectively at scale for IPv6-only clients before IPv4 exhaustion. > One thing that ARIN staff could do to help this process would be > to run a v6/v4 agnostic and fully transparent meeting network. By > this I mean that you should be able to bring a pure IPv4 laptop or > a pure IPv6 laptop to the meetings, and get equivalent service > including access to any v6 or v4 Internet sites. By fully transparent > I mean that all the technical details of how this service is > supplied should be on display for people to copy and adapt to > their own networks. Yes, it would mean some development work > on NAT-PT and ALGs to finish the job so that they actually work > in the wild, but this is not an insurmountable task and it fits > in with ARIN's education mandate. > Sounds like an admirable goal, as is a similar exercise to turn off IPv4 at the upcoming IETF plenaries and try to get people to communicate with the IPv4 Internet from an IPv6-only network. However, until someone succeeds at demonstrating how this can be done cost-effectively at ISP scale, I think we need to be able to implement the dual-stack transition plan as originally specified, and I think that a transfer policy is a necessary prerequisite to that. -Scott From tedm at ipinc.net Wed Feb 13 16:38:09 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 13 Feb 2008 13:38:09 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: Message-ID: >-----Original Message----- >From: David Conrad [mailto:drc at virtualized.org] >Sent: Monday, February 11, 2008 6:33 PM >To: Ted Mittelstaedt >Cc: Public Policy Mailing List >Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal > > >> Nothing in the CURRENT method of return-issue blocks improvements >> of the overall utilization of IPv4. > >Except there is currently no incentive to return blocks and there will >be less over time. > I don't understand this reasoning. If there's less than "no" incentive that means there's a disincentive - AKA an incentive to keeping unused blocks. What incentive to keeping an unused block that you will never use in the future exists other than selling it? And unless a buying-and selling market is developed through policies like these, how will an unused block your never going to use, ever have value? For unused blocks belonging to orgs that wil eventually use them, that is perfectly fine if they hang on to them. The assertion that there's "currently no incentive" to return or not return unused blocks is only true for legacy IPv4. For IPv4 under RSA, the incentive to return is to not have to pay fees for it. And while I (and some others) have advocated ARIN take a more agressive role over flushing out legacy IPv4 that isn't being used, the community has not appeared to support this. >> Transfers can also make it easier for problems with badly-utilized >> space to be perpetuated, rather than addressed. > >How is that worse than the situation as it exists now? > Putting in a "special" transfer system is in effect implying to the requestor that if they do buy this other network, they will get a free ride on meeting their current utilization on their current block. The existence of a "special" transfer system separate from the standard request-reallocate system that everyone follows, creates a "special" class that is just begging for a lawsuit. How can ARIN effectively argue in a court that they are denying a transfer for Sally Sue since she is under utilized, when they have a transfer system setup that is separate from the main system? Sally would argue that the entire reason a separate transfer system was created was to be able to allow transferees to sidestep the utilization requirements everyone else has to follow - otherwise, there would be no need for a special transfer system in the first place. Ted From sleibrand at internap.com Wed Feb 13 16:49:25 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 13 Feb 2008 16:49:25 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: Message-ID: <47B365E5.8090900@internap.com> Ted Mittelstaedt wrote: > >> How is that worse than the situation as it exists now? >> >> > > Putting in a "special" transfer system is in effect implying to the > requestor that if they do buy this other network, they will get a free > ride on meeting their current utilization on their current block. The > existence of a "special" transfer system separate from the standard > request-reallocate system that everyone follows, creates a "special" > class that is just begging for a lawsuit. How can ARIN effectively > argue in a court that they are denying a transfer for Sally Sue since > she is under utilized, when they have a transfer system setup that > is separate from the main system? Sally would argue that the entire > reason a separate transfer system was created was to be able to > allow transferees to sidestep the utilization requirements everyone > else has to follow - otherwise, there would be no need for a special > transfer system in the first place. I'm not sure I understand which "special transfer system" you're talking about. Under the IPv4 transfer policy proposal, any organization wishing to acquire address space through a simple IPv4 transfer has to justify that they need the addresses, just as they have to do today. They must demonstrate efficient use of current space, and demonstrate near-term need for the IPv4 addresses being requested. They will essentially follow the same process to get space as they do today, up to the point where ARIN tells them, "we don't have the addresses you need right now, so here's a qualification that allows you to go get those addresses via the transfer market". In addition, this policy proposal preserves the existing M&A transfer policy, whereby an organization making an acquisition can also acquire the IP addresses currently in use by the acquired organization. Under this policy, the organizations must still demonstrate that the addresses to be transferred are being efficiently utilized. Does that address your concern that the transfer system will be perceived as unfair? Or do you still see some actual unfairness in the policy that we should address? Thanks, Scott From owen at delong.com Wed Feb 13 16:57:03 2008 From: owen at delong.com (Owen DeLong) Date: Wed, 13 Feb 2008 13:57:03 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: Message-ID: <6377979F-689B-47F1-B91A-FD4D7A245886@delong.com> > The assertion that there's "currently no incentive" to return or not > return unused blocks is only true for legacy IPv4. For IPv4 under > RSA, > the incentive to return is to not have to pay fees for it. And while > I (and some others) have advocated ARIN take a more agressive role > over > flushing out legacy IPv4 that isn't being used, the community has not > appeared to support this. > Given that end users pay $100 per year, regardless of the number of addresses held, I'm not sure how paying for it becomes an incentive to return unused space. The lack of an incentive is not, in itself a disincentive. Between forward and reverse there is a point known as stopped. >>> Transfers can also make it easier for problems with badly-utilized >>> space to be perpetuated, rather than addressed. >> >> How is that worse than the situation as it exists now? >> > > Putting in a "special" transfer system is in effect implying to the > requestor that if they do buy this other network, they will get a free > ride on meeting their current utilization on their current block. The > existence of a "special" transfer system separate from the standard > request-reallocate system that everyone follows, creates a "special" > class that is just begging for a lawsuit. How can ARIN effectively Given that the policy under discussion specifically precludes such transfers until IANA is no longer able to respond to requests, thus eliminating the standard request-reallocate in short order, I am not sure I agree with your reasoning. Additionally, the policy specifically requires that a transferee meet all of the same requirements that are necessary in order to qualify under the request-reallocate system prior to receiving a transfered block, so, this policy doesn't really create a "special" class in that regard. > > argue in a court that they are denying a transfer for Sally Sue since > she is under utilized, when they have a transfer system setup that > is separate from the main system? Sally would argue that the entire > reason a separate transfer system was created was to be able to > allow transferees to sidestep the utilization requirements everyone > else has to follow - otherwise, there would be no need for a special > transfer system in the first place. > You really should read the policy. It was carefully crafted with the desire to avoid such side-stepping and only really be effective when the traditional process is no longer possible, but, still preserve the same requirements. If you feel that the policy does not accomplish this, it would be useful for you to propose alternative language that you believe would do so. Owen From tedm at ipinc.net Wed Feb 13 17:04:44 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 13 Feb 2008 14:04:44 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B12650.2060107@internap.com> Message-ID: >-----Original Message----- >From: Scott Leibrand [mailto:sleibrand at internap.com] >Sent: Monday, February 11, 2008 8:54 PM >To: Ted Mittelstaedt >Cc: ppml at arin.net >Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal > > >> Is there any reason that extending the lifetime of IPv4 will be of any >> benefit to the Internet community? > >Yes. There is a large installed base for whom migrating to IPv6 may be >painful (expensive). Reducing the community's total expense for >operating their IP networks is a benefit to the Internet community. > The longer you put off migration to IPv6 the more IPv4 hosts you will have, and the more work you will have to do to migrate all of them. Now that all modern OS's and router OS's are IPv6 compliant, there is less and less reason every day to delay it. The best thing for the entire Internet is for all hosts to migrate to IPv6 at the same time. This will have the least amount of stress on the routers, (smallest route table) and it will not give any one org a competitive advantage over another, that is based soley on what IP addressing they happen to have in inventory. It will also allow the networks to offload the largest amount of the cost of transition on to the end-users, who after all are the main beneficiaries of the Internet's existence. Phasing in IPv6 as so many people seem to think is a good idea is by contrast a horrible idea, as what will happen is the end users will simply have no incentive to upgrade their stuff to be IPv6 compliant - if their ISP asks them to do it, they will move to a competitor - thus the early IPv6 adopters will get penalized, they will end up spending the money to upgrade, and losing customers. The very best thing is for all end users to be given a consistent message by ALL ISP's that they must update. Consider for a second the "phase in" process for HD-TV broadcasts in North America. The number of end user consumers who have adopted HD-TV during the "phase in" period prior to Feb 2009 is a drop in the bucket. If the drop-dead deadline for broadcasting had never been set to Feb 2009, but instead set to "when the last guy turns off his NTSC TV set" then HD-TV would be stillborn. Telephone systems also do not "phase in" dialing plan changes. When they go to 10-digit dialing for an exchange, it affects EVERYONE. They do not tell people "oh, you have an older phone which only saves the 7 digits from it's caller ID into your redial button, we will wait until your phone dies before making you start dialing 10 digits" >That is exactly what this policy proposal attempts to accomplish: it >requires that any potential transferee justify their need for IP space, >exactly as they have to do today. They can then get IPv4 space from >ARIN, if ARIN has any to give, or they can go out and find a transferor >willing to part with some space. > Alowing them to go directly to a transferor is the fundamental problem. Sure, it may allow an org to get some IPv4 when ARIN has none. But the side effects are to introduce the idea of IP ownership. If the transferor has IPv4 to give they likely are already in violation of their RSA, in any case. It's far better to hold orgs to the RSA contracts and promises they made, and if they have extra IPv4, they should return it to ARIN for reallocation. We will have to deal with the case law and precident that allowing this creates, long after the last Ipv4 address is decomissioned. For that reason alone it is foolish to hamstring ARIN's future IP addressing authority for the sake of a short-term fix now. This is the legacy IPv4 assignment fiasco all over again. > >One important point I'll reiterate: we're not talking about just >"abandoned" or "unused" IP space here. We're talking about providing >organizations a financial incentive to reduce their usage of IPv4 space >(such as by adopting IPv6), thereby freeing up space for other >organizations who still need it. To enable that, we need a new policy, >such as the one we've proposed. > Paying less money for IP addressing, by paying the lower fees for IPv6, is plenty of incentive for organizations to reduce their usage of IPv4. We don't need to give them further money by letting them sell off their IPv4 to the highest bidder. Ted From randy at psg.com Wed Feb 13 18:22:03 2008 From: randy at psg.com (Randy Bush) Date: Thu, 14 Feb 2008 08:22:03 +0900 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: <47B12650.2060107@internap.com><47B30DC8.5020907@internap.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> Message-ID: <47B37B9B.9060508@psg.com> those coming to nanog (and we hope apricot, ietf, ...) will have the opportunity to join us in eating our own dogfood. there will be extensive ipv6 deployment and even an hour when normal ipv4 is turned off. the hacks and tricks to make this work will be part of the program content. so it will be educate and measure time. randy From bmanning at vacation.karoshi.com Wed Feb 13 18:33:57 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 13 Feb 2008 23:33:57 +0000 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B37B9B.9060508@psg.com> References: <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> <47B37B9B.9060508@psg.com> Message-ID: <20080213233357.GB2209@vacation.karoshi.com.> along those lines, two applications I use tend to lack good IPv6 support, SKYPE/GIZMO and ADIUM. please apply the cluebyfour. --bill On Thu, Feb 14, 2008 at 08:22:03AM +0900, Randy Bush wrote: > those coming to nanog (and we hope apricot, ietf, ...) will have the > opportunity to join us in eating our own dogfood. there will be > extensive ipv6 deployment and even an hour when normal ipv4 is turned > off. the hacks and tricks to make this work will be part of the program > content. so it will be educate and measure time. > > 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 Feb 13 18:38:47 2008 From: randy at psg.com (Randy Bush) Date: Thu, 14 Feb 2008 08:38:47 +0900 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <20080213233357.GB2209@vacation.karoshi.com.> References: <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> <47B37B9B.9060508@psg.com> <20080213233357.GB2209@vacation.karoshi.com.> Message-ID: <47B37F87.7040807@psg.com> bmanning at vacation.karoshi.com wrote: > along those lines, two applications I use tend to lack > good IPv6 support, SKYPE/GIZMO and ADIUM. please > apply the cluebyfour. also from my last nanog slides ... Where is the web page with a matrix of application by platform showing which are v6 capable and clickable link on how to turn it on? http://www.deepspace6.net/docs/ipv6_status_page_apps.html out of date Many applications which support v6 have sufficiently poor performance that early adopters are being told to turn v6 off XP does not work in a v6-only environment, because it does not support DNS queries over IPv6 transport randy From bmanning at vacation.karoshi.com Wed Feb 13 18:58:24 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 13 Feb 2008 23:58:24 +0000 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B37F87.7040807@psg.com> References: <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> <47B37B9B.9060508@psg.com> <20080213233357.GB2209@vacation.karoshi.com.> <47B37F87.7040807@psg.com> Message-ID: <20080213235824.GA2674@vacation.karoshi.com.> On Thu, Feb 14, 2008 at 08:38:47AM +0900, Randy Bush wrote: > bmanning at vacation.karoshi.com wrote: > > along those lines, two applications I use tend to lack > > good IPv6 support, SKYPE/GIZMO and ADIUM. please > > apply the cluebyfour. > > Many applications which support v6 have sufficiently poor performance > that early adopters are being told to turn v6 off > > XP does not work in a v6-only environment, because it does not support > DNS queries over IPv6 transport > > randy then your nanog, ietf and potentially apricot experiments will be lively. better block an hour on either side of your one hour "v4 is comatose" for folks to configure their hardware, some may need it and it would be rude to the speaker -after- the event to have 95% of the audience ignoring her. --bill From jweyand at computerdata.com Wed Feb 13 19:12:15 2008 From: jweyand at computerdata.com (Jim Weyand) Date: Wed, 13 Feb 2008 19:12:15 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal Message-ID: <1582DCBFF968F044A9A910C0AB177C902CE569@cliff.cdi.local> Scott- I copied section 8.4.2 and added your new language as the final bullet point. I assume this is how you want it to read. 8.4.2 Conditions on the transferee: * 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 only receive one IPv4 address transfer every 6 months. * The transferee may request and receive a contiguous CIDR block large enough to provide a 12 month supply of IPv4 addresses. As I reflect on your proposal I have some thoughts. 1) Must a transferee receive all allowed addresses in a single transaction from a single transferor? Because your new language says, "receive a contiguous CIDR block" I assume that is your intent. I understand that there are router table issues here and I am a businessman not a technologist but it seems if I am pre-qualified to receive a /16 and I find two /17s that are already advertised they can be moved to my address space with no net effect on the router table. I can see the potential problem where several entities have been pre-qualified as transferors of a /16 and begin transferring /20s (possibly because the market has valued them higher) and my transferee above puts together his /16 worth of address space by purchasing (I think I did the math right) 8 /20s from different holders resulting in significant additional entries in the routing table. One solution to this is to allow the transfers but charge a transfer fee for each transaction that increases the size of the router table. My rationale for the additional fee is that all members of the community bear some additional cost and individual entities that cause the additional cost should bear some burden. 2) I know there is a great concern in the community with speculators that might buy and sell address space for a profit. However the unintended consequence of putting too many barriers to trade is that a "gray market" will develop that will be outside of the control of the RIR. I understand from posts I have read here today that such a thing is already happening. Maybe this is not a problem and I am worrying about something that has no effect. Thanks again for your work. You have shown great patience explaining your proposal to all involved. -Jim -----Original Message----- From: Scott Leibrand [mailto:sleibrand at internap.com] Sent: Wednesday, February 13, 2008 11:13 AM To: Jim Weyand Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal Jim, Reading over 4.2 and 4.3 of the NRPM, I see lots of different conditions for different types of networks. Specifically, the text in 4.2.2.1.3 and 4.2.2.2.2 requiring that the requested IP address space will be utilized within three months refers to organizations justifying an initial allocation on the basis of their use of PA space, and is intended to minimize delay in renumbering out of PA space (if applicable) and beginning to use and route the new space. As I read those sections, they don't require 100% utilization within three months. However, in 4.2.4.3 and 4.2.4.4, it does appear that a new ISP that needs additional space before they've been an ARIN member for a year can only justify a three-month supply of addresses. After that, they can get six months' worth. In the case of end users, they can get over a year's worth of space according to 4.3.3. Given all this confusion, I'd like to decouple the 8.4 transfer policy's transfer sizes somewhat from the allocation and assignment sizes in 4.2 and 4.3, by adding the following bullet point to 8.4.2: * The transferee may request and receive a contiguous CIDR block large enough to provide a 12 month supply of IPv4 addresses. That will preserve the requirement that need and efficient use are justified, but would bypass the sections of 4.2 and 4.3 concerned with preventing hoarding (intentional or otherwise). My assumption here is that the cost of transferring addresses and a 12-month supply rule would act as a sufficient brake to prevent anyone from getting more addresses than they need for that timeframe. The 12-month supply should also be sufficient, in concert with the one-block-every-6-months condition, to ensure that transferees get enough address space to limit unnecessary deaggregation. Thoughts? -Scott > > > 4.2.2.1.3. Three months > > Provide detailed information showing specifically how a /20 will be > utilized within three months. > > > 4.2.2.2.2. Three months > > Provide information showing that the requested IP address space will > be utilized within three months and demonstrating an intent to > announce the requested space in a multihomed fashion. > > > 4.2.2.2.4. Additional requests following the initial > allocation > > To receive additional address space following the initial allocation, > multihomed organizations must have returned the original IP address > space to its provider in its entirety and must provide justification > for a new allocation as described above in the section titled > Requirements for Requesting Initial Address Space. > > > 4.2.4.3. Three months > > Provide detailed information showing specifically that the address > space will be utilized within three months. Determination of the > appropriate allocation to be issued is based on efficient utilization > of space within this three-month time frame. > > > 4.2.4.4. Six months > > After a subscriber has been a member of ARIN for one year they may > choose to request a six-month supply of IP addresses. > > > 4.3.3. Utilization rate > > Utilization rate of address space is a key factor in justifying a new > assignment of IP address space. Requesters must show exactly how > previous address assignments have been utilized and must provide > appropriate details to verify their one-year growth projection. The > basic criteria that must be met are: > > * A 25% immediate utilization rate, and > * A 50% utilization rate within one year. > Scott Leibrand wrote: > No, I think that reflects my failure to actually re-read 4.2.2 when > writing 8.4.3. :-) I'll look into that and see what revisions are > needed are needed to make them consistent. Good catch. > > Thanks, > Scott > > Jim Weyand wrote: > >> Well done! However I see one small issue that probably reflects my lack >> of understanding: >> >> Section 8.4.3 of the proposal below references NRPM 4.2.2. regarding >> minimum allocation size and section 8.4.1 says, "The transferee may only >> receive one IPv4 address transfer every 6 months." >> >> However NRPM 4.2.2.2.2. says, " Provide information showing that the >> requested IP address space will be utilized within three months and >> demonstrating..." >> >> Which of course would mean that, to be consistent with the NRPM, a >> transferee could only buy a three month supply of addresses every six >> months. >> >> >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of >> Member Services >> Sent: Monday, February 11, 2008 11:35 AM >> To: ppml at arin.net >> Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal >> >> Resending with a typo that has been corrected in 8.4.2 below. The >> original text is supposed to have "24 months" twice in that section. >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> >> >> ARIN received the following policy proposal. In accordance with the ARIN >> Internet Resource Policy Evaluation Process, the proposal is being >> posted to the ARIN Public Policy Mailing List (PPML) and being placed on >> ARIN's website. >> >> The ARIN Advisory Council (AC) will review this proposal at their next >> regularly scheduled meeting. The AC may decide to: >> >> 1. Accept the proposal as written. If the AC accepts the proposal, it >> will be posted as a formal policy proposal to PPML and it will be >> presented at a Public Policy Meeting. >> >> 2. Not accept the proposal. If the AC does not accept the proposal, >> the AC will explain their decision via the PPML. If a proposal is not >> accepted, then the author may elect to use the petition process to >> advance their proposal. If the author elects not to petition or the >> petition fails, then the proposal will be closed. >> >> The AC shepherds for this proposal are Scott Leibrand and Stacy Taylor. >> >> The AC invites everyone to comment on this proposal on the PPML, >> particularly their support or non-support and the reasoning behind their >> opinion. Such participation contributes to a thorough vetting and >> provides important guidance to the AC in their deliberations. >> >> The ARIN Internet Resource Policy Evaluation Process can be found at: >> http://www.arin.net/policy/irpep.html >> >> Mailing list subscription information can be found at: >> http://www.arin.net/mailing_lists/ >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Policy Proposal Name: IPv4 Transfer Policy Proposal >> >> Author: ARIN Advisory Council >> >> Proposal Version: 1.0 >> >> Submission Date: 02/07/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 "M&A Transfer >> Requirements": >> >> 8.2. M&A Transfer Requirements >> >> 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.] >> >> >> [8.3 - retitle to "M&A Transfer Documentation Requirements": >> >> 8.3. M&A Transfer Documentation Requirements >> >> 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.4. Requirements for Simple Transfer of IPv4 Addresses >> >> After the exhaustion of the IANA IPv4 free pool, ARIN will also process >> IPv4 address transfer requests subject to the following conditions. >> >> 8.4.1 Conditions on the transferor: >> >> * 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.4.2 Conditions on the transferee: >> >> * 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 only receive one IPv4 address transfer every 6 >> months. >> >> >> >> 8.4.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. >> >> 8.4.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.4.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 exact network address and size >> (CIDR prefix length) the transferor is eligible to provide, and >> the expiration date of the pre-qualification. >> >> 8.5. Safe Harbor for IPv4 Transfers through this Simple Transfer >> Process >> >> IPv4 address resources being made available for transfer shall be exempt >> from ARIN audit until expiration of the transfer pre-qualification or >> completion of the transfer. In the event that a transfer >> pre-qualification expires, ARIN shall have up to 90 days to initiate an >> audit prior to this exemption being reinstated through subsequent >> transfer pre-qualification. This will not extend the end of the >> exemption. >> >> 8.6. 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.7. 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. >> >> 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. >> _______________________________________________ >> 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 randy at psg.com Wed Feb 13 19:26:09 2008 From: randy at psg.com (Randy Bush) Date: Thu, 14 Feb 2008 09:26:09 +0900 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <20080213235824.GA2674@vacation.karoshi.com.> References: <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> <47B37B9B.9060508@psg.com> <20080213233357.GB2209@vacation.karoshi.com.> <47B37F87.7040807@psg.com> <20080213235824.GA2674@vacation.karoshi.com.> Message-ID: <47B38AA1.7070401@psg.com> > then your nanog, ietf and potentially apricot experiments > will be lively. better block an hour on either side of your > one hour "v4 is comatose" for folks to configure their hardware, the experimental nets will be up in parallel the whole time. From dino at cisco.com Wed Feb 13 19:31:13 2008 From: dino at cisco.com (Dino Farinacci) Date: Wed, 13 Feb 2008 16:31:13 -0800 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B38AA1.7070401@psg.com> References: <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> <47B37B9B.9060508@psg.com> <20080213233357.GB2209@vacation.karoshi.com.> <47B37F87.7040807@psg.com> <20080213235824.GA2674@vacation.karoshi.com.> <47B38AA1.7070401@psg.com> Message-ID: <847E224B-8160-4C7A-9DE8-4AAD5AC7B491@cisco.com> >> then your nanog, ietf and potentially apricot experiments >> will be lively. better block an hour on either side of your >> one hour "v4 is comatose" for folks to configure their hardware, > > the experimental nets will be up in parallel the whole time. I have LISP working for IPv6, let's fire it up. ;-) Dino From farmer at umn.edu Wed Feb 13 19:43:02 2008 From: farmer at umn.edu (David Farmer) Date: Wed, 13 Feb 2008 18:43:02 -0600 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <20080213233357.GB2209@vacation.karoshi.com.> References: , <47B37B9B.9060508@psg.com>, <20080213233357.GB2209@vacation.karoshi.com.> Message-ID: <47B33A36.7802.242267B2@farmer.umn.edu> Some good IPv6 presentations from the R&E world, well all but the last one, its horrable, the guy can give a presentation to save his life. :) Internet2 hasn't completed linking the video with the presentations for the latest meeting, therefore the links are included with the presentations below. http://events.internet2.edu/2008/jt-hawaii/sessionDetails.cfm?session=3598&event=278 http://winmedia.internet2.edu/jointtechs-w08/jtw08-14.wmv Same presentation from the previous meeting, to see how things have changed, or not. The video link is included on the page. http://events.internet2.edu/2007/jt-batavia/sessionDetails.cfm?session=3324&event=272 http://events.internet2.edu/2008/jt-hawaii/sessionDetails.cfm?session=3603&event=278 http://winmedia.internet2.edu/jointtechs-w08/jtw08-18.wmv http://events.internet2.edu/2008/jt-hawaii/sessionDetails.cfm?session=3607&event=278 no video http://events.internet2.edu/2008/jt-hawaii/sessionDetails.cfm?session=3638&event=278 http://winmedia.internet2.edu/jointtechs-w08/jtw08-38.wmv ================================================= 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 randy at psg.com Wed Feb 13 22:35:45 2008 From: randy at psg.com (Randy Bush) Date: Thu, 14 Feb 2008 12:35:45 +0900 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B31722.5080600@internap.com> References: <1582DCBFF968F044A9A910C0AB177C902CE55A@cliff.cdi.local> <47B1D21F.5030807@internap.com> <47B31722.5080600@internap.com> Message-ID: <47B3B711.4040004@psg.com> all in all, this proposal and much of the discussion feels to me as if it has an underlying subtext of "this is bad and the people doing it are bad people, but we know we can't stop them so we're going to impose all the obstacles and conditions we think we can get away with." aside from global engineering issues of routing impact minimization and operational issues of ensuring fair and valid transfers, why do we need to place silly restrictions such as "you can only get one bathroom pass in a given class period," "you can't share your lunch with a foreign friend," etc? the mpa and riaa are teaching our children that it's normal to be criminals. let's not do the same to our operational peers. address space transfer is going to be an ever-increasing part of normal life; get over it. our job is to make internet operations simple and easy. randy From sleibrand at internap.com Wed Feb 13 23:43:05 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 13 Feb 2008 23:43:05 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B3B711.4040004@psg.com> References: <1582DCBFF968F044A9A910C0AB177C902CE55A@cliff.cdi.local> <47B1D21F.5030807@internap.com> <47B31722.5080600@internap.com> <47B3B711.4040004@psg.com> Message-ID: <47B3C6D9.5050205@internap.com> Randy Bush wrote: > all in all, this proposal and much of the discussion feels to me as if > it has an underlying subtext of "this is bad and the people doing it are > bad people, but we know we can't stop them so we're going to impose all > the obstacles and conditions we think we can get away with." > I know others feel that way, that a transfer market is a bad thing, but we have to do it anyway. I personally don't share that view: I think that a transfer market is the best way to minimize the cost to the community of the IPv4 to IPv6 transition, and therefore it's a good thing. I believe that the conditions in the proposal can be justified based on sound principles, such as the ones you mention below and a few others. If there are conditions or other aspects that aren't justified, I'll be more than happy to discuss removing them. (In fact, I've been having some other discussions and will probably propose removing one of the transferor conditions shortly.) > aside from global engineering issues of routing impact minimization and > operational issues of ensuring fair and valid transfers, why do we need > to place silly restrictions such as "you can only get one bathroom pass > in a given class period," "you can't share your lunch with a foreign > friend," etc? > The "one bathroom pass per class period" restriction (one transfer every 6 months) is directly intended to minimize routing impact, by ensuring that a transferee gets all the space they need as a single block, not by vacuuming up lots of smaller blocks, thereby forcing other blocks to be split to meet the needs of smaller orgs. The "can't share your lunch" condition is meant to keep the impact of the policy within the scope of our policy-making authority, so we don't have to do a globally coordinated policy. As I've expressed earlier, I think we should create a simple way to allow transfers between regions once two or more RIRs have passed transfer policies. > address space transfer is going to be an ever-increasing part of normal > life; get over it. our job is to make internet operations simple and easy. > In your opinion, which conditions unnecessarily complicate life-after-free-pool without commensurate benefit? Thanks, Scott From randy at psg.com Wed Feb 13 23:50:41 2008 From: randy at psg.com (Randy Bush) Date: Thu, 14 Feb 2008 13:50:41 +0900 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B3C6D9.5050205@internap.com> References: <1582DCBFF968F044A9A910C0AB177C902CE55A@cliff.cdi.local> <47B1D21F.5030807@internap.com> <47B31722.5080600@internap.com> <47B3B711.4040004@psg.com> <47B3C6D9.5050205@internap.com> Message-ID: <47B3C8A1.8070503@psg.com> Scott Leibrand wrote: > I believe that the conditions in the proposal can be justified based > on sound principles, such as the ones you mention below and a few > others. If there are conditions or other aspects that aren't > justified, I'll be more than happy to discuss removing them. (In > fact, I've been having some other discussions and will probably > propose removing one of the transferor conditions shortly.) shall we have a little side party at nanog? doing this by email is not gonna be easy. randy From tvest at pch.net Wed Feb 13 23:52:53 2008 From: tvest at pch.net (Tom Vest) Date: Wed, 13 Feb 2008 23:52:53 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B3B711.4040004@psg.com> References: <1582DCBFF968F044A9A910C0AB177C902CE55A@cliff.cdi.local> <47B1D21F.5030807@internap.com> <47B31722.5080600@internap.com> <47B3B711.4040004@psg.com> Message-ID: <1026CF8E-A71A-4FCD-B3B9-5EA317490784@pch.net> On Feb 13, 2008, at 10:35 PM, Randy Bush wrote: > all in all, this proposal and much of the discussion feels to me as if > it has an underlying subtext of "this is bad and the people doing > it are > bad people, but we know we can't stop them so we're going to impose > all > the obstacles and conditions we think we can get away with." > > aside from global engineering issues of routing impact minimization > and > operational issues of ensuring fair and valid transfers, why do we > need > to place silly restrictions such as "you can only get one bathroom > pass > in a given class period," "you can't share your lunch with a foreign > friend," etc? > > the mpa and riaa are teaching our children that it's normal to be > criminals. let's not do the same to our operational peers. Hi Randy, It seems to me that the MPAA and RIAA are attempting to "enclose" old turf using the excuse of a new threat -- new digital reproduction/ transmission technology. They're trying to assert new exclusive rights over value that had been (at least for a few decades) more or less accessible, on a nonexclusive basis, to the general public. If they're actually teaching our children to disregard the law, is there any antecedent for that other than the fact that they employ lobbyists who are especially good at manipulating the rules and rulemakers? Perhaps this looks like more evidence for the orthodox libertarian argument: since rules are rulemakers are fallible, and susceptible to corruption or manipulation, they should all be abolished. However, if market power is real, fungible power (and it seems blatantly obvious to me), then I hardly think that eliminating the rules is going to help matters much. If the law didn't exist, then the RIAA/MPAA couldn't commandeer it to make our children into criminals -- but then nothing would prevent them from shacking up with their facilities-owning friends and making it physically impossible for our children to do, or eventually think, anything that they didn't explicitly permit. If "do what thou wilt" sounds good to individual libertarians, I can't even begin to imagine how attractive it must be for fabulously wealthy and powerful artificial persons. Sometimes rules are unjust or inefficient, and rulebreakers can claim the moral high ground. Sometimes not, and the rulebreakers are just crooks. It's not the fact of rules, or the identity of the rulemakers, but rather the intent, substance, direct and indirect costs and benefits (and who suffers or enjoys them), and likelihood of success that determines their just or unjustness. > address space transfer is going to be an ever-increasing part of > normal > life; You are almost certainly right on this point. > get over it. Okay. > our job is to make internet operations simple and easy. For whom? For would-be buyers or sellers on day one, would-be buyers and sellers on day two of thereafter, or for some even broader set of direct and indirect stakeholders? When the community recognized that address resources were "scarce", they opted to create systems that sought to balance the needs and pressures of the present against the expectation of similar needs and demands in the future. It's not at all clear to me that the exhaustion of the unallocated free pool invalidates that overall mandate, even if it eventually has to be pursued by different institutions using different tools. I wish we could reorient these arguments toward answering real questions, rather than simply declaring that the future is already (narrowly) determined and doubters should just get out of the way. TV > 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 Thu Feb 14 00:06:10 2008 From: randy at psg.com (Randy Bush) Date: Thu, 14 Feb 2008 14:06:10 +0900 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B3C6D9.5050205@internap.com> References: <1582DCBFF968F044A9A910C0AB177C902CE55A@cliff.cdi.local> <47B1D21F.5030807@internap.com> <47B31722.5080600@internap.com> <47B3B711.4040004@psg.com> <47B3C6D9.5050205@internap.com> Message-ID: <47B3CC42.7010703@psg.com> [ scott told me off list that he will not be at nanog. shame, as this would make a good ad hoc bof ] i think the six month thing is five levels indirect from the goal, route conservation, you say you want to achieve. hence it will have far less effect on the goal and many undesirable side effects and cause much faking to get around it. complexity is rarely actually except as a barrier to competition (which is why the telephants got into the sick mind-set that it is a good thing). i think the restriction on inter-region is un-needed and not useful. if it won't work operationally for the rirs, then they will handle that at the admin/ops level; it is not a matter of *policy*. and putting it in now will just mean we will have to go through policy process hoops later to take it back out. randy From sleibrand at internap.com Thu Feb 14 00:14:38 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 14 Feb 2008 00:14:38 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <1582DCBFF968F044A9A910C0AB177C902CE569@cliff.cdi.local> References: <1582DCBFF968F044A9A910C0AB177C902CE569@cliff.cdi.local> Message-ID: <47B3CE3E.7050109@internap.com> Jim Weyand wrote: > Scott- > > I copied section 8.4.2 and added your new language as the final bullet > point. I assume this is how you want it to read. > Yeah, I did the order slightly differently, but that doesn't matter except for readability. It'll go into version 1.1 of the proposal. > As I reflect on your proposal I have some thoughts. > > 1) Must a transferee receive all allowed addresses in a single > transaction from a single transferor? Because your new language says, > "receive a contiguous CIDR block" I assume that is your intent. I > understand that there are router table issues here Correct. > and I am a businessman not a technologist That's good: we need more perspectives like yours. > but it seems if I am pre-qualified to > receive a /16 and I find two /17s that are already advertised they can > be moved to my address space with no net effect on the router table. There's no direct effect on the routing table from that, but taking those two /17's means that someone who only needs a /17 will likely have to split a larger block to get it. Over time, average netblock size has decreased, and it will likely continue to do so. Therefore, we will have to allow deaggregation to meet the needs of ever-smaller netblocks, but we shouldn't encourage more deaggregation than necessary by using two smaller netblocks in place of one larger one. > I can see the potential problem where several entities have been > pre-qualified as transferors of a /16 and begin transferring /20s > (possibly because the market has valued them higher) and my transferee > above puts together his /16 worth of address space by purchasing (I > think I did the math right) 8 /20s from different holders resulting in > significant additional entries in the routing table. > > One solution to this is to allow the transfers but charge a transfer fee > for each transaction that increases the size of the router table. My > rationale for the additional fee is that all members of the community > bear some additional cost and individual entities that cause the > additional cost should bear some burden. > That would in theory be a sensible solution, and is very similar to the approach I feel governments should take to pollution-related externalities. However, ARIN is not a government, and needs to be very careful not to use fees in a punitive manner. Others can speak to those issues more than I, but my general impression is that while ARIN can charge fees for services performed (such as the work of transferring a registration), those fees can't be disproportionately high, which is what would be required to have an economic impact on deaggregation. > 2) I know there is a great concern in the community with speculators > that might buy and sell address space for a profit. However the > unintended consequence of putting too many barriers to trade is that a > "gray market" will develop that will be outside of the control of the > RIR. I understand from posts I have read here today that such a thing > is already happening. > > Maybe this is not a problem and I am worrying about something that has > no effect. > Yes, this is a valid concern. The main concern about speculation is that the price to transfer IPv4 address resources will likely track along something like a bell curve (price rising as free supply is used up, then later falling as people finish moving to IPv6), so if speculators are allowed to acquire addresses while the price is going up (with the hope of selling them as the price continues to go up), that will steepen the bell curve, causing a classic boom-and-crash pattern. This would, of course, raise the cost of acquiring IPv4 address resources when they're needed the most, and then flood the market with cheap addresses after they're no longer really needed. In order to control this, I think we need to ensure that the actual transfer of IPv4 address registrations occurs between legitimate address holders and organizations with a legitimate need for IPv4 addresses who'll actually use them. Private contracts of various sorts are possible to deal with the financial and timing issues, but at the end of the day when ARIN goes to complete the transfer, the addresses need to go to the network who'll be using them. There is definitely a small black market in IPv4 addresses today, and will likely be a much larger gray market later on if we don't implement a transfer policy, or do so poorly. I personally don't believe that steps taken to prevent speculation will encourage use of whatever gray market does exist: in fact, I would argue that our success at that will encourage use of the legitimate market. Are there any specific transfer conditions that you feel constitute more of a barrier to trade than is justified? > Thanks again for your work. You have shown great patience explaining > your proposal to all involved. > Thanks. And thank you (and everyone else who's posted) for participating in this discussion and providing constructive feedback. -Scott > -----Original Message----- > From: Scott Leibrand [mailto:sleibrand at internap.com] > Sent: Wednesday, February 13, 2008 11:13 AM > To: Jim Weyand > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal > > Jim, > > Reading over 4.2 and 4.3 of the NRPM, I see lots of different conditions > > for different types of networks. Specifically, the text in 4.2.2.1.3 > and 4.2.2.2.2 requiring that the requested IP address space will be > utilized within three months refers to organizations justifying an > initial allocation on the basis of their use of PA space, and is > intended to minimize delay in renumbering out of PA space (if > applicable) and beginning to use and route the new space. As I read > those sections, they don't require 100% utilization within three months. > > However, in 4.2.4.3 and 4.2.4.4, it does appear that a new ISP that > needs additional space before they've been an ARIN member for a year can > > only justify a three-month supply of addresses. After that, they can > get six months' worth. In the case of end users, they can get over a > year's worth of space according to 4.3.3. > > Given all this confusion, I'd like to decouple the 8.4 transfer policy's > > transfer sizes somewhat from the allocation and assignment sizes in 4.2 > and 4.3, by adding the following bullet point to 8.4.2: > > * The transferee may request and receive a contiguous CIDR block > large enough to provide a 12 month supply of IPv4 addresses. > > That will preserve the requirement that need and efficient use are > justified, but would bypass the sections of 4.2 and 4.3 concerned with > preventing hoarding (intentional or otherwise). My assumption here is > that the cost of transferring addresses and a 12-month supply rule would > > act as a sufficient brake to prevent anyone from getting more addresses > than they need for that timeframe. The 12-month supply should also be > sufficient, in concert with the one-block-every-6-months condition, to > ensure that transferees get enough address space to limit unnecessary > deaggregation. > > Thoughts? > > -Scott > >> 4.2.2.1.3. Three months >> >> Provide detailed information showing specifically how a /20 will be >> utilized within three months. >> >> >> 4.2.2.2.2. Three months >> >> Provide information showing that the requested IP address space will >> be utilized within three months and demonstrating an intent to >> announce the requested space in a multihomed fashion. >> >> >> 4.2.2.2.4. Additional requests following the initial >> allocation >> >> To receive additional address space following the initial allocation, >> multihomed organizations must have returned the original IP address >> space to its provider in its entirety and must provide justification >> for a new allocation as described above in the section titled >> Requirements for Requesting Initial Address Space. >> >> >> 4.2.4.3. Three months >> >> Provide detailed information showing specifically that the address >> space will be utilized within three months. Determination of the >> appropriate allocation to be issued is based on efficient utilization >> of space within this three-month time frame. >> >> >> 4.2.4.4. Six months >> >> After a subscriber has been a member of ARIN for one year they may >> choose to request a six-month supply of IP addresses. >> >> >> 4.3.3. Utilization rate >> >> Utilization rate of address space is a key factor in justifying a new >> assignment of IP address space. Requesters must show exactly how >> previous address assignments have been utilized and must provide >> appropriate details to verify their one-year growth projection. The >> basic criteria that must be met are: >> >> * A 25% immediate utilization rate, and >> * A 50% utilization rate within one year. >> >> > > > Scott Leibrand wrote: > >> No, I think that reflects my failure to actually re-read 4.2.2 when >> writing 8.4.3. :-) I'll look into that and see what revisions are >> needed are needed to make them consistent. Good catch. >> >> Thanks, >> Scott >> >> Jim Weyand wrote: >> >> >>> Well done! However I see one small issue that probably reflects my >>> > lack > >>> of understanding: >>> >>> Section 8.4.3 of the proposal below references NRPM 4.2.2. regarding >>> minimum allocation size and section 8.4.1 says, "The transferee may >>> > only > >>> receive one IPv4 address transfer every 6 months." >>> >>> However NRPM 4.2.2.2.2. says, " Provide information showing that the >>> requested IP address space will be utilized within three months and >>> demonstrating..." >>> >>> Which of course would mean that, to be consistent with the NRPM, a >>> transferee could only buy a three month supply of addresses every six >>> months. >>> >>> >>> -----Original Message----- >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf >>> > Of > >>> Member Services >>> Sent: Monday, February 11, 2008 11:35 AM >>> To: ppml at arin.net >>> Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal >>> >>> Resending with a typo that has been corrected in 8.4.2 below. The >>> original text is supposed to have "24 months" twice in that section. >>> >>> Member Services >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> >>> >>> ARIN received the following policy proposal. In accordance with the >>> > ARIN > >>> Internet Resource Policy Evaluation Process, the proposal is being >>> posted to the ARIN Public Policy Mailing List (PPML) and being placed >>> > on > >>> ARIN's website. >>> >>> The ARIN Advisory Council (AC) will review this proposal at their >>> > next > >>> regularly scheduled meeting. The AC may decide to: >>> >>> 1. Accept the proposal as written. If the AC accepts the proposal, >>> > it > >>> will be posted as a formal policy proposal to PPML and it will be >>> presented at a Public Policy Meeting. >>> >>> 2. Not accept the proposal. If the AC does not accept the >>> > proposal, > >>> the AC will explain their decision via the PPML. If a proposal is not >>> accepted, then the author may elect to use the petition process to >>> advance their proposal. If the author elects not to petition or the >>> petition fails, then the proposal will be closed. >>> >>> The AC shepherds for this proposal are Scott Leibrand and Stacy >>> > Taylor. > >>> The AC invites everyone to comment on this proposal on the PPML, >>> particularly their support or non-support and the reasoning behind >>> > their > >>> opinion. Such participation contributes to a thorough vetting and >>> provides important guidance to the AC in their deliberations. >>> >>> The ARIN Internet Resource Policy Evaluation Process can be found at: >>> http://www.arin.net/policy/irpep.html >>> >>> Mailing list subscription information can be found at: >>> http://www.arin.net/mailing_lists/ >>> >>> Regards, >>> >>> Member Services >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> ## * ## >>> >>> >>> Policy Proposal Name: IPv4 Transfer Policy Proposal >>> >>> Author: ARIN Advisory Council >>> >>> Proposal Version: 1.0 >>> >>> Submission Date: 02/07/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 "M&A Transfer >>> Requirements": >>> >>> 8.2. M&A Transfer Requirements >>> >>> 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.] >>> >>> >>> [8.3 - retitle to "M&A Transfer Documentation Requirements": >>> >>> 8.3. M&A Transfer Documentation Requirements >>> >>> 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.4. Requirements for Simple Transfer of IPv4 Addresses >>> >>> After the exhaustion of the IANA IPv4 free pool, ARIN will also >>> > process > >>> IPv4 address transfer requests subject to the following conditions. >>> >>> 8.4.1 Conditions on the transferor: >>> >>> * 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.4.2 Conditions on the transferee: >>> >>> * 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 only receive one IPv4 address transfer >>> > every 6 > >>> months. >>> >>> >>> >>> 8.4.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. >>> >>> 8.4.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.4.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 exact network address and >>> > size > >>> (CIDR prefix length) the transferor is eligible to provide, >>> > and > >>> the expiration date of the pre-qualification. >>> >>> 8.5. Safe Harbor for IPv4 Transfers through this Simple Transfer >>> Process >>> >>> IPv4 address resources being made available for transfer shall be >>> > exempt > >>> from ARIN audit until expiration of the transfer pre-qualification or >>> completion of the transfer. In the event that a transfer >>> pre-qualification expires, ARIN shall have up to 90 days to initiate >>> > an > >>> audit prior to this exemption being reinstated through subsequent >>> transfer pre-qualification. This will not extend the end of the >>> exemption. >>> >>> 8.6. 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.7. 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. >>> >>> 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. >>> _______________________________________________ >>> 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 sleibrand at internap.com Thu Feb 14 00:30:43 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 14 Feb 2008 00:30:43 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B3CC42.7010703@psg.com> References: <1582DCBFF968F044A9A910C0AB177C902CE55A@cliff.cdi.local> <47B1D21F.5030807@internap.com> <47B31722.5080600@internap.com> <47B3B711.4040004@psg.com> <47B3C6D9.5050205@internap.com> <47B3CC42.7010703@psg.com> Message-ID: <47B3D203.6030607@internap.com> Randy Bush wrote: > [ scott told me off list that he will not be at nanog. shame, as this > would make a good ad hoc bof ] And as I mentioned, I'd be happy to participate by telephone in any such ad hoc discussion that does develop, so don't let my physical absence dissuade you. > i think the restriction on inter-region is un-needed and not useful. > if it won't work operationally for the rirs, then they will handle > that at the admin/ops level; it is not a matter of *policy*. and > putting it in now will just mean we will have to go through policy > process hoops later to take it back out. I'll address this one first. I have no strong opinions on the inter-region restriction. On the one hand, I don't want to encourage "RIR shopping". On the other hand, I can see some justifications, such as yours, for not addressing this in policy. Perhaps others could comment on this and inform the discussion a bit. > i think the six month thing is five levels indirect from the goal, > route conservation, you say you want to achieve. hence it will have > far less effect on the goal and many undesirable side effects and > cause much faking to get around it. complexity is rarely actually > except as a barrier to competition (which is why the telephants got > into the sick mind-set that it is a good thing). So I guess we might as well get into the full discussion of how to go about balancing routing table efficiency with ensuring a fully liquid market that gets space to those who need it effectively. There are a number of aspects of policy that bear on this: 1. Justification of efficient use 2. Minimum allocation size 3. Preventing transferees from collecting multiple small blocks 4. Preventing transferors from splitting their existing block into too many smaller ones Theoretically, #1 and #2 might be enough to get us a decent level of routing table efficiency. However, since acquisition of IPv4 resources by transfer will incur significant costs, there will be significant incentive to acquire smaller blocks than is typical today, and that will likely accelerate the rate of routing table growth. Therefore, #3 is a possible counterweight: if a transferee can get one year's worth of addresses by transfer (rounding up to CIDR boundaries), and can't come back for more for 6 months, they will be less inclined to get new space every month or every quarter based on budget targets, and will instead need to get a large enough block to meet all their needs for at least 6 months. This will directly reduce the number of routing slots used by that transferee. #4 I'm not so sure about. I originally put such a restriction in the policy proposal based on the intuition that it would be an additional check on deaggregation. However, in discussions since then, I've realized that doing so may significantly reduce the supply of IPv4 address blocks of the sizes in demand by potential transferees. This runs counter to one of my goals, maximizing supply and making addresses available at the lowest possible cost. It also tends to be somewhat inefficient (in any market) to try to regulate both suppliers and consumers. Therefore, I am now leaning towards relaxing the conditions on transferors from what is proposed in version 1.0. That might even mean removing all restriction on deaggregation by transferors, down to the minimum allocation size, or there might be some middle ground. If anyone has any good ideas along those lines, please share. -Scott From michael.dillon at bt.com Thu Feb 14 02:26:44 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 14 Feb 2008 07:26:44 -0000 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B35D02.4030206@internap.com> References: <47B12650.2060107@internap.com> <47B30DC8.5020907@internap.com> <47B33D51.5020503@internap.com> <47B35D02.4030206@internap.com> Message-ID: > Where can I buy these NAT-PT and Teredo boxes and ALGs? NAT-PT, Teredo and ALGs are software, not hardware. You install them on whatever boxes you wish according to the load that you want to handle. > How much do > they cost, particularly at scale? Whatever commodity hardware costs for you. > And where can I get all of the > middleboxes (firewalls, network management systems, VPN > concentrators, > load balancers, etc.) to support native IPv6? Start at ARIN's IPv6 wiki at http://www.getipv6.info and follow up with some of the vendors there. In the case of software solutions like Miredo, if you can't do it in-house, contact your favorite local consultants to set it up for you. There is no such thing as IPv6 ISP-in-a-box. You still have to chase the vendors to get the features that you want, just as in the IPv4 world. > It's pretty > clear to me > that we are *not* ready to do IPv6-only networking without dual-stack. Dual-stack is not a way to do IPv6-only networking. Please re-read your sentence slowly and check the definition of "only" and "dual-stack". Here is an ISOC briefing from 2002 http://www.isoc.org/briefings/006/ that makes it pretty clear what dual-stack means. > > If an ISP can't make the Internet a basically seamless service, > > regardless of IPv6 or IPv4, then they simply won't survive against > > their more nimble competition. > > You are arguing that some networks will run IPv6, some will run IPv4, > and there will be devices that happily translate between the > two. No, I'm saying that we are entering a transition period when ISPs implementing IPv6 will also have to set up transition mechanisms for IPv4 traffic, and when IPv4 ISPs will also be forced into implementing transition mechanisms because the global public Internet will be a mixture of IPv4 and IPv6. Since people nowadays tend to move their computing endpoints from place to place, all ISPs will need to support IPv4 and IPv6 users to some degree or other. > I am > arguing that no one will go IPv6-only right away, everyone > who does IPv6 > will want do dual-stack, and that they'll need IPv4 addresses > to do so. Which means that dual-stack is a short term solution which most people will not be able to *GROW* after IPv4 addresses run out. Ten years ago this looked like a good way to transition, but not anymore. Companies who make the technical choices which allow them to grow their IPv6 infrastructure without adding IPv4 addresses will have an advantage in the next few years. There are a number of large network operators with MPLS core networks and these companies have discovered that it is relatively easy to add IPv6 edge routers using 6PE without disrupting the rest of their network. I expect 100% of MPLS networks to take this route and I strongly recommend IPv4 core networks to begin today in evaluating GRE or PWE3 IPv6 overlay network possibilities (or MPLS transition). > > One thing that ARIN staff could do to help this process would be > > to run a v6/v4 agnostic and fully transparent meeting network. > Sounds like an admirable goal, as is a similar exercise to > turn off IPv4 > at the upcoming IETF plenaries and try to get people to > communicate with > the IPv4 Internet from an IPv6-only network. I strongly disagree. The IETF plan is to slap people in the face hoping that they will wake up and be happy. I am suggesting that ARIN could take a technical leadership role and demonstrate how a mixed Internet is possible without slapping people in the face. > However, until someone > succeeds at demonstrating how this can be done > cost-effectively at ISP > scale, As with any kind of scaling, the first step is to show that it can be done. --Michael Dillon From Keith at jcc.com Thu Feb 14 07:57:50 2008 From: Keith at jcc.com (Keith W. Hare) Date: Thu, 14 Feb 2008 07:57:50 -0500 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 Transfer Policy Proposal Message-ID: > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Randy Bush > Sent: Wednesday, February 13, 2008 6:22 PM > > those coming to nanog (and we hope apricot, ietf, ...) will > have the opportunity to join us in eating our own dogfood. > there will be extensive ipv6 deployment and even an hour when > normal ipv4 is turned off. the hacks and tricks to make this > work will be part of the program content. so it will be > educate and measure time. It would be useful to have a paper documenting all of the pieces & parts needed to make this work. I will believe IPv6 is almost real when I can go to the web sites for PC Connection, CDW, etc., search for IPv6, and find routers, switches, etc. that claim to support IPv6. Right now, IPv6 is not even a marketing buzzword. The products that do support IPv6 list it deep in the specifications, not in the big text on the outside of the box. Keith ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ From bicknell at ufp.org Thu Feb 14 08:48:07 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 14 Feb 2008 08:48:07 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B3CC42.7010703@psg.com> References: <1582DCBFF968F044A9A910C0AB177C902CE55A@cliff.cdi.local> <47B1D21F.5030807@internap.com> <47B31722.5080600@internap.com> <47B3B711.4040004@psg.com> <47B3C6D9.5050205@internap.com> <47B3CC42.7010703@psg.com> Message-ID: <20080214134807.GA3512@ussenterprise.ufp.org> In a message written on Thu, Feb 14, 2008 at 02:06:10PM +0900, Randy Bush wrote: > i think the restriction on inter-region is un-needed and not useful. if > it won't work operationally for the rirs, then they will handle that at > the admin/ops level; it is not a matter of *policy*. and putting it in > now will just mean we will have to go through policy process hoops later > to take it back out. I'm not sure transfers across regions are as easy as "just do it". One interesting area that we haven't discussed is dispute resolution. There's going to be at least one case where someone doesn't live up to their end of the bargan; either not paying or not relenquishing the resource. With the policy as written both parties have signed an RSA with a single RIR and have agreed to the same transfer policy which they are bound to by the RSA. Presumably the RIR can work to mediate the situation and worse comes to worse it's relatively well defined who to sue in court. The situation is not so clear if one party as signed a contract with one RIR, and another with a different RIR; particularly when those parties may have signed contracts with different, even conflicting terms. Do the RIR's need a contractual relationship? If you had to go to court do you sue one, or the other, or both? ARIN's RSA specifies Virginia, I presume RIPE's specifies Holland; how do those provisions square legally. Worse, what if the transfer policies are different? What if ARIN's says the resource must be available on the date of the transfer, and RIPE's policy states the resource must be available within 30 days? Should the recipient expect it immediately or in 30 days? One solution is a global policy. What that generally means is hitting all 5 RIR's twice, once to get feedback from all 5, then fixing the language, then going back to all 5 to present and get it accepted. Given the schedules I think 18 months is a realistic timeframe for that process to occur. Is it worth taking the 18 months to get it right? Do we pass a policy in our own region in the mean time, or wait for the "one true 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 kkargel at polartel.com Thu Feb 14 09:25:23 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 14 Feb 2008 08:25:23 -0600 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: <47B12650.2060107@internap.com><47B30DC8.5020907@internap.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410660104F346@mail> I completely understand that the list of things I touched on was primarily the "trivial" applications, I did that on purpose to stress a point. Whether realistic or not these "trivial" applications are the things that will generate noise from my residential ISP customers. I am sure that commercial and enterprise implementations face a completely different set of priorities, with the exception of smooth running VPN's being critical. I am also sure that there are many critical apps that I did not mention which are not IPv6 functional today, but I do not want to write a treatise. I do find it quite interesting that end user applications seem to be riding the leading edge, for example Operating Systems and Email Clients are ready, while email servers and RBL's are lagging behind. IPv6 is technically possible today (Great news IMHO, and kudos to all that brought it to being), but I would certainly not call it useful for the average consumer -- yet. As I stated earlier, the biggest drawback up here in the boonies is that none of my upstream providers are offering IPv6. The day after I have IPv6 upstream available I will be routing, in some shape or fashion. Kevin > -----Original Message----- > From: Bill Darte [mailto:BillD at cait.wustl.edu] > Sent: Wednesday, February 13, 2008 12:09 PM > To: Kevin Kargel; ppml at arin.net > Subject: IPv6 getting real: was Policy Proposal: IPv4 > Transfer Policy Proposal > > > > > > There is no way we will be able to go IPv6 only until ALL > of the major > > content providers are IPv6 functional, and ALL of the email > providers > > are compliant. Think of how you would complain if your ISP > went IPv6 > > and told you that you could now email to "some" places.. or even > > "most" > > places. > > > > There are a lot of things that need to be functional before > > IPv6 is a reality for ISP's.. little stuff like IPv6 > RBL's, bug free > > IPv6 VPN compatibility with ALL of the major VPN hardware > and software > > vendors, > > IPv6 connectivity for entertainment networks like Xbox Live > and PS3, > > gaming sites, IM protocols, and a host of other applications that > > consumers rightfully demand. Any one of these "trivial" > services not > > working is a deal killer for an ISP converting to IPv6 only. > > > (Snip) > > > > What tends to be forgotten, is that for the little guys > IPv6 will not > > be a complete solution until EVERYTHING that is available > on IPv4 is > > also available on IPv6 and the use is just as transparant > to the end > > user. > > > > Kevin > > > > > Thanks for this list of things that you feel must become > 'real' before there can be a significant adoption of IPv6 by > the industry. > > I would like to call for others to consider what among this > listing of things may NOT be a problem in your experience, > and ALSO other serious items that Kevin may have missed > including applications. > > I believe it is important to identify all the stumbling > blocks (perhaps as a checklist) that may exist so potential > adopters can get a heads up and importantly begin to apply > leverage to their vendors for support...in order to reduce > the number of hurdles. > > Or perhaps a comprehensive checklist already exists that I'm > unaware of... > > Finally, I'm interested in initiatives that you know exist or > could/should exist (open source projects, research needed, > etc.) that would help reduce these stumbling blocks. > > It would be nice to consider what ARIN (beyond policy and > within its charter and mission) could support to promote adoption. > > Bill Darte > ARIN AC > From michael.dillon at bt.com Thu Feb 14 09:49:10 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 14 Feb 2008 14:49:10 -0000 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 TransferPolicy Proposal In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A0631410660104F346@mail> References: <47B12650.2060107@internap.com><47B30DC8.5020907@internap.com><70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> <70DE64CEFD6E9A4EB7FAF3A0631410660104F346@mail> Message-ID: > As I stated earlier, the biggest drawback up here in the > boonies is that none of my upstream providers are offering > IPv6. The day after I have > IPv6 upstream available I will be routing, in some shape or fashion. This is a widely held position which suggests that IPv6 will mainly be deployed from the network core outwards to the edges. This means that the largest ISPs and other core service providers have to be first. When I say "core service providers" I mean things like DNS providers (finally IPv6 glue records are appearing in root nameservers) and RIRs like ARIN. I don't consider ARIN conference attendees to be core service providers which is why I consider the shutting down of IPv4 service to be little more than a stunt. ARIN plays the role of ISP during a conference and it is ARIN which should be adapting their services not the attendees. If ARIN cannot offer an Internet service that just plain works, regardless of whether a laptop has IPv4 or IPv6 or both configured, then who can? Where will we learn to provide such a service? The only thing that comes from this stunt, other than some disruption of the meeting, is that a few people will get their laptops configured to run with both IPv4 and IPv6, but this does NOTHING to further the work that needs to be done. Of course today the answer probably is that nobody can. But if we don't begin to make the effort, however imperfect, we will not get through this transition without a lot of pain. In the early days of the Internet, a lot of things did not work properly. But people repeatedly came together at meetings like Interop to try and make things work, take notes on problem areas, and go back home to fix what was broken. Eventually, this paid off. IPv6 is no different and will not just fall from the sky, fully formed and perfect, wrapped up in a nice turquoise box with a vendor's label on the side. --Michael Dillon From kkargel at polartel.com Thu Feb 14 09:49:52 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 14 Feb 2008 08:49:52 -0600 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B338A9.4010500@internap.com> References: <47B12650.2060107@internap.com> <47B30DC8.5020907@internap.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> <47B338A9.4010500@internap.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410660104F348@mail> Scott, The best plan I see now for residential ISP's is to start putting new customers on IPv6 for local connectivity, using dual stack translation for global connectivity. This will work for almost everything except VPN's and residential servers (xBox, remote desktop et.al.) .. With that phase working when IPv6 DHCP is debugged we can start migrating existing end users via Radius and PPPoE. This should actually be rather transparant to the customer. As customer connections are the primary consumer of IP's for an ISP, utilizing IPv6 for this will allow IP's to be reclaimed for use for global connections. This will greatly extend the time that an ISP can remain IPv4 functional after exhaustion. My plan at this point is to try to arrange things so I can function no matter what changes in policy arise. > -----Original Message----- > From: Scott Leibrand [mailto:sleibrand at internap.com] > Sent: Wednesday, February 13, 2008 12:36 PM > To: Kevin Kargel > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal > > Thanks for that perspective, Kevin. > > Do you see a transfer policy like this one as necessary to > maintain IPv4 connectivity during the transition? If not, > how do you think ISPs like you will deal with the continued > need for IPv4 addressing after free pool exhaustion? If so, > do you think that this proposed transfer policy strikes a > good balance between providing the conditions for a liquid > market and preventing unnecessary routing table growth and > speculative market behavior? > > Thanks, > Scott > > Kevin Kargel wrote: > > Just to give some feedback FROM one the ISP's you are > talking about.. > > Our plan is to go dual stack as soon as ANY of our upstream > providers > > can feed us dual stack. We are already working on the > enterprise dual > > stack routing, and have actually established an IPv6 tunnel > connection > > (that I don't want to route real traffic over and abuse the network > > that was so kind as to let us connect). Luckily, we use > exclusively > > Cisco routing hardware, which has dual stack funtionality built in. > > > > There is no way we will be able to go IPv6 only until ALL > of the major > > content providers are IPv6 functional, and ALL of the email > providers > > are compliant. Think of how you would complain if your ISP > went IPv6 > > and told you that you could now email to "some" places.. > or even "most" > > places. > > > > There are a lot of things that need to be functional before > IPv6 is a > > reality for ISP's.. little stuff like IPv6 RBL's, bug free > IPv6 VPN > > compatibility with ALL of the major VPN hardware and > software vendors, > > IPv6 connectivity for entertainment networks like Xbox Live > and PS3, > > gaming sites, IM protocols, and a host of other applications that > > consumers rightfully demand. Any one of these "trivial" > services not > > working is a deal killer for an ISP converting to IPv6 only. > > > > So whether or not it is more expensive, more work, or > otherwise more > > painful, ISP's will be forced to maintain IPv4 connectivity until > > content there is obsoleted. > > > > What tends to be forgotten, is that for the little guys > IPv6 will not > > be a complete solution until EVERYTHING that is available > on IPv4 is > > also available on IPv6 and the use is just as transparant > to the end user. > > > > Kevin > > > > > > > >> -----Original Message----- > >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] > On Behalf > >> Of Scott Leibrand > >> Sent: Wednesday, February 13, 2008 9:33 AM > >> To: michael.dillon at bt.com > >> Cc: ppml at arin.net > >> Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal > >> > >> michael.dillon at bt.com wrote: > >> > >>>> Yes. There is a large installed base for whom migrating to > >>>> IPv6 may be painful (expensive). Reducing the community's total > >>>> expense for operating their IP networks is a benefit to > >>>> > >> the Internet > >> > >>>> community. > >>>> > >>>> > >>> RED HERRING! > >>> > >>> Given the fact that ISPs who implement IPv6 transit service > >>> > >> will also > >> > >>> have to implement transition mechanisms such as Teredo, > 6to4, etc., > >>> there is no imperative for any part of the installed base > >>> > >> to migrate > >> > >>> to IPv6 before they are ready. > >>> > >>> The imperative today is for those organizations with > >>> > >> steadily growing > >> > >>> networks at the heart of their business model (ISPs) to begin > >>> transitioning. Whether it is painful or not, they must do > it or die > >>> because network growth is fundamental to their being. > >>> > >>> > >> I think you make an unjustified assumption that ISPs will > be able to > >> deploy IPv6-only service to new customers and operate transition > >> mechanisms such as Teredo, 6to4, etc. > >> > >> An alternative, and IMO more likely, transition mechanism > is to use > >> two much more familiar technologies: dual stack and NAT. Many > >> consumer ISPs will be able to start providing IPv6 > support, provide > >> the ability for their customers to dual-stack, and then start > >> providing NAT'd RFC1918 addresses to their DHCP customers > instead of > >> public IPs. This will be fairly easy for some ISPs, and more > >> difficult for others (such as business ISPs, with more static-IP > >> customers and smaller DHCP pools). > >> In addition, there will be a great diversity of IPv6 support in > >> middleboxes (home routers, enterprise firewalls, etc.) > >> > >> Given this diversity in cost of migrating to IPv6 > >> (dual-stack) and reducing IPv4 demand, there is an opportunity to > >> allow organizations for whom the migration cost is higher to delay > >> migration until IPv6 technology is better > developed/deployed, and in > >> the mean time get IPv4 addresses from other organizations for whom > >> the migration cost is lower. Additionally, such a transfer policy > >> would provide an incentive to encourage organizations to migrate > >> their installed base to some form of IPv6 where it's > easier to do so, > >> rather than requiring growing networks to do so if it's more > >> expensive for them. > >> > >> > >>> If an ISP decided to try and avoid implementing IPv6 by getting > >>> IPv4 addresses from other sources, they are simply backing > >>> > >> themselves > >> > >>> into a corner and relying on their competitors to operate > >>> > >> transition > >> > >>> mechanisms for them. This is a risky strategy since the > >>> > >> market segment > >> > >>> who are willing to buy IPv4 network access will be steadily > >>> > >> shrinking. > >> > >>> In addition, their existing customers will begin to move > >>> > >> away because > >> > >>> the ISP is perceived as being incompetent and at risk of > hitting a > >>> brick wall. > >>> > >>> > >> I suspect that after ARIN free pool exhaustion, all ISPs > will offer > >> some form of IPv6 service. To do so successfully, and support > >> dual-stack, however, there will be a continued need for IPv4 > >> addresses. In some cases, a network may be able to free up enough > >> IPv4 addresses to allow them to transfer them to other > organizations. > >> In other cases, they'll be able to free up some, but not all, of > >> their existing IPv4 addresses and use the remainder for > growth. In > >> other cases, growth may overtake the ability of a network to > >> cost-effectively reclaim > >> IPv4 addresses (possibly due to a small install base), so > continued > >> availability of addresses from other organizations will be > essential > >> to avoiding much higher transition costs than are necessary. > >> > >> > >>> > >>> > >>>> This policy > >>>> proposal allows organizations to choose what's best for > >>>> > >> them, rather > >> > >>>> than forcing a one-size-fits-all solution. > >>>> > >>>> > >>> I disagree that this policy does what you say. In fact this > >>> > >> policy is > >> > >>> trying to set up a market for buying and selling IP addresses. > >>> > >>> > >> I don't think we're in disagreement here. This policy proposal > >> allows organizations to choose what's best for them by > setting up a > >> market for transferring IP addresses. The addresses > aren't property, > >> so no one will be buying and selling the addresses themselves, but > >> the underlying market economics will be similar. > >> > >>> Under current policy, an ISP who migrates infrastructure to > >>> > >> IPv6 can > >> > >>> return their IPv4 addresses to ARIN. And an ISP who is not > >>> > >> migrating > >> > >>> can continue to apply to ARIN for more IPv4 addresses and > >>> > >> receive the > >> > >>> returned ones. > >>> > >>> This is clear and simple and easy to understand. It is > the way that > >>> IPv4 allocation has always been done and is fully understood by > >>> everybody who deals with IP networking. Any new policy > like the one > >>> proposed, simply muddies the waters and creates confusion. > >>> > >>> > >> Yes, it is clear and simple, but it is not sufficient. If > a network > >> has no incentive to go to the trouble of renumbering out of IPv4 > >> addresses, they won't return them, and there won't be enough IPv4 > >> addresses to meet the needs of those who need more addresses. > >> However, if the transfer process can cover the cost of > renumbering, > >> many more organizations will choose to do so. To put it in basic > >> economic terms, if we fix the price of scarce IPv4 > addresses at zero > >> (by leaving policy unchanged), supply will be insufficient to meet > >> demand after the free pool is exhausted. > >> If we allow price to be set by a market, the price will > rise to the > >> point where it increases supply and reduces demand enough > to get them > >> into balance. > >> > >> -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 michael.dillon at bt.com Thu Feb 14 11:01:12 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 14 Feb 2008 16:01:12 -0000 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 TransferPolicy Proposal In-Reply-To: References: Message-ID: > I will believe IPv6 is almost real when I can go to the web > sites for PC Connection, CDW, etc., search for IPv6, and find > routers, switches, etc. > that claim to support IPv6. And before you can do that, somebody has to collect that information so that PC Connection and CDW can find the products to sell. That's why ARIN has set up an IPv6 info Wiki where this information can be collated. A couple of pages with the info that you mentioned are and . Feel free to register on the site and add your entries to those lists, or add new pages with other lists, or add any other useful information that will help people. I've taken the liberty of setting up a page for information on how to make use of IPv6 at the ARIN Member Meetings. Right now this is just a placeholder. Hopefully ARIN staff and those helping run the IPv6 network, will add to the page soon. --Michael Dillon From kkargel at polartel.com Thu Feb 14 11:42:51 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 14 Feb 2008 10:42:51 -0600 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4TransferPolicy Proposal In-Reply-To: References: Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410660104F34F@mail> > > I will believe IPv6 is almost real when I can go to the web > sites for > > PC Connection, CDW, etc., search for IPv6, and find > routers, switches, > > etc. > > that claim to support IPv6. > Any routers and switches made by Cisco with anything close to current IOS or CatOS support IPv6 with dual stack and translation. Kevin From info at arin.net Thu Feb 14 11:54:07 2008 From: info at arin.net (Member Services) Date: Thu, 14 Feb 2008 11:54:07 -0500 Subject: [ppml] NRPM version 2008.1 - New Policy Implementation Message-ID: <47B4722F.6030604@arin.net> On 11 December 2007, the ARIN Board of Trustees, based 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-25: IPv6 Policy Housekeeping This policy proposal has been incorporated into version 2008.1 of the ARIN Number Resource Policy Manual (NRPM) which is effective 14 February 2008. NRPM version 2008.1 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 dlw+arin at tellme.com Thu Feb 14 12:19:42 2008 From: dlw+arin at tellme.com (David Williamson) Date: Thu, 14 Feb 2008 09:19:42 -0800 Subject: [ppml] Random v6 discussions (was Re: Policy Proposal: IPv4 Transfer Policy Proposal) In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A0631410660104F348@mail> References: <47B30DC8.5020907@internap.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> <47B338A9.4010500@internap.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F348@mail> Message-ID: <20080214171942.GN8368@shell01.cell.sv2.tellme.com> On Thu, Feb 14, 2008 at 08:49:52AM -0600, Kevin Kargel wrote: > As customer connections are the primary consumer of IP's for an > ISP, utilizing IPv6 for this will allow IP's to be reclaimed for use for > global connections. That's one of the key problems, isn't it? The place you least want to disrupt anything is the very edge. We're talking about mucking up layer 3. That's the network layer...that bit that's supposed to provide end-to-end connectivity. Everything below isn't worried about reaching beyond the local network. Everything above is assuming the network layer has done its job. You can muck about in the middle of a connection (by encapsulation, labelling, etc.), but the end points are going to care about that end-to-end connectivity. Much as I like the idea of "fix the edge so that we have more time to fix the middle", I think it's going to be much more practical to fix the middle, and dual-stack the edge until v6 is viable end-to-end on its own. Oh, and there's no way that's going to happen without massive impact to the whole network, since getting the edge fixed will definitely take longer than the remaining time before pool exhaustion, no matter how you calculate it. That implies some quality time with protocol translators...pick your favorite 4-to-6 conversion method. It stuns me that there are serious networking folks who don't think we'll run out of v4 addresses. But this is now waaaaaay off the topic of policy, which is the purpose of this list. -David From kkargel at polartel.com Thu Feb 14 12:49:54 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 14 Feb 2008 11:49:54 -0600 Subject: [ppml] Random v6 discussions (was Re: Policy Proposal: IPv4 Transfer Policy Proposal) In-Reply-To: <20080214171942.GN8368@shell01.cell.sv2.tellme.com> References: <47B30DC8.5020907@internap.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> <47B338A9.4010500@internap.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F348@mail> <20080214171942.GN8368@shell01.cell.sv2.tellme.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410660104F351@mail> One thing to remember that may affect your algorythm, is that for residential ISP's as the last mile deliverer we have two edges.. an external edge connecting to the world, and an internal edge connecting to our customer premises. Right now the only solution that makes any sense for me is to dual stack both edges, then dual stack my core, slowly migrate my customer edge to v6 only, and migrate the outside edge ot v6 when v4 traffic disappears (indicating end user need dissapation). I certainly believe we are running out of v4 addresses. I do not anticipate that v4 will be obsoleted in my career duration. Kevin > -----Original Message----- > From: David Williamson [mailto:dlw+arin at tellme.com] > Sent: Thursday, February 14, 2008 11:20 AM > To: Kevin Kargel > Cc: ppml at arin.net > Subject: Random v6 discussions (was Re: [ppml] Policy > Proposal: IPv4 Transfer Policy Proposal) > > On Thu, Feb 14, 2008 at 08:49:52AM -0600, Kevin Kargel wrote: > > As customer connections are the primary consumer of > IP's for an ISP, > > utilizing IPv6 for this will allow IP's to be reclaimed for use for > > global connections. > > That's one of the key problems, isn't it? The place you > least want to disrupt anything is the very edge. We're > talking about mucking up layer 3. That's the network > layer...that bit that's supposed to provide end-to-end > connectivity. Everything below isn't worried about reaching > beyond the local network. Everything above is assuming the > network layer has done its job. You can muck about in the > middle of a connection (by encapsulation, labelling, etc.), > but the end points are going to care about that end-to-end > connectivity. > > Much as I like the idea of "fix the edge so that we have more > time to fix the middle", I think it's going to be much more > practical to fix the middle, and dual-stack the edge until v6 > is viable end-to-end on its own. Oh, and there's no way > that's going to happen without massive impact to the whole > network, since getting the edge fixed will definitely take > longer than the remaining time before pool exhaustion, no > matter how you calculate it. That implies some quality time > with protocol translators...pick your favorite 4-to-6 > conversion method. > > It stuns me that there are serious networking folks who don't > think we'll run out of v4 addresses. But this is now > waaaaaay off the topic of policy, which is the purpose of this list. > > -David > From BillD at cait.wustl.edu Thu Feb 14 12:59:17 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Thu, 14 Feb 2008 11:59:17 -0600 Subject: [ppml] Random v6 discussions (was Re: Policy Proposal: IPv4Transfer Policy Proposal) In-Reply-To: <20080214171942.GN8368@shell01.cell.sv2.tellme.com> References: <47B30DC8.5020907@internap.com><70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail><47B338A9.4010500@internap.com><70DE64CEFD6E9A4EB7FAF3A0631410660104F348@mail> <20080214171942.GN8368@shell01.cell.sv2.tellme.com> Message-ID: David, I don't think your comments are waaaay off or even somewhat off the mark of policy. Policy making depends upon as complete and full understanding of the mix of opinions and probabilities as possible. Those of you with insight through experience must project those insights into the future that all may judge them against their own experience. Ultimately, this will result in the best decision making. bd > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of David Williamson > Sent: Thursday, February 14, 2008 11:20 AM > To: Kevin Kargel > Cc: ppml at arin.net > Subject: [ppml] Random v6 discussions (was Re: Policy > Proposal: IPv4Transfer Policy Proposal) > > On Thu, Feb 14, 2008 at 08:49:52AM -0600, Kevin Kargel wrote: > > As customer connections are the primary consumer of > IP's for an ISP, > > utilizing IPv6 for this will allow IP's to be reclaimed for use for > > global connections. > > That's one of the key problems, isn't it? The place you > least want to disrupt anything is the very edge. We're > talking about mucking up layer 3. That's the network > layer...that bit that's supposed to provide end-to-end > connectivity. Everything below isn't worried about reaching > beyond the local network. Everything above is assuming the > network layer has done its job. You can muck about in the > middle of a connection (by encapsulation, labelling, etc.), > but the end points are going to care about that end-to-end > connectivity. > > Much as I like the idea of "fix the edge so that we have more > time to fix the middle", I think it's going to be much more > practical to fix the middle, and dual-stack the edge until v6 > is viable end-to-end on its own. Oh, and there's no way > that's going to happen without massive impact to the whole > network, since getting the edge fixed will definitely take > longer than the remaining time before pool exhaustion, no > matter how you calculate it. That implies some quality time > with protocol translators...pick your favorite 4-to-6 > conversion method. > > It stuns me that there are serious networking folks who don't > think we'll run out of v4 addresses. But this is now > waaaaaay off the topic of policy, which is the purpose of this list. > > -David > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at > info at arin.net if you experience any issues. > From tedm at ipinc.net Thu Feb 14 13:02:03 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 14 Feb 2008 10:02:03 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <6377979F-689B-47F1-B91A-FD4D7A245886@delong.com> Message-ID: >-----Original Message----- >From: Owen DeLong [mailto:owen at delong.com] >Sent: Wednesday, February 13, 2008 1:57 PM >To: Ted Mittelstaedt >Cc: David Conrad; Public Policy Mailing List >Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal > > >Given that the policy under discussion specifically precludes such >transfers until IANA is no longer able to respond to requests, thus >eliminating the standard request-reallocate in short order, I am not >sure I agree with your reasoning. > This is an ARIN not an IANA policy. You mean "when ARIN is no longer able to respond..." ARIN will always be able to respond, because there will be IPv4 that will always be vacated. There will always be ISP's and networks that go out of business and stop paying their registration fees, thus that space will become available. The problem isn't that ARIN cannot respond with IPv4 allocation requests. The problem is that they cannot repond as fast as you want 'em. Unless, of course, this policy goes into effect. Because then, nobody will return IPv4 to ARIN. They will just sell it to someone else. Over time the deep-pockets own everything. You know, we already have that kind of stuff going on in other industries. I for one am just a bit sick of the "he who has the gold makes the rules" garbage. Can we just please NOT have to drag the Internet down this path? >Additionally, the policy specifically requires that a transferee meet >all of the same requirements that are necessary in order to qualify >under the request-reallocate system prior to receiving a transfered >block, so, this policy doesn't really create a "special" class in that >regard. > If that is all you really want, then a "reservation" system can be created that would require the IP block owner to return the blocks to ARIN then ARIN reallocate them. No money need change hands between the donor and recipient. The donor pays less fees so they financially benefit. If your dead-set that the only way donors will give up IPv4 is by paying them over and above the financial gain for not having to pay fees on IPv4, then post-IPv4 runout, ARIN can start "bonusing" out donors who return IPv4 - and raise allocation fees for IPv4 to pay for the bonuses. In that way it is fair for everyone, and the burden is not on the requestor to find an org that has spare IPv4. Also, it eliminates a lot of annoyong "do-nothings" who will likely setup boiler room operations and do dialing for dollars, bothering all of us admins whining for IPv4 they can 'broker' for us. > >If you feel that the policy does not accomplish this, it would be useful >for you to propose alternative language that you believe would do so. > I just did. Ted From michael.dillon at bt.com Thu Feb 14 13:15:29 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 14 Feb 2008 18:15:29 -0000 Subject: [ppml] Random v6 discussions (was Re: Policy Proposal: IPv4Transfer Policy Proposal) In-Reply-To: <20080214171942.GN8368@shell01.cell.sv2.tellme.com> References: <47B30DC8.5020907@internap.com><70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail><47B338A9.4010500@internap.com><70DE64CEFD6E9A4EB7FAF3A0631410660104F348@mail> <20080214171942.GN8368@shell01.cell.sv2.tellme.com> Message-ID: > It stuns me that there are serious networking folks who don't > think we'll run out of v4 addresses. But this is now > waaaaaay off the topic of policy, which is the purpose of this list. Not at all. This is bang on topic for the policy list. Clearly the current methods used for analyzing the data which show IPv4 addresses running out at the IANA level in 2 to 3 years are not sufficient. What other kinds of analysis do we need to do? Perhaps just looking for a runout date is not sufficient but we need some other measures as well. And many people have claimed that there will be more free IPv4 addresses as people dual-stack their networks. But this doesn't make sense. Has anyone had the opportunity to analyse an ISPs IPv6 deployment plans to figure when in the deployment process they will begin to have an increase of free IPv4 addresses, and how will that figure grow (or not grow) over what period of time? This is definitely an area where we should consider soliciting the help of the academic community to do the kind of studies that will provide us hard facts to base our policies on. In fact, it would be worthwhile for ARIN to increase its communication with the various federal/national governments in the region to see if they can provide some support. Perhaps the FCC or CRTC will mandate ISPs to report the data needed so that researchers can get access to analyze it. --Michael Dillon From owen at delong.com Thu Feb 14 13:18:00 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Feb 2008 10:18:00 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: Message-ID: <09D0258A-BC87-4375-9EC9-D5AC107589BE@delong.com> On Feb 14, 2008, at 10:02 AM, Ted Mittelstaedt wrote: > > >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> Sent: Wednesday, February 13, 2008 1:57 PM >> To: Ted Mittelstaedt >> Cc: David Conrad; Public Policy Mailing List >> Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal >> >> >> Given that the policy under discussion specifically precludes such >> transfers until IANA is no longer able to respond to requests, thus >> eliminating the standard request-reallocate in short order, I am not >> sure I agree with your reasoning. >> > > This is an ARIN not an IANA policy. > > You mean "when ARIN is no longer able to respond..." > Yes, this is an ARIN policy. However, if you read the ARIN policy text, the policy is implemented upon IANA free pool exhaustion, so, the policy takes effect when IANA s not able to respond to requests from RIRs. > ARIN will always be able to respond, because there will be IPv4 > that will always be vacated. There will always be ISP's and > networks that go out of business and stop paying their registration > fees, thus that space will become available. > > The problem isn't that ARIN cannot respond with IPv4 allocation > requests. The problem is that they cannot repond as fast as you > want 'em. > This entire line of reasoning only makes sense if you follow the above incorrect restatement of my meaning to it's absurd conclusion. > Unless, of course, this policy goes into effect. Because then, > nobody will return IPv4 to ARIN. They will just sell it to someone > else. Over time the deep-pockets own everything. > Current return statistics don't seem to support your position here. I'm not convinced this policy is the right thing to do for a number of reasons. However, this reasoning doesn't really have much to do with my reasons for questioning the policy. > You know, we already have that kind of stuff going on in other > industries. I for one am just a bit sick of the "he who has the > gold makes the rules" garbage. Can we just please NOT have to > drag the Internet down this path? > I'll leave the discussions of the benefits/evils of capitalism/ socialism/ communism and comparative economics to others who have more expertise and interest. I believe most, if not all of the economies in the ARIN service region are based on capitalism, so, some amount of that is hard to avoid. >> Additionally, the policy specifically requires that a transferee meet >> all of the same requirements that are necessary in order to qualify >> under the request-reallocate system prior to receiving a transfered >> block, so, this policy doesn't really create a "special" class in >> that >> regard. >> > > If that is all you really want, then a "reservation" system can > be created that would require the IP block owner to return the blocks > to ARIN then ARIN reallocate them. No money need change hands > between the donor and recipient. The donor pays less fees so they > financially benefit. > I just don't see where you're getting this idea. Many (if not most) of the likely "donors" are end-user assignments as far as ARIN fees go, if they are paying fees at all. As such, they pay $100 per year now, and, they would pay $100 per ear afterwards. > If your dead-set that the only way donors will give up IPv4 is by > paying them over and above the financial gain for not having to pay > fees on IPv4, then post-IPv4 runout, ARIN can start "bonusing" out > donors who return IPv4 - and raise allocation fees for IPv4 to pay > for the bonuses. In that way it is fair for everyone, and the burden > is not on the requestor to find an org that has spare IPv4. > I would encourage you to draft alternative policy language that would support such a system. I'm not necessarily opposed to that method, but, I'm not sure how to go about implementing such a thing in policy. >> >> If you feel that the policy does not accomplish this, it would be >> useful >> for you to propose alternative language that you believe would do so. >> > > I just did. > Uh, you presented a summary of what could become an alternative proposal, but, as I stated above, you have a ways to go before you reach alternative policy language. Owen From tedm at ipinc.net Thu Feb 14 13:36:51 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 14 Feb 2008 10:36:51 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A0631410660104F348@mail> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Kevin Kargel >Sent: Thursday, February 14, 2008 6:50 AM >To: ppml at arin.net >Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal > > > Scott, > The best plan I see now for residential ISP's is to start >putting new customers on IPv6 for local connectivity, Which will be very difficult. The vast majority of residential customers these days are cable and DSL. The IP addresses assigned out by the ISP's they are connected to are being assigned to the CPE devices which are plugged into the customers PeeCees or xboxes or suchlike with ethernet, or wireless. There is not, to my knowledge, a SINGLE CPE, ie: DSL modem, cable modem, Linksys/Netgear/Dlink/whatever ethernet-to-ethernet router that speaks IPv6. Other than the test firmware that was written for a Linksys I believe it was, and perhaps some Linux-replacement-firmware for a handful of wireless routers (Buffalo, etc.) there are no firmware updates for the millions of DSL and cable modems that are both DSL and NAT devices to make them IPv6. A very large number of residential users run multiple computers, both laptops on wireless or small hubs. Their ISP can, of course, easily assign them a subnet of IPv6. But, they will need a router at their site to route the IPv6 subnet. THe only way this can be done right now is for them to reconfigure their DSL modem/NAT or cable modem/NAT devices into "bridged" mode, then use a commercial Cisco device costing a minimum of $500. That's if their ISP is even handing out IPv6 subnets. And I didn't see that the experimental IPv6 firmware supported IPv6 PPPoE, either, which is how most of these ISPs are delivering services. For residential users, they are in a situation now with Windows XP and Windows Vista and MacOS X that they have machines that can speak IPv6 - behind routers that cannot, and will not unless the DSL modem vendors release firmware updates. Which will likely not happen for any CPE model that is older than 2 years. For ISP's that didn't get on to the DSL bandwagon, and are supplying dialup only, the situation is even worse. Most of those these days have outsourced their dialup to wholesale dialup port providers who are providing both the dialup modem port and the Internet connectivity as well. These ISP's don't even own their own equipment. And the few holdouts who still do are quite often running 15 year old Livingston Portmasters and other such gear that isn't IPv6 compliant. None of the wholesale national dialup providers at this time provide IPv6 connectivity for dialup ports they sell. And they likely won't either as they can see their market shrinking steadily every year - what this means is the used market is flooded with perfectly good dialup modem pools, and anyone wholesaling dialup ports today is in a contracting market, they are essentially making a living extracting the last bits of money out of a dying market. They won't be buying new gear for this when there's so much older gear that is on the secondary market. All of this is the situation in the US today, I would be interested in what goes on in other countries, but I would guess dialup is starting to die off there as well. To my view, it's pretty clear IPv6 conversion must commence from the core and spread out. Ted Mittelstaedt From bicknell at ufp.org Thu Feb 14 13:46:03 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 14 Feb 2008 13:46:03 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: <70DE64CEFD6E9A4EB7FAF3A0631410660104F348@mail> Message-ID: <20080214184603.GA26086@ussenterprise.ufp.org> In a message written on Thu, Feb 14, 2008 at 10:36:51AM -0800, Ted Mittelstaedt wrote: > There is not, to my knowledge, a SINGLE CPE, ie: DSL modem, cable modem, > Linksys/Netgear/Dlink/whatever ethernet-to-ethernet router that speaks > IPv6. Other than the test firmware that was written for a Linksys I Apple Airport Extreme. IPv6 routing, 6to4 tunneling and manual tunnels out of the box. > A very large number of residential users run multiple computers, both > laptops on wireless or small hubs. Their ISP can, of course, easily > assign them a subnet of IPv6. But, they will need a router at their > site to route the IPv6 subnet. Perhaps if your cable modem, often provided by the ISP, dropped off a /64 there would be a lot of users who had no need for a NAT/Router. WiFi boxes may not be manageable over IPv6, but can broadcast an IPv6 network at layer 2 in this configuration. The primary reason people have "routers" today is they get a single IP, so they need a NAT gatway to connect multiple computers. Providing a /64 makes that unnecessary, which largely means support in those boxes is a non-issue. Imagine that, removing a box from the network, reducing cost, complexity, and configuration. -- 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 mksmith at adhost.com Thu Feb 14 14:09:53 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 14 Feb 2008 11:09:53 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <20080214184603.GA26086@ussenterprise.ufp.org> References: <70DE64CEFD6E9A4EB7FAF3A0631410660104F348@mail> <20080214184603.GA26086@ussenterprise.ufp.org> Message-ID: <17838240D9A5544AAA5FF95F8D52031603555367@ad-exh01.adhost.lan> > > A very large number of residential users run multiple computers, both > > laptops on wireless or small hubs. Their ISP can, of course, easily > > assign them a subnet of IPv6. But, they will need a router at their > > site to route the IPv6 subnet. > > Perhaps if your cable modem, often provided by the ISP, dropped off a > /64 there would be a lot of users who had no need for a NAT/Router. > WiFi boxes may not be manageable over IPv6, but can broadcast an > IPv6 network at layer 2 in this configuration. The primary reason > people have "routers" today is they get a single IP, so they need a NAT > gatway to connect multiple computers. Providing a /64 makes that > unnecessary, which largely means support in those boxes is a non-issue. > > Imagine that, removing a box from the network, reducing cost, > complexity, and configuration. > Imagine all those PC's with no broadcast-level demarcation connected over a cable system. Imagine all those open ports. Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 475 bytes Desc: not available URL: From kkargel at polartel.com Thu Feb 14 14:10:08 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 14 Feb 2008 13:10:08 -0600 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: <47B12650.2060107@internap.com><47B30DC8.5020907@internap.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> <70DE64CEFD6E9A4EB7FAF3A0631410660104F346@mail> Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410660104F352@mail> Most of the appliance type devices are not supporting IPv6 yet.. perhaps because of a lack of support services such as a functioning DNS (glue?) and lack of the aforementioned RBL support. > -----Original Message----- > From: Antonio Querubin [mailto:tony at lava.net] > Sent: Thursday, February 14, 2008 1:06 PM > To: Kevin Kargel > Subject: Re: [ppml] IPv6 getting real: was Policy Proposal: > IPv4 Transfer Policy Proposal > > On Thu, 14 Feb 2008, Kevin Kargel wrote: > > > treatise. I do find it quite interesting that end user > applications > > seem to be riding the leading edge, for example Operating > Systems and > > Email Clients are ready, while email servers and RBL's are lagging > > behind. > > Which popular email servers do you know of that aren't IPv6 > capable? (may as well shame them in public as long as we're at it) :) > > RBLs tend to be reactionary and will probably start doing > IPv6 only when the problem of IPv6 spammers becomes serious enough. > > Antonio Querubin > whois: AQ7-ARIN > From bicknell at ufp.org Thu Feb 14 14:14:35 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 14 Feb 2008 14:14:35 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <17838240D9A5544AAA5FF95F8D52031603555367@ad-exh01.adhost.lan> References: <20080214184603.GA26086@ussenterprise.ufp.org> <17838240D9A5544AAA5FF95F8D52031603555367@ad-exh01.adhost.lan> Message-ID: <20080214191435.GA28853@ussenterprise.ufp.org> In a message written on Thu, Feb 14, 2008 at 11:09:53AM -0800, Michael K. Smith - Adhost wrote: > Imagine all those PC's with no broadcast-level demarcation connected over a cable system. Imagine all those open ports. That's not what I said. I assume your cable modem would drop off a /64 (or /56 or /48) for you and only you. That is, the cable modem is the router. -- 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 kkargel at polartel.com Thu Feb 14 14:15:07 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 14 Feb 2008 13:15:07 -0600 Subject: [ppml] Random v6 discussions (was Re: Policy Proposal: IPv4 Transfer Policy Proposal) In-Reply-To: References: <47B30DC8.5020907@internap.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> <47B338A9.4010500@internap.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F348@mail> <20080214171942.GN8368@shell01.cell.sv2.tellme.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F351@mail> Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410660104F354@mail> > In our own experience, we've found that dual-stacking the > edge is more difficult than doing the core or border because > the edge equipment in the network you control is relatively > less likely to be IPv6 enabled or upgradable for a variety of reasons. > Ah, I am lucky enough to have Cisco network hardware throughout the enterprise.. perhaps that makes things easier. I realize that not everyone has budget or desire to do that. It will at the moment put the onus on our customers to use bridged modems and either a software router or perhaps one of the two two available small hardware routers that support IPv6. From iljitsch at muada.com Thu Feb 14 14:35:54 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 14 Feb 2008 20:35:54 +0100 Subject: [ppml] Random v6 discussions (was Re: Policy Proposal: IPv4 Transfer Policy Proposal) In-Reply-To: <20080214171942.GN8368@shell01.cell.sv2.tellme.com> References: <47B30DC8.5020907@internap.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> <47B338A9.4010500@internap.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F348@mail> <20080214171942.GN8368@shell01.cell.sv2.tellme.com> Message-ID: <56446763-B32C-4AE7-884B-B0F26858F7BF@muada.com> On 14 feb 2008, at 18:19, David Williamson wrote: > Much as I like the idea of "fix the edge so that we have more time to > fix the middle", I think it's going to be much more practical to fix > the middle, and dual-stack the edge until v6 is viable end-to-end on > its own. Oh, and there's no way that's going to happen without > massive > impact to the whole network, since getting the edge fixed will > definitely take longer than the remaining time before pool exhaustion, > no matter how you calculate it. So let's not waste any time... It's still almost impossible to buy a broadband modem / home router / CPE that will do IPv6, and because those almost always do NAT, it's also pretty hard to tunnel IPv6 through such a box. But that's not the only hard part. ISPs can pretty much leave old customers on IPv4 and give IPv6 to new customers. For content sites, it's different: you do v6 or you don't. Because of firewalling and less than optimal routing in some places, IPv6 can be worse than IPv4, so the way things are now, it's not a good idea for Big Content to turn on IPv6. They also don't care about the IPv4 depletion, they only need a few addresses. ISPs on the other hand use up millions. So it's likely that we'll end up in a situation where as of a certain date, a lot of new users will be IPv6-only or IPv6+not-so-good-IPv4, while existing users and content are pretty much IPv4-only. > That implies some quality time with > protocol translators...pick your favorite 4-to-6 conversion method. Within the IETF there are currently discussions about this. This is mostly in the requirements gathering stage, so if you have any, please let us know. However, being the impatient type, I co-authored a proposal for modifying the NAT-PT transition mechanism so that it doesn't have the downsides the existing way of doing that has, and it can also support IPv4-only applications: http://www.muada.com/drafts/draft-van-beijnum-v6ops-mnat-pt-00.txt (Internet-Drafts submission seems to have problems, I get a 404 from the IETF server right now, so please use the link above.) The next step after this is a way for home gateways to translate IPv6 to IPv4 to provide translated IPv4 connectivity to IPv4-only systems in a home that only has IPv6-connectivity. Any feedback is appreciated, even from those of you who don't have the time to read the full proposal. > It stuns me that there are serious networking folks who don't think > we'll run out of v4 addresses. Running out of addresses is like running out of toothpaste: there's never a point when you're actually flat out, but at some point you get tired of squeezing the tube harder and harder. From tedm at ipinc.net Thu Feb 14 14:41:20 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 14 Feb 2008 11:41:20 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <20080214184603.GA26086@ussenterprise.ufp.org> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Leo Bicknell >Sent: Thursday, February 14, 2008 10:46 AM >To: ppml at arin.net >Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal > > >In a message written on Thu, Feb 14, 2008 at 10:36:51AM -0800, Ted >Mittelstaedt wrote: >> There is not, to my knowledge, a SINGLE CPE, ie: DSL modem, cable modem, >> Linksys/Netgear/Dlink/whatever ethernet-to-ethernet router that speaks >> IPv6. Other than the test firmware that was written for a Linksys I > >Apple Airport Extreme. IPv6 routing, 6to4 tunneling and manual >tunnels out of the box. > I think the Time Capsule will be kicking the Airport's ass pretty quick now - do you know if it's also IPv6? But, what was that I said about a $500 device? Seriously, with all due respect to Apple, the marketing on the Airport is entirely focused on Macintoshes. Most PC users don't think that the Airport will work with anything other than a Mac. While this undoubtedly helps the sales of the Airport to the Mac community, it makes it a niche product along the lines of the Linux-based alternative firmware for wireless routers in terms of market penetration. I happen to use a PC running FreeBSD as my own home router on my home DSL line - it also can be an IPv6 compliant router. >> A very large number of residential users run multiple computers, both >> laptops on wireless or small hubs. Their ISP can, of course, easily >> assign them a subnet of IPv6. But, they will need a router at their >> site to route the IPv6 subnet. > >Perhaps if your cable modem, often provided by the ISP, dropped off >a /64 there would be a lot of users who had no need for a NAT/Router. There's no reason that this couldn't happen. All you would need to do is write some stateful inspection firewall code in there, very easy to do, Cisco had this running in 8MB of flash/4MB of RAM in a 2500 almost a decade ago. >WiFi boxes may not be manageable over IPv6, but can broadcast an >IPv6 network at layer 2 in this configuration. The primary reason >people have "routers" today is they get a single IP, so they need >a NAT gatway to connect multiple computers. Providing a /64 makes >that unnecessary, which largely means support in those boxes is a >non-issue. > >Imagine that, removing a box from the network, reducing cost, >complexity, and configuration. > I'd love it. The problem is you got all these CPE makers out there like Broadexnt, Westell, Efficient Networks, ActionTec, and so on, who under OEM contracts with telcos like Southwestern Bell, and cable companies, 6 years ago created DSL and Cable modems that had NAT code - with the principle purpose of preventing the Telco ISP's networks from melting down under attacks from infected Windows boxes. Those customers all paid their ounce of flesh 3-4 years ago for those devices, and those CPE makers made their profits, disbursed their bonuses and such to their employees, and their dividends to their shareholders, and ended those product lines, or came out with new models. Your now asking them to go back into in some case 8 year old microcode and rewrite it. How exactly do they make a profit doing this? They don't. They will be happy to sell you brand NEW devices that will support IPv6 (I would assume) but they aren't wanting to undercut their new product by brushing up perfectly good, working, -old- product so it's compliant with a new IP numbering system. Cisco and Juniper can pull that with commercial gear because so much of it is under service contracts that continually fund that, but this is residential consumer gear and it doesen't work that way. The end users, naturally, aren't going to want to spend the money for new devices if their old ones are still working. That is why the HD-TV changeover is the way it is. I don't want to beat a dead horse but I keep returning to this analogy because it's an example of a technological upgrade done properly. ALL of the consmers get screwed over ALL at the SAME time, so there isn't any of this nonsense of upsetting the various broadcasters markets - your not for example increasing ABC's market share because NBC went to HD-TV before they did. Everyone goes to it all at the same time. Consumers have no recourse but to spend the money for converters or new TV's. The increased content is available all at the same time. This is the way the IPv4->IPv6 transition should be managed and it's a shame that it's a bunch of techs in charge of it, rather than a bunch of marketing people (like in TV-land) because the techs have no marketing sense whatsoever, and what we are going to end up with is going to be 100 times more painful than what it could be. It's like ripping off the bandage quick or slow - the IPv6 conversion is ripping it off slow, so we will have lots of years of excruciating pain to deal with. Ah well, I guess there's some small consolation - when we get tired of dealing with it at the end of the day we can go home an watch a decent movie our 40 inch HD-TV's! Ted From tedm at ipinc.net Thu Feb 14 14:50:20 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 14 Feb 2008 11:50:20 -0800 Subject: [ppml] Random v6 discussions (was Re: Policy Proposal: IPv4Transfer Policy Proposal) In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A0631410660104F354@mail> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Kevin Kargel >Sent: Thursday, February 14, 2008 11:15 AM >To: ppml at arin.net >Subject: Re: [ppml] Random v6 discussions (was Re: Policy Proposal: >IPv4Transfer Policy Proposal) > > > >> In our own experience, we've found that dual-stacking the >> edge is more difficult than doing the core or border because >> the edge equipment in the network you control is relatively >> less likely to be IPv6 enabled or upgradable for a variety of reasons. >> >Ah, I am lucky enough to have Cisco network hardware throughout the >enterprise.. perhaps that makes things easier. I realize that not >everyone has budget or desire to do that. > >It will at the moment put the onus on our customers to use bridged >modems and either a software router or perhaps one of the two two >available small hardware routers that support IPv6. Another possible option is distributing RFC1918 IPv4 to your end users and dual-numbering your mailserver and a big web proxy server on your network - just don't interconnect the RFC1918 to the Internet with a NAT. (If you have ever experienced a NAT behind a NAT, it's dog-slow) Obviously this would only be good for remotes that just do e-mail and web surfing. Ted From tedm at ipinc.net Thu Feb 14 14:51:29 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 14 Feb 2008 11:51:29 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <09D0258A-BC87-4375-9EC9-D5AC107589BE@delong.com> Message-ID: >-----Original Message----- >From: Owen DeLong [mailto:owen at delong.com] >Sent: Thursday, February 14, 2008 10:18 AM >To: Ted Mittelstaedt >Cc: David Conrad; Public Policy Mailing List >Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal > > > >I'll leave the discussions of the benefits/evils of capitalism/ >socialism/ >communism and comparative economics to others who have more >expertise and interest. > >I believe most, if not all of the economies in the ARIN service region >are based on capitalism, so, some amount of that is hard to avoid. > ARIN is a non-profit and it's charter is thus not to act in a capitalistic manner. > >I just don't see where you're getting this idea. Many (if not most) >of the >likely "donors" are end-user assignments as far as ARIN fees go, if >they are paying fees at all. As such, they pay $100 per year now, and, >they would pay $100 per ear afterwards. > Before we go putting a transfer policy in based on the idea that many of these "extra" IPv4 blocks are end-user assignments, why isn't anyone asking ARIN how many of these are actually end-user assignments? If only 2% of the IPv4 are end-user assignments, then why are we doing this? What is the point of putting in a transfer policy that benefits so few? Whatever IPv4 scavenged from them will be so small as to be meaningless. If your supporting the transfer proposal the onus is on you to get these reports from ARIN and use them to convince the rest of us the policy is needed, not throw around "likely" assumptions. >> If your dead-set that the only way donors will give up IPv4 is by >> paying them over and above the financial gain for not having to pay >> fees on IPv4, then post-IPv4 runout, ARIN can start "bonusing" out >> donors who return IPv4 - and raise allocation fees for IPv4 to pay >> for the bonuses. In that way it is fair for everyone, and the burden >> is not on the requestor to find an org that has spare IPv4. >> >I would encourage you to draft alternative policy language that would >support such a system. I'm not necessarily opposed to that method, >but, I'm not sure how to go about implementing such a thing in policy. >Uh, you presented a summary of what could become an alternative >proposal, Yes, that was the intent. Before going to the work of writing a policy change, is it not a good idea to float the trial balloon as a summary idea first? Ted From owen at delong.com Thu Feb 14 15:01:18 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Feb 2008 12:01:18 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: Message-ID: <272F5542-EBC3-4664-B9F3-DB3985D7CE0B@delong.com> On Feb 14, 2008, at 11:51 AM, Ted Mittelstaedt wrote: > > >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> Sent: Thursday, February 14, 2008 10:18 AM >> To: Ted Mittelstaedt >> Cc: David Conrad; Public Policy Mailing List >> Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal >> >> >> >> I'll leave the discussions of the benefits/evils of capitalism/ >> socialism/ >> communism and comparative economics to others who have more >> expertise and interest. >> >> I believe most, if not all of the economies in the ARIN service >> region >> are based on capitalism, so, some amount of that is hard to avoid. >> > > ARIN is a non-profit and it's charter is thus not to act in a > capitalistic manner. > And, under this policy, ARIN would not be acting in a capatilistic manner. ARIN would merely be allowing others to trade IPv4 addresses on that basis. >> >> I just don't see where you're getting this idea. Many (if not most) >> of the >> likely "donors" are end-user assignments as far as ARIN fees go, if >> they are paying fees at all. As such, they pay $100 per year now, >> and, >> they would pay $100 per ear afterwards. >> > > Before we go putting a transfer policy in based on the idea that > many of these "extra" IPv4 blocks are end-user assignments, why > isn't anyone asking ARIN how many of these are actually end-user > assignments? > > If only 2% of the IPv4 are end-user assignments, then why are > we doing this? What is the point of putting in a transfer policy that > benefits so few? Whatever IPv4 scavenged from them will be so > small as to be meaningless. > The percentage of total IPv4 is not nearly the issue so much as the percentage of likely unused IPv4 addresses. ARIN would be able to provide statistics on total IPv4, but, does not have any statistics on underutilized blocks after they have been delegated. > If your supporting the transfer proposal the onus is on you to > get these reports from ARIN and use them to convince the rest of > us the policy is needed, not throw around "likely" assumptions. > I have not taken a position on this proposal yet. I helped craft it along with my fellow AC members based on what we believed to be a good set of tradeoffs assuming the community felt such a transfer process was needed. I am not yet convinced either way on the need or not for such a process. Certainly, there are possible scenarios under which I would definitely oppose such a policy. I'm not sure about supporting such a policy. >>> If your dead-set that the only way donors will give up IPv4 is by >>> paying them over and above the financial gain for not having to pay >>> fees on IPv4, then post-IPv4 runout, ARIN can start "bonusing" out >>> donors who return IPv4 - and raise allocation fees for IPv4 to pay >>> for the bonuses. In that way it is fair for everyone, and the >>> burden >>> is not on the requestor to find an org that has spare IPv4. >>> >> I would encourage you to draft alternative policy language that would >> support such a system. I'm not necessarily opposed to that method, >> but, I'm not sure how to go about implementing such a thing in >> policy. > >> Uh, you presented a summary of what could become an alternative >> proposal, > > Yes, that was the intent. Before going to the work of writing a > policy change, is it not a good idea to float the trial balloon > as a summary idea first? > Sure. So, I encourage you to do the rest of the work of writing and submitting the proposal. Owen > Ted From dwhite at olp.net Thu Feb 14 15:04:15 2008 From: dwhite at olp.net (Dan White) Date: Thu, 14 Feb 2008 14:04:15 -0600 Subject: [ppml] Random v6 discussions (was Re: Policy Proposal: IPv4 Transfer Policy Proposal) In-Reply-To: <56446763-B32C-4AE7-884B-B0F26858F7BF@muada.com> References: <47B30DC8.5020907@internap.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F343@mail> <47B338A9.4010500@internap.com> <70DE64CEFD6E9A4EB7FAF3A0631410660104F348@mail> <20080214171942.GN8368@shell01.cell.sv2.tellme.com> <56446763-B32C-4AE7-884B-B0F26858F7BF@muada.com> Message-ID: <47B49EBF.3000305@olp.net> Iljitsch van Beijnum wrote: > So let's not waste any time... It's still almost impossible to buy a > broadband modem / home router / CPE that will do IPv6, and because > those almost always do NAT, it's also pretty hard to tunnel IPv6 > through such a box. There are creative ways around limitations like that. After continually asking our BRAS and modem vendors for IPv6 support, for years and without any coherent response, I've had to find workarounds. If you have a modem with good bridge group/VLAN support, you can create an additional PVC upstream just for IPv6, and attach that PVC to the WAN bridge group, in the case of a bridged configuration, or the LAN bridge group, in the case of a layer-3 router/NAT configuration. To put that another way, if your IPv4 modem is NATd, you could potentially (depending on your modem) create a separate virtual pipe upstream, and backdoor it into the customer's LAN. I certainly understand the wide gaping security hole that creates, but it may be something that a customer may be willing to accept if I can present them the option. Also, I'm a big fan of layer-two separation, so each IPv6 PVC goes back to a Linux box via separate VLANs, which in itself provides some security robustness (where high-jacked DHCPv6 requests aren't of such a big concern). > But that's not the only hard part. ISPs can pretty much leave old > customers on IPv4 and give IPv6 to new customers. For content sites, > it's different: you do v6 or you don't. Because of firewalling and > less than optimal routing in some places, IPv6 can be worse than IPv4, > so the way things are now, it's not a good idea for Big Content to > turn on IPv6. They also don't care about the IPv4 depletion, they only > need a few addresses. ISPs on the other hand use up millions. So it's > likely that we'll end up in a situation where as of a certain date, a > lot of new users will be IPv6-only or IPv6+not-so-good-IPv4, while > existing users and content are pretty much IPv4-only. I don't look at this as a scenario as having to dictate to my customers (as a service provider) which class of addressing they should use. I'll provide it to them today (or in the near future), and let them decide if they want to try it or not as an opt-in feature. If we wait until IPv4 runs out, or we're forced to do so for other reasons, then we're in a situation where we're making the decisions for customers, rather than customers making their own decisions about the technology they would wish to use. It may be that at some point, we'll have to charge more for a customer who wishes to have a publicly routable IPv4 address. In all honesty, I don't expect a lot of uptake in the near term, but by providing an optional IPv6 network connection to users, we give them time to learn it at their own pace, rather than ripping IPv4 out from under them. Also, it gives us time, as a service provider, to ignore hard time frames and to gain experience with it ourselves. - Dan White From bicknell at ufp.org Thu Feb 14 15:43:17 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 14 Feb 2008 15:43:17 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: <20080214184603.GA26086@ussenterprise.ufp.org> Message-ID: <20080214204317.GA33890@ussenterprise.ufp.org> In a message written on Thu, Feb 14, 2008 at 11:41:20AM -0800, Ted Mittelstaedt wrote: > I'd love it. The problem is you got all these CPE makers out > there like Broadexnt, Westell, Efficient Networks, ActionTec, and [snip] > > Those customers all paid their ounce of flesh 3-4 years ago for > those devices, and those CPE makers made their profits, disbursed > their bonuses and such to their employees, and their dividends to > their shareholders, and ended those product lines, or came out > with new models. > > Your now asking them to go back into in some case 8 year old microcode > and rewrite it. How exactly do they make a profit doing this? Nope. Those boxes will be replaced. Not because of IPv6. Cable companies are already replacing DOCSIS 1.0 devices in some areas with 2.0 devices for reasons that have nothing to do with IPv6. Some of these same drivers will require DOCSYS 3.0 devices in the very near future. That's the problem with IPv6 in a vacuum. Yes, replacing a cable modem just to get IPv6 is costly. But they are also replacing them to get more bandwidth, to get better control over the bandwidth that is there, to get better management from the device. > The end users, naturally, aren't going to want to spend the money > for new devices if their old ones are still working. If you told most end users they could get 8Mbps down for the same price as 6Mbps down; but they have to pay $50 one time for the modem they would jump at it. Given DOCSYS 3.0's better use of cable spectrum they cable companies well be able to do just that. IPv6 would come along for free. It seems to me a lot of people like to forget that the IPv6 transition is already underway. Cable companies put IPv6 in DOCSYS 3.0. Cisco and Juniper have their plans. Forward thinking companies with higher margins (like Apple) already have it in their devices. And you know what, some things will never be upgraded. My old HP printer at home, which will likely never speak IPv6. I only care if I can reach it from the local subnet, it will not hold back IPv6 deployment in any way shape or form. It may hold back getting rid of dual stack, but that's an argument for 5-10 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 Fred.Wettling at Bechtel.com Thu Feb 14 15:44:34 2008 From: Fred.Wettling at Bechtel.com (Wettling, Fred) Date: Thu, 14 Feb 2008 15:44:34 -0500 Subject: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." In-Reply-To: References: <20080209133943.GA54068@ussenterprise.ufp.org><20080209191140.GA18897@vacation.karoshi.com.> <47AE0648.6090108@bogus.com> Message-ID: Perspective from a very large global engineering company... Over 95% (thousands) of our computers around the world are running dual-stack today at our offices and projects. The current limitations to an IPv6-only environment are things like legacy operating systems and external sites and services that do not support IPv6 yet. We'll be running dual-stack for the next few years, with an increasing dependence on available IPv6 transport for new capabilities such as P2P. Major implementation pains in the last three years of IPv6 implementation is lack of product features (i.e. no DHCPv6 support in Windows XP or Windows Server 2003) and lack of native IPv6 services to the premise from several major carriers. These shortcomings have delayed some of our planned activities or have workarounds we would have preferred not to implement. Fred Wettling -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of John Curran Sent: Saturday, February 09, 2008 3:20 PM To: Joel Jaeggli Cc: Public Policy Mailing List Subject: Re: [ppml] "Who's afraid of IPv4 address depletion? Apparently no one." At 12:00 PM -0800 2/9/08, Joel Jaeggli wrote: >John Curran wrote: > >Is it safe to presume that these are architectures proposed for new customer connections? It is hard to imagine an existing Internet connected (via IPv4) site having any reason to evolve its internal network into an IPv6 island intentionally in the near future... > >Actually if you recover the v4 address currently consumed by your infrastructure you can continue to provide them to your customers which may by a substantial incentive to produce a network which is subtantially ipv6 only. Interesting; this presumes that that one's willing to depart from 'ships in the night' IPv4/IPv6 backbone approach, and "transparently" alter the transport of your existing production IPv4 customer traffic... I'm not saying it won't happen (as depletion will eventually force some very hard decisions) but it's not the traditional risk-adverse approach used by the carriers, who loathe to do anything that could result in even a small percentage of their business customers complaining/switching/leaving. Of course, it's opportunities like that which nimble/brave firms use to gain advantage (and not dissimilar to the recent switch that some carriers did with production POTS trunks to VoIP for cost advantages...), and if there's sufficient IPv4 address space to be to recovered, it could be one possible route which allows IPv4 growth while also making progress on transition. From owen at delong.com Thu Feb 14 23:50:00 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Feb 2008 20:50:00 -0800 Subject: [ppml] IPv4 Resource Distribution After IANA Free Pool Exhaustion -- ARIN AC BoF Message-ID: Members of the ARIN AC will be present to discuss IPv4 after IANA Free Pool Exhaustion and get input from the community on how they feel this should be handled. Members of the community attending the NANOG conference are encouraged to attend this session and give your input. The session will be from 4:00 to 5:30 on Tuesday, February 19th and will be in the Crystal Room on Level B. We will be discussing the recently posted transfer policy proposal and other ideas around the IPv4 free-pool exhaustion process(es). Thanks, Owen DeLong ARIN AC From sleibrand at internap.com Fri Feb 15 10:41:22 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 15 Feb 2008 10:41:22 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: Message-ID: <47B5B2A2.2080305@internap.com> Ted Mittelstaedt wrote: > That is why the HD-TV changeover is the way it is. I don't want to > beat a dead horse but I keep returning to this analogy because it's > an example of a technological upgrade done properly. ALL of the > consmers get screwed over ALL at the SAME time, so there isn't any > of this nonsense of upsetting the various broadcasters markets - > your not for example increasing ABC's market share because NBC went > to HD-TV before they did. Everyone goes to it all at the same time. > Consumers have no recourse but to spend the money for converters or > new TV's. The increased content is available all at the same time. Don't most HDTVs get hooked up to Cable or Satellite networks, rather than broadcast? And isn't the flag-day required broadcast conversion just to *digital* broadcasting, not to *HD*? I don't own a TV (analog or digital, SD or HD) myself, but I get the impression that the switch to HD is actually being driven by demand from Cable and Satellite users who want to watch the HD programming they provide. If you really think our government could do a better job getting us converted to IPv6 than the industry can do on its own, feel free to write your congressperson. But ARIN is not a government, and we have to deal with the reality of the situation as it confronts us. That means continuing to make IPv4 addresses available as long as they're needed, and AFAICT a transfer policy is the only proposal on the table that can accomplish that. -Scott From jradel at vantage.com Fri Feb 15 12:18:35 2008 From: jradel at vantage.com (Jon Radel) Date: Fri, 15 Feb 2008 12:18:35 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B5B2A2.2080305@internap.com> References: <47B5B2A2.2080305@internap.com> Message-ID: <47B5C96B.5080009@vantage.com> Scott Leibrand wrote: > Ted Mittelstaedt wrote: > > >> That is why the HD-TV changeover is the way it is. I don't want to >> beat a dead horse but I keep returning to this analogy because it's >> an example of a technological upgrade done properly. ALL of the >> consmers get screwed over ALL at the SAME time, so there isn't any >> of this nonsense of upsetting the various broadcasters markets - >> your not for example increasing ABC's market share because NBC went >> to HD-TV before they did. Everyone goes to it all at the same time. >> Consumers have no recourse but to spend the money for converters or >> new TV's. The increased content is available all at the same time. >> > > > Don't most HDTVs get hooked up to Cable or Satellite networks, rather > than broadcast? And isn't the flag-day required broadcast conversion > just to *digital* broadcasting, not to *HD*? I don't own a TV (analog > or digital, SD or HD) myself, but I get the impression that the switch > to HD is actually being driven by demand from Cable and Satellite users > who want to watch the HD programming they provide. > I suspect that cable and satellite providers who want an excuse to charge yet another premium charge have a role too..... That said, while there are certainly admirable aspects to the management of the conversion from analog to digital broadcast, dissemination of correct, succinct, and useful information on what is really going on is weak and not something that I'd advocate emulating. I expect loud squealing by owners of fancy HD TVs (or more precisely, HDTV Monitors instead of HDTVs) who bought them early enough to get only an analog tuner to grow to deafening volumes just any day now. Or maybe not. Are 99.9% of them hooked up to cable boxes which act as converters? I certainly don't know, not that that matters. What does matter is that most of the people in industry, at least those who interface with the public, either don't know what is going on and/or are willfully misleading people. See stories like http://www.baltimoresun.com/business/bal-tv0213,0,7189012.story where 4 out of 5 clerks selling TVs were giving out incorrect information. Out of curiosity, a couple of weeks ago I asked somebody who works customer service in one of my local cable provider's storefronts how long I'd be getting analog signal from my cable company. I got the impression that he didn't even understand the question. (I believe the FCC mandates that cable providers continue providing core channels in analog until 2012--oops, no, actually that impression I got from another sloppy newspaper article, what the FCC actually says is subtly, but critically, different. See http://www.dtv.gov/ for more.) And, yes, Scott, the February 17, 2009 flag day is when over-the-air analog broadcasts stop and, presumably, any TV broadcast station which wishes to remain in business has long since started broadcasting a digital signal. No, Ted, not everyone *started* or will start HD broadcast at the same time. Of course, we've had issues ourselves. I suspect, on the basis of no hard evidence at all, that one of the reasons we have significant pockets of belief that IPv4 addresses will not run out soon enough to worry about yet, is that we already did a cycle of "the sky is falling" / oh, NAT and CIDR will allow us to shuffle things / never mind, the duct tape and chewing gum are holding out, everybody get back to making money. I bet lots of people are waiting for somebody very clever to invent bailing wire, when they bother thinking about IP addresses at all. --Jon Radel From Lee at Dilkie.com Fri Feb 15 12:41:00 2008 From: Lee at Dilkie.com (Lee Dilkie) Date: Fri, 15 Feb 2008 12:41:00 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: Message-ID: <47B5CEAC.3070908@Dilkie.com> Ted Mittelstaedt wrote: > That is why the HD-TV changeover is the way it is. I don't want to > beat a dead horse but I keep returning to this analogy because it's > an example of a technological upgrade done properly. ALL of the > consmers get screwed over ALL at the SAME time, so there isn't any > of this nonsense of upsetting the various broadcasters markets - > your not for example increasing ABC's market share because NBC went > to HD-TV before they did. Everyone goes to it all at the same time. > Consumers have no recourse but to spend the money for converters or > new TV's. The increased content is available all at the same time. > > > It's an interesting analogy but not a very good fit. First. The US government is subsidizing some of the cost for consumers to get converter boxes, to the tune of 1.4 billon dollars (that's the payout, I'm sure program admin costs will add to that) (see http://www.wskg.com/analog_shutoff.htm) I don't think I see anyone standing up and offering that kind of money here. Second. The analogy is weak. All the content producers had nothing to do, they still produce content the same regardless of the transmission media. Those shows using videotape don't need to change, nor do films. For our conversion, s/w applications need to be re-written to handle the change. Some of these applications are at the edge of the network, firewalls, routers, for example. Some of these applications are embedded in computers, email, web, games, business productivity, client-server, sharing, the list is very long. All of these will need to be changed before they can work on IPv6. This is a considerably more difficult and disruptive than simply switching over one segment of the transport to a new format. A better analogy would be this. Imagine the government mandated the end of 70mm 24 fps film next year. From then on, all that can be shown in movie theaters would be 130mm 30 fps film. Oh, and there would exist no magic converter box to convert movies to the new format(*)... Then you're asking for every studio to change out all their film equipment, along with the theaters. And old films would have to be re-shot in the new format... This would be considerably more disruptive. (*) - regarding converting ipv4 to ipv6. I have serious doubts about the scalability of such proposals. I also wonder how many ALGs will have to be developed to handle all the protocols that carry ip addresses within. I believe that dual-stack is the best forward path and someday in the future we can start deploying IPv6-only applications. But you'll need a decent working dual-stack penetration to justify a business case and before that happens, ISPs need to offer IPv6, home routers need to support it, and last and most important, the *killer* IPv6 application needs to be invented. -lee From rdavis at nal.usda.gov Fri Feb 15 13:16:50 2008 From: rdavis at nal.usda.gov (Davis, Bob) Date: Fri, 15 Feb 2008 13:16:50 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B5B2A2.2080305@internap.com> References: <47B5B2A2.2080305@internap.com> Message-ID: HD-TV over the air does provide higher quality (no ghost images) and higher definition TV image (I get 1080i on some channels). --- Bob -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Scott Leibrand Sent: Friday, February 15, 2008 10:41 AM To: Ted Mittelstaedt Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal Ted Mittelstaedt wrote: > That is why the HD-TV changeover is the way it is. I don't want to > beat a dead horse but I keep returning to this analogy because it's > an example of a technological upgrade done properly. ALL of the > consmers get screwed over ALL at the SAME time, so there isn't any > of this nonsense of upsetting the various broadcasters markets - > your not for example increasing ABC's market share because NBC went > to HD-TV before they did. Everyone goes to it all at the same time. > Consumers have no recourse but to spend the money for converters or > new TV's. The increased content is available all at the same time. Don't most HDTVs get hooked up to Cable or Satellite networks, rather than broadcast? And isn't the flag-day required broadcast conversion just to *digital* broadcasting, not to *HD*? I don't own a TV (analog or digital, SD or HD) myself, but I get the impression that the switch to HD is actually being driven by demand from Cable and Satellite users who want to watch the HD programming they provide. If you really think our government could do a better job getting us converted to IPv6 than the industry can do on its own, feel free to write your congressperson. But ARIN is not a government, and we have to deal with the reality of the situation as it confronts us. That means continuing to make IPv4 addresses available as long as they're needed, and AFAICT a transfer policy is the only proposal on the table that can accomplish that. -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 kozam at mlksoft.com Fri Feb 15 23:11:28 2008 From: kozam at mlksoft.com (Marc L. Kozam) Date: Fri, 15 Feb 2008 23:11:28 -0500 Subject: [ppml] IPv6 getting real: was Policy Proposal:IPv4TransferPolicy Proposal References: <70DE64CEFD6E9A4EB7FAF3A0631410660104F34F@mail> Message-ID: <007601c87052$015de8e0$49c7f9c7@mlksoft.com> > Any routers and switches made by Cisco with anything close to current > IOS or CatOS support IPv6 with dual stack and translation. The 857 doesn't support IPv6, although it is an otherwise excellent high end CPE device. There is probably no technical reason for this since the closely related 877 does. Perhaps Cisco could comment on why IPv6 isn't a "core" feature. From oberman at es.net Sat Feb 16 01:16:59 2008 From: oberman at es.net (Kevin Oberman) Date: Fri, 15 Feb 2008 22:16:59 -0800 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 TransferPolicy Proposal In-Reply-To: Your message of "Thu, 14 Feb 2008 14:49:10 GMT." Message-ID: <20080216061659.0BEEF4500F@ptavv.es.net> > Date: Thu, 14 Feb 2008 14:49:10 -0000 > From: > Sender: ppml-bounces at arin.net > > > > As I stated earlier, the biggest drawback up here in the > > boonies is that none of my upstream providers are offering > > IPv6. The day after I have > > IPv6 upstream available I will be routing, in some shape or fashion. > > This is a widely held position which suggests that IPv6 will > mainly be deployed from the network core outwards to the edges. > This means that the largest ISPs and other core service providers > have to be first. When I say "core service providers" I mean things > like DNS providers (finally IPv6 glue records are appearing in root > nameservers) and RIRs like ARIN. > > I don't consider ARIN conference attendees to be core service > providers which is why I consider the shutting down of IPv4 > service to be little more than a stunt. ARIN plays the role of > ISP during a conference and it is ARIN which should be adapting > their services not the attendees. If ARIN cannot offer an Internet > service that just plain works, regardless of whether a laptop has > IPv4 or IPv6 or both configured, then who can? Where will we learn > to provide such a service? The only thing that comes from this > stunt, other than some disruption of the meeting, is that a few > people will get their laptops configured to run with both IPv4 > and IPv6, but this does NOTHING to further the work that needs > to be done. > > Of course today the answer probably is that nobody can. But if we > don't begin to make the effort, however imperfect, we will not > get through this transition without a lot of pain. > > In the early days of the Internet, a lot of things did not work > properly. But people repeatedly came together at meetings like > Interop to try and make things work, take notes on problem areas, > and go back home to fix what was broken. Eventually, this paid off. > IPv6 is no different and will not just fall from the sky, fully > formed and perfect, wrapped up in a nice turquoise box with a > vendor's label on the side. Sorry to be so late into this discussion. The flu has put me a bit behind. Like Randy and a VERY few others, I have been involved in engineering a production quality native IPv6 for some time. Unlike the commercial world, the research and educational networks of the world mostly provide full IPv6 capability. Some of us have been providing production IPv6 for over half a decade. The fact that IPv6 is available to most users at many major universities in the US, Canada, and Europe should mean a fair amount of traffic. After all, it's in the core. You would think college students would be trading MP3s or movies or something. (I've heard many rumors that they have been known to do so over IPv4.) Is there traffic? Not that I have seen. Is there demand? Not that I have seen. Is there interest? At least a bit more than I typically see in the commercial Internet, but not a whole lot. Every major router vendor offers "full" IPv6 support. It's just that the definition of "full" is a bit fuzzy. It often is synonymous with "half-baked". IPv6 often lacks many features we take for granted in IPv4. Want to see how many IPv4 bytes are accepted from a peer? No problem. I simple SNMP query and you have the data. But for IPv6 on at least two major router vendors, no way. I can only count packets with no way to guess the average packet size or byte count. Is this "full" support? I guess. Lots of management and security gear claims IPv6 capabilities, but it's often more of a check-box things that was never really debugged or made remotely practical. A product that can process IPv4 traffic at 4 Mpps might only process IPv6 at 400 Kpps. This works fine today because of the lack of IPv6 traffic. You may not be too happy if we start getting "real" IPv6 loads. (And there are some significant exceptions.) How do you feel about not having fully functional security and management tools? You think the bad guys don't know what IPv6 is? How well vetted is the security of the IPv6 code in anything? Leaves me VERY nervous. I have every confidence that there are a bunch of ugly, gaping security holes in IPv6 code that are just waiting for the bad guys to find them. And my final point, the DFZ is huge and continuing to grow at a steady pace that threatens to outstrip hardware capacity. I should remind yo that IPv6 addresses are 4 times as long and they will take more space in the FIB than IPv4 addresses (2-4 times, oddly). If services all start to move to dual stack, what happens to the FIB? hardware is near capacity, so lets tripple the TCAM requirement. Sounds good to me. Would people stop thinking the the "simple" adoption of IPv6 is going to fix everything all by itself? It is likely to break a LOT of stuff in the process. In a business this is often NOT considered a way to succeed. (I'm resisting the obvious Microsoft comment.) The world will not end. The Internet will not die, but it may not be a lot of fun, either. It sure won't be easy. -- 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 kc at caida.org Sat Feb 16 18:27:44 2008 From: kc at caida.org (k claffy) Date: Sat, 16 Feb 2008 15:27:44 -0800 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 TransferPolicy Proposal In-Reply-To: <20080216061659.0BEEF4500F@ptavv.es.net> References: <20080216061659.0BEEF4500F@ptavv.es.net> Message-ID: <20080216232744.GA43669@rommie.caida.org> On Fri, Feb 15, 2008 at 10:16:59PM -0800, Kevin Oberman wrote: Unlike the commercial world, the research and educational networks of the world mostly provide full IPv6 capability. Some of us have been providing production IPv6 for over half a decade. kevin, this definition of "full" is as fuzzy as the vendors'. it took us (an network research group at SDSC/UCSD) 2 years to get IPv6 connectivity to our prefix after we first requested it. we hit 6 or 7 obstacles, including address space suballocation bureaucracy (weeks back and forth getting clarification on what kind of ipv6 addresses we should have, then months with ucsd trying to get a suballocation) to cisco router working ipv6 image acquisition (months, several re-tries) to sysadmin learning curves ("ugh, what do we do about autoconf") to fires in san diego burning down the house of the only SDSC network admin who had the magic combination of enable access and ipv6 clue on the magic router between us and v6 transit to Internet2 (months.). all along we had the issue of what research grant should pay for the additional work, since NSF certainly isn't interested in funding infrastructure, and we had to take time away from funded research projects to work on it. my hopes for having the academics blaze the ipv6 trail were tempered by the reality of trying it ourselves. The fact that IPv6 is available to most users at many major universities in the US, Canada, and Europe should mean a fair amount of traffic. there may be some optimistic confluence of 'universities' and 'users' here. we have ipv6 to our prefix now, but we had strong incentive because we want to do ipv6 topology mapping. i can't imagine why academics in general 'should' use ipv6. academics in general have no idea what ipv6 is, nor reason to learn. After all, it's in the core. You would think college students would be trading MP3s or movies or something. (I've heard many rumors that they have been known to do so over IPv4.) you lost me there. if they're trading music and movies over ipv4, why should they use ipv6? Is there traffic? Not that I have seen. Is there demand? Not that I have seen. Is there interest? At least a bit more than I typically see in the commercial Internet, but not a whole lot. well, i'm not sure how you'd see it since the Juniper routers that form the core of Internet2's backbone, while v6-capable, are not v6-netflow-capable. the flow export on those boxes doesn't support v6, and there has been no other attempt to characterize IPv6 traffic (tunneled or native) on I2. (see slide 14 of joe's talk http://www.uoregon.edu/~joe/missing-half/ ) so in 2008 not only is there no evidence that U.S. academics are using IPv6 applications on their backbone, there is also currently no means to acquire evidence. no trailblazing here. and if I2 only had enough resources for tilting at one windmill this decade: DNSSEC or IPv6, which should they pursue? Every major router vendor offers "full" IPv6 support. It's just that the definition of "full" is a bit fuzzy. It often is synonymous with "half-baked". i'm still missing the leap of logic that connects 'half-baked' to the expectation that academic networking staff on perpetually tight budgets and already loaded down with more critical networking issues than they can handle should be investing in IPv6. i'm not saying they shouldn't, but noone has made the case. the R&E community will need exactly the same two things that the rest of the world will need to support ipv6: incentive and capital. k From michael at rancid.berkeley.edu Sat Feb 16 19:26:32 2008 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Sat, 16 Feb 2008 16:26:32 -0800 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 TransferPolicy Proposal In-Reply-To: <20080216232744.GA43669@rommie.caida.org> References: <20080216061659.0BEEF4500F@ptavv.es.net> <20080216232744.GA43669@rommie.caida.org> Message-ID: <47B77F38.9070208@rancid.berkeley.edu> k claffy wrote: > After all, it's in the core. You would think college students > would be trading MP3s or movies or something. (I've heard many rumors > that they have been known to do so over IPv4.) > > you lost me there. if they're trading music and movies > over ipv4, why should they use ipv6? They will only start using IPv6 when they realize that the DMCA 'enforcers' out there have no visibility in IPv6 and that they can share stuff with impunity. (This may already be happening in tunnels.) But that brings us back to the point. Many EDUs who have v6 in their core, and even in administrative and research nets, have not enabled it on their resnets, mainly because there is so much management glue that allows for bandwidth management, auditing (so the resnet admins know who to contact if/when those DMCA notices come in), making sure only authorized users are using the resnet, etc. That management glue currently only understands IPv4. The fear is that if an EDU enables IPv6 on a reshall network, it will be the wild, wild west all over again. It's interesting to note that since EDUs *are* ISPs with respect to their resnets, I can certainly understand why commercial residential SPs are not fully v6ified, and why we'll see v6 in the core first. michael From kc at caida.org Sun Feb 17 14:14:47 2008 From: kc at caida.org (k claffy) Date: Sun, 17 Feb 2008 11:14:47 -0800 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 TransferPolicy Proposal In-Reply-To: <47B77F38.9070208@rancid.berkeley.edu> References: <20080216061659.0BEEF4500F@ptavv.es.net> <20080216232744.GA43669@rommie.caida.org> <47B77F38.9070208@rancid.berkeley.edu> Message-ID: <20080217191447.GA96953@rommie.caida.org> On Sat, Feb 16, 2008 at 04:26:32PM -0800, Michael Sinatra wrote: k claffy wrote: > After all, it's in the core. You would think college students > would be trading MP3s or movies or something. (I've heard many rumors > that they have been known to do so over IPv4.) > >you lost me there. if they're trading music and movies >over ipv4, why should they use ipv6? They will only start using IPv6 when they realize that the DMCA 'enforcers' out there have no visibility in IPv6 and that they can share stuff with impunity. (This may already be happening in tunnels.) i'm not sure which implication of this prediction worries me most: - the idea that file sharers who do not want to be detected should use a protocol that noone else is using - the assumption that hollywood doesn't have the political capital to 'detect unlawful use of ipv6' using our tax dollars - the suggestion that the 'killer app' (sic!) for ipv6 is illegal activity. But that brings us back to the point. Many EDUs who have v6 in their core, and even in administrative and research nets, have not enabled it on their resnets, mainly because there is so much management glue that allows for bandwidth management, auditing (so the resnet admins know who to contact if/when those DMCA notices come in), making sure only authorized users are using the resnet, etc. That management glue currently only understands IPv4. The fear is that if an EDU enables IPv6 on a reshall network, it will be the wild, wild west all over again. except without the romantic idealism that we were changing the world (incentive), the relatively immediate feedback that we /were/ changing the world ("mom has email!"), the peace-of-mind that comes with having no installed base to irritiate (much less a paying installed base), and the massive government investment that made all the R&E network design, architecture, construction, operation, and upgrades possible (capital). instead of all those advantages, we have at least a dozen persistent problems with the current Internet that IPv6 will do nothing to solve and in some cases will exacerbate. besides that i guess i can see the similarity to the wild west, in terms of horse-drawn carriages kicking up dust and stuff. It's interesting to note that since EDUs *are* ISPs with respect to their resnets, I can certainly understand why commercial residential SPs are not fully v6ified, and why we'll see v6 in the core first. well, the difference between the edge and the core is going away with consolidation ("so we've got that going for us"), but i missed the part where the core had incentive to throw capital into a new network. i thought they were still working on sustainable business models for the current one. but geoff has thoroughly covered this territory. k From iljitsch at muada.com Sun Feb 17 14:47:22 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 17 Feb 2008 20:47:22 +0100 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 TransferPolicy Proposal In-Reply-To: <20080216061659.0BEEF4500F@ptavv.es.net> References: <20080216061659.0BEEF4500F@ptavv.es.net> Message-ID: <8E30C086-A76A-42F3-864C-B9003C4B6B9E@muada.com> On 16 feb 2008, at 7:16, Kevin Oberman wrote: > Is there traffic? Not that I have seen. Is there demand? Not that I > have > seen. Is there interest? At least a bit more than I typically see in > the commercial Internet, but not a whole lot. What I'm seeing is that about 0.1% of all hosts supports IPv6. That means that the chance of a random data flow being between two IPv6 hosts is one in a million. In order to see a measurable amount of IPv6 traffic at least a few percent of all hosts must support IPv6. Running IPv6 tomorrow makes no sense. But running IPv4 in 2020 doesn't make any sense, either. At some point the unstoppable force will meet the unmovable object. From oberman at es.net Sun Feb 17 17:23:03 2008 From: oberman at es.net (Kevin Oberman) Date: Sun, 17 Feb 2008 14:23:03 -0800 Subject: [ppml] IPv6 getting real: was Policy Proposal: IPv4 TransferPolicy Proposal In-Reply-To: Your message of "Sat, 16 Feb 2008 15:27:44 PST." <20080216232744.GA43669@rommie.caida.org> Message-ID: <20080217222303.6E6824500F@ptavv.es.net> > Date: Sat, 16 Feb 2008 15:27:44 -0800 > From: k claffy > > On Fri, Feb 15, 2008 at 10:16:59PM -0800, Kevin Oberman wrote: > > Unlike the commercial world, the research and educational networks of > the world mostly provide full IPv6 capability. Some of us have been > providing production IPv6 for over half a decade. > > kevin, this definition of "full" is as fuzzy as the vendors'. > it took us (an network research group at SDSC/UCSD) 2 years to > get IPv6 connectivity to our prefix after we first requested it. > we hit 6 or 7 obstacles, including address space suballocation > bureaucracy (weeks back and forth getting clarification on > what kind of ipv6 addresses we should have, then months with ucsd > trying to get a suballocation) to cisco router working ipv6 > image acquisition (months, several re-tries) to sysadmin > learning curves ("ugh, what do we do about autoconf") > to fires in san diego burning down the house of the only SDSC > network admin who had the magic combination of enable access > and ipv6 clue on the magic router between us and v6 transit > to Internet2 (months.). all along we had the issue of what > research grant should pay for the additional work, since NSF > certainly isn't interested in funding infrastructure, and we > had to take time away from funded research projects to work on it. > my hopes for having the academics blaze the ipv6 trail > were tempered by the reality of trying it ourselves. I can't speak for UCSD, although they do have some pretty good networking people. I've worked with some of them in relation to IPv6 in the past and, the main issue was actually getting something to happen. I don't know haw many queries I sent them (no, I'm not naming names) about it, but it literally took years, about 2, even though I know that they were already running IPv6 routinely in support of a remote microscopy experiment. I suspect that it was just too low on their priority list. ESnet treats IPv6 in exactly the same way as we do IPv4 and, when a customer requests IPv6 connectivity, it is usually provided in less then 48 hours, providing their equipment/software supports it. That said, we have had such little demand that I do worry that the capability might atrophy. We get fairly regular queries about how to get IPv6 connectivity, but follow-ups, let alone actual traffic often never happen. With the recent federal mandates for IPv6, I suspect that will change, but I am not holding my breath. It does get frustrating. But I do not think that the IPv6 support offered by ESnet or Internet2 is in any way half-baked. Unfortunately, neither makes it to the end users that want it (and I really believe that they exist). > The fact that IPv6 is available to most users at many major universities > in the US, Canada, and Europe should mean a fair amount of traffic. > > there may be some optimistic confluence of 'universities' > and 'users' here. we have ipv6 to our prefix now, but we had > strong incentive because we want to do ipv6 topology mapping. > i can't imagine why academics in general 'should' use ipv6. > academics in general have no idea what ipv6 is, nor reason to learn. I am sure that you are right. Most academics have little, if any incentive to do IPv6. It's the students I would hope to see generating some traffic. At least a little bit. > After all, it's in the core. You would think college students > would be trading MP3s or movies or something. (I've heard many rumors > that they have been known to do so over IPv4.) > > you lost me there. if they're trading music and movies > over ipv4, why should they use ipv6? Because many schools block the IPv4 file sharing on legal, moral, or network survival grounds and, to this point, most don't even have the capacity to do much about IPv6 because most of the tools for managing file sharing don't work with IPv6. There is also the likelihood that the MPAA and RIAA are not watching IPv6 activity. I have never been into such things, but, if I was and had IPv6 available, I think I'd go there. > Is there traffic? Not that I have seen. Is there demand? Not that I have > seen. Is there interest? At least a bit more than I typically see in > the commercial Internet, but not a whole lot. > > well, i'm not sure how you'd see it since the Juniper routers > that form the core of Internet2's backbone, while v6-capable, > are not v6-netflow-capable. the flow export on those boxes > doesn't support v6, and there has been no other attempt to > characterize IPv6 traffic (tunneled or native) on I2. > (see slide 14 of joe's talk http://www.uoregon.edu/~joe/missing-half/) I think we just hit the "half-baked" part. ESnet generally places IPv6 on separate VLANs or interfaces to let us measure IPv6 traffic. It's not perfect, but it lets me say there is almost none. > so in 2008 not only is there no evidence that U.S. academics are > using IPv6 applications on their backbone, there is also currently > no means to acquire evidence. no trailblazing here. and if > I2 only had enough resources for tilting at one windmill this > decade: DNSSEC or IPv6, which should they pursue? > > Every major router vendor offers "full" IPv6 support. It's just that the > definition of "full" is a bit fuzzy. It often is synonymous with > "half-baked". > > i'm still missing the leap of logic that connects 'half-baked' > to the expectation that academic networking staff on perpetually > tight budgets and already loaded down with more critical networking > issues than they can handle should be investing in IPv6. > i'm not saying they shouldn't, but noone has made the case. None. I am primarily talking to the wishful thinkers, mostly in the commercial world, who keep mumbling "IPV6 is the answer" when asked about almost any major issue the Internet is likely to see in the next 4 years. While IPv6 is important and I really, really believe it is coming, they might as well be saying "42 is the answer". > the R&E community will need exactly the same two things that the > rest of the world will need to support ipv6: incentive and capital. Once gain, you seem to think that my message was a commentary on R&E use of IPv6. R&E is WAY ahead of the rest of the US Internet. That is that the R&E community is doing something, if not much. The real problems are in tools, support (e.g. lack of netflow either for or on IPv6), and a near total lack of interest by those who could make a real difference. (This means service providers and ISPs.) Maybe I was not clear on my real points. I will admit that I was on a bit of a rant and that does not always make for the best of clarity. -- 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 iljitsch at muada.com Mon Feb 18 09:23:09 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 18 Feb 2008 15:23:09 +0100 Subject: [ppml] IPv4 transfers Message-ID: <09DB172F-F865-4360-9D1E-47B1C100661F@muada.com> If IPv4 transfers are allowed but in a way that involves ARIN, then IPv4 addresses that are currently used in the ARIN region can only be obtained by organizations that are also in the ARIN region. ARIN has a little more address space under it than APNIC and the RIPE NCC: 29 /8s for ARIN, 26 for APNIC and the RIPE NCC, LACNIC has 6 and Afrinic 2. However, if we include the legacy /8 space the picture becomes very different: of the 44 /8s that are allocated/assigned (from the delegation records on the RIR FTP servers) APNIC and RIPE both have one in their database, ARIN the other 42. For the space that's under "various registries" (mostly legacy class B), ARIN governs 28.91 /8s, RIPE 6.91 and the other RIRs put together 4.21 /8s. Adding it all up: ARIN: 29 + 42 + 28.91 = 99.91 /8s, 1676 million addresses RIPE NCC: 26 + 1 + 6.91 = 33.91 /8s, 569 million addresses ARPNIC: 26 + 1 + 3.28 = 30.28 /8s, 508 million addresses LACNIC: 6 + 0.57 = 6.57 /8s, 110 million addresses AfriNIC: 2 + 0.36 = 2.36 /8s, 40 million addresses (After I disabled IPv6 I was able to visit the ARIN website and) I had a look at policy proposal 2007-27. This seems like a good way to solve this issue: ARIN would increase IPv4 maintenance fees, and with that finance a "buy back" program from legacy holders. The address space would then be shared with the other RIRs in accordance with 2007-27. From owen at delong.com Tue Feb 19 13:11:13 2008 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Feb 2008 10:11:13 -0800 Subject: [ppml] No Webcast of IPv4 Free Pool BoF today Message-ID: <0B3BCFA6-CA0C-40D0-9F7A-9EA7CD2C72D1@delong.com> I have been informed by Merit that there will be no webcast of this afternoon's AC Hosted BoF. I apologize for any inconvenience. I am posting this because I received a number of inquiries on this topic. Owen From leo.vegoda at icann.org Tue Feb 19 22:36:19 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 19 Feb 2008 19:36:19 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47B0794F.40205@arin.net> Message-ID: On 11/02/2008 17:35, "Member Services" wrote: [...] > 8.4.1 Conditions on the transferor: [...] > * 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. The current policy allows some subscriber members to receive IPv4 space to meet their needs for six months. 4.2.4.4. Six months After a subscriber has been a member of ARIN for one year they may choose to request a six-month supply of IP addresses. Can the proposers explain why the proposal would not allow transfers away from subscribers until 24 months after receiving their last allocation? The difference between the two periods is considerable and I am not sure why the proposers chose 24 months rather than 12, 36 or some other number of months. Thanks, Leo From owen at delong.com Wed Feb 20 01:02:40 2008 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Feb 2008 22:02:40 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: Message-ID: On Feb 19, 2008, at 7:36 PM, Leo Vegoda wrote: > On 11/02/2008 17:35, "Member Services" wrote: > > [...] > >> 8.4.1 Conditions on the transferor: > > [...] > >> * 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. > > The current policy allows some subscriber members to receive IPv4 > space to > meet their needs for six months. > > 4.2.4.4. Six months > > After a subscriber has been a member of ARIN for one year > they may choose to request a six-month supply of IP addresses. > > Can the proposers explain why the proposal would not allow transfers > away > from subscribers until 24 months after receiving their last > allocation? The > difference between the two periods is considerable and I am not sure > why the > proposers chose 24 months rather than 12, 36 or some other number of > months. > We put a stake in the ground at a relatively random point. It is believed that likely 4.2.4.4 will soon be revised to reflect 12 months, and, I suspect not unlikely that the proposed transfer policy will receive a similar revision. Owen From cliffb at cjbsys.bdb.com Wed Feb 20 17:39:08 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Wed, 20 Feb 2008 17:39:08 -0500 (EST) Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal Message-ID: <200802202239.m1KMd8bR000663@cjbsys.bdb.com> I was away from the list for a while and have been trying to catch up on all the postings on this proposal. I've read a lot of pros and cons for the proposal but it seems to me that unless ARIN is fundamentally changing its charter, there should be very limited reasons for approving sales. If I haven't made it through to someone elses comments that express the same thing, forgive me. As I understand the process of getting IPv4 numbers, an entity will come to ARIN with a justification for new/additional allocations. Based on certain criteria, ARIN will approve or disapprove the request. If one entity buys another entity, the IP numbers from the purchasee can be transferred to the purchaser as approved by an existing ARIN policy. Unless ARIN changes its charter, these seem to be the approved ways of getting IPv4 numbers. It seems to me that the only time ARIN should be in the business of approving "sales" of IPv4 addresses is when they have run out of the size requested. If someone has justified an allocation but ARIN doesn't have the assets, then the requestor/ARIN may initiate an effort to find those assets from a 3rd party. (At some point, this may be the de facto process because of limited assets at ARIN) It may be a matter of degree but I don't think ARIN should be approving sales of IPv4 addresses unless they have no assets to offer. Approving "sales" before ARIN has run out of assets would corrupt the current process and lead to all kinds of discontent from those who play by the rules. If I misread the proposal and this is what it says, forgive me but it seemed more convoluted than what I said above. 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 sleibrand at internap.com Wed Feb 20 14:08:48 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 20 Feb 2008 14:08:48 -0500 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: Message-ID: <47BC7AC0.1050304@internap.com> Leo Vegoda wrote: > On 11/02/2008 17:35, "Member Services" wrote: > > [...] > >> 8.4.1 Conditions on the transferor: > > [...] > >> * 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. > > The current policy allows some subscriber members to receive IPv4 space to > meet their needs for six months. > > 4.2.4.4. Six months > > After a subscriber has been a member of ARIN for one year > they may choose to request a six-month supply of IP addresses. > > Can the proposers explain why the proposal would not allow transfers away > from subscribers until 24 months after receiving their last allocation? The > difference between the two periods is considerable and I am not sure why the > proposers chose 24 months rather than 12, 36 or some other number of months. The restriction in 8.4.1 is on someone becoming a transferor (someone with surplus addresses willing to transfer them to another party) if they have acquired addresses recently. It does not prevent someone from *getting* addresses through the transfer process who has recently received them under 4.2.4.4 or through any other policy. (The policy section related to that is the "one transfer every 6 months" rule, but there is no restriction on how soon after your last normal allocation you can acquire space through your first transfer.) The concern in 8.4.1 is with hoarding and speculation. Without a waiting period between receiving addresses and becoming a transferor, there would be a strong incentive for an organization to attempt to acquire as many addresses as possible under current policy, with the intent to transfer them for a profit after IANA exhaustion. Similarly, an organization might wish to speculate on a rising price for IPv4 addresses, by acquiring addresses via transfer while the price is low, intending to transfer them later at a higher price. It is our belief that such speculative behavior is antithetical to the goal of smoothing the upcoming transition, so we attempted to introduce mechanisms to ensure that transfers occur only between organizations with a legitimate surplus of addresses, and those with a legitimate need for them. The period selected (24 months) seemed like a good balance between eliminating the quick-profit motive for speculation, while allowing a legitimate transition of an ISP from needing IPv4 addresses to being able to transition a surplus after moving to IPv6 or otherwise freeing up addresses in use. Having said that, the time periods in this proposal are somewhat tentative, and we have always intended to change them as needed to reflect the community's consensus. So if you would like to make an argument for shorter or longer timeframes on this or any other clause, please do. Thanks, Scott From leo.vegoda at icann.org Wed Feb 20 19:48:31 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 20 Feb 2008 16:48:31 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <47BC7AC0.1050304@internap.com> Message-ID: On 20/02/2008 11:08, "Scott Leibrand" wrote: [...] > It is our belief that such speculative behavior is antithetical to the > goal of smoothing the upcoming transition, so we attempted to introduce > mechanisms to ensure that transfers occur only between organizations > with a legitimate surplus of addresses, and those with a legitimate need > for them. The period selected (24 months) seemed like a good balance > between eliminating the quick-profit motive for speculation, while > allowing a legitimate transition of an ISP from needing IPv4 addresses > to being able to transition a surplus after moving to IPv6 or otherwise > freeing up addresses in use. > > Having said that, the time periods in this proposal are somewhat > tentative, and we have always intended to change them as needed to > reflect the community's consensus. So if you would like to make an > argument for shorter or longer timeframes on this or any other clause, > please do. I don't know whether 24 months is better than another length of time. However, it seems that the current proposal would mean that if a network got a six month supply of IPv4 space from ARIN six months before the IANA free pool was exhausted they would have to wait a further 18 months before they could transfer away any prefixes they no longer needed. These numbers would change if proposal 2007-22 is accepted. Is it possible to give an accurate prediction for how long ARIN will be able to supply the minimum allocation size after IANA's free pool is empty? If it's at least 18 months then I suppose that's OK. But an awkward period where ARIN's free pool cannot supply the minimum allocation and transfers are not yet allowed doesn't sound like a good idea. Is an awkward hiatus likely? What length of time would be needed to make speculation unattractive but maintain a steady supply of address space from ARIN or transfers? Regards, Leo From owen at delong.com Wed Feb 20 20:37:49 2008 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Feb 2008 17:37:49 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: Message-ID: <646A2687-CB1A-4E94-A150-7FFA720B2173@delong.com> > > I don't know whether 24 months is better than another length of time. > However, it seems that the current proposal would mean that if a > network got > a six month supply of IPv4 space from ARIN six months before the > IANA free > pool was exhausted they would have to wait a further 18 months > before they > could transfer away any prefixes they no longer needed. These > numbers would > change if proposal 2007-22 is accepted. > If they just got a 6 month supply of addresses, shouldn't that imply that they don't have any addresses they can free up? I think this is a very strange corner case. If you need more addressing through the normal 6 month supply (or 12 if 2007-22 passes) process, then, I would think the likelihood of you needing less at some point significantly less than 24 months down the road should be minimal. > Is it possible to give an accurate prediction for how long ARIN will > be able > to supply the minimum allocation size after IANA's free pool is > empty? If > it's at least 18 months then I suppose that's OK. But an awkward > period > where ARIN's free pool cannot supply the minimum allocation and > transfers > are not yet allowed doesn't sound like a good idea. > I don't know. I'm sure Leslie could probably pull something together. > Is an awkward hiatus likely? What length of time would be needed to > make > speculation unattractive but maintain a steady supply of address > space from > ARIN or transfers? > My thinking is that for the first 18 or so months of needing transfers, it's unlikely that legitimate requesters of IP address space would be in a position to part with significant amounts of it. Additionally, other longer-term holders will probably supply the market at least somewhat during this time. Owen From leo.vegoda at icann.org Wed Feb 20 21:15:42 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 20 Feb 2008 18:15:42 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <646A2687-CB1A-4E94-A150-7FFA720B2173@delong.com> Message-ID: On 20/02/2008 17:37, "Owen DeLong" wrote: >> >> I don't know whether 24 months is better than another length of time. >> However, it seems that the current proposal would mean that if a >> network got >> a six month supply of IPv4 space from ARIN six months before the >> IANA free >> pool was exhausted they would have to wait a further 18 months >> before they >> could transfer away any prefixes they no longer needed. These >> numbers would >> change if proposal 2007-22 is accepted. >> > If they just got a 6 month supply of addresses, shouldn't that imply > that they > don't have any addresses they can free up? There could be addresses to free up when customer numbers drop or service offerings change. In the former case, a drop in revenue could be temporarily plugged by 'selling off' address space. In the latter case, an ISP might want to offer a basic web-only service provided with an RFC 1918 address while 'selling off' the freed up address space to gain some extra revenue. I think both these scenarios could happen. They aren't necessarily good things - but someone else might need that address space and if so, why not let them get hold of it? Regards, Leo From sleibrand at internap.com Wed Feb 20 21:28:57 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 20 Feb 2008 18:28:57 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: <200802202239.m1KMd8bR000663@cjbsys.bdb.com> References: <200802202239.m1KMd8bR000663@cjbsys.bdb.com> Message-ID: <47BCE1E9.7040706@internap.com> Cliff Bedore wrote: > I was away from the list for a while and have been trying to catch up on all > the postings on this proposal. I've read a lot of pros and cons for the > proposal but it seems to me that unless ARIN is fundamentally changing its > charter, there should be very limited reasons for approving sales. If I > haven't made it through to someone elses comments that express the same thing, > forgive me. > > As I understand the process of getting IPv4 numbers, an entity will come to > ARIN with a justification for new/additional allocations. Based on certain > criteria, ARIN will approve or disapprove the request. Yes, I believe that accurately describes the standard request process under today's policy. > If one entity buys another entity, the IP numbers from the purchasee can be > transferred to the purchaser as approved by an existing ARIN policy. Yes, I believe that accurately describes existing transfer policy. > Unless ARIN changes its charter, these seem to be the approved ways of getting > IPv4 numbers. Replace "charter" with "policy", and that would be correct. > It seems to me that the only time ARIN should be in the business of approving > "sales" of IPv4 addresses is when they have run out of the size requested. If > someone has justified an allocation but ARIN doesn't have the assets, then > the requestor/ARIN may initiate an effort to find those assets from a 3rd > party. (At some point, this may be the de facto process because of limited > assets at ARIN) Exactly. All projections are that we will run out of addresses within a few years, so we're trying to get policy in place to deal with that eventuality before it occurs. > It may be a matter of degree but I don't think ARIN should be approving sales > of IPv4 addresses unless they have no assets to offer. Approving "sales" before > ARIN has run out of assets would corrupt the current process and lead to all > kinds of discontent from those who play by the rules. > > If I misread the proposal and this is what it says, forgive me but it seemed > more convoluted than what I said above. The proposed policy would only institute a liberalized transfer policy once IANA's IPv4 free pool is exhausted. There will be a short period of time between that date and the date when ARIN has insufficient IPv4 addresses to meet requests (probably months, but perhaps more depending on how the last bit of the IANA free pool is distributed). The main reasons for activating the new transfer policy upon IANA exhaustion were: - It's much easier to define IANA exhaustion (there are no more /8's that haven't been allocated to RIRs) than to define ARIN exhaustion. - Activating the transfer policy a short time before ARIN runs out of space will give potential transferors time to get pre-qualified and begin using the ARIN listing service before the first transferees (who will likely need space *right now*) begin participating. A gradual ramp-up in activity (possibly including the transfer of legacy /24's) will give everyone time to figure out the new system, and work out any minor problems that will likely arise. -Scott From sleibrand at internap.com Wed Feb 20 21:50:18 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 20 Feb 2008 21:50:18 -0500 (EST) Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: Message-ID: On 02/20/08 at 6:15pm -0800, Leo Vegoda wrote: > On 20/02/2008 17:37, "Owen DeLong" wrote: > >>> >>> I don't know whether 24 months is better than another length of time. >>> However, it seems that the current proposal would mean that if a >>> network got a six month supply of IPv4 space from ARIN six months >>> before the IANA free pool was exhausted they would have to wait a >>> further 18 months before they could transfer away any prefixes they no >>> longer needed. These numbers would change if proposal 2007-22 is >>> accepted. >>> >> If they just got a 6 month supply of addresses, shouldn't that imply >> that they don't have any addresses they can free up? > > There could be addresses to free up when customer numbers drop or service > offerings change. > > In the former case, a drop in revenue could be temporarily plugged by > 'selling off' address space. In the latter case, an ISP might want to offer > a basic web-only service provided with an RFC 1918 address while 'selling > off' the freed up address space to gain some extra revenue. > > I think both these scenarios could happen. They aren't necessarily good > things - but someone else might need that address space and if so, why not > let them get hold of it? I would agree, but would also argue that the shorter we make the waiting period, the more incentive we give for someone who might be inclined to "game" the system, by acquiring as many addresses as they can justify prior to exhaustion (causing a "run on the bank") and then turning around to transfer them again right after exhaustion. So, does a 24 month waiting period appropriately balance the legitimate need for address recipients to become transferors with the need to prevent "flipping"? Or should that timeframe be shorter/longer? (I know Leo already answered "I don't know", but perhaps others have some input.) -Scott From owen at delong.com Thu Feb 21 15:05:46 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Feb 2008 12:05:46 -0800 Subject: [ppml] Revised 2007-17 Legacy outreach and partial reclamation Message-ID: What follows is a pretty major rewrite of proposal 2007-17 based on community input, staff input, and feedback from the other members of the Advisory Council. I hope that this new version of the proposal will better meet the desires of the community, the rigors of the ARIN policy process, and, the needs of the ARIN staff. If you choose to comment on this new version, please indicate whether you favor or oppose it as well as any ways in which you believe it could be improved. Thanks, Owen Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 Policy Proposal Name: Legacy Outreach and Partial Reclamation Author name: Owen DeLong email: owen at delong.com telephone: 408-921-6984 organization: JITTR Networks Proposal Version: 0.2.0 Submission Date: 2008 February 21 Proposal type: M new, modify, or delete. Policy term: permanent temporary, permanent, or renewable. 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 Meeting presenter: TBD, probably Owen DeLong END OF TEMPLATE -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Thu Feb 21 15:29:41 2008 From: info at arin.net (Member Services) Date: Thu, 21 Feb 2008 15:29:41 -0500 Subject: [ppml] Revised 2007-17 Legacy outreach and partial reclamation In-Reply-To: References: Message-ID: <47BDDF35.6030008@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: > What follows is a pretty major rewrite of proposal 2007-17 based on > community input, staff input, and feedback from the other members > of the Advisory Council. I hope that this new version of the proposal > will better meet the desires of the community, the rigors of the > ARIN policy process, and, the needs of the ARIN staff. > > If you choose to comment on this new version, please indicate whether > you favor or oppose it as well as any ways in which you believe it > could be improved. > > Thanks, > > Owen > > > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 > > > Policy Proposal Name: Legacy Outreach and Partial Reclamation > Author > name: Owen DeLong > email: owen at delong.com > telephone: 408-921-6984 > organization: JITTR Networks > > Proposal Version: 0.2.0 > Submission Date: 2008 February 21 > Proposal type: M > new, modify, or delete. > Policy term: permanent > temporary, permanent, or renewable. > 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 > > Meeting presenter: > > TBD, probably Owen DeLong > > 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 owen at delong.com Thu Feb 21 16:23:22 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Feb 2008 13:23:22 -0800 Subject: [ppml] Proposal "Loophole Closure for 2007-21" withdrawn Message-ID: The authors have come to agreement with the ARIN AC that the policy proposal titled "Loophole Closure for 2007-21" is no longer needed and should be withdrawn at this time. As such, the proposal is withdrawn. Owen DeLong on behalf of Owen DeLong and Scott Liebrand From owen at delong.com Thu Feb 21 16:25:06 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Feb 2008 13:25:06 -0800 Subject: [ppml] Proposal 2007-26 Withdrawn Message-ID: <8A73154C-309E-4A5D-A3D8-C98193F7015F@delong.com> As the author of policy proposal 2007-26, having seen that the comments on PPML regarding this policy proposal have shown virtually no community support for the ideas contained therein, I have decided to withdraw the proposal at this time. Owen DeLong From mksmith at adhost.com Thu Feb 21 17:01:03 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 21 Feb 2008 14:01:03 -0800 Subject: [ppml] Revised 2007-17 Legacy outreach and partial reclamation In-Reply-To: <47BDDF35.6030008@arin.net> References: <47BDDF35.6030008@arin.net> Message-ID: <17838240D9A5544AAA5FF95F8D52031603698ECD@ad-exh01.adhost.lan> Hello All: I oppose this policy as written. I have put comments in line below, but in summary, the incentives to Legacy holders seem largely ephemeral in comparison to the disincentives and, as such, I don't think this policy will be well received by the Legacy community. It should be noted that I am not a Legacy address holder. > > 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. > > This certainly sounds hopeful. > > 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. > > Here's where we get ephemeral. What does "as convenient and risk-free...as possible" actually mean? > > 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. I'm not sure I understand the intent of this one. Is this to say ARIN will not require the owner to renumber within the remaining block, or renumber out of the block into a new, non-Legacy block at some future date? > > > > 4.6.4 Incentives > > The Board of Trustees should consider creating incentives for > > organizations to return addresses under this policy. Should? That doesn't really say much to my mind. I think a "must" or "will" would be in order to make this palatable. > > > > 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. > > So this seems like a clearly defined "stick." As I read this, I need to sign an RSA for new space and for the space left over after any reclamation. > > 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. > > I like the intent of this, but given the gravity of the outcome of being labeled "unreachable" I think a single, annual contact attempt and a "reasonable effort" are not sufficient for de-allocating the resource. I would like to know what a reasonable effort is. My guess is a lot of the Legacy contact information for an entity is stale, but the entity itself is not. > > 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: > > I'm assuming one or more of the bullets below would be rolled up under 4.6.4? > > > > 1. If the organization does not currently pay ARIN > > fees, they shall remain fee exempt. > > Don't the vast majority pay some sort of fees already? I thought even the Legacy holders paid at least a nominal fee to ARIN. > > 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. > > So, if I return a /28 a year I get a single year waiver for each /28? Hrmm. How about: /24 - /23 -> 6 month waiver /22 - /21 -> 1 year waiver /20 - /17 -> 2 year waiver /16 - /8 -> 5 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. > > This would probably meet with the least resistance. > > 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. > > This seems to be a disincentive to getting IPv6 space. I want everyone to get IPv6 *now* so I don't want ARIN to put stipulations on any IPv4-holder to acquiring IPv6 space. I would rather see something along the lines of "IPv6 assignments will be made separate and distinct from any previous IPv4 assignments and will be entered into under a separate RSA from any other agreements that may exist." IANAL so that last sentence was off-the-cuff. Basically, let them get the /32 under the same arrangements as me and don't put any restrictions based upon their legacy allocations or contracts. Regards, Michael Smith Adhost Internet LLC. -------------- 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 Thu Feb 21 17:25:44 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Feb 2008 14:25:44 -0800 Subject: [ppml] Revised 2007-17 Legacy outreach and partial reclamation In-Reply-To: <17838240D9A5544AAA5FF95F8D52031603698ECD@ad-exh01.adhost.lan> References: <47BDDF35.6030008@arin.net> <17838240D9A5544AAA5FF95F8D52031603698ECD@ad-exh01.adhost.lan> Message-ID: <115DF1B9-EEFA-407C-8E6D-5CD2368E8BA9@delong.com> On Feb 21, 2008, at 2:01 PM, Michael K. Smith - Adhost wrote: > Hello All: > > I oppose this policy as written. I have put comments in line below, > but in summary, the incentives to Legacy holders seem largely > ephemeral in comparison to the disincentives and, as such, I don't > think this policy will be well received by the Legacy community. It > should be noted that I am not a Legacy address holder. > As I understand it, you object because you believe the policy by itself would not be effective. Would you agree it could be effective if the BoT were to adopt additional incentives as recommended in the Rationale section? Those incentives were removed from the policy text to address the technicality that fees, fee waivers and the like are not policy matters and cannot be addressed in the policy process. >>> 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. >>> > This certainly sounds hopeful. > >>> 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. >>> > Here's where we get ephemeral. What does "as convenient and risk- > free...as possible" actually mean? > It means that any resource holder seeking to return resources to ARIN should be able to do so without fear that ARIN will seek to do some harm to the organization returning the address space. For example, returning address space will not force you to renumber (other than to stop using the addresses you are returning). It should not trigger an additional audit of your retained resources. Etcetera. In general, this is intended as a guideline statement to staff that the public interest is best served if people have no reason to be afraid of returning unused address space. >>> 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. > > I'm not sure I understand the intent of this one. Is this to say > ARIN will not require the owner to renumber within the remaining > block, or renumber out of the block into a new, non-Legacy block at > some future date? > This is intended to cover a situation where, for example, someone has a /16 and needs a /18 of that space. Instead of returning the /16 and getting a completely different /18, this policy would require ARIN staff to allow the holder to return any /18 and /17 from the /16 while still keeping the / 18 of the holder's choosing. Under current policy, theoretically, the holder could be required to return the entire /16. Although that is not current staff practice in most such cases, it is how current policy is written. >>> >>> 4.6.4 Incentives >>> The Board of Trustees should consider creating incentives for >>> organizations to return addresses under this policy. > > Should? That doesn't really say much to my mind. I think a "must" > or "will" would be in order to make this palatable. > Again, because of the limitations of the policy process, should is the strongest language that can be applied in this context. I have a high degree of confidence that if this policy is adopted, the board will consider creating incentives. Even if they do not, I don't see any way in which this policy is harmful, and, the membership certainly can through the member meeting process create a forcing function for the board to consider incentives if this policy is adopted. Fee issues are outside the purview of the policy process, so, this was the best compromise I could strike. >>> >>> 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. >>> > > So this seems like a clearly defined "stick." As I read this, I > need to sign an RSA for new space and for the space left over after > any reclamation. > Not exactly. You need to sign an RSA for new space anyway. If you retain a block that is not expanded (i.e. you have a /16 and you return all but a /18), you would not be required to sign an RSA. If, on the other hand, you have 7 /24s that are non-contiguous and you return 6 of them, retain 1 of them, and, are assigned the appropriate other /24s to make it a /22 (effectively returning a net of 3 /24s), you would be required to sign an RSA that covers the /22. The RSA still wouldn't apply to any other blocks you retain. >>> 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. >>> > > I like the intent of this, but given the gravity of the outcome of > being labeled "unreachable" I think a single, annual contact attempt > and a "reasonable effort" are not sufficient for de-allocating the > resource. I would like to know what a reasonable effort is. My > guess is a lot of the Legacy contact information for an entity is > stale, but the entity itself is not. > In order to be subject to this, you would have to participate in this policy at least once. Existing stale legacy contacts would not be subject to this issue since they would have to contact ARIN and update their contact information in order to participate in this policy. Once you've participated in this policy, you've agreed to make contact with ARIN once a year and keep your contact up to date. All you need to do to avoid being labelled is make a phone call once every 12 months, and, you can avoid your resources being reclaimed by calling once every 18 months. (An email works, too). Also, note that in the next paragraph, if you are paying fees every year, by paying your fee, you have met the requirement to make contact. >>> 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: >>> > > I'm assuming one or more of the bullets below would be rolled up > under 4.6.4? > The bullets below can't be policy. That is why they were removed from the policy in this rewrite. Fees are set by the BoT and are not part of the public policy process. >>> >>> 1. If the organization does not currently pay ARIN >>> fees, they shall remain fee exempt. >>> > Don't the vast majority pay some sort of fees already? I thought > even the Legacy holders paid at least a nominal fee to ARIN. > Nope. Many legacy holders pay no fees. >>> 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. >>> > So, if I return a /28 a year I get a single year waiver for each / > 28? Hrmm. How about: > > /24 - /23 -> 6 month waiver > /22 - /21 -> 1 year waiver > /20 - /17 -> 2 year waiver > /16 - /8 -> 5 year waiver > Nope. That's why it says "one-time single year waiver". You only get a free year the first time you return a /28. After that, you'd have to return at least a /20 to get additional fees waived. I'm not necessarily opposed to your graduated structure either. However, this discussion of fee waivers really would be more appropriate on arin-discuss or as a suggestion sent to the BoT. The text in the rationale section of the proposal is intended just as a straw-man for what the BoT might consider. It is really outside of the purview of the policy process. > >>> 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. >>> > > > This would probably meet with the least resistance. > >>> 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. >>> > > This seems to be a disincentive to getting IPv6 space. I want > everyone to get IPv6 *now* so I don't want ARIN to put stipulations > on any IPv4-holder to acquiring IPv6 space. I would rather see > something along the lines of "IPv6 assignments will be made separate > and distinct from any previous IPv4 assignments and will be entered > into under a separate RSA from any other agreements that may > exist." IANAL so that last sentence was off-the-cuff. Basically, > let them get the /32 under the same arrangements as me and don't put > any restrictions based upon their legacy allocations or contracts. > That's possible now. However, if they want to get it for a reduced fee or for free, they face the tradeoff of bringing their legacy IPv4 under RSA. Owen From cliffb at cjbsys.bdb.com Thu Feb 21 18:01:12 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Thu, 21 Feb 2008 18:01:12 -0500 (EST) Subject: [ppml] Legacy RSAs signed Message-ID: <200802212301.m1LN1C6q012697@cjbsys.bdb.com> Does anyone have a count of legacy holders who have signed the legacy RSA? I'm curious if it has had any effect on pulling people in from the swamp. 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 owen at delong.com Thu Feb 21 18:52:49 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Feb 2008 15:52:49 -0800 Subject: [ppml] Revised Policy Proposal 2007-14 Message-ID: Based on feedback from the ARIN AC and from the Albuquerque meeting, I'm posting this revised proposal for 2007-14. Changes include: Rational expanded to clarify that 2c creates a limitation on how often ARIN can do a without-cause review. Changed the without cause limitation to 24 months instead of 12. Rewrote Paragraph 4 in an attempt at greater clarity of intent. Added paragraph 9 to address concerns about timed policies that have not completed. I hope that these revisions create a proposal which is acceptable to the community. I know that the community put significant effort into the discussion of this proposal and I believe that such a review process will benefit the community greatly. Thanks, Owen 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 ipgoddess at gmail.com Thu Feb 21 19:28:21 2008 From: ipgoddess at gmail.com (Stacy Taylor) Date: Thu, 21 Feb 2008 16:28:21 -0800 Subject: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal In-Reply-To: References: Message-ID: <1c16a4870802211628u187b0d1cu1914e914687adf5e@mail.gmail.com> We should also take into account the network abusers and spammers out there. The longer timetable for coming back for another transfer would go toward keeping space cleaner, longer, and letting the spammers stew in their own dirty space.Stacy On Wed, Feb 20, 2008 at 6:50 PM, Scott Leibrand wrote: > On 02/20/08 at 6:15pm -0800, Leo Vegoda wrote: > > > On 20/02/2008 17:37, "Owen DeLong" wrote: > > > >>> > >>> I don't know whether 24 months is better than another length of time. > >>> However, it seems that the current proposal would mean that if a > >>> network got a six month supply of IPv4 space from ARIN six months > >>> before the IANA free pool was exhausted they would have to wait a > >>> further 18 months before they could transfer away any prefixes they no > >>> longer needed. These numbers would change if proposal 2007-22 is > >>> accepted. > >>> > >> If they just got a 6 month supply of addresses, shouldn't that imply > >> that they don't have any addresses they can free up? > > > > There could be addresses to free up when customer numbers drop or > service > > offerings change. > > > > In the former case, a drop in revenue could be temporarily plugged by > > 'selling off' address space. In the latter case, an ISP might want to > offer > > a basic web-only service provided with an RFC 1918 address while > 'selling > > off' the freed up address space to gain some extra revenue. > > > > I think both these scenarios could happen. They aren't necessarily good > > things - but someone else might need that address space and if so, why > not > > let them get hold of it? > > I would agree, but would also argue that the shorter we make the waiting > period, the more incentive we give for someone who might be inclined to > "game" the system, by acquiring as many addresses as they can justify > prior to exhaustion (causing a "run on the bank") and then turning around > to transfer them again right after exhaustion. > > So, does a 24 month waiting period appropriately balance the legitimate > need for address recipients to become transferors with the need to prevent > "flipping"? Or should that timeframe be shorter/longer? (I know Leo > already answered "I don't know", but perhaps others have some input.) > > -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 vixie at isc.org Fri Feb 22 01:25:00 2008 From: vixie at isc.org (Paul Vixie) Date: 22 Feb 2008 06:25:00 +0000 Subject: [ppml] Legacy RSAs signed In-Reply-To: <200802212301.m1LN1C6q012697@cjbsys.bdb.com> References: <200802212301.m1LN1C6q012697@cjbsys.bdb.com> Message-ID: cliffb at cjbsys.bdb.com (Cliff Bedore) writes: > Does anyone have a count of legacy holders who have signed the legacy RSA? > I'm curious if it has had any effect on pulling people in from the swamp. ISC has signed. -- Paul Vixie From jhframe at dcn.org Fri Feb 22 02:10:22 2008 From: jhframe at dcn.org (Jim Frame) Date: Thu, 21 Feb 2008 23:10:22 -0800 Subject: [ppml] Legacy RSAs signed In-Reply-To: <200802212301.m1LN1C6q012697@cjbsys.bdb.com> References: <200802212301.m1LN1C6q012697@cjbsys.bdb.com> Message-ID: <47BE755E.3010305@dcn.org> Cliff Bedore wrote: > Does anyone have a count of legacy holders who have signed the legacy RSA? > I'm curious if it has had any effect on pulling people in from the swamp. Davis Community Network has signed, though not without reservations. We felt that we were forced into relinquishing rights to certain resources in favor of an organization with an inferior claim to those resources, but one with the power to interfere with our enjoyment of same. The decision ultimately hinged upon our assessment of the risk/reward ratio, without regard to the fairness of the situation. (All without even knowing that we were in a swamp.) -- --------------------------------------------------------------------- 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 info at arin.net Fri Feb 22 13:08:43 2008 From: info at arin.net (Member Services) Date: Fri, 22 Feb 2008 13:08:43 -0500 Subject: [ppml] Revised Policy Proposal 2007-14 In-Reply-To: References: Message-ID: <47BF0FAB.5000303@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: > Based on feedback from the ARIN AC and from the Albuquerque meeting, I'm > posting this revised proposal for 2007-14. > > Changes include: > Rational expanded to clarify that 2c creates a limitation on how > often ARIN can do a > without-cause review. > > Changed the without cause limitation to 24 months instead of 12. > > Rewrote Paragraph 4 in an attempt at greater clarity of intent. > > Added paragraph 9 to address concerns about timed policies that have > not completed. > > I hope that these revisions create a proposal which is acceptable to > the community. I know > that the community put significant effort into the discussion of this > proposal and I believe > that such a review process will benefit the community greatly. > > Thanks, > > Owen > > 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 > > > > _______________________________________________ > 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 Fri Feb 22 13:20:41 2008 From: info at arin.net (Member Services) Date: Fri, 22 Feb 2008 13:20:41 -0500 Subject: [ppml] Proposal 2007-26 Withdrawn In-Reply-To: <8A73154C-309E-4A5D-A3D8-C98193F7015F@delong.com> References: <8A73154C-309E-4A5D-A3D8-C98193F7015F@delong.com> Message-ID: <47BF1279.3070203@arin.net> Policy Proposal 2007-26 IPv6 Assignment Guidelines The author withdrew their proposal. The proposal is closed. The policy proposal text is available at: http://www.arin.net/policy/proposals/2007_26.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) Owen DeLong wrote: > As the author of policy proposal 2007-26, having seen that the comments > on PPML regarding this policy proposal have shown virtually no community > support for the ideas contained therein, I have decided to withdraw the > proposal at this time. > > Owen DeLong > > _______________________________________________ > 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 Fri Feb 22 13:27:56 2008 From: info at arin.net (Member Services) Date: Fri, 22 Feb 2008 13:27:56 -0500 Subject: [ppml] Policy Proposal 2007-16: IPv4 Soft Landing - Withdrawn by author Message-ID: <47BF142C.4030202@arin.net> Policy Proposal 2007-16 IPv4 Soft Landing The author withdrew their proposal. The proposal is closed. The policy proposal text is below and available at: http://www.arin.net/policy/proposals/2007_16.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-16 IPv4 Soft Landing Author: David Conrad Proposal type: New Policy term: Permanent Policy statement: This policy is intended to replace section 4.2.4.1 of the ARIN Number Resource Policy Manual with wording substantially along the lines of: --- begin modification --- 4.2.4.1 In order to encourage a smooth transition to IPv6, ARIN has instituted a set of IPv4 Address Allocation "phases" that vary the requirements for address allocation using the amount of address space remaining unallocated by IANA as a metric. As the amount of address space in the IANA free pool is reduced, the requirements for IPv4 address allocation are made more stringent. When requesting additional IPv4 address space, ISPs must meet the requirements of the IPv4 Address Allocation phase ARIN was in when the request was submitted. These phases will require the requester to demonstrate increasingly efficient utilization of previously allocated IPv4 address space, including all space reassigned to their customers. In addition, depending on the IPv4 Address Allocation phase ARIN was in when the request was submitted, there may be additional requirements that will need to be met by the requester such as completing a survey on IPv6 deployment plans, documentation of non-private address space used for internal infrastructure, documentation of IPv6 plans for offering connectivity and services, etc. The reassignment information section of the ARIN ISP Network Request Template should be completed for all address blocks that have been allocated to your organization. In the template, line 1b. Assigned: information will be verified via SWIP/RWHOIS and 1c. Reserved: should be used to indicate internal network information. Please note that until all requirements are met and your prior utilization is verified to meet the requirements specified in the IPv4 Address Allocation phase in which the request was received, ARIN can neither process nor approve a request for additional addresses. IPv4 Allocation Phases The thresholds and the requirements to justify an allocation of new IPv4 address space from ARIN are defined in this section. Phase: 0 Threshold: Greater than 40 /8s Requirements: Requesters must: * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 25% utilization - Demonstrate a one year requirement of 50% utilization Phase: 1 Threshold: 40 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 25% utilization - Demonstrate a one year requirement of 50% utilization * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used. Phase: 2 Threshold: 25 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 85% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 50% utilization - Demonstrate a one year requirement of 75% utilization * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used. * Provide plans for migrating all non-RFC 1918 address space used for internal infrastructure either to IPv6 (preferred) or to private addressing where possible. Where such migration is not possible, provide documentation listing the use of addresses that are not migratable and the reasons for the inability to migrate. * Demonstrate documented plans for availability of production IPv6 infrastructure and connectivity services within 6 months of submitting the request. Phase: 3 Threshold: 10 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 90% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 75% utilization - Demonstrate a one year requirement of 90% utilization * Provide documentation demonstrating migration (where possible) of non-RFC 1918 address space used for internal infrastructure to either IPv6 (preferred) or private addressing. * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure, how it is used, and why it is not possible to migrate those addresses to either IPv6 (preferred) or private addressing. * Demonstrate availability of production IPv6 infrastructure and connectivity services. Notes: * Phase 0 reflects current allocation requirements. * Phases 1 through 3 are to be implemented 30 days after IANA allocates address space from the IPv4 free pool that reduces that free pool to a number of /8s that are at or below the threshold specified. * If multiple thresholds should be crossed within a 30 day period, the requirements from the last threshold crossed will be applied to requesters for additional address space at the time of the request. --- end modification --- Rationale: The rationale for this proposal is threefold: * to prolong the availability of IPv4 addresses for requesters who can provide sufficient justification; * to encourage the deployment of IPv6 as an alternative to IPv4 by making the requirements to justify IPv4 allocations increasingly stringent over time; * to promote the more efficient use of increasingly scarce IPv4 resources. As the lack of significant deployment of IPv6 can attest, the cost of deploying IPv6 currently outweighs the benefits that protocol would appear to provide. This proposal aims to encourage the deployment of IPv6 by over time, making the allocation of IPv4 both more difficult and contingent on the requester demonstrating both support for IPv6 as well as requiring a demonstration that the IPv4 address space they administer is being used efficiently. The goal of these measures is to rebalance the IPv6 deployment cost/benefit ratio thereby encouraging greater uptake of IPv6 before the IPv4 free pool is exhausted. The "IPv4 Soft Landing" policy aims to provide for a smoother transition away from IPv4 towards IPv6 by imposing increasingly strict requirements for new address allocations as the amount of address space available in the IANA unallocated IPv4 address pool decreases. These increased requirements include both more stringent reassignment and utilization percentages as well as requiring documented IPv6 infrastructure services and connectivity provision and the documentation or reuse of public IPv4 address space used for internal infrastructure. The increased stringency in the allocation requirements is intended both to increase the efficiency of utilization of the IPv4 address space and to reduce the likelihood of a "run" on the remaining free pool of IPv4 address space. ARIN staff would be expected to use the same mechanisms in use today to verify conformance to the specified requirements. The requirements for demonstration of IPv6 infrastructure services and connectivity are intended to motivate ISPs to provide those services before the only address space they can offer their customers is IPv6, thereby offering an opportunity to break the "chicken-and-egg" problem limiting significant IPv6 deployment. Verification of these requirements can be done by ARIN staff by using IPv6 transport to connect to published services of the ISP (e.g., DNS servers, WWW URLs, etc.) as well as using IPv6 ping to identified addresses internal to the ISP. Obviously, false positive responses for most any objective mechanism for verifying the availability can be engineered, so ARIN staff may also consider subjective reports of an inability to obtain IPv6 services by customers as an indicator of (lack of) conformance to this requirement. The requirements to migrate internal infrastructure to either IPv6 or private (e.g., RFC 1918) addressing are intended to improve the efficiency of utilization of IPv4 address space, reserving the scarce IPv4 resources for purposes for which IPv6 or private addresses are not suitable. These requirements acknowledge that pragmatically, the use of IPv4 is absolutely essential only for servers in client-server architectures, machines engaged in peer-to-peer applications, and entry points for NAT/ALG devices. As such, use of IPv4 for purposes such as router interface numbering, client-only devices, and devices which should not be available from external networks should be discouraged. Since there can be circumstances in which migration of internal infrastructure addresses to private addressing would not be feasible, this policy allows for requesters to document those situations in which it is not possible to do the migration. The time for transition between phases of this policy are not fixed, rather they depend on the rate of consumption of IPv4 address space from the IANA free pool. Current RIR operational procedure is to request 2 /8s from the IANA when the RIR's current pool of free IPv4 address space is depleted. This procedure should ensure transitions between phases will have some lead-time, so organizations can prepare for the next phase of IPv4 address allocation. Given the highly volatile nature of IPv4 consumption and the inability to define a predictive model rooted in an underlying theory rather than extrapolating over existing data, the thresholds chosen are acknowledged to be somewhat arbitrary. The intent of the chosen values is to provide a "reasonable" amount of time, approximately 18 months, between transitions at current consumption rates (approximately 10 /8s per year). However, it should be explicitly noted that one of the intents of this policy is to extend the IPv4 free pool lifetime, thus as the policy becomes effective, the amount of time between phase transitions would presumably increase. Timetable for implementation: Immediately upon approval of this policy by the ARIN Board of Trustees. From info at arin.net Fri Feb 22 13:43:19 2008 From: info at arin.net (Member Services) Date: Fri, 22 Feb 2008 13:43:19 -0500 Subject: [ppml] Proposal "Loophole Closure for 2007-21" withdrawn In-Reply-To: References: Message-ID: <47BF17C7.5050907@arin.net> Policy Proposal Loophole Closure for 2007-21 The author withdrew their proposal. The proposal is closed. The policy proposal text is available at: http://lists.arin.net/pipermail/ppml/2008-February/009974.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) Owen DeLong wrote: > The authors have come to agreement with the ARIN AC that the > policy proposal titled "Loophole Closure for 2007-21" is no > longer needed and should be withdrawn at this time. > > As such, the proposal is withdrawn. > > Owen DeLong > on behalf of Owen DeLong and Scott Liebrand > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > From Lee at dilkie.com Fri Feb 22 19:47:21 2008 From: Lee at dilkie.com (Lee Dilkie) Date: Fri, 22 Feb 2008 19:47:21 -0500 Subject: [ppml] Legacy RSAs signed In-Reply-To: <47BE755E.3010305@dcn.org> References: <200802212301.m1LN1C6q012697@cjbsys.bdb.com> <47BE755E.3010305@dcn.org> Message-ID: <47BF6D19.9040104@dilkie.com> Jim Frame wrote: > Cliff Bedore wrote: > > >> Does anyone have a count of legacy holders who have signed the legacy RSA? >> I'm curious if it has had any effect on pulling people in from the swamp. >> > > Davis Community Network has signed, though not without reservations. We > felt that we were forced into relinquishing rights to certain resources > in favor of an organization with an inferior claim to those resources, > but one with the power to interfere with our enjoyment of same. The > decision ultimately hinged upon our assessment of the risk/reward ratio, > without regard to the fairness of the situation. (All without even > knowing that we were in a swamp.) > > Shocking. My read is that you felt bullied into signing. After visiting your website, I can see your point of view. You're a non-profit with little resources to fight for what's fair. Swampwater feels fine to me. -lee From mksmith at adhost.com Mon Feb 25 13:41:27 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Mon, 25 Feb 2008 10:41:27 -0800 Subject: [ppml] Revised 2007-17 Legacy outreach and partial reclamation In-Reply-To: <115DF1B9-EEFA-407C-8E6D-5CD2368E8BA9@delong.com> References: <47BDDF35.6030008@arin.net> <17838240D9A5544AAA5FF95F8D52031603698ECD@ad-exh01.adhost.lan> <115DF1B9-EEFA-407C-8E6D-5CD2368E8BA9@delong.com> Message-ID: <17838240D9A5544AAA5FF95F8D520316036990B7@ad-exh01.adhost.lan> Hello Owen: I apologize for not getting back to you sooner. > > > Hello All: > > > > I oppose this policy as written. I have put comments in line below, > > but in summary, the incentives to Legacy holders seem largely > > ephemeral in comparison to the disincentives and, as such, I don't > > think this policy will be well received by the Legacy community. It > > should be noted that I am not a Legacy address holder. > > > As I understand it, you object because you believe the policy by > itself would not be effective. Would you agree it could be effective > if the BoT were to adopt additional incentives as recommended > in the Rationale section? Those incentives were removed from the > policy text to address the technicality that fees, fee waivers and the > like are not policy matters and cannot be addressed in the policy > process. > Absolutely. My personal opinion is that the *only* way to get the Legacy holders to come into the fold is through incentives. Why would a Legacy holder ever choose to come under the ARIN umbrella otherwise? > > > >>> 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. > >>> > > Here's where we get ephemeral. What does "as convenient and risk- > > free...as possible" actually mean? > > > It means that any resource holder seeking to return resources to ARIN > should be able to do so without fear that ARIN will seek to do some > harm to the organization returning the address space. For example, > returning address space will not force you to renumber (other than > to stop using the addresses you are returning). It should not trigger > an additional audit of your retained resources. Etcetera. In general, > this is intended as a guideline statement to staff that the public > interest is best served if people have no reason to be afraid of > returning > unused address space. So I like the second set of examples better than the first. Would it be better to have no example at all so that it read: ARIN shall seek to make the return of address space as convenient and risk-free to the returning organization as 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. > > > > I'm not sure I understand the intent of this one. Is this to say > > ARIN will not require the owner to renumber within the remaining > > block, or renumber out of the block into a new, non-Legacy block at > > some future date? > > > This is intended to cover a situation where, for example, someone has > a /16 > and needs a /18 of that space. Instead of returning the /16 and > getting a > completely different /18, this policy would require ARIN staff to > allow the > holder to return any /18 and /17 from the /16 while still keeping the / > 18 of > the holder's choosing. Under current policy, theoretically, the > holder could > be required to return the entire /16. Although that is not current > staff practice > in most such cases, it is how current policy is written. > Something like "ARIN will allow for the return of partial blocks of space from within the originally assigned block without any further encumbrances". > >>> > >>> 4.6.4 Incentives > >>> The Board of Trustees should consider creating incentives for > >>> organizations to return addresses under this policy. > > > > Should? That doesn't really say much to my mind. I think a "must" > > or "will" would be in order to make this palatable. > > > Again, because of the limitations of the policy process, should is the > strongest language that can be applied in this context. I have a high > degree of confidence that if this policy is adopted, the board will > consider creating incentives. Even if they do not, I don't see any > way in which this policy is harmful, and, the membership certainly > can through the member meeting process create a forcing function > for the board to consider incentives if this policy is adopted. > Fee issues are outside the purview of the policy process, so, this > was the best compromise I could strike. > It just seems to take all the teeth out of it, whereas the requirement further down are all very concrete. I'd love to hear from Legacy holders about how they read it. > > > > I'm assuming one or more of the bullets below would be rolled up > > under 4.6.4? > > > The bullets below can't be policy. That is why they were removed from > the > policy in this rewrite. Fees are set by the BoT and are not part of > the public > policy process. > It might be better to remove it entirely so that it doesn't set unreasonable expectations. Then, a separate discussion about incentives could be had within the community and submitted as comments/suggestions to the BoT. 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 info at arin.net Tue Feb 26 08:32:50 2008 From: info at arin.net (Member Services) Date: Tue, 26 Feb 2008 08:32:50 -0500 Subject: [ppml] Policy Proposal 2008-1: SWIP support for smaller than /29 assignments Message-ID: <47C41502.3040509@arin.net> On 21 February 2008, the ARIN Advisory Council (AC) concluded its initial review of "SWIP support for smaller than /29 assignments" and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2008-1: SWIP support for smaller than /29 assignments. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2008_1.html All persons in the community are encouraged to discuss Policy Proposal 2008-1 prior to it being presented at the ARIN XXI Public Policy Meeting in April 2008. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2008-1 SWIP support for smaller than /29 assignments Author: Joe Maimon Proposal Version: 1 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 Tue Feb 26 08:33:22 2008 From: info at arin.net (Member Services) Date: Tue, 26 Feb 2008 08:33:22 -0500 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal Message-ID: <47C41522.2040304@arin.net> On 21 February 2008, the ARIN Advisory Council (AC) concluded its initial review of "IPv4 Transfer Policy Proposal" and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2008-2: IPv4 Transfer Policy Proposal. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2008_2.html All persons in the community are encouraged to discuss Policy Proposal 2008-2 prior to it being presented at the ARIN XXI Public Policy Meeting in April 2008. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2008-2 IPv4 Transfer Policy Proposal Author: ARIN Advisory Council Proposal Version: 1 Date: 26 February 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 ?M&A Transfer Requirements?: 8.2. M&A Transfer Requirements 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.] [8.3 ? retitle to ?M&A Transfer Documentation Requirements?: 8.3. M&A Transfer Documentation Requirements 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.4. Requirements for Simple Transfer of IPv4 Addresses After the exhaustion of the IANA IPv4 free pool, ARIN will also process IPv4 address transfer requests subject to the following conditions. 8.4.1 Conditions on the transferor: * 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.4.2 Conditions on the transferee: * 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 only receive one IPv4 address transfer every 6 months. 8.4.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. 8.4.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.4.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 exact network address and size (CIDR prefix length) the transferor is eligible to provide, and the expiration date of the pre-qualification. 8.5. Safe Harbor for IPv4 Transfers through this Simple Transfer Process IPv4 address resources being made available for transfer shall be exempt from ARIN audit until expiration of the transfer pre-qualification or completion of the transfer. In the event that a transfer pre-qualification expires, ARIN shall have up to 90 days to initiate an audit prior to this exemption being reinstated through subsequent transfer pre-qualification. This will not extend the end of the exemption. 8.6. 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.7. 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. 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 Tue Feb 26 08:34:54 2008 From: info at arin.net (Member Services) Date: Tue, 26 Feb 2008 08:34:54 -0500 Subject: [ppml] Policy Proposal: Community Networks IPv6 Allocation Message-ID: <47C4157E.8010105@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 revised text must be posted to the PPML by 7 March 2008 in order to meet the requirement of 30 days of online discussion or the proposal will not be presented at the upcoming ARIN Public Policy Meeting in Denver. 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) From randy at psg.com Tue Feb 26 16:32:42 2008 From: randy at psg.com (Randy Bush) Date: Wed, 27 Feb 2008 05:32:42 +0800 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <47C41522.2040304@arin.net> References: <47C41522.2040304@arin.net> Message-ID: <47C4857A.8000105@psg.com> > On 21 February 2008, the ARIN Advisory Council (AC) concluded its > initial review of "IPv4 Transfer Policy Proposal" and accepted it as a > formal policy proposal for discussion by the community. > ... > Author: ARIN Advisory Council i can't decide if this is merely amusing or should bother me. i think i will write it of to our being such a rule/process obsessed culture. randy From BillD at cait.wustl.edu Tue Feb 26 17:06:15 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 26 Feb 2008 16:06:15 -0600 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal References: <47C41522.2040304@arin.net> <47C4857A.8000105@psg.com> Message-ID: Can I safely assume that your comments are AGAINST the proposal? We on the AC would like to keep track of those favoring and against each proposal, as always. Bill Darte -----Original Message----- From: ppml-bounces at arin.net on behalf of Randy Bush Sent: Tue 2/26/2008 3:32 PM To: Member Services Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal > On 21 February 2008, the ARIN Advisory Council (AC) concluded its > initial review of "IPv4 Transfer Policy Proposal" and accepted it as a > formal policy proposal for discussion by the community. > ... > Author: ARIN Advisory Council i can't decide if this is merely amusing or should bother me. i think i will write it of to our being such a rule/process obsessed culture. randy _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Tue Feb 26 17:17:09 2008 From: randy at psg.com (Randy Bush) Date: Wed, 27 Feb 2008 06:17:09 +0800 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: References: <47C41522.2040304@arin.net> <47C4857A.8000105@psg.com> Message-ID: <47C48FE5.9050004@psg.com> Bill Darte wrote: > Can I safely assume that your comments are AGAINST the proposal? as i do not understand your threat model, i can not speak to your safety. i am surprised that you [ need to ] see my comment as either for or against. it was intended to speak to the process, not the proposal. the sub-text was, since the AC is the process approval body for proposals, _perhaps_ the AC should not be making proposals itself. my opinions of the proposal have been stated previously. randy, who claims no exemption to our culture's rule obsession From oberman at es.net Tue Feb 26 17:19:01 2008 From: oberman at es.net (Kevin Oberman) Date: Tue, 26 Feb 2008 14:19:01 -0800 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: Your message of "Tue, 26 Feb 2008 16:06:15 CST." Message-ID: <20080226221901.508E54500E@ptavv.es.net> Randy will surely correct me if I am wrong, but I think it is the exact text quoted which elicited his response, not the proposal, itself. -- 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 > Date: Tue, 26 Feb 2008 16:06:15 -0600 > From: "Bill Darte" > Sender: ppml-bounces at arin.net > > Can I safely assume that your comments are AGAINST the proposal? > > We on the AC would like to keep track of those favoring and against each proposal, as always. > > Bill Darte > > > -----Original Message----- > From: ppml-bounces at arin.net on behalf of Randy Bush > Sent: Tue 2/26/2008 3:32 PM > To: Member Services > Cc: ppml at arin.net > Subject: Re: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal > > > On 21 February 2008, the ARIN Advisory Council (AC) concluded its > > initial review of "IPv4 Transfer Policy Proposal" and accepted it as a > > formal policy proposal for discussion by the community. > > ... > > Author: ARIN Advisory Council > > i can't decide if this is merely amusing or should bother me. i think i > will write it of to our being such a rule/process obsessed culture. > > randy > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From BillD at cait.wustl.edu Tue Feb 26 17:55:58 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 26 Feb 2008 16:55:58 -0600 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal References: <47C41522.2040304@arin.net> <47C4857A.8000105@psg.com> <47C48FE5.9050004@psg.com> Message-ID: Ah, but the role of the AC is not now, nor has it ever been limited to process shepherding. bd -----Original Message----- From: ppml-bounces at arin.net on behalf of Randy Bush Sent: Tue 2/26/2008 4:17 PM To: Bill Darte Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal Bill Darte wrote: > Can I safely assume that your comments are AGAINST the proposal? as i do not understand your threat model, i can not speak to your safety. i am surprised that you [ need to ] see my comment as either for or against. it was intended to speak to the process, not the proposal. the sub-text was, since the AC is the process approval body for proposals, _perhaps_ the AC should not be making proposals itself. my opinions of the proposal have been stated previously. randy, who claims no exemption to our culture's rule obsession _______________________________________________ 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 jsullivan at hbk.com Wed Feb 27 13:53:21 2008 From: jsullivan at hbk.com (Jake Sullivan) Date: Wed, 27 Feb 2008 12:53:21 -0600 Subject: [ppml] (no subject) Message-ID: jsullivan at hbk.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.hannigan at batelnet.bs Wed Feb 27 23:35:30 2008 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Wed, 27 Feb 2008 23:35:30 -0500 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal Message-ID: <47c63a12.2a6.72ac.1909@batelnet.bs> ----- Original Message ----- From: Randy Bush To: Member Services Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal Date: Wed, 27 Feb 2008 05:32:42 +0800 > > On 21 February 2008, the ARIN Advisory Council (AC) > > concluded its initial review of "IPv4 Transfer Policy > > Proposal" and accepted it as a formal policy proposal > > for discussion by the community. ... > > Author: ARIN Advisory Council > > i can't decide if this is merely amusing or should bother > me. i think i will write it of to our being such a > rule/process obsessed culture. > +1. -M< From martin.hannigan at batelnet.bs Wed Feb 27 23:59:43 2008 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Wed, 27 Feb 2008 23:59:43 -0500 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal Message-ID: <47c63fbf.e3.730f.15452@batelnet.bs> ----- Original Message ----- From: "Bill Darte" To: "Randy Bush" Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal Date: Tue, 26 Feb 2008 16:55:58 -0600 > Ah, but the role of the AC is not now, nor has it ever > been limited to process shepherding. > > bd > Hi Bill! The AC should not be undervalued. Still, I think that the AC, as a whole, should reconsider putting forth policy. Bottom up policy shouldn't come from the middle. Thanks, -M< From jcurran at istaff.org Thu Feb 28 01:09:43 2008 From: jcurran at istaff.org (John Curran) Date: Thu, 28 Feb 2008 01:09:43 -0500 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <47c63fbf.e3.730f.15452@batelnet.bs> References: <47c63fbf.e3.730f.15452@batelnet.bs> Message-ID: At 11:59 PM -0500 2/27/08, Martin Hannigan wrote: >The AC should not be undervalued. Still, I think that the >AC, as a whole, should reconsider putting forth policy. >Bottom up policy shouldn't come from the middle. As long as independent proposals get a fair shake, I see no reason for the AC not to put forth proposals. They are, after all, elected based on their knowledge of addressing and related issues. In this particular case, the ARIN Board asked the AC to consider implications of IPv4 transfer policies and make a proposal for discussion purposes. /John From BillD at cait.wustl.edu Thu Feb 28 07:12:08 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Thu, 28 Feb 2008 06:12:08 -0600 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal References: <47c63fbf.e3.730f.15452@batelnet.bs> Message-ID: The critical difference between what Mary and what John say below...and the critical difference to the industry....I won't say the 'bottom'...is that the AC did not put forth policy...they crafted a proposal for the consideration of the industry to boo out of existence or embrace as they see fit. I see no harm in this and in fact see that this lives up to the thought and consideration that those electing the AC as knowledgeble and thoughtful individuals..and representatives...would expect. bd -----Original Message----- From: ppml-bounces at arin.net on behalf of John Curran Sent: Thu 2/28/2008 12:09 AM To: Martin Hannigan Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal At 11:59 PM -0500 2/27/08, Martin Hannigan wrote: >The AC should not be undervalued. Still, I think that the >AC, as a whole, should reconsider putting forth policy. >Bottom up policy shouldn't come from the middle. As long as independent proposals get a fair shake, I see no reason for the AC not to put forth proposals. They are, after all, elected based on their knowledge of addressing and related issues. In this particular case, the ARIN Board asked the AC to consider implications of IPv4 transfer policies and make a proposal for discussion purposes. /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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From BillD at cait.wustl.edu Thu Feb 28 07:19:31 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Thu, 28 Feb 2008 06:19:31 -0600 Subject: [ppml] Apologies - MarTy... Message-ID: Seems I missed a T in referring to MarTy Hannigan in my previous message. I apoligize for the omission and assure that I was neither trying to score political points as is happening all around us in current race to the white house, no slight or anger my friend and colleague.... bd -------------- next part -------------- An HTML attachment was scrubbed... URL: From cliffb at cjbsys.bdb.com Thu Feb 28 10:11:33 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Thu, 28 Feb 2008 10:11:33 -0500 (EST) Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal Message-ID: <200802281511.m1SFBXnO024037@cjbsys.bdb.com> I think the idea of this proposal is necessary but I don't think ARIN should be in the business of assisting transfer sales of IP addresses unless they have no assets to fill a legitmate request. It may be implied somewhere that ARIN will not allow a sale if they have assets available but I didn't see it. Therefore I'm not convinced that "exhaustion of the IANA IPv4 free pool" is the correct time. I think transfer sales should start the first time ARIN can't meet a legitmate request and even after that, should only be allowed when ARIN doesn't have the particular size requested available. Proposal 2007-17 is supposed to encourage asset holders to return unused blocks but 2008-2 unless carefully managed could encourage hording in hopes of future sales. This is pretty much what I was trying to say in my prior post and I hope it's clearer this time. 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 martin.hannigan at batelnet.bs Thu Feb 28 10:00:46 2008 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Thu, 28 Feb 2008 10:00:46 -0500 Subject: [ppml] Apologies - MarTy... Message-ID: <47c6cc9e.2ba.499.13426@batelnet.bs> ----- Original Message ----- From: "Bill Darte" To: Subject: [ppml] Apologies - MarTy... Date: Thu, 28 Feb 2008 06:19:31 -0600 > Seems I missed a T in referring to MarTy Hannigan in my > previous message. I apoligize for the omission and assure > that I was neither trying to score political points as is > happening all around us in current race to the white house > , no slight or anger my friend and colleague.... > > bd Hi Bill! No worries! It's better than being called 'Nancy Boy'! :-) From martin.hannigan at batelnet.bs Thu Feb 28 10:12:59 2008 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Thu, 28 Feb 2008 10:12:59 -0500 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal Message-ID: <47c6cf7b.1de.52d.6@batelnet.bs> ----- Original Message ----- From: John Curran To: "Martin Hannigan" Cc: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal Date: Thu, 28 Feb 2008 01:09:43 -0500 > At 11:59 PM -0500 2/27/08, Martin Hannigan wrote: > >The AC should not be undervalued. Still, I think that the > >AC, as a whole, should reconsider putting forth policy. > >Bottom up policy shouldn't come from the middle. > > As long as independent proposals get a fair shake, I > see no reason for the AC not to put forth proposals. [ clip ] Hi John! It may appear that a policy isn't going to get a fair shake since the AC may be viewed as having rubber stamped it. I don't believe that our current AC would do that, but I think appearance matters. Assigning the Chair's name as author may be "better". Thanks for the feedback! Best, Marty From owen at delong.com Thu Feb 28 10:50:14 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Feb 2008 07:50:14 -0800 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <47c6cf7b.1de.52d.6@batelnet.bs> References: <47c6cf7b.1de.52d.6@batelnet.bs> Message-ID: <93ADDB2A-D59D-490F-BACB-AA5D82AAB2C6@delong.com> > > >> At 11:59 PM -0500 2/27/08, Martin Hannigan wrote: >>> The AC should not be undervalued. Still, I think that the >>> AC, as a whole, should reconsider putting forth policy. >>> Bottom up policy shouldn't come from the middle. >> >> As long as independent proposals get a fair shake, I >> see no reason for the AC not to put forth proposals. > > [ clip ] > > Hi John! > > It may appear that a policy isn't going to get a fair shake > since the AC may be viewed as having rubber stamped it. I > don't believe that our current AC would do that, but I think > appearance matters. Marty, I don't think this is a risk with this policy. First, there are enough AC members who have publicly described reservations, concerns, and, in some cases outright opposition to the proposal that I can't see this looking like a rubber stamp, even IF it gets adopted. Second, when the AC passes a proposal along to the BoT, we do so with a roll call vote. I think that a unanimous vote in favor of this proposal from the AC is highly unlikely. Third, if the BoT perceives a rubber stamp from the AC contrary to the will of the community, the BoT would certainly exercise their authority to remand the proposal as having failed to follow the IRPEP. The two proposals which were remanded after the ABQ meeting show that the board has no hesitation to question AC decisions where they feel appropriate. For my part, the current draft of the proposal represents a good starting point for the AC to discuss the issue with the community. I remain greatly conflicted about the idea of a market for the transfer of IPv4 address space. If you had asked me about such a proposal up until a year ago, I would have stated outright opposition. Today, looking at the other forces likely to be at work after IANA free pool exhaustion, I'm not so sure it is a bad idea. I'm also not at all sure it's a good idea. The only thing I am sure of is that this question needs a great deal of discussion in the community prior to making a decision to move forward with such a major change in policy. Further, I'm sure that if we are to have that discussion, it is very urgent we start the discussion immediately. I believe that the AC drafted this proposal as a mechanism to facilitate that discussion in the community and that it represents exactly that. An opportunity to discuss the issue. I cannot speak for the entire AC, but, certainly my intent in participating in the development process on this proposal was to get the issue before the community and gather feedback for the AC. I am, at this time, neither recommending nor opposing this proposal as I feel I simply don't have enough data to make an informed decision on the issue. As a member of the community, if I had to vote today, I'd vote no. Not because I think the proposal is a bad idea, but, because I am not sufficiently convinced that it is a good idea. I do not believe it would be appropriate for the chair to be the author of this proposal. The entire AC has put considerable effort into developing and refining this proposal, and, we continue to discuss and debate it both here and amongst the AC as authors. Having the chair listed as the author would obscure that process from the public view and would be, in my opinion, contrary to the spirit of openness that is key to our policy development process. Owen From stephen at sprunk.org Thu Feb 28 10:22:01 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 28 Feb 2008 09:22:01 -0600 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal References: <200802281511.m1SFBXnO024037@cjbsys.bdb.com> Message-ID: <005601c87a21$471e80f0$563816ac@atlanta.polycom.com> Thus spake "Cliff Bedore" >I think the idea of this proposal is necessary but I don't think ARIN >should > be in the business of assisting transfer sales of IP addresses unless they > have no assets to fill a legitmate request. It may be implied somewhere > that > ARIN will not allow a sale if they have assets available but I didn't see > it. > Therefore I'm not convinced that "exhaustion of the IANA IPv4 free pool" > is > the correct time. I think transfer sales should start the first time ARIN > can't meet a legitmate request and even after that, should only be allowed > when ARIN doesn't have the particular size requested available. While I agree with this comment in principle, it isn't practical. There will be bugs in the process that need to be ironed out, and we need people to start qualifying for transfers (in and out) prior to them actually needing to take place to ensure an orderly transition. (If we adopt this or a similar proposal, which I'm still on the fence about.) S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From bicknell at ufp.org Thu Feb 28 10:59:53 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 28 Feb 2008 10:59:53 -0500 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <200802281511.m1SFBXnO024037@cjbsys.bdb.com> References: <200802281511.m1SFBXnO024037@cjbsys.bdb.com> Message-ID: <20080228155953.GA92342@ussenterprise.ufp.org> In a message written on Thu, Feb 28, 2008 at 10:11:33AM -0500, Cliff Bedore wrote: > I think the idea of this proposal is necessary but I don't think ARIN should > be in the business of assisting transfer sales of IP addresses unless they > have no assets to fill a legitmate request. It may be implied somewhere that > ARIN will not allow a sale if they have assets available but I didn't see it. > Therefore I'm not convinced that "exhaustion of the IANA IPv4 free pool" is > the correct time. I think transfer sales should start the first time ARIN > can't meet a legitmate request and even after that, should only be allowed > when ARIN doesn't have the particular size requested available. In one of our sessions someone proposed "the first time ARIN could not fill a request"; and we were in fact informed that had already occurred. While a bit of a technicality, I suspect the issue was ARIN did not have enough free space for a large request, and had to go back to IANA for more space which prevented them from filling the request right away. The problem with using the date ARIN can't make a sale is that it is different for different people, and in fact may not be what you request. ARIN could keep a table of "we can make /18, /19, and /20's" on the web site, but making a /20 may use up the last /18 and take it away. Or, someone may ask for a /20, work with ARIN staff who only sees justification for a /21, but there are none of those left. If someone was basing their decision on the availability of /20's that won't work so well. Lastly, if we wait for ARIN to be unavailable and then spin up the system described in 2008-2 there will likely be a small gap during which no one can get space. While I believe ARIN staff can manage the transition quite nicely, there is a level of public education, putting information on the web, having staff process a new type of request, etc. I think many on the AC wanted to err on th side of a small amount of overlap rather than a small gap in service. Do any of those reasons alter your opinion, or do you still believe IANA Free Pool exhaustion is the wrong time? -- 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 Thu Feb 28 11:16:58 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 28 Feb 2008 11:16:58 -0500 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <47c6cf7b.1de.52d.6@batelnet.bs> References: <47c6cf7b.1de.52d.6@batelnet.bs> Message-ID: <20080228161658.GB92342@ussenterprise.ufp.org> In a message written on Thu, Feb 28, 2008 at 10:12:59AM -0500, Martin Hannigan wrote: > Assigning the Chair's name as author may be "better". Speaking as Chair, I did not author the proposal. This isn't a case of one or two AC members brining a proposal and asking for the entire AC's name to be on it. The AC held multiple sessions on this subject and worked together to develop this proposal. It is truly a group effort, with portions of the proposal written by different people. As a policy moves through the process the AC considers it in two very different lights. Our "initial review" is done simply to make sure the policy is ready to be discussed. At this stage we reject things because they are poorly written, hard to understand, or we feel the issue has been beaten to death and there's no reason to discuss it further. As a gateway to formal discussion the bar is relatively low. That's the step that has already been taken. Later in the process the AC will meet again, consider all of the discussion on PPML and at the meeting and decide if the proposal achieved community consensus. The AC takes this part of the job quite seriously, and I have every confidence that the AC will only move this proposal along if there is strong community support. If there is still worry though, there are still two more ways out. After the AC decides to move it along it goes to last call where the community can point out that the process was not followed and document their concerns. Those comments initially go back to the AC. Were the community to say we got it wrong I'm sure the AC would reconsider their actions. Last, but not least, once all of this is done it must go to the Board. One of their many checks is that the IRPEP was followed. The Board has returned proposals to the AC before with concerns over the process and asked for clarification. I have no doubt that if AC were to "rubber stamp" the proposal the Board would refuse to implement it. Were I not on the AC I would likely also be a skeptic. I won't ask anyone to just "trust us", but rather would simply ask that you monitor the process and speak up if you see the AC going against the will of the community. Right now it is much more important we discuss the merits of a very important proposal for the future of our entire industry. -- 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 Thu Feb 28 14:11:18 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Thu, 28 Feb 2008 14:11:18 -0500 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <20080228155953.GA92342@ussenterprise.ufp.org> References: <200802281511.m1SFBXnO024037@cjbsys.bdb.com> <20080228155953.GA92342@ussenterprise.ufp.org> Message-ID: <47C70756.4030409@cjbsys.bdb.com> Leo Bicknell wrote: > In a message written on Thu, Feb 28, 2008 at 10:11:33AM -0500, Cliff Bedore wrote: > >> I think the idea of this proposal is necessary but I don't think ARIN should >> be in the business of assisting transfer sales of IP addresses unless they >> have no assets to fill a legitmate request. It may be implied somewhere that >> ARIN will not allow a sale if they have assets available but I didn't see it. >> Therefore I'm not convinced that "exhaustion of the IANA IPv4 free pool" is >> the correct time. I think transfer sales should start the first time ARIN >> can't meet a legitmate request and even after that, should only be allowed >> when ARIN doesn't have the particular size requested available. >> > > In one of our sessions someone proposed "the first time ARIN could > not fill a request"; and we were in fact informed that had already > occurred. While a bit of a technicality, I suspect the issue was > ARIN did not have enough free space for a large request, and had > to go back to IANA for more space which prevented them from filling > the request right away. > > The problem with using the date ARIN can't make a sale is that it > is different for different people, and in fact may not be what you > request. ARIN could keep a table of "we can make /18, /19, and > /20's" on the web site, but making a /20 may use up the last /18 > and take it away. Or, someone may ask for a /20, work with ARIN > staff who only sees justification for a /21, but there are none of > those left. If someone was basing their decision on the availability > of /20's that won't work so well. > I realize that ARIN resources and user resources for sale will happen in an overlapping manner. I realize it is a complex problem due to considerations such as splitting a large block to handle a small block vs transfer/sale of a user block of the right size. Probably more complex than I can imagine right now but ARIN is also chartered(? whatever term is correct) to get users to convert to IPv6 and spending lots of time and money to extend IPv4 seems to be contrary to that goal. I'm not sure anyone coming in for addresses that late in the game shouldn't suffer a few delays in getting addresses. It's not like they haven't had ample warning about a shortage. > Lastly, if we wait for ARIN to be unavailable and then spin up the > system described in 2008-2 there will likely be a small gap during > which no one can get space. While I believe ARIN staff can manage > the transition quite nicely, there is a level of public education, > putting information on the web, having staff process a new type of > request, etc. I think many on the AC wanted to err on th side of > a small amount of overlap rather than a small gap in service. > I don't think ARIN has to wait to set up the procedures. I just think they should wait to start using them. :-) One problem with listing end user blocks for sale is that technically, the end user can no longer justify their current allocation and it would seem that ARIN would be justified in reclaiming them is a fair number of cases rather than approving a transfer sale. > Do any of those reasons alter your opinion, or do you still believe > IANA Free Pool exhaustion is the wrong time? > I understand your argument but I think the answer has to decided based on whether ARIN is more interested in promoting the switch to v6 or band-aiding v4 for as long as possible. ARIN does seem to have something of a split personality toward perpetuating v4 and promoting v6. This proposal seems to me to be bending over backwards toward perpetuating v4. The proposals to allow/get legacy users to use v6 and sign RSAs however seems to have some dis-incentives to them. If ARIN really wanted legacy users to sign an RSA and convert to v6, they would allow them to qualify for a v6 allocation equivalent to the v4 size they received during the legacy period without regard to whether they meet the current requirements. As an example, I have a /24 PI which was granted long before ARIN ever came along. I currently don't meet the 25/50% rule to justify that /24 but I did meet the requirements at the time it was issued. I would think that ARIN could offer the minimum v6 allocation to any /24 (or maybe any) legacy holder who is willing to sign the RSA and join the fold. I don't think it would be a big number since I expect many of the legacy addresses have been abandoned and many who are active would qualify under current rules but it would demonstrate ARIN's seriousness about getting v6 started. This should probably be a separate discussion but it fits in with (at least my perception of) the ARIN split personality aspect of the 2008-2 Also note that in reality, I'll probably be retired and in a home before my /24 will cease to be useful. I'd like to get the v6 space to use for learning/testing and maybe forcing my upstream ISP to start routing v6. If enough people did that, it would help speed the transition. Cliff > > ------------------------------------------------------------------------ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Feb 28 14:44:52 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Feb 2008 11:44:52 -0800 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <47C70756.4030409@cjbsys.bdb.com> References: <200802281511.m1SFBXnO024037@cjbsys.bdb.com> <20080228155953.GA92342@ussenterprise.ufp.org> <47C70756.4030409@cjbsys.bdb.com> Message-ID: > I realize that ARIN resources and user resources for sale will > happen in an overlapping manner. I realize it is a complex problem > due to considerations such as splitting a large block to handle a > small block vs transfer/sale of a user block of the right size. > Probably more complex than I can imagine right now but ARIN is also > chartered(? whatever term is correct) to get users to convert to > IPv6 and spending lots of time and money to extend IPv4 seems to be > contrary to that goal. I'm not sure anyone coming in for addresses > that late in the game shouldn't suffer a few delays in getting > addresses. It's not like they haven't had ample warning about a > shortage. Could you please point to the document where it states that ARIN is charged with encouraging one protocol vs. another? I believe that ARIN is charged with the stewardship of address space in the ARIN service region. While I would agree that IPv4 has a finite number of addresses and a limited ability to support the continued growth of the internet, I also believe that ARIN has a protocol-independent obligation to provide the best stewardship possible over ALL IP Number resources (IPv6, IPv4, and ASN) so long as the community is using them. > > I understand your argument but I think the answer has to decided > based on whether ARIN is more interested in promoting the switch to > v6 or band-aiding v4 for as long as possible. > You say that as if they are mutually exclusive. I am not convinced that they always are. > ARIN does seem to have something of a split personality toward > perpetuating v4 and promoting v6. This proposal seems to me to be > bending over backwards toward perpetuating v4. The proposals to > allow/get legacy users to use v6 and sign RSAs however seems to have > some dis-incentives to them. If ARIN really wanted legacy users to > sign an RSA and convert to v6, they would allow them to qualify for > a v6 allocation equivalent to the v4 size they received during the > legacy period without regard to whether they meet the current > requirements. As an example, I have a /24 PI which was granted long > before ARIN ever came along. I currently don't meet the 25/50% rule > to justify that /24 but I did meet the requirements at the time it > was issued. I would think that ARIN could offer the minimum v6 > allocation to any /24 (or maybe any) legacy holder who is willing to > sign the RSA and join the fold. I don't think it would be a big > number since I expect many of the legacy addresses have been > abandoned and many who are active would qualify under current rules > but it would demonstrate ARIN's seriousness about getting v6 > started. This should probably be a separate discussion but it fits > in with (at least my perception of) the ARIN split personality > aspect of the 2008-2 In this respect, you are speaking of ARIN as if it is some distant body independent from you. If you feel such a policy would be accepted by the community and is of benefit, I encourage you to download the policy template from the ARIN web site, review the Internet Resource Policy Evaluation Process at http://www.arin.net/policy/irpep.html, complete the template and submit it as a proposed policy. Any member of the community may submit a proposed policy. If you have any questions or would like further assistance in this, please feel free to contact me, or, any other member of the ARIN AC. This is one of the key reasons we have an AC. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleibrand at internap.com Thu Feb 28 14:57:07 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 28 Feb 2008 11:57:07 -0800 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <47C70756.4030409@cjbsys.bdb.com> References: <200802281511.m1SFBXnO024037@cjbsys.bdb.com> <20080228155953.GA92342@ussenterprise.ufp.org> <47C70756.4030409@cjbsys.bdb.com> Message-ID: <47C71213.90709@internap.com> Cliff, Thanks for your feedback on the IPv4 transfer policy proposal. I'd be interested in your feedback on the Safe Harbor language in the policy proposal, as it directly relates to what you said about transferors no longer needing their space. On the issue of PIv6 space for IPv4 holders, the policy proposal to allow that did indeed get consensus at ABQ. Unfortunately, due to issues with wordsmithing on the floor of the meeting, final approval has been delayed until we can bring the revised wording back at the Denver meeting and make sure no one feels it represents a significant change from the intent of the original proposal and what got consensus at ABQ. -Scott Cliff Bedore wrote: > Leo Bicknell wrote: >> In a message written on Thu, Feb 28, 2008 at 10:11:33AM -0500, Cliff Bedore wrote: >> >>> I think the idea of this proposal is necessary but I don't think ARIN should >>> be in the business of assisting transfer sales of IP addresses unless they >>> have no assets to fill a legitmate request. It may be implied somewhere that >>> ARIN will not allow a sale if they have assets available but I didn't see it. >>> Therefore I'm not convinced that "exhaustion of the IANA IPv4 free pool" is >>> the correct time. I think transfer sales should start the first time ARIN >>> can't meet a legitmate request and even after that, should only be allowed >>> when ARIN doesn't have the particular size requested available. >>> >> >> In one of our sessions someone proposed "the first time ARIN could >> not fill a request"; and we were in fact informed that had already >> occurred. While a bit of a technicality, I suspect the issue was >> ARIN did not have enough free space for a large request, and had >> to go back to IANA for more space which prevented them from filling >> the request right away. >> >> The problem with using the date ARIN can't make a sale is that it >> is different for different people, and in fact may not be what you >> request. ARIN could keep a table of "we can make /18, /19, and >> /20's" on the web site, but making a /20 may use up the last /18 >> and take it away. Or, someone may ask for a /20, work with ARIN >> staff who only sees justification for a /21, but there are none of >> those left. If someone was basing their decision on the availability >> of /20's that won't work so well. >> > I realize that ARIN resources and user resources for sale will happen in > an overlapping manner. I realize it is a complex problem due to > considerations such as splitting a large block to handle a small block > vs transfer/sale of a user block of the right size. Probably more > complex than I can imagine right now but ARIN is also chartered(? > whatever term is correct) to get users to convert to IPv6 and spending > lots of time and money to extend IPv4 seems to be contrary to that > goal. I'm not sure anyone coming in for addresses that late in the game > shouldn't suffer a few delays in getting addresses. It's not like they > haven't had ample warning about a shortage. >> Lastly, if we wait for ARIN to be unavailable and then spin up the >> system described in 2008-2 there will likely be a small gap during >> which no one can get space. While I believe ARIN staff can manage >> the transition quite nicely, there is a level of public education, >> putting information on the web, having staff process a new type of >> request, etc. I think many on the AC wanted to err on th side of >> a small amount of overlap rather than a small gap in service. >> > > I don't think ARIN has to wait to set up the procedures. I just think > they should wait to start using them. :-) One problem with listing end > user blocks for sale is that technically, the end user can no longer > justify their current allocation and it would seem that ARIN would be > justified in reclaiming them is a fair number of cases rather than > approving a transfer sale. >> Do any of those reasons alter your opinion, or do you still believe >> IANA Free Pool exhaustion is the wrong time? >> > > I understand your argument but I think the answer has to decided based > on whether ARIN is more interested in promoting the switch to v6 or > band-aiding v4 for as long as possible. > > ARIN does seem to have something of a split personality toward > perpetuating v4 and promoting v6. This proposal seems to me to be > bending over backwards toward perpetuating v4. The proposals to > allow/get legacy users to use v6 and sign RSAs however seems to have > some dis-incentives to them. If ARIN really wanted legacy users to sign > an RSA and convert to v6, they would allow them to qualify for a v6 > allocation equivalent to the v4 size they received during the legacy > period without regard to whether they meet the current requirements. As > an example, I have a /24 PI which was granted long before ARIN ever came > along. I currently don't meet the 25/50% rule to justify that /24 but I > did meet the requirements at the time it was issued. I would think that > ARIN could offer the minimum v6 allocation to any /24 (or maybe any) > legacy holder who is willing to sign the RSA and join the fold. I don't > think it would be a big number since I expect many of the legacy > addresses have been abandoned and many who are active would qualify > under current rules but it would demonstrate ARIN's seriousness about > getting v6 started. This should probably be a separate discussion but > it fits in with (at least my perception of) the ARIN split personality > aspect of the 2008-2 > > Also note that in reality, I'll probably be retired and in a home before > my /24 will cease to be useful. I'd like to get the v6 space to use for > learning/testing and maybe forcing my upstream ISP to start routing v6. > If enough people did that, it would help speed the transition. > > Cliff >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN Public Policy >> Mailing List (PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml >> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 cliffb at cjbsys.bdb.com Thu Feb 28 16:06:19 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Thu, 28 Feb 2008 16:06:19 -0500 (EST) Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <47C71213.90709@internap.com> from "Scott Leibrand" at Feb 28, 2008 11:57:07 AM Message-ID: <200802282106.m1SL6J3o027069@cjbsys.bdb.com> > > Cliff, > > Thanks for your feedback on the IPv4 transfer policy proposal. > > I'd be interested in your feedback on the Safe Harbor language in the > policy proposal, as it directly relates to what you said about > transferors no longer needing their space. I guess I'd have to say this strikes me as contrary to what I understand to be current policy of "efficient utilization" requirements. It may be that in some cases, selling a small section of an allocation wouldn't violate "efficient utilization" but I think in many cases it would and ARIN would be simultaneously requiring the efficiency and letting people not be efficient if they are selling numbers for a profit. --- >From 6.4.1 6.4.1. Address space not to be considered property It is contrary to the goals of this document and is not in the interests of the Internet community as a whole for address space to be considered freehold property. --- Whatever the proposed policy says, when someone can get paid for transferring something from themselves to another, it strikes me that that something is effectively property. > > On the issue of PIv6 space for IPv4 holders, the policy proposal to > allow that did indeed get consensus at ABQ. Unfortunately, due to > issues with wordsmithing on the floor of the meeting, final approval has > been delayed until we can bring the revised wording back at the Denver > meeting and make sure no one feels it represents a significant change > from the intent of the original proposal and what got consensus at ABQ. Depending upon the outcome of that policy, I may submit a proposal to change that. Cliff > > -Scott > > Cliff Bedore wrote: > > Leo Bicknell wrote: > >> In a message written on Thu, Feb 28, 2008 at 10:11:33AM -0500, Cliff Bedore wrote: > >> > >>> I think the idea of this proposal is necessary but I don't think ARIN should > >>> be in the business of assisting transfer sales of IP addresses unless they > >>> have no assets to fill a legitmate request. It may be implied somewhere that > >>> ARIN will not allow a sale if they have assets available but I didn't see it. > >>> Therefore I'm not convinced that "exhaustion of the IANA IPv4 free pool" is > >>> the correct time. I think transfer sales should start the first time ARIN > >>> can't meet a legitmate request and even after that, should only be allowed > >>> when ARIN doesn't have the particular size requested available. > >>> > >> > >> In one of our sessions someone proposed "the first time ARIN could > >> not fill a request"; and we were in fact informed that had already > >> occurred. While a bit of a technicality, I suspect the issue was > >> ARIN did not have enough free space for a large request, and had > >> to go back to IANA for more space which prevented them from filling > >> the request right away. > >> > >> The problem with using the date ARIN can't make a sale is that it > >> is different for different people, and in fact may not be what you > >> request. ARIN could keep a table of "we can make /18, /19, and > >> /20's" on the web site, but making a /20 may use up the last /18 > >> and take it away. Or, someone may ask for a /20, work with ARIN > >> staff who only sees justification for a /21, but there are none of > >> those left. If someone was basing their decision on the availability > >> of /20's that won't work so well. > >> > > I realize that ARIN resources and user resources for sale will happen in > > an overlapping manner. I realize it is a complex problem due to > > considerations such as splitting a large block to handle a small block > > vs transfer/sale of a user block of the right size. Probably more > > complex than I can imagine right now but ARIN is also chartered(? > > whatever term is correct) to get users to convert to IPv6 and spending > > lots of time and money to extend IPv4 seems to be contrary to that > > goal. I'm not sure anyone coming in for addresses that late in the game > > shouldn't suffer a few delays in getting addresses. It's not like they > > haven't had ample warning about a shortage. > >> Lastly, if we wait for ARIN to be unavailable and then spin up the > >> system described in 2008-2 there will likely be a small gap during > >> which no one can get space. While I believe ARIN staff can manage > >> the transition quite nicely, there is a level of public education, > >> putting information on the web, having staff process a new type of > >> request, etc. I think many on the AC wanted to err on th side of > >> a small amount of overlap rather than a small gap in service. > >> > > > > I don't think ARIN has to wait to set up the procedures. I just think > > they should wait to start using them. :-) One problem with listing end > > user blocks for sale is that technically, the end user can no longer > > justify their current allocation and it would seem that ARIN would be > > justified in reclaiming them is a fair number of cases rather than > > approving a transfer sale. > >> Do any of those reasons alter your opinion, or do you still believe > >> IANA Free Pool exhaustion is the wrong time? > >> > > > > I understand your argument but I think the answer has to decided based > > on whether ARIN is more interested in promoting the switch to v6 or > > band-aiding v4 for as long as possible. > > > > ARIN does seem to have something of a split personality toward > > perpetuating v4 and promoting v6. This proposal seems to me to be > > bending over backwards toward perpetuating v4. The proposals to > > allow/get legacy users to use v6 and sign RSAs however seems to have > > some dis-incentives to them. If ARIN really wanted legacy users to sign > > an RSA and convert to v6, they would allow them to qualify for a v6 > > allocation equivalent to the v4 size they received during the legacy > > period without regard to whether they meet the current requirements. As > > an example, I have a /24 PI which was granted long before ARIN ever came > > along. I currently don't meet the 25/50% rule to justify that /24 but I > > did meet the requirements at the time it was issued. I would think that > > ARIN could offer the minimum v6 allocation to any /24 (or maybe any) > > legacy holder who is willing to sign the RSA and join the fold. I don't > > think it would be a big number since I expect many of the legacy > > addresses have been abandoned and many who are active would qualify > > under current rules but it would demonstrate ARIN's seriousness about > > getting v6 started. This should probably be a separate discussion but > > it fits in with (at least my perception of) the ARIN split personality > > aspect of the 2008-2 > > > > Also note that in reality, I'll probably be retired and in a home before > > my /24 will cease to be useful. I'd like to get the v6 space to use for > > learning/testing and maybe forcing my upstream ISP to start routing v6. > > If enough people did that, it would help speed the transition. > > > > Cliff > >> > >> ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to the ARIN Public Policy > >> Mailing List (PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/ppml > >> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > >> > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 mjackson at fhlb-of.com Thu Feb 28 15:55:43 2008 From: mjackson at fhlb-of.com (Jackson, Matt) Date: Thu, 28 Feb 2008 15:55:43 -0500 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <200802282106.m1SL6J3o027069@cjbsys.bdb.com> References: <47C71213.90709@internap.com> from "Scott Leibrand" at Feb 28, 2008 11:57:07 AM <200802282106.m1SL6J3o027069@cjbsys.bdb.com> Message-ID: unsubscribe -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Cliff Bedore Sent: Thursday, February 28, 2008 4:06 PM To: Scott Leibrand Cc: PPML Subject: Re: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal > > Cliff, > > Thanks for your feedback on the IPv4 transfer policy proposal. > > I'd be interested in your feedback on the Safe Harbor language in the > policy proposal, as it directly relates to what you said about > transferors no longer needing their space. I guess I'd have to say this strikes me as contrary to what I understand to be current policy of "efficient utilization" requirements. It may be that in some cases, selling a small section of an allocation wouldn't violate "efficient utilization" but I think in many cases it would and ARIN would be simultaneously requiring the efficiency and letting people not be efficient if they are selling numbers for a profit. --- >From 6.4.1 6.4.1. Address space not to be considered property It is contrary to the goals of this document and is not in the interests of the Internet community as a whole for address space to be considered freehold property. --- Whatever the proposed policy says, when someone can get paid for transferring something from themselves to another, it strikes me that that something is effectively property. > > On the issue of PIv6 space for IPv4 holders, the policy proposal to > allow that did indeed get consensus at ABQ. Unfortunately, due to > issues with wordsmithing on the floor of the meeting, final approval has > been delayed until we can bring the revised wording back at the Denver > meeting and make sure no one feels it represents a significant change > from the intent of the original proposal and what got consensus at ABQ. Depending upon the outcome of that policy, I may submit a proposal to change that. Cliff > > -Scott > > Cliff Bedore wrote: > > Leo Bicknell wrote: > >> In a message written on Thu, Feb 28, 2008 at 10:11:33AM -0500, Cliff Bedore wrote: > >> > >>> I think the idea of this proposal is necessary but I don't think ARIN should > >>> be in the business of assisting transfer sales of IP addresses unless they > >>> have no assets to fill a legitmate request. It may be implied somewhere that > >>> ARIN will not allow a sale if they have assets available but I didn't see it. > >>> Therefore I'm not convinced that "exhaustion of the IANA IPv4 free pool" is > >>> the correct time. I think transfer sales should start the first time ARIN > >>> can't meet a legitmate request and even after that, should only be allowed > >>> when ARIN doesn't have the particular size requested available. > >>> > >> > >> In one of our sessions someone proposed "the first time ARIN could > >> not fill a request"; and we were in fact informed that had already > >> occurred. While a bit of a technicality, I suspect the issue was > >> ARIN did not have enough free space for a large request, and had > >> to go back to IANA for more space which prevented them from filling > >> the request right away. > >> > >> The problem with using the date ARIN can't make a sale is that it > >> is different for different people, and in fact may not be what you > >> request. ARIN could keep a table of "we can make /18, /19, and > >> /20's" on the web site, but making a /20 may use up the last /18 > >> and take it away. Or, someone may ask for a /20, work with ARIN > >> staff who only sees justification for a /21, but there are none of > >> those left. If someone was basing their decision on the availability > >> of /20's that won't work so well. > >> > > I realize that ARIN resources and user resources for sale will happen in > > an overlapping manner. I realize it is a complex problem due to > > considerations such as splitting a large block to handle a small block > > vs transfer/sale of a user block of the right size. Probably more > > complex than I can imagine right now but ARIN is also chartered(? > > whatever term is correct) to get users to convert to IPv6 and spending > > lots of time and money to extend IPv4 seems to be contrary to that > > goal. I'm not sure anyone coming in for addresses that late in the game > > shouldn't suffer a few delays in getting addresses. It's not like they > > haven't had ample warning about a shortage. > >> Lastly, if we wait for ARIN to be unavailable and then spin up the > >> system described in 2008-2 there will likely be a small gap during > >> which no one can get space. While I believe ARIN staff can manage > >> the transition quite nicely, there is a level of public education, > >> putting information on the web, having staff process a new type of > >> request, etc. I think many on the AC wanted to err on th side of > >> a small amount of overlap rather than a small gap in service. > >> > > > > I don't think ARIN has to wait to set up the procedures. I just think > > they should wait to start using them. :-) One problem with listing end > > user blocks for sale is that technically, the end user can no longer > > justify their current allocation and it would seem that ARIN would be > > justified in reclaiming them is a fair number of cases rather than > > approving a transfer sale. > >> Do any of those reasons alter your opinion, or do you still believe > >> IANA Free Pool exhaustion is the wrong time? > >> > > > > I understand your argument but I think the answer has to decided based > > on whether ARIN is more interested in promoting the switch to v6 or > > band-aiding v4 for as long as possible. > > > > ARIN does seem to have something of a split personality toward > > perpetuating v4 and promoting v6. This proposal seems to me to be > > bending over backwards toward perpetuating v4. The proposals to > > allow/get legacy users to use v6 and sign RSAs however seems to have > > some dis-incentives to them. If ARIN really wanted legacy users to sign > > an RSA and convert to v6, they would allow them to qualify for a v6 > > allocation equivalent to the v4 size they received during the legacy > > period without regard to whether they meet the current requirements. As > > an example, I have a /24 PI which was granted long before ARIN ever came > > along. I currently don't meet the 25/50% rule to justify that /24 but I > > did meet the requirements at the time it was issued. I would think that > > ARIN could offer the minimum v6 allocation to any /24 (or maybe any) > > legacy holder who is willing to sign the RSA and join the fold. I don't > > think it would be a big number since I expect many of the legacy > > addresses have been abandoned and many who are active would qualify > > under current rules but it would demonstrate ARIN's seriousness about > > getting v6 started. This should probably be a separate discussion but > > it fits in with (at least my perception of) the ARIN split personality > > aspect of the 2008-2 > > > > Also note that in reality, I'll probably be retired and in a home before > > my /24 will cease to be useful. I'd like to get the v6 space to use for > > learning/testing and maybe forcing my upstream ISP to start routing v6. > > If enough people did that, it would help speed the transition. > > > > Cliff > >> > >> ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to the ARIN Public Policy > >> Mailing List (PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/ppml > >> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > >> > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/ _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. ************************************************************************* This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom it is addressed. This communication may contain protected or privileged material and should only be viewed by the intended recipient(s). If you are not the intended recipient or the person responsible for delivering the email to the intended recipient(s), be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. Any data contained in this e-mail has been prepared for informational purposes only unless otherwise specified. While it is believed to be correct, accuracy cannot be guaranteed. ************************************************************************* From cliffb at cjbsys.bdb.com Thu Feb 28 16:13:16 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Thu, 28 Feb 2008 16:13:16 -0500 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: References: <200802281511.m1SFBXnO024037@cjbsys.bdb.com> <20080228155953.GA92342@ussenterprise.ufp.org> <47C70756.4030409@cjbsys.bdb.com> Message-ID: <47C723EC.3050900@cjbsys.bdb.com> Owen DeLong wrote: >> I realize that ARIN resources and user resources for sale will happen >> in an overlapping manner. I realize it is a complex problem due to >> considerations such as splitting a large block to handle a small >> block vs transfer/sale of a user block of the right size. Probably >> more complex than I can imagine right now but ARIN is also >> chartered(? whatever term is correct) to get users to convert to IPv6 >> and spending lots of time and money to extend IPv4 seems to be >> contrary to that goal. I'm not sure anyone coming in for addresses >> that late in the game shouldn't suffer a few delays in getting >> addresses. It's not like they haven't had ample warning about a >> shortage. > > Could you please point to the document where it states that ARIN is > charged > with encouraging one protocol vs. another? I guess it seems to me that when you have a scarce resource and completely non-scarce resource, good stewardship would demand that emphasis be given to encouraging use of the non-scarce resource. > > I believe that ARIN is charged with the stewardship of address space > in the > ARIN service region. While I would agree that IPv4 has a finite number of > addresses and a limited ability to support the continued growth of the > internet, > I also believe that ARIN has a protocol-independent obligation to provide > the best stewardship possible over ALL IP Number resources (IPv6, > IPv4, and > ASN) so long as the community is using them. >> >> I understand your argument but I think the answer has to decided >> based on whether ARIN is more interested in promoting the switch to >> v6 or band-aiding v4 for as long as possible. >> > You say that as if they are mutually exclusive. I am not convinced > that they always are. See above > >> ARIN does seem to have something of a split personality toward >> perpetuating v4 and promoting v6. This proposal seems to me to be >> bending over backwards toward perpetuating v4. The proposals to >> allow/get legacy users to use v6 and sign RSAs however seems to have >> some dis-incentives to them. If ARIN really wanted legacy users to >> sign an RSA and convert to v6, they would allow them to qualify for a >> v6 allocation equivalent to the v4 size they received during the >> legacy period without regard to whether they meet the current >> requirements. As an example, I have a /24 PI which was granted long >> before ARIN ever came along. I currently don't meet the 25/50% rule >> to justify that /24 but I did meet the requirements at the time it >> was issued. I would think that ARIN could offer the minimum v6 >> allocation to any /24 (or maybe any) legacy holder who is willing to >> sign the RSA and join the fold. I don't think it would be a big >> number since I expect many of the legacy addresses have been >> abandoned and many who are active would qualify under current rules >> but it would demonstrate ARIN's seriousness about getting v6 >> started. This should probably be a separate discussion but it fits >> in with (at least my perception of) the ARIN split personality aspect >> of the 2008-2 > > In this respect, you are speaking of ARIN as if it is some distant > body independent from you. > > If you feel such a policy would be accepted by the community and is of > benefit, I encourage > you to download the policy template from the ARIN web site, review the > Internet Resource > Policy Evaluation Process at http://www.arin.net/policy/irpep.html, > complete the template > and submit it as a proposed policy. > > Any member of the community may submit a proposed policy. > > If you have any questions or would like further assistance in this, > please feel free to contact > me, or, any other member of the ARIN AC. This is one of the key > reasons we have an AC. After the meeting depending upon the results of 2007-21, I'll probably propose something. Cliff > > Owen > From sleibrand at internap.com Thu Feb 28 16:34:05 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 28 Feb 2008 13:34:05 -0800 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <200802282106.m1SL6J3o027069@cjbsys.bdb.com> References: <200802282106.m1SL6J3o027069@cjbsys.bdb.com> Message-ID: <47C728CD.7000407@internap.com> Cliff Bedore wrote: >> Cliff, >> >> Thanks for your feedback on the IPv4 transfer policy proposal. >> >> I'd be interested in your feedback on the Safe Harbor language in the >> policy proposal, as it directly relates to what you said about >> transferors no longer needing their space. > > I guess I'd have to say this strikes me as contrary to what I understand > to be current policy of "efficient utilization" requirements. It may be that > in some cases, selling a small section of an allocation wouldn't violate > "efficient utilization" but I think in many cases it would and ARIN would be > simultaneously requiring the efficiency and letting people not be efficient if > they are selling numbers for a profit. I actually look at it a bit differently. IMO we are attempting to encourage efficient utilization in several ways. The primary current way, which will continue under the proposed transfer policy, is to require efficient use of current space, and plans to efficiently use new space, before anyone can get additional space. Today, we don't have any good method of going back to legacy holders, and those whose networks are no longer growing, and verify efficient use. Recent proposals confirmed that ARIN has the right to do so, but I haven't seen much space reclaimed as a result of that. Additionally, and perhaps more importantly, space can be in use for purposes of audit, but may not be absolutely needed. Without some incentive, most organizations in that situation won't want to take on the task of renumbering things to free up space. So as I see it, encouraging people to free up space by allowing them to transfer it is a very effective way to encourage efficient utilization. If you have ideas for equally effective ways to encourage such behavior, I'd love to hear them, but I don't think I've seen any so far. > --- > From 6.4.1 6.4.1. Address space not to be considered property > > It is contrary to the goals of this document and is not in the interests of > the Internet community as a whole for address space to be considered freehold > property. > --- > > Whatever the proposed policy says, when someone can get paid for transferring > something from themselves to another, it strikes me that that something is > effectively property. This is definitely a valid concern. ARIN counsel has been involved in helping us ensure that the proposed policy preserves the addresses-are-not-property legal regime as much as possible. I suspect there will be an opportunity at Denver to discuss this issue at length, and unless ARIN wants to have counsel discuss the issue here on PPML, I think that's the best venue for discussing it. >> On the issue of PIv6 space for IPv4 holders, the policy proposal to >> allow that did indeed get consensus at ABQ. Unfortunately, due to >> issues with wordsmithing on the floor of the meeting, final approval has >> been delayed until we can bring the revised wording back at the Denver >> meeting and make sure no one feels it represents a significant change >> from the intent of the original proposal and what got consensus at ABQ. > > Depending upon the outcome of that policy, I may submit a proposal to change > that. I look forward to seeing it. -Scott >> Cliff Bedore wrote: >>> Leo Bicknell wrote: >>>> In a message written on Thu, Feb 28, 2008 at 10:11:33AM -0500, Cliff Bedore wrote: >>>> >>>>> I think the idea of this proposal is necessary but I don't think ARIN should >>>>> be in the business of assisting transfer sales of IP addresses unless they >>>>> have no assets to fill a legitmate request. It may be implied somewhere that >>>>> ARIN will not allow a sale if they have assets available but I didn't see it. >>>>> Therefore I'm not convinced that "exhaustion of the IANA IPv4 free pool" is >>>>> the correct time. I think transfer sales should start the first time ARIN >>>>> can't meet a legitmate request and even after that, should only be allowed >>>>> when ARIN doesn't have the particular size requested available. >>>>> >>>> In one of our sessions someone proposed "the first time ARIN could >>>> not fill a request"; and we were in fact informed that had already >>>> occurred. While a bit of a technicality, I suspect the issue was >>>> ARIN did not have enough free space for a large request, and had >>>> to go back to IANA for more space which prevented them from filling >>>> the request right away. >>>> >>>> The problem with using the date ARIN can't make a sale is that it >>>> is different for different people, and in fact may not be what you >>>> request. ARIN could keep a table of "we can make /18, /19, and >>>> /20's" on the web site, but making a /20 may use up the last /18 >>>> and take it away. Or, someone may ask for a /20, work with ARIN >>>> staff who only sees justification for a /21, but there are none of >>>> those left. If someone was basing their decision on the availability >>>> of /20's that won't work so well. >>>> >>> I realize that ARIN resources and user resources for sale will happen in >>> an overlapping manner. I realize it is a complex problem due to >>> considerations such as splitting a large block to handle a small block >>> vs transfer/sale of a user block of the right size. Probably more >>> complex than I can imagine right now but ARIN is also chartered(? >>> whatever term is correct) to get users to convert to IPv6 and spending >>> lots of time and money to extend IPv4 seems to be contrary to that >>> goal. I'm not sure anyone coming in for addresses that late in the game >>> shouldn't suffer a few delays in getting addresses. It's not like they >>> haven't had ample warning about a shortage. >>>> Lastly, if we wait for ARIN to be unavailable and then spin up the >>>> system described in 2008-2 there will likely be a small gap during >>>> which no one can get space. While I believe ARIN staff can manage >>>> the transition quite nicely, there is a level of public education, >>>> putting information on the web, having staff process a new type of >>>> request, etc. I think many on the AC wanted to err on th side of >>>> a small amount of overlap rather than a small gap in service. >>>> >>> I don't think ARIN has to wait to set up the procedures. I just think >>> they should wait to start using them. :-) One problem with listing end >>> user blocks for sale is that technically, the end user can no longer >>> justify their current allocation and it would seem that ARIN would be >>> justified in reclaiming them is a fair number of cases rather than >>> approving a transfer sale. >>>> Do any of those reasons alter your opinion, or do you still believe >>>> IANA Free Pool exhaustion is the wrong time? >>>> >>> I understand your argument but I think the answer has to decided based >>> on whether ARIN is more interested in promoting the switch to v6 or >>> band-aiding v4 for as long as possible. >>> >>> ARIN does seem to have something of a split personality toward >>> perpetuating v4 and promoting v6. This proposal seems to me to be >>> bending over backwards toward perpetuating v4. The proposals to >>> allow/get legacy users to use v6 and sign RSAs however seems to have >>> some dis-incentives to them. If ARIN really wanted legacy users to sign >>> an RSA and convert to v6, they would allow them to qualify for a v6 >>> allocation equivalent to the v4 size they received during the legacy >>> period without regard to whether they meet the current requirements. As >>> an example, I have a /24 PI which was granted long before ARIN ever came >>> along. I currently don't meet the 25/50% rule to justify that /24 but I >>> did meet the requirements at the time it was issued. I would think that >>> ARIN could offer the minimum v6 allocation to any /24 (or maybe any) >>> legacy holder who is willing to sign the RSA and join the fold. I don't >>> think it would be a big number since I expect many of the legacy >>> addresses have been abandoned and many who are active would qualify >>> under current rules but it would demonstrate ARIN's seriousness about >>> getting v6 started. This should probably be a separate discussion but >>> it fits in with (at least my perception of) the ARIN split personality >>> aspect of the 2008-2 >>> >>> Also note that in reality, I'll probably be retired and in a home before >>> my /24 will cease to be useful. I'd like to get the v6 space to use for >>> learning/testing and maybe forcing my upstream ISP to start routing v6. >>> If enough people did that, it would help speed the transition. >>> >>> Cliff >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to the ARIN Public Policy >>>> Mailing List (PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/ppml >>>> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. >>>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to the ARIN Public Policy >>> Mailing List (PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/ppml >>> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. > > From bicknell at ufp.org Thu Feb 28 16:35:57 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 28 Feb 2008 16:35:57 -0500 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <47C70756.4030409@cjbsys.bdb.com> References: <200802281511.m1SFBXnO024037@cjbsys.bdb.com> <20080228155953.GA92342@ussenterprise.ufp.org> <47C70756.4030409@cjbsys.bdb.com> Message-ID: <20080228213557.GA23007@ussenterprise.ufp.org> In a message written on Thu, Feb 28, 2008 at 02:11:18PM -0500, Cliff Bedore wrote: > I don't think ARIN has to wait to set up the procedures. I just think > they should wait to start using them. :-) One problem with listing > end user blocks for sale is that technically, the end user can no > longer justify their current allocation and it would seem that ARIN > would be justified in reclaiming them is a fair number of cases rather > than approving a transfer sale. The most common case people consider when thinking about this policy is the resource holder who now has "extra" for whatever reason. That however is not the only case of interest. One of the economic theories here is that different companies have different costs to move to IPv6. Perhaps there is a company out there that is fully using a /19 right now, and to do IPv6 needs to buy $20,000 worth of new hardware which they cannot afford. However, if a /20 is going for $20,000 they can buy the equipment on credit, renumber half their users out of it, sell the /20 to pay for the equipment, and end up with a /20 going forward. So it's not that they don't need the /19 today or aren't fully using it; but rather that a financial incentive may get them to move to IPv6 and free up IPv4 resources. The /20 may be purchased by someone who has $1,000,000 in expenses to move to IPv6, and paying $20,000 to delay it until the price of equipment drops is in their best interest. > requirements. As an example, I have a /24 PI which was granted long > before ARIN ever came along. I currently don't meet the 25/50% rule > to justify that /24 but I did meet the requirements at the time it was > issued. I would think that ARIN could offer the minimum v6 allocation > to any /24 (or maybe any) legacy holder who is willing to sign the RSA > and join the fold. I don't think it would be a big number since I I believe policy proposal 2007-21 is of interst to you: http://www.arin.net/policy/proposals/2007_21.html As Scott already posted, it would likely be in place already were it not for some language issues. I suggest you voice your support for the proposal if you think it's a good idea. -- 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 stephen at sprunk.org Thu Feb 28 17:04:21 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 28 Feb 2008 16:04:21 -0600 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal References: <200802281511.m1SFBXnO024037@cjbsys.bdb.com><20080228155953.GA92342@ussenterprise.ufp.org> <47C70756.4030409@cjbsys.bdb.com> Message-ID: <006f01c87a57$c7aff4c0$563816ac@atlanta.polycom.com> Thus spake "Cliff Bedore" > One problem with listing end user blocks for sale is that technically, > the end user can no longer justify their current allocation and it would > seem that ARIN would be justified in reclaiming them is a fair number > of cases rather than approving a transfer sale. You're missing the difference between "justify" and "need". I don't _need_ a public address for every host on my network, even though I'd be _justified_ in getting such from ARIN under current policy. All I _need_ is a handful of addresses and a NAT box. If someone was willing to pay me to switch from the former model to the latter -- more than my cost of doing so -- why would I choose not to? There's also the issue of determining if ARIN _can_ reclaim unjustified address space from the people that hold most of it: legacy holders. Any attempt to do so is virtually certain to result in expensive lawsuits that will drag on for years, defeating the purpose. This proposal would give legacy holders an economic incentive to give up address space that we likely could not get back by any other means. For that matter, ARIN doesn't think it can reclaim _any_ unjustified space except in the event of fraud; that may change if 2007-14 passes in Denver. Even then, that proposal contains an explicit exemption for legacy space due to the above issue. >> Do any of those reasons alter your opinion, or do you still believe >> IANA Free Pool exhaustion is the wrong time? > > I understand your argument but I think the answer has to decided based > on whether ARIN is more interested in promoting the switch to v6 or > band-aiding v4 for as long as possible. I've been told that ARIN (meaning the corporation, not the community) is not in the business of promoting one protocol over another or encouraging people to switch. Being a resposible steward, which is ARIN's charter, means they must continue to serve v4 needs to the extent possible given the technical constraints; if people find that v6 meets their needs better due to not having those technical constraints, people will move of their own volition. 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 cliffb at cjbsys.bdb.com Thu Feb 28 17:40:05 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Thu, 28 Feb 2008 17:40:05 -0500 (EST) Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal Message-ID: <200802282240.m1SMe5JC027923@cjbsys.bdb.com> Rather than quote long messages regarding this, I'm going to start a new message about this. Scott Leibrand wrote --- I actually look at it a bit differently. IMO we are attempting to encourage efficient utilization in several ways. The primary current way, which will continue under the proposed transfer policy, is to require efficient use of current space, and plans to efficiently use new space, before anyone can get additional space. Today, we don't have any good method of going back to legacy holders, and those whose networks are no longer growing, and verify efficient use. Recent proposals confirmed that ARIN has the right to do so, but I haven't seen much space reclaimed as a result of that. Additionally, and perhaps more importantly, space can be in use for purposes of audit, but may not be absolutely needed. Without some incentive, most organizations in that situation won't want to take on the task of renumbering things to free up space. So as I see it, encouraging people to free up space by allowing them to transfer it is a very effective way to encourage efficient utilization. If you have ideas for equally effective ways to encourage such behavior, I'd love to hear them, but I don't think I've seen any so far. --- I think 2007-17 provides for such reclamation albeit without any money changing hands. Leo Bicknell wrote --- The most common case people consider when thinking about this policy is the resource holder who now has "extra" for whatever reason. That however is not the only case of interest. One of the economic theories here is that different companies have different costs to move to IPv6. Perhaps there is a company out there that is fully using a /19 right now, and to do IPv6 needs to buy $20,000 worth of new hardware which they cannot afford. However, if a /20 is going for $20,000 they can buy the equipment on credit, renumber half their users out of it, sell the /20 to pay for the equipment, and end up with a /20 going forward. So it's not that they don't need the /19 today or aren't fully using it; but rather that a financial incentive may get them to move to IPv6 and free up IPv4 resources. The /20 may be purchased by someone who has $1,000,000 in expenses to move to IPv6, and paying $20,000 to delay it until the price of equipment drops is in their best interest. --- I think this argument lends credence to the claim that numbers have become property. I just see this as a very slippery slope that once ARIN starts down, there will be no going back and there may be unforseen consequences of numbers becoming de facto property. I.e. once IP numbers become property, who is ARIN to regulate it as a monopoly. You can say it's not property but if it walks like a duck and quacks like a duck..... I just see this becoming a legal nightmare. It might be possible to avoid the property problem if the numbers have to be returned to ARIN and then redistributed but I can't see how payment between transferee and transferor could be made in that case. 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 randy at psg.com Thu Feb 28 17:39:03 2008 From: randy at psg.com (Randy Bush) Date: Fri, 29 Feb 2008 06:39:03 +0800 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <47C723EC.3050900@cjbsys.bdb.com> References: <200802281511.m1SFBXnO024037@cjbsys.bdb.com> <20080228155953.GA92342@ussenterprise.ufp.org> <47C70756.4030409@cjbsys.bdb.com> <47C723EC.3050900@cjbsys.bdb.com> Message-ID: <47C73807.6000100@psg.com> > I guess it seems to me that when you have a scarce resource and > completely non-scarce resource, good stewardship would demand that > emphasis be given to encouraging use of the non-scarce resource. i suspect folk may also take into account the costs and ease of using those two alternatives. randy, who is trying to reduce the difficulty of using the less scarce one From bicknell at ufp.org Thu Feb 28 17:46:15 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 28 Feb 2008 17:46:15 -0500 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <200802282240.m1SMe5JC027923@cjbsys.bdb.com> References: <200802282240.m1SMe5JC027923@cjbsys.bdb.com> Message-ID: <20080228224615.GA28936@ussenterprise.ufp.org> In a message written on Thu, Feb 28, 2008 at 05:40:05PM -0500, Cliff Bedore wrote: > I just see this as a very slippery slope that once ARIN starts down, there > will be no going back and there may be unforseen consequences of numbers > becoming de facto property. I.e. once IP numbers become property, who is ARIN > to regulate it as a monopoly. You can say it's not property but if it walks > like a duck and quacks like a duck..... I just see this becoming a legal > nightmare. It might be possible to avoid the property problem if the numbers > have to be returned to ARIN and then redistributed but I can't see how payment > between transferee and transferor could be made in that case. ARIN offers a set of services. They include reverse DNS delegation, running a whois server, insuring uniqueness, enforcing community rules, running ARIN meetings, and I'm sure many other things I've forgotten. When you're issued a number resource today it's not property, rather you pay ARIN a fee for all of those services. What's being transferred from one party to another is the right to use those services. The RSA spells this out fairly nicely, and the transfer policy was written with the legal impacts in mind. From a legal perspective the service is not so different from any of thousands of other services exchanged for money every day. A gym membership, seat on an airline, or your home phone service. None of these contractual relationships mean you own locker 352, or seat 12-D, or 555-867-5309. Some of these contracts allow you to transfer, some do not. The fact that I might be able to sell the 6 months left on my gym contract to someone else does not mean I own locker 352, or the gym, merely that the service is transferable from one party to another. The airline tells me if I try to sell my seat the contract is null and void. -- 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 owen at delong.com Fri Feb 29 02:00:17 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Feb 2008 23:00:17 -0800 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <200802282240.m1SMe5JC027923@cjbsys.bdb.com> References: <200802282240.m1SMe5JC027923@cjbsys.bdb.com> Message-ID: <7C7C7723-2544-46C1-8E81-754061A6B4D2@delong.com> > > I think 2007-17 provides for such reclamation albeit without any money > changing hands. > > 2007-17 is proposed, but, is not policy. Hopefully it will receive support and be adopted after the Denver meeting in its current form. If you support the revised version, please say so on PPML. If you don't, please also say so and let us know why. > > I think this argument lends credence to the claim that numbers have > become > property. > > I just see this as a very slippery slope that once ARIN starts down, > there > will be no going back and there may be unforseen consequences of > numbers > becoming de facto property. I.e. once IP numbers become property, > who is ARIN > to regulate it as a monopoly. You can say it's not property but if > it walks > like a duck and quacks like a duck..... I just see this becoming a > legal > nightmare. It might be possible to avoid the property problem if > the numbers > have to be returned to ARIN and then redistributed but I can't see > how payment > between transferee and transferor could be made in that case. I think that's a very valid concern. One which I think the AC is taking very seriously, and, one which we have discussed very carefully with counsel. We are very fortunate to have two excellent lawyers, one of whom is also an accomplished economist assisting us in developing this policy. However, I agree that we are threading a needle here and that these concerns remain a significant factor in considering this policy. Owen From cliffb at cjbsys.bdb.com Fri Feb 29 10:27:02 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Fri, 29 Feb 2008 10:27:02 -0500 (EST) Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal Message-ID: <200802291527.m1TFR2nb003937@cjbsys.bdb.com> Leo and Owen One of my concerns is that ARIN not get caught by unintended consequences of this change. I know what you intend and it may be the lesser of many evils but I also know that as things become scarcer, people beccome more "creative" about what they are willing to do to get their share and a little more. ARIN is a group that relies on the goodness of people/organizations to function. I admire that and respect it but I think ARIN needs to recognize that there are vultures out there who will try almost anything to get something they think they deserve. I worry that like companies who don't protect their trademarks aggresively enough and lose them, ARIN by adopting this policy might lose the battle about numbers being property in spite of what they say. Companies lose sexual harassment cases all the time because even though their policies say one thing, their actions (or inactions) say another. 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. 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 bicknell at ufp.org Fri Feb 29 10:49:39 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 29 Feb 2008 10:49:39 -0500 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <200802291527.m1TFR2nb003937@cjbsys.bdb.com> References: <200802291527.m1TFR2nb003937@cjbsys.bdb.com> Message-ID: <20080229154939.GD97564@ussenterprise.ufp.org> 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From owen at delong.com Fri Feb 29 11:03:57 2008 From: owen at delong.com (Owen DeLong) Date: Fri, 29 Feb 2008 08:03:57 -0800 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <200802291527.m1TFR2nb003937@cjbsys.bdb.com> References: <200802291527.m1TFR2nb003937@cjbsys.bdb.com> Message-ID: On Feb 29, 2008, at 7:27 AM, Cliff Bedore wrote: > Leo and Owen > > One of my concerns is that ARIN not get caught by unintended > consequences of > this change. I know what you intend and it may be the lesser of > many evils > but I also know that as things become scarcer, people beccome more > "creative" > about what they are willing to do to get their share and a little > more. ARIN > is a group that relies on the goodness of people/organizations to > function. I > admire that and respect it but I think ARIN needs to recognize that > there are > vultures out there who will try almost anything to get something > they think > they deserve. I worry that like companies who don't protect their > trademarks > aggresively enough and lose them, ARIN by adopting this policy might > lose the > battle about numbers being property in spite of what they say. > Companies lose > sexual harassment cases all the time because even though their > policies say > one thing, their actions (or inactions) say another. > > 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. > I have a high degree of confidence that the ARIN attorneys have done just that in this context and in a number of other contexts. I also agree that in spite of this, the issue remains a concern and a serious detractor to the implementation of the policy. Owen From jweyand at computerdata.com Fri Feb 29 12:14:04 2008 From: jweyand at computerdata.com (Jim Weyand) Date: Fri, 29 Feb 2008 12:14:04 -0500 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal Message-ID: <1582DCBFF968F044A9A910C0AB177C902CE5E9@cliff.cdi.local> 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/ From sleibrand at internap.com Fri Feb 29 12:31:53 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 29 Feb 2008 09:31:53 -0800 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <1582DCBFF968F044A9A910C0AB177C902CE5E9@cliff.cdi.local> References: <1582DCBFF968F044A9A910C0AB177C902CE5E9@cliff.cdi.local> Message-ID: <47C84189.2050907@internap.com> Jim, Yes, Ben has been monitoring this list. I haven't heard him express concerns with that particular clause, because the proposed policy allows a party with a larger block than they need to keep one contiguous portion of it and transfer the rest: there's no need to trade it in for a smaller block. Ben has expressed concerns about the restrictions that limit deaggregation on the transferor side. If I understand his position correctly, he believes that requiring transferees to fill their entire request with one transfer is good and necessary to prevent deaggregation, 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. There are a few different ways to deal with this, in addition to the proposed transfer policy's conditions or a transferee-restrictions-only system. For example, we might ask ARIN to monitor market prices, and allow as many bits of deaggregation (on transferor pre-qualifications) as needed to keep supply and demand in balance across the range of address sizes... -Scott Jim Weyand wrote: > 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. > From michael.dillon at bt.com Fri Feb 29 13:10:54 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 29 Feb 2008 18:10:54 -0000 Subject: [ppml] SWIP proposal and SWIP stats. In-Reply-To: <47C83A50.9050509@arin.net> References: <00bd01c87233$a4a78640$edf692c0$@com> <890915790-1203370562-cardhu_decombobulator_blackberry.rim.net-1284932976-@bxe120.bisx.prod.on.blackberry> <20080219023541.GE12566@skywalker.creative.net.au> <01e401c874db$cb7a5130$483816ac@atlanta.polycom.com> <47BE967F.1010809@psg.com> <47C5CFDB.1000006@psg.com> <47C83A50.9050509@arin.net> Message-ID: > As recently suggested, ARIN has made the requested changes to > produce a new histogram. It can be found at: > > http://www.arin.net/statistics/index.html#ipv4org. One of those charts shows that there are about 1,000 SWIPs which are processed manually each month. Given that there is a proposal whose effect will be to INCREASE the number of SWIPs submitted, it would be interesting to know what causes SWIPs to be processed manually. I wouldn't be surprised to learn that the systems can process several times as many SWIPs as today at no additional cost. However, manual processing costs are going to increase directly with the number of SWIPs that are processed manually. --Michael Dillon From michael.dillon at bt.com Fri Feb 29 13:25:02 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 29 Feb 2008 18:25:02 -0000 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <47C84189.2050907@internap.com> References: <1582DCBFF968F044A9A910C0AB177C902CE5E9@cliff.cdi.local> <47C84189.2050907@internap.com> Message-ID: > There are a few different ways to deal with this, in addition > to the proposed transfer policy's conditions or a > transferee-restrictions-only system. For example, we might > ask ARIN to monitor market prices, and allow as many bits of > deaggregation (on transferor pre-qualifications) as needed to > keep supply and demand in balance across the range of address sizes... If ARIN does decide to monitor this particular derivatives market and take actions to regulate that market, are there any implications of that within the law? For instance, would ARIN have to be licenced or registered with the SEC? It would be interesting to hear from someone with financial markets expertise to see what is the likelihood that these IP address blocks would be considered to be some kind of exotic equity derivative. After all, if IP address blocks are being bought and sold, they have an equity value and the contracts that are sold would be equity derivatives. And since holders of these contracts can profit by selling them, then they are securities and therefore under the regulatory gaze of the SEC. --Michael Dillon From bicknell at ufp.org Fri Feb 29 14:03:35 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 29 Feb 2008 14:03:35 -0500 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: References: <1582DCBFF968F044A9A910C0AB177C902CE5E9@cliff.cdi.local> <47C84189.2050907@internap.com> Message-ID: <20080229190334.GA36802@ussenterprise.ufp.org> In a message written on Fri, Feb 29, 2008 at 06:25:02PM -0000, michael.dillon at bt.com wrote: > all, if IP address blocks are being bought and sold, they have an > equity value and the contracts that are sold would be equity > derivatives. IP address blocks are not being bought or sold. The services provided by ARIN are being transferred from one party to another for monetary consideration. Even the AC has trouble keeping the language straight; but the example I've used is Windows. People all the time say "I bought a copy of Windows." However, if you look at the contract that's not what happened at all; you licensed a single copy of the software for use on a single CPU blah blah blah blah (I think about 30 pages of blah, actually). It's easy to say "I bought some IP space from ARIN", but if you read the RSA that's not what happened at all. Specific to your question about SEC (or other) regulation, I don't believe it has been raised as a concern with the way the current policy is drafted. There is a generic concern that any change in policy may prompt /new/ government regulation in the realm of IP Resources but I don't think there's a feeling any of the current regulations would magically apply if this policy were to pass. -- 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 John.Kuhn at ontario.ca Fri Feb 29 14:21:36 2008 From: John.Kuhn at ontario.ca (Kuhn, John (MGCS)) Date: Fri, 29 Feb 2008 14:21:36 -0500 Subject: [ppml] Welcome to the "PPML" mailing list In-Reply-To: References: Message-ID: Received message John Kuhn -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of ppml-request at arin.net Sent: February 29, 2008 2:19 PM To: Kuhn, John (MGCS) Subject: Welcome to the "PPML" mailing list Welcome to the PPML at arin.net mailing list! To post to this list, send your email to: ppml at arin.net General information about the mailing list is at: http://lists.arin.net/mailman/listinfo/ppml If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: http://lists.arin.net/mailman/options/ppml/john.kuhn%40ontario.ca You can also make such adjustments via email by sending a message to: PPML-request at arin.net with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: ucrezure Normally, Mailman will remind you of your arin.net mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. From jmaimon at chl.com Fri Feb 29 15:32:27 2008 From: jmaimon at chl.com (Joe Maimon) Date: Fri, 29 Feb 2008 15:32:27 -0500 Subject: [ppml] SWIP proposal and SWIP stats. In-Reply-To: References: <00bd01c87233$a4a78640$edf692c0$@com> <890915790-1203370562-cardhu_decombobulator_blackberry.rim.net-1284932976-@bxe120.bisx.prod.on.blackberry> <20080219023541.GE12566@skywalker.creative.net.au> <01e401c874db$cb7a5130$483816ac@atlanta.polycom.com> <47BE967F.1010809@psg.com> <47C5CFDB.1000006@psg.com> <47C83A50.9050509@arin.net> Message-ID: <47C86BDB.4090608@chl.com> michael.dillon at bt.com wrote: >>As recently suggested, ARIN has made the requested changes to >>produce a new histogram. It can be found at: >> >>http://www.arin.net/statistics/index.html#ipv4org. > > > One of those charts shows that there are about 1,000 SWIPs which > are processed manually each month. Given that there is a proposal > whose effect will be to INCREASE the number of SWIPs submitted, > it would be interesting to know what causes SWIPs to be processed > manually. Definitely interesting. The expected increase is unknown, but I would be surpised were it be more than a few percentage points of current. > > I wouldn't be surprised to learn that the systems can process several > times as many SWIPs as today at no additional cost. However, manual > processing costs are going to increase directly with the number of > SWIPs that are processed manually. > > --Michael Dillon That doesnt match the stat trend. The number of manuals does not appear to correlate at all to the overall number, which varies from a high of 88k to 35k, more than double. The manuals vary from 1700 to 750, but the 1700 comes from a month of 44k automatic, contrast with 816 manuals from a month of 88.4k From michael.dillon at bt.com Fri Feb 29 15:59:09 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 29 Feb 2008 20:59:09 -0000 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal In-Reply-To: <20080229190334.GA36802@ussenterprise.ufp.org> References: <1582DCBFF968F044A9A910C0AB177C902CE5E9@cliff.cdi.local><47C84189.2050907@internap.com> <20080229190334.GA36802@ussenterprise.ufp.org> Message-ID: > IP address blocks are not being bought or sold. The services > provided by ARIN are being transferred from one party to > another for monetary consideration. Precisely my point. It is a contract or agreement that is being sold and that is exactly what a lot of financial instruments are based on such as derivatives, reinsurance, and factoring. If these are deemed to be financial instruments, then the laws covering SEC jurisdiction would apply, which then leads to the necessity of complying with SEC regulations. > Specific to your question about SEC (or other) regulation, I > don't believe it has been raised as a concern with the way > the current policy is drafted. There is a generic concern > that any change in policy may prompt /new/ government > regulation in the realm of IP Resources but I don't think > there's a feeling any of the current regulations would > magically apply if this policy were to pass. I don't have any concern whatsoever about /new/ government regulation in this area because the USG is just not interested in extending regulation to Internet stuff if they can avoid it. What I am worried about is that existing laws, and existing regulatory regimes may come into play if ARIN steps across certain boundaries. This would require no action at all on the part of the USG, legislators or the SEC. If you decide to set up a website selling stocks, then you have chosen to operate in a regulated field of activity and are required to follow all the regulations and laws that apply to that field of activity. --Michael Dillon From martin.hannigan at batelnet.bs Fri Feb 29 19:15:25 2008 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Fri, 29 Feb 2008 19:15:25 -0500 Subject: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal Message-ID: <47c8a01d.101.38ee.25290@batelnet.bs> ----- Original Message ----- From: Leo Bicknell To: ppml at arin.net Subject: Re: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal Date: Fri, 29 Feb 2008 14:03:35 -0500 > In a message written on Fri, Feb 29, 2008 at 06:25:02PM > > -0000, michael.dillon at bt.com wrote: all, if IP address > > blocks are being bought and sold, they have an equity > > value and the contracts that are sold would be equity > derivatives. > > IP address blocks are not being bought or sold. The > services provided by ARIN are being transferred from one > party to another for monetary consideration. Would they be considered "property" and titled through certificates? -M<