To ULA or not to ULA. That is the question: Whether ‘tis nobler in the mind to suffer the slings and arrows of multiple NATs…
Ok, ok. I’ll stop now (and in a moment, explain my lame joke to the uninitiated.) But first, in case you’re wondering what exactly I’ll be covering in this blog (i.e., whether you want to read it), I’m going to review the critical details of IPv6 ULAs before offering some suggestions on the best and most proper uses of them. This will be at least partly accomplished by demonstrating three ways ULAs can be abused in ways that will almost certainly cause major headaches down the road.
Introduction
ULA, of course, is short for IPv6 Unique Local Addresses. Most of us gain our first, familiar understanding of IPv6 ULAs when hearing them described (more or less) as the equivalent of IPv4 private addresses (RFC 1918). (A quick-and-dirty way to understand them is to think about what unique and local mean in this context: unique meaning no overlaps with others using the same address type and local meaning local to your company only.) If we’re both new to IPv6 and used to running corporate LANs, it would be quite natural to imagine upon hearing such a description that we’d soon be deploying these so-called private IPv6 ULAs and using NAT to translate to public IPv6 addresses (from the Global Unicast Address or GUA range) at the edge of the enterprise network. Fortunately, the relatively slow deployment of IPv6 among enterprises prevents this unforced error and by and by we learn that such a configuration is most definitely not recommended as a best practice (or 2nd best practice, or even 3rd best practice) for reasons we’ll cover below.
Characteristics of IPv6 Unique Local Addresses (ULAs)
IPv6 ULAs have some particular characteristics, each with a caveat.
- They’re considered global in scope – though as we’ll see in a moment we have to be careful with how we interpret that scope description
- IPv6 ULAs are allocated from the fc00::/7 subnet – though technically only from the bottom half (or is it the top half, the right or left half?) of fd00::/8
- ULAs from this range have a randomly generated 40 bits – though in practice these 40 bits are often manually assigned to make them easier to remember
Figure 1. Unique Local Address structure
According to RFC 4007 “IPv6 Scoped Address Architecture,” unicast IPv6 addresses are either link-local in scope and uniquely identify interfaces on only a single link (e.g., addresses derived from the prefix fe80::/10) or they are global in scope and uniquely identify an interface anywhere on the Internet.
Unique Local Addresses permit communication between nodes on different links and so certainly aren’t link-local in scope. But their global scope is characteristically different than addresses from the actual Global Unicast Allocation (2000::/3) in that ULAs are not currently indicated for routing on the Internet (you can review the IANA registries for IPv6 address types here and here). Instead, they are typically used in the way we first described them, as the equivalent of IPv4 private addresses; e.g., routed exclusively within an enterprise private network. Given this usage, their scope would appear to be somewhere between link-local and global.
Incidentally, such a scope was formally defined. The site-local address allocation (fec0::/10) was conceived to provide addressing exclusively within a site but has now been deprecated.
The ULA prefix is fc00::/7. But the 8th most-significant-bit (MSB) determines which “half” of the allocation a prefix is being assigned from, fc00::/8 or fd00::/8. According to the RFC 4193 “Unique Local IPv6 Unicast Addresses,” this bit indicates a locally assigned prefix when set to 1 and is undefined when set to 0. Thus, technically only prefixes from fd00::/8 should be defined and used.
As with the next characteristic, however, there is nothing preventing an administrator from bending the rules and defining and using a prefix from the fc00::/8 portion of the allocation.
Finally, the 40 bits defining any ULA prefix assigned from the fd00::/8 ULA range, are supposed to be randomly defined. This is done to maximize the probability that any ULA prefix will indeed be unique, not only within the site where the prefix is assigned but also truly globally unique across the entire Internet.
The benefit of such randomness is almost no possibility of overlapping address space when different company’s networks merge. All of the complex and potentially difficult renumbering, NAT configurations, or network overlays IT network administrators have had to rely on when dealing with overlapping IPv4 private address ranges goes away when using properly randomly-generated ULAs.
3 Ways to Ruin Your Network with IPv6 ULAs
Based on the characteristics of ULA we’ve described so far there are three ways we can abuse ULAs that will, as typical with such abuse, save us time up front but cause much suffering down the road.
First: Deploy ULAs and NAT66
Have you heard the story of the grandparent teaching their grandchild to cook a fish?
“First, we have to cut off the head and tail before placing it in the pan.”
“But why?” asks the grandchild noticing that the saucepan is big enough to hold the fish with its head and tail attached.
“Well, I’m not sure exactly. We’ve always done it this way.”
Turns out a distant ancestor didn’t have a big enough pan and cut off the head and tail out of necessity – a step no longer necessary but taken out of habit.
IPv4 private addressing and NAT, then, is the too-small-saucepan.
First we used IPv4 private addressing because we worried we would not have enough addresses for enterprise networks. NAT provided the means for this but was always an inelegant and brittle kludge that broke or bent protocol behavior and interfered with application performance and reliability. Still, over time, the IT network folks began to perceive a measure of security from the way NAT hides the internal addresses of hosts on the corporate LAN. No help was the fact that the firewalls providing NAT were also providing a more concrete form of perimeter-based network security in the form of stateful packet inspection. It’s been repeatedly demonstrated over time that perimeter-based security by itself is insufficient to protect corporate LAN and enterprise IT hosts and servers.
Just as it sounds NAT66 typically provides stateful address translation between two IPv6 address prefixes – often ULA to GUA and back again. You still need all the NAT helpers and application fixups to make this configuration work with IPv6 and the resulting performance and reliability is just as brittle as with IPv4 NAT (it’s even possible that said performance and reliability could be worse with NAT66 due to the relative lack of the opportunity to test at scale).
Meanwhile, IPv6 was designed to allow for the configuration of multiple addresses on a host interface. Different address scopes allow for more granular administration of network routing and security policy. ULA addresses were not defined with the idea that they would be translated to Global Unicast Addresses at the enterprise edge. Instead, ULA addresses can be configured on a host interface along with GUA and link-local addresses, with each address routed and secured according to its proper scope: link-local on the local link, ULA addresses within a site (or between sites but not routed on the public Internet), and GUA addresses for Internet traffic.
NPTv6
By comparison, NPTv6 offers a way of statelessly translating between ULA and GUA prefixes of the same size (Figure 2). Since NPTv6 is stateless, no port translation is required nor other manipulation of transport characteristics. Other benefits include end-to-end reachability along with 1:1 address mapping, potentially allowing for redundant paths with no active failover required. Finally, no assumption about security is made given that a 1:1 internal-to-external (and back) mapping exists and no state is maintained with NPTv6.
Perhaps most usefully of all, NPTv6 allows the effective use of ULAs to prevent the requirement of network renumbering without the accompanying brittleness of NAT66. One external network (GUA) prefix can be trivially replaced with another while the internal network (ULA) prefix remains the same.
![Figure 2. “A Simple [NPTv6] Translator” (courtesy of IETF RFC 6296)](https://live-infoblox-blog.pantheonsite.io/wp-content/uploads/simple-nptv6-translator.png)
Figure 2. “A Simple [NPTv6] Translator” (courtesy of IETF RFC 6296)
Next time we’ll look at the other 2 ways you can ruin your future network with ULAs as well as offer more suggestions for properly deploying them.
