idnits 2.17.1 draft-kuarsingh-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4364], [I-D.ietf-behave-lsn-requirements]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 20, 2012) is 4446 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.weil-shared-transition-space-request' is defined on line 773, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-05 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG V. Kuarsingh, Ed. 3 Internet-Draft J. Cianfarani 4 Intended status: Informational Rogers Communications 5 Expires: August 23, 2012 February 20, 2012 7 CGN Deployment with MPLS/VPNs 8 draft-kuarsingh-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). CGN is a concept 15 also described in [I-D.ietf-behave-lsn-requirements] and describes 16 the model as a dual layer translation model. Although operators may 17 wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near 18 term needs may not be satisfied with an IPv6 deployment alone. This 19 document provides a practical integration model which allows CGN to 20 be integrated into the network meeting the connectivity needs of the 21 customer while being mindful of not disrupting existing services and 22 meeting the technical challenges that CGN brings. The model includes 23 the use of MPLS/VPNs defined in [RFC4364] as a tool to achieve this 24 goal. This document does not intend to defend the merits of CGN. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 23, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. CGN Network Deployment Requirements . . . . . . . . . . . . . 4 63 3.1. Centralized versus Distributed Deployment . . . . . . . . 5 64 3.2. CGN and Traditional IPv4 Service Co-existence . . . . . . 6 65 3.3. CGN By-Pass . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.4. Routing Plane Separation . . . . . . . . . . . . . . . . . 6 67 3.5. Flexible Deployment Options . . . . . . . . . . . . . . . 7 68 3.6. IPv4 Overlap Space . . . . . . . . . . . . . . . . . . . . 7 69 3.7. Transactional Logging for LSN Systems . . . . . . . . . . 7 70 3.8. Additional CGN Requirements . . . . . . . . . . . . . . . 8 71 4. MPLS/VPN based CGN Framework . . . . . . . . . . . . . . . . . 8 72 4.1. Service Separation . . . . . . . . . . . . . . . . . . . . 9 73 4.2. Internal Service Delivery . . . . . . . . . . . . . . . . 10 74 4.2.1. Dual Stack Operation . . . . . . . . . . . . . . . . . 11 75 4.3. Deployment Flexibility . . . . . . . . . . . . . . . . . . 12 76 4.4. Comparison of MPLS/VPN Option versus other CGN 77 Attachment Options . . . . . . . . . . . . . . . . . . . . 13 78 4.4.1. IEEE 802.1Q . . . . . . . . . . . . . . . . . . . . . 13 79 4.4.2. Policy Based Routing . . . . . . . . . . . . . . . . . 14 80 4.4.3. Traffic Engineering . . . . . . . . . . . . . . . . . 14 81 4.4.4. Multiple Routing Topologies . . . . . . . . . . . . . 14 82 5. Experiences . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 6. Basic Integration and Requirements Support . . . . . . . . . . 14 84 7. Performance . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 91 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 94 1. Introduction 96 Operators are faced with near term IPv4 address exhaustion 97 challenges. Many operators may not have a sufficient amount of IPv4 98 addresses in the future to satisfy the needs of their growing 99 customer base. This challenge may also be present before or during 100 an active transition to IPv6 somewhat complicating the overall 101 problem space. 103 To face this challenge, operators may need to deploy CGN (Carrier 104 Grade NAT) as described in [I-D.ietf-behave-lsn-requirements] to help 105 extend the connectivity matrix once IPv4 addresses run out in the 106 network. CGN's addition to the network requires integration in an 107 often running state environment with working IPv4 and/or IPv6 108 services. 110 The addition of the CGN introduces an operator controlled and 111 administered translation layer which needs to be added in a manner 112 which does not overly disrupt existing services. This addition may 113 also include interworking in a dual stack environment where the IPv4 114 path requires translation. 116 This document shows how MPLS/VPNs as described in [RFC4364] can be 117 used to integrate the CGN infrastructure solving key problems faced 118 by the operator. This model has also been tested and validated in 119 real production network models and allows fluid operation with 120 existing IPv4 and IPv6 services. 122 2. Motivation 124 The selection of CGN may be made by an operator based on a number of 125 factors. The overall driver may be the depletion of IPv4 address 126 pools which leaves little to no addresses for IPv4 service growth. 127 IPv6 is considered the strategic answer, but it's applicability and 128 usefulness in many networks is limited by the current access network 129 and consumer home network. These environments often are filled with 130 IPv4-Only equipment which may not be upgradable to IPv6. 132 The ability to replace IPv4-Only equipment may be out of the control 133 of the operator, and even when it's in the administrative control; it 134 poses both cost and technical challenges as operators build out 135 massive programs for equipment retirement or upgrade. Theses issues 136 leave an operator in a precarious position which may lead to the 137 decision to deploy CGN. Other address IPv4 sharing options do exist 138 which are more architecturally desirable, but the practical and 139 workable approach in many cases is a CGN deployment using NAT444. 141 If the operator as has chosen to deploy CGN, they should this in a 142 manner as not to negatively impact the existing IPv4 or IPv6 customer 143 base. This will include solving a number of challenges since 144 customers who's connections require translation will have network 145 routing and flow needs which are different from legacy IPv4 146 connections. 148 The solution will also need to work in a dual stack environment where 149 other options such as DS-Lite [RFC6333] are not yet viable. Even 150 technologies like 6RD [RFC5969] still require an IPv4 connectivity 151 path to service the customer endpoint. The solution will need to 152 address basic Internet connectivity, on-net service offerings, back 153 office management, billing, policy and security models already in 154 place within the operator's network. CGN will often integrate quite 155 readily with the aforementioned requirements where as other 156 transition mechanism may not due to the requirements to support IPv6 157 as the base protocol for IPv4 connectivity. 159 3. CGN Network Deployment Requirements 161 If a service provider is considering a CGN deployment with a provider 162 NAT44 function, there are a number of basic requirements which are of 163 importance. Preliminary requirements may require the following from 164 the incoming CGN system architecture: 166 - Support distributed (sparse) and centralized (dense) deployment 167 models; 169 - Allow co-existence with traditional IPv4 based deployments, 170 which provide global scoped IPs to CPEs; 172 - Provide a framework for CGN by-pass supporting non-translated 173 flows between endpoints within a provider's network; 175 - Provide routing framework which allows the segmentation of 176 routing control and forwarding paths between CGN and non-CGN 177 mediated flows; 179 - Provide flexibility for operators to modify their deployments 180 over time as translation demands change (connections, bandwidth, 181 translation realms/zones and other vectors); 183 - Flexibility should include integration options for common access 184 technologies such as DSL (BRAS), DOCSIS (CMTS), Mobile (GGSN/PGW/ 185 ASN-GW), and Ethernet access; 186 - Support deployment modes that allow for IPv4 address overlap 187 within the operator's network (between various translation realms 188 or zones); 190 - Allow for evolution to future dual-stack and IPv4/IPv6 191 transition deployment modes; 193 - Transactional logging and export capabilities to support 194 auxiliary functions including abuse mitigation; 196 - Support for stateful connection synchronization between 197 translation instances/elements (redundancy); 199 - Support for CGN Shared Space [I-D.weil-shared-transition-space- 200 request] deployment modes if applicable; 202 - Allows for the enablement of CGN functionality (if required) 203 while still minimizing costs and customer impact to the best 204 extend possible; 206 Other requirements may be assessed on a operator-by-operator basis, 207 but those listed above should be considered for any given deployment 208 architecture. 210 3.1. Centralized versus Distributed Deployment 212 Centralized deployments of CGN (longer proximity to end user and/or 213 higher densities of subscribers/connections to CGN instances) differ 214 from distributed deployments of CGN (closer proximity to end user 215 and/or lower densities of subscribers/connections to CGN instances). 216 Service providers will likely deploy CGN translation points more 217 centrally during initial phases. Early deployments will likely see 218 light loading on these new systems since legacy IPv4 services will 219 continue to operate with most endpoints using globally unique IPv4 220 addresses. Exceptional cases which may drive heavy usage in initial 221 stages may include operators who already translate most IPv4 traffic 222 and will migrate to a CGN implementation from legacy firewalls; or a 223 green field deployment which may see quick growth in the number of 224 new IPv4 endpoints which require Internet connectivity. 226 Over time, most providers will likely need to expand and possibly 227 distribute the translation points as demand for the CGN system 228 increases. The extent of the expansion of the CGN infrastructure 229 will depend on factors such as growth in the number of IPv4 230 endpoints, status of IPv6 content on the Internet and the overall 231 progress globally to an IPv6-dominate Internet (reducing the demand 232 for IPv4 connectivity). 234 3.2. CGN and Traditional IPv4 Service Co-existence 236 Newer CGN serviced endpoints will exist alongside endpoints served by 237 traditional IPv4 global IPs. Providers will need to rationalize 238 these environments since both have distinct forwarding needs. 239 Traditional IPv4 services will likely require (or be best served) 240 direct forwarding towards Internet peering points while CGN mediated 241 flows require access to a translator. CGN and non-CGN mediated flows 242 post two fundamentally different forwarding needs. 244 The new CGN environments should not negatively impact the existing 245 IPv4 service base by forcing all traffic to translation enabled 246 network points since many flows do not require translation and this 247 would reduce performance of the existing flows. This would also 248 require massive scaling of the CGN which is a cost and efficiency 249 concern as well. 251 Traffic flow and forwarding efficiency is considered important since 252 networks are under considerable demand to deliver more and more 253 bandwidth without the luxury of needless inefficiencies which can be 254 introduced with CGN. 256 3.3. CGN By-Pass 258 The CGN environment is only needed for flows with translation 259 requirements. Many flows which remain in a service provider 260 environment, do not require translation. Such services include 261 operator offered DNS Services, DHCP Services, NTP Services, Web 262 Caching, Mail, News and other services which are local to the 263 operator's network. 265 The operator may want to leverage opportunities to offer third 266 parties a platform to also provide services without translation. CGN 267 By-pass can be accomplished in many ways, but a simplistic, 268 deterministic and scalable model is preferred. 270 3.4. Routing Plane Separation 272 Many operators will want to engineer traffic separately for CGN flows 273 versus flows which are part of the more traditional IPv4 environment. 274 Many times the routing of these two major flow types differ, 275 therefore route separation may be required. 277 Routing plane separation also allows the operator to utilize other 278 addressing techniques, which may not be feasible on a single routing 279 plane. Such examples include the use of overlapping private address 280 space [RFC1918] or use of other IPv4 space which may overlap globally 281 within the operator's network. 283 3.5. Flexible Deployment Options 285 Service providers operate complex routing environments and offer a 286 variety of IPv4 based services. Many operator environments utilize 287 distributed peering infrastructures for transit and peering and these 288 may span large geographical areas and regions. A CGN solution should 289 offer the operator an ability to place CGN translation points at 290 various points within their network. 292 The CGN deployment should also be flexible enough to change over time 293 as demand for translation services increase. In turn, the deployment 294 will need to then adapt as translation demand decreases caused by the 295 transition of flows to IPv6. Translation points should be able to be 296 placed and moved with as little re-engineering effort as possible 297 minimizing the risks to the customer base. 299 Depending on hardware capabilities, security practices and IPv4 300 address availability, the translation environments my need to be 301 segmented and/or scaled over time to meet organic IPv4 demand growth. 302 Operators will want to seek deployment models which are conducive to 303 meeting these goals as well. 305 3.6. IPv4 Overlap Space 307 IP address overlap for CGN translation realms may be required if 308 insufficient IPv4 addresses are available within the service provider 309 environment to assign internally unique IPs to the CGN customer base 310 . The CGN deployment should provide mechanisms to manage IPv4 311 overlap if required. 313 3.7. Transactional Logging for LSN Systems 315 CGNs may require transactional logging since the source IP and 316 related transport protocol information is not easily visible to 317 external hosts and system. 319 If needed, the CGN systems should be able to generate logs which 320 identify 'internal' host parameters (i.e. IP/Port) and associated 321 them to external translated parameters imposed by the translator. 322 The logged information should be stored on the CGN hardware and/or 323 exported to an external system for processing. Operators may need to 324 keep track of this information (securely) to meet regulatory and/or 325 legal obligations. Further information can be found in [I-D.ietf- 326 behave-lsn-requirements] with respect to CGN logging requirements 327 (Logging Section). 329 3.8. Additional CGN Requirements 331 The CGN platform will also need to meet the needs of additional 332 requirements such as Bulk Port Allocation and other CGN device 333 specific functions. These additional requirements are captured 334 within [I-D.ietf-behave-lsn-requirements]. 336 4. MPLS/VPN based CGN Framework 338 The MPLS/VPN [RFC4364] framework for CGN segregates the 'pre- 339 translated' realms within the service provider space into layer-3 340 MPLS/VPNs. The operator can deploy a single realm for all CGN based 341 flows, or can deploy multiple realms based on translation demand and 342 other factors such as geographical proximity. A realm in this model 343 refers to a 'VPN' which shares a unique RD/RT combination, routing 344 plane and forwarding behaviours. 346 The MPLS/VPN infrastructure provides control plane and forwarding 347 separation for the traditional IPv4 service environment and CGN 348 environment(s). The separation allows for routing information (such 349 as default routes) to be propagated separately for CGN and non-CGN 350 based customer flows. Traffic can be efficiently routed to the 351 Internet for normal flows, and routed directly to translators for CGN 352 mediated flows. Although many operators may run a "default-route- 353 free" core, IPv4 flows which require translation must obviously be 354 routed first to a translator, so a default route is acceptable for 355 the pre-translated realms. 357 The physical location of the VRF Termination point for a MPLS/VPN 358 enabled CGN can vary and be located anywhere within the operator's 359 network. This model fully virtualizes the translation service from 360 the base IPv4 forwarding environment which will likely carrying 361 Internet bound traffic. The base IPv4 environment can continue to 362 service traditional IPv4 customer flows plus post translated CGN 363 flows. 365 Figure 1 provides a view of the basic model. The Access node 366 provides CPE access to either the CGN VRF or the Global Routing 367 Table, depending on whether the customer receives a private or public 368 IP. Translator mediated traffic follows an MPLS LSP which can be 369 setup dynamically and can span one hop, or many hops (with no need 370 for complex routing policies). Traffic is then forwarded to the 371 translator (shown below) which can be an external appliance or 372 integrated into the VRF Termination (Provider Edge) router. Once 373 traffic is translated, it is forwarded to the global routing table 374 for general Internet forwarding. The Global Routing table can also 375 be a separate VRF (Internet Access VPN/VRF) should the provider 376 choose to implement their Internet based services in that fashion. 377 The translation services are effectively overlaid onto the network, 378 but are maintained within a separate forwarding and control plane. 380 Access Node VRF Termination LSN 381 +-----------+ +-----------+ +-----------+ 382 | | | | | | 383 CPE | +-------+ | | +-------+ | | +-------+ | 384 +----+ | | | | LSP | | | | IP | | | | 385 | --+---+-+->VRF--+-+-----+-+->VRF--+-+----+-+-> | | 386 +----+ | | | | | | | | | | | | 387 | +-------+ | | +-------+ | | | | | 388 | | | | | | XLATE | | 389 | | | | | | | | 390 CPE | +-------+ | | +-------+ | | | | | 391 +----+ | | | | | | | | IP | | | | 392 | --+---+-+->GRT | | | | GRT<-+-+----+-+-- | | 393 +----+ | | | | | | | | | | | | | | 394 | +---+---+ | | +---+---+ | | +-------+ | 395 +-----+-----+ +-----+-----+ +-----------+ 396 | | 397 | | IPv4 398 | | IP +---------+ 399 | +------------+-> | 400 | IP | GRT | 401 +------------------------------+-> | 402 +---------+ 404 Figure 1: Basic MPLS/VPN CGN Model 406 If more then one VRF (translation realm) is used within the 407 operator's network, each VPN instance can manage CGN flows 408 independently for the respective realm. Various redundancy models 409 can be used within this architecture to support failover from one 410 physical CGN hardware instance to another. If state information 411 needs to be passed or maintained between hardware instances, the 412 vendor would need to enable this feature in a suitable manner. 414 4.1. Service Separation 416 The MPLS/VPN CGN framework supports route separation. The 417 traditional IPv4 flows can be separated at the access node (Initial 418 Layer 3 service point) from those which require translation. This 419 type of service separation is possible on common technologies used 420 for Internet access within many operator networks. Service 421 separation can be accomplished on common access technology including 422 those used for DOCSIS (CMTS), Ethernet Access, DSL (BRAS), and Mobile 423 Access (GGSN/ASN-GW) architectures. 425 4.2. Internal Service Delivery 427 Internal services can be delivered directly to the privately 428 addressed endpoint within the CGN domain without translation. This 429 can be accomplished using direct route exchange (import/export) 430 between the CGN VRFs and the Services VRFs. The previous statement 431 assumes the provider puts key services into a VRF for simple route 432 exchange. This model allows the provider to maintain separate 433 forwarding rules for translated flows, which require a pass through 434 the translator to reach external network entities, versus those flows 435 which need to access internal services. This operational detail can 436 be advantageous for a number of reasons. 438 First, the provider can reduce the load on the translator since 439 internal services do not need to be factored into the scaling of the 440 CGN hardware. Secondly, more direct forwarding paths can be 441 maintained providing better network efficiency. Thirdly, geographic 442 locations of the translators and the services infrastructure can be 443 deployed in a location in an independent manner. Additionally, the 444 operator can allow CGN subject endpoints to be accessible via an 445 untranslated path reducing the complexities of provider initiated 446 management flows. This last point is of key interest since NAT 447 removes transparency to the end device in normal cases. 449 Figure 2 below shows how internal services are provided untranslated 450 since flows are sent directly from the access node to the services 451 node/VRF via an MPLS LSP. This traffic is not forwarded to the CGN 452 translator and therefore is not subject to problematic behaviours 453 related to NAT. The services VRF contains routing information which 454 can be "imported" into the access node VRF and the CGN VRF routing 455 information can be "imported" into the Services VRF. 457 Access Node VRF Termination LSN 458 +-------------+ +-----------+ +----------+ 459 | | | | | | 460 CPE | +---------+ | | +-------+ | | +------+ | 461 +-----+ | | | | | | | | | | | | 462 | --+--+-+-> VRF --+-+--+ | | VRF | | | | | | 463 +-----+ | | | | | | | | | | | | | 464 | +---------+ | | | +-------+ | | | | | 465 | | | | | | |XLATE | | 466 | | | | | | | | | 467 CPE | +---------+ | | | +-------+ | | | | | 468 +-----+ | | | | | | | | | | | | | 469 | --+--+-+-> GRT | | | | | GRT | | | | | | 470 +-----+ | | | | | | | | | | | | | | 471 | +----+----+ | | | +-------+ | | +------+ | 472 +------+------+ | +-----------+ +----------+ 473 | | 474 | | IPv4 475 | | +-----------+ 476 | +---------------+->Services | 477 | | VRF | 478 .-------------------------+-> | | 479 +-----+-----+ 480 | 481 +-----V-----+ 482 | | 483 | Local | 484 | Content | 485 +-----------+ 487 Figure 2: Internal Services and CGN By-Pass 489 This demonstrates the ability to offer CGN By-Pass in a simple and 490 deterministic manner without the need of policy based routing or 491 traffic engineering. 493 4.2.1. Dual Stack Operation 495 The MPLS/VPN CGN model can also be used in conjunction with IPv4/IPv6 496 dual stack service modes. Since many providers will use CGNs on an 497 interim basis while IPv6 matures within the global Internet or due to 498 technical constraints, a dual stack option is of strategic 499 importance. Operators can offer this dual stack service for both 500 traditional IPv4 (global IP) endpoints and CGN mediated endpoints. 502 Operators can separate the IP flows for IPv4 and IPv6 traffic, or use 503 other routing techniques to move IPv6 based flows towards the GRT 504 (Global Routing Table or Instance) while allowing IPv4 flows to 505 remain within the IPv4 CGN VRF for translator services. 507 The Figure 3 below shows how IPv4 translation services can be 508 provided alongside IPv6 based services. The model shown allows the 509 provider to enable CGN to manage IPv4 flows (translated) and IPv6 510 flows are routed without translation efficiently towards the 511 Internet. Once again, forwarding of flows to the translator does not 512 impact IPv6 flows which do not require this service. 514 Access Node VRF Termination LSN 515 +-----------+ +-----------+ +-----------+ 516 | | | | | | 517 CPE | +-------+ | | +-------+ | | +-------+ | 518 +-----+ | | | |LSP| | | | IP | | | | 519 | --+--+-+->VRF--+-+---+-+->VRF--+-+----+-+> | | 520 |IPv4 | | | | | | | | | | | | | 521 | | | +-------+ | | +-------+ | | | | | 522 +-----| | | | | | | XLATE | | 523 |IPv6 | | | | | | | | | 524 | | | +-------+ | | +-------+ | | | | | 525 | | | | IPv6 | | | | IPv4 | | IP | | | | 526 | --+--+-+->GRT | | | | GRT<-+-+----+-+-- | | 527 +-----+ | | | | | | | | | | | | | | 528 | +---+---+ | | +---+---+ | | +-------+ | 529 +-----+-----+ +-----+-----+ +-----------+ 530 | | 531 | | +-----------+ 532 | | IP | IPv4 | 533 | +----------+-> GRT | 534 | +-----------+ 535 | 536 | 537 | 538 | IP +-----------+ 539 +--------------------------+-> IPv6 | 540 | GRT | 541 +-----------+ 543 Figure 3: CGN with IPv6 Dual Stack Operation 545 4.3. Deployment Flexibility 547 The CGN translator services can be moved, separated or segmented (new 548 translation realms) without the need to change the overall 549 translation design. Since dynamic LSPs are used to forward traffic 550 from the access nodes to the translation points, the physical 551 location of the VRF termination points can vary and be changed 552 easily. 554 This type of flexibility allows the service provider to initially 555 deploy more centralized translation services based on relatively low 556 loading factors, and distribute the translation points over time to 557 improve network traffic efficiencies and support higher translation 558 load. 560 Although traffic engineered paths are not required within the MPLS/ 561 VPN deployment model, nothing precludes an operator from using 562 technologies like MPLS with Traffic Engineering [RFC3031]. 563 Additional routing mechanisms can be used as desired by the provider 564 and can be seen as independent. There is no specific need to 565 diversify the existing infrastructure in most cases. 567 4.4. Comparison of MPLS/VPN Option versus other CGN Attachment Options 569 Other integration architecture options exist which can attach CGN 570 based service flows to a translator instance. Alternate options 571 which can be used to attach such services include: 573 - IEEE 802.1Q for direct attachment to a next hop translator; 575 - Policy Based Routing (Static) to direct translation bound 576 traffic to a network based translator; 578 - Traffic Engineering or; 580 - Multiple Routing Topologies 582 4.4.1. IEEE 802.1Q 584 IEEE 802.1Q can be used to associate separated traffic from the 585 access node to the next hop router's CGN instance. This technology 586 option may limit the CGN placement to the next hop router unless a 587 second technology option is paired with it to extend connectivity 588 deeper in the network. 590 This option is most effective if CGN instances are placed directly 591 upstream of the access node. Distributed CGN instance placement is 592 not likely an initial stage of the CGN deployment due to cost and 593 demand factors. 595 4.4.2. Policy Based Routing 597 Policy Based Routing (PBR) provides another option to direct CGN 598 mediated flows to a translator. PBR options, although possible, are 599 difficult to maintain (static policy) and must be configured 600 throughout the network with considerable maintenance overhead. 602 More centralized deployments may be difficult or too onerous to 603 deploy using Policy Based Routing methods. Policy Based Routing 604 would not achieve route separation (unless used with others options), 605 and may add complexities to the providers' routing environment. 607 4.4.3. Traffic Engineering 609 Traffic Engineering can also be used to direct traffic from an access 610 node towards a translator. Traffic Engineering, like MPLS-TE, may be 611 difficult to setup and maintain. Traffic Engineering provides 612 additional benefits if used with MPLS by adding potentials for faster 613 path re-convergence. Traffic Engineering paths would need to be 614 updated and redefined overtime as CGN translation points are 615 augmented or moved. 617 4.4.4. Multiple Routing Topologies 619 Multiple routing topologies can be used to direct CGN based flows to 620 translators. This option would achieve the same basic goal as the 621 MPLS/VPN option but with additional implementation overhead and 622 platform configuration complexity. Since operator based translation 623 is expected to have an unknown lifecycle, and may see various degrees 624 of demand (dependant on operator IPv4 Global space availability and 625 shift of traffic to IPv6), it may be too large of an undertaking for 626 the provider to enabled this as their primary option for CGN. 628 5. Experiences 630 6. Basic Integration and Requirements Support 632 The MPLS/VPN CGN environment has been successfully integrated into 633 real network environments utilizing existing network service delivery 634 mechanisms. It solves many issues related to provider based 635 translation environments, while still subject to problematic 636 behaviours inherent within NAT. 638 Key issues which are solved or managed with the MPLS/VPN option 639 include: 641 - Centralized and Distributed Deployment model support 643 - Routing Plane Separation for CGN flows versus traditional IPv4 644 flows 646 - Flexible Translation Point Design (can relocate translators and 647 split translation zones easily) 649 - Low maintenance overhead (dynamic routing environment with 650 little maintenance of separate routing infrastructure other then 651 management of MPLS/VPNs) 653 - CGN By-pass options (for internal and third party services which 654 exist within the provider domain) 656 - IPv4 Translation Realm overlap support (can reuse IP addresses 657 between zones with some impact to extranet service model) 659 - Simple failover techniques can be implemented with redundant 660 translators, such as using a second default route 662 7. Performance 664 The MPLS/VPN CGN model was observed to support basic functions which 665 are typically used by customers within an operator environment. 666 Examples of successful operation include: 668 - Traditional Web (HTTP) Surfing (client initiated) 670 - Internet Video Streaming 672 - HTTP Based Client Connections 674 - High Connection Count sites (i.e. Google Maps) 676 - Email Transaction Support (POP, IMAP, SMTP) 678 - Instant Messaging Support (Online Status, File transfers, text 679 chat) 681 - ICMP Operation (client initiated Echo, Traceroute) 683 - Peer to Peer application support (download) 685 - DNS (based on services extranet option, but was problematic when 686 passed through a translator) 688 CGNs are still subject to problematic connectivity even within the 689 MPLS/VPN technology approach. Problems which arise, or are not 690 inherently addressed in this model include: 692 - Inward services from the Internet to the CPE 694 - Web session tracking 696 - Restricting usage and/or access based on source IP 698 - Abuse mitigation (masquerade of potential offenders) 700 - Increased network or server IDS false positives 702 - Increased customer risk for session hijacking 704 - Exceeding firewall TCP/UDP limits 706 - Customer identification (external site) 708 - Poor source based load balancing 710 - Customer usage tracking / Ad insertion 712 - Other applications or operations may be negatively impacted 714 8. IANA Considerations 716 There are not specific IANA considerations known at this time with 717 the architecture described herein. Should a provide choose to use 718 non-assigned IP address space within their translation realms, then 719 considerations may apply. 721 9. Security Considerations 723 The same security considerations would typically exist for CGN 724 deployments when compared with traditional IPv4 based services. With 725 the MPLS/VPN model, the operator would want to consider security 726 issues related to offering IP services over MPLS. 728 If a provider plans to operate the pre-translation realm (CPE towards 729 translator IPv4 zone) as a non-public like network, then additional 730 security measures may be needed to secure this environment. It is 731 however the position in this document that CGN realms are public 732 domains which utilize non-Internet routable IP addresses for endpoint 733 addressing. 735 10. Conclusions 737 The MPLS/VPN delivery method for a CGN deployment is an effective and 738 scalable way to deliver mass translation services. The architecture 739 avoids the complex requirements of traffic engineering and policy 740 based routing when combining these new service flows to existing IPv4 741 operation. This is advantageous since the NAT44/CGN environments 742 should be introduced with as little impact as possible and these 743 environments are expected to change over time. 745 The MPLS/VPN based CGN architecture solves many of this issues 746 related to deploying this technology in existing operator networks. 748 11. Acknowledgements 750 Thanks to the following people for their participating in integrating 751 and testing the CGN environment: Chris Metz, Syd Alam, Richard 752 Lawson, John E Spence. 754 Additional thanks for the following people for the guidance on IPv6 755 transition considerations: John Jason Brzozowski, Chris Donley, Jason 756 Weil, Lee Howard, Jean-Francois Tremblay 758 12. References 760 12.1. Normative References 762 [I-D.ietf-behave-lsn-requirements] 763 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 764 and H. Ashida, "Common requirements for Carrier Grade NATs 765 (CGNs)", draft-ietf-behave-lsn-requirements-05 (work in 766 progress), November 2011. 768 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 769 Networks (VPNs)", RFC 4364, February 2006. 771 12.2. Informative References 773 [I-D.weil-shared-transition-space-request] 774 Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 775 M. Azinger, "IANA Reserved IPv4 Prefix for Shared Address 776 Space", draft-weil-shared-transition-space-request-15 777 (work in progress), February 2012. 779 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 780 E. Lear, "Address Allocation for Private Internets", 781 BCP 5, RFC 1918, February 1996. 783 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 784 Label Switching Architecture", RFC 3031, January 2001. 786 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 787 Infrastructures (6rd) -- Protocol Specification", 788 RFC 5969, August 2010. 790 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 791 Stack Lite Broadband Deployments Following IPv4 792 Exhaustion", RFC 6333, August 2011. 794 Authors' Addresses 796 Victor Kuarsingh (editor) 797 Rogers Communications 798 8200 Dixie Road 799 Brampton, Ontario L6T 0C1 800 Canada 802 Email: victor.kuarsingh@gmail.com 803 URI: http://www.rogers.com 805 John Cianfarani 806 Rogers Communications 807 8200 Dixie Road 808 Brampton, Ontario L6T 0C1 809 Canada 811 Email: john.cianfarani@rci.rogers.com 812 URI: http://www.rogers.com