draft-ietf-opsawg-lsn-deployment-04.txt   draft-ietf-opsawg-lsn-deployment-05.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: June 26, 2014 December 23, 2013 Expires: July 27, 2014 January 23, 2014
CGN Deployment with BGP/MPLS IP VPNs CGN Deployment with BGP/MPLS IP VPNs
draft-ietf-opsawg-lsn-deployment-04 draft-ietf-opsawg-lsn-deployment-05
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 maintain a subscriber side NAT home network will likely also maintain a subscriber side NAT
function. Exhaustion of the IPv4 address pool is a major driver function. Exhaustion of the IPv4 address pool is a major driver
compelling some operators to implement CGN. Although operators may compelling some operators to implement CGN. Although operators may
skipping to change at page 1, line 31 skipping to change at page 1, line 31
term needs may not be satisfied with an IPv6 deployment alone. This term needs may not be satisfied with an IPv6 deployment alone. This
document provides a practical integration model which allows the CGN document provides a practical integration model which allows the CGN
platform to be integrated into the network, meeting the connectivity platform to be integrated into the network, meeting the connectivity
needs of the subscriber while being mindful of not disrupting needs of the subscriber while being mindful of not disrupting
existing services and meeting the technical challenges that CGN existing services and meeting the technical challenges that CGN
brings. The model included in this document utilizes BGP/MPLS IP brings. The model included in this document utilizes BGP/MPLS IP
VPNs which allow for virtual routing separation helping ease the CGNs VPNs which allow for virtual routing separation helping ease the CGNs
impact on the network. This document does not intend to defend the impact on the network. This document does not intend to defend the
merits of CGN. 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 June 26, 2014. This Internet-Draft will expire on July 27, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Existing Network Considerations . . . . . . . . . . . . . . . 5
3. CGN Network Deployment Requirements . . . . . . . . . . . . . 4 3. CGN Network Deployment Requirements . . . . . . . . . . . . . 5
3.1. Centralized versus Distributed Deployment . . . . . . . . 6 3.1. Centralized versus Distributed Deployment . . . . . . . . 6
3.2. CGN and Traditional IPv4 Service Co-existence . . . . . . 6 3.2. CGN and Traditional IPv4 Service Co-existence . . . . . . 7
3.3. CGN By-Pass . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. CGN By-Pass . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Routing Plane Separation . . . . . . . . . . . . . . . . 7 3.4. Routing Plane Separation . . . . . . . . . . . . . . . . . 8
3.5. Flexible Deployment Options . . . . . . . . . . . . . . . 7 3.5. Flexible Deployment Options . . . . . . . . . . . . . . . 8
3.6. IPv4 Overlap Space . . . . . . . . . . . . . . . . . . . 8 3.6. IPv4 Overlap Space . . . . . . . . . . . . . . . . . . . . 8
3.7. Transactional Logging for CGN Systems . . . . . . . . . . 8 3.7. Transactional Logging for CGN Systems . . . . . . . . . . 9
3.8. Base CGN Requirements . . . . . . . . . . . . . . . . . . 8 3.8. Base CGN Requirements . . . . . . . . . . . . . . . . . . 9
4. BGP/MPLS IP VPN based CGN Framework . . . . . . . . . . . . . 9 4. BGP/MPLS IP VPN based CGN Framework . . . . . . . . . . . . . 9
4.1. Service Separation . . . . . . . . . . . . . . . . . . . 10 4.1. Service Separation . . . . . . . . . . . . . . . . . . . . 11
4.2. Internal Service Delivery . . . . . . . . . . . . . . . . 11 4.2. Internal Service Delivery . . . . . . . . . . . . . . . . 12
4.2.1. Dual Stack Operation . . . . . . . . . . . . . . . . 13 4.2.1. Dual Stack Operation . . . . . . . . . . . . . . . . . 14
4.3. Deployment Flexibility . . . . . . . . . . . . . . . . . 15 4.3. Deployment Flexibility . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . 15 Attachment Options . . . . . . . . . . . . . . . . . . . . 16
4.4.1. Policy Based Routing . . . . . . . . . . . . . . . . 15 4.4.1. Policy Based Routing . . . . . . . . . . . . . . . . . 16
4.4.2. Traffic Engineering . . . . . . . . . . . . . . . . . 16 4.4.2. Traffic Engineering . . . . . . . . . . . . . . . . . 17
4.4.3. Multiple Routing Topologies . . . . . . . . . . . . . 16 4.4.3. Multiple Routing Topologies . . . . . . . . . . . . . 17
4.5. Multicast Considerations . . . . . . . . . . . . . . . . 16 4.5. Multicast Considerations . . . . . . . . . . . . . . . . . 17
5. Experiences . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Experiences . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Basic Integration and Requirements Support . . . . . . . 16 5.1. Basic Integration and Requirements Support . . . . . . . . 17
5.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 17 5.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. BGP/MPLS IP VPN CGN Framework Discussion . . . . . . . . . . 18 8. BGP/MPLS IP VPN CGN Framework Discussion . . . . . . . . . . . 18
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
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.
skipping to change at page 4, line 4 skipping to change at page 4, line 48
DOCSIS - Data Over Cable Service Interface Specification DOCSIS - Data Over Cable Service Interface Specification
CMTS - Cable Modem Termination System CMTS - Cable Modem Termination System
DSL -Digital subscriber line DSL -Digital subscriber line
BRAS - Broadband Remote Access Server BRAS - Broadband Remote Access Server
GGSN - Gateway GPRS Support Node GGSN - Gateway GPRS Support Node
GPRS - General Packet Radio Service GPRS - General Packet Radio Service
ASN-GW - Access Service Network Gateway ASN-GW - Access Service Network Gateway
GRT - Global Routing Table
2. Motivation Internal Realm - Addressing and/or network zone been the CPE and
CGN as specified in [RFC6888]
The selection of CGN may be made by an operator based on a number of External Realm - Public side network zone and addressing on the
factors. The overall driver may be the depletion of IPv4 address Internet facing side of the CGN as specified in [RFC6888]
pools which leaves little to no addresses for IPv4 service or
connection demand growth. IPv6 is considered the strategic answer,
but it's applicability and usefulness in many networks is limited by
the current access network and consumer home network. Customer
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 2. Existing Network Considerations
of the operator, and even when it's in the administrative control, it
poses both cost and technical challenges as operators build out The selection of CGN may be made by an operator based on a number of
massive programs for equipment retirement or upgrade. These issues factors. The overall driver to use CGN may be the depletion of IPv4
leave an operator in a precarious position which may lead to the address pools which leaves little to no addresses for a growing IPv4
decision to deploy CGN. Other address IPv4 sharing options do exist service or connection demand growth. IPv6 is considered the
which are more architecturally desirable, but the practical and strategic answer for IPv4 address depletion; however, the operator
workable approach in many cases is a CGN deployment using the NAT444 may independently decide that CGN is needed to supplement IPv6 and
framework. address their particular IPv4 service deployment needs.
If the operator has chosen to deploy CGN, they should do 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 whose connections require translation will have since subscribers whose 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
other options such as DS-Lite [RFC6333] are not yet viable. Even
technologies like 6RD [RFC5969] still require an IPv4 connectivity
path to service the subscriber endpoint. The solution will need to
address basic Internet connectivity, on-net service offerings, back
office management, billing, policy and security models already in
place within the operator's network. CGN will often integrate quite
readily with the aforementioned requirements where as other
transition mechanism may not due to the requirements to support IPv6
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 architectural NAT44 function, there are a number of basic architectural
requirements which are of importance. Preliminary architectural requirements which are of importance. Preliminary architectural
requirements may require all or some of those captured in the list requirements may require all or some of those captured in the list
below. Each of the architectural requirement items listed are below. Each of the architectural requirement items listed are
expanded upon in the following subsections. It should be noted that expanded upon in the following subsections. It should be noted that
architectural CGN requirements add additive to base CGN functional architectural CGN requirements add additive to base CGN functional
requirements in [RFC6888]. The assessed architectural requirements requirements in [RFC6888]. The assessed architectural requirements
skipping to change at page 6, line 13 skipping to change at page 6, line 44
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 may 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 and from distributed deployments of CGN (closer proximity to end user
/or lower densities of subscribers/connections to CGN instances). and/or lower densities of subscribers/connections to CGN instances).
Service providers may likely deploy CGN translation points more Service providers may likely deploy CGN translation points more
centrally during initial phases if the early system demand is low. centrally during initial phases if the early system demand is low.
Early deployments may see light loading on these new systems since Early deployments may see light loading on these new systems since
legacy IPv4 services will continue to operate with most endpoints legacy IPv4 services will continue to operate with most endpoints
using globally unique IPv4 addresses. Exceptional cases which may using globally unique IPv4 addresses. Exceptional cases which may
drive heavy usage in initial stages may include operators who already drive heavy usage in initial stages may include operators who already
translate a significant portion of their IPv4 traffic; may transition translate a significant portion of their IPv4 traffic; may transition
to a CGN implementation from legacy translation mechanisms (i.e. to a CGN implementation from legacy translation mechanisms (i.e.
traditional firewalls); or build a green field deployment which may traditional firewalls); or build a green field deployment which may
see quick growth in the number of new IPv4 endpoints which require see quick growth in the number of new IPv4 endpoints which require
skipping to change at page 8, line 18 skipping to change at page 8, line 49
Operators may also want to choose models that support transition to Operators may also want to choose models that support transition to
other translation environments such as DS-Lite [RFC6333] and/or NAT64 other translation environments such as DS-Lite [RFC6333] and/or NAT64
[RFC6146]. Operators will want to seek deployment models which are [RFC6146]. Operators will want to seek deployment models which are
conducive to meeting these goals as well. conducive to meeting these goals as well.
3.6. IPv4 Overlap Space 3.6. IPv4 Overlap Space
IPv4 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 operator insufficient IPv4 addresses are available within the operator
environment to assign internally unique IPv4 addresses to the CGN environment to assign internally unique IPv4 addresses to the CGN
subscriber base . The CGN deployment should provide mechanisms to subscriber base . The CGN deployment should provide mechanisms to
manage IPv4 overlap if required. manage IPv4 overlap if required.
3.7. Transactional Logging for CGN Systems 3.7. Transactional Logging for CGN 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 realm host parameters (i.e. IP/Port) and
them to external translated parameters imposed by the translator. associated them to external realm parameters imposed by the
The logged information should be stored on the CGN hardware and/or translator. The logged information should be stored on the CGN
exported to an external system for processing. The operator may hardware and/or exported to another system for processing. The
choose to also enable mechanisms to help reduce logging such as block operator may choose to also enable mechanisms to help reduce logging
allocation of UDP and TCP ports or deterministic translation options such as block allocation of UDP and TCP ports or deterministic
such as [I-D.donley-behave-deterministic-cgn]. translation options such as [I-D.donley-behave-deterministic-cgn].
Operators may need to keep track of this information (securely) to Operators may need to keep track of this information (securely) to
meet regulatory and/or legal obligations. Further information can be meet regulatory and/or legal obligations. Further information can be
found in [RFC6888] with respect to CGN logging requirements (Logging found in [RFC6888] with respect to CGN logging requirements (Logging
Section). Section).
3.8. Base CGN Requirements 3.8. Base CGN Requirements
Whereas the requirements above represent assessed architectural Whereas the requirements above represent assessed architectural
requirements, the CGN platform will also need to meet the need to requirements, the CGN platform will also need to meet the need to
meet the base CGN requirements of a CGN function. Base requirements meet the base CGN requirements of a CGN function. Base requirements
include such functions as Bulk Port Allocation and other CGN device include such functions as Bulk Port Allocation and other CGN device
specific functions. These base CGN platform requirements are specific functions. These base CGN platform requirements are
captured within [RFC6888]. captured within [RFC6888].
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
translated' realms within the service provider space into Layer-3 internal realms within the service provider space into Layer-3 MPLS
MPLS based VPNs. The operator can deploy a single realm for all CGN based VPNs. The operator can deploy a single realm for all CGN based
based flows, or can deploy multiple realms based on translation flows, or can deploy multiple realms based on translation demand and
demand and other factors such as geographical proximity. A realm in other factors such as geographical proximity. A realm in this model
this model refers to a 'VPN' which shares a unique Route refers to a 'VPN' which shares a unique Route Distinguisher/Route
Distinguisher/Route Target (RD/RT) combination, routing plane and Target (RD/RT) combination, routing plane and forwarding behaviours.
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 internal realms.
The physical location of the Virtual Routing and Forwarding (VRF) The physical location of the Virtual Routing and Forwarding (VRF)
Termination point for a BGP/MPLS IP VPN enabled CGN can vary and be Termination point for a BGP/MPLS IP VPN enabled CGN can vary and be
located anywhere within the operator's network. This model fully located anywhere within the operator's network. This model fully
virtualizes the translation service from the base IPv4 forwarding virtualizes the translation service from the base IPv4 forwarding
environment which will likely be carrying Internet bound traffic. environment which will likely be carrying Internet bound traffic.
The base IPv4 environment can continue to service traditional IPv4 The base IPv4 environment can continue to service traditional IPv4
subscriber flows plus post 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
skipping to change at page 10, line 15 skipping to change at page 11, line 15
Access Node VRF Termination CGN Access Node VRF Termination CGN
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| | | | | | | | | | | |
CPE | +-------+ | | +-------+ | | +-------+ | CPE | +-------+ | | +-------+ | | +-------+ |
+----+ | | | | LSP | | | | IP | | | | +----+ | | | | LSP | | | | IP | | | |
| --+---+-+->VRF--+-+-----+-+->VRF--+-+----+-+-> | | | --+---+-+->VRF--+-+-----+-+->VRF--+-+----+-+-> | |
+----+ | | | | | | | | | | | | +----+ | | | | | | | | | | | |
| +-------+ | | +-------+ | | | | | | +-------+ | | +-------+ | | | | |
| | | | | | XLATE | | | | | | | | XLATE | |
| | | | | | | | | | | | | | | |
CPE | +-------+ | | +-------+ | | | | | CPE-CGN | +-------+ | | +-------+ | | | | |
+----+ | | | | | | | | IP | | | | +----+ | | | | | | | | IP | | | |
| --+---+-+->GRT | | | | GRT<-+-+----+-+-- | | | --+---+-+->GRT | | | | GRT<-+-+----+-+-- | |
+----+ | | | | | | | | | | | | | | +----+ | | | | | | | | | | | | | |
| +---+---+ | | +---+---+ | | +-------+ | | +---+---+ | | +---+---+ | | +-------+ |
+-----+-----+ +-----+-----+ +-----------+ +-----+-----+ +-----+-----+ +-----------+
| | | |
| | IPv4 | | IPv4
| | IP +---------+ | | IP +---------+
| +------------+-> | | +------------+-> |
| IP | GRT | | IP | GRT |
+------------------------------+-> | +------------------------------+-> |
+---------+ +---------+
Figure 1: Basic BGP/MPLS IP VPN CGN Model Figure 1: Basic BGP/MPLS IP VPN CGN Model
If more then one VRF (translation realm) is used within the If more then one VRF (translation realm) is used within the
operator's network, each VPN instance can manage CGN flows operator's network, each VPN instance can manage CGN flows
independently for the respective realm. Various redundancy models independently for the respective realm. The described architecture
can be used within this architecture to support failover from one does not prescribe a single redundancy model that ensures network
physical CGN hardware instance to another. If state information availability as a result of CGN failure. Deployments are able to
needs to be passed or maintained between hardware instances, the select a redundancy model that fits best with their network design.
vendor would need to enable this feature in a suitable manner. If state information needs to be passed or maintained between
hardware instances, the vendor would need to enable this feature in a
suitable manner.
4.1. Service Separation 4.1. Service Separation
The MPLS/VPN CGN framework supports route separation. The The MPLS/VPN CGN framework supports route separation. The
traditional IPv4 flows can be separated at the access node (Initial traditional IPv4 flows can be separated at the access node (Initial
Layer 3 service point) from those which require translation. This Layer 3 service point) from those which require translation. This
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
skipping to change at page 12, line 15 skipping to change at page 13, line 15
Access Node VRF Termination CGN Access Node VRF Termination CGN
+-------------+ +-----------+ +----------+ +-------------+ +-----------+ +----------+
| | | | | | | | | | | |
CPE | +---------+ | | +-------+ | | +------+ | CPE | +---------+ | | +-------+ | | +------+ |
+-----+ | | | | | | | | | | | | +-----+ | | | | | | | | | | | |
| --+--+-+-> VRF --+-+--+ | | VRF | | | | | | | --+--+-+-> VRF --+-+--+ | | VRF | | | | | |
+-----+ | | | | | | | | | | | | | +-----+ | | | | | | | | | | | | |
| +---------+ | | | +-------+ | | | | | | +---------+ | | | +-------+ | | | | |
| | | | | | |XLATE | | | | | | | | |XLATE | |
| | | | | | | | | | | | | | | | | |
CPE | +---------+ | | | +-------+ | | | | | CPE-CGN | +---------+ | | | +-------+ | | | | |
+-----+ | | | | | | | | | | | | | +-----+ | | | | | | | | | | | | |
| --+--+-+-> GRT | | | | | GRT | | | | | | | --+--+-+-> GRT | | | | | GRT | | | | | |
+-----+ | | | | | | | | | | | | | | +-----+ | | | | | | | | | | | | | |
| +----+----+ | | | +-------+ | | +------+ | | +----+----+ | | | +-------+ | | +------+ |
+------+------+ | +-----------+ +----------+ +------+------+ | +-----------+ +----------+
| | | |
| | IPv4 | | IPv4
| | +-----------+ | | +-----------+
| +---------------+->Services | | +---------------+->Services |
| | VRF | | | VRF |
skipping to change at page 12, line 41 skipping to change at page 13, line 41
| Local | | Local |
| Content | | Content |
+-----------+ +-----------+
Figure 2: Internal Services and CGN By-Pass Figure 2: Internal Services and CGN By-Pass
An extension to the services delivery LSP is the ability to also An extension to the services delivery LSP is the ability to also
provide direct subscriber to subscriber traffic flows between CGN provide direct subscriber to subscriber traffic flows between CGN
zones. Each zone or realm may be fitted with separate CGN resources, zones. Each zone or realm may be fitted with separate CGN resources,
but the subtending subscribers don't necessarily need to be mediated but the subtending subscribers don't necessarily need to be mediated
(translated) by the CGN translators. This option, as shown in (translated) by the CGN translators. This option, as shown in Figure
Figure 3 below, is easy to implement and can only be enabled if no 3 below, is easy to implement and can only be enabled if no IPv4
IPv4 address overlap is used between communicating CGN zones. address overlap is used between communicating CGN zones.
Access Node-1 VRF Termination CGN-1 Access Node-1 VRF Termination CGN-1
+-------------+ +-----------+ +----------+ +-------------+ +-----------+ +----------+
| | | | | | | | | | | |
CPE-1 | +---------+ | | +-------+ | | +------+ | CPE-1 | +---------+ | | +-------+ | | +------+ |
+-----+ | | | | | | | | | | | | +-----+ | | | | | | | | | | | |
| --+--+-+- VRF --+-+-+ | | VRF | | | | | | | --+--+-+- VRF --+-+-+ | | VRF | | | | | |
+-----+ | | | | | | | | | | | | | +-----+ | | | | | | | | | | | | |
| +---------+ | | | +-------+ | | | | | | +---------+ | | | +-------+ | | | | |
| | | | | | |XLATE | | | | | | | | |XLATE | |
| | | | | | | | | | | | | | | | | |
CPE-2 | +---------+ | | | +-------+ | | | | | CPE-2-CGN| +---------+ | | | +-------+ | | | | |
+-----+ | | | | | | | | | | | | | +-----+ | | | | | | | | | | | | |
| --+--+-+- GRT | | | | | GRT | | | | | | | --+--+-+- GRT | | | | | GRT | | | | | |
+-----+ | | | | | | | | | | | | | +-----+ | | | | | | | | | | | | |
| +---------+ | | | +-------+ | | +------+ | | +---------+ | | | +-------+ | | +------+ |
+-------------+ | +-----------+ +----------+ +-------------+ | +-----------+ +----------+
| |
LSP | LSP |
| |
Access Node-2 | VRF Termination CGN-2 Access Node-2 | VRF Termination CGN-2
+-------------+ | +-----------+ +----------+ +-------------+ | +-----------+ +----------+
| | | | | | | | | | | | | |
CPE-3 | +---------+ | | | +-------+ | | +------+ | CPE-3-CGN| +---------+ | | | +-------+ | | +------+ |
+-----+ | | | | | | | | | | | | | +-----+ | | | | | | | | | | | | |
| --+--+-+-- VRF --+-+-+ | | VRF | | | | | | | --+--+-+-- VRF --+-+-+ | | VRF | | | | | |
+-----+ | | | | | | | | | | | | +-----+ | | | | | | | | | | | |
| +---------+ | | +-------+ | | | | | | +---------+ | | +-------+ | | | | |
| | | | | |XLATE | | | | | | | |XLATE | |
| | | | | | | | | | | | | | | |
CPE-4 | +---------+ | | +-------+ | | | | | CPE-4 | +---------+ | | +-------+ | | | | |
+-----+ | | | | | | | | | | | | +-----+ | | | | | | | | | | | |
| --+--+-+- GRT | | | | GRT | | | | | | | --+--+-+- GRT | | | | GRT | | | | | |
+-----+ | | | | | | | | | | | | +-----+ | | | | | | | | | | | |
skipping to change at page 14, line 22 skipping to change at page 15, line 22
The Figure 4 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 CGN Access Node VRF Termination CGN
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| | | | | | | | | | | |
CPE | +-------+ | | +-------+ | | +-------+ | CPE-CG | +-------+ | | +-------+ | | +-------+ |
+-----+ | | | |LSP| | | | IP | | | | +-----+ | | | |LSP| | | | IP | | | |
| --+--+-+->VRF--+-+---+-+->VRF--+-+----+-+> | | | --+--+-+->VRF--+-+---+-+->VRF--+-+----+-+> | |
|IPv4 | | | | | | | | | | | | | |IPv4 | | | | | | | | | | | | |
| | | +-------+ | | +-------+ | | | | | | | | +-------+ | | +-------+ | | | | |
+-----| | | | | | | XLATE | | +-----| | | | | | | XLATE | |
|IPv6 | | | | | | | | | |IPv6 | | | | | | | | |
| | | +-------+ | | +-------+ | | | | | | | | +-------+ | | +-------+ | | | | |
| | | | IPv6 | | | | IPv4 | | IP | | | | | | | | IPv6 | | | | IPv4 | | IP | | | |
| --+--+-+->GRT | | | | GRT<-+-+----+-+-- | | | --+--+-+->GRT | | | | GRT<-+-+----+-+-- | |
+-----+ | | | | | | | | | | | | | | +-----+ | | | | | | | | | | | | | |
skipping to change at page 17, line 35 skipping to change at page 18, line 35
5.2. 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 subscribes within an operator environment. A are typically used by subscribes within an operator environment. A
full review of the observed impacts related to CGN (NAT444) are full review of the observed impacts related to CGN (NAT444) are
covered in [RFC7021]. covered in [RFC7021].
6. IANA Considerations 6. IANA Considerations
There are not specific IANA considerations known at this time with This document has no IANA actions.
the architecture described herein. Should a provide choose to use
non-assigned IP address space within their translation realms, then
considerations may apply.
7. 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.
the MPLS/VPN model, the operator would want to consider security
issues related to offering IP services over MPLS.
If a provider plans to operate the pre-translation realm (CPE towards
translator IPv4 zone) as a non-public like network, then additional
security measures may be needed to secure this environment. It is
however the position in this document that CGN realms are public
domains which utilize non-Internet routable IP addresses for endpoint
addressing.
8. BGP/MPLS IP VPN CGN Framework Discussion 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.
skipping to change at page 18, line 42 skipping to change at page 19, line 33
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] [I-D.donley-behave-deterministic-cgn]
Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K.,
and O. Vautrin, "Deterministic Address Mapping to Reduce and O. Vautrin, "Deterministic Address Mapping to Reduce
Logging in Carrier Grade NAT Deployments", draft-donley- Logging in Carrier Grade NAT Deployments",
behave-deterministic-cgn-06 (work in progress), July 2013. draft-donley-behave-deterministic-cgn-06 (work in
progress), July 2013.
[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", BCP E. Lear, "Address Allocation for Private Internets",
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.
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
Multicast Encapsulations", RFC 5332, August 2008. Multicast Encapsulations", RFC 5332, August 2008.
[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", RFC Infrastructures (6rd) -- Protocol Specification",
5969, August 2010. RFC 5969, August 2010.
[RFC6037] Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems' [RFC6037] Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems'
Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037, Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037,
October 2010. October 2010.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011. Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental
 End of changes. 30 change blocks. 
120 lines changed or deleted 95 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/