idnits 2.17.1 draft-ietf-opsawg-lsn-deployment-04.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 (December 23, 2013) is 3775 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-06 Summary: 0 errors (**), 0 flaws (~~), 2 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: June 26, 2014 December 23, 2013 7 CGN Deployment with BGP/MPLS IP VPNs 8 draft-ietf-opsawg-lsn-deployment-04 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 June 26, 2014. 47 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. CGN Network Deployment Requirements . . . . . . . . . . . . . 4 68 3.1. Centralized versus Distributed Deployment . . . . . . . . 6 69 3.2. CGN and Traditional IPv4 Service Co-existence . . . . . . 6 70 3.3. CGN By-Pass . . . . . . . . . . . . . . . . . . . . . . . 7 71 3.4. Routing Plane Separation . . . . . . . . . . . . . . . . 7 72 3.5. Flexible Deployment Options . . . . . . . . . . . . . . . 7 73 3.6. IPv4 Overlap Space . . . . . . . . . . . . . . . . . . . 8 74 3.7. Transactional Logging for CGN Systems . . . . . . . . . . 8 75 3.8. Base CGN Requirements . . . . . . . . . . . . . . . . . . 8 76 4. BGP/MPLS IP VPN based CGN Framework . . . . . . . . . . . . . 9 77 4.1. Service Separation . . . . . . . . . . . . . . . . . . . 10 78 4.2. Internal Service Delivery . . . . . . . . . . . . . . . . 11 79 4.2.1. Dual Stack Operation . . . . . . . . . . . . . . . . 13 80 4.3. Deployment Flexibility . . . . . . . . . . . . . . . . . 15 81 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN 82 Attachment Options . . . . . . . . . . . . . . . . . . . 15 83 4.4.1. Policy Based Routing . . . . . . . . . . . . . . . . 15 84 4.4.2. Traffic Engineering . . . . . . . . . . . . . . . . . 16 85 4.4.3. Multiple Routing Topologies . . . . . . . . . . . . . 16 86 4.5. Multicast Considerations . . . . . . . . . . . . . . . . 16 87 5. Experiences . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 5.1. Basic Integration and Requirements Support . . . . . . . 16 89 5.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 17 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 92 8. BGP/MPLS IP VPN CGN Framework Discussion . . . . . . . . . . 18 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 96 10.2. Informative References . . . . . . . . . . . . . . . . . 18 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 99 1. Introduction 101 Operators are faced with near term IPv4 address exhaustion 102 challenges. Many operators may not have a sufficient amount of IPv4 103 addresses in the future to satisfy the needs of their growing 104 subscriber base. This challenge may also be present before or during 105 an active transition to IPv6 somewhat complicating the overall 106 problem space. 108 To face this challenge, operators may need to deploy CGN (Carrier 109 Grade NAT) as described in [RFC6888] to help extend the connectivity 110 matrix once IPv4 address caches run out on the local local operator. 111 CGN deployments will most often be added into operator networks which 112 already have active IPv4 and/or IPv6 services. 114 The addition of the CGN introduces an operator controlled and 115 administered translation layer which should be added in a manner 116 which minimizes disruption to existing services. The CGN system 117 addition may also include interworking in a dual stack environment 118 where the IPv4 path requires translation. 120 This document shows how BGP/MPLS IP VPNs as described in [RFC4364] 121 can be used to integrate the CGN infrastructure solving key 122 integration challenges faced by the operator. This model has also 123 been tested and validated in real production network models and 124 allows fluid operation with existing IPv4 and IPv6 services. 126 1.1. Terms 128 A list of acronyms used throughout this document are defined in list 129 below. 131 CGN - Carrier Grade NAT 133 DOCSIS - Data Over Cable Service Interface Specification 135 CMTS - Cable Modem Termination System 137 DSL -Digital subscriber line 139 BRAS - Broadband Remote Access Server 141 GGSN - Gateway GPRS Support Node 142 GPRS - General Packet Radio Service 144 ASN-GW - Access Service Network Gateway 146 2. Motivation 148 The selection of CGN may be made by an operator based on a number of 149 factors. The overall driver may be the depletion of IPv4 address 150 pools which leaves little to no addresses for IPv4 service or 151 connection demand growth. IPv6 is considered the strategic answer, 152 but it's applicability and usefulness in many networks is limited by 153 the current access network and consumer home network. Customer 154 environments often are filled with IPv4-only equipment which may not 155 be upgradable to IPv6. 157 The ability to replace IPv4-only equipment may be out of the control 158 of the operator, and even when it's in the administrative control, it 159 poses both cost and technical challenges as operators build out 160 massive programs for equipment retirement or upgrade. These issues 161 leave an operator in a precarious position which may lead to the 162 decision to deploy CGN. Other address IPv4 sharing options do exist 163 which are more architecturally desirable, but the practical and 164 workable approach in many cases is a CGN deployment using the NAT444 165 framework. 167 If the operator has chosen to deploy CGN, they should do this in a 168 manner as not to negatively impact the existing IPv4 or IPv6 169 subscriber base. This will include solving a number of challenges 170 since subscribers whose connections require translation will have 171 network routing and flow needs which are different from legacy IPv4 172 connections. 174 The solution will also need to work in a dual stack environment where 175 other options such as DS-Lite [RFC6333] are not yet viable. Even 176 technologies like 6RD [RFC5969] still require an IPv4 connectivity 177 path to service the subscriber endpoint. The solution will need to 178 address basic Internet connectivity, on-net service offerings, back 179 office management, billing, policy and security models already in 180 place within the operator's network. CGN will often integrate quite 181 readily with the aforementioned requirements where as other 182 transition mechanism may not due to the requirements to support IPv6 183 as the base protocol for IPv4 connectivity. 185 3. CGN Network Deployment Requirements 187 If a service provider is considering a CGN deployment with a provider 188 NAT44 function, there are a number of basic architectural 189 requirements which are of importance. Preliminary architectural 190 requirements may require all or some of those captured in the list 191 below. Each of the architectural requirement items listed are 192 expanded upon in the following subsections. It should be noted that 193 architectural CGN requirements add additive to base CGN functional 194 requirements in [RFC6888]. The assessed architectural requirements 195 for deployment are: 197 - Support distributed (sparse) and centralized (dense) deployment 198 models; 200 - Allow co-existence with traditional IPv4 based deployments, 201 which provide global scoped IPv4 addresses to CPEs; 203 - Provide a framework for CGN by-pass supporting non-translated 204 flows between endpoints within a provider's network; 206 - Provide a routing framework which allows the segmentation of 207 routing control and forwarding paths between CGN and non-CGN 208 mediated flows; 210 - Provide flexibility for operators to modify their deployments 211 over time as translation demands change (connections, bandwidth, 212 translation realms/zones and other vectors); 214 - Flexibility should include integration options for common access 215 technologies such as DSL (BRAS), DOCSIS (CMTS), Mobile (GGSN/PGW/ 216 ASN-GW), and direct Ethernet; 218 - Support deployment modes that allow for IPv4 address overlap 219 within the operator's network (between various translation realms 220 or zones); 222 - Allow for evolution to future dual-stack and IPv4/IPv6 223 transition deployment modes; 225 - Transactional logging and export capabilities to support 226 auxiliary functions including abuse mitigation; 228 - Support for stateful connection synchronization between 229 translation instances/elements (redundancy); 231 - Support for CGN Shared Space [RFC6598] deployment modes if 232 applicable; 234 - Allows for the enablement of CGN functionality (if required) 235 while still minimizing costs and subscriber impact to the best 236 extend possible; 238 Other requirements may be assessed on a operator-by-operator basis, 239 but those listed above may be considered for any given deployment 240 architecture. 242 3.1. Centralized versus Distributed Deployment 244 Centralized deployments of CGN (longer proximity to end user and/or 245 higher densities of subscribers/connections to CGN instances) differ 246 from distributed deployments of CGN (closer proximity to end user and 247 /or lower densities of subscribers/connections to CGN instances). 248 Service providers may likely deploy CGN translation points more 249 centrally during initial phases if the early system demand is low. 250 Early deployments may see light loading on these new systems since 251 legacy IPv4 services will continue to operate with most endpoints 252 using globally unique IPv4 addresses. Exceptional cases which may 253 drive heavy usage in initial stages may include operators who already 254 translate a significant portion of their IPv4 traffic; may transition 255 to a CGN implementation from legacy translation mechanisms (i.e. 256 traditional firewalls); or build a green field deployment which may 257 see quick growth in the number of new IPv4 endpoints which require 258 Internet connectivity. 260 Over time, some providers may need to expand and possibly distribute 261 the translation points if demand for the CGN system increases. The 262 extent of the expansion of the CGN infrastructure will depend on 263 factors such as growth in the number of IPv4 endpoints, status of 264 IPv6 content on the Internet and the overall progress globally to an 265 IPv6-dominate Internet (reducing the demand for IPv4 connectivity). 266 The overall demand for CGN resources will probably follow a bell-like 267 curve with a growth, peak and decline period. 269 3.2. CGN and Traditional IPv4 Service Co-existence 271 Newer CGN serviced endpoints will exist alongside endpoints served by 272 traditional IPv4 globally routed IPv4 addresses. Operators will need 273 to rationalize these environments since both have distinct forwarding 274 needs. Traditional IPv4 services will likely require (or be best 275 served) direct forwarding towards Internet peering points while CGN 276 mediated flows require access to a translator. CGN and non-CGN 277 mediated flows pose two fundamentally different forwarding needs. 279 The new CGN environments should not negatively impact the existing 280 IPv4 service base by forcing all traffic to translation enabled 281 network points since many flows do not require translation and this 282 would reduce performance of the existing flows. This would also 283 require massive scaling of the CGN which is a cost and efficiency 284 concern as well. 286 Traffic flow and forwarding efficiency is considered important since 287 networks are under considerable demand to deliver more and more 288 bandwidth without the luxury of needless inefficiencies which can be 289 introduced with CGN. 291 3.3. CGN By-Pass 293 The CGN environment is only needed for flows with translation 294 requirements. Many flows which remain within the operator's network, 295 do not require translation. Such services include operator offered 296 DNS Services, DHCP Services, NTP Services, Web Caching, E-Mail, News 297 and other services which are local to the operator's network. 299 The operator may want to leverage opportunities to offer third 300 parties a platform to also provide services without translation. CGN 301 by-pass can be accomplished in many ways, but a simplistic, 302 deterministic and scalable model is preferred. 304 3.4. Routing Plane Separation 306 Many operators will want to engineer traffic separately for CGN flows 307 versus flows which are part of the more traditional IPv4 environment. 308 Many times the routing of these two major flow types differ, 309 therefore route separation may be required. 311 Routing plane separation also allows the operator to utilize other 312 addressing techniques, which may not be feasible on a single routing 313 plane. Such examples include the use of overlapping private address 314 space [RFC1918], Shared Address Space [RFC6598] or use of other IPv4 315 space which may overlap globally within the operator's network. 317 3.5. Flexible Deployment Options 319 Service providers operate complex routing environments and offer a 320 variety of IPv4 based services. Many operator environments utilize 321 distributed peering infrastructures for transit and peering and these 322 may span large geographical areas and regions. A CGN solution should 323 offer the operator an ability to place CGN translation points at 324 various points within their network. 326 The CGN deployment should also be flexible enough to change over time 327 as demand for translation services increase or change as noted in 328 [RFC6264]. In turn, the deployment will need to then adapt as 329 translation demand decreases caused by the transition of flows to 330 IPv6. Translation points should be able to be placed and moved with 331 as little re-engineering effort as possible minimizing the risks to 332 the subscriber base. 334 Depending on hardware capabilities, security practices and IPv4 335 address availability, the translation environments may need to be 336 segmented and/or scaled over time to meet organic IPv4 demand growth. 337 Operators may also want to choose models that support transition to 338 other translation environments such as DS-Lite [RFC6333] and/or NAT64 339 [RFC6146]. Operators will want to seek deployment models which are 340 conducive to meeting these goals as well. 342 3.6. IPv4 Overlap Space 344 IPv4 address overlap for CGN translation realms may be required if 345 insufficient IPv4 addresses are available within the operator 346 environment to assign internally unique IPv4 addresses to the CGN 347 subscriber base . The CGN deployment should provide mechanisms to 348 manage IPv4 overlap if required. 350 3.7. Transactional Logging for CGN Systems 352 CGNs may require transactional logging since the source IP and 353 related transport protocol information is not easily visible to 354 external hosts and system. 356 If needed, the CGN systems should be able to generate logs which 357 identify 'internal' host parameters (i.e. IP/Port) and associated 358 them to external translated parameters imposed by the translator. 359 The logged information should be stored on the CGN hardware and/or 360 exported to an external system for processing. The operator may 361 choose to also enable mechanisms to help reduce logging such as block 362 allocation of UDP and TCP ports or deterministic translation options 363 such as [I-D.donley-behave-deterministic-cgn]. 365 Operators may need to keep track of this information (securely) to 366 meet regulatory and/or legal obligations. Further information can be 367 found in [RFC6888] with respect to CGN logging requirements (Logging 368 Section). 370 3.8. Base CGN Requirements 372 Whereas the requirements above represent assessed architectural 373 requirements, the CGN platform will also need to meet the need to 374 meet the base CGN requirements of a CGN function. Base requirements 375 include such functions as Bulk Port Allocation and other CGN device 376 specific functions. These base CGN platform requirements are 377 captured within [RFC6888]. 379 4. BGP/MPLS IP VPN based CGN Framework 381 The BGP/MPLS IP VPN [RFC4364] framework for CGN segregates the 'pre- 382 translated' realms within the service provider space into Layer-3 383 MPLS based VPNs. The operator can deploy a single realm for all CGN 384 based flows, or can deploy multiple realms based on translation 385 demand and other factors such as geographical proximity. A realm in 386 this model refers to a 'VPN' which shares a unique Route 387 Distinguisher/Route Target (RD/RT) combination, routing plane and 388 forwarding behaviours. 390 The BGP/MPLS IP VPN infrastructure provides control plane and 391 forwarding separation for the traditional IPv4 service environment 392 and CGN environment(s). The separation allows for routing 393 information (such as default routes) to be propagated separately for 394 CGN and non-CGN based subscriber flows. Traffic can be efficiently 395 routed to the Internet for normal flows, and routed directly to 396 translators for CGN mediated flows. Although many operators may run 397 a "default-route-free" core, IPv4 flows which require translation 398 must obviously be routed first to a translator, so a default route is 399 acceptable for the pre-translated realms. 401 The physical location of the Virtual Routing and Forwarding (VRF) 402 Termination point for a BGP/MPLS IP VPN enabled CGN can vary and be 403 located anywhere within the operator's network. This model fully 404 virtualizes the translation service from the base IPv4 forwarding 405 environment which will likely be carrying Internet bound traffic. 406 The base IPv4 environment can continue to service traditional IPv4 407 subscriber flows plus post translated CGN flows. 409 Figure 1 provides a view of the basic model. The Access node 410 provides CPE access to either the CGN VRF or the Global Routing 411 Table, depending on whether the subscriber receives a private or 412 public IP. Translator mediated traffic follows an MPLS Label- 413 switched Path (LSP) which can be setup dynamically and can span one 414 hop, or many hops (with no need for complex routing policies). 415 Traffic is then forwarded to the translator (shown below) which can 416 be an external appliance or integrated into the VRF Termination 417 (Provider Edge) router. Once traffic is translated, it is forwarded 418 to the global routing table for general Internet forwarding. The 419 Global Routing table can also be a separate VRF (Internet Access VPN/ 420 VRF) should the provider choose to implement their Internet based 421 services in that fashion. The translation services are effectively 422 overlaid onto the network, but are maintained within a separate 423 forwarding and control plane. 425 Access Node VRF Termination CGN 426 +-----------+ +-----------+ +-----------+ 427 | | | | | | 428 CPE | +-------+ | | +-------+ | | +-------+ | 429 +----+ | | | | LSP | | | | IP | | | | 430 | --+---+-+->VRF--+-+-----+-+->VRF--+-+----+-+-> | | 431 +----+ | | | | | | | | | | | | 432 | +-------+ | | +-------+ | | | | | 433 | | | | | | XLATE | | 434 | | | | | | | | 435 CPE | +-------+ | | +-------+ | | | | | 436 +----+ | | | | | | | | IP | | | | 437 | --+---+-+->GRT | | | | GRT<-+-+----+-+-- | | 438 +----+ | | | | | | | | | | | | | | 439 | +---+---+ | | +---+---+ | | +-------+ | 440 +-----+-----+ +-----+-----+ +-----------+ 441 | | 442 | | IPv4 443 | | IP +---------+ 444 | +------------+-> | 445 | IP | GRT | 446 +------------------------------+-> | 447 +---------+ 449 Figure 1: Basic BGP/MPLS IP VPN CGN Model 451 If more then one VRF (translation realm) is used within the 452 operator's network, each VPN instance can manage CGN flows 453 independently for the respective realm. Various redundancy models 454 can be used within this architecture to support failover from one 455 physical CGN hardware instance to another. If state information 456 needs to be passed or maintained between hardware instances, the 457 vendor would need to enable this feature in a suitable manner. 459 4.1. Service Separation 461 The MPLS/VPN CGN framework supports route separation. The 462 traditional IPv4 flows can be separated at the access node (Initial 463 Layer 3 service point) from those which require translation. This 464 type of service separation is possible on common technologies used 465 for Internet access within many operator networks. Service 466 separation can be accomplished on common access technology including 467 those used for DOCSIS (CMTS), Ethernet Access, DSL (BRAS), and Mobile 468 Access (GGSN/ASN-GW) architectures. 470 4.2. Internal Service Delivery 472 Internal services can be delivered directly to the privately 473 addressed endpoint within the CGN domain without translation. This 474 can be accomplished in one of two methods. The first method may 475 include reducing the overall number of VRFs in the system and 476 exposing services in the GRT along with a method of exchanging routes 477 between the CGN VRF and GRT called route leaking. The second method, 478 which is described in detail within this section is the use of a 479 Services VRF. The second model is a more traditional extranet 480 services model, but requires more system resources to implement. 482 Using direct route exchange (import/export) between the CGN VRFs and 483 the Services VRFs creates reachablity using the aforementioned 484 extranet model available in the BGP/MPLS IP VPN structure. This 485 model allows the provider to maintain separate forwarding rules for 486 translated flows, which require a pass through the translator to 487 reach external network entities, versus those flows which need to 488 access internal services. This operational detail can be 489 advantageous for a number of reasons such as service access policies 490 and endpoint identification. 492 First, the provider can reduce the load on the translator since 493 internal services do not need to be factored into the scaling of the 494 CGN hardware (which may be quite large). Secondly, more direct 495 forwarding paths can be maintained providing better network 496 efficiency. Thirdly, geographic locations of the translators and the 497 services infrastructure can be deployed in locations in an 498 independent manner. Additionally, the operator can allow CGN subject 499 endpoints to be accessible via an untranslated path reducing the 500 complexities of provider initiated management flows. This last point 501 is of key interest since NAT removes transparency to the end device 502 in normal cases. 504 Figure 2 below shows how internal services are provided untranslated 505 since flows are sent directly from the access node to the services 506 node/VRF via an MPLS LSP. This traffic is not forwarded to the CGN 507 translator and therefore is not subject to problematic behaviours 508 related to NAT. The services VRF contains routing information which 509 can be "imported" into the access node VRF and the CGN VRF routing 510 information can be "imported" into the Services VRF. 512 Access Node VRF Termination CGN 513 +-------------+ +-----------+ +----------+ 514 | | | | | | 515 CPE | +---------+ | | +-------+ | | +------+ | 516 +-----+ | | | | | | | | | | | | 517 | --+--+-+-> VRF --+-+--+ | | VRF | | | | | | 518 +-----+ | | | | | | | | | | | | | 519 | +---------+ | | | +-------+ | | | | | 520 | | | | | | |XLATE | | 521 | | | | | | | | | 522 CPE | +---------+ | | | +-------+ | | | | | 523 +-----+ | | | | | | | | | | | | | 524 | --+--+-+-> GRT | | | | | GRT | | | | | | 525 +-----+ | | | | | | | | | | | | | | 526 | +----+----+ | | | +-------+ | | +------+ | 527 +------+------+ | +-----------+ +----------+ 528 | | 529 | | IPv4 530 | | +-----------+ 531 | +---------------+->Services | 532 | | VRF | 533 .-------------------------+-> | | 534 +-----+-----+ 535 | 536 +-----V-----+ 537 | | 538 | Local | 539 | Content | 540 +-----------+ 542 Figure 2: Internal Services and CGN By-Pass 544 An extension to the services delivery LSP is the ability to also 545 provide direct subscriber to subscriber traffic flows between CGN 546 zones. Each zone or realm may be fitted with separate CGN resources, 547 but the subtending subscribers don't necessarily need to be mediated 548 (translated) by the CGN translators. This option, as shown in 549 Figure 3 below, is easy to implement and can only be enabled if no 550 IPv4 address overlap is used between communicating CGN zones. 552 Access Node-1 VRF Termination CGN-1 553 +-------------+ +-----------+ +----------+ 554 | | | | | | 555 CPE-1 | +---------+ | | +-------+ | | +------+ | 556 +-----+ | | | | | | | | | | | | 557 | --+--+-+- VRF --+-+-+ | | VRF | | | | | | 558 +-----+ | | | | | | | | | | | | | 559 | +---------+ | | | +-------+ | | | | | 560 | | | | | | |XLATE | | 561 | | | | | | | | | 562 CPE-2 | +---------+ | | | +-------+ | | | | | 563 +-----+ | | | | | | | | | | | | | 564 | --+--+-+- GRT | | | | | GRT | | | | | | 565 +-----+ | | | | | | | | | | | | | 566 | +---------+ | | | +-------+ | | +------+ | 567 +-------------+ | +-----------+ +----------+ 568 | 569 LSP | 570 | 571 Access Node-2 | VRF Termination CGN-2 572 +-------------+ | +-----------+ +----------+ 573 | | | | | | | 574 CPE-3 | +---------+ | | | +-------+ | | +------+ | 575 +-----+ | | | | | | | | | | | | | 576 | --+--+-+-- VRF --+-+-+ | | VRF | | | | | | 577 +-----+ | | | | | | | | | | | | 578 | +---------+ | | +-------+ | | | | | 579 | | | | | |XLATE | | 580 | | | | | | | | 581 CPE-4 | +---------+ | | +-------+ | | | | | 582 +-----+ | | | | | | | | | | | | 583 | --+--+-+- GRT | | | | GRT | | | | | | 584 +-----+ | | | | | | | | | | | | 585 | +---------+ | | +-------+ | | +------+ | 586 +-------------+ +-----------+ +----------+ 588 The inherent capabilities of the BGP/MPLS IP VPN model demonstrates 589 the ability to offer CGN By-Pass in a standard and deterministic 590 manner without the need of policy based routing or traffic 591 engineering. 593 4.2.1. Dual Stack Operation 595 The BGP/MPLS IP VPN CGN model can also be used in conjunction with 596 IPv4/IPv6 dual stack service modes. Since many providers will use 597 CGNs on an interim basis while IPv6 matures within the global 598 Internet or due to technical constraints, a dual stack option is of 599 strategic importance. Operators can offer this dual stack service 600 for both traditional IPv4 (global IP) endpoints and CGN mediated 601 endpoints. 603 Operators can separate the IP flows for IPv4 and IPv6 traffic, or use 604 other routing techniques to move IPv6 based flows towards the GRT 605 (Global Routing Table or Instance) while allowing IPv4 flows to 606 remain within the IPv4 CGN VRF for translator services. 608 The Figure 4 below shows how IPv4 translation services can be 609 provided alongside IPv6 based services. The model shown allows the 610 provider to enable CGN to manage IPv4 flows (translated) and IPv6 611 flows are routed without translation efficiently towards the 612 Internet. Once again, forwarding of flows to the translator does not 613 impact IPv6 flows which do not require this service. 615 Access Node VRF Termination CGN 616 +-----------+ +-----------+ +-----------+ 617 | | | | | | 618 CPE | +-------+ | | +-------+ | | +-------+ | 619 +-----+ | | | |LSP| | | | IP | | | | 620 | --+--+-+->VRF--+-+---+-+->VRF--+-+----+-+> | | 621 |IPv4 | | | | | | | | | | | | | 622 | | | +-------+ | | +-------+ | | | | | 623 +-----| | | | | | | XLATE | | 624 |IPv6 | | | | | | | | | 625 | | | +-------+ | | +-------+ | | | | | 626 | | | | IPv6 | | | | IPv4 | | IP | | | | 627 | --+--+-+->GRT | | | | GRT<-+-+----+-+-- | | 628 +-----+ | | | | | | | | | | | | | | 629 | +---+---+ | | +---+---+ | | +-------+ | 630 +-----+-----+ +-----+-----+ +-----------+ 631 | | 632 | | +-----------+ 633 | | IP | IPv4 | 634 | +----------+-> GRT | 635 | +-----------+ 636 | 637 | 638 | 639 | IP +-----------+ 640 +--------------------------+-> IPv6 | 641 | GRT | 642 +-----------+ 644 Figure 4: CGN with IPv6 Dual Stack Operation 646 4.3. Deployment Flexibility 648 The CGN translator services can be moved, separated or segmented (new 649 translation realms) without the need to change the overall 650 translation design. Since dynamic LSPs are used to forward traffic 651 from the access nodes to the translation points, the physical 652 location of the VRF termination points can vary and be changed 653 easily. 655 This type of flexibility allows the service provider to initially 656 deploy more centralized translation services based on relatively low 657 loading factors, and distribute the translation points over time to 658 improve network traffic efficiencies and support higher translation 659 load. 661 Although traffic engineered paths are not required within the MPLS/ 662 VPN deployment model, nothing precludes an operator from using 663 technologies like MPLS with Traffic Engineering [RFC3031]. 664 Additional routing mechanisms can be used as desired by the provider 665 and can be seen as independent. There is no specific need to 666 diversify the existing infrastructure in most cases. 668 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN Attachment 669 Options 671 Other integration architecture options exist which can attach CGN 672 based service flows to a translator instance. Alternate options 673 which can be used to attach such services include: 675 - Policy Based Routing (Static) to direct translation bound 676 traffic to a network based translator; 678 - Traffic Engineering or; 680 - Multiple Routing Topologies 682 4.4.1. Policy Based Routing 684 Policy Based Routing (PBR) provides another option to direct CGN 685 mediated flows to a translator. PBR options, although possible, are 686 difficult to maintain (static policy) and must be configured 687 throughout the network with considerable maintenance overhead. 689 More centralized deployments may be difficult or too onerous to 690 deploy using Policy Based Routing methods. Policy Based Routing 691 would not achieve route separation (unless used with others options), 692 and may add complexities to the providers' routing environment. 694 4.4.2. Traffic Engineering 696 Traffic Engineering can also be used to direct traffic from an access 697 node towards a translator. Traffic Engineering, like MPLS-TE, may be 698 difficult to setup and maintain. Traffic Engineering provides 699 additional benefits if used with MPLS by adding potentials for faster 700 path re-convergence. Traffic Engineering paths would need to be 701 updated and redefined overtime as CGN translation points are 702 augmented or moved. 704 4.4.3. Multiple Routing Topologies 706 Multiple routing topologies can be used to direct CGN based flows to 707 translators. This option would achieve the same basic goal as the 708 MPLS/VPN option but with additional implementation overhead and 709 platform configuration complexity. Since operator based translation 710 is expected to have an unknown lifecycle, and may see various degrees 711 of demand (dependant on operator IPv4 Global space availability and 712 shift of traffic to IPv6), it may be too large of an undertaking for 713 the provider to enabled this as their primary option for CGN. 715 4.5. Multicast Considerations 717 When deploying BGP/MPLS IP VPN's as an service method for user plane 718 traffic to access CGN, one needs to be cognizant of current or future 719 IP multicast requirements. User plane IP Multicast which may 720 originate outside of the VRF requires more consideration specific 721 consideration. Adding the requirement for user plane IP multicast 722 can potentially cause additional complexity related to import and 723 exporting the IP multicast routes in addition to sub optimal scaling, 724 and bandwidth utilization. 726 It is recommended to reference best practice and designs from 727 [RFC6037], [RFC6513], and [RFC5332] 729 5. Experiences 731 5.1. Basic Integration and Requirements Support 733 The MPLS/VPN CGN environment has been successfully integrated into 734 real network environments utilizing existing network service delivery 735 mechanisms. It solves many issues related to provider based 736 translation environments, while still subject to problematic 737 behaviours inherent within NAT. 739 Key issues which are solved or managed with the MPLS/VPN option 740 include: 742 - Centralized and Distributed Deployment model support 744 - Routing Plane Separation for CGN flows versus traditional IPv4 745 flows 747 - Flexible Translation Point Design (can relocate translators and 748 split translation zones easily) 750 - Low maintenance overhead (dynamic routing environment with 751 little maintenance of separate routing infrastructure other then 752 management of MPLS/VPNs) 754 - CGN By-pass options (for internal and third party services which 755 exist within the provider domain) 757 - IPv4 Translation Realm overlap support (can reuse IP addresses 758 between zones with some impact to extranet service model) 760 - Simple failover techniques can be implemented with redundant 761 translators, such as using a second default route 763 5.2. Performance 765 The MPLS/VPN CGN model was observed to support basic functions which 766 are typically used by subscribes within an operator environment. A 767 full review of the observed impacts related to CGN (NAT444) are 768 covered in [RFC7021]. 770 6. IANA Considerations 772 There are not specific IANA considerations known at this time with 773 the architecture described herein. Should a provide choose to use 774 non-assigned IP address space within their translation realms, then 775 considerations may apply. 777 7. Security Considerations 779 The same security considerations would typically exist for CGN 780 deployments when compared with traditional IPv4 based services. With 781 the MPLS/VPN model, the operator would want to consider security 782 issues related to offering IP services over MPLS. 784 If a provider plans to operate the pre-translation realm (CPE towards 785 translator IPv4 zone) as a non-public like network, then additional 786 security measures may be needed to secure this environment. It is 787 however the position in this document that CGN realms are public 788 domains which utilize non-Internet routable IP addresses for endpoint 789 addressing. 791 8. BGP/MPLS IP VPN CGN Framework Discussion 793 The MPLS/VPN delivery method for a CGN deployment is an effective and 794 scalable way to deliver mass translation services. The architecture 795 avoids the complex requirements of traffic engineering and policy 796 based routing when combining these new service flows to existing IPv4 797 operation. This is advantageous since the NAT44/CGN environments 798 should be introduced with as little impact as possible and these 799 environments are expected to change over time. 801 The MPLS/VPN based CGN architecture solves many of this issues 802 related to deploying this technology in existing operator networks. 804 9. Acknowledgements 806 Thanks to the following people for their comments and feedback: Dan 807 Wing, Chris Metz, Chris Donley, Tina TSOU, Christophoer Liljenstolpe 808 and Tom Taylor. 810 Thanks to the following people for their participating in integrating 811 and testing the CGN environment and for their IPv6 transition 812 guidance: Syd Alam, Richard Lawson, John E Spence, John Jason 813 Brzozowski, Chris Donley, Jason Weil, Lee Howard, Jean-Francois 814 Tremblay 816 10. References 818 10.1. Normative References 820 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 821 Networks (VPNs)", RFC 4364, February 2006. 823 10.2. Informative References 825 [I-D.donley-behave-deterministic-cgn] 826 Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 827 and O. Vautrin, "Deterministic Address Mapping to Reduce 828 Logging in Carrier Grade NAT Deployments", draft-donley- 829 behave-deterministic-cgn-06 (work in progress), July 2013. 831 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 832 E. Lear, "Address Allocation for Private Internets", BCP 833 5, RFC 1918, February 1996. 835 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 836 Label Switching Architecture", RFC 3031, January 2001. 838 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 839 Multicast Encapsulations", RFC 5332, August 2008. 841 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 842 Infrastructures (6rd) -- Protocol Specification", RFC 843 5969, August 2010. 845 [RFC6037] Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems' 846 Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037, 847 October 2010. 849 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 850 NAT64: Network Address and Protocol Translation from IPv6 851 Clients to IPv4 Servers", RFC 6146, April 2011. 853 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 854 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 855 June 2011. 857 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 858 Stack Lite Broadband Deployments Following IPv4 859 Exhaustion", RFC 6333, August 2011. 861 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 862 VPNs", RFC 6513, February 2012. 864 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 865 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 866 Space", BCP 153, RFC 6598, April 2012. 868 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 869 and H. Ashida, "Common Requirements for Carrier-Grade NATs 870 (CGNs)", BCP 127, RFC 6888, April 2013. 872 [RFC7021] Donley, C., Howard, L., Kuarsingh, V., Berg, J., and J. 873 Doshi, "Assessing the Impact of Carrier-Grade NAT on 874 Network Applications", RFC 7021, September 2013. 876 Authors' Addresses 878 Victor Kuarsingh (editor) 879 Rogers Communications 880 8200 Dixie Road 881 Brampton, Ontario L6T 0C1 882 Canada 884 Email: victor@jvknet.com 885 URI: http://www.rogers.com 886 John Cianfarani 887 Rogers Communications 888 8200 Dixie Road 889 Brampton, Ontario L6T 0C1 890 Canada 892 Email: john.cianfarani@rci.rogers.com 893 URI: http://www.rogers.com