IPv6 Unique Local Addresses (ULA) Made Useless
Recent news from the Department of Unintended Consequences: RFC 6724 changed the IPv4/IPv6 source/destination address selection rules a decade ago, and it seems that the common interpretation of those rules makes IPv6 Unique Local Addresses (ULA) less preferred than the IPv4 addresses, at least according to the recent Unintended Operational Issues With ULA draft by Nick Buraglio, Chris Cummings and Russ White.
End result: If you use only ULA addresses in your dual-stack network1, IPv6 won’t be used at all. Even worse, if you use ULA addresses together with global IPv6 addresses (GUA) as a fallback mechanism, there might be hidden gotchas that you won’t discover until you turn off IPv4. Looks like someone did a Truly Great Job, and ULA stands for Useless Local Addresses.
For more details:
- Listen to The Foibles and Frailties of IPv6 ULA episode of the Modem Podcast
- Read the IETF draft
- Enjoy the recent discussion on v6ops mailing list. I ran out of popcorn and patience and dropped out.
Do you care? Maybe.
Someone asked a question along the lines “does anyone know of a good ULA use case” at the end of the Modem Podcast episode I mentioned above, and there happens to be one that might be relevant to a few mid-sized enterprise networks: site-to-site VPN with local Internet exit. I wrote about it in 2013 and as far as I know nothing changed in the meantime (apart from ULA addresses becoming useless). Here are the links to the (somewhat) relevant blog posts:
- To ULA or not to ULA, That’s the Question (September 2013)
- PA, PI or ULA IPv6 Address Space? It depends (January 2014)
- IPv6 Legends and Myths: More Opinions than Data Points (April 2012)
- Why Can’t We All Use Provider-Independent IPv6 Addresses? (April 2018)
Finally, let me conclude with an awesome quote from Randy Bush (made in October 2012):
It is cheering to see that the IPv6 ivory tower still stands despite years of attack by reality.
-
Which you REALLY SHOULD NOT. ↩︎
I tried it a few months ago in a home/lab environment - and yes, it doesn't work.
In my setup I generated a new ULA /48 range and assigned a /64 to an internal WiFi-enabled subnet. I had 2 upstream Internet links: - a primary fast link dual-stacked to the ISP - a slow ADSL IPv4 only backup link with an he.net IPv6 tunnel
A single router did NAT66 for the /64 blocks when traffic was routing over each uplink.
I found devices always preferred IPv4 over IPv6-ULA. After hacking around on a Linux host I found where preferences were set, but they're horribly complex and you just can't fix other devices like Windows, Android, iOS, etc.
So yes, a lot of docs say it should work but in real life it doesn't because the network stacks on almost all OS's are hard coded to prefer IPv4 over IPv6 ULA addresses.
I reverted to using my he.net assigned public /64 on the LAN, and NAT66 when going over the other uplink. Real public IPv6 is preferred over IPv4, so it works as expected. But not ULA.
Some years ago, before some parts of RFC 6724 were implemented in common operating systems, the situation was different. Using ULA did not work.
ULA was treated identically to GUA. If one added ULA addressing for local only IPv6 tests to an existing IPv4 network with Internet connectivity, Internet connectivity would break (no Happy Eyeballs or Happy Eyeballs v2), or it would be slower due to trying IPv4 later than IPv6.
Unique Local Addresses were worse than useless, they were harmful, because local use of Unique Local Addresses negatively affected global connectivity.
(This problem was documented in RFC 5220 section 2.2.2 from 2008, referenced in RFC 6724.)
Useless, but no longer harmful, ULA could be seen as an improvement. :-)
We use ULA as WAN address for our GPON ONUs as additional security measurement to prevent most of the internet to brute force passwords and to have little bit more safety from exploiting know vulnerabilities of ONU vendors. They love to left backdoors and write unsecure code. Then customers get delegated prefix of global IPv6 addresses.
I haven't seen this behavior on (modern) Ubuntu 20.04/22.04 and Win10.
I have a switch with ULA address (I don't have PIA space at home) and an ipv4(RFC1918) address. A dns lookup returns the ULA address & ipv4 address. Using ping or ssh to the dns name always has me connecting to the ULA address.
https://twitter.com/5SpeedFun/status/1518047636166746114