IPv6 and the Swinging Technology Pendulum
35 years ago, mainframes, single-protocol networks (be it SNA or DECnet), and centralized architectures that would make hard-core SDN evangelists gloat with unbridled pride were all the rage. If you’re old enough to remember IBM SNA, you know what I’m talking about.
A few years later, everything changed.
Local area networks (starting with cheap ARCnet and then thin-coax Ethernet), personal computers, and a bit later x86-based servers totally changed the networking landscape. All of a sudden we had to deal with half a dozen protocols and tons of unpredictable peer-to-peer traffic.
Most networking engineers eventually adapted and got operational experience running multiprotocol networks, and started treating peer-to-peer traffic and end-to-end principle as business-as-usual.
The old-timers had a really hard time adapting to the new world (it took IBM years to retrofit peer-to-peer communication using LU6.2 into their SNA protocol stack), and some of them retired before ever having to touch an Ethernet cable.
More recently, we’ve experienced another shift, this time in a totally different direction. All network-layer protocols but IP died, application architectures became ever more centralized (cloud is nothing else but a mainframe with distributed internal architecture), and end-to-end principle slowly died by thousand cuts made by kludges ranging from NAT and ALG to DPI and WAN acceleration.
We got to a point where people entering networking in the last 10+ years have no operational experience running multiprotocol networks, might view end-to-end principle as a security hole instead of an architectural simplification, or use network designs that rely heavily on NAT to get the job done. We’ve lost approximately 20 years of progress (or whatever).
With this in mind, it’s no wonder we’re experiencing outright denials of the need for IPv6, and dismal IPv6 adoption in enterprise networks – a lot of people running them are in exactly the same position as the SNA networking engineers were when they faced the inevitable need to deploy IP or IPX in their enterprise network.
Thanks for dropping by and leaving a comment! It's a true honor to have you as one of my occasional readers.
I don't blame the designers of BSD/WinSock API. It's evident the Socket API was v0.1, DNS was still on the drawing board when they released it, and those were the heady times of quick-and-dirty solutions that gave us headaches like FTP and SMTP.
The real blame should fall on IESG that didn't push hard enough for higher-layer changes in mid-1990s when they embraced the IPng proposal. Looping through a set of network-layer addresses in application code is so obviously a broken abstraction (or maybe it's just the 20-20 hindsight ;).
IPv6 looks like IETF / ieee got jealous of IPv4 stealing the show and wanted to show off how they could do it better whilst ignoring anyone with an interest in it.
I believe IPv6 is fundamentaly flawed, from privacy concerns to the incomprehensible addressing scheme (i understand the reasons for using a hex numbered dotted notation, but is confiusing for non network types & connecting to those new IoT devices at home will be a pain when its IP is 128 characters, a home dns server would make life easier) to the massive over allocation of addressing (who needs a /64 at home).
Enterprises with the skill, money, resources and motivation are dragging their heals on this adoption.
Home users with an increasing number of intra/inter connected devices and a basic router will suddenly find limitations or device name conflicts in the ipv6 world.