Policy Proposal 2007-6: IPv4 PI minimum size change [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: Abandoned

Tracking Information

Discussion Tracking

Mailing List:

Formal introduction on PPML on 2 March 2007

Staff assessment - 13 April 2007
AC intent to abandon - 25 April 2007Public Policy Mailing List

ARIN Public Policy Meeting:

ARIN XIX

ARIN Advisory Council:

1 March 2007
24 April 2007

ARIN Board of Trustees:

Revisions:

Implementation:

Author(s):

David Williamson

Proposal type: modify

Policy term: permanent

Policy statement:

In section 4.3.2.2 of the NRPM, change all occurences of “/22” to “/24”.

(That is, replace the existing 4.3.2.2 with this text:

For end-users who demonstrate an intent to announce the requested space in a multihomed fashion, the minimum block of IP address space assigned is a /24. If assignments smaller than a /24 are needed, multihomed end-users should contact their upstream providers. When prefixes are assigned which are longer than /20, they will be from a block reserved for that purpose.)

Remove references to IPv4 in section 4.4, as they are no longer relevant. Section 4.4 could be moved, at the discretion of the NRPM editors, to somewhere in section 6, for clarity.

The rationale for moving the allocation “edge” for IPv4 PI space to /24 has three fundamental points: routing slot consumption would be unchanged, it reflects widespread routing practices, and it discourages waste.

While experiments indicate that a few ISPs still try to filter at the /22 boundary, I have been repeatedly told that most don’t filter anything shorter than a /24. While routing policy and allocation policies don’t need to necessarily match, it is not unreasonable to have them in alignment.

In addition, by keeping the PI allocation size for multi-homed organizations at /22, organizations seeking PI space that don’t meet the requirements may be encouraged to exaggerate their address usage. This is something that should clearly not be encouraged.

On the topic of routing slots, I would like to note that any org qualifying under the PI policies in 4.3.2.2 would also qualify for PA space, and would likely have an interest in multi-homing regardless of the usage of PA vs. PI space. In either instance, a routing slot is consumed by a /24. This policy change should therefore have minimal, if any, impact on the size of the global routing table. It merely gives organizations more options at a slightly smaller network size. Remember that for consideration under 4.3.2.2, an organiztion *must* be multi-homed.

On a side note, it’s tempting to remove the restriction entirely. If an organization only qualifies for a /28 (for example), they could receive an allocation of that size. Market forces would decide if that /28 was worth a routing slot. If the /28 contained my personal website, I suspect it would not be routable. If that /28 contained Microsoft Update, I suspect it would. In the interest of operational sanity and simplicity, I am not making a proposal to remove the restriction. (Note that section 4.1.1 explicitly notes that PI addresses are not guaranteed to be globally routable.)

There is fundamental conflict between the urge for aggregation and the desire for conservation. The latter would prefer that organizations not have any excess space, while the former would prefer that fewer networks exist in the DFZ, regardless of wastage. Since the DFZ already permits deaggregation to /24, the conservation urge should be allowed to push to that edge.

As noted in 4.1.5, “determination of IP address allocation size is the responsibility of ARIN.” This proposal simply allows the community to request appropriately sized blocks, and ARIN to allocate prefixes of a size that is commensurate with established need.

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.