[arin-announce] Policy Proposal: A Modest Proposal for an Alternate IPv6 Allocation Process

[Member Services]

Please be advised that the following policy proposal has been
posted to the ARIN Public Policy Mailing List. All discussion of the
proposal must take place on the PPML.

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


1. Policy Proposal Name: A Modest Proposal for an Alternate IPv6
Allocation Process

2. Proposal Originator: William Herrin

3. Proposal Version: 1.0

4. Date: 5 June 2009

5. Proposal type: new

6. Policy term: See 6.11.7 below.

7. Policy statement:

Add section 6.11 as follows:

6.11 Alternate IPv6 allocation process

Section 6.11 offers an alternative to the address assignment process
laid out in sections 6.5 and 6.10. Except where explicitly mentioned,
no elements of the process here are binding on the process in those
sections and vice versa.

6.11.1 ARIN pools used for allocation.

ARIN shall reserve 3 pools of IPv6 addresses for the purpose of
address allocation under section 6.11.

The first pool shall be used solely for making /48 allocations. ARIN
will make no larger or smaller allocations from this pool.

The second pool shall be used solely for making /32 allocations. ARIN
will make no larger or smaller allocations from this pool.

The third pool shall be used solely for making /24 allocations. ARIN
will make no larger or smaller allocations from this pool.

ARIN shall publish the locations of these pool such that folks
operating routers in the Internet Default-Free Zone can filter route
announcements based on these published sizes if they so choose.


6.11.2 Initial allocation

6.11.2.1 Initial allocation criteria

To qualify for an initial allocation of IPv6 address space, an
organization must:

a. Be multihomed in the ARIN region with at least two different
Internet Service Providers, both of whom agree to propagate the
organization's IPv6 prefix into the Internet Default-Free Zone.

b. Have already obtained an Autonomous System Number.

c. Do not already hold a /48 or shorter IPv6 allocation from ARIN
under any current or prior policy.

d. If requesting a /32, hold at least a /18 of IPv4 addresses

e. If requesting a /32, have implemented either SWIP or RWHOIS for all
IPv4 allocations /28 or shorter.

6.11.2.2 Initial allocation size

If requested, a /32 from the pool reserved for assigning /32's.
Otherwise a /48 from the pool reserved for assigning /48's.


6.11.3 Extra /32 allocation

Organizations which hold a /48 from ARIN are eligible for an
additional /32 allocation from the pool reserved for /32 allocations
if they:

a. Demonstrate that they continue to meet the qualifications for the
/48 assignment.

b. Do not already hold a /32 or shorter allocation from ARIN under any
current or prior policy.

c. Plan to provide IPv6 service such that they will run out of space
in the /48 within one year of making the second application.

d. Have implemented either SWIP or RWHOIS for all downstream
allocations shorter than /64.

e. Agree to return all ARIN allocations longer than /33 except for one
/48 allocation to ARIN within one year of receiving the /32
allocation. Although 6.11.2 permits only one /48 allocation to an
organization (hence no need to return anything), they may hold more
than one due to mergers, acquisitions, policy changes, etc. These
extras must be removed from the DFZ BGP table and returned to ARIN
once a /32 is assigned.


6.11.4 Extra /24 allocation

Organizations which hold a /32 from ARIN are eligible for an
additional /24 allocation from the pool reserved for /24 allocations
if they:

a. Demonstrate that they continue to meet the qualifications for the
/32 assignment.

b. Do not already hold a /24 or shorter allocation from ARIN under any
current or prior policy.

c. Plan to provide downstream IPv6 service with address space such
that they will run out of space within the /32 within two years of
making the third application.

d. Return all /33 or longer allocations to ARIN prior to making the
/24 application.

e. Agree to return all allocations longer than /25 except for one /32
allocation to ARIN within one year of receiving the /24 allocation.


6.11.5 Additional allocations

No additional allocation beyond the single /24 is contemplated for a
single organization at this time. No known usage pattern could require
more than a /24 of IPv6 address space without egregious waste.


6.11.6 Advice to multihomed users

ARIN advises multihomed end-users that section 6.11 has been
intentionally crafted to enable folks operating routers in the
Internet Default-Free Zone to filter out route announcements longer
than /48 within the /48 pool, longer than /32 within the /32 pool and
longer than /24 within the /24 pool. Accordingly, it is probable that
addresses assigned by an ISP instead of by ARIN will only be usable
with that one ISP.


6.11.7 Policy term and re-evaluation

Three years from policy implementation, ARIN staff and the ARIN
advisory council shall separately review the efficacy of address
allocations made under both section 6.11 and sections 6.5 plus 6.10.
Each shall recommend to the ARIN Board of Trustees that either 6.11 or
both 6.5 and 6.10 be struck from the NRPM. The board shall review the
recommendations and either strike section 6.11, strike both sections
6.5 and 6.10, or take no action, retaining both policies.



8. Rationale:

The IPv6 allocation policy under section 6.5 makes a number of
unproven assumptions about how IPv6 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 pool, its impractical
to detect or 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
mutlihomed 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 disagregates 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 and not before without a great deal of guesswork trying
to define that need.

B. Efficient utilization of BGP routing slots. Few multihomed orgs
will ever announce more than two unfilterable routes.

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 the first allocation. You're either
multihomed or you're not. If you're multihomed, you qualify.

F. For those who can live within the /48 there are distinct
advantages: no swip or rwhois reporting and the generic end-user
annual fee instead of the ISP annual fee. Once you're up to a /32, you
pay the ISP annual fee. As a result, ARIN doesn't have to scrutinize
the /32 requests too closely either.

G. No disruption to the prior IPv6 allocation policy until this new
one proves itself.


FAQ

Q. Isn't this classful addressing all over again?

A. Yes, with a twist. Now you have to fully use a class C before you
can get a class B and fully use a class B before you can get a class
A. And by the way, there are potentially 16 million class A's, not a
mere 200.

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. Why prevent single-homed users from getting ARIN addresses?

A. Any IPv6 allocation from ARIN must be announced into the Internet
DFZ via BGP in order to use it on the Internet. That costs a lot of
money, more than $10k per year according to
http://bill.herrin.us/network/bgpcost.html   Worse, it spends other
people's money: no practical system exists for recovering the cost of
a consumed routing slot from the folks who announced the route.

If you don't get an allocation from ARIN then you have to renumber in
order to change ISPs. That can cost a lot of money too. Sometimes far
more than $10k. But it spends only your money, not somebody else's.

Finally there's the technical consideration: regardless of who assigns
the addresses, a multihomed system must announce a route into the DFZ.
That's the way BGP works and we're stuck with it for at least another
decade. So why not let the multihomed org get his IP addresses from
ARIN? By contrast, a single-homed system works just fine with its
addresses aggregated inside the shorter route announced by its ISP.


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

A. Last year 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, its true. The long answer is more complicated.

Folks have tried very hard to devise multi-vendor multihomed systems
which don't rely on BGP. Some even work OK for networks containing no
Internet servers.

The only non-BGP approach that has ever come close to success for a
system that hosts Internet servers is dynamically changing DNS records
to favor the currently working Internet connection. "Close" is a
relative term here. Such network architectures are enormously complex
and they don't work for a useful definition of "work." 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. 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 and all multihomed
entities get their IP addresses directly from ARIN then any route in
the /32 pool which is longer than /32 is a traffic engineering route.
As a router operator you can filter and discard a traffic engineering
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 traffic engineering
routes... If they're 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 for certain that the
routes you're filtering are only for TE.


Q. Why make folks return all but one /48 to get a /32 and all but one
/32 to get a /24?

A. Without the address scarcity issue which drives IPv4 policy, the
primary criteria for IPv6 addressing policy is suppressing the route
count in the IPv6 DFZ. Such a criteria is not well served if an
organization holds dozens of discontiguous address spaces as a result
of acquisitions, mergers and the like. With the return policy in
place, organizations will generally only announce one or two primary
routes, routes necessary for the correct operation of the Internet.
Any other announced routes will be for traffic engineering. Because of
the segregated pools from which the allocations come, those traffic
engineering routes can be filtered by anyone who gains insufficient
advantage from them without harming the Internet as a whole.

The return policy does require some renumbering activity. However,
with only modest planning on the registrant's part, the policy is
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 if the first allocation from the /48 is a /48?

A. RFC 3177 recommends that downstream customers receive a /48
assignment by default. Obviously there's a mismatch here if the ARIN
allocation is also a /48.

The short version is that RFC 3177 is not the gospel truth. It's based
on the IPv6 allocation model embodied in ARIN policy section 6.5 where
we try very hard to assign all the addresses you'll ever need up front
so that you only ever use one routing slot. This proposal attempts to
slow-start IPv6 allocations instead, while still maintaining the
principle of suppressing the routing table size. With a /48 allocation
under this proposal, 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. There
are 16 /52's in your /48, or 4000 /60's. Plenty to get started. And a
/60 is 16 /64 subnets. That's an internal LAN, a DMZ and 14 more
subnets.


Q. What happens when organizations merge or split?

A. Entities which merge will want to renumber out of and return one of
the allocations so that they don't run into grief when they go to get
the next larger allocation from ARIN. If done gradually, this should
be a minor hardship.

Entities which split have a bigger problem since 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 expected 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. Why allow folks announcing IPv4 /18's to jump straight to a /32?

A. We're not really starting from scratch here and there are plenty of
IPv6 addresses. Why make extra useless work for large ISPs who -are-
going to use more than a /48? There are far fewer than 30k orgs
holding /18s. How much grief should we cause them in order to save at
most one whole /25?


Q. Why not just replace section 6.5 instead of running this allocation
system in parallel?

A. The most experienced user of IPv6 still has only a fraction of the
experience that we have with IPv4. Yet the network operating model
proposed by the IETF is radically different than the IPv4 model. The
author believes that the IETF recommendation is based on an errant
operating model, but he respects those who believe otherwise. The
author also believes that competition is a good thing and history
backs up this claim. Since little long term harm can come from briefly
running both systems in parallel, allowing them to compete directly
will result in the selection of the superior system.


Q. You've covered multihomed and single-homed. What about IPv6
addresses for uses which will not be connected to the Internet at all?

A. "ULA Central" or an idea like it is not addressed in this policy
proposal. If desired, it should probably be implemented in a separate,
parallel policy. The author observes that all of 2002:0a00::/24 is
available for your offline use and there are plenty of others if you
don't like that one.


Implementation notes:

Initially, ARIN may want to use sparse allocation inside each of the
three reserved pools until the policies are re-evaluated in three
years. That way if section 6.11 is retired in favor of section 6.5,
the 6.11 assignments may be able to grow by changing the netmask as
intended in section 6.5. If 6.11 is retained, sparse allocation should
cease.

Because IPv6 addresses are plentiful and the largest possible
allocation under this policy is /24, the author recommends against
explicit criteria for efficiency at this time. Instead, ARIN should
consider selecting a fee schedule for /48, /32 and /24 allocations
which discourages asking for more addresses than are really needed.
Something along the lines of $100, $10k and $100k per year
respectively might do nicely.

Under this proposal there is no difference whatsoever between an
allocation and an assignment. The two words should be treated as
synonyms.


9. Timetable for implementation: immediate; re-evaluate in 3 years