Policy Proposal 103: Change IPv6 Allocation Process

[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 103: Change IPv6 Allocation Process

Proposal Originator: William Herrin

Proposal Version: 1.0

Date: 9 November 2009

Proposal type: new

Policy term: permanent.

Policy statement:

Strike NRPM sections: 6.2.3, 6.2.4, 6.2.6-6.2.9, 6.4.3, 6.4.4,
6.5.1-6.5.5, 6.5.8, 6.7, 6.10

Strike NRPM section 6.9 paragraph 2.

Replace 6.2.5 as follows:

6.2.5 Allocate and Assign

For the purposes of NRPM section 6, allocate and assign are
synonymous. Both terms describe any or all use identified in section
2.5.

Replace 6.5.7 with:

6.5.7. Existing IPv6 address space holders

Organizations that received IPv6 allocations under the previous IPv6
address policy are entitled to either retain those allocations as is
or trade them in for an allocation under 6.5.9.

Add NRPM section 6.5.9 as follows:

6.5.9 IPv6 Allocations

6.5.9.1 ARIN shall allocate IPv6 address blocks in exactly and only
the following denominations: /56, /48, /40, /32, /24

6.5.9.2 No utilization-based eligibility requirements shall apply to
IPv6 allocations.

6.5.9.3 ARIN shall accept registration of no more than one address
block of each size for any single organization.

6.5.9.4 ARIN shall allocate IPv6 addresses from pools such that the
identity of the allocation pool serves to classify the expected size
of allocations within. ISPs may use that classification to filter or
otherwise manage their routing tables.

6.5.9.5 For each allocation size, ARIN shall further manage the
allocation pools such that the pool identity serves to classify
whether or not the registrant is Multihomed.

6.5.9.6 ARIN shall offer addresses from pools classified as multihomed
only to organizations which ARIN has verified are multihomed on the
public Internet per NRPM 2.7.

6.5.9.7 Where an organization ceases to be Multihomed it shall
surrender all address allocations from within pools classified as
multihomed within 3 months.


Rationale:

See the implementation notes section below for what should replace
utilization-based eligibility.

The existing IPv6 allocation policy under section 6.5 makes a number
of unproven assumptions about how IPv6 allocations will work.

Unproven: we can make a reasonable guess about how many IPv6 subnets
an organization will need at the outset when they first request IP
addresses. When in all of human history has this ever proven true of
any resource?

Unproven: with sparse allocation, we can allow organizations to expand
by just changing their subnet mask so that they don't have to announce
additional routes into the DFZ. This claim is questionable. With
sparse allocation, we either consume much larger blocks that what we
assign (so why not just assign the larger block?) or else we don't
consume them in which case the org either has to renumber to expand or
he has to announce a second route. Worse, because routes of various
sizes are all scattered inside the same address space, its impractical
to filter out the traffic engineering routes.

Unproven: we can force organizations not to disaggregate for traffic
engineering purposes. Neither any of our experience with IPv4 nor any
of the research in the IRTF Routing Research Group suggests that this
is even remotely practical so long as BGP or any similar system rules
the roost.

Unproven: all non-ISPs can be reasonably expected to get their address
space from ISPs instead of from ARIN. We can certainly operate that
way, but it could prove deadly to the routing table. Any organization
multihomed between two ISPs will need to announce that route via BGP,
regardless of where they get the address space from. We have knobs and
dials in the routers that let us easily filter disaggregates from
distant announcements, but we don't dare do so if there is a
possibility that one of those disaggregates is a multihomed customer
rather than traffic engineering.

Benefits of this proposal:

A. Efficient allocation of IP addresses. Orgs get what they need when
they need it without a great deal of guesswork.

B. Efficient utilization of BGP routing slots. No multihomed orgs will
announce more than five unfilterable routes, and that only if they're
so large that they can afford the price tag for the biggest address
blocks. That's a good thing since IPv6 routes that propagate worldwide
may impose an annual systemic overhead cost on ISPs of as much as US
$16,000 each.

C. Traffic engineering routes are trivially filterable. Any route
longer than the published allocation size can be presumed to be
traffic engineering, not a downstream multihomed customer, thus you
can filter distant small routes with confidence and ease.

D. Fair. No need to define the difference between ISP and not ISP.
Everybody plays by the same rules.

E. No complicated analysis for allocation. You pay for what you want
and get what you pay for. You're either multihomed or you're not.

F. Gets ARIN out of the business of being the gatekeeper for Internet
routing policy. By classifying allocations instead of making
eligibility decisions, ARIN empowers the ISPs to set appropriate
routing eligibility policies instead.

FAQ
Q. Isn't this classfull addressing all over again?
A. Yes.
Classful addressing had a lot of virtues with respect to route
filtering and management. We had to abandon it because there weren't
enough B's for everyone who needed more than one C and there weren't
enough A's period. With IPv6, we don't have that problem. Not yet and
maybe not ever. Perhaps we can have our cake and eat it too.

Q. What if I don't want to accept /56 routes for single-homed users?

A. This policy proposal intentionally and fully places backbone
routing policy in the hands of the ISPs who operate the Internet's
"Default-Free Zone (DFZ)," colloquially known as the Internet
backbone. The author expects that some of the allocations, especially
some of the single-homed allocations, *will not* be routable on the
public Internet. When we hold a general expectation that all of ARIN's
allocations will be routable, we effectively mean that ARIN decides
what the Internet routing policy will be. That's precisely the role
this proposal removes from ARIN's hands and restores to the ISPs.

Q. Spell it out for me. How exactly will pools and size
classifications enable route filtering?

A. Suppose ARIN holds 4000::/12. ARIN might split it up as follows:

4000::/13 -- reserved
4008::/15 -- multihomed /24 allocations
400a::/15 -- non-multihomed /24 allocations
400c::/16 -- multihomed /32 allocations
400d::/16 -- non-multihomed /32 allocations
400e:0000::/18 -- multihomed /40 allocations
400e:4000::/18 -- non-multihomed /40 allocations
400e:8000::/24 -- multihomed /48 allocations
400e:8100::/24 -- non-multihomed /48 allocations
400e:8200::/24 -- multihomed /56 allocations
400e:8300::/24 -- non-multihomed /56 allocations
400e:8400::/22 -- reserved
400e:8800::/21 -- reserved
400e:9000::/20 -- reserved
400e:a000::/19 -- reserved
400e:c000::/18 -- reserved
400f::/16 -- reserved

Now, you're an ISP. Here's a sample routing policy you might choose:

Accept any routes to /32 because anyone paying $10k per year for
addresses is big enough to ride.
For /24 allow 2 bits of traffic engineering too.
Single-homers who won't spend $10k/year on their addresses (smaller
than /32) must use addresses from their ISP. Tough luck.
Accept multihomers down to /48.
The folks paying only $10/year for /56's aren't serious.

Your route filter looks like this:

accept 400e:8000::/24 equal 48
accept 400e:0000::/18 equal 40
accept 400c::/15 equal 32
accept 4008::/14 le 26
reject 4000::/12 le 128

Note how 400e:8000::/24 contains only /48 allocations and you're
allowing only /48 announcements. Since there aren't any /47 or /46
allocations there, nobody in the pool can slip TE routes past you. On
the other hand, you'll get some benefit of traffic engineering from
the super-massive /24 registrants up in 4008::/14 because you're
allowing them to disaggregate down to /26.

Q. If its so expensive to announce routes into the DFZ, why not use
something better than BGP?

A. In 2008 the IRTF Routing Research Group compiled an exhaustive
study attempting to identify the possible ways to improve the routing
system. A draft of the results is at
http://tools.ietf.org/html/draft-irtf-rrg-recommendation-02 . While
there are many promising ideas for how to replace BGP with something
that scales better, we're at least a decade away and probably more
from any significant deployment of a BGP replacement.

Q. Is it really true that multihoming requires announcing a route via
BGP?

A. The short answer is yes. The long answer is more complicated.

Folks have tried very hard to devise multi-vendor multihomed systems
which don't rely on BGP. The only approach that has ever come near
success is dynamically changing DNS records to favor the currently
working Internet connection. "Near" is a relative term here. Such
network architectures are enormously complex and they don't work
especially well. The DNS protocol itself supports quick changes but
the applications which use it often don't. It takes hours to achieve
two-nines recovery from an address change in the DNS and it takes
months to achieve five-nines recovery. Web browsers, for example,
don't immediately recover. Search google for "DNS Pinning."

Q. So the Internet's resulting route policy will be to allow all the
sizes that no major ISP decides to filter and restrict the rest?

A. That's one possible outcome. On the other hand, research in the
routing field suggests that with a sufficiently rich classification
scheme, it may be possible to implement lower priority systems with
provider-independent addresses yet without a global route. Hints for
how such a thing might work can be found in
http://www.cs.cornell.edu/people/francis/va-wp.pdf and
http://bill.herrin.us/network/trrp.html. Such schemes need a rich
classification process at the address allocation level that makes it
possible for ISPs to make reasonable and simple decisions about which
routes should be distributed to every DFZ router and which should not.

Wouldn't that be something: IPv6 provider independent addresses for
everybody without materially increasing the cost of the routing
system.

Q. Why allocate the /48's from a pool only for /48's, /32's from a /32
pool, etc.? Why not allocate from just one pool?

A. If all assignments in a particular pool are /32 then any route in
the /32 pool which is longer than /32 is a traffic engineering (TE)
route. As a router operator you can filter and discard TE routes if
you find they give you insufficient benefit. The routes you filter
don't cost you any money; only the routes you keep carry a price tag.

You can only filter if you're sure they're TE routes... If they're
distinct downstream customer routes and you filter them, there goes
the Internet. Or at least there goes your part of it. See customers.
See customers run... straight to your competitor. Setting up the
distinct pools makes it practical to know with certainty whether the
routes you're filtering are only for TE.

Q. Why allow only one allocation of each particular size?

A. Without the address scarcity issue which drives IPv4 policy, the
primary criteria for IPv6 addressing policy is suppressing the
disaggregation that drives route count in the IPv4 DFZ (NRPM 6.3.8).
Such a criteria is not well served if an organization holds dozens of
discontiguous address spaces as a result of acquisitions, mergers and
and growing a little bit at a time. This proposal says, in effect,
once you've consumed your smaller allocation it's time for you to get
a *much* bigger allocation. The rest of us don't want to pay the
routing table price for you coming back again and again and again.

The proposal could require some renumbering as a result of mergers and
acquisitions. However, with only modest planning on the registrant's
part, the policy its flexible enough to allow that renumbering to
occur over a long period of time so that both cost and disruption are
minimized. In many cases, customer churn can be expected to take care
of much of the renumbering activity all by itself.

Q. What about the IETF recommendations?

A. RFC 3177 recommends that ISPs receive a /32 while downstream
customers receive a /48 assignment by default with so-called "sparse
allocation" to allow those assignments to expand by changing the
netmask. While this proposal supports organizations who wish to follow
those recommendations, it is not this proposal's intention that ARIN
follow RFC 3177.

RFC 3177 is not the gospel truth. It was written back in 2001 when
there was little IPv6 outside of academia and, indeed, little IPv6 at
all. It's an engineers' SWAG about what operations folk should do
that's now 8-years-stale.

This proposal attempts to slow-start IPv6 allocations instead, while
still maintaining the principle of suppressing the routing table size.
As an ISP, consider implementing a slow start for your downstream
customers as well: Give them a /60 initially, add a /56 when they need
it and add a /52 when they run out of the /56. A /60 is 16 /64
subnets. That's an internal LAN, a DMZ and 14 more subnets. Just how
many subnets do you think your normal downstream customer will
actually use?

Q. What happens when organizations merge or split?

A. Entities which merge may renumber out of and return  conflicting
allocations, or they may maintain the existence of the acquired
organization in order to keep it's addresses. Either way it should be
a minor hardship.

Entities which split have a bigger problem since the practical effect
of route filtering may be that only one of them can keep the
addresses. To a large extent, that problem already exists and is a
pain in the rump for IPv4 operations today. This policy doesn't solve
it but it doesn't make it a whole lot worse either. Because
disaggregates are likely to be filtered, this IPv6 policy does gives
us a slightly better guarantee that the rest of us won't get stuck
with the check (in the form of routing slot consumption) when an ISP
goes bankrupt and gets split up.

Q.  What about IPv6 addresses for uses which will not be connected to
the Internet at all?

A. Folks are welcome to get non-multihomed addresses for any purpose
whatsoever. If they do eventually decide to connect to the Internet,
the routes will follow whatever rules the ISPs have imposed for routes
within the single-homed pools.

Q. What about reporting requirements for downstream assignments?

A. Reporting requirements were instituted for the purpose of verifying
eligibility for additional allocations. They have proven useful for
other purposes and the author encourages ARIN to maintain the SWIP
system. Nevertheless, this proposal renders the use of SWIP for IPv6
optional since it is no longer needed to verify eligibility for
allocations.

Q. What if I need more than a /24?

A. This proposal's author asserts as obvious: anyone who defines a
need for more than a trillion subnets should make their case publicly
on PPML, seeking a follow-on proposal that establishes address pools
at the /16 level.

Q. What are the struck sections of the current IPv6 policy and why
should they be struck?

A. 6.2.3 - 6.2.9 define terms that have no meaning or use in the
policy as revised by this proposal.

The 6.4.3 notion of a minimum allocation is obsoleted by the
allocation pools of specific size in this proposal.

6.4.4 is moot as this proposal does not expect registrants to justify
their IPv6 allocation size.

6.5.1 - 6.5.4 and 6.5.8 are replaced entirely by 6.5.9.

6.5.5 is largely moot since it's no longer necessary to confirm
downstream assignments in order to determine eligibility for
additional addresses.

6.7 is moot as it is unnecessary to compute utilization to justify
addresses under this proposal.

6.9 paragraph 2 is moot since utilization is not a factor in IPv6
policy under this proposal.

6.10 is redundant since micro-allocations are trivially accomplished
under 6.5.9.


Implementation notes:

To prevent wasteful consumption of IPv6 address space without a
complicated eligibility regime, the author recommends an initial and
annual fee regime for IPv6 address allocations similar to:

/56 -- $10 USD
/48 -- $100 USD
/40 -- $1000 USD
/32 -- $10,000 USD
/24 -- $100,000 USD
Legacy -- the lesser of the cost of the next larger size or the cost
of the next smaller size times the number encompassed by the
registration.

The above notwithstanding, it may be advisable to discount /40s and
/32s to a much lower price during IPv6's general deployment process in
order to encourage adoption. Folks who already hold /31's should
probably also get a big break on the $20k fee for a good long while,
perhaps until the first time they request an additional block without
offering a plan to return the legacy addresses.

For verification of multihoming, the current way ARIN verifies
multihoming for other parts of it's policy appears satisfactory.
Should that change, the author suggests requiring that the AS#
contacts for at least two AS#'s submit a template indicating that they
intend to originate or propagate IPv6 BGP routes from the registrant's
ORG.

Timetable for implementation: immediate