draft-ietf-opsawg-lsn-deployment-01.txt		draft-ietf-opsawg-lsn-deployment-02.txt
	OPSAWG V. Kuarsingh, Ed.		OPSAWG V. Kuarsingh, Ed.
	Internet-Draft J. Cianfarani		Internet-Draft J. Cianfarani
	Intended status: Informational Rogers Communications		Intended status: Informational Rogers Communications
	Expires: April 18, 2013 October 15, 2012		Expires: August 22, 2013 February 18, 2013
	CGN Deployment with BGP/MPLS IP VPNs		CGN Deployment with BGP/MPLS IP VPNs
	draft-ietf-opsawg-lsn-deployment-01		draft-ietf-opsawg-lsn-deployment-02
	Abstract		Abstract
	This document specifies a framework to integrate a Network Address		This document specifies a framework to integrate a Network Address
	Translation layer into an operator's network to function as a Carrier		Translation layer into an operator's network to function as a Carrier
	Grade NAT (also known as CGN or Large Scale NAT). The CGN		Grade NAT (also known as CGN or Large Scale NAT). The CGN
	infrastructure will often form a NAT444 environment as the subscriber		infrastructure will often form a NAT444 environment as the subscriber
	home network will likely also contain a NAT function. Exhaustion of		home network will likely also maintain a subscriber side NAT
	the IPv4 address pool is a major driver compelling some operators to		function. Exhaustion of the IPv4 address pool is a major driver
	implement CGN. Although operators may wish to deploy IPv6 to		compelling some operators to implement CGN. Although operators may
	strategically overcome IPv4 exhaustion, near term needs may not be		wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near
	satisfied with an IPv6 deployment alone. This document provides a		term needs may not be satisfied with an IPv6 deployment alone. This
	practical integration model which allows the CGN platform to be		document provides a practical integration model which allows the CGN
	integrated into the network meeting the connectivity needs of the		platform to be integrated into the network meeting the connectivity
	subscriber while being mindful of not disrupting existing services		needs of the subscriber while being mindful of not disrupting
	and meeting the technical challenges that CGN brings. The model		existing services and meeting the technical challenges that CGN
	included in this document utilizes BGP/MPLS IP VPNs which allow for		brings. The model included in this document utilizes BGP/MPLS IP
	virtual routing separation helping ease the CGNs impact on the		VPNs which allow for virtual routing separation helping ease the CGNs
	network. This document does not intend to defend the merits of CGN.		impact on the network. This document does not intend to defend the
			merits of CGN.
	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 April 18, 2013.		This Internet-Draft will expire on August 22, 2013.
	Copyright Notice		Copyright Notice
			Copyright (c) 2013 IETF Trust and the persons identified as the
	Copyright (c) 2012 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
	skipping to change at page 2, line 30		skipping to change at page 2, line 31
	3. CGN Network Deployment Requirements . . . . . . . . . . . . . 4		3. CGN Network Deployment Requirements . . . . . . . . . . . . . 4
	3.1. Centralized versus Distributed Deployment . . . . . . . . 5		3.1. Centralized versus Distributed Deployment . . . . . . . . 5
	3.2. CGN and Traditional IPv4 Service Co-existence . . . . . . 6		3.2. CGN and Traditional IPv4 Service Co-existence . . . . . . 6
	3.3. CGN By-Pass . . . . . . . . . . . . . . . . . . . . . . . 6		3.3. CGN By-Pass . . . . . . . . . . . . . . . . . . . . . . . 6
	3.4. Routing Plane Separation . . . . . . . . . . . . . . . . . 6		3.4. Routing Plane Separation . . . . . . . . . . . . . . . . . 6
	3.5. Flexible Deployment Options . . . . . . . . . . . . . . . 7		3.5. Flexible Deployment Options . . . . . . . . . . . . . . . 7
	3.6. IPv4 Overlap Space . . . . . . . . . . . . . . . . . . . . 7		3.6. IPv4 Overlap Space . . . . . . . . . . . . . . . . . . . . 7
	3.7. Transactional Logging for LSN Systems . . . . . . . . . . 7		3.7. Transactional Logging for LSN Systems . . . . . . . . . . 7
	3.8. Additional CGN Requirements . . . . . . . . . . . . . . . 8		3.8. Additional CGN Requirements . . . . . . . . . . . . . . . 8
	4. BGP/MPLS IP VPN based CGN Framework . . . . . . . . . . . . . 8		4. BGP/MPLS IP VPN based CGN Framework . . . . . . . . . . . . . 8
	4.1. Service Separation . . . . . . . . . . . . . . . . . . . . 9		4.1. Service Separation . . . . . . . . . . . . . . . . . . . . 10
	4.2. Internal Service Delivery . . . . . . . . . . . . . . . . 10		4.2. Internal Service Delivery . . . . . . . . . . . . . . . . 10
	4.2.1. Dual Stack Operation . . . . . . . . . . . . . . . . . 11		4.2.1. Dual Stack Operation . . . . . . . . . . . . . . . . . 12
	4.3. Deployment Flexibility . . . . . . . . . . . . . . . . . . 13		4.3. Deployment Flexibility . . . . . . . . . . . . . . . . . . 14
	4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN		4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN
	Attachment Options . . . . . . . . . . . . . . . . . . . . 13		Attachment Options . . . . . . . . . . . . . . . . . . . . 14
	4.4.1. Policy Based Routing . . . . . . . . . . . . . . . . . 13		4.4.1. Policy Based Routing . . . . . . . . . . . . . . . . . 14
	4.4.2. Traffic Engineering . . . . . . . . . . . . . . . . . 14		4.4.2. Traffic Engineering . . . . . . . . . . . . . . . . . 15
	4.4.3. Multiple Routing Topologies . . . . . . . . . . . . . 14		4.4.3. Multiple Routing Topologies . . . . . . . . . . . . . 15
	5. Experiences . . . . . . . . . . . . . . . . . . . . . . . . . 14		5. Experiences . . . . . . . . . . . . . . . . . . . . . . . . . 15
	5.1. Basic Integration and Requirements Support . . . . . . . . 14		5.1. Basic Integration and Requirements Support . . . . . . . . 15
	5.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 15		5.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 16
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 15		7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15		8. BGP/MPLS IP VPN CGN Framework Discussion . . . . . . . . . . . 16
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 16		10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	10.2. Informative References . . . . . . . . . . . . . . . . . . 16		10.2. Informative References . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	Operators are faced with near term IPv4 address exhaustion		Operators are faced with near term IPv4 address exhaustion
	challenges. Many operators may not have a sufficient amount of IPv4		challenges. Many operators may not have a sufficient amount of IPv4
	addresses in the future to satisfy the needs of their growing		addresses in the future to satisfy the needs of their growing
	subscriber base. This challenge may also be present before or during		subscriber base. This challenge may also be present before or during
	an active transition to IPv6 somewhat complicating the overall		an active transition to IPv6 somewhat complicating the overall
	problem space.		problem space.
	To face this challenge, operators may need to deploy CGN (Carrier		To face this challenge, operators may need to deploy CGN (Carrier
	Grade NAT) as described in [I-D.ietf-behave-lsn-requirements] to help		Grade NAT) as described in [I-D.ietf-behave-lsn-requirements] to help
	extend the connectivity matrix once IPv4 addresses run out in the		extend the connectivity matrix once IPv4 addresses caches run out on
	network. CGN deployments will most often be added into operator		the local local operator. CGN deployments will most often be added
	networks which already have active IPv4 and/or IPv6 services.		into operator networks which already have active IPv4 and/or IPv6
			services.
	The addition of the CGN introduces an operator controlled and		The addition of the CGN introduces an operator controlled and
	administered translation layer which should be added in a manner		administered translation layer which should be added in a manner
	which minimizes disruption to existing services. This addition may		which minimizes disruption to existing services. The CGN system
	also include interworking in a dual stack environment where the IPv4		addition may also include interworking in a dual stack environment
	path requires translation.		where the IPv4 path requires translation.
	This document shows how BGP/MPLS IP VPNs as described in [RFC4364]		This document shows how BGP/MPLS IP VPNs as described in [RFC4364]
	can be used to integrate the CGN infrastructure solving key		can be used to integrate the CGN infrastructure solving key
	integration challenges faced by the operator. This model has also		integration challenges faced by the operator. This model has also
	been tested and validated in real production network models and		been tested and validated in real production network models and
	allows fluid operation with existing IPv4 and IPv6 services.		allows fluid operation with existing IPv4 and IPv6 services.
	2. Motivation		2. Motivation
	The selection of CGN may be made by an operator based on a number of		The selection of CGN may be made by an operator based on a number of
	factors. The overall driver may be the depletion of IPv4 address		factors. The overall driver may be the depletion of IPv4 address
	pools which leaves little to no addresses for IPv4 service growth.		pools which leaves little to no addresses for IPv4 service or
	IPv6 is considered the strategic answer, but it's applicability and		connection demand growth. IPv6 is considered the strategic answer,
	usefulness in many networks is limited by the current access network		but it's applicability and usefulness in many networks is limited by
	and consumer home network. These environments often are filled with		the current access network and consumer home network. Customer
	IPv4-Only equipment which may not be upgradable to IPv6.		environments often are filled with IPv4-Only equipment which may not
			be upgradable to IPv6.
	The ability to replace IPv4-Only equipment may be out of the control		The ability to replace IPv4-Only equipment may be out of the control
	of the operator, and even when it's in the administrative control; it		of the operator, and even when it's in the administrative control; it
	poses both cost and technical challenges as operators build out		poses both cost and technical challenges as operators build out
	massive programs for equipment retirement or upgrade. Theses issues		massive programs for equipment retirement or upgrade. These issues
	leave an operator in a precarious position which may lead to the		leave an operator in a precarious position which may lead to the
	decision to deploy CGN. Other address IPv4 sharing options do exist		decision to deploy CGN. Other address IPv4 sharing options do exist
	which are more architecturally desirable, but the practical and		which are more architecturally desirable, but the practical and
	workable approach in many cases is a CGN deployment using NAT444.		workable approach in many cases is a CGN deployment using the NAT444
			framework.
	If the operator as has chosen to deploy CGN, they should this in a		If the operator has chosen to deploy CGN, they should do this in a
	manner as not to negatively impact the existing IPv4 or IPv6		manner as not to negatively impact the existing IPv4 or IPv6
	subscriber base. This will include solving a number of challenges		subscriber base. This will include solving a number of challenges
	since subscribers who's connections require translation will have		since subscribers who's connections require translation will have
	network routing and flow needs which are different from legacy IPv4		network routing and flow needs which are different from legacy IPv4
	connections.		connections.
	The solution will also need to work in a dual stack environment where		The solution will also need to work in a dual stack environment where
	other options such as DS-Lite [RFC6333] are not yet viable. Even		other options such as DS-Lite [RFC6333] are not yet viable. Even
	technologies like 6RD [RFC5969] still require an IPv4 connectivity		technologies like 6RD [RFC5969] still require an IPv4 connectivity
	path to service the subscriber endpoint. The solution will need to		path to service the subscriber endpoint. The solution will need to
	address basic Internet connectivity, on-net service offerings, back		address basic Internet connectivity, on-net service offerings, back
	office management, billing, policy and security models already in		office management, billing, policy and security models already in
	place within the operator's network. CGN will often integrate quite		place within the operator's network. CGN will often integrate quite
	readily with the aforementioned requirements where as other		readily with the aforementioned requirements where as other
	transition mechanism may not due to the requirements to support IPv6		transition mechanism may not due to the requirements to support IPv6
	as the base protocol for IPv4 connectivity.		as the base protocol for IPv4 connectivity.
	3. CGN Network Deployment Requirements		3. CGN Network Deployment Requirements
	If a service provider is considering a CGN deployment with a provider		If a service provider is considering a CGN deployment with a provider
	NAT44 function, there are a number of basic requirements which are of		NAT44 function, there are a number of basic architectural
	importance. Preliminary requirements may require the following from		requirements which are of importance. Preliminary architectural
	the incoming CGN system architecture:		requirements may require all or some of the following from the
			incoming CGN system:
	- Support distributed (sparse) and centralized (dense) deployment		- Support distributed (sparse) and centralized (dense) deployment
	models;		models;
	- Allow co-existence with traditional IPv4 based deployments,		- Allow co-existence with traditional IPv4 based deployments,
	which provide global scoped IPs to CPEs;		which provide global scoped IPv4 addresses to CPEs;
	- Provide a framework for CGN by-pass supporting non-translated		- Provide a framework for CGN by-pass supporting non-translated
	flows between endpoints within a provider's network;		flows between endpoints within a provider's network;
	- Provide routing framework which allows the segmentation of		- Provide a routing framework which allows the segmentation of
	routing control and forwarding paths between CGN and non-CGN		routing control and forwarding paths between CGN and non-CGN
	mediated flows;		mediated flows;
	- Provide flexibility for operators to modify their deployments		- Provide flexibility for operators to modify their deployments
	over time as translation demands change (connections, bandwidth,		over time as translation demands change (connections, bandwidth,
	translation realms/zones and other vectors);		translation realms/zones and other vectors);
	- Flexibility should include integration options for common access		- Flexibility should include integration options for common access
	technologies such as DSL (BRAS), DOCSIS (CMTS), Mobile (GGSN/PGW/		technologies such as DSL (BRAS), DOCSIS (CMTS), Mobile (GGSN/PGW/
	ASN-GW), and Ethernet access;		ASN-GW), and direct Ethernet;
	- Support deployment modes that allow for IPv4 address overlap		- Support deployment modes that allow for IPv4 address overlap
	within the operator's network (between various translation realms		within the operator's network (between various translation realms
	or zones);		or zones);
	- Allow for evolution to future dual-stack and IPv4/IPv6		- Allow for evolution to future dual-stack and IPv4/IPv6
	transition deployment modes;		transition deployment modes;
	- Transactional logging and export capabilities to support		- Transactional logging and export capabilities to support
	auxiliary functions including abuse mitigation;		auxiliary functions including abuse mitigation;
	skipping to change at page 5, line 23		skipping to change at page 5, line 27
	translation instances/elements (redundancy);		translation instances/elements (redundancy);
	- Support for CGN Shared Space [RFC6598] deployment modes if		- Support for CGN Shared Space [RFC6598] deployment modes if
	applicable;		applicable;
	- Allows for the enablement of CGN functionality (if required)		- Allows for the enablement of CGN functionality (if required)
	while still minimizing costs and subscriber impact to the best		while still minimizing costs and subscriber impact to the best
	extend possible;		extend possible;
	Other requirements may be assessed on a operator-by-operator basis,		Other requirements may be assessed on a operator-by-operator basis,
	but those listed above should be considered for any given deployment		but those listed above may be considered for any given deployment
	architecture.		architecture.
	3.1. Centralized versus Distributed Deployment		3.1. Centralized versus Distributed Deployment
	Centralized deployments of CGN (longer proximity to end user and/or		Centralized deployments of CGN (longer proximity to end user and/or
	higher densities of subscribers/connections to CGN instances) differ		higher densities of subscribers/connections to CGN instances) differ
	from distributed deployments of CGN (closer proximity to end user		from distributed deployments of CGN (closer proximity to end user
	and/or lower densities of subscribers/connections to CGN instances).		and/or lower densities of subscribers/connections to CGN instances).
	Service providers will likely deploy CGN translation points more		Service providers may likely deploy CGN translation points more
	centrally during initial phases. Early deployments will likely see		centrally during initial phases if the early system demand is low.
	light loading on these new systems since legacy IPv4 services will		Early deployments may see light loading on these new systems since
	continue to operate with most endpoints using globally unique IPv4		legacy IPv4 services will continue to operate with most endpoints
	addresses. Exceptional cases which may drive heavy usage in initial		using globally unique IPv4 addresses. Exceptional cases which may
	stages may include operators who already translate most IPv4 traffic		drive heavy usage in initial stages may include operators who already
	and will migrate to a CGN implementation from legacy firewalls; or a		translate a significant portion of their IPv4 traffic; may transition
	green field deployment which may see quick growth in the number of		to a CGN implementation from legacy translation mechanisms (i.e.
	new IPv4 endpoints which require Internet connectivity.		traditional firewalls); or build a green field deployment which may
			see quick growth in the number of new IPv4 endpoints which require
			Internet connectivity.
	Over time, most providers will likely need to expand and possibly		Over time, some providers may need to expand and possibly distribute
	distribute the translation points as demand for the CGN system		the translation points if demand for the CGN system increases. The
	increases. The extent of the expansion of the CGN infrastructure		extent of the expansion of the CGN infrastructure will depend on
	will depend on factors such as growth in the number of IPv4		factors such as growth in the number of IPv4 endpoints, status of
	endpoints, status of IPv6 content on the Internet and the overall		IPv6 content on the Internet and the overall progress globally to an
	progress globally to an IPv6-dominate Internet (reducing the demand		IPv6-dominate Internet (reducing the demand for IPv4 connectivity).
	for IPv4 connectivity).		The overall demand for CGN resources will probably follow a bell-like
			curve with a growth, peak and decline period.
	3.2. CGN and Traditional IPv4 Service Co-existence		3.2. CGN and Traditional IPv4 Service Co-existence
	Newer CGN serviced endpoints will exist alongside endpoints served by		Newer CGN serviced endpoints will exist alongside endpoints served by
	traditional IPv4 global IPs. Providers will need to rationalize		traditional IPv4 globally routed IPv4 addresses. Operators will need
	these environments since both have distinct forwarding needs.		to rationalize these environments since both have distinct forwarding
	Traditional IPv4 services will likely require (or be best served)		needs. Traditional IPv4 services will likely require (or be best
	direct forwarding towards Internet peering points while CGN mediated		served) direct forwarding towards Internet peering points while CGN
	flows require access to a translator. CGN and non-CGN mediated flows		mediated flows require access to a translator. CGN and non-CGN
	post two fundamentally different forwarding needs.		mediated flows pose two fundamentally different forwarding needs.
	The new CGN environments should not negatively impact the existing		The new CGN environments should not negatively impact the existing
	IPv4 service base by forcing all traffic to translation enabled		IPv4 service base by forcing all traffic to translation enabled
	network points since many flows do not require translation and this		network points since many flows do not require translation and this
	would reduce performance of the existing flows. This would also		would reduce performance of the existing flows. This would also
	require massive scaling of the CGN which is a cost and efficiency		require massive scaling of the CGN which is a cost and efficiency
	concern as well.		concern as well.
	Traffic flow and forwarding efficiency is considered important since		Traffic flow and forwarding efficiency is considered important since
	networks are under considerable demand to deliver more and more		networks are under considerable demand to deliver more and more
	bandwidth without the luxury of needless inefficiencies which can be		bandwidth without the luxury of needless inefficiencies which can be
	introduced with CGN.		introduced with CGN.
	3.3. CGN By-Pass		3.3. CGN By-Pass
	The CGN environment is only needed for flows with translation		The CGN environment is only needed for flows with translation
	requirements. Many flows which remain in a service provider		requirements. Many flows which remain within the operator's network,
	environment, do not require translation. Such services include		do not require translation. Such services include operator offered
	operator offered DNS Services, DHCP Services, NTP Services, Web		DNS Services, DHCP Services, NTP Services, Web Caching, E-Mail, News
	Caching, Mail, News and other services which are local to the		and other services which are local to the operator's network.
	operator's network.
	The operator may want to leverage opportunities to offer third		The operator may want to leverage opportunities to offer third
	parties a platform to also provide services without translation. CGN		parties a platform to also provide services without translation. CGN
	By-pass can be accomplished in many ways, but a simplistic,		By-pass can be accomplished in many ways, but a simplistic,
	deterministic and scalable model is preferred.		deterministic and scalable model is preferred.
	3.4. Routing Plane Separation		3.4. Routing Plane Separation
	Many operators will want to engineer traffic separately for CGN flows		Many operators will want to engineer traffic separately for CGN flows
	versus flows which are part of the more traditional IPv4 environment.		versus flows which are part of the more traditional IPv4 environment.
	Many times the routing of these two major flow types differ,		Many times the routing of these two major flow types differ,
	therefore route separation may be required.		therefore route separation may be required.
	Routing plane separation also allows the operator to utilize other		Routing plane separation also allows the operator to utilize other
	addressing techniques, which may not be feasible on a single routing		addressing techniques, which may not be feasible on a single routing
	plane. Such examples include the use of overlapping private address		plane. Such examples include the use of overlapping private address
	space [RFC1918] or use of other IPv4 space which may overlap globally		space [RFC1918], Shared Address Space [RFC6598] or use of other IPv4
	within the operator's network.		space which may overlap globally within the operator's network.
	3.5. Flexible Deployment Options		3.5. Flexible Deployment Options
	Service providers operate complex routing environments and offer a		Service providers operate complex routing environments and offer a
	variety of IPv4 based services. Many operator environments utilize		variety of IPv4 based services. Many operator environments utilize
	distributed peering infrastructures for transit and peering and these		distributed peering infrastructures for transit and peering and these
	may span large geographical areas and regions. A CGN solution should		may span large geographical areas and regions. A CGN solution should
	offer the operator an ability to place CGN translation points at		offer the operator an ability to place CGN translation points at
	various points within their network.		various points within their network.
	The CGN deployment should also be flexible enough to change over time		The CGN deployment should also be flexible enough to change over time
	as demand for translation services increase. In turn, the deployment		as demand for translation services increase or change as noted in
	will need to then adapt as translation demand decreases caused by the		[RFC6264]. In turn, the deployment will need to then adapt as
	transition of flows to IPv6. Translation points should be able to be		translation demand decreases caused by the transition of flows to
	placed and moved with as little re-engineering effort as possible		IPv6. Translation points should be able to be placed and moved with
	minimizing the risks to the subscriber base.		as little re-engineering effort as possible minimizing the risks to
			the subscriber base.
	Depending on hardware capabilities, security practices and IPv4		Depending on hardware capabilities, security practices and IPv4
	address availability, the translation environments my need to be		address availability, the translation environments my need to be
	segmented and/or scaled over time to meet organic IPv4 demand growth.		segmented and/or scaled over time to meet organic IPv4 demand growth.
	Operators will want to seek deployment models which are conducive to		Operators may also want to choose models that support transition to
	meeting these goals as well.		other translation environments such as DS-Lite [RFC6333] and/or NAT64
			[RFC6146]. Operators will want to seek deployment models which are
			conducive to meeting these goals as well.
	3.6. IPv4 Overlap Space		3.6. IPv4 Overlap Space
	IP address overlap for CGN translation realms may be required if		IPv4 address overlap for CGN translation realms may be required if
	insufficient IPv4 addresses are available within the service provider		insufficient IPv4 addresses are available within the operator
	environment to assign internally unique IPs to the CGN subscriber		environment to assign internally unique IPv4 addresses to the CGN
	base . The CGN deployment should provide mechanisms to manage IPv4		subscriber base . The CGN deployment should provide mechanisms to
	overlap if required.		manage IPv4 overlap if required.
	3.7. Transactional Logging for LSN Systems		3.7. Transactional Logging for LSN Systems
	CGNs may require transactional logging since the source IP and		CGNs may require transactional logging since the source IP and
	related transport protocol information is not easily visible to		related transport protocol information is not easily visible to
	external hosts and system.		external hosts and system.
	If needed, the CGN systems should be able to generate logs which		If needed, the CGN systems should be able to generate logs which
	identify 'internal' host parameters (i.e. IP/Port) and associated		identify 'internal' host parameters (i.e. IP/Port) and associated
	them to external translated parameters imposed by the translator.		them to external translated parameters imposed by the translator.
	The logged information should be stored on the CGN hardware and/or		The logged information should be stored on the CGN hardware and/or
	exported to an external system for processing. Operators may need to		exported to an external system for processing. The operator may
	keep track of this information (securely) to meet regulatory and/or		choose to also enable mechanisms to help reduce logging such as block
	legal obligations. Further information can be found in [I-D.ietf-		allocation of UDP and TCP ports or deterministic translation options
	behave-lsn-requirements] with respect to CGN logging requirements		such as [I-D.donley-behave-deterministic-cgn].
	(Logging Section).
			Operators may need to keep track of this information (securely) to
			meet regulatory and/or legal obligations. Further information can be
			found in [I-D.ietf-behave-lsn-requirements] with respect to CGN
			logging requirements (Logging Section).
	3.8. Additional CGN Requirements		3.8. Additional CGN Requirements
	The CGN platform will also need to meet the needs of additional		The CGN platform will also need to meet the needs of additional
	requirements such as Bulk Port Allocation and other CGN device		requirements such as Bulk Port Allocation and other CGN device
	specific functions. These additional requirements are captured		specific functions. These additional requirements are captured
	within [I-D.ietf-behave-lsn-requirements].		within [I-D.ietf-behave-lsn-requirements].
	4. BGP/MPLS IP VPN based CGN Framework		4. BGP/MPLS IP VPN based CGN Framework
	The BGP/MPLS IP VPN [RFC4364] framework for CGN segregates the 'pre-		The BGP/MPLS IP VPN [RFC4364] framework for CGN segregates the 'pre-
	translated' realms within the service provider space into Layer-3		translated' realms within the service provider space into Layer-3
	MPLS based VPNs. The operator can deploy a single realm for all CGN		MPLS based VPNs. The operator can deploy a single realm for all CGN
	based flows, or can deploy multiple realms based on translation		based flows, or can deploy multiple realms based on translation
	demand and other factors such as geographical proximity. A realm in		demand and other factors such as geographical proximity. A realm in
	this model refers to a 'VPN' which shares a unique RD/RT combination,		this model refers to a 'VPN' which shares a unique Route
	routing plane and forwarding behaviours.		Distinguisher/Route Target (RD/RT) combination, routing plane and
			forwarding behaviours.
	The BGP/MPLS IP VPN infrastructure provides control plane and		The BGP/MPLS IP VPN infrastructure provides control plane and
	forwarding separation for the traditional IPv4 service environment		forwarding separation for the traditional IPv4 service environment
	and CGN environment(s). The separation allows for routing		and CGN environment(s). The separation allows for routing
	information (such as default routes) to be propagated separately for		information (such as default routes) to be propagated separately for
	CGN and non-CGN based subscriber flows. Traffic can be efficiently		CGN and non-CGN based subscriber flows. Traffic can be efficiently
	routed to the Internet for normal flows, and routed directly to		routed to the Internet for normal flows, and routed directly to
	translators for CGN mediated flows. Although many operators may run		translators for CGN mediated flows. Although many operators may run
	a "default-route-free" core, IPv4 flows which require translation		a "default-route-free" core, IPv4 flows which require translation
	must obviously be routed first to a translator, so a default route is		must obviously be routed first to a translator, so a default route is
	acceptable for the pre-translated realms.		acceptable for the pre-translated realms.
	The physical location of the VRF Termination point for a BGP/MPLS IP		The physical location of the Virtual Routing and Forwarding (VRF)
	VPN enabled CGN can vary and be located anywhere within the		Termination point for a BGP/MPLS IP VPN enabled CGN can vary and be
	operator's network. This model fully virtualizes the translation		located anywhere within the operator's network. This model fully
	service from the base IPv4 forwarding environment which will likely		virtualizes the translation service from the base IPv4 forwarding
	carrying Internet bound traffic. The base IPv4 environment can		environment which will likely be carrying Internet bound traffic.
	continue to service traditional IPv4 subscriber flows plus post		The base IPv4 environment can continue to service traditional IPv4
	translated CGN flows.		subscriber flows plus post translated CGN flows.
	Figure 1 provides a view of the basic model. The Access node		Figure 1 provides a view of the basic model. The Access node
	provides CPE access to either the CGN VRF or the Global Routing		provides CPE access to either the CGN VRF or the Global Routing
	Table, depending on whether the subscriber receives a private or		Table, depending on whether the subscriber receives a private or
	public IP. Translator mediated traffic follows an MPLS LSP which can		public IP. Translator mediated traffic follows an MPLS Label-
	be setup dynamically and can span one hop, or many hops (with no need		switched Path (LSP) which can be setup dynamically and can span one
	for complex routing policies). Traffic is then forwarded to the		hop, or many hops (with no need for complex routing policies).
	translator (shown below) which can be an external appliance or		Traffic is then forwarded to the translator (shown below) which can
	integrated into the VRF Termination (Provider Edge) router. Once		be an external appliance or integrated into the VRF Termination
	traffic is translated, it is forwarded to the global routing table		(Provider Edge) router. Once traffic is translated, it is forwarded
	for general Internet forwarding. The Global Routing table can also		to the global routing table for general Internet forwarding. The
	be a separate VRF (Internet Access VPN/VRF) should the provider		Global Routing table can also be a separate VRF (Internet Access VPN/
	choose to implement their Internet based services in that fashion.		VRF) should the provider choose to implement their Internet based
	The translation services are effectively overlaid onto the network,		services in that fashion. The translation services are effectively
	but are maintained within a separate forwarding and control plane.		overlaid onto the network, but are maintained within a separate
			forwarding and control plane.
	Access Node VRF Termination LSN		Access Node VRF Termination CGN
	+-----------+ +-----------+ +-----------+		+-----------+ +-----------+ +-----------+
	| | | | | |		| | | | | |
	CPE | +-------+ | | +-------+ | | +-------+ |		CPE | +-------+ | | +-------+ | | +-------+ |
	+----+ | | | | LSP | | | | IP | | | |		+----+ | | | | LSP | | | | IP | | | |
	| --+---+-+->VRF--+-+-----+-+->VRF--+-+----+-+-> | |		| --+---+-+->VRF--+-+-----+-+->VRF--+-+----+-+-> | |
	+----+ | | | | | | | | | | | |		+----+ | | | | | | | | | | | |
	| +-------+ | | +-------+ | | | | |		| +-------+ | | +-------+ | | | | |
	| | | | | | XLATE | |		| | | | | | XLATE | |
	| | | | | | | |		| | | | | | | |
	CPE | +-------+ | | +-------+ | | | | |		CPE | +-------+ | | +-------+ | | | | |
	skipping to change at page 10, line 11		skipping to change at page 10, line 23
	type of service separation is possible on common technologies used		type of service separation is possible on common technologies used
	for Internet access within many operator networks. Service		for Internet access within many operator networks. Service
	separation can be accomplished on common access technology including		separation can be accomplished on common access technology including
	those used for DOCSIS (CMTS), Ethernet Access, DSL (BRAS), and Mobile		those used for DOCSIS (CMTS), Ethernet Access, DSL (BRAS), and Mobile
	Access (GGSN/ASN-GW) architectures.		Access (GGSN/ASN-GW) architectures.
	4.2. Internal Service Delivery		4.2. Internal Service Delivery
	Internal services can be delivered directly to the privately		Internal services can be delivered directly to the privately
	addressed endpoint within the CGN domain without translation. This		addressed endpoint within the CGN domain without translation. This
	can be accomplished using direct route exchange (import/export)		can be accomplished in one of two methods. The first method may
	between the CGN VRFs and the Services VRFs. The previous statement		include reducing the overall number of VRFs in the system and
	assumes the provider puts key services into a VRF for simple route		exposing services in the GRT along with a method of exchanging routes
	exchange. This model allows the provider to maintain separate		between the CGN VRF and GRT called route leaking. The second method,
	forwarding rules for translated flows, which require a pass through		which is described in detail within this section is the use of a
	the translator to reach external network entities, versus those flows		Services VRF. The second model is a more traditional extranet
	which need to access internal services. This operational detail can		services model, but requires more system resources to implement.
	be advantageous for a number of reasons.
			Using direct route exchange (import/export) between the CGN VRFs and
			the Services VRFs creates reachablity using the aforementioned
			extranet model available in the BGP/MPLS IP VPN structure. This
			model allows the provider to maintain separate forwarding rules for
			translated flows, which require a pass through the translator to
			reach external network entities, versus those flows which need to
			access internal services. This operational detail can be
			advantageous for a number of reasons such as service access policies
			and endpoint identification.
	First, the provider can reduce the load on the translator since		First, the provider can reduce the load on the translator since
	internal services do not need to be factored into the scaling of the		internal services do not need to be factored into the scaling of the
	CGN hardware. Secondly, more direct forwarding paths can be		CGN hardware (which may be quite large). Secondly, more direct
	maintained providing better network efficiency. Thirdly, geographic		forwarding paths can be maintained providing better network
	locations of the translators and the services infrastructure can be		efficiency. Thirdly, geographic locations of the translators and the
	deployed in a location in an independent manner. Additionally, the		services infrastructure can be deployed in locations in an
	operator can allow CGN subject endpoints to be accessible via an		independent manner. Additionally, the operator can allow CGN subject
	untranslated path reducing the complexities of provider initiated		endpoints to be accessible via an untranslated path reducing the
	management flows. This last point is of key interest since NAT		complexities of provider initiated management flows. This last point
	removes transparency to the end device in normal cases.		is of key interest since NAT removes transparency to the end device
			in normal cases.
	Figure 2 below shows how internal services are provided untranslated		Figure 2 below shows how internal services are provided untranslated
	since flows are sent directly from the access node to the services		since flows are sent directly from the access node to the services
	node/VRF via an MPLS LSP. This traffic is not forwarded to the CGN		node/VRF via an MPLS LSP. This traffic is not forwarded to the CGN
	translator and therefore is not subject to problematic behaviours		translator and therefore is not subject to problematic behaviours
	related to NAT. The services VRF contains routing information which		related to NAT. The services VRF contains routing information which
	can be "imported" into the access node VRF and the CGN VRF routing		can be "imported" into the access node VRF and the CGN VRF routing
	information can be "imported" into the Services VRF.		information can be "imported" into the Services VRF.
	Access Node VRF Termination LSN		Access Node VRF Termination CGN
	+-------------+ +-----------+ +----------+		+-------------+ +-----------+ +----------+
	| | | | | |		| | | | | |
	CPE | +---------+ | | +-------+ | | +------+ |		CPE | +---------+ | | +-------+ | | +------+ |
	+-----+ | | | | | | | | | | | |		+-----+ | | | | | | | | | | | |
	| --+--+-+-> VRF --+-+--+ | | VRF | | | | | |		| --+--+-+-> VRF --+-+--+ | | VRF | | | | | |
	+-----+ | | | | | | | | | | | | |		+-----+ | | | | | | | | | | | | |
	| +---------+ | | | +-------+ | | | | |		| +---------+ | | | +-------+ | | | | |
	| | | | | | |XLATE | |		| | | | | | |XLATE | |
	| | | | | | | | |		| | | | | | | | |
	CPE | +---------+ | | | +-------+ | | | | |		CPE | +---------+ | | | +-------+ | | | | |
	skipping to change at page 11, line 37		skipping to change at page 11, line 45
	+-----+-----+		+-----+-----+
	|		|
	+-----V-----+		+-----V-----+
	| |		| |
	| Local |		| Local |
	| Content |		| Content |
	+-----------+		+-----------+
	Figure 2: Internal Services and CGN By-Pass		Figure 2: Internal Services and CGN By-Pass
	This demonstrates the ability to offer CGN By-Pass in a simple and		An extension to the services delivery LSP is the ability to also
	deterministic manner without the need of policy based routing or		provide direct subscriber to subscriber traffic flows between CGN
	traffic engineering.		zones. Each zone or realm may be fitted with separate CGN resources,
			but the subtending subscribers don't necessarily need to be mediated
			(translated) by the CGN translators. This option, as shown in Figure
			3 below, is easy to implement and can only be enabled if no IPv4
			address overlap is used between communicating CGN zones.
			Access Node-1 VRF Termination CGN-1
			+-------------+ +-----------+ +----------+
			| | | | | |
			CPE-1 | +---------+ | | +-------+ | | +------+ |
			+-----+ | | | | | | | | | | | |
			| --+--+-+- VRF --+-+-+ | | VRF | | | | | |
			+-----+ | | | | | | | | | | | | |
			| +---------+ | | | +-------+ | | | | |
			| | | | | | |XLATE | |
			| | | | | | | | |
			CPE-2 | +---------+ | | | +-------+ | | | | |
			+-----+ | | | | | | | | | | | | |
			| --+--+-+- GRT | | | | | GRT | | | | | |
			+-----+ | | | | | | | | | | | | |
			| +---------+ | | | +-------+ | | +------+ |
			+-------------+ | +-----------+ +----------+
			|
			LSP |
			|
			Access Node-2 | VRF Termination CGN-2
			+-------------+ | +-----------+ +----------+
			| | | | | | |
			CPE-3 | +---------+ | | | +-------+ | | +------+ |
			+-----+ | | | | | | | | | | | | |
			| --+--+-+-- VRF --+-+-+ | | VRF | | | | | |
			+-----+ | | | | | | | | | | | |
			| +---------+ | | +-------+ | | | | |
			| | | | | |XLATE | |
			| | | | | | | |
			CPE-4 | +---------+ | | +-------+ | | | | |
			+-----+ | | | | | | | | | | | |
			| --+--+-+- GRT | | | | GRT | | | | | |
			+-----+ | | | | | | | | | | | |
			| +---------+ | | +-------+ | | +------+ |
			+-------------+ +-----------+ +----------+
			The inherent capabilities of the BGP/MPLS IP VPN model demonstrates
			the ability to offer CGN By-Pass in a standard and deterministic
			manner without the need of policy based routing or traffic
			engineering.
	4.2.1. Dual Stack Operation		4.2.1. Dual Stack Operation
	The BGP/MPLS IP VPN CGN model can also be used in conjunction with		The BGP/MPLS IP VPN CGN model can also be used in conjunction with
	IPv4/IPv6 dual stack service modes. Since many providers will use		IPv4/IPv6 dual stack service modes. Since many providers will use
	CGNs on an interim basis while IPv6 matures within the global		CGNs on an interim basis while IPv6 matures within the global
	Internet or due to technical constraints, a dual stack option is of		Internet or due to technical constraints, a dual stack option is of
	strategic importance. Operators can offer this dual stack service		strategic importance. Operators can offer this dual stack service
	for both traditional IPv4 (global IP) endpoints and CGN mediated		for both traditional IPv4 (global IP) endpoints and CGN mediated
	endpoints.		endpoints.
	Operators can separate the IP flows for IPv4 and IPv6 traffic, or use		Operators can separate the IP flows for IPv4 and IPv6 traffic, or use
	other routing techniques to move IPv6 based flows towards the GRT		other routing techniques to move IPv6 based flows towards the GRT
	(Global Routing Table or Instance) while allowing IPv4 flows to		(Global Routing Table or Instance) while allowing IPv4 flows to
	remain within the IPv4 CGN VRF for translator services.		remain within the IPv4 CGN VRF for translator services.
	The Figure 3 below shows how IPv4 translation services can be		The Figure 4 below shows how IPv4 translation services can be
	provided alongside IPv6 based services. The model shown allows the		provided alongside IPv6 based services. The model shown allows the
	provider to enable CGN to manage IPv4 flows (translated) and IPv6		provider to enable CGN to manage IPv4 flows (translated) and IPv6
	flows are routed without translation efficiently towards the		flows are routed without translation efficiently towards the
	Internet. Once again, forwarding of flows to the translator does not		Internet. Once again, forwarding of flows to the translator does not
	impact IPv6 flows which do not require this service.		impact IPv6 flows which do not require this service.
	Access Node VRF Termination LSN		Access Node VRF Termination CGN
	+-----------+ +-----------+ +-----------+		+-----------+ +-----------+ +-----------+
	| | | | | |		| | | | | |
	CPE | +-------+ | | +-------+ | | +-------+ |		CPE | +-------+ | | +-------+ | | +-------+ |
	+-----+ | | | |LSP| | | | IP | | | |		+-----+ | | | |LSP| | | | IP | | | |
	| --+--+-+->VRF--+-+---+-+->VRF--+-+----+-+> | |		| --+--+-+->VRF--+-+---+-+->VRF--+-+----+-+> | |
	|IPv4 | | | | | | | | | | | | |		|IPv4 | | | | | | | | | | | | |
	| | | +-------+ | | +-------+ | | | | |		| | | +-------+ | | +-------+ | | | | |
	+-----| | | | | | | XLATE | |		+-----| | | | | | | XLATE | |
	|IPv6 | | | | | | | | |		|IPv6 | | | | | | | | |
	| | | +-------+ | | +-------+ | | | | |		| | | +-------+ | | +-------+ | | | | |
	skipping to change at page 12, line 44		skipping to change at page 13, line 49
	| +----------+-> GRT |		| +----------+-> GRT |
	| +-----------+		| +-----------+
	|		|
	|		|
	|		|
	| IP +-----------+		| IP +-----------+
	+--------------------------+-> IPv6 |		+--------------------------+-> IPv6 |
	| GRT |		| GRT |
	+-----------+		+-----------+
	Figure 3: CGN with IPv6 Dual Stack Operation		Figure 4: CGN with IPv6 Dual Stack Operation
	4.3. Deployment Flexibility		4.3. Deployment Flexibility
	The CGN translator services can be moved, separated or segmented (new		The CGN translator services can be moved, separated or segmented (new
	translation realms) without the need to change the overall		translation realms) without the need to change the overall
	translation design. Since dynamic LSPs are used to forward traffic		translation design. Since dynamic LSPs are used to forward traffic
	from the access nodes to the translation points, the physical		from the access nodes to the translation points, the physical
	location of the VRF termination points can vary and be changed		location of the VRF termination points can vary and be changed
	easily.		easily.
	skipping to change at page 15, line 41		skipping to change at page 16, line 41
	the MPLS/VPN model, the operator would want to consider security		the MPLS/VPN model, the operator would want to consider security
	issues related to offering IP services over MPLS.		issues related to offering IP services over MPLS.
	If a provider plans to operate the pre-translation realm (CPE towards		If a provider plans to operate the pre-translation realm (CPE towards
	translator IPv4 zone) as a non-public like network, then additional		translator IPv4 zone) as a non-public like network, then additional
	security measures may be needed to secure this environment. It is		security measures may be needed to secure this environment. It is
	however the position in this document that CGN realms are public		however the position in this document that CGN realms are public
	domains which utilize non-Internet routable IP addresses for endpoint		domains which utilize non-Internet routable IP addresses for endpoint
	addressing.		addressing.
	8. Conclusions		8. BGP/MPLS IP VPN CGN Framework Discussion
	The MPLS/VPN delivery method for a CGN deployment is an effective and		The MPLS/VPN delivery method for a CGN deployment is an effective and
	scalable way to deliver mass translation services. The architecture		scalable way to deliver mass translation services. The architecture
	avoids the complex requirements of traffic engineering and policy		avoids the complex requirements of traffic engineering and policy
	based routing when combining these new service flows to existing IPv4		based routing when combining these new service flows to existing IPv4
	operation. This is advantageous since the NAT44/CGN environments		operation. This is advantageous since the NAT44/CGN environments
	should be introduced with as little impact as possible and these		should be introduced with as little impact as possible and these
	environments are expected to change over time.		environments are expected to change over time.
	The MPLS/VPN based CGN architecture solves many of this issues		The MPLS/VPN based CGN architecture solves many of this issues
	related to deploying this technology in existing operator networks.		related to deploying this technology in existing operator networks.
	9. Acknowledgements		9. Acknowledgements
	Thanks to the following people for their participating in integrating		Thanks to the following people for their comments and feedback: Dan
	and testing the CGN environment: Chris Metz, Syd Alam, Richard		Wing, Chris Metz, Chris Donley, Tina TSOU, Christophoer Liljenstolpe
	Lawson, John E Spence.		and Tom Taylor.
	Additional thanks for the following people for the guidance on IPv6		Thanks to the following people for their participating in integrating
	transition considerations: John Jason Brzozowski, Chris Donley, Jason		and testing the CGN environment and for their IPv6 transition
	Weil, Lee Howard, Jean-Francois Tremblay		guidance: Syd Alam, Richard Lawson, John E Spence, John Jason
			Brzozowski, Chris Donley, Jason Weil, Lee Howard, Jean-Francois
			Tremblay
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	Networks (VPNs)", RFC 4364, February 2006.		Networks (VPNs)", RFC 4364, February 2006.
	10.2. Informative References		10.2. Informative References
			[I-D.donley-behave-deterministic-cgn]
			Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K.,
			and O. Vautrin, "Deterministic Address Mapping to Reduce
			Logging in Carrier Grade NAT Deployments",
			draft-donley-behave-deterministic-cgn-05 (work in
			progress), January 2013.
	[I-D.donley-nat444-impacts]		[I-D.donley-nat444-impacts]
	Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U.		Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U.
	Colorado, "Assessing the Impact of Carrier-Grade NAT on		Colorado, "Assessing the Impact of Carrier-Grade NAT on
	Network Applications", draft-donley-nat444-impacts-05		Network Applications", draft-donley-nat444-impacts-05
	(work in progress), October 2012.		(work in progress), October 2012.
	[I-D.ietf-behave-lsn-requirements]		[I-D.ietf-behave-lsn-requirements]
	Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,		Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
	and H. Ashida, "Common requirements for Carrier Grade NATs		and H. Ashida, "Common requirements for Carrier Grade NATs
	(CGNs)", draft-ietf-behave-lsn-requirements-09 (work in		(CGNs)", draft-ietf-behave-lsn-requirements-10 (work in
	progress), August 2012.		progress), December 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.
	[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol		[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
	Label Switching Architecture", RFC 3031, January 2001.		Label Switching Architecture", RFC 3031, January 2001.
	[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4		[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
	Infrastructures (6rd) -- Protocol Specification",		Infrastructures (6rd) -- Protocol Specification",
	RFC 5969, August 2010.		RFC 5969, August 2010.
			[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
			NAT64: Network Address and Protocol Translation from IPv6
			Clients to IPv4 Servers", RFC 6146, April 2011.
			[RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental
			Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264,
			June 2011.
	[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-		[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
	Stack Lite Broadband Deployments Following IPv4		Stack Lite Broadband Deployments Following IPv4
	Exhaustion", RFC 6333, August 2011.		Exhaustion", RFC 6333, August 2011.
	[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and		[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
	M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address		M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
	Space", BCP 153, RFC 6598, April 2012.		Space", BCP 153, RFC 6598, April 2012.
	Authors' Addresses		Authors' Addresses
End of changes. 45 change blocks.
	155 lines changed or deleted		241 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/