[ppml] Policy Proposal 2007-6: IPv4 PI minimum size change

[Member Services]

On 1 March 2007 the ARIN Advisory Council (AC) concluded its review
of 'IPv4 PI Minimum Size Change' and accepted it as a formal policy
proposal for discussion by the community.

The proposal is designated Policy Proposal 2007-6: IPv4 PI Minimum Size
Change. The proposal text is below and can be found at:
http://www.arin.net/policy/proposals/2007_6.html

All persons in the community are encouraged to discuss Policy
Proposal 2007-6 prior to it being presented at the ARIN Public Policy
Meeting in San Juan, Puerto Rico, 23-24 April 2007. Both the discussion
on the Public Policy Mailing List and at the Public Policy Meeting will
be used to determine the community consensus regarding this policy proposal.

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

ARIN's Policy Proposal Archive can be found at:
http://www.arin.net/policy/proposals/proposal_archive.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##

Policy Proposal 2007-6: IPv4 PI minimum size change

Author: David Williamson

Proposal Version: 1.0

Submission Date: 2/14/2007

Proposal type: modify

Policy term: permanent

Policy statement:

In section 4.3.2.2 of the NRPM, change all occurrences 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