ULA is the equivalent of RFC1918, effectively. FC00::/7 You’re thinking of link-local addresses which are the fe80 addresses. Those are autogenerated. ULA is assigned however you want – SLAAC, DHCPv6, static, etc…. RFC1918 equivalent.
Nominally, you’d almost never think about link-local. You essentially have all of fc00::/7 to utilize as you wish. So, for you, I suppose, you could do FC00:0:22:XXXX::/64 22nd state, XXXX being vlan ID or some other identifier or whatever you want (servers could be FC00:0:22:1::/64 and workstations FC00:0:22:2::/64 and so on – feel free to be creative! You have FC00::/32 through FC00:3E8::/32 to play around in! With /48’s I like to do PRE:FIX:HERE:VLANID::/64) Including the office number, so you could do FC00:22:0:1 (the 0 between the 22 and 1 is the office number, second the network/vlan identifier, whatever – you can be creative and as long or compact as you want here). So let’s say you have FC00:22:0:1::1 – okay, that’s a router! FC00:22:0:2:SLAA:CASS:IGNE:DAUTOCONF – sweet that’s a workstation (SLAAC for simplicity sake, DHCPv6 can also be an option, but a bit more to configure/maintain). FC00:22:0:1::250 – that’s the linux server! Okay, so now your linux server is FC00:22:0:1::250, still simple enough. And any firewall logs with that info will immediately tell you right where it is and what network it’s on, etc. Then with NPT, you’re mapping provider prefix aaand you’re right where you were with V4, including needing to update DNS in failover. Now you just change the provider prefix portion instead of the whole IP address. The ::250 will stay the same on either provider externally. NPT will just convert say, 1234:5678:1234:5678::/64 to FC00:22:0:1::/64 at the edge, and vice versa. So your linux server would be 1234:5678:1234:5678::250 You never want to hardcode link-local addressing, that’s all entirely autonomous and is used for a variety of things, but that’s out of scope here. From: Aaron C. de Bruyn <[email protected]> Sent: Friday, June 19, 2026 4:24 PM To: Gary Sparkes <[email protected]> Cc: North American Network Operators Group <[email protected]>; Marco Moock <[email protected]> Subject: Re: IPv4 flag day On Fri, Jun 19, 2026 at 1:03 PM Gary Sparkes <[email protected]<mailto:[email protected]>> wrote: The clean path would be NPTv6 with ULA for the same exact setup. It would slot in and work identically to how the IPv4 deployment is today. Instead of RFC1918, you have ULA addressing. Same concept. Except with NPTv6 you're doing 1:1 and eliminate PAT. Of course, if you're single provider, might as well just use prefix delegation, NPT's real shine is the multi-WAN scenario with no upstream routing protocol that sparked off a lot of discussion. As to changing providers when using prefix delegation, most stuff can auto-update itself, but otherwise it's a simple find/replace exercise in documentation and records when your provider prefix changes as the last half of the address is entirely stable, and the first half is (mostly) provider. Maybe I need to do a bit more digging as I'm not an expert at IPv6--but aren't ULA addresses basically randomly assigned to hosts based on their NIC HW address and a few other things? A short example from a very large client I manage: They use IPv4 10/8 The next octet is allocated for the state the office is located in "plus 100". So if they open an office in Alabama (22nd state to join the union), it's gonna be 10.122/16. The third octet is assigned sequentially. The first office opened in Alabama is 10.122.0.0/24<http://10.122.0.0/24>. The last octet is static. Router at .254, linux server at .250, Windows (ugh) RDP server at .249, workstations are DHCP between .100 and .199, etc... You can give me nearly any IP from this client and I know the device. But ULA gives me: fe80::ae1f:6bff:feb0:3c98/64 What even is that? Their router? A Windows box? Hard-code the address to fe80::122:00000:250/64 (just to know it's a linux server in Alabama) and then set up NPTv6...and update a *ton* of DNS info so the rest of the world can easily get to the correct machines? Again, I'm having to renumber somewhere--either update a bunch of DNS or update a bunch of internal machines when I change ISPs or have a fail-over. At least that's what it always seemed like to me after going through all the 800-page IPv6 tomes over the years. ;) -A _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/NI65BQKECBLOUNVIYOARAV2LNMHQBIO2/
