Policy Proposal 103: Change IPv6 Allocation Process - revised

[Member Services]

The proposal originator submitted a revised version of the proposal.

The AC will review this proposal at their next regularly scheduled
meeting and decide how to utilize the proposal. Their decision will be
announced to the PPML.

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal 103: Change IPv6 Allocation Process

Proposal Originator: William Herrin

Proposal Version: 1.1

Date: 20 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 6.3.5 sentence 2.

Strike "/NIR" from NRPM section 6.5.6.

In section 6.9 strike NRPM "/LIR" at the end of paragraph 1 and all of
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.3.4 paragraph 4 with:

Further, RIRs should apply allocation practices that minimize route
disaggregation.

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. Where the prefix
length of such registrations differs from the standard lengths in
6.5.9.1, it shall count as a registration of the next longer length.

The above notwithstanding, ARIN is authorized to standardize the
prefix lengths within these previously-allocated address pools in a
manner approaching 6.5.9.4 by increasing the prefix length of all
registrants within a particular pool to some specific minimum prefix
length for the pool.

Add NRPM section 6.2.10 as follows:

6.2.10 Organization

An organization under section 6 is either:

one or more legal entities under common control or ownership, or

one such legal entity which operates strictly separate networks from
the others.

Add NRPM section 6.5.9 as follows:

6.5.9 Regular IPv6 Allocations

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

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

6.5.9.3 ARIN shall register no more than one address block of each
prefix-length for any single organization. These blocks may be
registered simultaneously. Renumbering of existing blocks is not
required to receive additional blocks.

6.5.9.4 ARIN shall allocate IPv6 addresses from pools such that the
identity of the allocation pool serves to classify the expected prefix
length 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 happens to the existing (legacy) IPv6 allocations and
assignments?

A. An organization will be entitled to retain their existing
allocations indefinitely if they so desire. If the prefix length does
not match one of the standard prefix lengths then it will be treated
as the next smaller prefix length for the purposes of determining
eligibility for further IPv6 allocations. To discourage unnecessary
disaggregation, the prefix length of this "legacy" allocation will not
be expanded even if there is room in the pool to do so.

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 does standardize prefix lengths within the legacy pools in
6.5.7 mean?

A. Wes George pointed out that depending on the rules ARIN has
followed with respect to leaving space between allocations, it may be
possible to standardize the existing pools on some prefix length as
well. If it is possible, folks should become able to better filter
disaggregation in those pools too.

So, for example, if ARIN allocated a /32, a /31 and a /30 from the old
/32 pool and reserved a /28 for each allocation to expand, ARIN could
peremptorily increase all three allocations to either /28 and then
publish that the exact prefix length in that pool is /28.

Another example, if ARIN allocated a bunch of /32's and a /26,
reserving /28 for each allocated /32, ARIN could increase the /32's to
/28 and publish that the minimum allocation size for the pool is /28.
Instead of the /26 registrant being able to disaggregate into 64
/32's, he might then be constrained to only disaggregate into 4 /28's.

While this proposal does not require ARIN to take that action, it
authorizes it.

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.

6.3.4 paragraph 4 gives instructions on accomplishing address
aggregation which are, if this proposal's rationale is correct,
counterproductive to encouraging route aggregation. Address
aggregation only matters to the extent that it helps bring about route
aggregation.

6.3.5 sentence 2 speaks to documentation issues that are incompatible
with this proposal. If this proposal's rationale is correct then fees
alone are sufficient to prevent unnecessary waste.

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: following an update of ARIN's IPv6
fee structure.