--- 1/draft-ietf-opsawg-lsn-deployment-00.txt 2012-10-15 00:14:26.669508930 +0200 +++ 2/draft-ietf-opsawg-lsn-deployment-01.txt 2012-10-15 00:14:26.725508768 +0200 @@ -1,52 +1,54 @@ OPSAWG V. Kuarsingh, Ed. Internet-Draft J. Cianfarani Intended status: Informational Rogers Communications -Expires: November 16, 2012 May 15, 2012 +Expires: April 18, 2013 October 15, 2012 CGN Deployment with BGP/MPLS IP VPNs - draft-ietf-opsawg-lsn-deployment-00 + draft-ietf-opsawg-lsn-deployment-01 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). CGN is a concept - also described in [I-D.ietf-behave-lsn-requirements] and describes - the model as a dual layer translation model. 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 CGN to - be integrated into the network meeting the connectivity needs of the - customer while being mindful of not disrupting existing services and - meeting the technical challenges that CGN brings. The model includes - the use of BGP/MPLS IP VPNs defined in [RFC4364] as a tool to achieve - this goal. This document does not intend to defend the merits of - CGN. + 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 contain a 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 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 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 November 16, 2012. + This Internet-Draft will expire on April 18, 2013. Copyright Notice Copyright (c) 2012 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 @@ -69,63 +71,61 @@ 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 . . . . . . . . . . . . . . . . . . . . 9 4.2. Internal Service Delivery . . . . . . . . . . . . . . . . 10 4.2.1. Dual Stack Operation . . . . . . . . . . . . . . . . . 11 4.3. Deployment Flexibility . . . . . . . . . . . . . . . . . . 13 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN Attachment Options . . . . . . . . . . . . . . . . . . . . 13 - 4.4.1. IEEE 802.1Q . . . . . . . . . . . . . . . . . . . . . 13 - 4.4.2. Policy Based Routing . . . . . . . . . . . . . . . . . 14 - 4.4.3. Traffic Engineering . . . . . . . . . . . . . . . . . 14 - 4.4.4. Multiple Routing Topologies . . . . . . . . . . . . . 14 + 4.4.1. Policy Based Routing . . . . . . . . . . . . . . . . . 13 + 4.4.2. Traffic Engineering . . . . . . . . . . . . . . . . . 14 + 4.4.3. Multiple Routing Topologies . . . . . . . . . . . . . 14 5. Experiences . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 6. Basic Integration and Requirements Support . . . . . . . . . . 14 - 7. Performance . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 + 5.1. Basic Integration and Requirements Support . . . . . . . . 14 + 5.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 15 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 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 - customer 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 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 run out in the - network. CGN's addition to the network requires integration in an - often running state environment with working IPv4 and/or IPv6 - services. + network. 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 needs to be added in a manner - which does not overly disrupt existing services. This addition may + administered translation layer which should be added in a manner + which minimizes disruption to existing services. This 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 problems - 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. + 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. 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 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. These environments often are filled with IPv4-Only equipment which may not be upgradable to IPv6. @@ -133,30 +133,30 @@ 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. Theses 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 NAT444. If the operator as has chosen to deploy CGN, they should this in a - manner as not to negatively impact the existing IPv4 or IPv6 customer - base. This will include solving a number of challenges since - customers who's connections require translation will have network - routing and flow needs which are different from legacy IPv4 + 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 + 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 customer endpoint. The solution will need to + path to service the subscriber endpoint. The solution will need to address basic Internet connectivity, on-net service offerings, back 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 @@ -194,21 +195,21 @@ - Transactional logging and export capabilities to support auxiliary functions including abuse mitigation; - Support for stateful connection synchronization between translation instances/elements (redundancy); - Support for CGN Shared Space [RFC6598] deployment modes if applicable; - Allows for the enablement of CGN functionality (if required) - while still minimizing costs and customer impact to the best + while still minimizing costs and subscriber impact to the best extend possible; Other requirements may be assessed on a operator-by-operator basis, but those listed above should 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 @@ -288,34 +289,34 @@ distributed peering infrastructures for transit and peering and these may span large geographical areas and regions. A CGN solution should offer the operator an ability to place CGN translation points at various points within their network. The CGN deployment should also be flexible enough to change over time as demand for translation services increase. 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 customer base. + minimizing the risks to the subscriber base. Depending on hardware capabilities, security practices and IPv4 address availability, the translation environments my need to be segmented and/or scaled over time to meet organic IPv4 demand growth. Operators will want to seek deployment models which are conducive to meeting these goals as well. 3.6. IPv4 Overlap Space IP address overlap for CGN translation realms may be required if insufficient IPv4 addresses are available within the service provider - environment to assign internally unique IPs to the CGN customer base - . The CGN deployment should provide mechanisms to manage IPv4 + environment to assign internally unique IPs to the CGN subscriber + base . The CGN deployment should provide mechanisms to manage IPv4 overlap if required. 3.7. Transactional Logging for LSN 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 @@ -341,40 +342,40 @@ 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 RD/RT combination, routing plane and forwarding behaviours. The BGP/MPLS IP VPN infrastructure provides control plane and forwarding separation for the traditional IPv4 service environment and CGN environment(s). The separation allows for routing information (such as default routes) to be propagated separately for - CGN and non-CGN based customer 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 translators for CGN mediated flows. Although many operators may run a "default-route-free" core, IPv4 flows which require translation must obviously be routed first to a translator, so a default route is acceptable for the pre-translated realms. The physical location of the VRF Termination point for a BGP/MPLS IP VPN enabled CGN can vary and be located anywhere within the operator's network. This model fully virtualizes the translation service from the base IPv4 forwarding environment which will likely carrying Internet bound traffic. The base IPv4 environment can - continue to service traditional IPv4 customer flows plus post + continue to service traditional IPv4 subscriber flows plus post translated CGN flows. Figure 1 provides a view of the basic model. The Access node provides CPE access to either the CGN VRF or the Global Routing - Table, depending on whether the customer receives a private or public - IP. Translator mediated traffic follows an MPLS LSP which can be - setup dynamically and can span one hop, or many hops (with no need + Table, depending on whether the subscriber receives a private or + public IP. Translator mediated traffic follows an MPLS LSP which can + be setup dynamically and can span one hop, or many hops (with no need for complex routing policies). Traffic is then forwarded to the translator (shown below) which can be an external appliance or integrated into the VRF Termination (Provider Edge) router. Once traffic is translated, it is forwarded to the global routing table for general Internet forwarding. The Global Routing table can also be a separate VRF (Internet Access VPN/VRF) should the provider choose to implement their Internet based services in that fashion. The translation services are effectively overlaid onto the network, but are maintained within a separate forwarding and control plane. @@ -566,78 +567,63 @@ and can be seen as independent. There is no specific need to diversify the existing infrastructure in most cases. 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN Attachment Options Other integration architecture options exist which can attach CGN based service flows to a translator instance. Alternate options which can be used to attach such services include: - - IEEE 802.1Q for direct attachment to a next hop translator; - - Policy Based Routing (Static) to direct translation bound traffic to a network based translator; - Traffic Engineering or; - Multiple Routing Topologies -4.4.1. IEEE 802.1Q - - IEEE 802.1Q can be used to associate separated traffic from the - access node to the next hop router's CGN instance. This technology - option may limit the CGN placement to the next hop router unless a - second technology option is paired with it to extend connectivity - deeper in the network. - - This option is most effective if CGN instances are placed directly - upstream of the access node. Distributed CGN instance placement is - not likely an initial stage of the CGN deployment due to cost and - demand factors. - -4.4.2. Policy Based Routing +4.4.1. Policy Based Routing Policy Based Routing (PBR) provides another option to direct CGN mediated flows to a translator. PBR options, although possible, are difficult to maintain (static policy) and must be configured throughout the network with considerable maintenance overhead. More centralized deployments may be difficult or too onerous to deploy using Policy Based Routing methods. Policy Based Routing would not achieve route separation (unless used with others options), and may add complexities to the providers' routing environment. -4.4.3. Traffic Engineering +4.4.2. Traffic Engineering Traffic Engineering can also be used to direct traffic from an access node towards a translator. Traffic Engineering, like MPLS-TE, may be difficult to setup and maintain. Traffic Engineering provides additional benefits if used with MPLS by adding potentials for faster path re-convergence. Traffic Engineering paths would need to be updated and redefined overtime as CGN translation points are augmented or moved. -4.4.4. Multiple Routing Topologies +4.4.3. Multiple Routing Topologies 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. 5. Experiences -6. Basic Integration and Requirements Support +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. Key issues which are solved or managed with the MPLS/VPN option include: @@ -645,139 +631,100 @@ - Routing Plane Separation for CGN flows versus traditional IPv4 flows - Flexible Translation Point Design (can relocate translators and split translation zones easily) - Low maintenance overhead (dynamic routing environment with little maintenance of separate routing infrastructure other then management of MPLS/VPNs) - - CGN By-pass options (for internal and third party services which exist within the provider domain) - IPv4 Translation Realm overlap support (can reuse IP addresses 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 -7. Performance +5.2. Performance The MPLS/VPN CGN model was observed to support basic functions which - are typically used by customers within an operator environment. - Examples of successful operation include: - - - Traditional Web (HTTP) Surfing (client initiated) - - - Internet Video Streaming - - - HTTP Based Client Connections - - - High Connection Count sites (i.e. Google Maps) - - - Email Transaction Support (POP, IMAP, SMTP) - - - Instant Messaging Support (Online Status, File transfers, text - chat) - - - ICMP Operation (client initiated Echo, Traceroute) - - - Peer to Peer application support (download) - - DNS (based on services extranet option, but was problematic when - passed through a translator) - - CGNs are still subject to problematic connectivity even within the - MPLS/VPN technology approach. Problems which arise, or are not - inherently addressed in this model include: - - - Inward services from the Internet to the CPE - - - Web session tracking - - - Restricting usage and/or access based on source IP - - - Abuse mitigation (masquerade of potential offenders) - - - Increased network or server IDS false positives - - - Increased customer risk for session hijacking - - - Exceeding firewall TCP/UDP limits - - - Customer identification (external site) - - - Poor source based load balancing - - - Customer usage tracking / Ad insertion - - - Other applications or operations may be negatively impacted + 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]. -8. IANA Considerations +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. -9. Security Considerations +7. Security Considerations The same security considerations would typically exist for CGN deployments when compared with traditional IPv4 based services. With 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. -10. Conclusions +8. Conclusions The MPLS/VPN delivery method for a CGN deployment is an effective and scalable way to deliver mass translation services. The architecture avoids the complex requirements of traffic engineering and policy based routing when combining these new service flows to existing IPv4 operation. This is advantageous since the NAT44/CGN environments should be introduced with as little impact as possible and these environments are expected to change over time. The MPLS/VPN based CGN architecture solves many of this issues related to deploying this technology in existing operator networks. -11. Acknowledgements +9. Acknowledgements Thanks to the following people for their participating in integrating and testing the CGN environment: Chris Metz, Syd Alam, Richard Lawson, John E Spence. Additional thanks for the following people for the guidance on IPv6 transition considerations: John Jason Brzozowski, Chris Donley, Jason Weil, Lee Howard, Jean-Francois Tremblay -12. References +10. References -12.1. Normative References +10.1. Normative References [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. -12.2. Informative References +10.2. Informative References + + [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-06 (work in - progress), May 2012. + (CGNs)", draft-ietf-behave-lsn-requirements-09 (work in + progress), August 2012. [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. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification",