Staged IPv6 Transition of Domain Name Systems

specifies the IPv6 transport operational guidelines of Domain Name Systems (DNS). It recommends IPv4-only or dual stack for the authoritative servers to avoid the name space fragmentation. also recommends that at least one authoritative server enables IPv4 for every zone. Keeping IPv4-enabled authoritative servers is important to avoid the name space fragmentation as mentioned in . However, it could slow down the transition of DNS to the IPv6 by prioritizing IPv4 over IPv6. This document specifies the three-stage IPv6 transition of DNS, consisting of the following three steps: 1) mandating dual stack (i.e., both IPv4 and IPv6 transport) for every zone (), 2) prioritizing the IPv6 transport over IPv4 by recursive servers or use happy eyeballs (), and 3) turning the IPv4 transport optional for authoritative servers (). 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 RFC 2119.

The first stage of the IPv6 transiton of DNS is to turn the authoritative servers into dual stack by mandating IPv6 as well as IPv4 transport for every zone. Section 1.3 in states that "the recommendation is to always keep at least one authoritative server IPv4-enabled, and to ensure that recursive DNS servers support IPv4." This enables IPv4-only recursive servers to reach any name space as every zone has at least one authoritative server. However, this also demotivates IPv6 deployment on authoritative servers as it implies that recursive servers keeps IPv4 access to authoritative servers. Therefore, it is important to equally define IPv4 and IPv6 for the authoritative server deployment in the specification. This document, at Stage 1, updates and to reccommend that at least one authoritative server enables IPv6 while at least one authoritative server continues to keep IPv4-enabled for every zone. This does not introduce the DNS name space fragmentation because IPv4 global reachability is maintained for every zone even if some zones do not follow the updated recommendation. This stage MAY be suspended for a certain period of time after updating and so every zone is prepared.

The second stage is to recommend recursive servers to support the IPv6 transport for queries to authoritative servers. Suppose Stage 1 is successfully implemented, all zones support at least one IPv6 authoritative server. Then, recursive servers have both choices of IPv4 and IPv6 for access to authoritative servers. ensures that recursive servers support IPv4, but we do not need to ensure the IPv4 transport at this stage. In addition to the dual stack recursive server deployment, this document recommends that recursive servers prioritize the IPv6 transport over IPv4 for their recursive queries to authoritative servers or use happy eyeballs . It enables us to monitor the DNS query traffic by root servers and other authoritative servers and analyze the ratio of IPv6 capable recursive servers and their performance.

The final step is to turn the IPv4 transport optional on authoritative servers so that we prepare for the IPv4 sunset on DNS. To do so, Section 1.3 in could be rephrased to "the recommendation is to always keep at least one authoritative server IPv6-enabled, and to ensure that recursive DNS servers support IPv6." It is expected that most of authoritative servers continue supporting dual stack even if we turn the IPv4 transport optional unless IPv6-only authoritative servers are proven to be feasible and credible. At Stage 2, IPv6-only recursive servers MAY be theoretically viable. However, there is a concern on the name space fragmentation as we do not expect all zones over the Internet follow the up-to-date RFCs and support IPv6 authoritative servers. Therefore, we need careful considerations on turning the IPv4 transport optional for recursive servers. This document does not turn the IPv4 transport of recursive servers optional at Stage 3. The sunset of IPv4 DNS should be considered along with the IPv4 sunset of all Internet applications.

The timeline of the transition SHOULD globally be advised and aligned althogh no synchronous configuration changes are required. For example, the following timeline for the staged transition proposed in this document is considered:

(By the end of Y2028) Stage 1: Mandate the dual stack transport on all the authoritative servers by updating and .
(Y2030) Stage 2: Prioritize IPv6 transport over IPv4 by recursive servers. A new Internet-Draft MAY be required.
(Y2035) Stage 3: Turn the IPv4 transport optional by updating and again or by obsoleting them.

Stage 1 and 2 do not introduce any name space fragmentation as the IPv4 transport MUST still be supported nevertheless the IPv6 transport is not enabled by part of authoritative servers during their transition delay. Stage 2 MAY implement a step-by-step strategy such as World IPv6 Day and World IPv6 Launch. Stage 3 MAY be deferred if careful analysis of the penetration and performance of the IPv6 transport after Stage 2 shows concerning results.

This document does not have IANA Considerations.

This document introduces no additional security considerations.