draft-ietf-v6ops-nat64-deployment-05.txt		draft-ietf-v6ops-nat64-deployment-06.txt
	v6ops J. Palet Martinez		v6ops J. Palet Martinez
	Internet-Draft The IPv6 Company		Internet-Draft The IPv6 Company
	Intended status: Informational April 19, 2019		Intended status: Informational May 4, 2019
	Expires: October 21, 2019		Expires: November 5, 2019
	Additional NAT64/464XLAT Deployment Guidelines in Operator and		Additional NAT64/464XLAT Deployment Guidelines in Operator and
	Enterprise Networks		Enterprise Networks
	draft-ietf-v6ops-nat64-deployment-05		draft-ietf-v6ops-nat64-deployment-06
	Abstract		Abstract
	This document describes how NAT64 (including 464XLAT) can be deployed		This document describes how NAT64 (including 464XLAT) can be deployed
	in an IPv6 network, whether cellular ISP, broadband ISP, or		in an IPv6 network, whether cellular ISP, broadband ISP, or
	enterprise, and possible optimizations. The document also discusses		enterprise, and possible optimizations. The document also discusses
	issues to be considered when having IPv6-only connectivity,		issues to be considered when having IPv6-only connectivity,
	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 37 ¶		skipping to change at page 1, line 37 ¶
	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 October 21, 2019.		This Internet-Draft will expire on November 5, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 41 ¶
	4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 22		4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 22
	4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 22		4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 22
	4.4. Foreign DNS . . . . . . . . . . . . . . . . . . . . . . . 23		4.4. Foreign DNS . . . . . . . . . . . . . . . . . . . . . . . 23
	4.4.1. Manual Configuration of Foreign DNS . . . . . . . . . 24		4.4.1. Manual Configuration of Foreign DNS . . . . . . . . . 24
	4.4.2. DNS Privacy . . . . . . . . . . . . . . . . . . . . . 24		4.4.2. DNS Privacy . . . . . . . . . . . . . . . . . . . . . 24
	4.4.3. Split DNS . . . . . . . . . . . . . . . . . . . . . . 25		4.4.3. Split DNS . . . . . . . . . . . . . . . . . . . . . . 25
	4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 25		4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 25
	4.6. IPv4 literals and old APIs . . . . . . . . . . . . . . . 25		4.6. IPv4 literals and old APIs . . . . . . . . . . . . . . . 25
	4.7. IPv4-only Hosts or Applications . . . . . . . . . . . . . 26		4.7. IPv4-only Hosts or Applications . . . . . . . . . . . . . 26
	4.8. CLAT Translation Considerations . . . . . . . . . . . . . 26		4.8. CLAT Translation Considerations . . . . . . . . . . . . . 26
	4.9. EAMT Considerations . . . . . . . . . . . . . . . . . . . 27		4.9. EAM Considerations . . . . . . . . . . . . . . . . . . . 27
			4.10. Incoming Connections . . . . . . . . . . . . . . . . . . 27
	5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 27		5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 27
	6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 30		6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 30
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 31		7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
	10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 32		10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 32
	11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 36		11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 36
	12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 36		12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 37
	13. ANNEX D: Changes from -00 to -01/-02 . . . . . . . . . . . . 36		13. ANNEX D: Changes from -00 to -01/-02 . . . . . . . . . . . . 37
	14. ANNEX E: Changes from -02 to -03 . . . . . . . . . . . . . . 37		14. ANNEX E: Changes from -02 to -03 . . . . . . . . . . . . . . 37
	15. ANNEX F: Changes from -03 to -04 . . . . . . . . . . . . . . 37		15. ANNEX F: Changes from -03 to -04 . . . . . . . . . . . . . . 38
	16. ANNEX G: Changes from -04 to -05 . . . . . . . . . . . . . . 37		16. ANNEX G: Changes from -04 to -05 . . . . . . . . . . . . . . 38
	17. References . . . . . . . . . . . . . . . . . . . . . . . . . 37		17. ANNEX H: Changes from -05 to -06 . . . . . . . . . . . . . . 38
	17.1. Normative References . . . . . . . . . . . . . . . . . . 37		18. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
	17.2. Informative References . . . . . . . . . . . . . . . . . 39		18.1. Normative References . . . . . . . . . . . . . . . . . . 38
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42		18.2. Informative References . . . . . . . . . . . . . . . . . 41
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 43
	1. Introduction		1. Introduction
	Stateful NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4		Stateful NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4
	translation mechanism, which allows IPv6-only hosts to communicate		translation mechanism, which allows IPv6-only hosts to communicate
	with IPv4-only servers using unicast UDP, TCP, or ICMP, by means of		with IPv4-only servers using unicast UDP, TCP, or ICMP, by means of
	IPv4 public addresses sharing, among multiple IPv6-only hosts.		IPv4 public addresses sharing, among multiple IPv6-only hosts.
	Unless otherwise stated, references in the rest of this document to		Unless otherwise stated, references in the rest of this document to
	NAT64 (function) should be interpreted as to Stateful NAT64.		NAT64 (function) should be interpreted as to Stateful NAT64.
	skipping to change at page 7, line 20 ¶		skipping to change at page 7, line 20 ¶
	|		|
	|		|
	+----------+ +----+-----+		+----------+ +----+-----+
	| | | |		| | | |
	| IPv6 +--------+ DNS64 +		| IPv6 +--------+ DNS64 +
	| | | |		| | | |
	+----------+ +----------+		+----------+ +----------+
	Figure 2: NAT64 in external service provider		Figure 2: NAT64 in external service provider
	As well, is equivalent to the scenario where the outsourcing		This is equivalent to the scenario where the outsourcing agreement
	agreement with the external provider is to provide both the NAT64 and		with the external provider is to provide both the NAT64 and DNS64
	DNS64 functions. Once more, all the considerations in the previous		functions. Once more, all the considerations in the previous
	paragraphs of this section are the same for this sub-case.		paragraphs of this section are the same for this sub-case.
	+----------+ +----------+		+----------+ +----------+
	| extNAT64 | | |		| extNAT64 | | |
	| + +-------+ IPv4 |		| + +-------+ IPv4 |
	| extDNS64 | | |		| extDNS64 | | |
	+----+-----+ +----------+		+----+-----+ +----------+
	|		|
	+----------+ |		+----------+ |
	| | |		| | |
	skipping to change at page 10, line 30 ¶		skipping to change at page 10, line 30 ¶
	The possible communication paths, among the IPv4/IPv6 stacks of both		The possible communication paths, among the IPv4/IPv6 stacks of both
	peers, in this case, are:		peers, in this case, are:
	a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among		a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among
	peers.		peers.
	b. Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation.		b. Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation.
	c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT		c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT
	implements EAMT as indicated by Section 4.9. In principle, it is		implements EAM (Explicit Address Mappings) as indicated by
	not expected that services are deployed in Internet using		Section 4.9. In principle, it is not expected that services are
	IPv6-only, unless there is certainty that peers will also be		deployed in Internet using IPv6-only, unless there is certainty
	IPv6-capable.		that peers will also be IPv6-capable.
	d. Local-IPv4 to Remote-IPv4: DNS64, CLAT and NAT64 translations.		d. Local-IPv4 to Remote-IPv4: DNS64, CLAT and NAT64 translations.
	e. Local-IPv4 to Remote-dual-stack using EAMT optimization: If the		e. Local-IPv4 to Remote-dual-stack using EAM optimization: If the
	CLAT implements EAMT as indicated by Section 4.9, instead of		CLAT implements EAM as indicated by Section 4.9, instead of using
	using the path d. above, NAT64 translation is avoided and the		the path d. above, NAT64 translation is avoided and the flow will
	flow will use IPv6 from the CLAT to the destination.		use IPv6 from the CLAT to the destination.
	The rest of the figures in this section show different choices for		The rest of the figures in this section show different choices for
	placing the different elements.		placing the different elements.
	+----------+ +----------+ +----------+		+----------+ +----------+ +----------+
	| IPv6 | | NAT64 | | |		| IPv6 | | NAT64 | | |
	| + +--------+ + +--------+ IPv4 |		| + +--------+ + +--------+ IPv4 |
	| CLAT | | DNS64 | | |		| CLAT | | DNS64 | | |
	+----------+ +----------+ +----------+		+----------+ +----------+ +----------+
	skipping to change at page 11, line 49 ¶		skipping to change at page 11, line 49 ¶
	| CLAT |		| CLAT |
	+----------+		+----------+
	Figure 7: 464XLAT with DNS64; NAT64 and DNS64 in external provider		Figure 7: 464XLAT with DNS64; NAT64 and DNS64 in external provider
	3.1.3. Service Provider Offering 464XLAT, without DNS64		3.1.3. Service Provider Offering 464XLAT, without DNS64
	The major advantage of this scenario, using 464XLAT without DNS64, is		The major advantage of this scenario, using 464XLAT without DNS64, is
	that the service provider ensures that DNSSEC is never broken, even		that the service provider ensures that DNSSEC is never broken, even
	in case the user modifies the DNS configuration. Nevertheless, some		in case the user modifies the DNS configuration. Nevertheless, some
	CLAT implementations or applications may expose an extra delay, which		CLAT implementations or applications may impose an extra delay, which
	is inducted by the dual A/AAAA queries (and wait for both responses),		is induced by the dual A/AAAA queries (and wait for both responses),
	unless Happy Eyeballs v2 (HEv2, [RFC8305]) is also present.		unless Happy Eyeballs v2 (HEv2, [RFC8305]) is also present.
	A possible variation of this scenario is the case when DNS64 is used		A possible variation of this scenario is the case when DNS64 is used
	only for the discovery of the NAT64 prefix. The rest of the document		only for the discovery of the NAT64 prefix. The rest of the document
	is not considering it as a different scenario, because once the		is not considering it as a different scenario, because once the
	prefix has been discovered, the DNS64 function is not used, so it		prefix has been discovered, the DNS64 function is not used, so it
	behaves as if the DNS64 synthesis function is not present.		behaves as if the DNS64 synthesis function is not present.
	In this scenario, as in the previous one, there are no issues related		In this scenario, as in the previous one, there are no issues related
	to IPv4-only hosts (or IPv4-only applications) behind the IPv6-only		to IPv4-only hosts (or IPv4-only applications) behind the IPv6-only
	skipping to change at page 13, line 7 ¶		skipping to change at page 13, line 7 ¶
	The possible communication paths, among the IPv4/IPv6 stacks of both		The possible communication paths, among the IPv4/IPv6 stacks of both
	peers, in this case, are:		peers, in this case, are:
	a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among		a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among
	peers.		peers.
	b. Local-IPv6 to Remote-IPv4: Regular DNS, CLAT and NAT64		b. Local-IPv6 to Remote-IPv4: Regular DNS, CLAT and NAT64
	translations.		translations.
	c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT		c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT
	implements EAMT as indicated by Section 4.9. In principle, it is		implements EAM as indicated by Section 4.9. In principle, it is
	not expected that services are deployed in Internet using		not expected that services are deployed in Internet using
	IPv6-only, unless there is certainty that peers will also be		IPv6-only, unless there is certainty that peers will also be
	IPv6-capable.		IPv6-capable.
	d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT and NAT64		d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT and NAT64
	translations.		translations.
	e. Local-IPv4 to Remote-dual-stack using EAMT optimization: If the		e. Local-IPv4 to Remote-dual-stack using EAM optimization: If the
	CLAT implements EAMT as indicated by Section 4.9, instead of		CLAT implements EAM as indicated by Section 4.9, instead of using
	using the path d. above, NAT64 translation is avoided and the		the path d. above, NAT64 translation is avoided and the flow will
	flow will use IPv6 from the CLAT to the destination.		use IPv6 from the CLAT to the destination.
	It needs to be noticed that this scenario works while the local		It needs to be noticed that this scenario works while the local
	hosts/applications are dual-stack (which is the current situation),		hosts/applications are dual-stack (which is the current situation),
	because the connectivity from a local-IPv6 to a remote-IPv4 is not		because the connectivity from a local-IPv6 to a remote-IPv4 is not
	possible without an AAAA synthesis. This aspect is important only		possible without an AAAA synthesis. This aspect is important only
	when in the LANs behind the CLAT there are IPv6-only hosts and they		when in the LANs behind the CLAT there are IPv6-only hosts and they
	need to communicate with remote IPv4-only hosts. However, it doesn't		need to communicate with remote IPv4-only hosts. However, it doesn't
	look a sensible approach from an Operating System or application		look a sensible approach from an Operating System or application
	vendor perspective, to provide IPv6-only support unless, similarly to		vendor perspective, to provide IPv6-only support unless, similarly to
	case c above, there is certainty of peers supporting IPv6 as well. A		case c above, there is certainty of peers supporting IPv6 as well. A
	skipping to change at page 17, line 24 ¶		skipping to change at page 17, line 24 ¶
	the previous sections, by the figure number. The possible values		the previous sections, by the figure number. The possible values
	are:		are:
	o "-" Scenario "bad" for that criteria.		o "-" Scenario "bad" for that criteria.
	o "+" Scenario "good" for that criteria.		o "+" Scenario "good" for that criteria.
	o "*" Scenario "bad" for that criteria, however it is typically		o "*" Scenario "bad" for that criteria, however it is typically
	resolved, with the support of HEv2 ([RFC8305]).		resolved, with the support of HEv2 ([RFC8305]).
	In some cases "countermeasures", alternative or special		In some cases, "countermeasures", alternative or special
	configurations, may be available for the criteria designated as		configurations, may be available for the criteria designated as
	"bad". So this comparison is considering a generic case, as a quick		"bad". So, this comparison is considering a generic case, as a quick
	comparison guide. In some cases, a "bad" criteria is not necessarily		comparison guide. In some cases, a "bad" criterion is not
	a negative aspect, all it depends on the specific needs/		necessarily a negative aspect, all it depends on the specific needs/
	characteristics of the network where the deployment will take place.		characteristics of the network where the deployment will take place.
	For instance, in a network which has only IPv6-only hosts and apps		For instance, in a network which has only IPv6-only hosts and apps
	using only DNS and IPv6-compliant APIs, there is no impact using only		using only DNS and IPv6-compliant APIs, there is no impact using only
	NAT64 and DNS64, but if the hosts may validate DNSSEC, that item is		NAT64 and DNS64, but if the hosts may validate DNSSEC, that item is
	still relevant.		still relevant.
	+----------------+---+---+---+---+---+---+---+---+---+----+----+----+		+----------------+---+---+---+---+---+---+---+---+---+----+----+----+
	| Item / Figure | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |		| Item / Figure | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
	+----------------+---+---+---+---+---+---+---+---+---+----+----+----+		+----------------+---+---+---+---+---+---+---+---+---+----+----+----+
	| DNSSEC | - | - | - | - | - | - | - | + | + | + | + | + |		| DNSSEC | - | - | - | - | - | - | - | + | + | + | + | + |
	skipping to change at page 23, line 35 ¶		skipping to change at page 23, line 35 ¶
	will be done at the NAT64. This may break DNSSEC, unless		will be done at the NAT64. This may break DNSSEC, unless
	measures as described in the precedent sections are taken.		measures as described in the precedent sections are taken.
	2. Without DNS64: If DNS64 is not used, all the IPv4 traffic will		2. Without DNS64: If DNS64 is not used, all the IPv4 traffic will
	make use of the CLAT, so two translations are required (NAT46 at		make use of the CLAT, so two translations are required (NAT46 at
	the CLAT and NAT64 at the PLAT), which adds some overhead in		the CLAT and NAT64 at the PLAT), which adds some overhead in
	terms of the extra NAT46 translation. However, this avoids the		terms of the extra NAT46 translation. However, this avoids the
	AAAA synthesis and consequently will never break DNSSEC.		AAAA synthesis and consequently will never break DNSSEC.
	Note that the extra translation, when DNS64 is not used, takes place		Note that the extra translation, when DNS64 is not used, takes place
	at the CLAT, which means no extra overhead for the operator.		at the CLAT, which means no extra overhead for the operator. It
	However, adds potential extra delays to establish the connections,		however adds potential extra delays to establish the connections, and
	and no perceptible impact for a CE in a broadband network, while it		no perceptible impact for a CE in a broadband network, while it may
	may have some impact in a battery powered device. This cost for a		have some impact in a battery powered device. This cost for a
	battery powered device, is possibly comparable to the cost when the		battery powered device, is possibly comparable to the cost when the
	device is doing a local address synthesis (see Section 7.1 of		device is doing a local address synthesis (see Section 7.1 of
	[RFC8305]).		[RFC8305]).
	4.4. Foreign DNS		4.4. Foreign DNS
	Clients, devices or applications in a service provider network, may		Clients, devices or applications in a service provider network, may
	use DNS servers from other networks. This may be the case either if		use DNS servers from other networks. This may be the case either if
	individual applications use their own DNS server, the Operating		individual applications use their own DNS server, the Operating
	System itself or even the CE, or combinations of the above.		System itself or even the CE, or combinations of the above.
	Those "foreign" DNS servers may not support DNS64, which will mean		Those "foreign" DNS servers may not support DNS64, which will mean
	that those scenarios that require a DNS64 may not work. However, if		that those scenarios that require a DNS64 may not work. However, if
	a CLAT function is available, the considerations in Section 4.3 will		a CLAT function is available, the considerations in Section 4.3 will
	apply.		apply.
	In the case that the foreign DNS supports the DNS64 function, we may		In the case that the foreign DNS supports the DNS64 function, we may
	be in the situation of providing incorrect configurations parameters,		be in the situation of providing incorrect configurations parameters,
	for example un-matching WKP or NSP, or a case such the one described		for example, un-matching WKP or NSP, or a case such the one described
	in Section 3.2.3.		in Section 3.2.3.
	Having a CLAT function, even if using foreign DNS without a DNS64		Having a CLAT function, even if using foreign DNS without a DNS64
	function, ensures that everything will work, so the CLAT must be		function, ensures that everything will work, so the CLAT must be
	considered as an advantage even against user configuration errors.		considered as an advantage even against user configuration errors.
	The cost of this, is that all the traffic will use a double		The cost of this, is that all the traffic will use a double
	translation (NAT46 at the CLAT and NAT64 at the operator network),		translation (NAT46 at the CLAT and NAT64 at the operator network),
	unless there is support for EAMT (Section 4.9).		unless there is support for EAM (Section 4.9).
	An exception to that is the case when there is a CLAT function at the		An exception to that is the case when there is a CLAT function at the
	CE, which is not able to obtain the correct configuration parameters		CE, which is not able to obtain the correct configuration parameters
	(again, un-matching WKP or NSP).		(again, un-matching WKP or NSP).
	However, it needs to be reinforced, that if there is not a CLAT		However, it needs to be emphasized, that if there is not a CLAT
	function (scenarios without 464XLAT), an external DNS without DNS64		function (scenarios without 464XLAT), an external DNS without DNS64
	support, will disallow any access to IPv4-only destination networks,		support, will disallow any access to IPv4-only destination networks,
	and will not guarantee DNSSEC, so will behave as in the		and will not guarantee DNSSEC, so will behave as in the
	Section 3.2.1.		Section 3.2.1.
	The causes of "foreign DNS" could be classified in three main		The causes of "foreign DNS" could be classified in three main
	categories, as depicted in the following sub-sections.		categories, as depicted in the following sub-sections.
	4.4.1. Manual Configuration of Foreign DNS		4.4.1. Manual Configuration of Foreign DNS
	skipping to change at page 25, line 16 ¶		skipping to change at page 25, line 16 ¶
	When networks or hosts use "split-DNS" (also called Split Horizon,		When networks or hosts use "split-DNS" (also called Split Horizon,
	DNS views or private DNS), the successful use of the DNS64 is not		DNS views or private DNS), the successful use of the DNS64 is not
	guaranteed. Section 4 of [RFC6950], analyses this case.		guaranteed. Section 4 of [RFC6950], analyses this case.
	A similar situation may happen in case of VPNs that force all the DNS		A similar situation may happen in case of VPNs that force all the DNS
	queries through the VPN, ignoring the operator DNS64 function.		queries through the VPN, ignoring the operator DNS64 function.
	4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP)		4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP)
	[RFC6052] (IPv6 Addressing of IPv4/IPv6 Translators), Section 3,		Section 3 of [RFC6052] (IPv6 Addressing of IPv4/IPv6 Translators),
	discusses some considerations which are useful to decide if an		discusses some considerations which are useful to decide if an
	operator should use the WKP or an NSP.		operator should use the WKP or an NSP.
	Taking in consideration that discussion and other issues, we can		Taking in consideration that discussion and other issues, we can
	summarize the possible decision points as:		summarize the possible decision points as:
	a. The WKP MUST NOT be used to represent non-global IPv4 addresses.		a. The WKP MUST NOT be used to represent non-global IPv4 addresses.
	If this is required because the network to be translated use non-		If this is required because the network to be translated use non-
	global addresses, then an NSP is required.		global addresses, then an NSP is required.
	skipping to change at page 27, line 6 ¶		skipping to change at page 27, line 6 ¶
	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 ([RFC8415]). Instead, a single /64 is provided for each		DHCPv6-PD ([RFC8415]). Instead, a single /64 is provided for each
	PDP context and prefix sharing ([RFC6877]) is used. So, in this		PDP context and prefix sharing ([RFC6877]) is used. So, in this
	case, the UEs typically have a build-in CLAT function which is		case, the UEs typically have a build-in CLAT function which is
	performing a stateful NAT44 translation before the stateless NAT46.		performing a stateful NAT44 translation before the stateless NAT46.
	4.9. EAMT Considerations		4.9. EAM Considerations
	Explicit Address Mappings for Stateless IP/ICMP Translation		Explicit Address Mappings for Stateless IP/ICMP Translation
	([RFC7757]) provide a way to configure explicit mappings between IPv4		([RFC7757]) provide a way to configure explicit mappings between IPv4
	and IPv6 prefixes of any length. When this is used, for example in a		and IPv6 prefixes of any length. When this is used, for example in a
	CLAT function, it may provide a simple mechanism in order to avoid		CLAT function, it may provide a simple mechanism in order to avoid
	traffic flows between IPv4-only nodes or applications and dual-stack		traffic flows between IPv4-only nodes or applications and dual-stack
	destinations to be translated twice (NAT46 and NAT64), by creating		destinations to be translated twice (NAT46 and NAT64), by creating
	mapping entries with the GUA of the IPv6-reachable destination. This		mapping entries with the GUA of the IPv6-reachable destination. This
	optimization of the NAT64 usage is very useful in many scenarios,		optimization of the NAT64 usage is very useful in many scenarios,
	including CDNs and caches, as described in		including CDNs and caches, as described in
	[I-D.palet-v6ops-464xlat-opt-cdn-caches].		[I-D.palet-v6ops-464xlat-opt-cdn-caches].
	In addition to that, it may provide as well a way for IPv4-only nodes		In addition to that, it may provide as well a way for IPv4-only nodes
	or applications to communicate with IPv6-only destinations.		or applications to communicate with IPv6-only destinations.
			4.10. Incoming Connections
			The use of NAT64, in principle, disallows IPv4 incoming connections,
			which may be still needed for IPv4-only peer-to-peer applications.
			However, there are several alternatives that resolve this issue:
			a. STUN ([RFC5389]), TURN ([RFC5766]) and ICE ([RFC8445]) are
			commonly used by peer-to-peer applications in order to allow
			incoming connections with IPv4 NAT. In the case of NAT64, they
			work as well.
			b. PCP ([RFC6887]) allows a host to control how incoming IPv4 and
			IPv6 packets are translated and forwarded. A NAT64 may implement
			PCP to allow this service.
			c. EAM ([RFC7757]) may also be used in order to configure explicit
			mappings for customers that require them. This is used for
			example by SIIT-DC ([RFC7755]) and SIIT-DC-DTM ([RFC7756]).
	5. Summary of Deployment Recommendations for NAT64/464XLAT		5. Summary of Deployment Recommendations for NAT64/464XLAT
	NAT64/464XLAT has demonstrated to be a valid choice in several		NAT64/464XLAT has demonstrated to be a valid choice in several
	scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), with hundreds of millions		scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), with hundreds of millions
	of users, offering different choices of deployment, depending on each		of users, offering different choices of deployment, depending on each
	network case, needs and requirements. Despite that, this document is		network case, needs and requirements. Despite that, this document is
	not an explicit recommendation for using this choice versus other		not an explicit recommendation for using this choice versus other
	IPv4aaS transition mechanisms. Instead, this document is a guide		IPv4aaS transition mechanisms. Instead, this document is a guide
	that facilitates evaluating a possible implementation of		that facilitates evaluating a possible implementation of
	NAT64/464XLAT and key decision points about specific design		NAT64/464XLAT and key decision points about specific design
	skipping to change at page 28, line 39 ¶		skipping to change at page 29, line 10 ¶
	the CLAT (Section 4.3).		the CLAT (Section 4.3).
	If DNS64 is not used, at least one of the alternatives described in		If DNS64 is not used, at least one of the alternatives described in
	Section 4.1.1, must be followed in order to learn he NAT64 prefix.		Section 4.1.1, must be followed in order to learn he NAT64 prefix.
	The operator needs to consider that if the DNS configuration can be		The operator needs to consider that if the DNS configuration can be
	modified (Section 4.4, Section 4.4.2, Section 4.4.3), which most		modified (Section 4.4, Section 4.4.2, Section 4.4.3), which most
	probably is impossible to avoid, there are chances that instead of		probably is impossible to avoid, there are chances that instead of
	configuring a DNS64 a foreign non-DNS64 is used. In a scenario with		configuring a DNS64 a foreign non-DNS64 is used. In a scenario with
	only a NAT64 function IPv4-only remote host will no longer be		only a NAT64 function IPv4-only remote host will no longer be
	accesible. Instead, it will continue to work in the case of 464XLAT.		accessible. Instead, it will continue to work in the case of
			464XLAT.
	Similar considerations need to be taken regarding the usage of a		Similar considerations need to be taken regarding the usage of a
	NAT64 WKP vs NSP (Section 4.5), as they must match with the		NAT64 WKP vs NSP (Section 4.5), as they must match with the
	configuration of the DNS64. In case of using foreign DNS, they may		configuration of the DNS64. In case of using foreign DNS, they may
	not match. If there is a CLAT and the configured foreign DNS is not		not match. If there is a CLAT and the configured foreign DNS is not
	a DNS64, the network will keep working only if other means of		a DNS64, the network will keep working only if other means of
	learning the NAT64 prefix are available.		learning the NAT64 prefix are available.
	As described in Section 4.8, for broadband networks, the CEs		As described in Section 4.8, for broadband networks, the CEs
	supporting a CLAT function, SHOULD support DHCPv6-PD ([RFC8415]), or		supporting a CLAT function, SHOULD support DHCPv6-PD ([RFC8415]), or
	skipping to change at page 30, line 15 ¶		skipping to change at page 30, line 33 ¶
	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 function, not using a DNS64 but		be, in addition to having a CLAT function, not using a DNS64 but
	instead making sure that the hosts have a built-in address synthesis		instead making sure that the hosts have a built-in address synthesis
	feature. Operators could manage to provide CEs with the CLAT		feature. Operators could manage to provide CEs with the CLAT
	function, however the built-in address synthesis feature is out of		function, however the built-in address synthesis feature is out of
	their control. If the synthesis is provided either by the Operating		their control. If the synthesis is provided either by the Operating
	System (via its DNS resolver API) or by the application (via its own		System (via its DNS resolver API) or by the application (via its own
	DNS resolver), in such way that the prefix used for the NAT64		DNS resolver), in such way that the prefix used for the NAT64
	function is reachable for the host, the problem goes away.		function is reachable for the host, the problem goes away.
	Whenever feasible, using EAMT ([RFC7757]) as indicated in		Whenever feasible, using EAM ([RFC7757]) as indicated in Section 4.9,
	Section 4.9, provides a very relevant optimization, avoiding double-		provides a very relevant optimization, avoiding double-translations.
	translations.
			Applications that require incoming connections, typically already
			provide means for that. However, PCP and EAM, as indicated in
			Section 4.10, are valid alternatives, even for creating explicit
			mappings for customers that require them.
	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 function (and DNS64 function,		This include scenarios where the NAT64 function (and DNS64 function,
	if available) are under the control of that network (or can be		if available) are under the control of that network (or can be
	configured manually according to that network specific requirements),		configured manually according to that network specific requirements),
	skipping to change at page 33, line 51 ¶		skipping to change at page 34, line 18 ¶
	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 ([I-D.ietf-6man-ra-pref64]) or		future, such as Router Advertising ([I-D.ietf-6man-ra-pref64]) or
	DHCPv6 options ([I-D.li-intarea-nat64-prefix-dhcp-option]).		DHCPv6 options ([I-D.li-intarea-nat64-prefix-dhcp-option]).
	2. If the CLAT function allows stateless NAT46 translation, a /64		2. If the CLAT function allows stateless NAT46 translation, a /64
	from the pool typically provided to the CE by means of DHCPv6-PD		from the pool typically provided to the CE by means of DHCPv6-PD
	[RFC8415], 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.8.		before the a stateless NAT46, as described in Section 4.8.
	A more detailed configuration approach is described in		A more detailed configuration approach is described in [RFC8585].
	[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. It is highly		provided for the discovery of the PLAT prefix. It is highly
	recommended to follow [RIPE-690], in order to ensure that multiple		recommended to follow [RIPE-690], in order to ensure that multiple
	/64s are available, including the one needed for the NAT46 stateless		/64s are available, including the one needed for the NAT46 stateless
	translation.		translation.
	The operator needs to understand other issues, described across this		The operator needs to understand other issues, described across this
	document, in order to take the relevant decisions. For example, if		document, in order to take the relevant decisions. For example, if
	several NAT64 functions are needed in the context of scalability/		several NAT64 functions are needed in the context of scalability/
	skipping to change at page 34, line 52 ¶		skipping to change at page 35, line 30 ¶
	Figure 18: CE setup with built-in CLAT without DNS64		Figure 18: CE setup with built-in CLAT without DNS64
	In this case, the discovery of the PLAT prefix needs to be arranged		In this case, the discovery of the PLAT prefix needs to be arranged
	as indicated in Section 4.1.1.		as indicated in Section 4.1.1.
	In this case, the CE doesn't have a built-in CLAT function, or the		In this case, the CE doesn't have a built-in CLAT function, or the
	customer can choose to setup the IPv6 operator-managed CE in bridge		customer can choose to setup the IPv6 operator-managed CE in bridge
	mode (and optionally use an external router), or for example, there		mode (and optionally use an external router), or for example, there
	is an access technology that requires some kind of media converter		is an access technology that requires some kind of media converter
	(ONT for FTTH, CableModem for DOCSIS, etc.), the complete setup will		(ONT for FTTH, Cable-Modem for DOCSIS, etc.), the complete setup will
	look as in the next figure. Obviously, there will be some		look as in the next figure. Obviously, there will be some
	intermediate configuration steps for the bridge, depending on the		intermediate configuration steps for the bridge, depending on the
	specific access technology/protocols, which should not modify the		specific access technology/protocols, which should not modify the
	steps already described in the previous cases for the CLAT function		steps already described in the previous cases for the CLAT function
	configuration.		configuration.
	+-------+ .-----. .-----.		+-------+ .-----. .-----.
	| | / \ / \		| | / \ / \
	| Res./ | / IPv6- \ .-----. / IPv4- \		| Res./ | / IPv6- \ .-----. / IPv4- \
	| SOHO +--( only )--( NAT64 )--( only )		| SOHO +--( only )--( NAT64 )--( only )
	skipping to change at page 35, line 48 ¶		skipping to change at page 36, line 43 ¶
	Figure 19: CE setup with bridged CLAT without DNS64		Figure 19: CE setup with bridged CLAT without DNS64
	It should be avoided that several routers (i.e., the operator		It should be avoided that several routers (i.e., the operator
	provided CE and a downstream user provided router) enable		provided CE and a downstream user provided router) enable
	simultaneously routing and/or CLAT, in order to avoid multiple NAT44		simultaneously routing and/or CLAT, in order to avoid multiple NAT44
	and NAT46 levels, as well as ensuring the correct operation of		and NAT46 levels, as well as ensuring the correct operation of
	multiple IPv6 subnets. In those cases, it is suggested the use of		multiple IPv6 subnets. In those cases, it is suggested the use of
	HNCP ([RFC8375]).		HNCP ([RFC8375]).
	Note that the procedure described here for the CE setup, can be		Note that the procedure described here for the CE setup, can be
	simplified if the CE follows [I-D.ietf-v6ops-transition-ipv4aas].		simplified if the CE follows [RFC8585].
	11. ANNEX B: CLAT Implementation		11. ANNEX B: CLAT Implementation
	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 function.		o [RFC7915] for the NAT46 function.
	o [RFC7050] for the PLAT prefix discovery.		o [RFC7050] for the PLAT prefix discovery.
	skipping to change at page 37, line 20 ¶		skipping to change at page 38, line 9 ¶
	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. ANNEX F: Changes from -03 to -04		15. ANNEX F: Changes from -03 to -04
	Section to be removed after WGLC. Significant updates are:		Section to be removed after WGLC. Significant updates are:
	1. Added text related to EAMT considerations.		1. Added text related to EAM considerations.
	16. ANNEX G: Changes from -04 to -05		16. ANNEX G: Changes from -04 to -05
	Section to be removed after WGLC. Significant updates are:		Section to be removed after WGLC. Significant updates are:
	1. Added cross references to EAMT section.		1. Added cross references to EAM section.
	2. Reworded "foreing DNS section".		2. Reworded "foreing DNS section".
	3. Overall editorial review of text, pictures and nits correction.		3. Overall editorial review of text, pictures and nits correction.
	17. References		17. ANNEX H: Changes from -05 to -06
	17.1. Normative References		Section to be removed after WGLC. Significant updates are:
			1. Corrected EAMT to EAM.
			2. Typos and nits.
			3. New considerations regarding incoming connections.
			18. References
			18.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>.
			[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
			"Session Traversal Utilities for NAT (STUN)", RFC 5389,
			DOI 10.17487/RFC5389, October 2008,
			<https://www.rfc-editor.org/info/rfc5389>.
	[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",		[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
	BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,		BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
	<https://www.rfc-editor.org/info/rfc5625>.		<https://www.rfc-editor.org/info/rfc5625>.
			[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
			Relays around NAT (TURN): Relay Extensions to Session
			Traversal Utilities for NAT (STUN)", RFC 5766,
			DOI 10.17487/RFC5766, April 2010,
			<https://www.rfc-editor.org/info/rfc5766>.
	[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 38, line 35 ¶		skipping to change at page 39, line 41 ¶
	[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts		[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
	Using "Bump-in-the-Host" (BIH)", RFC 6535,		Using "Bump-in-the-Host" (BIH)", RFC 6535,
	DOI 10.17487/RFC6535, February 2012,		DOI 10.17487/RFC6535, February 2012,
	<https://www.rfc-editor.org/info/rfc6535>.		<https://www.rfc-editor.org/info/rfc6535>.
	[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>.
			[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
			P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
			DOI 10.17487/RFC6887, April 2013,
			<https://www.rfc-editor.org/info/rfc6887>.
	[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>.
	skipping to change at page 39, line 33 ¶		skipping to change at page 40, line 43 ¶
	[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>.
	[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,		[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
	Richardson, M., Jiang, S., Lemon, T., and T. Winters,		Richardson, M., Jiang, S., Lemon, T., and T. Winters,
	"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",		"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
	RFC 8415, DOI 10.17487/RFC8415, November 2018,		RFC 8415, DOI 10.17487/RFC8415, November 2018,
	<https://www.rfc-editor.org/info/rfc8415>.		<https://www.rfc-editor.org/info/rfc8415>.
			[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
			Connectivity Establishment (ICE): A Protocol for Network
			Address Translator (NAT) Traversal", RFC 8445,
			DOI 10.17487/RFC8445, July 2018,
			<https://www.rfc-editor.org/info/rfc8445>.
	[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS		[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
	(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,		(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
	<https://www.rfc-editor.org/info/rfc8484>.		<https://www.rfc-editor.org/info/rfc8484>.
	17.2. Informative References		18.2. Informative References
	[About-DNS64]		[About-DNS64]
	Linkova, J., "Let's talk about IPv6 DNS64 & DNSSEC", 2016,		Linkova, J., "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]
	Lencse, G. and Y. Kadobayashi, "Benchmarking DNS64		Lencse, G. and Y. Kadobayashi, "Benchmarking DNS64
	Implementations: Theory and Practice", Computer		Implementations: Theory and Practice", Computer
	Communications , vol. 127, no. 1, pp. 61-74,		Communications , vol. 127, no. 1, pp. 61-74,
	skipping to change at page 40, line 27 ¶		skipping to change at page 41, line 40 ¶
	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-06 (work in		Connections", draft-huitema-quic-dnsoquic-06 (work in
	progress), March 2019.		progress), March 2019.
	[I-D.ietf-6man-ra-pref64]		[I-D.ietf-6man-ra-pref64]
	Colitti, L., Kline, E., and J. Linkova, "Discovering		Colitti, L., Kline, E., and J. Linkova, "Discovering
	PREF64 in Router Advertisements", draft-ietf-6man-ra-		PREF64 in Router Advertisements", draft-ietf-6man-ra-
	pref64-00 (work in progress), March 2019.		pref64-00 (work in progress), March 2019.
	[I-D.ietf-v6ops-transition-ipv4aas]
	Palet, J., Liu, H., and M. Kawashima, "Requirements for
	IPv6 Customer Edge Routers to Support IPv4 Connectivity
	as-a-Service", draft-ietf-v6ops-transition-ipv4aas-15
	(work in progress), January 2019.
	[I-D.li-intarea-nat64-prefix-dhcp-option]		[I-D.li-intarea-nat64-prefix-dhcp-option]
	Li, L., Cui, Y., Liu, C., Wu, J., Baker, F., and J. Palet,		Li, L., Cui, Y., Liu, C., Wu, J., Baker, F., and J. Palet,
	"DHCPv6 Options for Discovery NAT64 Prefixes", draft-li-		"DHCPv6 Options for Discovery NAT64 Prefixes", draft-li-
	intarea-nat64-prefix-dhcp-option-01 (work in progress),		intarea-nat64-prefix-dhcp-option-02 (work in progress),
	March 2017.		April 2019.
	[I-D.lmhp-v6ops-transition-comparison]		[I-D.lmhp-v6ops-transition-comparison]
	Lencse, G., Palet, J., Howard, L., Patterson, R., and I.		Lencse, G., Palet, J., Howard, L., Patterson, R., and I.
	Farrer, "Pros and Cons of IPv6 Transition Technologies for		Farrer, "Pros and Cons of IPv6 Transition Technologies for
	IPv4aaS", draft-lmhp-v6ops-transition-comparison-02 (work		IPv4aaS", draft-lmhp-v6ops-transition-comparison-02 (work
	in progress), January 2019.		in progress), January 2019.
	[I-D.palet-v6ops-464xlat-opt-cdn-caches]		[I-D.palet-v6ops-464xlat-opt-cdn-caches]
	Palet, J. and A. D'Egidio, "464XLAT Optimization for CDNs/		Palet, J. and A. D'Egidio, "464XLAT Optimization for CDNs/
	Caches", draft-palet-v6ops-464xlat-opt-cdn-caches-01 (work		Caches", draft-palet-v6ops-464xlat-opt-cdn-caches-01 (work
	skipping to change at page 41, line 30 ¶		skipping to change at page 42, line 35 ¶
	[RFC7051] Korhonen, J., Ed. and T. Savolainen, Ed., "Analysis of		[RFC7051] Korhonen, J., Ed. and T. Savolainen, Ed., "Analysis of
	Solution Proposals for Hosts to Learn NAT64 Prefix",		Solution Proposals for Hosts to Learn NAT64 Prefix",
	RFC 7051, DOI 10.17487/RFC7051, November 2013,		RFC 7051, DOI 10.17487/RFC7051, November 2013,
	<https://www.rfc-editor.org/info/rfc7051>.		<https://www.rfc-editor.org/info/rfc7051>.
	[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>.
			[RFC7755] Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for
			IPv6 Data Center Environments", RFC 7755,
			DOI 10.17487/RFC7755, February 2016,
			<https://www.rfc-editor.org/info/rfc7755>.
			[RFC7756] Anderson, T. and S. Steffann, "Stateless IP/ICMP
			Translation for IPv6 Internet Data Center Environments
			(SIIT-DC): Dual Translation Mode", RFC 7756,
			DOI 10.17487/RFC7756, February 2016,
			<https://www.rfc-editor.org/info/rfc7756>.
	[RFC7849] Binet, D., Boucadair, M., Vizdal, A., Chen, G., Heatley,		[RFC7849] Binet, D., Boucadair, M., Vizdal, A., Chen, G., Heatley,
	N., Chandler, R., Michaud, D., Lopez, D., and W. Haeffner,		N., Chandler, R., Michaud, D., Lopez, D., and W. Haeffner,
	"An IPv6 Profile for 3GPP Mobile Devices", RFC 7849,		"An IPv6 Profile for 3GPP Mobile Devices", RFC 7849,
	DOI 10.17487/RFC7849, May 2016,		DOI 10.17487/RFC7849, May 2016,
	<https://www.rfc-editor.org/info/rfc7849>.		<https://www.rfc-editor.org/info/rfc7849>.
	[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,		[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
	and P. Hoffman, "Specification for DNS over Transport		and P. Hoffman, "Specification for DNS over Transport
	Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May		Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
	2016, <https://www.rfc-editor.org/info/rfc7858>.		2016, <https://www.rfc-editor.org/info/rfc7858>.
	skipping to change at page 42, line 5 ¶		skipping to change at page 43, line 20 ¶
	[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram		[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
	Transport Layer Security (DTLS)", RFC 8094,		Transport Layer Security (DTLS)", RFC 8094,
	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>.
	[RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking		[RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking
	Methodology for IPv6 Transition Technologies", RFC 8219,		Methodology for IPv6 Transition Technologies", RFC 8219,
	DOI 10.17487/RFC8219, August 2017,		DOI 10.17487/RFC8219, August 2017,
	<https://www.rfc-editor.org/info/rfc8219>.		<https://www.rfc-editor.org/info/rfc8219>.
			[RFC8585] Palet Martinez, J., Liu, H., and M. Kawashima,
			"Requirements for IPv6 Customer Edge Routers to Support
			IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May
			2019, <https://www.rfc-editor.org/info/rfc8585>.
	[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]
	Lencse, G. and Y. Kadobayashi, "Methodology for the		Lencse, G. and Y. Kadobayashi, "Methodology for the
	identification of potential security issues of different		identification of potential security issues of different
	IPv6 transition technologies: Threat analysis of DNS64 and		IPv6 transition technologies: Threat analysis of DNS64 and
End of changes. 40 change blocks.
	67 lines changed or deleted		133 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/