Network Working Group H. Asai Internet-Draft Preferred Networks / WIDE Project Updates: 3901, 44724 (if approved) T. Tomine Intended status: Informational NAOJ / WIDE Project Expires: 4 September 2025 3 March 2025 Staged IPv6 Transition of Domain Name Systems draft-asai-dnsop-rfc4472bis-00 Abstract This document specifies the three-stage IPv6 transition of Domain Name Systems (DNS) transport. The scope of this document is only the transport between authoritative servers and recursive servers, but does not include the transport of recursive servers for DNS clients. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 September 2025. Copyright Notice Copyright (c) 2025 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 (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Asai & Tomine Expires 4 September 2025 [Page 1] Internet-Draft Staged IPv6 Transition of DNS March 2025 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Stage 1: Dual Stack DNS Zones . . . . . . . . . . . . . . . . 2 3. Stage 2: Dual Stack Recursive Servers . . . . . . . . . . . . 3 4. Stage 3: Optional IPv4 Transport on Authoritative Servers . . 3 5. Considerations on Timeline of the Staged Transition . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 8. Normative References . . . . . . . . . . . . . . . . . . . . 4 9. Informative References . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction [RFC3901] 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. [RFC4472] 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 [RFC3901]. 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 (Section 2), 2) prioritizing the IPv6 transport over IPv4 by recursive servers or use happy eyeballs [RFC8305] (Section 3), and 3) turning the IPv4 transport optional for authoritative servers (Section 4). 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 [RFC2119]. 2. Stage 1: Dual Stack DNS Zones 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. Asai & Tomine Expires 4 September 2025 [Page 2] Internet-Draft Staged IPv6 Transition of DNS March 2025 Section 1.3 in [RFC4472] 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 [RFC3901] and [RFC4472] 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 [RFC3901] and [RFC4472] so every zone is prepared. 3. Stage 2: Dual Stack Recursive Servers 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. [RFC4472] 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 [RFC8305]. 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. 4. Stage 3: Optional IPv4 Transport on Authoritative Servers 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 [RFC4472] 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 Asai & Tomine Expires 4 September 2025 [Page 3] Internet-Draft Staged IPv6 Transition of DNS March 2025 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. 5. Considerations on Timeline of the Staged Transition 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: 1. (By the end of Y2028) Stage 1: Mandate the dual stack transport on all the authoritative servers by updating [RFC3901] and [RFC4472]. 2. (Y2030) Stage 2: Prioritize IPv6 transport over IPv4 by recursive servers. A new Internet-Draft MAY be required. 3. (Y2035) Stage 3: Turn the IPv4 transport optional by updating [RFC3901] and [RFC4472] 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. 6. IANA Considerations This document does not have IANA Considerations. 7. Security Considerations This document introduces no additional security considerations. 8. Normative References Asai & Tomine Expires 4 September 2025 [Page 4] Internet-Draft Staged IPv6 Transition of DNS March 2025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, . 9. Informative References [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational Guidelines", BCP 91, RFC 3901, DOI 10.17487/RFC3901, September 2004, . [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, DOI 10.17487/RFC4472, April 2006, . Authors' Addresses Hirochika Asai Preferred Networks, Inc. / WIDE Project 1-6-1 Otemachi, Chiyoda, Tokyo 100-0004 Japan Email: panda@wide.ad.jp Takashi Tomine National Astronomical Observatory of Japan / WIDE Project 2-21-1 Osawa Mitaka, Tokyo 181-8588 Japan Email: tomine@wide.ad.jp Asai & Tomine Expires 4 September 2025 [Page 5]