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

[William Herrin]

On Mon, Nov 16, 2009 at 1:30 PM, George, Wes E [NTK]
<Wesley.E.George at sprint.com> wrote:
> I'm opposed to this proposal.

Hi Wes,

Thanks for the feedback. I hope I can address some of your concerns
and convince you to reconsider some of the others.


> 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.

I don't know how -exactly- how the traffic engineering process would
change under this proposal, if at all. As you rightly point out, it's
a complex dance. This proposal doesn't preclude using disaggregation
for TE, but it does alter the dynamics of the dance.

In the current routing system, TE by disaggregation is a fact of life.
You'll carry it (and pay for it) whether it helps you better
communicate with the remote system or not because you can't
efficiently get rid of it.

Under this proposal, you have the right *and* the ability to reject
disaggregate TE that doesn't do you any good. That doesn't mean you'll
reject all TE. Where your network performs better as a result of
someone else's TE, you're as likely to use it as you are to use BGP
communities today. On the other hand, when Bell South comes along and
offers 4300 routes, you'll probably say: nope. You're cut. I'll take
your aggregate and your top few disaggregates, and that's it. And
you'll have that power.


> of the claimed benefits, so this would at the very least
> need to be a global policy.

Pushing this as a global coordinated policy has two major risks
associated with it.

The first is that it takes much longer to negotiate a global policy,
so IPv6 policy will still be in flux much closer to the IPv4 run-out.
That's not a good thing.

The second is: what if we're wrong? You're right to observe that this
proposal is a radical departure from existing allocation policy. If by
chance it makes things worse rather than better, it would be good if
that only impacted one region and harmed the multinationals not at
all.

I respectfully disagree that we won't see any of the benefits without
a global policy. Operators in the RIPE and APNIC regions are just as
capable of filtering announcements from the ARIN region on
classification boundaries as anyone else is. Whatever benefit there is
to be had, we should see 10%-20% of it in a single-region policy. If
the benefit proves enough, I think it likely that the other regions
will move to adopt similar policies without needing coordination or,
frankly, much of a push.


> 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.

My experience has been that groups like NANOG and, to the extent that
it impacts addressing, PPML are better equipped to address operations
issues than the IETF. That's why many if not most of the successful
RFC's get written as BCPs after the fact.

That's also after I spent the past several years participating in the
IETF's routing WG's. Brilliant folks in the IETF, without exception,
but folks with an operations bent are sparse on the ground.


> 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,

The guidance is very simple: the registrant gets whatever size he A)
requests and B) pays for. That's it.

Look at it this way: who am I to tell you how many IP addresses you
need to do your job? I'm nobody.  You are uniquely well qualified to
strike the best balance between cost and size in your particular
organization. If it isn't absolutely necessary for me to second guess
your judgment in such matters, why should I?


> 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.

If you can afford to put $100k *per year* into IPv6 addresses, well
first, thank you for the investment in IPv6. I appreciate your
efforts. And second off, I want you to have a /24. Really. I do. With
that financial pressure behind your endeavors, I want you to have
every possible advantage.

However... unless you're already in ARIN's X-Large class, I doubt
you're going to be willing to cough up $100k for IPv6 addresses. For
the sake of the argument, let's assume that all the X-Large's will be
willing to do so. How many orgs is that? Less than 1000 worldwide?



> 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.

That's a risk. BUT, the /40 has less than half a percent of the space
in the /32. You'd have to need only a hairs breadth more space than
the /32 with no expectation of growing.

You might add the /40 anyway for the sake of getting a little bit of
TE ability. But that's a feature, not a bug: a well regulated safety
release valve for the folks who really do need a little alternate
routing but aren't big enough to afford the top end allocations where
some disaggregation is likely to be allowed.


> your suggested fees likely don't even cover ARINs costs of administration at the low end.

Absent a need to evaluate the application's legitimacy, you can run it
like the DNS. DNS runs fine under $10 per registration-year.



> 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?

I would expect ISPs to exclude routes within the smaller single-homed
ARIN blocks for precisely that reason. Wouldn't you?

If an org has to choose between paying $1k/year for addresses and
using their ISP's addresses, most will choose to use their ISP's
addresses and deal with the renumbering. If they have to choose
between that and $10k, well, these are single-homed folks. For many,
adding an extra $10k would mean paying three times as much per year
for Internet service than they already do.

Where the extra $10k is not an obstruction, aren't those the same
folks you would expect to qualify for addresses based on utilization
anyway?


> I have no way to aggregate it, and no choice but to carry it.

You do have a choice. I respect that you're not used to making a
choice; you've been able to rely on ARIN to make it for you.

To be frank, the whole point of the $10 /56 level is to put you into a
position as an ISP where you have to make a choice about filtering
because you can't rationally carry those routes on your big iron. I
*DO NOT* seriously expect you to carry single-homed /56's in the DFZ.

I would also offer the following point: if you really would prefer
that ARIN be the gatekeeper for Internet routing policy in North
America then we ought to stop playing the "ARIN isn't responsible for
routing" game. Trying to have it both ways helps nobody.


> 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?

My intention in the proposal was that you keep the /29 for as long as
you want (don't renumber unless you want to!) and it counts under the
new policy as your choice of a /32 or a /24, making you eligible to
add either a /24 or a /32 but not both.

My intention was also that the /29 *would not* be expandable to a /24,
even if ARIN reserved enough space to do so. That's the IPv6 swamp and
we're stuck with it but let's not make it any worse than it already
is.




> 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 [...] compared with other
> options like sparse allocation.

Well, sparse is easy. 200 /56 allocations inside your /29 costs 8 bits
leaving you with /37 as your largest possible remaining allocation.
But, each of the /56's is, at that point, also capable of expanding to
/37 via a netmask change.

With the method described in this proposal, there's no need and indeed
no reason to leave space between allocations, so the same 200 /56's
consume part of one /48, leaving the largest remaining allocation in
your /29 at /30. However, any of the /56's who need more addresses
will add a /48 instead of being able to expand their /56.


>From an address conservation perspective, this proposal's allocation
method should come out way ahead of sparse. Sparse is incredibly
wasteful of address space.


>From a route table conservation perspective, it's a tougher call. Your
99th percentile organization won't afford a /24 and the /56 won't be
routable so that means you can push four routes unless other ISPs
decide to allow more. That's less than half of where we're at in the
IPv4 table today.

On the other hand, your /29 disaggregates to 8 /32's and when ARIN
expands it to a /28, that gives you 16 /32's. And you're big enough
that you'll probably announce them as /32's for the sake of TE. Worse
will happen in the /48 pool where /40's won't be uncommon. And there
will be a /48 pool that you'll have to carry because /48 cutouts of
your /32 won't be routable and multihomed downstreams do still have to
work...

My gut says that the disaggregability of the current /48 pool combined
with it's need to be routable in the current structure and combined
with the desirability of traffic engineering means we're going to have
an IPv4-like bloat while this proposal tends to put a harder limit on
what will end up being allowed in the routing table.



> but I am one of those who is worried about us not learning
> from history.

As am I. What do you make of the following history lesson:

When the prior version of the Internet Protocol was replaced with
IPv4, each organization which had a single address in the old scheme
was assigned a class A, four tenths of a percent of the new protocol's
total address space.


The lesson I take is this: the allocation process for the prior
protocol offers a poor guide for the new one. Try to treat the new
protocol conservatively, not in relation to how the old protocol
functioned, but in relation to how the new protocol functions.

Regards,
Bill Herrin





-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004