ULA Precedence Improvements

Fun!

ULAs no longer a tripping hazard

by Craig Miller

IPv6 Unique Local Addresses (ULA) have been problematic since 2012 when RFC 6724 was published. The problem is that a ULA destination address is prioritized lower than an IPv4 address, including RFC 1918 private addresses. If you are implementing IPv6, and you set up a server with a IPv6 ULA and an IPv4 address (in DNS), only the IPv4 address will be used by clients accessing the server. This leads to a false sense that your IPv6 implementation is working just fine.

For this reason, ULAs have been discouraged. That's about to change with a new RFC working its way through the IETF. The current draft is expected to reach full RFC status by the end of 2025.

Address Selection Precedence, the old way

With the addition of IPv6, there can now be multiple addresses assigned to a single interface (think Wifi, or Ethernet). There can be multiple IPv6 Global Addresses (GUAs), an IPv6 Link-Local address, an IPv4 address, and even multiple ULAs. Because of this, there must be an algorithm or precedence system to determine which address to use. RFC 6724 published in 2012 standardizes a precedence system for the different types of addresses.

      Prefix        Precedence Label
      ::1/128               50     0
      ::/0                  40     1
      ::ffff:0:0/96         35     4
      2002::/16             30     2
      2001::/32              5     5
      fc00::/7               3    13
      ::/96                  1     3
      fec0::/10              1    11
      3ffe::/16              1    12

IPv4 addresses are in the ::ffff:0:0/96 block of addresses (represented as Mapped Addresses)

ULAs are in the fc00::7 block of addresses. Since the first half of fc00::/7 are reserved, ULAs are therefore in the fd00::/8 block, and will always start with FD.

Address Selection Precedence, the new way

The RFC Draft looks to address the Precedence problem by updating the precedence of ULAs higher than IPv4 addresses.


   Prefix        Precedence Label
   ::1/128               50     0
   $known_local/48       45    14 (**)
   ::/0                  40     1
   fc00::/7              30    13 (*)
   ::ffff:0:0/96         20     4 (*)
   2002::/16              5     2 (*)
   2001::/32              5     5
   ::/96                  1     3
   fec0::/10              1    11
   3ffe::/16              1    12

   (*) value(s) changed in update
   (**) $known_local = the ULA Known-Local /48 IPv6 prefix(es)

The new RFC draft introduces the concept of Known-Local address, which is a ULA in the same /48 as the client host. This allows for Known-Local ULAs to be given a higher precedence than IPv6 GUAs, and will result in clients connecting to servers in the same /48 prefix (but on different subnets) to connect using ULA-to-ULA.

Rolling out this change

Sadly, this change is not an easy change using a Router Advertisement (RA) or DHCPv6 option. The Precedence table is located on each host. It can be found at:

OS Location/Command
Linux /etc/gai.conf
MacOS None 1
Windows use netsh 2
BSD ip6addrctl show

Since the precedence is set on each host, one must touch each host to change it. In a SOHO network, it means changing a handful of hosts individually. In an Enterprise environment, one needs to change the precedence on the image that is used to re-image the corporate laptops.

Why wait, test in the lab now

The RFC is on the standards track, and therefore will become an IETF standard once it is published. Now is the time to re-configure a few of your client and server hosts in the lab to better understand how this change will impact your network. This will save you a lot of time in troubleshooting when the next auto-update for the OS occurs.

Part of the IPv6 Protocol evolution

The updated RFC 6724 draft is part of the third wave of improvements to the IPv6 protocol. It isn't easy creating a new protocol which is implemented world-wide. IPv4 has its short-comings, and they will remain, as there is no more active development by the IETF for IPv4. IPv6 has been tested in the world-wide internet for decades, deficiencies have been found, and the protocol has evolved, and been improved. With this draft becoming a future standard, the use of ULAs will no longer trip you up.

Notes:

  1. MacOS implements RFC 6724 in getaddrinfo function call. There is no easy way to change precedence.
  2. Windows precedence must be configured using netsh. To see the current precedent table type: netsh int ipv6 show prefixpolicies
  3. Some would say that the Precedence table which created the ULA problem was back in RFC 3484, but since RFC 6724 deprecates 3484, I am sticking with 6724.

Photo credits:


17 July 2025