draft-ietf-v6ops-siit-dc-2xlat-02.txt		rfc7756.txt
	IPv6 Operations T. Anderson		Internet Engineering Task Force (IETF) T. Anderson
	Internet-Draft Redpill Linpro		Request for Comments: 7756 Redpill Linpro
	Intended status: Informational S. Steffann		Category: Informational S. Steffann
	Expires: April 14, 2016 S.J.M. Steffann Consultancy		ISSN: 2070-1721 S.J.M. Steffann Consultancy
	October 12, 2015		February 2016
	SIIT-DC: Dual Translation Mode		Stateless IP/ICMP Translation for IPv6 Internet Data Center
	draft-ietf-v6ops-siit-dc-2xlat-02		Environments (SIIT-DC): Dual Translation Mode
	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 Center Environments (SIIT-DC)
	(SIIT-DC), which allows applications, protocols, or nodes that are		architecture, 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 with SIIT-DC. This is accomplished by introducing a new
	introducing a new component called an SIIT-DC Edge Relay, which		component called an SIIT-DC Edge Relay, which reverses the
	reverses the translations made by an SIIT-DC Border Relay. The		translations made by an SIIT-DC Border Relay. The application and/or
	application and/or node is thus provided with seemingly native IPv4		node is thus provided with seemingly native IPv4 connectivity that
	connectivity that provides end-to-end address transparency.		provides end-to-end address transparency.
	The reader is expected to be familiar with the SIIT-DC architecture		The reader is expected to be familiar with the SIIT-DC architecture
	described in I-D.ietf-v6ops-siit-dc.		described in RFC 7755.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This document is not an Internet Standards Track specification; it is
	provisions of BCP 78 and BCP 79.		published for informational purposes.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Not all documents
			approved by the IESG are a candidate for any level of Internet
			Standard; see Section 2 of RFC 5741.
	This Internet-Draft will expire on April 14, 2016.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc7756.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Edge Relay Description . . . . . . . . . . . . . . . . . . . 4		3. Edge Relay Description . . . . . . . . . . . . . . . . . . . 5
	3.1. Node-Based Edge Relay . . . . . . . . . . . . . . . . . . 5		3.1. Node-Based Edge Relay . . . . . . . . . . . . . . . . . . 6
	3.2. Network-Based Edge Relay . . . . . . . . . . . . . . . . 7		3.2. Network-Based Edge Relay . . . . . . . . . . . . . . . . 7
	3.2.1. Edge Router "On A Stick" . . . . . . . . . . . . . . 8		3.2.1. Edge Relay "on a Stick" . . . . . . . . . . . . . . . 8
	3.2.2. Edge Router that Bridges IPv6 Packets . . . . . . . . 9		3.2.2. Edge Relay 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 . . . . . . . . . 11
	5.2. Additional EAMs Configured in Edge Relay . . . . . . . . 11		5.2. Additional EAMs Configured in Edge Relay . . . . . . . . 12
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 13		7.1. Normative References . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		7.2. Informative References . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . 14		Appendix A. Examples: Network-Based IPv4 Connectivity . . . . . 16
	9.2. Informative References . . . . . . . . . . . . . . . . . 14
	Appendix A. Examples: Network-Based IPv4 Connectivity . . . . . 15
	A.1. Subnet with IPv4 Service Addresses . . . . . . . . . . . 16		A.1. Subnet with IPv4 Service Addresses . . . . . . . . . . . 16
	A.2. Subnet with Unrouted IPv4 Addresses . . . . . . . . . . . 16		A.2. Subnet with Unrouted IPv4 Addresses . . . . . . . . . . . 16
			Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	SIIT-DC [I-D.ietf-v6ops-siit-dc] describes an architecture where		SIIT-DC [RFC7755] describes an architecture where IPv4-only users can
	IPv4-only users can access IPv6-only services through a stateless		access IPv6-only services through a stateless translator called an
	translator called an SIIT-DC Border Relay (BR). This approach has		SIIT-DC Border Relay (BR). This approach has certain limitations,
	certain limitations, however. In particular, the following cases		however. In particular, the following cases will work poorly or not
	will work poorly or not at all:		at all:
	o Application protocols that do not support NAT (i.e., the lack of		o Application protocols that do not support NAT (i.e., the lack of
	end-to-end transparency of IP addresses).		end-to-end transparency of IP addresses).
	o Nodes that cannot connect to IPv6 networks at all, or that can		o Nodes that cannot connect to IPv6 networks at all or that can only
	only connect such networks if they also provide IPv4 connectivity		connect such networks if they also provide IPv4 connectivity
	(i.e., dual-stacked networks).		(i.e., dual-stacked networks).
	o Application software which makes use of legacy IPv4-only APIs, or		o Application software that makes use of legacy IPv4-only APIs or
	otherwise makes assumptions that IPv4 connectivity is available.		otherwise makes assumptions that IPv4 connectivity is available.
	By extending the SIIT-DC architecture with a new component called an		By extending the SIIT-DC architecture with a new component called an
	Edge Relay (ER), all of the above can be made to work correctly in an		Edge Relay (ER), all of the above can be made to work correctly in an
	otherwise IPv6-only network environment using SIIT-DC.		otherwise IPv6-only network environment using SIIT-DC.
	The purpose of the ER is to reverse the IPv4-to-IPv6 packet		The purpose of the ER is to reverse the IPv4-to-IPv6 packet
	translations previously done by the BR for traffic arriving from IPv4		translations previously done by the BR for traffic arriving from IPv4
	clients and forward this as "native" IPv4 to the node or application.		clients and forward this as "native" IPv4 to the node or application.
	In the reverse direction, IPv4 packets transmitted by the node or		In the reverse direction, IPv4 packets transmitted by the node or
	skipping to change at page 3, line 31		skipping to change at page 3, line 42
	before they are forwarded to the BR, which in turn will reverse the		before they are forwarded to the BR, which in turn will reverse the
	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 performs stateless protocol		A device or a logical function that performs stateless protocol
	translation between IPv4 and IPv6. It MUST do so in accordance		translation between IPv4 and IPv6. It MUST do so in accordance
	with [RFC6145] and [I-D.ietf-v6ops-siit-eam].		with [RFC6145] and [RFC7757].
	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 devices or application software. It is		connectivity to IPv4-only devices or application software. It is
	very similar in function to a BR, but is typically located close		very similar in function to a BR but is typically located close to
	to the IPv4-only component(s) it is supporting rather than on the		the IPv4-only component(s) it is supporting rather than on the
	IDC's outer network border. An ER may be either Node-Based		outer network border of the Internet Data Center (IDC). An ER may
	(Section 3.1) or Network-Based (Section 3.2).		be either node based (Section 3.1) or network based (Section 3.2).
	IPv4 Service Address		IPv4 Service Address:
	An IPv4 address representing a node or service located in an IPv6		An IPv4 address representing a node or service located in an IPv6
	network. It is coupled with an IPv6 Service Address using an EAM.		network. It is coupled with an IPv6 Service Address using an
	Packets sent to this address is translated to IPv6 by the BR, and		Explicit Address Mapping (EAM). Packets sent to this address are
	possibly back to IPv4 by an ER, before reaching the node or		translated to IPv6 by the BR, and possibly back to IPv4 by an ER,
	service.		before reaching the node or 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.		communicate 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 bidirectional coupling between an IPv4 Service Address and an
	IPv6 Service Address configured in a BR or 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 [RFC7757].
	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, a 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,
	unless an EAM exists for the IP address that is being translated.		unless an EAM exists for the IP address that is being translated.
	IPv4-converted IPv6 addresses		IPv4-Converted IPv6 Addresses:
	As defined in Section 1.3 of [RFC6052].		As defined in Section 1.3 of [RFC6052].
	IDC		IDC:
	Short for "Internet Data Centre"; a data centre whose main purpose		Short for "Internet Data Center"; a data center whose main purpose
	is to deliver services to the public Internet, the use case SIIT-		is to deliver services to the public Internet. SIIT-DC is
	DC is primarily targeted at. IDCs are typically operated by		primarily targeted at being deployed in an IDC. An IDC is
	Internet Content Providers or Managed Services Providers.		typically operated by an Internet Content Provider or a Managed
			Services Provider.
	SIIT		SIIT:
	The Stateless IP/ICMP Translation algorithm, as specified in		The Stateless IP/ICMP Translation Algorithm, as specified in
	[RFC6145].		[RFC6145].
	XLAT		XLAT:
	Short for "Translation". Used in figures to indicate where a BR/		Short for "Translation". Used in figures to indicate where a BR/
	ER uses SIIT [RFC6145] to translate IPv4 packets to IPv6 and vice		ER uses SIIT [RFC6145] to translate IPv4 packets to IPv6 and vice
	versa.		versa.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Edge Relay Description		3. Edge Relay Description
	An Edge Relay (ER) is at its core an implementation of the Stateless
	IP/ICMP Translation algorithm [RFC6145] that supports Explicit		An ER is at its core an implementation of the Stateless IP/ICMP
	Address Mappings [I-D.ietf-v6ops-siit-eam]. It provides virtual IPv4		Translation Algorithm [RFC6145] that supports Explicit Address
	connectivity for nodes or applications which require this to operate		Mappings [RFC7757]. It provides virtual IPv4 connectivity for nodes
	correctly in an SIIT-DC environment.		or applications that require this to operate correctly with SIIT-DC.
	Packets from the IPv4 Internet destined for an IPv4 Service Address		Packets from the IPv4 Internet destined for an IPv4 Service Address
	is first translated to IPv6 by a BR. The resulting IPv6 packets are		are first translated to IPv6 by a BR. The resulting IPv6 packets are
	subsequently forwarded to the ER that owns the IPv6 Service Address		subsequently forwarded to the ER that owns the IPv6 Service Address
	the translated packets are addressed to. The ER then translates them		the translated packets are addressed to. The ER then translates them
	back to IPv4 before forwarding them to the IPv4 application or node.		back to IPv4 before forwarding them to the IPv4 application or node.
	In the other direction, the exact same translations happen, only in		In the other direction, the exact same translations happen, only in
	reverse. This process provides end-to-end transparency of IPv4		reverse. This process provides end-to-end transparency of IPv4
	addresses.		addresses.
	An ER may handle an arbitrary number of IPv4/IPv6 Service Addresses.		An ER may handle an arbitrary number of IPv4/IPv6 Service Addresses.
	All the EAMs configured in the BR that involve the IPv4/IPv6 Service		All the EAMs configured in the BR that involve the IPv4/IPv6 Service
	Addresses handled by an ER MUST also be present in the ER's		Addresses handled by an ER MUST also be present in the ER's
	configuration.		configuration.
	An ER may be implemented in two distinct ways; as a software-based		An ER may be implemented in two distinct ways: as a software-based
	service residing inside an otherwise IPv6-only node, or as a network-		service residing inside an otherwise IPv6-only node or as a network-
	based service that provides an isolated IPv4 network segment to which		based service that provides an isolated IPv4 network segment to which
	nodes that require IPv4 can connect. In both cases native IPv6		nodes that require IPv4 can connect. In both cases, native IPv6
	connectivity may be provided simultaneously with the virtual IPv4		connectivity may be provided simultaneously with the virtual IPv4
	connectivity. Thus, dual-stack connectivity is facilitated in case		connectivity. Thus, dual-stack connectivity is facilitated in case
	the node or application support it.		the node or application supports it.
	The choice between a node- or network-based ER is made on a per-		The choice between a node- or network-based ER is made on a per-
	service or per-node basis. An arbitrary number of each type of ER		service or per-node basis. An arbitrary number of each type of ER
	may co-exist in an SIIT-DC architecture.		may co-exist in an SIIT-DC architecture.
	This section describes the different approaches and discusses which		This section describes the different approaches and discusses which
	approach fits best for the various use cases.		approach fits best for the various use cases.
	3.1. Node-Based Edge Relay		3.1. Node-Based Edge Relay
	A Node-based Edge Relay
	[IPv4 Internet] [IPv6 Internet]		[IPv4 Internet] [IPv6 Internet]
	| |		| |
	+-----|-----+ |		+-----|-----+ |
	| (BR/XLAT) | |		| (BR/XLAT) | |
	+-----|-----+ |		+-----|-----+ |
	| | +-----<IPv6-only node/server>----------+		| | +-----<IPv6-only node/server>----------+
	[IPv6-only IDC network] | +----------------+|		[IPv6-only IDC network] | +----------------+|
	| | /--(ER/XLAT)--AF_INET Dual-stack ||		| | /--(ER/XLAT)--AF_INET Dual-stack ||
	\-------------------------+ | Application ||		\-------------------------+ | application ||
	| \------------AF_INET6 Software ||		| \------------AF_INET6 software ||
	| +----------------+|		| +----------------+|
	+--------------------------------------+		+--------------------------------------+
	Figure 1		Figure 1: A Node-Based Edge Relay
	A node-based ER is typically implemented as a logical software		A node-based ER is typically implemented as a logical software
	function that runs inside the operating system of an IPv6 node. It		function that runs inside the operating system of an IPv6 node. It
	provides applications running on the same node with IPv4		provides applications running on the same node with IPv4
	connectivity. Its IPv4 Service Address SHOULD be considered a		connectivity. Its IPv4 Service Address SHOULD be considered a
	regular local address that allows application running on the same		regular local address that allows applications running on the same
	node to use it with IPv4-only API calls, e.g., to create AF_INET		node to use it with IPv4-only API calls, e.g., to create AF_INET
	sockets that listen for and accept incoming connections to its IPv4		sockets that listen for and accept incoming connections to its IPv4
	Service Address. An ER may accomplish this by creating a virtual		Service Address. An ER may accomplish this by creating a virtual
	network adapter to which it assigns the IPv4 Service Address and		network adapter to which it assigns the IPv4 Service Address and
	points a default IPv4 route. This approach is similar to the "Bump-		points a default IPv4 route. This approach is similar to the
	in-the-Stack" approach discussed in [RFC6535], however it does not		"Bump-in-the-Stack" approach discussed in [RFC6535]; however, it does
	include an Extension Name Resolver.		not include an Extension Name Resolver.
	As shown in Figure 1, if the application supports dual-stack		As shown in Figure 1, if the application supports dual-stack
	operation, IPv6 clients will be able to communicate with it directly		operation, IPv6 clients will be able to communicate with it directly
	using native IPv6. Neither the BR nor the ER will intercept this		using native IPv6. Neither the BR nor the ER will intercept this
	communication. Support for IPv6 in the application is however not a		communication. Support for IPv6 in the application is, however, not
	requirement; the application may opt not to establish any IPv6		a requirement; the application may opt not to establish any IPv6
	sockets. Foregoing IPv6 in this manner will simply preclude		sockets. Foregoing IPv6 in this manner will simply preclude
	connectivity to the service from IPv6-only clients; connectivity to		connectivity to the service from IPv6-only clients; connectivity to
	the service from IPv4 clients (through the BR) will continue work in		the service from IPv4 clients (through the BR) will continue work in
	the same way.		the same way.
	The ER requires a dedicated IPv6 Service Address for each IPv4		The ER requires a dedicated IPv6 Service Address for each IPv4
	Service Address it has configured. The IPv6 network MUST forward		Service Address it has configured. The IPv6 network MUST forward
	traffic to these IPv6 Service Addresses to the node, whose operating		traffic to these IPv6 Service Addresses to the node, whose operating
	system MUST in turn forward them to the ER. This document does not		system MUST in turn forward them to the ER. This document does not
	attempt to fully explore the multitude of ways this could be		attempt to fully explore the multitude of ways this could be
	accomplished, however considering that the IPv6 protocol is designed		accomplished; however, considering that the IPv6 protocol is designed
	for having multiple addresses assigned to a single node, one		for having multiple addresses assigned to a single node, one
	particularly straight-forward way would be to assign the ER's IPv6		particularly straight-forward way would be to assign the ER's IPv6
	Service Addresses as secondary IPv6 addresses on the node itself so		Service Addresses as secondary IPv6 addresses on the node itself so
	that it the upstream router learns of their location using the IPv6		that the upstream router learns of their location using the IPv6
	Neighbor Discovery Protocol [RFC4861].		Neighbor Discovery Protocol [RFC4861].
	3.2. Network-Based Edge Relay		3.2. Network-Based Edge Relay
	A Basic Network-based Edge Relay
	[IPv4 Internet] [IPv6 Internet]		[IPv4 Internet] [IPv6 Internet]
	| |		| |
	+-----|-----+ |		+-----|-----+ |
	| (BR/XLAT) | |		| (BR/XLAT) | |
	+-----|-----+ |		+-----|-----+ |
	| |		| |
	[IPv6-only IDC network] +--<IPv4-only node/server>--+		[IPv6-only IDC network] +--<IPv4-only node/server>--+
	| | +----------------+|		| | +----------------+|
	+-----|-----+ [v4-only] | | IPv4-only ||		+-----|-----+ [v4-only] | | IPv4-only ||
	| (ER/XLAT)-----[network]--------AF_INET Application ||		| (ER/XLAT)-----[network]--------AF_INET application ||
	+-----------+ [segment] | | Software ||		+-----------+ [segment] | | software ||
	| +----------------+|		| +----------------+|
	+---------------------------+		+---------------------------+
	Figure 2		Figure 2: A Basic Network-Based Edge Relay
	A network-based ER performs the exact same as a node-based ER does,		A network-based ER functions the exact same way as a node-based ER
	only that instead of assigning the IPv4 Service Addresses to an		does, only that instead of assigning the IPv4 Service Addresses to an
	internal-only virtual network adapter, traffic destined for them are		internal-only virtual network adapter, traffic destined for them are
	forwarded onto a network segment to which nodes that require IPv4		forwarded onto a network segment to which nodes that require IPv4
	connectivity connect to. The ER also functions as the default IPv4		connectivity connect to. The ER also functions as the default IPv4
	router for the nodes on this network segment.		router for the nodes on this network segment.
	Each node on the IPv4 network segment MUST acquire and assign an IPv4		Each node on the IPv4 network segment MUST acquire and assign an IPv4
	Service Address to a local network interface. While this document		Service Address to a local network interface. While this document
	does not attempt to explore all the various methods by which this		does not attempt to explore all the various methods by which this
	could be accomplished, some examples are provided in Appendix A.		could be accomplished, some examples are provided in Appendix A.
	The basic ER illustrated in Figure 2 establishes an IPv4-only network		The basic ER illustrated in Figure 2 establishes an IPv4-only network
	segment between itself and the IPv4-only nodes it serves. This is		segment between itself and the IPv4-only nodes it serves. This is
	fine if the nodes it provides IPv4 access have no support for IPv6		fine if the nodes it provides IPv4 access to have no support for IPv6
	whatsoever; however if they are dual-stack capable, it is would not		whatsoever; however, if they are dual-stack capable, it would not be
	be ideal to take away their IPv6 connectivity in this manner. While		ideal to take away their IPv6 connectivity in this manner. While it
	it is RECOMMENDED to use a node-based ER in this case, appropriate		is RECOMMENDED to use a node-based ER in this case, appropriate
	implementations of a node-based ER might not be available for every		implementations of a node-based ER might not be available for every
	node. If the application protocol in question does not work		node. If the application protocol in question does not work
	correctly in a NAT environment, standard SIIT-DC cannot be used		correctly in a NAT environment, standard SIIT-DC cannot be used
	either, which leaves a network-based ER is the only remaining		either, which leaves a network-based ER as the only remaining
	solution. The following subsections contains examples on how the ER		solution. The following subsections contain examples on how the ER
	could be implemented in a way that provides IPv6 connectivity for		could be implemented in a way that provides IPv6 connectivity for
	dual-stack capable nodes.		dual-stack capable nodes.
	3.2.1. Edge Router "On A Stick"		3.2.1. Edge Relay "on a Stick"
	A Network-based Edge Relay "On A Stick"
	[IPv4 Internet] [IPv6 Internet]		[IPv4 Internet] [IPv6 Internet]
	| |		| |
	+-----|-----+ |		+-----|-----+ |
	| (BR/XLAT) | |		| (BR/XLAT) | |
	+-----|-----+ |		+-----|-----+ |
	| |		| |
	[IPv6-only IDC network]		[IPv6-only IDC network]
	|		|
	| +-------------+		| +-------------+
	| | _IPv6_ |		| | _IPv6_ |
	| | / \ |		| | / \ |
	+==== (ER/XLAT) |		+==== (ER/XLAT) |
	| | \_ _/ |		| | \_ _/ |
	| | IPv4 | +--<Dual stack node/server>--+		| | IPv4 | +--<Dual-stack node/server>--+
	| +-------------+ | +----------------+|		| +-------------+ | +----------------+|
	| | /---AF_INET Dual-stack ||		| | /---AF_INET Dual-stack ||
	[Dual-stack network segment]----< | Application ||		[Dual-stack network segment]----< | application ||
	| \--AF_INET6 Software ||		| \--AF_INET6 software ||
	| +----------------+|		| +----------------+|
	+----------------------------+		+----------------------------+
	Figure 3		Figure 3: A Network-Based Edge Relay "on a Stick"
	The ER "On A Stick" approach illustrated in Figure 3 ensures that the		The ER "on a stick" approach illustrated in Figure 3 ensures that the
	dual-stack capable node retains native IPv6 connectivity by		dual-stack capable node retains native IPv6 connectivity by
	connecting the ER's IPv4 and IPv6 interfaces to the same network		connecting the ER's IPv4 and IPv6 interfaces to the same network
	segment, alternatively by using a single dual-stacked interface.		segment, alternatively by using a single dual-stacked interface.
	Native IPv6 traffic between the IDC network and the node bypasses the		Native IPv6 traffic between the IDC network and the node bypasses the
	ER entirely, while IPv4 traffic from the node will be routed directly		ER entirely, while IPv4 traffic from the node will be routed directly
	to the ER (because it acts as its default IPv4 router), where it is		to the ER (because it acts as its default IPv4 router), where it is
	translated to IPv6 before being transmitted to the upstream default		translated to IPv6 before being transmitted to the upstream default
	IPv6 router. The ER could attract inbound traffic to the IPv6		IPv6 router. The ER could attract inbound traffic to the IPv6
	Service Addresses by responding to the upstream router's IPv6		Service Addresses by responding to the upstream router's IPv6
	Neighbor Discovery [RFC4861] messages for them.		Neighbor Discovery [RFC4861] messages for them.
	3.2.2. Edge Router that Bridges IPv6 Packets		3.2.2. Edge Relay That Bridges IPv6 Packets
	A Network-based Edge Relay containing an IPv6 Bridge
	[IPv4 Internet] [IPv6 Internet]		[IPv4 Internet] [IPv6 Internet]
	| |		| |
	+-----|-----+ |		+-----|-----+ |
	| (BR/XLAT) | |		| (BR/XLAT) | |
	+-----|-----+ |		+-----|-----+ |
	| |		| |
	[IPv6-only IDC network]		[IPv6-only IDC network]
	|		|
	+-----------|--------------+		+-----------|--------------+
	| ____/ \_IPv6_ |		| ____/ \_IPv6_ |
	| / \ |		| / \ |
	| (IPv6 Bridge) (ER/XLAT) |		| (IPv6 Bridge) (ER/XLAT) |
	| \____ _ _/ |		| \____ _ _/ |
	| \ / IPv4 | +--<Dual stack node/server>--+		| \ / IPv4 | +--<Dual-stack node/server>--+
	+-----------|--------------+ | +----------------+|		+-----------|--------------+ | +----------------+|
	| | /---AF_INET Dual-stack ||		| | /---AF_INET Dual-stack ||
	[Dual-stack network segment]----< | Application ||		[Dual-stack network segment]----< | application ||
	| \--AF_INET6 Software ||		| \--AF_INET6 software ||
	| +----------------+|		| +----------------+|
	+----------------------------+		+----------------------------+
	Figure 4		Figure 4: A Network-Based Edge Relay Containing an IPv6 Bridge
	The ER illustrated in Figure 4 will transparently bridge IPv6 frames		The ER illustrated in Figure 4 will transparently bridge IPv6 frames
	between its upstream and downstream interfaces. IPv6 packets		between its upstream and downstream interfaces. IPv6 packets sent
	addressed the ER's own IPv6 Service Addresses from the upstream IDC		from the upstream IDC network to an IPv6 Service Address are
	network are intercepted (e.g., by responding to IPv6 Neighbor		intercepted by the ER (e.g., by responding to IPv6 Neighbor Discovery
	Discovery [RFC4861] messages for them) and routed through the		[RFC4861] messages for them) and routed through the translation
	translation function before being forwarded out its downstream		function before being forwarded out the ER's downstream interface as
	interface as IPv4 packets. The downstream network segment thus		IPv4 packets. The downstream network segment thus becomes dual
	becomes dual-stacked.		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		than the default value defined in Section 4 of [RFC6145] (1280
	bytes), as it will typically contained within a single administrative		bytes), as it will typically be contained within a single
	domain. Therefore, it is RECOMMENDED that the IPv6 Path MTU		administrative domain. Therefore, it is RECOMMENDED that the IPv6
	configured in the ER is raised accordingly. It is RECOMMENDED that		Path MTU configured in the ER be raised accordingly. It is
	the ER and the BR use identical configured IPv6 Path MTU values.		RECOMMENDED that 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 a maximum-sized IPv4 packet can fit in an
	an unfragmented IPv6 packet. This ensures that the application may		unfragmented IPv6 packet. This ensures that the application may do
	do its part in avoiding IP-level fragmentation from occurring, e.g.,		its part in avoiding IP-level fragmentation from occurring, e.g., by
	by segmenting/fragmenting outbound packets at the application layer,		segmenting/fragmenting outbound packets at the application layer, and
	and advertising the maximum size its peer may use for inbound packets		advertising the maximum size its peer may use for inbound packets
	(e.g., through the use of the TCP MSS option).		(e.g., through the use of the TCP Maximum Segment Size (MSS) option).
	A node-based ER could accomplish this by configuring this MTU value		A node-based ER could accomplish this by configuring this MTU value
	on the virtual network adapter, while a network-based ER could do so		on the virtual network adapter, while a network-based ER could do so
	by advertising the MTU to its downstream nodes using the DHCPv4		by advertising the MTU to its downstream nodes using the DHCPv4
	Interface MTU Option [RFC2132].		Interface MTU option [RFC2132].
	4.3. IPv4 Identification Header		4.3. IPv4 Identification Header
	If the generation of IPv6 Atomic Fragments is disabled, the value of		If the generation of IPv6 Atomic Fragments is disabled, the value of
	the IPv4 Identification header will be lost during the translation.		the IPv4 Identification header will be lost during the translation.
	Conversely, enabling the generation of IPv6 Atomic Fragments will		Conversely, enabling the generation of IPv6 Atomic Fragments will
	ensure that the IPv4 Identification Header will carried end-to-end.		ensure that the IPv4 Identification header will be carried end to
	Note that for this to work bi-directionally, IPv6 Atomic Fragment		end. Note that for this to work bidirectionally, IPv6 Atomic
	generation MUST be enabled on both the BR and the ER.		Fragment generation MUST be enabled on both the BR and the ER.
	Apart from certain diagnostic tools, there are few (if any)		Apart from certain diagnostic tools, there are few (if any)
	application protocols that make use of the IPv4 Identification		application protocols that make use of the IPv4 Identification
	header. Therefore, the loss of the IPv4 Identification value will		header. Therefore, the loss of the IPv4 Identification value will
	therefore generally not cause any problems.		generally not cause any problems.
	IPv6 Atomic Fragments and their impact on the IPv4 Identification		IPv6 Atomic Fragments and their impact on the IPv4 Identification
	header is further discussed in Section 4.9.2 of		header is further discussed in Section 4.9.2 of [RFC7755].
	[I-D.ietf-v6ops-siit-dc].
	5. Intra-IDC IPv4 Communication		5. Intra-IDC IPv4 Communication
	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 go
	through the ER, as it will typically be incapable to contact IPv6		through the ER, as it will typically be incapable of contacting IPv6
	destinations directly. The following subsections discusses various		destinations directly. The following subsections discuss 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		If the BR supports hairpinning as described in Section 4.2 of
	[I-D.ietf-v6ops-siit-eam], the easiest solution is to make the target		[RFC7757], the easiest solution is to make the target service
	service available through SIIT-DC in the normal way, that is, by		available through SIIT-DC in the normal way; that is, by provisioning
	provisioning an EAM to the BR that assigns an IPv4 Service Address		an EAM to the BR that assigns an IPv4 Service Address with the target
	with the target service's IPv6 Service Address.		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.
	Hairpinned IPv4-IPv4 packet flow
	+-[Pkt#1: IPv4]-+ +--[Pkt#2: IPv6]-------------+		+-[Pkt#1: IPv4]-+ +--[Pkt#2: IPv6]-------------+
	| SRC 192.0.2.1 | (XLAT#1) | SRC 2001:db8:a:: |		| SRC 192.0.2.1 | (XLAT#1) | SRC 2001:db8:a:: |
	| DST 192.0.2.2 |--(@ ER A)-->| DST 2001:db8:46::192.0.2.2 |---\		| DST 192.0.2.2 |--(@ ER A)-->| DST 2001:db8:46::192.0.2.2 |---\
	+---------------+ +----------------------------+ |		+---------------+ +----------------------------+ |
	(XLAT#2)		(XLAT#2)
	+-[Pkt#4: IPv4]-+ +--[Pkt#3: IPv6]-------------+ ( @ BR )		+-[Pkt#4: IPv4]-+ +--[Pkt#3: IPv6]-------------+ ( @ BR )
	| SRC 192.0.2.1 | (XLAT#3) | SRC 2001:db8:46::192.0.2.1 | |		| SRC 192.0.2.1 | (XLAT#3) | SRC 2001:db8:46::192.0.2.1 | |
	| DST 192.0.2.2 |<--(@ ER B)--| DST 2001:db8:b:: |<--/		| DST 192.0.2.2 |<--(@ ER B)--| DST 2001:db8:b:: |<--/
	+---------------+ +----------------------------+		+---------------+ +----------------------------+
	Figure 5		Figure 5: Hairpinned IPv4-IPv4 Packet Flow
	Figure 5 illustrates the flow of a hairpinned packet sent from the		Figure 5 illustrates the flow of a hairpinned packet sent from the
	IPv4-only node/app behind ER A towards an IPv6-only node/app behind		IPv4-only node/app behind ER A towards an IPv6-only node/app behind
	ER B. ER A is configured with the EAM {192.0.2.1,2001:db8:a::}, ER B		ER B. ER A is configured with the EAM {192.0.2.1,2001:db8:a::} and
	with {192.0.2.2,2001:db8:b::}. The BR is configured with both EAMs,		ER B with {192.0.2.2,2001:db8:b::}. The BR is configured with both
	and supports hairpinning. Note that if the target service had not		EAMs and supports hairpinning. Note that if the target service had
	been located behind an ER, the third and final translation (XLAT#3)		not been located behind an ER, the third and final translation
	would not have happened, i.e., the target service/node would have		(XLAT#3) would not have happened, i.e., the target service/node would
	received and responded to packet #3 directly.		have received and responded to packet #3 directly.
	If the IPv4-only nodes/services do not need connectivity with the		If the IPv4-only nodes/services do not need connectivity with the
	public IPv4 Internet, private IPv4 addresses [RFC1918] could be used		public IPv4 Internet, private IPv4 addresses [RFC1918] could be used
	as their IPv4 Service Addresses in order to conserve the IDC		as their IPv4 Service Addresses in order to conserve the IDC
	operator's pool of public IPv4 addresses.		operator's pool of public IPv4 addresses.
	5.2. Additional EAMs Configured in Edge Relay		5.2. Additional EAMs Configured in Edge Relay
	If the BR does not support hairpinning, or if the hairpinning		If the BR does not support hairpinning, or if the hairpinning
	solution is not desired for some other reason, intra-IDC IPv4 traffic		solution is not desired for some other reason, intra-IDC IPv4 traffic
	skipping to change at page 12, line 15		skipping to change at page 12, line 20
	service the IPv4-only node or application needs to communicate with.		service the IPv4-only node or application needs to communicate with.
	This makes the IPv6 traffic between the ER and the target service's		This makes the IPv6 traffic between the ER and the target service's
	IPv6 Service Address follow the direct path through the IPv6 network.		IPv6 Service Address follow the direct path through the IPv6 network.
	The traffic does not pass the BR, which means that this solution		The traffic does not pass the BR, which means that this solution
	might yield better latency than the hairpinning approach.		might yield better latency than the hairpinning approach.
	The additional EAM configured in the ER consists of the target's IPv6		The additional EAM configured in the ER consists of the target's IPv6
	Service Address and an IPv4 Service Address. The IPv4-only node or		Service Address and an IPv4 Service Address. The IPv4-only node or
	application will contact the target's assigned IPv4 Service Address		application will contact the target's assigned IPv4 Service Address
	using its own IPv4 Service Address as the source. The ER will then		using its own IPv4 Service Address as the source. The ER will then
	proceed to translate this to an IPv6 packet with the local		proceed to translate the original IPv4 packet to an IPv6 packet. The
	application/node's own IPv6 Service Address as source and the target		source address of the resulting IPv6 packet will be the IPv6 Service
	service's IPv6 Service Address as the destination, and forward this		Address of the local node or application, while the destination
	to the IPv6 network. Replies from the target service will undergo		address will be the IPv6 Service Address of the target. Any replies
	these translations in reverse.		from the target will undergo identical translation, only in reverse.
	If the target service is also located behind another ER, that other
	ER MUST also be provisioned with an additional EAM that contains the
	origin IPv4-only application/node's IPv4 and IPv6 Service Addresses.
	Otherwise, the target service's ER will be unable to translate the
	source address of the incoming packets.
	Non-hairpinned IPv4-IPv4 packet flow		If the target service is located behind another ER, that other ER
			MUST also be provisioned with an additional EAM that contains the
			IPv4 and IPv6 Service Addresses of the origin IPv4-only node or
			application. Otherwise, the target service's ER will be unable to
			translate the source address of the incoming packets.
	+-[Pkt#1: IPv4]-+ +--[Pkt#2: IPv6]---+		+-[Pkt#1: IPv4]-+ +--[Pkt#2: IPv6]---+
	| SRC 192.0.2.1 | (XLAT#1) | SRC 2001:db8:a:: |		| SRC 192.0.2.1 | (XLAT#1) | SRC 2001:db8:a:: |
	| DST 192.0.2.2 |--(@ ER A)-->| DST 2001:db8:b:: |		| DST 192.0.2.2 |--(@ ER A)-->| DST 2001:db8:b:: |
	+---------------+ +------------------+		+---------------+ +------------------+
	|		|
	+-[Pkt#3: IPv4]-+ |		+-[Pkt#3: IPv4]-+ |
	| SRC 192.0.2.1 | (XLAT#2) |		| SRC 192.0.2.1 | (XLAT#2) |
	| DST 192.0.2.2 |<-------(@ ER B)------/		| DST 192.0.2.2 |<-------(@ ER B)------/
	+---------------+		+---------------+
	Figure 6		Figure 6: Non-hairpinned IPv4-IPv4 Packet Flow
	Figure 6 illustrates the flow of a packet carrying intra-IDC IPv4		Figure 6 illustrates the flow of a packet carrying intra-IDC IPv4
	traffic between two IPv4-only nodes/applications that are both		traffic between two IPv4-only nodes/applications that are both
	located behind ERs. Both ER A and ER B are configured with two EAMs:		located behind ERs. Both ER A and ER B are configured with two EAMs:
	{192.0.2.1,2001:db8:a::} and {192.0.2.2,2001:db8:b::}. The packet		{192.0.2.1,2001:db8:a::} and {192.0.2.2,2001:db8:b::}. The packet
	will follow the regular routing path through the IPv6 IDC network;		will follow the regular routing path through the IPv6 IDC network;
	the BR is not involved and the packet will not be hairpinned.		the BR is not involved, and the packet will not be hairpinned.
	The above approach is not mutually exclusive with the hairpinning		The above approach is not mutually exclusive with the hairpinning
	approach described in Section 5.1: If both EAMs above are also		approach described in Section 5.1: If both EAMs above are also
	configured on the BR, both 192.0.2.1 and 192.0.2.2 would be reachable		configured on the BR, both 192.0.2.1 and 192.0.2.2 would be reachable
	from other IPv4-only services/nodes using the hairpinning approach.		from other IPv4-only services/nodes using the hairpinning approach.
	They would also be reachable from the IPv4 Internet.		They would also be reachable from the IPv4 Internet.
	Note that if the target service in this example was not located		Note that if the target service in this example was not located
	behind an ER, but instead was a native IPv6 service listening on		behind an ER, but instead was a native IPv6 service listening on
	2001:db8:b::, the second translation step in Figure 6 would not		2001:db8:b::, the second translation step in Figure 6 would not
	skipping to change at page 13, line 25		skipping to change at page 13, line 25
	directly.		directly.
	As with the hairpinning approach, if the IPv4-only nodes/services do		As with the hairpinning approach, if the IPv4-only nodes/services do
	not need connectivity to/from the public IPv4 Internet, private IPv4		not need connectivity to/from the public IPv4 Internet, private IPv4
	addresses [RFC1918] could be used as their IPv4 Service Addresses.		addresses [RFC1918] could be used as their IPv4 Service Addresses.
	Alternatively, in the case where the target service is on native		Alternatively, in the case where the target service is on native
	IPv6, the target's assigned IPv4 Service Address has only local		IPv6, the target's assigned IPv4 Service Address has only local
	significance behind the ER. It could therefore be assigned from the		significance behind the ER. It could therefore be assigned from the
	IPv4 Service Continuity Prefix [RFC7335].		IPv4 Service Continuity Prefix [RFC7335].
	6. Acknowledgements		6. Security Considerations
	The author would like to especially thank the authors of 464XLAT
	[RFC6877]: Masataka Mawatari, Masanobu Kawashima, and Cameron Byrne.
	The architecture described by this document is merely an adaptation
	of their work to a data centre environment, and could not have
	happened without them.
	The author would like also to thank the following individuals for
	their contributions, suggestions, corrections, and criticisms: Fred
	Baker, Tobias Brox, Olafur Gudmundsson, Christer Holmberg, Ray
	Hunter, Shucheng LIU (Will), Andrew Yourtchenko.
	7. IANA Considerations
	This draft makes no request of the IANA.
	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 [RFC7755] for
	[I-D.ietf-v6ops-siit-dc] for security considerations applicable to		security considerations applicable to the SIIT-DC architecture in
	the SIIT-DC architecture in general.		general.
	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
	destination address equal to one of its local IPv6 Service Addresses,		destination address equal to one of its local IPv6 Service Addresses,
	the resulting packet would appear to the IPv4-only application/node		the resulting packet would appear to the IPv4-only application/node
	as locally generated, as both the source address and the destination		as locally generated, as both the source address and the destination
	address will be the same address. This could trick the application		address will be the same address. This could trick the application
	into believing the packet came from a trusted source (itself). To		into believing the packet came from a trusted source (itself). To
	prevent this, the ER SHOULD discard any received IPv6 packets that		prevent this, the ER SHOULD discard any received IPv6 packets that
	have a source address that is either 1) equal to any of its local		have a source address that is either 1) equal to any of its local
	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		7. References
	9.1. Normative References
	[I-D.ietf-v6ops-siit-dc]
	Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for
	IPv6 Data Centre Environments", draft-ietf-v6ops-siit-
	dc-02 (work in progress), August 2015.
	[I-D.ietf-v6ops-siit-eam]		7.1. Normative References
	Anderson, T. and A. Leiva, "Explicit Address Mappings for
	Stateless IP/ICMP Translation", draft-ietf-v6ops-siit-
	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, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119,
	RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	9.2. Informative References		[RFC7755] Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for
			IPv6 Data Center Environments", RFC 7755,
			DOI 10.17487/RFC7755, February 2016,
			<http://www.rfc-editor.org/info/rfc7755>.
	[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or		[RFC7757] Anderson, T. and A. Leiva, "Explicit Address Mappings for
			Stateless IP/ICMP Translation", RFC 7757,
			DOI 10.17487/RFC7757, February 2016,
			<http://www.rfc-editor.org/info/rfc7757>.
			7.2. Informative References
			[RFC826] 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, DOI 10.17487/RFC0826, November 1982,		RFC 826, DOI 10.17487/RFC0826, November 1982,
	<http://www.rfc-editor.org/info/rfc826>.		<http://www.rfc-editor.org/info/rfc826>.
	[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,
	<http://www.rfc-editor.org/info/rfc1918>.		<http://www.rfc-editor.org/info/rfc1918>.
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
	2131, DOI 10.17487/RFC2131, March 1997,		RFC 2131, DOI 10.17487/RFC2131, March 1997,
	<http://www.rfc-editor.org/info/rfc2131>.		<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, DOI 10.17487/RFC2132, March 1997,		Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
	<http://www.rfc-editor.org/info/rfc2132>.		<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, DOI 10.17487/RFC2827,		Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
	May 2000, <http://www.rfc-editor.org/info/rfc2827>.		May 2000, <http://www.rfc-editor.org/info/rfc2827>.
	skipping to change at page 15, line 33		skipping to change at page 15, line 20
	[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,
	<http://www.rfc-editor.org/info/rfc6052>.		<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, DOI 10.17487/RFC6145, April 2011,		Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
	<http://www.rfc-editor.org/info/rfc6145>.		<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, DOI 10.17487/		Using "Bump-in-the-Host" (BIH)", RFC 6535,
	RFC6535, February 2012,		DOI 10.17487/RFC6535, February 2012,
	<http://www.rfc-editor.org/info/rfc6535>.		<http://www.rfc-editor.org/info/rfc6535>.
	[RFC6724] Thaler, D., Ed., 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, DOI 10.17487/RFC6724, September 2012,		(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
	<http://www.rfc-editor.org/info/rfc6724>.		<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",
	6877, DOI 10.17487/RFC6877, April 2013,		RFC 6877, DOI 10.17487/RFC6877, April 2013,
	<http://www.rfc-editor.org/info/rfc6877>.		<http://www.rfc-editor.org/info/rfc6877>.
	[RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335, DOI		[RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335,
	10.17487/RFC7335, August 2014,		DOI 10.17487/RFC7335, August 2014,
	<http://www.rfc-editor.org/info/rfc7335>.		<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 a network-based ER and the IPv4 node(s) it serves is to
	Service Address(es) can be enclosed within a larger IPv4 prefix. The		ensure the IPv4 Service Address(es) can be enclosed within a larger
	ER may then claim one address in this prefix for itself, and use it		IPv4 prefix. The ER may then claim one address in this prefix for
	to provide an IPv4 default router address. The ER may then proceed		itself and use it to provide an IPv4 default router address and
	to assign the IPv4 Service Address(es) to its downstream node(s)		assign the IPv4 Service Address(es) to its downstream node(s) using
	using DHCPv4 [RFC2131]. For example, if the IPv4 Service Addresses		DHCPv4 [RFC2131]. For example, if the IPv4 Service Addresses are
	are 192.0.2.26 and 192.0.2.27, the ER would configure the address		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.
	One disadvantage of this method is that IPv4 communication between		One disadvantage of this method is that IPv4 communication between
	the IPv4 node(s) behind the ER and other services made available		the IPv4 node(s) behind the ER and other services made available
	through SIIT-DC becomes impossible, if those other services are		through SIIT-DC becomes impossible, if those other services are
	assigned IPv4 Service Addresses that also are covered by the same		assigned IPv4 Service Addresses that also are covered by the same
	IPv4 prefix (e.g., 192.0.2.28). This happens because the IPv4 nodes		IPv4 prefix (e.g., 192.0.2.28). This happens because the IPv4 nodes
	will mistakenly believe they have an on-link route to the entire		will mistakenly believe they have an on-link route to the entire
	prefix, and attempt to resolve the addresses using ARP [RFC0826],		prefix and attempt to resolve the addresses using ARP [RFC826],
	instead of sending them to the ER for translation to IPv6. This		instead of sending them to the ER for translation to IPv6. This
	problem could however be overcome by avoiding assigning IPv4 Service		problem could, however, be overcome by avoiding assigning IPv4
	Addresses which overlaps with an IPv4 prefix handled by an ER (at the		Service Addresses that overlap with an IPv4 prefix handled by an ER
	expense of wasting some potential IPv4 Service Addresses), or by		(at the expense of wasting some potential IPv4 Service Addresses) or
	ensuring that the overlapping IPv6 Service Addresses are only		by ensuring that the overlapping IPv4 Service Addresses are only
	assigned to services which do not need to communicate with the IPv4		assigned to services that do not need to communicate with the IPv4
	node(s) behind the ER. A third way to avoid this problem is		node(s) behind the ER. A third way to avoid this problem is
	discussed in Appendix A.2.		discussed in Appendix A.2.
	A.2. Subnet with Unrouted IPv4 Addresses		A.2. Subnet with Unrouted IPv4 Addresses
	In order to avoid the problem discussed in Appendix A.1, a private		In order to avoid the problem discussed in Appendix A.1, a private
	unrouted IPv4 network that does not encompass the IPv4 Service		unrouted IPv4 network that does not encompass the IPv4 Service
	Address(es) could be used to provide connectivity between the ER and		Address(es) could be used to provide connectivity between the ER and
	the IPv4-only node(s) it serves. An IPv4-only node must then assign		the IPv4-only node(s) it serves. An IPv4-only node must then assign
	its IPv4 Service Address as secondary local address, while the ER		its IPv4 Service Address as a secondary local address, while the ER
	routes each of the IPv4 Service Addresses to its assigned node using		routes each of the IPv4 Service Addresses to its assigned node using
	that node's private on-link IPv4 address as the next-hop. This		that node's private on-link IPv4 address as the next hop. This
	approach would ensure there are no overlaps with IPv4 Service		approach would ensure there are no overlaps with IPv4 Service
	addresses elsewhere in the infrastructure, but on the other hand it		Addresses elsewhere in the infrastructure, but on the other hand, it
	would preclude the use of DHCPv4 [RFC2131] for assigning the IPv4		would preclude the use of DHCPv4 [RFC2131] for assigning the IPv4
	Service Addresses.		Service Addresses.
	This approach creates a need to ensure that the IPv4 application is		This approach creates a need to ensure that the IPv4 application is
	selecting the IPv4 Service Address (as opposed to its private on-link		selecting the IPv4 Service Address (as opposed to its private on-link
	IPv4 address) as its source address when initiating outbound		IPv4 address) as its source address when initiating outbound
	connections. This could be accomplished by altering the Default		connections. This could be accomplished by altering the Default
	Address Selection Policy Table [RFC6724] on the IPv4 node.		Address Selection Policy Table [RFC6724] on the IPv4 node.
			Acknowledgements
			The authors would like to especially thank the authors of 464XLAT
			[RFC6877]: Masataka Mawatari, Masanobu Kawashima, and Cameron Byrne.
			The architecture described by this document is merely an adaptation
			of their work to a data center environment and could not have
			happened without them.
			The authors would like also to thank the following individuals for
			their contributions, suggestions, corrections, and criticisms: Fred
			Baker, Tobias Brox, Olafur Gudmundsson, Christer Holmberg, Ray
			Hunter, Shucheng LIU (Will), and Andrew Yourtchenko.
	Authors' Addresses		Authors' Addresses
	Tore Anderson		Tore Anderson
	Redpill Linpro		Redpill Linpro
	Vitaminveien 1A		Vitaminveien 1A
	0485 Oslo		0485 Oslo
	Norway		Norway
	Phone: +47 959 31 212		Phone: +47 959 31 212
	Email: tore@redpill-linpro.com		Email: tore@redpill-linpro.com
End of changes. 101 change blocks.
	251 lines changed or deleted		236 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/