Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations

[Member Services]

ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with Policy Development
Process.

This proposal is in the first stage of the Policy Development Process.
ARIN staff will perform the Clarity and Understanding step. Staff does
not evaluate the proposal at this time, their goal is to make sure that
they understand the proposal and believe the community will as well.
Staff will report their results to the ARIN Advisory Council (AC) within
10 days.

The AC will review the proposal at their next regularly scheduled
meeting (if the period before the next regularly scheduled meeting is
less than 10 days, then the period may be extended to the subsequent
regularly scheduled meeting). The AC will decide how to utilize the
proposal and announce the decision to the PPML.

In the meantime, the AC invites everyone to comment on the proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Mailing list subscription information can be found
at: https://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations

Proposal Originator: Chris Grundemann & Ted Mittelstaedt

Proposal Version: 1

Date: 5 November 2009

Proposal type: modify

Policy term: permanent

Policy statement:

     Modify section 4.2.1.5. Minimum allocation:

In general, ARIN allocates IP address prefixes no longer than /23 to
ISPs. If allocations smaller than /23 are needed, ISPs should request
address space from their upstream provider.  When prefixes are
assigned which are longer than /20, they will be from a block reserved
for that purpose whenever that is feasible.

     And

     Replace the contents of section 4.2.2. Initial allocation to ISPs:

4.2.2.1. Use of /24

The efficient utilization of an entire previously allocated /24 from
their upstream ISP.

4.2.2.2. Efficient utilization

Demonstrate efficient use of IP address space allocations by providing
appropriate documentation, including assignment histories, showing
their efficient use. ISPs must provide reassignment information on the
entire previously allocated block(s) via SWIP or RWHOIS server for /29
or larger blocks. For blocks smaller than /29 and for internal space,
ISPs should provide utilization data either via SWIP or RWHOIS server
or by using the table format described in Section 4.2.3.7.5.

4.2.2.3. Three months

Provide detailed information showing specifically how the initial
allocation will be utilized within three months.

4.2.2.4. Renumber and return

ISPs receiving an initial allocation smaller than /20 must agree that
the newly requested IP address space will be used to renumber out of
the current addresses which will be returned to the assigning
organization within 12 months. ISPs receiving an initial allocation
equal to or larger than /20 may wish to renumber out of their
previously allocated space. In this case, an ISP must use the new
prefix to renumber out of that previously allocated block of address
space and must return the space to its upstream provider.

4.2.2.5. Replacement initial allocation

Any ISP which has received an initial allocation, or previous
replacement initial allocation, smaller than /20 who wishes to receive
additional address space must request a replacement initial
allocation. To receive a replacement initial allocation, an ISP must
agree to renumber out of and return the existing allocation in it's
entirety within 12 months of receiving a new allocation and provide
justification for the new allocation as described in section 4.2.4.

Rationale:

This policy proposal fundamentally changes and simplifies the initial
IPv4 allocations to ISPs by doing the following:

1) Makes moot whether the requesting ISP is multihomed or not, with
this policy change all initial ISPs request under the same minimums.

2) Lowers the minimums, making it easier for smaller ISPs to qualify
for direct allocations from ARIN.

3) Reduces fragmentation of the allocated IPv4 pool by forcing smaller
ISPs who do qualify under the minimum to return the small allocation
when they outgrow it.  Note particularly that this does not "change
the bar" for ISPs who have already received small allocations, as they
will have not agreed to return those smaller allocations when they get
larger allocations.

4) Indirectly encourages the adoption of IPv6 as the ISPs that now
qualify for numbering under this policy change will be considered an
LIR and thus satisfy one of the IPv6 requirements in section 6.5.1.1


This policy proposal idea grew out of Proposal 98 and 100 and the
discussions surrounding those proposals as well as many discussions on
the ppml and on arin-discuss mailing lists.

For starters, it's well known that while transit networks have the
ability to filter IPv4 BGP advertisements, few to none filter anything
larger than a /24 (any who do filter /24 or larger have a default
route to fall back on), and a /24 (for perhaps no better reason than
it happens to be a "class C") has become the de-facto standard
minimum.  As a result, assigning blocks smaller than a /22 (the
current minimum under 4.2.2) isn't going to break anything.

Secondly, the primary motivator for denying smaller ISPs an initial
allocation from ARIN is to slow the growth of the DFZ, due to concerns
that growth of the so-called "IPv4 global routing table" would exceed
memory requirements in routers operated by transit networks.  This is
why Section 4.2.2 was split into multihomed and non-multihomed in the
first place, to help "raise the bar" and prevent a land rush.  Section
4.2.2.1 makes it so that only really large ISPs qualify for an initial
allocation, Section 4.2.2.2 makes it so that only ISPs with the
financial ability to bring in multiple feeds can qualify.  Basically,
your either big and poor or small and rich - whereas the typical
"garage operator" ISP would be small and poor.

Our belief is that while this may have worked a decade ago, it's a
moot issue now.  For one thing, nothing prevents orgs that obtain
larger allocations from splitting their advertisements.  For example
an org that has a /22 and 2 feeds, one larger than the other, might
choose to advertise 2 /23's so they can prepend one of the /23's
towards the smaller feed, so as to reduce traffic.  Orgs that have
distributed NOCS and even larger allocations have also done this for
traffic flow reasons.  There is no real guarantee than an org getting
a contiguous block will actually advertise it under a single route
entry, so it seems somewhat hypocritical to deny smaller ISPs an
initial allocation because of the reason that small allocations clog
up the so-called "global route table" when larger ISPs can and
sometimes do clog it up by subnetting.

The Internet landscape has changed tremendously, it is much more
expensive now for "garage operators" to initiate operations, and the
ISP industry has had a lot of consolidation.  These factors are much
more of a deterrent to small operators getting started and wanting an
initial allocation.  And, with small operators, labor is costly and
renumbering out of an upstream-assigned IPv4 block is a big barrier as
well.

We feel that allowing smaller ISPs to qualify now for IPv4 will have a
number of benefits:

1) It's possible that post-IPv4 runout, financial pressure to justify
assignments will develop among transit networks as the "market rate"
of IPv4 rises.  That may lead to smaller ISPs who don't have their own
assignments to be pressured to shrink operations (or be pushed out
completely), by upstreams eager to sell IPv4 blocks on the transfer
market.

2) Sometimes an issue is helped more by being "nibbled to death by
ducks".  If a large number of small ISPs were to obtain IPv4 and
follow up by obtaining IPv6 at the same time, the cumulative effect of
many small operators calling their upstreams and pressuring their
upstreams to supply native IPv6 routing might be much stronger - and
might cause more of them to get on the ball with IPv6 deployments.

3) Small IPv4 subnets that a /23 or /22 allocation can be made from
will be increasingly available to ARIN from reclamation efforts, thus
allocating small subnets that the RIR generates from these efforts to
legitimate ISPs will help to prevent "squatting" on them from spammers
and other network criminals, without consuming "virgin" blocks in the
free pool.  It might even be possible for ARIN to use portions of the
"old swamp" (ie: 192.5.0.0/16, 192.12.0.0/16, 192.16.0.0/16, etc.) for
this.

Timetable for implementation:  immediate