IPv6 is old enough to buy its own beer (in US, not just in Europe), but there are still tons of naysayers explaining how hard it is to deploy. That’s probably true if you’re forced to work with decades-old boxes, or if you handcrafted your environment with a gazillion clicks in a fancy GUI, but if you used Terraform to deploy your application in AWS, it’s as hard as adding a few extra lines in your configuration files.
Nadeem Lughmani did a great job documenting the exact changes needed to get IPv6 working in AWS VPC, including adjusting the IPv6 routing tables, and security groups. Enjoy ;)
One of the hands-on exercises in our Networking in Public Cloud Deployments online course asks the attendees to deploy a full-blown virtual networking solution with a front-end (web) server in a public subnet, and back-end (database) server in a private subnet.
The next (optional) exercise asks them to add IPv6 to the mix for a full-blown dual-stack deployment.
When I’ve seen my good friends Christopher Werny and Enno Rey talk about IPv6 security at RIPE78 meeting, another bit of one of my puzzles fell in place. I was planning to do an update of the IPv6 security webinar I’d done with Eric Vyncke, and always wanted to get it done by a security practitioner focused on enterprise networks, making Christopher a perfect fit.
As it was almost a decade since we did the original webinar, Christopher started with an overview of IPv6 security challenges (TL&DR: not much has changed).
A lot of people are confused about the roles of network layers (some more than others), the interactions between MAC addresses, IP addresses, and TCP/UDP port numbers, the differences between routing and bridging… and why it’s so bad to bridge across large distances (or in large networks).
I tried to explain most of those topic in How Networks Really Work webinar (next session coming on April 2nd), but as is usually the case someone did a much better job: you MUST READ the poetic and hilariously funny World in which IPv6 was a good design by Avery Pennarun.
Six years ago, when I was talking about overlay virtual networks at Interop, I loved to joke that we must be living on a weird planet where Microsoft has the best overlay virtual networking implementation… at least as far as IPv6 goes.
Even then, their data plane implementation which was fully dual-stack-aware on both tenant- and underlay level was way ahead of what System Center could do.
I got some interesting feedback from one of my readers on Segment Routing with IPv6 extension headers:
Some people position SRv6 as the universal underlay and overlay due to its capabilities for network programming by means of feature+locator SRH separation.
Stupid me replied “SRv6 is NOT an overlay solution but a source routing solution.”
One of my readers listened to a podcast where a $vendor described how they found another use case for
source routing IPv6 segment routing (SR): 5G networks… and wondered whether SR made a comeback or is about to.
To figure out what segment routing is, watch the webinar we did with Jeff Tantsura a while ago.
I don’t know nearly enough about mobile networks to have an opinion, however…
A team of IPv6 security experts I highly respect (including my good friends Enno Rey, Eric Vyncke and Merike Kaeo) put together a lengthy document describing security considerations for IPv6 networks. The document is a 35-page overview of things you should know about IPv6 security, listing over a hundred relevant RFCs and other references.
No wonder enterprise IPv6 adoption is so slow – we managed to make a total mess.
He found out that renumbering IPv6 in his lab required almost four times as many changes as renumbering (outside) IPv4 in the same lab.
My cynical take on that experience: “Now that you’ve documented everything that needs to be changed, make sure it’s automated the next time ;)”
In Moving Complexity to Application Layer I discussed the idea of trying to use all addresses returned in a DNS response when trying to establish a connection with a server, concluding with “I don’t think anyone big enough to influence browser vendors is interested in reinventing this particular wheel.”
I’m really glad to report I was wrong ;) This is what RFC 8305 (Happy Eyeballs v2) says:
Here’s another back-to-the-fundamentals question I received a while ago when discussing IPv6 multihoming challenges:
I was wondering why enterprise can’t have dedicated block of IPv6 address and ISPs route the traffic to it. Enterprise shall select the ISP's based on the routing and preferences configured?
Let’s try to analyze where the problem might be. First the no-brainers:
Remember the IPv6 elephant in the room – the inability to do small-site multihoming without NAT (well, NPT66)? IPv6 is old enough to buy its own beer, but the elephant is still hogging the room. Tons of ideas have been thrown around in IETF (mostly based on source address selection tricks), but none of that spaghetti stuck to the wall.
The idea of generating random IPv6 addresses (so you cannot be tracked across multiple networks based on your MAC address) that stay stable within each subnet (so you don’t pollute everyone’s ND cache every time you open your iPad) is pretty old: RFC 7217 was published almost exactly four years ago.
Linux was quick to pick it up, OpenBSD got RFC 7127 support a few weeks ago. However, there’s an Easter egg in the OpenBSD patches that implement it: SLAAC on OpenBSD now works with any prefix length (not just /64).
One of my readers sent me this question:
Do you have any thoughts on this meltdown HPTI thing? How does a hardware issue/feature become a software vulnerability? Hasn't there always been an appropriate level of separation between kernel and user space?
There’s always been privilege-level separation between kernel and user space, but not the address space separation - kernel has been permanently mapped into the high-end addresses of user space (but not visible from the user-space code on systems that had decent virtual memory management hardware) since the days of OS/360, CP/M and VAX/VMS (RSX-11M was an exception since it ran on 16-bit CPU architecture and its designers wanted to support programs up to 64K byte in size).
In December 2017 IETF published RFC 8273 created by the v6ops working group (which means there must have been significant consensus within the working group that we need the solution and that it makes at least marginal sense).
The RFC specifies a mechanism by which the first-hop router allocates a unique /64 IPv6 prefix for every host attached to a subnet and uses unicast and multicast RA responses sent to unicast MAC addresses to give every host the impression that it’s the sole host on its own subnet.
The first thought of anyone even vaguely familiar with how complex IPv6 already is should be “WTF???” Unfortunately, there are good reasons we need this monstrosity.