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

[Member Services]

Draft Policy 2010-5
Reduce and Simplify IPv4 Initial Allocations

On 18 February 2010 the ARIN Advisory Council (AC) selected "Reduce and
Simplify IPv4 Initial Allocations" as a draft policy for adoption
discussion on the PPML and at the Public Policy Meeting in Toronto in April.

The draft was developed by the AC from policy proposal "102. Reduce and
Simplify IPv4 Initial Allocations". Per the Policy Development Process
the AC submitted text to ARIN for a staff and legal assessment prior to
its selection as a draft policy. Below the draft policy is the ARIN
staff and legal assessment, followed by the text that was submitted by
the AC.

Draft Policy 2010-5 is below and can be found at:
https://www.arin.net/policy/proposals/2010_5.htm

You are encouraged to discuss Draft Policy 2010-5 on the PPML prior to
the April Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the community consensus for adopting this as policy.

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

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


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


#####


STAFF ASSESSMENT

Proposal: Reduce and Simplify IPv4 Initial Allocations

Proposal Version (Date): 05 February 2010

Date of Assessment:  17 February 2010

1.	Proposal Summary (Staff Understanding)

Staff understands this policy shifts the IPv4 minimum allocation size to
a /23 and removes the requirement to be multi-homed. It allows ISPs to
request blocks of /23, /22, or /21 from ARIN with a 12-month renumbering
requirement, and to request blocks of /20 or larger with optional
renumbering. Finally, it introduces the idea that an ISP must renumber
out of an ARIN-issued /23, /22, or /21 if it wishes to request
additional addresses from ARIN.

2. Comments

A.	ARIN Staff Comments

•	4.2.2.4 states: "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." This is not declarative policy text and
does not provide definitive direction to the community on how to qualify
for IPv4 resources or to the staff on how to assess requests for IPv4
resources.  If this isn’t a policy requirement, it should be removed
from the policy text and perhaps placed in a best practices guide.
•	4.2.2.5 has confusing uses of the word "initial". The section is
clearly intended to apply to any direct allocation longer than a /20,
including 2nd, 3rd, and nth replacement allocations. But it uses
"initial" allocation too many times. For clarity, staff suggests
removing the word "initial" from both the title and all instances beyond
the first usage of the word.
•	The policy lays out numerous renumbering requirements and timeframes,
however it does not specify any repercussions for non-compliance,
leaving the ARIN staff on its own to determine the course of action.
Staff experience has shown us that adherence to renumbering requirements
in existing policies has often been problematic for some organizations.
When a company does not adhere to their renumbering commitments, it
forces ARIN to make a judgment call that could potentially impact an
organization’s business and productivity.

B.	ARIN General Counsel

                    "At this time counsel has no significant legal
comments.”


3. Resource Impact

This policy would have a moderate resource impact.  It is estimated that
implementation would occur within 3 - 6 months following ratification by
the ARIN Board of Trustees. The following would be needed in order to
implement:

•	New software or tools to effectively track the status of multiple
instances of renumbering requirements
•	Construction of a detailed implementation plan to include how to work
with customers who fail to meet the renumbering requirements
•	New guidelines
•	Staff training


4. Proposal Text

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.