Policy Proposal 2007-6 - Abandoned

[Member Services]

Policy Proposal 2007-6
IPv4 PI minimum size change

The ARIN Advisory Council (AC), acting under the provisions of the ARIN
Internet Resource Policy Evaluation Process (IRPEP), determined that
there is not community consensus in favor of the proposal and abandoned
it. The AC made this determination at their meeting at the conclusion of
the ARIN Public Policy meeting on 24 April 2007. The Chair of the AC
reported the results of the AC meeting during the Members Meeting. The
AC Chair's report can be found at:
http://www.arin.net/meetings/minutes/ARIN_XIX/mem.html

In order for this proposal to be further considered the author must use
the last call petition process as defined in the ARIN Internet Resource
Policy Evaluation Process. This policy will be considered to be
abandoned if the author of the proposal does not initiate a last call
petition by 23:59, Eastern Time, 2 May 2007.

The policy proposal text is provided below and is also available at:
http://www.arin.net/policy/proposals/2007_6.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)


##*##


Policy Proposal 2007-6
IPv4 PI minimum size change

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.

Rationale:

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