Category: IPv6

In December 2020 Ed Horley invited me to a chat about IPv6 in the public cloud. While I usually don’t want to think about a protocol that’s old enough to buy its own beer in US, we nonetheless had interesting discussions (including the need for frequent RA messages in AWS VPC).

Getting Docker to work with IPv6 is an interesting and under-documented (trying to stay diplomatic) adventure, but there’s a shortcut to the promised land: even if your Docker environment is pure IPv4 morass, you can still reach published container ports over IPv6 thanks to the userland proxy I described last week. The performance is obviously commensurate with traversing kernel-user boundary too many times.

New to this rabbit hole? Start here.

Finally, you don’t have to tell me (again) that Docker is dead and we should all use K8s. It’s as useful as telling me CloudStack is dead and we should all use OpenStack. Different challenges deserve different tools.

Avery Pennarun continued his if only IPv6 would be less academic saga with a must-read IPv4, IPv6, and a sudden change in attitude article in which he (among other things) correctly identified IPv6 as a typical example of second-system effect:

If we were feeling snarky, we could perhaps describe IPv6 as “the String Theory of networking”: a decades-long boondoggle that attracts True Believers, gets you flamed intensely if you question the doctrine, and which is notable mainly for how much progress it has held back.

In the end, his conclusion matches what I said a decade ago: if only the designers of the original Internet wouldn’t be too stubborn to admit a networking stack needs a session layer. For more details, watch The Importance of Network Layers part of Networks Really Work webinar

I wanted to write a “SRv6 makes no little sense” blog post for a long while, but there were always more relevant topics to focus on. Fortunately I won’t have to write it anytime soon; Ethan Banks did a fantastic job with SR(x)6 - Snake Oil Or Salvation?. Make sure you read it before attending the next “SRx6 will save the world” vendor presentation.

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.

TL&DR: MIA

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.

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.

Johannes Weber was forced to stress-test the IPv6 networks are easy to renumber nonsense and documented his test results – a must-read for everyone deploying IPv6.

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: