From info at arin.net Tue May 1 15:11:35 2007 From: info at arin.net (Member Services) Date: Tue, 01 May 2007 15:11:35 -0400 Subject: Revised Policy Proposal Resource Reclamation In-Reply-To: References: Message-ID: <463790E7.7040807@arin.net> ARIN received the following policy proposal. The author withdrew the previous proposal; it is closed. In accordance with the ARIN Internet Resource Policy Evaluation Process, this 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) ## * ## Policy Proposal Name: Reclamation of Number Resources Author: Owen DeLong, Stephen Sprunk Proposal Version: 1.1 Submission Date: 4/30/07 Proposal type: modify Policy term: permanent Policy statement: Resource Reclamation 1. ARIN may review the current usage of any resources allocated or assigned 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 required to bring them into compliance. If an organization holds multiple ARIN delegations, they may return any number of whole delegations necessary to restore compliance. If an organization holds a single ARIN delegation, they shall return a single aggregate portion of the delegation to restore compliance. 5. If the organization does not voluntarily return resources as required, ARIN may revoke any resources as required to bring the organization into compliance. ARIN shall follow the same guidelines for revocation that are required for voluntary return in the previous paragraph. 6. Return or revocation of resources shall be immediate for billing purposes. 7. ARIN shall not issue any returned or revoked resources to another organization for a minimum of six months after reclamation. ARIN shall negotiate a longer term with the resource holder if ARIN believes the resource holder is working in good faith to restore compliance and has a valid need for additional time to renumber out of the affected blocks. 8. The whois database shall indicate that such blocks are scheduled for reclamation and shall display the date determined under the previous paragraph. Delete sections 4.1.2, 4.1.3, 4.1.4 Remove the sentence "In extreme cases, existing allocations may be affected." from section 4.2.3.1. Rationale: ARIN feels that current policy does not give them the power to audit 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 stop using any resources to be reclaimed. The deleted sections/text would be redundant with the adoption of this proposal. Timetable for implementation: Immediate From info at arin.net Fri May 4 12:49:01 2007 From: info at arin.net (Member Services) Date: Fri, 04 May 2007 12:49:01 -0400 Subject: ARIN XIX Meeting Report Now Available Message-ID: <463B63FD.20204@arin.net> The ARIN community recently concluded the ARIN XIX Public Policy and Members Meetings, held in San Juan, Puerto Rico, 22-25 April 2007. The meeting report includes presentations, summary notes, and transcripts of these meetings, and is now available on the ARIN website at: http://www.arin.net/meetings/minutes/ARIN_XIX/ In addition to these files, the page referenced will have links added to an archive of the meeting's webcast next week. We thank all in the community who participated either in person or remotely, and look forward to seeing you all again for ARIN XX in Albuquerque, New Mexico, 17-19 October 2007. Regards, Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Fri May 11 04:14:31 2007 From: info at arin.net (Member Services) Date: Fri, 11 May 2007 04:14:31 -0400 Subject: Policy Proposal: IPv4 Soft Landing Message-ID: <464425E7.1070305@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 their meeting is within ten days, then the review may be extended to the subsequent 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) ## * ## 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. From info at arin.net Fri May 18 10:16:35 2007 From: info at arin.net (Member Services) Date: Fri, 18 May 2007 10:16:35 -0400 Subject: Policy Proposal 2007-13: Removal of ISP Immediate Need from End-User Message-ID: <464DB543.1010107@arin.net> On 17 May 2007 the ARIN Advisory Council (AC) concluded its review of "Removal of ISP Immediate Need from End-User" and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2007-13: Removal of ISP Immediate Need from End-User. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2007_13.html All persons in the community are encouraged to discuss Policy Proposal 2007-13 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-13 Removal of ISP Immediate Need from End-User Author: Rob Seastrom, David Williamson, Owen DeLong Proposal Version: 0.1 Submission Date: 4/24/07 Proposal type: delete Policy term: permanent Policy statement: Delete section 4.3.4, which reads: 4.3.4. Additional considerations End-users may qualify for address space under other policies such as Immediate need [4.2.1.6] or Micro-allocation [4.4]. from the NRPM. Rationale: As discussed at ARIN XIX, section 4.3.4 creates a conflict with section 4.2.1.6 in that section 4.2.1.6 specifically excludes end users while section 4.3.4 is specifically for end users. Prior to the development of the multihoming policy for end users, the immediate need policy was required in order to support end users being able to get address space under some circumstances. The "immediate need" title is a misnomer as it is more an issue of "initial need without prior address utilization" than "immediate need". Such initial needs for end users are now addressed best through the multihoming policy. Timetable for implementation: immediate From info at arin.net Fri May 18 10:16:54 2007 From: info at arin.net (Member Services) Date: Fri, 18 May 2007 10:16:54 -0400 Subject: Policy Proposal: Reclamation of Number Resources In-Reply-To: <463790E7.7040807@arin.net> References: <463790E7.7040807@arin.net> Message-ID: <464DB556.7090600@arin.net> On 17 May 2007 the ARIN Advisory Council (AC) reviewed "Reclamation of Number Resources" and did not accept it at this time as a formal policy proposal. The AC will work with the author prior to taking further action. 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. The author withdrew the > previous proposal; it is closed. In accordance with the ARIN > Internet Resource Policy Evaluation Process, this 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) > > > ## * ## > > > Policy Proposal Name: Reclamation of Number Resources > > Author: Owen DeLong, Stephen Sprunk > > Proposal Version: 1.1 > > Submission Date: 4/30/07 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Resource Reclamation > > 1. ARIN may review the current usage of any resources allocated or > assigned 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 required to bring them into > compliance. If an organization holds multiple ARIN delegations, they > may return any number of whole delegations necessary to restore > compliance. If an organization holds a single ARIN delegation, they > shall return a single aggregate portion of the delegation to restore > compliance. > > 5. If the organization does not voluntarily return resources as > required, ARIN may revoke any resources as required to bring the > organization into compliance. ARIN shall follow the same guidelines > for revocation that are required for voluntary return in the previous > paragraph. > > 6. Return or revocation of resources shall be immediate for > billing purposes. > > 7. ARIN shall not issue any returned or revoked resources to > another organization for a minimum of six months after reclamation. > ARIN shall negotiate a longer term with the resource holder if ARIN > believes the resource holder is working in good faith to restore > compliance and has a valid need for additional time to renumber out > of the affected blocks. > > 8. The whois database shall indicate that such blocks are scheduled > for reclamation and shall display the date determined under the previous > paragraph. > > Delete sections 4.1.2, 4.1.3, 4.1.4 > > Remove the sentence "In extreme cases, existing allocations may be > affected." from section 4.2.3.1. > > Rationale: > > ARIN feels that current policy does not give them the power to audit > 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 stop using any resources to be reclaimed. > > The deleted sections/text would be redundant with the adoption of > this proposal. > > 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 Fri May 18 10:17:18 2007 From: info at arin.net (Member Services) Date: Fri, 18 May 2007 10:17:18 -0400 Subject: Policy Proposal: IPv4 Soft Landing In-Reply-To: <464425E7.1070305@arin.net> References: <464425E7.1070305@arin.net> Message-ID: <464DB56E.7030101@arin.net> On 17 May 2007 the ARIN Advisory Council (AC) reviewed "IPv4 Soft Landing" and did not accept it at this time as a formal policy proposal. The AC will work with the author prior to taking further action. 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 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 their meeting is within ten days, then the review may be > extended to the subsequent 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) > > > ## * ## > > > 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 Mon May 21 09:06:05 2007 From: info at arin.net (Member Services) Date: Mon, 21 May 2007 09:06:05 -0400 Subject: ARIN Board Advises Internet Community on Migration to IPv6 Message-ID: <4651993D.1020408@arin.net> ARIN and the other Regional Internet Registries have distributed Internet Protocol version 6, IPv6, alongside IPv4 since 1999. To date, ARIN has issued both protocol versions in tandem and has not advocated one over the other. ARIN has closely monitored trends in demand and distribution for both protocol versions with the understanding that the IPv4 available resource pool would continue to diminish. The available IPv4 resource pool has now been reduced to the point that ARIN is compelled to advise the Internet community that migration to IPv6 is necessary for any applications that require ongoing availability from ARIN of contiguous IP number resources. On 7 May 2007, the ARIN Board of Trustees passed the following resolution: RESOLUTION OF THE BOARD OF TRUSTEES OF ARIN ON INTERNET PROTOCOL NUMBERING RESOURCE AVAILABILITY WHEREAS, community access to Internet Protocol (IP) numbering Resources has proved essential to the successful growth of the Internet; and, WHEREAS, ongoing community access to Internet Protocol version 4 (IPv4) numbering resources can not be assured indefinitely; and, WHEREAS, Internet Protocol version 6 (IPv6) numbering resources are available and suitable for many Internet applications, BE IT RESOLVED, that this Board of Trustees hereby advises the Internet community that migration to IPv6 numbering resources is necessary for any applications which require ongoing availability from ARIN of contiguous IP numbering resources; and, BE IT ORDERED, that this Board of Trustees hereby directs ARIN staff to take any and all measures necessary to assure veracity of applications to ARIN for IPv4 numbering resources; and, BE IT RESOLVED, that this Board of Trustees hereby requests the ARIN Advisory Council to consider Internet Numbering Resource Policy changes advisable to encourage migration to IPv6 numbering resources where possible. Implementation of this resolution will include both internal and external components. Internally, ARIN will review its resource request procedures and continue to provide policy experience reports to the Advisory Council. Externally, ARIN will send progress announcements to the ARIN community as well as the wider technical audience, government agencies, and media outlets. ARIN will produce new documentation, from basic introductory fact sheets to FAQs on how this resolution will affect users in the region. ARIN will focus on IPv6 in many of its general outreach activities, such as speaking engagements, trade shows, and technical community meetings. For more information visit the IPv6 Information Center at: http://www.arin.net/v6/v6-info.html. Regards, Raymond A. Plzak President and CEO American Registry for Internet Numbers (ARIN)