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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8305]  Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
              Better Connectivity Using Concurrency", RFC 8305,
              DOI 10.17487/RFC8305, December 2017,
              <https://www.rfc-editor.org/info/rfc8305>.

9.  Informative References

   [RFC3901]  Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
              Guidelines", BCP 91, RFC 3901, DOI 10.17487/RFC3901,
              September 2004, <https://www.rfc-editor.org/info/rfc3901>.

   [RFC4472]  Durand, A., Ihren, J., and P. Savola, "Operational
              Considerations and Issues with IPv6 DNS", RFC 4472,
              DOI 10.17487/RFC4472, April 2006,
              <https://www.rfc-editor.org/info/rfc4472>.

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]