idnits 2.17.1 draft-ietf-softwire-dual-stack-lite-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- == There are 19 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 9 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 738 has weird spacing: '... |Host a.b.c...' == Line 1297 has weird spacing: '...routing domai...' -- The document date (March 3, 2009) is 5526 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.despres-sam' is defined on line 1295, but no explicit reference was found in the text == Unused Reference: 'UPnP-IGD' is defined on line 1357, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-cheshire-nat-pmp-03 == Outdated reference: A later version (-03) exists of draft-despres-sam-01 == Outdated reference: A later version (-05) exists of draft-dhankins-softwire-tunnel-option-01 == Outdated reference: A later version (-05) exists of draft-nishitani-cgn-01 == Outdated reference: A later version (-10) exists of draft-ymbk-aplusp-02 -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Durand 3 Internet-Draft Comcast 4 Intended status: Standards Track R. Droms 5 Expires: September 4, 2009 Cisco 6 B. Haberman 7 JHU APL 8 J. Woodyatt 9 Apple 10 March 3, 2009 12 Dual-stack lite broadband deployments post IPv4 exhaustion 13 draft-ietf-softwire-dual-stack-lite-00 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 4, 2009. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 The common thinking for more than 10 years has been that the 52 transition to IPv6 will be based on the dual stack model and that 53 most things would be converted this way before we ran out of IPv4. 55 It has not happened. The IANA free pool of IPv4 addresses will be 56 depleted soon, well before any significant IPv6 deployment will have 57 occurred. 59 This document revisits the dual-stack model and introduces the dual- 60 stack lite technology aimed at better aligning the costs and benefits 61 of deploying IPv6. Dual-stack lite will provide the necessary bridge 62 between the two protocols, offering an evolution path of the Internet 63 post IANA IPv4 depletion. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Requirements language . . . . . . . . . . . . . . . . . . 4 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.3. IPv4 exhaustion coming sooner than expected . . . . . . . 4 71 2. Handling the legacy . . . . . . . . . . . . . . . . . . . . . 5 72 2.1. Legacy edges of the Internet for broadband customers . . . 5 73 2.2. Content and Services available on the Internet . . . . . . 5 74 2.3. Additional impact on new broadband deployment . . . . . . 5 75 2.4. Burden on service providers . . . . . . . . . . . . . . . 5 76 3. Expectations for dual-stack lite deployment . . . . . . . . . 6 77 3.1. Expectations for home gateway based scenarios . . . . . . 6 78 3.2. Expectations for devices directly connected to the 79 broadband service provider network . . . . . . . . . . . . 6 80 3.3. Application expectations . . . . . . . . . . . . . . . . . 7 81 3.4. Service provider network expectations . . . . . . . . . . 7 82 4. Dual-stack lite . . . . . . . . . . . . . . . . . . . . . . . 7 83 4.1. Domain of application . . . . . . . . . . . . . . . . . . 8 84 4.2. Dual-stack lite interface . . . . . . . . . . . . . . . . 8 85 4.3. Dual-stack lite device . . . . . . . . . . . . . . . . . . 8 86 4.4. Dual-stack lite home router . . . . . . . . . . . . . . . 8 87 4.5. Dual-stack lite router . . . . . . . . . . . . . . . . . . 9 88 4.6. Discovery of the dual-stack lite carrier-grade NAT 89 device . . . . . . . . . . . . . . . . . . . . . . . . . . 9 90 4.7. Dual-stack lite carrier-grade NAT . . . . . . . . . . . . 9 91 5. Example architectures . . . . . . . . . . . . . . . . . . . . 10 92 5.1. Router-based architecture . . . . . . . . . . . . . . . . 10 93 5.1.1. Example message flow . . . . . . . . . . . . . . . . . 12 94 5.1.2. Translation details . . . . . . . . . . . . . . . . . 16 95 5.2. Host based architecture . . . . . . . . . . . . . . . . . 17 96 5.2.1. Example message flow . . . . . . . . . . . . . . . . . 19 97 5.2.2. Translation details . . . . . . . . . . . . . . . . . 23 98 6. Encapsulations . . . . . . . . . . . . . . . . . . . . . . . . 23 99 7. Carrier-grade NAT considerations . . . . . . . . . . . . . . . 23 100 7.1. Per customer port allocation . . . . . . . . . . . . . . . 24 101 7.2. ALG . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 102 7.3. UPnP . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 103 7.4. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 104 8. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 26 105 8.1. Multicast considerations . . . . . . . . . . . . . . . . . 26 106 8.2. 3rd party carrier-grade NAT . . . . . . . . . . . . . . . 26 107 8.3. Interface initialization . . . . . . . . . . . . . . . . . 27 108 9. Comparison with an architecture with multiple-layers of NAT . 27 109 10. Comparison with NAT-PT (or its potential replacements) . . . . 28 110 11. Comparison with DSTM . . . . . . . . . . . . . . . . . . . . . 29 111 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 112 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 113 14. Security Considerations . . . . . . . . . . . . . . . . . . . 29 114 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 115 15.1. Normative references . . . . . . . . . . . . . . . . . . . 30 116 15.2. Informative references . . . . . . . . . . . . . . . . . . 30 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 119 1. Introduction 121 This document presents views on IP deployments after the exhaustion 122 of IPv4 addresses and some of the necessary technologies to achieve 123 it. The views expressed are the authors' personal opinions and in no 124 way imply that Comcast plans to deploy or that Cisco will implement 125 the technologies described here. 127 1.1. Requirements language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 1.2. Terminology 135 This document makes a distinction between a dual-stack capable and a 136 dual-stack provisioned device. The former is a device that has code 137 that implements both IPv4 and IPv6, from the network layer to the 138 applications. The later is a similar device that has been 139 provisioned with both an IPv4 and an IPv6 address on its 140 interface(s). This document will also further refine this notion by 141 distinguishing between interfaces provisioned directly by the service 142 provider from those provisioned by the customer. 144 1.3. IPv4 exhaustion coming sooner than expected 146 Global public IPv4 addresses coming from the IANA free pool are 147 running out faster than many predicted a few years ago. The current 148 model shows that exhaustion could happen as early as 2010 or 2011. 149 See http://ipv4.potaroo.net for more details. Those projection are 150 based on the assumption that tomorrow is going to be very similar to 151 today, i.e., looking at recent address consumption figures is a good 152 indicator of future consumption patterns. This of course, does not 153 take into account any new large scale deployment of IP technology or 154 any human reaction when facing an upcoming shortage. 156 The prediction of the exact date of exhaustion of the IANA free pool 157 is outside the scope of this document, however one conclusion must be 158 drawn from that study: there will be in the near future a point where 159 new global public IPv4 addresses will not be available in large 160 enough quantity thus any new broadband deployment may have to 161 consider the option of not provisioning any (global) IPv4 addresses 162 to the WAN facing interface of edge devices. However, the classic 163 IPv6 deployment model known as "dual stack provisioning" can be a non 164 starter in such environments. 166 2. Handling the legacy 168 The dual-stack lite technology is intended for maintaining 169 connectivity to legacy IPv4 devices and networks after the exhaustion 170 of the IPv4 address space while service provider networks make a 171 transition to IPv6-only deployments. This section describes some of 172 the specific legacy scenarios addressed by dual-stack lite. 174 2.1. Legacy edges of the Internet for broadband customers 176 Broadband home customers have a mix and match of IP enabled devices. 177 The most recent operating systems (e.g., Windows Vista, Mac OS X and 178 various versions of Linux) can operate in an IPv6-only environment; 179 however most of the legacy devices can't. Windows XP, for example, 180 cannot process DNS requests over IPv6 transport. Expecting broadband 181 customers to massively upgrade their software (and in most cases the 182 corresponding hardware) to deploy IPv6 is a very tall order. 184 2.2. Content and Services available on the Internet 186 IPv6 deployment has taken a very long time to take off, so the 187 current situation is that almost none of the content and services 188 available on the Internet are accessible over IPv6. This situation 189 will probably change in the future, but for now, one has to make the 190 assumption that most of the traffic generated by (and to) broadband 191 customers will be sent to (and originated by) IPv4 nodes. 193 2.3. Additional impact on new broadband deployment 195 Even when considering new, green field, broadband deployments, such 196 as always-on 4G, service providers have to face the same situation as 197 described above, that is, content and services available on the 198 Internet are, today, generally accessible only over IPv4 and not 199 IPv6. This makes adoption of IPv6 for green field deployment 200 difficult. Solutions like NAT-PT, now deprecated, do not provide, as 201 of today, a satisfying and scalable answer. 203 2.4. Burden on service providers 205 As a conclusion, broadband service providers may be faced with the 206 situation where they have IPv4 customers who need to communicate with 207 IPv4 servers on the Internet but may not have any IPv4 addresses left 208 to assign to those customers. A service providers may also be in a 209 situation where it wants to deploy IPv6 in its core network, avoiding 210 the use of scarce IPv4 addresses. However, without some form of 211 backward compatibility with IPv4, the cost and the benefits of 212 deploying IPv6 are not aligned, making incremental IPv6 deployment 213 very difficult. 215 3. Expectations for dual-stack lite deployment 217 3.1. Expectations for home gateway based scenarios 219 This section mainly address home style networks characterized by the 220 presence of a home gateway. 222 Legacy, unmodified, IPv4-only devices inside the home network are 223 expected to keep using RFC1918 address space, a-la 192.168.0.0/16 and 224 should be able to access the IPv4 Internet in a similar way they do 225 it today through a home gateway IPv4 NAT. 227 Unmodified IPv6 capable devices are expected to be able to reach 228 directly the IPv6 Internet, without going through any translation. 229 It is expected that most IPv6 capable devices will also be IPv4 230 capable and will simply be configured with an IPv4 RFC1918 style 231 address within the home network and access the IPv4 Internet the same 232 way as the legacy IPv4-only devices within the home. 234 IPv6-only devices that do not include code for an IPv4 stack are 235 outside of the scope of this document. 237 It is expected that the home gateway is either software upgradable, 238 replaceable or provided by the service provider as part of a new 239 contract. Outside of early IPv6 deployments done prior to IPv4 240 exhaustion using some form of tunnel, this is pretty much a 241 requirement to deploy any IPv6 service to the home. It is expected 242 that this home gateway will be a dual stack capable device that would 243 only be provisioned with IPv6 on its WAN side. IPv4 and IPv6 are 244 expected to be locally provisioned on any LAN interfaces of such 245 devices. IPv4 addresses on such interfaces are expected to be 246 RFC1918. The key point here is that the service provider will not 247 provision any IPv4 addresses for those home gateway devices. 249 3.2. Expectations for devices directly connected to the broadband 250 service provider network 252 Under this deployment model, devices directly connected to the 253 broadband service provider network without the presence of a home 254 gateway will have to be dual stack capable devices. The service 255 provider facing interface(s) of such device will only be provisioned 256 with IPv6. IPv4 may or may not be provisioned locally on other 257 interfaces of such devices. Similarly to the above section, the key 258 point here is that the service provider will not provision any IPv4 259 addresses for those directly connected devices. 261 It is expected that directly connected devices will implement code to 262 support the dual-stack lite functionality. The minimum support 263 required is an IPv4 over IPv6 tunnel. 265 IPv4-only devices and IPv6-only devices are specifically left out of 266 scope for this document. It is expected that most modern device 267 directly connected to the service provider network would not have 268 memory constraints to implement both stack. 270 3.3. Application expectations 272 Most applications that today work transparently through an IPv4 home 273 gateway NAT should keep working the same way. However, it is not 274 expected that applications that requires specific port assignment or 275 port mapping from the NAT box will keep working. Details and 276 recommendations for application behavior are outside the scope of 277 this document and should be discussed in the behave working group. 279 3.4. Service provider network expectations 281 The dual-stack lite deployment model is based on the notion that IPv4 282 addresses will be shared by several customers. This implies that the 283 NAT functionality will move from the home gateway to a device hosted 284 within the service provider network. It is important to observe that 285 this functionality does not have to be performed deep in the core of 286 the network and that it might be better implemented close to the 287 aggregation point of customer traffic. 289 4. Dual-stack lite 291 The core ideas behind dual-stack lite are: 293 o Move from a deployment model where a globally unique IPv4 address 294 is provisioned per customer and shared among several devices 295 within that customer premise to a deployment model where that 296 globally unique IPv4 address is shared among many customers 298 o Provide transport of IPv4 traffic to customers over a core network 299 that uses only IPv6 301 Instead of relying on a cascade of NATs or NAT-PT, the dual-stack 302 lite model is built on IPv4 over IPv6 tunnels to cross the network to 303 reach a carrier-grade IPv4-IPv4 NAT. As such, it simplifies the 304 management of the service provider network by using only IPv6 and 305 provides the customer the benefit of having only one layer of NAT. 306 The additional benefit of this model is to gradually introduce IPv6 307 in the Internet by making it virtually backward compatible with IPv4. 309 4.1. Domain of application 311 The dual-stack lite deployment model has been designed with broadband 312 networks in mind. It is certainly applicable to other domains 313 although the authors do not make any specific claim of suitability. 315 4.2. Dual-stack lite interface 317 A dual-stack lite interface on a dual-stack capable device is modeled 318 as a point to point IPv4 over IPv6 tunnel. Its configuration 319 requires that the device is provisioned with IPv6 but does not 320 require it to be provisioned with a global IPv4 by the service 321 provider. 323 Any locally unique IPv4 address can be configured on the subscriber 324 network end of the dual-stack lite tunnel. In the case of dual-stack 325 lite in which the tunnel endpoint is in a host Section 5.2, it is 326 recommended that dual-stack lite implementations use any address 327 a.b.c.d in the well known range e.f.g.h/p (to be defined by IANA) but 328 the first one (all-zero address in the reserved subnet) as the IPv4 329 host side of the tunnel and the last one of the same range as the 330 address of the IPv4 default gateway, with a netmask to cover a /p 331 network. 333 Note 1: on a multi-home node, several dual-stack like interfaces 334 could end-up being configured. Each of those interfaces should be 335 configured with a different IPv4 address taken out of the reserved 336 range. 338 Note 2: because of this static configuration using well known values, 339 there is no need to run a DHCPv4 client on a Dual-stack lite 340 interface. 342 The service provider network end point of a dual-stack lite interface 343 is the IPv6 address of a dual-stack lite carrier-grade NAT within the 344 service provider network. 346 4.3. Dual-stack lite device 348 A dual-stack lite device is a dual-stack capable device implementing 349 a dual-stack lite interface. In the absence of better routing 350 information, a dual-stack lite device will configure a static IPv4 351 default route over the dual-stack lite interface. 353 4.4. Dual-stack lite home router 355 A dual-stack lite home router is a dual-stack capable home router 356 implementing a dual-stack lite interface layered on top of its WAN 357 interface. In the absence of better routing information, a dual- 358 stack lite home router will configure a static IPv4 default route 359 over the dual-stack lite interface. The dual-stack lite home router 360 can use any IPv4 address a.b.c.d out of the e.f.g.h/p prefix (TBD by 361 IANA) to source its own IPv4 packets, embedded into the IPv6 tunnel. 362 If the dual-stack lite home router need to configure a router 363 pointing to an IPv4 default router, it can use the last address in 364 the e.f.g.h/p (TBD by IANA) range for that purpose, with a netmask to 365 cover a /p (TBD by IANA) network. 367 Note: a dual-stack lite home router SHOULD NOT perform any IPv4 368 address translation. It should simply act as a router and pass 369 packets from the LAN to the dual-stack lite interface and back 370 without changing any address. The dual-stack lite router will have 371 to take into account the lowered MTU of the tunnel and possibly 372 perform IPv4 fragmentation. 374 4.5. Dual-stack lite router 376 The concept of a dual-stack lite home router can be extended to any 377 IPv4 router serving as a gateway between a leaf IP domain and the 378 rest of the Internet. 380 4.6. Discovery of the dual-stack lite carrier-grade NAT device 382 The IPv6 address of a dual-stack lite carrier-grade NAT device can be 383 configured on a dual-stack lite interface using a variety of methods, 384 ranging from an out-of-band mechanism, manual configuration, a to-be- 385 defined DHCPv6 option [I-D.dhankins-softwire-tunnel-option] or a to- 386 be-defined IPv6 router advertisement. It is expected that over time 387 some or all the above methods, as well as others, will be defined. 388 The requirements and specifications of such methods are out of scope 389 for this document. 391 4.7. Dual-stack lite carrier-grade NAT 393 A dual-stack lite carrier grade NAT is a special IPv4 to IPv4 NAT 394 deployed within the service provider network. It is reachable by 395 customers via a series of point to point IPv4 over IPv6 tunnels. 397 A dual-stack lite carrier-grade NAT uses a combination of the IPv6 398 source address of the tunnel and the inner IPv4 source address to 399 establish and maintain the IPv4 NAT mapping table. 401 A dual-stack lite carrier-grade NAT does not have to perform any 402 IPv6-IPv6, IPv6-IPv4 or IPv4-IPv6 NAT. 404 A dual-stack lite carrier-grade NAT can use the last IPv4 address of 405 the range e.f.g.h/p (TBD by IANA) in the IPv4 ICMP packets it will 406 originate toward a dual-stack lite client to enable meaningful ping 407 and traceroute results. 409 5. Example architectures 411 The underlying technology behind dual-stack lite is the combination 412 of two well-known technologies: NAT and tunneling. This combination 413 can be best described using the terminology developed in the softwire 414 working group as Softwire NAT, or SNAT. 416 Two architectures can be deployed for dual-stack lite. One is 417 targeting the legacy installed base of IPv4 only hosts (and dual- 418 stack capable hosts) sitting behind a gateway. The second is 419 targeting dual-stack capable hosts initiating the tunnel themselves. 421 5.1. Router-based architecture 423 This architecture is targeted at residential broadband deployments 424 but can be adapted easily to other types of deployment where the 425 installed base of IPv4-only device is important. 427 As illustrated in Figure 1, this dual-stack lite deployment model 428 consists of three components: the dual-stack lite home router, the 429 dual-stack lite carrier-grade NAT and a softwire between the softwire 430 initiator (SI) in the dual-stack lite home router and the softwire 431 concentrator (SC) in the dual-stack lite carrier-grade NAT. The 432 dual-stack lite carrier-grade NAT performs IPv4-IPv4 NAT translations 433 to multiplex multiple subscribers through a single global IPv4 434 address. Overlapping address spaces used by subscribers are 435 disambiguated through the identification of tunnel endpoints. 437 +-----------+ 438 | Host | 439 +-----+-----+ 440 |10.0.0.1 441 | 442 | 443 |10.0.0.2 444 +---------|---------+ 445 | | | 446 |dual-stack lite home router 447 |+--------+--------+| 448 || SNAT SI || 449 |+--------+--------+| 450 +--------|||--------+ 451 |||2001:0:0:1::1 452 ||| 453 |||<-IPv4-in-IPv6 softwire 454 ||| 455 -------|||------- 456 / ||| \ 457 | ISP core network | 458 \ ||| / 459 -------|||------- 460 ||| 461 |||2001:0:0:2::1 462 +--------|||--------+ 463 |dual-stack lite carrier-grade NAT 464 |+--------+--------+| 465 || SNAT SC || 466 |+--------+--------+| 467 | |NAT| | 468 | +-+-+ | 469 +---------|---------+ 470 |129.0.0.1 471 | 472 --------|-------- 473 / | \ 474 | Internet | 475 \ | / 476 --------|-------- 477 | 478 |128.0.0.1 479 +-----+-----+ 480 | IPv4 Host | 481 +-----------+ 483 Figure 1: SNAT gateway-based architecture 485 Notes: 487 o The dual-stack lite home router is not required to be on the same 488 link as the host 490 o The dual-stack lite home router could be replaced by a dual-stack 491 lite router in the service provider network 493 The resulting solution accepts an IPv4 datagram that is translated 494 into an IPv4-in-IPv6 softwire datagram for transmission across the 495 softwire. At the corresponding endpoint, the IPv4 datagram is 496 decapsulated, and the translated IPv4 address is inserted based on a 497 translation from the softwire. 499 5.1.1. Example message flow 501 In the example shown in Figure 2, the translation tables in the dual- 502 stack lite carrier-grade NAT is configured to forward between IP/TCP 503 (10.0.0.1/10000) and IP/TCP (129.0.0.1/5000). That is, a datagram 504 received by the dual-stack lite home router from the host at address 505 10.0.0.1, using TCP DST port 10000 will be translated a datagram with 506 IP SRC address 129.0.0.1 and TCP SRC port 5000 in the Internet. 508 +-----------+ 509 | Host | 510 +-----+-----+ 511 | |10.0.0.1 512 IPv4 datagram 1 | | 513 | | 514 v |10.0.0.2 515 +---------|---------+ 516 | | | 517 |dual-stack lite home router 518 |+--------+--------+| 519 || SNAT SI || 520 |+--------+--------+| 521 +--------|||--------+ 522 | |||2001:0:0:1::1 523 IPv6 datagram 2| ||| 524 | |||<-IPv4-in-IPv6 softwire 525 | ||| 526 -----|-|||------- 527 / | ||| \ 528 | ISP core network | 529 \ | ||| / 530 -----|-|||------- 531 | ||| 532 | |||2001:0:0:2::1 533 +------|-|||--------+ 534 |dual-stack lite carrier-grade NAT 535 | v ||| | 536 |+--------+--------+| 537 || SNAT SC || 538 |+--------+--------+| 539 | |NAT| | 540 | +-+-+ | 541 +---------|---------+ 542 | |129.0.0.1 543 IPv4 datagram 3 | | 544 -----|--|-------- 545 / | | \ 546 | Internet | 547 \ | | / 548 -----|--|-------- 549 | | 550 v |128.0.0.1 551 +-----+-----+ 552 | IPv4 Host | 553 +-----------+ 555 Figure 2: Outbound Datagram 557 +-----------------+--------------+---------------+ 558 | Datagram | Header field | Contents | 559 +-----------------+--------------+---------------+ 560 | IPv4 datagram 1 | IPv4 Dst | 128.0.0.1 | 561 | | IPv4 Src | 10.0.0.1 | 562 | | TCP Dst | 80 | 563 | | TCP Src | 10000 | 564 | --------------- | ------------ | ------------- | 565 | IPv6 Datagram 2 | IPv6 Dst | 2001:0:0:2::1 | 566 | | IPv6 Src | 2001:0:0:1::1 | 567 | | IPv4 Dst | 128.0.0.1 | 568 | | IPv4 Src | 10.0.0.1 | 569 | | TCP Dst | 80 | 570 | | TCP Src | 10000 | 571 | --------------- | ------------ | ------------- | 572 | IPv4 datagram 3 | IPv4 Dst | 128.0.0.1 | 573 | | IPv4 Src | 129.0.0.1 | 574 | | TCP Dst | 80 | 575 | | TCP Src | 5000 | 576 +-----------------+--------------+---------------+ 578 Datagram header contents 580 When datagram 1 is received by the dual-stack lite home router, the 581 SI function encapsulates the datagram in datagram 2 and forwards it 582 to the dual-stack lite carrier-grade NAT over the softwire. 584 When it receives datagram 2, the SC in the dual-stack lite carrier- 585 grade NAT hands the IPv4 datagram to the NAT, which determines from 586 its translation table that the datagram received on Softwire_1 with 587 TCP SRC port 10000 should be translated to datagram 3 with IP SRC 588 address 129.0.0.1 and TCP SRC port 5000. 590 Figure 3 shows an inbound message received at the dual-stack lite 591 carrier-grade NAT. When the NAT function in the dual-stack lite 592 carrier-grade NAT receives datagram 1, it looks up the IP/TCP DST in 593 its translation table. In the example in Figure 3, the NAT 594 translates the TCP DST port to 10000, sets the IP DST address to 595 10.0.0.1 and hands the datagram to the SC for transmission over 596 Softwire_1. The SI in the dual-stack lite home router decapsulates 597 IPv4 datagram from the inbound softwire datagram, and forwards it to 598 the host. 600 +-----------+ 601 | Host | 602 +-----+-----+ 603 ^ |10.0.0.1 604 IPv4 datagram 3 | | 605 | | 606 | |10.0.0.2 607 +---------|---------+ 608 | +-+-+ | 609 |dual-stack lite home router 610 |+--------+--------+| 611 || SNAT SI || 612 |+--------+--------+| 613 +--------|||--------+ 614 ^ |||2001:0:0:1::1 615 IPv6 datagram 2 | ||| 616 | |||<-IPv4-in-IPv6 softwire 617 | ||| 618 -----|-|||------- 619 / | ||| \ 620 | ISP core network | 621 \ | ||| / 622 -----|-|||------- 623 | ||| 624 | |||2001:0:0:2::1 625 +------|-|||--------+ 626 |dual-stack lite carrier-grade NAT 627 |+--------+--------+| 628 || SNAT SC || 629 |+--------+--------+| 630 | |NAT| | 631 | +-+-+ | 632 +---------|---------+ 633 ^ |129.0.0.1 634 IPv4 datagram 1 | | 635 -----|--|-------- 636 / | | \ 637 | Internet | 638 \ | | / 639 -----|--|-------- 640 | | 641 | |128.0.0.1 642 +-----+-----+ 643 | IPv4 Host | 644 +-----------+ 646 Figure 3: Inbound Datagram 648 +-----------------+--------------+---------------+ 649 | Datagram | Header field | Contents | 650 +-----------------+--------------+---------------+ 651 | IPv4 datagram 1 | IPv4 Dst | 129.0.0.1 | 652 | | IPv4 Src | 128.0.0.1 | 653 | | TCP Dst | 5000 | 654 | | TCP Src | 80 | 655 | --------------- | ------------ | ------------- | 656 | IPv6 Datagram 2 | IPv6 Dst | 2001:0:0:1::1 | 657 | | IPv6 Src | 2001:0:0:2::1 | 658 | | IPv4 Dst | 10.0.0.1 | 659 | | IP Src | 128.0.0.1 | 660 | | TCP Dst | 10000 | 661 | | TCP Src | 80 | 662 | --------------- | ------------ | ------------- | 663 | IPv4 datagram 3 | IPv4 Dst | 10.0.0.1 | 664 | | IPv4 Src | 128.0.0.1 | 665 | | TCP Dst | 10000 | 666 | | TCP Src | 80 | 667 +-----------------+--------------+---------------+ 669 Datagram header contents 671 5.1.2. Translation details 673 The dual-stack lite carrier-grade NAT has a NAT that translates 674 between softwire/port pairs and IPv4-address/port pairs. The same 675 translation is applied to IPv4 datagrams received on the device's 676 external interface and from the softwire endpoint in the device. 678 In Figure 2, the translator network interface in the dual-stack lite 679 carrier-grade NAT is on the Internet, and the softwire interface 680 connects to the dual-stack lite home router. The dual-stack lite 681 carrier-grade NAT translator is configured as follows: 683 Network interface: Translate IPv4 destination address and TCP 684 destination port to the softwire identifier and TCP destination 685 port 687 Softwire interface: Translate softwire identifier and TCP source 688 port to IPv4 source address and TCP source port 690 Here is how the translation in Figure 3 works: 692 o Datagram 1 is received on the dual-stack lite carrier-grade NAT 693 translator network interface. The translator looks up the IPv4- 694 address/port pair in its translator table, rewrites the IPv4 695 destination address to 10.0.0.1 and the TCP source port to 10000, 696 and hands the datagram to the SE to be forwarded over the 697 softwire. 699 o The IPv4 datagram is received on the dual-stack lite home router 700 SI. The SI function extracts the IPv4 datagram and the dual-stack 701 lite home router forwards datagram 3 to the host. 703 +-------------------------------+--------------------+ 704 | Softwire/IPv4/Port | IPv4/Port | 705 +-------------------------------+--------------------+ 706 | Softwire_1/10.0.0.1/TCP 10000 | 129.0.0.1/TCP 5000 | 707 +-------------------------------+--------------------+ 709 dual-stack lite carrier-grade NAT translation table 711 5.2. Host based architecture 713 This architecture is targeted at new, large scale deployments of 714 dual-stack capable devices implementing a dual-stack lite interface. 716 As illustrated in Figure 4, this dual-stack lite deployment model 717 consists of three components: the dual-stack lite host, the dual- 718 stack lite carrier-grade NAT and a softwire between the softwire 719 initiator (SI) in the host and the softwire concentrator (SC) in the 720 dual-stack lite carrier-grade NAT. The dual-stack lite host is 721 assumed to have IPv6 service and can exchange IPv6 traffic with the 722 dual-stack lite carrier-grade NAT. 724 The dual-stack lite carrier-grade NAT performs IPv4-IPv4 NAT 725 translations to multiplex multiple subscribers through a single 726 global IPv4 address. Overlapping IPv4 address spaces used by the 727 dual-stack lite hosts are disambiguated through the identification of 728 tunnel endpoints. 730 In this situation, the dual-stack lite host configures the IPv4 731 address a.b.c.d out of the well-known range e.f.g.h/p (TBD by IANA) 732 on it dual-stack lite interface acting as the SI. It also configure 733 the last IPv4 address of the reserved range as the address of its 734 default gateway, with a netmask to cover a /p (TBD by IANA) network. 736 +-------------------+ 737 | | 738 |Host a.b.c.d | 739 |+--------+--------+| 740 || SNAT SI || 741 |+--------+--------+| 742 +--------|||--------+ 743 |||2001:0:0:1::1 744 ||| 745 |||<-IPv4-in-IPv6 softwire 746 ||| 747 -------|||------- 748 / ||| \ 749 | ISP core network | 750 \ ||| / 751 -------|||------- 752 ||| 753 |||2001:0:0:2::1 754 +--------|||--------+ 755 |dual-stack lite carrier-grade NAT 756 |+--------+--------+| 757 || SNAT SC || 758 |+--------+--------+| 759 | |NAT| | 760 | +-+-+ | 761 +---------|---------+ 762 |129.0.0.1 763 | 764 --------|-------- 765 / | \ 766 | Internet | 767 \ | / 768 --------|-------- 769 | 770 |128.0.0.1 771 +-----+-----+ 772 | IPv4 Host | 773 +-----------+ 775 Figure 4: SNAT host-based architecture 777 The resulting solution accepts an IPv4 datagram that is translated 778 into an IPv4-in-IPv6 softwire datagram for transmission across the 779 softwire. At the corresponding endpoint, the IPv4 datagram is 780 decapsulated, and the translated IPv4 address is inserted based on a 781 translation from the softwire. 783 5.2.1. Example message flow 785 In the example shown in Figure 5, the translation tables in the dual- 786 stack lite carrier-grade NAT is configured to forward between IP/TCP 787 (a.b.c.d/10000) and IP/TCP (129.0.0.1/5000). That is, a datagram 788 received from the host at address a.b.c.d, using TCP DST port 10000 789 will be translated a datagram with IP SRC address 129.0.0.1 and TCP 790 SRC port 5000 in the Internet. 792 +-------------------+ 793 | | 794 |Host a.b.c.d | 795 |+--------+--------+| 796 || SNAT SI || 797 |+--------+--------+| 798 +--------|||--------+ 799 | |||2001:0:0:1::1 800 IPv6 datagram 1| ||| 801 | |||<-IPv4-in-IPv6 softwire 802 | ||| 803 -----|-|||------- 804 / | ||| \ 805 | ISP core network | 806 \ | ||| / 807 -----|-|||------- 808 | ||| 809 | |||2001:0:0:2::1 810 +------|-|||--------+ 811 |dual-stack lite carrier-grade NAT 812 | v ||| | 813 |+--------+--------+| 814 || SNAT SC || 815 |+--------+--------+| 816 | |NAT| | 817 | +-+-+ | 818 +---------|---------+ 819 | |129.0.0.1 820 IPv4 datagram 2 | | 821 -----|--|-------- 822 / | | \ 823 | Internet | 824 \ | | / 825 -----|--|-------- 826 | | 827 v |128.0.0.1 828 +-----+-----+ 829 | IPv4 Host | 830 +-----------+ 832 Figure 5: Outbound Datagram 834 +-----------------+--------------+---------------+ 835 | Datagram | Header field | Contents | 836 +-----------------+--------------+---------------+ 837 | IPv6 Datagram 1 | IPv6 Dst | 2001:0:0:2::1 | 838 | | IPv6 Src | 2001:0:0:1::1 | 839 | | IPv4 Dst | 128.0.0.1 | 840 | | IPv4 Src | a.b.c.d | 841 | | TCP Dst | 80 | 842 | | TCP Src | 10000 | 843 | --------------- | ------------ | ------------- | 844 | IPv4 datagram 2 | IPv4 Dst | 128.0.0.1 | 845 | | IPv4 Src | 129.0.0.1 | 846 | | TCP Dst | 80 | 847 | | TCP Src | 5000 | 848 +-----------------+--------------+---------------+ 850 Datagram header contents 852 When sending an IPv4 packet, the dual-stack lite host encapsulates it 853 in datagram 1 and forwards it to the dual-stack lite carrier-grade 854 NAT over the softwire. 856 When it receives datagram 1, the SC in the dual-stack lite carrier- 857 grade NAT hands the IPv4 datagram to the NAT, which determines from 858 its translation table that the datagram received on Softwire_1 with 859 TCP SRC port 10000 should be translated to datagram 3 with IP SRC 860 address 129.0.0.1 and TCP SRC port 5000. 862 Figure 6 shows an inbound message received at the dual-stack lite 863 carrier-grade NAT. When the NAT function in the dual-stack lite 864 carrier-grade NAT receives datagram 1, it looks up the IP/TCP DST in 865 its translation table. In the example in Figure 3, the NAT 866 translates the TCP DST port to 10000, sets the IP DST address to 867 a.b.c.d and hands the datagram to the SC for transmission over 868 Softwire_1. The SI in the dual-stack lite home router decapsulates 869 IPv4 datagram from the inbound softwire datagram, and forwards it to 870 the host. 872 +-------------------+ 873 | | 874 |Host a.b.c.d | 875 |+--------+--------+| 876 || SNAT SI || 877 |+--------+--------+| 878 +--------|||--------+ 879 ^ |||2001:0:0:1::1 880 IPv6 datagram 2 | ||| 881 | |||<-IPv4-in-IPv6 softwire 882 | ||| 883 -----|-|||------- 884 / | ||| \ 885 | ISP core network | 886 \ | ||| / 887 -----|-|||------- 888 | ||| 889 | |||2001:0:0:2::1 890 +------|-|||--------+ 891 |dual-stack lite carrier-grade NAT 892 | | ||| | 893 |+--------+--------+| 894 || SNAT SC || 895 |+--------+--------+| 896 | |NAT| | 897 | +-+-+ | 898 +---------|---------+ 899 ^ |129.0.0.1 900 IPv4 datagram 1 | | 901 -----|--|-------- 902 / | | \ 903 | Internet | 904 \ | | / 905 -----|--|-------- 906 | | 907 | |128.0.0.1 908 +-----+-----+ 909 | IPv4 Host | 910 +-----------+ 912 Figure 6: Inbound Datagram 914 +-----------------+--------------+---------------+ 915 | Datagram | Header field | Contents | 916 +-----------------+--------------+---------------+ 917 | IPv4 datagram 1 | IPv4 Dst | 129.0.0.1 | 918 | | IPv4 Src | 128.0.0.1 | 919 | | TCP Dst | 5000 | 920 | | TCP Src | 80 | 921 | --------------- | ------------ | ------------- | 922 | IPv6 Datagram 2 | IPv6 Dst | 2001:0:0:1::1 | 923 | | IPv6 Src | 2001:0:0:2::1 | 924 | | IPv4 Dst | a.b.c.d | 925 | | IP Src | 128.0.0.1 | 926 | | TCP Dst | 10000 | 927 | | TCP Src | 80 | 928 +-----------------+--------------+---------------+ 930 Datagram header contents 932 5.2.2. Translation details 934 The translations happening in the dual-stack lite carrier-grade NAT 935 are the same as in the previous examples. The well known IPv4 936 address a.b.c.d out of the e.f.g.h/p (TBD by IANA) range used by all 937 the hosts are disambiguated by the IPv6 source address of the 938 softwire. 940 6. Encapsulations 942 In its simplest deployment model, dual-stack lite only requires IPv4 943 in IPv6 encapsulation. In more complex scenario where a site gateway 944 would play the role of the softwire initiator, more complex 945 encapsulation might be desired. Thus dual-stack lite hosts, dual- 946 stack lite home gateway and dual-stack lite NAT devices MUST at 947 minimum implement IPv4 in IPv6 encapsulation. On top of that, dual- 948 stack lite NAT devices MAY also support other encapsulation, like 949 L2TPv2/v3, GRE, MPLS,... If they do, they SHOULD support L2TPv2 as 950 defined in the IETF softwire hub & spoke framework. 952 7. Carrier-grade NAT considerations 954 A dual-stack lite carrier-grade NAT SHOULD implement behavior 955 conforming to the best current practice, currently documented in 956 [RFC4787], [I-D.ietf-behave-tcp] and [I-D.ietf-behave-nat-icmp]. 957 Other requirements for carrier-grade NATs can be found in 958 [I-D.nishitani-cgn]. DISCUSSION: those requirements need to be 959 harmonized. 961 7.1. Per customer port allocation 963 Because IPv4 addresses will be shared among customers and potentially 964 a large address space reduction factor may be applied, in average, 965 only a limited number N of TCP or UDP port numbers will be available 966 per customer. This means that applications opening a very large 967 number of TCP ports may have a harder time to work. For example, it 968 has been reported that a very well know web site was using AJAX 969 techniques and was opening up to 69 TCP ports per web page. If we 970 make the hypothesis of an address space reduction of a factor 100 971 (one IPv4 address per 100 customers), and 65k ports per IPv4 972 addresses available, that makes a total of N=650 ports available 973 simultaneously to be shared among the various devices behind the 974 dual-stack lite tunnel end-point. 976 There is an important operational difference if those N ports are 977 pre-allocated in a cookie-cutter fashion versus allocated on demand 978 by incoming connections. This is a difference between an average of 979 N ports and a maximum of N ports. Several service providers have 980 reported an average number of connections per customer in the single 981 digit. At the opposite end, thousands or tens of thousands of ports 982 could be use in a peak by any single customer browsing a number of 983 AJAX/Web 2.0 sites. With that average number of connections per 984 customers in mind, having an address space reduction of a factor 100 985 or more is realistic. 987 Application expecting incoming connections, such a peer-to-peer ones, 988 have become popular. Those applications use a very limited number of 989 ports, usually a single one. Making sure those applications keep 990 working in a dual-stack lite environment is important. Similarly, 991 there is a growing list of applications that require some king of ALG 992 to work through a NAT. Service provider carrier-grade NATs should 993 not to be in the way of the deployment of such applications. As 994 such, there is a legitimate need to leave certain ports under the 995 control of the end user. This argue for an hybrid environment, where 996 most ports are dynamically managed by the carrier-grade NAT in a 997 shared pool and a limited number are dedicated per users and 998 controlled by them. 1000 A service provider can reserve a static number of ports per user. 1001 Note: those could be TCP and UDP ports. The simplest way to allow 1002 users to control the associated NAT bindings is to offer a web 1003 interface (for example as part of the service provider portal) where, 1004 once authenticated, a user can configure each dedicated external IPv4 1005 address/port binding on the carrier-grade NAT in one of the following 1006 way: 1008 o either direct the carrier-grade NAT to forward incoming traffic on 1009 this address/port to the dual-stack lite home gateway, and let 1010 this device deal with it. This required support for A+P 1011 [I-D.ymbk-aplusp] semantic on the home gateway. 1013 o or direct the carrier-grade NAT to rewrite the destination address 1014 in those incoming packets to a private IPv4 address within the 1015 home network. For obvious security reasons, redirection to global 1016 IPv4 address should not be authorized. Note: this behavior is 1017 very similar to the port forwarding function found in most home 1018 gateways. 1020 The exact number of ports reserved per user is left at the discretion 1021 of the service provider. If more ports need to be reserved outside 1022 of that static dedicated range, more ports can be dynamically 1023 reserved. NAT-PMP [I-D.cheshire-nat-pmp] is a good solution for 1024 that. A DHCPv6 option such as 1025 [I-D.bajko-v6ops-port-restricted-ipaddr-assign] may also be an 1026 interesting solution to reserve further ports, although this may be 1027 limited to the A+P semantic mentioned above, as there might not be a 1028 way to explicitly control the port forwarding semantic. 1030 More considerations on sharing IPv4 addresses can be found in 1031 "I-D.ford-shared-addressing-issues". 1033 7.2. ALG 1035 The carrier-grade NAT should only perform a minimum number of ALG for 1036 the classic applications such as FTP, RTSP/RTP, IPsec and PPTP VPN 1037 pass-through and enable the users to use their own ALG on statically 1038 or dynamically reserved port instead. 1040 In particular, the carrier-grade NAT SHOULD NOT perform any ALG on 1041 the ports reserved either statically or dynamically for a user. 1043 7.3. UPnP 1045 One could be tempted to have the home gateway relaying UPnP messages 1046 over the tunnel to the carrier-grade NAT. Unfortunately, this would 1047 not work. Some applications insist on running on a well-known port 1048 number (or port range) using UPnP to request the NAT to reserve that 1049 port. Those ports may or may not be available; they could be used by 1050 another customer. Using UPnP, a NAT box does not have any way to 1051 redirect such applications to use another port, the only option is to 1052 deny the request. Those applications typically then cycle through a 1053 small range of ports (typically 10 or so) until they abort. The 1054 likelihood of those ports being all already in use by other users is 1055 very high. As such, UPnP cannot be supported as-is in a dual-stack 1056 lite environment. 1058 NAT-PMP offers a better semantic, by enabling the NAT to redirect the 1059 application to use another unallocated port. 1061 7.4. MTU 1063 Using an encapsulation (IP in IP or L2TP) to carry IPv4 traffic over 1064 IPv6 will reduce the effective MTU of the datagrams. Unfortunately, 1065 path MTU discovery is not a reliable method to deal with this. As 1066 such a combination of solutions is suggested: 1068 o For TCP traffic, let the carrier-grade NAT rewrite the MSS in the 1069 first SYN packet to a lower value. 1071 o For non-TCP traffic, perform fragmentation and reassembly over the 1072 tunnel between the home gateway and the carrier grade NAT. In 1073 practice, this means put the IPv4 packet into a large IPv6 packet 1074 and fragment/reassemble the IPv6 packet at each endpoint of the 1075 tunnel. There is a performance price to pay for this. 1076 Fragmentation is not very expensive, but reassembly can be, 1077 especially on the carrier-grade NAT that would have to keep track 1078 of a lot of flows. However, such a carrier-grade NAT would only 1079 have to perform reassembly for large UDP packets sourced by 1080 customers, not for large UDP packets received by customers. In 1081 other words, streaming video to a customer would not have a 1082 significant impact on the performance of the carrier-grade NAT, 1083 but will require more work on the home gateway side. 1085 8. Future work 1087 The items described bellow could be included in a future version of 1088 this document or be the object of a separate document. 1090 8.1. Multicast considerations 1092 This document only describes unicast IPv4 as IPv4 Multicast is not 1093 widely deployed in broadband networks. Some multicast IPv4 1094 considerations might to be discussed as well in a future revision of 1095 this document. 1097 8.2. 3rd party carrier-grade NAT 1099 The dual-stack lite architecture can be easily extended to support 1100 3rd party carrier-grade NATs. The dual-stack lite interface just 1101 need to be pointed to the IPv6 address of that 3rd party carrier- 1102 grade NAT instead of the IPv6 address of the service provider 1103 carrier-grade NAT. Implementation of dual-stack lite should enable 1104 users to override the mechanism used for automatic discovery of the 1105 carrier grade NAT and, for example, manually enter the DNS name of 1106 the selected carrier-grade NAT. 1108 8.3. Interface initialization 1110 The initialization sequence of each interface of a dual-stack lite 1111 node need to be analyzed and heuristics need to be defined to 1112 determined if each interface operates in IPv4 mode, IPv6 mode, dual- 1113 stack mode or dual-stack lite mode. The absence/presence of the 1114 DHCPv6 option discussed above in requests/responses could be a 1115 trigger to decide in which mode to operate. 1117 9. Comparison with an architecture with multiple-layers of NAT 1119 An alternative architecture could consist on layering multiple levels 1120 of IPv4-IPv4 NAT toward the edges of the service provider network. 1121 Such architecture has a key advantage: it would work with any 1122 existing IPv4 home gateway. However, it would have a number of 1123 drawbacks: 1125 o Each NAT device in the path will have its own application level 1126 gateways, increasing the odds of failure or miss-configuration. 1128 o The larger private IPv4 address space available today is Net 1129 10.0.0.0/8. It can in theory accommodate for about 16 million 1130 addresses, in practice, with an 80% allocation efficiency, it can 1131 address about 13 million devices. This may not be enough for 1132 existing and future large scale deployments, thus multiple 1133 overlapping copies of Net 10 might have to be used simultaneously. 1134 This in itself create more complexity: 1136 * If multiple copies of Net 10 are in use, network 1137 troubleshooting gets more difficult. One first need to figure 1138 out in which Net 10 realm the customer is before sending a ping 1139 to a home gateway to test it. This means that provisioning 1140 systems need to be modified to include this information. 1142 * Multiple overlapping copies of Net 10 often intersect in some 1143 places with routers and firewalls. The configuration of such 1144 devices need to carefully take into accounts the overlapping 1145 address space. Debugging problems created by miss- 1146 configuration can be time consuming. 1148 o Both legacy customers with global IPv4 addresses and new customers 1149 with private IPv4 addresses may be connected to the same 1150 aggregation router. That router will have to make the decision to 1151 send packets directly to the Internet or via a translator based on 1152 the source address of those packets, which is known as source- 1153 based routing. Although not impossible to implement, this adds 1154 complexity to the management of the network. 1156 None of the issues described above are show stoppers, but put 1157 together, they seriously increase the complexity of the management of 1158 the network. 1160 10. Comparison with NAT-PT (or its potential replacements) 1162 NAT-PT [RFC2766] deals with the translation from IPv6 to IPv4 and 1163 vice versa. As such, it would not help solving the problem of 1164 offering IPv4 service to legacy IPv4 hosts. NAT-PT is targeted at 1165 green field IPv6 deployments, allowing them to access services and 1166 content on the IPv4 Internet. In that sense, NAT-PT could be in 1167 competition with dual-stack lite for green field deployment of new 1168 devices directly connected to the broadband service provider network. 1170 In this situation, NAT-PT has the advantage of enabling to remove 1171 entirely the IPv4 stack on edge devices. This may be critical on 1172 sensor type devices with a very small memory footprint. However, it 1173 is unclear if such devices really need to have access to the whole 1174 global IPv4 Internet in the first place or if they only need to 1175 communicate with servers that can be made IPv6 enable. 1177 In the more general case, dual-stack lite has several advantages over 1178 NAT-PT: 1180 o Dual-stack lite does not require any hack to the DNS. In other 1181 words, there is no need to synthesize fake AAAA records to 1182 represent IPv4 addresses. This make DNSsec works more reliably. 1184 o Because of the DNS ALG hack, NAT-PT places restriction on the 1185 topology, in most cases requiring that all exiting traffic go 1186 through a single point of contention. Because there is no DNS ALG 1187 with dual-stack lite and because each dual-stack lite device can 1188 be directed independently to a different dual-stack lite NAT, the 1189 dual-stack lite architecture can scale better. 1191 o ALG sometimes need to manipulate literal IP address in the payload 1192 of packets. In the case of an IPv4-IPv4 NAT, this is a simple 32 1193 bit field replacement. In the case of IPv6-IPv4 (or IPv4-IPv6) 1194 NAT, a 128 bit field need to be substituted by a 32 bit field (or 1195 vice versa). This makes NAT-PT ALG more complex than dual-stack 1196 lite NAT ALG. 1198 For more detail on NAT-PT related issues, see [RFC4966]. 1200 11. Comparison with DSTM 1202 DSTM [I-D.bound-dstm-exp] was addressing IPv6 backward compatibility 1203 with IPv4 by providing a temporary IPv4 address to dual-stack nodes. 1204 Connectivity was also provided by the way of IPv4 over IPv6 tunnels. 1205 However, DSTM was relying on nodes acquiring and releasing IPv4 1206 addresses on a need to have basis. It is the authors' opinion that 1207 such mechanism may not provide the necessary savings in address space 1208 for large scale broadband deployments. 1210 12. Acknowledgements 1212 The authors would like to acknowledge the role of Mark Townsley for 1213 his input on the overall architecture of this technology by pointing 1214 this work in the direction of [I-D.droms-softwires-snat]. Note that 1215 this document results from a merging of [I-D.durand-dual-stack-lite] 1216 and [I-D.droms-softwires-snat].Also to be acknowledged are the many 1217 discussions with a number of people including Shin Miyakawa, 1218 Katsuyasu Toyama, Akihide Hiura, Takashi Uematsu, Tetsutaro Hara, 1219 Yasunori Matsubayashi, Ichiro Mizukoshi. The author would also like 1220 to thank David Ward, Jari Arkko, Thomas Narten and Geoff Huston for 1221 their constructive feedback. A special thank you goes to Dave Thaler 1222 for his review and comments. 1224 13. IANA Considerations 1226 This draft request IANA to allocate a well know IPv4 e.f.g.h/29 1227 network prefix. That range is used to number the dual-stack lite 1228 interfaces. Reserving a /29 allows for 6 possible interfaces on a 1229 multi-home node. The last IPv4 address of this range is reserved as 1230 the IPv4 address of the default router for such dual-stack lite 1231 hosts. 1233 14. Security Considerations 1235 Security issues associated with NAT have long been documented. See 1236 [RFC2663] and [RFC2993]. 1238 However, moving the NAT functionality from the home gateway to the 1239 core of the service provider network and sharing IPv4 addresses among 1240 customers create additional requirements when logging data for abuse 1241 treatment. With any architecture where an IPv4 address does not 1242 uniquely represent an end host, IPv4 addresses and a timestamps are 1243 no longer sufficient to identify a particular broadband customer. 1244 Additional information like TCP port numbers will be required for 1245 that purpose. 1247 Similarly, some attack mitigation techniques put an IPv4 address in a 1248 "penalty box" for a period of time if an abnormal behavior is 1249 observed. Such techniques may need to be revisited as they would 1250 impact more than just one user (presumably the offender) at a time. 1252 With IPv4 addresses shared by multiple users, ports become a critical 1253 resource. As such, some mechanisms need to be put in place by a 1254 carrier-grade NAT to limit port usage, either by rate-limiting new 1255 connections or putting a hard limit on the maximum number of port 1256 usable by a single user. If this number is high enough, it should 1257 not interfere with normal usage and still provide reasonable 1258 protection of the shared pool. 1260 More considerations on sharing IPv4 addresses can be found in 1261 "I-D.ford-shared-addressing-issues". 1263 If some form of IPv6 ingress filtering is deployed in the broadband 1264 network and dual-stack lite service is restricted to those customers, 1265 then tunnels terminating at the carrier-grade NAT and coming from 1266 registered customer IPv6 addresses cannot be spoofed. Thus a simple 1267 access control list on the tunnel transport source address is all 1268 what is required to accept traffic on the southbound interface of a 1269 carrier-grade NAT. 1271 15. References 1273 15.1. Normative references 1275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1276 Requirement Levels", BCP 14, RFC 2119, March 1997. 1278 15.2. Informative references 1280 [I-D.bajko-v6ops-port-restricted-ipaddr-assign] 1281 Bajko, G. and T. Savolainen, "Port Restricted IP Address 1282 Assignment", 1283 draft-bajko-v6ops-port-restricted-ipaddr-assign-02 (work 1284 in progress), November 2008. 1286 [I-D.bound-dstm-exp] 1287 Bound, J., "Dual Stack IPv6 Dominant Transition Mechanism 1288 (DSTM)", draft-bound-dstm-exp-04 (work in progress), 1289 October 2005. 1291 [I-D.cheshire-nat-pmp] 1292 Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 1293 draft-cheshire-nat-pmp-03 (work in progress), April 2008. 1295 [I-D.despres-sam] 1296 Despres, R., "Stateless Address Mappings (SAMs) IPv6 & 1297 extended IPv4 via local routing domains - possibly 1298 multihomed", draft-despres-sam-01 (work in progress), 1299 November 2008. 1301 [I-D.dhankins-softwire-tunnel-option] 1302 Hankins, D., "Dynamic Host Configuration Protocol Option 1303 for Softwires", draft-dhankins-softwire-tunnel-option-01 1304 (work in progress), August 2008. 1306 [I-D.droms-softwires-snat] 1307 Droms, R. and B. Haberman, "Softwires Network Address 1308 Translation (SNAT)", draft-droms-softwires-snat-01 (work 1309 in progress), July 2008. 1311 [I-D.durand-dual-stack-lite] 1312 Durand, A., "Dual-stack lite broadband deployments post 1313 IPv4 exhaustion", draft-durand-dual-stack-lite-00 (work in 1314 progress), July 2008. 1316 [I-D.ietf-behave-nat-icmp] 1317 Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 1318 Behavioral Requirements for ICMP protocol", 1319 draft-ietf-behave-nat-icmp-12 (work in progress), 1320 January 2009. 1322 [I-D.ietf-behave-tcp] 1323 Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1324 Srisuresh, "NAT Behavioral Requirements for TCP", 1325 draft-ietf-behave-tcp-08 (work in progress), 1326 September 2008. 1328 [I-D.nishitani-cgn] 1329 Nishitani, T., Miyakawa, S., Nakagawa, A., and H. Ashida, 1330 "Common Functions of Large Scale NAT (LSN)", 1331 draft-nishitani-cgn-01 (work in progress), November 2008. 1333 [I-D.ymbk-aplusp] 1334 Maennel, O., Bush, R., Cittadini, L., and S. Bellovin, 1335 "The A+P Approach to the IPv4 Address Shortage", 1336 draft-ymbk-aplusp-02 (work in progress), January 2009. 1338 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1339 Translator (NAT) Terminology and Considerations", 1340 RFC 2663, August 1999. 1342 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 1343 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1344 February 2000. 1346 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 1347 November 2000. 1349 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1350 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1351 RFC 4787, January 2007. 1353 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 1354 Address Translator - Protocol Translator (NAT-PT) to 1355 Historic Status", RFC 4966, July 2007. 1357 [UPnP-IGD] 1358 UPnP Forum, "Universal Plug and Play Internet Gateway 1359 Device Standardized Gateway Device Protocol", 1360 September 2006, 1361 . 1363 Authors' Addresses 1365 Alain Durand 1366 Comcast 1367 1500 Market st 1368 Philadelphia, PA 19102 1369 USA 1371 Email: alain_durand@cable.comcast.com 1372 Ralph Droms 1373 Cisco 1374 1414 Massachusetts Avenue 1375 Boxborough, MA 01714 1376 US 1378 Phone: +1 978.936.1674 1379 Email: rdroms@cisco.com 1381 Brian Haberman 1382 Johns Hopkins University Applied Physics Lab 1383 11100 Johns Hopkins Road 1384 Laurel, MD 20723-6099 1385 US 1387 Phone: +1 443 778 1319 1388 Email: brian@innovationslab.net 1390 James Woodyatt 1391 Apple Inc. 1392 1 Infinite Loop 1393 Cupertino, CA 95014 1394 US 1396 Email: jhw@apple.com