2013-7 Previous Version [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.

View the current policy proposal text.

The following text was archived on 16 May 2014

Recommended Draft Policy ARIN-2013-7
NRPM 4 (IPv4) Policy Cleanup

Date: 25 March 2014

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

“ARIN-2013-7: “NRPM 4 (IPv4) Policy Cleanup” enables fair and impartial number resource administration by removing no-longer-relevant sections of the NRPM, and clarifying other sections. All of the remaining changes in this draft policy have proven uncontroversial thus far.”

Problem Statement:

Parts of NRPM 4 are irrelevant, especially after IPv4 run-out, and should be cleaned up for clarity.

Policy statement:

Short list of changes with details explained below.

Remove section 4.1.1 Routability
Update section 4.1.5 Determination of resource requests
Remove section 4.1.7 RFC2050
Remove section 4.1.9 Returned IPv4 Addresses
Replace and retitle section 4.2.4.3 Subscriber Members Less Than One Year
Remove section 4.2.4.4. Subscriber Members After One Year

Details:

Remove section 4.1.1 Routability

It is no longer necessary for the NRPM to suggest where an organization obtains resources from.

Retitle and rewrite section (4.1.5 Determination of IP address allocation size)

Remove: “Determination of IP address allocation size is the responsibility of ARIN.”

Replace with: (4.1.5 Resource request size) “Determining the validity of the amount of requested IP address resources is the responsibility of ARIN.”

Rationale: Clarify that it is the validity of the request that is more the focus than the amount of resources requested. This does not prevent ARIN from suggesting that a smaller block would be justified where a larger one would not, but also does not suggest that it is ARIN’s sole discretion to judge the size of the blocks needed.

Remove section 4.1.7 RFC2050

Now that RFC2050 has been replaced with RFC 7020 and ARIN-2013-4 RIR Principles has been adopted, this section is no longer needed.

Remove section 4.2.4.3 Subscriber Members Less Than One Year and 4.2.4.4. Subscriber Members After One Year

Replace with: (4.2.4.3 Request size) “ISPs may request up to a 3-month supply of IPv4 addresses from ARIN, or a 24-month supply via 8.3 or 8.4 transfer.”

Rationale: Since ARIN received its last /8, by IANA implementing section 10.4.2.2, this is now a distinction without a difference.

Timetable for implementation: Immediate

##########

ARIN Staff and Legal Assessment

ARIN-prop-2013-7bis – “NRPM 4 (IPv4) Policy Cleanup”

Date of Assessment: 04 Mar 2014

Summary (Staff Understanding)

The intent of this proposal is to modify several existing sections of NRPM 4 as the author believes that they are becoming increasingly irrelevant as we move closer to IPv4 run-out. Sections to be modified include 4.1.1, 4.1.5, 4.1.7, 4.1.9, 4.2.4.3, 4.2.4.4, and 4.2.5.

Changes include:

No longer comments on global routability for IP addresses issued by ARIN and no longer recommends where ISPs should consider requesting IP address space
Removes ARIN’s sole discretion to determine the size of additional IPv4 allocations to ISPs
Removes reference to RFC2050
Removes text requiring ARIN to make returned, revoked, and recovered IP addresses available in the ARIN region as soon as possible
Codifies that all ISPs may request up to a three month supply of IPv4 addresses from ARIN, or a 24 month supply via 8.3 transfer
Removes the web hosting policy
Comments

A. ARIN Staff Comments

· This proposal removes or modifies 7 different policies in NRPM, however, these changes do not appear to alter staff’s ability to obtain appropriate justification for resource requests, nor create any potential operational impact.

· This proposal could be implemented as written

B. ARIN General Counsel - Legal Assessment

The policy does not create legal concerns.

Resource Impact

This policy would have minimal resource impact from an implementation aspect. 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 Text

Problem Statement: Parts of NRPM 4 are irrelevant, especially after IPv4
run-out, and should be cleaned up for clarity.

Policy statement:

Short list of changes with details explained below.

Remove section 4.1.1 Routability
It is no longer necessary for the NRPM to suggest where an organization
obtains resources from.

Retitle and rewrite section (4.1.5 Determination of IP address allocation size)
Remove: “Determination of IP address allocation size is the responsibility of ARIN.”

Replace with: (4.1.5 Resource request size) “Determining the validity of
the amount of requested IP address resources is the responsibility of ARIN.”

Remove section 4.1.7 RFC2050
Now that RFC2050 has been replaced with RFC 7020 and ARIN-2013-4 RIR
Principles has been adopted, this section is no longer needed.

Remove section 4.2.4.3 Subscriber Members Less Than One Year and 4.2.4.4. Subscriber Members After One Year
Replace with: (4.2.4.3 Request size) “ISPs may request up to a 3-month
supply of IPv4 addresses from ARIN, or a 24-month supply via 8.3 transfer.”

Rationale: Since ARIN received its last /8, by IANA implementing section
10.4.2.2, this is now a distinction without a difference.

Remove section 4.2.5 Web Hosting Policy
This information-gathering policy has been in place for a decade now with no resulting policy changes, and is no longer needed in light of IPv4 runout.

XXXXX

The following version was archived on 25 March 2014

Draft Policy ARIN-2013-7
NRPM 4 (IPv4) Policy Cleanup

Date: 24 January 2014

Problem Statement:

Parts of NRPM 4 are irrelevant, especially after IPv4 run-out, and should be cleaned up for clarity.

Policy statement:

Short list of changes with details explained below.

Details:

Remove section 4.1.1 Routability
It is no longer necessary for the NRPM to suggest where an organization obtains resources from.

Retitle and rewrite section (4.1.5 Determination of IP address allocation size)
Remove: “Determination of IP address allocation size is the responsibility of ARIN.”

Replace with: (4.1.5 Resource request size) “Determining the validity of the amount of requested IP address resources is the responsibility of ARIN.”

Remove section 4.1.7 RFC2050
Now that RFC2050 has been replaced with RFC 7020 and ARIN-2013-4 RIR Principles has been adopted, this section is no longer needed.

Remove section 4.2.4.3 Subscriber Members Less Than One Year and 4.2.4.4. Subscriber Members After One Year
Replace with: (4.2.4.3 Request size) “ISPs may request up to a 3-month supply of IPv4 addresses from ARIN, or a 24-month supply via 8.3 transfer.”

Rationale: Since ARIN received its last /8, by IANA implementing section 10.4.2.2, this is now a distinction without a difference.

Remove section 4.2.5 Web Hosting Policy
This information-gathering policy has been in place for a decade now with no resulting policy changes, and is no longer needed in light of IPv4 runout.

Timetable for implementation: Immediate

XXXXX

The following version was archived on 24 January 2014

Draft Policy ARIN-2013-7
Merge IPv4 ISP and End-User Requirements

Date: 20 August 2013

Problem Statement: This proposal attempts to reconcile the differences
in requirements for obtaining PA and PI IPv4 address resources.

Policy statement:

Short list of changes with details explained below.

* Remove section 4.1.1 Routability
* Rewrite section 4.1.5 Determination of resource requests
* Remove section 4.1.7 RFC2050
* Rename section header 4.2 Allocations to ISPs (Requiments for Requesting Initial Address Space)
* Remove section header 4.2.1 Principles and promote subsections
* Rewrite section 4.2.1.1 Purpose
* Remove section 4.2.1.4 Slow start
* Remove section 4.2.1.5 Minimum allocation
* Remove section 4.2.2.1 Standard or non-multihomed (and subsections)
* Remove section 4.2.2.2 Multihomed (and subsections)
* Rewrite section 4.2.2 with combined wording to replace sections that are being removed. See details below.
* Replace section 4.2.4 ISP Additional Requests (and subsections)
* Move original section 4.3.5 to new combined section 4.2.7. (unchanged
text)
* Remove section 4.2.5 Web Hosting Policy
* Remove section 4.3 End-users-Assignments to end-users (and subsections)
* Remove section 4.9 Minimum allocation for the Caribbean and North
Atlantic Islands (and subsections)

Summary of requirement changes:

Minimum allocation for a single-homed ISP is reduced from a /20 to /22.

Minimum allocation for a multi-homed ISP is reduced from a /22 to a /24.

The distinction between subscriber members who are before or after a one
year anniversary is removed.

Minimum assignments for a single-homed end user is reduced from a /20 to a /22.

The requirement that multi-homed, end-user assignments smaller than a /20 be made from a block reserved for that purpose is removed.

The utilization requirements on an initial end-user assignment changes
from 25% immediate, 50% within one year to 80% within three months. This
is offset by the lowering of the minimum block size requirement for
single-homed networks.

The timeframe for additional ISP allocations is changed from three months back to one year.

The special section for the Caribbean region is integrated into the same
requirements as the rest of the region with the existing /22 and the
addition of an option for a multi-homed /24.

Details:

* Remove section 4.1.1 Routability
In merging the PI and PA requirements this section seems unnecessary in
the newer version. It is also not necessary for the NRPM to suggest who or where an organization obtains resources.

* Renumber and rewrite section (4.1.5 Determination of IP address
allocation size)

Remove: “Determination of IP address allocation size is the responsibility
of ARIN.”

Replace with: (4.1.1 Determination of resource requests)
“Determining the validity of the amount of requested IP address resources is the responsibility of ARIN.”

Rationale: The specific use of “allocation” does not propagate to end-user assignments in the proposed, merged instance. It is also an attempt to clarify that it is the validity of the request that is more the focus than the amount of resources requested. This does not prevent ARIN from suggesting that a smaller block would be justified where a larger one would not, but also does not suggest that it is ARIN’s sole discretion to judge the size of the blocks needed.

* Remove section 4.1.7 RFC2050
With RFC2050 being updated the debate needs to occur whether this section should be retained in the principles of the IPv4 policy section. This may be better addressed by ARIN-2013-4.

* Rename section header (4.2 Allocations to ISPs Requiments for Requesting Initial Address Space)
New section name: 4.2 Resource Requirements

* Remove section 4.2.1 Principles and promote subsections
In merging the requirements of section 4.2 and 4.3 this section becomes
overly complicated and this was an attempt to simplify.

* Replacement section (4.2.1 Purpose)

Remove: “ARIN allocates blocks of IP addresses to ISPs for the purpose of reassigning that space to their customers.”

Replace with: “ARIN provides blocks of IP addresses to network operators
for the purpose of using these resources on their network.”

Rationale: The distinction is removed between end-users and ISP’s to
provide a unified set of requirements.

* Remove section 4.2.1.4 Slow start
In an attempt to merge ISP and end user assignments it was desired to not take any functionality away that already existed for one or the other and balance this with transfer requirements.

* Remove section 4.2.1.5 Minimum allocation
In an attempt to merge ISP and end user assignments it was desired to not take any functionality away that already existed for one or the other and balance this with transfer requirements.

* Remove section 4.2.2.1 Standard or non-multihomed (and subsections)
This is being replaced with the merged text in the proposed section 4.2.5.

* Remove section 4.2.2.2 Multihomed (and subsections)
This is being replaced with the merged text in the proposed section 4.2.5.

* Rewrite section 4.2.2 with combined wording to replace sections that are being removed.

Replacement section (4.2.5 Minimum Size and Utilization)

A /24 is the minimum sized block to be provided to a multi-homed network.

A /22 is the minimum sized block to be provided to a single-homed network.

Through appropriate documentation like reassignment information of blocks from an upstream provider, or other means requested by ARIN, it must be shown how an initial block would be 80% utilized within three months. It must be agreed upon that the newly requested IP address space will be used to renumber out of any current addresses, which will be returned to their upstream provider(s). Blocks smaller than the minimum should be obtained from an upstream provider.

* Replace section 4.2.4 ISP Additional Requests (and subsections)

Replacement section (4.2.6 Subsequent Requests)

All previously received IP address resources must be efficiently utilized, and at least 80% of their most recent IP block(s) in order to obtain approval of receiving up to an additional 12-month supply of IP address resources.

* Move original section 4.3.5 to new combined section 4.2.7. (unchanged
text)

* Remove section 4.2.5 Web Hosting Policy
This is being replaced with the merged text in the proposed section 4.2.5 and 4.2.6

* Remove section 4.3 End-users-Assignments to end-users (and subsections)
This is being replaced with the merged text in the proposed section 4.2.5 and 4.2.6

* Remove section 4.9 Minimum allocation for the Caribbean and North
Atlantic Islands (and subsections)
This is being replaced with the merged text in the proposed section 4.2.5 and 4.2.6

Comments: The network resource policy manual has become an
unnecessarily complex document as a result quickly evolving requirements.
This proposal is an attempt to simplify one part of the document in a way that is easily understood even though it intentionally leaves other parts unresolved. This was done to keep the scope to something that could realistically be discussed.

Timetable for implementation: Immediate

Proposed text changes in pdf: https://www.arin.net/policy/proposals/ARIN-prop-190_proposed_text_changes.pdf