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