[ppml] Policy Proposal: IPv4 PI minimum size change

[Member Services]

ARIN received the following policy proposal. In accordance with the ARIN
Internet Resource Policy Evaluation Process, the proposal is being
posted to the ARIN Public Policy Mailing List (PPML) and being placed on
ARIN's website.

The AC will review this proposal and may decide to:

1. Accept the proposal as a formal policy proposal as it is presented;

2. Work with the author to:
      a) clarify the language or intent of the proposal;
      b) divide the proposal into two (2) or more proposals; or
      c) combine the proposal with other proposals; or,

3. Not accept the proposal as a formal policy proposal.

The AC will review this proposal at their next meeting. If the AC
accepts the proposal, then it will be posted as a formal policy proposal
to PPML and it will be presented at a Public Policy Meeting. If the AC
does not accept the proposal, then the AC will explain that decision;
and at that time the author may elect to use the petition process to
advance their proposal. If the author elects not to petition or the
petition fails, then the proposal will be closed.

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

Mailing list subscription information can be found at:
http://www.arin.net/mailing_lists/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal Name: 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 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