Category: IPv6

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:

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.

I love reading well-argued contrarian views, and Geoff Huston’s Opinion in Defense of NAT is definitely worth the time it will take you to read it.

TL&DR: Geoff argues that with all the wastage going on in IPv6 land (most bizarre: let’s give a /48 to every residential subscriber) the number of bits available for IPv6 endpoint addressing gets close to what we can squeeze out of IPv4 NAT.

In the Future of Networking with Fred Baker Fred mentioned an interesting IPv6 deployment scenario: give a /64 prefix to every server to support container deployment, and run routing protocols between servers and ToR switches to advertise the /64 prefix to the data center fabric preferably using link-local addresses.

Let’s recap:

A month ago I told you how dr. Olivier Bonaventure starts his networking course with IPv6. But there’s more: the full textbook for the undergraduate course (Computer Networking: Principles, Protocols and Practice) is open-sourced and available (in source form) on GitHub.

You might wonder why I’m so enthusiastic, so let me tell you another story…

In mid-July dr. Olivier Bonaventure (one of the unsung networking heroes who’s always trying to address real-life problems instead of inventing unicorn solutions in search of a problem) sent an email to v6ops mailing list describing how they teach networking.

Short summary for differently-attentive:

You wouldn’t believe it – after almost 22 years (yeah, it’s been that long since RFC 1883 was published), IPv6 became an Internet standard (RFC8200/STD86). No wonder some people claim IETF moves at glacial speed ;)

Speaking of IPv6, IETF and glacial speeds – there’s been a hilarious thread before Prague IETF meeting heatedly arguing whether the default WLAN SSID should be IPv6-only (+NAT64). Definitely worth reading (for the entertainment value) over a beer or two.

One of my readers sent me an email that’s easiest paraphrased into: “Why can’t I have a different IPv6 link-local address (LLA) on every access port connected to a VLAN interface?”

There’s probably nothing stopping someone from implementing such an approach, but it would go against the usual understanding of how bridging and routing interact in L2+L3 switches.

An engineer watching my IPv6 Transition Mechanisms webinar sent me this question:

We would appreciate any insight you might have as to which transitional mechanisms the ISPs are actually deploying.

All of them ;)