idnits 2.17.00 (12 Aug 2021) /tmp/idnits53802/draft-ietf-opsawg-lsn-deployment-06.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 (April 13, 2014) is 2953 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5969' is defined on line 821, but no explicit reference was found in the text == Outdated reference: draft-donley-behave-deterministic-cgn has been published as RFC 7422 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: October 15, 2014 April 13, 2014 7 CGN Deployment with BGP/MPLS IP VPNs 8 draft-ietf-opsawg-lsn-deployment-06 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 October 15, 2014. 47 Copyright Notice 49 Copyright (c) 2014 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. Existing Network Considerations . . . . . . . . . . . . . . . 4 67 3. CGN Network Deployment Requirements . . . . . . . . . . . . . 4 68 3.1. Centralized versus Distributed Deployment . . . . . . . . 5 69 3.2. CGN and Traditional IPv4 Service Co-existence . . . . . . 6 70 3.3. CGN By-Pass . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.4. Routing Plane Separation . . . . . . . . . . . . . . . . 7 72 3.5. Flexible Deployment Options . . . . . . . . . . . . . . . 7 73 3.6. IPv4 Overlap Space . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . 8 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 . . . . . . . . . . 17 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 GRT - Global Routing Table 148 Internal Realm - Addressing and/or network zone been the CPE and 149 CGN as specified in [RFC6888] 151 External Realm - Public side network zone and addressing on the 152 Internet facing side of the CGN as specified in [RFC6888] 154 2. Existing Network Considerations 156 The selection of CGN may be made by an operator based on a number of 157 factors. The overall driver to use CGN may be the depletion of IPv4 158 address pools which leaves little to no addresses for a growing IPv4 159 service or connection demand growth. IPv6 is considered the 160 strategic answer for IPv4 address depletion; however, the operator 161 may independently decide that CGN is needed to supplement IPv6 and 162 address their particular IPv4 service deployment needs. 164 If the operator has chosen to deploy CGN, they should do this in a 165 manner as not to negatively impact the existing IPv4 or IPv6 166 subscriber base. This will include solving a number of challenges 167 since subscribers whose connections require translation will have 168 network routing and flow needs which are different from legacy IPv4 169 connections. 171 3. CGN Network Deployment Requirements 173 If a service provider is considering a CGN deployment with a provider 174 NAT44 function, there are a number of basic architectural 175 requirements which are of importance. Preliminary architectural 176 requirements may require all or some of those captured in the list 177 below. Each of the architectural requirement items listed are 178 expanded upon in the following subsections. It should be noted that 179 architectural CGN requirements add additive to base CGN functional 180 requirements in [RFC6888]. The assessed architectural requirements 181 for deployment are: 183 - Support distributed (sparse) and centralized (dense) deployment 184 models; 186 - Allow co-existence with traditional IPv4 based deployments, 187 which provide global scoped IPv4 addresses to CPEs; 188 - Provide a framework for CGN by-pass supporting non-translated 189 flows between endpoints within a provider's network; 191 - Provide a routing framework which allows the segmentation of 192 routing control and forwarding paths between CGN and non-CGN 193 mediated flows; 195 - Provide flexibility for operators to modify their deployments 196 over time as translation demands change (connections, bandwidth, 197 translation realms/zones and other vectors); 199 - Flexibility should include integration options for common access 200 technologies such as DSL (BRAS), DOCSIS (CMTS), Mobile (GGSN/PGW/ 201 ASN-GW), and direct Ethernet; 203 - Support deployment modes that allow for IPv4 address overlap 204 within the operator's network (between various translation realms 205 or zones); 207 - Allow for evolution to future dual-stack and IPv4/IPv6 208 transition deployment modes; 210 - Transactional logging and export capabilities to support 211 auxiliary functions including abuse mitigation; 213 - Support for stateful connection synchronization between 214 translation instances/elements (redundancy); 216 - Support for CGN Shared Space [RFC6598] deployment modes if 217 applicable; 219 - Allows for the enablement of CGN functionality (if required) 220 while still minimizing costs and subscriber impact to the best 221 extend possible; 223 Other requirements may be assessed on a operator-by-operator basis, 224 but those listed above may be considered for any given deployment 225 architecture. 227 3.1. Centralized versus Distributed Deployment 229 Centralized deployments of CGN (longer proximity to end user and/or 230 higher densities of subscribers/connections to CGN instances) differ 231 from distributed deployments of CGN (closer proximity to end user and 232 /or lower densities of subscribers/connections to CGN instances). 233 Service providers may likely deploy CGN translation points more 234 centrally during initial phases if the early system demand is low. 235 Early deployments may see light loading on these new systems since 236 legacy IPv4 services will continue to operate with most endpoints 237 using globally unique IPv4 addresses. Exceptional cases which may 238 drive heavy usage in initial stages may include operators who already 239 translate a significant portion of their IPv4 traffic; may transition 240 to a CGN implementation from legacy translation mechanisms (i.e. 241 traditional firewalls); or build a green field deployment which may 242 see quick growth in the number of new IPv4 endpoints which require 243 Internet connectivity. 245 Over time, some providers may need to expand and possibly distribute 246 the translation points if demand for the CGN system increases. The 247 extent of the expansion of the CGN infrastructure will depend on 248 factors such as growth in the number of IPv4 endpoints, status of 249 IPv6 content on the Internet and the overall progress globally to an 250 IPv6-dominate Internet (reducing the demand for IPv4 connectivity). 251 The overall demand for CGN resources will probably follow a bell-like 252 curve with a growth, peak and decline period. 254 3.2. CGN and Traditional IPv4 Service Co-existence 256 Newer CGN serviced endpoints will exist alongside endpoints served by 257 traditional IPv4 globally routed IPv4 addresses. Operators will need 258 to rationalize these environments since both have distinct forwarding 259 needs. Traditional IPv4 services will likely require (or be best 260 served) direct forwarding towards Internet peering points while CGN 261 mediated flows require access to a translator. CGN and non-CGN 262 mediated flows pose two fundamentally different forwarding needs. 264 The new CGN environments should not negatively impact the existing 265 IPv4 service base by forcing all traffic to translation enabled 266 network points since many flows do not require translation and this 267 would reduce performance of the existing flows. This would also 268 require massive scaling of the CGN which is a cost and efficiency 269 concern as well. 271 Traffic flow and forwarding efficiency is considered important since 272 networks are under considerable demand to deliver more and more 273 bandwidth without the luxury of needless inefficiencies which can be 274 introduced with CGN. 276 3.3. CGN By-Pass 278 The CGN environment is only needed for flows with translation 279 requirements. Many flows which remain within the operator's network, 280 do not require translation. Such services include operator offered 281 DNS Services, DHCP Services, NTP Services, Web Caching, E-Mail, News 282 and other services which are local to the operator's network. 284 The operator may want to leverage opportunities to offer third 285 parties a platform to also provide services without translation. CGN 286 by-pass can be accomplished in many ways, but a simplistic, 287 deterministic and scalable model is preferred. 289 3.4. Routing Plane Separation 291 Many operators will want to engineer traffic separately for CGN flows 292 versus flows which are part of the more traditional IPv4 environment. 293 Many times the routing of these two major flow types differ, 294 therefore route separation may be required. 296 Routing plane separation also allows the operator to utilize other 297 addressing techniques, which may not be feasible on a single routing 298 plane. Such examples include the use of overlapping private address 299 space [RFC1918], Shared Address Space [RFC6598] or use of other IPv4 300 space which may overlap globally within the operator's network. 302 3.5. Flexible Deployment Options 304 Service providers operate complex routing environments and offer a 305 variety of IPv4 based services. Many operator environments utilize 306 distributed peering infrastructures for transit and peering and these 307 may span large geographical areas and regions. A CGN solution should 308 offer the operator an ability to place CGN translation points at 309 various points within their network. 311 The CGN deployment should also be flexible enough to change over time 312 as demand for translation services increase or change as noted in 313 [RFC6264]. In turn, the deployment will need to then adapt as 314 translation demand decreases caused by the transition of flows to 315 IPv6. Translation points should be able to be placed and moved with 316 as little re-engineering effort as possible minimizing the risks to 317 the subscriber base. 319 Depending on hardware capabilities, security practices and IPv4 320 address availability, the translation environments may need to be 321 segmented and/or scaled over time to meet organic IPv4 demand growth. 322 Operators may also want to choose models that support transition to 323 other translation environments such as DS-Lite [RFC6333] and/or NAT64 324 [RFC6146]. Operators will want to seek deployment models which are 325 conducive to meeting these goals as well. 327 3.6. IPv4 Overlap Space 329 IPv4 address overlap for CGN translation realms may be required if 330 insufficient IPv4 addresses are available within the operator 331 environment to assign internally unique IPv4 addresses to the CGN 332 subscriber base . The CGN deployment should provide mechanisms to 333 manage IPv4 overlap if required. 335 3.7. Transactional Logging for CGN Systems 337 CGNs may require transactional logging since the source IP and 338 related transport protocol information is not easily visible to 339 external hosts and system. 341 If needed, the CGN systems should be able to generate logs which 342 identify internal realm host parameters (i.e. IP/Port) and associated 343 them to external realm parameters imposed by the translator. The 344 logged information should be stored on the CGN hardware and/or 345 exported to another system for processing. The operator may choose 346 to also enable mechanisms to help reduce logging such as block 347 allocation of UDP and TCP ports or deterministic translation options 348 such as [I-D.donley-behave-deterministic-cgn]. 350 Operators may be legally obligated to keep track of translation 351 information. The operator may need to utilize their standard 352 practices in handling sensitive customer data when storing and/or 353 transporting such data. Further information can be found in 354 [RFC6888] with respect to CGN logging requirements (Logging section). 356 3.8. Base CGN Requirements 358 Whereas the requirements above represent assessed architectural 359 requirements, the CGN platform will also need to meet the need to 360 meet the base CGN requirements of a CGN function. Base requirements 361 include such functions as Bulk Port Allocation and other CGN device 362 specific functions. These base CGN platform requirements are 363 captured within [RFC6888]. 365 4. BGP/MPLS IP VPN based CGN Framework 367 The BGP/MPLS IP VPN [RFC4364] framework for CGN segregates the 368 internal realms within the service provider space into Layer-3 MPLS 369 based VPNs. The operator can deploy a single realm for all CGN based 370 flows, or can deploy multiple realms based on translation demand and 371 other factors such as geographical proximity. A realm in this model 372 refers to a 'VPN' which shares a unique Route Distinguisher/Route 373 Target (RD/RT) combination, routing plane and forwarding behaviours. 375 The BGP/MPLS IP VPN infrastructure provides control plane and 376 forwarding separation for the traditional IPv4 service environment 377 and CGN environment(s). The separation allows for routing 378 information (such as default routes) to be propagated separately for 379 CGN and non-CGN based subscriber flows. Traffic can be efficiently 380 routed to the Internet for normal flows, and routed directly to 381 translators for CGN mediated flows. Although many operators may run 382 a "default-route-free" core, IPv4 flows which require translation 383 must obviously be routed first to a translator, so a default route is 384 acceptable for the internal realms. 386 The physical location of the Virtual Routing and Forwarding (VRF) 387 Termination point for a BGP/MPLS IP VPN enabled CGN can vary and be 388 located anywhere within the operator's network. This model fully 389 virtualizes the translation service from the base IPv4 forwarding 390 environment which will likely be carrying Internet bound traffic. 391 The base IPv4 environment can continue to service traditional IPv4 392 subscriber flows plus post translated CGN flows. 394 Figure 1 provides a view of the basic model. The Access node 395 provides CPE access to either the CGN VRF or the Global Routing 396 Table, depending on whether the subscriber receives a private or 397 public IP. Translator mediated traffic follows an MPLS Label- 398 switched Path (LSP) which can be setup dynamically and can span one 399 hop, or many hops (with no need for complex routing policies). 400 Traffic is then forwarded to the translator (shown below) which can 401 be an external appliance or integrated into the VRF Termination 402 (Provider Edge) router. Once traffic is translated, it is forwarded 403 to the global routing table for general Internet forwarding. The 404 Global Routing table can also be a separate VRF (Internet Access VPN/ 405 VRF) should the provider choose to implement their Internet based 406 services in that fashion. The translation services are effectively 407 overlaid onto the network, but are maintained within a separate 408 forwarding and control plane. 410 Access Node VRF Termination CGN 411 +-----------+ +-----------+ +-----------+ 412 | | | | | | 413 CPE | +-------+ | | +-------+ | | +-------+ | 414 +----+ | | | | LSP | | | | IP | | | | 415 | --+---+-+->VRF--+-+-----+-+->VRF--+-+----+-+-> | | 416 +----+ | | | | | | | | | | | | 417 | +-------+ | | +-------+ | | | | | 418 | | | | | | XLATE | | 419 | | | | | | | | 420 CPE-CGN | +-------+ | | +-------+ | | | | | 421 +----+ | | | | | | | | IP | | | | 422 | --+---+-+->GRT | | | | GRT<-+-+----+-+-- | | 423 +----+ | | | | | | | | | | | | | | 424 | +---+---+ | | +---+---+ | | +-------+ | 425 +-----+-----+ +-----+-----+ +-----------+ 426 | | 427 | | IPv4 428 | | IP +---------+ 429 | +------------+-> | 430 | IP | GRT | 431 +------------------------------+-> | 432 +---------+ 434 Figure 1: Basic BGP/MPLS IP VPN CGN Model 436 If more then one VRF (translation realm) is used within the 437 operator's network, each VPN instance can manage CGN flows 438 independently for the respective realm. The described architecture 439 does not prescribe a single redundancy model that ensures network 440 availability as a result of CGN failure. Deployments are able to 441 select a redundancy model that fits best with their network design. 442 If state information needs to be passed or maintained between 443 hardware instances, the vendor would need to enable this feature in a 444 suitable manner. 446 4.1. Service Separation 448 The MPLS/VPN CGN framework supports route separation. The 449 traditional IPv4 flows can be separated at the access node (Initial 450 Layer 3 service point) from those which require translation. This 451 type of service separation is possible on common technologies used 452 for Internet access within many operator networks. Service 453 separation can be accomplished on common access technology including 454 those used for DOCSIS (CMTS), Ethernet Access, DSL (BRAS), and Mobile 455 Access (GGSN/ASN-GW) architectures. 457 4.2. Internal Service Delivery 459 Internal services can be delivered directly to the privately 460 addressed endpoint within the CGN domain without translation. This 461 can be accomplished in one of two methods. The first method may 462 include reducing the overall number of VRFs in the system and 463 exposing services in the GRT along with a method of exchanging routes 464 between the CGN VRF and GRT called route leaking. The second method, 465 which is described in detail within this section is the use of a 466 Services VRF. The second model is a more traditional extranet 467 services model, but requires more system resources to implement. 469 Using direct route exchange (import/export) between the CGN VRFs and 470 the Services VRFs creates reachablity using the aforementioned 471 extranet model available in the BGP/MPLS IP VPN structure. This 472 model allows the provider to maintain separate forwarding rules for 473 translated flows, which require a pass through the translator to 474 reach external network entities, versus those flows which need to 475 access internal services. This operational detail can be 476 advantageous for a number of reasons such as service access policies 477 and endpoint identification. 479 First, the provider can reduce the load on the translator since 480 internal services do not need to be factored into the scaling of the 481 CGN hardware (which may be quite large). Secondly, more direct 482 forwarding paths can be maintained providing better network 483 efficiency. Thirdly, geographic locations of the translators and the 484 services infrastructure can be deployed in locations in an 485 independent manner. Additionally, the operator can allow CGN subject 486 endpoints to be accessible via an untranslated path reducing the 487 complexities of provider initiated management flows. This last point 488 is of key interest since NAT removes transparency to the end device 489 in normal cases. 491 Figure 2 below shows how internal services are provided untranslated 492 since flows are sent directly from the access node to the services 493 node/VRF via an MPLS LSP. This traffic is not forwarded to the CGN 494 translator and therefore is not subject to problematic behaviours 495 related to NAT. The services VRF contains routing information which 496 can be "imported" into the access node VRF and the CGN VRF routing 497 information can be "imported" into the Services VRF. 499 Access Node VRF Termination CGN 500 +-------------+ +-----------+ +----------+ 501 | | | | | | 502 CPE | +---------+ | | +-------+ | | +------+ | 503 +-----+ | | | | | | | | | | | | 504 | --+--+-+-> VRF --+-+--+ | | VRF | | | | | | 505 +-----+ | | | | | | | | | | | | | 506 | +---------+ | | | +-------+ | | | | | 507 | | | | | | |XLATE | | 508 | | | | | | | | | 509 CPE-CGN | +---------+ | | | +-------+ | | | | | 510 +-----+ | | | | | | | | | | | | | 511 | --+--+-+-> GRT | | | | | GRT | | | | | | 512 +-----+ | | | | | | | | | | | | | | 513 | +----+----+ | | | +-------+ | | +------+ | 514 +------+------+ | +-----------+ +----------+ 515 | | 516 | | IPv4 517 | | +-----------+ 518 | +---------------+->Services | 519 | | VRF | 520 .-------------------------+-> | | 521 +-----+-----+ 522 | 523 +-----V-----+ 524 | | 525 | Local | 526 | Content | 527 +-----------+ 529 Figure 2: Internal Services and CGN By-Pass 531 An extension to the services delivery LSP is the ability to also 532 provide direct subscriber to subscriber traffic flows between CGN 533 zones. Each zone or realm may be fitted with separate CGN resources, 534 but the subtending subscribers don't necessarily need to be mediated 535 (translated) by the CGN translators. This option, as shown in 536 Figure 3 below, is easy to implement and can only be enabled if no 537 IPv4 address overlap is used between communicating CGN zones. 539 Access Node-1 VRF Termination CGN-1 540 +-------------+ +-----------+ +----------+ 541 | | | | | | 542 CPE-1 | +---------+ | | +-------+ | | +------+ | 543 +-----+ | | | | | | | | | | | | 544 | --+--+-+- VRF --+-+-+ | | VRF | | | | | | 545 +-----+ | | | | | | | | | | | | | 546 | +---------+ | | | +-------+ | | | | | 547 | | | | | | |XLATE | | 548 | | | | | | | | | 549 CPE-2-CGN| +---------+ | | | +-------+ | | | | | 550 +-----+ | | | | | | | | | | | | | 551 | --+--+-+- GRT | | | | | GRT | | | | | | 552 +-----+ | | | | | | | | | | | | | 553 | +---------+ | | | +-------+ | | +------+ | 554 +-------------+ | +-----------+ +----------+ 555 | 556 LSP | 557 | 558 Access Node-2 | VRF Termination CGN-2 559 +-------------+ | +-----------+ +----------+ 560 | | | | | | | 561 CPE-3-CGN| +---------+ | | | +-------+ | | +------+ | 562 +-----+ | | | | | | | | | | | | | 563 | --+--+-+-- VRF --+-+-+ | | VRF | | | | | | 564 +-----+ | | | | | | | | | | | | 565 | +---------+ | | +-------+ | | | | | 566 | | | | | |XLATE | | 567 | | | | | | | | 568 CPE-4 | +---------+ | | +-------+ | | | | | 569 +-----+ | | | | | | | | | | | | 570 | --+--+-+- GRT | | | | GRT | | | | | | 571 +-----+ | | | | | | | | | | | | 572 | +---------+ | | +-------+ | | +------+ | 573 +-------------+ +-----------+ +----------+ 575 The inherent capabilities of the BGP/MPLS IP VPN model demonstrates 576 the ability to offer CGN By-Pass in a standard and deterministic 577 manner without the need of policy based routing or traffic 578 engineering. 580 4.2.1. Dual Stack Operation 582 The BGP/MPLS IP VPN CGN model can also be used in conjunction with 583 IPv4/IPv6 dual stack service modes. Since many providers will use 584 CGNs on an interim basis while IPv6 matures within the global 585 Internet or due to technical constraints, a dual stack option is of 586 strategic importance. Operators can offer this dual stack service 587 for both traditional IPv4 (global IP) endpoints and CGN mediated 588 endpoints. 590 Operators can separate the IP flows for IPv4 and IPv6 traffic, or use 591 other routing techniques to move IPv6 based flows towards the GRT 592 (Global Routing Table or Instance) while allowing IPv4 flows to 593 remain within the IPv4 CGN VRF for translator services. 595 The Figure 4 below shows how IPv4 translation services can be 596 provided alongside IPv6 based services. The model shown allows the 597 provider to enable CGN to manage IPv4 flows (translated) and IPv6 598 flows are routed without translation efficiently towards the 599 Internet. Once again, forwarding of flows to the translator does not 600 impact IPv6 flows which do not require this service. 602 Access Node VRF Termination CGN 603 +-----------+ +-----------+ +-----------+ 604 | | | | | | 605 CPE-CG | +-------+ | | +-------+ | | +-------+ | 606 +-----+ | | | |LSP| | | | IP | | | | 607 | --+--+-+->VRF--+-+---+-+->VRF--+-+----+-+> | | 608 |IPv4 | | | | | | | | | | | | | 609 | | | +-------+ | | +-------+ | | | | | 610 +-----| | | | | | | XLATE | | 611 |IPv6 | | | | | | | | | 612 | | | +-------+ | | +-------+ | | | | | 613 | | | | IPv6 | | | | IPv4 | | IP | | | | 614 | --+--+-+->GRT | | | | GRT<-+-+----+-+-- | | 615 +-----+ | | | | | | | | | | | | | | 616 | +---+---+ | | +---+---+ | | +-------+ | 617 +-----+-----+ +-----+-----+ +-----------+ 618 | | 619 | | +-----------+ 620 | | IP | IPv4 | 621 | +----------+-> GRT | 622 | +-----------+ 623 | 624 | 625 | 626 | IP +-----------+ 627 +--------------------------+-> IPv6 | 628 | GRT | 629 +-----------+ 631 Figure 4: CGN with IPv6 Dual Stack Operation 633 4.3. Deployment Flexibility 635 The CGN translator services can be moved, separated or segmented (new 636 translation realms) without the need to change the overall 637 translation design. Since dynamic LSPs are used to forward traffic 638 from the access nodes to the translation points, the physical 639 location of the VRF termination points can vary and be changed 640 easily. 642 This type of flexibility allows the service provider to initially 643 deploy more centralized translation services based on relatively low 644 loading factors, and distribute the translation points over time to 645 improve network traffic efficiencies and support higher translation 646 load. 648 Although traffic engineered paths are not required within the MPLS/ 649 VPN deployment model, nothing precludes an operator from using 650 technologies like MPLS with Traffic Engineering [RFC3031]. 651 Additional routing mechanisms can be used as desired by the provider 652 and can be seen as independent. There is no specific need to 653 diversify the existing infrastructure in most cases. 655 4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN Attachment 656 Options 658 Other integration architecture options exist which can attach CGN 659 based service flows to a translator instance. Alternate options 660 which can be used to attach such services include: 662 - Policy Based Routing (Static) to direct translation bound 663 traffic to a network based translator; 665 - Traffic Engineering or; 667 - Multiple Routing Topologies 669 4.4.1. Policy Based Routing 671 Policy Based Routing (PBR) provides another option to direct CGN 672 mediated flows to a translator. PBR options, although possible, are 673 difficult to maintain (static policy) and must be configured 674 throughout the network with considerable maintenance overhead. 676 More centralized deployments may be difficult or too onerous to 677 deploy using Policy Based Routing methods. Policy Based Routing 678 would not achieve route separation (unless used with others options), 679 and may add complexities to the providers' routing environment. 681 4.4.2. Traffic Engineering 683 Traffic Engineering can also be used to direct traffic from an access 684 node towards a translator. Traffic Engineering, like MPLS-TE, may be 685 difficult to setup and maintain. Traffic Engineering provides 686 additional benefits if used with MPLS by adding potentials for faster 687 path re-convergence. Traffic Engineering paths would need to be 688 updated and redefined overtime as CGN translation points are 689 augmented or moved. 691 4.4.3. Multiple Routing Topologies 693 Multiple routing topologies can be used to direct CGN based flows to 694 translators. This option would achieve the same basic goal as the 695 MPLS/VPN option but with additional implementation overhead and 696 platform configuration complexity. Since operator based translation 697 is expected to have an unknown lifecycle, and may see various degrees 698 of demand (dependant on operator IPv4 Global space availability and 699 shift of traffic to IPv6), it may be too large of an undertaking for 700 the provider to enabled this as their primary option for CGN. 702 4.5. Multicast Considerations 704 When deploying BGP/MPLS IP VPN's as an service method for user plane 705 traffic to access CGN, one needs to be cognizant of current or future 706 IP multicast requirements. User plane IP Multicast which may 707 originate outside of the VRF requires more consideration specific 708 consideration. Adding the requirement for user plane IP multicast 709 can potentially cause additional complexity related to import and 710 exporting the IP multicast routes in addition to sub optimal scaling, 711 and bandwidth utilization. 713 It is recommended to reference best practice and designs from 714 [RFC6037], [RFC6513], and [RFC5332] 716 5. Experiences 718 5.1. Basic Integration and Requirements Support 720 The MPLS/VPN CGN environment has been successfully integrated into 721 real network environments utilizing existing network service delivery 722 mechanisms. It solves many issues related to provider based 723 translation environments, while still subject to problematic 724 behaviours inherent within NAT. 726 Key issues which are solved or managed with the MPLS/VPN option 727 include: 729 - Centralized and Distributed Deployment model support 731 - Routing Plane Separation for CGN flows versus traditional IPv4 732 flows 734 - Flexible Translation Point Design (can relocate translators and 735 split translation zones easily) 737 - Low maintenance overhead (dynamic routing environment with 738 little maintenance of separate routing infrastructure other then 739 management of MPLS/VPNs) 741 - CGN By-pass options (for internal and third party services which 742 exist within the provider domain) 744 - IPv4 Translation Realm overlap support (can reuse IP addresses 745 between zones with some impact to extranet service model) 747 - Simple failover techniques can be implemented with redundant 748 translators, such as using a second default route 750 5.2. Performance 752 The MPLS/VPN CGN model was observed to support basic functions which 753 are typically used by subscribes within an operator environment. A 754 full review of the observed impacts related to CGN (NAT444) are 755 covered in [RFC7021]. 757 6. IANA Considerations 759 This document has no IANA actions. 761 7. Security Considerations 763 An operator implementing CGN using BGP/MPLS IP VPNs should refer to 764 [RFC6888] section 7 for security considerations related to CGN 765 deployments. The operator should continue to employ standard 766 security methods in place for their standard MPLS deployment and can 767 also refer to the security considerations section in [RFC4364] which 768 discusses both control plane and data plane security. 770 8. BGP/MPLS IP VPN CGN Framework Discussion 772 The MPLS/VPN delivery method for a CGN deployment is an effective and 773 scalable way to deliver mass translation services. The architecture 774 avoids the complex requirements of traffic engineering and policy 775 based routing when combining these new service flows to existing IPv4 776 operation. This is advantageous since the NAT44/CGN environments 777 should be introduced with as little impact as possible and these 778 environments are expected to change over time. 780 The MPLS/VPN based CGN architecture solves many of this issues 781 related to deploying this technology in existing operator networks. 783 9. Acknowledgements 785 Thanks to the following people for their comments and feedback: Dan 786 Wing, Chris Metz, Chris Donley, Tina TSOU, Christophoer Liljenstolpe 787 and Tom Taylor. 789 Thanks to the following people for their participating in integrating 790 and testing the CGN environment and for their IPv6 transition 791 guidance: Syd Alam, Richard Lawson, John E Spence, John Jason 792 Brzozowski, Chris Donley, Jason Weil, Lee Howard, Jean-Francois 793 Tremblay 795 10. References 797 10.1. Normative References 799 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 800 Networks (VPNs)", RFC 4364, February 2006. 802 10.2. Informative References 804 [I-D.donley-behave-deterministic-cgn] 805 Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 806 and O. Vautrin, "Deterministic Address Mapping to Reduce 807 Logging in Carrier Grade NAT Deployments", draft-donley- 808 behave-deterministic-cgn-07 (work in progress), January 809 2014. 811 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 812 E. Lear, "Address Allocation for Private Internets", BCP 813 5, RFC 1918, February 1996. 815 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 816 Label Switching Architecture", RFC 3031, January 2001. 818 [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS 819 Multicast Encapsulations", RFC 5332, August 2008. 821 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 822 Infrastructures (6rd) -- Protocol Specification", RFC 823 5969, August 2010. 825 [RFC6037] Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems' 826 Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037, 827 October 2010. 829 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 830 NAT64: Network Address and Protocol Translation from IPv6 831 Clients to IPv4 Servers", RFC 6146, April 2011. 833 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 834 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 835 June 2011. 837 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 838 Stack Lite Broadband Deployments Following IPv4 839 Exhaustion", RFC 6333, August 2011. 841 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 842 VPNs", RFC 6513, February 2012. 844 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 845 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 846 Space", BCP 153, RFC 6598, April 2012. 848 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 849 and H. Ashida, "Common Requirements for Carrier-Grade NATs 850 (CGNs)", BCP 127, RFC 6888, April 2013. 852 [RFC7021] Donley, C., Howard, L., Kuarsingh, V., Berg, J., and J. 853 Doshi, "Assessing the Impact of Carrier-Grade NAT on 854 Network Applications", RFC 7021, September 2013. 856 Authors' Addresses 858 Victor Kuarsingh (editor) 859 Rogers Communications 860 8200 Dixie Road 861 Brampton, Ontario L6T 0C1 862 Canada 864 Email: victor@jvknet.com 865 URI: http://www.rogers.com 866 John Cianfarani 867 Rogers Communications 868 8200 Dixie Road 869 Brampton, Ontario L6T 0C1 870 Canada 872 Email: john.cianfarani@rci.rogers.com 873 URI: http://www.rogers.com