owen at delong.com
Mon Sep 17 18:16:03 UTC 2012
On Sep 16, 2012, at 20:23 , Randy Bush <randy at psg.com> wrote:
> [ yes, there are a lot of idiots out there. this is not new. but ]
>> "We are totally convinced that the factors that made IPv4 run out of
>> addresses will remanifest themselves once again and likely sooner than
>> a lot of us might expect given the "Reccomendations" for "Best
>> Practice" deployment."
> while i am not "totally convinced," i am certainly concerned. we are
> doing many of the same things all over again. remember when rip forced
> a homogenous, often classful, mask length in a network and we chewed
> through /24s? think /64 in ipv6, except it's half the bits not 1/4 of
> them. remember when we gave out As and Bs willy nilly? look at the
> giant swaths of v6 we give out today in the hopes that someone will
> deploy it.
> and don't bs me with how humongous the v6 address space is. we once
> though 32 bits was humongous.
We thought 32 bits was humongous in the context of a research project
that would connect universities, research institutions and some military
In that context, 32 bits would still be humongous.
Our estimation of humongous didn't change, the usage of the network
changed dramatically. The experiment escaped from the laboratory
and took on a life of its own. Once that happened, the realization that
32 bits wasn't enough was very nearly immediate.
The IPv6 address space offers 61 bits of network numbers each of which
holds up to 64 bits worth of hosts. Obviously you never want to fill one
of those subnets (nor could you with any available hardware), but it means
that you don't have to waste time thinking about rightsizing network
I won't say we will never run out of IPv6 address space, but I will say
that I'll be surprised if IPv6 doesn't hit a different limit first.
Guess what... If it turns out that our current behavior with respect to IPv6
addresses is ill-advised, then, we have 6+ more copies of the current
IPv6 address space where we can try different allocation strategies.
Rather than fretting about the perils of using the protocol as intended,
let's deploy it, get a working end-to-end internet and see where we stand.
More information about the NANOG