Skip to main content

Deprecation of DNS64 for Discovery of IPv6 Prefix Used for IPv6 Address Synthesis
draft-buraglio-deprecate7050-00

Document Type Active Internet-Draft (dnsop WG)
Authors Nick Buraglio , Tommy Jensen , Jen Linkova
Last updated 2024-11-04 (Latest revision 2024-09-09)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources Mailing list discussion
Stream WG state Candidate for WG Adoption
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-buraglio-deprecate7050-00
dnsop                                                        N. Buraglio
Internet-Draft                                   Energy Sciences Network
Intended status: Standards Track                               T. Jensen
Expires: 13 March 2025                                         Microsoft
                                                              J. Linkova
                                                                  Google
                                                        9 September 2024

Deprecation of DNS64 for Discovery of IPv6 Prefix Used for IPv6 Address
                               Synthesis
                    draft-buraglio-deprecate7050-00

Abstract

   RFC7050 describes a method for detecting the presence of DNS64 and
   for learning the IPv6 prefix used for protocol translation (RFC6145).
   This methodology depends on the existence of a well-known IPv4-only
   fully qualified domain name "ipv4only.arpa.".  Because newer methods
   exist that lack the requirement of a higher level protocol, instead
   using existing operations in the form of native router
   advertisements, discovery of the IPv6 prefix used for protocol
   translation using RFC7050 is deprecated to legacy status.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://buraglio.github.io/draft-buraglio-deprecate7050/draft-
   buraglio-deprecate7050.html.  Status information for this document
   may be found at https://datatracker.ietf.org/doc/draft-buraglio-
   deprecate7050/.

   Discussion of this document takes place on the dnsop Working Group
   mailing list (mailto:dnsop@ietf.org), which is archived at
   https://datatracker.ietf.org/wg/dnsop/about/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/dnsop/.

   Source for this draft and an issue tracker can be found at
   https://github.com/buraglio/draft-buraglio-deprecate7050.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

Buraglio, et al.          Expires 13 March 2025                 [Page 1]
Internet-Draft              Deprecate RFC7050             September 2024

   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 13 March 2025.

Copyright Notice

   Copyright (c) 2024 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Existing issues with RFC 7050 . . . . . . . . . . . . . . . .   4
     3.1.  Dependency on Network-Provided Recursive Resolvers  . . .   4
     3.2.  Network Stack Initialization Delay  . . . . . . . . . . .   4
     3.3.  Inflexibility . . . . . . . . . . . . . . . . . . . . . .   4
     3.4.  Security Implications . . . . . . . . . . . . . . . . . .   5
       3.4.1.  Definition of secure channel  . . . . . . . . . . . .   5
       3.4.2.  Secure channel example of IPsec . . . . . . . . . . .   5
       3.4.3.  Secure channel example of link layer encryption . . .   6
   4.  Recommendations for PREF64 Discovery  . . . . . . . . . . . .   6
     4.1.  Deployment Recommendations  . . . . . . . . . . . . . . .   6
     4.2.  Clients Implementation Recommendations  . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

Buraglio, et al.          Expires 13 March 2025                 [Page 2]
Internet-Draft              Deprecate RFC7050             September 2024

1.  Introduction

   The DNS-based mechanism defined in [RFC7050] was the very first
   mechanism available for nodes to discover the PREF64 information.
   However since the publication of RFC7050, other methods have been
   developed to address some of [RFC7050] limitations.

   For example, [RFC8781] describes a Neighbor Discovery option to be
   used in Router Advertisements (RAs) to communicate prefixes of
   Network Address and Protocol Translation from IPv6 clients to IPv4
   servers (NAT64) to hosts.  This approach has the advantage of using
   the same communication channel IPv6 clients use to discover other
   network configurations such as the network's default route.  This
   means network administrators can secure this configuration along with
   other configurations IPv6 requires using a single approach such as RA
   Guard [RFC6105].

   Taking into account some fundamental flaws of [RFC7050] mechanism, it
   seems desirable to deprecate it and recommend new deployments and
   implementations to use better methods to obtain PREF64 information.

2.  Conventions and Definitions

   NAT64: a mechanism for translating IPv6 packets to IPv4 packets and
   vice versa.  The translation is done by translating the packet
   headers according to the IP/ICMP Translation Algorithm defined in
   [RFC6145].

   DNS64: a mechanism for synthesizing AAAA records from A records,
   defined in [RFC6147].

   Router Advertisement: A packet used by Neighbor Discovery [RFC4861]
   and StateLess Address AutoConfiguration (SLAAC, [RFC4862]) to
   advertize the presence of the routers, togther with other IPv6
   configuration information.

   PREF64 (or NAT64 prefix): An IPv6 prefix used for IPv6 address
   synthesis and for network addresses and protocols translation from
   IPv6 clients to IPv4 servers, [RFC6146].

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Buraglio, et al.          Expires 13 March 2025                 [Page 3]
Internet-Draft              Deprecate RFC7050             September 2024

3.  Existing issues with RFC 7050

   DNS-based method of discovering the NAT64 prefix introduces some
   challenges, which make this approach less preferable than most
   recently developed alternatives (such as PREF64 RA option,
   [RFC8781]).  This section outlines the key issues, associated with
   [RFC7050].

3.1.  Dependency on Network-Provided Recursive Resolvers

   Fundamentally, the presence of the NAT64 and the exact value of the
   prefix used for the translation are network-specific attributes.
   Therefore, to discover the PREF64 the device needs to use the DNS
   resolvers provided by the network.  If the device is configured to
   use other recursive resolvers, its name resolution APIs and libraries
   are required to recognize 'ipv4only.arpa.' as a special name and give
   it special treatment.  This issue and remediation approach are
   discussed in [RFC8880].  However, it has been observed that not all
   [RFC7050] implementations support [RFC8880] requirements for special
   treatment of 'ipv4only.arpa.'.  As a result, configuring such systems
   to use resolvers other than the one provided by the network might
   break the PREF64 discovery, leading to degraded user experience.

3.2.  Network Stack Initialization Delay

   When using SLAAC ([RFC4862]), an IPv6 host usually needs just one
   Router Advertisement (RA, [RFC4861]) packet to obtain all information
   required to complete the host's network configuration.  For an
   IPv6-only host, the PREF64 information is essential, especially if
   the host implements the customer-side translator (CLAT) ([RFC6877]).
   The mechanism defined in [RFC7050] implies that the PREF64
   information is not bundled with all other network configuration
   parameters provided by RAs, and can only be obtained after the host
   has configured the rest of its IPv6 stack.  Therefore, until the
   process described in Section 3 of [RFC7050] is completed, the CLAT
   process can not start, which negatively impacts IPv4-only
   applications which have alrady started.

3.3.  Inflexibility

   Section 3 of [RFC7050] requires that the node SHALL cache the replies
   received during the PREF64 discovery and SHOULD repeat the discovery
   process ten seconds before the TTL of the Well-Known Name's synthetic
   AAAA resource record expires.  As a result, once the PREF64 is
   discovered, it will be used until the TTL expired, or until the node
   disconnects from the network.  There is no mechanism for an operator
   to force the PREF64 rediscovery on the node without disconnecting the
   node from the network.  If the operator needs to change the PREF64

Buraglio, et al.          Expires 13 March 2025                 [Page 4]
Internet-Draft              Deprecate RFC7050             September 2024

   value used in the network, they need to proactively reduce the TTL
   value returned by the DNS64 server.  This method has two significant
   drawbacks:

   *  many networks utilize external DNS64 servers and therefore have no
      control over the TTL value.

   *  the PREF64 changes need to be planned and executed at least TTL
      seconds in advance.  If the operator needs to notify nodes that a
      particular prefix must not be used (e.g. during a network outage
      or if the nodes learnt a rogue PREF64 as a result of an attack),
      it might not be possible without interrupting the network
      connectivity for the affected nodes.

3.4.  Security Implications

   As discussed in Section 7 of [RFC7050], the DNS-based PREF64
   discovery is prone to DNS spoofing attacks.  In addition to creating
   a wider attack surface for IPv6 deployments, [RFC7050] has other
   security challenges worth noting to justify declaring it legacy.

3.4.1.  Definition of secure channel

   [RFC7050] requires a node's communication channel with a DNS64 server
   to be a "secure channel" which it defines to mean "a communication
   channel a node has between itself and a DNS64 server protecting DNS
   protocol-related messages from interception and tampering."  This
   need is redundant when another communication mechanism of
   IPv6-related configuration, specifically Router Advertisements, can
   already be defended against tampering by RA Guard [RFC6105].
   Requiring nodes to implement two defense mechanisms when only one is
   necessary when [RFC8781] is used in place of [RFC7050] creates
   unnecessary risk.

3.4.2.  Secure channel example of IPsec

   One of the two examples [RFC7050] defines to qualify a communication
   channel with a DNS64 server is the use of an "IPsec-based virtual
   private network (VPN) tunnel".  As of the time of this writing, this
   is not supported as a practice by any common operating system DNS
   client.  While they could, there have also since been multiple
   mechanisms defined for performing DNS-specific encryption such as
   those defined in [RFC9499] that would be more appropriately scoped to
   the applicable DNS traffic.  These are also compatible with encrypted
   DNS advertisement by the network using Discovery of Network-
   designated Resolvers [RFC9463] that would ensure the clients know in
   advance that the DNS64 server supported the encryption mechanism.

Buraglio, et al.          Expires 13 March 2025                 [Page 5]
Internet-Draft              Deprecate RFC7050             September 2024

3.4.3.  Secure channel example of link layer encryption

   The other example given by [RFC7050] that would allow a communication
   channel with a DNS64 server to qualify as a "secure channel" is the
   use of a "link layer utilizing data encryption technologies".  As of
   the time of this writing, most common link layer implementations use
   data encryption already with no extra effort needed on the part of
   network nodes.  While this appears to be a trivial way to satisfy
   this requirement, it also renders the requirement meaningless since
   any node along the path can still read the higher-layer DNS traffic
   containing the translation prefix.  This seems to be at odds with the
   definition of "secure channel" as explained in Section 2.2 of
   [RFC7050].

4.  Recommendations for PREF64 Discovery

4.1.  Deployment Recommendations

   Operators deploying NAT64 networks SHOULD provide PREF64 information
   in Router Advertisements as per [RFC8781].

4.2.  Clients Implementation Recommendations

   Clients SHOULD obtain PREF64 information from Router Advertisements
   as per [RFC8781] instead of using [RFC7050] method.  In the absense
   of the PREF64 information in RAs, a client MAY choose to fall back to
   RFC7050.

5.  Security Considerations

   Obtaining PREF64 information from Router Advertisements improves the
   overall security of an IPv6-only client as it mitigates all attack
   vectors related to spoofed or rogue DNS response, as discussed in
   Section 7 of [RFC7050].  Security considerations related to obtaining
   PREF64 information from RAs are discussed in Section 7 of [RFC8781].

6.  IANA Considerations

   It is expected that there will be a long tail of both clients and
   networks still relying on [RFC7050] as a sole mechanism to discover
   PREF64 information.  Therefore IANA still need to maintain
   "ipv4only.arpa." as described in [RFC7050] and this document has no
   IANA actions.

7.  References

7.1.  Normative References

Buraglio, et al.          Expires 13 March 2025                 [Page 6]
Internet-Draft              Deprecate RFC7050             September 2024

   [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/rfc/rfc2119>.

   [RFC7050]  Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
              the IPv6 Prefix Used for IPv6 Address Synthesis",
              RFC 7050, DOI 10.17487/RFC7050, November 2013,
              <https://www.rfc-editor.org/rfc/rfc7050>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

7.2.  Informative References

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <https://www.rfc-editor.org/rfc/rfc4861>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <https://www.rfc-editor.org/rfc/rfc4862>.

   [RFC6105]  Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
              Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
              DOI 10.17487/RFC6105, February 2011,
              <https://www.rfc-editor.org/rfc/rfc6105>.

   [RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
              <https://www.rfc-editor.org/rfc/rfc6145>.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
              April 2011, <https://www.rfc-editor.org/rfc/rfc6146>.

   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
              Beijnum, "DNS64: DNS Extensions for Network Address
              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
              DOI 10.17487/RFC6147, April 2011,
              <https://www.rfc-editor.org/rfc/rfc6147>.

Buraglio, et al.          Expires 13 March 2025                 [Page 7]
Internet-Draft              Deprecate RFC7050             September 2024

   [RFC6877]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
              Combination of Stateful and Stateless Translation",
              RFC 6877, DOI 10.17487/RFC6877, April 2013,
              <https://www.rfc-editor.org/rfc/rfc6877>.

   [RFC8781]  Colitti, L. and J. Linkova, "Discovering PREF64 in Router
              Advertisements", RFC 8781, DOI 10.17487/RFC8781, April
              2020, <https://www.rfc-editor.org/rfc/rfc8781>.

   [RFC8880]  Cheshire, S. and D. Schinazi, "Special Use Domain Name
              'ipv4only.arpa'", RFC 8880, DOI 10.17487/RFC8880, August
              2020, <https://www.rfc-editor.org/rfc/rfc8880>.

   [RFC9463]  Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
              and T. Jensen, "DHCP and Router Advertisement Options for
              the Discovery of Network-designated Resolvers (DNR)",
              RFC 9463, DOI 10.17487/RFC9463, November 2023,
              <https://www.rfc-editor.org/rfc/rfc9463>.

   [RFC9499]  Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
              RFC 9499, DOI 10.17487/RFC9499, March 2024,
              <https://www.rfc-editor.org/rfc/rfc9499>.

Acknowledgments

   TODO acknowledge.

Authors' Addresses

   Nick Buraglio
   Energy Sciences Network
   Email: buraglio@forwardingplane.net

   Tommy Jensen
   Microsoft
   Email: tojens.ietf@gmail.com

   Jen Linkova
   Google
   Email: furry13@gmail.com

Buraglio, et al.          Expires 13 March 2025                 [Page 8]