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]