Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
1. Policy Proposal Name: A Modest Proposal for an Alternate IPv6 Allocation Process
2. Proposal Originator
1. name: William Herrin
2. email: bill@herrin.us
3. telephone:
4. organization: Self
3. Proposal Version: 1.0
4. Date: 6/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 blocks used for allocation.
ARIN shall reserve 3 blocks of IPv6 addresses for the purpose of address allocation under
section 6.11.
The first block shall be used solely for making /48 allocations. ARIN will make no larger
or smaller allocations from this block.
The second block shall be used solely for making /32 allocations. ARIN will make no larger
or smaller allocations from this block.
The third block shall be used solely for making /24 allocations. ARIN will make no larger
or smaller allocations from this block.
ARIN shall publish the locations of these blocks 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 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 downstream IPv6 service such that they will run out of space in the /48
within one calendar 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 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, 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 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 calendar 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 /32 within the /32 block and longer than /24 within the /24
block. 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 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 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 about actual 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 classfull 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 its 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. 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 close to success 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 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 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. 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 blocks
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
END OF TEMPLATE