draft-ietf-v6ops-nat64-deployment-00.txt		draft-ietf-v6ops-nat64-deployment-01.txt
	v6ops J. Palet Martinez		v6ops J. Palet Martinez
	Internet-Draft The IPv6 Company		Internet-Draft The IPv6 Company
	Intended status: Informational July 2, 2018		Intended status: Informational August 13, 2018
	Expires: January 3, 2019		Expires: February 14, 2019
	NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks		NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks
	draft-ietf-v6ops-nat64-deployment-00		draft-ietf-v6ops-nat64-deployment-01
	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 January 3, 2019.		This Internet-Draft will expire on February 14, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 47 ¶		skipping to change at page 2, line 47 ¶
	5. Summary of Deployment Recommendations for NAT64 . . . . . . . 23		5. Summary of Deployment Recommendations for NAT64 . . . . . . . 23
	6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 25		6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 25
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 27		7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
	10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 27		10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 27
	11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 30		11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 30
	12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 31		12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 31
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
	13.1. Normative References . . . . . . . . . . . . . . . . . . 31		13.1. Normative References . . . . . . . . . . . . . . . . . . 31
	13.2. Informative References . . . . . . . . . . . . . . . . . 33		13.2. Informative References . . . . . . . . . . . . . . . . . 32
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34
	1. Introduction		1. Introduction
	NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation,		NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation,
	which allows IPv6-only hosts to contact IPv4 servers using unicast		which allows IPv6-only hosts to contact IPv4 servers using unicast
	UDP, TCP or ICMP, by means of a single or a set of IPv4 public		UDP, TCP or ICMP, by means of a single or a set of IPv4 public
	addresses assigned to the translator, to be shared by the IPv6-only		addresses assigned to the translator, to be shared by the IPv6-only
	clients.		clients.
	skipping to change at page 3, line 28 ¶		skipping to change at page 3, line 28 ¶
	DNS64 ([RFC6147]), is in charge of the synthesis of AAAA records from		DNS64 ([RFC6147]), is in charge of the synthesis of AAAA records from
	the A records, avoiding changes in both, the IPv6-only hosts and the		the A records, avoiding changes in both, the IPv6-only hosts and the
	IPv4-only server, so they can use a NAT64.		IPv4-only server, so they can use a NAT64.
	However, the use of NAT64 and/or DNS64 present three issues:		However, the use of NAT64 and/or DNS64 present three issues:
	a. Because DNS64 ([RFC6147]) modifies DNS answers, and DNSSEC is		a. Because DNS64 ([RFC6147]) modifies DNS answers, and DNSSEC is
	designed to detect such modifications, DNS64 ([RFC6147]) can		designed to detect such modifications, DNS64 ([RFC6147]) can
	potentially break DNSSEC, depending on a number of factors, such		potentially break DNSSEC, depending on a number of factors, such
	as the location of the DNS64 function (at a DNS server or		as the location of the DNS64 function (at a DNS server or
	validator, at the end host, ...), how as been configured, if the		validator, at the end host, ...), how it has been configured, if
	end-hosts is validating, etc.		the end-hosts is validating, etc.
	b. Because the need of using DNS64 ([RFC6147]), there is a major		b. Because the need of using DNS64 ([RFC6147]), there is a major
	issue for NAT64 ([RFC6146]), as doesn't work when literal		issue for NAT64 ([RFC6146]), as doesn't work when literal
	addresses or non-IPv6 compliant APIs are being used.		addresses or non-IPv6 compliant APIs are being used.
	c. NAT64 alone, doesn't provide a solution for IPv4-only hosts or		c. NAT64 alone, doesn't provide a solution for IPv4-only hosts or
	applications located within a network which are connected to a		applications located within a network which are connected to a
	service provider IPv6-only access.		service provider IPv6-only access.
	The same issues are true if part of an enterprise or similar network,		The same issues are true if part of an enterprise or similar network,
	skipping to change at page 6, line 41 ¶		skipping to change at page 6, line 41 ¶
	+----------+ | +----------+		+----------+ | +----------+
	| | | | |		| | | | |
	| IPv6 +-------------+--------------+ IPv4 |		| IPv6 +-------------+--------------+ IPv4 |
	| | | |		| | | |
	+----------+ +----------+		+----------+ +----------+
	Figure 3: NAT64 and DNS64 in external provider		Figure 3: NAT64 and DNS64 in external provider
	One more equivalent scenario will be if the service provider offers		One more equivalent scenario will be if the service provider offers
	the NAT64 only, and the DNS64 function is from an external provider		the NAT64 only, and the DNS64 function is from an external provider
	with or without a specific agreement among them. This is an scenario		with or without a specific agreement among them. This is a scenario
	already feasible today, as several "global" service providers provide		already feasible today, as several "global" service providers provide
	free DNS64 services and users often configure manually their DNS.		free DNS64 services and users often configure manually their DNS.
	This will only work if both the NAT64 and the DNS64 are using the		This will only work if both the NAT64 and the DNS64 are using the
	same WKP (Well-Known Prefix) or NSP (Network-Specific Prefix). All		same WKP (Well-Known Prefix) or NSP (Network-Specific Prefix). All
	the considerations in the previous paragraphs of this section are the		the considerations in the previous paragraphs of this section are the
	same for this sub-case.		same for this sub-case.
	Of course, if the external DNS64 is agreed with the service provider,		Of course, if the external DNS64 is agreed with the service provider,
	then we are in the same case as in the previous ones already depicted		then we are in the same case as in the previous ones already depicted
	in this scenario.		in this scenario.
	skipping to change at page 8, line 18 ¶		skipping to change at page 8, line 18 ¶
	the end-user device applications can access IPv4-only end-networks/		the end-user device applications can access IPv4-only end-networks/
	applications, despite those applications or devices use literal IPv4		applications, despite those applications or devices use literal IPv4
	addresses or non-IPv6 compliant APIs.		addresses or non-IPv6 compliant APIs.
	In addition to that, in the same example of the cellular network		In addition to that, in the same example of the cellular network
	above, if the User Equipment (UE) provides tethering, other devices		above, if the User Equipment (UE) provides tethering, other devices
	behind it will be presented with a traditional NAT44, in addition to		behind it will be presented with a traditional NAT44, in addition to
	the native IPv6 support, so clearly it allows IPv4-only hosts inside		the native IPv6 support, so clearly it allows IPv4-only hosts inside
	the IPv6-only access network.		the IPv6-only access network.
	Furthermore, as indicated in [RFC6877] (464XLAT), can be used in		Furthermore, as indicated in [RFC6877], 464XLAT can be used in
	broadband IPv6 network architectures, by implementing the CLAT		broadband IPv6 network architectures, by implementing the CLAT
	functionality at the CE.		functionality at the CE.
	In order to understand all the communication possibilities, let's		In order to understand all the communication possibilities, let's
	assume the following representation of two dual-stack peers:		assume the following representation of two dual-stack peers:
	+-------+ .-----. .-----.		+-------+ .-----. .-----.
	| | / \ / \		| | / \ / \
	.-----. | Res./ | / IPv6- \ .-----. / IPv4- \		.-----. | Res./ | / IPv6- \ .-----. / IPv4- \
	/ Local \ | SOHO +--( only )---( NAT64 )---( only )		/ Local \ | SOHO +--( only )---( NAT64 )---( only )
	skipping to change at page 15, line 18 ¶		skipping to change at page 15, line 18 ¶
	the previous sections, by the Figure number. The possible values		the previous sections, by the Figure number. The possible values
	are:		are:
	- Scenario "bad" for that item.		- Scenario "bad" for that item.
	+ Scenario "good" for that item.		+ Scenario "good" for that item.
	Needs to be noted that in some cases "countermeasures", alternative		Needs to be noted that in some cases "countermeasures", alternative
	or special configurations, may be available for the items designated		or special configurations, may be available for the items designated
	as "bad", so this comparison is making a generic case, as a quick		as "bad", so this comparison is making a generic case, as a quick
	comparison guide. In some cases, a "bad" idem is not necessarily a		comparison guide. In some cases, a "bad" item is not necessarily a
	negative aspect, all it depends on the specific needs/characteristics		negative aspect, all it depends on the specific needs/characteristics
	of the network where the deployment will take place. For instance,		of the network where the deployment will take place. For instance,
	in a network which has only IPv6-only hosts and apps using only DNS		in a network which has only IPv6-only hosts and apps using only DNS
	and IPv6-compliant APIs, there is no impact using only NAT64 and		and IPv6-compliant APIs, there is no impact using only NAT64 and
	DNS64, but if the hosts may validate DNSSEC, that item is still		DNS64, but if the hosts may validate DNSSEC, that item is still
	relevant.		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 |
	+----------------+---+---+---+---+---+---+---+---+---+----+----+----+		+----------------+---+---+---+---+---+---+---+---+---+----+----+----+
	skipping to change at page 16, line 26 ¶		skipping to change at page 16, line 26 ¶
	If a device connected to an IPv6-only WAN queries for a domain name		If a device connected to an IPv6-only WAN queries for a domain name
	in a signed zone, by means of a recursive name server that supports		in a signed zone, by means of a recursive name server that supports
	DNS64, and the result is a synthesized AAAA record, and the recursive		DNS64, and the result is a synthesized AAAA record, and the recursive
	name server is configured to perform DNSSEC validation and has a		name server is configured to perform DNSSEC validation and has a
	valid chain of trust to the zone in question, it will		valid chain of trust to the zone in question, it will
	cryptographically validate the negative response from the		cryptographically validate the negative response from the
	authoritative name server. This is the expected DNS64 behavior: The		authoritative name server. This is the expected DNS64 behavior: The
	recursive name server actually lies to the client device. However,		recursive name server actually lies to the client device. However,
	in most of the cases, the client will not notice it, because		in most of the cases, the client will not notice it, because
	generally, they don't perform validation themselves an instead, rely		generally, they don't perform validation themselves and instead, rely
	on the recursive name servers.		on the recursive name servers.
	A validating DNS64 resolver in fact, increase the confidence on the		A validating DNS64 resolver in fact, increase the confidence on the
	synthetic AAAA, as it has validated that a non-synthetic AAAA for		synthetic AAAA, as it has validated that a non-synthetic AAAA for
	sure, doesn't exists. However, if the client device is		sure, doesn't exists. However, if the client device is
	NAT64-oblivious (most common case) and performs DNSSEC validation on		NAT64-oblivious (most common case) and performs DNSSEC validation on
	the AAAA record, it will fail as it is a synthesized record.		the AAAA record, it will fail as it is a synthesized record.
	The best possible scenario from DNSSEC point of view is when the		The best possible scenario from DNSSEC point of view is when the
	client requests the DNS64 server to perform the DNSSEC validation (by		client requests the DNS64 server to perform the DNSSEC validation (by
	skipping to change at page 24, line 4 ¶		skipping to change at page 24, line 4 ¶
	supported by the operator), in order to fully support the actual user		supported by the operator), in order to fully support the actual user
	needs (IPv4-only devices and applications, usage of literals and old		needs (IPv4-only devices and applications, usage of literals and old
	APIs), they SHOULD consider the 464XLAT scenario and in that case,		APIs), they SHOULD consider the 464XLAT scenario and in that case,
	MUST support the customer-side translator (CLAT).		MUST support the customer-side translator (CLAT).
	If the operator offers DNS services, in order to increase performance		If the operator offers DNS services, in order to increase performance
	by reducing the double translation for all the IPv4 traffic, they MAY		by reducing the double translation for all the IPv4 traffic, they MAY
	support DNS64 and avoid, as much as possible, breaking DNSSEC. In		support DNS64 and avoid, as much as possible, breaking DNSSEC. In
	this case, if the DNS service is offering DNSSEC validation, then it		this case, if the DNS service is offering DNSSEC validation, then it
	MUST be in such way that it is aware of the DNS64. This is		MUST be in such way that it is aware of the DNS64. This is
	considered de simpler and safer approach, and MAY be combined as well		considered the simpler and safer approach, and MAY be combined as
	with the other possible solutions described in this document:		well with the other possible solutions described in this document:
	o DNS infrastructure MUST be aware of DNS64 (Section 4.1.2).		o DNS infrastructure MUST be aware of DNS64 (Section 4.1.2).
	o Devices running CLAT SHOULD follow the indications in		o Devices running CLAT SHOULD follow the indications in
	Section 4.1.3 (Stub validator). However, this may be out of the		Section 4.1.3 (Stub validator). However, this may be out of the
	control of the operator.		control of the operator.
	o CEs SHOULD include a DNS proxy and validator (Section 4.1.4).		o CEs SHOULD include a DNS proxy and validator (Section 4.1.4).
	o Section 4.1.5 (ACL of clients) and Section 4.1.6 (Mapping-out IPv4		o Section 4.1.5 (ACL of clients) and Section 4.1.6 (Mapping-out IPv4
	skipping to change at page 30, line 42 ¶		skipping to change at page 30, line 42 ¶
	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, so it is suggested to use HNCP ([RFC8375]).		multiple IPv6 subnets, so it is suggested to use 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 draft-ietf-v6ops-transition-ipv4aas ...		simplified if the CE follows [I-D.ietf-v6ops-transition-ipv4aas].
	TBD.
	11. ANNEX B: CLAT Implementation		11. ANNEX B: CLAT Implementation
	TBD.
	A CLAT CE implementation basically requires support of [RFC7915] for		A CLAT CE implementation basically requires support of [RFC7915] for
	the NAT46 functionality, [RFC7050] for the PLAT prefix discovery		the NAT46 functionality, [RFC7050] for the PLAT prefix discovery
	(and/or [RFC7225] for PCP), and if stateless NAT46 is supported,		(and/or [RFC7225] for PCP), and if stateless NAT46 is supported,
	mechanisms to ensure that multiple /64 are available, such as		mechanisms to ensure that multiple /64 are available, such as
	DHCPv6-PD [RFC3633].		DHCPv6-PD [RFC3633].
	There are several OpenSource implementations of CLAT, such as:		There are several OpenSource implementations of CLAT, such as:
	Android: https://github.com/ddrown/android_external_android-clat.		Android: https://github.com/ddrown/android_external_android-clat.
	Linux: https://github.com/toreanderson/clatd.		Linux: https://github.com/toreanderson/clatd.
	OpenWRT: https://github.com/openwrt-		OpenWRT: https://github.com/openwrt-
	routing/packages/blob/master/nat46/files/464xlat.sh.		routing/packages/blob/master/nat46/files/464xlat.sh.
	VPP: https://git.fd.io/vpp/tree/src/plugins/nat.		VPP: https://git.fd.io/vpp/tree/src/plugins/nat.
	12. ANNEX C: Benchmarking		12. ANNEX C: Benchmarking
	TBD.
	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. References		13. References
	13.1. Normative References		13.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,
	skipping to change at page 33, line 14 ¶		skipping to change at page 33, line 7 ¶
	13.2. Informative References		13.2. Informative References
	[About-DNS64]		[About-DNS64]
	J. Linkova, "Let's talk about IPv6 DNS64 & DNSSEC", 2016,		J. Linkova, "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		G. Lencse and Y. Kadobayashi, "Benchmarking DNS64
	Implementations: Theory and Practice", September 2018.		Implementations: Theory and Practice", Computer
			Communications (Elsevier), vol. 127, no. 1, pp. 61-74,
			DOI 10.1016/j.comcom.2018.05.005, September 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-05 (work in
	progress), June 2018.		progress), June 2018.
	[I-D.ietf-doh-dns-over-https]		[I-D.ietf-doh-dns-over-https]
	Hoffman, P. and P. McManus, "DNS Queries over HTTPS		Hoffman, P. and P. McManus, "DNS Queries over HTTPS
	(DoH)", draft-ietf-doh-dns-over-https-12 (work in		(DoH)", draft-ietf-doh-dns-over-https-12 (work in
	progress), June 2018.		progress), June 2018.
			[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-07
			(work in progress), August 2018.
	[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>.
	[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>.
	[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		G. Lencse 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
	stateful NAT64", September 2018.		stateful NAT64", Computers & Security (Elsevier), vol. 77,
			no. 1, pp. 397-411, DOI 10.1016/j.cose.2018.04.012, August
			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. 16 change blocks.
	21 lines changed or deleted		26 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/