RFC 7050
Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis
RFC 7050: Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis ✨
okay bestie, let's get into it 🦋 this is RFC 7050, a Standards Track doc from November 2013 (ISSN 2070-1721). the authors are T. Savolainen (Nokia), J. Korhonen (Broadcom), and D. Wing (Cisco Systems). it's published as an IETF Request for Comments, and this header doesn't list any obsoletes or updates fields. the whole vibe is how a node can figure out which IPv6 prefix its network uses for translation, so it can do its own address synthesis 💅🌸
Abstract
okay so this doc describes a way for a node to detect that DNS64 is present and learn the IPv6 prefix the access network uses for protocol translation 🎀 the trick depends on a well-known IPv4-only fully qualified domain name, "ipv4only.arpa.". once a node knows this stuff, it can do local IPv6 address synthesis and maybe skip NAT64 on dual-stack and multi-interface setups ✨
Status of This Memo
this is an Internet Standards Track document 🔥
it's a product of the Internet Engineering Task Force (IETF). it represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more info on Internet Standards, check Section 2 of RFC 5741 🧚
info about the current status of this doc, any errata, and how to send feedback is at http://www.rfc-editor.org/info/rfc7050 💜
Copyright Notice
Copyright (c) 2013 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 (http://trustee.ietf.org/license-info) as in effect on the date of publication. please read these carefully, bestie, because they explain your rights and restrictions for this document 📜 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 without warranty, as described in the Simplified BSD License 💖
Table of Contents
1. Introduction ....................................................3
2. Requirements Notation and Terminology ...........................4
2.1. Requirements Notation ......................................4
2.2. Terminology ................................................4
3. Node Behavior ...................................................4
3.1. Validation of Discovered Pref64::/n ........................6
3.1.1. DNSSEC Requirements for the Network .................7
3.1.2. DNSSEC Requirements for the Node ....................7
3.2. Connectivity Check .........................................8
3.2.1. No Connectivity Checks against "ipv4only.arpa." .....9
3.3. Alternative Fully Qualified Domain Names ..................10
3.4. Message Flow Illustration .................................10
4. Operational Considerations for Hosting the IPv4-Only
Well-Known Name ................................................12
5. Operational Considerations for DNS64 Operator ..................12
5.1. Mapping of IPv4 Address Ranges to IPv6 Prefixes ...........13
6. Exit Strategy ..................................................14
7. Security Considerations ........................................14
8. IANA Considerations ............................................15
8.1. Domain Name Reservation Considerations ....................15
8.2. IPv4 Address Allocation Considerations ....................16
8.3. IAB Statement Regarding This .arpa Request ................17
9. Acknowledgements ...............................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................19
Appendix A. Example of DNS Record Configuration ..................20
Appendix B. About the IPv4 Address for the Well-Known Name .......211. Introduction 🦋
okay so, as part of the move to IPv6, some access networks are going to use NAT64 [RFC6146] and DNS64 [RFC6147] to give IPv4 connectivity to IPv6-only nodes [RFC6144] ✨ DNS64 uses IPv6 address synthesis to make local IPv6 addresses for peers that only have IPv4 addresses. that way, DNS-using IPv6-only nodes can talk to IPv4-only peers 💖
BUT, DNS64 can't help apps that don't use DNS, like apps that get IPv4 address literals as referrals 😭 those apps could still work through NAT64, as long as they can make locally valid IPv6 addresses that get translated to the peers' IPv4 addresses 🫶
also, DNS64 can't do IPv6 address synthesis for nodes running validating DNS resolvers that use DNS Security (DNSSEC). so the nodes have to do the synthesis themselves 💅 to pull that off, they need to learn the IPv6 prefix(es) the access network uses for protocol translation. a prefix can be a Network-Specific Prefix (NSP) or a Well-Known Prefix (WKP) [RFC6052], and this doc calls it Pref64::/n [RFC6146] 🌸
this doc describes a best-effort method so apps and nodes can learn what they need to do local IPv6 address synthesis 🎀 the synthesis procedure itself is out of scope here. an example is a browser that runs into IPv4 address literals on an IPv6-only access network. another example is a node running a validating, security-aware DNS resolver on an IPv6-only access network 🧚
knowing that IPv6 address synthesis is happening can also be useful if DNS64 and NAT64 are used on dual-stack access networks, or if a node is multi-interfaced [RFC6418] 💜 in those cases, nodes may choose to prefer IPv4 or another network interface so they can avoid going through protocol translators ✨
⚠️ heads up: this approach won't give you a system that's as robust, secure, and well-behaved as an all-IPv6 system. so it is highly recommended to upgrade nodes' destinations to IPv6, and only use the described method as a transition solution 🙈
2. Requirements Notation and Terminology 💅
2.1. Requirements Notation
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. these are the BCP 14 key words, so read them carefully 🔥
2.2. Terminology
here's the vocab you need, bestie 🍓
- NAT64 FQDN: a fully qualified domain name (FQDN) for a NAT64 protocol translator.
- Pref64::/n: an IPv6 prefix used for IPv6 address synthesis [RFC6146].
- Pref64::WKA: an IPv6 address made of Pref64::/n and WKA, placed at any of the locations allowed by RFC 6052 [RFC6052].
- Secure Channel: a communication channel a node has between itself and a DNS64 server, which protects DNS protocol-related messages from interception and tampering. it can be, for example, an IPsec-based virtual private network (VPN) tunnel or a link layer that uses data encryption technologies 🔐
- Well-Known IPv4-only Name (WKN): the fully qualified domain name "ipv4only.arpa.", which is well known to have only A record(s) 🌈
- Well-Known IPv4 Address (WKA): an IPv4 address that is well known and shows up in an A record for the well-known name. two well-known IPv4 addresses are defined for Pref64::/n discovery purposes:
192.0.0.170and192.0.0.171⭐
3. Node Behavior ✨
okay bestie, this is where the node actually does things 💅. Any node that needs to know whether there's a NAT64 on the network (and which Pref64::/n it's using for protocol translation) SHALL send a DNS query for the AAAA records of the Well-Known IPv4-only Name (WKN), which is ipv4only.arpa. 🎀. A node MAY do this query on both IPv6-only and dual-stack access networks, so it's not picky 🌸.
When the node sends that AAAA query for the WKN, it MUST set the "Checking Disabled (CD)" bit to zero [RFC4035]. Why? Because if the bit is set, the DNS64 server won't do IPv6 address synthesis (Section 3 of [RFC6147]), and then it would never reveal the Pref64::/n being used for translation. So no skipping that bit, periodt 🙅♀️.
A DNS reply with one or more AAAA records is basically the network going "yep, I'm doing IPv6 address synthesis" ✨. BUT (and this is a big but 😭) captive portals and NXDOMAIN or NODATA hijacking by the access network can make it look like there's a NAT64 when there isn't. One way to catch that is to query a fully qualified domain name that's known to be invalid (it normally gives back an empty or error response) and see whether you get a valid record anyway 🕵️♀️. Still, as long as the hijacked domain doesn't give AAAA answers containing a well-known IPv4 address in any location defined by [RFC6052], it won't mess up the Pref64::/n learning. Crisis averted 🦋.
A node MUST go through all the AAAA records it got back and collect one or more Pref64::/n 🔍. The list might include the Well-Known Prefix 64:ff9b::/96 [RFC6052], or one or more Network-Specific Prefixes. For NSPs, the node SHALL figure out the address format by searching the received IPv6 addresses for the WKN's well-known IPv4 addresses 🧩. It SHALL assume those IPv4 addresses might sit at the locations listed in [RFC6052], Section 2.2. The node MUST check on octet boundaries, so a 32-bit well-known IPv4 address value only shows up once in an IPv6 address. If the value shows up again inside the IPv6 address, the node SHALL repeat the search using the other well-known IPv4 address 🔁.
If only one Pref64::/n showed up in the DNS response, the node SHALL use that one for BOTH local synthesis AND for spotting synthesis the DNS64 server did on the network 💖.
If more than one Pref64::/n showed up, a node SHOULD use all of them when deciding whether other IPv6 addresses it received are synthetic 👀. The node MUST use all learned Pref64::/n when doing its own local IPv6 address synthesis, and it uses them in the order it received them from the DNS64 server. So when the node hands a list of locally synthesized IPv6 addresses up to the upper layers, those addresses MUST be synthesized using all the discovered Pref64::/n prefixes, in the received order 📋✨.
If the well-known IPv4 addresses aren't in the standard locations, then either the network isn't using a standard address format, or unexpected IPv4 addresses got used when the AAAA records were synthesized 😵. Either way, the Pref64::/n can't be determined and the heuristic procedure has failed 💀. Over time, developers might learn about IPv6-translated address formats that are extensions or alternatives to the standard ones. When that happens, developers MAY add extra steps to the discovery procedure. Those extra steps are outside the scope of this document 🌈.
If a node doesn't get a positive DNS reply to the AAAA query, the node MAY do a DNS A query for the well-known name 🔎. A positive reply to that A query tells you the recursive DNS server being used is NOT a DNS64 server 🙅.
For a negative response (NXDOMAIN, NODATA) or a DNS query timeout, one of these is going on: there's no DNS64 server on the access network, the access network filtered out the well-known query, or something just went wrong in DNS resolution 🤷♀️. Every unsuccessful case means the node can't do local IPv6 address synthesis, so it's a no-go for that part. For a timeout, the node SHOULD retransmit the DNS query like any other DNS query it makes [RFC1035] ⏰. For a negative response (NXDOMAIN, NODATA), the node MUST obey the Time to Live (TTL) [RFC1035] of that response before it resends the AAAA query. No spamming allowed 🙅♀️. The node MAY watch for DNS replies with IPv6 addresses built from the WKP, and if it sees any, the node SHOULD use the WKP as if it had been learned during the query for the well-known name 👑.
To save Internet resources where possible, a node should do Pref64::/n discovery only when it's actually needed (for example, when local synthesis is required, or when a new network interface connects to a new network, and so on) 🌍. The node SHALL cache the replies it gets during the Pref64::/n discovery procedure, and it SHOULD repeat the discovery process ten seconds before the TTL of the Well-Known Name's synthetic AAAA record expires ⏳🦋.
3.1. Validation of Discovered Pref64::/n
Okay, security time, and this part is SERIOUS 😭🚨. If a node is using an insecure channel between itself and a DNS64 server, or the DNS64 server is untrusted, then an attacker can mess with the node's Pref64::/n discovery. That can lead to denial-of-service, redirection, man-in-the-middle, or other attacks. Yikes 🙈.
To protect against these attacks, the node SHOULD talk to a trusted DNS64 server over a secure channel, or use DNSSEC 🔐. NAT64 operators SHOULD give the node facilities for validating Pref64::/n discovery over a secure channel and/or with DNSSEC protection 🛡️.
It's really important to understand that DNSSEC only validates that the discovered Pref64::/n is the one that belongs to a domain used by the NAT64 FQDN. DNSSEC does NOT tell you whether the node is actually on the network where that Pref64::/n is supposed to be used 🙅♀️. And DNSSEC validation can't be used at all in the case of a WKP ❌.
3.1.1. DNSSEC Requirements for the Network
If the operator has chosen to support nodes that validate discovered Pref64::/n with DNSSEC, then the operator of the NAT64 device MUST do the following configurations 📝.
- Have one or more fully qualified domain names for the NAT64 translator entities (later called NAT64 FQDN). If more than one
Pref64::/nis used in a network (e.g., for load-balancing), it's up to the network administrators to decide whether one NAT64's FQDN maps to more than onePref64::/n, or whether there's a dedicated NAT64 FQDN for eachPref64::/n🌸. - Each NAT64 FQDN MUST have one or more DNS AAAA records containing
Pref64::WKA(Pref64::/ncombined with WKA) 💜. - Each
Pref64::WKAMUST have a PTR record that points to the matching NAT64 FQDN 🧚. - Sign the NAT64 FQDNs' AAAA and A records with DNSSEC 🔏.
3.1.2. DNSSEC Requirements for the Node
A node SHOULD prefer a secure channel to talk to a DNS64 server whenever it's possible 🫶. On top of that, a node that has a DNSSEC validating resolver MAY use the following procedure to validate its Pref64::/n discovery 🧠✨.
- Find
Pref64::/ncandidates heuristically by making an AAAA query foripv4only.arpa.using the procedure in Section 3. This gives you IPv6 addresses made ofPref64::/ncombined with WKA, which isPref64::WKA. For eachPref64::/nthe node wants to validate, the node does the following steps 🔍. - Send a DNS PTR query for the IPv6 address of the translator (in the ".ip6.arpa." tree), using the
Pref64::WKAyou learned in step 1. CNAME and DNAME results should be followed according to the rules in RFC 1034 [RFC1034], RFC 1035 [RFC1035], and RFC 6672 [RFC6672]. The final response will include one or more NAT64 FQDNs 🦋. - The node SHOULD compare the domains of the learned NAT64 FQDNs with the node's list of trusted domains, and choose a NAT64 FQDN that matches 📚. How a node learns its trusted domains is implementation specific. If the node has no trust in the domain, then the discovery procedure is not secure, and the remaining steps below MUST NOT be performed 🚫.
- Send a DNS AAAA query for the NAT64 FQDN 📨.
- Check that the DNS AAAA response contains the
Pref64::WKAaddresses you received in step 1. The NAT64 FQDN might have multiple AAAA records, in which case the node MUST check whether any of the addresses match the ones it got in step 1. The node MUST ignore other responses and NOT use them for local IPv6 address synthesis 🙅♀️. - Do DNSSEC validation on the DNS AAAA response 🔐.
After the node has successfully done the above five steps, it can consider the Pref64::/n validated 🎉👑🌈.
3.2. Connectivity Check 🔌✨
Okay so once the node learns a Pref64::/n, it SHOULD run a connectivity check, bestie 💅. A Pref64::/n can be non-functional for a bunch of reasons: discovery didn't work the way it was supposed to, the IPv6 path to the NAT64 is down, the NAT64 itself is down, or the IPv4 path past the NAT64 is down. Not it 💀.
There are two main ways to figure out if a learned Pref64::/n is working. The first is a dedicated connectivity check. The second is to just try using the learned Pref64::/n. Each one has trade-offs, like extra network traffic or a delay the user might actually notice 🙈, so implementations should carefully weigh which approach fits their application and the network.
The node SHOULD use an implementation-specific connectivity check server and a protocol of the implementation's choice 🧚. If that's not possible, a node MAY do a PTR resource record query of the Pref64::WKA to get a NAT64 FQDN. Then the node does an A resource query of that NAT64 FQDN, which returns zero or more A resource records pointing to connectivity check servers run by the network operator. A negative response to the PTR or A resource query means there are no connectivity check servers available, so no hard feelings 🫶.
A network operator that provides NAT64 services for a mix of nodes, some with implementation-specific connectivity check servers and some without, SHOULD help those nodes out by mapping each NAT64 FQDN to one or more DNS A resource records with IPv4 address(es) pointing to connectivity check server(s) 🌸. The connectivity check approach based on Pref64::/n only works with NSPs, because you can't register A records for each different domain using a WKP. Also, the network operator MUST disable ICMPv6 rate limiting for connectivity check messages 🚫.
If multiple connectivity check servers are available, the node picks the first one, with implementation-specific servers getting the VIP treatment ⭐.
The connectivity check protocol used with implementation-specific connectivity check servers is implementation specific. Period 💅.
The connectivity check protocol used with the connectivity check servers pointed to by the NAT64 FQDN's A resource records is ICMPv6 [RFC4443]. The node doing a connectivity check against these servers SHALL send an ICMPv6 Echo Request to an IPv6 address synthesized by combining the discovered Pref64::/n with an IPv4 address of the server, as specified in [RFC6052] 🦋. This tests the IPv6 path to the NAT64, the NAT64's operation, and the IPv4 path all the way to the connectivity check server, which is so iconic to test all three at once 🔥. If there's no response to the ICMPv6 Echo Request, the node SHALL send another ICMPv6 Echo Request a second later. If there's still nothing, the node SHALL send a third ICMPv6 Echo Request two seconds after that. If an ICMPv6 Echo Response comes back, the node knows the IPv6 path to the connectivity check server is functioning normally ✨. If no response is received after three transmissions, and three seconds have passed since the last ICMPv6 Echo Request, the node learns this Pref64::/n might not be functioning. At that point the node MAY choose a different Pref64::/n (if one is available), MAY choose to alert the user, or MAY proceed anyway, assuming the failure is temporary or is caused by the connectivity check itself 🤷♀️. Honestly, ICMPv6 is unreliable by design, so failing to get ICMPv6 responses may not mean anything other than the network failing to carry ICMPv6 messages 😭.
If no separate connectivity check is performed before local IPv6 address synthesis, a node MAY monitor whether connection attempts made with locally synthesized IPv6 addresses succeed 👀. Based on those results, and on any ICMPv6 error messages received (such as Destination Unreachable messages), the node MAY stop performing local address synthesis and MAY restart the Pref64::/n discovery procedures 🔄.
3.2.1. No Connectivity Checks against "ipv4only.arpa." 🚫🌐
Clients MUST NOT send a connectivity check to an address returned by the ipv4only.arpa. query. By design, no server is supposed to run on the Internet at that address, so it's a no-go 🙅♀️. Similarly, network operators MUST NOT operate a server on that address. Here's the tea ☕: operators who skip running a connectivity check server would let that traffic leak toward the Internet, where it gets dropped, and the client ends up with a false negative. The NAT64 is working totally fine, but the check fails because nothing is listening at ipv4only.arpa. on the Internet and the NAT64 operator isn't running anything there either. Ugh, so unnecessary 😤. Instead, the connectivity check looks up and uses an additional DNS resource record. This makes sure packets don't leak out to the Internet for no reason and lowers the chance of a false negative 🫧.
3.3. Alternative Fully Qualified Domain Names 🎀
Some applications, operating systems, devices, or networks might find it useful to run their own DNS infrastructure to do something similar to ipv4only.arpa., but with a different resource record 💖. The main perk is making sure the DNS infrastructure stays available and that the DNS record itself is configured properly. For example, a company called Example might have their application query ipv4only.example.com. Apart from the different DNS resource record being queried, everything else is expected to work exactly like the steps described in this document 🧁.
3.4. Message Flow Illustration 🗺️
The figure below shows an example message flow for prefix discovery with Pref64::/n validation. It also shows the step where the procedure ends if no Pref64::/n validation is done 🌈.
In this example, the DNS64 server provides three Pref64::/n prefixes. The first Pref64::/n uses an NSP, which in this example is 2001:db8:42::/96. The second Pref64::/n also uses an NSP, which here is 2001:db8:43::/96. The third Pref64::/n uses the WKP. So when the Pref64::/n prefixes are combined with the WKA to form Pref64::WKA, the synthetic IPv6 addresses the DNS64 server returns are 2001:db8:42::192.0.0.170, 2001:db8:43::192.0.0.170, and 64:ff9b::192.0.0.170. The DNS64 server could also return synthetic addresses containing the IPv4 address 192.0.0.171 🍓.
The validation isn't done for the WKP, so check out Section 3.1 for the details 👑.
Node DNS64 server
| |
| "AAAA" query for "ipv4only.arpa." |
|----------------------------------------------->|"A" query for
| |"ipv4only.arpa."
| |--------------->
| |
| | "A" response:
| | "192.0.0.170"
| | "192.0.0.171"
| |<---------------
| +----------------------------+
| | "AAAA" synthesis using |
| | three Pref64::/n. |
| +----------------------------+
| "AAAA" response with: |
| "2001:db8:42::192.0.0.170" |
| "2001:db8:43::192.0.0.170" |
| "64:ff9b::192.0.0.170" |
|<-----------------------------------------------|
| |
+----------------------------------------------+ |
| If Pref64::/n validation is not performed, a | |
| node can fetch prefixes from AAAA responses | |
| at this point and skip the steps below. | |
+----------------------------------------------+ |
| |
| "PTR" query #1 for "2001:db8:42::192.0.0.170 |
|----------------------------------------------->|
| "PTR" query #2 for "2001:db8:43::192.0.0.170 |
|----------------------------------------------->|
| |
| "PTR" response #1 "nat64_1.example.com" |
|<-----------------------------------------------|
| "PTR" response #2 "nat64_2.example.com" |
|<-----------------------------------------------|
| |
+----------------------------------------------+ |
| Compare received domains to a trusted domain | |
| list and if matches are found, continue. | |
+----------------------------------------------+ |
| |
| "AAAA" query #1 for "nat64_1.example.com" |
|----------------------------------------------->|
| "AAAA" query #2 for "nat64_2.example.com" |
|----------------------------------------------->|
| |
| "AAAA" resp. #1 with "2001:db8:42::192.0.0.170 |
|<-----------------------------------------------|
| "AAAA" resp. #2 with "2001:db8:43::192.0.0.170 |
|<-----------------------------------------------|
| |
+----------------------------------------------+ |
| Validate AAAA responses and compare the IPv6 | |
| addresses to those previously learned. | |
+----------------------------------------------+ |
| |
+----------------------------------------------+ |
| Fetch the Pref64::/n from the validated | |
| responses and take into use. | |
+----------------------------------------------+ |
| |
Figure 1: Pref64::/n Discovery Procedure4. Operational Considerations for Hosting the IPv4-Only Well-Known Name 🏠✨
The authoritative name server for the well-known name SHALL have its DNS record TTL set to at least 60 minutes, so caching works better 🕰️💅. The exact TTL value will be determined and tuned based on operational experiences 📈.
The domain serving the well-known name MUST be signed with DNSSEC 🔐. See also Section 7 💜.
5. Operational Considerations for DNS64 Operator ✨
Okay so, if you run a DNS64 server, you're basically holding the steering wheel 🧚. A network operator of a DNS64 server can guide nodes that use heuristic discovery procedures, just by managing the responses the DNS64 server hands out 💅.
If the operator wants nodes to use multiple Pref64::/n prefixes, they need to configure DNS64 servers to reply with multiple synthetic AAAA records. As per Section 3, the nodes can then use them all 🎀.
There are no guarantees on which Pref64::/n prefix a node ends up using 🥺. If the operator wants nodes to use one specific Pref64::/n, or to switch the one they use over time (say, for load balancing), the only method that's guaranteed to work is making the DNS64 server return a single synthetic AAAA resource record. The TTL on that record should be set so the node repeats the Pref64::/n discovery when required 🔁.
Besides picking how many Pref64::/n prefixes to return and what TTL to use, DNS64 servers MUST NOT interfere with or perform other special procedures for the queries related to the well-known name. No meddling, bestie 🙅♀️.
5.1. Mapping of IPv4 Address Ranges to IPv6 Prefixes
Okay, the lore: [RFC6147] lets DNS64 implementations map specific IPv4 address ranges to separate Pref64::/n prefixes 🗺️. That's how special use IPv4 addresses [RFC6890] get handled. Here's an example setup where this might be used (it's giving data center vibes 🏢):
NAT64 "A" ----- IPv4-only servers in a data center
/
IPv6-only node---<
\
NAT64 "B" ----- IPv4 Internet
Figure 2: NAT64s with IPv4 Address RangesNAT64 "A" is used when accessing IPv4-only servers in the data center, and NAT64 "B" is used for Internet access 🌐.
The heuristic discovery method in this document doesn't support learning the rules a DNS64 server might use to map specific IPv4 address ranges to separate Pref64::/n prefixes 😭. So nodes will use the same discovered Pref64::/n to synthesize IPv6 addresses from any IPv4 address. That can cause issues for routing and connectivity establishment. The operator of the NAT64 and the DNS64 ought to take this into account when designing the network 🧠.
Network operators can help IPv6-only nodes by making sure they don't have to work with IPv4 address literals that use special mapping rules 🫶. The IPv4-only servers reached from special IPv4 address ranges ought to have signed AAAA records, which lets IPv6-only nodes skip local address synthesis entirely. If the IPv6-only nodes aren't using DNSSEC, then it's enough for the network's DNS64 server to return synthetic AAAA resource records pointing to IPv4-only servers. Avoiding local address synthesis for IPv4 addresses in special ranges is the best approach to help nodes ✨.
If IPv6-only nodes have no choice but to use IPv4 address literals from special IPv4 address ranges, and they'll do local synthesis with the discovered Pref64::/n, then the network ought to use routing to make sure packets reach the correct NAT64 🚦. For example, a router on the path from an IPv6-only host to the NAT64s can forward IPv6 packets to the correct NAT64, as shown in Figure 3. The routing could be based on the last 32 bits of the IPv6 address, but the network operator can also use some other IPv6 address format allowed by [RFC6052] if that makes routing setup simpler 🛠️. This setup needs extra logic on the NAT64 that provides connectivity to special IPv4 address ranges: it has to be able to translate packets it receives that use the Pref64::/n used with Internet connections.
NAT64 "A" ----- IPv4-only servers in a data center
/
IPv6-only host---router
\
NAT64 "B" ----- IPv4 Internet
Figure 3: NAT64s with Assisting Router6. Exit Strategy 👋
A day will come when this tool is no longer needed 🥹. A node SHOULD implement a configuration knob for disabling the Pref64::/n discovery feature, so it can be switched off when the time comes 🌅.
7. Security Considerations 🔒
Buckle up, this section is serious 💀. The security considerations follow closely those of [RFC6147]. The possible attacks are very similar in two cases: when an attacker controls a DNS64 server and returns tampered IPv6 addresses to a node, and when an attacker causes the node to use tampered Pref64::/n for local address synthesis. DNSSEC cannot be used to validate responses created by a DNS64 server the node has no trust relationship with. So this document doesn't change the big picture for untrusted network scenarios 😬.
If an attacker alters the Pref64::/n used by a DNS64 server or a node, the traffic the node generates will be delivered to an altered destination. That can lead to a denial-of-service (DoS) attack (if the resulting IPv6 addresses aren't assigned to any device), a flooding attack (if they're assigned to devices that don't want the traffic), or an eavesdropping attack (if the altered NSP is routed through the attacker) 🚨.
Even though a well-known name's DNS A resource record wouldn't necessarily need DNSSEC protection (both the name and the IPv4 addresses are well-known), DNSSEC protection is required for DNS AAAA resource record queries 🔐. Without DNSSEC, fake positive AAAA responses could cause hosts to wrongly detect a Pref64::/n, which would let an attacker inject a malicious Pref64::/n into hosts' synthesis procedures 👿. A signed "ipv4only.arpa." allows validating DNS64 servers (see Section 3, Case 5 of [RFC6147], for example) to detect malicious AAAA resource records. So the zone serving the well-known name has to be protected with DNSSEC 🛡️.
For Pref64::/n discovery validation, the access network SHOULD sign the NAT64 translator's fully qualified domain name 🖊️. A node SHOULD use the algorithm described in Section 3.1 to validate each discovered Pref64::/n ✅.
The procedure described in Section 3.1.2 requires a node using DNSSEC to validate Pref64::/n discovery to have a list of trusted domains 📜. If a matching domain isn't found at Step 3 in Section 3.1.2, an implementation might be tempted to ask the user to temporarily or permanently add a received domain as trusted. History has shown that average users can't properly handle such queries and tend to say yes without thinking, just to move forward quickly 🙈. So unless the DNSSEC-using implementation has a way to dynamically and reliably add trusted domains, it's better to fail the Pref64::/n discovery procedure ❌.
Lastly, the best mitigation against Pref64::/n discovery attacks is adding IPv6 support for nodes' destinations, which reduces the need to perform local IPv6 address synthesis 🏆.
8. IANA Considerations 📋
8.1. Domain Name Reservation Considerations
Per the procedures in [RFC3172] and [RFC6761], IANA has delegated a new second-level domain in the .ARPA zone for the well-known domain name "ipv4only.arpa.". The intention is that there won't be any further delegation of names below "ipv4only.arpa." 🙌. IANA handles the administrative and operational management of this zone. Here are the answers to the seven questions listed in [RFC6761] 💁♀️:
- Are human users expected to recognize these names as special and use them differently? In what way?
No, although this is a domain delegated under the .arpa infrastructural identifier top level domain 🤷♀️.
- Are writers of application software expected to make their software recognize these names as special and treat them differently? In what way?
Yes. Any application attempting to perform NAT64 discovery will query the name 🔍.
- Are writers of name resolution APIs and libraries expected to make their software recognize these names as special and treat them differently? If so, how?
Yes, to the extent the API or library is affected by NAT64 🧩.
- Are developers of caching domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?
No.
- Are developers of authoritative domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?
No.
- Does this reserved Special-Use Domain Name have any potential impact on DNS server operators? If they try to configure their authoritative DNS server as authoritative for this reserved name, will compliant name server software reject it as invalid? Do DNS server operators need to know about that and understand why? Even if the name server software doesn't prevent them from using this reserved name, are there other ways that it may not work as expected, of which the DNS server operator should be aware?
This name has effects for operators of NAT64/DNS64, but otherwise it's just another delegated .arpa domain 🧑💻.
- How should DNS Registries/Registrars treat requests to register this reserved domain name? Should such requests be denied? Should such requests be allowed, but only to a specially-designated entity?
The registry for .arpa is held at IANA, and only IANA needs to take action here 🏛️.
8.2. IPv4 Address Allocation Considerations
The well-known name needs to map to two different global IPv4 addresses, which have been allocated as described in [RFC6890]. Those addresses were taken from the IANA IPv4 Special Purpose Address Registry [RFC6890], and 192.0.0.170 and 192.0.0.171 have been assigned to this document with the parameters shown below 🎀:
+----------------------+-------------------------------+
| Attribute | Value |
+----------------------+-------------------------------+
| Address Block | 192.0.0.170/32 |
| | 192.0.0.171/32 |
| Name | NAT64/DNS64 Discovery |
| RFC | RFC 7050, Section 2.2 |
| Allocation Date | February 2013 |
| Termination Date | N/A |
| Source | False |
| Destination | False |
| Forwardable | False |
| Global | False |
| Reserved-by-protocol | True |
+----------------------+-------------------------------+
The Record for IPv4 Address Allocation for IPv4 Special Purpose
Address RegistryThe zone "ipv4only.arpa." is delegated from the ARPA zone to appropriate name servers chosen by IANA. An apex A RRSet has been inserted in the "ipv4only.arpa." zone like so 🌸:
IPV4ONLY.ARPA. IN A 192.0.0.170
IPV4ONLY.ARPA. IN A 192.0.0.1718.3. IAB Statement Regarding This .arpa Request 🏛️
okay so with this document getting published, the IAB gives the thumbs up to delegating "ipv4only" in the .arpa domain 💅. Under [RFC3172], the IAB asked IANA to delegate and provision "ipv4only.arpa." exactly as this specification writes it 🎀. BUT (and this is important bestie) the IAB does not take any architectural or technical position about this specification. so they're signing off on the name, not vouching for the design 🙈
9. Acknowledgements 🫶
the authors wanna thank Dmitry Anipko, Cameron Byrne, Aaron Yi Ding, Christian Huitema, Washam Fan, Peter Koch, Stephan Lagerholm, Zhenqiang Li, Simon Perreault, Marc Petit-Huguenin, Andrew Sullivan, and Dave Thaler for significant improvement ideas and comments 💖 these people made it so much better ✨
Jouni Korhonen would like to acknowledge his previous employer, Nokia Siemens Networks, where the majority of his work on this document was carried out 🧚
10. References 📚
10.1. Normative References
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
- [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
- [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
- [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
- [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
- [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, April 2011.
- [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, June 2012.
10.2. Informative References
- [RFC3172] Huston, G., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, September 2001.
- [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", RFC 5735, January 2010.
- [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
- [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, November 2011.
- [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, February 2013.
- [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, April 2013.
Appendix A. Example of DNS Record Configuration 🍓
okay this appendix is the fun part, the actual zone file vibes 🎀 the BIND-style examples show how a NAT64 operator could configure A and AAAA records.
the examples use Pref64::/n of 2001:db8::/96, both WKAs, and the example.com domain 🌸
the PTR record for reverse queries (Section 3.1.1, Bullet 3):
$ORIGIN A.A.0.0.0.0.0.C\
.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA.
@ IN SOA ns1.example.com. hostmaster.example.com. (
2003080800 12h 15m 3w 2h)
IN NS ns.example.com.
IN PTR nat64.example.com.
$ORIGIN B.A.0.0.0.0.0.C\
.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA.
@ IN SOA ns1.example.com. hostmaster.example.com. (
2003080800 12h 15m 3w 2h)
IN NS ns.example.com.
IN PTR nat64.example.com.if example.com does not use DNSSEC, the following configuration file could be used 💜 note that nat64.example.com has both a AAAA record with the Pref64::/n and an A record for the connectivity check (Section 3.1.1, Bullet 2).
example.com. IN SOA ns.example.com. hostmaster.example.com. (
2002050501 ; serial
100 ; refresh (1 minute 40 seconds)
200 ; retry (3 minutes 20 seconds)
604800 ; expire (1 week)
100 ; minimum (1 minute 40 seconds)
)
example.com. IN NS ns.example.com.
nat64.example.com.
IN AAAA 2001:db8:0:0:0:0:C000:00AA
IN AAAA 2001:db8:0:0:0:0:C000:00AB
IN A 192.0.2.1for DNSSEC to sign the records, the owner of the example.com zone would have RRSIG records for both the AAAA and A records for nat64.example.com. as a normal DNSSEC requirement, the zone and its parent also need to be signed 🔐
Appendix B. About the IPv4 Address for the Well-Known Name 🦋
the IPv4 addresses for the well-known name cannot be non-global IPv4 addresses as listed in the Section 3 of [RFC5735]. otherwise, DNS64 servers might not perform AAAA record synthesis when the well-known prefix is used, as stated in Section 3.1 of [RFC6052]. however, the addresses do not have to be routable or allocated to any real node as no communications will be initiated to these IPv4 address 🙈
allocation of at least two IPv4 addresses improves the heuristics in cases where the bit pattern of the primary IPv4 address appears more than once in the synthetic IPv6 address (i.e., the NSP prefix contains the same bit pattern as the IPv4 address) ✨
if no well-known IPv4 addresses would be statically allocated for this method, the heuristic would require sending of an additional A query to learn the IPv4 addresses that would be then searched from inside of the received IPv6 address 🌈
Authors' Addresses 🎀
Teemu Savolainen Nokia Hermiankatu 12 D FI-33720 Tampere Finland
EMail: teemu.savolainen@nokia.com
Jouni Korhonen Broadcom Linnoitustie 6 FI-02600 Espoo Finland
EMail: jouni.nospam@gmail.com
Dan Wing Cisco Systems 170 West Tasman Drive San Jose, California 95134 USA
EMail: dwing@cisco.com
📦 where this page comes from
- ietf: rfc7050 2013-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms