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

[George, Wes E [NTK]]

-----Original Message-----
From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin
Sent: Monday, November 16, 2009 4:52 PM
To: George, Wes E [NTK]
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process

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.

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

[weg] I'd argue that I have the right and the ability to reject disaggregate TE blocks today if they aren't helping my network. However, you're right in that it takes some fairly complex automation to digest the current allocations to determine what is filterable and what is not. Your policy does make that easier. However, I'm not sure that benefit in and of itself is enough to change my opinion that this isn't a good idea.

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

[weg] agreed, but I don't think that it will have so much of an impact that an extra 6 months or a year (or more) would make enough difference that it doesn't make sense as a coordinated policy.

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.

[weg] that's fair. However, to quote Homer Simpson..."can't someone else do it?" I'd rather not play guinea pig in our region.

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.

[weg] I think this hits on my concern - Your opinion and my opinion as to whether this is a good idea are still just opinions without some more analysis. We don't *know* that this will be any better. I'd rather you show your work - do some analysis of the current routing table to draw some conclusions about how much of an improvement we might actually see from something like this, both if just one region does it and if all regions do it BEFORE we implement it. Even if it's fairly simplistic and uses the IPv4 table + classful allocation (allocate the entirety of IPv4 space as many times as necessary), I'm not keen on recommending such a radical change without more analysis to back it up.

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

<snip>
Brilliant folks in the IETF, without exception,
but folks with an operations bent are sparse on the ground.

[weg] no argument on lack of operator expertise and representation.
Consider this a PSA to get more people on this list involved at IETF and vice versa. ;-)
However, that aside, as I said above, this is a recommendation that needs more analysis as to its efficacy and impacts, not necessarily more operators to provide opinions. IETF (and IRTF) is good at analysis.

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

[weg] fair enough, but why are you trying to discourage me from asking for a /24 by making it prohibitively expensive then? If we're really trying to reduce the amount of overhead and justification because IPv6 is so vast and non-scarce, then make it easier to justify, don't remove the justification altogether and replace it with some pseudo-scarcity pricing model..

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

[weg] that's exactly my point. I'm in X-Large today, but there's a  W I D E  gap between the current fee and your proposed, even if I look at multiple org-IDs to add up the total money I'm paying to ARIN. I can afford 100K/year as an "investment in IPv6" but I would rather invest that in, you know, capital to actually make IPv6 work on my network, rather than a throwaway expense. I see no reason I should have to pay that much for a resource that is, by virtue of your advocating no use-based justification, *not* scarce. You have no way to discourage people for asking for /24s that they don't need without punishing those who actually do need one if you try to control it with pricing alone.

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

[weg] ok, that was a bad example, but the mention of multiple discrete networks jogged my memory on the example I should have given, which is that today, many companies have multiple ORG-IDs, all of which are justifying their own IP space and paying their own fees. What's to stop me from using that as a means to get 3 /32s instead of the 1 /24 I really should have gotten? Your proposed text (your second message) does cover that by prohibiting it, but I'm sure there will be another loophole. I was a good boy and got all of my IPv6 space with the intention of breaking it up across all of my business areas instead of getting several smaller blocks, one for each org. If I have 3 orgs, I'm still saving myself $70K/year by getting each their own /32, which if you look at it selfishly, is more important than the additional routing slots I'm taking up in the DFZ, especially if my hypothetical company is one that doesn't have to carry the DFZ routing table.

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

[weg] no, I wouldn't. See below.

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?

[weg] I don't know, but every time we try to say "renumbering is easy" or "renumbering isn't a barrier to changing ISPs" we get shouted down by a bunch of folks who as far as I know are actual, real-live small ISPs who beg to differ. So I'll pose the question to the group - Is $1K/year a reasonable investment to ensure that you get PI space? What about $10K? What about $10? Could you live on a /56?

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

[weg] I think you have a fundamental flaw in this assumption, and it basically breaks routing for any single-homed customer who chooses to use PI space. Let's say I'm opening "Wes's IPv6-only ISP" out of my garage. I get my $10 /56, and buy service from a single upstream. I'm doing static routing - I have a default, my upstream has a static route to me, which they are redistributing into BGP. It's PI space. How exactly would any ISP beyond the one I'm currently connected to (you know, the rest of the DFZ) be able to reach my lil' ol' /56 if my ISP isn't announcing it to the rest of the DFZ internet, or the rest of the DFZ internet isn't accepting my upstream's announcement? It's not like anyone is announcing a larger aggregate block, because the person who got the next /56 in that block may well be on a completely different ISP. Do you expect ISPs to just turn on auto-summary and hope that they get lucky enough to find some blocks that aggregate? Therefore that /56 is useless unless my ISP is so well-connected that I don't need to talk to anyone else, or I don't actually need routable space. So the "Sophie's choice" that you leave big ISPs with is either, carry a significant increase in routing state, or partition the internet. Yay, sign me up! Thanks for the "choice", ARIN! While I used /56 in this example because it's cheap, I think the same argument applies for /48s. The RIRs have already sort of forced this issue by allocating direct PI /48s, so I don't see why /56s would be any different.

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.

[weg] I never said I'd prefer ARIN to do it. I said that your policy, and things like direct /48 PI allocations is forcing ARIN to do so, as I detailed above.

> 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.
[weg] if that's your intention, I didn't read that from the policy or implementation notes. You should probably make that clearer. Also, I'm unclear as to how being able to bring blocks to standard sizes through changes in bitmask would make the "IPv6 swamp" worse.

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

[weg] Thanks for that, but I think you missed a fundamental distinction - allocated space (that is, ARIN actually gave it to an end network) is for all intents and purposes completely in use. Reserved space (that is, ARIN blocked it off as a means to expand an existing network's allocation via bitmask change in the future) is not. Therefore when space waste/availability becomes a concern, we can reclaim the reserved space. It's much harder to get back allocated space. See also IPv4 legacy holders for evidence of such.

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

[weg] I take a different lesson - no one could conceive of exhausting the available address space given the demands of the current network and what they could imagine for future demands, so they allocated easy, large blocks on the assumption that the original networks would grow into them sooner than those not present on it yet, since they'd been using the network the longest.
Further, efficiency of address use wasn't important because there was so much of it available. If anything I'll concede that some of the decisions made in earlier implementations of the protocol were driven by the hardware limitations at state-of-the-art, and so optimal was replaced by doable. In that, I think your proposal might have merit, provided you can show some analysis that it actually helps get us around the (hopefully) short-term limits of the routing system in a way that justifies the sub-optimal use of the space.

Thanks,
Wes George

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.