[arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process

[George, Wes E [NTK]]

I'm opposed to this proposal.

I like the spirit behind it. However, I'm not sure how well it would actually work in practice (as you have alluded to regarding things like preventing deaggregation), - I simply don't think that it's really practical to filter traffic-engineering deaggregations without providing networks an alternate method to manage their traffic - there's a real quagmire in determining what is "distant" and therefore ok to filter vs what is not, especially when you're trying to do it with standardized route-policies.
While I agree that RFC3177 is outdated and ARIN already isn't following it to the letter, ARIN doing this sort of radical change on their own would have near zero of the claimed benefits, so this would at the very least need to be a global policy. In my opinion, an IETF draft that updates RFC3177 would be even more helpful, since that would help to discuss the implications to the routing system within the body most equipped to evaluate it.

There are also fundamental questions in my mind around the execution of this proposal.
I have a major problem with the fact that this proposal as written doesn't seem to give any guidance as to how ARIN staff would determine who gets what size allocation, nor how to manage when it is ok to give a single org more than one block (of a different size). The rationale seems to imply that we're no good at predicting use, so let's stop trying, and just give everyone whatever size block they're willing to pay for.
Until people have really gotten away from the scarcity mentality that accompanies IPv4 addressing, barring any sort of justification requirement, most entities that can afford it will ask for a /24 simply because they can. It will take years for people not to view IPv6 as a scarce resource, especially if the IPv4 runout is nasty.
Raising the price won't work, because you don't want to punish those that have a network that is actually big enough to justify that size, and you'd have to raise it significantly to actually change behavior for those who don't. Your recommendation of increasing the high-end fees to well north of where they are today means that you are actually creating a disincentive to building big networks under one block - instead of getting a /24 because I need a bit more than a /32, I might get a /32 and a /40, thereby adding an entry in the routing table to save money. While $100K isn't a lot of money compared with your average cable company or mobile operator's annual capital budget, it *is* punitive given the increase over the previous size. This is especially true assuming that IP address resources are still supposed to be allocated based on need, and the primary thought here is that we have an embarrassment of riches and therefore no reason to constrict our allocations like we did in IPv4. Maybe you end up with two different fee structures, one for those who can justify the space based on usage and one for those who can't, but that's awfully complicated for what is largely an unproven benefit. It also ends up that the few large block holders are subsidizing the smaller block holders, because your suggested fees likely don't even cover ARINs costs of administration at the low end.

Then, allowing the same org to go back to the well for another block of a different size with the same (zero) justification, encourages wasteful and lazy use of address space, and will actually result in more addresses in the table; instead of having to subnet my current /24 so that I have space available for some new project, I might just go ask for another /40 or /32. It's so cheap under your proposed fee structure, it's easier to buy more than it is to free up what I have via renumbering. Not saying that people can't play the H-D ratio to end up with that result anyway, but I think this makes it worse.

Also, I think this moves towards a system where there really is no concept of/use for PD space anymore. What incentive is there to get PD space and be forced to renumber if you change ISPs when you can so easily (and under your suggested fee structure, cheaply!) qualify for PI space? This means that a lot of the existing aggregation that takes place in the DFZ today due to larger ISPs aggregating blocks that they allocate to small, statically routed or singly-homed BGP-speaking networks downstream of them would just disappear, to be replaced with discrete blocks in the routing table. I think this is far worse than any benefit derived from reducing the need for some networks to come back to get a second block because they have used up their first one, or easier filtering on address boundaries. Even if you increase the small block prices, it's still justified against the cost of renumbering to change upstreams, so there's a big incentive for small companies to get their own blocks, if the discussion on some of the other "open IPv6" policies are any indicator.
Contrary to what is claimed in this proposal, I view this specific side effect as very much ARIN dictating routing policy. Maybe not overtly, but the end result is the same - you're enabling a lot of networks that would otherwise use PD space to become PI and therefore occupy its own slot in the routing table, because I have no way to aggregate it, and no choice but to carry it.

You also need to address how existing allocations that don't fall on those rigid boundaries would be handled. My organization, for example, has a /29. That means ARIN needs to be able to give me the extra bits in order to magically make that into a /24. If ARIN didn't allocate sparsely enough to make that work and I have to renumber, how long do I have? How do I justify the cost of triggering a renumber on a network I *just* rolled out? If I'm reading your fee recommendations right you have a grandfather clause, and that would make a lot of the supposed benefits of this proposal go away too, because no one will want to renumber, especially if it means going from $16K in annual fees to $100K, meaning that we've just lost our deterministic filtering.

Another question I do think is largely unanswered is some manner of estimate of how much address space (in terms of number of networks) going back to something like classful address allocation would cost us, bumped up against what we think the world might look like (in terms of rough numbers of IPv6 blocks in use) in 10 years time, and compared with other options like sparse allocation. Your basic supposition is that there was nothing wrong with classful addressing, we just didn't have enough bits to match the number of networks that we would have needed. Since you don't seem to be advocating the rigidity of routing (no subnetting) that came with classful routing, I more or less agree, but I am one of those who is worried about us not learning from history. How many times in the past has someone uttered some variance of the phrase "but this is more than we could need in a hundred years!" only to be very, very wrong. While IPv6 is a *lot* of address space, it's not infinite. I think we need to be careful with changes such as this unless we have some defensible math that tells us we won't be back here in a few years' time looking to undo this and reclaim address space from our new "class A holders" because we've run out of addresses due to the number of /24s we had to allocate. It's far easier to fill in the sparsely populated allocations that were reserved for existing networks to grow with new requestors than it is to reclaim address space that's already allocated, so I'm not buying the argument that this is no more wasteful than sparse allocation.

FWIW,
The entirety of the IANA available space right now is a /3. That works out to 2M /24s.
ARIN has 5 /23s and a /12 - that's 4K /24s, assuming nothing was allocated, or 1M /32s.
Like I said... A lot, but not infinite.

Sorry for the book.

Thanks,
Wes George

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services
Sent: Monday, November 09, 2009 2:32 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process

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




_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.