draft-ietf-opsawg-lsn-deployment-00.txt		draft-ietf-opsawg-lsn-deployment-01.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: November 16, 2012 May 15, 2012		Expires: April 18, 2013 October 15, 2012
	CGN Deployment with BGP/MPLS IP VPNs		CGN Deployment with BGP/MPLS IP VPNs
	draft-ietf-opsawg-lsn-deployment-00		draft-ietf-opsawg-lsn-deployment-01
	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). CGN is a concept		Grade NAT (also known as CGN or Large Scale NAT). The CGN
	also described in [I-D.ietf-behave-lsn-requirements] and describes		infrastructure will often form a NAT444 environment as the subscriber
	the model as a dual layer translation model. Although operators may		home network will likely also contain a NAT function. Exhaustion of
	wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near		the IPv4 address pool is a major driver compelling some operators to
	term needs may not be satisfied with an IPv6 deployment alone. This		implement CGN. Although operators may wish to deploy IPv6 to
	document provides a practical integration model which allows CGN to		strategically overcome IPv4 exhaustion, near term needs may not be
	be integrated into the network meeting the connectivity needs of the		satisfied with an IPv6 deployment alone. This document provides a
	customer while being mindful of not disrupting existing services and		practical integration model which allows the CGN platform to be
	meeting the technical challenges that CGN brings. The model includes		integrated into the network meeting the connectivity needs of the
	the use of BGP/MPLS IP VPNs defined in [RFC4364] as a tool to achieve		subscriber while being mindful of not disrupting existing services
	this goal. This document does not intend to defend the merits of		and meeting the technical challenges that CGN brings. The model
	CGN.		included in this document utilizes BGP/MPLS IP VPNs which allow for
			virtual routing separation helping ease the CGNs 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 November 16, 2012.		This Internet-Draft will expire on April 18, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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
	skipping to change at page 2, line 35		skipping to change at page 2, line 36
	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 . . . . . . . . . . . . . . . . . . . . 9
	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 . . . . . . . . . . . . . . . . . 11
	4.3. Deployment Flexibility . . . . . . . . . . . . . . . . . . 13		4.3. Deployment Flexibility . . . . . . . . . . . . . . . . . . 13
	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 . . . . . . . . . . . . . . . . . . . . 13
	4.4.1. IEEE 802.1Q . . . . . . . . . . . . . . . . . . . . . 13		4.4.1. Policy Based Routing . . . . . . . . . . . . . . . . . 13
	4.4.2. Policy Based Routing . . . . . . . . . . . . . . . . . 14		4.4.2. Traffic Engineering . . . . . . . . . . . . . . . . . 14
	4.4.3. Traffic Engineering . . . . . . . . . . . . . . . . . 14		4.4.3. Multiple Routing Topologies . . . . . . . . . . . . . 14
	4.4.4. Multiple Routing Topologies . . . . . . . . . . . . . 14
	5. Experiences . . . . . . . . . . . . . . . . . . . . . . . . . 14		5. Experiences . . . . . . . . . . . . . . . . . . . . . . . . . 14
	6. Basic Integration and Requirements Support . . . . . . . . . . 14		5.1. Basic Integration and Requirements Support . . . . . . . . 14
	7. Performance . . . . . . . . . . . . . . . . . . . . . . . . . 15		5.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 15
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 16		7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17		8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 17		10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
	12.2. Informative References . . . . . . . . . . . . . . . . . . 17		10.2. Informative References . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	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
	customer 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 run out in the
	network. CGN's addition to the network requires integration in an		network. CGN deployments will most often be added into operator
	often running state environment with working IPv4 and/or IPv6		networks which already have active IPv4 and/or IPv6 services.
	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 needs to be added in a manner		administered translation layer which should be added in a manner
	which does not overly disrupt existing services. This addition may		which minimizes disruption to existing services. This addition may
	also include interworking in a dual stack environment where the IPv4		also include interworking in a dual stack environment where the IPv4
	path requires translation.		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 problems		can be used to integrate the CGN infrastructure solving key
	faced by the operator. This model has also been tested and validated		integration challenges faced by the operator. This model has also
	in real production network models and allows fluid operation with		been tested and validated in real production network models and
	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 growth.
	IPv6 is considered the strategic answer, but it's applicability and		IPv6 is considered the strategic answer, but it's applicability and
	usefulness in many networks is limited by the current access network		usefulness in many networks is limited by the current access network
	and consumer home network. These environments often are filled with		and consumer home network. These environments often are filled with
	IPv4-Only equipment which may not be upgradable to IPv6.		IPv4-Only equipment which may not be upgradable to IPv6.
	skipping to change at page 4, line 6		skipping to change at page 4, line 4
	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. Theses 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 NAT444.
	If the operator as has chosen to deploy CGN, they should this in a		If the operator as has chosen to deploy CGN, they should this in a
	manner as not to negatively impact the existing IPv4 or IPv6 customer		manner as not to negatively impact the existing IPv4 or IPv6
	base. This will include solving a number of challenges since		subscriber base. This will include solving a number of challenges
	customers who's connections require translation will have network		since subscribers who's connections require translation will have
	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 customer 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
	skipping to change at page 5, line 21		skipping to change at page 5, line 19
	- Transactional logging and export capabilities to support		- Transactional logging and export capabilities to support
	auxiliary functions including abuse mitigation;		auxiliary functions including abuse mitigation;
	- Support for stateful connection synchronization between		- Support for stateful connection synchronization between
	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 customer 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 should 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
	skipping to change at page 7, line 19		skipping to change at page 7, line 19
	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. In turn, the deployment
	will need to then adapt as translation demand decreases caused by the		will need to then adapt as translation demand decreases caused by the
	transition of flows to IPv6. Translation points should be able to be		transition of flows to IPv6. Translation points should be able to be
	placed and moved with as little re-engineering effort as possible		placed and moved with as little re-engineering effort as possible
	minimizing the risks to the customer base.		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 will want to seek deployment models which are conducive to
	meeting these goals as well.		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		IP 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 service provider
	environment to assign internally unique IPs to the CGN customer base		environment to assign internally unique IPs to the CGN subscriber
	. The CGN deployment should provide mechanisms to manage IPv4		base . The CGN deployment should provide mechanisms to manage IPv4
	overlap if required.		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
	skipping to change at page 8, line 26		skipping to change at page 8, line 26
	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 RD/RT combination,
	routing plane and forwarding behaviours.		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 customer 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 VRF Termination point for a BGP/MPLS IP
	VPN enabled CGN can vary and be located anywhere within the		VPN enabled CGN can vary and be located anywhere within the
	operator's network. This model fully virtualizes the translation		operator's network. This model fully virtualizes the translation
	service from the base IPv4 forwarding environment which will likely		service from the base IPv4 forwarding environment which will likely
	carrying Internet bound traffic. The base IPv4 environment can		carrying Internet bound traffic. The base IPv4 environment can
	continue to service traditional IPv4 customer flows plus post		continue to service traditional IPv4 subscriber flows plus post
	translated CGN flows.		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 customer receives a private or public		Table, depending on whether the subscriber receives a private or
	IP. Translator mediated traffic follows an MPLS LSP which can be		public IP. Translator mediated traffic follows an MPLS LSP which can
	setup dynamically and can span one hop, or many hops (with no need		be setup dynamically and can span one hop, or many hops (with no need
	for complex routing policies). Traffic is then forwarded to the		for complex routing policies). Traffic is then forwarded to the
	translator (shown below) which can be an external appliance or		translator (shown below) which can be an external appliance or
	integrated into the VRF Termination (Provider Edge) router. Once		integrated into the VRF Termination (Provider Edge) router. Once
	traffic is translated, it is forwarded to the global routing table		traffic is translated, it is forwarded to the global routing table
	for general Internet forwarding. The Global Routing table can also		for general Internet forwarding. The Global Routing table can also
	be a separate VRF (Internet Access VPN/VRF) should the provider		be a separate VRF (Internet Access VPN/VRF) should the provider
	choose to implement their Internet based services in that fashion.		choose to implement their Internet based services in that fashion.
	The translation services are effectively overlaid onto the network,		The translation services are effectively overlaid onto the network,
	but are maintained within a separate forwarding and control plane.		but are maintained within a separate forwarding and control plane.
	skipping to change at page 13, line 34		skipping to change at page 13, line 34
	and can be seen as independent. There is no specific need to		and can be seen as independent. There is no specific need to
	diversify the existing infrastructure in most cases.		diversify the existing infrastructure in most cases.
	4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN Attachment		4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN Attachment
	Options		Options
	Other integration architecture options exist which can attach CGN		Other integration architecture options exist which can attach CGN
	based service flows to a translator instance. Alternate options		based service flows to a translator instance. Alternate options
	which can be used to attach such services include:		which can be used to attach such services include:
	- IEEE 802.1Q for direct attachment to a next hop translator;
	- Policy Based Routing (Static) to direct translation bound		- Policy Based Routing (Static) to direct translation bound
	traffic to a network based translator;		traffic to a network based translator;
	- Traffic Engineering or;		- Traffic Engineering or;
	- Multiple Routing Topologies		- Multiple Routing Topologies
	4.4.1. IEEE 802.1Q		4.4.1. Policy Based Routing
	IEEE 802.1Q can be used to associate separated traffic from the
	access node to the next hop router's CGN instance. This technology
	option may limit the CGN placement to the next hop router unless a
	second technology option is paired with it to extend connectivity
	deeper in the network.
	This option is most effective if CGN instances are placed directly
	upstream of the access node. Distributed CGN instance placement is
	not likely an initial stage of the CGN deployment due to cost and
	demand factors.
	4.4.2. Policy Based Routing
	Policy Based Routing (PBR) provides another option to direct CGN		Policy Based Routing (PBR) provides another option to direct CGN
	mediated flows to a translator. PBR options, although possible, are		mediated flows to a translator. PBR options, although possible, are
	difficult to maintain (static policy) and must be configured		difficult to maintain (static policy) and must be configured
	throughout the network with considerable maintenance overhead.		throughout the network with considerable maintenance overhead.
	More centralized deployments may be difficult or too onerous to		More centralized deployments may be difficult or too onerous to
	deploy using Policy Based Routing methods. Policy Based Routing		deploy using Policy Based Routing methods. Policy Based Routing
	would not achieve route separation (unless used with others options),		would not achieve route separation (unless used with others options),
	and may add complexities to the providers' routing environment.		and may add complexities to the providers' routing environment.
	4.4.3. Traffic Engineering		4.4.2. Traffic Engineering
	Traffic Engineering can also be used to direct traffic from an access		Traffic Engineering can also be used to direct traffic from an access
	node towards a translator. Traffic Engineering, like MPLS-TE, may be		node towards a translator. Traffic Engineering, like MPLS-TE, may be
	difficult to setup and maintain. Traffic Engineering provides		difficult to setup and maintain. Traffic Engineering provides
	additional benefits if used with MPLS by adding potentials for faster		additional benefits if used with MPLS by adding potentials for faster
	path re-convergence. Traffic Engineering paths would need to be		path re-convergence. Traffic Engineering paths would need to be
	updated and redefined overtime as CGN translation points are		updated and redefined overtime as CGN translation points are
	augmented or moved.		augmented or moved.
	4.4.4. Multiple Routing Topologies		4.4.3. Multiple Routing Topologies
	Multiple routing topologies can be used to direct CGN based flows to		Multiple routing topologies can be used to direct CGN based flows to
	translators. This option would achieve the same basic goal as the		translators. This option would achieve the same basic goal as the
	MPLS/VPN option but with additional implementation overhead and		MPLS/VPN option but with additional implementation overhead and
	platform configuration complexity. Since operator based translation		platform configuration complexity. Since operator based translation
	is expected to have an unknown lifecycle, and may see various degrees		is expected to have an unknown lifecycle, and may see various degrees
	of demand (dependant on operator IPv4 Global space availability and		of demand (dependant on operator IPv4 Global space availability and
	shift of traffic to IPv6), it may be too large of an undertaking for		shift of traffic to IPv6), it may be too large of an undertaking for
	the provider to enabled this as their primary option for CGN.		the provider to enabled this as their primary option for CGN.
	5. Experiences		5. Experiences
	6. Basic Integration and Requirements Support		5.1. Basic Integration and Requirements Support
	The MPLS/VPN CGN environment has been successfully integrated into		The MPLS/VPN CGN environment has been successfully integrated into
	real network environments utilizing existing network service delivery		real network environments utilizing existing network service delivery
	mechanisms. It solves many issues related to provider based		mechanisms. It solves many issues related to provider based
	translation environments, while still subject to problematic		translation environments, while still subject to problematic
	behaviours inherent within NAT.		behaviours inherent within NAT.
	Key issues which are solved or managed with the MPLS/VPN option		Key issues which are solved or managed with the MPLS/VPN option
	include:		include:
	skipping to change at page 15, line 19		skipping to change at page 15, line 4
	- Routing Plane Separation for CGN flows versus traditional IPv4		- Routing Plane Separation for CGN flows versus traditional IPv4
	flows		flows
	- Flexible Translation Point Design (can relocate translators and		- Flexible Translation Point Design (can relocate translators and
	split translation zones easily)		split translation zones easily)
	- Low maintenance overhead (dynamic routing environment with		- Low maintenance overhead (dynamic routing environment with
	little maintenance of separate routing infrastructure other then		little maintenance of separate routing infrastructure other then
	management of MPLS/VPNs)		management of MPLS/VPNs)
	- CGN By-pass options (for internal and third party services which		- CGN By-pass options (for internal and third party services which
	exist within the provider domain)		exist within the provider domain)
	- IPv4 Translation Realm overlap support (can reuse IP addresses		- IPv4 Translation Realm overlap support (can reuse IP addresses
	between zones with some impact to extranet service model)		between zones with some impact to extranet service model)
	- Simple failover techniques can be implemented with redundant		- Simple failover techniques can be implemented with redundant
	translators, such as using a second default route		translators, such as using a second default route
	7. Performance		5.2. Performance
	The MPLS/VPN CGN model was observed to support basic functions which		The MPLS/VPN CGN model was observed to support basic functions which
	are typically used by customers within an operator environment.		are typically used by subscribes within an operator environment. A
	Examples of successful operation include:		full review of the observed impacts related to CGN (NAT444) are
			covered in [I-D.donley-nat444-impacts].
	- Traditional Web (HTTP) Surfing (client initiated)
	- Internet Video Streaming
	- HTTP Based Client Connections
	- High Connection Count sites (i.e. Google Maps)
	- Email Transaction Support (POP, IMAP, SMTP)
	- Instant Messaging Support (Online Status, File transfers, text
	chat)
	- ICMP Operation (client initiated Echo, Traceroute)
	- Peer to Peer application support (download)
	- DNS (based on services extranet option, but was problematic when
	passed through a translator)
	CGNs are still subject to problematic connectivity even within the
	MPLS/VPN technology approach. Problems which arise, or are not
	inherently addressed in this model include:
	- Inward services from the Internet to the CPE
	- Web session tracking
	- Restricting usage and/or access based on source IP
	- Abuse mitigation (masquerade of potential offenders)
	- Increased network or server IDS false positives
	- Increased customer risk for session hijacking
	- Exceeding firewall TCP/UDP limits
	- Customer identification (external site)
	- Poor source based load balancing
	- Customer usage tracking / Ad insertion
	- Other applications or operations may be negatively impacted
	8. IANA Considerations		6. IANA Considerations
	There are not specific IANA considerations known at this time with		There are not specific IANA considerations known at this time with
	the architecture described herein. Should a provide choose to use		the architecture described herein. Should a provide choose to use
	non-assigned IP address space within their translation realms, then		non-assigned IP address space within their translation realms, then
	considerations may apply.		considerations may apply.
	9. Security Considerations		7. Security Considerations
	The same security considerations would typically exist for CGN		The same security considerations would typically exist for CGN
	deployments when compared with traditional IPv4 based services. With		deployments when compared with traditional IPv4 based services. With
	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.
	10. Conclusions		8. Conclusions
	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.
	11. Acknowledgements		9. Acknowledgements
	Thanks to the following people for their participating in integrating		Thanks to the following people for their participating in integrating
	and testing the CGN environment: Chris Metz, Syd Alam, Richard		and testing the CGN environment: Chris Metz, Syd Alam, Richard
	Lawson, John E Spence.		Lawson, John E Spence.
	Additional thanks for the following people for the guidance on IPv6		Additional thanks for the following people for the guidance on IPv6
	transition considerations: John Jason Brzozowski, Chris Donley, Jason		transition considerations: John Jason Brzozowski, Chris Donley, Jason
	Weil, Lee Howard, Jean-Francois Tremblay		Weil, Lee Howard, Jean-Francois Tremblay
	12. References		10. References
	12.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.
	12.2. Informative References		10.2. Informative References
			[I-D.donley-nat444-impacts]
			Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U.
			Colorado, "Assessing the Impact of Carrier-Grade NAT on
			Network Applications", draft-donley-nat444-impacts-05
			(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-06 (work in		(CGNs)", draft-ietf-behave-lsn-requirements-09 (work in
	progress), May 2012.		progress), August 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",
End of changes. 34 change blocks.
	130 lines changed or deleted		76 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/