Waste will kill ipv6 too

Fri Dec 29 00:24:44 UTC 2017

On Thu, 28 Dec 2017 16:35:08 -0500, Owen DeLong <owen at delong.com> wrote:
> Wasting 2^64 addresses was intentional because the original plan was for  
> a 64-bit total
> address and the additional 64 bits was added to make universal 64-bit  
> subnets a no-brainer.

Incorrect. The original 128 address space was split 80+48. That *LATER*  
became 64+64 to support EUI-64 (vs. 48bit ethernet MACs)

A 64bit LAN is, and always will be, an infinitely stupid idea. The reason  
for that over-optimization in SLAAC never materialized -- the 8bit  
micro-controlers from the 80s will never run IPv6, so the ability to form  
your address in 4 lines of ASM is meaningless, even more so when IPSec was  
bolted on. (later marked optional, but was originally required)

SLAAC is still, to this day, THE. ONLY. THING. demanding your LANs be  
64bits. I've run LANs with longer prefixes for decades. And they work.  
(the original intent was to keep android devices from using IPv6, as  
there's no f'ing way to turn it off, or even see it anywhere.) Yes, there  
are various RFCs saying you need to use /64's, but they're all bunk. SLAAC  
is the only thing that REQUIRES a /64, and few modifications to your IPv6  
source and privacy extensions function just fine with longer prefixes.  
(don't go nuts and use /120's, unless you like seeing address collisions;  
DAD is designed to handle that -- and does, but it can take a few rounds  
to find a free address. I've used /96 on a LAN with ~100 machines without  
issue.)

Back to the main theme... artificially cutting the address space in half,  
just makes the point even stronger. IPv6 address space is, in fact, half  
as big as people think it is, because we've drawn a line at /64 -- and the  
catastrophic part is people *ARE* wiring that into hardware. Every example  
I've seen people bat around about just how big 2^128 is, ignores the  
reality of Real World Networking(tm). They ignore infrastructure. The  
ignore route table size. They ignore the sparse nature of hierarchical  
address assignment. In the "10B people === 10B /48's" example, that's a  
dense PI allocation scheme that will lead to a global routing table  
approaching 10B routes -- you can't aggregate a random selection of /48s  
-- with zero consideration for how those 10B networks will interconnect.

The simple truth is, we're doing the exact same thing with IPv6 that we  
did with IPv4: "The address space is so mind alteringly large we'll never  
use even a fraction of it." *pause* "Umm, wait a minute, we're carving  
this turkey up alarmingly fast." Will we use up the entire thing? Of  
course we will; it's not, in fact, *infinite*, so we *will* eventually  
assign all of it. It's going to happen a lot faster than most people  
think, as we're so cavalier with handing out vast amounts of space for  
which most people will never use more than (a) one LAN, and (b) a few  
dozen addresses within that single LAN. Will it happen in 5, 10, 100  
years? The later is a safer bet. (not that I'll be around to collect) But  
just like IPv4, some decades down the road, people will see how stupid our  
allocation scheme really is, and begin a new "classless" era for IPv6. The  
short of it is, we got here first, so we don't have to give a shit about  
being efficient or frugal.