draft-ietf-v6ops-siit-dc-2xlat-01.txt		draft-ietf-v6ops-siit-dc-2xlat-02.txt
	IPv6 Operations T. Anderson		IPv6 Operations T. Anderson
	Internet-Draft Redpill Linpro		Internet-Draft Redpill Linpro
	Intended status: Informational S. Steffann		Intended status: Informational S. Steffann
	Expires: December 30, 2015 S.J.M. Steffann Consultancy		Expires: April 14, 2016 S.J.M. Steffann Consultancy
	June 28, 2015		October 12, 2015
	SIIT-DC: Dual Translation Mode		SIIT-DC: Dual Translation Mode
	draft-ietf-v6ops-siit-dc-2xlat-01		draft-ietf-v6ops-siit-dc-2xlat-02
	Abstract		Abstract
	This document describes an extension of the Stateless IP/ICMP		This document describes an extension of the Stateless IP/ICMP
	Translation for IPv6 Internet Data Centre Environments architecture		Translation for IPv6 Internet Data Centre Environments architecture
	(SIIT-DC), which allows applications, protocols, or nodes that are		(SIIT-DC), which allows applications, protocols, or nodes that are
	incompatible with IPv6, and/or Network Address Translation to operate		incompatible with IPv6, and/or Network Address Translation to operate
	correctly in an SIIT-DC environment. This is accomplished by		correctly in an SIIT-DC environment. This is accomplished by
	introducing a new component called an SIIT-DC Edge Relay, which		introducing a new component called an SIIT-DC Edge Relay, which
	reverses the translations made by an SIIT-DC Border Relay. The		reverses the translations made by an SIIT-DC Border Relay. The
	skipping to change at page 1, line 42		skipping to change at page 1, line 42
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 December 30, 2015.		This Internet-Draft will expire on April 14, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 21		skipping to change at page 2, line 21
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Edge Relay Description . . . . . . . . . . . . . . . . . . . 4		3. Edge Relay Description . . . . . . . . . . . . . . . . . . . 4
	3.1. Node-Based Edge Relay . . . . . . . . . . . . . . . . . . 5		3.1. Node-Based Edge Relay . . . . . . . . . . . . . . . . . . 5
	3.2. Network-Based Edge Relay . . . . . . . . . . . . . . . . 6		3.2. Network-Based Edge Relay . . . . . . . . . . . . . . . . 7
	3.2.1. Edge Router "On A Stick" . . . . . . . . . . . . . . 7		3.2.1. Edge Router "On A Stick" . . . . . . . . . . . . . . 8
	3.2.2. Edge Router that Bridges IPv6 Packets . . . . . . . . 8		3.2.2. Edge Router that Bridges IPv6 Packets . . . . . . . . 9
	4. Deployment Considerations . . . . . . . . . . . . . . . . . . 9		4. Deployment Considerations . . . . . . . . . . . . . . . . . . 9
	4.1. IPv6 Path MTU . . . . . . . . . . . . . . . . . . . . . . 9		4.1. IPv6 Path MTU . . . . . . . . . . . . . . . . . . . . . . 9
	4.2. IPv4 MTU . . . . . . . . . . . . . . . . . . . . . . . . 10		4.2. IPv4 MTU . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.3. IPv4 Identification Header . . . . . . . . . . . . . . . 10		4.3. IPv4 Identification Header . . . . . . . . . . . . . . . 10
	5. Intra-IDC IPv4 Communication . . . . . . . . . . . . . . . . 10		5. Intra-IDC IPv4 Communication . . . . . . . . . . . . . . . . 10
	5.1. Hairpinning by the SIIT-DC Border Relay . . . . . . . . . 10		5.1. Hairpinning by the SIIT-DC Border Relay . . . . . . . . . 10
	5.2. Additional EAMs Configured in Edge Relay . . . . . . . . 11		5.2. Additional EAMs Configured in Edge Relay . . . . . . . . 11
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 13		8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	8.1. Address Spoofing . . . . . . . . . . . . . . . . . . . . 13
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . 14
	9.2. Informative References . . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . 14
	Appendix A. Examples: Network-Based IPv4 Connectivity . . . . . 15		Appendix A. Examples: Network-Based IPv4 Connectivity . . . . . 15
	A.1. Subnet with IPv4 Service Addresses . . . . . . . . . . . 15		A.1. Subnet with IPv4 Service Addresses . . . . . . . . . . . 16
	A.2. Subnet with Unrouted IPv4 Addresses . . . . . . . . . . . 16		A.2. Subnet with Unrouted IPv4 Addresses . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	SIIT-DC [I-D.ietf-v6ops-siit-dc] describes an architecture where		SIIT-DC [I-D.ietf-v6ops-siit-dc] describes an architecture where
	IPv4-only users can access IPv6-only services through a stateless		IPv4-only users can access IPv6-only services through a stateless
	translator called an SIIT-DC Border Relay (BR). This approach has		translator called an SIIT-DC Border Relay (BR). This approach has
	certain limitations, however. In particular, the following cases		certain limitations, however. In particular, the following cases
	will work poorly or not at all:		will work poorly or not at all:
	skipping to change at page 3, line 32		skipping to change at page 3, line 32
	translations and forward them to the IPv4 client. The node or		translations and forward them to the IPv4 client. The node or
	application is thus provided with "virtual" IPv4 Internet		application is thus provided with "virtual" IPv4 Internet
	connectivity that retains end-to-end transparency for the IPv4		connectivity that retains end-to-end transparency for the IPv4
	addresses.		addresses.
	2. Terminology		2. Terminology
	This document makes use of the following terms:		This document makes use of the following terms:
	SIIT-DC Border Relay (BR)		SIIT-DC Border Relay (BR)
	A device or a logical function that translates traffic between		A device or a logical function that performs stateless protocol
	IPv4 clients and IPv6 services. See [I-D.ietf-v6ops-siit-dc].		translation between IPv4 and IPv6. It MUST do so in accordance
			with [RFC6145] and [I-D.ietf-v6ops-siit-eam].
	SIIT-DC Edge Relay (ER)		SIIT-DC Edge Relay (ER)
	A device or logical function that provides "native" IPv4		A device or logical function that provides "native" IPv4
	connectivity to IPv4-only nodes or applications. It functions in		connectivity to IPv4-only devices or application software. It is
	the same way as a BR, but is located close to the IPv4-only nodes/		very similar in function to a BR, but is typically located close
	applications it is supporting rather than on the network border.		to the IPv4-only component(s) it is supporting rather than on the
			IDC's outer network border. An ER may be either Node-Based
			(Section 3.1) or Network-Based (Section 3.2).
	IPv4 Service Address		IPv4 Service Address
	An IPv4 address representing an IPv6 service, with which IPv4-only		An IPv4 address representing a node or service located in an IPv6
	clients communicates. It is coupled with an IPv6 Service Address		network. It is coupled with an IPv6 Service Address using an EAM.
	using an EAM. Packets sent to this address is translated to IPv6		Packets sent to this address is translated to IPv6 by the BR, and
	by the BR and possibly back to IPv4 again by the ER, and vice		possibly back to IPv4 by an ER, before reaching the node or
	versa in the opposite direction.		service.
	IPv6 Service Address		IPv6 Service Address
	An IPv6 address assigned to an application, node, or service;		An IPv6 address assigned to an application, node, or service;
	either directly or indirectly (through an ER). It is coupled with		either directly or indirectly (through an ER). It is coupled with
	an IPv4 Service Address using an EAM. IPv4-only clients		an IPv4 Service Address using an EAM. IPv4-only clients
	communicates with the IPv6 Service Address through SIIT-DC.		communicates with the IPv6 Service Address through SIIT-DC.
	Explicit Address Mapping (EAM)		Explicit Address Mapping (EAM)
	A bi-directional coupling between an IPv4 Service Address and an		A bi-directional coupling between an IPv4 Service Address and an
	IPv6 Service Address configured in an BR/ER. When translating		IPv6 Service Address configured in a BR or ER. When translating
	between IPv4 and IPv6, the BR/ER changes the address fields in the		between IPv4 and IPv6, the BR/ER changes the address fields in the
	translated packet's IP header according to any matching EAM. The		translated packet's IP header according to any matching EAM. The
	EAM algorithm is specified in [I-D.ietf-v6ops-siit-eam].		EAM algorithm is specified in [I-D.ietf-v6ops-siit-eam].
	Translation Prefix		Translation Prefix
	An IPv6 prefix into which the entire IPv4 address space is mapped,		An IPv6 prefix into which the entire IPv4 address space is mapped,
	according to the algorithm in [RFC6052]. The Translation Prefix		according to the algorithm in [RFC6052]. The Translation Prefix
	is routed to the BR's IPv6 interface. When translating between		is routed to the BR's IPv6 interface. When translating between
	IPv4 and IPv6, an BR/ER will insert/remove the Translation Prefix		IPv4 and IPv6, an BR/ER will insert/remove the Translation Prefix
	into/from the address fields in the translated packet's IP header,		into/from the address fields in the translated packet's IP header,
	skipping to change at page 9, line 42		skipping to change at page 9, line 46
	Discovery [RFC4861] messages for them) and routed through the		Discovery [RFC4861] messages for them) and routed through the
	translation function before being forwarded out its downstream		translation function before being forwarded out its downstream
	interface as IPv4 packets. The downstream network segment thus		interface as IPv4 packets. The downstream network segment thus
	becomes dual-stacked.		becomes dual-stacked.
	4. Deployment Considerations		4. Deployment Considerations
	4.1. IPv6 Path MTU		4.1. IPv6 Path MTU
	The IPv6 Path MTU between the ER and the BR will typically be larger		The IPv6 Path MTU between the ER and the BR will typically be larger
	than the default value defined in Section 4 of [RFC6145] (1280), as		than the default value defined in Section 4 of [RFC6145] (1280
	it will typically contained within a single administrative domain.		bytes), as it will typically contained within a single administrative
	Therefore, it is RECOMMENDED that the IPv6 Path MTU configured in the		domain. Therefore, it is RECOMMENDED that the IPv6 Path MTU
	ER is raised accordingly. It is RECOMMENDED that the ER and the BR		configured in the ER is raised accordingly. It is RECOMMENDED that
	use identical configured IPv6 Path MTU values.		the ER and the BR use identical configured IPv6 Path MTU values.
	4.2. IPv4 MTU		4.2. IPv4 MTU
	In order to avoid IPv6 fragmentation, an ER SHOULD ensure that the		In order to avoid IPv6 fragmentation, an ER SHOULD ensure that the
	IPv4 MTU used by applications or nodes is equal to the configured		IPv4 MTU used by applications or nodes is equal to the configured
	IPv6 Path MTU - 20, so that an maximum-sized IPv4 packet can fit in		IPv6 Path MTU - 20, so that an maximum-sized IPv4 packet can fit in
	an unfragmented IPv6 packet. This ensures that the application may		an unfragmented IPv6 packet. This ensures that the application may
	do its part in avoiding IP-level fragmentation from occurring, e.g.,		do its part in avoiding IP-level fragmentation from occurring, e.g.,
	by segmenting/fragmenting outbound packets at the application layer,		by segmenting/fragmenting outbound packets at the application layer,
	and advertising the maximum size its peer may use for inbound packets		and advertising the maximum size its peer may use for inbound packets
	skipping to change at page 11, line 4		skipping to change at page 11, line 4
	Although SIIT-DC is primarily intended to facilitate communication		Although SIIT-DC is primarily intended to facilitate communication
	between IPv4-only nodes on the Internet and services located in an		between IPv4-only nodes on the Internet and services located in an
	IPv6-only IDC network, an IPv4-only node or application located		IPv6-only IDC network, an IPv4-only node or application located
	behind an ER might need to communicate with other nodes or services		behind an ER might need to communicate with other nodes or services
	in the IDC. The IPv4-only node or application will need to so		in the IDC. The IPv4-only node or application will need to so
	through the ER, as it will typically be incapable to contact IPv6		through the ER, as it will typically be incapable to contact IPv6
	destinations directly. The following subsections discusses various		destinations directly. The following subsections discusses various
	methods on how to facilitate such communication.		methods on how to facilitate such communication.
	5.1. Hairpinning by the SIIT-DC Border Relay		5.1. Hairpinning by the SIIT-DC Border Relay
	If the BR supports hairpinning as described in Section 4.2 of I-D		If the BR supports hairpinning as described in Section 4.2 of
	.ietf-v6ops-siit-eam [I-D.ietf-v6ops-siit-eam], the easiest solution		[I-D.ietf-v6ops-siit-eam], the easiest solution is to make the target
	is to make the target service available through SIIT-DC in the normal		service available through SIIT-DC in the normal way, that is, by
	way, that is, by provisioning an EAM to the BR that assigns an IPv4		provisioning an EAM to the BR that assigns an IPv4 Service Address
	Service Address with the target service's IPv6 Service Address.		with the target service's IPv6 Service Address.
	This allows the IPv4-only node or application to transmit packets		This allows the IPv4-only node or application to transmit packets
	destined for the target service's IPv4 Service Address, which the ER		destined for the target service's IPv4 Service Address, which the ER
	will then translate to a corresponding IPv4-converted IPv6 address by		will then translate to a corresponding IPv4-converted IPv6 address by
	inserting the Translation Prefix [RFC6052]. When this IPv6 packet		inserting the Translation Prefix [RFC6052]. When this IPv6 packet
	reaches the BR, it will be hairpinned and transmitted back to the		reaches the BR, it will be hairpinned and transmitted back to the
	target service's IPv6 Service Address (where it could possibly pass		target service's IPv6 Service Address (where it could possibly pass
	through another ER before reaching the target service). Return		through another ER before reaching the target service). Return
	traffic from the target service will be hairpinned in the same		traffic from the target service will be hairpinned in the same
	fashion.		fashion.
	skipping to change at page 13, line 35		skipping to change at page 13, line 35
	6. Acknowledgements		6. Acknowledgements
	The author would like to especially thank the authors of 464XLAT		The author would like to especially thank the authors of 464XLAT
	[RFC6877]: Masataka Mawatari, Masanobu Kawashima, and Cameron Byrne.		[RFC6877]: Masataka Mawatari, Masanobu Kawashima, and Cameron Byrne.
	The architecture described by this document is merely an adaptation		The architecture described by this document is merely an adaptation
	of their work to a data centre environment, and could not have		of their work to a data centre environment, and could not have
	happened without them.		happened without them.
	The author would like also to thank the following individuals for		The author would like also to thank the following individuals for
	their contributions, suggestions, corrections, and criticisms: Fred		their contributions, suggestions, corrections, and criticisms: Fred
	Baker, Tobias Brox, Ray Hunter, Shucheng LIU (Will), Andrew		Baker, Tobias Brox, Olafur Gudmundsson, Christer Holmberg, Ray
	Yourtchenko.		Hunter, Shucheng LIU (Will), Andrew Yourtchenko.
	7. IANA Considerations		7. IANA Considerations
	This draft makes no request of the IANA. The RFC Editor may remove		This draft makes no request of the IANA.
	this section prior to publication.
	8. Security Considerations		8. Security Considerations
	This section discusses security considerations specific to the use of		This section discusses security considerations specific to the use of
	an ER. See the Security Considerations section in		an ER. See the Security Considerations section in
	[I-D.ietf-v6ops-siit-dc] for additional security considerations		[I-D.ietf-v6ops-siit-dc] for security considerations applicable to
	applicable to the SIIT-DC architecture in general.		the SIIT-DC architecture in general.
	8.1. Address Spoofing
	If the ER receives an IPv4 packet from the application/node from a		If the ER receives an IPv4 packet from the application/node from a
	source address it does not have an EAM for, both the source and		source address it does not have an EAM for, both the source and
	destination addresses will be rewritten according to [RFC6052].		destination addresses will be rewritten according to [RFC6052].
	After undergoing the reverse translation in the BR, the resulting		After undergoing the reverse translation in the BR, the resulting
	IPv4 packet routed to the IPv4 network will have a spoofed IPv4		IPv4 packet routed to the IPv4 network will have a spoofed IPv4
	source address. The ER SHOULD therefore ensure that ingress		source address. The ER SHOULD therefore ensure that ingress
	filtering [RFC2827] is used on the ER's IPv4 interface, so that such		filtering [RFC2827] is used on the ER's IPv4 interface, so that such
	packets are immediately discarded.		packets are immediately discarded.
	If the ER receives an IPv6 packet with both the source and		If the ER receives an IPv6 packet with both the source and
	skipping to change at page 14, line 31		skipping to change at page 14, line 27
	IPv6 Service Addresses, or 2) after translation from IPv6 to IPv4,		IPv6 Service Addresses, or 2) after translation from IPv6 to IPv4,
	equal to any of its local IPv4 Service Addresses.		equal to any of its local IPv4 Service Addresses.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-v6ops-siit-dc]		[I-D.ietf-v6ops-siit-dc]
	Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for		Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for
	IPv6 Data Centre Environments", draft-ietf-v6ops-siit-		IPv6 Data Centre Environments", draft-ietf-v6ops-siit-
	dc-00 (work in progress), December 2014.		dc-02 (work in progress), August 2015.
	[I-D.ietf-v6ops-siit-eam]		[I-D.ietf-v6ops-siit-eam]
	Anderson, T. and A. Leiva, "Explicit Address Mappings for		Anderson, T. and A. Leiva, "Explicit Address Mappings for
	Stateless IP/ICMP Translation", draft-ietf-v6ops-siit-		Stateless IP/ICMP Translation", draft-ietf-v6ops-siit-
	eam-00 (work in progress), May 2015.		eam-01 (work in progress), June 2015.
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
			RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	9.2. Informative References		9.2. Informative References
	[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or		[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
	converting network protocol addresses to 48.bit Ethernet		Converting Network Protocol Addresses to 48.bit Ethernet
	address for transmission on Ethernet hardware", STD 37,		Address for Transmission on Ethernet Hardware", STD 37,
	RFC 826, November 1982.		RFC 826, DOI 10.17487/RFC0826, November 1982,
			<http://www.rfc-editor.org/info/rfc826>.
	[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and		[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
	E. Lear, "Address Allocation for Private Internets", BCP		and E. Lear, "Address Allocation for Private Internets",
	5, RFC 1918, February 1996.		BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
			<http://www.rfc-editor.org/info/rfc1918>.
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
	2131, March 1997.		2131, DOI 10.17487/RFC2131, March 1997,
			<http://www.rfc-editor.org/info/rfc2131>.
	[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor		[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
	Extensions", RFC 2132, March 1997.		Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
			<http://www.rfc-editor.org/info/rfc2132>.
	[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:		[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
	Defeating Denial of Service Attacks which employ IP Source		Defeating Denial of Service Attacks which employ IP Source
	Address Spoofing", BCP 38, RFC 2827, May 2000.		Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
			May 2000, <http://www.rfc-editor.org/info/rfc2827>.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	September 2007.		DOI 10.17487/RFC4861, September 2007,
			<http://www.rfc-editor.org/info/rfc4861>.
	[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,
	October 2010.		DOI 10.17487/RFC6052, October 2010,
			<http://www.rfc-editor.org/info/rfc6052>.
	[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation		[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
	Algorithm", RFC 6145, April 2011.		Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
			<http://www.rfc-editor.org/info/rfc6145>.
	[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, February 2012.		Using "Bump-in-the-Host" (BIH)", RFC 6535, DOI 10.17487/
			RFC6535, February 2012,
			<http://www.rfc-editor.org/info/rfc6535>.
	[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,		[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
	"Default Address Selection for Internet Protocol Version 6		"Default Address Selection for Internet Protocol Version 6
	(IPv6)", RFC 6724, September 2012.		(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
			<http://www.rfc-editor.org/info/rfc6724>.
	[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:		[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
	Combination of Stateful and Stateless Translation", RFC		Combination of Stateful and Stateless Translation", RFC
	6877, April 2013.		6877, DOI 10.17487/RFC6877, April 2013,
			<http://www.rfc-editor.org/info/rfc6877>.
	[RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335,		[RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335, DOI
	August 2014.		10.17487/RFC7335, August 2014,
			<http://www.rfc-editor.org/info/rfc7335>.
	Appendix A. Examples: Network-Based IPv4 Connectivity		Appendix A. Examples: Network-Based IPv4 Connectivity
	A.1. Subnet with IPv4 Service Addresses		A.1. Subnet with IPv4 Service Addresses
	One relatively straight-forward way to provide IPv4 connectivity		One relatively straight-forward way to provide IPv4 connectivity
	between the ER and the IPv4 node(s) it serves is to ensure the IPv4		between the ER and the IPv4 node(s) it serves is to ensure the IPv4
	Service Address(es) can be enclosed within a larger IPv4 prefix. The		Service Address(es) can be enclosed within a larger IPv4 prefix. The
	ER may then claim one address in this prefix for itself, and use it		ER may then claim one address in this prefix for itself, and use it
	to provide an IPv4 default router address. The ER may then proceed		to provide an IPv4 default router address. The ER may then proceed
	to assign the IPv4 Service Address(es) to its downstream node(s)		to assign the IPv4 Service Address(es) to its downstream node(s)
	using DHCPv4 [RFC2131]. For example, if the IPv4 Service Addresses		using DHCPv4 [RFC2131]. For example, if the IPv4 Service Addresses
	are 192.0.2.26 and 192.0.2.27, the ER would configure the address		are 192.0.2.26 and 192.0.2.27, the ER would configure the address
	192.0.2.25/29 on its IPv4-facing interface and would add the two IPv4		192.0.2.25/29 on its IPv4-facing interface and would add the two IPv4
	Service Addresses to its DHCPv4 pool.		Service Addresses to its DHCPv4 pool.
End of changes. 34 change blocks.
	59 lines changed or deleted		74 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/