IPv6 in 2025: ULAs and NAT66

Welcome to year 13 of the IPv6 transition, counting from IPv6 Launch Day, held on June 6 of 2012.

In commemoration of this, I decided to write down some of my thoughts on IPv6 and see if I can't produce something for a target audience that is still wondering what IPv6 even is and if they should be using it at home.

Where we are Today

The one-line summary of the current state of the IPv6 transition process is "IPv6 is everywhere people don't need to think about IP addresses". Which, since routing is pretty fundamentally tied to IP addressing, kind of explains why pretty wide swathes of the internet are still reliant on IPv4 addressing.

Phones are pretty consistently IPv6, but last I checked most home networks aren't running off the cell network.

Some are. But again, most aren't.

A lot of words have been written over the last 13 years on why adoption of IPv6 has been so slow, and the problem really does have a lot of different facets to it. Not something you can boil down to just one particular issue.

For this blog post, though, I want to focus on what I see as being the biggest stumbling block.

Namely, for some reason, the IPv6 community really doesn't seem to want to take full advantage of the Unique Local Address system that is in the IPv6 spec. Often due to it being "too IPv4", which doesn't make any sense.

IPv4 has local addressing, of course - RFC 1918 is a pretty critical part of the internet. And the typical small single-location network looks something like a single WAN uplink coming down to a gateway/firewall/NAT appliance which translates internal IPv4 addresses allocated sequentially from 192.168.X.0 on up into a single external IP address.

Externally, all those hosts look like a single host. Even if one of the hosts is just a light bulb that has an internet connection for some unfathomable reason.

Some people will insist on calling this NAPT due to the many-to-one mapping, but this really doesn't seem to have caught on. It's NAT.

In fact, let's run with that internet-connected light bulb for a moment. What's the "canonical" way that should work under IPv6?

Well, the exact process depends on whether you're using DHCPv6 or SLAAC, obviously, but that's mostly an implementation detail. At a broader scale, the "correct" way to network the light bulb is to give it a "globally-routable unicast" address (GUA), then either trust its onboard firewall to reject malicious incoming connections (which would make one a moron) or put it behind an external firewall of some sort. Preferably stateful, so that it can only make outgoing connections and all unexpected incoming connections are universally refused.

When you see people say that "NAT isn't security" they're right in a way - but if nothing else it did ensure that the vast majority of residential networks are using a stateful firewall. That's not nothing.

But one really wonders what we've actually gained at that point. In exchange for the gateway not needing to do NAT anymore (which realistically is only a computing load concern if you're not also providing a stateful firewall...), your light bulbs have become globally routable and packets to them from a network-local host more closely resemble packets from remote hosts, making intrusion detection just that little bit harder.

Plus it's nice that ISPs reliably refuse to route local addresses at all*. Which makes it that much harder to smuggle a locally-addressed packet to your gateway.

* Yes, yes, many DOCSIS networks have multiple people on the same broadcast domain. If you know what that means you also know why it's really not what we're talking about here.

NPT is not NAT

Sometimes people will offer "NPT" as a "more IPv6" alternative to NAT. It isn't. NPT, outside of some very specific use cases that nobody wondering how to set up an IPv6 network to begin with is dealing with, is worthless. At a minimum, it doesn't solve the global routability problem so it's not really a step up from GUAs.

Most people can just skip the rest of this section, but to briefly describe why that is:

NPT is essentially NAT except that only the first part of the IP address is translated. Hence Network Prefix Translation.

This means the bit that one might be concerned about keeping private - the bit the identifies the actual host that is communicating - is left intact.

Again, worthless outside of extremely niche use cases.

What was that about ULAs?

The reason I brought up ULAs, then, is that they dramatically simplify setting up small-scale networks. You don't need to worry about whether your firewall is going to let an attacker inject packets to control your lights or thermostat. So long as it's on and it's stateful, you're probably OK.

Yes, this is an IPv6 Network

So all this said, I'll describe how I originally set up my own network as far as IPv6 is concerned:

1. All hosts on the network get a ULA, not GUAs.
2. These ULAs start at fc00::0 (yes, not fd00::0) and increment from there, with some segments allocated for local servers and other segments allocated dynamically to hosts that join/leave the network.
3. Any GUA packets that are not outgoing are dropped by any switch encountering them.
4. Gateway is configured to NAT those ULAs to a single GUA using NAT66.

Note that the addresses described in (2) are quite deliberately not RFC 4193 §3.2 compliant. That is by design, as the idea of assigning a local address only to try to make it globally unique is obviously extremely silly.

Anyways, that's it. That's all that was needed. Since then I've played around with more complicated configurations (BGP really is a fascinating protocol), but that's all been for my own enjoyment, ultimately.

Those four steps should be plenty as an outline for the overwhelming majority of residential and even small business needs.

You'll also notice that these are pretty much how your average IPv4 router is configured out of the box. The fact that IPv6 addressing on those same routers is often either disabled out of the box or configured completely uselessly is a source of frustration, but if you want to use IPv6 you're going to have to deal with it anyway.

So at the end of the day if you just don't want to deal with all that mess... just turn off IPv6 and be done with it.

If that's not an option for you... well, I really do wish the defaults were better. But the four steps described above are really the simplest configuration you can put together, so hopefully that helps.

But Global Routability...

As a final note I do want to preempt one particular objection to this sort of network configuration.

If you go trawling the IPv6 forums the single most common complaint about this sort of configuration you'll see is that it "breaks global routability".

This is extremely silly, and is rooted in the 90s-era approach to the internet that IPv6's designers were thinking about.

Back then, each individual computer - a "host" - was expected to be reachable whenever it was on. If you wanted to host a bunch of files you just dropped them in a folder and ran an FTP program that listened for people requesting those files.

If you wanted to run a website you did the same exact thing, just with the HTTP protocol instead of FTP.

VoIP telephones weren't really a thing back then (most internet was via the phone system instead, really), but as people thought about it they decided it made sense to run that in a similar way. You'd dial an IP address like you would a phone number, and only that given computer would "ring".

The fact that IPv4 was kept alive by NAT instead of IPv6 being the only game in town completely shattered that approach. Now you couldn't try to download your files from any computer in the world, since the other person had to have set up port forwarding first.

Which... really isn't that big a problem, I have to say. It's kind of like complaining that when you're calling a landline-equipped house you can only call the house rather than a specific phone inside the house.

Today, we have an infrastructure that makes NAT pretty manageable. UPnP is pretty solid, and even kids can set up port forwarding for their Minecraft servers.