Waste will kill ipv6 too

Fri Dec 29 00:41:25 UTC 2017

> On 29 Dec 2017, at 11:24 am, Ricky Beam <jfbeam at gmail.com> wrote:
> 
> 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.


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org