draft-ietf-v6ops-nat64-deployment-07.txt		draft-ietf-v6ops-nat64-deployment-08.txt
	v6ops J. Palet Martinez		v6ops J. Palet Martinez
	Internet-Draft The IPv6 Company		Internet-Draft The IPv6 Company
	Intended status: Informational July 8, 2019		Intended status: Informational July 11, 2019
	Expires: January 9, 2020		Expires: January 12, 2020
	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-07		draft-ietf-v6ops-nat64-deployment-08
	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 January 9, 2020.		This Internet-Draft will expire on January 12, 2020.
	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 36 ¶		skipping to change at page 2, line 36 ¶
	4.1.2. DNSSEC validator aware of DNS64 . . . . . . . . . . . 21		4.1.2. DNSSEC validator aware of DNS64 . . . . . . . . . . . 21
	4.1.3. Stub validator . . . . . . . . . . . . . . . . . . . 22		4.1.3. Stub validator . . . . . . . . . . . . . . . . . . . 22
	4.1.4. CLAT with DNS proxy and validator . . . . . . . . . . 22		4.1.4. CLAT with DNS proxy and validator . . . . . . . . . . 22
	4.1.5. ACL of clients . . . . . . . . . . . . . . . . . . . 22		4.1.5. ACL of clients . . . . . . . . . . . . . . . . . . . 22
	4.1.6. Mapping-out IPv4 addresses . . . . . . . . . . . . . 23		4.1.6. Mapping-out IPv4 addresses . . . . . . . . . . . . . 23
	4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 23		4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 23
	4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 23		4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 23
	4.4. Foreign DNS . . . . . . . . . . . . . . . . . . . . . . . 24		4.4. Foreign DNS . . . . . . . . . . . . . . . . . . . . . . . 24
	4.4.1. Manual Configuration of DNS . . . . . . . . . . . . . 25		4.4.1. Manual Configuration of DNS . . . . . . . . . . . . . 25
	4.4.2. DNS Privacy/Encryption Mechanisms . . . . . . . . . . 25		4.4.2. DNS Privacy/Encryption Mechanisms . . . . . . . . . . 25
	4.4.3. Split DNS . . . . . . . . . . . . . . . . . . . . . . 26		4.4.3. Split DNS and VPNs . . . . . . . . . . . . . . . . . 26
	4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 26		4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 26
	4.6. IPv4 literals and non-IPv6 Compliant APIs . . . . . . . . 26		4.6. IPv4 literals and non-IPv6 Compliant APIs . . . . . . . . 26
	4.7. IPv4-only Hosts or Applications . . . . . . . . . . . . . 27		4.7. IPv4-only Hosts or Applications . . . . . . . . . . . . . 27
	4.8. CLAT Translation Considerations . . . . . . . . . . . . . 27		4.8. CLAT Translation Considerations . . . . . . . . . . . . . 27
	4.9. EAM Considerations . . . . . . . . . . . . . . . . . . . 28		4.9. EAM Considerations . . . . . . . . . . . . . . . . . . . 28
	4.10. Incoming Connections . . . . . . . . . . . . . . . . . . 28		4.10. Incoming Connections . . . . . . . . . . . . . . . . . . 28
	5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 28		5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 28
	6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 31		6. Deployment of 464XLAT/NAT64 in Enterprise Networks . . . . . 31
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 33		7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
	10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 34		10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 34
	11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 37		11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 37
	12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 38		12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 38
	13. ANNEX D: Changes from -00 to -01/-02 . . . . . . . . . . . . 38		13. ANNEX D: Changes from -00 to -01/-02 . . . . . . . . . . . . 38
	14. ANNEX E: Changes from -02 to -03 . . . . . . . . . . . . . . 38		14. ANNEX E: Changes from -02 to -03 . . . . . . . . . . . . . . 38
	15. ANNEX F: Changes from -03 to -04 . . . . . . . . . . . . . . 39		15. ANNEX F: Changes from -03 to -04 . . . . . . . . . . . . . . 39
	16. ANNEX G: Changes from -04 to -05 . . . . . . . . . . . . . . 39		16. ANNEX G: Changes from -04 to -05 . . . . . . . . . . . . . . 39
	skipping to change at page 4, line 21 ¶		skipping to change at page 4, line 21 ¶
	specific.		specific.
	According to that, across this document, the use of "operator",		According to that, across this document, the use of "operator",
	"operator network", "service provider", and similar ones, are		"operator network", "service provider", and similar ones, are
	interchangeable with equivalent cases of enterprise networks (and		interchangeable with equivalent cases of enterprise networks (and
	similar ones). This may be also the case for "managed end-user		similar ones). This may be also the case for "managed end-user
	networks".		networks".
	Note that if all the hosts in a network were performing the address		Note that if all the hosts in a network were performing the address
	synthesis, as described in Section 7.2 of [RFC6147], some of the		synthesis, as described in Section 7.2 of [RFC6147], some of the
	drawbacks may vanish. However, it is today unrealistic to expect		drawbacks may vanish. However, it is unrealistic today to expect
	that, considering the high number of devices and applications that		that, considering the high number of devices and applications that
	aren't yet IPv6-enabled. So, in this document, this will be		aren't yet IPv6-enabled. So, in this document, this will be
	considered only for specific scenarios that can guarantee it.		considered only for specific scenarios that can guarantee it.
	An analysis of stateful IPv4/IPv6 mechanisms is provided in		An analysis of stateful IPv4/IPv6 mechanisms is provided in
	[RFC6889].		[RFC6889].
	This document looks into different possible NAT64 ([RFC6146])		This document looks into different possible NAT64 ([RFC6146])
	deployment scenarios, including IPv4-IPv6-IPv4 (464 for short) and		deployment scenarios, including IPv4-IPv6-IPv4 (464 for short) and
	similar ones, which were not documented in [RFC6144], such as 464XLAT		similar ones, which were not documented in [RFC6144], such as 464XLAT
	skipping to change at page 25, line 38 ¶		skipping to change at page 25, line 38 ¶
	categories, as depicted in the following sub-sections.		categories, as depicted in the following sub-sections.
	4.4.1. Manual Configuration of DNS		4.4.1. Manual Configuration of DNS
	It is becoming increasingly common that end-users or even devices or		It is becoming increasingly common that end-users or even devices or
	applications configure alternative DNS in their Operating Systems,		applications configure alternative DNS in their Operating Systems,
	and sometimes in CEs.		and sometimes in CEs.
	4.4.2. DNS Privacy/Encryption Mechanisms		4.4.2. DNS Privacy/Encryption Mechanisms
	A new trend is for clients or applications to use mechanisms for DNS		Clients or applications may use mechanisms for DNS privacy/
	privacy/encryption, such as DNS over TLS ([RFC7858]), DNS over DTLS		encryption, such as DNS over TLS ([RFC7858]), DNS over DTLS
	([RFC8094]), DNS queries over HTTPS ([RFC8484]) or DNS over QUIC		([RFC8094]), DNS queries over HTTPS ([RFC8484]) or DNS over QUIC
	([I-D.huitema-quic-dnsoquic]). Those are commonly cited as DoT, DoH		([I-D.huitema-quic-dnsoquic]). Those are commonly cited as DoT, DoH
	and DoQ.		and DoQ.
	Those DNS privacy/encryption options, currently are typically		Those DNS privacy/encryption options, currently are typically
	provided by the applications, not the Operating System vendors. At		provided by the applications, not the Operating System vendors. At
	the time of writing this document, at least DoT and DoH standards		the time of writing this document, at least DoT and DoH standards
	have declared DNS64 (and consequently NAT64) out of their scope, so		have declared DNS64 (and consequently NAT64) out of their scope, so
	an application using them may break NAT64, unless a correctly		an application using them may break NAT64, unless a correctly
	configured CLAT function is used.		configured CLAT function is used.
	4.4.3. Split DNS		4.4.3. Split DNS and VPNs
	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)
	skipping to change at page 28, line 31 ¶		skipping to change at page 28, line 31 ¶
	4.10. Incoming Connections		4.10. Incoming Connections
	The use of NAT64, in principle, disallows IPv4 incoming connections,		The use of NAT64, in principle, disallows IPv4 incoming connections,
	which may be still needed for IPv4-only peer-to-peer applications.		which may be still needed for IPv4-only peer-to-peer applications.
	However, there are several alternatives that resolve this issue:		However, there are several alternatives that resolve this issue:
	a. STUN ([RFC5389]), TURN ([RFC5766]) and ICE ([RFC8445]) are		a. STUN ([RFC5389]), TURN ([RFC5766]) and ICE ([RFC8445]) are
	commonly used by peer-to-peer applications in order to allow		commonly used by peer-to-peer applications in order to allow
	incoming connections with IPv4 NAT. In the case of NAT64, they		incoming connections with IPv4 NAT. In the case of NAT64, they
	work as well. Note also the relevance of		work as well. RFC editor note: If in time, replace STUN and TURN
	[I-D.ietf-tram-turnbis].		with [I-D.ietf-tram-stunbis] / [I-D.ietf-tram-turnbis].
	b. PCP ([RFC6887]) allows a host to control how incoming IPv4 and		b. PCP ([RFC6887]) allows a host to control how incoming IPv4 and
	IPv6 packets are translated and forwarded. A NAT64 may implement		IPv6 packets are translated and forwarded. A NAT64 may implement
	PCP to allow this service.		PCP to allow this service.
	c. EAM ([RFC7757]) may also be used in order to configure explicit		c. EAM ([RFC7757]) may also be used in order to configure explicit
	mappings for customers that require them. This is used for		mappings for customers that require them. This is used for
	example by SIIT-DC ([RFC7755]) and SIIT-DC-DTM ([RFC7756]).		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), being the predominant
	of users, being the predominant mechanism in the majority of the		mechanism in the majority of the cellular networks, which account for
	cellular networks (which account for hundreds of millions of users).		hundreds of millions of users ([ISOC]). NAT64/464XLAT offer
	NAT64/464XLAT offer different choices of deployment, depending on		different choices of deployment, depending on each network case,
	each network case, needs and requirements. Despite that, this		needs and requirements. Despite that, this document is not an
	document is not an explicit recommendation for using this choice		explicit recommendation for using this choice versus other IPv4aaS
	versus other IPv4aaS transition mechanisms. Instead, this document		transition mechanisms. Instead, this document is a guide that
	is a guide that facilitates evaluating a possible implementation of		facilitates evaluating a possible implementation of NAT64/464XLAT and
	NAT64/464XLAT and key decision points about specific design		key decision points about specific design considerations for its
	considerations for its deployment.		deployment.
	Depending on the specific requirements of each deployment case, DNS64		Depending on the specific requirements of each deployment case, DNS64
	may be a required function, while in other cases the adverse effects		may be a required function, while in other cases the adverse effects
	may be counterproductive. Similarly, in some cases a NAT64 function,		may be counterproductive. Similarly, in some cases a NAT64 function,
	together with a DNS64 function, may be a valid solution, when there		together with a DNS64 function, may be a valid solution, when there
	is a certainty that IPv4-only hosts or applications do not need to be		is a certainty that IPv4-only hosts or applications do not need to be
	supported (Section 4.6 and Section 4.7). However, in other cases		supported (Section 4.6 and Section 4.7). However, in other cases
	(i.e. IPv4-only devices or applications need to be supported), the		(i.e. IPv4-only devices or applications need to be supported), the
	limitations of NAT64/DNS64, may suggest the operator to look into		limitations of NAT64/DNS64, may suggest the operator to look into
	464XLAT as a more complete solution.		464XLAT as a more complete solution.
	skipping to change at page 30, line 6 ¶		skipping to change at page 30, line 6 ¶
	This "increased performance" approach has the disadvantage of		This "increased performance" approach has the disadvantage of
	potentially breaking DNSSEC for a small percentage of validating end-		potentially breaking DNSSEC for a small percentage of validating end-
	hosts versus the small impact of a double translation taking place in		hosts versus the small impact of a double translation taking place in
	the CE. If CE performance is not an issue, which is the most		the CE. If CE performance is not an issue, which is the most
	frequent case, then a much safer approach is to not use DNS64 at all,		frequent case, then a much safer approach is to not use DNS64 at all,
	and consequently, ensure that all the IPv4 traffic is translated at		and consequently, ensure that all the IPv4 traffic is translated at
	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 the 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
	accessible. Instead, it will continue to work in the case of		accessible. Instead, it will continue to work in the case of
	464XLAT.		464XLAT.
	Similar considerations need to be taken regarding the usage of a		Similar considerations need to be taken regarding the usage of a
	skipping to change at page 31, line 44 ¶		skipping to change at page 31, line 44 ¶
	function is reachable for the host, the problem goes away.		function is reachable for the host, the problem goes away.
	Whenever feasible, using EAM ([RFC7757]) as indicated in Section 4.9,		Whenever feasible, using EAM ([RFC7757]) as indicated in Section 4.9,
	provides a very relevant optimization, avoiding double-translations.		provides a very relevant optimization, avoiding double-translations.
	Applications that require incoming connections, typically already		Applications that require incoming connections, typically already
	provide means for that. However, PCP and EAM, as indicated in		provide means for that. However, PCP and EAM, as indicated in
	Section 4.10, are valid alternatives, even for creating explicit		Section 4.10, are valid alternatives, even for creating explicit
	mappings for customers that require them.		mappings for customers that require them.
	6. Deployment of NAT64 in Enterprise Networks		6. Deployment of 464XLAT/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),
	and for whatever reasons, there is a need to provide "IPv6-only		and for whatever reasons, there is a need to provide "IPv6-only
	access" to any part of that network or it is IPv6-only connected to		access" to any part of that network or it is IPv6-only connected to
	skipping to change at page 33, line 19 ¶		skipping to change at page 33, line 19 ¶
	| | + +--------+ CLAT | +--------+ NAT64 |		| | + +--------+ CLAT | +--------+ NAT64 |
	| | IPv4 | | | | only | |		| | IPv4 | | | | only | |
	| +----------+ +----------+ | +----------+		| +----------+ +----------+ | +----------+
	+----------------------------------+		+----------------------------------+
	Figure 16: DS enterprise with CLAT, IPv6-only Access, without DNS64		Figure 16: DS enterprise with CLAT, IPv6-only Access, without DNS64
	7. Security Considerations		7. Security Considerations
	This document does not have new specific security considerations		This document does not have new specific security considerations
	beyond those already reported by each of the documents cited.		beyond those already reported by each of the documents cited. For
			example, DNS64 ([RFC6147]) already describes the DNSSEC issues.
			Note that, as already described in Section 4.4, there may be
			undesirable interactions, specially if using VPNs or DNS privacy,
			which may impact in the correct performance of DNS64/NAT64.
	It should be remarked that the use of a DNS64 function has equivalent		It should be remarked that the use of a DNS64 function has equivalent
	privacy considerations as in the case of a regular DNS, either		privacy considerations as in the case of a regular DNS, either
	located in the service provider or an external one.		located in the service provider or an external one.
	8. IANA Considerations		8. IANA Considerations
	This document does not have any new specific IANA considerations.		This document does not have any new specific IANA considerations.
	Note: This section is assuming that https://www.rfc-		Note: This section is assuming that https://www.rfc-
	skipping to change at page 43, line 21 ¶		skipping to change at page 43, line 21 ¶
	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. and J. Linkova, "Discovering PREF64 in Router		Colitti, L. and J. Linkova, "Discovering PREF64 in Router
	Advertisements", draft-ietf-6man-ra-pref64-01 (work in		Advertisements", draft-ietf-6man-ra-pref64-01 (work in
	progress), June 2019.		progress), June 2019.
			[I-D.ietf-tram-stunbis]
			Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing,
			D., Mahy, R., and P. Matthews, "Session Traversal
			Utilities for NAT (STUN)", draft-ietf-tram-stunbis-21
			(work in progress), March 2019.
	[I-D.ietf-tram-turnbis]		[I-D.ietf-tram-turnbis]
	K, R., Johnston, A., Matthews, P., and J. Rosenberg,		K, R., Johnston, A., Matthews, P., and J. Rosenberg,
	"Traversal Using Relays around NAT (TURN): Relay		"Traversal Using Relays around NAT (TURN): Relay
	Extensions to Session Traversal Utilities for NAT (STUN)",		Extensions to Session Traversal Utilities for NAT (STUN)",
	draft-ietf-tram-turnbis-27 (work in progress), June 2019.		draft-ietf-tram-turnbis-27 (work in progress), June 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-02 (work in progress),		intarea-nat64-prefix-dhcp-option-02 (work in progress),
	skipping to change at page 43, line 49 ¶		skipping to change at page 44, line 10 ¶
	[I-D.palet-v6ops-464xlat-opt-cdn-caches]		[I-D.palet-v6ops-464xlat-opt-cdn-caches]
	Palet, J. and A. D'Egidio, "464XLAT Optimization", draft-		Palet, J. and A. D'Egidio, "464XLAT Optimization", draft-
	palet-v6ops-464xlat-opt-cdn-caches-02 (work in progress),		palet-v6ops-464xlat-opt-cdn-caches-02 (work in progress),
	June 2019.		June 2019.
	[I-D.vixie-dns-rpz]		[I-D.vixie-dns-rpz]
	Vixie, P. and V. Schryver, "DNS Response Policy Zones		Vixie, P. and V. Schryver, "DNS Response Policy Zones
	(RPZ)", draft-vixie-dns-rpz-04 (work in progress),		(RPZ)", draft-vixie-dns-rpz-04 (work in progress),
	December 2016.		December 2016.
			[ISOC] ISOC, "State of IPv6 Deployment 2018", 2018,
			<https://www.internetsociety.org/resources/2018/
			state-of-ipv6-deployment-2018/>.
	[RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar,		[RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar,
	"Analysis of Stateful 64 Translation", RFC 6889,		"Analysis of Stateful 64 Translation", RFC 6889,
	DOI 10.17487/RFC6889, April 2013,		DOI 10.17487/RFC6889, April 2013,
	<https://www.rfc-editor.org/info/rfc6889>.		<https://www.rfc-editor.org/info/rfc6889>.
	[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>.
End of changes. 15 change blocks.
	25 lines changed or deleted		40 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/