> On 29 Dec 2017, at 11:24 am, Ricky Beam <jfb...@gmail.com> wrote: > > On Thu, 28 Dec 2017 16:35:08 -0500, Owen DeLong <o...@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: ma...@isc.org
