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