Policy 2007-21: PIv6 for legacy holders with RSA and efficient use [Archived]

OUT OF DATE?

Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.

Status: Adopted - NRPM Section 6.5.8.1

Tracking Information

Discussion Tracking

Mailing List:

Formal introduction on PPML on 28 August 2007

Staff assessment - 14 October 2007
Last Call - 23 October through 6 November 2007
Remanded to AC - 11 December 2007
Revised - 11 March 2008
Staff Assessment - 21 March 2008
Last call - 14-29 April 2008Public Policy Mailing List

ARIN Public Policy Meeting:

ARIN XX
ARIN XXI

ARIN Advisory Council:

AC Shepherds:
Suzanne Woolf and Owen DeLong

23 August 2007
20 September 2007
18 October 2007
15 November 2007
20 December 2007
17 January 2008
21 February 2008
20 March 2008
9 April 2008
15 May 2008

ARIN Board of Trustees:

11 December 2007
20 June 2008

Revisions:

Click here to view previous versions.

Implementation:

5 August 2008

Author(s):

Scott Leibrand

Policy Proposal 2007-21
PIv6 for legacy holders with RSA and efficient use

Author: Scott Leibrand

Date: 14 April 2008

Proposal type: modify

Policy term: permanent

Policy statement:

Modify NRPM section 6.5.8.1 (Direct assignments from ARIN to end-user organizations: Criteria), to read:

To qualify for a direct assignment, an organization must:

  1. not be an IPv6 LIR; and

  2. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect, or demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must be covered by any 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

OUT OF DATE?

Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.