Re: Waste will kill ipv6 too

[Mark Andrews <marka () isc org>]

> On 29 Dec 2017, at 11:24 am, Ricky Beam <jfbeam () gmail com> wrote:
>
> On Thu, 28 Dec 2017 16:35:08 -0500, Owen DeLong <owen () 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 () isc org