ISP customer assignments

Joe Greco jgreco at ns.sol.net
Mon Oct 5 19:10:59 UTC 2009


> Am I the only one that finds this problematic? 

No, but most of the people who find this "problematic" haven't done
any looking into the matter.

> I mean, the whole point
> of moving to a 128 bit address was to ensure that we would never again
> have a problem of address depletion. Now I'm not saying that this puts
> us anywhere in that boat (yet) but isn't saying "oh, lets just put a
> /64 on every interface" pretty well ignoring the lessons of the last
> 20 years? Surely a /96 or even a /112 would have been just as good.

No, it wouldn't have been.  The sheer usefulness of having things like
stateless autoconfig for many trivial applications should not be
underestimated.

> Lets think longer term... IPv4 is several decades old now and still in
> use. If IPv6 lasts another 50 years before someone decides that it
> needs a redo, with current practices, what will things look like?
> Consider the population at that point and consider the number of
> interfaces as more and more devices become IP enabled. "wireless"
> devices have their own issues to content with (spectrum being perhaps
> the biggest limiter) so wired devices will always be around. That
> means physical interfaces and probably multiple LANs in each
> residence. I can see where each device may want its own LAN and will
> talk to components of itself using IP internally, perhaps even having
> a valid reason for having these individual components publically
> addressable.

Do some math, then.

A /64 handles a single network.  An essentially infinite number of
devices can live within that space, though there are practical limits.
You might realistically have a network for your light switches and a
network for your A/V gear.  You seem to anticipate that, so let's just
say we agree, but I'm going to make a big whopper claim and say that we
should delegate /48 to end users.  This means each user could have up
to 65,536 /64's.  While I can daydream about scenarios that would eat
up a significant fraction of those subnets, I have to also concede that
consolidation is probably possible.

Population today is about 7 billion.  A fairly aggressive long range
report by the UN puts population in 2300 as high as maybe 40 billion,
or about six times our current population.

Let's just pretend we had the 40 billion today.  To come up with 40
billion unique /48 allocations, we'd need almost 36 bits.

Of course, this assumes that you can sequentially allocate them.  More
realistic scenarios suggest that you'd have several bits worth of
sparseness.  Maybe 40 bits.

Okay, 40 bits is close to 48 bits.

But we're not delegating /48's to everyone (yet) and we don't have
40 billion people on the planet.

> Like I said, I'm not necessarily saying we're going to find ourselves
> in that boat again but it does seem as though more thought is
> required. (And yes, I fully realize the magnitude of 2^64. I also
> fully realize how quickly inexhaustable resources become rationable.)

People HAVE done the thought.  They've thought about it and argued it
back and forth for years.  This isn't a good place to continue to beat
the discolored spot where the dead horse formerly lay; there are some
discussions in the NANOG archives as it stands.  It's mostly only those 
who are steeped in the IPv4 thinking and who haven't done the math are 
concerned about /64's.

And note that you're *free* to go allocate a /96 or a /112 to your
devices if you really want to do the manual configuration.  What's
required is for you to do the thinking as to whether or not it is
worth it to paddle furiously against the current to save a resource
that is in no short supply.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.




More information about the NANOG mailing list