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 and for translating network addresses and
	protocols from IPv6 clients to IPv4 servers using the algorithm		protocols from IPv6 clients to IPv4 servers using the algorithm
	defined in [RFC6052].		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 heurisitic 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 heurisitc 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		Fundamentally, the NAT64 function and the exact value of the prefix
	prefix used for the translation are network-specific attributes.		used for the translation are network-specific attributes. Therefore,
	Therefore, [RFC7050] requires the endpoint discovering the prefix to		[RFC7050] requires the endpoint discovering the prefix to use the
	use the DNS64 resolvers provided by the network. If the device or an		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 333 ¶
	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
	skipping to change at line 430 ¶		skipping to change at line 435 ¶
	[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.		[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
	Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,		Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
	DOI 10.17487/RFC6105, February 2011,		DOI 10.17487/RFC6105, February 2011,
	<https://www.rfc-editor.org/info/rfc6105>.		<https://www.rfc-editor.org/info/rfc6105>.
	[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for		[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
	IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144,		IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144,
	April 2011, <https://www.rfc-editor.org/info/rfc6144>.		April 2011, <https://www.rfc-editor.org/info/rfc6144>.
	[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/info/rfc6146>.
	[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van		[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
	Beijnum, "DNS64: DNS Extensions for Network Address		Beijnum, "DNS64: DNS Extensions for Network Address
	Translation from IPv6 Clients to IPv4 Servers", RFC 6147,		Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
	DOI 10.17487/RFC6147, April 2011,		DOI 10.17487/RFC6147, April 2011,
	<https://www.rfc-editor.org/info/rfc6147>.		<https://www.rfc-editor.org/info/rfc6147>.
	[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:		[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
	Combination of Stateful and Stateless Translation",		Combination of Stateful and Stateless Translation",
	RFC 6877, DOI 10.17487/RFC6877, April 2013,		RFC 6877, DOI 10.17487/RFC6877, April 2013,
	<https://www.rfc-editor.org/info/rfc6877>.		<https://www.rfc-editor.org/info/rfc6877>.
End of changes. 13 change blocks.
	54 lines changed or deleted		54 lines changed or added
This html diff was produced by rfcdiff 1.48.