Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis
updated by
- rfc-8880 — Special Use Domain Name 'ipv4only.arpa'
Extracted elements (26)
Connectivity checks deliberately avoid the 'ipv4only.arpa.' addresses and instead resolve a separate A record from the NAT64 FQDN. This prevents packet leakage to the Internet and avoids false-negative connectivity results when operators neglect to provision a connectivity check server.
The WKAs must be global (not RFC 5735 non-global) IPv4 addresses because DNS64 servers may refuse to synthesize AAAA records for non-global IPv4 addresses when the Well-Known Prefix is in use, per RFC 6052 Section 3.1. The addresses need not be routable since no actual communication is directed to them.
Two WKAs (192.0.0.170 and 192.0.0.171) are allocated rather than one because some NSP prefixes may contain the same 32-bit pattern as the primary WKA, making it appear more than once in the synthetic IPv6 address. The second address provides an unambiguous alternative for locating the embedded IPv4 value.
DNS64 cannot perform IPv6 address synthesis for nodes running DNSSEC-validating resolvers; those nodes must perform synthesis locally using a discovered Pref64::/n. This is the primary motivation for the discovery mechanism.
The heuristic discovery method does not support learning per-IPv4-address-range prefix mapping rules used by some DNS64 deployments (e.g., separate NAT64 for data-center vs. Internet ranges). Nodes will apply a single discovered Pref64::/n to all IPv4 addresses, which may cause routing issues.
A node MUST look through all received AAAA resource records to collect one or more Pref64::/n values, and MUST check on octet boundaries to ensure each 32-bit WKA appears exactly once in the IPv6 address.
A node requiring NAT64/Pref64::/n information SHALL send a DNS AAAA query for 'ipv4only.arpa.' and MAY do so on both IPv6-only and dual-stack networks.
Clients MUST NOT send connectivity checks to addresses returned by the 'ipv4only.arpa.' query; network operators MUST NOT operate a server at those addresses. A separate PTR/A lookup is used instead to find connectivity check servers.
DNS64 servers MUST NOT interfere with or perform special processing for queries related to the well-known name 'ipv4only.arpa.'.
For DNSSEC-based validation, each NAT64 FQDN MUST have one or more AAAA records containing Pref64::WKA, and each Pref64::WKA MUST have a PTR record pointing back to the NAT64 FQDN. The NAT64 FQDN's records MUST be signed with DNSSEC.
If no trusted domain match is found at step 3 of DNSSEC validation, the remaining validation steps MUST NOT be performed and the discovery procedure is considered insecure.
Network operators providing NAT64 with ICMPv6-based connectivity checks MUST disable ICMPv6 rate limiting for connectivity check messages.
On a negative DNS response (NXDOMAIN, NODATA), the node MUST obey the TTL before resending the AAAA query; on timeout, the node SHOULD retransmit like any other DNS query.
The authoritative name server for 'ipv4only.arpa.' SHALL set the DNS record TTL to at least 60 minutes to improve DNS caching effectiveness, and the domain MUST be signed with DNSSEC.
The node SHALL cache Pref64::/n discovery replies and SHOULD repeat the discovery process ten seconds before the TTL of the WKN's synthetic AAAA record expires.
When multiple Pref64::/n prefixes are discovered, the node MUST use all of them when performing local IPv6 address synthesis, applying them in the order received from the DNS64 server.
When querying AAAA records for the WKN, a node MUST set the Checking Disabled (CD) bit to zero; otherwise the DNS64 server will not perform IPv6 address synthesis and will not reveal the Pref64::/n.
Connectivity checks against an NSP-based Pref64::/n use ICMPv6 Echo Requests sent to an IPv6 address synthesized from the NAT64 FQDN's A record IPv4 address. The node SHALL retransmit up to three times (at t=0, t+1s, t+3s) before declaring the prefix non-functional.
The DNSSEC validation procedure for Pref64::/n consists of five steps: (1) heuristic AAAA query for 'ipv4only.arpa.', (2) PTR query for Pref64::WKA to obtain NAT64 FQDNs, (3) comparison of FQDNs against a trusted domain list, (4) AAAA query for the NAT64 FQDN, and (5) DNSSEC validation of the AAAA response.
The Well-Known IPv4-only Name (WKN) is the FQDN 'ipv4only.arpa.', which is well-known to have only A records. Querying its AAAA records causes a DNS64 server to synthesize IPv6 addresses, revealing the Pref64::/n in use.
Two Well-Known IPv4 Addresses (WKAs) are defined for Pref64::/n discovery: 192.0.0.170 and 192.0.0.171. A node searches for these values within received synthetic IPv6 addresses to determine the prefix length and format.
IANA allocated 192.0.0.170/32 and 192.0.0.171/32 in the IPv4 Special Purpose Address Registry for NAT64/DNS64 Discovery (RFC 7050). These addresses are marked non-Source, non-Destination, non-Forwardable, non-Global, and Reserved-by-protocol.
IANA delegated the second-level domain 'ipv4only.arpa.' in the .ARPA zone for NAT64/DNS64 discovery. No further delegation below this name is intended; administrative management is by IANA.
An attacker controlling a DNS64 server or able to intercept DNS responses can inject a malicious Pref64::/n, redirecting all synthesized traffic to an attacker-controlled destination, causing denial-of-service, flooding, or eavesdropping. Nodes SHOULD use a trusted DNS64 server over a secure channel or validate using DNSSEC.
DNSSEC protection is required for AAAA resource record queries to 'ipv4only.arpa.' because fake positive AAAA responses could cause nodes to erroneously detect a Pref64::/n and use an attacker-injected prefix for address synthesis. The zone MUST be signed.
Implementations using DNSSEC validation SHOULD NOT prompt users to add unknown domains to their trusted domain list, as users tend to accept such prompts without consideration. It is better to fail the discovery procedure when no trusted domain match is found.