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/