--- 1/draft-ietf-opsawg-lsn-deployment-02.txt 2013-06-27 21:14:25.434608532 +0100 +++ 2/draft-ietf-opsawg-lsn-deployment-03.txt 2013-06-27 21:14:25.478609600 +0100 @@ -1,18 +1,18 @@ OPSAWG V. Kuarsingh, Ed. Internet-Draft J. Cianfarani 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 - draft-ietf-opsawg-lsn-deployment-02 + draft-ietf-opsawg-lsn-deployment-03 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 @@ -20,101 +20,101 @@ 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 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 +Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 August 22, 2013. + This Internet-Draft will expire on December 29, 2013. 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 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. CGN Network Deployment Requirements . . . . . . . . . . . . . 4 3.1. Centralized versus Distributed Deployment . . . . . . . . 5 3.2. CGN and Traditional IPv4 Service Co-existence . . . . . . 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.6. IPv4 Overlap Space . . . . . . . . . . . . . . . . . . . . 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 - 4.1. Service Separation . . . . . . . . . . . . . . . . . . . . 10 + 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.1. Dual Stack Operation . . . . . . . . . . . . . . . . 12 + 4.3. Deployment Flexibility . . . . . . . . . . . . . . . . . 14 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN - Attachment Options . . . . . . . . . . . . . . . . . . . . 14 - 4.4.1. Policy Based Routing . . . . . . . . . . . . . . . . . 14 + 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.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 . . . . . . . . . . . 16 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 + 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 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 [I-D.ietf-behave-lsn-requirements] 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. + 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. 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 @@ -210,22 +209,22 @@ extend possible; Other requirements may be assessed on a operator-by-operator basis, but those listed above may be considered for any given deployment architecture. 3.1. Centralized versus Distributed Deployment Centralized deployments of CGN (longer proximity to end user and/or higher densities of subscribers/connections to CGN instances) differ - from distributed deployments of CGN (closer proximity to end user - and/or lower densities of subscribers/connections to CGN instances). + from distributed deployments of CGN (closer proximity to end user and + /or lower densities of subscribers/connections to CGN instances). Service providers may likely deploy CGN translation points more centrally during initial phases if the early system demand is low. Early deployments may see light loading on these new systems since legacy IPv4 services will continue to operate with most endpoints using globally unique IPv4 addresses. Exceptional cases which may drive heavy usage in initial stages may include operators who already translate a significant portion of their IPv4 traffic; may transition to a CGN implementation from legacy translation mechanisms (i.e. traditional firewalls); or build a green field deployment which may see quick growth in the number of new IPv4 endpoints which require @@ -331,29 +331,29 @@ 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 [I-D.ietf-behave-lsn-requirements] with respect to CGN - logging requirements (Logging Section). + found in [RFC6888] with respect to CGN logging requirements (Logging + Section). 3.8. Additional 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 [I-D.ietf-behave-lsn-requirements]. + 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 @@ -676,20 +677,34 @@ Multiple routing topologies can be used to direct CGN based flows to translators. This option would achieve the same basic goal as the MPLS/VPN option but with additional implementation overhead and platform configuration complexity. Since operator based translation is expected to have an unknown lifecycle, and may see various degrees of demand (dependant on operator IPv4 Global space availability and 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. +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.1. Basic Integration and Requirements Support The MPLS/VPN CGN environment has been successfully integrated into real network environments utilizing existing network service delivery mechanisms. It solves many issues related to provider based translation environments, while still subject to problematic behaviours inherent within NAT. @@ -774,72 +790,79 @@ 10.1. Normative References [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. + 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-05 - (work in progress), October 2012. - - [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. + Network Applications", draft-donley-nat444-impacts-06 + (work in progress), April 2013. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and - E. Lear, "Address Allocation for Private Internets", - BCP 5, RFC 1918, February 1996. + 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. + [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 - Infrastructures (6rd) -- Protocol Specification", - RFC 5969, August 2010. + Infrastructures (6rd) -- Protocol Specification", RFC + 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 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- Stack Lite Broadband Deployments Following IPv4 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 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 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) Rogers Communications 8200 Dixie Road Brampton, Ontario L6T 0C1 Canada - Email: victor.kuarsingh@gmail.com + 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