From info at arin.net Mon Jul 9 11:46:20 2007 From: info at arin.net (Member Services) Date: Mon, 09 Jul 2007 11:46:20 -0400 Subject: Policy Proposal: Authentication of Legacy Resources In-Reply-To: <20070706163335.831.qmail@hoster908.com> References: <20070706163335.831.qmail@hoster908.com> Message-ID: <4692584C.6040509@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 AC will review this proposal and may decide to: 1. Accept the proposal as a formal policy proposal as it is presented; 2. Work with the author to: a) clarify the language or intent of the proposal; b) divide the proposal into two (2) or more proposals; or c) combine the proposal with other proposals; or, 3. Not accept the proposal as a formal policy proposal. The AC will review this proposal at their next regularly scheduled meeting. If the AC accepts the proposal, then it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. If the AC does not accept the proposal, then the AC will explain that decision; and at that time 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 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/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Andrew Dul wrote: > I've been working on this policy with a few people from the AC for a couple of months. Given today's discussion on the PPML, it seemed like an appropriate time to submit it to the policy process. > > ============== > > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 > 1. Policy Proposal Name: Authentication of Legacy Resources > 2. Author > a. name: Andrew Dul > b. email: andrew.dul at quark.net > c. telephone: +1 206-359-8130 > d. organization: Perkins Coie LLP > 3. Proposal Version: 1.0 > 4. Submission Date: 07012007 > 5. Proposal type: New > 6. Policy term: Permanent > 7. Policy statement: > > Add new NRPM section 4.9 - Legacy Records > > Legacy resource record holders shall be permitted to sign an registration services agreement which permits the organization which is currently using the resources as of January 1, 2007 to continue to use those resources as long as a registration services agreement is signed by the organization and the organization is not past-due on their annual maintenance fee. ARIN will evaluate and verify the chain of custody of any resource records prior to executing a registration services agreement with an organization. > > If a legacy resource holder requests additional IPv4 resources all IPv4 resources (legacy and non-legacy) shall be evaluated to determine utilization for additional assignments under NRPM sections 4.2 or 4.3. > > ARIN shall use all reasonable methods to attempt to contact legacy record holders starting on January 1, 2008. > > ARIN shall also post information on the public website regarding this outreach to legacy resource holders. > > No changes shall be made to legacy resource records which are not covered by a registration services agreement after December 31, 2007. > > Add new NRPM section 7.3 - Legacy Reverse Delegation Records > > Legacy IP address record holders who have not signed a registration services agreement with ARIN will have their name server delegations for the in-addr.arpa zone removed starting on June 30, 2009. All name server delegations shall be removed from the in-addr.arpa zone by December 31, 2009. > > If an individual contacts ARIN and claims to represent a legacy record holder after the removal of an organization's name server delegations, the individual shall be permitted to request a one-time 6 month reinstatement of their name server delegations. This 6 month period is intended to allow an organization to work in good faith to establish a registration services agreement. > > 8. Rationale: > > An ARIN Legacy resource holder is an organization which was issued number resources prior to the formation of ARIN and whose registration information was not transferred to another RIR through the Early Registration Transfer Project (http://www.arin.net/registration/erx). Legacy resource holders were issued number resources through an informal process. This policy proposal attempts to bring these legacy resource holders into a formal agreement with ARIN, the manager of the IP numbering resources for many of the legacy record holders. > > Some legacy resource holders have expressed concerns about committing to a registration services agreement when the legacy resource holder cannot be assured that they will be permitted to retain and their resources for the long-term. This policy proposal also does not preclude existing legacy space holders, who may have signed another version of the registration services agreement from having the same commitment level. It is suggested that the Board of Trustees formalize the annual maintenance fees for legacy resource holders at a level similar to the $100 USD per year for end-sites. > > This policy sets in place a notification period of 18 months to contact all legacy resource holders and creates an incentive for the holders to formalize their relationship with ARIN. The dates in this policy proposal were arbitrarily chosen based upon an expected ratification by the ARIN Board of Trustees by December 31, 2007. If this policy is implemented after December 31, 2007, the trigger dates in the policy should be adjusted appropriately. > > Given the informal relationship under which the resources were granted, ARIN current maintains the records including WHOIS and in-addr.arpa delegations in a best-effort fashion. Many believe that ARIN may not be obligated to maintain these records. ARIN has experienced some difficulty maintaining these records. Legacy records have been a popular target for hijackers, in part due to the out of date information contained in these records. Having up to date contact information would assist ARIN and ISP's in insuring the stability of the Internet. > > This policy proposal sets a termination date for in-addr.arpa delegation services for legacy resource record holders who have not formalized their relationship with ARIN through a registration services agreement. The 6 month period of delegation record removal was intended to provide ARIN the flexibility of removing the records on a gradual plan during second half of 2009 and to avoid a large change on a single day. > > Legacy resource holders who sign a registration services agreement would continue to receive all the services that are currently provided by ARIN plus they would be eligible for any future services that ARIN may offer, such as cryptographic signing of resource records. > > 9. Timetable for implementation: As stated in policy > 10. Meeting presenter: Andrew Dul > > END OF TEMPLATE > _______________________________________________ > 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 Jul 11 15:19:10 2007 From: info at arin.net (Member Services) Date: Wed, 11 Jul 2007 15:19:10 -0400 Subject: ARIN XX Registration Now Open Message-ID: <46952D2E.9000206@arin.net> ARIN invites you to join us 17-19 October 2007 in Albuquerque, New Mexico for the ARIN XX Public Policy and Members Meeting. The meeting will be held back-to-back with NANOG 41 at the Hyatt Regency Albuquerque. Previous back-to-back meetings have proven to be excellent opportunities for involvement in both organizations and we look forward to even greater success and participation this fall. Registration for ARIN XX is now open. Meeting information is available at http://www.arin.net/ARIN-XX/. The special room rate of $158 single/double occupancy is available for reservations made on or before 24 September 2007. Reserve your room now as space may be limited. ARIN holds open, biannual Public Policy and Members Meetings, providing an opportunity for the entire Internet community to contribute to Internet number resource policy discussions and development, network with colleagues, and attend workshops and tutorials. Community participation is the basis of the ARIN policy development process and current policy proposals up for discussion at this meeting are available at: http://www.arin.net/policy/proposals/proposal_archive.html ARIN XX Overview * Sunday, 14 October - NANOG and ARIN are excited to jointly offer a day of workshops and tutorials on a variety of IPv6 topics -- more details coming soon! * Tuesday, 16 October - Evening Open Policy Hour, First Timer Luncheon * Wednesday, 17 October - ARIN Public Policy Meeting, Day 1, evening ARIN Social * Thursday, 18 October - ARIN Public Policy Meeting, Day 2 * Friday, 19 October - ARIN Members Meeting (open to all ARIN XX attendees) Additional agenda details and more information about ARIN XX will be posted to our website as we get closer to the meeting, so check back often! Regards, Member Services Department American Registry for Internet Numbers From info at arin.net Thu Jul 19 14:27:08 2007 From: info at arin.net (Member Services) Date: Thu, 19 Jul 2007 14:27:08 -0400 Subject: Deadline for Policy Proposals - 18 August 2007 Message-ID: <469FACFC.3010702@arin.net> The ARIN XX Public Policy Meeting will take place 17-18 October 2007 in Denver. 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 Thu Jul 19 15:44:43 2007 From: info at arin.net (Member Services) Date: Thu, 19 Jul 2007 15:44:43 -0400 Subject: ARIN Opens IPv6 Wiki Site Message-ID: <469FBF2B.6030406@arin.net> As directed by the ARIN Board of Trustees in its 7 May 2007 IPv6 resolution (http://www.arin.net/announcements/20070521.html), ARIN continues to look for ways to assist the community by providing education and outreach on migration to IPv6. Today ARIN opens a new wiki-based site as an open forum for the ARIN community. All interested individuals in the community are invited to use the site, at http://www.getipv6.info, to post information they believe may be helpful to others looking at implementations or migrations of networks to IPv6. This can include recommended practices, success stories, case studies, and general information on using IPv6 in the ARIN region. The intent is to create a site that is useful and relevant, particularly to those involved with IPv6 within the ARIN region, by taking advantage of the incredible range of knowledge available in the ARIN community. As is the case with all wiki-based websites, this site will be an open and organic repository of information. What appears on the site will be up to the community, with only minimal involvement by ARIN staff. To help begin and frame the focus of the site, some relevant links back to ARIN's main website have been added, and general policies regarding acceptable use and privacy have been created and posted. Those unfamiliar with wiki-based websites should review the MediaWiki User's Guide at http://meta.wikimedia.org/wiki/MediaWiki_User's_Guide before getting started. As the site develops and grows, ARIN staff involvement will be limited to assisting or organizing navigation and highlighting specific content articles or categories. Individuals with questions or suggestions about this site may send them to webmaster at arin.net. ARIN looks forward to the community taking this small "seed" and developing it into a resource that has value to everyone. Regards, Member Services Department American Registry for Internet Numbers (ARIN) From info at arin.net Thu Jul 19 17:07:18 2007 From: info at arin.net (Member Services) Date: Thu, 19 Jul 2007 17:07:18 -0400 Subject: Deadline for Policy Proposals - 18 August 2007 In-Reply-To: <469FACFC.3010702@arin.net> References: <469FACFC.3010702@arin.net> Message-ID: <469FD286.2090202@arin.net> Correction. The ARIN XX Public Policy Meeting will take place 17-18 October 2007 in Albuquerque. Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > The ARIN XX Public Policy Meeting will take place 17-18 October 2007 in > Denver. 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) > > > > > _______________________________________________ > 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 Fri Jul 20 10:48:22 2007 From: info at arin.net (Member Services) Date: Fri, 20 Jul 2007 10:48:22 -0400 Subject: Policy Proposal: Global Policy for the Allocation of the Remaining IPv4 Address Space Message-ID: <46A0CB36.7050201@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: 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 Version: v1 Submission Date: 07/17/2007 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 Fri Jul 20 15:50:27 2007 From: info at arin.net (Member Services) Date: Fri, 20 Jul 2007 15:50:27 -0400 Subject: ARIN Community Consultation - Participation Details Message-ID: <46A11203.8070505@arin.net> On Monday, 23 July, ARIN will open a community consultation following the guidelines in the ARIN Consultation and Suggestion Process. There will be one week of discussion followed by polling. The subject is improvements to ARIN WHOIS Directory Service. Consult at arin.net, an open and archived mailing list, will host the public discussion. Only list subscribers will be eligible to participate in the discussion and polling. Poll results will be publicly available and will be used by the ARIN President to help determine what course of action, if any, ARIN should take regarding the subject. The ACSP documentation is available at: http://www.arin.net/about_us/corp_docs/acsp.html Details on how to subscribe to consult at arin.net are available at: http://lists.arin.net/mailman/listinfo/consult We welcome community-wide participation. Please address any questions to info at arin.net. Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Fri Jul 20 17:44:52 2007 From: info at arin.net (Member Services) Date: Fri, 20 Jul 2007 17:44:52 -0400 Subject: Mailing List Syndication Message-ID: <004501c7cb17$348b4fe0$528888c0@arin.net> ARIN is now offering a Really Simple Syndication (RSS) feed of its Public Policy Mailing List (PPML) to make it easier for the community to follow the discussions about Internet number resource policy in the ARIN region. There are two feeds available; one contains all postings to PPML, while the second one contains only ARIN announcements to the list. ARIN announcements to the list include announcements of new policy proposals, the status of proposals as they make their way through the Internet Resource Policy Evaluation Process (IRPEP), and policy implementation announcements. Both of the feeds will be updated every time a message is submitted to the mailing list.. Information about these new feeds, and the existing RSS feed of all website announcements, is available at http://www.arin.net/rss.html. The RSS feed of all posts to PPML is available at http://lists.arin.net/pipermail/ppml/rss.xml The RSS feed of just ARIN announcements to PPML is available at http://lists.arin.net/pipermail/info/rss.xml ARIN hopes this effort proves useful to the community and feedback about this offering or suggestions on other methods of bringing content to the community are welcome at webmaster at arin.net. Regards, Member Services Department American Registry for Internet Numbers (ARIN) From info at arin.net Mon Jul 23 11:04:54 2007 From: info at arin.net (Member Services) Date: Mon, 23 Jul 2007 11:04:54 -0400 Subject: Call for Consultation: ARIN WHOIS Directory Services Message-ID: <46A4C396.3040006@arin.net> ARIN received a suggestion to allow CIDR style queries to the ARIN WHOIS directory service. In addition to this enhancement, ARIN would like to explore other possible modifications that the community desires. ARIN requests that you provide specific feedback as to what additional WHOIS enhancements would benefit you and why they are needed. Please submit your suggestions and feedback to the consult at arin.net. You can subscribe to the arin-consult mailing list at http://lists.arin.net/mailman/listinfo/consult. Discussion on consult at arin.net will close at noon ET 27 July. A poll on the topic will be conducted beginning Tuesday, 31 July. Only subscribers on the consult at arin.net list when the poll opens will be eligible to participate. Poll results will be publicly available and will be used by the ARIN President to help determine what course of action, if any, ARIN should take regarding the subject. The ARIN Consultation and Suggestion Process documentation is available at: http://www.arin.net/about_us/corp_docs/acsp.html We welcome community-wide participation. Please address any process questions to info at arin.net. Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Tue Jul 24 14:45:17 2007 From: info at arin.net (Member Services) Date: Tue, 24 Jul 2007 14:45:17 -0400 Subject: Policy Proposal: Global Policy for the Allocation of the Remaining IPv4 Address Space In-Reply-To: <46A0CB36.7050201@arin.net> References: <46A0CB36.7050201@arin.net> Message-ID: <46A648BD.7030601@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 Matt Pounsett and Bill Darte. 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: 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 Version: v1 > > Submission Date: 07/17/2007 > > 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. > > > > _______________________________________________ > 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 Tue Jul 24 14:56:12 2007 From: info at arin.net (Member Services) Date: Tue, 24 Jul 2007 14:56:12 -0400 Subject: Policy Proposal: IPv4 Soft Landing In-Reply-To: <464425E7.1070305@arin.net> References: <464425E7.1070305@arin.net> Message-ID: <46A64B4C.1070002@arin.net> On 19 July 2007, the ARIN Advisory Council (AC) postponed their decision regarding the proposal titled "IPv4 Soft Landing" in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At the next regularly scheduled AC meeting, the AC will make their decision to accept or not accept the proposal as a formal policy proposal. 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) > ## * ## > > > Policy Proposal Name: IPv4 Soft Landing > > Author: David Conrad > > Proposal Version: 1.0 > > Submission Date: 2007-05-02 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > 30 days after specified thresholds in the amount of address space > remaining in the IANA IPv4 free pool are crossed, the requirements > necessary for ISPs to obtain additional IPv4 address space are made > more stringent and requesters must demonstrate efforts both to utilize > scarce IPv4 address space more efficiently, set up IPv6 infrastructure > services, and eventually offer production IPv6 connectivity. > > The proposed thresholds and the requirements to justify an allocation > of new IPv4 address space from ARIN are: > > Phase 0 > Threshold N/A > Requirements > > Requesters must demonstrate: > > * No requirements to document IPv6 infrastructure services or IPv6 > connectivity services. > > * 80% utilization in all customer assignments as reflected in > SWIP/rwhois reassignments > > * Downstream immediate requirement: 25% > > * Downstream requirement after 1 year: 50% > > Phase 1 > Threshold 40 /8s > Requirements: > > Requesters must demonstrate: > > * Documented plans for availability of production IPv6 infrastructure > services within 6 months > > * Documented plans for availability of production IPv6 service within > 1 year > > * 85% utilization in all customer assignments as reflected in > SWIP/rwhois reassignments > > * Downstream immediate requirement: 33% > > * Downstream requirement after 1 year: 66% > > Phase 2 > Threshold 30 /8s > Requirements: > > Requesters must demonstrate: > > * Documented availability of production IPv6 infrastructure services > > * Documented plans for availability of production IPv6 service within > 6 months > > * 90% utilization in all customer assignments as reflected in > SWIP/rwhois reassignments > > * Current 3rd-party auditors report of IPv4 address space utilization > > * Downstream immediate requirement: 50% > > * Downstream requirement after 1 year: 75% > > Phase 3 > Threshold 20 /8s > Requirements: > > Requesters must demonstrate: > > * Documented availability of production IPv6 infrastructure services > > * Documented availability of production IPv6 connectivity service > > * A migration plan for all internal infrastructure to either IPv6 or > private addressing > > * 92% utilization in all customer assignments as reflected in > SWIP/rwhois reassignments > > * Current 3rd-party auditors report of IPv4 address space utilization > > * Downstream immediate requirement: 60% > > * Downstream requirement after 1 year: 80% > > Phase 4 > Threshold 15 /8s > Requirements: > > Requesters must demonstrate: > > * Documented availability of production IPv6 connectivity services > > * Initiation of migration of internal infrastructure to either IPv6 or > private addressing > > * 94% utilization in all customer assignments as reflected in > SWIP/rwhois reassignments > > * Current 3rd-party auditors report of IPv4 address space utilization > > * Downstream immediate requirement: 70% > > * Downstream requirement after 1 year: 85% > > Internal infrastructure can be used in justification for IPv4 address > space only in special circumstances > > Phase 5 > Threshold 10 /8s > Requirements: > > Requesters must demonstrate: > > * Documented availability of production IPv6 connectivity services > > * Recycling of 25% of (non-private) IPv4 address space formerly used > for internal infrastructure > > * 96% utilization in all customer assignments as reflected in > SWIP/rwhois reassignments > > * Current 3rd-party auditors report of IPv4 address space utilization > > * Downstream immediate requirement: 75% > > * Downstream requirement after 1 year: 90% > > Internal infrastructure can no longer be used in justification for > IPv4 address space > > Phase 6 > Threshold 5 /8s > Requirements: > > Requesters must demonstrate: > > * Documented availability of production IPv6 connectivity services > > * Recycling of 75% of IPv4 address space formerly used for internal > infrastructure > > * 98% utilization in all customer assignments as reflected in > SWIP/rwhois reassignments > > * Current 3rd-party auditors report of IPv4 address space utilization > > * Downstream immediate requirement: 80% > > * Downstream requirement after 1 year: 95% > > Internal infrastructure can no longer be used in justification for > IPv4 address space > > Note that for the purposes of this proposal, the following definitions > apply: > > * Downstream: entities to which the ISP may assign address space. > > * IPv6 infrastructure services: services such as DNS, WWW, FTP, > etc. accessible via IPv6. > > * IPv6 connectivity: IP connectivity service provided over IPv6 > transport, either natively or via an IPv6 tunnel. > > * Internal infrastructure: routers, switches, servers, etc., that are > not normally visible or directly accessed by the ISP customers. > > Phase 0 reflects current allocation requirements. Subsequent phases > of this policy 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. > > Rationale: > > The rationale for this proposal is threefold: > > * to prolong the availability of IPv4 addresses to 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 making the allocation of IPv4 both more difficult and > contingent on the ISP demonstrating both support for IPv6 as well as > more efficient use of the IPv4 address space they administer. 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 reuse of > 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 utilization of customer > 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 breaking 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. > > The requirement to provide a current third-party auditors report of > utilization is intended to deter fraudulent justification data used to > support IPv4 allocations in the absence of actual need. > > 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. This policy anticipates ARIN staff will make use of > auditor reports to verify appropriate use of IPv4 addresses in > internal infrastructure. > > 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 their 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. > > Timetable for implementation: > > Immediately upon approval of this policy by the ARIN Board of Trustees. > > > > _______________________________________________ > 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 Tue Jul 24 15:01:43 2007 From: info at arin.net (Member Services) Date: Tue, 24 Jul 2007 15:01:43 -0400 Subject: Policy Proposal: Legacy Outreach and Partial Reclamation In-Reply-To: <46851DF7.8020106@arin.net> References: <371EB4EE-C2FE-46CD-BAF9-DB35937B572A@delong.com> <46851DF7.8020106@arin.net> Message-ID: <46A64C97.1050604@arin.net> On 19 July 2007, the ARIN Advisory Council (AC) postponed their decision regarding the proposal titled "Legacy Outreach and Partial Reclamation" in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At the next regularly scheduled AC meeting, the AC will make their decision to accept or not accept the proposal as a formal policy proposal. 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) > ## * ## > > > Owen DeLong wrote: > >>Here's an attempt to partially drain the swamp and create some >>incentives >>for legacy holders to both return available IPv4 space and start using >>IPv6. >> >>Comments welcome. >> >>Owen >> >> >>Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 >> >> >>Policy Proposal Name: Legacy Outreach and Partial Reclamation >>Author >> name: Owen DeLong >> email: owen at delong.com >> telephone: 408-921-6984 >> organization: JITTR Networks >> >>Proposal Version: 0.0.1 >>Submission Date: 2007 April 22 >>Proposal type: M >> new, modify, or delete. >>Policy term: permanent >> temporary, permanent, or renewable. >>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 >> >>Meeting presenter: >> >> TBD, probably Owen DeLong >> >>END OF TEMPLATE >>_______________________________________________ >>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 >> > > > > _______________________________________________ > 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 Tue Jul 24 15:56:21 2007 From: info at arin.net (Member Services) Date: Tue, 24 Jul 2007 15:56:21 -0400 Subject: Policy Proposal 2007-14: Resource Review Process Message-ID: <46A65965.6070108@arin.net> On 19 July 2007, the ARIN Advisory Council (AC) concluded their initial review of "Resource Review Process" and accepted it as a formal policy proposal for discussion by the community. The AC accepted the revised version of this proposal which was posted to PPML on 17 July 2007. The revised version included changing the name of the proposal from "Reclamation of Number Resources" to "Resource Review Process". The proposal is designated Policy Proposal 2007-14: Resource Review Process. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_14.html All persons in the community are encouraged to discuss Policy Proposal 2007-14 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-14 Resource Review Process Author: Owen DeLong, Stephen Sprunk Proposal type: modify Policy term: permanent Policy statement: Add the following to the NRPM: Resource Review 1. ARIN may review the current usage of any resources issued by ARIN to an organization. The organization shall furnish whatever records are necessary to perform this review. 2. ARIN may conduct such reviews: a. when any new resource is requested, b. whenever ARIN has cause to believe that the resources had originally been obtained fraudulently, or c. at any other time without cause unless a prior review has been completed in the preceding 12 months. 3. ARIN shall communicate the results of the review to the organization. 4. If the review shows that existing usage is substantially not in compliance with current allocation and/or assignment policies, the organization shall return resources as needed to bring them substantially into compliance. If possible, only whole resources shall be returned. Partial address blocks shall be returned in such a way that the portion retained will comprise a single aggregate block. 5. If the organization does not voluntarily return resources as required, ARIN may revoke any resources issued by ARIN as required to bring the organization into overall compliance. ARIN shall follow the same guidelines for revocation that are required for voluntary return in the previous paragraph. 6. Except in cases of fraud, an organization shall be given a minimum of six months to effect a return. ARIN shall negotiate a longer term with the organization if ARIN believes the organization is working in good faith to substantially restore compliance and has a valid need for additional time to renumber out of the affected blocks. 7. ARIN shall continue to maintain the resource(s) while their return or revocation is pending, except no new maintenance fees shall be assessed for the resource(s). 8. Legacy resources in active use, regardless of utilization, are not subject to revocation by ARIN. However, the utilization of legacy resources shall be considered during a review to assess overall compliance. Delete NRPM sections 4.1.2, 4.1.3, 4.1.4 Remove the sentence "In extreme cases, existing allocations may be affected." from NRPM section 4.2.3.1. Policy Rationale Rationale: ARIN feels that current policy does not give them the power to review or reclaim resources except in cases of fraud, despite this being mentioned in the Registration Services Agreement. This policy proposal provides clear policy authority to do so, guidelines for how and under what conditions it shall be done, and a guarantee of a (minimum) six-month grace period so that the current user shall have time to renumber out of any resources to be reclaimed. The nature of the "review" is to be of the same form as is currently done when an organization requests new resources, i.e. the documentation required and standards should be the same. The renumbering period does not affect any "hold" period that ARIN may apply after return or revocation of resources is complete. The deleted sections/text would be redundant with the adoption of this proposal. Timetable for implementation: Immediate From info at arin.net Tue Jul 24 15:56:49 2007 From: info at arin.net (Member Services) Date: Tue, 24 Jul 2007 15:56:49 -0400 Subject: Policy Proposal 2007-15: Authentication of Legacy Resources Message-ID: <46A65981.90004@arin.net> On 19 July 2007, the ARIN Advisory Council (AC) concluded their initial review of "Authentication of Legacy Resources" and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-15: Authentication of Legacy Resources. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_15.html All persons in the community are encouraged to discuss Policy Proposal 2007-15 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-15 Authentication of Legacy Resources Author: Andrew Dul Proposal type: New Policy term: Permanent Policy statement: Add new NRPM section 4.9 - Legacy Records Legacy resource record holders shall be permitted to sign an registration services agreement which permits the organization which is currently using the resources as of January 1, 2007 to continue to use those resources as long as a registration services agreement is signed by the organization and the organization is not past-due on their annual maintenance fee. ARIN will evaluate and verify the chain of custody of any resource records prior to executing a registration services agreement with an organization. If a legacy resource holder requests additional IPv4 resources all IPv4 resources (legacy and non-legacy) shall be evaluated to determine utilization for additional assignments under NRPM sections 4.2 or 4.3. ARIN shall use all reasonable methods to attempt to contact legacy record holders starting on January 1, 2008. ARIN shall also post information on the public website regarding this outreach to legacy resource holders. No changes shall be made to legacy resource records which are not covered by a registration services agreement after December 31, 2007. Add new NRPM section 7.3 - Legacy Reverse Delegation Records Legacy IP address record holders who have not signed a registration services agreement with ARIN will have their name server delegations for the in-addr.arpa zone removed starting on June 30, 2009. All name server delegations shall be removed from the in-addr.arpa zone by December 31, 2009. If an individual contacts ARIN and claims to represent a legacy record holder after the removal of an organization's name server delegations, the individual shall be permitted to request a one-time 6 month reinstatement of their name server delegations. This 6 month period is intended to allow an organization to work in good faith to establish a registration services agreement. Policy Rationale An ARIN Legacy resource holder is an organization which was issued number resources prior to the formation of ARIN and whose registration information was not transferred to another RIR through the Early Registration Transfer Project (http://www.arin.net/registration/erx). Legacy resource holders were issued number resources through an informal process. This policy proposal attempts to bring these legacy resource holders into a formal agreement with ARIN, the manager of the IP numbering resources for many of the legacy record holders. Some legacy resource holders have expressed concerns about committing to a registration services agreement when the legacy resource holder cannot be assured that they will be permitted to retain and their resources for the long-term. This policy proposal also does not preclude existing legacy space holders, who may have signed another version of the registration services agreement from having the same commitment level. It is suggested that the Board of Trustees formalize the annual maintenance fees for legacy resource holders at a level similar to the $100 USD per year for end-sites. This policy sets in place a notification period of 18 months to contact all legacy resource holders and creates an incentive for the holders to formalize their relationship with ARIN. The dates in this policy proposal were arbitrarily chosen based upon an expected ratification by the ARIN Board of Trustees by December 31, 2007. If this policy is implemented after December 31, 2007, the trigger dates in the policy should be adjusted appropriately. Given the informal relationship under which the resources were granted, ARIN current maintains the records including WHOIS and in-addr.arpa delegations in a best-effort fashion. Many believe that ARIN may not be obligated to maintain these records. ARIN has experienced some difficulty maintaining these records. Legacy records have been a popular target for hijackers, in part due to the out of date information contained in these records. Having up to date contact information would assist ARIN and ISP's in insuring the stability of the Internet. This policy proposal sets a termination date for in-addr.arpa delegation services for legacy resource record holders who have not formalized their relationship with ARIN through a registration services agreement. The 6 month period of delegation record removal was intended to provide ARIN the flexibility of removing the records on a gradual plan during second half of 2009 and to avoid a large change on a single day. Legacy resource holders who sign a registration services agreement would continue to receive all the services that are currently provided by ARIN plus they would be eligible for any future services that ARIN may offer, such as cryptographic signing of resource records. Timetable for implementation: As stated in policy From info at arin.net Wed Jul 25 10:47:29 2007 From: info at arin.net (Member Services) Date: Wed, 25 Jul 2007 10:47:29 -0400 Subject: Policy Proposal: IANA Policy for Allocation of ASN Blocks to RIRs Message-ID: <46A76281.4030706@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: Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks to Regional Internet Registries Author: Axel Pawlik Proposal Version: 1 Submission Date: 24 July 2007 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 Fri Jul 27 12:30:31 2007 From: info at arin.net (Member Services) Date: Fri, 27 Jul 2007 12:30:31 -0400 Subject: WHOIS Enhancement Consultation Now Closed Message-ID: <46AA1DA7.4050704@arin.net> ARIN thanks the community for its input regarding the suggestion to allow CIDR style queries to the ARIN WHOIS directory services. Additional enhancements were suggested and will be reviewed. Given the nature of the feedback provided on the list, a subsequent polling is not necessary. ARIN staff will take all input under discussion and next week will report back to the community with its intended course of action regarding changes to ARIN WHOIS directory services. The archives of this discussion are available at: http://lists.arin.net/pipermail/consult/ Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Fri Jul 27 16:44:36 2007 From: info at arin.net (Member Services) Date: Fri, 27 Jul 2007 16:44:36 -0400 Subject: Policy Proposal: IANA Policy for Allocation of ASN Blocks to RIRs In-Reply-To: <46A76281.4030706@arin.net> References: <46A76281.4030706@arin.net> Message-ID: <46AA5934.4090806@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 Dan Alexander and Heather Schiller. 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: Internet Assigned Numbers Authority (IANA) Policy > for Allocation of ASN Blocks to Regional Internet Registries > > Author: Axel Pawlik > > Proposal Version: 1 > > Submission Date: 24 July 2007 > > 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 > > _______________________________________________ > 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 Jul 30 12:51:27 2007 From: info at arin.net (Member Services) Date: Mon, 30 Jul 2007 12:51:27 -0400 Subject: Policy Proposal: Definition of known ISP and changes to IPv6 initial allocation criteria Message-ID: <46AE170F.6010901@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: 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 From info at arin.net Mon Jul 30 13:23:53 2007 From: info at arin.net (Member Services) Date: Mon, 30 Jul 2007 13:23:53 -0400 Subject: Policy Proposal: PIv6 for legacy holders with RSA and efficient use Message-ID: <46AE1EA9.3010509@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: 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