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

[William Herrin]

On Tue, Nov 17, 2009 at 1:09 PM, George, Wes E [NTK]
<Wesley.E.George at sprint.com> wrote:
> From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin
>>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.

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?



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


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.


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




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

I'll try to clarify that in the next draft.


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


>> 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 [is] completely in
> use. Reserved space is not.

Heavily fragmented reserved space creates waste and other problems. In
the sparse example above you needed to assign a /32 to someone, you'd
have to go back for more address space or allocate 32 disaggregate
/37's. With this proposal's method, that /32 is readily doable, as is
a /30. Free space fragmentation is not *as bad* as allocated space
fragmentation, but it's still bad.



On Mon, Nov 16, 2009 at 7:40 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> On Nov 16, 2009, at 4:27 PM, William Herrin <bill at herrin.us> wrote:
>> 6.2.10 Organization
>>
>> An organization under section 6 is either:
>>
>> one or more legal entities under common control or ownership, or
>>
>> one such legal entity which operates a strictly separate network from
>> the others.
>>
>>
>> Thoughts? Alternatives?

> Another consideration is Multiple Discrete Networks.

Hi Scott,

If I can duck the issue for now, I'd like to see that addressed in a
later policy. I don't see Multiple Discrete Networks in current IPv6
policy. I only see it under NRPM 4.5.

The proposal helps a little by allowing orgs to get several distinct
blocks. In theory that will at least allow folks with a small number
of discrete networks to get started. But more work will probably be
needed to assess what's fair and whether it should be treated as a
third measurement vector so that ISPs can filter differently.

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