--- 1/draft-ietf-opsawg-lsn-deployment-03.txt 2013-12-23 08:14:32.030541506 -0800 +++ 2/draft-ietf-opsawg-lsn-deployment-04.txt 2013-12-23 08:14:32.074542551 -0800 @@ -1,32 +1,32 @@ OPSAWG V. Kuarsingh, Ed. Internet-Draft J. Cianfarani Intended status: Informational Rogers Communications -Expires: December 29, 2013 June 27, 2013 +Expires: June 26, 2014 December 23, 2013 CGN Deployment with BGP/MPLS IP VPNs - draft-ietf-opsawg-lsn-deployment-03 + draft-ietf-opsawg-lsn-deployment-04 Abstract This document specifies a framework to integrate a Network Address Translation layer into an operator's network to function as a Carrier Grade NAT (also known as CGN or Large Scale NAT). The CGN infrastructure will often form a NAT444 environment as the subscriber home network will likely also maintain a subscriber side NAT function. Exhaustion of the IPv4 address pool is a major driver compelling some operators to implement CGN. Although operators may wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near term needs may not be satisfied with an IPv6 deployment alone. This 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 existing services and meeting the technical challenges that CGN brings. The model included in this document utilizes BGP/MPLS IP VPNs which allow for virtual routing separation helping ease the CGNs impact on the network. This document does not intend to defend the merits of CGN. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -35,23 +35,24 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 29, 2013. + This Internet-Draft will expire on June 26, 2014. Copyright Notice + Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of @@ -54,126 +55,151 @@ publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. CGN Network Deployment Requirements . . . . . . . . . . . . . 4 - 3.1. Centralized versus Distributed Deployment . . . . . . . . 5 + 3.1. Centralized versus Distributed Deployment . . . . . . . . 6 3.2. CGN and Traditional IPv4 Service Co-existence . . . . . . 6 - 3.3. CGN By-Pass . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.4. Routing Plane Separation . . . . . . . . . . . . . . . . 6 + 3.3. CGN By-Pass . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.4. Routing Plane Separation . . . . . . . . . . . . . . . . 7 3.5. Flexible Deployment Options . . . . . . . . . . . . . . . 7 - 3.6. IPv4 Overlap Space . . . . . . . . . . . . . . . . . . . 7 - 3.7. Transactional Logging for LSN Systems . . . . . . . . . . 7 - 3.8. Additional CGN Requirements . . . . . . . . . . . . . . . 8 - 4. BGP/MPLS IP VPN based CGN Framework . . . . . . . . . . . . . 8 + 3.6. IPv4 Overlap Space . . . . . . . . . . . . . . . . . . . 8 + 3.7. Transactional Logging for CGN Systems . . . . . . . . . . 8 + 3.8. Base CGN Requirements . . . . . . . . . . . . . . . . . . 8 + 4. BGP/MPLS IP VPN based CGN Framework . . . . . . . . . . . . . 9 4.1. Service Separation . . . . . . . . . . . . . . . . . . . 10 - 4.2. Internal Service Delivery . . . . . . . . . . . . . . . . 10 - 4.2.1. Dual Stack Operation . . . . . . . . . . . . . . . . 12 - 4.3. Deployment Flexibility . . . . . . . . . . . . . . . . . 14 + 4.2. Internal Service Delivery . . . . . . . . . . . . . . . . 11 + 4.2.1. Dual Stack Operation . . . . . . . . . . . . . . . . 13 + 4.3. Deployment Flexibility . . . . . . . . . . . . . . . . . 15 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN - Attachment Options . . . . . . . . . . . . . . . . . . . 14 - 4.4.1. Policy Based Routing . . . . . . . . . . . . . . . . 14 - 4.4.2. Traffic Engineering . . . . . . . . . . . . . . . . . 15 - 4.4.3. Multiple Routing Topologies . . . . . . . . . . . . . 15 - 4.5. Multicast Considerations . . . . . . . . . . . . . . . . 15 - 5. Experiences . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 5.1. Basic Integration and Requirements Support . . . . . . . 15 - 5.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 16 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 8. BGP/MPLS IP VPN CGN Framework Discussion . . . . . . . . . . 17 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 - 10.2. Informative References . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 + Attachment Options . . . . . . . . . . . . . . . . . . . 15 + 4.4.1. Policy Based Routing . . . . . . . . . . . . . . . . 15 + 4.4.2. Traffic Engineering . . . . . . . . . . . . . . . . . 16 + 4.4.3. Multiple Routing Topologies . . . . . . . . . . . . . 16 + 4.5. Multicast Considerations . . . . . . . . . . . . . . . . 16 + 5. Experiences . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 5.1. Basic Integration and Requirements Support . . . . . . . 16 + 5.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 17 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 8. BGP/MPLS IP VPN CGN Framework Discussion . . . . . . . . . . 18 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 + 10.2. Informative References . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction Operators are faced with near term IPv4 address exhaustion challenges. Many operators may not have a sufficient amount of IPv4 addresses in the future to satisfy the needs of their growing subscriber base. This challenge may also be present before or during an active transition to IPv6 somewhat complicating the overall problem space. To face this challenge, operators may need to deploy CGN (Carrier Grade NAT) as described in [RFC6888] to help extend the connectivity - matrix once IPv4 addresses caches run out on the local local - operator. CGN deployments will most often be added into operator - networks which already have active IPv4 and/or IPv6 services. + matrix once IPv4 address caches run out on the local local operator. + CGN deployments will most often be added into operator networks which + already have active IPv4 and/or IPv6 services. The addition of the CGN introduces an operator controlled and administered translation layer which should be added in a manner which minimizes disruption to existing services. The CGN system addition may also include interworking in a dual stack environment where the IPv4 path requires translation. This document shows how BGP/MPLS IP VPNs as described in [RFC4364] can be used to integrate the CGN infrastructure solving key integration challenges faced by the operator. This model has also been tested and validated in real production network models and allows fluid operation with existing IPv4 and IPv6 services. +1.1. Terms + + A list of acronyms used throughout this document are defined in list + below. + + CGN - Carrier Grade NAT + + DOCSIS - Data Over Cable Service Interface Specification + + CMTS - Cable Modem Termination System + + DSL -Digital subscriber line + + BRAS - Broadband Remote Access Server + + GGSN - Gateway GPRS Support Node + GPRS - General Packet Radio Service + + ASN-GW - Access Service Network Gateway + 2. Motivation 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 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 + 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 - of the operator, and even when it's in the administrative control; it + 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 poses both cost and technical challenges as operators build out massive programs for equipment retirement or upgrade. These issues leave an operator in a precarious position which may lead to the decision to deploy CGN. Other address IPv4 sharing options do exist which are more architecturally desirable, but the practical and workable approach in many cases is a CGN deployment using the NAT444 framework. 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 subscriber base. This will include solving a number of challenges - since subscribers who's connections require translation will have + since subscribers whose connections require translation will have network routing and flow needs which are different from legacy IPv4 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 If a service provider is considering a CGN deployment with a provider NAT44 function, there are a number of basic architectural requirements which are of importance. Preliminary architectural - requirements may require all or some of the following from the - incoming CGN system: + requirements may require all or some of those captured in the list + below. Each of the architectural requirement items listed are + expanded upon in the following subsections. It should be noted that + architectural CGN requirements add additive to base CGN functional + requirements in [RFC6888]. The assessed architectural requirements + for deployment are: - Support distributed (sparse) and centralized (dense) deployment models; - Allow co-existence with traditional IPv4 based deployments, which provide global scoped IPv4 addresses to CPEs; - Provide a framework for CGN by-pass supporting non-translated flows between endpoints within a provider's network; @@ -265,21 +291,21 @@ 3.3. CGN By-Pass The CGN environment is only needed for flows with translation requirements. Many flows which remain within the operator's network, do not require translation. Such services include operator offered DNS Services, DHCP Services, NTP Services, Web Caching, E-Mail, News and other services which are local to the operator's network. The operator may want to leverage opportunities to offer third 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. 3.4. Routing Plane Separation Many operators will want to engineer traffic separately for CGN flows versus flows which are part of the more traditional IPv4 environment. Many times the routing of these two major flow types differ, therefore route separation may be required. Routing plane separation also allows the operator to utilize other @@ -299,61 +325,63 @@ The CGN deployment should also be flexible enough to change over time as demand for translation services increase or change as noted in [RFC6264]. In turn, the deployment will need to then adapt as translation demand decreases caused by the transition of flows to IPv6. Translation points should be able to be placed and moved with as little re-engineering effort as possible minimizing the risks to the subscriber base. Depending on hardware capabilities, security practices and IPv4 - address availability, the translation environments my need to be + address availability, the translation environments may need to be segmented and/or scaled over time to meet organic IPv4 demand growth. Operators may also want to choose models that support transition to 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 IPv4 address overlap for CGN translation realms may be required if insufficient IPv4 addresses are available within the operator environment to assign internally unique IPv4 addresses to the CGN subscriber base . The CGN deployment should provide mechanisms to manage IPv4 overlap if required. -3.7. Transactional Logging for LSN Systems +3.7. Transactional Logging for CGN Systems CGNs may require transactional logging since the source IP and related transport protocol information is not easily visible to external hosts and system. If needed, the CGN systems should be able to generate logs which identify 'internal' host parameters (i.e. IP/Port) and associated them to external translated parameters imposed by the translator. The logged information should be stored on the CGN hardware and/or exported to an external system for processing. The operator may choose to also enable mechanisms to help reduce logging such as block allocation of UDP and TCP ports or deterministic translation options such as [I-D.donley-behave-deterministic-cgn]. Operators may need to keep track of this information (securely) to meet regulatory and/or legal obligations. Further information can be found in [RFC6888] with respect to CGN logging requirements (Logging Section). -3.8. Additional CGN Requirements +3.8. Base CGN Requirements - The CGN platform will also need to meet the needs of additional - requirements such as Bulk Port Allocation and other CGN device - specific functions. These additional requirements are captured - within [RFC6888]. + Whereas the requirements above represent assessed architectural + requirements, the CGN platform will also need to meet the need to + meet the base CGN requirements of a CGN function. Base requirements + include such functions as Bulk Port Allocation and other CGN device + specific functions. These base CGN platform requirements are + captured within [RFC6888]. 4. BGP/MPLS IP VPN based CGN Framework The BGP/MPLS IP VPN [RFC4364] framework for CGN segregates the 'pre- translated' realms within the service provider space into Layer-3 MPLS based VPNs. The operator can deploy a single realm for all CGN based flows, or can deploy multiple realms based on translation demand and other factors such as geographical proximity. A realm in this model refers to a 'VPN' which shares a unique Route Distinguisher/Route Target (RD/RT) combination, routing plane and @@ -510,23 +538,23 @@ | Local | | Content | +-----------+ Figure 2: Internal Services and CGN By-Pass An extension to the services delivery LSP is the ability to also provide direct subscriber to subscriber traffic flows between CGN 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. + (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 | | @@ -730,21 +758,21 @@ between zones with some impact to extranet service model) - Simple failover techniques can be implemented with redundant translators, such as using a second default route 5.2. Performance The MPLS/VPN CGN model was observed to support basic functions which are typically used by subscribes within an operator environment. A full review of the observed impacts related to CGN (NAT444) are - covered in [I-D.donley-nat444-impacts]. + covered in [RFC7021]. 6. IANA Considerations There are not specific IANA considerations known at this time with 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 @@ -791,28 +819,21 @@ [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. 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] - Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U. - Colorado, "Assessing the Impact of Carrier-Grade NAT on - Network Applications", draft-donley-nat444-impacts-06 - (work in progress), April 2013. + behave-deterministic-cgn-06 (work in progress), July 2013. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008. @@ -841,28 +862,32 @@ VPNs", RFC 6513, February 2012. [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, April 2012. [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. + [RFC7021] Donley, C., Howard, L., Kuarsingh, V., Berg, J., and J. + Doshi, "Assessing the Impact of Carrier-Grade NAT on + Network Applications", RFC 7021, September 2013. + Authors' Addresses + Victor Kuarsingh (editor) Rogers Communications 8200 Dixie Road Brampton, Ontario L6T 0C1 Canada Email: victor@jvknet.com URI: http://www.rogers.com - John Cianfarani Rogers Communications 8200 Dixie Road Brampton, Ontario L6T 0C1 Canada Email: john.cianfarani@rci.rogers.com URI: http://www.rogers.com