[arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations
info at arin.net
Thu Nov 5 13:46:45 EST 2009
ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with Policy Development
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
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:
The ARIN Policy Development Process can be found at:
Mailing list subscription information can be found
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
Modify section 126.96.36.199. 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.
Replace the contents of section 4.2.2. Initial allocation to ISPs:
188.8.131.52. Use of /24
The efficient utilization of an entire previously allocated /24 from
their upstream ISP.
184.108.40.206. 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 220.127.116.11.5.
18.104.22.168. Three months
Provide detailed information showing specifically how the initial
allocation will be utilized within three months.
22.214.171.124. 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.
126.96.36.199. 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.
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
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 188.8.131.52
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
184.108.40.206 makes it so that only really large ISPs qualify for an initial
allocation, Section 220.127.116.11 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
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
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: 18.104.22.168/16, 22.214.171.124/16, 126.96.36.199/16, etc.) for
Timetable for implementation: immediate
More information about the ARIN-PPML