Unintended Consequences of IPv6 SLAAC

One of my friends is running a large IPv6 network and has already experienced a shortage of IPv6 neighbor cache on some of his switches. Digging deeper into the root causes, he discovered:

In my larger environments, I see significant neighbor table cache entries, especially on network segments with hosts that make many long-term connections. These hosts have 10 to 20 addresses that maintain state over days or weeks to accomplish their processes.

What’s going on? A perfect storm of numerous unrelated annoyances:

  • Stateless Autoconfiguration. IPv6 was designed before IPv4 got DHCP and wanted to mimic the ease-of-deployment of AppleTalk and Novell IPX, resulting in SLAAC. SLAAC was supposed to generate a single (global) IPv6 address per node.
  • SLAAC Privacy Extensions. SLAAC used the interface MAC address to generate an IPv6 address. That could be used to track users across network segments; IETF solved that with SLAAC Privacy Extensions (RFC 4941 and RFC 8981).
  • Long-running TCP sessions. According to RFC 8981, a host should periodically generate a new IPv6 address and deprecate its old addresses (the default rotation period is 24 hours). Deleting an IPv6 address kills any TCP session using it (unless you’re running MP-TCP), so the deprecated addresses stay active as long as TCP sessions are using them.
  • Reconnecting to the Network. I was told (years ago) that some mobile devices generate a new IPv6 address every time they wake up. I have no idea what modern iOS/Android implementations do; feedback would be highly appreciated.

Why is that a problem? In two words: cache trashing. When a hardware packet forwarding device runs out of the IPv6 ND cache, it punts transit packets to the CPU (increasing the CPU load) to trigger IPv6 neighbor discovery. Some devices might drop the “offending” IPv6 packets, resulting in increased packet drops and reduced performance, eventually making IPv6 perform worse than IPv4.

Can we fix it? As is always the case in network design, you have to choose what tradeoffs you want to make:

  • Limiting the number of ND entries per interface will protect the scarce hardware resources but result in suboptimal performance for everyone using IPv6 on an affected segment.
  • Using Semantically Opaque Interface Identifiers (RFC 7217) would solve the problem but enable user tracking within a segment (but not across segments).
  • DHCPv6 IA_NA address allocation could limit the number of addresses assigned to a single IPv6 host. Contrary to popular lore spread by DHCPv6 haters, a host can request multiple IPv6 addresses via DHCPv6 (address rotation is thus not a big deal), and a DHCPv6 server can deny a request for a new address (forcing the host to choose between privacy and broken TCP sessions).

OK, it looks like environments facing hardware resource shortages could use DHCPv6 to fix that, right? Well, no. Look at the overview of IPv6 support in various operating systems and tell me if you can spot popular end-user operating systems that do not support DHCPv6.

As of March 2024, two modern end-user operating systems did not support DHCPv61, both from the company that graced us with a generative AI model that refused to draw a picture of a white male pope for diversity reasons. Even worse, the controversy goes back more than a decade, and we’re still forced to deal with the consequences of the stubbornness of highly opinionated engineers who think they know better than us how to run our networks. No wonder we’re experiencing low enterprise adoption of a protocol that could buy a beer even in the US for quite a few years.

On a completely unrelated topic, did you know that the only way to get a VM IPv6 address in Google Cloud is to use DHCPv6?

  1. We can probably agree to ignore OpenVMS and Windows NT, right? ↩︎


  1. Just opt for RFC7217 if not ia_na and/or ia_pd (for the CLAT thing).

    If these are Linux hosts we're talking about, disable “use_tempaddr” and generate stable-private addresses by configuring “stable_secret” and “addr_gen_mode”: https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

    Similarly, the Linux feature above should exist for Windows and macOS. And if the feature is supported, then forget about temporary addresses and configure a persistent “private” address instead. Meaning, each host will use only one /128 for its lifetime.

    I'm a strong advocate for BCOP-690 (yes I know it's SP-oriented) and do not believe in this crap about “Privacy extension rotation or dynamic IPs will magically stop big bro from tracking you” — No, I personally use analytics tools and no, dynamic IPs doesn't stop tracking in any shape or form. This is a tinfoil conspiracy theory that tracking is dropped dead on dynamic IPs that seems popular in EU for some reason and parts of Asia (where I am based in).

    So, in addition to BCOP-690, I explicitly configured pref-lifetime and valid-lifetime to infinity on the upstream router. I don't believe in “dynamic IPs” for anything in IPv6 world.

    1. I probably agree with most what you wrote, but there's a stomping elephant in the room called Android :( Unfortunately the people controlling its IPv6 stack think they can do whatever they feel like doing regardless of the impact on everyone else.

    2. I believe you and I have interacted in the past on v6ops IETF mailing list on DHCPv6 support issues for god-almighty Android. We're on the same page on this topic.

      I recommend Android users to connect to v4-only RFC1918 VLAN/SSID and then VPN from there and finally get /128 GUA on the VPN interface on the client side. WireGuard works well for this one and a company can automate it with middle-ware like headscale/tailscale or whatever take your pick middle-ware.

      If the employees or employer don't like this, then buy everyone an iPhone or recommend it “If you want native IPv6, Switch to iPhone”.

    3. That kind of iPhone encouragement is the type of forced compliance that'd get me to go seek a job offer from the companies biggest competitor and then when they ask why I'm leaving I tell them "you wouldn't give me good internet." Personally I'm sort of neutral on Android's lack of DHCP support but I understand their concerns and share some of them and I understand the argument going the other way.

Add comment