idnits 2.17.1 draft-ietf-opsawg-lsn-deployment-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 18, 2013) is 4082 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-donley-behave-deterministic-cgn-05 == Outdated reference: A later version (-06) exists of draft-donley-nat444-impacts-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG V. Kuarsingh, Ed. 3 Internet-Draft J. Cianfarani 4 Intended status: Informational Rogers Communications 5 Expires: August 22, 2013 February 18, 2013 7 CGN Deployment with BGP/MPLS IP VPNs 8 draft-ietf-opsawg-lsn-deployment-02 10 Abstract 12 This document specifies a framework to integrate a Network Address 13 Translation layer into an operator's network to function as a Carrier 14 Grade NAT (also known as CGN or Large Scale NAT). The CGN 15 infrastructure will often form a NAT444 environment as the subscriber 16 home network will likely also maintain a subscriber side NAT 17 function. Exhaustion of the IPv4 address pool is a major driver 18 compelling some operators to implement CGN. Although operators may 19 wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near 20 term needs may not be satisfied with an IPv6 deployment alone. This 21 document provides a practical integration model which allows the CGN 22 platform to be integrated into the network meeting the connectivity 23 needs of the subscriber while being mindful of not disrupting 24 existing services and meeting the technical challenges that CGN 25 brings. The model included in this document utilizes BGP/MPLS IP 26 VPNs which allow for virtual routing separation helping ease the CGNs 27 impact on the network. This document does not intend to defend the 28 merits of CGN. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 22, 2013. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. CGN Network Deployment Requirements . . . . . . . . . . . . . 4 66 3.1. Centralized versus Distributed Deployment . . . . . . . . 5 67 3.2. CGN and Traditional IPv4 Service Co-existence . . . . . . 6 68 3.3. CGN By-Pass . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.4. Routing Plane Separation . . . . . . . . . . . . . . . . . 6 70 3.5. Flexible Deployment Options . . . . . . . . . . . . . . . 7 71 3.6. IPv4 Overlap Space . . . . . . . . . . . . . . . . . . . . 7 72 3.7. Transactional Logging for LSN Systems . . . . . . . . . . 7 73 3.8. Additional CGN Requirements . . . . . . . . . . . . . . . 8 74 4. BGP/MPLS IP VPN based CGN Framework . . . . . . . . . . . . . 8 75 4.1. Service Separation . . . . . . . . . . . . . . . . . . . . 10 76 4.2. Internal Service Delivery . . . . . . . . . . . . . . . . 10 77 4.2.1. Dual Stack Operation . . . . . . . . . . . . . . . . . 12 78 4.3. Deployment Flexibility . . . . . . . . . . . . . . . . . . 14 79 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN 80 Attachment Options . . . . . . . . . . . . . . . . . . . . 14 81 4.4.1. Policy Based Routing . . . . . . . . . . . . . . . . . 14 82 4.4.2. Traffic Engineering . . . . . . . . . . . . . . . . . 15 83 4.4.3. Multiple Routing Topologies . . . . . . . . . . . . . 15 84 5. Experiences . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 5.1. Basic Integration and Requirements Support . . . . . . . . 15 86 5.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 16 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 89 8. BGP/MPLS IP VPN CGN Framework Discussion . . . . . . . . . . . 16 90 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 93 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 96 1. Introduction 98 Operators are faced with near term IPv4 address exhaustion 99 challenges. Many operators may not have a sufficient amount of IPv4 100 addresses in the future to satisfy the needs of their growing 101 subscriber base. This challenge may also be present before or during 102 an active transition to IPv6 somewhat complicating the overall 103 problem space. 105 To face this challenge, operators may need to deploy CGN (Carrier 106 Grade NAT) as described in [I-D.ietf-behave-lsn-requirements] to help 107 extend the connectivity matrix once IPv4 addresses caches run out on 108 the local local operator. CGN deployments will most often be added 109 into operator networks which already have active IPv4 and/or IPv6 110 services. 112 The addition of the CGN introduces an operator controlled and 113 administered translation layer which should be added in a manner 114 which minimizes disruption to existing services. The CGN system 115 addition may also include interworking in a dual stack environment 116 where the IPv4 path requires translation. 118 This document shows how BGP/MPLS IP VPNs as described in [RFC4364] 119 can be used to integrate the CGN infrastructure solving key 120 integration challenges faced by the operator. This model has also 121 been tested and validated in real production network models and 122 allows fluid operation with existing IPv4 and IPv6 services. 124 2. Motivation 126 The selection of CGN may be made by an operator based on a number of 127 factors. The overall driver may be the depletion of IPv4 address 128 pools which leaves little to no addresses for IPv4 service or 129 connection demand growth. IPv6 is considered the strategic answer, 130 but it's applicability and usefulness in many networks is limited by 131 the current access network and consumer home network. Customer 132 environments often are filled with IPv4-Only equipment which may not 133 be upgradable to IPv6. 135 The ability to replace IPv4-Only equipment may be out of the control 136 of the operator, and even when it's in the administrative control; it 137 poses both cost and technical challenges as operators build out 138 massive programs for equipment retirement or upgrade. These issues 139 leave an operator in a precarious position which may lead to the 140 decision to deploy CGN. Other address IPv4 sharing options do exist 141 which are more architecturally desirable, but the practical and 142 workable approach in many cases is a CGN deployment using the NAT444 143 framework. 145 If the operator has chosen to deploy CGN, they should do this in a 146 manner as not to negatively impact the existing IPv4 or IPv6 147 subscriber base. This will include solving a number of challenges 148 since subscribers who's connections require translation will have 149 network routing and flow needs which are different from legacy IPv4 150 connections. 152 The solution will also need to work in a dual stack environment where 153 other options such as DS-Lite [RFC6333] are not yet viable. Even 154 technologies like 6RD [RFC5969] still require an IPv4 connectivity 155 path to service the subscriber endpoint. The solution will need to 156 address basic Internet connectivity, on-net service offerings, back 157 office management, billing, policy and security models already in 158 place within the operator's network. CGN will often integrate quite 159 readily with the aforementioned requirements where as other 160 transition mechanism may not due to the requirements to support IPv6 161 as the base protocol for IPv4 connectivity. 163 3. CGN Network Deployment Requirements 165 If a service provider is considering a CGN deployment with a provider 166 NAT44 function, there are a number of basic architectural 167 requirements which are of importance. Preliminary architectural 168 requirements may require all or some of the following from the 169 incoming CGN system: 171 - Support distributed (sparse) and centralized (dense) deployment 172 models; 174 - Allow co-existence with traditional IPv4 based deployments, 175 which provide global scoped IPv4 addresses to CPEs; 177 - Provide a framework for CGN by-pass supporting non-translated 178 flows between endpoints within a provider's network; 180 - Provide a routing framework which allows the segmentation of 181 routing control and forwarding paths between CGN and non-CGN 182 mediated flows; 184 - Provide flexibility for operators to modify their deployments 185 over time as translation demands change (connections, bandwidth, 186 translation realms/zones and other vectors); 188 - Flexibility should include integration options for common access 189 technologies such as DSL (BRAS), DOCSIS (CMTS), Mobile (GGSN/PGW/ 190 ASN-GW), and direct Ethernet; 192 - Support deployment modes that allow for IPv4 address overlap 193 within the operator's network (between various translation realms 194 or zones); 196 - Allow for evolution to future dual-stack and IPv4/IPv6 197 transition deployment modes; 199 - Transactional logging and export capabilities to support 200 auxiliary functions including abuse mitigation; 202 - Support for stateful connection synchronization between 203 translation instances/elements (redundancy); 205 - Support for CGN Shared Space [RFC6598] deployment modes if 206 applicable; 208 - Allows for the enablement of CGN functionality (if required) 209 while still minimizing costs and subscriber impact to the best 210 extend possible; 212 Other requirements may be assessed on a operator-by-operator basis, 213 but those listed above may be considered for any given deployment 214 architecture. 216 3.1. Centralized versus Distributed Deployment 218 Centralized deployments of CGN (longer proximity to end user and/or 219 higher densities of subscribers/connections to CGN instances) differ 220 from distributed deployments of CGN (closer proximity to end user 221 and/or lower densities of subscribers/connections to CGN instances). 222 Service providers may likely deploy CGN translation points more 223 centrally during initial phases if the early system demand is low. 224 Early deployments may see light loading on these new systems since 225 legacy IPv4 services will continue to operate with most endpoints 226 using globally unique IPv4 addresses. Exceptional cases which may 227 drive heavy usage in initial stages may include operators who already 228 translate a significant portion of their IPv4 traffic; may transition 229 to a CGN implementation from legacy translation mechanisms (i.e. 230 traditional firewalls); or build a green field deployment which may 231 see quick growth in the number of new IPv4 endpoints which require 232 Internet connectivity. 234 Over time, some providers may need to expand and possibly distribute 235 the translation points if demand for the CGN system increases. The 236 extent of the expansion of the CGN infrastructure will depend on 237 factors such as growth in the number of IPv4 endpoints, status of 238 IPv6 content on the Internet and the overall progress globally to an 239 IPv6-dominate Internet (reducing the demand for IPv4 connectivity). 240 The overall demand for CGN resources will probably follow a bell-like 241 curve with a growth, peak and decline period. 243 3.2. CGN and Traditional IPv4 Service Co-existence 245 Newer CGN serviced endpoints will exist alongside endpoints served by 246 traditional IPv4 globally routed IPv4 addresses. Operators will need 247 to rationalize these environments since both have distinct forwarding 248 needs. Traditional IPv4 services will likely require (or be best 249 served) direct forwarding towards Internet peering points while CGN 250 mediated flows require access to a translator. CGN and non-CGN 251 mediated flows pose two fundamentally different forwarding needs. 253 The new CGN environments should not negatively impact the existing 254 IPv4 service base by forcing all traffic to translation enabled 255 network points since many flows do not require translation and this 256 would reduce performance of the existing flows. This would also 257 require massive scaling of the CGN which is a cost and efficiency 258 concern as well. 260 Traffic flow and forwarding efficiency is considered important since 261 networks are under considerable demand to deliver more and more 262 bandwidth without the luxury of needless inefficiencies which can be 263 introduced with CGN. 265 3.3. CGN By-Pass 267 The CGN environment is only needed for flows with translation 268 requirements. Many flows which remain within the operator's network, 269 do not require translation. Such services include operator offered 270 DNS Services, DHCP Services, NTP Services, Web Caching, E-Mail, News 271 and other services which are local to the operator's network. 273 The operator may want to leverage opportunities to offer third 274 parties a platform to also provide services without translation. CGN 275 By-pass can be accomplished in many ways, but a simplistic, 276 deterministic and scalable model is preferred. 278 3.4. Routing Plane Separation 280 Many operators will want to engineer traffic separately for CGN flows 281 versus flows which are part of the more traditional IPv4 environment. 282 Many times the routing of these two major flow types differ, 283 therefore route separation may be required. 285 Routing plane separation also allows the operator to utilize other 286 addressing techniques, which may not be feasible on a single routing 287 plane. Such examples include the use of overlapping private address 288 space [RFC1918], Shared Address Space [RFC6598] or use of other IPv4 289 space which may overlap globally within the operator's network. 291 3.5. Flexible Deployment Options 293 Service providers operate complex routing environments and offer a 294 variety of IPv4 based services. Many operator environments utilize 295 distributed peering infrastructures for transit and peering and these 296 may span large geographical areas and regions. A CGN solution should 297 offer the operator an ability to place CGN translation points at 298 various points within their network. 300 The CGN deployment should also be flexible enough to change over time 301 as demand for translation services increase or change as noted in 302 [RFC6264]. In turn, the deployment will need to then adapt as 303 translation demand decreases caused by the transition of flows to 304 IPv6. Translation points should be able to be placed and moved with 305 as little re-engineering effort as possible minimizing the risks to 306 the subscriber base. 308 Depending on hardware capabilities, security practices and IPv4 309 address availability, the translation environments my need to be 310 segmented and/or scaled over time to meet organic IPv4 demand growth. 311 Operators may also want to choose models that support transition to 312 other translation environments such as DS-Lite [RFC6333] and/or NAT64 313 [RFC6146]. Operators will want to seek deployment models which are 314 conducive to meeting these goals as well. 316 3.6. IPv4 Overlap Space 318 IPv4 address overlap for CGN translation realms may be required if 319 insufficient IPv4 addresses are available within the operator 320 environment to assign internally unique IPv4 addresses to the CGN 321 subscriber base . The CGN deployment should provide mechanisms to 322 manage IPv4 overlap if required. 324 3.7. Transactional Logging for LSN Systems 326 CGNs may require transactional logging since the source IP and 327 related transport protocol information is not easily visible to 328 external hosts and system. 330 If needed, the CGN systems should be able to generate logs which 331 identify 'internal' host parameters (i.e. IP/Port) and associated 332 them to external translated parameters imposed by the translator. 333 The logged information should be stored on the CGN hardware and/or 334 exported to an external system for processing. The operator may 335 choose to also enable mechanisms to help reduce logging such as block 336 allocation of UDP and TCP ports or deterministic translation options 337 such as [I-D.donley-behave-deterministic-cgn]. 339 Operators may need to keep track of this information (securely) to 340 meet regulatory and/or legal obligations. Further information can be 341 found in [I-D.ietf-behave-lsn-requirements] with respect to CGN 342 logging requirements (Logging Section). 344 3.8. Additional CGN Requirements 346 The CGN platform will also need to meet the needs of additional 347 requirements such as Bulk Port Allocation and other CGN device 348 specific functions. These additional requirements are captured 349 within [I-D.ietf-behave-lsn-requirements]. 351 4. BGP/MPLS IP VPN based CGN Framework 353 The BGP/MPLS IP VPN [RFC4364] framework for CGN segregates the 'pre- 354 translated' realms within the service provider space into Layer-3 355 MPLS based VPNs. The operator can deploy a single realm for all CGN 356 based flows, or can deploy multiple realms based on translation 357 demand and other factors such as geographical proximity. A realm in 358 this model refers to a 'VPN' which shares a unique Route 359 Distinguisher/Route Target (RD/RT) combination, routing plane and 360 forwarding behaviours. 362 The BGP/MPLS IP VPN infrastructure provides control plane and 363 forwarding separation for the traditional IPv4 service environment 364 and CGN environment(s). The separation allows for routing 365 information (such as default routes) to be propagated separately for 366 CGN and non-CGN based subscriber flows. Traffic can be efficiently 367 routed to the Internet for normal flows, and routed directly to 368 translators for CGN mediated flows. Although many operators may run 369 a "default-route-free" core, IPv4 flows which require translation 370 must obviously be routed first to a translator, so a default route is 371 acceptable for the pre-translated realms. 373 The physical location of the Virtual Routing and Forwarding (VRF) 374 Termination point for a BGP/MPLS IP VPN enabled CGN can vary and be 375 located anywhere within the operator's network. This model fully 376 virtualizes the translation service from the base IPv4 forwarding 377 environment which will likely be carrying Internet bound traffic. 378 The base IPv4 environment can continue to service traditional IPv4 379 subscriber flows plus post translated CGN flows. 381 Figure 1 provides a view of the basic model. The Access node 382 provides CPE access to either the CGN VRF or the Global Routing 383 Table, depending on whether the subscriber receives a private or 384 public IP. Translator mediated traffic follows an MPLS Label- 385 switched Path (LSP) which can be setup dynamically and can span one 386 hop, or many hops (with no need for complex routing policies). 387 Traffic is then forwarded to the translator (shown below) which can 388 be an external appliance or integrated into the VRF Termination 389 (Provider Edge) router. Once traffic is translated, it is forwarded 390 to the global routing table for general Internet forwarding. The 391 Global Routing table can also be a separate VRF (Internet Access VPN/ 392 VRF) should the provider choose to implement their Internet based 393 services in that fashion. The translation services are effectively 394 overlaid onto the network, but are maintained within a separate 395 forwarding and control plane. 397 Access Node VRF Termination CGN 398 +-----------+ +-----------+ +-----------+ 399 | | | | | | 400 CPE | +-------+ | | +-------+ | | +-------+ | 401 +----+ | | | | LSP | | | | IP | | | | 402 | --+---+-+->VRF--+-+-----+-+->VRF--+-+----+-+-> | | 403 +----+ | | | | | | | | | | | | 404 | +-------+ | | +-------+ | | | | | 405 | | | | | | XLATE | | 406 | | | | | | | | 407 CPE | +-------+ | | +-------+ | | | | | 408 +----+ | | | | | | | | IP | | | | 409 | --+---+-+->GRT | | | | GRT<-+-+----+-+-- | | 410 +----+ | | | | | | | | | | | | | | 411 | +---+---+ | | +---+---+ | | +-------+ | 412 +-----+-----+ +-----+-----+ +-----------+ 413 | | 414 | | IPv4 415 | | IP +---------+ 416 | +------------+-> | 417 | IP | GRT | 418 +------------------------------+-> | 419 +---------+ 421 Figure 1: Basic BGP/MPLS IP VPN CGN Model 423 If more then one VRF (translation realm) is used within the 424 operator's network, each VPN instance can manage CGN flows 425 independently for the respective realm. Various redundancy models 426 can be used within this architecture to support failover from one 427 physical CGN hardware instance to another. If state information 428 needs to be passed or maintained between hardware instances, the 429 vendor would need to enable this feature in a suitable manner. 431 4.1. Service Separation 433 The MPLS/VPN CGN framework supports route separation. The 434 traditional IPv4 flows can be separated at the access node (Initial 435 Layer 3 service point) from those which require translation. This 436 type of service separation is possible on common technologies used 437 for Internet access within many operator networks. Service 438 separation can be accomplished on common access technology including 439 those used for DOCSIS (CMTS), Ethernet Access, DSL (BRAS), and Mobile 440 Access (GGSN/ASN-GW) architectures. 442 4.2. Internal Service Delivery 444 Internal services can be delivered directly to the privately 445 addressed endpoint within the CGN domain without translation. This 446 can be accomplished in one of two methods. The first method may 447 include reducing the overall number of VRFs in the system and 448 exposing services in the GRT along with a method of exchanging routes 449 between the CGN VRF and GRT called route leaking. The second method, 450 which is described in detail within this section is the use of a 451 Services VRF. The second model is a more traditional extranet 452 services model, but requires more system resources to implement. 454 Using direct route exchange (import/export) between the CGN VRFs and 455 the Services VRFs creates reachablity using the aforementioned 456 extranet model available in the BGP/MPLS IP VPN structure. This 457 model allows the provider to maintain separate forwarding rules for 458 translated flows, which require a pass through the translator to 459 reach external network entities, versus those flows which need to 460 access internal services. This operational detail can be 461 advantageous for a number of reasons such as service access policies 462 and endpoint identification. 464 First, the provider can reduce the load on the translator since 465 internal services do not need to be factored into the scaling of the 466 CGN hardware (which may be quite large). Secondly, more direct 467 forwarding paths can be maintained providing better network 468 efficiency. Thirdly, geographic locations of the translators and the 469 services infrastructure can be deployed in locations in an 470 independent manner. Additionally, the operator can allow CGN subject 471 endpoints to be accessible via an untranslated path reducing the 472 complexities of provider initiated management flows. This last point 473 is of key interest since NAT removes transparency to the end device 474 in normal cases. 476 Figure 2 below shows how internal services are provided untranslated 477 since flows are sent directly from the access node to the services 478 node/VRF via an MPLS LSP. This traffic is not forwarded to the CGN 479 translator and therefore is not subject to problematic behaviours 480 related to NAT. The services VRF contains routing information which 481 can be "imported" into the access node VRF and the CGN VRF routing 482 information can be "imported" into the Services VRF. 484 Access Node VRF Termination CGN 485 +-------------+ +-----------+ +----------+ 486 | | | | | | 487 CPE | +---------+ | | +-------+ | | +------+ | 488 +-----+ | | | | | | | | | | | | 489 | --+--+-+-> VRF --+-+--+ | | VRF | | | | | | 490 +-----+ | | | | | | | | | | | | | 491 | +---------+ | | | +-------+ | | | | | 492 | | | | | | |XLATE | | 493 | | | | | | | | | 494 CPE | +---------+ | | | +-------+ | | | | | 495 +-----+ | | | | | | | | | | | | | 496 | --+--+-+-> GRT | | | | | GRT | | | | | | 497 +-----+ | | | | | | | | | | | | | | 498 | +----+----+ | | | +-------+ | | +------+ | 499 +------+------+ | +-----------+ +----------+ 500 | | 501 | | IPv4 502 | | +-----------+ 503 | +---------------+->Services | 504 | | VRF | 505 .-------------------------+-> | | 506 +-----+-----+ 507 | 508 +-----V-----+ 509 | | 510 | Local | 511 | Content | 512 +-----------+ 514 Figure 2: Internal Services and CGN By-Pass 516 An extension to the services delivery LSP is the ability to also 517 provide direct subscriber to subscriber traffic flows between CGN 518 zones. Each zone or realm may be fitted with separate CGN resources, 519 but the subtending subscribers don't necessarily need to be mediated 520 (translated) by the CGN translators. This option, as shown in Figure 521 3 below, is easy to implement and can only be enabled if no IPv4 522 address overlap is used between communicating CGN zones. 523 Access Node-1 VRF Termination CGN-1 524 +-------------+ +-----------+ +----------+ 525 | | | | | | 526 CPE-1 | +---------+ | | +-------+ | | +------+ | 527 +-----+ | | | | | | | | | | | | 528 | --+--+-+- VRF --+-+-+ | | VRF | | | | | | 529 +-----+ | | | | | | | | | | | | | 530 | +---------+ | | | +-------+ | | | | | 531 | | | | | | |XLATE | | 532 | | | | | | | | | 533 CPE-2 | +---------+ | | | +-------+ | | | | | 534 +-----+ | | | | | | | | | | | | | 535 | --+--+-+- GRT | | | | | GRT | | | | | | 536 +-----+ | | | | | | | | | | | | | 537 | +---------+ | | | +-------+ | | +------+ | 538 +-------------+ | +-----------+ +----------+ 539 | 540 LSP | 541 | 542 Access Node-2 | VRF Termination CGN-2 543 +-------------+ | +-----------+ +----------+ 544 | | | | | | | 545 CPE-3 | +---------+ | | | +-------+ | | +------+ | 546 +-----+ | | | | | | | | | | | | | 547 | --+--+-+-- VRF --+-+-+ | | VRF | | | | | | 548 +-----+ | | | | | | | | | | | | 549 | +---------+ | | +-------+ | | | | | 550 | | | | | |XLATE | | 551 | | | | | | | | 552 CPE-4 | +---------+ | | +-------+ | | | | | 553 +-----+ | | | | | | | | | | | | 554 | --+--+-+- GRT | | | | GRT | | | | | | 555 +-----+ | | | | | | | | | | | | 556 | +---------+ | | +-------+ | | +------+ | 557 +-------------+ +-----------+ +----------+ 559 The inherent capabilities of the BGP/MPLS IP VPN model demonstrates 560 the ability to offer CGN By-Pass in a standard and deterministic 561 manner without the need of policy based routing or traffic 562 engineering. 564 4.2.1. Dual Stack Operation 566 The BGP/MPLS IP VPN CGN model can also be used in conjunction with 567 IPv4/IPv6 dual stack service modes. Since many providers will use 568 CGNs on an interim basis while IPv6 matures within the global 569 Internet or due to technical constraints, a dual stack option is of 570 strategic importance. Operators can offer this dual stack service 571 for both traditional IPv4 (global IP) endpoints and CGN mediated 572 endpoints. 574 Operators can separate the IP flows for IPv4 and IPv6 traffic, or use 575 other routing techniques to move IPv6 based flows towards the GRT 576 (Global Routing Table or Instance) while allowing IPv4 flows to 577 remain within the IPv4 CGN VRF for translator services. 579 The Figure 4 below shows how IPv4 translation services can be 580 provided alongside IPv6 based services. The model shown allows the 581 provider to enable CGN to manage IPv4 flows (translated) and IPv6 582 flows are routed without translation efficiently towards the 583 Internet. Once again, forwarding of flows to the translator does not 584 impact IPv6 flows which do not require this service. 586 Access Node VRF Termination CGN 587 +-----------+ +-----------+ +-----------+ 588 | | | | | | 589 CPE | +-------+ | | +-------+ | | +-------+ | 590 +-----+ | | | |LSP| | | | IP | | | | 591 | --+--+-+->VRF--+-+---+-+->VRF--+-+----+-+> | | 592 |IPv4 | | | | | | | | | | | | | 593 | | | +-------+ | | +-------+ | | | | | 594 +-----| | | | | | | XLATE | | 595 |IPv6 | | | | | | | | | 596 | | | +-------+ | | +-------+ | | | | | 597 | | | | IPv6 | | | | IPv4 | | IP | | | | 598 | --+--+-+->GRT | | | | GRT<-+-+----+-+-- | | 599 +-----+ | | | | | | | | | | | | | | 600 | +---+---+ | | +---+---+ | | +-------+ | 601 +-----+-----+ +-----+-----+ +-----------+ 602 | | 603 | | +-----------+ 604 | | IP | IPv4 | 605 | +----------+-> GRT | 606 | +-----------+ 607 | 608 | 609 | 610 | IP +-----------+ 611 +--------------------------+-> IPv6 | 612 | GRT | 613 +-----------+ 615 Figure 4: CGN with IPv6 Dual Stack Operation 617 4.3. Deployment Flexibility 619 The CGN translator services can be moved, separated or segmented (new 620 translation realms) without the need to change the overall 621 translation design. Since dynamic LSPs are used to forward traffic 622 from the access nodes to the translation points, the physical 623 location of the VRF termination points can vary and be changed 624 easily. 626 This type of flexibility allows the service provider to initially 627 deploy more centralized translation services based on relatively low 628 loading factors, and distribute the translation points over time to 629 improve network traffic efficiencies and support higher translation 630 load. 632 Although traffic engineered paths are not required within the MPLS/ 633 VPN deployment model, nothing precludes an operator from using 634 technologies like MPLS with Traffic Engineering [RFC3031]. 635 Additional routing mechanisms can be used as desired by the provider 636 and can be seen as independent. There is no specific need to 637 diversify the existing infrastructure in most cases. 639 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN Attachment 640 Options 642 Other integration architecture options exist which can attach CGN 643 based service flows to a translator instance. Alternate options 644 which can be used to attach such services include: 646 - Policy Based Routing (Static) to direct translation bound 647 traffic to a network based translator; 649 - Traffic Engineering or; 651 - Multiple Routing Topologies 653 4.4.1. Policy Based Routing 655 Policy Based Routing (PBR) provides another option to direct CGN 656 mediated flows to a translator. PBR options, although possible, are 657 difficult to maintain (static policy) and must be configured 658 throughout the network with considerable maintenance overhead. 660 More centralized deployments may be difficult or too onerous to 661 deploy using Policy Based Routing methods. Policy Based Routing 662 would not achieve route separation (unless used with others options), 663 and may add complexities to the providers' routing environment. 665 4.4.2. Traffic Engineering 667 Traffic Engineering can also be used to direct traffic from an access 668 node towards a translator. Traffic Engineering, like MPLS-TE, may be 669 difficult to setup and maintain. Traffic Engineering provides 670 additional benefits if used with MPLS by adding potentials for faster 671 path re-convergence. Traffic Engineering paths would need to be 672 updated and redefined overtime as CGN translation points are 673 augmented or moved. 675 4.4.3. Multiple Routing Topologies 677 Multiple routing topologies can be used to direct CGN based flows to 678 translators. This option would achieve the same basic goal as the 679 MPLS/VPN option but with additional implementation overhead and 680 platform configuration complexity. Since operator based translation 681 is expected to have an unknown lifecycle, and may see various degrees 682 of demand (dependant on operator IPv4 Global space availability and 683 shift of traffic to IPv6), it may be too large of an undertaking for 684 the provider to enabled this as their primary option for CGN. 686 5. Experiences 688 5.1. Basic Integration and Requirements Support 690 The MPLS/VPN CGN environment has been successfully integrated into 691 real network environments utilizing existing network service delivery 692 mechanisms. It solves many issues related to provider based 693 translation environments, while still subject to problematic 694 behaviours inherent within NAT. 696 Key issues which are solved or managed with the MPLS/VPN option 697 include: 699 - Centralized and Distributed Deployment model support 701 - Routing Plane Separation for CGN flows versus traditional IPv4 702 flows 704 - Flexible Translation Point Design (can relocate translators and 705 split translation zones easily) 707 - Low maintenance overhead (dynamic routing environment with 708 little maintenance of separate routing infrastructure other then 709 management of MPLS/VPNs) 710 - CGN By-pass options (for internal and third party services which 711 exist within the provider domain) 713 - IPv4 Translation Realm overlap support (can reuse IP addresses 714 between zones with some impact to extranet service model) 716 - Simple failover techniques can be implemented with redundant 717 translators, such as using a second default route 719 5.2. Performance 721 The MPLS/VPN CGN model was observed to support basic functions which 722 are typically used by subscribes within an operator environment. A 723 full review of the observed impacts related to CGN (NAT444) are 724 covered in [I-D.donley-nat444-impacts]. 726 6. IANA Considerations 728 There are not specific IANA considerations known at this time with 729 the architecture described herein. Should a provide choose to use 730 non-assigned IP address space within their translation realms, then 731 considerations may apply. 733 7. Security Considerations 735 The same security considerations would typically exist for CGN 736 deployments when compared with traditional IPv4 based services. With 737 the MPLS/VPN model, the operator would want to consider security 738 issues related to offering IP services over MPLS. 740 If a provider plans to operate the pre-translation realm (CPE towards 741 translator IPv4 zone) as a non-public like network, then additional 742 security measures may be needed to secure this environment. It is 743 however the position in this document that CGN realms are public 744 domains which utilize non-Internet routable IP addresses for endpoint 745 addressing. 747 8. BGP/MPLS IP VPN CGN Framework Discussion 749 The MPLS/VPN delivery method for a CGN deployment is an effective and 750 scalable way to deliver mass translation services. The architecture 751 avoids the complex requirements of traffic engineering and policy 752 based routing when combining these new service flows to existing IPv4 753 operation. This is advantageous since the NAT44/CGN environments 754 should be introduced with as little impact as possible and these 755 environments are expected to change over time. 757 The MPLS/VPN based CGN architecture solves many of this issues 758 related to deploying this technology in existing operator networks. 760 9. Acknowledgements 762 Thanks to the following people for their comments and feedback: Dan 763 Wing, Chris Metz, Chris Donley, Tina TSOU, Christophoer Liljenstolpe 764 and Tom Taylor. 766 Thanks to the following people for their participating in integrating 767 and testing the CGN environment and for their IPv6 transition 768 guidance: Syd Alam, Richard Lawson, John E Spence, John Jason 769 Brzozowski, Chris Donley, Jason Weil, Lee Howard, Jean-Francois 770 Tremblay 772 10. References 774 10.1. Normative References 776 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 777 Networks (VPNs)", RFC 4364, February 2006. 779 10.2. Informative References 781 [I-D.donley-behave-deterministic-cgn] 782 Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 783 and O. Vautrin, "Deterministic Address Mapping to Reduce 784 Logging in Carrier Grade NAT Deployments", 785 draft-donley-behave-deterministic-cgn-05 (work in 786 progress), January 2013. 788 [I-D.donley-nat444-impacts] 789 Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U. 790 Colorado, "Assessing the Impact of Carrier-Grade NAT on 791 Network Applications", draft-donley-nat444-impacts-05 792 (work in progress), October 2012. 794 [I-D.ietf-behave-lsn-requirements] 795 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 796 and H. Ashida, "Common requirements for Carrier Grade NATs 797 (CGNs)", draft-ietf-behave-lsn-requirements-10 (work in 798 progress), December 2012. 800 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 801 E. Lear, "Address Allocation for Private Internets", 802 BCP 5, RFC 1918, February 1996. 804 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 805 Label Switching Architecture", RFC 3031, January 2001. 807 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 808 Infrastructures (6rd) -- Protocol Specification", 809 RFC 5969, August 2010. 811 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 812 NAT64: Network Address and Protocol Translation from IPv6 813 Clients to IPv4 Servers", RFC 6146, April 2011. 815 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 816 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 817 June 2011. 819 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 820 Stack Lite Broadband Deployments Following IPv4 821 Exhaustion", RFC 6333, August 2011. 823 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 824 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 825 Space", BCP 153, RFC 6598, April 2012. 827 Authors' Addresses 829 Victor Kuarsingh (editor) 830 Rogers Communications 831 8200 Dixie Road 832 Brampton, Ontario L6T 0C1 833 Canada 835 Email: victor.kuarsingh@gmail.com 836 URI: http://www.rogers.com 838 John Cianfarani 839 Rogers Communications 840 8200 Dixie Road 841 Brampton, Ontario L6T 0C1 842 Canada 844 Email: john.cianfarani@rci.rogers.com 845 URI: http://www.rogers.com