From info at arin.net Thu Mar 5 16:01:15 2009 From: info at arin.net (Member Services) Date: Thu, 05 Mar 2009 16:01:15 -0500 Subject: Policy Proposal: Protective Usage Transfer Policy for IPv4 Address - Revised Message-ID: <49B03D9B.9070103@arin.net> Policy Proposal Protective Usage Transfer Policy for IPv4 Address The proposal originator submitted a revised version of the proposal. The AC will review this proposal at their next regularly scheduled meeting and decide how to utilize the proposal. Their decision will be announced to the PPML. In the meantime, the AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Policy Development Process can be found at: http://www.arin.net/policy/pdp.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: Protective Usage Transfer Policy for IPv4 Address Proposal Originator : Christopher A. Quesada Proposal Version: 2 Date: 5 March 2009 Policy statement: Critical infrastructure providers may appeal to ARIN for final review and approval of any full or partial transfer of IPv4 address space that has been in use by the critical infrastructure serving the community for five consecutive years or more. Such appeal may result in a partial or full approval of the requested transfer, or rejection of the transfer if it lacks appropriate rationale, justification, or interferes with the seamless operation of such critical infrastructure or hardship to the provider. Rationale: Protection of critical infrastructure providers of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs and IANA is necessary in order to ensure the continuous operation of the Internet for its global service community. It is possible for an organization to transfer an aggregate IPv4 address resource containing allocations/assignments downstream supporting critical infrastructure (as defined in ARIN?s Number Resource Policy Manual). This policy is intended to protect that critical infrastructure by allowing for the review and final approval of such transfer by ARIN, upon appeal by the critical infrastructure provider to ARIN, within a sixty day period of the transfer notification if such transfer would interfere with the continuous and seamless operation of that critical infrastructure or hardship to the provider. Review of the transfer can consist of a request by ARIN to the transferring organization for a rationale for such transfer. This may include but not be limited to, a requirement for the receiving party to submit the appropriate network request form identifying the need and justification for the aggregate IPv4 address resource. From info at arin.net Mon Mar 9 11:18:01 2009 From: info at arin.net (Member Services) Date: Mon, 09 Mar 2009 11:18:01 -0400 Subject: Policy Proposal (Global): Allocation of IPv4 Blocks to Regional Internet Registries - Revised Message-ID: <49B53329.5010603@arin.net> Policy Proposal (Global) Allocation of IPv4 Blocks to Regional Internet Registries The proposal originator submitted a revised version of the proposal. See the rationale for an explanation of changes in this version. The proposal will be forwarded to the ARIN Advisory Council for their consideration. The proposal is on the AC's docket for development and evaluation. The ARIN Policy Development Process can be found at: http://www.arin.net/policy/pdp.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: Allocation of IPv4 Blocks to Regional Internet Registries Proposal Originator: This proposal was developed by a team consisting of persons from each of the 5 RIRs. Adiel A. Akplogan AfriNIC Raul Echeberria LACNIC Geoff Huston APNIC MAEMURA Akinori APNIC Axel Pawlik RIPE NCC Ray Plzak ARIN Oscar A. Robles-Garay" LACNIC Nigel Titley RIPE NCC Paul Wilson APNIC Proposal Version: 3.0 Date: 9 March 2009 Proposal type: New Global Policy term: Permanent Policy statement: This document describes the policy governing the allocation of IPv4 address space from the IANA to the Regional Internet Registries (RIRs). This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with this policy. Such requirements should be specified by appropriate agreements among the RIRs and ICANN. This policy is to be implemented in two phases. A. Phase I: Recovery of IPv4 Address Space Upon ratification of this policy by the ICANN Board of Directors the IANA shall establish a mechanism to receive IPv4 address space which is returned to it by the RIRs, and hold that address space in a 'recovered IPv4 pool'. Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration. Each RIR shall at quarterly intervals return any such recovered address space to the IANA in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool. During Phase I, no allocations will be made from the recovered IPv4 pool. B. Phase II: Allocation of Recovered IPv4 address space by the IANA Upon ratification of this policy by the ICANN Board of Directors and a declaration by the IANA that its existing free pool of unallocated IPv4 address space is depleted; Global Addressing Policy ASO-001-2 (adopted by ICANN Board 8 April 2005) is rescinded. IANA will then commence to allocate the IPv4 address space from the recovered IPv4 pool. 1. The following definitions apply to this policy: a. Recovered Address Space. Recovered address space is that address space that is returned to an RIR as a result of any activity that seeks to reclaim unused address space or is voluntarily returned to the RIR or is reclaimed by the RIR as a result of legal action or abuse determination. Recovered address space does not include that address space that is reclaimed because of non-payment of contractual fees whose reclamation date is less than 1 year at the time of the report. b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4 address space held by an RIR to include recovered address space not yet returned less that address space that is committed in accordance with the RIR's reservation policy and practices. c. Aggregated address blocks. Aggregated address blocks are contiguous prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24 and 10.0.1.0/24 are two contiguous prefixes that can be combined to form an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two contiguous prefixes that cannot be combined on a natural bit boundary to form an aggregated block. 2. Allocation of IPv4 Address Space a. For the purposes of this policy, an 'IPv4 allocation period' is defined as a 6-month period following 1 March or 1 September in each year. b. At the beginning of each IPv4 allocation period, the IANA will determine the 'IPv4 allocation unit' for that period, as 1/10 of its IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary. The minimum 'IPv4 allocation unit' size will be a /24. c. In each allocation period, each RIR may issue one IPv4 request to the IANA. Providing that the RIR satisfies the allocation criteria described in paragraph B.2, the IANA will allocate a single allocation unit, composed of the smallest possible number of blocks available in its IPv4 address pool. 3. IPv4 Address Space Allocation Criteria A RIR is eligible to receive additional IPv4 address space from the IANA when the total of its IPv4 address holdings is less than 50% of the current IPv4 allocation unit, and providing that it has not already received an IPv4 allocation from the IANA during the current IPv4 allocation period. 4. Initial Allocation of IPv4 Address Space Each new RIR shall, at the moment of recognition, be allocated one (1) allocation unit by the IANA. If an allocation unit is not available, then the IANA will issue this block as soon as one is available. This allocation will be made regardless of the newly formed RIR's projected utilization figures and shall be independent of the IPv4 address space that may have been transferred to the new RIR by the already existing RIRs as part of the formal transition process. 5. Reporting a. All returned space is to be recorded in an IANA-published log of IPv4 address space transactions, with each log entry detailing the returned address block, the date of the return, and the returning RIR. b. All allocated space is also to be recorded in this IANA-published log of IPv4 address space transactions, with each log entry detailing the address blocks, the date of the allocation and the recipient RIR. c. The IANA will maintain a public registry of the current disposition of all IPv4 address space, detailing all reservations and current allocations and current IANA-held address space that is unallocated. d) The IANA may make public announcements of IPv4 address block transactions that occur under this policy. The IANA will make appropriate modifications to the "Internet Protocol V4 Address Space" page of the IANA website and may make announcements to its own appropriate announcement lists. The IANA announcements will be limited to which address ranges, the time of allocation and to which Registry they have been allocated. Rationale: This is version 3 of the policy proposal. It is the form that reached consensus following community discussion at the APNIC 27 Policy SIG on Thursday 26 February 2008 and endorsement at the APNIC Member Meeting (AMM) on Friday 27 February 2008. With the depletion of the IANA free pool of IPv4 address space, the current policy regarding the allocation of IPv4 address space to the RIRs will become obsolete. The RIRs may, according to their individual policies and procedures, recover IPv4 address space. This policy provides a mechanism for the RIRs to retro allocate the recovered IPv4 address space to the IANA and provides the IANA the policy by which it can allocate it back to the RIRs on a needs basis. This policy creates a new global pool of IPv4 address space that can be allocated where it is needed on a global basis without a transfer of address space between the RIRs. Specifically this revision does the following: a. Adds the definition of "aggregated block" as paragraph 1.3. b. Adds to paragraph 2.b the minimum allocation size which can be allocated by IANA. XXXXXXXXXXXXXXXXXXXXXXXXXXXXX Below are 3 exemplar scenarios of the execution of this policy after Phase II is in force. These are not part of the rationale but are provided for illustrative purposes. Example 1: On 1 March 2020, IANA has the equivalent of a /17 (32,768 addresses) worth of IPv4 addresses. 1. IANA calculates that 1/10 of this space is 3,276 addresses. 2. IANA rounds this down to the next bit boundary, which creates a minimum allocation size of /21 (2,048 addresses). 3. Each RIR can request and receive a single allocation unit equivalent to a /21 worth of addresses. 4. While IANA may not be able to allocate a contiguous /21 and can allocate noncontiguous smaller blocks equivalent to a /21 worth of addresses. Example 2: On 1 March 2020, IANA has the equivalent of a /20 (4,096 addresses) worth of IPv4 addresses. 1. IANA calculates that 1/10 of this space is 409 addresses. 2. IANA rounds this down to the next bit boundary, which creates a minimum allocation size of /24 (256 addresses). 3. Each RIR can request and receive a single allocation unit equivalent to a /24 worth of addresses. 4. As the minimum size of address space returned to IANA is /24, IANA can allocate a contiguous range of addresses that amount to a /24. Example 3: On 1 March 2020, IANA has the equivalent of a /21 (2,048 addresses) worth of IPv4 addresses. 1. IANA calculates that 1/10 of this space is 204 addresses. 2. IANA rounds this down to the next bit boundary, which creates a minimum allocation size of /25 (128 addresses). 3. A /25 is smaller than the minimum permissible allocation size under this policy. A /25 is smaller than the minimum permissible allocation size under this policy. Therefore, IANA is unable to make an allocation until more address space is received. XXXXXXXXXXXXXXXXXXXXXXXXXXXXX Timetable for implementation: This policy is to be implemented immediately upon ratification by the ICANN Board of Directors according to the global policy process described in the ASO MoU. From info at arin.net Mon Mar 9 14:42:01 2009 From: info at arin.net (Member Services) Date: Mon, 09 Mar 2009 14:42:01 -0400 Subject: Petition Deadline =?windows-1252?Q?=96_San_Antonio?= Message-ID: <49B562F9.5070909@arin.net> Next month ARIN will conduct it?s bi-annual meeting ARIN XXIII 26-29 April 2009 in San Antonio Texas. During that time, the Public Policy Meeting will occur 27-28 April 2009. In accordance with the Policy Development Process, ARIN is informing the community that the time to petition due to dissatisfaction with the actions taken so far by the ARIN Advisory Council (AC) regarding policy proposals is drawing to a close. The AC is currently working on six proposals and draft texts. The AC intends to bring forth the following as draft policies for discussion on the ARIN Public Policy Mailing list and at the upcoming Public Policy Meeting: 2008-7: Whois Integrity Policy Proposal 80. IPv4 Recovery Fund 81. Depleted IPv4 reserves 82. Allocation of IPv4 Blocks to Regional Internet Registries (Global) The AC is continuing to work on these, but may not be publishing draft policy text on the PPML in time for the upcoming Public Policy Meeting: 2008-3: Community Networks IPv6 Allocation 83. Protective Usage Transfer Policy for IPv4 Address All draft policies must be published to the PPML at least 35 days prior to a meeting in order to be placed on the agenda for that meeting. That 35-day deadline for ARIN XXIII is 23 March 2009. In addition, the entire petition process to move proposals forward as draft policies must be completed prior to the 35-day deadline. Per the ARIN Policy Development Process, ?Any member of the community, including a proposal originator, may initiate a Discussion Petition if they are dissatisfied with the action taken by the Advisory Council regarding any specific policy proposal. If successful, this petition will change the policy proposal to a draft policy which will be published for discussion and review by the community on the PPML and at an upcoming public policy meeting.? The deadline to start a proposal petition is 13 March 2009. Petitions must include the proposal and a petition statement. Once begun, a petition lasts for 5 business days. Success is measured as support from at least 10 different people from 10 different organizations. Should an actual petition begin, ARIN staff will post more detailed information. The text for Draft Policies and Proposals is available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Thu Mar 12 14:04:05 2009 From: info at arin.net (Member Services) Date: Thu, 12 Mar 2009 14:04:05 -0400 Subject: ICANN Ratifies Global Policy: End Policy for IANA IPv4 allocations to RIRs Message-ID: <49B94E95.6090607@arin.net> On 6 March 2009 the ICANN Board of Directors ratified the global policy, End Policy for IANA IPv4 allocations to RIRs. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm In the ARIN region, this corresponds to policy 2007-23: End Policy for IANA IPv4 allocations to RIRs (adopted by the ARIN Board of Trustees 20 June 2008). https://www.arin.net/policy/proposals/2007_23.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Wed Mar 18 14:46:04 2009 From: info at arin.net (Member Services) Date: Wed, 18 Mar 2009 14:46:04 -0400 Subject: Policy Proposal: IPv6 Multiple Discrete Networks Message-ID: <49C1416C.9070203@arin.net> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the 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 Policy Development Process can be found at: http://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv6 Multiple Discrete Networks Proposal Originator: David Divins Proposal Version: 1 Date: 3/17/2009 Proposal type: Add Policy term: Permanent Policy statement: Organizations with multiple discrete IPv6 networks desiring to request new or additional address space under a single Organization ID must meet the following criteria: 1. The organization shall be a single entity and not a consortium of smaller independent entities. 2. The organization must have compelling criteria for creating discrete networks. Examples of a discrete network might include: 1. Regulatory restrictions for data transmission, 2. Geographic distance and diversity between networks, 3. Autonomous multihomed discrete networks. 3. The organization must keep detailed records on how it has allocated space to each location, including the date of each allocation. 4. The organization should notify ARIN at the time of the request their desire to apply this policy to their account. Rationale: This proposed policy is suggested as NRPM 6.11. The policy is intended to provide parity between current IPv4 policy and allow discrete network operators to obtain IPv6 space. Timetable for implementation: Immediately From info at arin.net Fri Mar 20 13:29:47 2009 From: info at arin.net (Member Services) Date: Fri, 20 Mar 2009 13:29:47 -0400 Subject: Policy Proposal: Sunset 2008-6 on schedule Message-ID: <49C3D28B.4060103@arin.net> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the 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 Policy Development Process can be found at: http://www.arin.net/policy/pdp.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: Sunset 2008-6 on schedule Proposal Originator: Owen DeLong Proposal Version: 1.0 Date: 19 March 2009 Proposal type: delete Policy term: permanent Policy statement: Effective March 31, 2012, the changes made to the NRPM by policy 2008-6 are to be deleted. Rationale: Part of the policy that the community developed consensus for in 2008-6 included a sunset clause. The ARIN Board in an unprecedented action chose to discard this clause while approving the remainder of the policy. This proposal is intended to restore the will of the community and ensure that this policy remains temporary as intended. Timetable for implementation: March 31, 2012 From info at arin.net Mon Mar 23 15:05:03 2009 From: info at arin.net (Member Services) Date: Mon, 23 Mar 2009 15:05:03 -0400 Subject: Draft Policy 2008-3: Community Networks IPv6 Assignment Message-ID: <49C7DD5F.7070306@arin.net> SUBJECT: Draft Policy 2008-3: Community Networks IPv6 Assignment Draft Policy 2008-3 Community Networks IPv6 Assignment The following draft policy text is being posted for feedback and discussion on the Public Policy Mailing List (PPML). After the October 2008 Public Policy Meeting the ARIN Advisory Council (AC) decided that 2008-3 required more work. The text below was developed by the AC. The AC was required to submit text to ARIN for staff and legal assessment prior to selecting it as a draft policy. The assessment, along with the text that was assessed, is located below the draft policy. On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy 2008-3: Community Networks IPv6 Assignment for adoption discussion on the PPML and at the upcoming Public Policy Meeting. Draft Policy 2008-3 is below and can be found at: https://www.arin.net/policy/proposals/2008_3.html We encourage you to discuss Draft Policy 2008-3 on PPML prior to the ARIN XXIII Public Policy Meeting. Both the discussion on the PPML and at the Public Policy Meeting will be used by the ARIN Advisory Council to determine the community consensus regarding adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html All of the Draft Policies under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2008-3 Community Networks IPv6 Assignment Date: 23 March 2009 Policy statement: [Add Section 2.8 to the NRPM.] 2.8 Community Network A community network is any network organized and operated by a mostly volunteer group operating as or under the fiscal support of a non-profit organization or university for the purpose of providing free or low-cost connectivity to the residents of their local service area. To be treated as a community network under ARIN policy, the applicant must further certify to ARIN that the community network staff is at least 50% volunteer and that the annual budget for community network activities is less than $250,000. [Modify 6.5.8.1b as follows.] b. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect or be a qualifying Community Network as defined in Section 2.8, with assignment criteria defined in section 6.5.9. [Add Section 6.5.9 to the NRPM.] 6.5.9 Community Network Assignments 6.5.9.1 Qualification Criteria To qualify for a direct assignment, a community network must demonstrate it will immediately provide sustained service to at least 100 simultaneous users and must demonstrate a plan to provide sustained service to at least 200 simultaneous users within one year. For community networks located in rural regions or in the Caribbean and North Atlantic Islands Sector, the numbers in these qualification criteria may be relaxed at ARIN's discretion. 6.5.9.2. Initial assignment size The minimum size of the assignment is /48. Organizations requesting a larger assignment must provide documentation of the characteristics of the Community Network's size and architecture that require the use of additional subnets. An HD-Ratio of .94 with respect to subnet utilization within the network must be met for all assignments larger than a /48. These assignments shall be made from a distinctly identified prefix and shall be made with a reservation for growth of at least a /44. This reservation may be assigned to other organizations later, at ARIN's discretion. 6.5.9.3. Subsequent assignment size Additional assignments may be made when the need for additional subnets is justified. Justification will be determined based on a detailed plan of the network's architecture and the .94 HD-Ratio metric. When possible, assignments will be made from an aggregatable adjacent address block. Rationale: this policy was originally proposed by community network operators to provide them with the ability to receive a direct assignment of IPv6 address resources from ARIN. the operators of such networks have expressed their need to have a stable and globally unique address assignment with which to number their network infrastructure. many such networks are not able to meet the current criteria for a PI IPv6 assignment from ARIN. in an environment where connections to outside networks may come and go, a stable internal address structure would be very valuable. additionally, the ability to exchange routes with others, whether locally or tunneled, and thereby have native IPv6 connectivity, would be quite beneficial. these operators were also hopeful that, once this new class of address assignments was created, they could pursue lower annual fees for community networks through the ARIN Consultation and Suggestion Process (ACSP). there could also be a number of potential benefits to allowing community network participants to begin using IPv6 addressing. some of these networks have many technically capable and adventurous members who would be motivated to begin developing and/or experimenting with the software extensions which will be needed to support IPv6 prefix selection among multiple IPv6 prefixes when establishing remote connections. also, participants in networks receiving such assignments will have the necessary global-ID to experiment with the various proposals currently being developed for separating network locater from network ID. also, during the more than one year timeframe that this policy has been under consideration, other people have suggested other scenarios where community networks would provide a valuable resource. one such proposal was discussed at one of the Caribbean Sector meetings where some participants pointed out the efforts were being made in remote or sparsely populated areas to establish community networks which would serve as connections back to educational resources for distant learning capabilities. there are also many still wild areas of North America where such community networks could provide improved connectivity over telephone modems. Timetable for implementation: Immediate. ##### ARIN Staff Assessment *2008-3* *Title: Community Networks IPv6 Allocation* *Proposal Submitted: 04 March 2008* *Latest Revision Submitted: 06 March 2009 (includes AC revisions)* *Date of Assessment: 15 March 2009* I. Understanding of the Policy: *Staff Understanding of the Proposal:* ARIN staff understands this policy would provide an IPv6 assignment of a /48 or larger to any community network that can demonstrate it will provide service to at least 100 users immediately, and have a plan to demonstrate that it will provide service to at least 200 users within one year. II. Comments A. ARIN Staff Comments: ? The title of the policy says ?allocation? while this policy is clearly an ?assignment? policy. Therefore, the title should be changed. In addition, the title of section 6.5.9 should be changed to say ?assignment? and not ?allocation?. B. ARIN General Counsel Comments: Counsel sees no significant legal or litigation risk regarding this policy. III. Resource Impact The resource impact of implementing this policy is viewed as minimal. It is estimated that this policy could require up to 1 person month of effort to implement following ratification by the ARIN Board of Trustees. It may require the following: * Guidelines Changes * Staff training * Development of new internal procedures Text assessed: 2008-3: Community Networks IPv6 Allocation** *Policy statement:* [Add Section 2.8 to the NRPM.] 2.8 Community Network A community network is any network organized and operated by a mostly volunteer group operating as or under the fiscal support of a non-profit organization or university for the purpose of providing free or low-cost connectivity to the residents of their local service area. To be treated as a community network under ARIN policy, the applicant must further certify to ARIN that the community network staff is at least 50% volunteer and that the annual budget for community network activities is less than $250,000. [Modify 6.5.8.1b as follows.] b. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect or be a qualifying Community Network as defined in Section 2.8, with allocation criteria defined in section 6.5.9. [Add Section 6.5.9 to the NRPM.] 6.5.9 Community Network Allocations 6.5.9.1 Qualification Criteria To qualify for a direct assignment, a community network must demonstrate it will immediately provide sustained service to at least 100 simultaneous users and must demonstrate a plan to provide sustained service to at least 200 simultaneous users within one year. For community networks located in rural regions or in the Caribbean and North Atlantic Islands Sector, the numbers in these qualification criteria may be relaxed at ARIN's discretion. 6.5.9.2. Initial assignment size The minimum size of the assignment is /48. Organizations requesting a larger assignment must provide documentation of the characteristics of the Community Network's size and architecture that require the use of additional subnets. An HD-Ratio of .94 with respect to subnet utilization within the network must be met for all assignments larger than a /48. These assignments shall be made from a distinctly identified prefix and shall be made with a reservation for growth of at least a /44. This reservation may be assigned to other organizations later, at ARIN's discretion. 6.5.9.3. Subsequent assignment size Additional assignments may be made when the need for additional subnets is justified. Justification will be determined based on a detailed plan of the network's architecture and the .94 HD-Ratio metric. When possible, assignments will be made from an aggregatable adjacent address block. From info at arin.net Mon Mar 23 15:05:18 2009 From: info at arin.net (Member Services) Date: Mon, 23 Mar 2009 15:05:18 -0400 Subject: =?windows-1252?Q?Draft_Policy_2008-7=3A_Identify_Invalid?= =?windows-1252?Q?_WHOIS_POC=92s?= Message-ID: <49C7DD6E.3010106@arin.net> SUBJECT: Draft Policy 2008-7: Identify Invalid WHOIS POC?s Draft Policy 2008-7 Identify Invalid WHOIS POC?s The following draft policy text is being posted for feedback and discussion on the Public Policy Mailing List (PPML). After the October 2008 Public Policy Meeting the ARIN Advisory Council (AC) decided that 2008-7 required more work. The text below was developed by the AC with help from the proposal originators. The AC was required to submit text to ARIN for staff and legal assessment prior to selecting it as a draft policy. The assessment, along with the text that was assessed, is located below the draft policy. On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy 2008-7: Identify Invalid WHOIS POC?s (formally known as WHOIS Integrity Policy Proposal) for adoption discussion on the PPML and at the upcoming Public Policy Meeting. Draft Policy 2008-7 is below and can be found at: https://www.arin.net/policy/proposals/2008_7.html We encourage you to discuss Draft Policy 2008-7 on PPML prior to the ARIN XXIII Public Policy Meeting. Both the discussion on the PPML and at the Public Policy Meeting will be used by the ARIN Advisory Council to determine the community consensus regarding adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html All of the Draft Policies under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2008-7 Identify Invalid WHOIS POC?s Date: 23 March 2009 Policy Statement: During ARINs annual WHOIS POC validation, an e-mail will be sent to every POC in the WHOIS database. Each POC will have a maximum of 60 days to respond with an affirmative that their WHOIS contact information is correct and complete. Unresponsive POC email addresses shall be marked as such in the database. If ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the record shall be deleted. ARIN will maintain, and make readily available to the community, a current list of address-blocks with no valid POC; this data will be subject to the current bulk WHOIS policy. Timetable for implementation: Immediate ##### ARIN Staff Assessment 2008-7 Title: Identify Invalid WHOIS POC's (formerly known as WHOIS Integrity Policy Proposal) Revision Submitted: 07 March 2008 2nd Revision Submitted: 12 Feb 2009 Date of Assessment: 24 Feb 2009 The assessment of this text includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this text as it is currently stated. Any changes to the language may necessitate further analysis by staff and Counsel. I. Understanding ARIN staff understands that this will institute an annual re-registration of all POCs registered in WHOIS. POCs who do not respond within 60 days will be marked in the database as "un-responsive" and if staff deems them to be invalid for any reason, may remove them from WHOIS. In addition, staff will maintain a list of all address blocks with no valid POCs and will make this data available to any organization using the bulk whois policy criteria. II. Issues and Concerns A. ARIN Staff Comments: * Resource records marked as ?unresponsive? or those with no POCs at all could become the targets of hijackers who, in the past have tended to look for address blocks that contain obsolete or stale data. * An annual re-registration of all POCs (~223,000 currently) will likely result in a vast increase in workload, particularly with the follow up work and research involved when a POC does not reply within 60 days. This could result in a slow down in registration response and processing times. * This policy refers to the Bulk Whois policy rather than stating the actual criteria under which an organization will be allowed to request the list of all address blocks with no valid POCs. It would be better policy text to state the specific criteria, including the requirement to sign an AUP, within this policy itself. B. ARIN General Counsel * It is possible those delisted will threaten or file litigation to be relisted. However, a properly promulgated policy does not pose antirust or other legal concerns. III. Resource Impact The resource impact of implementing this policy is viewed as significant. Barring any unforeseen resource requirements, it is estimated that this policy could take up to 18 person months to fully implement from the date of ratification of the policy by the ARIN Board of Trustees. It may require the following: * Staff training * Development of new internal process and procedures and modification to existing ones * Creation of an automated system to track notifications, updates, and current status of the POC notification. Provide allowances for manual intervention and follow-up by staff. Engineering estimates that it could take up to 18 person months for the creation and implementation of this system. In addition, this could impact ARIN?s current project deployment schedule. * Increased workload could result in the need for additional staff Text assessed: 2008-7: Identify Invalid WHOIS POC's (formally known as WHOIS Integrity Policy Proposal) Revised text is as follows: During ARINs annual WHOIS POC validation, an e-mail will be sent to every POC in the WHOIS database. Each POC will have a maximum of 60 days to respond with an affirmative that their WHOIS contact information is correct and complete. Unresponsive POC email addresses shall be marked as such in the database. If ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the record shall be deleted. ARIN will maintain, and make readily available to the community, a current list of address-blocks with no valid POC; this data will be subject to the current bulk WHOIS policy. From info at arin.net Mon Mar 23 15:05:31 2009 From: info at arin.net (Member Services) Date: Mon, 23 Mar 2009 15:05:31 -0400 Subject: Draft Policy 2009-2: Depleted IPv4 reserves Message-ID: <49C7DD7B.5000901@arin.net> Draft Policy 2009-2 Depleted IPv4 reserves The following draft policy text is being posted for feedback and discussion on the Public Policy Mailing List (PPML). This draft policy was developed by the ARIN Advisory Council (AC) from Policy Proposal 81: Depleted IPv4 reserves. The AC has taken the proposal and developed it into a draft policy. The AC was required to submit text to ARIN for staff and legal assessment prior to selecting it as a draft policy. The assessment, along with the text that was assessed, is located below the draft policy. On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy 2009-2: Depleted IPv4 reserves for adoption discussion on the PPML and at the upcoming Public Policy Meeting. Draft Policy 2009-2 is below and can be found at: https://www.arin.net/policy/proposals/2009_2.html We encourage you to discuss Draft Policy 2009-2 on the PPML prior to the ARIN XXIII Public Policy Meeting. Both the discussion on the PPML and at the Public Policy Meeting will be used by the AC to determine the community consensus regarding adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html All of the Draft Policies under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2009-2 Depleted IPv4 reserves Date: 23 March 2009 Policy statement: (add the following section to the NRPM) 4.1.8 Depleted IPv4 reserves A limit will be applied to all IPv4 address requests when ARIN's reserve of unallocated IPv4 address space drops below an equivalent /9. When this happens, an ISP or End User may receive up to a single /20 within a six month period. This restriction will be lifted in the event the reserve of unallocated IPv4 address space increases to an equivalent /7. Rationale: As the reserve of IPv4 address space becomes smaller, there is a risk that many organizations will be denied resources by a large, last minute request. By implementing a throttle on the last of the IPv4 address space, a more limited group of organizations will be impacted, allowing many organizations to receive ongoing resources during the transition to IPv6. According to the ARIN statistics page http://www.arin.net/statistics/index.html, 1,993 organizations were issued IP space in 2006 and 2007. Of these allocations 41% of the applicants received less than a /20. On the opposite end, 82 organizations received large blocks. Given that the last reserve of IPv4 space cannot possibly meet the needs of the 82 organizations, the space could be managed in a way to provide for the needs of a wider base of consumers while the largest ISPs build momentum behind IPv6. The goal is to find a balance between the needs of organizations requiring space, and avoiding the restrictions on end user growth. For this reason, any caps on allocations should be implemented when the reserves are essentially depleted, rather than trying to restrict end user growth when IP space is still readily available. By putting a six month window on the maximum allocation, the remaining IP space could provide at least one year for everyone to implement other solutions while still being able to obtain an IPv4 address allocation. The time period was also added to provide a consistent rate of depletion, avoiding a scenario where a large organization could queue multiple, justifiable requests, resulting in the scenario the proposal is intended to avoid. Additional language may need to be added in the event a paid transfer policy is approved. The thinking is to have two pools of available IP. One being the current, IANA allocated, reserve of IP space. The second being IP blocks recovered through monetary incentive. This proposal would apply to the IANA allocated reserves and would not apply to blocks made available by monetary means. An additional thought was to avoid tying this policy shift specifically to the last /8 allocated by IANA. This allows the policy to come in and out of play in the event that IPv4 address space is abandoned or returned to ARIN. Timetable for implementation: Immediate ##### ARIN Staff Assessment *Title: Depleted IPv4 Reserves* *Proposal Submitted: 02 Dec 2008* *Revision Submitted: 16 Feb 2009* *Date of Assessment: 10 March 2009* I. Understanding of the Policy: *Staff Understanding of the Proposal:* ARIN understands this policy goes into effect when ARIN has less than a /9 worth of IPv4 address space available to be issued to customers. At that time, an ISP or End user can only receive a /20 from ARIN within a six month period. This restriction will be removed if ARIN?s available pool of addresses increases to a /7 equivalent. II. Comments: A. ARIN Staff Comments: o One question to consider is whether staff should be setting aside a /9 in anticipation of this policy. If that is not done, there is the potential that one large request could take away a very large block of ARIN?s remaining inventory and leave us with far less than the /9 equivalent needed to implement this policy. For example, if there is one /8 left, and ISP A qualifies for a /8, and it gets issued, then there will be no address space left to issue under this policy. + If the intent is to make sure there is at least a /9 available to give out in /20 blocks, then the trigger point may need to be reconsidered. Here are two potential options: # Trigger the policy when filling a request would drop the supply below a /9 # Give the org whose request would drop the supply below a /9 as many addresses as would take us to a /9, then trigger the policy. B. ARIN General Counsel Comments: The policy does not pose any significant legal risk to ARIN. A community decision to segment the remaining unissued IPV4 numbers to serve a larger number of users on its face does not discriminate against or for any user, large or small. Therefore it is legally unobjectionable. It is a rational scheme for distribution reasonably related to meeting the needs of as many end users as possible. Counsel respectfully suggests that the policy as drafted may contain potential seeds of confusion by providing for switching back to current distribution policies, and then back to this policy. III. Resource Impact The resource impact of implementing this policy is viewed as minimal. It is estimated that this policy could require up to 3 person months of effort to implement following ratification by the ARIN Board of Trustees. Because this implementation is not planned, it may preempt ARIN?s current project deployment schedule. It may require the following: * Guidelines Changes * Modifications to existing registration software tools ? they need to be able to report to staff existing inventory levels and to notify us when the /9 threshold is reached or is imminent. Text assessed: Depleted IPv4 reserves *Policy statement:* 4.1.8 Depleted IPv4 reserves A limit will be applied to all IPv4 address requests when ARIN's reserve of unallocated IPv4 address space drops below an equivalent /9. When this happens, an ISP or End User may receive up to a single /20 within a six month period. This restriction will be lifted in the event the reserve of unallocated IPv4 address space increases to an equivalent /7. From info at arin.net Mon Mar 23 15:05:43 2009 From: info at arin.net (Member Services) Date: Mon, 23 Mar 2009 15:05:43 -0400 Subject: Draft Policy 2009-3 (Global): Allocation of IPv4 Blocks to Regional Internet Registries Message-ID: <49C7DD87.4010508@arin.net> Draft Policy 2009-3 (Global) Allocation of IPv4 Blocks to Regional Internet Registries The following draft policy text is being posted for feedback and discussion on the Public Policy Mailing List (PPML). This draft policy was developed by the ARIN Advisory Council (AC) from Policy Proposal 82: Allocation of IPv4 Blocks to Regional Internet Registries. The AC has taken the proposal and developed it into a draft policy. The AC was required to submit text to ARIN for staff and legal assessment prior to selecting it as a draft policy. The assessment, along with the text that was assessed, is located below the draft policy. On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy 2009-3: Allocation of IPv4 Blocks to Regional Internet Registries for adoption discussion on the PPML and at the upcoming Public Policy Meeting. Draft Policy 2009-3 is below and can be found at: https://www.arin.net/policy/proposals/2009_3.html We encourage you to discuss Draft Policy 2009-3 on the PPML prior to the ARIN XXIII Public Policy Meeting. Both the discussion on the PPML and at the Public Policy Meeting will be used by the AC to determine the community consensus regarding adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html All of the Draft Policies under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2009-3 (Global) Allocation of IPv4 Blocks to Regional Internet Registries Date: 23 March 2009 Policy statement: This document describes the policy governing the allocation of IPv4 address space from the IANA to the Regional Internet Registries (RIRs). This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with this policy. Such requirements should be specified by appropriate agreements among the RIRs and ICANN. This policy is to be implemented in two phases. A. Phase I: Recovery of IPv4 Address Space Upon ratification of this policy by the ICANN Board of Directors the IANA shall establish a mechanism to receive IPv4 address space which is returned to it by the RIRs, and hold that address space in a 'recovered IPv4 pool'. Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration. At quarterly intervals, each RIR shall return to the IANA any legacy address space recovered, and may return to the IANA any non-legacy address space recovered, in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool. During Phase I, no allocations will be made from the recovered IPv4 pool. Return of recovered address space (as described above) will continue throughout Phase II. B. Phase II: Allocation of Recovered IPv4 address space by the IANA Upon ratification of this policy by the ICANN Board of Directors and a declaration by the IANA that its existing free pool of unallocated IPv4 address space is depleted; Global Addressing Policy ASO-001-2 (adopted by ICANN Board 8 April 2005) is rescinded. IANA will then commence to allocate the IPv4 address space from the recovered IPv4 pool. 1. The following definitions apply to this policy: a. Recovered Address Space. Recovered address space is that address space that is returned to an RIR as a result of any activity that seeks to reclaim unused address space or is voluntarily returned to the RIR or is reclaimed by the RIR as a result of legal action or abuse determination. Recovered address space does not include that address space that is reclaimed because of non-payment of contractual fees whose reclamation date is less than 1 year at the time of the report. b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4 address space held by an RIR to include recovered address space not yet returned less that address space that is committed in accordance with the RIR's reservation policy and practices. c. Aggregated address blocks. Aggregated address blocks are contiguous prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24 and 10.0.1.0/24 are two contiguous prefixes that can be combined to form an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two contiguous prefixes that cannot be combined on a natural bit boundary to form an aggregated block. d. Legacy address space. IPv4 address space allocated or assigned prior to the creation of the RIR. 2. Allocation of IPv4 Address Space a. For the purposes of this policy, an 'IPv4 allocation period' is defined as a 6-month period following 1 March or 1 September in each year. b. At the beginning of each IPv4 allocation period, the IANA will determine the 'IPv4 allocation unit' for that period, as 1/10 of its IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary. The minimum 'IPv4 allocation unit' size will be a /24. c. In each allocation period, each RIR may issue one IPv4 request to the IANA. Providing that the RIR satisfies the allocation criteria described in paragraph B.2, the IANA will allocate a single allocation unit, composed of the smallest possible number of blocks available in its IPv4 address pool. 3. IPv4 Address Space Allocation Criteria A RIR is eligible to receive additional IPv4 address space from the IANA when the total of its IPv4 address holdings is less than 50% of the current IPv4 allocation unit, and providing that it has not already received an IPv4 allocation from the IANA during the current IPv4 allocation period. 4. Initial Allocation of IPv4 Address Space Each new RIR shall, at the moment of recognition, be allocated one (1) allocation unit by the IANA. If an allocation unit is not available, then the IANA will issue this block as soon as one is available. This allocation will be made regardless of the newly formed RIR's projected utilization figures and shall be independent of the IPv4 address space that may have been transferred to the new RIR by the already existing RIRs as part of the formal transition process. 5. Reporting a. All returned space is to be recorded in an IANA-published log of IPv4 address space transactions, with each log entry detailing the returned address block, the date of the return, and the returning RIR. b. All allocated space is also to be recorded in this IANA-published log of IPv4 address space transactions, with each log entry detailing the address blocks, the date of the allocation and the recipient RIR. c. The IANA will maintain a public registry of the current disposition of all IPv4 address space, detailing all reservations and current allocations and current IANA-held address space that is unallocated. d) The IANA may make public announcements of IPv4 address block transactions that occur under this policy. The IANA will make appropriate modifications to the "Internet Protocol V4 Address Space" page of the IANA website and may make announcements to its own appropriate announcement lists. The IANA announcements will be limited to which address ranges, the time of allocation and to which Registry they have been allocated. ##### ARIN Staff Assessment *Title: Allocation of IPv4 Blocks to the Regional Internet Registries* *Proposal Submitted: 30 Jan 2009* *Revision Submitted: 05 March 2009* *Date of Assessment: 10 March 2009* * * I. Understanding of the Policy: *Staff Understanding of the Proposal:* Staff understands that this proposal would be implemented in 2 phases. Phase 1 would require the RIRs to return recovered IPv4 legacy address space (via policy or procedure) to the IANA and have the option of returning recovered non-legacy address space to the IANA. Phase 2 would start after the depletion of the IANA free pool and would nullify the existing IANA to RIR policy (Global Addressing Policy ASO-001-2). The new IANA to RIR policy would allow each RIR to receive approximately 1/10th of the recovered IPv4 pool from IANA once every 6 months as long as it meets the qualification criteria written in paragraph B2. IANA will be required to keep a log of all returned IPv4 address space and all issued IPv4 address space from the recovered pool, as well as maintain a public registry of the current disposition of all IPv4 address space. II. Comments A. ARIN Staff Comments * The one policy that this impacts is NRPM 4.6 Amnesty and Aggregation, which says ?Transactions should only be accepted under this policy if they are in the interests of the community (e.g. they improve aggregation or result in a net reclamation of space).? Because the ARIN region holds the majority of the legacy address space, and most of the address space returned under this policy is legacy space, it would mean that there would be no ?net return? of address space to ARIN. ARIN would essentially be exchanging legacy address space for non-legacy address space, and returning the legacy address space it received in the exchange to IANA, resulting in a net loss of address space in ARIN?s available pool. B. ARIN General Counsel Comments: The current basis of allocation of numbers was established in RFC's 2008 and 2050 and is need based. If one region has greater needs than another, the current policy of IANA does not require equal distribution to all RIR's s. This proposed policy would establish a different political and not needs based method for allocating returned space. It would make each RIR an equal recipient of such space. But the level of need and economic activity between each RI R is not equal. This policy will tend to reallocate returned space away from where it is recovered, in the ARIN region , and move more of it to AFRINIC and LACNIC than current distribution principles. By equating the smaller economies and related needs of certain regions to the needs of other regions, like ARIN, that have greater day to day need, it in effect creates a new political order of distribution thru equal shares. It is possible sovereign governments in the regions with greater activity will not agree to such a revised distribution model. The proposed policy undermines the legal rationale for distribution. The policy also creates a powerful disincentive for any RIR, including ARIN, to undertake any financial expenditure of RIR dollars for programs intended to obtain returned space for reallocation. Currently ARIN is working towards policies such as the LRSA and 2008-6, intended to encourage returns and use of under utilized resources, but which cost ARIN expenditures other RIRs are not duplicating. Any policy which creates such a disincentive by leaving expenditures with a single RIR, who cannot benefit except to receive 20% of the returned space should be carefully considered. Finally, it is likely entities with number resources in the ARIN region may be willing to return those resources for uses in the region but unwilling to do so if 4/5 of such resources will be sent to other regions. III. Resource Impact The resource impact of implementing this policy is viewed as minimal. It is estimated that this policy could require up to 3 person months of effort to implement following ratification by the ARIN Board of Trustees. Because this implementation is not planned, it may preempt ARIN?s current project deployment schedule. It may require the following: * Modifications to existing registration procedures to include the handling of returned/reclaimed address space and the process of requesting additional address space from the IANA. * Staff training Text assessed: *Allocation of IPv4 Blocks to Regional Internet Registries (Global)* *Policy statement:* This document describes the policy governing the allocation of IPv4 address space from the IANA to the Regional Internet Registries (RIRs). This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with this policy. Such requirements should be specified by appropriate agreements among the RIRs and ICANN. This policy is to be implemented in two phases. A. Phase I: Recovery of IPv4 Address Space Upon ratification of this policy by the ICANN Board of Directors the IANA shall establish a mechanism to receive IPv4 address space which is returned to it by the RIRs, and hold that address space in a 'recovered IPv4 pool'. Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration. At quarterly intervals, each RIR shall return any legacy address space recovered, and may return any non-legacy address space recovered, to the IANA in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool. During Phase I, no allocations will be made from the recovered IPv4 pool. Return of recovered address space (as described above) will continue throughout Phase II. B. Phase II: Allocation of Recovered IPv4 address space by the IANA Upon ratification of this policy by the ICANN Board of Directors and a declaration by the IANA that its existing free pool of unallocated IPv4 address space is depleted; Global Addressing Policy ASO-001-2 (adopted by ICANN Board 8 April 2005) is rescinded. IANA will then commence to allocate the IPv4 address space from the recovered IPv4 pool. 1. The following definitions apply to this policy: a. Recovered Address Space. Recovered address space is that address space that is returned to an RIR as a result of any activity that seeks to reclaim unused address space or is voluntarily returned to the RIR or is reclaimed by the RIR as a result of legal action or abuse determination. Recovered address space does not include that address space that is reclaimed because of non-payment of contractual fees whose reclamation date is less than 1 year at the time of the report. b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4 address space held by an RIR to include recovered address space not yet returned less that address space that is committed in accordance with the RIR's reservation policy and practices. c. Legacy address space. IPv4 address space allocated or assigned prior to the creation of the RIR. 2. Allocation of IPv4 Address Space a. For the purposes of this policy, an 'IPv4 allocation period' is defined as a 6-month period following 1 March or 1 September in each year. b. At the beginning of each IPv4 allocation period, the IANA will determine the 'IPv4 allocation unit' for that period, as 1/10 of its IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary. c. In each allocation period, each RIR may issue one IPv4 request to the IANA. Providing that the RIR satisfies the allocation criteria described in paragraph B.2, the IANA will allocate a single allocation unit, composed of the smallest possible number of blocks available in its IPv4 address pool. 3. IPv4 Address Space Allocation Criteria A RIR is eligible to receive additional IPv4 address space from the IANA when the total of its IPv4 address holdings is less than 50% of the current IPv4 allocation unit, and providing that it has not already received an IPv4 allocation from the IANA during the current IPv4 allocation period. 4. Initial Allocation of IPv4 Address Space Each new RIR shall, at the moment of recognition, be allocated one (1) allocation unit by the IANA. If an allocation unit is not available, then the IANA will issue this block as soon as one is available. This allocation will be made regardless of the newly formed RIR's projected utilization figures and shall be independent of the IPv4 address space that may have been transferred to the new RIR by the already existing RIRs as part of the formal transition process. 5. Reporting a. All returned space is to be recorded in an IANA-published log of IPv4 address space transactions, with each log entry detailing the returned address block, the date of the return, and the returning RIR. b. All allocated space is also to be recorded in this IANA-published log of IPv4 address space transactions, with each log entry detailing the address blocks, the date of the allocation and the recipient RIR. c. The IANA will maintain a public registry of the current disposition of all IPv4 address space, detailing all reservations and current allocations and current IANA-held address space that is unallocated. d) The IANA may make public announcements of IPv4 address block transactions that occur under this policy. The IANA will make appropriate modifications to the "Internet Protocol V4 Address Space" page of the IANA website and may make announcements to its own appropriate announcement lists. The IANA announcements will be limited to which address ranges, the time of allocation and to which Registry they have been allocated. From info at arin.net Mon Mar 23 15:06:02 2009 From: info at arin.net (Member Services) Date: Mon, 23 Mar 2009 15:06:02 -0400 Subject: Draft Policy 2009-4: IPv4 Recovery Fund Message-ID: <49C7DD9A.6030907@arin.net> Draft Policy 2009-4 IPv4 Recovery Fund The following draft policy text is being posted for feedback and discussion on the Public Policy Mailing List (PPML). This draft policy was developed by the ARIN Advisory Council (AC) from Policy Proposal 80: IPv4 Recovery Fund. The AC has taken the proposal and developed it into a draft policy. The AC was required to submit text to ARIN for staff and legal assessment prior to selecting it as a draft policy. The assessment, along with the text that was assessed, is located below the draft policy. On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy 2009-4: IPv4 Recovery Fund for adoption discussion on the PPML and at the upcoming Public Policy Meeting. Draft Policy 2009-4 is below and can be found at: https://www.arin.net/policy/proposals/2009_4.html We encourage you to discuss Draft Policy 2009-4 on the PPML prior to the ARIN XXIII Public Policy Meeting. Both the discussion on the PPML and at the Public Policy Meeting will be used by the AC to determine the community consensus regarding adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html All of the Draft Policies under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2009-4 IPv4 Recovery Fund Date: 23 March 2009 Policy statement: (Create new section in section 4, represented by "4.X".) 4.X IPv4 Recovery Fund 4.X.1 Implementation Timing Upon receiving a valid request for a block larger than ARIN can satisfy from its existing free pool, or, by obtaining additional space from IANA, ARIN shall begin offering financial incentives for returned IP blocks according to this policy. 4.X.2 Recovery of IPv4 Space ARIN believes that organizations should voluntarily return unused and/or unneeded IP resources to the community. However, upon implementation of this policy, ARIN will offer financial incentives for the return of IPv4 resources to ARIN relinquishment of any future claims to those resources. ARIN will continue to accept voluntary returns. 4.X.3 Allocation of Recovered Space Once approved for IPv4 space ARIN will ask the requester to specify a bid of how much they are willing to pay for reclamation of address space. ARIN will use this bid in determining what incentives to offer for return of space. The requester may make a higher bid at any time, which is treated as a brand new bid replacing their old bid. If ARIN recovers space and offers it to requester at or below the specified bid within 60 days of the time the bid was made then the bid shall be binding on requester at the price ARIN offers the space. 4.X.4 Address Block Management ARIN may not offer a partial fill, that is provide a block smaller than the one for which the requester was approved. ARIN may split recovered blocks into multiple smaller blocks at the staff's discretion using the following principals: - It is unlikely a request will be made for the address block size involved in the next 60 days. - The block is divided into as few parts as practical. - There are enough bids to allow the entire block to be allocated. 4.X.5 Transparency ARIN staff shall make public the current and historical prices of asks, bids, and executed transactions in a manor that facilitates the bidding process. ARIN staff must regularly report on the amount of address space obtained and distributed via this mechanism, number of blocks subdivided, as well as aggregate financial numbers. 4.X.6 Cost Recovery ARIN shall manage the address space recovery program with a goal of cost recovery. ARIN may: - Use ARIN funds to reclaim blocks when there is no specific demand; if such reclamation is deemed in the best interest of the community and there is a significant likelyhood of future demand. - Use a portion of the funds collected under this program to pay for the implementation of this program. Rationale: Many have recognized that in order for unused or poorly used IPv4 resources to be returned to the free pool that financial compensation will be required. This is particularly the case in poorly used assets where the current holder may have to expend time and money to renumber in order to free the blocks. This proposal sets up a fund administered by ARIN to encourage the return of space. Effectively ARIN will offer financial incentives to return unused or poorly used IPv4 resources and place them back into the IPv4 free pool. The intention is for this activity to be revenue neutral to ARIN. To achieve that goal those requesting IPv4 resources will be requested to bid on a one-time payment to the recovery fund to cover the cost of the resources they have received. The proposal is intentionally vague on the exact implementation details to staff because: - Transactions with those returning space and obtaining space may occur in any order. - The bidding process may need to evolve over time, and may not be as simple as highest bidder wins. It may include aspects such as a dutch auction style format (all winners pay the lowest winning price), or may include other factors such as which size blocks ARIN has free in an effort to limit deaggregation. - ARIN will have to develop contracts and procedures around this activity that are better suited for staff and legal than the policy process. Compared to other "transfer proposals", this proposal has the following benefits: - Maintains that IP addresses are not property. - Maintains the concept that unused addresses should be returned to the free pool. - Maintains need based addressing. - Removes the need for those with excess resources to find those without resources. There is no need for any sort of listing service, eBay, etc. - All transactions are two party transactions with ARIN as one of the parties. The potential for multi-party legal disputes is reduced. - ARIN can absorb spikes in supply or demand, creating more level prices over time. - ARIN can provide transparency across all transactions in this system. - Reduces confusion to new entrants over where they should go to receive address space. Change Log: - Changed "monetary" to "financial" to allow for the possibility of ARIN offering things other than direct payment (like fee credits). Credit: Robert Bonomi. - Updated numbering so there were not two 4.10.2's. Also changed to using a place holder for section. Credit: Robert Bonomi - Changed the cost recovery language to be more clear and provide some additional flexibility. - Clarified 4.10.2 about future claims. Credit: Ted Mittelstaedt - Split 10.X.3 into 10.X.3 and 10.X.3 with better titles. - Left the exact algorithm to staff. Removed examples as a result. Timetable for implementation: Staff should begin developing procedures and updated templates immediately. Policy would not go into effect until the criteria listed occurs. ##### ARIN Staff Assessment * Title: IPv4 Recovery Fund* *Proposal Submitted: 08 Jan 2009 * *Date of Assessment: 10 March 2009* I. Understanding of the Policy: *Staff Understanding of the Proposal:* ARIN understands this policy allows approved requestors of IPv4 address space to place binding "bids" for the addresses they have been approved. In turn, ARIN can use the monies from those bids to offer financial incentives to registrants of address space to return unused or unneeded addresses to the free pool for reissue to the approved requestors. II. Comments A. ARIN Staff Comments: * It is unclear to staff exactly when this policy would be triggered. For example, if someone is approved for a /9, and ARIN has only bits of fragmented space left (/10, /12, /13, etc.) which together could fill a /9 request, would this trigger this policy? In other words, can ARIN use dis-contiguous smaller blocks or would the requester be denied and asked to bid on a /9 that may be returned in the future? * The policy appears to say that once a request cannot be filled, a requester must make a bid. There does not seem to be an option of waiting for a block that is voluntarily returned. It would be helpful if the policy specified that once the policy is triggered, there is no opting out, if this is indeed the case. * Once the policy is triggered, it is difficult to tell whether every request must then be filled via the bid process or if requesters can choose not to use it. Again, it would be helpful if this were specifically spelled out in the policy text. * Under section 4.X.3 what would happen if a requester doesn't pay the bid amount they committed to? If ARIN is paying the money up front for that address space but is unable to collect that amount back, it could put ARIN at some financial risk. * The bidding process as laid out in section 4.X.3 is somewhat confusing. There is no mention made of a situation where there are two bidders competing for the same address space. Would ARIN automatically award the space to the highest bidder? If so, could that be viewed as an unfair process that rewards those with the most monetary resources? * If someone return's space without monetary compensation in the midst of this, it is not clear whether ARIN would then offer that address space under the current fee structure or under this bid structure. * The term "cost recovery? in section 4x6 should be clearly defined. Specifically, this states that we can use "a portion" of the funds collected to recover space even when there is no demand. * Is there anything to prohibit out of region bidders? ARIN?s current practice is to issue address space only to organizations that will be using that space within ARIN?s region. If anyone can bid on this space from any region, it will represent a fundamental change in the way we operate today. * This policy would change ARIN?s current financial and business models and would significantly impact the way we do business today. * This policy could be a disincentive for people to voluntarily return IP address space, which is something that people do on a somewhat regular basis today. B. ARIN General Counsel Comments: Nothing in ARIN's Articles of Incorporation or Bylaws prevents ARIN from implementing this policy. However, this policy would represent a major shift in ARIN's activities by requiring ARIN to build business capabilities and undertake legal risks quite different from ARIN's existing business and expertise. In particular, this proposal would require that ARIN staff exercise skills as traders -- e.g. buying IPv4 resource when they think they should buy, selling when they think they should sell. The required skills are not unlike those involved in running a hedge fund or, perhaps, the US government role in buying Strategic Petroleum Reserve assets. The required skills are quite different from ARIN's core competency. This proposal would also introduce potentially capital requirements -- causing ARIN to invest its funds in purchases of v4 resource in anticipation of future sales. As a nonprofit with a limited financial reserve, ARIN faces an important financial risk from such transactions, in that ARIN could lose significant funds if IPv4 prices do not evolve as ARIN staff anticipate. The proposal is relatively silent on the specifics of ARIN's decision-making process for allocating the IPv4 resources ARIN obtains through this process. While it may be appropriate to delegate those decisions to staff, it is difficult to legally assess the proposal without a vision of the decision rules ARIN would use in allocating scarce space among multiple prospective recipients. Moreover, because many potential recipients will urgently want additional v4 space, such decisions are likely to be closely scrutinized, and ARIN would need a clear and compelling reason to choose to grant space purchased to one recipient rather than another. This proposal also exposes ARIN to significant and unameliorated legal risk. For example, in each potential transfer, ARIN participates at least twice on "good" transactions that go well -- one to receive space from an original provider, then a second time to transfer that space to an ultimate recipient. But each transaction performed presents legal risk. For example, if a putative provider promises to transfer, but reneges, ARIN might find itself having to sue to compel such sale. Conversely, if a putative provider wants to sell ARIN addresses at a given price, but ARIN is unwilling to pay that price, the provider might sue ARIN, alleging that ARIN's decision to reject that price was wrongful. (The provider might ground its case in a purchase it sees as similar, in which some other provider received that price.) As to recipients, ARIN might face liability from those who wanted v4 resource but did not receive it (at the prices they sought to offer), and ARIN might feel compelled to enter litigation if a recipient ultimately refuses to pay for resources it received. In short, ARIN would face important legal risks both due to the multiple sequential transactions and due to disputes potentially resulting from ARIN's significant decision-making discretion as to the purchase and allocation of v4 resource. These risks may be worth accepting in order to get the benefits of address transfers. However, ARIN faces significantly less legal risk from a other proposed decentralized markets where ARIN's role is not central (e.g. , see the market portion of an abandoned policy, 2008-6) in which address providers and recipients were left to their own resources to reach agreements directly between one another, without ARIN serving to receive and transfer all resources and all associated funds. III. Resource Impact The resource impact of implementing this policy is viewed as significant. It is estimated that this policy could require up to 18 person months of effort to implement following ratification by the ARIN Board of Trustees. Because this implementation is not planned, it may preempt ARIN?s current project deployment schedule. It may require the following: * The development of a tracking system to monitor the transaction, both the purchase and the sale, as well as the inventory. * The development of a reporting system. * Modifications to ARIN?s existing business model would be needed, particularly if ARIN gets into the business of buying back address space which then becomes designated as an asset and inventory. * Increased fees due to potential litigation, legal costs, and collection costs * Modifications to existing registration procedures * Staff training * Guidelines updates Text assessed: Policy Proposal Name: IPv4 Recovery Fund *Policy statement:* * (Create new section in section 4, represented by "4.X".)* *4.X IPv4 Recovery Fund* 4.X.1 Implementation Timing Upon receiving a valid request for a block larger than ARIN can satisfy from its existing free pool, or, by obtaining additional space from IANA, ARIN shall begin offering financial incentives for returned IP blocks according to this policy. 4.X.2 Recovery of IPv4 Space ARIN believes that organizations should voluntarily return unused and/or unneeded IP resources to the community. However, upon implementation of this policy, ARIN will offer financial incentives for the return of IPv4 resources to ARIN relinquishment of any future claims to those resources. ARIN will continue to accept voluntary returns. 4.X.3 Allocation of Recovered Space Once approved for IPv4 space ARIN will ask the requester to specify a bid of how much they are willing to pay for reclamation of address space. ARIN will use this bid in determining what incentives to offer for return of space. The requester may make a higher bid at any time, which is treated as a brand new bid replacing their old bid. If ARIN recovers space and offers it to requester at or below the specified bid within 60 days of the time the bid was made then the bid shall be binding on requester at the price ARIN offers the space. 4.X.4 Address Block Management ARIN may not offer a partial fill, that is provide a block smaller than the one for which the requester was approved. ARIN may split recovered blocks into multiple smaller blocks at the staff's discretion using the following principals: - It is unlikely a request will be made for the address block size involved in the next 60 days. - The block is divided into as few parts as practical. - There are enough bids to allow the entire block to be allocated. 4.X.5 Transparency ARIN staff shall make public the current and historical prices of asks, bids, and executed transactions in a manor that facilitates the bidding process. ARIN staff must regularly report on the amount of address space obtained and distributed via this mechanism, number of blocks subdivided, as well as aggregate financial numbers. 4.X.6 Cost Recovery ARIN shall manage the address space recovery program with a goal of cost recovery. ARIN may: - Use ARIN funds to reclaim blocks when there is no specific demand; if such reclamation is deemed in the best interest of the community and there is a significant likelyhood of future demand. - Use a portion of the funds collected under this program to pay for the implementation of this program. From info at arin.net Tue Mar 24 11:48:41 2009 From: info at arin.net (Member Services) Date: Tue, 24 Mar 2009 11:48:41 -0400 Subject: Policy Proposal: Protective Usage Transfer Policy for IPv4 Address - Abandoned In-Reply-To: <49B03D9B.9070103@arin.net> References: <49B03D9B.9070103@arin.net> Message-ID: <49C900D9.6040003@arin.net> Policy Proposal 83 Protective Usage Transfer Policy for IPv4 Address On 19 March 2009 the ARIN Advisory Council (AC) abandoned Policy Proposal 83: Protective Usage Transfer Policy for IPv4 Address. The AC provided the following explanation of their decision: ##### ?The Advisory Council, seeing little support and a large amount of opposition on PPML for the Policy Proposal 83 - Protective Usage Transfer Policy for IPv4 Address has decided to abandon it. Further, the Advisory Council believes that the specific issues raised in this proposal are adequately addressed by existing policy allowing critical infrastructure providers to obtain assignments directly from ARIN. Therefore, if critical infrastructure providers believe they need protected resources to guarantee the availability of Internet critical infrastructure they provide, they should obtain resources directly from ARIN, see NRPM 4.4 and 6.10. However, beyond the specific issues raised in this proposal, several more general issues and questions were raised in the discussion of this proposal. The Advisory Council intends to investigate some of these general issues and questions at a workshop in April. Additionally, the Advisory Council encourages feedback on PPML regarding these general issues and questions.? ##### The AC abandoned the proposal. Per the ARIN Policy Development Process, ?Any member of the community, including a proposal originator, may initiate a Discussion Petition if they are dissatisfied with the action taken by the Advisory Council regarding any specific policy proposal. If successful, this petition will change the policy proposal to a draft policy which will be published for discussion and review by the community on the PPML and at an upcoming public policy meeting.? Note that we have passed the deadline for petitions for the upcoming meeting in San Antonio (as posted to PPML on 9 March 2009); a successful petition at this time would be for the Fall ARIN meeting. The deadline to start a proposal petition is 30 March 2009. Petitions must include the proposal and a petition statement. Once begun, a petition lasts for 5 business days. Success is measured as support from at least 10 different people from 10 different organizations. Should an actual petition begin, ARIN staff will post additional information. The text for Draft Policies and Proposals is available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Member Services wrote: > Policy Proposal > Protective Usage Transfer Policy for IPv4 Address > > The proposal originator submitted a revised version of the proposal. > > The AC will review this proposal at their next regularly scheduled > meeting and decide how to utilize the proposal. Their decision will be > announced to the PPML. > > In the meantime, the AC invites everyone to comment on this proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > The ARIN Policy Development Process can be found at: > http://www.arin.net/policy/pdp.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: Protective Usage Transfer Policy for IPv4 Address > > Proposal Originator : Christopher A. Quesada > > Proposal Version: 2 > > Date: 5 March 2009 > > Policy statement: > > Critical infrastructure providers may appeal to ARIN for final review > and approval of any full or partial transfer of IPv4 address space that > has been in use by the critical infrastructure serving the community for > five consecutive years or more. Such appeal may result in a partial or > full approval of the requested transfer, or rejection of the transfer if > it lacks appropriate rationale, justification, or interferes with the > seamless operation of such critical infrastructure or hardship to the > provider. > > Rationale: > Protection of critical infrastructure providers of the Internet, > including public exchange points, core DNS service providers (e.g. > ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs > and IANA is necessary in order to ensure the continuous operation of the > Internet for its global service community. It is possible for an > organization to transfer an aggregate IPv4 address resource containing > allocations/assignments downstream supporting critical infrastructure > (as defined in ARIN?s Number Resource Policy Manual). This policy is > intended to protect that critical infrastructure by allowing for the > review and final approval of such transfer by ARIN, upon appeal by the > critical infrastructure provider to ARIN, within a sixty day period of > the transfer notification if such transfer would interfere with the > continuous and seamless operation of that critical infrastructure or > hardship to the provider. Review of the transfer can consist of a > request by ARIN to the transferring organization for a rationale for > such transfer. This may include but not be limited to, a requirement > for the receiving party to submit the appropriate network request form > identifying the need and justification for the aggregate IPv4 address > resource. > > > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > From info at arin.net Tue Mar 24 13:00:24 2009 From: info at arin.net (Member Services) Date: Tue, 24 Mar 2009 13:00:24 -0400 Subject: Draft Policy 2009-1: Transfer Policy (Using the Emergency PDP) Message-ID: <49C911A8.5020009@arin.net> Draft Policy 2009-1 Transfer Policy The ARIN Board of Trustees has declared a policy emergency and is making use of the Emergency PDP provision in the ARIN Policy Development Process to revise policy. At their meeting on 6 February 2009 the ARIN Board of Trustees, based on the recommendation of the ARIN Advisory Council and noting that the Policy Development Process had been followed, adopted Draft Policy 2008-6: Emergency Transfer Policy for IPv4 Addresses. Then at their meeting on 8 March 2009, the Board noted there is a gap in the transfer policy that limits the availability of IPv4 address space at a time when otherwise available IPv4 address space will become scarce, and declared this gap an emergency. The Board initiated the Emergency PDP of the Policy Development Process in order to revise the transfer policy (both the existing transfer policy and the policy just adopted). Per the Emergency PDP, the draft policy below is being posted to the Public Policy Mailing List for 10 business days of discussion and review by the community. The emergency discussion period ends 7 April 2009. Within 5 business days of the end of discussion the Advisory Council will, having reviewed the comments on the list, review the draft policy and make a recommendation to the Board of Trustees. The Board may adopt or reject the draft policy. If the Board adopts the policy, it will be presented at the next public policy meeting for reconsideration. We encourage you to discuss Draft Policy 2009-1 on the PPML. The discussion on the list will be used by the AC to determine the community consensus regarding adopting this as policy. Draft Policy 2009-1: Transfer Policy is available below and at: https://www.arin.net/policy/proposals/2009_1.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Policy 2008-6: Emergency Transfer Policy for IPv4 Addresses can be found at: https://www.arin.net/policy/proposals/2008_6.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy 2009-1 Transfer Policy Originator: ARIN Board of Trustees (using the Emergency PDP provision in the ARIN Policy Development Process) Date: 24 March 2009 Policy statement: Insert into the ARIN Number Resource Policy Manual as follows: Add Section 2.8: ?Organization. An Organization is one or more legal entities under common control or ownership.? Replace Section 8 as follows: 8. Transfers 8.1. Principles 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. Mergers and Acquisitions ARIN will consider requests for the transfer of number resources in the case of mergers and acquisitions 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. 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) affecting the transfer of assets, e.g., bill of sale, certificate of merger, contract, deed, or court decree. ? A detailed inventory of all assets utilized by the requesting party in maintaining and using the number resource. ? A list of the requesting party's customers using the number resource. If further justification is required, the requesting party may be asked to provide any of the following, or other supporting documentation, as applicable: ? A general listing of the assets or components acquired ? A specific description of acquisitions, including: o Type and quantity of equipment o Customer base ? A description of how number resources are being utilized ? Network engineering plans, including: o Host counts o Subnet masking o Network diagrams o Reassignments to customers 8.3 Transfers to Specified Recipients Number resources may be released, in whole or in part, to ARIN for transfer to another specified organizational recipient, by any authorized resource holder within the ARIN region. Such transferred number resources may only be received by organizations that are within the ARIN region and can demonstrate the need for such resources in the exact amount which they can justify under current ARIN policies. ##### Notes: Most of the existing Section 8 is left unchanged. List of changes: 2.8 New. 8.1 Changes from ?Transfers? to ?Principles.? 8.2 Changes from ?Transfer Requirements? to ?Mergers and Acquisitions.? 8.2 The word ?only? is removed. 8.3 Merged up into 8.2. 8.3 Edited version of the adopted 2008-6. From info at arin.net Mon Mar 30 14:02:49 2009 From: info at arin.net (Member Services) Date: Mon, 30 Mar 2009 14:02:49 -0400 Subject: [arin-ppml] Draft Policy 2009-3 (Global): Allocation of IPv4 Blocks to Regional Internet Registries In-Reply-To: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy> References: <37137.208.54.95.48.1238379940.squirrel@webmail.lacnic.net.uy> Message-ID: <49D10949.9000803@arin.net> Raul, According to the ARIN Policy Development Process the petition period for the upcoming San Antonio meeting closed on 13 March 2009. The deadline information was posted to PPML earlier this month, see the post: http://lists.arin.net/pipermail/arin-ppml/2009-March/013106.html The draft policy is under discussion, statements of support and opposition are welcome and appreciated. Both the discussion on the PPML and at the Public Policy Meeting will be used by the AC to determine the community consensus regarding adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Member Services American Registry for Internet Numbers (ARIN) raul at lacnic.net wrote: > Dear all: > > This proposal is a proposal for a global policy. It means that the same > proposal has to be approved in every region. They can be approved with > some wording differences, but the spirit of the proposal should be the > same. > > The proposal was the result of a long collaboration effort of senior staff > members and board members of all the 5 RIRs and the original text is the > one that is being considered in every region. > > As far as I know the authors of the proposal were not consulted by the > ARIN-AC and based on exchanges among the authors in the past few days, I > can say that in general the feeling is that the changes introduced by the > ARIN-AC are very signficant and so, this is a different proposal. > > My personal view is that changing the concept of a global policy proposal > in one RIR means to avoid the approval of the policy. I strongly encourage > ARIN to put the original proposal under consideration of its community as > it is being done in the other regions. The proposal can be approved or > not, That's part of the process, but it doesn't make sense to approve a > different proposal. IMHO, the AC is able to put forward the new proposal > for discussion if they consider that it is better, and in that way to > start the process of discussion of a new global policy proposal. > > I have to confess that dealing with 5 different PDPs is not so easy. I > don't know if a petition process should be started, If yes, please take > this email as the request for initiating that process. > > Since this announcement was issued last Monday in the afternoon, I am not > sure how the business days are counted, but I guess that I am still within > the valid period. > > However, I think that as a practices, global policy proposals should not > be changed by any advisory council or policy chair of one region due to > the impact that to change the proposal produce in the global process. > > > Best Regards, > > Ra?l > > > > --------------- > > > > El 23/03/2009, a las 04:05 p.m., Member Services escribi?: > > Draft Policy 2009-3 (Global) > Allocation of IPv4 Blocks to Regional Internet Registries > > The following draft policy text is being posted for feedback and > discussion on the Public Policy Mailing List (PPML). > > This draft policy was developed by the ARIN Advisory Council (AC) from > Policy Proposal 82: Allocation of IPv4 Blocks to Regional Internet > Registries. The AC has taken the proposal and developed it into a draft > policy. The AC was required to submit text to ARIN for staff and legal > assessment prior to selecting it as a draft policy. The assessment, > along with the text that was assessed, is located below the draft policy. > > On 20 March 2009 the ARIN Advisory Council (AC) selected Draft Policy > 2009-3: Allocation of IPv4 Blocks to Regional Internet Registries for > adoption discussion on the PPML and at the upcoming Public Policy Meeting. > > Draft Policy 2009-3 is below and can be found at: > https://www.arin.net/policy/proposals/2009_3.html > > We encourage you to discuss Draft Policy 2009-3 on the PPML prior to the > ARIN XXIII Public Policy Meeting. Both the discussion on the PPML and at > the Public Policy Meeting will be used by the AC to determine the > community consensus regarding adopting this as policy. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > All of the Draft Policies under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy 2009-3 (Global) > Allocation of IPv4 Blocks to Regional Internet Registries > > Date: 23 March 2009 > > Policy statement: > > This document describes the policy governing the allocation of IPv4 > address space from the IANA to the Regional Internet Registries (RIRs). > This document does not stipulate performance requirements in the > provision of services by IANA to an RIR in accordance with this policy. > Such requirements should be specified by appropriate agreements among > the RIRs and ICANN. > > This policy is to be implemented in two phases. > > A. Phase I: Recovery of IPv4 Address Space > > Upon ratification of this policy by the ICANN Board of Directors the > IANA shall establish a mechanism to receive IPv4 address space which is > returned to it by the RIRs, and hold that address space in a 'recovered > IPv4 pool'. > > Each RIR through their respective chosen policies and strategies may > recover IPv4 address space which is under their administration. At > quarterly intervals, each RIR shall return to the IANA any legacy > address space recovered, and may return to the IANA any non-legacy > address space recovered, in aggregated blocks of /24 or larger, for > inclusion in the recovered IPv4 pool. > > During Phase I, no allocations will be made from the recovered IPv4 > pool. Return of recovered address space (as described above) will > continue throughout Phase II. > > B. Phase II: Allocation of Recovered IPv4 address space by the IANA > > Upon ratification of this policy by the ICANN Board of Directors and a > declaration by the IANA that its existing free pool of unallocated IPv4 > address space is depleted; Global Addressing Policy ASO-001-2 (adopted > by ICANN Board 8 April 2005) is rescinded. IANA will then commence to > allocate the IPv4 address space from the recovered IPv4 pool. > > 1. The following definitions apply to this policy: > > a. Recovered Address Space. Recovered address space is that address > space that is returned to an RIR as a result of any activity that seeks > to reclaim unused address space or is voluntarily returned to the RIR or > is reclaimed by the RIR as a result of legal action or abuse > determination. Recovered address space does not include that address > space that is reclaimed because of non-payment of contractual fees whose > reclamation date is less than 1 year at the time of the report. > > b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4 > address space held by an RIR to include recovered address space not yet > returned less that address space that is committed in accordance with > the RIR's reservation policy and practices. > > c. Aggregated address blocks. Aggregated address blocks are contiguous > prefixes that can be aggregated on natural bit boundaries. 10.0.0.0/24 > and 10.0.1.0/24 are two contiguous prefixes that can be combined to form > an aggregated address block. 10.0.0.0/24 and 10.0.1.0/25 are two > contiguous prefixes that cannot be combined on a natural bit boundary to > form an aggregated block. > > d. Legacy address space. IPv4 address space allocated or assigned prior > to the creation of the RIR. > > 2. Allocation of IPv4 Address Space > > a. For the purposes of this policy, an 'IPv4 allocation period' is > defined as a 6-month period following 1 March or 1 September in each year. > > b. At the beginning of each IPv4 allocation period, the IANA will > determine the 'IPv4 allocation unit' for that period, as 1/10 of its > IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary. > The minimum 'IPv4 allocation unit' size will be a /24. > > c. In each allocation period, each RIR may issue one IPv4 request to the > IANA. Providing that the RIR satisfies the allocation criteria described > in paragraph B.2, the IANA will allocate a single allocation unit, > composed of the smallest possible number of blocks available in its IPv4 > address pool. > > 3. IPv4 Address Space Allocation Criteria > > A RIR is eligible to receive additional IPv4 address space from the IANA > when the total of its IPv4 address holdings is less than 50% of the > current IPv4 allocation unit, and providing that it has not already > received an IPv4 allocation from the IANA during the current IPv4 > allocation period. > > 4. Initial Allocation of IPv4 Address Space > > Each new RIR shall, at the moment of recognition, be allocated one (1) > allocation unit by the IANA. If an allocation unit is not available, > then the IANA will issue this block as soon as one is available. This > allocation will be made regardless of the newly formed RIR's projected > utilization figures and shall be independent of the IPv4 address space > that may have been transferred to the new RIR by the already existing > RIRs as part of the formal transition process. > > 5. Reporting > > a. All returned space is to be recorded in an IANA-published log of IPv4 > address space transactions, with each log entry detailing the returned > address block, the date of the return, and the returning RIR. > > b. All allocated space is also to be recorded in this IANA-published log > of IPv4 address space transactions, with each log entry detailing the > address blocks, the date of the allocation and the recipient RIR. > > c. The IANA will maintain a public registry of the current disposition > of all IPv4 address space, detailing all reservations and current > allocations and current IANA-held address space that is unallocated. > > d) The IANA may make public announcements of IPv4 address block > transactions that occur under this policy. The IANA will make > appropriate modifications to the "Internet Protocol V4 Address Space" > page of the IANA website and may make announcements to its own > appropriate announcement lists. The IANA announcements will be limited > to which address ranges, the time of allocation and to which Registry > they have been allocated. > > > > ##### > > ARIN Staff Assessment > > *Title: Allocation of IPv4 Blocks to the Regional Internet Registries* > > *Proposal Submitted: 30 Jan 2009* > > *Revision Submitted: 05 March 2009* > > *Date of Assessment: 10 March 2009* > > * * > > I. Understanding of the Policy: > > *Staff Understanding of the Proposal:* > > Staff understands that this proposal would be implemented in 2 phases. > Phase 1 would require the RIRs to return recovered IPv4 legacy address > space (via policy or procedure) to the IANA and have the option of > returning recovered non-legacy address space to the IANA. Phase 2 would > start after the depletion of the IANA free pool and would nullify the > existing IANA to RIR policy (Global Addressing Policy ASO-001-2). The > new IANA to RIR policy would allow each RIR to receive approximately > 1/10th of the recovered IPv4 pool from IANA once every 6 months as long > as it meets the qualification criteria written in paragraph B2. IANA > will be required to keep a log of all returned IPv4 address space and > all issued IPv4 address space from the recovered pool, as well as > maintain a public registry of the current disposition of all IPv4 > address space. > > II. Comments > > A. ARIN Staff Comments > > * The one policy that this impacts is NRPM 4.6 Amnesty and > Aggregation, which says ?Transactions should only be accepted > under this policy if they are in the interests of the community > (e.g. they improve aggregation or result in a net reclamation of > space).? Because the ARIN region holds the majority of the legacy > address space, and most of the address space returned under this > policy is legacy space, it would mean that there would be no ?net > return? of address space to ARIN. ARIN would essentially be > exchanging legacy address space for non-legacy address space, and > returning the legacy address space it received in the exchange to > IANA, resulting in a net loss of address space in ARIN?s available > pool. > > B. ARIN General Counsel Comments: > > The current basis of allocation of numbers was established in RFC's 2008 > and 2050 and is need based. If one region has greater needs than > another, the current policy of IANA does not require equal distribution > to all RIR's s. This proposed policy would establish a different > political and not needs based method for allocating returned space. It > would make each RIR an equal recipient of such space. But the level of > need and economic activity between each RI R is not equal. This policy > will tend to reallocate returned space away from where it is recovered, > in the ARIN region , and move more of it to AFRINIC and LACNIC than > current distribution principles. By equating the smaller economies and > related needs of certain regions to the needs of other regions, like > ARIN, that have greater day to day need, it in effect creates a new > political order of distribution thru equal shares. It is possible > sovereign governments in the regions with greater activity will not > agree to such a revised distribution model. The proposed policy > undermines the legal rationale for distribution. > > The policy also creates a powerful disincentive for any RIR, including > ARIN, to undertake any financial expenditure of RIR dollars for programs > intended to obtain returned space for reallocation. Currently ARIN is > working towards policies such as the LRSA and 2008-6, intended to > encourage returns and use of under utilized resources, but which cost > ARIN expenditures other RIRs are not duplicating. Any policy which > creates such a disincentive by leaving expenditures with a single RIR, > who cannot benefit except to receive 20% of the returned space should be > carefully considered. > > Finally, it is likely entities with number resources in the ARIN region > may be willing to return those resources for uses in the region but > unwilling to do so if 4/5 of such resources will be sent to other regions. > > III. Resource Impact > > The resource impact of implementing this policy is viewed as minimal. It > is estimated that this policy could require up to 3 person months of > effort to implement following ratification by the ARIN Board of > Trustees. Because this implementation is not planned, it may preempt > ARIN?s current project deployment schedule. It may require the following: > > * Modifications to existing registration procedures to include the > handling of returned/reclaimed address space and the process of > requesting additional address space from the IANA. > * Staff training > > Text assessed: > > *Allocation of IPv4 Blocks to Regional Internet Registries (Global)* > > *Policy statement:* > > This document describes the policy governing the allocation of IPv4 > address space from the IANA to the Regional Internet Registries (RIRs). > This document does not stipulate performance requirements in the > provision of services by IANA to an RIR in accordance with this policy. > Such requirements should be specified by appropriate agreements among > the RIRs and ICANN. > > This policy is to be implemented in two phases. > > A. Phase I: Recovery of IPv4 Address Space > > Upon ratification of this policy by the ICANN Board of Directors the > IANA shall establish a mechanism to receive IPv4 address space which is > returned to it by the RIRs, and hold that address space in a 'recovered > IPv4 pool'. > > Each RIR through their respective chosen policies and strategies may > recover IPv4 address space which is under their administration. At > quarterly intervals, each RIR shall return any legacy address space > recovered, and may return any non-legacy address space recovered, to the > IANA in aggregated blocks of /24 or larger, for inclusion in the > recovered IPv4 pool. > > During Phase I, no allocations will be made from the recovered IPv4 > pool. Return of recovered address space (as described above) will > continue throughout Phase II. > > B. Phase II: Allocation of Recovered IPv4 address space by the IANA > > Upon ratification of this policy by the ICANN Board of Directors and a > declaration by the IANA that its existing free pool of unallocated IPv4 > address space is depleted; Global Addressing Policy ASO-001-2 (adopted > by ICANN Board 8 April 2005) is rescinded. IANA will then commence to > allocate the IPv4 address space from the recovered IPv4 pool. > > 1. The following definitions apply to this policy: > > a. Recovered Address Space. Recovered address space is that address > space that is returned to an RIR as a result of any activity that seeks > to reclaim unused address space or is voluntarily returned to the RIR or > is reclaimed by the RIR as a result of legal action or abuse > determination. Recovered address space does not include that address > space that is reclaimed because of non-payment of contractual fees whose > reclamation date is less than 1 year at the time of the report. > > b. IPv4 Address Holdings. IPv4 address holdings are all unallocated IPv4 > address space held by an RIR to include recovered address space not yet > returned less that address space that is committed in accordance with > the RIR's reservation policy and practices. > > c. Legacy address space. IPv4 address space allocated or assigned prior > to the creation of the RIR. > > 2. Allocation of IPv4 Address Space > > a. For the purposes of this policy, an 'IPv4 allocation period' is > defined as a 6-month period following 1 March or 1 September in each year. > > b. At the beginning of each IPv4 allocation period, the IANA will > determine the 'IPv4 allocation unit' for that period, as 1/10 of its > IPv4 address pool, rounded down to the next CIDR (power-of-2) boundary. > > c. In each allocation period, each RIR may issue one IPv4 request to the > IANA. Providing that the RIR satisfies the allocation criteria described > in paragraph B.2, the IANA will allocate a single allocation unit, > composed of the smallest possible number of blocks available in its IPv4 > address pool. > > 3. IPv4 Address Space Allocation Criteria > > A RIR is eligible to receive additional IPv4 address space from the IANA > when the total of its IPv4 address holdings is less than 50% of the > current IPv4 allocation unit, and providing that it has not already > received an IPv4 allocation from the IANA during the current IPv4 > allocation period. > > 4. Initial Allocation of IPv4 Address Space > > Each new RIR shall, at the moment of recognition, be allocated one (1) > allocation unit by the IANA. If an allocation unit is not available, > then the IANA will issue this block as soon as one is available. This > allocation will be made regardless of the newly formed RIR's projected > utilization figures and shall be independent of the IPv4 address space > that may have been transferred to the new RIR by the already existing > RIRs as part of the formal transition process. > > 5. Reporting > > a. All returned space is to be recorded in an IANA-published log of IPv4 > address space transactions, with each log entry detailing the returned > address block, the date of the return, and the returning RIR. > > b. All allocated space is also to be recorded in this IANA-published log > of IPv4 address space transactions, with each log entry detailing the > address blocks, the date of the allocation and the recipient RIR. > > c. The IANA will maintain a public registry of the current disposition > of all IPv4 address space, detailing all reservations and current > allocations and current IANA-held address space that is unallocated. > > d) The IANA may make public announcements of IPv4 address block > transactions that occur under this policy. The IANA will make > appropriate modifications to the "Internet Protocol V4 Address Space" > page of the IANA website and may make announcements to its own > appropriate announcement lists. The IANA announcements will be limited > to which address ranges, the time of allocation and to which Registry > they have been allocated. > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > >