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: 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 11:28:10 2008 From: info at arin.net (Member Services) Date: Wed, 06 Feb 2008 11:28:10 -0500 Subject: ARIN Mailing Lists Message-ID: <47A9E01A.9000309@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 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: 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 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: 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: 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: 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 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: 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: 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: 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 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: 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 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: 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 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 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: 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 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: 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: 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: 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)