draft-ietf-opsawg-lsn-deployment-02.txt   draft-ietf-opsawg-lsn-deployment-03.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: August 22, 2013 February 18, 2013 Expires: December 29, 2013 June 27, 2013
CGN Deployment with BGP/MPLS IP VPNs CGN Deployment with BGP/MPLS IP VPNs
draft-ietf-opsawg-lsn-deployment-02 draft-ietf-opsawg-lsn-deployment-03
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 August 22, 2013. This Internet-Draft will expire on December 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . 10 4.1. Service Separation . . . . . . . . . . . . . . . . . . . 10
4.2. Internal Service Delivery . . . . . . . . . . . . . . . . 10 4.2. Internal Service Delivery . . . . . . . . . . . . . . . . 10
4.2.1. Dual Stack Operation . . . . . . . . . . . . . . . . . 12 4.2.1. Dual Stack Operation . . . . . . . . . . . . . . . . 12
4.3. Deployment Flexibility . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . 14 Attachment Options . . . . . . . . . . . . . . . . . . . 14
4.4.1. Policy Based Routing . . . . . . . . . . . . . . . . . 14 4.4.1. Policy Based Routing . . . . . . . . . . . . . . . . 14
4.4.2. Traffic Engineering . . . . . . . . . . . . . . . . . 15 4.4.2. Traffic Engineering . . . . . . . . . . . . . . . . . 15
4.4.3. Multiple Routing Topologies . . . . . . . . . . . . . 15 4.4.3. Multiple Routing Topologies . . . . . . . . . . . . . 15
5. Experiences . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.5. Multicast Considerations . . . . . . . . . . . . . . . . 15
5.1. Basic Integration and Requirements Support . . . . . . . . 15 5. Experiences . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Basic Integration and Requirements Support . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. BGP/MPLS IP VPN CGN Framework Discussion . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 8. BGP/MPLS IP VPN CGN Framework Discussion . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . 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 [RFC6888] to help extend the connectivity
extend the connectivity matrix once IPv4 addresses caches run out on matrix once IPv4 addresses caches run out on the local local
the local local operator. CGN deployments will most often be added operator. CGN deployments will most often be added into operator
into operator networks which already have active IPv4 and/or IPv6 networks which already have active IPv4 and/or IPv6 services.
services.
The addition of the CGN introduces an operator controlled and The addition of the CGN introduces an operator controlled and
administered translation layer which should be added in a manner administered translation layer which should be added in a manner
which minimizes disruption to existing services. The CGN system which minimizes disruption to existing services. The CGN system
addition may also include interworking in a dual stack environment addition may also include interworking in a dual stack environment
where the IPv4 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
skipping to change at page 5, line 34 skipping to change at page 5, line 32
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 from distributed deployments of CGN (closer proximity to end user and
and/or lower densities of subscribers/connections to CGN instances). /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 7, line 39 skipping to change at page 7, line 37
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 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. The operator may exported to an external system for processing. The operator may
choose to also enable mechanisms to help reduce logging such as block choose to also enable mechanisms to help reduce logging such as block
allocation of UDP and TCP ports or deterministic translation options allocation of UDP and TCP ports or deterministic translation options
such as [I-D.donley-behave-deterministic-cgn]. 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 [I-D.ietf-behave-lsn-requirements] with respect to CGN found in [RFC6888] with respect to CGN logging requirements (Logging
logging requirements (Logging Section). 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 [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 '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 Route this model refers to a 'VPN' which shares a unique Route
Distinguisher/Route Target (RD/RT) combination, routing plane and Distinguisher/Route Target (RD/RT) combination, routing plane and
skipping to change at page 12, line 5 skipping to change at page 12, line 4
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 Figure (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 3 below, is easy to implement and can only be enabled if no 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 | +---------+ | | | +-------+ | | | | |
| --+--+-+- GRT | | | | | GRT | | | | | | +-----+ | | | | | | | | | | | | |
+-----+ | | | | | | | | | | | | | | --+--+-+- GRT | | | | | GRT | | | | | |
| +---------+ | | | +-------+ | | +------+ | +-----+ | | | | | | | | | | | | |
+-------------+ | +-----------+ +----------+ | +---------+ | | | +-------+ | | +------+ |
| +-------------+ | +-----------+ +----------+
LSP | |
| LSP |
Access Node-2 | VRF Termination CGN-2 |
+-------------+ | +-----------+ +----------+ Access Node-2 | VRF Termination CGN-2
| | | | | | | +-------------+ | +-----------+ +----------+
CPE-3 | +---------+ | | | +-------+ | | +------+ | | | | | | | |
+-----+ | | | | | | | | | | | | | CPE-3 | +---------+ | | | +-------+ | | +------+ |
| --+--+-+-- VRF --+-+-+ | | VRF | | | | | | +-----+ | | | | | | | | | | | | |
+-----+ | | | | | | | | | | | | | --+--+-+-- VRF --+-+-+ | | VRF | | | | | |
| +---------+ | | +-------+ | | | | | +-----+ | | | | | | | | | | | |
| | | | | |XLATE | | | +---------+ | | +-------+ | | | | |
| | | | | | | | | | | | | |XLATE | |
CPE-4 | +---------+ | | +-------+ | | | | | | | | | | | | |
+-----+ | | | | | | | | | | | | CPE-4 | +---------+ | | +-------+ | | | | |
| --+--+-+- GRT | | | | GRT | | | | | | +-----+ | | | | | | | | | | | |
+-----+ | | | | | | | | | | | | | --+--+-+- GRT | | | | GRT | | | | | |
| +---------+ | | +-------+ | | +------+ | +-----+ | | | | | | | | | | | |
+-------------+ +-----------+ +----------+ | +---------+ | | +-------+ | | +------+ |
+-------------+ +-----------+ +----------+
The inherent capabilities of the BGP/MPLS IP VPN model demonstrates The inherent capabilities of the BGP/MPLS IP VPN model demonstrates
the ability to offer CGN By-Pass in a standard and deterministic the ability to offer CGN By-Pass in a standard and deterministic
manner without the need of policy based routing or traffic manner without the need of policy based routing or traffic
engineering. 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
skipping to change at page 15, line 26 skipping to change at page 15, line 26
Multiple routing topologies can be used to direct CGN based flows to Multiple routing topologies can be used to direct CGN based flows to
translators. This option would achieve the same basic goal as the translators. This option would achieve the same basic goal as the
MPLS/VPN option but with additional implementation overhead and MPLS/VPN option but with additional implementation overhead and
platform configuration complexity. Since operator based translation platform configuration complexity. Since operator based translation
is expected to have an unknown lifecycle, and may see various degrees is expected to have an unknown lifecycle, and may see various degrees
of demand (dependant on operator IPv4 Global space availability and of demand (dependant on operator IPv4 Global space availability and
shift of traffic to IPv6), it may be too large of an undertaking for shift of traffic to IPv6), it may be too large of an undertaking for
the provider to enabled this as their primary option for CGN. the provider to enabled this as their primary option for CGN.
4.5. Multicast Considerations
When deploying BGP/MPLS IP VPN's as an service method for user plane
traffic to access CGN, one needs to be cognizant of current or future
IP multicast requirements. User plane IP Multicast which may
originate outside of the VRF requires more consideration specific
consideration. Adding the requirement for user plane IP multicast
can potentially cause additional complexity related to import and
exporting the IP multicast routes in addition to sub optimal scaling,
and bandwidth utilization.
It is recommended to reference best practice and designs from
[RFC6037], [RFC6513], and [RFC5332]
5. Experiences 5. Experiences
5.1. Basic Integration and Requirements Support 5.1. Basic Integration and Requirements Support
The MPLS/VPN CGN environment has been successfully integrated into The MPLS/VPN CGN environment has been successfully integrated into
real network environments utilizing existing network service delivery real network environments utilizing existing network service delivery
mechanisms. It solves many issues related to provider based mechanisms. It solves many issues related to provider based
translation environments, while still subject to problematic translation environments, while still subject to problematic
behaviours inherent within NAT. behaviours inherent within NAT.
skipping to change at page 17, line 33 skipping to change at page 17, line 42
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", Logging in Carrier Grade NAT Deployments", draft-donley-
draft-donley-behave-deterministic-cgn-05 (work in behave-deterministic-cgn-05 (work in progress), January
progress), January 2013. 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-06
(work in progress), October 2012. (work in progress), April 2013.
[I-D.ietf-behave-lsn-requirements]
Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common requirements for Carrier Grade NATs
(CGNs)", draft-ietf-behave-lsn-requirements-10 (work in
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
BCP 5, RFC 1918, February 1996. 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
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", Infrastructures (6rd) -- Protocol Specification", RFC
RFC 5969, August 2010. 5969, August 2010.
[RFC6037] Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems'
Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037,
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
Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264,
June 2011. 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.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
VPNs", RFC 6513, February 2012.
[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 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common Requirements for Carrier-Grade NATs
(CGNs)", BCP 127, RFC 6888, April 2013.
Authors' Addresses
Victor Kuarsingh (editor) Victor Kuarsingh (editor)
Rogers Communications Rogers Communications
8200 Dixie Road 8200 Dixie Road
Brampton, Ontario L6T 0C1 Brampton, Ontario L6T 0C1
Canada Canada
Email: victor.kuarsingh@gmail.com Email: victor@jvknet.com
URI: http://www.rogers.com URI: http://www.rogers.com
John Cianfarani John Cianfarani
Rogers Communications Rogers Communications
8200 Dixie Road 8200 Dixie Road
Brampton, Ontario L6T 0C1 Brampton, Ontario L6T 0C1
Canada Canada
Email: john.cianfarani@rci.rogers.com Email: john.cianfarani@rci.rogers.com
URI: http://www.rogers.com URI: http://www.rogers.com
 End of changes. 23 change blocks. 
99 lines changed or deleted 121 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/