Internet Area WG V. Kuarsingh, Ed. Internet-Draft J. Cianfarani Intended status: Informational Rogers Communications Expires: January 28, 2012 July 27, 2011 NAT44/LSN Deployment Options and Experiences draft-kuarsingh-lsn-deployment-04 Abstract This document specifies NAT44 [RFC3022] with Large Scale NAT [draft-ietf-behave-lsn-requirements-02] integration options along with production model experience. The NAT44/LSN implementation is associated with the NAT444 [draft-shirasaki-nat444-04] model. Service Providers are preparing for IPv4 address depletion by enabling IPv6 and/or extending connectivity for IPv4 to support legacy Internet end points. This document provides practical integration options for Large Scale NAT systems which enable provider NAT44 and is applicable primarily to service providers. The document does not intend to argue the merits of NAT444 versus other IPv4 run out technology options. 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 January 28, 2012. Copyright Notice Copyright (c) 2011 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 Kuarsingh & Cianfarani Expires January 28, 2012 [Page 1] Internet-Draft NAT44/LSN Deployment Options July 2011 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 3. NAT44/LSN Deployment Requirements . . . . . . . . . . . . . . 4 3.1. Centralized vs Distributed Modes . . . . . . . . . . . . . 5 3.2. NAT44/LSN and Traditional IPv4 Service Co-existence . . . 5 3.3. NAT444 By-Pass . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Routing Plane Separation . . . . . . . . . . . . . . . . . 6 3.5. Flexible Deployment Options . . . . . . . . . . . . . . . 6 3.6. IPv4 Overlap Space . . . . . . . . . . . . . . . . . . . . 6 3.7. Transactional Logging for LSN Systems . . . . . . . . . . 7 4. MPLS/VPN based NAT44/LSN Framework . . . . . . . . . . . . . . 7 4.1. Service Separation . . . . . . . . . . . . . . . . . . . . 9 4.2. Internal Service Delivery . . . . . . . . . . . . . . . . 9 4.3. Dual Stack Operation . . . . . . . . . . . . . . . . . . . 10 4.4. Deployment Flexibility . . . . . . . . . . . . . . . . . . 11 4.5. Comparison of MPLS/VPN Option versus other LSN Attachment Options . . . . . . . . . . . . . . . . . . . . 12 4.5.1. IEEE 802.1Q . . . . . . . . . . . . . . . . . . . . . 12 4.5.2. Policy Based Routing . . . . . . . . . . . . . . . . . 12 4.5.3. Traffic Engineering . . . . . . . . . . . . . . . . . 13 4.5.4. Multiple Routing Topologies . . . . . . . . . . . . . 13 5. Experiences . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Basic Integration and Requirements Support . . . . . . . . 13 5.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . . . 18 Kuarsingh & Cianfarani Expires January 28, 2012 [Page 2] Internet-Draft NAT44/LSN Deployment Options July 2011 1. Introduction The majority of service providers are planning on or implementing technologies to mitigate the impact of IPv4 address depletion. Many service providers are planning on implementing a service provider NAT44 infrastructure independently or alongside IPv6. NAT444 [draft-shirasaki-nat444-04] is a technology model which deals with IPv4 address depletion by providing a framework which implements a service provider controlled and administrated NAT44 translation infrastructure. The NAT444 model can be implemented in an incremental fashion to complement the existing IPv4 legacy services. NAT44/LSN can also be implemented as part of an IPv6 (Dual Stack) offering allowing for connectivity to the IPv6 Internet. This document shows how MPLS/VPNs [RFC4364] can be used to provide NAT44/LSN services by solving key problems faced by service providers. Although other integration models may exist, the framework described herein has shown to be successful when tested and characterized in real production models. 2. Motivation Providers may choose to select NAT44/LSN as an initial stage to deal with IPv4 address depletion due to the limited IPv6 technology support in existing end user equipment. Specifically, many devices within the customer premise may not initially support IPv6 or may never support IPv6. Cost, business constraints and other technical reasons may also motivate providers to initially offer NAT44/LSN services. The selection of NAT44/LSN to connect IPv4 endpoints to the IPv4 Internet does not preclude service providers from making IPv6 available to customers. Dual Stack implementations are feasible utilizing both native IPv4 and NAT44/LSN based IPv4 connectivity. IPv6 connectivity can co-exist with NAT44/LSN, including 6RD [RFC5969] deployments, which may utilize private space for IPv4. Initially providing a NAT44/LSN deployment in a dual stack connection model versus other options such as DS-Lite allows providers to ease the burden on networks as services, back office, billing, policy and security systems are migrated to support IPv6 or IPv4/IPv6 tunnelling options. NAT444 based connectivity utilizing Large Scale NAT systems can be evolved in the future once IPv6 has matured within the service provider network and customer environments. Kuarsingh & Cianfarani Expires January 28, 2012 [Page 3] Internet-Draft NAT44/LSN Deployment Options July 2011 3. NAT44/LSN Deployment Requirements If a service provider is considering a NAT44 deployment with Large Scale NAT (NAT44/LSN), there are a number of basic requirements which are of importance. Preliminary requirements may include the NAT44/ LSN system capability to: - Support distributed (sparse) and centralized (dense) Deployment Modes; - Allow co-existence with traditional IPv4 based deployments, which provide global scoped IPs to CPEs; - Provide a framework for NAT by-pass supporting non-translated flows between endpoints within a provider's network; - Provide routing framework which allows the segmentation of routing control and forwarding paths between NAT44/LSN and non-NAT44/LSN mediated flows; - Provide flexibility for providers to modify their deployments over time as translation demands change (connections, bandwidth, translation realms/zones and other vectors); - Flexibility should include integration options for common access technologies such as DSL [BRAS], DOCSIS [CMTS], Mobile [GGSN/PGW/ ASN-GW], and Ethernet access. - Support deployment modes that allow for IPv4 address overlap within the NAT44/LSN provider network (between various translation realms); - Allow for evolution to future dual-stack and IPv4/IPv6 transition deployment modes; - Transactional logging and export capabilities to support auxiliary functions including abuse mitigation; - Support for stateful connection synchronization between translation instances/elements (redundancy) - Support for ISP Shared Space [draft-weil-shared-transition-space-request-02] deployment modes if applicable; - Allows for the enablement of NAT44/LSN functionality (if required) while still minimizing costs and customer impact to the best extend possible; Kuarsingh & Cianfarani Expires January 28, 2012 [Page 4] Internet-Draft NAT44/LSN Deployment Options July 2011 Other requirements may be assessed on a provider-by-provider basis, but those listed above should be considered for any given deployment. 3.1. Centralized vs Distributed Modes Centralized deployments of LSN (longer proximity to end user and/or higher densities of subscribers/connections to LSN instances) differ from distributed deployments of LSN (closer proximity to end user and/or lower densities of subscribers/connections to LSN instances). Service providers will likely deploy LSN translation points more centrally during initial phases. Early deployments will likely 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 providers who already translate most IPv4 traffic and will migrate to a NAT44/LSN implementation from legacy firewalls; or a green field deployment which may see quick growth in the number of new IPv4 endpoints which require Internet connectivity. Over time, most providers will likely need to expand and possibly distribute the translation points as demand for the NAT44/LSN system increases. The extent of the expansion of the NAT44/LSN infrastructure will depend on factors such as growth in the number of IPv4 endpoints, status of IPv6 content on the Internet and the overall progress globally to an IPv6 world. 3.2. NAT44/LSN and Traditional IPv4 Service Co-existence Newer NAT44/LSN serviced endpoints will exist alongside endpoints served by traditional IPv4 global IPs. Providers will need to rationalize these environments since both have distinct forwarding needs. Traditional IPv4 services will likely require (or be best served) with direct forwarding towards Internet peering points while NAT444 mediated flows require access to a translator. The new NAT44/LSN environments should not negatively impact the existing IPv4 service base by forcing all traffic to translation enabled network points since many flows do not require translation. Traffic flow and forwarding efficiency is considered important since networks are under considerable demand to delivery more and more bandwidth without the luxury of needless inefficiencies which can be introduced with NAT44/LSN. 3.3. NAT444 By-Pass The NAT44/LSN environment is only needed for flows with translation requirements. Many flows which remain in a service provider Kuarsingh & Cianfarani Expires January 28, 2012 [Page 5] Internet-Draft NAT44/LSN Deployment Options July 2011 environment, do not require translation. Such services include provider offered DNS Caching, DHCP Services, NTP Services, Web Caching and other services local to the provider network. The provider may want to leverage opportunities to offer third parties a platform to also provide end device services without translation. NAT44/LSN By-pass can be accomplished in many ways, but a simplistic, deterministic and scalable model is preferred. 3.4. Routing Plane Separation Many providers will want to engineer traffic separately for NAT44/LSN flows versus flows which are part of the more traditional IPv4 environment. Many times the routing of these two major flow types differ, therefore routing separation may be required. Routing plane separation also allows the provider to utilize other addressing techniques, which may not be feasible on a single routing plane. Such examples include the use of overlapping private address space [RFC1918] or use of other IPv4 space which may overlap globally (i.e. ISP Shared Space, BOGON Space or others). 3.5. Flexible Deployment Options Service providers operate complex routing environments and offer a variety of IPv4 based services. Many provider environments utilize distributed peering infrastructures for transit and peering and these may span large geographical regions. A NAT44/LSN solution should offer the provider the ability to place LSN translation points at various points within their network. The NAT44/LSN 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 migration 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. Depending on hardware capabilities, security practices and IPv4 address availability, the translation environments my need to be segmented and/or grown over time to meet organic IPv4 demand growth. Providers will want to seek deployment models which are conducive to meeting these goals as well. 3.6. IPv4 Overlap Space IP address overlap for NAT44/LSN translation realms may be required if insufficient IPv4 addresses are available within the service Kuarsingh & Cianfarani Expires January 28, 2012 [Page 6] Internet-Draft NAT44/LSN Deployment Options July 2011 provider environment. The NAT44/LSN deployment should provide mechanisms to enable such an option if required. 3.7. Transactional Logging for LSN Systems NAT44/LSN 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 LSN 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 LSN hardware and/or exported to an external system for processing. Providers may need to keep track of this information (securely) to meet regulatory and/or legal obligations. 4. MPLS/VPN based NAT44/LSN Framework The MPLS/VPN [RFC4364] framework for NAT44/LSN segregates the 'pre- translated' realms within the service provider space into Layer-3 MPLS/VPNs. The provider can deploy a single realm for all NAT44/LSN 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 and routing plane. The MPLS/VPN infrastructure provides control plane and forwarding separation for the traditional IPv4 service environment and NAT44/LSN environment(s). The separation allows for routing information (such as default routes) to be propagated separately for these two major service classes. Traffic can be efficiently routed to the Internet for normal flows, and routed directly to translators for NAT44/LSN mediated flows. Although many providers 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 realm. The physical location of the VRF Termination point and LSN can vary and be located anywhere within the provider's MPLS enabled network. This model fully virtualizes the translation service forwarding from the base IPv4 forwarding environment which will likely carry Internet bound traffic. The base IPv4 environment can continue to service traditional IPv4 customer flows plus post translated NAT44/LSN flows. Figure 1 provides a view of the basic model. The Access node provides CPE access to either the NAT44/LSN VRF or the Global Routing Kuarsingh & Cianfarani Expires January 28, 2012 [Page 7] Internet-Draft NAT44/LSN Deployment Options July 2011 Table, depending on whether the customer receives a private or public IP. Translation mediated traffic follows an MPLS LSP which can be setup dynamically and can span one hop, or many hops (with not 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. Access Node VRF Termination LSN +-----------+ +-----------+ +-----------+ | | | | | | CPE | +-------+ | | +-------+ | | +-------+ | +----+ | | | | LSP | | | | IP | | | | | --+---+-+->VRF--+-+-----+-+->VRF--+-+----+-+-> | | +----+ | | | | | | | | | | | | | +-------+ | | +-------+ | | | | | | | | | | | XLATE | | | | | | | | | | CPE | +-------+ | | +-------+ | | | | | +----+ | | | | | | | | IP | | | | | --+---+-+->GRT | | | | GRT<-+-+----+-+-- | | +----+ | | | | | | | | | | | | | | | +---+---+ | | +---+---+ | | +-------+ | +-----+-----+ +-----+-----+ +-----------+ | | | | IPv4 | | IP +---------+ | +------------+-> | | IP | GRT | +------------------------------+-> | +---------+ Figure 1: Basic MPLS/VPN NAT44/LSN Model If more then one VRF (translation realm) is used within the provider space, each VPN instance can manage NAT44/LSN flows independently for the respective realm. Various redundancy models can be used within this architecture to support failover from one physical LSN hardware instance to another. If state information needs to be passed or maintained between hardware instances, the vendor would need to enable this feature in a suitable manner. Kuarsingh & Cianfarani Expires January 28, 2012 [Page 8] Internet-Draft NAT44/LSN Deployment Options July 2011 4.1. Service Separation The MPLS/VPN NAT44/LSN framework supports route separation. The traditional IPv4 flows can be separated at the access node (Initial Layer 3 service point) from those which require translation. This type of service separation is possible on common technologies used for Internet access within many provider networks. Service separation can be accomplished on common access technology including those used for DOCSIS [CMTS], Ethernet Access, DSL [BRAS], and Mobile Access [GGSN/AGNGW] architectures. 4.2. Internal Service Delivery Internal services can be delivered directly to the privately addressed endpoint within the NAT44/LSN domain without translation. This can be accomplished using direct route exchange (import/export) between the NAT44/LSN VRFs and the Services VRFs. The previous statement assumes the provider puts key services into a VRF for easy routed exchange. This model allows the provider to maintain separate forwarding rules for translated flows, which require a pass through the translator to reach an external network entity, versus those flows which need to access internal services. This operational detail can be advantageous for a number of reasons. First, the provider can reduce the load on the translator since internal services do not need to be factored into the scaling of the LSN hardware. Secondly, more direct forwarding paths can be maintained providing better network efficiency. Thirdly, geographic locations of the translators and the services infrastructure can be deployed in a location independent manner. Additionally, the provider can allow NAT44/LSN endpoints to be accessible via an untranslated path reducing the complexities of provider initiated management flows. This last point is of key interest since NAT44 removes transparency to the end device in normal cases. Figure 2 below shows how internal services are provided untranslated since flows are sent directly from the access node to the services node/VRF via an MPLS LSP. This traffic is not forwarded to the LSN/ translator and therefore is not subject to problematic behaviors related to NAT. The services VRF contains routing information which can be "imported" into the access node VRF and the LSN VRF routing information can be "imported" into the services VRF. Kuarsingh & Cianfarani Expires January 28, 2012 [Page 9] Internet-Draft NAT44/LSN Deployment Options July 2011 Access Node VRF Termination LSN +-------------+ +-----------+ +----------+ | | | | | | CPE | +---------+ | | +-------+ | | +------+ | +-----+ | | | | | | | | | | | | | --+--+-+-> VRF --+-+--+ | | VRF | | | | | | +-----+ | | | | | | | | | | | | | | +---------+ | | | +-------+ | | | | | | | | | | | |XLATE | | | | | | | | | | | CPE | +---------+ | | | +-------+ | | | | | +-----+ | | | | | | | | | | | | | | --+--+-+-> GRT | | | | | GRT | | | | | | +-----+ | | | | | | | | | | | | | | | +----+----+ | | | +-------+ | | +------+ | +------+------+ | +-----------+ +----------+ | | | | IPv4 | | +-----------+ | +---------------+->Services | | | VRF | .-------------------------+-> | | +-----+-----+ | +-----V-----+ | | | Local | | Content | +-----------+ Figure 2: Internal Services and NAT44/LSN By-Pass This demonstrates the ability to offer NAT By-Pass in a simple and deterministic method without the need of policy based routing or traffic engineering. 4.3. Dual Stack Operation The MPLS/VPN NAT44/LSN model can also be used in conjunction with IPv4/IPv6 dual stack service modes. Since many providers will use LSNs on an interim basis while IPv6 matures within the global Internet, a dual stack option is of strategic importance. Providers can offer this dual stack service for both traditional IPv4 (global IP) endpoints and NAT44/LSN mediated endpoints. Providers can separate the IP flows for IPv4 and IPv6 traffic, or use other routing techniques to move IPv6 based flows towards the GRT while allowing IPv4 flows to remain within the IPv4 LSN VRF for Kuarsingh & Cianfarani Expires January 28, 2012 [Page 10] Internet-Draft NAT44/LSN Deployment Options July 2011 translator services. The figure below shows how IPv4 translation services can be provided alongside IPv6 based services. The model shown allows the provider to enable NAT44/LSN to manage IPv4 flows (translated) and IPv6 flows are routed without translation efficiently towards the Internet. Once again, forwarding of flows to the translator does not impact IPv6 flows which do not require this service. Access Node VRF Termination LSN +-----------+ +-----------+ +-----------+ | | | | | | CPE | +-------+ | | +-------+ | | +-------+ | +-----+ | | | |LSP| | | | IP | | | | | --+--+-+->VRF--+-+---+-+->VRF--+-+----+-+> | | |IPv4 | | | | | | | | | | | | | | | | +-------+ | | +-------+ | | | | | +-----| | | | | | | XLATE | | |IPv6 | | | | | | | | | | | | +-------+ | | +-------+ | | | | | | | | | IPv6 | | | | IPv4 | | IP | | | | | --+--+-+->GRT | | | | GRT<-+-+----+-+-- | | +-----+ | | | | | | | | | | | | | | | +---+---+ | | +---+---+ | | +-------+ | +-----+-----+ +-----+-----+ +-----------+ | | | | +-----------+ | | IP | IPv4 | | +----------+-> GRT | | +-----------+ | | | | IP +-----------+ +--------------------------+-> IPv6 | | GRT | +-----------+ Figure 3: NAT44/LSN with IPv6 Dual Stack Operation 4.4. Deployment Flexibility The LSN translator services can be moved, separated or segmented (new translation realms) without the need to change the overall translation design. Since dynamic LSPs are used to forward traffic from the access nodes to the translation points, physical locations of the VRF termination points can vary and be changed easily. Kuarsingh & Cianfarani Expires January 28, 2012 [Page 11] Internet-Draft NAT44/LSN Deployment Options July 2011 This type of flexibility allows the service provider to initially deploy more centralized translation services based on relatively low loading factors, and distribute the translation points over time to improve network traffic efficiencies and support higher translation load. Although traffic engineered paths are not required within the MPLS/ VPN deployment model, nothing precludes a service provider from using technologies like MPLS with Traffic Engineering [RFC3031]. Additional routing mechanisms can be used as desired by the provider and can be seen as independent. There is not specific need to diversify the existing infrastructure in most cases. 4.5. Comparison of MPLS/VPN Option versus other LSN Attachment Options Other integration architecture options exist which can attach NAT44/ LSN 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.5.1. IEEE 802.1Q IEEE 802.1Q can be used to associate separated traffic from the access node to the next hop router's LSN instance. This technology option may limit the LSN placement to the next hop router unless a second technology option is paired with it to extend connectivity further in the network. This option is most effective if LSN instances are placed directly upstream of the access node. Distributed LSN instance placement is not likely an initial stage of the NAT44/LSN deployment due to cost and demand factors. 4.5.2. Policy Based Routing Policy Based Routing (Static Routing) provides another option to direct NAT44/LSN 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. Kuarsingh & Cianfarani Expires January 28, 2012 [Page 12] Internet-Draft NAT44/LSN Deployment Options July 2011 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.5.3. Traffic Engineering Traffic Engineering can also be used to direct traffic from an access node towards a translator. Traffic Engineering, like PBR, 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 LSN translation points are augmented or moved. 4.5.4. Multiple Routing Topologies Multiple routing topologies can be used to direct NAT44/LSN based flows to translators. This option would achieve the same basic goal as the MPLS/VPN option but with additional implementation overhead. Since provider based translation is expected to have an unknown lifecycle, and may see various degrees of demand (dependant on providers 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 NAT44/LSN. 5. Experiences 5.1. Basic Integration and Requirements Support The MPLS/VPN NAT44/LSN environment has been successfully integrated into real network environments utilizing existing network service delivery mechanisms. It appears to solve many issues related to provider based translation environments, while still subject to problematic behaviors inherent within NAT44 (and by extension NAT444). Key issues which are solved or managed with the MPLS/VPN option include: - Centralized and Distributed Deployment model support - Routing Plane Separation for NAT44/LSN flows versus traditional IPv4 flows - Flexible Translation Point Design (can relocate translators and split translation zones easily) Kuarsingh & Cianfarani Expires January 28, 2012 [Page 13] Internet-Draft NAT44/LSN Deployment Options July 2011 - Low maintenance overhead (dynamic routing environment with little maintenance of separate routing infrastructure other then management of MPLS/VPNs) - NAT44 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 5.2. Performance The MPLS/VPN NAT44/LSN model was observed to support basic functions which are typically used by customers within a service provider 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 (mention Bit Torrent?) - DNS (based on services extranet option, but was problematic when passed through a translator) NAT44/LSNs 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 Kuarsingh & Cianfarani Expires January 28, 2012 [Page 14] Internet-Draft NAT44/LSN Deployment Options July 2011 - 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 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 The same security considerations would typically exist for NAT44/LSN deployments when compared with traditional IPv4 based services. If a provider plans to operation 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. 8. Conclusions The MPLS/VPN delivery method for NAT44/LSN is an effective and scalable way to delivery mass translation services. The architecture avoids the complex requirements of traffic engineering and policy based routing. This is advantageous since the NAT44/LSN environment is expected to change over time and will potentially migrate to more progressive dual stack environments like DS-Lite over time. The architecture solves many of this issues related to NAT444 as an overall translation model which are of concern to large Service Providers. Kuarsingh & Cianfarani Expires January 28, 2012 [Page 15] Internet-Draft NAT44/LSN Deployment Options July 2011 9. Acknowledgements Thanks to the following people for their participating in integrating and testing the NAT44/LSN 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 10. References 10.1. Normative References [I-D.ietf-behave-lsn-requirements] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for Carrier Grade NAT (CGN)", draft-ietf-behave-lsn-requirements-02 (work in progress), July 2011. [I-D.shirasaki-nat444] Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., and H. Ashida, "NAT444", draft-shirasaki-nat444-04 (work in progress), July 2011. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. 10.2. Informative References [I-D.weil-shared-transition-space-request] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA Reserved IPv4 Prefix for Shared Transition Space", draft-weil-shared-transition-space-request-02 (work in progress), July 2011. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. Kuarsingh & Cianfarani Expires January 28, 2012 [Page 16] Internet-Draft NAT44/LSN Deployment Options July 2011 [RFC2881] Mitton, D. and M. Beadles, "Network Access Server Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, July 2000. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002. [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008. [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011. [RFC6319] Azinger, M. and L. Vegoda, "Issues Associated with Kuarsingh & Cianfarani Expires January 28, 2012 [Page 17] Internet-Draft NAT44/LSN Deployment Options July 2011 Designating Additional Private IPv4 Address Space", RFC 6319, July 2011. Authors' Addresses Victor Kuarsingh (editor) Rogers Communications 8200 Dixie Road Brampton, Ontario L6T 0C1 Canada Email: victor.kuarsingh@rci.rogers.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 Kuarsingh & Cianfarani Expires January 28, 2012 [Page 18]