An EDNS0 Option for Sharing Pref64::/n

Network Address and Protocol Translation from IPv6 clients to IPv4 servers (NAT64) function is widely deployed, especially in cellular networks. Such a function is solicited when an IPv6-only host communicates with an IPv4-only server. For that communication to take place, IPv4-only servers are represented in the IPv6 domain by synthesizing IPv6 addresses based on IPv4 addresses (called, IPv4-converted IPv6 addresses). The address translation algorithm is specified in . In addition to an IPv4 address, this algorithm uses a dedicated IPv6 prefix as input. Such a prefix can be the Well-Known Prefix (i.e., 64:ff9b::/96) or a Network-Specific Prefix (NSP). DNS64 specifies a companion mechanism to represent IPv4-only servers in the IPv6 domains. Such a mechanism relies upon the same address translation algorithm as the one used by the NAT64 function. When both DNS64 and NAT64 are deployed in the same network, the same IPv6 prefix must be used to feed the address translation algorithm (Section 2 of ). A sample deployment scenario is depicted in . Note that no mechanism is supported to synchronize the prefix configured in both functions. In particular, there is no communication between the DNS64 and NAT64 functions.

In networks where DNS64 is enabled, some deployments use distinct IP addresses to reach the "normal" DNS server and the DNS64 server. This is used to demux queries issues by IPv6-only hosts from those from dual-stack hosts. The mechanism defined in this document allows to use the same DNS configuration for both IPv6-only and dual-stack hosts. NAT64 does not require a DNS64 server to be enabled and, even if it is used, it does not mandate that it is enabled in the same network. As such, several public DNS64 servers are currently available for use over the Internet. However, these servers are restricted to the Well-Known Prefix. Users who decides to bypass their network-provisioned DNS64 server (e.g., including both trusted (access network, typically) and untrusted networks such as Airports) may experience connectivity issues if an NSP is used in their local networks (Section 4.4 of ). This document solves that issues by specifying a mechanism that allows to use any DNS64 server, not only the one hosted in the network that enables the NAT64. If the IPv4 address of a remote IPv4-only server is known to an IPv6-only host (e.g., IPv4 literals, legacy DNS), the IPv6-only host can proceed with local address synthesis. For example, the stub resolver on the IPv6-only host tries to obtain (native) AAAA records, and if they are not found, the DNS64 function on the host will send a query for A records and then synthesize AAAA records. This behavior requires the host's stub-resolver to learn the prefix used for IPv6/IPv4 translation and synthesize AAAA records accordingly. Many mechanisms were specified to discover such prefix, e.g.: defines a new Port Control Protocol (PCP) option to inform hosts about the Pref64::/n and suffix used by a NAT64 function. specifies a Neighbor Discovery option used in Router Advertisements (RAs) to communicate NAT64 prefixes to hosts. The reader may refer to for an analysis on the issues related to the discovery of the Pref64::/n. In some environments two DNS queries are issued even if the host is serviced using an IPv6-only connectivity (typically, AAAA followed by A). These two queries are sent sequentially, which introduces an extra delay when the target resource is IPv4-only. Such delay can be prevented owing to the mechanism specified in this document. As a side effect, the mechanism optimizes the load on DNS64 servers as only one query will be used instead of two. This document updates as it extends the DNS64 processing to also consider the supplied Pref64::/n in an EDNS0 option to synthesize AAA records. In particular statements such as "locally configured Pref64::/n" are updated to "locally configured Pref64::/n or Pref64::/n supplied in an EDNS0 PREFIX64 option". To that aim, this document leverages the aforementioned discovery mechanism to detect the presence of a NAT64 function. In summary, the mechanism defined in this document is meant to: Provide a signal to indicate the support of NAT64 in a network. Allow a DNS64 server to service clients with distinct NAT64 prefixes. Avoid delays when both A and AAA queries are required. Optimize load on DNS server as only one query is generated rather that duplicating load when both AAA and A queries are required.

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 when, and only when, they appear in all capitals, as shown here. The reader should be familiar with terms and concepts defined in , , and . Also, the document makes use of terms defined in . "IPv6-only host" refers to a host with an IPv6-only connectivity.

The format of the PREFIX64 EDNS0 option is shown in . This format adheres to the guidelines specified in Section 6.1.2 of .

The description of the fields is as follows: MUST be set to TBA (). Size (in octets) of the enclosed Pref64::/n. Allowed values are: 0, 4, 5, 6, 7, 8, and 9. The receiver MUST ignore the option if the OPTION-LENGTH is not set to one of those values. When the value is set to 0, this indicates the presence of a NAT64 function in the network from which the query is generated. This field identifies the IPv6 unicast prefix to be used for constructing an IPv4-converted IPv6 address from an IPv4 address as specified in Section 2.2 of . In such case, the prefix length MUST be 32, 40, 48, 56, 64, and 96 bits (i.e., OPTION-LENGTH must be set to 4, 5, 6, 7, 8, and 9) as specified in . This prefix can be the Well-Known Prefix (i.e., 64:ff9b::/96) or a Network-Specific Prefix. The address synthesis MUST follow the guidelines documented in .

A stub-resolver on an IPv6-only host that discovers the presence of NAT64 inserts the PREFIX64 EDNS0 option in its AAAA queries. If the stub-resolver is on a multi-interfaced device, the Pref64::/n conveyed in the PREFIX64 EDNS0 option MUST be the one that is associated with the interface over which the DNS query is sent. A stub-resolver that is prepared to handle A RRs enclosed in the additional section (e.g., security-aware and validating hosts) MAY insert a PREFIX64 EDNS0 option with an OPTION-LENGTH set to zero in its AAAA DNS queries. Such option is used by intermediate/authoritative servers as a signal to include A RR in the additional section. If a DNS server enables a DNS64 function, then the AAAA query is treated as in with the exception that supplied valid Pref64::/n are used for synthesizing AAAA records. The reply MAY echo the PREFIX64 EDNS0 option. A DNS forwarder MAY be configured to forward AAAA queries that carry an PREFIX64 EDNS0 option with non-null prefixes to a DNS64 server. Such queries are thus relayed to that DNS64 server. Upon receipt of such queries, the AAAA query is treated as in with the exception that supplied valid Pref64::/n are used for synthesizing AAAA records. This prevents from exposing distinct IP addresses of DNS servers for "normal" DNS and DNS64 operations. A DNS64 MAY be instructed to return the Pref64::/n that it uses when synthesizing AAAA records. If so, the DNS64 MUST include the PREFIX64 option in its replies that carry synthesized AAAA records. This is superior to the current situation where users have to check the documentation (when available) to determine the prefix used by a DNS64 server for address synthesis. Absent such checks, errors can be encountered to service IPv6-only hosts. The use of PREFIX64 option allows to automatically detect mismatches between the prefix used in the network (that is, the NAT64 function) and the one that is used by a DNS64 function. A stub-resolver SHOULD determine whether the returned AAAA includes a native or IPv4-converted IPv6 by comparing the first bits of the IPv6 address with the local Pref64::/n. This check is also meant to determine that an on-path attacker has modified the PREFIX64 option.

Generic EDNS0 security considerations are discussed in Section 8 of . As discussed in Section 5.5 of , a security-aware and validating host has to perform the DNS64 function locally. This specification does not prevent that. The only enhancement is the receipt of A RRs in the additional section of AAAA replies.

This document requests IANA to assign the following new code from the "DNS EDNS0 Option Codes (OPT)" registry available at :

Thanks to Tiru Reddy for the comments.