NAT64 Well-Known Prefix vs. Network-Specific Prefix

NAT is evil … and NAT-ing is bad …. Right? That is what we have all been taught since the beginning in “IPv6 school.” But what about a NAT that may be a necessary evil, and may help your enterprise on its journey to deploy IPv6? That is where NAT64 comes in.

During the long evolution of how to transition from IPv4 to IPv6, there have been numerous philosophical (and practical) twists and turns. From tunneling, to dual-stacking, to IPv6-mostly, all toward our ultimate goal of an IPv6-only world. Where the industry generally stands today is recommending IPv6-mostly. This is a middle ground between dual-stack and IPv6-only. The reality is that IPv4 still exists on the public internet and most certainly in your enterprise as well. IPv6-mostly is a framework where IPv6‑only endpoints and IPv4 endpoints coexist on the same network. IPv6 is the primary protocol, while IPv4 is still available on demand.

Since IPv6 and IPv4 are unable to directly communicate, translation technologies are required for the two endpoints to converse. Numerous transition technologies have been developed over the years, but today the most common techniques pertinent to enterprises are server load balancing (SLB64 & SLB46), typically used to front-end internal servers under the enterprise’s control, and NAT64, used by IPv6-only endpoints to access unknown/unmanaged IPv4 hosts—whether internal to the organization or on the broader internet. This blog will focus on the latter—and specifically, which type of prefix, well-known prefix (WKP) or network-specific prefix (NSP), to select when designing a NAT64 deployment.

What Is NAT64?

NAT64 (RFC 6146), which is an integral part of DNS64/NAT64 and 464XLAT (RFC 6877), is a stateful translation technology that allows IPv6-only clients to communicate with IPv4-only devices. Communication can be via Transmission Control Protocol (TCP), unicast User Datagram Protocol (UDP) or Internet Control Message Protocol (ICMP). The NAT64 translator device speaks IPv6 on one side and utilizes one or more source NAT IPv4 addresses on the back end to communicate with devices that speak the legacy internet protocol.

As noted above, both DNS64/NAT64 and 464XLAT utilize NAT64 translators. With DNS64/NAT64, a DNS64 server will synthesize (basically spoof) IPv6 records from IPv4-only DNS records (i.e., A records). When an IPv6-only device sends a DNS query for AAAA records for a server with only an A record, the DNS64 server will synthesize an AAAA record using a NAT64 prefix (also known as PREF64). This NAT64 prefix, which may be either a WKP (64:ff9b::/96) or an NSP, is combined with the IPv4 address to generate the IPv6 address. This address is subsequently routed to a NAT64 gateway. (For more information specifically on how DNS64 works, refer to Infoblox – About DNS64.)

With 464XLAT, a similar process takes place, however, without the use of DNS64. The client-side translator (CLAT) on the IPv6-only device (e.g., Windows 11 (support expected in fall 2025), iOS, Android, MacOS, Linux) presents an IPv4 stack to applications and locally translates any IPv4 packets to IPv6 using the NAT64 prefix (WKP or the NSP). These IPv6 packets are then forwarded to the provider-side translator (PLAT), which is simply a NAT64 device. Since 464XLAT does not utilize DNS64, the NAT64 prefix, whether WKP or NSP, is typically learned by the CLAT via Router Advertisement PREF64 (RFC 8781).

Devices that provide NAT64 translation run the gamut including enterprise-caliber routers, firewalls, load balancers (ADCs) as well as software applications such as Jool, Tayga and OpenWRT that can be installed on various platforms.

NAT64 Prefix Options

Whether you are planning to deploy 464XLAT or DNS64/NAT64 (or both, for a “belt and suspenders” approach), you have two general choices for your NAT64 prefix: (1) the WKP (64:ff9b::/96), or (2) an NSP.

The WKP, which is 64::ff9b::/96, is defined and reserved in RFC 6052. The benefits of using the WKP are simplicity and standardization. Operationally, it is easily recognizable as a NAT64 prefix. And some CLAT deployments will simply use the WKP by default without the need for any further discovery or configuration. This makes the WKP ideal for small or basic implementations. There are some limitations that accompany the WKP, however. The WKP is less flexible and scalable for larger, more complex deployments, possibly making the NSP a better option in those instances. Additionally, the WKP is only for public IPv4 addresses and is not for use with non-global IPv4 addresses, such as RFC 1918 numbers (Section 3.1 of RFC 6052).

Figure 1. Example: NAT64 using the WKP

Using an NSP for NAT64 provides flexibility and advanced routing capabilities that are not possible with the WKP. While the WKP is ideal for simple deployments, an NSP allows network operators to better control and manage traffic in more complex, large-scale environments. For example, it provides support for multiple NAT64 gateways. An organization can deploy multiple NAT64 gateways, each using a different NSP. This allows for load balancing and more granular traffic management, where a specific prefix can steer traffic to a particular NAT64 gateway. The benefits of this include scalability, the ability to use routing protocols for traffic engineering, to provide redundancy or facilitate graceful maintenance. If a NAT64 gateway needs to be taken down for maintenance, new connections can be routed to a gateway with a different NSP. Existing connections associated with the old prefix can continue to be served until they naturally time out, ensuring service continuity for end users.

Figure 2. Example: NAT64 using the NSP

The NSP also allows for external reachability. Unlike the WKP, an NSP can be globally routable across the internet. This enables external users and networks to reach IPv4 resources that are behind your NAT64 gateway. Along with the scalability and flexibility benefits come some potential downsides, however. Choosing the NSP over the WKP creates additional administrative overhead and requires more complex configuration in your environment. Also, some CLAT deployments may not honor an NSP. Therefore, the requirements for your specific IPv6 transition goals need to be weighed in conjunction with the tradeoffs outlined above. The table below summarizes, at a high level, these tradeoffs.

NAT64 Prefix Option	Pros	Cons
WKP	Ideal for basic implementations Simplicity Standardized prefix is operationally identifiable Many CLATs will utilize without any configuration	Less suited for more complex deployments Lacks flexibility Less scalable Not for use with private IPv4 addresses such as RFC 1918
NSP	Better suited for more complex deployments Scalability—allows for multiple gateways Routing protocol traffic engineering Externally routable Supports RFC 1918 and reserved IPv4 addresses	Additional configuration Administrative overhead May not be supported by some CLAT deployments

Other Considerations

If an organization implements the NSP for their NAT64 deployment, they may want to still route WKP traffic to a logging device—even though the WKP is not being used by the translator. Some devices, IoT or otherwise, may not honor PREF64 and simply use 64::ff9b::/96 despite being instructed otherwise. Using a device to capture this traffic and log it can assist in fixing broken implementations. If there is a vendor involved, the problem can be brought to their attention so they can remediate the faulty behavior.

Another reality to be mindful of is that NAT64 is still NAT, and NATs are not perfect. Applications can break during the translation. Therefore, it is important to test all critical services with your NAT64 deployment and identify applications that may need to be updated—such as programs with embedded IPv4 addresses. These will need to be corrected, or a workaround may be required. In some instances, your NAT64 gateway platform may support application layer gateways (ALGs) to process and correct some well-known offenders, such as File Transfer Protocol (FTP), Session Initiation Protocol (SIP) and Point-to-Point Tunneling Protocol (PPTP).

Despite NAT64 being imperfect, the technology is quite mature and well tested, even in very large-scale deployments. Many mobile carriers, having long since exhausted public and private IPv4 address space, deploy IPv6-only networks, and have utilized 464XLAT (NAT64) for years. It is quite likely you have been using it on your mobile phone without knowing it (which is the ultimate indicator of success). Point being, NAT64 it is a mature and proven IPv6 transition technology.

Conclusion

On your journey to deploy IPv6, multiple transition technologies will likely be deployed. One of these tools, whether DNS64/NAT64 or 464XLAT (or both), will likely rely on NAT64 translators. When implementing NAT64, there are tradeoffs in deciding whether to utilize the WKP or an NSP. The former is better suited for smaller, simple deployments, where the latter allows for more flexibility and better scalability, albeit at the cost of additional configuration and administrative overhead. The overview above will hopefully help you in evaluating your organization’s requirements and weighing the benefits of each option to find the best fit. Regardless of the prefix path you choose, NAT64 is a mature technology that has been well tested and proven in the industry.