[arin-ppml] 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: Tuesday, November 17, 2009 5:47 PM
To: arin-ppml at arin.net
Cc: George, Wes E [NTK]
Subject: Re: [arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process

On Tue, Nov 17, 2009 at 1:09 PM, George, Wes E [NTK]
<Wesley.E.George at sprint.com> wrote:

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

Hi Wes,

I think you make a fair point here. And we have lots of time before
the next meeting.

What kind of analysis would you like to see? Assuming ARIN is willing
to provide the data, how about a simulation based on the IPv4
allocation history, repeating it as if under both the current and
proposed IPv6 methods using a couple of different assumption sets and
then looking to see where it comes out in terms of resulting
allocations, free space fragmentation, disaggregability estimates and
so on?

[weg] yeah I think that gets to the right ballpark. You probably need to assume some percentages as to how much deaggregation will still be done as well as how much of it will be filtered by ISPs in the DFZ.
I think you do need to try to capture some scenarios that assume some percentage of PI /48s displacing what would otherwise be aggregated PD /48s.

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

The nice thing about cash is that balancing what you want with what
you're willing to pay for is a tried and true method for achieving
respectable efficiency.

If you want a /24 badly enough to pay $100k for it, and more to the
point if you think that's an investment you'll recover well on, then
you should have it. If not, what *is* in your budget?

[weg] it's sort of moot what is in my budget. I was simply saying that this seems to be quite a lot outside of the current fee structure, and fairly arbitrary - a simple order of magnitude increase as we go up the scale, and I can't exactly see why, other than an assumption that those large enough that they could have justified a /24 in the current system must have deep pockets, so they won't notice, and it'll keep "the riffraff" out. I think this precludes the new entries, the innovators on the assumption that $100K isn't a lot in the grand scheme of things. Maybe it would be for some...

In the name of leaving no stone unturned, I'd like to discuss
alternatives. If not cash paid to ARIN directly, would you see annual
Internet services budget as a more reasonable measurement vector?
HD-ratio is truly bizarre but is there another non-cash vector you'd
like to discuss? Perhaps a combination method where the smaller
allocations are simple cash while the larger ones require modest
justification but come with a lower price tag?

I'd also like to hear from anyone who would argue that simple cash
*is* the better choice.
[weg] like I said, I think the best balance would be to still have SOME amount of usage-based justification, probably much less stringent, and make the fee more reasonable, but waive the requirement for justification if someone wants it bad enough to pay an exorbitant fee. That said, I'm still not convinced that pricing is the way to enforce efficiency. If your goal is to make the routing table better, then you can implement rigid allocation models without messing with the justification to get one of said allocations. If your goal is to also make it easier to get IPv6 space in order to spur implementation, you can do that by reducing the current justification requirements. I'm not in favor of eliminating them altogether.

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

Upside down. Can't break what never worked. Instead, it sets the
barrier to entry: ISPs don't carry the single-homed /56 block any more
than they carry /26's in the DFZ today. So, just as you have to step
up to a /24 to play in the DFZ for IPv4, you have to step up to some
larger size to be single-homed in IPv6 with PI addresses. Which costs
more. So, you have to make a judgment call about whether not having to
renumber is worth the extra cash outlay.

[weg] Then what's the point in having /56 as an allocation at all, and especially at that price point? It has limited value, primarily for folks that have networks with a requirement for globally unique addresses but no requirement for them to be Internet routable. What I see is far more likely is people raising a ground swell of support for "I have a /56 from ARIN, and you have to route it, because I can't afford to pay you AND pay $1K/year for a /48, you big ISPs are always taking advantage of the little guy..." We didn't always accept /24s in IPv4 either...
Even if I concede that /56 isn't breaking anything not broken today, and maybe it won't end up being routed, I'd argue that even at /48, it presents enough of an incentive that you will increase the number of single-homed PI holders and therefore significantly increase the routing table. At least under the other proposals being discussed, you have to be multihomed to play, so you can make the argument that you're not actively adding something to the routing table that wasn't already there (a multihomed network using PD space is always deaggregated so that you don't have prefix-length matching problems). $1K/year is (usually) still cheaper than a connection to a second provider.

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

For each bit that you increase the mask of your allocation in the
swamp, you double the potential disaggregation you can force on
everybody else. Hence "worse." Also, there's a fairness question.
Grandfathering an existing resource assignment is generally perceived
as fair, but new registrants wouldn't have access to expanding netmask
allocations.

[weg] I don't view expanding an existing network to match the standardized (and only available) netmasks as in any way unfair to new entrants. Plus, I don't see why you couldn't do filtering just the same as you do for the "non-swamp" space to nuke the disaggregation. The more of the swamp space you can get into standardized prefixes, the more you simplify any filtering you attempt to do. Even if there's not discrete blocks allocated for the different sizes, you still can put some assumptions in place about the amount of disaggregation on any of those normalized allocation sizes.

Thanks again,

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.