RFC 8683
Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks
RFC 8683: Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks 🎀✨
Okay bestie, let's get into this one. 💅 It's Informational, not a Standards Track spec, so think of it as a super detailed how-to guide written by the IETF. 🌈 It came out in November 2019, it's ISSN 2070-1721, and the author is J. Palet Martinez from The IPv6 Company. 🦋 It doesn't obsolete anything, and it doesn't update anything either. Lowkey iconic, no cap. 🧚
Abstract
Okay so the vibe here is: how do you deploy NAT64 (including 464XLAT) in an IPv6 network? 🌸 Whether that network is a cellular ISP, a broadband ISP, or an enterprise, this doc walks through the deployment options and the optimizations you can make. 💖 It also talks about the stuff you have to think about when you're IPv6-only, like a) DNS64, b) apps or devices that use literal IPv4 addresses or non-IPv6-compliant APIs, and c) IPv4-only hosts or apps. 😭 Main character energy for the whole networking world. 👑
Status of This Memo
This document is not an Internet Standards Track specification. It's published for informational purposes, so it's not a standard, just a very helpful guide. 🍓
It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. ✨ It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). 💅 Not every IESG-approved doc is a candidate for an Internet Standard, though. See Section 2 of RFC 7841. 🙈
If you want the current status, any errata, or a way to send feedback, go to https://www.rfc-editor.org/info/rfc8683. 🦋
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. 🔥
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc. 💀 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per that same Simplified BSD License. 🫶
Table of Contents 🧚
1. Introduction
2. Requirements Language
3. NAT64 Deployment Scenarios
3.1. Known to Work
3.1.1. Service Provider NAT64 with DNS64
3.1.2. Service Provider Offering 464XLAT Using DNS64
3.1.3. Service Provider Offering 464XLAT, without Using DNS64
3.2. Known to Work under Special Conditions
3.2.1. Service Provider NAT64 without DNS64
3.2.2. Service-Provider NAT64; DNS64 in IPv6 Hosts
3.2.3. Service-Provider NAT64; DNS64 in the IPv4-Only Remote
Network
3.3. Comparing the Scenarios
4. Issues to be Considered
4.1. DNSSEC Considerations and Possible Approaches
4.1.1. Not Using DNS64
4.1.2. DNSSEC Validator Aware of DNS64
4.1.3. Stub Validator
4.1.4. CLAT with DNS Proxy and Validator
4.1.5. ACL of Clients
4.1.6. Mapping Out IPv4 Addresses
4.2. DNS64 and Reverse Mapping
4.3. Using 464XLAT with/without DNS64
4.4. Foreign DNS
4.4.1. Manual Configuration of DNS
4.4.2. DNS Privacy/Encryption Mechanisms
4.4.3. Split DNS and VPNs
4.5. Well-Known Prefix (WKP) vs. Network-Specific Prefix (NSP)
4.6. IPv4 Literals and Non-IPv6-Compliant APIs
4.7. IPv4-Only Hosts or Applications
4.8. CLAT Translation Considerations
4.9. EAM Considerations
4.10. Incoming Connections
5. Summary of Deployment Recommendations for NAT64/464XLAT
6. Deployment of 464XLAT/NAT64 in Enterprise Networks
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Example of Broadband Deployment with 464XLAT
Appendix B. CLAT Implementation
Appendix C. Benchmarking
Acknowledgements
Author's Address1. Introduction ✨
Okay so, Stateful NAT64 [RFC6146] is a stateful IPv6-to-IPv4 translation mechanism. 🦋 It lets IPv6-only hosts talk to IPv4-only servers over unicast UDP, TCP, or ICMP, and it does this by sharing public IPv4 addresses across lots of IPv6-only hosts. 🌸 Unless otherwise stated, when this document says NAT64 (function), it means Stateful NAT64. 💅
Packet headers get translated using the IP/ICMP translation algorithm defined in [RFC7915]. The IPv4 and IPv6 addresses get algorithmically translated back and forth following [RFC6052]. 🧚
DNS64 [RFC6147] is the one that synthesizes AAAA records from A records, so it only works for apps that use DNS. 💖 It was designed so that neither the IPv6-only hosts nor the IPv4-only server would need changes, which means they can use a NAT64 function. 🫶 As Section 5.5 of [RFC6147] discusses, a security-aware, validating host has to perform the DNS64 function locally. 🔥
But using NAT64 and/or DNS64 comes with three drawbacks: 😭
- Because DNS64 [RFC6147] modifies DNS answers, and DNSSEC is designed to detect exactly that kind of modification, DNS64 [RFC6147] may potentially break DNSSEC. Whether it does depends on a bunch of factors: where the DNS64 function lives (a DNS server or validator, the end host, ...), how it's configured, whether the end hosts are validating, and so on. 💀
- Because you need DNS64 [RFC6147] or some alternative "host/application built-in" mechanism for address synthesis, NAT64 [RFC6146] can have an issue: it doesn't work when IPv4 literal addresses or non-IPv6-compliant APIs are being used. 🙈
- NAT64 alone was not designed to cover IPv4-only hosts or applications that sit inside a network and are connected to a service provider's IPv6-only access link. It was built for one very specific scenario (see Section 2.1 of [RFC6144]). 🍓
These drawbacks can show up if part of an enterprise network connects to other parts of the same network, or to third-party networks, over IPv6-only connectivity. 🌈 That's just one example, though, and plenty of similar cases exist. 💜 All of them are deployment specific. ✨
So the terms "operator", "operator network", "service provider", and similar ones are interchangeable with the equivalent enterprise network cases, and other cases may be similar too. 🎀 The same goes for "managed end-user networks". 💅
Now, if every host in a network were doing address synthesis, as described in Section 7.2 of [RFC6147], some of those drawbacks might not apply. 🦋 But honestly? That's unrealistic today, given how many devices and apps aren't IPv6 enabled yet. 😭 So this document only considers the case where all hosts do synthesis for specific scenarios that can guarantee it. 🫶
If you want an analysis of stateful IPv4/IPv6 mechanisms, check out [RFC6889]. 🧚
This document looks at different NAT64 [RFC6146] deployment scenarios, including IPv4-IPv6-IPv4 (464 for short) and similar ones that weren't documented in [RFC6144]. That includes 464XLAT [RFC6877] in operator (broadband and cellular) and enterprise networks. It also gives guidelines to help avoid operational issues. 🌸
It explores the possible NAT64 deployment scenarios, split into "known to work" and "known to work under special conditions", and gives a quick, generic comparison table between them. 💖 Then it covers the issues an operator needs to understand so the best approach can be picked for each specific network. ✨ A summary gives some recommendations and decision points, and there's a section with clarifications for using this doc in enterprise networks. 👑 Finally, Appendix A is an example of a broadband deployment using 464XLAT, plus hints for a customer-side translator (CLAT) implementation. 🌈
[RFC7269] already covers NAT64 deployment options and experiences. 🦋 This doc and [RFC7269] are complementary, since they look at different deployment considerations. Plus, this doc takes into account the updated deployment experience and newer standards. 💅
The target deployment scenarios here may also be covered by other IPv4-as-a-Service (IPv4aaS) transition mechanisms. 🧚 But that's only true for broadband networks. For cellular networks, the only supported solution is NAT64/464XLAT. 😭 So comparing the different IPv4aaS transition mechanisms is out of scope for this document, and those are analyzed in [IPv6-TRANSITION]. 🫶
So this doc shouldn't be used as a guide for an operator or enterprise to decide which IPv4aaS is best for its own network. 🙈 Instead, use it as a tool to understand all the implications, including relevant documents (or even specific parts of them) for deploying NAT64/464XLAT, and to make the decision process around specific deployment details easier. 💜
2. Requirements Language 🎀
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 💅 Translation: these words only carry their special meaning when they're in ALL CAPS. 🌸
3. NAT64 Deployment Scenarios 🦋
DNS64 (see Section 7 of [RFC6147]) provides three deployment scenarios, depending on where the DNS64 function lives. 🧚 But since that document came out, other deployment scenarios and NAT64 use cases have shown up in real networks, even though some of them were specifically ruled out by the original NAT64/DNS64 work. 😭
So the perspective in this doc is to broaden those scenarios and add a few new ones. 💖 To keep the number of possible cases manageable, we work under the assumption that the service provider wants every customer to have service without failures. 🫶 That means considering the following assumptions for the worst possible case:
a. There are hosts that will be validating DNSSEC. 🔥
b. IPv4 literal addresses and non-IPv6-compliant APIs are being used. 💀
c. There are IPv4-only hosts or applications beyond the IPv6-only link (e.g., tethering in cellular networks). 🙈
This doc uses a common set of possible "participant entities":
- An IPv6-only access network (IPv6). 🍓
- An IPv4-only remote network/server/service (IPv4). 🌈
- A NAT64 function (NAT64) in the service provider. 💜
- A DNS64 function (DNS64) in the service provider. ✨
- An external service provider offering the NAT64 function and/or the DNS64 function (extNAT64/extDNS64). 🎀
- A 464XLAT customer-side translator (CLAT). 💅
Note that the nomenclature in parentheses is the short form that gets used in the figures. 🦋 Also, the boxes in the figures don't mean they're each a single device. They represent one or more functions located in that part of the network. For example, a single box with NAT64 and DNS64 functions could actually be several devices, not just one. 🧚
The possible scenarios are split into two general categories: 🌸
- Known to work. ✨
- Known to work under special conditions. 💖
Okay that's part 1 done, bestie! 🫶 There's more coming in the next parts, so stay tuned. 💅🌈
3.1. Known to Work ✨
okay so this whole category is the "we KNOW this works" crew 💅 there are real, well-known deployments from different operators using these setups. each one comes with its own pros and cons, and for some operators the trade-offs are totally worth it 🫶
3.1.1. Service Provider NAT64 with DNS64
in this scenario (Figure 1), the service provider runs both the NAT64 and DNS64 functions 🎀
this is the most common setup, the one the designers of NAT64 [RFC6146] and DNS64 [RFC6147] originally had in mind 🌸 it can also come with DNSSEC implications tho, so keep that in your back pocket 👀
this scenario might also not fix the issues with IPv4 literal addresses, non-IPv6-compliant APIs, or IPv4-only hosts or applications sitting behind the IPv6-only access network 💀
+----------+ +----------+ +----------+
| | | NAT64 | | |
| IPv6 +--------+ + +--------+ IPv4 |
| | | DNS64 | | |
+----------+ +----------+ +----------+
Figure 1: NAT64 with DNS64there's a similar vibe (Figure 2) if the service provider only does the DNS64 part, and the NAT64 function comes from an outsourcing deal with an external provider 🧚 all the considerations in the previous paragraphs of this section are the same for this sub-case ✨
+----------+ +----------+
| | | |
| extNAT64 +--------+ IPv4 |
| | | |
+----+-----+ +----------+
|
|
+----------+ +----+-----+
| | | |
| IPv6 +--------+ DNS64 +
| | | |
+----------+ +----------+
Figure 2: NAT64 in an External Service Providerthen this is equivalent to the scenario (Figure 3) where the outsourcing agreement with the external provider covers both the NAT64 and DNS64 functions 🫶 once more, all the considerations in the previous paragraphs of this section are the same for this sub-case 💖
+----------+ +----------+
| extNAT64 | | |
| + +-------+ IPv4 |
| extDNS64 | | |
+----+-----+ +----------+
|
+----------+ |
| | |
| IPv6 +-------------+
| |
+----------+
Figure 3: NAT64 and DNS64 in an External Providerone more equivalent scenario (Figure 4) happens if the service provider only offers the NAT64 function, and the DNS64 function comes from an external provider, with or without a specific agreement between them 🌈 this is a super common setup today, because several "global" service providers offer free DNS/DNS64 services and users often configure their DNS manually 👑 this will only work if both the NAT64 and DNS64 functions are using the Well-Known Prefix (WKP) or the same Network-Specific Prefix (NSP) 🔥 all the considerations in the previous paragraphs of this section are the same for this sub-case 🦋
of course, if the external DNS64 function is agreed with the service provider, then this case is basically similar to the ones already shown in this scenario 💅
+----------+
| |
| extDNS64 |
| |
+----+-----+
|
|
+----------+ +----+-----+ +----------+
| | | | | |
| IPv6 +--------+ NAT64 +--------+ IPv4 |
| | | | | |
+----------+ +----------+ +----------+
Figure 4: NAT64; DNS64 by an External Provider3.1.2. Service Provider Offering 464XLAT Using DNS64
464XLAT [RFC6877] describes an architecture that gives IPv4 connectivity across a network, or part of it, when that network is only natively carrying IPv6 🦋 the need to support the CLAT function so IPv4 service keeps working in IPv6-only cellular deployments has been suggested in [RFC7849] 📱
so, to pull this off, 464XLAT [RFC6877] leans on a combo of existing protocols 🧩
- the CLAT is a stateless IPv4-to-IPv6 translator (NAT46) [RFC7915] that's implemented in the end-user device or Customer Edge Router (CE), sitting at the "customer edge" of the network 🏠
- the provider-side translator (PLAT) is a stateful NAT64 [RFC6146], typically implemented in the operator network 🏢
- optionally, DNS64 [RFC6147] may allow an optimization: a single translation at the NAT64, instead of two translations (NAT46+NAT64), when the application on the end-user device supports IPv6 DNS (uses AAAA Resource Records) ✨
ngl the provider-side translator is called PLAT in the 464XLAT terminology [RFC6877], but for simplicity and uniformity across this document, it's always called NAT64 (function) 💖
in this scenario (Figure 5), the service provider deploys 464XLAT with a DNS64 function 🎀
as a result, the DNSSEC issues remain, unless the host is doing the address synthesis 👀
464XLAT [RFC6877] is a very simple way to deal with the major NAT64+DNS64 drawback: not working with applications or devices that use literal IPv4 addresses or non-IPv6-compliant APIs 🙈
464XLAT [RFC6877] has been used mainly in IPv6-only cellular networks 📱 by supporting a CLAT function, end-user device applications can reach IPv4-only end networks / applications, even when those applications or devices use literal IPv4 addresses or non-IPv6-compliant APIs 🫶
also, in the cellular network example above, if the User Equipment (UE) provides tethering, other devices behind it will see a traditional Network Address Translation from IPv4 to IPv4 (NAT44), on top of the native IPv6 support, so it clearly lets IPv4-only hosts behind the IPv6-only access network work 🌸
and as discussed in [RFC6877], 464XLAT can be used in broadband IPv6 network architectures too, by implementing the CLAT function at the CE 🌈
supporting this scenario in a network gives two extra perks 🍓
- DNS load optimization: a CLAT should implement a DNS proxy (per [RFC5625]) so that only IPv6-native queries and AAAA records are sent to the DNS64 server. otherwise, doubling the number of queries may impact the DNS infrastructure 😭
- Connection establishment delay optimization: if the UE/CE implementation detects the presence of a DNS64 function, it may issue only the AAAA query, instead of both the AAAA and A queries 🧚
to understand all the communication possibilities, let's assume the following representation of two dual-stack (DS) peers 🔍
+-------+ .-----. .-----.
| | / \ / \
.-----. | Res./ | / IPv6- \ .-----. / IPv4- \
/ Local \ | SOHO +--( only )---( NAT64 )---( only )
/ \ | | \ flow /\ `-----' \ flow /
( Dual- )--+ IPv6 | \ / \ / \ /
\ Stack / | CE | `--+--' \ .-----. / `--+--'
\ Peer / | with | | \ / Remote\/ |
`-----' | CLAT | +---+----+ / \ +---+----+
| | |DNS/IPv6| ( Dual- ) |DNS/IPv4|
+-------+ | with | \ Stack / +--------+
| DNS64 | \ Peer /
+--------+ `-----'
Figure A: Representation of 464XLAT among Two Peers with DNS64in this case, the possible communication paths between the IPv4/IPv6 stacks of both peers are as follows 🗺️
a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among peers.
b. Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation.
c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT implements Explicit Address Mappings (EAMs) as indicated by Section 4.9. In principle, it is not expected that services are deployed in the Internet when using IPv6 only, unless there is certainty that peers will also be IPv6 capable. 🙃
d. Local-IPv4 to Remote-IPv4: DNS64, CLAT, and NAT64 translations.
e. Local-IPv4 to Remote-dual-stack using EAM optimization: if the CLAT implements EAM as indicated by Section 4.9, instead of using the path d. above, NAT64 translation is avoided, and the flow will use IPv6 from the CLAT to the destination ✨
the rest of the figures in this section show different choices for placing the different elements 🎀
+----------+ +----------+ +----------+
| IPv6 | | NAT64 | | |
| + +--------+ + +--------+ IPv4 |
| CLAT | | DNS64 | | |
+----------+ +----------+ +----------+
Figure 5: 464XLAT with DNS64there's a similar scenario (Figure 6) if the service provider only offers the DNS64 function, and the NAT64 function comes from an outsourcing agreement with an external provider 🧚 all the considerations in the previous paragraphs of this section are the same for this sub-case 💜
+----------+ +----------+
| | | |
| extNAT64 +--------+ IPv4 |
| | | |
+----+-----+ +----------+
|
|
+----------+ +----+-----+
| IPv6 | | |
| + +--------+ DNS64 +
| CLAT | | |
+----------+ +----------+
Figure 6: 464XLAT with DNS64; NAT64 in an External Providerit's also equivalent to the scenario (Figure 7) where the outsourcing agreement with the external provider covers both the NAT64 and DNS64 functions 🫶 once more, all the considerations in the previous paragraphs of this section are the same for this sub-case 💅
+----------+ +----------+
| extNAT64 | | |
| + +--------+ IPv4 |
| extDNS64 | | |
+----+-----+ +----------+
|
+----------+ |
| IPv6 | |
| + +-------------+
| CLAT |
+----------+
Figure 7: 464XLAT with DNS64; NAT64 and DNS64 in an External Provider3.1.3. Service Provider Offering 464XLAT, without Using DNS64 ✨
okay so this one is the "no DNSSEC drama" scenario and I'm obsessed 💅 The big win (Figure 8) of running 464XLAT without DNS64 is that the service provider makes sure DNSSEC is never broken, even if the user messes around with the DNS configuration 🔐🦋 Nevertheless, some CLAT implementations or applications may add an extra delay 😭 because they send the dual A/AAAA queries and then have to wait for both answers, unless Happy Eyeballs v2 [RFC8305] is also present 🫶
A possible variation is when DNS64 is only used to discover the NAT64 prefix. This isn't treated as a different scenario in the rest of the document 🧚 Once the prefix has been discovered, the DNS64 function isn't used, so it acts as if the DNS64 synthesis function isn't there at all 💜
In this scenario, just like the last one, there are no issues with IPv4-only hosts (or IPv4-only applications) behind the IPv6-only access network 🌸 Those problems don't come up because they aren't about using IPv4 literals or non-IPv6-compliant APIs 🙈
The support of this scenario in a network gives you one perk:
- DNS load optimization 🍓: A CLAT should implement a DNS proxy (per [RFC5625]) so that only IPv6 native queries are sent to the DNS64 server. Otherwise, doubling the number of queries may impact the DNS infrastructure.
As mentioned earlier, the connection establishment delay optimization only happens for devices, Operating Systems, or applications that use Happy Eyeballs v2 [RFC8305], which is very common 👑
As before, let's picture two dual-stack peers:
+-------+ .-----. .-----.
| | / \ / \
.-----. | Res./ | / IPv6- \ .-----. / IPv4- \
/ Local \ | SOHO +--( only )---( NAT64 )---( only )
/ \ | | \ flow /\ `-----' \ flow /
( Dual- )--+ IPv6 | \ / \ / \ /
\ Stack / | CE | `--+--' \ .-----. / `--+--'
\ Peer / | with | | \ / Remote\/ |
`-----' | CLAT | +---+----+ / \ +---+----+
| | |DNS/IPv6| ( Dual- ) |DNS/IPv4|
+-------+ +--------+ \ Stack / +--------+
\ Peer /
`-----'
Figure B: Representation of 464XLAT among Two Peers without DNS64In this case, the possible communication paths between the IPv4/IPv6 stacks of both peers are:
a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among peers.
b. Local-IPv6 to Remote-IPv4: Regular DNS, CLAT, and NAT64 translations.
c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT implements EAM as indicated by Section 4.9. In principle, it is not expected that services are deployed in the Internet using IPv6 only, unless there is certainty that peers will also be IPv6-capable.
d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT, and NAT64 translations.
e. Local-IPv4 to Remote-dual-stack using EAM optimization: If the CLAT implements EAM as indicated by Section 4.9, instead of using path d. above, NAT64 translation is avoided, and the flow will use IPv6 from the CLAT to the destination.
Notice that this scenario works while the local hosts/applications are dual stack (which is the current situation) 💖 because connectivity from a local IPv6 to a remote IPv4 isn't possible without AAAA synthesis. This only matters when there are IPv6-only hosts in the LANs behind the CLAT that need to talk to remote IPv4-only hosts 🧐 However, it's not a sensible approach for an Operating System or application vendor to offer IPv6-only support unless, like case c above, there's certainty of peers supporting IPv6 as well 🙅♀️ An approach to a solution for this is also presented in [OPT-464XLAT].
The following figures show different choices for placing the different elements 🎀
+----------+ +----------+ +----------+
| IPv6 | | | | |
| + +--------+ NAT64 +--------+ IPv4 |
| CLAT | | | | |
+----------+ +----------+ +----------+
Figure 8: 464XLAT without DNS64This is equivalent to the scenario (Figure 9) where there's an outsourcing agreement with an external provider for the NAT64 function. All the considerations in the previous paragraphs of this section are the same for this sub-case 🤝
+----------+ +----------+
| | | |
| extNAT64 +--------+ IPv4 |
| | | |
+----+-----+ +----------+
|
+----------+ |
| IPv6 | |
| + +-------------+
| CLAT |
+----------+
Figure 9: 464XLAT without DNS64; NAT64 in an External Provider3.2. Known to Work under Special Conditions 🚧
okay this category is the "proceed with caution" zone ⚠️ The scenarios here are known NOT to work unless someone puts in serious effort to fix the issues, or they're meant to solve problems across "closed" networks instead of general Internet access 🔒 Even though some of the pros, cons, and trade-offs might be acceptable, operators have implementation difficulties, because their expectations of NAT64/DNS64 go beyond the original intent 😵💫
3.2.1. Service Provider NAT64 without DNS64 🙃
In this scenario (Figure 10), the service provider offers a NAT64 function, but there's no DNS64 function support at all 💀
As a consequence, an IPv6 host in the IPv6-only access network won't be able to detect DNS64 presence by means of [RFC7050], or learn the IPv6 prefix to be used for the NAT64 function 😩
This can be sorted out as indicated in Section 4.1.1 🔧
Regardless, because there's no DNS64 function, the IPv6 host won't be able to get AAAA synthesized records, so the NAT64 function becomes useless 😭
An exception to this "useless" scenario is to manually configure mappings between the A records of each IPv4-only remote host and the corresponding AAAA records using the WKP or NSP used by the service-provider NAT64 function, as if they were synthesized by a DNS64 function ✨
This mapping could be done in several ways, typically at the authoritative DNS server or at the service-provider resolvers, using DNS Response Policy Zones (RPZs) [DNS-RPZ] or equivalent functionality 🗂️ DNS RPZ may have implications for DNSSEC if the zone is signed. Also, if the service provider uses an NSP, having the mapping at the authoritative server may cause trouble for other parties trying to use a different NSP or WKP, unless multiple DNS "views" (split-DNS) are also in use at the authoritative servers 🧩
Generally, the mapping alternative only makes sense if a few sets of IPv4-only remote hosts need to be reached by a single network (or a small number of them) that supports IPv6 only in the access 📡 This will require some kind of mutual agreement to use this procedure, and that should not be a problem because it won't interfere with Internet use (which is a "closed service") 🤞
In any case, this scenario doesn't solve the issue of IPv4 literal addresses, non-IPv6-compliant APIs, or IPv4-only hosts within that IPv6-only access network 🚫
+----------+ +----------+ +----------+
| | | | | |
| IPv6 +--------+ NAT64 +--------+ IPv4 |
| | | | | |
+----------+ +----------+ +----------+
Figure 10: NAT64 without DNS643.2.2. Service-Provider NAT64; DNS64 in IPv6 Hosts 🖥️
In this scenario (Figure 11), the service provider offers the NAT64 function but not the DNS64 function. However, the IPv6 hosts have a built-in DNS64 function 🧠
This may become common if DNS64 gets implemented in all the IPv6 hosts/stacks. It's not common at the time of writing but may become more common in the near future 🔮 That way, DNSSEC validation is performed on the A record, and then the host can use the DNS64 function to reach the NAT64 function without any DNSSEC issues 🔐✨
This scenario fails to solve the issue of IPv4 literal addresses or non-IPv6-compliant APIs, unless the IPv6 hosts also support Happy Eyeballs v2 (Section 7.1 of [RFC8305]) 💔
Moreover, this scenario also fails to solve the problem of IPv4-only hosts or applications behind the IPv6-only access network 😬
+----------+ +----------+ +----------+
| IPv6 | | | | |
| + +--------+ NAT64 +--------+ IPv4 |
| DNS64 | | | | |
+----------+ +----------+ +----------+
Figure 11: NAT64; DNS64 in IPv6 Hosts3.2.3. Service-Provider NAT64; DNS64 in the IPv4-Only Remote Network 🌍
In this scenario (Figure 12), the service provider offers the NAT64 function only. The IPv4-only remote network offers the DNS64 function 🤔
This is not common, and it doesn't make sense for a remote network that isn't deploying IPv6 to be providing a DNS64 function 🙃 Like the scenario in Section 3.2.1, it will only work if both sides use the WKP or the same NSP, so the same considerations apply. It can also be tuned to behave as in Section 3.1.1 🔁
This scenario fails to solve the issue of IPv4 literal addresses or non-IPv6-compliant APIs 🙅
Moreover, this scenario also fails to solve the problem of IPv4-only hosts or applications behind the IPv6-only access network 😵
+----------+ +----------+ +----------+
| | | | | IPv4 |
| IPv6 +--------+ NAT64 +--------+ + |
| | | | | DNS64 |
+----------+ +----------+ +----------+
Figure 12: NAT64; DNS64 in IPv4-Only Hosts3.3. Comparing the Scenarios
okay bestie, it's showdown time 💅✨ we're putting every setup from the last sections head to head. the comparison uses six criteria (a through f), so let's go:
- a. DNSSEC: Are there hosts validating DNSSEC? 🔐
- b. Literal/APIs: Are there applications using IPv4 literals or non-IPv6-compliant APIs? 🙈
- c. IPv4 only: Are there hosts or applications using IPv4 only?
- d. Foreign DNS: Does the scenario survive if the user, Operating System, applications, or devices change the DNS?
- e. DNS load opt. (DNS load optimization): Are there extra queries that may impact the DNS infrastructure?
- f. Connect. opt. (connection establishment delay optimization): Is the UE/CE only issuing the AAAA query or also the A query and waiting for both responses?
In the table below, the columns are the scenarios from the previous sections, labeled by figure number. The symbols mean:
-means the scenario is "bad" for that criterion.+means the scenario is "good" for that criterion.*means the scenario is "bad" for that criterion, but it's typically fixed with the help of Happy Eyeballs v2 [RFC8305].
Some "bad" criteria can be countered with alternative or special configurations, so this is a generic quick-glance guide, not the final word 🧚 Also, a "bad" mark isn't always a problem. It depends on what your network actually needs. For example, if a network only has IPv6-only hosts and apps that use DNS and IPv6-compliant APIs, using only NAT64 and DNS64 has no impact. But if those hosts validate DNSSEC, that criterion still matters.
+---------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Item / Figure | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
+===============+===+===+===+===+===+===+===+===+===+====+====+====+
| DNSSEC | - | - | - | - | - | - | - | + | + | + | + | + |
+---------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Literal/APIs | - | - | - | - | + | + | + | + | + | - | - | - |
+---------------+---+---+---+---+---+---+---+---+---+----+----+----+
| IPv4-only | - | - | - | - | + | + | + | + | + | - | - | - |
+---------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Foreign DNS | - | - | - | - | + | + | + | + | + | - | + | - |
+---------------+---+---+---+---+---+---+---+---+---+----+----+----+
| DNS load opt. | + | + | + | + | + | + | + | + | + | + | + | + |
+---------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Connect. opt. | + | + | + | + | + | + | + | * | * | + | + | + |
+---------------+---+---+---+---+---+---+---+---+---+----+----+----+
Table 1: Scenario ComparisonThe big takeaway: if your network has to support any of these, you're in the spotlight:
- IPv4 literals
- non-IPv6-compliant APIs
- IPv4-only hosts or applications
In that case, only the scenarios with 464XLAT, a CLAT function, or equivalent built-in local address synthesis features will give you a valid solution 🦋 Those scenarios also keep working if the DNS configuration changes. Depending on whether DNS64 is used, DNSSEC may break for the hosts doing DNSSEC validation, so keep that in mind.
Every scenario is good for DNS load optimization, and with 464XLAT you may get an extra bit of optimization on top. All of the scenarios are also good for connection establishment delay optimization, but 464XLAT without DNS64 requires the usage of Happy Eyeballs v2. This isn't a big deal since it's commonly available in actual Operating Systems 💖
4. Issues to be Considered
This section goes through the issues an operator needs to think about for a NAT64/464XLAT deployment, since they can shape the decisions made about how to approach that deployment 👑
4.1. DNSSEC Considerations and Possible Approaches
As the security considerations for DNS64 point out (see Section 8 of [RFC6147]), DNS64 changes DNS answers, and DNSSEC is designed to detect exactly that kind of change. So DNS64 may break DNSSEC 😭
When a device on an IPv6-only access network asks for a domain name in a signed zone through a recursive name server that supports DNS64, the result may be a synthesized AAAA record. If that recursive name server is set up to do DNSSEC validation and has a valid chain of trust to the zone in question, it will cryptographically validate the negative response from the authoritative name server. This is the expected DNS64 behavior: the recursive name server actually "lies" to the client device 🙈 Still, in most cases the client won't notice, because it usually doesn't validate on its own. It relies on its recursive name servers instead.
A validating DNS64 resolver actually boosts confidence in the synthetic AAAA, since it has verified that a non-synthetic AAAA doesn't exist. But if the client device is oblivious to NAT64 (the most common case) and does DNSSEC validation on the AAAA record, it will fail, because that record was synthesized.
The best possible DNSSEC scenario is when the client asks the DNS64 server to do the DNSSEC validation (by setting the DNSSEC OK (DO) bit to 1 and the CD bit to 0). In this case, the DNS64 server validates the data, so tampering can only happen inside the DNS64 server (which counts as a trusted part, so the likelihood is low) or between the DNS64 server and the client. All other parts of the system, including transmission and caching, are protected by DNSSEC [Threat-DNS64] 🧁
Similarly, if the client querying the recursive name server is another name server set up to use it as a forwarder, and that name server is doing DNSSEC validation, it will also fail on any synthesized AAAA record.
All of those considerations are covered in depth in Sections 3, 5.5, and 6.2 of [RFC6147].
DNSSEC issues could be avoided if all the signed zones provided IPv6 connectivity together with the matching AAAA records. But that's outside the control of the operator who needs to deploy a NAT64 function. This has already been proposed in [DNS-DNSSEC].
Another solution, considered while [RFC6147] was being developed, is for validators to be DNS64 aware. That way, they can do the necessary discovery and handle the synthesis themselves. Since this was standardized early enough in the validator deployment curve, the expectation was that it would be okay to break certain DNSSEC assumptions for networks that were stuck and really needed NAT64/DNS64 ✨
As already mentioned, the scenarios in the previous section are simplified to look at the worst possible case and the most perfect approach. A DNSSEC breach won't happen if the end host isn't doing validation 🌸
Previous studies show that DNSSEC broken by using DNS64 makes up about 1.7% [About-DNS64] of cases. But we can't rule out that this number will grow as DNSSEC deployment grows. So the operator has a decision to make, based on this question: Do I really care about that percentage of cases and the impact on my help desk, or can I provide alternative solutions for them? Some solutions may exist, as the next sections show 🦋
4.1.1. Not Using DNS64
One solution is to avoid using DNS64, but as already mentioned, this isn't possible in every scenario.
DNS64 is a key component for some networks that need to meet traffic performance metrics monitored by governmental bodies and other institutions [FCC] [ARCEP] 📊
One drawback of not having DNS64 on the network side is that it's not possible to heuristically discover NAT64 [RFC7050]. As a result, an IPv6 host behind the IPv6-only access network won't be able to detect the presence of the NAT64 function or learn the IPv6 prefix to use for it, unless it's configured by other means.
The prefix discovery could be solved, as described in [RFC7050], by adding the relevant AAAA records to the ipv4only.arpa. zone of the service-provider recursive servers. For example, if using the WKP (64:ff9b::/96):
ipv4only.arpa. SOA . . 0 0 0 0 0
ipv4only.arpa. NS .
ipv4only.arpa. AAAA 64:ff9b::192.0.0.170
ipv4only.arpa. AAAA 64:ff9b::192.0.0.171
ipv4only.arpa. A 192.0.0.170
ipv4only.arpa. A 192.0.0.171Another option is DNS RPZ [DNS-RPZ] or equivalent functionality. Just note that this may impact DNSSEC if the zone is signed ⚠️
Another alternative, which only works in environments that support the Port Control Protocol (PCP) (for both the hosts or CEs and for the service-provider network), is to follow "Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)" [RFC7225] 💜
Other alternatives may be available in the future. All of them are covered in depth in [RFC7051]. However, because deployment has evolved, many considerations from that document have changed. New options are being documented, such as using Router Advertising [PREF64] or DHCPv6 options [DHCPv6-OPTIONS] 🌈
Supporting several of the possible approaches at once is convenient, and it ensures that clients with different ways of configuring the NAT64 prefix can still get it. This is also handy even when DNS64 is in use.
Also of special relevance to this section is [IPV4ONLY-ARPA] 🎀
4.1.2. DNSSEC Validator Aware of DNS64
In general, by default, DNS servers with the DNS64 function won't synthesize AAAA responses if the DO flag was set in the query 🧠
In this case, since only an A record is available, if a CLAT function is present, the CLAT will keep that traffic flow end to end as IPv4, just like with literal IPv4 addresses, so DNSSEC isn't broken.
This won't work without a CLAT function, though, because the hosts won't be able to use IPv4. That's the situation for all the scenarios without 464XLAT 😭
4.1.3. Stub Validator
If the DO flag is set, the client device does DNSSEC validation, and the Checking Disabled (CD) flag is set for a query, the DNS64 recursive server won't synthesize AAAA responses. In this case, the client can do the DNSSEC validation with the A record and then synthesize the AAAA responses [RFC6052]. For this to work, the client must have learned the NAT64 prefix beforehand using any of the available methods (see [RFC7050], [RFC7225], [PREF64], and [DHCPv6-OPTIONS]). This lets the client device skip the DNS64 function and still use NAT64, even with DNSSEC 🫶
If the end host is IPv4 only, this won't work without a CLAT function (which is the case for all scenarios without 464XLAT).
Instead of a CLAT, some devices or Operating Systems may implement an equivalent function using Bump-in-the-Host [RFC6535] as part of Happy Eyeballs v2 (see Section 7.1 of [RFC8305]). In this case, the considerations in the paragraphs above also apply 🍓
4.1.4. CLAT with DNS Proxy and Validator
Okay so if a CE has CLAT support and a DNS proxy (see Section 6.4 of [RFC6877]) 💅, the CE can act as a stub validator on behalf of the client devices. Then, using the same approach from Section 4.1.3, the DNS proxy basically "lies" to the client devices 🙈. Most of the time nobody notices, unless the clients do validation themselves. Again, this lets the client devices skip the DNS64 function but still use NAT64 with DNSSEC ✨.
Once more, this won't work without a CLAT function (which is the case for all scenarios without 464XLAT) 😭.
4.1.5. ACL of Clients
For dual-stack clients, AAAA queries usually win over A queries 🫶. If DNS64 is enabled for those clients, they'll never get A records, even for IPv4-only servers 💀.
So if there are IPv4-only servers sitting in the path before the NAT64 function, the clients won't be able to reach them. If DNSSEC is being used for all those flows, you can leave specific addresses or prefixes out of the DNS64 synthesis with Access Control Lists (ACLs) 🔥.
Once more, this won't work without a CLAT function (which is the case for all scenarios without 464XLAT) 😭.
4.1.6. Mapping Out IPv4 Addresses
If there are well-known specific IPv4 addresses or prefixes using DNSSEC, they can be mapped out of the DNS64 synthesis 🦋.
Even if it's not related to DNSSEC, this "mapping-out" feature is super common for making sure that addresses [RFC1918] (for example, the ones used by LAN servers) don't get synthesized into AAAA 🌸.
Once more, this won't work without a CLAT function (which is the case for all scenarios without 464XLAT) 😭.
4.2. DNS64 and Reverse Mapping
When a client device using DNS64 tries to reverse-map a synthesized IPv6 address, the name server responds with a CNAME record. That CNAME points the domain name used for the reverse lookup (the one under ip6.arpa) to the domain name for the embedded IPv4 address (under in-addr.arpa) 🧚.
This is the expected behavior, so no issues need to be considered for DNS reverse mapping ✨.
4.3. Using 464XLAT with/without DNS64
Here's the situation: the client device is IPv6 only (either because its stack or app is IPv6 only, or because it's connected via an IPv6-only LAN), and the remote server is IPv4 only (either because its stack is IPv4 only, or because it's on an IPv4-only LAN). In that case, only NAT64 combined with DNS64 can get the two talking 🌈. Because DNS64 is required here, DNSSEC validation is only possible if the recursive name server is validating the negative response from the authoritative name server, and the client isn't doing validation.
Note that at this stage of the transition, it's not expected that applications, devices, or Operating Systems are IPv6 only. It won't be a sensible move for a developer to head in that direction, unless it's crystal clear that the deployment scenario fully supports it 🙈.
On the other hand, an end user or enterprise network may decide to run IPv6 only in the LANs. If there's any chance applications could be IPv6 only, the Operating System may be responsible for either doing a local address synthesis or setting up some kind of on-demand VPN (IPv4-in-IPv6), which the network needs to support 👑. This may get really common in enterprise networks, where "Unique IPv6 Prefix per Host" [RFC8273] is supported 💜.
However, when the client device is dual stack and/or connected in a dual-stack LAN with a CLAT function (or has a built-in CLAT function), DNS64 is an option 🎀.
- With DNS64: If DNS64 is used, most of the IPv4 traffic (except if using literal IPv4 addresses or non-IPv6-compliant APIs) won't use the CLAT and will take the IPv6 path instead, so only one translation gets done at the NAT64. This may break DNSSEC, unless the measures described in the previous sections are taken.
- Without DNS64: If DNS64 is not used, all the IPv4 traffic will make use of the CLAT, so two translations are required (NAT46 at the CLAT and NAT64 at the PLAT). That adds some overhead in terms of the extra NAT46 translation. However, this avoids the AAAA synthesis, and so it will never break DNSSEC 🍓.
Note that the extra translation, when DNS64 is not used, takes place at the CLAT, which means no extra overhead for the operator 💖. However, it adds potential extra delays to establish connections. It has no perceptible impact for a CE in a broadband network, but it may have some impact on a battery-powered device 🔋. The cost for a battery-powered device is possibly comparable to the cost when the device is doing a local address synthesis (see Section 7.1 of [RFC8305]).
4.4. Foreign DNS
Clients, devices, or applications in a service-provider network may use DNS servers from other networks 🌍. This may happen if individual applications use their own DNS server, the Operating System itself, or even the CE, or some combination of the above.
Those "foreign" DNS servers may not support DNS64. As a result, the scenarios that require a DNS64 may not work. However, if a CLAT function is available, the considerations in Section 4.3 will apply.
If the foreign DNS supports the DNS64 function, incorrect configuration parameters may be provided that, for example, cause WKP or NSP to become unmatched, or result in a case such as the one described in Section 3.2.3 ⚠️.
Having a CLAT function, even when using foreign DNS without a DNS64 function, ensures that everything will work. So the CLAT must be considered to be an advantage despite user configuration errors 👑. As a result, all the traffic will use a double translation (NAT46 at the CLAT and NAT64 at the operator network), unless there is support for EAM (Section 4.9) ✨.
An exception is the case where there is a CLAT function at the CE that is not able to obtain the correct configuration parameters (again, causing WKP or NSP to become unmatched) 🙃.
However, it needs to be emphasized that if there is no CLAT function (which is the case for all scenarios without 464XLAT), an external DNS without DNS64 support will disallow any access to IPv4-only destination networks and will not guarantee correct DNSSEC validation. So it will behave as in Section 3.2.1 💀.
In summary, the consequences of using foreign DNS depend on each specific case. In general, though, if a CLAT function is present, most of the time there won't be any issues 🌈. In the other cases, access to IPv6-enabled services is still guaranteed for IPv6-enabled hosts, but it is not guaranteed for IPv4-only hosts, nor is access to IPv4-only services guaranteed for any hosts in the network.
The causes of "foreign DNS" could be classified in three main categories, as depicted in the following subsections 🧩.
4.4.1. Manual Configuration of DNS
It's becoming increasingly common for end users, or even devices or applications, to configure alternative DNS in their Operating Systems, and sometimes in CEs 🛠️.
4.4.2. DNS Privacy/Encryption Mechanisms
Clients or applications may use mechanisms for DNS privacy/encryption, such as DNS over TLS (DoT) [RFC7858], DNS over DTLS [RFC8094], DNS queries over HTTPS (DoH) [RFC8484], or DNS over QUIC (DoQ) [QUIC-CONNECTIONS] 🔐.
Right now, those DNS privacy/encryption options are typically provided by the applications, not the Operating System vendors. At the time this document was written, the DoT and DoH standards had declared DNS64 (and consequently NAT64) out of their scope. So an application using them may break NAT64, unless a correctly configured CLAT function is used 😬.
4.4.3. Split DNS and VPNs
When networks or hosts use "split-DNS" (also called Split Horizon, DNS views, or private DNS), the successful use of DNS64 isn't guaranteed 🙈. This case is analyzed in Section 4 of [RFC6950].
A similar situation may happen with VPNs that force all the DNS queries through the VPN and ignore the operator's DNS64 function 🔒.
4.5. Well-Known Prefix (WKP) vs. Network-Specific Prefix (NSP)
Section 3 of "IPv6 Addressing of IPv4/IPv6 Translator" [RFC6052] covers some considerations that are useful to an operator when deciding whether a WKP or an NSP should be used 📚.
Taking that discussion and other issues into account, we can summarize the possible decision points as follows 📝:
a. The WKP MUST NOT be used to represent non-global IPv4 addresses. If this is required because the network to be translated uses non-global addresses, then an NSP is required 🚫.
b. The WKP MAY appear in interdomain routing tables, if the operator provides a NAT64 function to peers. However, in this case, special considerations related to BGP filtering are required, and IPv4-embedded IPv6 prefixes longer than the WKP MUST NOT be advertised (or accepted) in BGP. An NSP may be a more appropriate option in those cases 🌐.
c. If several NAT64s use the same prefix, packets from the same flow may be routed to a different NAT64 in case of routing changes. This can be avoided by either using different prefixes for each NAT64 function or ensuring that all the NAT64s coordinate their state. Using an NSP could simplify that 🦋.
d. If DNS64 is required, and users, devices, Operating Systems, or applications may change their DNS configuration and deliberately choose an alternative DNS64 function, the alternative DNS64 will most likely use the WKP by default. In that case, if an NSP is used by the NAT64 function, clients will not be able to use the operator's NAT64 function, which will break connectivity to IPv4-only destinations 💔.
4.6. IPv4 Literals and Non-IPv6-Compliant APIs
A host or application using literal IPv4 addresses or older APIs (which aren't IPv6 compliant) behind a network with IPv6-only access won't work unless one of the following alternatives is provided 🧸:
- CLAT (or an equivalent function).
- Happy Eyeballs v2 (Section 7.1 of [RFC8305]).
- Bump-in-the-Host [RFC6535] with a DNS64 function.
Those alternatives will solve the problem for an end host. However, if the end host is providing "tethering" or an equivalent service to other hosts, that needs to be considered as well 📱. In other words, in a cellular network, these alternatives resolve the issue for the UE itself, but this may not be the case for hosts connected via the tethering.
Otherwise, the support of 464XLAT is the only valid and complete approach to resolve this issue 👑.
4.7. IPv4-Only Hosts or Applications
IPv4-only hosts, or an application behind a network with IPv6-only access, won't work unless a CLAT function is present 🥺.
464XLAT is the only valid approach to resolve this issue 💅✨.
4.8. CLAT Translation Considerations
okay so bestie 💅 "IPv6 Prefix Handling" (see Section 6.3 of [RFC6877]) says that if the CLAT function can be set up with a dedicated /64 prefix for the NAT46 translation, then a more efficient stateless translation is possible ✨
If that dedicated prefix isn't available, the CLAT function will need to do a stateful translation instead 🎀. For example, it can run stateful NAT44 on all the IPv4 LAN packets so they all look like they come from one single IPv4 address. Then the CLAT function does a stateless translation to a single IPv6 address 🦋.
Now, the way to max out CLAT performance is to configure a dedicated translation prefix 🔥. This is super easy to do automatically if the broadband CE or end-user device can get a shorter prefix through DHCPv6-PD [RFC8415] or other alternatives 💖. The CE can then use a specific /64 for the translation. This also works when broadband is provided over cellular access 🌈.
The above recommendation is often not possible for cellular networks when you're connecting smartphones (as UEs), because they generally don't use DHCPv6-PD [RFC8415] 😭. Instead, a single /64 is provided for each Packet Data Protocol (PDP) context, and prefix sharing [RFC6877] is used. In this case, UEs typically have a built-in CLAT function that performs a stateful NAT44 translation before the stateless NAT46 💅.
4.9. EAM Considerations
okay this one is giving optimization 🧚. "Explicit Address Mappings for Stateless IP/ICMP Translation" [RFC7757] lets you configure explicit mappings between IPv4 and IPv6 prefixes of any length ✨. When it's used, for example, in a CLAT function, it can be a simple way to stop traffic flows between IPv4-only nodes or applications and dual-stack destinations from getting translated twice (NAT46 and NAT64). You just create mapping entries using the Global Unicast Address (GUA) of the IPv6-reachable destination 💜. This NAT64 optimization is very useful in lots of scenarios, including Content Delivery Networks (CDNs) and caches, as described in [OPT-464XLAT] 🌸.
It can also give IPv4-only nodes or applications a way to communicate with IPv6-only destinations 🦋. Iconic.
4.10. Incoming Connections
ngl this is the part where people get stressed 😭 because NAT64 basically disallows incoming IPv4 connections, and IPv4-only peer-to-peer apps may still need them. Don't panic though, there are several ways to fix this 🫶:
- a. Session Traversal Utilities for NAT (STUN) [RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and Interactive Connectivity Establishment (ICE) [RFC8445] are commonly used by peer-to-peer applications to allow incoming connections with IPv4 NAT. They work with NAT64 too, so it's giving teamwork 👑.
- b. The Port Control Protocol (PCP) [RFC6887] lets a host control how incoming IPv4 and IPv6 packets are translated and forwarded 🎀. A NAT64 may implement PCP to offer this service.
- c. EAM [RFC7757] can also be used to configure explicit mappings for customers who need them 💖. For example, this is used by Stateless IP/ICMP Translation for IPv6 Data Center Environments (SIIT-DC) [RFC7755] and SIIT-DC Dual Translation Mode (SIIT-DC-DTM) [RFC7756] 🌈.
5. Summary of Deployment Recommendations for NAT64/464XLAT 👑
okay bestie, the big-picture recap time 🧚. It's been shown that NAT64/464XLAT is a valid choice in several scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4). It's the predominant mechanism in most cellular networks, which account for hundreds of millions of users [ISOC] 🔥. NAT64/464XLAT offers different deployment choices depending on each network's case, needs, and requirements ✨. That said, this document is NOT an explicit recommendation to pick this over other IPv4aaS transition mechanisms 🙈. Instead, it's a guide that helps you evaluate a possible NAT64/464XLAT implementation and the key decision points for its deployment 💅.
Depending on each deployment's requirements, DNS64 may be a required function. In other cases, its adverse effects may be counterproductive 😭. Similarly, in some cases a NAT64 function together with a DNS64 function may be a valid solution, but only when you're certain IPv4-only hosts or applications don't need to be supported (see Sections 4.6 and 4.7). Otherwise (i.e., IPv4-only devices or applications that do need support), the limitations of NAT64/DNS64 may mean the operator needs to look into 464XLAT as a more complete solution 🦋.
For broadband-managed networks (where the CE is provided or suggested/supported by the operator), 464XLAT should be considered so the actual user's needs are fully supported 🎀. That covers IPv4-only devices and applications, plus IPv4 literals and non-IPv6-compliant APIs. In that case, it must support a CLAT function 💖.
If the operator provides DNS services, they may support a DNS64 function to avoid breaking DNSSEC as much as possible 🔥. This also boosts performance by reducing the double translation for all the IPv4 traffic. In this case, if the DNS service offers DNSSEC validation, it must be aware of the DNS64. This is considered the simpler and safer approach, and it may be combined with other recommendations in this document:
- DNS infrastructure MUST be aware of DNS64 (Section 4.1.2).
- Devices running CLAT SHOULD follow the indications in "Stub Validator" (see Section 4.1.3). However, this may be out of the operator's control 🙈.
- CEs SHOULD include a DNS proxy and validator (Section 4.1.4) 🌸.
- "ACL of Clients" (see Section 4.1.5) and "Mapping Out IPv4 Addresses" (see Section 4.1.6) MAY be considered by operators, depending on their own infrastructure 🧚.
This "increased performance" approach has the downside of potentially breaking DNSSEC for a small percentage of validating end hosts, versus the small impact of a double translation happening in the CE 😭. If CE performance isn't an issue (which is the most frequent case), then a much safer approach is to skip DNS64 entirely. That way, all the IPv4 traffic gets translated at the CLAT (Section 4.3) 💅.
If DNS64 isn't used, at least one of the alternatives described in Section 4.1.1 must be followed to learn the NAT64 prefix 🌈.
Operators need to keep in mind that if the DNS configuration is modified (see Sections 4.4, 4.4.2, and 4.4.3), which most likely can't be avoided, a foreign non-DNS64 could be used instead of configuring a DNS64 👀. In a NAT64-only scenario, an IPv4-only remote host will no longer be accessible. With 464XLAT, though, it will keep working ✨.
Similar considerations apply to the usage of a NAT64 WKP vs. NSP (Section 4.5), since they must match the DNS64 configuration. When foreign DNS is used, they may not match. If there's a CLAT and the configured foreign DNS isn't a DNS64, the network will keep working only if other ways of learning the NAT64 prefix are available 🦋.
For broadband networks, as described in Section 4.8, CEs that support a CLAT function SHOULD support DHCPv6-PD [RFC8415] or alternative means of configuring a shorter prefix 💖. The CE SHOULD internally reserve one /64 for the stateless NAT46 translation 🎀. The operator must make sure customers are allocated prefixes shorter than /64 to support this optimization. One way or another, this doesn't hurt the performance of the operator network 🔥.
Operators may follow "Deployment Considerations" (Section 7 of [RFC6877]) for suggestions on how to take advantage of traffic-engineering requirements 🧚.
For cellular networks, DNSSEC considerations may seem out of scope, because UE Operating Systems commonly don't support DNSSEC 🙈. However, applications running on them may, or Operating Systems may get "built-in" support in the future. Also, if those devices offer tethering, other client devices behind the UE may be doing the validation, so proper DNSSEC support by the operator network is relevant 💅.
Furthermore, cellular networks supporting 464XLAT [RFC6877] and "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" [RFC7050] allow a progressive IPv6 deployment, with a single Access Point Name (APN) supporting all types of PDP context (IPv4, IPv6, and IPv4v6) 🌈. This lets the network automatically serve every possible combination of UEs 👑.
If the operator chooses to validate the DNS64 prefix discovery, it must follow the advice in "Validation of Discovered Pref64::/n" (see Section 3.1 of [RFC7050]) ✨.
One last thing: many networks may have a mix of complex scenarios at the same time, like customers who require 464XLAT and those who don't, or customers who require DNS64 and those who don't 🌸. In general, the different issues and approaches described in this document can be implemented at the same time for different customers or parts of the network. That mix doesn't cause any problems or incompatibilities. They work well together as long as provisioning is appropriate and differentiated 💜. In fact, NAT64/464XLAT lets an operator offering both cellular and broadband services use a single IPv4aaS for both networks, while still tailoring the key deployment decisions for each case 🧚. It's even possible to use hybrid CEs that have a main broadband access link and a backup via the cellular network 🦋.
In an ideal world, we could safely use DNS64 if the approach proposed in [DNS-DNSSEC] were followed, which avoids the cases where DNSSEC may break. However, that won't solve the issues related to DNS privacy and split DNS 😭.
The only 100% safe solution that resolves all the issues is, in addition to having a CLAT function, not using a DNS64 and instead making sure the hosts have a built-in address synthesis feature 🔥. Operators could manage to provide CEs with the CLAT function, but the built-in address synthesis feature is out of their control. If the synthesis is provided by either the Operating System (via its DNS resolver API) or the application (via its own DNS resolver) in such a way that the prefix used for the NAT64 function is reachable for the host, the problem goes away 🎀.
Whenever it's feasible, using EAM [RFC7757] as indicated in Section 4.9 is a very relevant optimization because it avoids double translations 💅.
Applications that require incoming connections typically already provide a means for that. However, PCP and EAM, as indicated in Section 4.10, are valid alternatives, even for creating explicit mappings for customers who need them 🫶.
6. Deployment of 464XLAT/NAT64 in Enterprise Networks ✨
okay so the recs in this doc totally work for enterprise networks, campuses, and similar places (including managed end-user networks) 🏢💅
This covers setups where that network controls the NAT64 function (and the DNS64 function too, if there is one), or can configure them by hand to match its own needs. It also covers when the network needs to give IPv6-only access to any part of itself, or when it's IPv6-only and connected to third-party networks 🌐
The IETF meeting network is a great example 🫶 It has both NAT64 and DNS64, so it runs into the same issues as Section 3.1.1. If there's a CLAT function in the IETF network, then there's no need for DNS64, and it falls under the considerations of Section 3.1.3. Both setups were already tested and verified on the IETF network, so we know they work 🔥
Here are a few of the possible scenarios 🦋
Figure 13 shows an IPv6-only enterprise network that connects to the Internet as dual stack, using local NAT64 and DNS64 functions 💜
+----------------------------------+
| Enterprise Network |
| +----------+ +----------+ | +----------+
| | IPv6- | | NAT64 | | | IPv4 |
| | only +--------+ + | +-------+ + |
| | LANs | | DNS64 | | | IPv6 |
| +----------+ +----------+ | +----------+
+----------------------------------+
Figure 13: IPv6-Only Enterprise with NAT64 and DNS64Figure 14 shows a DS enterprise network that connects to a DS Internet using a CLAT function, with no DNS64 function 🌸
+----------------------------------+
| Enterprise Network |
| +----------+ +----------+ | +----------+
| | IPv6 | | | | | IPv4 |
| | + +--------+ NAT64 | +-------+ + |
| | CLAT | | | | | IPv6 |
| +----------+ +----------+ | +----------+
+----------------------------------+
Figure 14: DS Enterprise with CLAT, DS Internet, without DNS64And last but not least, Figure 15 shows an IPv6-only provider with a NAT64 function, plus a DS enterprise network that uses its own CLAT function, with no DNS64 function 🧚
+----------------------------------+
| Enterprise Network |
| +----------+ +----------+ | +----------+
| | IPv6 | | | | IPv6 | |
| | + +--------+ CLAT | +--------+ NAT64 |
| | IPv4 | | | | only | |
| +----------+ +----------+ | +----------+
+----------------------------------+
Figure 15: DS Enterprise with CLAT and IPv6-Only Access, without
DNS647. Security Considerations 🔒
Okay, this doc doesn't add any brand-new security considerations 🙈 It just leans on the ones already reported by each of the docs it cites. For example, DNS64 [RFC6147] already covers the DNSSEC issues, so go check that one out too.
As we already went over in Section 4.4, there may be some undesirable interactions 😭 These are especially likely if you're using VPNs or DNS privacy, and they could mess with how DNS64/NAT64 performs correctly. This one is serious, bestie, so don't skip it 💀
Also, using a DNS64 function has privacy considerations that are the same as regular DNS 👀 Those considerations live either in the service provider or in an external service provider, so keep track of who's holding your queries.
8. IANA Considerations 🎀
This document has no IANA actions, so there's nothing to register or update here ✨
9. References 📚
9.1. Normative References
- [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
https://www.rfc-editor.org/info/rfc1918. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
https://www.rfc-editor.org/info/rfc2119. - [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008,
https://www.rfc-editor.org/info/rfc5389. - [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
https://www.rfc-editor.org/info/rfc5625. - [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010,
https://www.rfc-editor.org/info/rfc5766. - [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010,
https://www.rfc-editor.org/info/rfc6052. - [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, April 2011,
https://www.rfc-editor.org/info/rfc6144. - [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011,
https://www.rfc-editor.org/info/rfc6146. - [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, April 2011,
https://www.rfc-editor.org/info/rfc6147. - [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)", RFC 6535, DOI 10.17487/RFC6535, February 2012,
https://www.rfc-editor.org/info/rfc6535. - [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013,
https://www.rfc-editor.org/info/rfc6877. - [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013,
https://www.rfc-editor.org/info/rfc6887. - [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, DOI 10.17487/RFC7050, November 2013,
https://www.rfc-editor.org/info/rfc7050. - [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)", RFC 7225, DOI 10.17487/RFC7225, May 2014,
https://www.rfc-editor.org/info/rfc7225. - [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address Mappings for Stateless IP/ICMP Translation", RFC 7757, DOI 10.17487/RFC7757, February 2016,
https://www.rfc-editor.org/info/rfc7757. - [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP Translation Algorithm", RFC 7915, DOI 10.17487/RFC7915, June 2016,
https://www.rfc-editor.org/info/rfc7915. - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
https://www.rfc-editor.org/info/rfc8174. - [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
https://www.rfc-editor.org/info/rfc8273. - [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017,
https://www.rfc-editor.org/info/rfc8305. - [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018,
https://www.rfc-editor.org/info/rfc8375. - [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018,
https://www.rfc-editor.org/info/rfc8415. - [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018,
https://www.rfc-editor.org/info/rfc8445. - [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
https://www.rfc-editor.org/info/rfc8484.
9.2. Informative References ✨
okay bestie, this is the extra reading list 📚 these are the sources that give the background and context, not the rules you have to follow 💅 here they are, exactly as written 🦋
[About-DNS64]
Linkova, J., "Let's talk about IPv6 DNS64 & DNSSEC", June
2016, <https://blog.apnic.net/2016/06/09/lets-talk-
ipv6-dns64-dnssec/>.
[ARCEP] ARCEP, "Service client des operateurs : les mesures de
qualite de service", April 2018, <https://www.arcep.fr/
cartes-et-donnees/nos-publications-chiffrees/service-
client-des-operateurs-mesures-de-la-qualite-de-service/
service-client-des-operateurs-les-mesures-de-qualite-de-
service.html>.
[DHCPv6-OPTIONS]
Li, L., Cui, Y., Liu, C., Wu, J., Baker, F., and J. Palet,
"DHCPv6 Options for Discovery NAT64 Prefixes", Work in
Progress, Internet-Draft, draft-li-intarea-nat64-prefix-
dhcp-option-02, 20 April 2019,
<https://tools.ietf.org/html/draft-li-intarea-nat64-
prefix-dhcp-option-02>.
[DNS-DNSSEC]
Byrne, C. and J. Palet, "IPv6-Ready DNS/DNSSSEC
Infrastructure", Work in Progress, Internet-Draft, draft-
bp-v6ops-ipv6-ready-dns-dnssec-00, 10 October 2018,
<https://tools.ietf.org/html/draft-bp-v6ops-ipv6-ready-
dns-dnssec-00>.
[DNS-RPZ] Vixie, P. and V. Schryver, "DNS Response Policy Zones
(RPZ)", Work in Progress, Internet-Draft, draft-vixie-
dnsop-dns-rpz-00, 23 June 2018,
<https://tools.ietf.org/html/draft-vixie-dnsop-dns-rpz-
00>.
[DNS64-Benchm]
Lencse, G. and Y. Kadobayashi, "Benchmarking DNS64
Implementations: Theory and Practice", pp. 61-74, no. 1,
vol. 127, Computer Communications,
DOI 10.1016/j.comcom.2018.05.005, September 2018,
<https://www.sciencedirect.com/science/article/pii/
S0140366418302184?via%3Dihub>.
[DNS64-BM-Meth]
Lencse, G., Georgescu, M., and Y. Kadobayashi,
"Benchmarking Methodology for DNS64 Servers", pp. 162-175,
no. 1, vol. 109, Computer Communications,
DOI 10.1016/j.comcom.2017.06.004, September 2017,
<https://www.sciencedirect.com/science/article/pii/
S0140366416305904?via%3Dihub>.
[FCC] FCC, "Measuring Broadband America Mobile 2013-2018
Coarsened Data", December 2018, <https://www.fcc.gov/
reports-research/reports/measuring-broadband-america/
measuring-broadband-america-mobile-2013-2018>.
[IPV4ONLY-ARPA]
Cheshire, S. and D. Schinazi, "Special Use Domain Name
'ipv4only.arpa'", Work in Progress, Internet-Draft, draft-
cheshire-sudn-ipv4only-dot-arpa-14, 3 November 2018,
<https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-
dot-arpa-14>.
[IPv6-TRANSITION]
Lencse, G., Palet, J., Howard, L., Patterson, R., and I.
Farrer, "Pros and Cons of IPv6 Transition Technologies for
IPv4aaS", Work in Progress, Internet-Draft, draft-lmhp-
v6ops-transition-comparison-03, 6 July 2019,
<https://tools.ietf.org/html/draft-lmhp-v6ops-transition-
comparison-03>.
[ISOC] ISOC, "State of IPv6 Deployment 2018", June 2018,
<https://www.internetsociety.org/resources/2018/state-of-
ipv6-deployment-2018/>.
[OPT-464XLAT]
Palet, J. and A. D'Egidio, "464XLAT Optimization", Work in
Progress, Internet-Draft, draft-palet-v6ops-464xlat-opt-
cdn-caches-03, 8 July 2019, <https://tools.ietf.org/html/
draft-palet-v6ops-464xlat-opt-cdn-caches-03>.
[PREF64] Colitti, L. and J. Linkova, "Discovering PREF64 in Router
Advertisements", Work in Progress, Internet-Draft, draft-
ietf-6man-ra-pref64-06, 3 October 2019,
<https://tools.ietf.org/html/draft-ietf-6man-ra-
pref64-06>.
[QUIC-CONNECTIONS]
Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J.
Iyengar, "Specification of DNS over Dedicated QUIC
Connections", Work in Progress, Internet-Draft, draft-
huitema-quic-dnsoquic-07, 7 September 2019,
<https://tools.ietf.org/html/draft-huitema-quic-dnsoquic-
07>.
[RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar,
"Analysis of Stateful 64 Translation", RFC 6889,
DOI 10.17487/RFC6889, April 2013,
<https://www.rfc-editor.org/info/rfc6889>.
[RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba,
"Architectural Considerations on Application Features in
the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013,
<https://www.rfc-editor.org/info/rfc6950>.
[RFC7051] Korhonen, J., Ed. and T. Savolainen, Ed., "Analysis of
Solution Proposals for Hosts to Learn NAT64 Prefix",
RFC 7051, DOI 10.17487/RFC7051, November 2013,
<https://www.rfc-editor.org/info/rfc7051>.
[RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64
Deployment Options and Experience", RFC 7269,
DOI 10.17487/RFC7269, June 2014,
<https://www.rfc-editor.org/info/rfc7269>.
[RFC7755] Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for
IPv6 Data Center Environments", RFC 7755,
DOI 10.17487/RFC7755, February 2016,
<https://www.rfc-editor.org/info/rfc7755>.
[RFC7756] Anderson, T. and S. Steffann, "Stateless IP/ICMP
Translation for IPv6 Internet Data Center Environments
(SIIT-DC): Dual Translation Mode", RFC 7756,
DOI 10.17487/RFC7756, February 2016,
<https://www.rfc-editor.org/info/rfc7756>.
[RFC7849] Binet, D., Boucadair, M., Vizdal, A., Chen, G., Heatley,
N., Chandler, R., Michaud, D., Lopez, D., and W. Haeffner,
"An IPv6 Profile for 3GPP Mobile Devices", RFC 7849,
DOI 10.17487/RFC7849, May 2016,
<https://www.rfc-editor.org/info/rfc7849>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017,
<https://www.rfc-editor.org/info/rfc8094>.
[RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking
Methodology for IPv6 Transition Technologies", RFC 8219,
DOI 10.17487/RFC8219, August 2017,
<https://www.rfc-editor.org/info/rfc8219>.
[RFC8585] Palet Martinez, J., Liu, H. M.-H., and M. Kawashima,
"Requirements for IPv6 Customer Edge Routers to Support
IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May
2019, <https://www.rfc-editor.org/info/rfc8585>.
[RIPE-690] RIPE, "Best Current Operational Practice for Operators:
IPv6 prefix assignment for end-users - persistent vs non-
persistent, and what size to choose", October 2017,
<https://www.ripe.net/publications/docs/ripe-690>.
[Threat-DNS64]
Lencse, G. and Y. Kadobayashi, "Methodology for the
identification of potential security issues of different
IPv6 transition technologies: Threat analysis of DNS64 and
stateful NAT64", pp. 397-411, no. 1, vol. 77, Computers &
Security, DOI 10.1016/j.cose.2018.04.012, August 2018,
<https://www.sciencedirect.com/science/article/pii/
S0167404818303663?via%3Dihub>.Appendix A. Example of Broadband Deployment with 464XLAT ✨
okay bestie, this appendix is a full walkthrough of how an operator can roll out an IPv6-only network for residential and SOHO customers 🏠💖. It still supports IPv6 inbound connections, and it gives people IPv4-as-a-Service (IPv4aaS) through 464XLAT 🦋. literally so good.
Note that an equivalent setup could also be provided for enterprise customers 💼. If they need IPv4 inbound connections, several mechanisms can allow it depending on what they need. See [RFC7757] 🔥.
Conceptually, most of the operator network could be IPv6 only (the diagrams call this the "IPv6-only flow" 💜). Even if part of the network is actually dual stack, some customers (like residential ones) only get IPv6 access. This part of the network connects the IPv6-only subscribers, over IPv6-only access links, to IPv6 upstream providers and to the IPv4 Internet through NAT64 (that's PLAT in 464XLAT terms 🧚).
Traffic going from the CE to services on the IPv6 Internet (or to dual-stack remote services, when IPv6 is in use), and the traffic coming back, is purely native IPv6 🌸. So there's nothing special to think about there.
Now the DNS vibes 👀. Remote networks that are IPv4 only will typically have only IPv4 DNS (DNS/IPv4), or at least look like IPv4 DNS from the CE's perspective. On the operator side, the DNS as seen from the CE is IPv6 only (DNS/IPv6), and it also has a DNS64 function ✨.
On the customer LAN side there's really one network, which of course could be split into different segments. The most common setup is dual-stack segments, using global IPv6 addresses and [RFC1918] for IPv4, like in any regular residential / Small Office, Home Office (SOHO) IPv4 network 🎀. The figure below shows it as three segments, to prove that all three setups are valid: IPv6 only, IPv4 only, and dual stack 🌈.
.-----. +-------+ .-----. .-----.
/ IPv6- \ | | / \ / \
( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \
\ LANs / | SOHO +--( only )--( NAT64 )--( only )
`-----' | | \ flow / `-----' \ flow /
.-----. | IPv6 | \ / \ /
/ IPv4- \ | CE | `--+--' `--+--'
( only )--+ with | | |
\ LANs / | CLAT | +---+----+ +---+----+
`-----' | | |DNS/IPv6| |DNS/IPv4|
.-----. +---+---+ | with | +--------+
/ Dual- \ | | DNS64 |
( Stack )------| +--------+
\ LANs /
`-----'Figure 16: CE Setup with Built-In CLAT, with DNS64
In addition to the regular CE setup (which is usually access-technology dependent 📡), here's how the CLAT function gets configured:
- Discovery of the PLAT (NAT64) prefix: you can do this with [RFC7050], or with [RFC7225] in networks where PCP is supported 🔍. Other alternatives might show up in the future too, like Router Advertising [PREF64] or DHCPv6 options [DHCPv6-OPTIONS].
- If the CLAT function allows stateless NAT46 translation, a
/64from the pool typically given to the CE through DHCPv6-PD [RFC8415] needs to be set aside for that translation. Otherwise, the CLAT is forced to do an intermediate stateful NAT44 before the stateless NAT46, as described in Section 4.8 🙈.
A more detailed configuration approach is described in [RFC8585].
The operator network needs to make sure the right responses are provided for PLAT prefix discovery 📬. It is highly recommended that [RIPE-690] be followed, so that multiple /64s are available, including the one needed for the NAT46 stateless translation 💅.
The operator needs to understand the other issues covered throughout this document in order to make relevant decisions 🧠. For example, if several NAT64 functions are needed for scalability / high availability, an NSP should be considered (see Section 4.5).
More complex scenarios are possible 🌀. For example, a network might offer multiple NAT64 prefixes, destination-based NAT64 prefixes, etc.
If the operator decides not to provide a DNS64 function, this setup will be the same as the following figure. It will also be the setup seen from the CE's perspective if a foreign DNS is used and therefore isn't the operator-provided DNS64 function 🙃.
.-----. +-------+ .-----. .-----.
/ IPv6- \ | | / \ / \
( only )--+ Res./ | / IPv6- \ .-----. / IPv4- \
\ LANs / | SOHO +--( only )--( NAT64 )--( only )
`-----' | | \ flow / `-----' \ flow /
.-----. | IPv6 | \ / \ /
/ IPv4- \ | CE | `--+--' `--+--'
( only )--+ with | | |
\ LANs / | CLAT | +---+----+ +---+----+
`-----' | | |DNS/IPv6| |DNS/IPv4|
.-----. +---+---+ +--------+ +--------+
/ Dual- \ |
( Stack )------|
\ LANs /
`-----'Figure 17: CE Setup with Built-In CLAT, without DNS64
In this case, the discovery of the PLAT prefix needs to be arranged as indicated in Section 4.1.1.
Also, if the CE doesn't have a built-in CLAT function, the customer can set up the IPv6 operator-managed CE in bridge mode (and optionally use an external router) 🌉. Or, if there's an access technology that requires some kind of media converter (Optical Network Termination (ONT) for fiber to the home (FTTH), Cable Modem for Data-Over-Cable Service Interface Specification (DOCSIS), etc.), the complete setup will look like Figure 18. Obviously there will be some intermediate configuration steps for the bridge, depending on the specific access technology/protocols. Those steps should not change the steps already described for the CLAT function configuration.
+-------+ .-----. .-----.
| | / \ / \
| Res./ | / IPv6- \ .-----. / IPv4- \
| SOHO +--( only )--( NAT64 )--( only )
| | \ flow / `-----' \ flow /
| IPv6 | \ / \ /
| CE | `--+--' `--+--'
| Bridge| | |
| | +---+----+ +---+----+
| | |DNS/IPv6| |DNS/IPv4|
+---+---+ +--------+ +--------+
|
.-----. +---+---+
/ IPv6- \ | |
( only )--+ IPv6 |
\ LANs / | Router|
`-----' | |
.-----. | with |
/ IPv4- \ | CLAT |
( only )--+ |
\ LANs / | |
`-----' | |
.-----. +---+---+
/ Dual- \ |
( Stack )------|
\ LANs /
`-----'Figure 18: CE Setup with Bridged CLAT, without DNS64
🚫 Several routers (the operator-provided CE and the downstream user-provided router) that enable simultaneous routing and/or CLAT should be avoided. That keeps multiple NAT44 and NAT46 levels from stacking up, and keeps multiple IPv6 subnets working correctly. In those cases, using the Home Networking Control Protocol (HNCP) [RFC8375] is suggested.
Note that the CE setup procedure described here can be simplified if the CE follows [RFC8585] ✨.
Appendix B. CLAT Implementation
In addition to the regular set of CE features, a CLAT CE implementation requires support for:
- [RFC7915] for the NAT46 function.
- [RFC7050] for the PLAT prefix discovery.
- [RFC7225] for the PLAT prefix discovery if PCP is supported.
- [PREF64] for the PLAT prefix discovery by means of Router Advertising.
- [DHCPv6-OPTIONS] for the PLAT prefix discovery by means of DHCP.
- If stateless NAT46 is supported, a mechanism to ensure that multiple
/64are available, such as DHCPv6-PD [RFC8415], must be used.
There are several Open Source implementations of CLAT, such as:
- Android:
https://github.com/ddrown/android_external_android-clat - Jool:
https://www.jool.mx - Linux:
https://github.com/toreanderson/clatd - OpenWRT:
https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&a=search&h=refs%2Ftags%2Fv19.07.0-rc1&st=commit&s=464xlat - VPP:
https://git.fd.io/vpp/tree/src/plugins/nat
Appendix C. Benchmarking
A benchmarking methodology for IPv6 transition technologies has been defined in [RFC8219] 📊. NAT64 and 464XLAT are covered among the single- and double-translation technologies, respectively. DNS64 is covered in Section 9, and the methodology is elaborated in [DNS64-BM-Meth] of that document.
Several documents provide references to benchmarking results, for example, for DNS64 [DNS64-Benchm].
Acknowledgements 🫶
The author would like to acknowledge the inputs of Gabor Lencse, Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker, Mohamed Boucadair, Alejandro D'Egidio, Dan Wing, Mikael Abrahamsson, and Eric Vyncke. 💜
Conversations with Marcelo Bagnulo, one of the coauthors of NAT64 and DNS64, and email correspondence via the IETF mailing lists with Mark Andrews have been very useful for this work 🙌.
Work on this document was inspired by Christian Huitema, who suggested that DNS64 should never be used when deploying CLAT in the IETF network 💀.
Author's Address
Jordi Palet Martinez
The IPv6 Company
Molino de la Navata, 75
28420 La Navata - Galapagar Madrid
SpainEmail: jordi.palet@theipv6company.com URI: http://www.theipv6company.com/
📦 where this page comes from
- ietf: rfc8683 2019-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms