draft-ietf-v6ops-464xlat-09.txt		draft-ietf-v6ops-464xlat-10.txt
	Internet Engineering Task Force M. Mawatari		Internet Engineering Task Force M. Mawatari
	Internet-Draft Japan Internet Exchange Co.,Ltd.		Internet-Draft Japan Internet Exchange Co.,Ltd.
	Intended status: BCP M. Kawashima		Intended status: Informational M. Kawashima
	Expires: July 26, 2013 NEC AccessTechnica, Ltd.		Expires: August 27, 2013 NEC AccessTechnica, Ltd.
	C. Byrne		C. Byrne
	T-Mobile USA		T-Mobile USA
	January 22, 2013		February 23, 2013
	464XLAT: Combination of Stateful and Stateless Translation		464XLAT: Combination of Stateful and Stateless Translation
	draft-ietf-v6ops-464xlat-09		draft-ietf-v6ops-464xlat-10
	Abstract		Abstract
	This document describes an architecture (464XLAT) for providing		This document describes an architecture (464XLAT) for providing
	limited IPv4 connectivity across an IPv6-only network by combining		limited IPv4 connectivity across an IPv6-only network by combining
	existing and well-known stateful protocol translation RFC 6146 in the		existing and well-known stateful protocol translation RFC 6146 in the
	core and stateless protocol translation RFC 6145 at the edge. 464XLAT		core and stateless protocol translation RFC 6145 at the edge. 464XLAT
	is a simple and scalable technique to quickly deploy limited IPv4		is a simple and scalable technique to quickly deploy limited IPv4
	access service to IPv6-only edge networks without encapsulation.		access service to IPv6-only edge networks without encapsulation.
	skipping to change at page 1, line 38		skipping to change at page 1, line 38
	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 26, 2013.		This Internet-Draft will expire on August 27, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. BCP Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4		3. Motivation and Uniqueness of 464XLAT . . . . . . . . . . . . . 4
	4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Network Architecture . . . . . . . . . . . . . . . . . . . . . 4
	5. Motivation and Uniqueness of 464XLAT . . . . . . . . . . . . . 4		4.1. Wireline Network Architecture . . . . . . . . . . . . . . 4
	6. Network Architecture . . . . . . . . . . . . . . . . . . . . . 5		4.2. Wireless 3GPP Network Architecture . . . . . . . . . . . . 5
	6.1. Wireline Network Architecture . . . . . . . . . . . . . . 5		5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
	6.2. Wireless 3GPP Network Architecture . . . . . . . . . . . . 6		5.1. Wireline Network Applicability . . . . . . . . . . . . . . 6
	7. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7		5.2. Wireless 3GPP Network Applicability . . . . . . . . . . . 7
	7.1. Wireline Network Applicability . . . . . . . . . . . . . . 7		6. Implementation Considerations . . . . . . . . . . . . . . . . 7
	7.2. Wireless 3GPP Network Applicability . . . . . . . . . . . 8		6.1. IPv6 Address Format . . . . . . . . . . . . . . . . . . . 7
	8. Implementation Considerations . . . . . . . . . . . . . . . . 8		6.2. IPv4/IPv6 Address Translation Chart . . . . . . . . . . . 7
	8.1. IPv6 Address Format . . . . . . . . . . . . . . . . . . . 8		6.3. IPv6 Prefix Handling . . . . . . . . . . . . . . . . . . . 9
	8.2. IPv4/IPv6 Address Translation Chart . . . . . . . . . . . 8		6.4. DNS Proxy Implementation . . . . . . . . . . . . . . . . . 9
	8.3. IPv6 Prefix Handling . . . . . . . . . . . . . . . . . . . 10		6.5. CLAT in a Gateway . . . . . . . . . . . . . . . . . . . . 9
	8.4. DNS Proxy Implementation . . . . . . . . . . . . . . . . . 10		6.6. CLAT to CLAT communications . . . . . . . . . . . . . . . 9
	8.5. CLAT in a Gateway . . . . . . . . . . . . . . . . . . . . 10		7. Deployment Considerations . . . . . . . . . . . . . . . . . . 10
	8.6. CLAT to CLAT communications . . . . . . . . . . . . . . . 10		7.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 10
	9. Deployment Considerations . . . . . . . . . . . . . . . . . . 11		7.2. Traffic Treatment Scenarios . . . . . . . . . . . . . . . 10
	9.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 11		8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	9.2. Traffic Treatment Scenarios . . . . . . . . . . . . . . . 11		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 12		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12		11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		11.2. Informative References . . . . . . . . . . . . . . . . . . 12
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 13		Appendix A. Examples of IPv4/IPv6 Address Translation . . . . . . 13
	13.2. Informative References . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
	Appendix A. Examples of IPv4/IPv6 Address Translation . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	With the exhaustion of the unallocated IPv4 address pools, it will be		With the exhaustion of the unallocated IPv4 address pools, it will be
	difficult for many networks to assign IPv4 addresses to end users.		difficult for many networks to assign IPv4 addresses to end users.
	This document describes an IPv4 over IPv6 solution as one of the		This document describes an IPv4 over IPv6 solution as one of the
	techniques for IPv4 service extension and encouragement of IPv6		techniques for IPv4 service extension and encouragement of IPv6
	deployment. 464XLAT is not a one-for-one replacement of full IPv4		deployment. 464XLAT is not a one-for-one replacement of full IPv4
	functionality. The 464XLAT architecture only supports IPv4 in the		functionality. The 464XLAT architecture only supports IPv4 in the
	skipping to change at page 3, line 31		skipping to change at page 3, line 31
	require DNS64 [RFC6147] since an IPv4 host may simply send IPv4		require DNS64 [RFC6147] since an IPv4 host may simply send IPv4
	packets, including packets to an IPv4 DNS server, which will be		packets, including packets to an IPv4 DNS server, which will be
	translated on the customer side translator (CLAT) to IPv6 and back to		translated on the customer side translator (CLAT) to IPv6 and back to
	IPv4 on the provider side translator (PLAT). 464XLAT networks may use		IPv4 on the provider side translator (PLAT). 464XLAT networks may use
	DNS64 [RFC6147] to enable single stateful translation [RFC6146]		DNS64 [RFC6147] to enable single stateful translation [RFC6146]
	instead of 464XLAT double translation where possible. The 464XLAT		instead of 464XLAT double translation where possible. The 464XLAT
	architecture encourages the IPv6 transition by making IPv4 services		architecture encourages the IPv6 transition by making IPv4 services
	reachable across IPv6-only networks and providing IPv6 and IPv4		reachable across IPv6-only networks and providing IPv6 and IPv4
	connectivity to single-stack IPv4 or IPv6 servers and peers.		connectivity to single-stack IPv4 or IPv6 servers and peers.
	2. BCP Scenario		2. Terminology
	This document describes one way to deploy an IPv6-only access
	network, built on a 464XLAT architecture. Likely motivations for
	running an IPv6-only access network include the fact that IPv6-only
	single protocol operation is less complex and IPv4 addresses are
	scarce. Providing an IPv6-only network involves either tunneling or
	translation. This document describes how to build one type of
	solution based on translation. What is described herein has been
	implemented and shown to work well, and is the best current practice
	for building a service based on 464XLAT architecture.
	This BCP only applies when the following three criteria are present:
	1. There is an IPv6-only network that uses stateful translation
	[RFC6146] as the only mechanism for providing IPv4 access.
	2. There are IPv4-only applications or hosts that must communicate
	across the IPv6-only network to reach the IPv4 Internet.
	3. Existing business or technical artifacts preclude the use of a
	tunnel based IPv6 transition mechanism.
	3. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].
	4. Terminology
	PLAT: PLAT is Provider side translator(XLAT) that complies with		PLAT: PLAT is Provider side translator(XLAT) that complies with
	[RFC6146]. It translates N:1 global IPv6 addresses to global		[RFC6146]. It translates N:1 global IPv6 addresses to global
	IPv4 addresses, and vice versa.		IPv4 addresses, and vice versa.
	CLAT: CLAT is Customer side translator(XLAT) that complies with		CLAT: CLAT is Customer side translator(XLAT) that complies with
	[RFC6145]. It algorithmically translates 1:1 private IPv4		[RFC6145]. It algorithmically translates 1:1 private IPv4
	addresses to global IPv6 addresses, and vice versa. The CLAT		addresses to global IPv6 addresses, and vice versa. The CLAT
	function is applicable to a router or an end-node such as a		function is applicable to a router or an end-node such as a
	mobile phone. The CLAT SHOULD perform IP routing and		mobile phone. The CLAT should perform IP routing and
	forwarding to facilitate packets forwarding through the		forwarding to facilitate packets forwarding through the
	stateless translation even if it is an end-node. The CLAT as		stateless translation even if it is an end-node. The CLAT as
	a common home router or wireless Third Generation Partnership		a common home router or wireless Third Generation Partnership
	Project (3GPP) router is expected to perform gateway		Project (3GPP) router is expected to perform gateway
	functions such as DHCP server and DNS proxy for local		functions such as DHCP server and DNS proxy for local
	clients. The CLAT uses different IPv6 prefixes for CLAT-side		clients. The CLAT uses different IPv6 prefixes for CLAT-side
	and PLAT-side IPv4 addresses and therefore does not comply		and PLAT-side IPv4 addresses and therefore does not comply
	with the sentence "Both IPv4-translatable IPv6 addresses and		with the sentence "Both IPv4-translatable IPv6 addresses and
	IPv4-converted IPv6 addresses SHOULD use the same prefix." in		IPv4-converted IPv6 addresses should use the same prefix." in
	Section 3.3 of [RFC6052]. The CLAT does not facilitate		Section 3.3 of [RFC6052]. The CLAT does not facilitate
	communications between a local IPv4-only node and an IPv6-		communications between a local IPv4-only node and an IPv6-
	only node on the Internet.		only node on the Internet.
	5. Motivation and Uniqueness of 464XLAT		3. Motivation and Uniqueness of 464XLAT
	1. Minimal IPv4 resource requirements, maximum IPv4 efficiency		1. Minimal IPv4 resource requirements, maximum IPv4 efficiency
	through statistical multiplexing.		through statistical multiplexing.
	2. No new protocols required, quick deployment.		2. No new protocols required, quick deployment.
	3. IPv6-only networks are simpler and therefore less expensive to		3. IPv6-only networks are simpler and therefore less expensive to
	operate than dual-stack networks.		operate than dual-stack networks.
	4. Consistent native IP based monitoring, traffic engineering, and		4. Consistent native IP based monitoring, traffic engineering, and
	capacity planning techniques can be applied without the		capacity planning techniques can be applied without the
	indirection or obfuscation of a tunnel.		indirection or obfuscation of a tunnel.
	6. Network Architecture		4. Network Architecture
	Examples of 464XLAT architectures are shown in the figures in the		Examples of 464XLAT architectures are shown in the figures in the
	following sections.		following sections.
	Wireline Network Architecture can fit in the situations where there		Wireline Network Architecture can fit in the situations where there
	are clients behind the CLAT in the same way regardless of the type of		are clients behind the CLAT in the same way regardless of the type of
	access service, for example FTTH, DOCSIS, or WiFi.		access service, for example FTTH, DOCSIS, or WiFi.
	Wireless 3GPP Network Architecture fits in the situations where a		Wireless 3GPP Network Architecture fits in the situations where a
	client terminates the wireless access network and may act as a router		client terminates the wireless access network and may act as a router
	with tethered clients.		with tethered clients.
	6.1. Wireline Network Architecture		4.1. Wireline Network Architecture
	The private IPv4 host on this diagram can reach global IPv4 hosts via		The private IPv4 host on this diagram can reach global IPv4 hosts via
	translation on both CLAT and PLAT. On the other hand, the IPv6 host		translation on both CLAT and PLAT. On the other hand, the IPv6 host
	can reach other IPv6 hosts on the Internet directly without		can reach other IPv6 hosts on the Internet directly without
	translation. This means that the CPE/CLAT can not only have the		translation. This means that the CPE/CLAT can not only have the
	function of a CLAT but also the function of an IPv6 native router for		function of a CLAT but also the function of an IPv6 native router for
	native IPv6 traffic. The v4p host behind the CLAT on this diagram		native IPv6 traffic. The v4p host behind the CLAT on this diagram
	has [RFC1918] addresses.		has [RFC1918] addresses.
	+------+		+------+
	skipping to change at page 6, line 38		skipping to change at page 5, line 38
	+------+ |		+------+ |
	<- v4p -> XLAT <--------- v6 --------> XLAT <- v4g ->		<- v4p -> XLAT <--------- v6 --------> XLAT <- v4g ->
	v6 : Global IPv6		v6 : Global IPv6
	v4p : Private IPv4		v4p : Private IPv4
	v4g : Global IPv4		v4g : Global IPv4
	Figure 1: Wireline Network Topology		Figure 1: Wireline Network Topology
	6.2. Wireless 3GPP Network Architecture		4.2. Wireless 3GPP Network Architecture
	The CLAT function on the User Equipment (UE) provides an [RFC1918]		The CLAT function on the User Equipment (UE) provides an [RFC1918]
	address and IPv4 default route to the local node network stack. The		address and IPv4 default route to the local node network stack. The
	applications on the UE can use the private IPv4 address for reaching		applications on the UE can use the private IPv4 address for reaching
	global IPv4 hosts via translation on both the CLAT and the PLAT. On		global IPv4 hosts via translation on both the CLAT and the PLAT. On
	the other hand, reaching IPv6 hosts (including host presented via		the other hand, reaching IPv6 hosts (including host presented via
	DNS64 [RFC6147]) does not require the CLAT function on the UE.		DNS64 [RFC6147]) does not require the CLAT function on the UE.
	Presenting a private IPv4 network for tethering via NAT44 and		Presenting a private IPv4 network for tethering via NAT44 and
	stateless translation on the UE is also an application of the CLAT.		stateless translation on the UE is also an application of the CLAT.
	skipping to change at page 7, line 39		skipping to change at page 6, line 39
	<- v4p -> XLAT <--------- v6 --------> XLAT <- v4g ->		<- v4p -> XLAT <--------- v6 --------> XLAT <- v4g ->
	v6 : Global IPv6		v6 : Global IPv6
	v4p : Private IPv4		v4p : Private IPv4
	v4g : Global IPv4		v4g : Global IPv4
	PDP : Packet Data Protocol		PDP : Packet Data Protocol
	GGSN : Gateway GPRS Support Node		GGSN : Gateway GPRS Support Node
	Figure 2: Wireless 3GPP Network Topology		Figure 2: Wireless 3GPP Network Topology
	7. Applicability		5. Applicability
	7.1. Wireline Network Applicability		5.1. Wireline Network Applicability
	When an Internet Service Provider (ISP) has IPv6 access service and		When an Internet Service Provider (ISP) has IPv6 access service and
	provides 464XLAT, the ISP can provide outgoing IPv4 service to end		provides 464XLAT, the ISP can provide outgoing IPv4 service to end
	users across an IPv6 access network. The result is that edge network		users across an IPv6 access network. The result is that edge network
	growth is no longer tightly coupled to the availability of scarce		growth is no longer tightly coupled to the availability of scarce
	IPv4 addresses.		IPv4 addresses.
	If another ISP operates the PLAT, the edge ISP is only required to		If another ISP operates the PLAT, the edge ISP is only required to
	deploy an IPv6 access network. All ISPs do not need IPv4 access		deploy an IPv6 access network. All ISPs do not need IPv4 access
	networks. They can migrate their access network to a simple and		networks. They can migrate their access network to a simple and
	highly scalable IPv6-only environment.		highly scalable IPv6-only environment.
	7.2. Wireless 3GPP Network Applicability		5.2. Wireless 3GPP Network Applicability
	At the time of writing, in January 2013, the vast majority of mobile		At the time of writing, in February 2013, the vast majority of mobile
	networks are compliant to Pre-Release 9 3GPP standards. In Pre-		networks are compliant to Pre-Release 9 3GPP standards. In Pre-
	Release 9 3GPP networks, Global System for Mobile Communications		Release 9 3GPP networks, Global System for Mobile Communications
	(GSM) and Universal Mobile Telecommunications System (UMTS) networks		(GSM) and Universal Mobile Telecommunications System (UMTS) networks
	must signal and support both IPv4 and IPv6 Packet Data Protocol (PDP)		must signal and support both IPv4 and IPv6 Packet Data Protocol (PDP)
	attachments to access IPv4 and IPv6 network destinations [RFC6459].		attachments to access IPv4 and IPv6 network destinations [RFC6459].
	Since there are two PDPs required to support two address families,		Since there are two PDPs required to support two address families,
	this is double the number of PDPs required to support the status quo		this is double the number of PDPs required to support the status quo
	of one address family, which is IPv4.		of one address family, which is IPv4.
	For the cases of connecting to an IPv4 literal or IPv4 socket that		For the cases of connecting to an IPv4 literal or IPv4 socket that
	skipping to change at page 8, line 34		skipping to change at page 7, line 34
	the UE has the CLAT function that does a stateless translation		the UE has the CLAT function that does a stateless translation
	[RFC6145], but only when required by an IPv4-only scenario such as		[RFC6145], but only when required by an IPv4-only scenario such as
	IPv4 literals or IPv4-only sockets. The mobile network has a PLAT		IPv4 literals or IPv4-only sockets. The mobile network has a PLAT
	that does stateful translation [RFC6146].		that does stateful translation [RFC6146].
	464XLAT works with today's existing systems as much as possible.		464XLAT works with today's existing systems as much as possible.
	464XLAT is compatible with existing network based deep packet		464XLAT is compatible with existing network based deep packet
	inspection solutions like 3GPP standardized Policy and Charging		inspection solutions like 3GPP standardized Policy and Charging
	Control (PCC) [TS.23203].		Control (PCC) [TS.23203].
	8. Implementation Considerations		6. Implementation Considerations
	8.1. IPv6 Address Format		6.1. IPv6 Address Format
	The IPv6 address format in 464XLAT is defined in Section 2.2 of		The IPv6 address format in 464XLAT is defined in Section 2.2 of
	[RFC6052].		[RFC6052].
	8.2. IPv4/IPv6 Address Translation Chart		6.2. IPv4/IPv6 Address Translation Chart
	This chart offers an explanation about address translation		This chart offers an explanation about address translation
	architecture using a combination of stateful translation at the PLAT		architecture using a combination of stateful translation at the PLAT
	and stateless translation at the CLAT. The client on this chart is		and stateless translation at the CLAT. The client on this chart is
	delegated an IPv6 prefix from a prefix delegation mechanism such as		delegated an IPv6 prefix from a prefix delegation mechanism such as
	DHCPv6-PD [RFC3633], therefore it has a dedicated IPv6 prefix for		DHCPv6-PD [RFC3633], therefore it has a dedicated IPv6 prefix for
	translation.		translation.
	Destination IPv4 address		Destination IPv4 address
	+----------------------------+		+----------------------------+
	skipping to change at page 10, line 5		skipping to change at page 9, line 5
	| IPv4 | | assigned to IPv4 server |		| IPv4 | | assigned to IPv4 server |
	| client | +----------------------------+		| client | +----------------------------+
	+--------+ Source IPv4 address		+--------+ Source IPv4 address
	+----------------------------+		+----------------------------+
	| Private IPv4 address |		| Private IPv4 address |
	| assigned to IPv4 client |		| assigned to IPv4 client |
	+----------------------------+		+----------------------------+
	Case of enabling only stateless XLATE on CLAT		Case of enabling only stateless XLATE on CLAT
	8.3. IPv6 Prefix Handling		6.3. IPv6 Prefix Handling
	There are two relevant IPv6 prefixes that the CLAT must be aware of.		There are two relevant IPv6 prefixes that the CLAT must be aware of.
	First, CLAT must know its own IPv6 prefixes. The CLAT SHOULD acquire		First, CLAT must know its own IPv6 prefixes. The CLAT should acquire
	a /64 for the uplink interface, a /64 for all downlink interfaces,		a /64 for the uplink interface, a /64 for all downlink interfaces,
	and a dedicated /64 prefix for the purpose of sending and receiving		and a dedicated /64 prefix for the purpose of sending and receiving
	statelessly translated packets. When a dedicated /64 prefix is not		statelessly translated packets. When a dedicated /64 prefix is not
	available for translation from DHCPv6-PD [RFC3633], the CLAT MAY		available for translation from DHCPv6-PD [RFC3633], the CLAT may
	perform NAT44 for all IPv4 LAN packets so that all the LAN originated		perform NAT44 for all IPv4 LAN packets so that all the LAN originated
	IPv4 packets appear from a single IPv4 address and are then		IPv4 packets appear from a single IPv4 address and are then
	statelessly translated to one interface IPv6 address that is claimed		statelessly translated to one interface IPv6 address that is claimed
	by the CLAT via NDP and defended with DAD.		by the CLAT via NDP and defended with DAD.
	Second, the CLAT MUST discover the PLAT-side translation IPv6 prefix		Second, the CLAT must discover the PLAT-side translation IPv6 prefix
	used as a destination of the PLAT. The CLAT will use this prefix as		used as a destination of the PLAT. The CLAT will use this prefix as
	the destination of all translation packets that require stateful		the destination of all translation packets that require stateful
	translation to the IPv4 Internet. It MAY discover the PLAT-side		translation to the IPv4 Internet. It may discover the PLAT-side
	translation prefix using [I-D.ietf-behave-nat64-discovery-heuristic].		translation prefix using [I-D.ietf-behave-nat64-discovery-heuristic].
	In the future some other mechanisms, such as a new DHCPv6 option,		In the future some other mechanisms, such as a new DHCPv6 option,
	will possibly be defined to communicate the PLAT-side translation		will possibly be defined to communicate the PLAT-side translation
	prefix.		prefix.
	8.4. DNS Proxy Implementation		6.4. DNS Proxy Implementation
	The CLAT SHOULD implement a DNS proxy as defined in [RFC5625]. The		The CLAT should implement a DNS proxy as defined in [RFC5625]. The
	case of an IPv4-only node behind the CLAT querying an IPv4 DNS server		case of an IPv4-only node behind the CLAT querying an IPv4 DNS server
	is undesirable since it requires both stateful and stateless		is undesirable since it requires both stateful and stateless
	translation for each DNS lookup. The CLAT SHOULD set itself as the		translation for each DNS lookup. The CLAT should set itself as the
	DNS server via DHCP or other means and proxy DNS queries for IPv4 and		DNS server via DHCP or other means and proxy DNS queries for IPv4 and
	IPv6 LAN clients. Using the CLAT enabled home router or UE as a DNS		IPv6 LAN clients. Using the CLAT enabled home router or UE as a DNS
	proxy is a normal consumer gateway function and simplifies the		proxy is a normal consumer gateway function and simplifies the
	traffic flow so that only IPv6 native queries are made across the		traffic flow so that only IPv6 native queries are made across the
	access network. DNS queries from the client that are not sent to the		access network. DNS queries from the client that are not sent to the
	DNS proxy on the CLAT MUST be allowed and are translated and		DNS proxy on the CLAT must be allowed and are translated and
	forwarded just like any other IP traffic.		forwarded just like any other IP traffic.
	8.5. CLAT in a Gateway		6.5. CLAT in a Gateway
	The CLAT feature can be implemented in a common home router or mobile		The CLAT feature can be implemented in a common home router or mobile
	phone that has a tethering feature. Routers with a CLAT feature		phone that has a tethering feature. Routers with a CLAT feature
	SHOULD also provide common router services such as DHCP of [RFC1918]		should also provide common router services such as DHCP of [RFC1918]
	addresses, DHCPv6, NDP with RA, and DNS service.		addresses, DHCPv6, NDP with RA, and DNS service.
	8.6. CLAT to CLAT communications		6.6. CLAT to CLAT communications
	464XLAT is a hub and spoke architecture focused on enabling IPv4-only		464XLAT is a hub and spoke architecture focused on enabling IPv4-only
	services over IPv6-only networks. ICE [RFC5245] MAY be used to		services over IPv6-only networks. ICE [RFC5245] may be used to
	support peer-to-peer communication within a 464XLAT network.		support peer-to-peer communication within a 464XLAT network.
	9. Deployment Considerations		7. Deployment Considerations
	9.1. Traffic Engineering		7.1. Traffic Engineering
	Even if the ISP for end users is different from the PLAT provider		Even if the ISP for end users is different from the PLAT provider
	(e.g. another ISP), it can implement traffic engineering		(e.g. another ISP), it can implement traffic engineering
	independently from the PLAT provider. Detailed reasons are below:		independently from the PLAT provider. Detailed reasons are below:
	1. The ISP for end users can figure out IPv4 destination address		1. The ISP for end users can figure out IPv4 destination address
	from translated IPv6 packet header, so it can implement traffic		from translated IPv6 packet header, so it can implement traffic
	engineering based on IPv4 destination address (e.g. traffic		engineering based on IPv4 destination address (e.g. traffic
	monitoring for each IPv4 destination address, packet filtering		monitoring for each IPv4 destination address, packet filtering
	for each IPv4 destination address, etc.). The tunneling methods		for each IPv4 destination address, etc.). The tunneling methods
	skipping to change at page 11, line 30		skipping to change at page 10, line 30
	for processing the inner IPv4 packet of the tunnel packet.		for processing the inner IPv4 packet of the tunnel packet.
	2. If the ISP for end users can assign an IPv6 prefix greater than		2. If the ISP for end users can assign an IPv6 prefix greater than
	/64 to each subscriber, this 464XLAT architecture can separate		/64 to each subscriber, this 464XLAT architecture can separate
	IPv6 prefix for native IPv6 packets and the XLAT prefixes for		IPv6 prefix for native IPv6 packets and the XLAT prefixes for
	IPv4/IPv6 translation packets. Accordingly, it can identify the		IPv4/IPv6 translation packets. Accordingly, it can identify the
	type of packets ("native IPv6 packets" and "IPv4/IPv6 translation		type of packets ("native IPv6 packets" and "IPv4/IPv6 translation
	packets"), and implement traffic engineering based on the IPv6		packets"), and implement traffic engineering based on the IPv6
	prefix.		prefix.
	9.2. Traffic Treatment Scenarios		7.2. Traffic Treatment Scenarios
	The below table outlines how different permutations of connectivity		The below table outlines how different permutations of connectivity
	are treated in the 464XLAT architecture.		are treated in the 464XLAT architecture.
	NOTE: 464XLAT double translation treatment will be stateless when a		NOTE: 464XLAT double translation treatment will be stateless when a
	dedicated /64 is available for translation on the CLAT. Otherwise,		dedicated /64 is available for translation on the CLAT. Otherwise,
	the CLAT will have both stateful and stateless since it requires		the CLAT will have both stateful and stateless since it requires
	NAT44 from the LAN to a single IPv4 address and then stateless		NAT44 from the LAN to a single IPv4 address and then stateless
	translation to a single IPv6 address.		translation to a single IPv6 address.
	skipping to change at page 12, line 18		skipping to change at page 11, line 18
	+--------+-------------+-----------------------+-------------+		+--------+-------------+-----------------------+-------------+
	| IPv6 | IPv6 | End-to-end IPv6 | None |		| IPv6 | IPv6 | End-to-end IPv6 | None |
	+--------+-------------+-----------------------+-------------+		+--------+-------------+-----------------------+-------------+
	| IPv4 | IPv6 | Stateful Translation | PLAT |		| IPv4 | IPv6 | Stateful Translation | PLAT |
	+--------+-------------+-----------------------+-------------+		+--------+-------------+-----------------------+-------------+
	| IPv4 | IPv4 | 464XLAT | PLAT/CLAT |		| IPv4 | IPv4 | 464XLAT | PLAT/CLAT |
	+--------+-------------+-----------------------+-------------+		+--------+-------------+-----------------------+-------------+
	Traffic Treatment Scenarios		Traffic Treatment Scenarios
	10. Security Considerations		8. Security Considerations
	To implement a PLAT, see security considerations presented in Section		To implement a PLAT, see security considerations presented in Section
	5 of [RFC6146].		5 of [RFC6146].
	To implement a CLAT, see security considerations presented in Section		To implement a CLAT, see security considerations presented in Section
	7 of [RFC6145]. The CLAT MAY comply with [RFC6092].		7 of [RFC6145]. The CLAT may comply with [RFC6092].
	11. IANA Considerations		9. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	12. Acknowledgements		10. Acknowledgements
	The authors would like to thank JPIX NOC members, JPIX 464XLAT trial		The authors would like to thank JPIX NOC members, JPIX 464XLAT trial
	service members, Seiichi Kawamura, Dan Drown, Brian Carpenter, Rajiv		service members, Seiichi Kawamura, Dan Drown, Brian Carpenter, Rajiv
	Asati, Washam Fan, Behcet Sarikaya, Jan Zorz, Tatsuya Oishi, Lorenzo		Asati, Washam Fan, Behcet Sarikaya, Jan Zorz, Tatsuya Oishi, Lorenzo
	Colitti, Erik Kline, Ole Troan, Maoke Chen, Gang Chen, Tom Petch,		Colitti, Erik Kline, Ole Troan, Maoke Chen, Gang Chen, Tom Petch,
	Jouni Korhonen, Bjoern A. Zeeb, Hemant Singh, Vizdal Ales, Mark ZZZ		Jouni Korhonen, Bjoern A. Zeeb, Hemant Singh, Vizdal Ales, Mark ZZZ
	Smith, Mikael Abrahamsson, Tore Anderson, Teemu Savolainen, Alexandru		Smith, Mikael Abrahamsson, Tore Anderson, Teemu Savolainen, Alexandru
	Petrescu, Gert Doering, Victor Kuarsingh, Ray Hunter, James Woodyatt,		Petrescu, Gert Doering, Victor Kuarsingh, Ray Hunter, James Woodyatt,
	and Tom Taylor for their helpful comments. Special acknowledgments		Tom Taylor, and Remi Despres for their helpful comments. We also
	go to Remi Despres for his plentiful supports and suggestions,		would like to thank Fred Baker and Joel Jaeggli for their support.
	especially about using NAT44 with IANA's EUI-64 ID. We also would
	like to thank Fred Baker and Joel Jaeggli for their support.
	13. References		11. References
	13.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		11.1. Normative References
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[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.
			[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
			IPv4/IPv6 Translation", RFC 6144, April 2011.
	[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.
	[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful		[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
	NAT64: Network Address and Protocol Translation from IPv6		NAT64: Network Address and Protocol Translation from IPv6
	Clients to IPv4 Servers", RFC 6146, April 2011.		Clients to IPv4 Servers", RFC 6146, April 2011.
	13.2. Informative References		11.2. Informative References
	[I-D.ietf-behave-nat64-discovery-heuristic]		[I-D.ietf-behave-nat64-discovery-heuristic]
	Savolainen, T., Korhonen, J., and D. Wing, "Discovery of		Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
	the IPv6 Prefix Used for IPv6 Address Synthesis",		the IPv6 Prefix Used for IPv6 Address Synthesis",
	draft-ietf-behave-nat64-discovery-heuristic-13 (work in		draft-ietf-behave-nat64-discovery-heuristic-13 (work in
	progress), November 2012.		progress), November 2012.
	[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",		E. Lear, "Address Allocation for Private Internets",
	BCP 5, RFC 1918, February 1996.		BCP 5, RFC 1918, February 1996.
	skipping to change at page 16, line 22		skipping to change at page 15, line 22
	Phone: +81 3 3243 9579		Phone: +81 3 3243 9579
	Email: mawatari@jpix.ad.jp		Email: mawatari@jpix.ad.jp
	Masanobu Kawashima		Masanobu Kawashima
	NEC AccessTechnica, Ltd.		NEC AccessTechnica, Ltd.
	800, Shimomata		800, Shimomata
	Kakegawa-shi, Shizuoka 436-8501		Kakegawa-shi, Shizuoka 436-8501
	JAPAN		JAPAN
	Phone: +81 537 23 9655		Phone: +81 537 22 8274
	Email: kawashimam@vx.jp.nec.com		Email: kawashimam@vx.jp.nec.com
	Cameron Byrne		Cameron Byrne
	T-Mobile USA		T-Mobile USA
	Bellevue, Washington 98006		Bellevue, Washington 98006
	USA		USA
	Email: cameron.byrne@t-mobile.com		Email: cameron.byrne@t-mobile.com
End of changes. 45 change blocks.
	106 lines changed or deleted		74 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/