From info at arin.net Wed Aug 1 11:03:24 2007 From: info at arin.net (Member Services) Date: Wed, 01 Aug 2007 11:03:24 -0400 Subject: Policy Proposal: PIv6 for legacy holders with RSA and efficient use In-Reply-To: <46AE1EA9.3010509@arin.net> References: <46AE1EA9.3010509@arin.net> Message-ID: <46B0A0BC.6010508@arin.net> > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. The shepherds from the ARIN Advisory Council for this proposal are Suzanne Woolf and Ron da Silva. Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as a formal policy proposal as written. If the > AC accepts the proposal, it will be posted as a formal policy proposal > to PPML and it will be presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The AC > will work with the author to clarify, combine or divide the proposal. At > their following meeting the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision. If a proposal is not accepted, then > the author may elect to use the petition process to advance their > proposal. If the author elects not to petition or the petition fails, > then the proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: PIv6 for legacy holders with RSA and efficient use > > Author: Scott Leibrand > > Proposal Version: 1.0 > > Submission Date: 7/28/2007 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Modify NRPM section 6.5.8.1 (Direct assignments from ARIN to end-user > organizations: Criteria), to read: > > To qualify for a direct assignment, an organization must: > > 1. not be an IPv6 LIR; and > 2. qualify for an IPv4 assignment or allocation from ARIN under the > IPv4 policy currently in effect, or demonstrate efficient > utilization of a direct IPv4 assignment or allocation covered by a > current ARIN RSA. > > Rationale: > > Current policy allows direct IPv6 allocations and assignments to nearly > all organizations with IPv4 allocations or assignments from ARIN. As a > result, such organizations can get IPv6 space just as easily as they can > get IPv4 space, making it easy for them to transition to IPv6 as soon as > they're ready to do so. However, there are some organizations who > received IPv4 /23's and /24's prior to the formation of ARIN, and use > that space in a multihomed, provider-independent fashion. Under current > policy, such organizations cannot get IPv6 PI space without artificially > inflating host counts, and are therefore discouraged from adopting IPv6. > This policy proposal aims to remove this disincentive, and allow such > organizations to easily adopt IPv6. > > In addition, pre-ARIN assignments were issued through an informal > process, and many legacy resource holders have not yet entered into a > formal agreement with ARIN, the manager of many such IP numbering > resources. This policy proposal would require that such assignments be > brought under a current ARIN Registration Services Agreement, thereby > formalizing the relationship. > > Some pre-ARIN assignments may not be used efficiently. As unallocated > IPv4 numbering resources are approaching exhaustion, it is important to > ensure efficient utilization of IPv4 assignments, and to arrange for > reclamation of unused space. Therefore, this policy would require that > the organization wishing to receive IPv6 PI space demonstrate efficient > utilization of their IPv4 assignment. (Efficient utilization is already > defined elsewhere in policy, and the exact mechanism for achieving and > determining efficient use is a matter of procedure, not of policy, so > detailed procedures are not included in the policy statement above. The > intent is that any organization with an assignment of /23 or larger > which is less than 50% utilized would renumber and return whole unused > CIDR blocks as necessary to bring the remaining CIDR block to 50% > utilization or higher. A /24 should be considered efficiently utilized > as long as it is in use for multihoming, as /25's and smaller are not > routable for that purpose.) > > It has been suggested that this policy would be useful only until the > growth of IPv6 exceeds the growth of IPv4. I would agree with this, > and would further posit that the existing "qualify ... under the IPv4 > policy currently in effect" language should also be modified at that > time. I have therefore proposed this policy with a policy term of > "permanent", with the expectation that this section of policy (6.5.8.1) > will be rewritten at the appropriate time to entirely remove all IPv4 > dependencies. > > Timetable for implementation: immediate > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From info at arin.net Wed Aug 1 17:31:03 2007 From: info at arin.net (Member Services) Date: Wed, 1 Aug 2007 17:31:03 -0400 Subject: ARIN Board Statement on the Future of Addressing Policy Message-ID: <002a01c7d483$432067f0$528888c0@arin.net> The American Registry for Internet Numbers Board of Trustees released a statement today that assures ARIN will continue to facilitate the policy development process that defines how Internet Protocol (IP) addresses are distributed in its region, and also reaffirms that ARIN's policies do not encourage profit-driven speculation in IP addresses. The complete statement is included below and is also online at http://www.arin.net/media/200701August_Statement.pdf. On 1 August 2007, the ARIN Board of Trustees issued the following statement: Statement of ARIN's Board of Trustees regarding future Internet address policy in the ARIN region The global Internet requires numeric addresses for the routing of communications traffic. These addresses are necessarily finite in nature and have been defined in two groups. One group, called "Internet Protocol version 4," or IPv4, was defined in 1979 as a pool of approximately 4,300,000,000 addresses.(1)(2) In anticipation of the Internet growing larger than can be accommodated by the IPv4 pool, a second group, called "Internet Protocol version 6," or IPv6, was defined in 1995 as a pool of approximately 340,000,000,000,000,000,000,000,000,000,000,000,000 addresses, an address space billions upon billions of times larger.(3) In accordance with Internet governance principles, IP addresses of both versions are allocated to users by the Regional Internet Registries.(4) Because IP addresses are a finite resource, the allocation process is defined and overseen democratically and transparently by the public. The allocation process seeks to balance two goals: universal access to the Internet, and the stability of the Internet's essential communications function.(5) Because the growth of the Internet is leading to full use of the IPv4 address pool, soon the Regional Internet Registries will no longer have new, previously unassigned IPv4 addresses to allocate to users.(6) Forward-thinking users have already begun the transition to the much more plentiful IPv6 addresses in anticipation of this situation. There are, however, those who propose that the democratically established governance principles now be abandoned, to create a market in IP addresses. A market that abandons these existing, consensus-driven core values would encourage speculators to take advantage of the upcoming time of relative scarcity of IPv4 addresses to profit from less foresightful users' remaining need. The purpose of this memorandum is to assure the community that the democratic principles of Internet governance will be adhered to by ARIN, the Regional Internet Registry serving Canada, many Caribbean and North Atlantic islands, and the United States.(7) The resource-allocation policy under which ARIN operates has been produced through an open, transparent, and democratic process over more than a decade. ARIN is fully dedicated to preserving universal access and stable functionality of the Internet, and our policies do not encourage profit-driven speculation in the Internet addresses. The current resource management mechanism is fully sufficient to address the upcoming shortage of IPv4 addresses, and a continuation of sober and responsible enforcement will ensure continued maximum benefit to and protection of the entire Internet community. ---- (1) Internet Engineering Note 111, Internet Protocol, August 1979, by the University of Southern California Information Sciences Institute. http://www.networksorcery.com/enp/ien/ien111.txt (2) Internet Engineering Task Force Request for Comment number 760, DOD Standard Internet Protocol, January 1980, by the University of Southern California Information Sciences Institute. http://www.ietf.org/rfc/rfc0760.txt (3) Internet Engineering Task Force Request for Comment number 1883, Internet Protocol Version 6 (IPv6) Specification, December 1995, by Steve Deering and Robert Hinden. http://www.ietf.org/rfc/rfc1883.txt (4) Internet Engineering Task Force Request for Comment number 2050, Internet Registry IP Allocation Guidelines, November 1996, by Kim Hubbard, Mark Kosters, David Conrad, Daniel Karrenberg, and Jon Postel. http://www.ietf.org/rfc/rfc2050.txt (5) Internet Engineering Task Force Request for Comment number 2008, Implications of Various Address Allocation Policies for Internet Routing, October 1996, by Yakov Rekhter and Tony Li. http://www.ietf.org/rfc/rfc2008.txt (6) IPv4 Address Report, updated daily, by Geoff Huston. http://www.potaroo.net/tools/ipv4/index.html (7) The countries and territories of ARIN's service region are named at http://www.arin.net/community/ARINcountries.html Regards, Raymond A. Plzak President and CEO American Registry for Internet Numbers (ARIN) From info at arin.net Thu Aug 2 14:01:30 2007 From: info at arin.net (Member Services) Date: Thu, 02 Aug 2007 14:01:30 -0400 Subject: Policy Proposal: Definition of known ISP and changes to IPv6 initial allocation criteria In-Reply-To: <46AE170F.6010901@arin.net> References: <46AE170F.6010901@arin.net> Message-ID: <46B21BFA.2050009@arin.net> > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. The shepherds from the ARIN Advisory Council for this proposal are Paul Andersen and Alec Peterson. Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as a formal policy proposal as written. If the > AC accepts the proposal, it will be posted as a formal policy proposal > to PPML and it will be presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The AC > will work with the author to clarify, combine or divide the proposal. At > their following meeting the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision. If a proposal is not accepted, then > the author may elect to use the petition process to advance their > proposal. If the author elects not to petition or the petition fails, > then the proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Definition of known ISP and changes to IPv6 > initial allocation criteria > > Author: Kevin Loch > > Proposal Version: 1 > > Submission Date: 2007-07-27 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Add the following section 6.2.10: > > 6.2.10 Existing ISP > > An existing ISP is an organization which meets the following > criteria: > > 1. Has IPv4 or IPv6 address space directly allocated > by ARIN; or > 2. Has at least a total of an IPv4 /23 or an IPv6 /44 of address > space reallocated to them via SWIP by one or more upstream > ISPs. > > Address space directly assigned from ARIN or reassigned from > upstream ISPs does not count towards these requirements. > > Replace 6.5.1.1 (d) with the following text: > > d. be an existing ISP in the ARIN region or have a plan for > making assignments to at least 200 separate organizations > within five years. > > Rationale: > > This policy proposal would change two things in the IPv6 > Initial allocation criteria. It adds a definition for > "known ISP" and changes "200 /48 assignments" to > 200 assignments of any size, but to separate organizations. > > Existing ISP: > > The term "existing, known ISP" in the IPv6 ISP qualification > section is too vague and does not give ARIN staff sufficient > guidance for evaluating qualifications. This text defines > "existing, ISP" in a precise manner and removes the unnecessary > and ambiguous word "known". > > It has come to the author's attention that several organizations > have been refused IPv6 ISP allocations because they were not > considered an existing, known ISP. At least one of these > organizations has a /18 worth of IPv4 space reallocated to them > by various upstream ISPs and over 200 IPv4 customers. An > organization's choice to use provider addresses does not > have any affect on whether or not they are in fact an ISP. > > Address space that has been reallocated (not reassigned) > is a good indicato of an ISP as those SWIP templates > are only supposed to be used for downstream ISPs. > > The IPv4 /23 value was selected to match the utilization > requirement for the smallest direct IPv4 allocation from ARIN > under current policy. > > The IPv6 /44 value was selected to represent a number > of downstream customers comparable to the IPv4 requirements. > > > Updates to IPv6 initial allocation criteria: > > Section 6.5.4.1 recommends /56 assignments in some cases and > /48 assignments in others. The Initial allocation criteria > should reflect the flexibility of these recommendations. > An ISP should not have to provide an inefficient address > plan on their application even though they expect to have > over 200 IPv6 customers. > > Timetable for implementation: Immediate > > > > > _______________________________________________ > This message sent to you through the ARIN Public Policy Mailing List > (PPML at arin.net). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > From info at arin.net Mon Aug 6 10:52:25 2007 From: info at arin.net (Member Services) Date: Mon, 06 Aug 2007 10:52:25 -0400 Subject: Outcome of Community Consultation: ARIN WHOIS Directory Services Message-ID: <46B735A9.9070801@arin.net> The result of Suggestion 2007.15, sent through the ARIN Consultation and Suggestion Process and asking for ARIN WHOIS to accept CIDR style queries, was an ARIN community consultation on enhancements to this directory service. The archive of the consultation mailing list discussion is available at: http://www.arin.net/acsp/community_consult/23-07-2007_WhoisDirectoryService.html We thank those who provided valuable feedback during this consultation. This feedback will be used to develop the WHOIS improvement project. We anticipate beginning work on this project in the 1st quarter of 2008. Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Tue Aug 14 08:46:49 2007 From: info at arin.net (Member Services) Date: Tue, 14 Aug 2007 08:46:49 -0400 Subject: Deadline for Policy Proposals - 18 August 2007 Message-ID: <46C1A439.3020407@arin.net> The ARIN XX Public Policy Meeting will take place 17-18 October 2007 in Albuquerque, NM. New policy proposals must be submitted by 23:59 EDT, 18 August 2007, in order to be considered by the ARIN Advisory Council for possible inclusion on the ARIN XX agenda. This is in accordance with ARIN's Internet Resource Policy Evaluation Process, which requires that proposed policies be submitted at least 60 days prior to the meeting. Those who wish to propose new ARIN number resource policies or modifications to existing policies must submit a Policy Proposal Template. The template must be sent via e-mail to policy at arin.net. The Policy Proposal Template can be found at: http://www.arin.net/policy/irpep_template.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Tue Aug 14 17:08:35 2007 From: info at arin.net (Member Services) Date: Tue, 14 Aug 2007 17:08:35 -0400 Subject: Policy Proposal: Expand timeframe of Additional Requests Message-ID: <46C219D3.4080608@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as a formal policy proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Expand timeframe of Additional Requests Author: Dan Alexander Proposal Version: Version 1.0 Submission Date: 8/14/2007 Proposal type: modify Policy term: permanent Policy statement: The proposal is to modify section 4.2.4.4 of the NRPM Current wording: "After a subscriber has been a member of ARIN for one year they may choose to request a six-month supply of IP addresses." Change to: "After an organization has been an ARIN member in good standing for one year, they may choose to request up to a 12 month supply of IP addresses." Rationale: Currently, all RIR's provide organizations with at least a 12 month supply of IPv4 address space when making subsequent requests, with the exception of the ARIN region. The primary reason for this change is for continuity among all RIR. In doing so, all established organizations have a more consistent access to IP resources. The adjustment does not change demand on IPv4 address space. It only changes the frequency in which established organizations need to request address space. This would allow for fewer potential aggregates allocated to an organization providing more consolidated routing announcements. This does not change the requirement on new organizations where established growth trends have yet to be established. Timetable for implementation: Immediate From info at arin.net Tue Aug 14 18:00:34 2007 From: info at arin.net (Member Services) Date: Tue, 14 Aug 2007 18:00:34 -0400 Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0) Message-ID: <46C22602.7080600@arin.net> This proposal is in the Initial Review stage of the ARIN Internet Resource Policy Evaluation Process. On 17 May 2007 the ARIN Advisory Council (AC) reviewed 'IPv4 Soft Landing (version 1.0)' and decided to postpone their decision regarding the proposal in order to work with the author. The author submitted the following revised version of the proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as a formal policy proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC shepherd for this proposal is Bill Darte. The AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv4 Soft Landing Author: David Conrad Proposal Version: 2.0 Submission Date: 2007-08-14 Proposal type: New Policy term: Permanent Policy statement: This policy is intended to replace section 4.2.4.1 of the ARIN Number Resource Policy Manual with wording substantially along the lines of: --- begin modification --- 4.2.4.1 In order to encourage a smooth transition to IPv6, ARIN has instituted a set of IPv4 Address Allocation "phases" that vary the requirements for address allocation using the amount of address space remaining unallocated by IANA as a metric. As the amount of address space in the IANA free pool is reduced, the requirements for IPv4 address allocation are made more stringent. When requesting additional IPv4 address space, ISPs must meet the requirements of the IPv4 Address Allocation phase ARIN was in when the request was submitted. These phases will require the requester to demonstrate increasingly efficient utilization of previously allocated IPv4 address space, including all space reassigned to their customers. In addition, depending on the IPv4 Address Allocation phase ARIN was in when the request was submitted, there may be additional requirements that will need to be met by the requester such as completing a survey on IPv6 deployment plans, documentation of non-private address space used for internal infrastructure, documentation of IPv6 plans for offering connectivity and services, etc. The reassignment information section of the ARIN ISP Network Request Template should be completed for all address blocks that have been allocated to your organization. In the template, line 1b. Assigned: information will be verified via SWIP/RWHOIS and 1c. Reserved: should be used to indicate internal network information. Please note that until all requirements are met and your prior utilization is verified to meet the requirements specified in the IPv4 Address Allocation phase in which the request was received, ARIN can neither process nor approve a request for additional addresses. IPv4 Allocation Phases The thresholds and the requirements to justify an allocation of new IPv4 address space from ARIN are defined in this section. Phase: 0 Threshold: Greater than 40 /8s Requirements: Requesters must: * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 25% utilization - Demonstrate a one year requirement of 50% utilization Phase: 1 Threshold: 40 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 25% utilization - Demonstrate a one year requirement of 50% utilization * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used. Phase: 2 Threshold: 25 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 85% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 50% utilization - Demonstrate a one year requirement of 75% utilization * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used. * Provide plans for migrating all non-RFC 1918 address space used for internal infrastructure either to IPv6 (preferred) or to private addressing where possible. Where such migration is not possible, provide documentation listing the use of addresses that are not migratable and the reasons for the inability to migrate. * Demonstrate documented plans for availability of production IPv6 infrastructure and connectivity services within 6 months of submitting the request. Phase: 3 Threshold: 10 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 90% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 75% utilization - Demonstrate a one year requirement of 90% utilization * Provide documentation demonstrating migration (where possible) of non-RFC 1918 address space used for internal infrastructure to either IPv6 (preferred) or private addressing. * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure, how it is used, and why it is not possible to migrate those addresses to either IPv6 (preferred) or private addressing. * Demonstrate availability of production IPv6 infrastructure and connectivity services. Notes: * Phase 0 reflects current allocation requirements. * Phases 1 through 3 are to be implemented 30 days after IANA allocates address space from the IPv4 free pool that reduces that free pool to a number of /8s that are at or below the threshold specified. * If multiple thresholds should be crossed within a 30 day period, the requirements from the last threshold crossed will be applied to requesters for additional address space at the time of the request. --- end modification --- Rationale: The rationale for this proposal is threefold: * to prolong the availability of IPv4 addresses for requesters who can provide sufficient justification; * to encourage the deployment of IPv6 as an alternative to IPv4 by making the requirements to justify IPv4 allocations increasingly stringent over time; * to promote the more efficient use of increasingly scarce IPv4 resources. As the lack of significant deployment of IPv6 can attest, the cost of deploying IPv6 currently outweighs the benefits that protocol would appear to provide. This proposal aims to encourage the deployment of IPv6 by over time, making the allocation of IPv4 both more difficult and contingent on the requester demonstrating both support for IPv6 as well as requiring a demonstration that the IPv4 address space they administer is being used efficiently. The goal of these measures is to rebalance the IPv6 deployment cost/benefit ratio thereby encouraging greater uptake of IPv6 before the IPv4 free pool is exhausted. The "IPv4 Soft Landing" policy aims to provide for a smoother transition away from IPv4 towards IPv6 by imposing increasingly strict requirements for new address allocations as the amount of address space available in the IANA unallocated IPv4 address pool decreases. These increased requirements include both more stringent reassignment and utilization percentages as well as requiring documented IPv6 infrastructure services and connectivity provision and the documentation or reuse of public IPv4 address space used for internal infrastructure. The increased stringency in the allocation requirements is intended both to increase the efficiency of utilization of the IPv4 address space and to reduce the likelihood of a "run" on the remaining free pool of IPv4 address space. ARIN staff would be expected to use the same mechanisms in use today to verify conformance to the specified requirements. The requirements for demonstration of IPv6 infrastructure services and connectivity are intended to motivate ISPs to provide those services before the only address space they can offer their customers is IPv6, thereby offering an opportunity to break the "chicken-and-egg" problem limiting significant IPv6 deployment. Verification of these requirements can be done by ARIN staff by using IPv6 transport to connect to published services of the ISP (e.g., DNS servers, WWW URLs, etc.) as well as using IPv6 ping to identified addresses internal to the ISP. Obviously, false positive responses for most any objective mechanism for verifying the availability can be engineered, so ARIN staff may also consider subjective reports of an inability to obtain IPv6 services by customers as an indicator of (lack of) conformance to this requirement. The requirements to migrate internal infrastructure to either IPv6 or private (e.g., RFC 1918) addressing are intended to improve the efficiency of utilization of IPv4 address space, reserving the scarce IPv4 resources for purposes for which IPv6 or private addresses are not suitable. These requirements acknowledge that pragmatically, the use of IPv4 is absolutely essential only for servers in client-server architectures, machines engaged in peer-to-peer applications, and entry points for NAT/ALG devices. As such, use of IPv4 for purposes such as router interface numbering, client-only devices, and devices which should not be available from external networks should be discouraged. Since there can be circumstances in which migration of internal infrastructure addresses to private addressing would not be feasible, this policy allows for requesters to document those situations in which it is not possible to do the migration. The time for transition between phases of this policy are not fixed, rather they depend on the rate of consumption of IPv4 address space from the IANA free pool. Current RIR operational procedure is to request 2 /8s from the IANA when the RIR's current pool of free IPv4 address space is depleted. This procedure should ensure transitions between phases will have some lead-time, so organizations can prepare for the next phase of IPv4 address allocation. Given the highly volatile nature of IPv4 consumption and the inability to define a predictive model rooted in an underlying theory rather than extrapolating over existing data, the thresholds chosen are acknowledged to be somewhat arbitrary. The intent of the chosen values is to provide a "reasonable" amount of time, approximately 18 months, between transitions at current consumption rates (approximately 10 /8s per year). However, it should be explicitly noted that one of the intents of this policy is to extend the IPv4 free pool lifetime, thus as the policy becomes effective, the amount of time between phase transitions would presumably increase. Timetable for implementation: Immediately upon approval of this policy by the ARIN Board of Trustees. From info at arin.net Fri Aug 17 11:19:43 2007 From: info at arin.net (Member Services) Date: Fri, 17 Aug 2007 11:19:43 -0400 Subject: Policy Proposal: End Policy for IANA IPv4 allocations to RIRs Message-ID: <46C5BC8F.7090302@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as a formal policy proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: End Policy for IANA IPv4 allocations to RIRs Author: JPNIC IPv4 countdown policy team; Akinori MAEMURA Akira NAKAGAWA Izumi OKUTANI Kosuke ITO Kuniaki KONDO Shuji NAKAMURA Susumu SATO Takashi ARANO Tomohiro FUJISAKI Tomoya YOSHIDA Toshiyuki HOSAKA Proposal Version: 2 Submission Date: 2007/08/17 Proposal type: new Policy term:renewable Policy statement: 1) Distribute a single /8 to each RIR at the point when new IANA free pool hits 5 */8. This date is defined as "IANA Exhaustion Date". 2) It should be completely left up to each RIR communities to define a regional policy on how to distribute the remaining RIR free pool to LIRs within their respective regions after "IANA Exhaustion Date". Note 1: It is fine for an RIR to continue operations with the existing policy if that is the consensus decision of the respective RIR community. Note 2: Address recovery and re-distribution of recovered address space is another important measure for considerations, but should be treated as a separate policy proposal from distribution of new IANA pool. 3) RIRs should provide an official projection on IANA Exhaustion Date to the community through their website, at their Policy Meetings and through any other effective means. Rationale: [current problem] There are two major issues in terms of address management if no measures are taken for IPv4 address exhaustion. 1) Continue applying a global coordinated policy for distribution of the last piece(s) of RIR's unallocated address block does not match the reality of the situation in each RIR region. Issues each RIR region will face during the exhaustion period vary by region as the level of development of IPv4 and IPv6 are widely different. As a result, applying a global co-ordinated policy may not adequately address issues in a certain region while it could be work for the others. For example, in a region where late comers desperately need even small blocks of IPv4 addresses to access to the IPv4 Internet, a policy that defines the target of allocations/assignments of IPv4 address space to be late comers would be appropriate in such region. This would allow availablilty of IPv4 address space for such requirements for more years. Another example comes from difference in IPv6 deployment rate. For a region where IPv6 deployment rate is low, measures may be necessary to prolong IPv4 address life for the existing business as well as for new businesses until networks are IPv6 ready. Some regions may have strong needs to secure IPv4 address space for translators. A globally coordinated policy which addresses all the issues listed above to meet the needs for all RIR regions may result in not solving issues in any of the regions. 2) LIRs and stakeholders remain unprepared for the situation if they are not informed If LIRs and the community are uninformed of the exhaustion, their services and networks remain unprepared to face the situation at the time of exhaustion. [Objective of the proposal] This proposal seeks to provide the following solutions to the problems listed above. 1) RIR community should be able to define their own regional policies on how to assign the last piece(s) of allocation block in order to address their own regional issues during the exhaustion period. 2) RIRs should provide official projection of the date when LIRs will be able to receive the allocations under the current criteria. The criteria should remain consistent until this date in order to avoid confusion. [Pros and Cons] Pros: + It allows each RIR community to define a policy on how to distribute the last piece(s) of allocations which best matches their situation. + It helps LIR better informed of the date when they are able to receive allocations from RIRs under the current criteria and prepare for the event. Cons: + Concerns could be raised about allocating a fixed size to all RIRs, that it artificially fastens the consumption rate of some RIR regions. However, its impact is kept to minimum by keeping the allocation size to a single /8 which makes merely 3-4 months difference. + Concerns could be raised that explicitly allowing regional policies will encourage RIR shopping. However, this should not happen if the requirements within each region is adequately reflected in each RIR's policy through PDP. RIR may also chose to add criteria to prevent LIRs from other regions submitting such requests. Timetable for implementation: Immediate after all 5 RIRs (and possibly ICANN) ratifies the policy. From info at arin.net Fri Aug 17 14:21:35 2007 From: info at arin.net (Member Services) Date: Fri, 17 Aug 2007 14:21:35 -0400 Subject: Policy Proposal: IPv6 Assignment Guidelines Message-ID: <46C5E72F.2080903@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as a formal policy proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv6 Assignment Guidelines Author: Leo Bicknell Proposal Version: 1.0 Submission Date: 8/17/2007 Proposal type: new Policy term: permanent Policy statement: Replace the text in section 6.5.4.1 with the following text: LIR's may assign blocks in the range of /48 to /64 to end sites. All assignments made by LIR's should meet a minimum HD-Ratio of .25. * /64 - Site needing only a single subnet. * /60 - Site with 2-3 subnets initially. * /56 - Site with 4-7 subnets initially. * /52 - Site with 8-15 subnets initially. * /48 - Site with 16+ subnets initially. For end sites to whom reverse DNS will be delegated, the LIR/ISP should consider making an assignment on a nibble (4-bit) boundary to simplify reverse lookup delegation. LIR's do not need to issue all 5 sizes of prefixes as long as the HD-Ratio requirement is met. Rationale: The existing section 6.5.4.1 does not provide clear guidance on how large of a prefix to allocate to a site. This makes it difficult for LIR's to know they are in compliance with the rules, and makes it harder for ARIN staff to evaluate requests per the communities wishes. This policy is based on an HD Ratio of .25 for end sites. The following table may be useful: Prefix Size Number of Subnets Required in Use to Meet .25 ----------- ----------------- --------------------------- /64 1 1 /60 16 2 /56 256 4 /52 4096 8 /48 65536 16 It is believed this policy provides clear guidance while allowing LIR's to make generous allocations to their end-sites. Timetable for implementation: immediate for new requests, 2 year grace period for all existing assignments. From info at arin.net Fri Aug 17 14:21:57 2007 From: info at arin.net (Member Services) Date: Fri, 17 Aug 2007 14:21:57 -0400 Subject: Policy Proposal: ISP to LIR Clarification Message-ID: <46C5E745.5050708@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as a formal policy proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: ISP to LIR Clarification Author: Leo Bicknell Proposal Version: 1.0 Submission Date: 8/17/2007 Proposal type: modify Policy term: permanent Policy statement: Replace all instances of the word "ISP" in the NRPM with the word "LIR" and replace all instances of the phrase "LIR/ISP" with "LIR", except for the following: * Leave section 2.4 unchanged. * Leave section 2.7 unchanged. * In section 4.1.1, replace "ISPs" with "requesters". * In section 4.2, also remove "Internet Service Providers". * Leave section 6.2.4 unchanged. * Leave section 6.3.4 unchanged. * In section 6.9, replace "ISPs and LIRs" with "LIRs" for all three occurrence. Rationale: The NRPM is inconsistent. The terms ISP and LIR are used interchangeably throughout the document, with the term ISP being predominant in the IPv4 sections and the term LIR being predominant in the IPv6 sections. The use of the term ISP poses two different problems: 1) The term has meaning outside of ARIN's policy. Multiple discussions on PPML have degenerated over people arguing what an ISP is with regards to policy when the reality is that the relationship is defined in the NRPM. As LIR has no meaning outside of policy this confusion will be removed. 2) The other four RIRs have standardized on LIR. This change will make it easier for those doing business with more than one LIR to use consistent terms. This change does not alter any policy, it merely makes the policy easier to understand. Timetable for implementation: immediate From info at arin.net Fri Aug 17 14:22:31 2007 From: info at arin.net (Member Services) Date: Fri, 17 Aug 2007 14:22:31 -0400 Subject: Policy Proposal: IPv6 Policy Housekeeping Message-ID: <46C5E767.6010406@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as a formal policy proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv6 Policy Housekeeping Author: Leo Bicknell Proposal Version: 1.0 Submission Date: 8/17/2007 Proposal type: modify Policy term: permanent Policy statement: Change A: Remove the text between the section 6 header and the section 6.1 header. Remove section 6.1 entirely. Update all subsequent sections to have new section numbers (6.[n-1]). Change B: Move the image in section 6.2 to section 2. Remove sections 6.2.1 to 6.2.6. Change C: Move section 6.2.7 to (new) section 2.8, subheading "IPv6". Create section 2.8, subheading "IPv4", containing the following text: In IPv4, utilization is the percentage of the address space allocated or assigned relative to the total address space. Change D: Move section 6.2.8 to (new) section 2.8. Move section 6.2.9 to (new) section 2.9. As this leaves section 6.2 empty, remove section 6.2. Update all subsequent sections to have new section numbers (6.[n-1]). Change E: Remove section 6.3. Update all subsequent sections to have new section numbers (6.[n-1]). Change F: Remove section 6.4.1. Update all subsequent sections to have new section numbers (6.4.[n-1]). Change G: Remove section 6.4.2. Update all subsequent sections to have new section numbers (6.4.[n-1]). Change H: Remove section 6.4.4. Change I: In section 6.5.1.1.d, replace the existing statement with the new statement: "be an existing, known ISP in the ARIN region or have a plan for making at least 200 end-site assignments to other organizations within 5 years." Change J: Remove section 6.5.3 entirely. Update all subsequent sections to have new section numbers (6.5.[n-1]). Replace part of the text as (new) section 6.5.4.4: "All /56 and larger assignments to end sites are required to be registered either by the LIR or its subordinate ISPs in such a way that the RIR/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary." Change K: Section 6.5.8.2, add the following sentence to the end of the first paragraph: "An HD-Ratio of .94 must be met for all assignments larger than a /48." Add to the end of the second paragraph: "This reservation may be assigned to other organizations later, at ARIN's discretion." Change L: Section 6.5.8.3, add a sentence between the two existing sentences: "Justification will be determined based on the .94 HD-Ratio metric." Change M: Remove section 6.6. Update all subsequent sections to have new section numbers (6.[n-1]). Change N: Change the title of section 6.7 from "Appendix A: HD-Ratio" to "HD-Ratio". Change O: Remove section 6.8. Update all subsequent sections to have new section numbers (6.[n-1]). Rationale: When the IPv6 policy was passed, it was considered to be an "interim" policy, and it was intended to be similar in all 5 RIR's. Since that time it has become clear the policy is no longer interim (and proposal 2007-4 was passed to change just that) and it has also been modified separately in the different RIR's. It was brought to the ARIN AC's attention that there were a number of problems with "Section 6" of the NRPM as a result of this legacy: * The policy contained a large number of items that were not policy. * The policy contained a few items that were self contradictory. * The added text was redundant in some cases with existing text. * The policy was overly vague in a few areas, leaving ARIN staff to have to make interpretations of what the policy intended. * Policy changes made since the initial IPv6 policy was adopted have not always updated all of the relevant sections due to the complexity of section 6. The intent of these changes is not to change any existing policy, but rather to remove all non-policy items, and update any ambiguous items with the way that ARIN staff is currently interprets the policy. Change A: Not policy. Unnecessary. Confusing (policy is interim). Change B: Sections 6.2.1 to 6.2.6 are definitions that are already defined in section 2.1 to 2.7 Repeating them here is unnecessary. The picture is useful though, and should be moved to section 2 as part of the definitions. Change C: This is a definition item, and should be in the definition section. Also, the v4 versions should be defined at the same time. Change D: These are both definitions that should be in the definitions section. Change E: This is a manifesto, and is not address policy. If anything these belong is ARIN's mission statement. Change F: Not policy; covered by the RSA as a legal matter. Change G: Not policy. A darn good warning though ARIN should include with any other boilerplate when issuing address space. Change H: Not policy, and covered by actual policy statement 6.5.1.2. Change I: Proposal 2005-8 amended section 6.5.4.1 to allow /56 and /64 allocations, but section 6.5.1.1.d was never updated to match the change. It is believed the intent of the policy, and ARIN staff's current interpretation of the policy match the updated text. Change J: The first part is not policy, and incorrectly states there is no policy as section 6.5.4 has the policy in it. Take the one useful part and make it part of the 6.5.4 criteria. Change K: No metric is currently listed to justify a larger initial assignment. It is believed ARIN staff is currently applying the HD-Ratio similar to the ISP policy, this puts that in writing. Make it clear that the reservation may not exist in perpetuity. Change L: No metric is given to justify additional assignments. It is believed that ARIN staff is currently applying the HD_Ratio similar to the ISP policy, this puts that in writing. Change M: References, while useful on the web page and in template instructions are not policy. Change N: It's not an appendix. It's not even at the end. Change O: The background information would be something nice to archive on the ARIN web site somewhere, but is not policy and should be removed from the policy manual. Timetable for implementation: Immediate. From info at arin.net Mon Aug 20 10:29:07 2007 From: info at arin.net (Member Services) Date: Mon, 20 Aug 2007 10:29:07 -0400 Subject: Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses Message-ID: <46C9A533.5090808@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as a formal policy proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Decreasing Exponential Rationing of IPv4 IP Addresses Author: Dean Anderson Proposal Version: 1 Submission Date: 8/18/07 Proposal type: new Policy term: renewable Policy statement: ARIN will ration the remaining available IP Address Space according to a decreasing exponential function in the family of e^(-x), where the ultimate function and factors are chosen to ensure that the remaining IP address space lasts for at least 10 years. This function will be used to limit the IP Address space allocations. If IP Address Space becomes available (e.g. via return), the ration can be recalculated. However, Ration calculations will not be based on projected or anticipated returns. Contested IP Address Space will also be excluded from the amount of available Address Space for ration calculations. Rationale: Two reports[1,2] project that IP Addresses will be exhausted around March 2010. * Both reports agree that if IP Addresses continue to delegated at the present rates, we will run out of space in March 2010. * Everyone seems to agree that depletion will be a very bad event. * It is therefore imperative to begin rationing to slow down the rate of new delegations to conserve the available address space. * It is necessary to do this now. One can't start rationing after the resources run out. Sudden IPv4 IP Address Exhaustion is expected to cause sudden disruption and discontinuity in business operations and planning. As with other limited resources, the mere anticipation of exhaustion will lead to hoarding and other behaviors that increase the harm of a sudden exhaustion. Rationing on a decreasing exponential will essentially prevent total exhaustion and will gradually decrease the rate of IP Address delegation so to alleviate the harms of a sudden stop in IP Address delegation. Prevention of IPv4 IP Address Exhaustion will help ensure a smooth transition to IPV6. Rationing helps ensures that IP Address space remains available to future needs. [1] http://www.potaroo.net/tools/ipv4/index.html [2] http://www.tndh.net/~tony/ietf/ipv4-pool-combined-view.pdf Timetable for implementation: Immediate From info at arin.net Wed Aug 22 13:25:59 2007 From: info at arin.net (Member Services) Date: Wed, 22 Aug 2007 13:25:59 -0400 Subject: NRPM version 2007.2 - New Policy Implementation Message-ID: <46CC71A7.1090007@arin.net> On 14 June 2007, the ARIN Board of Trustees, based on the recommendations of the Advisory Council and noting that the Internet Resource Policy Evaluation Process had been followed, adopted the following policy proposal: 2007-11: Refinement of ISP Initial Allocation Policy 2007-9: Modernization of ISP Immediate Need Policy 2007-8: Transfer Policy Clarifications 2007-7: Creation of Policy for Subsequent End-User IP Requests/Assignments 2007-4: Changes to IPv6 policy - removal of "interim" consideration These policy proposals, as well as 2005-3: Lame Delegations, have been incorporated into version 2007.2 of the ARIN Number Resource Policy Manual (NRPM) which is effective 22 August 2007. NRPM version 2007.2 supersedes previous versions. See Appendix A of the NRPM for information regarding changes to the manual. The guidelines for lame delegations have been updated and can be found at: http://www.arin.net/reference/lame_delegations.html The NRPM can be found at: http://www.arin.net/policy/nrpm.html Appendix A can be found at: http://www.arin.net/policy/nrpm_changelog.html Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Wed Aug 22 16:53:40 2007 From: info at arin.net (Member Services) Date: Wed, 22 Aug 2007 16:53:40 -0400 Subject: AC shepherds Message-ID: <46CCA254.4080900@arin.net> The ARIN Advisory Council (AC) assigned shepherds for the policy proposals received over the last several days as follows: The shepherds from the AC for "Expand timeframe of Additional Requests" are Marla Azinger and Matt Pounsett. The shepherds from the AC for "End Policy for IANA IPv4 allocations to RIRs" are Dan Alexander and Robert Seastrom. The shepherds from the AC for "IPv6 Assignment Guidelines" are Ron da Silva and Stacy Taylor. The shepherds from the AC for "ISP to LIR Clarification" are Heather Schiller and Paul Andersen. The shepherds from the AC for "IPv6 Policy Housekeeping" are Lea Roberts and Stacy Taylor. The shepherds from the AC for "Decreasing Exponential Rationing of IPv4 IP Addresses" are Dan Alexander and Cathy Aronson. Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Thu Aug 23 11:30:58 2007 From: info at arin.net (Member Services) Date: Thu, 23 Aug 2007 11:30:58 -0400 Subject: [ppml] Policy Proposal: ISP to LIR Clarification - version 1.1 In-Reply-To: <46C5E745.5050708@arin.net> References: <46C5E745.5050708@arin.net> Message-ID: <46CDA832.7030709@arin.net> The author submitted a revised version of their proposal. Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: ISP to LIR Clarification Author: Leo Bicknell Proposal Version: 1.1 Submission Date: 8/22/2007 Proposal type: modify Policy term: permanent Policy statement: Replace all instances of the word "ISP" in the NRPM with the word "LIR" and replace all instances of the phrase "LIR/ISP" with "LIR", except for the following: * Leave section 2.4 unchanged. * Leave section 2.7 unchanged. * In section 4.1.1, replace "ISPs" with "requesters". * In section 4.2.1.1, also remove "Internet Service Providers". * Leave section 6.2.4 unchanged. * Leave section 6.3.4 unchanged. * In section 6.9, replace "ISPs and LIRs" with "LIRs" for all three occurrence. Rationale: The NRPM is inconsistent. The terms ISP and LIR are used interchangeably throughout the document, with the term ISP being predominant in the IPv4 sections and the term LIR being predominant in the IPv6 sections. The use of the term ISP poses two different problems: 1) The term has meaning outside of ARIN's policy. Multiple discussions on PPML have degenerated over people arguing what an ISP is with regards to policy when the reality is that the relationship is defined in the NRPM. As LIR has no meaning outside of policy this confusion will be removed. 2) The other four RIRs have standardized on LIR. This change will make it easier for those doing business with more than one LIR to use consistent terms. This change does not alter any policy, it merely makes the policy easier to understand. Timetable for implementation: immediate Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as a formal policy proposal as written. If the > AC accepts the proposal, it will be posted as a formal policy proposal > to PPML and it will be presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The AC > will work with the author to clarify, combine or divide the proposal. At > their following meeting the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision. If a proposal is not accepted, then > the author may elect to use the petition process to advance their > proposal. If the author elects not to petition or the petition fails, > then the proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: ISP to LIR Clarification > > Author: Leo Bicknell > > Proposal Version: 1.0 > > Submission Date: 8/17/2007 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Replace all instances of the word "ISP" in the NRPM with the word "LIR" > and replace all instances of the phrase "LIR/ISP" with "LIR", except for > the following: > > * Leave section 2.4 unchanged. > * Leave section 2.7 unchanged. > * In section 4.1.1, replace "ISPs" with "requesters". > * In section 4.2, also remove "Internet Service Providers". > * Leave section 6.2.4 unchanged. > * Leave section 6.3.4 unchanged. > * In section 6.9, replace "ISPs and LIRs" with "LIRs" for all three > occurrence. > > Rationale: > > The NRPM is inconsistent. The terms ISP and LIR are used > interchangeably throughout the document, with the term ISP being > predominant in the IPv4 sections and the term LIR being predominant in > the IPv6 sections. > > The use of the term ISP poses two different problems: > > 1) The term has meaning outside of ARIN's policy. Multiple discussions > on PPML have degenerated over people arguing what an ISP is with > regards to policy when the reality is that the relationship is > defined in the NRPM. As LIR has no meaning outside of policy > this confusion will be removed. > > 2) The other four RIRs have standardized on LIR. This change will make > it easier for those doing business with more than one LIR to use > consistent terms. > > This change does not alter any policy, it merely makes the policy easier > to understand. > > Timetable for implementation: immediate > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From info at arin.net Thu Aug 23 14:56:00 2007 From: info at arin.net (Member Services) Date: Thu, 23 Aug 2007 14:56:00 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 In-Reply-To: <46C5E72F.2080903@arin.net> References: <46C5E72F.2080903@arin.net> Message-ID: <46CDD840.1050001@arin.net> The author submitted a revised version of their proposal. Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv6 Assignment Guidelines Author: Leo Bicknell and Ed Lewis Proposal Version: 3.0 Submission Date: 8/23/2007 Proposal type: new Policy term: permanent Policy statement: Delete the text in 6.5.4.2 and Replace the text in section 6.5.4.1 with the following text: Assignments by LIRs /48 or smaller will not be reviewed by ARIN. Assignments greater than /48 will be reviewed to see if the additional space is warranted according to the 0.94 HD ratio policy. If the space is not warranted, ARIN will consider the excess space to be available for a different assignment, lowering the overall utilization score of the LIR. Rationale: The existing section 6.5.4.1 does not provide clear guidance on how ARIN should treat prefixes allocated to a site should an ISP come back for additional space in the future. This makes it difficult for LIR's to know if they are allocating in accordance with the rules under which they will be judged in the future. The existing section also provides no guidence on what the LIR or ARIN should do in the case a larger prefix is necessary. Timetable for implementation: immediate Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as a formal policy proposal as written. If the > AC accepts the proposal, it will be posted as a formal policy proposal > to PPML and it will be presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The AC > will work with the author to clarify, combine or divide the proposal. At > their following meeting the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision. If a proposal is not accepted, then > the author may elect to use the petition process to advance their > proposal. If the author elects not to petition or the petition fails, > then the proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: IPv6 Assignment Guidelines > > Author: Leo Bicknell > > Proposal Version: 1.0 > > Submission Date: 8/17/2007 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Replace the text in section 6.5.4.1 with the following text: > > LIR's may assign blocks in the range of /48 to /64 to end sites. > All assignments made by LIR's should meet a minimum HD-Ratio of .25. > > * /64 - Site needing only a single subnet. > * /60 - Site with 2-3 subnets initially. > * /56 - Site with 4-7 subnets initially. > * /52 - Site with 8-15 subnets initially. > * /48 - Site with 16+ subnets initially. > > For end sites to whom reverse DNS will be delegated, the LIR/ISP should > consider making an assignment on a nibble (4-bit) boundary to simplify > reverse lookup delegation. > > LIR's do not need to issue all 5 sizes of prefixes as long as the > HD-Ratio requirement is met. > > Rationale: > > The existing section 6.5.4.1 does not provide clear guidance on how > large of a prefix to allocate to a site. This makes it difficult for > LIR's to know they are in compliance with the rules, and makes it harder > for ARIN staff to evaluate requests per the communities wishes. > > This policy is based on an HD Ratio of .25 for end sites. The following > table may be useful: > > Prefix Size Number of Subnets Required in Use to Meet .25 > ----------- ----------------- --------------------------- > /64 1 1 > /60 16 2 > /56 256 4 > /52 4096 8 > /48 65536 16 > > It is believed this policy provides clear guidance while allowing LIR's > to make generous allocations to their end-sites. > > Timetable for implementation: immediate for new requests, 2 year grace > period for all existing assignments. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From info at arin.net Tue Aug 28 10:33:01 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:33:01 -0400 Subject: Policy Proposal 2007-16: IPv4 Soft Landing Message-ID: <46D4321D.1000608@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) concluded their initial review of "IPv4 Soft Landing" and accepted it as a formal policy proposal for discussion by the community. The AC accepted this proposal as written. The AC believes that further edits would clarify the proposal and enhance the chance of community consensus, and will be contacting the author with their suggestions within the next week. The Advisory Council recommends the author consider these changes, and submit them to policy at arin.net no later than 17 September 2007, which is suggested as a deadline for revisions for the upcoming public policy meeting. The proposal is designated Policy Proposal 2007-16: IPv4 Soft Landing. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_16.html All persons in the community are encouraged to discuss Policy Proposal 2007-16 prior to it being presented at the ARIN Public Policy Meeting in Albuquerque, New Mexico, 17-18 October 2007. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-16 IPv4 Soft Landing Author: David Conrad Proposal type: New Policy term: Permanent Policy statement: This policy is intended to replace section 4.2.4.1 of the ARIN Number Resource Policy Manual with wording substantially along the lines of: --- begin modification --- 4.2.4.1 In order to encourage a smooth transition to IPv6, ARIN has instituted a set of IPv4 Address Allocation "phases" that vary the requirements for address allocation using the amount of address space remaining unallocated by IANA as a metric. As the amount of address space in the IANA free pool is reduced, the requirements for IPv4 address allocation are made more stringent. When requesting additional IPv4 address space, ISPs must meet the requirements of the IPv4 Address Allocation phase ARIN was in when the request was submitted. These phases will require the requester to demonstrate increasingly efficient utilization of previously allocated IPv4 address space, including all space reassigned to their customers. In addition, depending on the IPv4 Address Allocation phase ARIN was in when the request was submitted, there may be additional requirements that will need to be met by the requester such as completing a survey on IPv6 deployment plans, documentation of non-private address space used for internal infrastructure, documentation of IPv6 plans for offering connectivity and services, etc. The reassignment information section of the ARIN ISP Network Request Template should be completed for all address blocks that have been allocated to your organization. In the template, line 1b. Assigned: information will be verified via SWIP/RWHOIS and 1c. Reserved: should be used to indicate internal network information. Please note that until all requirements are met and your prior utilization is verified to meet the requirements specified in the IPv4 Address Allocation phase in which the request was received, ARIN can neither process nor approve a request for additional addresses. IPv4 Allocation Phases The thresholds and the requirements to justify an allocation of new IPv4 address space from ARIN are defined in this section. Phase: 0 Threshold: Greater than 40 /8s Requirements: Requesters must: * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 25% utilization - Demonstrate a one year requirement of 50% utilization Phase: 1 Threshold: 40 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 25% utilization - Demonstrate a one year requirement of 50% utilization * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used. Phase: 2 Threshold: 25 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 85% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 50% utilization - Demonstrate a one year requirement of 75% utilization * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used. * Provide plans for migrating all non-RFC 1918 address space used for internal infrastructure either to IPv6 (preferred) or to private addressing where possible. Where such migration is not possible, provide documentation listing the use of addresses that are not migratable and the reasons for the inability to migrate. * Demonstrate documented plans for availability of production IPv6 infrastructure and connectivity services within 6 months of submitting the request. Phase: 3 Threshold: 10 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 90% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 75% utilization - Demonstrate a one year requirement of 90% utilization * Provide documentation demonstrating migration (where possible) of non-RFC 1918 address space used for internal infrastructure to either IPv6 (preferred) or private addressing. * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure, how it is used, and why it is not possible to migrate those addresses to either IPv6 (preferred) or private addressing. * Demonstrate availability of production IPv6 infrastructure and connectivity services. Notes: * Phase 0 reflects current allocation requirements. * Phases 1 through 3 are to be implemented 30 days after IANA allocates address space from the IPv4 free pool that reduces that free pool to a number of /8s that are at or below the threshold specified. * If multiple thresholds should be crossed within a 30 day period, the requirements from the last threshold crossed will be applied to requesters for additional address space at the time of the request. --- end modification --- Rationale: The rationale for this proposal is threefold: * to prolong the availability of IPv4 addresses for requesters who can provide sufficient justification; * to encourage the deployment of IPv6 as an alternative to IPv4 by making the requirements to justify IPv4 allocations increasingly stringent over time; * to promote the more efficient use of increasingly scarce IPv4 resources. As the lack of significant deployment of IPv6 can attest, the cost of deploying IPv6 currently outweighs the benefits that protocol would appear to provide. This proposal aims to encourage the deployment of IPv6 by over time, making the allocation of IPv4 both more difficult and contingent on the requester demonstrating both support for IPv6 as well as requiring a demonstration that the IPv4 address space they administer is being used efficiently. The goal of these measures is to rebalance the IPv6 deployment cost/benefit ratio thereby encouraging greater uptake of IPv6 before the IPv4 free pool is exhausted. The "IPv4 Soft Landing" policy aims to provide for a smoother transition away from IPv4 towards IPv6 by imposing increasingly strict requirements for new address allocations as the amount of address space available in the IANA unallocated IPv4 address pool decreases. These increased requirements include both more stringent reassignment and utilization percentages as well as requiring documented IPv6 infrastructure services and connectivity provision and the documentation or reuse of public IPv4 address space used for internal infrastructure. The increased stringency in the allocation requirements is intended both to increase the efficiency of utilization of the IPv4 address space and to reduce the likelihood of a "run" on the remaining free pool of IPv4 address space. ARIN staff would be expected to use the same mechanisms in use today to verify conformance to the specified requirements. The requirements for demonstration of IPv6 infrastructure services and connectivity are intended to motivate ISPs to provide those services before the only address space they can offer their customers is IPv6, thereby offering an opportunity to break the "chicken-and-egg" problem limiting significant IPv6 deployment. Verification of these requirements can be done by ARIN staff by using IPv6 transport to connect to published services of the ISP (e.g., DNS servers, WWW URLs, etc.) as well as using IPv6 ping to identified addresses internal to the ISP. Obviously, false positive responses for most any objective mechanism for verifying the availability can be engineered, so ARIN staff may also consider subjective reports of an inability to obtain IPv6 services by customers as an indicator of (lack of) conformance to this requirement. The requirements to migrate internal infrastructure to either IPv6 or private (e.g., RFC 1918) addressing are intended to improve the efficiency of utilization of IPv4 address space, reserving the scarce IPv4 resources for purposes for which IPv6 or private addresses are not suitable. These requirements acknowledge that pragmatically, the use of IPv4 is absolutely essential only for servers in client-server architectures, machines engaged in peer-to-peer applications, and entry points for NAT/ALG devices. As such, use of IPv4 for purposes such as router interface numbering, client-only devices, and devices which should not be available from external networks should be discouraged. Since there can be circumstances in which migration of internal infrastructure addresses to private addressing would not be feasible, this policy allows for requesters to document those situations in which it is not possible to do the migration. The time for transition between phases of this policy are not fixed, rather they depend on the rate of consumption of IPv4 address space from the IANA free pool. Current RIR operational procedure is to request 2 /8s from the IANA when the RIR's current pool of free IPv4 address space is depleted. This procedure should ensure transitions between phases will have some lead-time, so organizations can prepare for the next phase of IPv4 address allocation. Given the highly volatile nature of IPv4 consumption and the inability to define a predictive model rooted in an underlying theory rather than extrapolating over existing data, the thresholds chosen are acknowledged to be somewhat arbitrary. The intent of the chosen values is to provide a "reasonable" amount of time, approximately 18 months, between transitions at current consumption rates (approximately 10 /8s per year). However, it should be explicitly noted that one of the intents of this policy is to extend the IPv4 free pool lifetime, thus as the policy becomes effective, the amount of time between phase transitions would presumably increase. Timetable for implementation: Immediately upon approval of this policy by the ARIN Board of Trustees. From info at arin.net Tue Aug 28 10:37:22 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:37:22 -0400 Subject: Policy Proposal 2007-17: Legacy Outreach and Partial Reclamation Message-ID: <46D43322.6040907@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) concluded their initial review of "Legacy Outreach and Partial Reclamation" and accepted it as a formal policy proposal for discussion by the community. The AC accepted this proposal as written. The AC believes that further edits would clarify the proposal and enhance the chance of community consensus, and will be contacting the author with their suggestions within the next week. The Advisory Council recommends the author consider these changes, and submit them to policy at arin.net no later than 17 September 2007, which is suggested as a deadline for revisions for the upcoming public policy meeting. The proposal is designated Policy Proposal 2007-17: Legacy Outreach and Partial Reclamation. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_17.html All persons in the community are encouraged to discuss Policy Proposal 2007-17 prior to it being presented at the ARIN Public Policy Meeting in Albuquerque, New Mexico, 17-18 October 2007. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-17 Legacy Outreach and Partial Reclamation Author: Owen DeLong Proposal type: modify Policy term: permanent Policy statement: Modify section 4.6 as follows: 4.6 Amnesty Requests ARIN will accept the return or relinquishment of any address space from any existing address holder. If the address holder wishes to aggregate into a single block, ARIN may work with the address holder to arrive at an allocation or assignment which is equal to or smaller than the sum of their existing blocks and which best meets the needs of the existing holder and the community. There shall be no fee for returning addresses under this policy. Further, organizations returning addresses under this policy shall receive the following benefits: 1. If the organization does not currently pay ARIN fees, they shall remain fee exempt. 2. If the organization currently pays ARIN fees, their fees shall be waived for two years for each /20 equivalent returned, with any fractional /20 equivalent resulting in a one-time single year waiver. 3. Any organization returning address space under this policy shall continue under their existing RSA or they may choose to sign the current RSA. For organizations which currently do not have an RSA, they may sign the current RSA, or, they may choose to remain without an RSA. 4. All organizations returning space under this policy shall, if they meet other eligibility requirements and so request, obtain an appropriate IPv6 end-user assignment or ISP allocation as applicable, with no fees for the first 5 years. Organizations electing to receive IPv6 allocation/assignment under this provision must sign a current RSA and must agree that all of their IPv4 resources are henceforth subject to the RSA. Organizations taking this election shall be subject to end-user fees for their IPv4 resources not previously under an ARIN RSA. If they are already an ARIN subscriber, then IPv4 resources affected by this process may, instead, be added to their existing subscriber agreement at the address holder's discretion. Rationale: The current amnesty policy does a nice job of facilitating aggregation, which was the intent when it was drafted. However, as we approach IPv4 free-space exhaustion, the community now has an additional need to facilitate address reclamation. A very high percentage of underutilized space is in the hands of legacy holders who currently have no benefit to joining the ARIN process. Further, there is an unfortunate perception that doing so will require force the legacy holder into certain future disadvantages. This proposal attempts to resolve both of those issues while also providing some incentive to legacy organizations to start using IPv6 resources and bring their IPv4 resources into the ARIN process. This policy attempts to provide some benefit and remove most of the costs of making partial IPv4 returns. It also attempts to provide an incentive for these IPv4 holders to join the ARIN process. Timetable for implementation: Immediate From info at arin.net Tue Aug 28 10:38:33 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:38:33 -0400 Subject: Policy Proposal 2007-18: Global Policy for the Allocation of the Remaining IPv4 Address Space Message-ID: <46D43369.4020206@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) concluded their initial review of "Global Policy for the Allocation of the Remaining IPv4 Address Space" and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-18: Global Policy for the Allocation of the Remaining IPv4 Address Space. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_18.html All persons in the community are encouraged to discuss Policy Proposal 2007-18 prior to it being presented at the ARIN Public Policy Meeting in Albuquerque, New Mexico, 17-18 October 2007. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-18 Global Policy for the Allocation of the Remaining IPv4 Address Space Author: Roque Gagliano Co-authors: Francisco Obispo, Hytham EL Nakhal, Didier Allain Kla Proposal type: new Policy term: permanent Policy statement: This policy describes the process for the allocation of the remaining IPv4 space from IANA to the RIRs. When a minimum amount of available space is reached, an identical number of IPv4 allocation units (/8s) will be allocated from IANA to each RIR, replacing the current IPv4 allocation policy. In order to fulfill the requirements of this policy, at the time it is adopted, an identical number of IPv4 allocation units (N units) will be reserved by IANA for each RIR. The number N is defined as: 5. The reserved allocation units will no longer be part of the available space at the IANA pool. The process for the allocation of the remaining IPv4 space is divided in two consecutive phases: 1. Existing Policy Phase: During this phase IANA will continue allocating IPv4 addresses to the RIRs using the existing allocation policy. This phase will continue until a request for IPv4 address space from any RIR to IANA cannot be fulfilled with the remaining IPv4 space available at the IANA pool. This will be the last IPv4 address space request that IANA will accept from any RIR. At this point the next phase of the process will be initiated. 2. Exhaustion Phase: IANA will automatically allocate the reserved IPv4 allocation units to each RIR (N units to each one) and respond to the last request with the remaining available allocation units at the IANA pool (M units). 2.1. Size of the final IPv4 allocations: During this phase IANA will automatically allocate N allocation units to each RIR from the reserved space defined in this policy. IANA will also allocate M allocation units to the RIR that submitted the last request for IPv4 addresses. 2.2. Allocation of the remaining IPv4 Address space: After the completion of the evaluation of the final request for IPv4 addresses, IANA MUST: A) Immediately notify the NRO about the activation of the second phase of this policy. B) Proceed to allocate M allocation units to the RIR that submitted the last request for IPv4 address space. C) Proceed to allocate N allocation units to each RIR from the reserved space. Rationale: The IANA pool of allocation units of IPv4 addresses (/8s) is decreasing rapidly. A new policy is proposed to replace the current "on demand" policy in order to bring certainty on how the remaining space will be allocated. This policy eliminates the pressure on the remaining central pool of addresses by allocating equal amount of allocation units (N) to each RIR. RIR may be studying slow-landing policies or the possibility to reserve specific address spaces for "critical infrastructure" or new companies in order to comply with anti-trust regulations in its region. This policy allows each RIR to adopt those policies through its PDP, which is simpler than a global policy discussion process. Each RIR will have the exact information on the amount of address spaces that they will be receiving as a last allocation from the IANA. The policy is written in such a way that the discussion could be split in two sections: first do we agree on the concept of the policy and second what is the appropriate value for the last allocation units N. Timetable for implementation: This is a Global policy that needs to be approved by all RIRs and then ratified by ASO/ICANN. It has already reached consensus at LACNIC meeting. From info at arin.net Tue Aug 28 10:39:44 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:39:44 -0400 Subject: Policy Proposal 2007-19: IANA Policy for Allocation of ASN Blocks to RIRs Message-ID: <46D433B0.2070405@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) concluded their initial review of "IANA Policy for Allocation of ASN Blocks to RIRs" and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-19: IANA Policy for Allocation of ASN Blocks to RIRs. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_19.html All persons in the community are encouraged to discuss Policy Proposal 2007-19 prior to it being presented at the ARIN Public Policy Meeting in Albuquerque, New Mexico, 17-18 October 2007. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-19 IANA Policy for Allocation of ASN Blocks to RIRs Author: Axel Pawlik Proposal type: New Policy term: renewable Policy statement: Abstract This document describes the policy governing the allocation of Autonomous System Numbers (ASNs) from the IANA to the Regional Internet Registries (RIRs). This policy document does not stipulate performance requirements in the provision of services by the IANA to an RIR. Such requirements will be specified by appropriate agreements between ICANN and the Number Resource Organization (NRO). 1. Allocation Principles IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2009, allocations of 2-byte only and 4-byte only ASN blocks will be made separately and independent of each other [1]. This means until 31 December 2009, RIRs can receive two separate ASN blocks, one for 2-byte only ASNs and one for 4-byte only ASNs from the IANA under this policy. After this date, IANA and the RIRs will cease to make any distinction between 2-byte only and 4-byte only ASNs, and will operate ASN allocations from an undifferentiated 4-byte ASN allocation pool. 2. Initial Allocations Each new RIR will be allocated a new ASN block. 3. Additional Allocations An RIR is eligible to receive (an) additional ASN block(s) from the IANA if one of the following conditions is met: 1. The RIR has assigned/allocated 80% of the previously received ASN block, or 2. The number of free ASNs currently held by the RIR is less than two months need. This projection is based on the monthly average number of ASNs assigned/allocated by the RIR over the previous six months. An RIR will be allocated as many ASN blocks as are needed to support their registration needs for the next 12 months, based on their average assignment/allocation rate over the previous six months, unless the RIR specifically requests fewer blocks than it qualifies for. 4. Announcement of IANA Allocations The IANA, the NRO and the RIRs will make announcements and update their respective websites/databases when an allocation is made by the IANA to an RIR. ICANN and the NRO will establish administrative procedures to manage this process. [1. http://www.ripe.net/ripe/policies/proposals/2005-12.html] Rationale: There are global policies governing the allocation of IPv4 and IPv6 blocks from the IANA to RIRs. At this point there is no specific policy regarding the allocation of Autonomous System Numbers from the IANA to the RIRs. This proposal will create a policy to fill this gap. The criteria being proposed has already been the practice between IANA and RIRs so far and it has been proven to work. It is designed to allow RIRs to request ASN blocks from the IANA in a timely fashion and maintain enough ASNs in holding to ensure that their registration services can be sustained. It is also proposed that the RIRs be allocated as many ASN blocks as are needed to support their registration needs for the next 12 months. This will generally mean that each RIR will only need to make one ASN request from the IANA each year, thus lowering operational overhead for the RIRs. Timetable for implementation: Immediate From info at arin.net Tue Aug 28 10:41:45 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:41:45 -0400 Subject: Policy Proposal 2007-20: Definition of known ISP and changes to IPv6 initial allocation criteria Message-ID: <46D43429.1000306@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) concluded their initial review of "Definition of known ISP and changes to IPv6 initial allocation criteria" and accepted it as a formal policy proposal for discussion by the community. The AC accepted this proposal as written. The AC believes that further edits would clarify the proposal and enhance the chance of community consensus, and will be contacting the author with their suggestions within the next week. The Advisory Council recommends the author consider these changes, and submit them to policy at arin.net no later than 17 September 2007, which is suggested as a deadline for revisions for the upcoming public policy meeting. The proposal is designated Policy Proposal 2007-20: Definition of known ISP and changes to IPv6 initial allocation criteria. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_20.html All persons in the community are encouraged to discuss Policy Proposal 2007-20 prior to it being presented at the ARIN Public Policy Meeting in Albuquerque, New Mexico, 17-18 October 2007. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-20 Definition of known ISP and changes to IPv6 initial allocation criteria Author: Kevin Loch Proposal type: new Policy term: permanent Policy statement: Add the following section 6.2.10: 6.2.10 Existing ISP An existing ISP is an organization which meets the following criteria: 1. Has IPv4 or IPv6 address space directly allocated by ARIN; or 2. Has at least a total of an IPv4 /23 or an IPv6 /44 of address space reallocated to them via SWIP by one or more upstream ISPs. Address space directly assigned from ARIN or reassigned from upstream ISPs does not count towards these requirements. Replace 6.5.1.1 (d) with the following text: d. be an existing ISP in the ARIN region or have a plan for making assignments to at least 200 separate organizations within five years. Rationale: This policy proposal would change two things in the IPv6 Initial allocation criteria. It adds a definition for "known ISP" and changes "200 /48 assignments" to 200 assignments of any size, but to separate organizations. Existing ISP: The term "existing, known ISP" in the IPv6 ISP qualification section is too vague and does not give ARIN staff sufficient guidance for evaluating qualifications. This text defines "existing, ISP" in a precise manner and removes the unnecessary and ambiguous word "known". It has come to the author's attention that several organizations have been refused IPv6 ISP allocations because they were not considered an existing, known ISP. At least one of these organizations has a /18 worth of IPv4 space reallocated to them by various upstream ISPs and over 200 IPv4 customers. An organization's choice to use provider addresses does not have any affect on whether or not they are in fact an ISP. Address space that has been reallocated (not reassigned) is a good indicato of an ISP as those SWIP templates are only supposed to be used for downstream ISPs. The IPv4 /23 value was selected to match the utilization requirement for the smallest direct IPv4 allocation from ARIN under current policy. The IPv6 /44 value was selected to represent a number of downstream customers comparable to the IPv4 requirements. Updates to IPv6 initial allocation criteria: Section 6.5.4.1 recommends /56 assignments in some cases and /48 assignments in others. The Initial allocation criteria should reflect the flexibility of these recommendations. An ISP should not have to provide an inefficient address plan on their application even though they expect to have over 200 IPv6 customers. Timetable for implementation: Immediate From info at arin.net Tue Aug 28 10:43:00 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:43:00 -0400 Subject: Policy Proposal 2007-21: PIv6 for legacy holders with RSA and efficient use Message-ID: <46D43474.3040909@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) concluded their initial review of "PIv6 for legacy holders with RSA and efficient use" and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-21: PIv6 for legacy holders with RSA and efficient use. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_21.html All persons in the community are encouraged to discuss Policy Proposal 2007-21 prior to it being presented at the ARIN Public Policy Meeting in Albuquerque, New Mexico, 17-18 October 2007. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-21 PIv6 for legacy holders with RSA and efficient use Author: Scott Leibrand Proposal type: new Policy term: permanent Policy statement: Modify NRPM section 6.5.8.1 (Direct assignments from ARIN to end-user organizations: Criteria), to read: To qualify for a direct assignment, an organization must: 1. not be an IPv6 LIR; and 2. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect, or demonstrate efficient utilization of a direct IPv4 assignment or allocation covered by a current ARIN RSA. Rationale: Current policy allows direct IPv6 allocations and assignments to nearly all organizations with IPv4 allocations or assignments from ARIN. As a result, such organizations can get IPv6 space just as easily as they can get IPv4 space, making it easy for them to transition to IPv6 as soon as they're ready to do so. However, there are some organizations who received IPv4 /23's and /24's prior to the formation of ARIN, and use that space in a multihomed, provider-independent fashion. Under current policy, such organizations cannot get IPv6 PI space without artificially inflating host counts, and are therefore discouraged from adopting IPv6. This policy proposal aims to remove this disincentive, and allow such organizations to easily adopt IPv6. In addition, pre-ARIN assignments were issued through an informal process, and many legacy resource holders have not yet entered into a formal agreement with ARIN, the manager of many such IP numbering resources. This policy proposal would require that such assignments be brought under a current ARIN Registration Services Agreement, thereby formalizing the relationship. Some pre-ARIN assignments may not be used efficiently. As unallocated IPv4 numbering resources are approaching exhaustion, it is important to ensure efficient utilization of IPv4 assignments, and to arrange for reclamation of unused space. Therefore, this policy would require that the organization wishing to receive IPv6 PI space demonstrate efficient utilization of their IPv4 assignment. (Efficient utilization is already defined elsewhere in policy, and the exact mechanism for achieving and determining efficient use is a matter of procedure, not of policy, so detailed procedures are not included in the policy statement above. The intent is that any organization with an assignment of /23 or larger which is less than 50% utilized would renumber and return whole unused CIDR blocks as necessary to bring the remaining CIDR block to 50% utilization or higher. A /24 should be considered efficiently utilized as long as it is in use for multihoming, as /25's and smaller are not routable for that purpose.) It has been suggested that this policy would be useful only until the growth of IPv6 exceeds the growth of IPv4. I would agree with this, and would further posit that the existing "qualify ... under the IPv4 policy currently in effect" language should also be modified at that time. I have therefore proposed this policy with a policy term of "permanent", with the expectation that this section of policy (6.5.8.1) will be rewritten at the appropriate time to entirely remove all IPv4 dependencies. Timetable for implementation: immediate From info at arin.net Tue Aug 28 10:44:21 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:44:21 -0400 Subject: Policy Proposal 2007-22: Expand timeframe of Additional Requests Message-ID: <46D434C5.8070409@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) concluded their initial review of "Expand timeframe of Additional Requests" and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-22: Expand timeframe of Additional Requests. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_22.html All persons in the community are encouraged to discuss Policy Proposal 2007-22 prior to it being presented at the ARIN Public Policy Meeting in Albuquerque, New Mexico, 17-18 October 2007. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-22 Expand timeframe of Additional Requests Author: Dan Alexander Proposal type: modify Policy term: permanent Policy statement: The proposal is to modify section 4.2.4.4 of the NRPM Current wording: "After a subscriber has been a member of ARIN for one year they may choose to request a six-month supply of IP addresses." Change to: "After an organization has been an ARIN member in good standing for one year, they may choose to request up to a 12 month supply of IP addresses." Rationale: Currently, all RIR's provide organizations with at least a 12 month supply of IPv4 address space when making subsequent requests, with the exception of the ARIN region. The primary reason for this change is for continuity among all RIR. In doing so, all established organizations have a more consistent access to IP resources. The adjustment does not change demand on IPv4 address space. It only changes the frequency in which established organizations need to request address space. This would allow for fewer potential aggregates allocated to an organization providing more consolidated routing announcements. This does not change the requirement on new organizations where established growth trends have yet to be established. Timetable for implementation: Immediate From info at arin.net Tue Aug 28 10:45:16 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:45:16 -0400 Subject: Policy Proposal 2007-23: End Policy for IANA IPv4 allocations to RIRs Message-ID: <46D434FC.50208@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) concluded their initial review of "End Policy for IANA IPv4 allocations to RIRs" and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-23: End Policy for IANA IPv4 allocations to RIRs. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_23.html All persons in the community are encouraged to discuss Policy Proposal 2007-23 prior to it being presented at the ARIN Public Policy Meeting in Albuquerque, New Mexico, 17-18 October 2007. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-23 End Policy for IANA IPv4 allocations to RIRs Author: JPNIC IPv4 countdown policy team; Akinori MAEMURA, Akira NAKAGAWA, Izumi OKUTANI, Kosuke ITO, Kuniaki KONDO, Shuji NAKAMURA, Susumu SATO, Takashi ARANO, Tomohiro FUJISAKI, Tomoya YOSHIDA, Toshiyuki HOSAKA Proposal type: new Policy term:renewable Policy statement: 1) Distribute a single /8 to each RIR at the point when new IANA free pool hits 5 */8. This date is defined as "IANA Exhaustion Date". 2) It should be completely left up to each RIR communities to define a regional policy on how to distribute the remaining RIR free pool to LIRs within their respective regions after "IANA Exhaustion Date". Note 1: It is fine for an RIR to continue operations with the existing policy if that is the consensus decision of the respective RIR community. Note 2: Address recovery and re-distribution of recovered address space is another important measure for considerations, but should be treated as a separate policy proposal from distribution of new IANA pool. 3) RIRs should provide an official projection on IANA Exhaustion Date to the community through their website, at their Policy Meetings and through any other effective means. Rationale: [current problem] There are two major issues in terms of address management if no measures are taken for IPv4 address exhaustion. 1) Continue applying a global coordinated policy for distribution of the last piece(s) of RIR's unallocated address block does not match the reality of the situation in each RIR region. Issues each RIR region will face during the exhaustion period vary by region as the level of development of IPv4 and IPv6 are widely different. As a result, applying a global co-ordinated policy may not adequately address issues in a certain region while it could be work for the others. For example, in a region where late comers desperately need even small blocks of IPv4 addresses to access to the IPv4 Internet, a policy that defines the target of allocations/assignments of IPv4 address space to be late comers would be appropriate in such region. This would allow availablilty of IPv4 address space for such requirements for more years. Another example comes from difference in IPv6 deployment rate. For a region where IPv6 deployment rate is low, measures may be necessary to prolong IPv4 address life for the existing business as well as for new businesses until networks are IPv6 ready. Some regions may have strong needs to secure IPv4 address space for translators. A globally coordinated policy which addresses all the issues listed above to meet the needs for all RIR regions may result in not solving issues in any of the regions. 2) LIRs and stakeholders remain unprepared for the situation if they are not informed If LIRs and the community are uninformed of the exhaustion, their services and networks remain unprepared to face the situation at the time of exhaustion. [Objective of the proposal] This proposal seeks to provide the following solutions to the problems listed above. 1) RIR community should be able to define their own regional policies on how to assign the last piece(s) of allocation block in order to address their own regional issues during the exhaustion period. 2) RIRs should provide official projection of the date when LIRs will be able to receive the allocations under the current criteria. The criteria should remain consistent until this date in order to avoid confusion. [Pros and Cons] Pros: + It allows each RIR community to define a policy on how to distribute the last piece(s) of allocations which best matches their situation. + It helps LIR better informed of the date when they are able to receive allocations from RIRs under the current criteria and prepare for the event. Cons: + Concerns could be raised about allocating a fixed size to all RIRs, that it artificially fastens the consumption rate of some RIR regions. However, its impact is kept to minimum by keeping the allocation size to a single /8 which makes merely 3-4 months difference. + Concerns could be raised that explicitly allowing regional policies will encourage RIR shopping. However, this should not happen if the requirements within each region is adequately reflected in each RIR's policy through PDP. RIR may also chose to add criteria to prevent LIRs from other regions submitting such requests. Timetable for implementation: Immediate after all 5 RIRs (and possibly ICANN) ratifies the policy. From info at arin.net Tue Aug 28 10:46:55 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:46:55 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3 - AC postponed decision In-Reply-To: <46CDD840.1050001@arin.net> References: <46C5E72F.2080903@arin.net> <46CDD840.1050001@arin.net> Message-ID: <46D4355F.30000@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) postponed their decision regarding "IPv6 Assignment Guidelines" in order to work with the author on possible revisions. The AC will make their decision to accept or not accept the proposal as a formal policy proposal at a special AC meeting on 30 August 2007. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/submission_archive.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > The author submitted a revised version of their proposal. > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: IPv6 Assignment Guidelines > > Author: Leo Bicknell and Ed Lewis > > Proposal Version: 3.0 > > Submission Date: 8/23/2007 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Delete the text in 6.5.4.2 and Replace the text in section 6.5.4.1 > with the following text: > > Assignments by LIRs /48 or smaller will not be reviewed by ARIN. > Assignments greater than /48 will be reviewed to see if the additional > space is warranted according to the 0.94 HD ratio policy. If the > space is not warranted, ARIN will consider the excess space to be > available for a different assignment, lowering the overall utilization > score of the LIR. > > Rationale: > > The existing section 6.5.4.1 does not provide clear guidance on how > ARIN should treat prefixes allocated to a site should an ISP come > back for additional space in the future. This makes it difficult > for LIR's to know if they are allocating in accordance with the > rules under which they will be judged in the future. The existing > section also provides no guidence on what the LIR or ARIN should > do in the case a larger prefix is necessary. > > Timetable for implementation: immediate > > > > > Member Services wrote: > >> ARIN received the following policy proposal. In accordance with the ARIN >> Internet Resource Policy Evaluation Process, the proposal is being >> posted to the ARIN Public Policy Mailing List (PPML) and being placed on >> ARIN's website. >> >> The ARIN Advisory Council (AC) will review this proposal at their next >> regularly scheduled meeting. The AC may decide to: >> >> 1. Accept the proposal as a formal policy proposal as written. If the >> AC accepts the proposal, it will be posted as a formal policy proposal >> to PPML and it will be presented at a Public Policy Meeting. >> >> 2. Postpone their decision regarding the proposal until the next >> regularly scheduled AC meeting in order to work with the author. The AC >> will work with the author to clarify, combine or divide the proposal. At >> their following meeting the AC will accept or not accept the proposal. >> >> 3. Not accept the proposal. If the AC does not accept the proposal, >> the AC will explain their decision. If a proposal is not accepted, then >> the author may elect to use the petition process to advance their >> proposal. If the author elects not to petition or the petition fails, >> then the proposal will be closed. >> >> The AC will assign shepherds in the near future. ARIN will provide the >> names of the shepherds to the community via the PPML. >> >> In the meantime, the AC invites everyone to comment on this proposal on >> the PPML, particularly their support or non-support and the reasoning >> behind their opinion. Such participation contributes to a thorough >> vetting and provides important guidance to the AC in their deliberations. >> >> The ARIN Internet Resource Policy Evaluation Process can be found at: >> http://www.arin.net/policy/irpep.html >> >> Mailing list subscription information can be found at: >> http://www.arin.net/mailing_lists/ >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Policy Proposal Name: IPv6 Assignment Guidelines >> >> Author: Leo Bicknell >> >> Proposal Version: 1.0 >> >> Submission Date: 8/17/2007 >> >> Proposal type: new >> >> Policy term: permanent >> >> Policy statement: >> >> Replace the text in section 6.5.4.1 with the following text: >> >> LIR's may assign blocks in the range of /48 to /64 to end sites. >> All assignments made by LIR's should meet a minimum HD-Ratio of .25. >> >> * /64 - Site needing only a single subnet. >> * /60 - Site with 2-3 subnets initially. >> * /56 - Site with 4-7 subnets initially. >> * /52 - Site with 8-15 subnets initially. >> * /48 - Site with 16+ subnets initially. >> >> For end sites to whom reverse DNS will be delegated, the LIR/ISP should >> consider making an assignment on a nibble (4-bit) boundary to simplify >> reverse lookup delegation. >> >> LIR's do not need to issue all 5 sizes of prefixes as long as the >> HD-Ratio requirement is met. >> >> Rationale: >> >> The existing section 6.5.4.1 does not provide clear guidance on how >> large of a prefix to allocate to a site. This makes it difficult for >> LIR's to know they are in compliance with the rules, and makes it harder >> for ARIN staff to evaluate requests per the communities wishes. >> >> This policy is based on an HD Ratio of .25 for end sites. The following >> table may be useful: >> >> Prefix Size Number of Subnets Required in Use to Meet .25 >> ----------- ----------------- --------------------------- >> /64 1 1 >> /60 16 2 >> /56 256 4 >> /52 4096 8 >> /48 65536 16 >> >> It is believed this policy provides clear guidance while allowing LIR's >> to make generous allocations to their end-sites. >> >> Timetable for implementation: immediate for new requests, 2 year grace >> period for all existing assignments. >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy >> Mailing List (PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN >> Member Services >> Help Desk at info at arin.net if you experience any issues. >> > > From info at arin.net Tue Aug 28 10:49:31 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:49:31 -0400 Subject: [ppml] Policy Proposal: ISP to LIR Clarification - version 1.1 - AC did not accept In-Reply-To: <46CDA832.7030709@arin.net> References: <46C5E745.5050708@arin.net> <46CDA832.7030709@arin.net> Message-ID: <46D435FB.4080506@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) concluded its review of the proposed policy 'ISP to LIR Clarification' and did not accept it as a formal policy proposal. The AC did not accept the proposal because the AC feels that this is not a policy matter, instead it should be incorporated into NRPM edit work that is being done by several members of the AC. During the initial review period the AC may decide to: 1) Accept the proposal as a formal policy proposal as written. 2) Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. 3) Not accept the policy proposal. In the event that the AC decides not to accept the proposal, then the author may elect to use the petition process to advance the proposal. For petition details see the section called "Petition Process" in the ARIN Internet Resource Policy Evaluation Process which can be found at: http://www.arin.net/policy/irpep.html The deadline for the author to initiate a petition per the ARIN Internet Resource Policy Evaluation Process is 40 days prior to the meeting; the petition deadline for the ARIN XX Public Policy Meeting is 23:59 EDT, 7 September 2007. If the author chooses not to petition or the petition is unsuccessful, then the proposed policy is closed. If a petition is successful, then the proposal will be numbered and posted for discussion and presented at ARIN's Public Policy Meeting. Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > The author submitted a revised version of their proposal. > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: ISP to LIR Clarification > > Author: Leo Bicknell > > Proposal Version: 1.1 > > Submission Date: 8/22/2007 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Replace all instances of the word "ISP" in the NRPM with the word > "LIR" and replace all instances of the phrase "LIR/ISP" with "LIR", > except for the following: > > * Leave section 2.4 unchanged. > * Leave section 2.7 unchanged. > * In section 4.1.1, replace "ISPs" with "requesters". > * In section 4.2.1.1, also remove "Internet Service Providers". > * Leave section 6.2.4 unchanged. > * Leave section 6.3.4 unchanged. > * In section 6.9, replace "ISPs and LIRs" with "LIRs" for all three > occurrence. > > Rationale: > > The NRPM is inconsistent. The terms ISP and LIR are used interchangeably > throughout the document, with the term ISP being predominant in the > IPv4 sections and the term LIR being predominant in the IPv6 sections. > > The use of the term ISP poses two different problems: > > 1) The term has meaning outside of ARIN's policy. Multiple discussions > on PPML have degenerated over people arguing what an ISP is with > regards to policy when the reality is that the relationship is > defined in the NRPM. As LIR has no meaning outside of policy > this confusion will be removed. > > 2) The other four RIRs have standardized on LIR. This change will make > it easier for those doing business with more than one LIR to use > consistent terms. > > This change does not alter any policy, it merely makes the policy easier > to understand. > > Timetable for implementation: immediate > > > > > Member Services wrote: > >>ARIN received the following policy proposal. In accordance with the ARIN >>Internet Resource Policy Evaluation Process, the proposal is being >>posted to the ARIN Public Policy Mailing List (PPML) and being placed on >>ARIN's website. >> >>The ARIN Advisory Council (AC) will review this proposal at their next >>regularly scheduled meeting. The AC may decide to: >> >> 1. Accept the proposal as a formal policy proposal as written. If the >>AC accepts the proposal, it will be posted as a formal policy proposal >>to PPML and it will be presented at a Public Policy Meeting. >> >> 2. Postpone their decision regarding the proposal until the next >>regularly scheduled AC meeting in order to work with the author. The AC >>will work with the author to clarify, combine or divide the proposal. At >>their following meeting the AC will accept or not accept the proposal. >> >> 3. Not accept the proposal. If the AC does not accept the proposal, >>the AC will explain their decision. If a proposal is not accepted, then >>the author may elect to use the petition process to advance their >>proposal. If the author elects not to petition or the petition fails, >>then the proposal will be closed. >> >>The AC will assign shepherds in the near future. ARIN will provide the >>names of the shepherds to the community via the PPML. >> >>In the meantime, the AC invites everyone to comment on this proposal on >>the PPML, particularly their support or non-support and the reasoning >>behind their opinion. Such participation contributes to a thorough >>vetting and provides important guidance to the AC in their deliberations. >> >>The ARIN Internet Resource Policy Evaluation Process can be found at: >>http://www.arin.net/policy/irpep.html >> >>Mailing list subscription information can be found at: >>http://www.arin.net/mailing_lists/ >> >>Regards, >> >>Member Services >>American Registry for Internet Numbers (ARIN) >> >> >>## * ## >> >> >>Policy Proposal Name: ISP to LIR Clarification >> >>Author: Leo Bicknell >> >>Proposal Version: 1.0 >> >>Submission Date: 8/17/2007 >> >>Proposal type: modify >> >>Policy term: permanent >> >>Policy statement: >> >>Replace all instances of the word "ISP" in the NRPM with the word "LIR" >>and replace all instances of the phrase "LIR/ISP" with "LIR", except for >>the following: >> >>* Leave section 2.4 unchanged. >>* Leave section 2.7 unchanged. >>* In section 4.1.1, replace "ISPs" with "requesters". >>* In section 4.2, also remove "Internet Service Providers". >>* Leave section 6.2.4 unchanged. >>* Leave section 6.3.4 unchanged. >>* In section 6.9, replace "ISPs and LIRs" with "LIRs" for all three >>occurrence. >> >>Rationale: >> >>The NRPM is inconsistent. The terms ISP and LIR are used >>interchangeably throughout the document, with the term ISP being >>predominant in the IPv4 sections and the term LIR being predominant in >>the IPv6 sections. >> >>The use of the term ISP poses two different problems: >> >>1) The term has meaning outside of ARIN's policy. Multiple discussions >> on PPML have degenerated over people arguing what an ISP is with >> regards to policy when the reality is that the relationship is >> defined in the NRPM. As LIR has no meaning outside of policy >> this confusion will be removed. >> >>2) The other four RIRs have standardized on LIR. This change will make >> it easier for those doing business with more than one LIR to use >> consistent terms. >> >>This change does not alter any policy, it merely makes the policy easier >>to understand. >> >>Timetable for implementation: immediate >> >>_______________________________________________ >>PPML >>You are receiving this message because you are subscribed to the ARIN Public Policy >>Mailing List (PPML at arin.net). >>Unsubscribe or manage your mailing list subscription at: >>http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services >>Help Desk at info at arin.net if you experience any issues. >> > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From info at arin.net Tue Aug 28 10:55:14 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:55:14 -0400 Subject: [ppml] Policy Proposal: IPv6 Policy Housekeeping - AC postponed decision In-Reply-To: <46C5E767.6010406@arin.net> References: <46C5E767.6010406@arin.net> Message-ID: <46D43752.1070101@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) postponed their decision regarding "IPv6 Policy Housekeeping" in order to work with the author on possible revisions. The AC will make their decision to accept or not accept the proposal as a formal policy proposal at a special AC meeting on 30 August 2007. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/submission_archive.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as a formal policy proposal as written. If the > AC accepts the proposal, it will be posted as a formal policy proposal > to PPML and it will be presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The AC > will work with the author to clarify, combine or divide the proposal. At > their following meeting the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision. If a proposal is not accepted, then > the author may elect to use the petition process to advance their > proposal. If the author elects not to petition or the petition fails, > then the proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: IPv6 Policy Housekeeping > > Author: Leo Bicknell > > Proposal Version: 1.0 > > Submission Date: 8/17/2007 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Change A: > > Remove the text between the section 6 header and the section 6.1 > header. Remove section 6.1 entirely. Update all subsequent > sections to have new section numbers (6.[n-1]). > > Change B: > > Move the image in section 6.2 to section 2. > > Remove sections 6.2.1 to 6.2.6. > > Change C: > > Move section 6.2.7 to (new) section 2.8, subheading "IPv6". > > Create section 2.8, subheading "IPv4", containing the following text: > > In IPv4, utilization is the percentage of the address space > allocated or assigned relative to the total address space. > > Change D: > > Move section 6.2.8 to (new) section 2.8. > Move section 6.2.9 to (new) section 2.9. > > As this leaves section 6.2 empty, remove section 6.2. Update > all subsequent sections to have new section numbers (6.[n-1]). > > > Change E: > > Remove section 6.3. Update all subsequent sections to have new > section numbers (6.[n-1]). > > Change F: > > Remove section 6.4.1. Update all subsequent sections to have new > section numbers (6.4.[n-1]). > > Change G: > > Remove section 6.4.2. Update all subsequent sections to have new > section numbers (6.4.[n-1]). > > Change H: > > Remove section 6.4.4. > > Change I: > > In section 6.5.1.1.d, replace the existing statement with the new > statement: > > "be an existing, known ISP in the ARIN region or have a plan for > making at least 200 end-site assignments to other organizations > within 5 years." > > Change J: > > Remove section 6.5.3 entirely. Update all subsequent sections to > have new section numbers (6.5.[n-1]). > > Replace part of the text as (new) section 6.5.4.4: > > "All /56 and larger assignments to end sites are required to be > registered either by the LIR or its subordinate ISPs in > such a way that the RIR/NIR can properly evaluate the > HD-Ratio when a subsequent allocation becomes necessary." > > Change K: > > Section 6.5.8.2, add the following sentence to the end of the first > paragraph: > > "An HD-Ratio of .94 must be met for all assignments larger than > a /48." > > Add to the end of the second paragraph: > > "This reservation may be assigned to other organizations > later, at ARIN's discretion." > > Change L: > > Section 6.5.8.3, add a sentence between the two existing sentences: > > "Justification will be determined based on the .94 HD-Ratio > metric." > > Change M: > > Remove section 6.6. Update all subsequent sections to have new > section numbers (6.[n-1]). > > Change N: > > Change the title of section 6.7 from "Appendix A: HD-Ratio" to > "HD-Ratio". > > Change O: > > Remove section 6.8. Update all subsequent sections to have new > section numbers (6.[n-1]). > > Rationale: > > When the IPv6 policy was passed, it was considered to be an "interim" > policy, and it was intended to be similar in all 5 RIR's. Since that > time it has become clear the policy is no longer interim (and proposal > 2007-4 was passed to change just that) and it has also been modified > separately in the different RIR's. > > It was brought to the ARIN AC's attention that there were a number of > problems with "Section 6" of the NRPM as a result of this legacy: > > * The policy contained a large number of items that were not policy. > * The policy contained a few items that were self contradictory. > * The added text was redundant in some cases with existing text. > * The policy was overly vague in a few areas, leaving ARIN staff to > have to make interpretations of what the policy intended. > * Policy changes made since the initial IPv6 policy was adopted have > not always updated all of the relevant sections due to the complexity > of section 6. > > The intent of these changes is not to change any existing policy, but > rather to remove all non-policy items, and update any ambiguous items > with the way that ARIN staff is currently interprets the policy. > > Change A: > > Not policy. Unnecessary. Confusing (policy is interim). > > Change B: > > Sections 6.2.1 to 6.2.6 are definitions that are already defined in > section 2.1 to 2.7 Repeating them here is unnecessary. The picture > is useful though, and should be moved to section 2 as part of the > definitions. > > Change C: > > This is a definition item, and should be in the definition section. > Also, the v4 versions should be defined at the same time. > > Change D: > > These are both definitions that should be in the definitions section. > > Change E: > > This is a manifesto, and is not address policy. If anything these > belong is ARIN's mission statement. > > Change F: > > Not policy; covered by the RSA as a legal matter. > > Change G: > > Not policy. A darn good warning though ARIN should include with > any other boilerplate when issuing address space. > > Change H: > > Not policy, and covered by actual policy statement 6.5.1.2. > > Change I: > > Proposal 2005-8 amended section 6.5.4.1 to allow /56 and /64 > allocations, but section 6.5.1.1.d was never updated to match > the change. It is believed the intent of the policy, and ARIN > staff's current interpretation of the policy match the updated > text. > > Change J: > > The first part is not policy, and incorrectly states there is no > policy as section 6.5.4 has the policy in it. Take the one useful > part and make it part of the 6.5.4 criteria. > > Change K: > > No metric is currently listed to justify a larger initial > assignment. It is believed ARIN staff is currently applying > the HD-Ratio similar to the ISP policy, this puts that in writing. > > Make it clear that the reservation may not exist in perpetuity. > > Change L: > > No metric is given to justify additional assignments. It is > believed that ARIN staff is currently applying the HD_Ratio > similar to the ISP policy, this puts that in writing. > > Change M: > > References, while useful on the web page and in template instructions > are not policy. > > Change N: > > It's not an appendix. It's not even at the end. > > Change O: > > The background information would be something nice to archive on the > ARIN web site somewhere, but is not policy and should be removed from > the policy manual. > > Timetable for implementation: Immediate. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From info at arin.net Tue Aug 28 10:56:03 2007 From: info at arin.net (Member Services) Date: Tue, 28 Aug 2007 10:56:03 -0400 Subject: [ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses - AC did not accept In-Reply-To: <46C9A533.5090808@arin.net> References: <46C9A533.5090808@arin.net> Message-ID: <46D43783.9070205@arin.net> On 23 August 2007, the ARIN Advisory Council (AC) concluded its review of the proposed policy 'Decreasing Exponential Rationing of IPv4 IP Addresses' and did not accept it as a formal policy proposal. The AC did not accept the proposal because it presents an approach, rather than defines a policy. There are no details around how or where it adds to, or alters, the current version of the NRPM. During the initial review period the AC may decide to: 1) Accept the proposal as a formal policy proposal as written. 2) Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. 3) Not accept the policy proposal. In the event that the AC decides not to accept the proposal, then the author may elect to use the petition process to advance the proposal. For petition details see the section called "Petition Process" in the ARIN Internet Resource Policy Evaluation Process which can be found at: http://www.arin.net/policy/irpep.html The deadline for the author to initiate a petition per the ARIN Internet Resource Policy Evaluation Process is 40 days prior to the meeting; the petition deadline for the ARIN XX Public Policy Meeting is 23:59 EDT, 7 September 2007. If the author chooses not to petition or the petition is unsuccessful, then the proposed policy is closed. If a petition is successful, then the proposal will be numbered and posted for discussion and presented at ARIN's Public Policy Meeting. Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as a formal policy proposal as written. If the > AC accepts the proposal, it will be posted as a formal policy proposal > to PPML and it will be presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The AC > will work with the author to clarify, combine or divide the proposal. At > their following meeting the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision. If a proposal is not accepted, then > the author may elect to use the petition process to advance their > proposal. If the author elects not to petition or the petition fails, > then the proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Decreasing Exponential Rationing of IPv4 IP Addresses > > Author: Dean Anderson > > Proposal Version: 1 > > Submission Date: 8/18/07 > > Proposal type: new > > Policy term: renewable > > Policy statement: > > ARIN will ration the remaining available IP Address Space according to a > decreasing exponential function in the family of e^(-x), where the > ultimate function and factors are chosen to ensure that the remaining IP > address space lasts for at least 10 years. > This function will be used to limit the IP Address space allocations. > If IP Address Space becomes available (e.g. via return), the ration can > be recalculated. However, Ration calculations will not be based on > projected or anticipated returns. Contested IP Address Space will also > be excluded from the amount of available Address Space for ration > calculations. > > Rationale: > > Two reports[1,2] project that IP Addresses will be exhausted around > March 2010. > > * Both reports agree that if IP Addresses continue to delegated at the > present rates, we will run out of space in March 2010. > > * Everyone seems to agree that depletion will be a very bad event. > > * It is therefore imperative to begin rationing to slow down the rate of > new delegations to conserve the available address space. > > * It is necessary to do this now. One can't start rationing after the > resources run out. > > Sudden IPv4 IP Address Exhaustion is expected to cause sudden disruption > and discontinuity in business operations and planning. As with other > limited resources, the mere anticipation of exhaustion will lead to > hoarding and other behaviors that increase the harm of a sudden exhaustion. > > Rationing on a decreasing exponential will essentially prevent total > exhaustion and will gradually decrease the rate of IP Address delegation > so to alleviate the harms of a sudden stop in IP Address delegation. > > Prevention of IPv4 IP Address Exhaustion will help ensure a smooth > transition to IPV6. > > Rationing helps ensures that IP Address space remains available to > future needs. > > > [1] http://www.potaroo.net/tools/ipv4/index.html > [2] http://www.tndh.net/~tony/ietf/ipv4-pool-combined-view.pdf > > Timetable for implementation: Immediate > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. >