Dual stack IPv6 for IPv4 depletion

Wed Jul 15 16:20:25 UTC 2015

> On Jul 15, 2015, at 08:20 , George Metz <george.metz at gmail.com> wrote:
> 
> Reasonability, like beauty, is in the eye of the beholder, but I thank you
> for the compliment. :)
> 
> The short answer is "yes, that constitutes being prudent". The longer
> answer is "it depends on what you consider the wildest dreams".
> 
> There's a couple of factors playing in. First, look at every /64 that is
> assigned as an IPv4 /32 that someone is running NAT behind. This is flat
> out WRONG from a routing perspective, but from an allocation perspective,
> it's very much exactly what's happening because of SLAAC and the 48-bit MAC
> address basis for it. Since /64 is the minimum, that leaves us with less
> than half of the available bit mask in which to hand out that 1/8th the
> address space. Still oodles of addresses, but worth noting and is probably
> one reason why some of the "conservationists" react the way they do.

Then they are being silly. The thinking for IPv6 was a 64-bit address in toto
until SLAAC was proposed and 64 bits were added to enable that.

Even at 64 bits, you have more than 4 billion times as many network numbers as you
had host numbers in all of IPv4.

> Next, let's look at the wildest dreams aspect. The current "implementation"
> I'm thinking of in modern pop culture is Big Hero 6 (the movie, not the
> comics as I've never read them). Specifically, Hiro's "microbots". Each one
> needs an address to be able to communicate with the controller device. Even
> with the numbers of them, can probably be handled with a /64, but you'd
> also probably want them in separate "buckets" if you're doing separated
> tasks. Even so, a /48 could EASILY handle it.

Right…

> Now make them the size of a large-ish molecule. Or atom. Or protons.
> Nanotech or femtotech that's advanced enough gets into Clarke's Law - any
> sufficiently advanced technology is indistinguishable from magic - but in
> order to do that they need to communicate. If you think that won't be
> possible in the next 30 years, you probably haven't been paying attention.

Sure, but do you really think that IPv6 can handle that in all the other ways?
I think we’ll need a new protocol to do that for reasons other than address
space limitations well before we run out of IPv6 addresses.

> However, that's - barring a fundamental breakthrough - probably a decade or
> two off. Meanwhile we've got connected soda cans to worry about.

True.

> I wrote my email as a way of pointing out that maybe the concerns (on both
> sides)- aren't baseless, but at the same time maybe there's a way to split
> the difference. It's not too much of a stretch to see that, soon, 256
> subnets may not actually be enough to deal with the connected world and
> "Internet of Things" that's currently being developed. But would 1024? How
> about 4096? Is there any need in the next 10-15 years for EVERYONE to be
> getting handed 65,536 /64 subnets? Split the difference, go with a /52 and
> suddenly you've got FOUR THOUSAND subnets for individual users so that
> their soda cans can tell the suspension on their car that it's been opened
> and please smooth out the ride.

There are two ways to waste addresses. One is to allocate them to users who
don’t actually use all of them.

The other is to keep them on the shelf in the free pool until well past the useful
life of the protocol.

I don’t see splitting the difference at /52 as being any more useful than leaving
it at /48. Certainly it is an incremental improvement over /56 and wildly better
than /60, but it remains an unnecessarily inferior solution.

> Frankly, both sides seem intent on overkill in their preferred direction,
> and it's not particularly hard to meet in the middle.

Perhaps, but it’s also not hard to do harmful things with the best of intent.

Owen

> 
> On Tue, Jul 14, 2015 at 8:38 PM, Doug Barton <dougb at dougbarton.us> wrote:
> 
>> On 7/14/15 6:23 AM, George Metz wrote:
>> 
>>> It's always easier to be prudent from the get-go than it is to rein in the
>>> insanity at a later date. Just because we can't imagine a world where IPv6
>>> depletion is possible doesn't mean it can't exist, and exist far sooner
>>> than one might expect.
>>> 
>> 
>> I've been trying to stay out of this Nth repetition of the same
>> nonsensical debate, since neither side has anything new to add. However
>> George makes a valid point, which is "learn from the mistakes of the past."
>> 
>> So let me ask George, who seems like a reasonable fellow ... do you think
>> that creating an addressing plan that is more than adequate for even the
>> wildest dreams of current users and future growth out of just 1/8 of the
>> available space (meaning of course that we have 7/8 left to work with
>> should we make a complete crap-show out of 2000::/3) constitutes being
>> prudent, or not?
>> 
>> And please note, this is not a snark, I am genuinely interested in the
>> answer. I used to be one of the people responsible for the prudent use of
>> the integers (as the former IANA GM) so this is something I've put a lot of
>> thought into, and care deeply about. If there is something we've missed in
>> concocting the current plan, I definitely want to know about it.
>> 
>> Even taking into account some of the dubious decisions that were made 20
>> years ago, the numbers involved in IPv6 deployment are literally so
>> overwhelming that the human brain has a hard time conceiving of them.
>> Combine that with the conservation mindset that's been drilled into
>> everyone regarding IPv4 resources, and a certain degree of over-enthusiasm
>> for conserving IPv6 resources is understandable. But at the same time,
>> because the volume of integers is so vast, it could be just as easy to slip
>> into the early-days v4 mindset of "infinite," which is why I like to hear a
>> good reality check now and again. :)
>> 
>> Doug
>> 
>> --
>> I am conducting an experiment in the efficacy of PGP/MIME signatures. This
>> message should be signed. If it is not, or the signature does not validate,
>> please let me know how you received this message (direct, or to a list) and
>> the mail software you use. Thanks!
>> 
>> 