[arin-ppml] Controlling the IPv6 address consumption rate

William Herrin bill at herrin.us
Wed Oct 13 16:17:33 EDT 2010

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

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.


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


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!"

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

More information about the ARIN-PPML mailing list