Draft Policy 2010-5: Reduce and Simplify IPv4 Initial Allocations [Archived]

Status: Abandoned

Tracking Information

Discussion Tracking

Mailing List:

Formal introduction on PPML on 23 February 2010

Origin - Policy Proposal 102

Draft Policy - 23 February 2010 (with staff assessment)

Abandoned by AC - 28 April 2010

Additional staff comment - 14 February 2011

Public Policy Mailing List

ARIN Public Policy Meeting:

ARIN XXV

ARIN Advisory Council:

AC Shepherds:
Heather Schiller and Robert Seastrom

• 17 December 2009
• 15 January 2010
• 18 February 2010
• 18 March 2010
• 21 April 2010

ARIN Board of Trustees:

Revisions:

Implementation:

Draft Policy 2010-5
Reduce and Simplify IPv4 Initial Allocations

Version/Date: 23 February 2010

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 or equivalent 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. Multihomed organizations holding a /22 or a /21 at the time of policy adoption are exempt from having to renumber and return for a period of 12 months after this policy is adopted.

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