Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy [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: Implemented

Tracking Information

Discussion Tracking

Mailing List:

Formal introduction on PPML on 21 June 2016

Origin - ARIN-prop-230

Draft Policy - 21 June 2016

Recommended Draft Policy - 20 September 2016

Last Call - 26 October 2016

Recommended to Board: 22 November 2016

Public Policy Mailing List

ARIN Public Policy Meeting:

ARIN 38

ARIN Advisory Council:

AC Shepherds:
Leif Sawyer, David Huberman

ARIN Board of Trustees:

19 December 2016

Revisions:

Implementation:

21 February 2017

Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

Date: 26 October 2016

AC’s assessment of conformance with the Principles of Internet Number Resource Policy:

2016-5 is one of a set of overlapping policies involving simplification of section 8 specified transfer policy. Each takes a somewhat different approach, and all have a degree of community support. Based on community feedback at the upcoming ARIN 38 meeting in Dallas, we hope to advance whichever of those proposals is best-supported by the community, or craft and advance a unified proposal that incorporates the best attributes of the proposals currently on the docket. Moving 2016-5 to Recommended Draft will facilitate moving the best policy forward in a timely manner.

Problem Statement:

Section 4 of the Number Policy Resource Manual was developed over the past 15+ years primarily to conservatively manage the IPv4 number free pool. Since the IPv4 free pool was depleted in 2015, the policies which developed since ARIN’s inception may now not be as relevant now that the primary function of the registry, with regard to IPv4 numbers, is to record transfers.

Since section 4 of the NRPM now contains many use cases that are not as relevant, it makes sense to streamline the transfer process and to specifically outline the criteria that should be used to process transfers.

Therefore, we propose the following rewrite of the transfer policy, section 8 of the NRPM.

The goals of this rewrite are as follows:

Separate the criteria that is found in section 4 of the NRPM from the transfer process. - Provide a clear set of criteria that should be applied across all IPv4 transfers. - Lower the thresholds on utilization and future allocation size to negate the necessity of the corner cases which are currently enumerated in section 4 of the NRPM. - Reduce the complexity that is currently required for transfers, by applying simpler utilization criteria for current usage, and future allocation sizing.

Policy statement:

Add new section 8.5; update sections 8.2-8.4 as follows to reference 8.5.

8.2. Mergers, Acquisitions, and Reorganizations

ARIN will consider requests for the transfer of number resources in the case of mergers, acquisitions, and reorganizations under the following conditions:

The current registrant must not be involved in any dispute as to the status of the resources to be transferred. - The new entity must sign an RSA covering all resources to be transferred. - The resources to be transferred will be subject to ARIN policies. - The minimum transfer size is the smaller of the original allocation size or the applicable minimum allocation size in current policy. - For mergers and acquisition transfers, the recipient entity must provide evidence that they have acquired assets that use the resources to be transferred from the current registrant. ARIN will maintain an up-to-date list of acceptable types of documentation. ARIN will proceed with processing transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN transfer policy as defined in section 8.5. In that event, ARIN will work with the resource holder(s) to transfer the extra number resources to other organization(s) or accept a voluntary return of the extra number resources to ARIN.

8.3. Transfers between Specified Recipients within the ARIN Region

In addition to transfers under section 8.2, IPv4 numbers resources and ASNs may be transferred according to the following conditions.

Conditions on source of the transfer:

The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources. - The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers. Conditions on recipient of the transfer:
The recipients must meet the transfer requirements as defined in section 8.5. - The resources transferred will be subject to current ARIN policies. 8.4. Inter-RIR Transfers to Specified Recipients

Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies.

Conditions on source of the transfer:

The source entity must be the current rights holder of the IPv4 address resources recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources. - Source entities outside of the ARIN region must meet any requirements defined by the RIR where the source entity holds the registration. - Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.

Conditions on recipient of the transfer:

The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR. - Recipients within the ARIN region must meet the transfer requirements as defined in section 8.5. - Recipients within the ARIN region will be subject to current ARIN policies. 8.5. Specified Transfer Recipient Requirements

8.5.1. Registration Services Agreement

The receiving entity must sign an RSA covering all resources to be transferred unless that entity has a current (within the last two versions) RSA on file.

8.5.2. Operational Use

ARIN allocates or assigns number resources to organizations via transfer solely for the purpose of use on an operational network.

8.5.3. Minimum transfer size

ARIN’s minimum IPv4 transfer size is a /24.

8.5.4. Initial block

Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial IPv4 block of ARIN’s minimum transfer size.

8.5.5. Block size

Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN.

8.5.6. Efficient utilization of previous blocks

Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of their cumulative IPv4 address blocks in order to receive additional space. This includes all space reassigned to their customers.

Comments:

Timetable for implementation: immediately

Anything else: A redline has been provided to help the community understand the changes that have been made to the NRPM.

##########

Earlier Version

##########

Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

Date: 20 September 2016

AC’s assessment of conformance with the Principles of Internet Number Resource Policy:

Problem Statement:

Therefore, we propose the following rewrite of the transfer policy, section 8 of the NRPM.

The goals of this rewrite are as follows:

Separate the criteria that is found in section 4 of the NRPM from the transfer process.
Provide a clear set of criteria that should be applied across all IPv4 transfers.
Lower the thresholds on utilization and future allocation size to negate the necessity of the corner cases which are currently enumerated in section 4 of the NRPM.
Reduce the complexity that is currently required for transfers, by applying simpler utilization criteria for current usage, and future allocation sizing.

Policy statement:

Add new section 8.5; update sections 8.2-8.4 as follows to reference 8.5.

8.2. Mergers, Acquisitions, and Reorganizations

ARIN will consider requests for the transfer of number resources in the case of mergers, acquisitions, and reorganizations under the following conditions:

The current registrant must not be involved in any dispute as to the status of the resources to be transferred.
The new entity must sign an RSA covering all resources to be transferred.
The resources to be transferred will be subject to ARIN policies.
The minimum transfer size is the smaller of the original allocation size or the applicable minimum allocation size in current policy.
For mergers and acquisition transfers, the recipient entity must provide evidence that they have acquired assets that use the resources to be transferred from the current registrant. ARIN will maintain an up-to-date list of acceptable types of documentation.

ARIN will proceed with processing transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN transfer policy as defined in section 8.5. In that event, ARIN will work with the resource holder(s) to transfer the extra number resources to other organization(s) or accept a voluntary return of the extra number resources to ARIN.

8.3. Transfers between Specified Recipients within the ARIN Region

In addition to transfers under section 8.2, IPv4 numbers resources and ASNs may be transferred according to the following conditions.

Conditions on source of the transfer:

The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources.
The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.

Conditions on recipient of the transfer:

The recipients must meet the transfer requirements as defined in section 8.5.
The resources transferred will be subject to current ARIN policies.

8.4. Inter-RIR Transfers to Specified Recipients

Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies.

Conditions on source of the transfer:

The source entity must be the current rights holder of the IPv4 address resources recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources.
Source entities outside of the ARIN region must meet any requirements defined by the RIR where the source entity holds the registration.
Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.

Conditions on recipient of the transfer:

The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR.
Recipients within the ARIN region must meet the transfer requirements as defined in section 8.5.
Recipients within the ARIN region will be subject to current ARIN policies.

8.5. Specified Transfer Recipient Requirements

8.5.1. Registration Services Agreement

The receiving entity must sign an RSA covering all resources to be transferred unless that entity has a current (within the last two versions) RSA on file.

8.5.2. Operational Use

ARIN allocates or assigns number resources to organizations via transfer solely for the purpose of use on an operational network.

8.5.3. Minimum transfer size

ARIN’s minimum IPv4 transfer size is a /24.

8.5.4. Initial block

Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial IPv4 block of ARIN’s minimum transfer size.

8.5.5. Block size

8.5.6. Efficient utilization of previous blocks

Comments:

Timetable for implementation: immediately

Anything else: A redline has been provided to help the community understand the changes that have been made to the NRPM.

##########

Earlier Version

##########

Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy

Date: 21 June, 2016

Problem Statement

Therefore, we propose the following rewrite of the transfer policy, section 8 of the NRPM.

The goals of this rewrite are as follows:

Separate the criteria that is found in section 4 of the NRPM from the transfer process.
Provide a clear set of criteria that should be applied across all IPv4 transfers.
Lower the thresholds on utilization and future allocation size to negate the necessity of the corner cases which are currently enumerated in section 4 of the NRPM.
Reduce the complexity that is currently required for transfers, by applying simpler utilization criteria for current usage, and future allocation sizing.

Policy statement

Add new section 8.5; update sections 8.2-8.4 as follows to reference 8.5.

8.2. Mergers, Acquisitions, and Reorganizations

ARIN will consider requests for the transfer of number resources in the case of mergers, acquisitions, and reorganizations under the following conditions:

The current registrant must not be involved in any dispute as to the status of the resources to be transferred.
The new entity must sign an RSA covering all resources to be transferred.
The resources to be transferred will be subject to ARIN policies.
The minimum transfer size is the smaller of the original allocation size or the applicable minimum allocation size in current policy.
For mergers and acquisition transfers, the recipient entity must provide evidence that they have acquired assets that use the resources to be transferred from the current registrant. ARIN will maintain an up-to-date list of acceptable types of documentation.

8.3. Transfers between Specified Recipients within the ARIN Region

In addition to transfers under section 8.2, IPv4 numbers resources and ASNs may be transferred according to the following conditions.

Conditions on source of the transfer:

The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources.
The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.

Conditions on recipient of the transfer:

The recipients must meet the transfer requirements as defined in section 8.5.
The resources transferred will be subject to current ARIN policies.

8.4. Inter-RIR Transfers to Specified Recipients

Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies.

Conditions on source of the transfer:

The source entity must be the current rights holder of the IPv4 address resources recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources.
Source entities outside of the ARIN region must meet any requirements defined by the RIR where the source entity holds the registration.
Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.

Conditions on recipient of the transfer:

The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR.
Recipients within the ARIN region must meet the transfer requirements as defined in section 8.5.
Recipients within the ARIN region will be subject to current ARIN policies.

8.5. Specified Transfer Recipient Requirements

8.5.1. Registration Services Agreement

Transfer recipients must sign an RSA for the resources being received.

8.5.2. Operational Use

ARIN allocates or assigns blocks of IP addresses to organizations via transfer solely for the purpose of use on an operational network.

8.5.3. Minimum transfer size

ARIN’s minimum transfer size is a /24.

8.5.4. Initial block

Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial block of ARIN’s minimum transfer size.

8.5.5. Block size

Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN.

8.5.6. Efficient utilization of previous blocks

Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of every block in order to receive additional space. This includes all space reassigned to their customers.

Comments:

Timetable for implementation: immediately

Anything else: A redline has been provided to help the community understand the changes that have been made to the NRPM.

##########

ARIN STAFF & LEGAL ASSESSMENT
Draft Policy ARIN-2016-5
POST-IPv4-FREE-POOL-DEPLETION TRANSFER POLICY
https://www.arin.net/policy/proposals/2016_5.html

Date of Assessment: 12 September 2016

Summary (Staff Understanding)

Draft Policy 2016-5 creates clear policy separation between the needs-assessment work conducted for transfers and the assessments conducted for non-transfer related IPv4 requests. More specifically, the draft policy places needs-assessment related policy language for transfers in Section 8 of the NRPM and removes use of Section 4 of the NRPM from the transfer process completely.

Comments

A. ARIN Staff Comments

* If 2016-5 is implemented, staff would no longer use Section 4 of the NRPM to review needs-assessments for transfers (8.2, 8.3 recipient, 8.4 recipient, and transfer pre-approvals). Staff would use the new language in Section 8 of NRPM to conduct all transfer-related needs-assessments.

* The use of the words “block” and “blocks” without specifying which type of Internet number resources those words are referring to may introduce ambiguity that will confuse customers of the transfer processes. In working with customers inside this process over the last few years, staff has found ambiguity and/or concern about unclear elements of the process prevents customers from using or completing the transfer process. We suggest all instances of “block” or “blocks” be clarified by using the wording “IPv4 blocks”.

* Potential Issue #1: Transfer customers may interpret Section 8.5.1 to require a newly signed RSA for each transfer they receive. ARIN staff interpretation of the Section 8.5.1 language is that organizations that already have a recently signed RSA (within the last two versions) on file with ARIN may not need to sign a new RSA each time they receive a transfer. Suggested wording should read something similar to “The receiving entity must sign an RSA covering all resources to be transferred unless that entity has a current (within the last two versions) RSA on file.”

* Potential Issue #2: Staff interpretation of 8.5.6 intent is that all previous IPv4 blocks must be *cumulatively* utilized to the rate of 50%. The language as it exists, however, may confuse some customers or create a quandary for ARIN registration staff. For instance; if an organization had a /10 that is 99% utilized and a /20 that is 25% utilized, the customer may be deemed ineligible to qualify for an additional IPv4 block through the needs-assessment process. Even though we believe we can operate with the proposed text, in order not to confuse our customers we suggest that this language be clarified such as “Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of their cumulative IPv4 address blocks in order to receive additional space. This includes all space reassigned to their customers.”

* To properly implement the policies of 2016-5, staff would require clarification on the potential issues cited above.

B. ARIN General Counsel – Legal Assessment

The policy does not appear to create any material legal issue.

Resource Impact

Implementation of this policy would have minimal resource impact. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement:

* Updated guidelines and internal procedures
* Staff training

Proposal / Draft Policy Text Assessed

Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
Date: 25 July 2016

Problem Statement:

Therefore, we propose the following rewrite of the transfer policy, section 8 of the NRPM.

The goals of this rewrite are as follows:

Separate the criteria that is found in section 4 of the NRPM from the transfer process.
Provide a clear set of criteria that should be applied across all IPv4 transfers.
Lower the thresholds on utilization and future allocation size to negate the necessity of the corner cases which are currently enumerated in section 4 of the NRPM.
Reduce the complexity that is currently required for transfers, by applying simpler utilization criteria for current usage, and future allocation sizing.

Policy statement:

Add new section 8.5; update sections 8.2-8.4 as follows to reference 8.5.

8.2. Mergers, Acquisitions, and Reorganizations

ARIN will consider requests for the transfer of number resources in the case of mergers, acquisitions, and reorganizations under the following conditions:

The current registrant must not be involved in any dispute as to the status of the resources to be transferred.
The new entity must sign an RSA covering all resources to be transferred.
The resources to be transferred will be subject to ARIN policies.
The minimum transfer size is the smaller of the original allocation size or the applicable minimum allocation size in current policy.
For mergers and acquisition transfers, the recipient entity must provide evidence that they have acquired assets that use the resources to be transferred from the current registrant. ARIN will maintain an up-to-date list of acceptable types of documentation.

8.3. Transfers between Specified Recipients within the ARIN Region

In addition to transfers under section 8.2, IPv4 numbers resources and ASNs may be transferred according to the following conditions.

Conditions on source of the transfer:

The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources.
The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.

Conditions on recipient of the transfer:

The recipients must meet the transfer requirements as defined in section 8.5.
The resources transferred will be subject to current ARIN policies.

8.4. Inter-RIR Transfers to Specified Recipients

Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies.

Conditions on source of the transfer:

The source entity must be the current rights holder of the IPv4 address resources recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources.
Source entities outside of the ARIN region must meet any requirements defined by the RIR where the source entity holds the registration.
Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.

Conditions on recipient of the transfer:

The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR.
Recipients within the ARIN region must meet the transfer requirements as defined in section 8.5.
Recipients within the ARIN region will be subject to current ARIN policies.

8.5. Specified Transfer Recipient Requirements

8.5.1. Registration Services Agreement
Transfer recipients must sign an RSA for the resources being received.

8.5.2. Operational Use
ARIN allocates or assigns number resources to organizations via transfer solely for the purpose of use on an operational network.

8.5.3. Minimum transfer size
ARIN’s minimum IPv4 transfer size is a /24.

8.5.4. Initial block
Organizations without direct assignments or allocations from ARIN qualify for transfer of an initial block of ARIN’s minimum transfer size.

8.5.5. Block size
Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN.

8.5.6. Efficient utilization of previous blocks
Organizations with direct assignments or allocations from ARIN must have efficiently utilized at least 50% of every block in order to receive additional space. This includes all space reassigned to their customers.

Comments:

Timetable for implementation: immediately

Anything else: A redline has been provided to help the community understand the changes that have been made to the NRPM.

END