Updates to DNS64 Functionality Advertisement for DNS RA Option

DNS Extensions for Network Address Translation from IPv6 clients to IPv4 servers (DNS64) is a widely deployed mechanism for IPv6-only networks requiring access to IPv4-only services. introduce the reasons for using RA to deliver DNS64 address configuration. This document defines a new flag in the DNS RA option to communicate DNS64 server address to hosts.

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.

This section describes the key use cases that motivate the introduction of a new IPv6 Router Advertisement option to explicitly signal the availability of DNS64-capable resolvers.

Operators may wish to gradually migrate users from dual-stack to IPv6-only without relying on APN isolation or separate network slices. In such scenarios: IPv6-only users require DNS64 to access IPv4-only content. Dual-stack users should continue using standard DNS resolvers to avoid unnecessary translation and performance impact on NAT64 gateways. If both user groups share the same network, the operator needs a mechanism to selectively provide DNS64 server addresses only to IPv6-only hosts. Using RDNSS to distribute DNS server addresses would apply to all users, potentially overloading NAT64 gateways with traffic from dual-stack hosts. The proposed option enables the network to explicitly indicate which resolvers are DNS64-capable, allowing hosts to make informed decisions.

Operators often roll out new services gradually to manage risk and validate performance. For example: Initially, only 10% of IPv6-only users are directed to DNS64 resolvers. Over time, this percentage is increased until full deployment is achieved. With RDNSS alone, all users receive the same DNS server addresses, making phased rollout difficult without complex per-user configuration or multiple network slices. The proposed option allows operators to control which hosts receive DNS64 resolver information based on network policies (e.g., by selectively sending Router Advertisements with or without the new option). This enables fine-grained, incremental deployment without requiring per-host configuration changes.

In some deployments, operators operate multiple DNS server tiers: Tier 1: Standard DNS resolvers (non-DNS64) for dual-stack and IPv4-only users. Tier 2: DNS64-capable resolvers for IPv6-only users. Both tiers may serve the same network prefix. Without explicit signaling, IPv6-only hosts cannot distinguish which resolvers support DNS64. They would need to either: Probe each resolver (increasing signaling overhead and latency), or Be statically configured (reducing operational flexibility). The proposed option allows the network to explicitly advertise the DNS64 capability, enabling hosts to select the appropriate resolver without additional probing.

While host-side synthesis (e.g., using Pref64 options as defined in RFC 8781) is a valid approach, it requires host support and may not be available on all devices. In many real-world deployments: Legacy or constrained devices may not support host-side synthesis. Operators may prefer centralized translation for policy control, logging, or security reasons. For such environments, DNS64 remains a necessary component. The proposed option enhances DNS64 deployments by giving operators better control over which hosts use DNS64, without requiring host-side modifications beyond initial implementation of the option.

Need 1: Coexistence of IPv6-only and dual-stack users. Allows selective signaling of DNS64 resolvers to IPv6-only hosts. Need 2: Phased rollout. Enables incremental deployment without per-host configuration. Need 3: Multiple DNS server tiers. Lets hosts distinguish DNS64-capable resolvers from standard ones. Need 4: Centralized translation control. Supports operators who prefer DNS64 over host-side synthesis.

This section clarifies how the proposed DNS64 Router Advertisement option relates to existing mechanisms, emphasizing that it is intended as a complementary tool rather than a replacement for established solutions.

The Pref64 option (RFC 8781) is used to advertise the IPv6 prefix used for DNS64-based address synthesis, enabling host-side synthesis. This approach allows IPv6-only hosts to synthesize IPv4-embedded addresses locally without involving a DNS64 server. The proposed DNS64 option addresses a different problem: it signals which DNS servers are DNS64-capable, enabling hosts to select the appropriate resolver. The two options are complementary: Pref64 option enables host-side synthesis. DNS64 option enables network-side DNS64 selection. Operators may choose to deploy: Pref64 only (for hosts that support local synthesis), DNS64 option only (for networks relying on centralized DNS64 translation), or Both (for networks supporting a mix of host types and deployment strategies). Neither option replaces the other; they serve different operational needs.

RDNSS (Recursive DNS Server) is the standard mechanism for distributing DNS server addresses via Router Advertisements. However, RDNSS alone cannot indicate whether a DNS server supports DNS64 functionality. This limitation leads to the operational challenges described in the use cases: IPv6-only hosts cannot distinguish DNS64-capable resolvers from standard ones. Dual-stack hosts may unintentionally use DNS64 resolvers, increasing load on NAT64 gateways. The proposed option extends RDNSS by adding capability signaling. It does not replace RDNSS; rather, it builds upon it to provide richer information to hosts. In implementations, the DNS64 option would typically be carried alongside RDNSS options in the same RA message.

PDP context or APN (Access Point Name) isolation is a mechanism used in mobile networks to separate users into different logical networks. Operators can assign: IPv4-only PDP contexts, Dual-stack PDP contexts, or IPv6-only PDP contexts. This approach works but has operational trade-offs: Requires per-user configuration and management. May increase operational complexity when introducing new service tiers. Does not easily support per-user percentage-based rollout without complex provisioning systems. The proposed option operates at the IP layer, not at the PDP context layer. It provides a finer-grained, more flexible mechanism that works within a single network slice or PDP context. Operators can combine both approaches: Use PDP context for coarse-grained separation (e.g., IPv6-only users in a dedicated context). Use the proposed option for fine-grained control within that context (e.g., gradually enabling DNS64 for a subset of IPv6-only users). The option is not a replacement for PDP context isolation, but rather a complementary tool for operators seeking more flexible IPv6-only deployment strategies.

Some have suggested that hosts could detect DNS64 capability by: Probing DNS servers (e.g., by querying for AAAA records of known IPv4-only domains), or Using well-known addresses or special-purpose domains. While technically possible, these approaches have limitations: Increased latency: Probing adds delay to DNS resolution. Signaling overhead: Repeated probes consume network and server resources. Uncertainty: Results may be ambiguous or change over time. No network control: The operator cannot centrally control which hosts use DNS64. The proposed option provides a deterministic, low-overhead, operator-controlled alternative. It does not prohibit hosts from using detection mechanisms; rather, it offers a more efficient and controllable method when network-side signaling is available.

Based on , this specification introduces a 'T' flag bit allocated in the leftmost bit of the Reserved field to signal the presence of DNS64 server addresses in the option payload. Figure 1 shows the format of the DNS64 option.

Fields: Type: 8-bit identifier: 25 Length: 8-bit unsigned integer. Flag T: 1-bit integer. set to indicate DNS64 server addresses are in the option payload. Lifetime: 32-bit unsigned integer. DNS64 Server Address(es): One or more 128-bit IPv6 addresses of the DNS64.

This memo does not introduce any new security problems. Considerations are described in Section 7 in

This document requests allocation for the Flag T.

Thanks to Lorenzo Colitti, Nick Buraglio, Jordi Palet, Jen Linkova, Philipp S. Tiesel,Ted Lemon for the discussions, the feedback, and all contribution.