rfc9872v1.txt   rfc9872.txt 
skipping to change at line 101 skipping to change at line 101
[RFC8305]). [RFC8305]).
* Perform local DNS64 [RFC6147] functions. * Perform local DNS64 [RFC6147] functions.
* Support applications relying on IPv4 address referral * Support applications relying on IPv4 address referral
(Section 3.2.2 of [RFC7225]). (Section 3.2.2 of [RFC7225]).
Dynamic PREF64 discovery is useful to keep the NAT64 prefix Dynamic PREF64 discovery is useful to keep the NAT64 prefix
configuration up-to-date, particularly for unmanaged endpoints or configuration up-to-date, particularly for unmanaged endpoints or
endpoints that move between networks. [RFC7050] introduces the first endpoints that move between networks. [RFC7050] introduces the first
DNS64-based mechanism for PREF64 discovery based on [RFC7051] DNS64-based mechanism for PREF64 discovery per the analysis described
analysis. However, subsequent methods have been developed to address in [RFC7051]. However, subsequent methods have been developed to
the [RFC7050] limitations. address the limitations of the mechanism described in [RFC7050].
For instance, [RFC8781] defines a Neighbor Discovery [RFC4861] option For instance, [RFC8781] defines a Neighbor Discovery [RFC4861] option
for Router Advertisements (RAs) to convey PREF64 information to for Router Advertisements (RAs) to convey PREF64 information to
hosts. This approach offers several advantages (Section 3 of hosts. This approach offers several advantages (Section 3 of
[RFC8781]), including fate sharing with other host network [RFC8781]), including fate sharing with other host network
configuration parameters. configuration parameters.
Due to fundamental shortcomings of the [RFC7050] mechanism Due to fundamental shortcomings of the mechanism defined in [RFC7050]
(Section 4), [RFC8781] is the preferred solution for new deployments. (see Section 4 for more details), [RFC8781] describes the preferred
Implementations should strive for consistent PREF64 acquisition solution for new deployments. Implementations should strive for
methods. The DNS64-based mechanism of [RFC7050] should be employed consistent PREF64 acquisition methods. The DNS64-based mechanism of
only when RA-based PREF64 delivery is unavailable or as a fallback [RFC7050] should be employed only when RA-based PREF64 delivery is
for legacy systems incapable of processing the PREF64 RA Option. unavailable or as a fallback for legacy systems incapable of
processing the PREF64 RA Option.
2. Terminology 2. Terminology
DNS64: A mechanism for synthesizing AAAA records from A records, DNS64: A mechanism for synthesizing AAAA records from A records,
defined in [RFC6147]. defined in [RFC6147].
NAT64: A mechanism for translating IPv6 packets to IPv4 packets, and NAT64: A mechanism for translating IPv6 packets to IPv4 packets, and
vice versa. The translation is done by translating the packet vice versa. The translation is done by translating the packet
headers according to the IP/ICMP Translation Algorithm defined in headers according to the IP/ICMP Translation Algorithm defined in
[RFC7915]. NAT64 translators can operate in stateful mode [RFC7915]. NAT64 translators can operate in stateful mode
[RFC6144] or stateless mode [RFC6877] (e.g., customer-side [RFC6144] or stateless mode [RFC6877] (e.g., customer-side
translator (CLAT)). This document uses "NAT64" as a generalized translator (CLAT)). This document uses "NAT64" as a generalized
term for a translator, which uses the stateless IP/ICMP term for a translator, which uses the stateless IP/ICMP
Translation Algorithm defined in [RFC7915] and operates within a Translation Algorithm defined in [RFC7915] and operates within a
framework for IPv4/IPv6 translation described in [RFC6144]. framework for IPv4/IPv6 translation described in [RFC6144].
PREF64 (Pref64::/n or NAT64 prefix): An IPv6 prefix used for IPv6 PREF64: Pref64::/n or NAT64 prefix. An IPv6 prefix used for IPv6
address synthesis and for translating network addresses and address synthesis [RFC6146].
protocols from IPv6 clients to IPv4 servers using the algorithm
defined in [RFC6052].
Router Advertisement (RA): A packet used by Neighbor Discovery RA: Router Advertisement. A packet used by Neighbor Discovery
[RFC4861] and SLAAC to advertise the presence of the routers, [RFC4861] and SLAAC to advertise the presence of the routers,
together with other IPv6 configuration information. together with other IPv6 configuration information.
SLAAC: Stateless Address Autoconfiguration [RFC4862]. SLAAC: Stateless Address Autoconfiguration [RFC4862].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Recommendations for PREF64 Discovery 3. Recommendations for PREF64 Discovery
3.1. Deployment Recommendations for Endpoints 3.1. Deployment Recommendations for Endpoints
Endpoints SHOULD attempt to obtain PREF64 information from RAs per Endpoints SHOULD attempt to obtain PREF64 information from RAs per
[RFC8781], instead of using the [RFC7050] method. In the absence of [RFC8781], instead of using the method described in [RFC7050]. In
the PREF64 information in RAs, an endpoint MAY choose to fall back to the absence of the PREF64 information in RAs, an endpoint MAY choose
the mechanism defined in [RFC7050]. This recommendation to prefer to fall back to the mechanism defined in [RFC7050]. This
the [RFC8781] mechanism over the one defined in [RFC7050] is recommendation to prefer the mechanism defined in [RFC8781] over the
consistent with Section 5.1 of [RFC8781]. one defined in [RFC7050] is consistent with Section 5.1 of [RFC8781].
3.2. Deployment Recommendations for Operators 3.2. Deployment Recommendations for Operators
Network operators deploying NAT64 SHOULD provide PREF64 information Network operators deploying NAT64 SHOULD provide PREF64 information
in Router Advertisements per [RFC8781]. in Router Advertisements per [RFC8781].
3.2.1. Mobile Network Considerations 3.2.1. Mobile Network Considerations
While [RFC8781] support is widely integrated into modern operating While support for the option specified in [RFC8781] is widely
systems on mobile endpoints, equipment deployed in mobile network integrated into modern operating systems on mobile endpoints,
environments often lacks abilities to include the PREF64 Option into equipment deployed in mobile network environments often lacks
RAs. Therefore, the immediate deployment and enablement of PREF64 by abilities to include the PREF64 Option into RAs. Therefore, the
mobile operators may not currently be feasible and the immediate deployment and enablement of PREF64 by mobile operators may
recommendations outlined in this document are not presently not currently be feasible and the recommendations outlined in this
applicable to mobile network operators. These environments are document are not presently applicable to mobile network operators.
encouraged to incorporate [RFC8781] when made practical by These environments are encouraged to incorporate the option specified
infrastructure upgrades or software stack feature additions. in [RFC8781] when made practical by infrastructure upgrades or
software stack feature additions.
3.2.2. Migration Considerations 3.2.2. Migration Considerations
Transitioning from the [RFC7050] heuristic to using the [RFC8781] Transitioning from the heuristic procedure in [RFC7050] to using the
approach might require a period of time where both mechanisms approach in [RFC8781] might require a period of time where both
coexist. How long this may take depends on the endpoint footprint, mechanisms coexist. How long this may take depends on the endpoint
particularly the presence and number of endpoints running outdated footprint, particularly the presence and number of endpoints running
operating systems that do not support [RFC8781]. Operators are outdated operating systems that do not support the option in
advised to take those factors into account prior to removing support [RFC8781]. Operators are advised to take those factors into account
for the [RFC7050] heuristic, noting that it is still safe to add prior to removing support for the heuristic procedure in [RFC7050],
support for the [RFC8781] approach since endpoints that support it noting that it is still safe to add support for the approach in
will always prefer it over [RFC7050] if they follow RFC requirements. [RFC8781] since endpoints that support it will always prefer it over
[RFC7050] if they follow RFC requirements.
Migrating away from DNS64-based discovery also reduces dependency on Migrating away from DNS64-based discovery also reduces dependency on
DNS64 in general, thereby eliminating DNSSEC and DNS64 DNS64 in general, thereby eliminating DNSSEC and DNS64
incompatibility concerns (Section 6.2 of [RFC6147]). incompatibility concerns (Section 6.2 of [RFC6147]).
4. Existing Issues with RFC 7050 4. Existing Issues with RFC 7050
DNS-based discovery of the NAT64 prefix introduces some challenges, DNS-based discovery of the NAT64 prefix introduces some challenges,
which make this approach less preferable than the latest developed which make this approach less preferable than the latest developed
alternatives (such as the PREF64 RA Option [RFC8781]). This section alternatives (such as the PREF64 RA Option [RFC8781]). This section
outlines the key issues associated with [RFC7050] with a focus on outlines the key issues associated with [RFC7050] with a focus on
those not discussed in [RFC7050] or in the analysis of solutions for those not discussed in [RFC7050] or in the analysis of solutions for
hosts to discover the NAT64 prefix [RFC7051]. hosts to discover the NAT64 prefix [RFC7051].
Signalling PREF64 in the RA option addresses all issues outlined in Signalling PREF64 in the RA Option addresses all issues outlined in
this section (see Section 3 of [RFC8781] for details). this section (see Section 3 of [RFC8781] for details).
4.1. Dependency on Network-Provided Recursive Resolvers 4.1. Dependency on Network-Provided Recursive Resolvers
Fundamentally, the presence of the NAT64 and the exact value of the The presence or absence of NAT64 functionality, as well as its
prefix used for the translation are network-specific attributes. associated prefix (if present), are network-dependent attributes.
Therefore, [RFC7050] requires the endpoint discovering the prefix to Therefore, [RFC7050] requires the endpoint discovering the prefix to
use the DNS64 resolvers provided by the network. If the device or an use the DNS64 resolvers provided by the network. If the device or an
application is configured to use other recursive resolvers or runs a application is configured to use other recursive resolvers or runs a
local recursive resolver, the corresponding name resolution APIs and local recursive resolver, the corresponding name resolution APIs and
libraries are required to recognize 'ipv4only.arpa.' as a special libraries are required to recognize 'ipv4only.arpa.' as a special
name and give it special treatment. This issue and remediation name and give it special treatment. This issue and remediation
approach are discussed in [RFC8880]. However, it has been observed approach are discussed in [RFC8880]. However, it has been observed
that very few [RFC7050] implementations support the [RFC8880] that very few implementations of the method described in [RFC7050]
requirements for special treatment of 'ipv4only.arpa.'. As a result, support the requirements specified in [RFC8880] for special treatment
configuring such systems and applications to use resolvers other than of 'ipv4only.arpa.'. As a result, configuring such systems and
the one provided by the network breaks the PREF64 discovery, leading applications to use resolvers other than the one provided by the
to degraded user experience. network breaks the PREF64 discovery, leading to degraded user
experience.
VPN applications may override the endpoint's DNS configuration, for VPN applications may override the endpoint's DNS configuration, for
example, by configuring enterprise DNS servers as the node's example, by configuring enterprise DNS servers as the node's
recursive resolvers and forcing all name resolution through the VPN. recursive resolvers and forcing all name resolution through the VPN.
These enterprise DNS servers typically lack DNS64 functionality and These enterprise DNS servers typically lack DNS64 functionality and
therefore cannot provide information about the PREF64 used within the therefore cannot provide information about the PREF64 used within the
local network. If the VPN is configured in so-called "split local network. If the VPN is configured in so-called "split
tunneling" mode (when only a subset of network traffic is routed into tunneling" mode (when only a subset of network traffic is routed into
the VPN tunnel), endpoints may not discover the necessary PREF64, the VPN tunnel), endpoints may not discover the necessary PREF64,
which negatively impacts their connectivity on IPv6-only networks. which negatively impacts their connectivity on IPv6-only networks.
If both the network-provided DNS64 and the endpoint's resolver happen If both the network-provided DNS64 and the endpoint's resolver happen
to utilize the Well-Known Prefix (64:ff9b::/96) [RFC6052], the to utilize the Well-Known Prefix (64:ff9b::/96) [RFC6052], the
endpoint would end up using a PREF64 that's valid for the current endpoint would end up using a PREF64 that's valid for the current
network. However, if the endpoint changes its network attachment, it network. However, if the endpoint changes its network attachment, it
can't detect if the new network lacks NAT64 entirely or uses a can't detect if the new network lacks NAT64 entirely or uses a
network-specific prefix (NSP) [RFC6144] for NAT64. network-specific prefix (NSP) [RFC6144] for NAT64.
Signalling PREF64 in an RA option decouples the PREF64 discovery from Signalling PREF64 in an RA Option decouples the PREF64 discovery from
the host's DNS resolver configuration. the host's DNS resolver configuration.
4.2. Network Stack Initialization Delay 4.2. Network Stack Initialization Delay
When using SLAAC, an IPv6 host typically requires a single RA to When using SLAAC, an IPv6 host typically requires a single RA to
acquire its network configuration. For IPv6-only endpoints, timely acquire its network configuration. For IPv6-only endpoints, timely
PREF64 discovery is critical, particularly for those performing local PREF64 discovery is critical, particularly for those performing local
DNS64 or NAT64 functions, such as CLAT [RFC6877]. Until a PREF64 is DNS64 or NAT64 functions, such as CLAT [RFC6877]. Until a PREF64 is
obtained, the endpoint's IPv4-only applications and communication to obtained, the endpoint's IPv4-only applications and communication to
IPv4-only destinations are impaired. The mechanism defined in IPv4-only destinations are impaired. The mechanism defined in
skipping to change at line 329 skipping to change at line 331
security challenges, which are discussed below. security challenges, which are discussed below.
4.5.1. Definition of Secure Channel 4.5.1. Definition of Secure Channel
[RFC7050] requires a node's communication channel with a DNS64 server [RFC7050] requires a node's communication channel with a DNS64 server
to be a "secure channel", which it defines to mean "a communication to be a "secure channel", which it defines to mean "a communication
channel a node has between itself and a DNS64 server protecting DNS channel a node has between itself and a DNS64 server protecting DNS
protocol-related messages from interception and tampering". This protocol-related messages from interception and tampering". This
need is redundant when another communication mechanism of need is redundant when another communication mechanism of
IPv6-related configuration, specifically RAs, can already be defended IPv6-related configuration, specifically RAs, can already be defended
against tampering, for example, by enabling RA-Guard [RFC6105]. against tampering, for example, by enabling RA-Guard [RFC6105]. When
Requiring nodes to implement two defense mechanisms when only one is the mechanism defined in [RFC8781] is used in place of the one
necessary when [RFC8781] is used in place of [RFC7050] creates an defined in [RFC7050], nodes only need to implement one defense
unnecessary risk. mechanism; requiring nodes to implement two defense mechanisms
creates an unnecessary risk.
4.5.2. Secure Channel Example of IPsec 4.5.2. Secure Channel Example of IPsec
One of the two examples that [RFC7050] defines to qualify a One of the two examples that [RFC7050] defines to qualify a
communication channel with a DNS64 server is the use of an "IPsec- communication channel with a DNS64 server is the use of an "IPsec-
based virtual private network (VPN) tunnel". As of the time of this based virtual private network (VPN) tunnel". As of the time of this
writing, this is not supported as a practice by any common operating writing, this is not supported as a practice by any common operating
system DNS client. While they could, there have also since been system DNS client. While they could, there have also since been
multiple mechanisms defined for performing DNS-specific encryption, multiple mechanisms defined for performing DNS-specific encryption,
such as those defined in [RFC9499], that would be more appropriately such as those defined in [RFC9499], that would be more appropriately
 End of changes. 12 change blocks. 
50 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.48.