draft-ietf-v6ops-siit-dc-2xlat-00.txt		draft-ietf-v6ops-siit-dc-2xlat-01.txt
	IPv6 Operations T. Anderson		IPv6 Operations T. Anderson
	Internet-Draft Redpill Linpro		Internet-Draft Redpill Linpro
	Intended status: Standards Track January 25, 2015		Intended status: Informational S. Steffann
	Expires: July 29, 2015		Expires: December 30, 2015 S.J.M. Steffann Consultancy
			June 28, 2015
	SIIT-DC: Dual Translation Mode		SIIT-DC: Dual Translation Mode
	draft-ietf-v6ops-siit-dc-2xlat-00		draft-ietf-v6ops-siit-dc-2xlat-01
	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 Data Centre Environments architecture (SIIT-DC),		Translation for IPv6 Internet Data Centre Environments architecture
	which allows applications, protocols, or nodes that are incompatible		(SIIT-DC), which allows applications, protocols, or nodes that are
	with IPv6, SIIT-DC and/or Network Address Translation in general to		incompatible with IPv6, and/or Network Address Translation to operate
	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 Edge Translator, which reverses		introducing a new component called an SIIT-DC Edge Relay, which
	the translations made by an SIIT-DC Gateway. The application or		reverses the translations made by an SIIT-DC Border Relay. The
	device is thus provided with seemingly native IPv4 connectivity.		application and/or node is thus provided with seemingly native IPv4
			connectivity that 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 I-D.ietf-v6ops-siit-dc.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 July 29, 2015.		This Internet-Draft will expire on December 30, 2015.
	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
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Edge Translator Description . . . . . . . . . . . . . . . . . 4		3. Edge Relay Description . . . . . . . . . . . . . . . . . . . 4
	3.1. Host-Based Edge Translator . . . . . . . . . . . . . . . 5		3.1. Node-Based Edge Relay . . . . . . . . . . . . . . . . . . 5
	3.2. Network-Based Edge Translator . . . . . . . . . . . . . . 6		3.2. Network-Based Edge Relay . . . . . . . . . . . . . . . . 6
	4. Detailed Topology Example . . . . . . . . . . . . . . . . . . 9		3.2.1. Edge Router "On A Stick" . . . . . . . . . . . . . . 7
	5. Deployment Considerations . . . . . . . . . . . . . . . . . . 12		3.2.2. Edge Router that Bridges IPv6 Packets . . . . . . . . 8
	5.1. IPv6 Path MTU . . . . . . . . . . . . . . . . . . . . . . 12		4. Deployment Considerations . . . . . . . . . . . . . . . . . . 9
	5.2. IPv4 MTU . . . . . . . . . . . . . . . . . . . . . . . . 12		4.1. IPv6 Path MTU . . . . . . . . . . . . . . . . . . . . . . 9
	5.3. IPv4 Identification Header . . . . . . . . . . . . . . . 12		4.2. IPv4 MTU . . . . . . . . . . . . . . . . . . . . . . . . 10
	6. Intra-DC IPv4 Communication . . . . . . . . . . . . . . . . . 13		4.3. IPv4 Identification Header . . . . . . . . . . . . . . . 10
	6.1. Between IPv4-Only and IPv6-Only Services . . . . . . . . 13		5. Intra-IDC IPv4 Communication . . . . . . . . . . . . . . . . 10
	6.2. Between Two IPv4-Only Services . . . . . . . . . . . . . 15		5.1. Hairpinning by the SIIT-DC Border Relay . . . . . . . . . 10
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17		5.2. Additional EAMs Configured in Edge Relay . . . . . . . . 11
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 18		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	9.1. Address Spoofing . . . . . . . . . . . . . . . . . . . . 18		8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		8.1. Address Spoofing . . . . . . . . . . . . . . . . . . . . 13
	10.1. Normative References . . . . . . . . . . . . . . . . . . 18		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	10.2. Informative References . . . . . . . . . . . . . . . . . 19		9.1. Normative References . . . . . . . . . . . . . . . . . . 14
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19		9.2. Informative References . . . . . . . . . . . . . . . . . 14
			Appendix A. Examples: Network-Based IPv4 Connectivity . . . . . 15
			A.1. Subnet with IPv4 Service Addresses . . . . . . . . . . . 15
			A.2. Subnet with Unrouted IPv4 Addresses . . . . . . . . . . . 16
			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 Gateway. This approach has certain		translator called an SIIT-DC Border Relay (BR). This approach has
	limitations, however. In particular, the following cases will work		certain limitations, however. In particular, the following cases
	poorly or not at all:		will work poorly or not 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 Devices which cannot connect to IPv6 networks at all, or which can		o Nodes that cannot connect to IPv6 networks at all, or that can
	only connect such networks if they also provide IPv4 connectivity		only 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 which 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 Translator (ET), all of the above can be made to work correctly		Edge Relay (ER), all of the above can be made to work correctly in an
	in an otherwise IPv6-only network environment using SIIT-DC.		otherwise IPv6-only network environment using SIIT-DC.
	The purpose of the Edge Translator is to reverse the IPv4-to-IPv6		The purpose of the ER is to reverse the IPv4-to-IPv6 packet
	packet translations previously done by the SIIT-DC Gateway for		translations previously done by the BR for traffic arriving from IPv4
	traffic arriving from IPv4 clients and forward this as "native" IPv4		clients and forward this as "native" IPv4 to the node or application.
	to the application software or device. In the reverse direction,		In the reverse direction, IPv4 packets transmitted by the node or
	IPv4 packets transmitted by the application software or device is		application are intercepted by the ER, which translates them to IPv6
	intercepted by the Edge Translator, which will translate them to IPv6		before they are forwarded to the BR, which in turn will reverse the
	before they are forwarded to the SIIT-DC Gateway, which in turn will		translations and forward them to the IPv4 client. The node or
	reverse the translations and forward them to the IPv4 End User. In		application is thus provided with "virtual" IPv4 Internet
	short, the device or application software is provided with "virtual"		connectivity that retains end-to-end transparency for the IPv4
	IPv4 Internet connectivity that retains end-to-end transparency for		addresses.
	the IPv4 addresses.
	2. Terminology		2. Terminology
	This document makes use of the following terms:		This document makes use of the following terms:
	Edge Translator (ET)		SIIT-DC Border Relay (BR)
			A device or a logical function that translates traffic between
			IPv4 clients and IPv6 services. See [I-D.ietf-v6ops-siit-dc].
			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 nodes or applications. It functions in
	very similar in function to an SIIT-DC Gateway, but is typically		the same way as a BR, but is located close to the IPv4-only nodes/
	located close to the IPv4-only component(s) it is supporting		applications it is supporting rather than on the network border.
	rather than on the network border.
	IPv4 Service Address		IPv4 Service Address
	A public IPv4 address with which IPv4-only clients will		An IPv4 address representing an IPv6 service, with which IPv4-only
	communicate. This communication will be translated to IPv6 by the		clients communicates. It is coupled with an IPv6 Service Address
	SIIT-DC Gateway and back to IPv4 again by the Edge Translator.		using an EAM. Packets sent to this address is translated to IPv6
			by the BR and possibly back to IPv4 again by the ER, and vice
			versa in the opposite direction.
	SIIT-DC Gateway		IPv6 Service Address
	A device or a logical function that translates between IPv4 and		An IPv6 address assigned to an application, node, or service;
	IPv6 in accordance with [I-D.ietf-v6ops-siit-dc].		either directly or indirectly (through an ER). It is coupled with
			an IPv4 Service Address using an EAM. IPv4-only clients
			communicates with the IPv6 Service Address through SIIT-DC.
	Static Address Mapping		Explicit Address Mapping (EAM)
	A bi-directional mapping between an IPv4 Service Address and an		A bi-directional coupling between an IPv4 Service Address and an
	IPv6 Service Address configured in the SIIT-DC Gateway. When		IPv6 Service Address configured in an BR/ER. When translating
	translating between IPv4 and IPv6, the SIIT-DC Gateway changes the		between IPv4 and IPv6, the BR/ER changes the address fields in the
	address fields in the translated packet's IP header according to		translated packet's IP header according to any matching EAM. The
	any matching Static Address Mapping.		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,
	This prefix is routed to the SIIT-DC Gateway's IPv6 interface. It		according to the algorithm in [RFC6052]. The Translation Prefix
	is either an Network-Specific Prefix or a Well-Known Prefix as		is routed to the BR's IPv6 interface. When translating between
	specified in [RFC6052]. When translating between IPv4 and IPv6,		IPv4 and IPv6, an BR/ER will insert/remove the Translation Prefix
	the SIIT-DC Gateway will prepend or strip the Translation Prefix		into/from the address fields in the translated packet's IP header,
	from the address fields in the translated packet's IP header,		unless an EAM exists for the IP address that is being translated.
	unless a Static Address Mapping exists for the IP address in
	question.		IPv4-converted IPv6 addresses
			As defined in Section 1.3 of [RFC6052].
			IDC
			Short for "Internet Data Centre"; a data centre whose main purpose
			is to deliver services to the public Internet, the use case SIIT-
			DC is primarily targeted at. IDCs are typically operated by
			Internet Content Providers or Managed Services Providers.
			SIIT
			The Stateless IP/ICMP Translation algorithm, as specified in
			[RFC6145].
	XLAT		XLAT
	Used in figures to indicate where the Stateless IP/ICMP		Short for "Translation". Used in figures to indicate where a BR/
	Translation [RFC6145] algorithm is used to translate IPv4 packets		ER uses SIIT [RFC6145] to translate IPv4 packets to IPv6 and vice
	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 Translator Description		3. Edge Relay Description
	An Edge Translator (ET) is at its core an implementation of the		An Edge Relay (ER) is at its core an implementation of the Stateless
	Stateless IP/ICMP Translation algorithm [RFC6145], with the Static		IP/ICMP Translation algorithm [RFC6145] that supports Explicit
	Address Mapping extension described in Section 5.2 of		Address Mappings [I-D.ietf-v6ops-siit-eam]. It provides virtual IPv4
	[I-D.ietf-v6ops-siit-dc]. It provides virtual IPv4 connectivity for		connectivity for nodes or applications which require this to operate
	application software or devices which require this to operate
	correctly in an SIIT-DC environment.		correctly in an SIIT-DC environment.
	Inbound IPv4 packets destined for an IPv4 Service Address is first		Packets from the IPv4 Internet destined for an IPv4 Service Address
	translated to IPv6 by an SIIT-DC Gateway. The resulting IPv6 packets		is first translated to IPv6 by a BR. The resulting IPv6 packets are
	are subsequently forwarded to the ET handling the IPv6 Service		subsequently forwarded to the ER that owns the IPv6 Service Address
	Address they are addressed to. The ET then translates them back to		the translated packets are addressed to. The ER then translates them
	IPv4 before forwarding them to the IPv4 application software or		back to IPv4 before forwarding them to the IPv4 application or node.
	device. In the other direction, the exact same translations happen,		In the other direction, the exact same translations happen, only in
	only in reverse. This process provides end-to-end transparency of		reverse. This process provides end-to-end transparency of IPv4
	IPv4 addresses.		addresses.
	An ET may handle an arbitrary number of IPv4 Service Addresses. All		An ER may handle an arbitrary number of IPv4/IPv6 Service Addresses.
	the Static Address Mappings configured in the SIIT-DC Gateway(s) that		All the EAMs configured in the BR that involve the IPv4/IPv6 Service
	involve the IPv4 Service Addresses handled by an ET MUST be		Addresses handled by an ER MUST also be present in the ER's
	duplicated in that ET's configuration.		configuration.
	An ET 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 host, 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
	devices which 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 device or application software support it.		the node or application support it.
	The choice between a host- or network-based ET is made on a per-		The choice between a node- or network-based ER is made on a per-
	service or -device basis. An arbitrary number of each type of ET may		service or per-node basis. An arbitrary number of each type of ER
	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. Host-Based Edge Translator		3.1. Node-Based Edge Relay
	Overview of a Host-based Edge Translator		A Node-based Edge Relay
	[IPv4 Internet] [IPv6 Internet]		[IPv4 Internet] [IPv6 Internet]
	| |		| |
	+--|--<SIIT-DC GW>--+ |		+-----|-----+ |
	| [XLAT] | |		| (BR/XLAT) | |
	+--|----------------+ |		+-----|-----+ |
	| |		| | +-----<IPv6-only node/server>----------+
	[IPv6-only data centre network]		[IPv6-only IDC network] | +----------------+|
	|		| | /--(ER/XLAT)--AF_INET Dual-stack ||
	+--|--<IPv6-only server>---------------+		\-------------------------+ | Application ||
	| | +----------------+|		| \------------AF_INET6 Software ||
	| +--[ET/XLAT]--AF_INET Dual-stack ||		| +----------------+|
	| | | Application ||		+--------------------------------------+
	| \------------AF_INET6 Software ||
	| +----------------+|
	+--------------------------------------+
	Figure 1		Figure 1
	A host-based Edge Translator is typically implemented as a logical		A node-based ER is typically implemented as a logical software
	software function that runs inside the operating system of a host or		function that runs inside the operating system of an IPv6 node. It
	server. It provides software applications running on the same host		provides applications running on the same node with IPv4
	with IPv4 connectivity. The IPv4 Service Address it handles is		connectivity. Its IPv4 Service Address SHOULD be considered a
	considered local, allowing application software running on the same		regular local address that allows application running on the same
	host to use traditional 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 listens for and accepts incoming connections to its IPv4		sockets that listen for and accept incoming connections to its IPv4
	Service Address. An ET could accomplish this by creating an 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.		points a default IPv4 route. This approach is similar to the "Bump-
			in-the-Stack" approach discussed in [RFC6535], however it does not
			include an Extension Name Resolver.
	As shown in Figure 1, if the application software 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 SIIT-DC Gateway nor the ET will		using native IPv6. Neither the BR nor the ER will intercept this
	intercept this communication. Support for IPv6 in the application		communication. Support for IPv6 in the application is however not a
	software is however not a requirement; the application software may		requirement; the application may opt not to establish any IPv6
	opt not to establish any IPv6 sockets. Foregoing IPv6 in this manner		sockets. Foregoing IPv6 in this manner will simply preclude
	will simply preclude connectivity to the service from IPv6-only		connectivity to the service from IPv6-only clients; connectivity to
	clients; connectivity to the service from IPv4 clients (through the		the service from IPv4 clients (through the BR) will continue work in
	SIIT-DC Gateway) will work in the exact same manner in both cases.		the same way.
	The ET 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 host, whose operating		traffic to these IPv6 Service Addresses to the node, whose operating
	system must in turn forward them to the ET. This document does not		system MUST in turn forward them to the ER. This document does not
	explore the multitude of ways this could be accomplished, however		attempt to fully explore the multitude of ways this could be
	considering that the IPv6 protocol is designed for having multiple		accomplished, however considering that the IPv6 protocol is designed
	addresses assigned to a single node, one particularly straight-		for having multiple addresses assigned to a single node, one
	forward way would be to assign the ET's IPv6 Service Addresses as		particularly straight-forward way would be to assign the ER's IPv6
	secondary IPv6 addresses on the host itself so that it the upstream		Service Addresses as secondary IPv6 addresses on the node itself so
	router learns of their location using the IPv6 Neighbor Discovery		that it the upstream router learns of their location using the IPv6
	Protocol [RFC4861].		Neighbor Discovery Protocol [RFC4861].
	3.2. Network-Based Edge Translator		3.2. Network-Based Edge Relay
	Overview of a Basic Network-based Edge Translator		A Basic Network-based Edge Relay
	[IPv4 Internet] [IPv6 Internet]		[IPv4 Internet] [IPv6 Internet]
	| |		| |
	+--|--<SIIT-DC GW>--+ |		+-----|-----+ |
	| [XLAT] | |		| (BR/XLAT) | |
	+--|----------------+ |		+-----|-----+ |
	| |		| |
	[IPv6-only data centre network]		[IPv6-only IDC network] +--<IPv4-only node/server>--+
	|		| | +----------------+|
	+--|--<ET>--+		+-----|-----+ [v4-only] | | IPv4-only ||
	| [XLAT] |		| (ER/XLAT)-----[network]--------AF_INET Application ||
	+--|--------+		+-----------+ [segment] | | Software ||
	|		| +----------------+|
	[Isolated IPv4-only network segment]		+---------------------------+
	|
	+--|--<IPv4-only server>----+
	| | +----------------+|
	| \--AF_INET IPv4-only ||
	| | Application ||
	| | Software ||
	| +----------------+|
	+---------------------------+
	Figure 2		Figure 2
	A network-based Edge Translator performs the exact same as a host-		A network-based ER performs the exact same as a node-based ER does,
	based ET does, only that instead of assigning the IPv4 Service		only that instead of assigning the IPv4 Service Addresses to an
	Addresses to an internal-only virtual network adapter, traffic		internal-only virtual network adapter, traffic destined for them are
	destined for them are forwarded onto a network segment to which hosts		forwarded onto a network segment to which nodes that require IPv4
	that require IPv4 connectivity connect to. The ET also functions as		connectivity connect to. The ER also functions as the default IPv4
	the default IPv4 router for the hosts on this network segment.		router for the nodes on this network segment.
	Each host on the IPv4 network segment must acquire and assign an IPv4
	Service Address to a local network interface. This document does not
	attempt to explore all the various methods by which this can be
	accomplished, however one relatively straight-forward possibility
	would be to ensure the IPv4 Service Address(es) can be enclosed in an
	IPv4 prefix. The ET will then claim one address in this prefix for
	itself (used as the IPv4 default router address), and could assign
	the IPv4 Service Address(es) to the host(s) using DHCPv4. For
	example, if the IPv4 Service Addresses are 192.0.2.26 and 192.0.2.27,
	the ET would configure the address 192.0.2.25/29 on its IPv4-facing
	interface and would add the two IPv4 Service Addresses to its DHCPv4
	pool.
	One disadvantage of this method is that IPv4 communication between
	the IPv4 hosts and other services made available through SIIT-DC
	using the method described in Section 6 becomes impossible, if those
	other services are assigned IPv4 Service Addresses that also are
	covered by the same IPv4 prefix (e.g., 192.0.2.28). This is because
	the IPv4 nodes will mistakenly believe they have an on-link route to
	the entire prefix, and attempt to resolve the addresses using ARP
	(instead of forwarding them to the ET for translation to IPv6). This
	problem could however be overcome by avoiding assigning IPv4 Service
	Addresses which overlaps with an IPv4 prefix handled by an ET (at the
	expense of wasting some potential IPv4 Service Addresses), or by
	ensuring that they are only assigned to services which do not need to
	communicate with the IPv4 host(s) behind the ET.
	Another way to avoid the problem is to use a private unrouted IPv4		Each node on the IPv4 network segment MUST acquire and assign an IPv4
	network that does not encompass the IPv4 Service Addresses as the		Service Address to a local network interface. While this document
	IPv4, and instead assign the IPv4 Service Addresses as secondary		does not attempt to explore all the various methods by which this
	addresses on the servers. The ET must then route each IPv4 Service		could be accomplished, some examples are provided in Appendix A.
	Address to its respective server using the server's private on-link
	IPv4 address as the next-hop. This approach would ensure there are
	no overlaps, but on the other hand it would preclude the use of
	DHCPv4 for assigning the IPv4 Service Addresses, as well as create a
	need to ensure that the IPv4 application software is selecting the
	IPv4 Service Address (as opposed to its private on-link IPv4 address)
	as its source address when initiating outbound connections.
	The basic ET illustrated in Figure 2 establishes an IPv4-only network		The basic ER illustrated in Figure 2 establishes an IPv4-only network
	segment behind itself. This is fine if the devices it provides IPv4		segment between itself and the IPv4-only nodes it serves. This is
	access have no support for IPv6 whatsoever; however if they are dual-		fine if the nodes it provides IPv4 access have no support for IPv6
	stack capable, it is would not be ideal to take away their IPv6		whatsoever; however if they are dual-stack capable, it is would not
	connectivity. While it is recommended to use a host-based ET in this		be ideal to take away their IPv6 connectivity in this manner. While
	case, appropriate implementations of a host-based ET might not be		it is RECOMMENDED to use a node-based ER in this case, appropriate
	available for every device. If the application protocol does not		implementations of a node-based ER might not be available for every
	work correctly in a NAT environment, standard SIIT-DC cannot be used		node. If the application protocol in question does not work
	either. Thus, a network-based ET is the only solution.		correctly in a NAT environment, standard SIIT-DC cannot be used
			either, which leaves a network-based ER is the only remaining
			solution. The following subsections contains examples on how the ER
			could be implemented in a way that provides IPv6 connectivity for
			dual-stack capable nodes.
	The operator could avoid breaking the hosts' IPv4 connectivity by		3.2.1. Edge Router "On A Stick"
	connecting the ET's IPv4 and IPv6 interfaces to the same network
	segment, or by using a single dual-stacked interface instead. The
	latter alternative is shown in Figure 3. This could be thought of as
	an "ET on a stick". IPv6 traffic between the network and the hosts
	will bypass the ET entirely. IPv4 traffic from the hosts will be
	routed directly to the ET (because it's their default IPv4 router),
	and translated to IPv6 before its being transmitted to the upstream
	default IPv6 router. The ET could attract inbound traffic to its
	IPv6 Service Addresses by responding to the upstream router's IPv6
	Neighbor Discovery [RFC4861] messages for them.
	A Network-based Edge Translator "on a stick"		A Network-based Edge Relay "On A Stick"
	[IPv4 Internet] [IPv6 Internet]		[IPv4 Internet] [IPv6 Internet]
	| |		| |
	+--|--<SIIT-DC GW>--+ |		+-----|-----+ |
	| [XLAT] | |		| (BR/XLAT) | |
	+--|----------------+ |		+-----|-----+ |
	| |		| |
	[IPv6-only data centre network]		[IPv6-only IDC network]
	|		|
	| +--<ET>------+		| +-------------+
	| | ____ |		| | _IPv6_ |
	| | / \ |		| | / \ |
	+==== [XLAT] |		+==== (ER/XLAT) |
	| | \____/ |		| | \_ _/ |
	| | |		| | IPv4 | +--<Dual stack node/server>--+
	| +------------+		| +-------------+ | +----------------+|
	|		| | /---AF_INET Dual-stack ||
	[Dual-stack network segment]		[Dual-stack network segment]----< | Application ||
	|		| \--AF_INET6 Software ||
	+--|--<Dual-stack server>----+		| +----------------+|
	| | +----------------+|		+----------------------------+
	| +---AF_INET Dual-stack ||
	| | | Application ||
	| \--AF_INET6 Software ||
	| +----------------+|
	+----------------------------+
	Figure 3		Figure 3
	Yet another variation would be to implement the ET so that it		The ER "On A Stick" approach illustrated in Figure 3 ensures that the
	transparently passes IPv6 traffic between its downstream and upstream		dual-stack capable node retains native IPv6 connectivity by
	network ports unmodified, e.g., using Layer-2 bridging. Packets sent		connecting the ER's IPv4 and IPv6 interfaces to the same network
	to its own IPv6 Service Addresses from the upstream network are		segment, alternatively by using a single dual-stacked interface.
	intercepted (e.g, by responding to IPv6 Neighbor Discovery [RFC4861]		Native IPv6 traffic between the IDC network and the node bypasses the
	messages for them) and routed through the translation function, and		ER entirely, while IPv4 traffic from the node will be routed directly
	forwarded out its downstream interface. The downstream network		to the ER (because it acts as its default IPv4 router), where it is
	segment is thus becomes dual-stacked. This model is shown in Figure		translated to IPv6 before being transmitted to the upstream default
	4.		IPv6 router. The ER could attract inbound traffic to the IPv6
			Service Addresses by responding to the upstream router's IPv6
	A Transparent Network-based Edge Translator		Neighbor Discovery [RFC4861] messages for them.
	[IPv4 Internet] [IPv6 Internet]
	| |
	+--|--<SIIT-DC GW>--+ |
	| [XLAT] | |
	+--|----------------+ |
	| |
	[IPv6-only data centre network]
	|
	+--|--<Edge Translator>--+
	| |\_____________ |
	| | \ |
	| [Bridged IPv6] [XLAT] |
	| | _____________/ |
	| |/ |
	+--|---------------------+
	|
	[Dual-stack network segment]
	|
	+--|--<Dual-stack server>----+
	| | +----------------+|
	| +---AF_INET Dual-stack ||
	| | | Application ||
	| \--AF_INET6 Software ||
	| +----------------+|
	+----------------------------+
	Figure 4
	4. Detailed Topology Example
	The following figure shows how an application (that is presumably		3.2.2. Edge Router that Bridges IPv6 Packets
	incompatible with standard SIIT-DC) is being made available to the
	IPv4 Internet on the IPv4 address 192.0.2.4. The application will be
	able to know that this is its local address and thus be able to
	provide correct references to it in application payload.
	The figure also shows how the same application is available over IPv6		A Network-based Edge Relay containing an IPv6 Bridge
	on its IPv6 Service Address 2001:db8:12:34::3. This is included in
	order to illustrate how native IPv6 connectivity is not impacted by
	the Edge Translator, and also to illustrate how the address assigned
	to the ET (2001:db8:12:34::4) is separate from the primary IPv6
	address of the server. It is however important to note that the
	application in question does not have to be dual-stack capable at
	all. IPv4-only applications would also be able to operate behind an
	ET in the exact same manner.
	Note that the figure below could be considered a more detailed view		[IPv4 Internet] [IPv6 Internet]
	of Customer A's FTP server from the example topology figure in		| |
	Appendix A of [I-D.ietf-v6ops-siit-dc]. Both figures intentionally		+-----|-----+ |
	use the exact same example IP addresses and prefixes.		| (BR/XLAT) | |
			+-----|-----+ |
			| |
			[IPv6-only IDC network]
			|
			+-----------|--------------+
			| ____/ \_IPv6_ |
			| / \ |
			| (IPv6 Bridge) (ER/XLAT) |
			| \____ _ _/ |
			| \ / IPv4 | +--<Dual stack node/server>--+
			+-----------|--------------+ | +----------------+|
			| | /---AF_INET Dual-stack ||
			[Dual-stack network segment]----< | Application ||
			| \--AF_INET6 Software ||
			| +----------------+|
			+----------------------------+
	SIIT-DC Host Architecture with Edge Translation		Figure 4
	+-------------------+ +----------------+		The ER illustrated in Figure 4 will transparently bridge IPv6 frames
	| IPv6-capable user | | IPv4-only user |		between its upstream and downstream interfaces. IPv6 packets
	| ================= | | ============== |		addressed the ER's own IPv6 Service Addresses from the upstream IDC
	| | | |		network are intercepted (e.g., by responding to IPv6 Neighbor
	+-<2001:db8::ab:cd>-+ +-<203.0.113.50>-+		Discovery [RFC4861] messages for them) and routed through the
	| |		translation function before being forwarded out its downstream
	(the IPv6 internet) (the IPv4 Internet)		interface as IPv4 packets. The downstream network segment thus
	| |		becomes dual-stacked.
	| +------------------<192.0.2.0/24>-+
	| | |
	| | SIIT-DC Gateway |
	| | =============== |
	| | |
	| | Translation Prefix: |
	| | 2001:db8:46::/96 |
	| | |
	| | Static Address Mapping: |
	| | 192.0.2.4 <=> 2001:db8:12:34::4 |
	| | |
	| +--------------<2001:db8:46::/96>-+
	| |
	(the IPv6-only data centre network)
	| |
	+--<2001:db8:12:34::3>-------<2001:db8:12:34::4>---+
	| | | |
	| | IPv6-only server | |
	| | ================ | |
	| | | |
	| | +-------------<2001:db8:12:34::4>-+ |
	| | | | |
	| | | Edge Translator | |
	| | | =============== | |
	| | | | |
	| | | Translation Prefix: | |
	| | | 2001:db8:46::/96 | |
	| | | | |
	| | | Static Address Mapping: | |
	| | | 192.0.2.4 <=> 2001:db8:12:34::4 | |
	| | | | |
	| | +---------------------<192.0.2.4>-+ |
	| | | |
	| +-[2001:db8:12:34::3]--------------[192.0.2.4]-+ |
	| | AF_INET6 AF_INET | |
	| | | |
	| | Dual-stacked application | |
	| | | |
	| +----------------------------------------------+ |
	+--------------------------------------------------+
	Figure 5
	5. Deployment Considerations		4. Deployment Considerations
	5.1. IPv6 Path MTU		4.1. IPv6 Path MTU
	The IPv6 Path MTU between the Edge Translator and the SIIT-DC Gateway		The IPv6 Path MTU between the ER and the BR will typically be larger
	will typically be larger than the default value defined in Section 4		than the default value defined in Section 4 of [RFC6145] (1280), as
	of [RFC6145] (1280), as it will typically contained within a single		it will typically contained within a single administrative domain.
	administrative domain. Therefore, it is recommended that the IPv6		Therefore, it is RECOMMENDED that the IPv6 Path MTU configured in the
	Path MTU configured in the ET is raised accordingly. It is		ER is raised accordingly. It is RECOMMENDED that the ER and the BR
	RECOMMENDED that the ET and the SIIT-DC Gateway use identical		use identical configured IPv6 Path MTU values.
	configured IPv6 Path MTU values.
	5.2. IPv4 MTU		4.2. IPv4 MTU
	In order to avoid IPv6 fragmentation, an Edge Translator should		In order to avoid IPv6 fragmentation, an ER SHOULD ensure that the
	ensure that the IPv4 MTU used by applications or hosts is equal to		IPv4 MTU used by applications or nodes is equal to the configured
	the configured IPv6 Path MTU - 20, so that an maximum-sized IPv4		IPv6 Path MTU - 20, so that an maximum-sized IPv4 packet can fit in
	packet can fit in an unfragmented IPv6 packet. This ensures that the		an unfragmented IPv6 packet. This ensures that the application may
	application may do its part in avoiding IP-level fragmentation from		do its part in avoiding IP-level fragmentation from occurring, e.g.,
	occurring, e.g., by segmenting/fragmenting outbound packets at the		by segmenting/fragmenting outbound packets at the application layer,
	application layer, and advertising the maximum size its peer may use		and advertising the maximum size its peer may use for inbound packets
	for inbound packets (e.g., through the use of the TCP MSS option).		(e.g., through the use of the TCP MSS option).
	A host-based ET 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 ET could do so		on the virtual network adapter, while a network-based ER could do so
	by advertising the MTU to its downstream hosts using the DHCPv4		by advertising the MTU to its downstream nodes using the DHCPv4
	Interface MTU Option [RFC2132].		Interface MTU Option [RFC2132].
	5.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 carried end-to-end.
	Note that for this to work bi-directionally, IPv6 Atomic Fragment		Note that for this to work bi-directionally, IPv6 Atomic Fragment
	generation must be enabled on both the SIIT-DC Gateway(s) and on the		generation MUST be enabled on both the BR and the ER.
	Edge Translator.
	Note that 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.		therefore 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.8.2 of		header is further discussed in Section 4.9.2 of
	[I-D.ietf-v6ops-siit-dc].		[I-D.ietf-v6ops-siit-dc].
	6. Intra-DC IPv4 Communication		5. Intra-IDC IPv4 Communication
	While SIIT-DC is primarily intended to facilitate communication
	between IPv4-only nodes on the Internet and services hosted in an
	IPv6-only network, it is also possible to facilitate communication
	between an IPv4-only service or application running behind an Edge
	Translator and another service/application made available over IPv4
	through SIIT-DC. This other service/application may be a IPv6-only
	service, or it may also be an IPv4-only service running behind
	another ET.
	Facilitating such communication requires that another Static Address
	Mapping is configured in the ET (one for each service it wants to
	communicate to). If there are two ETs involved, both of them must be
	configured in the same fashion for bi-directional communication to
	work. The following two subsections contain examples that
	demonstrate how this may be set up.
	Note that for the intra-DC communication described in this section,
	the SIIT-DC Gateway is not involved at all. Therefore there is no
	requirement that the Static Address Mappings in question are also
	configured on the SIIT-DC Gateway. It is also possible to use
	private [RFC1918] IPv4 addresses, in order to reduce the need for
	publicly routable IPv4 addresses. However, if the IPv4-only
	application(s) are also to be made available to the IPv4 Internet
	through an SIIT-DC Gateway, it is highly recommended that the Static
	Address Mappings configured in the ET match those configured in the
	SIIT-DC Gateway. Otherwise one end up in the situation where a
	service is reached using different IPv4 addresses depending on
	whether one connects to it from the IPv4 Internet or from another
	IPv4-only application residing in the same data centre. While it may
	still work, the overall architecture gets significantly more complex.
	Finally, if both services/applications support IPv6, it is highly
	recommended that IPv6 is used for all internal communications. The
	approach described in this section should only be used if one or both
	of the services or applications only supports IPv4, making native
	IPv6 communication impossible.
	6.1. Between IPv4-Only and IPv6-Only Services
	This section demonstrates how an IPv4-only service/application "A"
	running behind an ET can communicate with an IPv6-only service "B".
	Intra-DC IPv4-only to IPv6-only Overview
	/--------------------------------------\		Although SIIT-DC is primarily intended to facilitate communication
	| IPv6-only data centre network |		between IPv4-only nodes on the Internet and services located in an
	\-+----------------------------------+-/		IPv6-only IDC network, an IPv4-only node or application located
	| |		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
	+--<2001:db8:6::>----------------+ +--<2001:db8:7::>----------------+		through the ER, as it will typically be incapable to contact IPv6
	| | | | | |		destinations directly. The following subsections discusses various
	| | IPv6-only server A | | | IPv6-only server B |		methods on how to facilitate such communication.
	| | ================== | | | ================== |
	| | | | | |
	|+-<2001:db8:6::>---------------+| |+-[2001:db8:7::]---------------+|
	|| || || AF_INET6 ||
	|| Edge Translator A || || ||
	|| ================= || || IPv6-only application B ||
	|| || |+------------------------------+|
	|| Static Address Mappings: || +--------------------------------+
	|| 192.0.2.6 <=> 2001:db8:6:: ||
	|| 192.0.2.7 <=> 2001:db8:7:: ||
	|| ||
	|+-<192.0.2.6>------------------+|
	| | |
	|+-[192.0.2.6]------------------+|
	|| AF_INET ||
	|| ||
	|| IPv4-only application A ||
	|+------------------------------+|
	+--------------------------------+
	Figure 6		5.1. Hairpinning by the SIIT-DC Border Relay
			If the BR supports hairpinning as described in Section 4.2 of I-D
			.ietf-v6ops-siit-eam [I-D.ietf-v6ops-siit-eam], the easiest solution
			is to make the target service available through SIIT-DC in the normal
			way, that is, by provisioning an EAM to the BR that assigns an IPv4
			Service Address with the target service's IPv6 Service Address.
	In this example, the IPv4-only application on server "A" is listening		This allows the IPv4-only node or application to transmit packets
	on the IPv4 address 192.0.2.6, which is made available to the IPv6		destined for the target service's IPv4 Service Address, which the ER
	network on the IPv6 address 2001:db8:6:: (by the ET). The IPv6-only		will then translate to a corresponding IPv4-converted IPv6 address by
	application on server "B" is only listening on the IPv6 address		inserting the Translation Prefix [RFC6052]. When this IPv6 packet
	2001:db8:7::, and has no knowledge of IPv4.		reaches the BR, it will be hairpinned and transmitted back to the
			target service's IPv6 Service Address (where it could possibly pass
			through another ER before reaching the target service). Return
			traffic from the target service will be hairpinned in the same
			fashion.
	In order to facilitate communication between the two application,		Hairpinned IPv4-IPv4 packet flow
	another Static Address Mapping must be configured in the ET on server
	"A". This provides an IPv4 address (192.0.2.7) that the IPv4-only
	application can communicate with, which represents the IPv6 address
	used by application "B" (2001:db8:7::).
	The following figure shows the packet translations step by step, for		+-[Pkt#1: IPv4]-+ +--[Pkt#2: IPv6]-------------+
	a packet sent by the IPv4-only application "A" to the IPv6-only		| SRC 192.0.2.1 | (XLAT#1) | SRC 2001:db8:a:: |
	application "B". For traffic in the opposite direction, you may read		| DST 192.0.2.2 |--(@ ER A)-->| DST 2001:db8:46::192.0.2.2 |---\
	the figure from the bottom up and swap the Src/Dst addresses.		+---------------+ +----------------------------+ |
			(XLAT#2)
			+-[Pkt#4: IPv4]-+ +--[Pkt#3: IPv6]-------------+ ( @ BR )
			| 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:: |<--/
			+---------------+ +----------------------------+
	Intra-DC IPv4-only to IPv6-only Packet Flow		Figure 5
	(IPv4-only application A) --\		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
	Src 192.0.2.6 |		ER B. ER A is configured with the EAM {192.0.2.1,2001:db8:a::}, ER B
	Dst 192.0.2.7 | Packet forwarding/translations		with {192.0.2.2,2001:db8:b::}. The BR is configured with both EAMs,
	| | happening inside server A		and supports hairpinning. Note that if the target service had not
	V |		been located behind an ER, the third and final translation (XLAT#3)
	[SIIT-DC ET A] |		would not have happened, i.e., the target service/node would have
	| --/		received and responded to packet #3 directly.
	| --\
	Src 2001:db8:6:: | Actual IPv6 packets routed
	Dst 2001:db8:7:: | through the IPv6 network
	| --/
	V
	(IPv6-only application B)
	Figure 7		If the IPv4-only nodes/services do not need connectivity with the
			public IPv4 Internet, private IPv4 addresses [RFC1918] could be used
			as their IPv4 Service Addresses in order to conserve the IDC
			operator's pool of public IPv4 addresses.
	6.2. Between Two IPv4-Only Services		5.2. Additional EAMs Configured in Edge Relay
	This section demonstrates how an IPv4-only service/application "A"		If the BR does not support hairpinning, or if the hairpinning
	running behind an ET can communicate with an IPv4-only service/		solution is not desired for some other reason, intra-IDC IPv4 traffic
	application "B" running behind another ET.		may be facilitated by configuring additional EAMs on the ER for each
			service the IPv4-only node or application needs to communicate with.
			This makes the IPv6 traffic between the ER and the target service's
			IPv6 Service Address follow the direct path through the IPv6 network.
			The traffic does not pass the BR, which means that this solution
			might yield better latency than the hairpinning approach.
	Intra-DC IPv4-only to IPv6-only Overview		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
			application will contact the target's assigned IPv4 Service Address
			using its own IPv4 Service Address as the source. The ER will then
			proceed to translate this to an IPv6 packet with the local
			application/node's own IPv6 Service Address as source and the target
			service's IPv6 Service Address as the destination, and forward this
			to the IPv6 network. Replies from the target service will undergo
			these translations in reverse.
	/--------------------------------------\		If the target service is also located behind another ER, that other
	| IPv6-only data centre network |		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.
	+--<2001:db8:8::>----------------+ +--<2001:db8:9::>----------------+
	| | | | | |
	| | IPv6-only server A | | | IPv6-only server B |
	| | ================== | | | ================== |
	| | | | | |
	|+-<2001:db8:8::>---------------+| |+-<2001:db8:9::>---------------+|
	|| || || ||
	|| Edge Translator A || || Edge Translator B ||
	|| ================= || || ================= ||
	|| || || ||
	|| Static Address Mappings: || || Static Address Mappings: ||
	|| 192.0.2.8 <=> 2001:db8:8:: || || 192.0.2.8 <=> 2001:db8:8:: ||
	|| 192.0.2.9 <=> 2001:db8:9:: || || 192.0.2.9 <=> 2001:db8:9:: ||
	|| || || ||
	|+-<192.0.2.8>------------------+| |+-<192.0.2.9>------------------+|
	| | | | | |
	|+-[192.0.2.8]------------------+| |+-[192.0.2.9]------------------+|
	|| AF_INET || || AF_INET ||
	|| || || ||
	|| IPv4-only application A || || IPv4-only application B ||
	|+------------------------------+| |+------------------------------+|
	+--------------------------------+ +--------------------------------+
	Figure 8		Non-hairpinned IPv4-IPv4 packet flow
	In this example, the IPv4-only application on server "A" is listening		+-[Pkt#1: IPv4]-+ +--[Pkt#2: IPv6]---+
	on the IPv4 address 192.0.2.8, which is made available to the IPv6		| SRC 192.0.2.1 | (XLAT#1) | SRC 2001:db8:a:: |
	network on the IPv6 address 2001:db8:8:: (by the ET). In the same		| DST 192.0.2.2 |--(@ ER A)-->| DST 2001:db8:b:: |
	fashion, the IPv4-only application on server "B" is listening on the		+---------------+ +------------------+
	IPv4 address 192.0.2.9 and is made available by its ET on the IPv6		|
	address 2001:db8:9::.		+-[Pkt#3: IPv4]-+ |
			| SRC 192.0.2.1 | (XLAT#2) |
			| DST 192.0.2.2 |<-------(@ ER B)------/
			+---------------+
	In order to facilitate communication between the two application, a		Figure 6
	second Static Address Mapping must be configured in the ET on both
	servers. This provides each application with an IPv4 address that
	represents the other application. Thus bi-directional communication
	between the two applications can commence.
	The following figure shows the packet translations step by step, for		Figure 6 illustrates the flow of a packet carrying intra-IDC IPv4
	a packet sent by the IPv4-only application "A" to the IPv4-only		traffic between two IPv4-only nodes/applications that are both
	application "B". For traffic in the opposite direction, you may read		located behind ERs. Both ER A and ER B are configured with two EAMs:
	the figure from the bottom up and swap the Src/Dst addresses.		{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;
			the BR is not involved and the packet will not be hairpinned.
	Intra-DC IPv4-only to IPv4-only Packet Flow		The above approach is not mutually exclusive with the hairpinning
			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
			from other IPv4-only services/nodes using the hairpinning approach.
			They would also be reachable from the IPv4 Internet.
	(IPv4-only application A) --\		Note that if the target service in this example was not located
	| |		behind an ER, but instead was a native IPv6 service listening on
	Src 192.0.2.8 |		2001:db8:b::, the second translation step in Figure 6 would not
	Dst 192.0.2.9 | Packet forwarding/translations		occur; the target service would receive and respond to packet #2
	| | happening inside server A		directly.
	V |
	[SIIT-DC ET A] |
	| --/
	| --\
	Src 2001:db8:8:: | Actual IPv6 packets routed
	Dst 2001:db8:9:: | through the IPv6 network
	| --/
	V --\
	[SIIT-DC ET B] |
	| |
	Src 192.0.2.8 | Packet forwarding/translations
	Dst 192.0.2.9 | happening inside server B
	| |
	V |
	(IPv4-only application B) --/
	Figure 9		As with the hairpinning approach, if the IPv4-only nodes/services do
			not need connectivity to/from the public IPv4 Internet, private IPv4
			addresses [RFC1918] could be used as their IPv4 Service Addresses.
			Alternatively, in the case where the target service is on native
			IPv6, the target's assigned IPv4 Service Address has only local
			significance behind the ER. It could therefore be assigned from the
			IPv4 Service Continuity Prefix [RFC7335].
	7. 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, Ray Hunter, Shucheng LIU (Will), Andrew
	Yourtchenko.		Yourtchenko.
	8. 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. The RFC Editor may remove
	this section prior to publication.		this section prior to publication.
	9. 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 Edge Translator. 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 additional security considerations
	applicable to the SIIT-DC architecture in general.		applicable to the SIIT-DC architecture in general.
	9.1. Address Spoofing		8.1. Address Spoofing
			If the ER receives an IPv4 packet from the application/node from a
	If the ET receives an IPv4 packet from the application from a		source address it does not have an EAM for, both the source and
	different source address than the one it has a Static Address Mapping		destination addresses will be rewritten according to [RFC6052].
	for, the both the source and destination addresses will be rewritten		After undergoing the reverse translation in the BR, the resulting
	according to [RFC6052]. After undergoing the reverse translation in		IPv4 packet routed to the IPv4 network will have a spoofed IPv4
	the SIIT-DC Gateway, the resulting IPv4 packet routed to the IPv4		source address. The ER SHOULD therefore ensure that ingress
	network will have a spoofed IPv4 source address. The ET should		filtering [RFC2827] is used on the ER's IPv4 interface, so that such
	therefore ensure that ingress filtering (cf. BCP38 [RFC2827]) is used		packets are immediately discarded.
	on the ET's IPv4 interface, so that such packets are immediately
	discarded.
	If the ET 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 the one it has a Static Address Mapping		destination address equal to one of its local IPv6 Service Addresses,
	for, the resulting packet would appear to the application as locally		the resulting packet would appear to the IPv4-only application/node
	generated, as both the source address and the destination address		as locally generated, as both the source address and the destination
	will be the same address as the one configured on the virtual IPv4		address will be the same address. This could trick the application
	interface. This could trick the application into thinking this		into believing the packet came from a trusted source (itself). To
	packet came from a trusted source, and give elevated privileges		prevent this, the ER SHOULD discard any received IPv6 packets that
	accordingly. To prevent this, the ET should discard any received		have a source address that is either 1) equal to any of its local
	IPv6 packets that have a source address that is equal either to		IPv6 Service Addresses, or 2) after translation from IPv6 to IPv4,
	either the IPv4 (after undergoing [RFC6052] translation) or the IPv6		equal to any of its local IPv4 Service Addresses.
	address in the Static Address Mapping.
	10. References		9. References
	10.1. Normative References		9.1. Normative References
	[I-D.ietf-v6ops-siit-dc]		[I-D.ietf-v6ops-siit-dc]
	tore, t., "SIIT-DC: Stateless IP/ICMP Translation for IPv6		Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for
	Data Centre Environments", draft-ietf-v6ops-siit-dc-00		IPv6 Data Centre Environments", draft-ietf-v6ops-siit-
	(work in progress), December 2014.		dc-00 (work in progress), December 2014.
			[I-D.ietf-v6ops-siit-eam]
			Anderson, T. and A. Leiva, "Explicit Address Mappings for
			Stateless IP/ICMP Translation", draft-ietf-v6ops-siit-
			eam-00 (work in progress), May 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, March 1997.
	10.2. Informative References		9.2. Informative References
			[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
			converting network protocol addresses to 48.bit Ethernet
			address for transmission on Ethernet hardware", STD 37,
			RFC 826, November 1982.
	[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and		[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
	E. Lear, "Address Allocation for Private Internets", BCP		E. Lear, "Address Allocation for Private Internets", BCP
	5, RFC 1918, February 1996.		5, RFC 1918, February 1996.
			[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
			2131, March 1997.
	[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, March 1997.
	[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, May 2000.
	[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.		September 2007.
	[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.		October 2010.
	[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, April 2011.
			[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
			Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012.
			[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
			"Default Address Selection for Internet Protocol Version 6
			(IPv6)", RFC 6724, September 2012.
	[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, April 2013.
	Author's Address		[RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335,
			August 2014.
			Appendix A. Examples: Network-Based IPv4 Connectivity
			A.1. Subnet with IPv4 Service Addresses
			One relatively straight-forward way to provide IPv4 connectivity
			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
			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 assign the IPv4 Service Address(es) to its downstream node(s)
			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
			192.0.2.25/29 on its IPv4-facing interface and would add the two IPv4
			Service Addresses to its DHCPv4 pool.
			One disadvantage of this method is that IPv4 communication between
			the IPv4 node(s) behind the ER and other services made available
			through SIIT-DC becomes impossible, if those other services are
			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
			will mistakenly believe they have an on-link route to the entire
			prefix, and attempt to resolve the addresses using ARP [RFC0826],
			instead of sending them to the ER for translation to IPv6. This
			problem could however be overcome by avoiding assigning IPv4 Service
			Addresses which overlaps with an IPv4 prefix handled by an ER (at the
			expense of wasting some potential IPv4 Service Addresses), or by
			ensuring that the overlapping IPv6 Service Addresses are only
			assigned to services which do not need to communicate with the IPv4
			node(s) behind the ER. A third way to avoid this problem is
			discussed in Appendix A.2.
			A.2. Subnet with Unrouted IPv4 Addresses
			In order to avoid the problem discussed in Appendix A.1, a private
			unrouted IPv4 network that does not encompass the IPv4 Service
			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
			its IPv4 Service Address as secondary local address, while the ER
			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
			approach would ensure there are no overlaps with IPv4 Service
			addresses elsewhere in the infrastructure, but on the other hand it
			would preclude the use of DHCPv4 [RFC2131] for assigning the IPv4
			Service Addresses.
			This approach creates a need to ensure that the IPv4 application is
			selecting the IPv4 Service Address (as opposed to its private on-link
			IPv4 address) as its source address when initiating outbound
			connections. This could be accomplished by altering the Default
			Address Selection Policy Table [RFC6724] on the IPv4 node.
			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
	URI: http://www.redpill-linpro.com		URI: http://www.redpill-linpro.com
			Sander Steffann
			S.J.M. Steffann Consultancy
			Tienwoningenweg 46
			Apeldoorn, Gelderland 7312 DN
			The Netherlands
			Email: sander@steffann.nl
End of changes. 91 change blocks.
	599 lines changed or deleted		499 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/