draft-ietf-v6ops-nat64-deployment-03.txt		draft-ietf-v6ops-nat64-deployment-04.txt
	v6ops J. Palet Martinez		v6ops J. Palet Martinez
	Internet-Draft The IPv6 Company		Internet-Draft The IPv6 Company
	Intended status: Informational October 10, 2018		Intended status: Informational April 2, 2019
	Expires: April 13, 2019		Expires: October 4, 2019
	NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks		NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks
	draft-ietf-v6ops-nat64-deployment-03		draft-ietf-v6ops-nat64-deployment-04
	Abstract		Abstract
	This document describes how NAT64 and 464XLAT can be deployed in an		This document describes how NAT64 and 464XLAT can be deployed in an
	IPv6 network, whether cellular ISP, broadband ISP, or enterprise and		IPv6 network, whether cellular ISP, broadband ISP, or enterprise and
	the issues to be considered when having an IPv6-only access link,		the issues to be considered when having an IPv6-only access link,
	regarding: a) DNS64, b) applications or devices that use literal IPv4		regarding: a) DNS64, b) applications or devices that use literal IPv4
	addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or		addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or
	applications.		applications.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 13, 2019.		This Internet-Draft will expire on October 4, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 38 ¶		skipping to change at page 2, line 38 ¶
	4.1.6. Mapping-out IPv4 addresses . . . . . . . . . . . . . 19		4.1.6. Mapping-out IPv4 addresses . . . . . . . . . . . . . 19
	4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 19		4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 19
	4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 20		4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 20
	4.4. Manual Configuration of Foreign DNS . . . . . . . . . . . 21		4.4. Manual Configuration of Foreign DNS . . . . . . . . . . . 21
	4.5. DNS Privacy . . . . . . . . . . . . . . . . . . . . . . . 21		4.5. DNS Privacy . . . . . . . . . . . . . . . . . . . . . . . 21
	4.6. Split DNS . . . . . . . . . . . . . . . . . . . . . . . . 21		4.6. Split DNS . . . . . . . . . . . . . . . . . . . . . . . . 21
	4.7. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 22		4.7. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 22
	4.8. IPv4 literals and old APIs . . . . . . . . . . . . . . . 22		4.8. IPv4 literals and old APIs . . . . . . . . . . . . . . . 22
	4.9. IPv4-only Hosts or Applications . . . . . . . . . . . . . 23		4.9. IPv4-only Hosts or Applications . . . . . . . . . . . . . 23
	4.10. CLAT Translation Considerations . . . . . . . . . . . . . 23		4.10. CLAT Translation Considerations . . . . . . . . . . . . . 23
	5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 23		4.11. EAMT Considerations . . . . . . . . . . . . . . . . . . . 23
	6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 26		5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 24
			6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 27
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 28		7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
	10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 28		10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 29
	11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 32		11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 32
	12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 32		12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 33
	13. ANNEX D: Changes from -00 and -01 . . . . . . . . . . . . . . 32		13. ANNEX D: Changes from -00 to -01 . . . . . . . . . . . . . . 33
	14. ANNEX D: Changes from -01 and -02 . . . . . . . . . . . . . . 32		14. ANNEX E: Changes from -01 to -02 . . . . . . . . . . . . . . 33
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 33		15. ANNEX F: Changes from -02 to -03 . . . . . . . . . . . . . . 33
	15.1. Normative References . . . . . . . . . . . . . . . . . . 33		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
	15.2. Informative References . . . . . . . . . . . . . . . . . 34		16.1. Normative References . . . . . . . . . . . . . . . . . . 34
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 36		16.2. Informative References . . . . . . . . . . . . . . . . . 36
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 37
	1. Introduction		1. Introduction
	NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation		NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation
	mechanism, which allows IPv6-only hosts to communicate with IPv4-only		mechanism, which allows IPv6-only hosts to communicate with IPv4-only
	servers using unicast UDP, TCP or ICMP, by means of IPv4 public		servers using unicast UDP, TCP or ICMP, by means of IPv4 public
	addresses sharing (assigned to the translator), among multiple		addresses sharing (assigned to the translator), among multiple
	IPv6-only hosts.		IPv6-only hosts.
	The translation of the packet headers is done using the IP/ICMP		The translation of the packet headers is done using the IP/ICMP
	skipping to change at page 18, line 20 ¶		skipping to change at page 18, line 20 ¶
	ipv4only.arpa. A 192.0.0.171		ipv4only.arpa. A 192.0.0.171
	An alternative option to the above, is the use of DNS RPZ (Response		An alternative option to the above, is the use of DNS RPZ (Response
	Policy Zones).		Policy Zones).
	One more alternative, only valid in environments with PCP support		One more alternative, only valid in environments with PCP support
	(for both the hosts or CEs and for the service provider network), to		(for both the hosts or CEs and for the service provider network), to
	follow [RFC7225] (Discovering NAT64 IPv6 Prefixes using PCP).		follow [RFC7225] (Discovering NAT64 IPv6 Prefixes using PCP).
	Other alternatives may be available in the future, such as Router		Other alternatives may be available in the future, such as Router
	Advertising ([I-D.pref64folks-6man-ra-pref64]) or DHCPv6 options.		Advertising ([I-D.ietf-6man-ra-pref64]) or DHCPv6 options.
	It may be convenient to support at the same time several of the		It may be convenient to support at the same time several of the
	approaches described, in order to ensure that clients with different		approaches described, in order to ensure that clients with different
	ways to configure the NAT64 prefix, successfully obtain it. This is		ways to configure the NAT64 prefix, successfully obtain it. This is
	also convenient even if DNS64 is being used.		also convenient even if DNS64 is being used.
	4.1.2. DNSSEC validator aware of DNS64		4.1.2. DNSSEC validator aware of DNS64
	In general, DNS servers with DNS64 function, by default, will not		In general, DNS servers with DNS64 function, by default, will not
	synthesize AAAA responses if the DNSSEC OK (DO) flag was set in the		synthesize AAAA responses if the DNSSEC OK (DO) flag was set in the
	skipping to change at page 18, line 44 ¶		skipping to change at page 18, line 44 ¶
	not broken. However, this will not work if a CLAT is not present as		not broken. However, this will not work if a CLAT is not present as
	the hosts will not be able to use IPv4 (scenarios without 464XLAT).		the hosts will not be able to use IPv4 (scenarios without 464XLAT).
	4.1.3. Stub validator		4.1.3. Stub validator
	If the DO flag is set and the client device performs DNSSEC		If the DO flag is set and the client device performs DNSSEC
	validation, and the Checking Disabled (CD) flag is set for a query,		validation, and the Checking Disabled (CD) flag is set for a query,
	as the DNS64 recursive server will not synthesize AAAA responses, the		as the DNS64 recursive server will not synthesize AAAA responses, the
	client could perform the DNSSEC validation with the A record and then		client could perform the DNSSEC validation with the A record and then
	may query the network for a NAT64 prefix ([RFC7050], [RFC7225],		may query the network for a NAT64 prefix ([RFC7050], [RFC7225],
	[I-D.pref64folks-6man-ra-pref64] or other methods) in order to		[I-D.ietf-6man-ra-pref64] or other methods) in order to synthesize
	synthesize the AAAA ([RFC6052]). This allow the client device to		the AAAA ([RFC6052]). This allow the client device to avoid using
	avoid using the CLAT and still use NAT64 even with DNSSEC.		the CLAT and still use NAT64 even with DNSSEC.
	If the end-host is IPv4-only, this will not work if a CLAT is not		If the end-host is IPv4-only, this will not work if a CLAT is not
	present (scenarios without 464XLAT), unless the client is able to		present (scenarios without 464XLAT), unless the client is able to
	locally perform the address synthesis.		locally perform the address synthesis.
	Some devices/OSs may implement, instead of CLAT, a similar function		Some devices/OSs may implement, instead of CLAT, a similar function
	by using Bump-in-the-Host ([RFC6535]), implemented as part of Happy		by using Bump-in-the-Host ([RFC6535]), implemented as part of Happy
	Eyeballs v2 (Section 7.1 of [RFC8305]). In this case, the		Eyeballs v2 (Section 7.1 of [RFC8305]). In this case, the
	considerations in the above paragraphs are also applicable.		considerations in the above paragraphs are also applicable.
	skipping to change at page 21, line 38 ¶		skipping to change at page 21, line 38 ¶
	However, it needs to be reinforced, that if there is not a CLAT		However, it needs to be reinforced, that if there is not a CLAT
	(scenarios without 464XLAT), an external DNS without DNS64 support,		(scenarios without 464XLAT), an external DNS without DNS64 support,
	will disallow any access to IPv4-only networks, and will not		will disallow any access to IPv4-only networks, and will not
	guarantee DNSSEC, so will behave as in the Section 3.2.1.		guarantee DNSSEC, so will behave as in the Section 3.2.1.
	4.5. DNS Privacy		4.5. DNS Privacy
	If clients use mechanisms for DNS privacy, such as DNS over TLS		If clients use mechanisms for DNS privacy, such as DNS over TLS
	([RFC7858]), DNS over DTLS ([RFC8094]), DNS queries over HTTPS		([RFC7858]), DNS over DTLS ([RFC8094]), DNS queries over HTTPS
	([I-D.ietf-doh-dns-over-https]) or DNS over QUIC		([RFC8484]) or DNS over QUIC ([I-D.huitema-quic-dnsoquic]), as they
	([I-D.huitema-quic-dnsoquic]), as they may provide different results		may provide different results to the same query, it must be expected
	to the same query, it must be expected equivalent effects as		equivalent effects as described in Section 4.4.
	described in Section 4.4.
	4.6. Split DNS		4.6. Split DNS
	As already indicated in precedent sections, the successful use of the		As already indicated in precedent sections, the successful use of the
	DNS64 is not guaranteed when networks or hosts can use "split-DNS"		DNS64 is not guaranteed when networks or hosts can use "split-DNS"
	(also called Split Horizon), private DNS. Section 4. of [RFC6950],		(also called Split Horizon), private DNS. Section 4. of [RFC6950],
	analyses this case. This a very common situation when using VPNs.		analyses this case. This a very common situation when using VPNs.
	4.7. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP)		4.7. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP)
	skipping to change at page 23, line 29 ¶		skipping to change at page 23, line 29 ¶
	However, if this dedicated prefix is not available, the CLAT will		However, if this dedicated prefix is not available, the CLAT will
	need to do a stateful translation, for example performing stateful		need to do a stateful translation, for example performing stateful
	NAT44 for all the IPv4 LAN packets, so they appear as coming from a		NAT44 for all the IPv4 LAN packets, so they appear as coming from a
	single IPv4 address, and then in turn, stateless translated to a		single IPv4 address, and then in turn, stateless translated to a
	single IPv6 address.		single IPv6 address.
	One possible setup, in order to maximize the CLAT performance, is to		One possible setup, in order to maximize the CLAT performance, is to
	configure the dedicated translation prefix. This can be easily		configure the dedicated translation prefix. This can be easily
	achieved automatically, if the broadband CE or end-user device is		achieved automatically, if the broadband CE or end-user device is
	able to obtain a shorter prefix by means of DHCPv6-PD ([RFC3633]), or		able to obtain a shorter prefix by means of DHCPv6-PD ([RFC8415]), or
	other alternatives, so the CE can use a specific /64 for the		other alternatives, so the CE can use a specific /64 for the
	translation. This is also possible when broadband is provided by a		translation. This is also possible when broadband is provided by a
	cellular access.		cellular access.
	The above recommendation is often not possible for cellular networks,		The above recommendation is often not possible for cellular networks,
	when connecting smartphones (as UEs), as generally they don't use		when connecting smartphones (as UEs), as generally they don't use
	DHCPv6-PD ([RFC3633]) an instead a single /64 is provided for each		DHCPv6-PD ([RFC8415]) an instead a single /64 is provided for each
	PDP context and use /64 prefix sharing ([RFC6877]). So, in this		PDP context and use /64 prefix sharing ([RFC6877]). So, in this
	case, the UEs typically have a build-in CLAT client, which is doing a		case, the UEs typically have a build-in CLAT client, which is doing a
	stateful NAT44 before the stateless NAT46.		stateful NAT44 before the stateless NAT46.
			4.11. EAMT Considerations
			Explicit Address Mappings for Stateless IP/ICMP Translation [RFC7757]
			provides a way to configure explicit mappings between IPv4 and IPv6
			prefixes of any length. When this is used, for example in a CLAT, it
			may provide a simple mechanism in order to avoid traffic flows
			between IPv4-only nodes or applications and dual-stack destinations
			to be translated twice (NAT46 and NAT64), by creating mapping entries
			with the GUA of the IPv6-reachable destination. This optimization of
			the NAT64 usage is very useful in many scenarios, including CDNs and
			caches, as described in [I-D.palet-v6ops-464xlat-opt-cdn-caches].
	5. Summary of Deployment Recommendations for NAT64/464XLAT		5. Summary of Deployment Recommendations for NAT64/464XLAT
	It can be argued that none of the possible transition mechanisms is		It can be argued that none of the possible transition mechanisms is
	perfect, and somehow, we may consider that actually this is a good		perfect, and somehow, we may consider that actually this is a good
	thing as a way to push for the IPv6 deployment, or otherwise, it may		thing as a way to push for the IPv6 deployment, or otherwise, it may
	be further delayed, with clear undesirable effects for the global		be further delayed, with clear undesirable effects for the global
	Internet.		Internet.
	However, for an operator, being in business means minimizing the		However, for an operator, being in business means minimizing the
	adverse transition effects, and provide the most perfect one,		adverse transition effects, and provide the most perfect one,
	skipping to change at page 25, line 29 ¶		skipping to change at page 25, line 42 ¶
	Similar considerations need to be taken regarding the usage of a		Similar considerations need to be taken regarding the usage of a
	NAT64 Well-Known-Prefix (WKP) vs Network-Specific Prefix (NSP)		NAT64 Well-Known-Prefix (WKP) vs Network-Specific Prefix (NSP)
	(Section 4.7), in the sense of, if using DNS64, they must match and,		(Section 4.7), in the sense of, if using DNS64, they must match and,
	if the user can change the DNS configuration, they will, most		if the user can change the DNS configuration, they will, most
	probably, not match. If there is a CLAT and the users chosen DNS is		probably, not match. If there is a CLAT and the users chosen DNS is
	not a DNS64, the network will keep working of other means of learning		not a DNS64, the network will keep working of other means of learning
	the NAT64 are available.		the NAT64 are available.
	As described in Section 4.10 in broadband networks, it is recommended		As described in Section 4.10 in broadband networks, it is recommended
	that CEs supporting CLAT, supports DHCPv6-PD ([RFC3633]), or		that CEs supporting CLAT, supports DHCPv6-PD ([RFC8415]), or
	alternative means for configuring a shorter prefix, and internally		alternative means for configuring a shorter prefix, and internally
	reserve one /64 for the stateless NAT46 translation. The operator		reserve one /64 for the stateless NAT46 translation. The operator
	must ensure that the customers get allocated prefixes shorter than		must ensure that the customers get allocated prefixes shorter than
	/64 in order to support this optimization. One way or the other,		/64 in order to support this optimization. One way or the other,
	this is not impacting the performance of the operator network.		this is not impacting the performance of the operator network.
	Operators may follow Section 7 of [RFC6877] (Deployment		Operators may follow Section 7 of [RFC6877] (Deployment
	Considerations), for suggestions in order to take advantage of		Considerations), for suggestions in order to take advantage of
	traffic engineering requirements.		traffic engineering requirements.
	skipping to change at page 26, line 33 ¶		skipping to change at page 26, line 46 ¶
	avoiding the cases where DNSSEC may be broken. However, this will		avoiding the cases where DNSSEC may be broken. However, this will
	not solve the issues related to DNS Privacy and Split DNS.		not solve the issues related to DNS Privacy and Split DNS.
	The only 100% safe solution, which also resolves all the issues, will		The only 100% safe solution, which also resolves all the issues, will
	be, in addition to having a CLAT, not using a DNS64 but instead		be, in addition to having a CLAT, not using a DNS64 but instead
	making sure that the hosts have a built-in address synthesis feature.		making sure that the hosts have a built-in address synthesis feature.
	Operators could manage to use the CLAT, however the built-in address		Operators could manage to use the CLAT, however the built-in address
	synthesis feature is out of their control, and can only be resolved		synthesis feature is out of their control, and can only be resolved
	by operating system vendors.		by operating system vendors.
			Whenever feasible, using EAMT ([RFC7757]) as indicated in
			Section 4.11, provides a very relevant optimization, avoiding double-
			translations.
	6. Deployment of NAT64 in Enterprise Networks		6. Deployment of NAT64 in Enterprise Networks
	The recommendations of this document can be used as well in		The recommendations of this document can be used as well in
	enterprise networks, campus and other similar scenarios (including		enterprise networks, campus and other similar scenarios (including
	managed end-user networks).		managed end-user networks).
	This include scenarios where the NAT64 (and/or DNS64) are under the		This include scenarios where the NAT64 (and/or DNS64) are under the
	control of that network (or can be configured manually according to		control of that network (or can be configured manually according to
	that network specific requirements), and for whatever reasons, there		that network specific requirements), and for whatever reasons, there
	is a need to provide "IPv6-only access" to any part of that network		is a need to provide "IPv6-only access" to any part of that network
	skipping to change at page 29, line 44 ¶		skipping to change at page 30, line 30 ¶
	Figure 17: CE setup with built-in CLAT with DNS64		Figure 17: CE setup with built-in CLAT with DNS64
	In addition to the regular CE setup, which will be typically access-		In addition to the regular CE setup, which will be typically access-
	technology dependent, the steps for the CLAT configuration can be		technology dependent, the steps for the CLAT configuration can be
	summarized as:		summarized as:
	1. Discovery of the PLAT (NAT64) prefix: It may be done using		1. Discovery of the PLAT (NAT64) prefix: It may be done using
	[RFC7050], or in those networks where PCP is supported, by means		[RFC7050], or in those networks where PCP is supported, by means
	of [RFC7225], or other alternatives that may be available in the		of [RFC7225], or other alternatives that may be available in the
	future, such as Router Advertising		future, such as Router Advertising ([I-D.ietf-6man-ra-pref64]) or
	([I-D.pref64folks-6man-ra-pref64]) or DHCPv6 options.		DHCPv6 options.
	2. If the CLAT allows stateless NAT46 translation, a /64 from the		2. If the CLAT allows stateless NAT46 translation, a /64 from the
	pool typically provided to the CE by means of DHCPv6-PD		pool typically provided to the CE by means of DHCPv6-PD
	[RFC3633], need to be set aside for that translation. Otherwise,		[RFC8415], need to be set aside for that translation. Otherwise,
	the CLAT is forced to perform an intermediate stateful NAT44		the CLAT is forced to perform an intermediate stateful NAT44
	before the a stateless NAT46, as described in Section 4.10.		before the a stateless NAT46, as described in Section 4.10.
	A more detailed configuration approach is described in		A more detailed configuration approach is described in
	[I-D.ietf-v6ops-transition-ipv4aas].		[I-D.ietf-v6ops-transition-ipv4aas].
	The operator network needs to ensure that the correct responses are		The operator network needs to ensure that the correct responses are
	provided for the discovery of the PLAT prefix, as well as it is		provided for the discovery of the PLAT prefix, as well as it is
	highly recommended follows [RIPE-690], in order to ensure that		highly recommended follows [RIPE-690], in order to ensure that
	multiple /64s are available including the one needed for the NAT46		multiple /64s are available including the one needed for the NAT46
	skipping to change at page 32, line 16 ¶		skipping to change at page 33, line 7 ¶
	In addition to the regular set of features for a CE, a CLAT CE		In addition to the regular set of features for a CE, a CLAT CE
	implementation requires support of:		implementation requires support of:
	o [RFC7915], for the NAT46 functionality.		o [RFC7915], for the NAT46 functionality.
	o [RFC7050], for the PLAT prefix discovery.		o [RFC7050], for the PLAT prefix discovery.
	o [RFC7225], for the PLAT prefix discovery if PCP is supported.		o [RFC7225], for the PLAT prefix discovery if PCP is supported.
	o [I-D.pref64folks-6man-ra-pref64], for the PLAT prefix discovery by		o [I-D.ietf-6man-ra-pref64], for the PLAT prefix discovery by means
	means of Router Advertising.		of Router Advertising.
	o If stateless NAT46 is supported, a mechanism to ensure that		o If stateless NAT46 is supported, a mechanism to ensure that
	multiple /64 are available, such as DHCPv6-PD [RFC3633].		multiple /64 are available, such as DHCPv6-PD [RFC8415].
	There are several OpenSource implementations of CLAT, such as:		There are several OpenSource implementations of CLAT, such as:
	o Android: https://github.com/ddrown/android_external_android-clat.		o Android: https://github.com/ddrown/android_external_android-clat.
	o Linux: https://github.com/toreanderson/clatd.		o Linux: https://github.com/toreanderson/clatd.
	o OpenWRT: https://github.com/openwrt-		o OpenWRT: https://github.com/openwrt-
	routing/packages/blob/master/nat46/files/464xlat.sh.		routing/packages/blob/master/nat46/files/464xlat.sh.
	o VPP: https://git.fd.io/vpp/tree/src/plugins/nat.		o VPP: https://git.fd.io/vpp/tree/src/plugins/nat.
	12. ANNEX C: Benchmarking		12. ANNEX C: Benchmarking
	Several documents provide references to benchmarking, for example in		Several documents provide references to benchmarking, for example in
	the case of DNS64, [DNS64-Benchm].		the case of DNS64, [DNS64-Benchm].
	13. ANNEX D: Changes from -00 and -01		13. ANNEX D: Changes from -00 to -01
	Section to be removed for WGLC. Significant updates are:		Section to be removed after WGLC. Significant updates are:
	1. Text changes across all the document.		1. Text changes across all the document.
	14. ANNEX D: Changes from -01 and -02		14. ANNEX E: Changes from -01 to -02
	Section to be removed for WGLC. Significant updates are:		Section to be removed after WGLC. Significant updates are:
	1. Added references to new cited documents.		1. Added references to new cited documents.
	2. Reference to RFC8273 and on-demand IPv4-in-IPv6 VPN for IPv6-only		2. Reference to RFC8273 and on-demand IPv4-in-IPv6 VPN for IPv6-only
	LANs w/o DNS64.		LANs w/o DNS64.
	3. Overall review and editorial changes.		3. Overall review and editorial changes.
	15. References		15. ANNEX F: Changes from -02 to -03
	15.1. Normative References		Section to be removed after WGLC. Significant updates are:
			1. Added text related to EAMT considerations.
			16. References
			16.1. Normative References
	[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,		[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
	and E. Lear, "Address Allocation for Private Internets",		and E. Lear, "Address Allocation for Private Internets",
	BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,		BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
	<https://www.rfc-editor.org/info/rfc1918>.		<https://www.rfc-editor.org/info/rfc1918>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
	Host Configuration Protocol (DHCP) version 6", RFC 3633,
	DOI 10.17487/RFC3633, December 2003,
	<https://www.rfc-editor.org/info/rfc3633>.
	[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.		[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
	Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,		Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
	DOI 10.17487/RFC6052, October 2010,		DOI 10.17487/RFC6052, October 2010,
	<https://www.rfc-editor.org/info/rfc6052>.		<https://www.rfc-editor.org/info/rfc6052>.
	[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		[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
	skipping to change at page 34, line 25 ¶		skipping to change at page 35, line 15 ¶
	[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of		[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
	the IPv6 Prefix Used for IPv6 Address Synthesis",		the IPv6 Prefix Used for IPv6 Address Synthesis",
	RFC 7050, DOI 10.17487/RFC7050, November 2013,		RFC 7050, DOI 10.17487/RFC7050, November 2013,
	<https://www.rfc-editor.org/info/rfc7050>.		<https://www.rfc-editor.org/info/rfc7050>.
	[RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the		[RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the
	Port Control Protocol (PCP)", RFC 7225,		Port Control Protocol (PCP)", RFC 7225,
	DOI 10.17487/RFC7225, May 2014,		DOI 10.17487/RFC7225, May 2014,
	<https://www.rfc-editor.org/info/rfc7225>.		<https://www.rfc-editor.org/info/rfc7225>.
			[RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address
			Mappings for Stateless IP/ICMP Translation", RFC 7757,
			DOI 10.17487/RFC7757, February 2016,
			<https://www.rfc-editor.org/info/rfc7757>.
	[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,		[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
	"IP/ICMP Translation Algorithm", RFC 7915,		"IP/ICMP Translation Algorithm", RFC 7915,
	DOI 10.17487/RFC7915, June 2016,		DOI 10.17487/RFC7915, June 2016,
	<https://www.rfc-editor.org/info/rfc7915>.		<https://www.rfc-editor.org/info/rfc7915>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix		[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
	skipping to change at page 34, line 47 ¶		skipping to change at page 35, line 42 ¶
	[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:		[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
	Better Connectivity Using Concurrency", RFC 8305,		Better Connectivity Using Concurrency", RFC 8305,
	DOI 10.17487/RFC8305, December 2017,		DOI 10.17487/RFC8305, December 2017,
	<https://www.rfc-editor.org/info/rfc8305>.		<https://www.rfc-editor.org/info/rfc8305>.
	[RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain		[RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain
	'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018,		'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018,
	<https://www.rfc-editor.org/info/rfc8375>.		<https://www.rfc-editor.org/info/rfc8375>.
	15.2. Informative References		[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
			Richardson, M., Jiang, S., Lemon, T., and T. Winters,
			"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
			RFC 8415, DOI 10.17487/RFC8415, November 2018,
			<https://www.rfc-editor.org/info/rfc8415>.
			[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
			(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
			<https://www.rfc-editor.org/info/rfc8484>.
			16.2. Informative References
	[About-DNS64]		[About-DNS64]
	J. Linkova, "Let's talk about IPv6 DNS64 & DNSSEC", 2016,		APNIC Blog, "Let's talk about IPv6 DNS64 & DNSSEC", 2016,
	<https://blog.apnic.net/2016/06/09/		<https://blog.apnic.net/2016/06/09/
	lets-talk-ipv6-dns64-dnssec/>.		lets-talk-ipv6-dns64-dnssec/>.
	[DNS64-Benchm]		[DNS64-Benchm]
	G. Lencse and Y. Kadobayashi, "Benchmarking DNS64		"Benchmarking DNS64 Implementations: Theory and Practice",
	Implementations: Theory and Practice", Computer		Computer Communications (Elsevier), vol. 127, no. 1,
	Communications (Elsevier), vol. 127, no. 1, pp. 61-74,		pp. 61-74, DOI 10.1016/j.comcom.2018.05.005, September
	DOI 10.1016/j.comcom.2018.05.005, September 2018.		2018.
	[I-D.bp-v6ops-ipv6-ready-dns-dnssec]		[I-D.bp-v6ops-ipv6-ready-dns-dnssec]
	Byrne, C. and J. Palet, "IPv6-Ready DNS/DNSSSEC		Byrne, C. and J. Palet, "IPv6-Ready DNS/DNSSSEC
	Infrastructure", draft-bp-v6ops-ipv6-ready-dns-dnssec-00		Infrastructure", draft-bp-v6ops-ipv6-ready-dns-dnssec-00
	(work in progress), October 2018.		(work in progress), October 2018.
	[I-D.huitema-quic-dnsoquic]		[I-D.huitema-quic-dnsoquic]
	Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J.		Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J.
	Iyengar, "Specification of DNS over Dedicated QUIC		Iyengar, "Specification of DNS over Dedicated QUIC
	Connections", draft-huitema-quic-dnsoquic-05 (work in		Connections", draft-huitema-quic-dnsoquic-06 (work in
	progress), June 2018.		progress), March 2019.
	[I-D.ietf-doh-dns-over-https]		[I-D.ietf-6man-ra-pref64]
	Hoffman, P. and P. McManus, "DNS Queries over HTTPS		Colitti, L., Kline, E., and J. Linkova, "Discovering
	(DoH)", draft-ietf-doh-dns-over-https-14 (work in		PREF64 in Router Advertisements", draft-ietf-6man-ra-
	progress), August 2018.		pref64-00 (work in progress), March 2019.
	[I-D.ietf-v6ops-transition-ipv4aas]		[I-D.ietf-v6ops-transition-ipv4aas]
	Palet, J., Liu, H., and M. Kawashima, "Requirements for		Palet, J., Liu, H., and M. Kawashima, "Requirements for
	IPv6 Customer Edge Routers to Support IPv4 Connectivity		IPv6 Customer Edge Routers to Support IPv4 Connectivity
	as-a-Service", draft-ietf-v6ops-transition-ipv4aas-09		as-a-Service", draft-ietf-v6ops-transition-ipv4aas-15
	(work in progress), October 2018.		(work in progress), January 2019.
	[I-D.pref64folks-6man-ra-pref64]		[I-D.palet-v6ops-464xlat-opt-cdn-caches]
	Colitti, L., Kline, E., and J. Linkova, "Discovering		Palet, J. and A. D'Egidio, "464XLAT Optimization for CDNs/
	PREF64 in Router Advertisements", draft-pref64folks-6man-		Caches", draft-palet-v6ops-464xlat-opt-cdn-caches-01 (work
	ra-pref64-02 (work in progress), October 2018.		in progress), March 2019.
	[RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba,		[RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba,
	"Architectural Considerations on Application Features in		"Architectural Considerations on Application Features in
	the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013,		the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013,
	<https://www.rfc-editor.org/info/rfc6950>.		<https://www.rfc-editor.org/info/rfc6950>.
	[RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64		[RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64
	Deployment Options and Experience", RFC 7269,		Deployment Options and Experience", RFC 7269,
	DOI 10.17487/RFC7269, June 2014,		DOI 10.17487/RFC7269, June 2014,
	<https://www.rfc-editor.org/info/rfc7269>.		<https://www.rfc-editor.org/info/rfc7269>.
	skipping to change at page 36, line 17 ¶		skipping to change at page 37, line 27 ¶
	DOI 10.17487/RFC8094, February 2017,		DOI 10.17487/RFC8094, February 2017,
	<https://www.rfc-editor.org/info/rfc8094>.		<https://www.rfc-editor.org/info/rfc8094>.
	[RIPE-690]		[RIPE-690]
	RIPE, "Best Current Operational Practice for Operators:		RIPE, "Best Current Operational Practice for Operators:
	IPv6 prefix assignment for end-users - persistent vs non-		IPv6 prefix assignment for end-users - persistent vs non-
	persistent, and what size to choose", October 2017,		persistent, and what size to choose", October 2017,
	<https://www.ripe.net/publications/docs/ripe-690>.		<https://www.ripe.net/publications/docs/ripe-690>.
	[Threat-DNS64]		[Threat-DNS64]
	G. Lencse and Y. Kadobayashi, "Methodology for the		"Methodology for the identification of potential security
	identification of potential security issues of different		issues of different IPv6 transition technologies: Threat
	IPv6 transition technologies: Threat analysis of DNS64 and		analysis of DNS64 and stateful NAT64", Computers &
	stateful NAT64", Computers & Security (Elsevier), vol. 77,		Security (Elsevier), vol. 77, no. 1, pp. 397-411,
	no. 1, pp. 397-411, DOI 10.1016/j.cose.2018.04.012, August		DOI 10.1016/j.cose.2018.04.012, August 2018.
	2018.
	Author's Address		Author's Address
	Jordi Palet Martinez		Jordi Palet Martinez
	The IPv6 Company		The IPv6 Company
	Molino de la Navata, 75		Molino de la Navata, 75
	La Navata - Galapagar, Madrid 28420		La Navata - Galapagar, Madrid 28420
	Spain		Spain
	Email: jordi.palet@theipv6company.com		Email: jordi.palet@theipv6company.com
End of changes. 35 change blocks.
	67 lines changed or deleted		99 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/