Internet-Draft Deprecate RFC7050 September 2024
Buraglio, et al. Expires 13 March 2025 [Page]
Workgroup:
dnsop
Internet-Draft:
draft-buraglio-deprecate7050-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
N. Buraglio
Energy Sciences Network
T. Jensen
Microsoft
J. Linkova
Google

Deprecation of DNS64 for Discovery of IPv6 Prefix Used for IPv6 Address Synthesis

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.

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.

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.

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 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.

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

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc6147>.
[RFC6877]
Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, , <https://www.rfc-editor.org/rfc/rfc6877>.
[RFC8781]
Colitti, L. and J. Linkova, "Discovering PREF64 in Router Advertisements", RFC 8781, DOI 10.17487/RFC8781, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc9463>.
[RFC9499]
Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, , <https://www.rfc-editor.org/rfc/rfc9499>.

Acknowledgments

TODO acknowledge.

Authors' Addresses

Nick Buraglio
Energy Sciences Network
Tommy Jensen
Microsoft
Jen Linkova
Google