[arin-ppml] Controlling the IPv6 address consumption rate

[William Herrin]

On Wed, Oct 13, 2010 at 11:58 AM, Owen DeLong <owen at delong.com> wrote:
> On Oct 13, 2010, at 7:43 AM, William Herrin wrote:
>> 8 bits of conservation worries me. We badly underestimated at the
>> start of IPv4. I'd be more comfortable starting with a more
>> conservative number (like 12 or 16) and then working down to 8 bits of
>> conservation after we gain a decade or two of experience.
>
> Yeah, I think that's pretty absurd.  Conserving 255/256ths of the address
> space is somewhat absurd to begin with, but, hey, why not... Plenty of
> room in the 1/256th we're talking about, so, OK

Hi Owen,

I should clarify that I'm worried about actually enforcing 8 bits of
conservation over time. We'll keep finding reasons why we need more
bits for something else, and the century that 8 bits gives can't lose
many bits before IPv6's lifespan shortens below 20 years.


>> 8 bits also means you have only 14 bits left for the nice-to-haves. If
>> you spend 12 of those bits bringing the downstream end-user assignment
>> from the austere /60 to your preferred /48, you'll have only 2 bits
>> left. That doesn't give you much flexibility with your routing. Are
>> you sure you wouldn't rather put 4 of your bits to bring the
>> assignment up to /56 and use the remaining 10 to do smarter things
>> with your routing hierarchies? 256 LANs is a lot of LANs for all but
>> the largest customers.
>
> And here's where you run off the rails again by miscounting the bits.

I didn't exactly do anything deep with the math. Where do you think I
miscounted?

128 bits total
- 64 bits LAN
- at least 4 bits end user assignment
- at least 25 bits of assignments to satisfy 20M users in a big ISP without NAT
- at least 9 bits of 20M-user ISPs to satisfy 7B people in the world
- at least 4 bits to deal with the implications of future technology changes
- 8 bits of conservation to slow v6 depletion versus v4 depletion
= 14 bits remaining.

Take away 12 more bits to bring your end-user assignment from /60 back
up to the /48 that you and Michael want and you've just 2 bits to
spare on routing optimization.

Or take away the extra 7 bits (32 total) you need in the ISP
allocation to do 6rd. Really 8 bits (33 total) since you want native
and 6rd in the same aggregate allocation. That leaves you with only 6
bits for any other routing optimizations or improving the end user
assignment from /60.


Seriously, I understand your argument that it's OK to burn through
2000::/3 and then worry about these numbers in the remaining 7/8ths of
the space. You're not wrong. But there's no miscount. These numbers
are the real deal.



On Wed, Oct 13, 2010 at 11:46 AM,  <michael.dillon at bt.com> wrote:
>> At the same time (maybe even in the same RFC), the IETF decided that
>> end users would not multihome using BGP with multiple ISPs under IPv6.
>> That too is the official standard.
>
> I call BS on this one. If you say "maybe even in the same RFC" then you
> clearly don't know where this statement is or exactly what was written
> or in what context.

Michael,

I must have misunderstood your source and references when you said,
"Yes, those architects strayed from network architecture into
political and economic engineering when they assumed that the
provider-centric addressing scheme would be the only supported way of
building IPv6 networks."

http://lists.arin.net/pipermail/arin-ppml/2006-April/004952.html

Perhaps YOU would explain why YOU believed that the IETF was opposed
to provider independent addresses for multihomed end users?



> The fact is that I believe your analysis is flawed and is based on false premises
> and probably riddled with other problems.

If you'd care to suggest exactly which premises you think are false
and why, we could probably have a useful discussion. It's hard to
argue the merits of someone standing up and shouting, "you lie!"

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