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/