Diff: rfc9872v2.txt - rfc9872.txt

	rfc9872v2.txt	rfc9872.txt

	skipping to change at line 135 ¶	skipping to change at line 135 ¶
	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].

	RA: Router Advertisement. 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

	skipping to change at line 182 ¶	skipping to change at line 180 ¶
	abilities to include the PREF64 Option into RAs. Therefore, the	abilities to include the PREF64 Option into RAs. Therefore, the
	immediate deployment and enablement of PREF64 by mobile operators may	immediate deployment and enablement of PREF64 by mobile operators may
	not currently be feasible and the recommendations outlined in this	not currently be feasible and the recommendations outlined in this
	document are not presently applicable to mobile network operators.	document are not presently applicable to mobile network operators.
	These environments are encouraged to incorporate the option specified	These environments are encouraged to incorporate the option specified
	in [RFC8781] when made practical by infrastructure upgrades or	in [RFC8781] when made practical by infrastructure upgrades or
	software stack feature additions.	software stack feature additions.

	3.2.2. Migration Considerations	3.2.2. Migration Considerations


	Transitioning from the heurisitic procedure in [RFC7050] to using the	Transitioning from the heuristic procedure in [RFC7050] to using the
	approach in [RFC8781] might require a period of time where both	approach in [RFC8781] might require a period of time where both
	mechanisms coexist. How long this may take depends on the endpoint	mechanisms coexist. How long this may take depends on the endpoint
	footprint, particularly the presence and number of endpoints running	footprint, particularly the presence and number of endpoints running
	outdated operating systems that do not support the option in	outdated operating systems that do not support the option in
	[RFC8781]. Operators are advised to take those factors into account	[RFC8781]. Operators are advised to take those factors into account

	prior to removing support for the heurisitc procedure in [RFC7050],	prior to removing support for the heuristic procedure in [RFC7050],
	noting that it is still safe to add support for the approach in	noting that it is still safe to add support for the approach in
	[RFC8781] since endpoints that support it will always prefer it over	[RFC8781] since endpoints that support it will always prefer it over
	[RFC7050] if they follow RFC requirements.	[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


	skipping to change at line 211 ¶	skipping to change at line 209 ¶
	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 NAT64 function and the exact value of the prefix	The presence or absence of NAT64 functionality, as well as its
	used for the translation are network-specific attributes. Therefore,	associated prefix (if present), are network-dependent attributes.
	[RFC7050] requires the endpoint discovering the prefix to use the	Therefore, [RFC7050] requires the endpoint discovering the prefix to
	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 implementations of the method described in [RFC7050]	that very few implementations of the method described in [RFC7050]
	support the requirements specified in [RFC8880] for special treatment	support the requirements specified in [RFC8880] for special treatment
	of 'ipv4only.arpa.'. As a result, configuring such systems and	of 'ipv4only.arpa.'. As a result, configuring such systems and
	applications to use resolvers other than the one provided by the	applications to use resolvers other than the one provided by the
	network breaks the PREF64 discovery, leading to degraded user	network breaks the PREF64 discovery, leading to degraded user

	skipping to change at line 435 ¶	skipping to change at line 433 ¶

	[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. 5 change blocks.
	9 lines changed or deleted	12 lines changed or added
This html diff was produced by rfcdiff 1.48.