Considerations For Using Unique Local Addresses

Unique Local Addresses (ULA) is defined in , and it is an alternative to site-local address (deprecated in ). But the two kind of addresses are not the same. ULAs are defined as a global scope address space. However, they are not intended to be used globally on the public Internet; in contrast, they are mostly used locally, for example, in isolated networks, internal networks, or VPNs. Global scope yet local usage, this special feature has confused network operators more or less. This document aims to introduce the usage of ULAs in various scenarios, provide some operational considerations, and clarify the advantages and disadvantages of the usage in each scenario. Thus, the administrators could choose to use ULAs in a certain way that considered benificial for them.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in when they appear in ALL CAPS. When these words are not in ALL CAPS (such as "should" or "Should"), they have their usual English meanings, and are not to be interpreted as key words.

ULA prefixes can be automatically generated using the algorithms described in . This feature allows automatic prefix allocation. Thus one can get a network working immediately without applying for prefix(es) from an RIR/LIR (Regional Internet Registry/Local Internet Registry).

ULAs are intended to have an extremely low probability of collision. The randomization of 40 bits in a ULA prefix is considered sufficient enough to ensure a high degree of uniqueness (refer to Section 3.2.3 for details) and simplifies merging of networks by avoiding the need to renumber overlapping IP address space. Such overlapping was a major drawback to the deployment of private addresses in IPv4. Note that, as described in , applications may treat ULAs in practice like global-scope addresses, but address selection algorithms may need to distinguish between ULAs and Global-scope Unicast Addresses (GUAs) to ensure bidirectional communications. As a further note, the default address selection policy table in ) responds to this requirement.

ULAs can be used for internal communications even without Internet connectivity. They need no registration, so they can support on-demand usage and do not carry any RIR/LIR burden of documentation or fees.

The prefixes of ULAs are well known thus they are easily identified and filtered. This feature is convenient for management of security policies and troubleshooting. For example, network administrators can segregate packets containing data which must stay in the internal network by assigning ULAs to internal servers. Externally-destined data can be sent to the Internet or telecommunication network by a separate function, through an appropriate gateway/firewall.

A ULA prefix can be generated once, at installation time or factory reset, and then possibly never be changed. Alternatively, it can be regenerated regularly, depending on deployment requirements.

IP is used ubiquitously. Some networks like industrial control bus (e.g. , , or even non-networked digital interfaces like have begun to use IP. In these kinds of networks, the system may lack the ability to communicate with the public networks. As another example, there may be some networks in which the equipment has the technical capability to connect to the Internet, but is prohibited by administration or just temporarily not connected. These networks may include separate financial networks, lab networks. machine-to-machine (e.g. vehicle networks), sensor networks, or even normal LANs, and can include very large numbers of addresses. Serious disadvantages and impact on applications due to the use of ambiguous address space have been well documented in . However, ULA is a straightforward way to assign the IP addresses in the kinds of networks just described, with minimal administrative cost or burden. Also, ULAs fit in multiple subnet scenarios, in which each subnet has its own ULA prefix. For example, when assigning vehicles with ULAs, it is then possible to separate in-vehicle embedded networks into different subnets depending on real-time situation. However, each isolated network has the possibility to be connected in the future. Administrators need to consider the following before deciding whether to use ULAs: If the network eventually connects to another isolated or private network, the potential for address collision arises. However, if the ULAs were generated in the standard way, this will not be a big problem. If the network eventually connects to the global Internet, then the operator will need to add a new global prefix and ensure that the address selection policy is properly set up on all interfaces. Operational considerations: Prefix generation: randomly generated according to the algorithms defined in or manually assigned. Normally, automatic generation of the prefixes is recommended, following . If there are some specific reasons that call for manual assignment, administrators have to plan the prefixes carefully to avoid collision. Prefix announcement: in some cases, networks might need to announce prefixes to each other. For example, in vehicle networks with infrastructure-less settings such as Vehicle-to-Vehicle (V2V) communication, prior knowledge of the respective prefixes is unlikely. Hence, a prefix announcement mechanism is needed to enable inter-vehicle communications based on IP. As one possibility, such announcements could rely on extensions to the Router Advertisement message of the Neighbor Discovery Protocol (e.g., and ).

In some situations, nodes in one network are assigned ULAs but not Global Unicast Addresses (GUAs), but the nodes also need to communicate with the outside network. There could be two approaches: Using Network Prefix Translation (NPTv6) NPTv6 is an experimental specification that provides a stateless one-to-one mapping between internal addresses and external addresses. Translating ULA prefixes into GUA prefixes is an use case of this specification. NPTv6 works differently from traditional stateful NAT/NAPT (which is discouraged in ). So it does not create several of the problems known to exsit with other kinds of NATs as discussed in and . However, NPTv6 Translation does create difficulties for some kinds of applications. (Please refer to Section 5 of for detailed analysis.) Using Application-Layer Proxies In this approach, the proxies terminate the network-layer connectivity of the hosts and associate separate internal and external connections. In some environments (e.g., information security sensitive enterprises or government departments), central control is exercised by allowing the endpoints to connect to the Internet only through a proxy. With IPv4, using private address space with proxies is an effective and common practice for this purpose, and it is natural to pick ULA as its counterpart in IPv6. Controversies of ULA-only Deployment The comunity has strong controversies of ULA-only deployment in connected networks. The main reason of those who are in favor of using ULAs this way is that it could get provider independent addresses or get connected from the isolated stage without applying to any RIRs/LIRs. This might be a essential benefit for the vast number of small organizations, for saving time and address fee. For those who are strongly against this usage, the main reason is to avoid breaking the end-to-end transparence. Because people have suffered from the NAT/Proxy middle boxes so much in the IPv4 ear, there is no reason to continue the suffering when IPv6 is available. So, according to the controversy, this document does not consider ULA+NPTv6/Proxy as a first choice for normal cases. Rather, this document considers ULA+PA (Provider Aggregated) as a better approach to connect to the global network when ULAs are expected to be retained. The use of ULA+PA is discussed in detail in below. Operational considerations: Firewall deployment: points out that an NPTv6 translator does not have the same security properties as a traditional NAT44, and hence needs be supplemented with a firewall if security at the boundary is an issue. The operator has to decide where to locate the firewall. If the firewall is located outside the NPTv6 translator, then filtering is based on the translated GUA prefixes, and when the internal ULA prefixes are renumbered, the filtering rules do not need to be changed. However, when the GUA prefixes of the NPTv6 are renumbered, the filtering rules need to be updated accordingly.). If the firewall is located inside the NPTv6 translator, the filtering is then based on the ULA prefixes, and the rules need to be updated correspondingly. There is no need to update when the NPTv6 GUA prefixes are renumbered.

Two classes of network might need to use ULA with PA (Provider Aggregated) addresses: Home network. Home networks are normally assigned with one or more globally routed PA prefixes to connect to the uplink of an ISP. In addition, they may need internal routed networking even when the ISP link is down. Then ULA is a proper tool to fit the requirement. requires the CPE to support ULA. Note: ULAs provide more benefit for multiple-segment home networks; for home networks containing only one segment, link-local addresses are better alternatives. Enterprise network. An enterprise network is usually a managed network with one or more PA prefixes or with a PI prefix, all of which are globally routed. The ULA can be used to improve internal connectivity and make it more resilient, or to isolate certain functions like OAM for servers. Benefits of Using ULAs in this scenario: Separated local communication plane: for either home networks or enterprise networks, the main purpose of using ULAs along with PA addresses is to provide a logically local routing plane separated from the global routing plane. The benefit is to ensure stable and specific local communication regardless of the ISP uplink failure. This benefit is especially meaningful for the home network or for private OAM function in an enterprise. Renumbering: in some special cases such as renumbering, enterprise administrators may want to avoid the need to renumber their internal-only, private nodes when they have to renumber the PA addresses of the rest of the network because they are changing ISPs, because the ISP has restructured its address allocations, or for some other reason. In these situations, ULA is an effective tool for addressing internal-only nodes. Even public nodes can benefit from ULA for renumbering, on their internal interfaces. When renumbering, as suggests, old prefixes continue to be valid until the new prefix(es) is(are) stable. In the process of adding new prefix(es) and deprecating old prefix(es), it is not easy to keep local communication disentangled from global routing plane change. If we use ULAs for local communication, the separated local routing plane can isolate the effects of global routing change. Drawbacks: Operational Complexity: there are some arguments that in practice the use of ULA+PA creates additional operational complexity. This is not a ULA-specific problem; the multiple-addresses-per-interface is an important feature of IPv6 protocol. Nevertheless, running multiple prefixes needs more operational consideration than running a single one. Operational considerations: Default Routing: connectivity may be broken if ULAs are used as default route. When using RIO (Route Information Option) in , specific routes can be added without a default route, thus avoiding bad user experience due to timeouts on ICMPv6 redirects. This behavior was well documented in as rule ULA-5 "An IPv6 CE router MUST NOT advertise itself as a default router with a Router Lifetime greater than zero whenever all of its configured and delegated prefixes are ULA prefixes." and along with rule L-3 "An IPv6 CE router MUST advertise itself as a router for the delegated prefix(es) (and ULA prefix if configured to provide ULA addressing) using the "Route Information Option" specified in Section 2.3 of . This advertisement is independent of having or not having IPv6 connectivity on the WAN interface.". However, it needs to be noticed that current OSes don't all support . SLAAC/DHCPv6 co-existing: Since SLAAC and DHCPv6 might be enabled in one network simultaneously; the administrators need to carefully plan how to assign ULA and PA prefixes in accordance with the two mechanisms. The administrators need to know the current issue of the SLAAC/DHCPv6 interaction (please refer to for details). Address selection: As mentioned in , there is a possibility that the longest matching rule will not be able to choose the correct address between ULAs and global unicast addresses for correct intra-site and extra-site communication. claims that a site-specific policy entry can be used to cause ULAs within a site to be preferred over global addresses. DNS relevant: if administrators choose not to do reverse DNS delegation inside of their local control of ULA prefixes, a significant amount of information about the ULA population may leak to the outside world. Because reverse queries will be made and naturally routed to the global reverse tree, so external parties will be exposed to the existence of a population of ULA addresses. provides more detailed situations on this issue. Administrators may need a split DNS to separate the queries from internal and external for ULA entries and GUA entries.

Generally, this document does not consider IPv4 to be in scope. But regarding ULA, there is a special case needs to be recognized, which is described in Section 3.2.2 of . When an enterprise has IPv4 Internet connectivity but does not yet have IPv6 Internet connectivity, and the enterprise wants to provide site-local IPv6 connectivity, a ULA is the best choice for site-local IPv6 connectivity. Each employee host will have both an IPv4 global or private address and a ULA. Here, when this host tries to connect to an outside node that has registered both A and AAAA records in the DNS, the host will choose AAAA as the destination address and the ULA for the source address according to the IPv6 preference of the default policy table defined in the old address selection standard . This will clearly result in a connection failure. The new address selection standard has corrected this behavior by preferring IPv4 than ULAs in the default policy table. However, there are still lots of hosts using the old standard , thus this could be an issue in real networks. Happy Eyeballs solves this connection failure problem, but unwanted timeouts will obviously lower the user experience. One possible approach to eliminating the timeouts is to deprecate the IPv6 default route and simply configure a scoped route on hosts (in the context of this document, only configure the ULA prefix routes). Another alternative is to configure IPv4 preference on the hosts, and not include DNS A records but only AAAA records for the internal nodes in the internal DNS server. Then outside nodes have both A and AAAA records and can be connected through IPv4 as default and internal nodes can always connect through IPv6. But since IPv6 preference is default, changing the default in all nodes is not suitable at scale.

ULA and are similar in some aspects. The most obvious one is as described in Section 3.1.3 that ULA provides an internal address independence capability in IPv6 that is similar to how is commonly used. ULA allows administrators to configure the internal network of each platform the same way it is configured in IPv4. Many organizations have security policies and architectures based around the local-only routing of addresses and those policies may directly map to ULA . But this does not mean that ULA is equal to an IPv6 version of deployment. usually combines with NAT/NAPT for global connectivity. But it is not necessary to combine ULAs with any kind of NAT. Operators can use ULA for local communications along with global addresses for global communications (see ). This is a big advantage brought by default support of multiple-addresses-per-interface feature in IPv6. (People may still have a requirement for NAT with ULA, this is discussed in . But people also need to keep in mind that ULA is not intentionally designed for this kind of use case.) Another important difference is the ability to merge two ULA networks without renumbering (because of the uniqueness), which is a big advantage over .

A ULA is by definition a prefix that is never advertised outside a given domain, and is used within that domain by agreement of those networked by the domain. So when using ULAs in a network, the administrators need to clearly set the scope of the ULAs and configure ACLs on relevant border routers to block them out of the scope. And if internal DNS is enabled, the administrators might also need to use internal-only DNS names for ULAs and might need to split the DNS so that the internal DNS server includes records that are not presented in the external DNS server.

As analyzed in , ULA is very suitable for isolated networks. Especially when there are subnets in the isolated network, ULA is a reasonable choice.

As described in , using ULAs along with PA addresses to provide a logically separated local plane can benefit OAM functions and renumbering.

Along with the general scenarios, this section provides some specific use cases that could benefit from using ULA.

For various reasons the administrators may want to have private routing be controlled and separated from other routing. For example, in the business-to-business case described in , two companies might want to use direct connectivity that only connects stated machines, such as a silicon foundry with client engineers that use it. A ULA provides a simple way to assign prefixes that would be used in accordance with an agreement between the parties.

The NAT64 PREF64 is just a group of local fake addresses for the DNS64 to point traffic to a NAT64. Using a ULA prefix as the PREF64 easily ensures that only local systems can use the translation resources of the NAT64 system since the ULA is not intended to be globally routable. The ULA helps clearly identify traffic that is locally contained and destined to a NAT64. Using ULA for PREF64 is deployed and it is an operational model. But there is an issue needs to be noted. The NAT64 standard specifies that the PREF64 should align with , in which the IPv4-Embedded IPv6 Address format was specified. If we pick a /48 for NAT64, it happens to be a standard 48/ part of ULA (7bit ULA well-known prefix+ 1 "L" bit + 40bit Global ID). Then the 40bit of ULA is not violated by being filled with part of the 32bit IPv4 address. This is important, because the 40bit assures the uniqueness of ULA. If the prefix is shorter than /48, the 40bit would be violated, and this could cause conformance issues. But it is considered that the most common use case will be a /96 PREF64, or even /64 will be used. So it seems this issue is not common in current practice. It is most common that ULA PREF64 will be deployed on a single internal network, where the clients and the NAT64 share a common internal network. ULA will not be effective as PREF64 when the access network must use an Internet transit to receive the translation service of a NAT64 since the ULA will not route across the Internet. According to the default address selection table specified in , the host would always prefer IPv4 over ULA. This could be a problem in NAT64-CGN scenario as analyzed in Section 8 of . So administrators need to add additional site-specific address selection rules to the default table to steer traffic flows going through NAT64-CGN. However, updating the default policy tables in all hosts involves significant management cost. This may be possible in an enterprise (using a group policy object, or other configuration mechanisms), but it is not suitable at scale for home networks.

ULAs could be self-generated and easily grabbed from the standard IPv6 stack. And ULAs don't need to be changed as the GUA prefixes do. So they are very suitable to be used as identifiers by the up layer applications. And since ULA is not intended to be globally routed, it is not harmful to the routing system. Such kind of benefit has been utilized in real implementations. For example, in , the protocol BTMM (Back To My Mac) needs to assign a topology-independent identifier to each client host according to the following considerations: TCP connections between two end hosts wish to survive in network changes. Sometimes one needs a constant identifier to be associated with a key so that the Security Association can survive the location changes. It needs to be noticed again that in theory ULA has the possibility of collision. However, the probability is desirably small enough and can be ignored in most cases when ULAs are used as identifiers.

Security considerations regarding ULAs, in general, please refer to the ULA specification . Also refer to , which shows how ULAs help with local network protection. As mentioned in , when using NPTv6, the administrators need to know where the firewall is located to set proper filtering rules. Also as mentioned in , if administrators choose not to do reverse DNS delegation inside their local control of ULA prefixes, a significant amount of information about the ULA population may leak to the outside world.

This memo has no actions for IANA.

Many valuable comments were received in the IETF v6ops WG mail list, especially from Cameron Byrne, Fred Baker, Brian Carpenter, Lee Howard, Victor Kuarsingh, Alexandru Petrescu, Mikael Abrahamsson, Tim Chown, Jen Linkova, Christopher Palmer Jong-Hyouk Lee, Mark Andrews, Lorenzo Colitti, Ted Lemon, Joel Jaeggli, David Farmer, Doug Barton, Owen Delong, Gert Doering, Bill Jouris, Bill Cerveny, Dave Thaler, Nick Hilliard, Jan Zorz, Randy Bush, Anders Brandt, , Sofiane Imadali and Wesley George. Some test of using ULA in the lab was done by our research partner BNRC-BUPT (Broad Network Research Centre in Beijing University of Posts and Telecommunications). Thanks for the work of Prof. Xiangyang Gong and student Dengjia Xu. Tom Taylor did a language review and revision throught the whole document. The authors appreciate a lot for his help. This document was produced using the xml2rfc tool (initially prepared using 2-Word-v2.0.template.dot.).