idnits 2.17.1 draft-ietf-softwire-dual-stack-lite-01.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 21 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 6 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 876 has weird spacing: '... |Host a.b.c...' == Line 1608 has weird spacing: '...-to-end model...' -- The document date (July 11, 2009) is 5396 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 1606, but no explicit reference was found in the text == Unused Reference: 'UPnP-IGD' is defined on line 1717, 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-02 == Outdated reference: A later version (-05) exists of draft-dhankins-softwire-tunnel-option-03 == Outdated reference: A later version (-02) exists of draft-ford-shared-addressing-issues-00 == Outdated reference: A later version (-11) exists of draft-ietf-tcpm-tcp-auth-opt-05 == Outdated reference: A later version (-05) exists of draft-nishitani-cgn-02 == Outdated reference: A later version (-10) exists of draft-ymbk-aplusp-03 -- Obsolete informational reference (is this intentional?): RFC 1700 (Obsoleted by RFC 3232) -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Durand, Ed. 3 Internet-Draft Comcast 4 Intended status: Standards Track July 11, 2009 5 Expires: January 12, 2010 7 Dual-stack lite broadband deployments post IPv4 exhaustion 8 draft-ietf-softwire-dual-stack-lite-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 12, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 The common thinking for more than 10 years has been that the 47 transition to IPv6 will be based on the dual stack model and that 48 most things would be converted this way before we ran out of IPv4. 50 It has not happened. The IANA free pool of IPv4 addresses will be 51 depleted soon, well before any significant IPv6 deployment will have 52 occurred. 54 This document revisits the dual-stack model and introduces the dual- 55 stack lite technology aimed at better aligning the costs and benefits 56 of deploying IPv6. Dual-stack lite will provide the necessary bridge 57 between the two protocols, offering an evolution path of the Internet 58 post IANA IPv4 depletion. 60 Dual-Stack lite enable a brodband service provider to share IPv4 61 addresses among customers by combining two well-known technologies: 62 IP in IP (IPv4/IPv6) and NAT. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Requirements language . . . . . . . . . . . . . . . . . . 4 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.3. IPv4 exhaustion coming sooner than expected . . . . . . . 4 70 2. The two long tails . . . . . . . . . . . . . . . . . . . . . . 5 71 2.1. The long tail of IPv4-only devices in the home . . . . . . 5 72 2.2. The long tail of content and services available on the 73 Internet . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.3. Additional impact on new broadband deployment . . . . . . 5 75 2.4. Burden on service providers . . . . . . . . . . . . . . . 6 76 2.5. Dual-prong strategy for broadband . . . . . . . . . . . . 6 77 3. Expectations for dual-stack lite deployment . . . . . . . . . 6 78 3.1. Expectations for home gateway based scenarios . . . . . . 6 79 3.2. Expectations for devices directly connected to the 80 broadband service provider network . . . . . . . . . . . . 7 81 3.3. Expectations for IP-enabled wireless devices scenario . . 7 82 3.4. Application expectations . . . . . . . . . . . . . . . . . 7 83 3.5. Service provider network expectations . . . . . . . . . . 8 84 4. Dual-stack lite . . . . . . . . . . . . . . . . . . . . . . . 8 85 4.1. Domain of application . . . . . . . . . . . . . . . . . . 8 86 4.2. Dual-stack lite interface . . . . . . . . . . . . . . . . 9 87 4.3. Dual-stack lite device . . . . . . . . . . . . . . . . . . 9 88 4.4. Dual-stack lite home router . . . . . . . . . . . . . . . 9 89 4.5. Dual-stack lite router . . . . . . . . . . . . . . . . . . 10 90 4.6. Discovery of the dual-stack lite carrier-grade NAT 91 device . . . . . . . . . . . . . . . . . . . . . . . . . . 10 92 4.7. Dual-stack lite carrier-grade NAT . . . . . . . . . . . . 11 93 5. Example architectures . . . . . . . . . . . . . . . . . . . . 11 94 5.1. Router-based architecture . . . . . . . . . . . . . . . . 11 95 5.1.1. Example message flow . . . . . . . . . . . . . . . . . 14 96 5.1.2. Translation details . . . . . . . . . . . . . . . . . 18 98 5.2. Host based architecture . . . . . . . . . . . . . . . . . 19 99 5.2.1. Example message flow . . . . . . . . . . . . . . . . . 22 100 5.2.2. Translation details . . . . . . . . . . . . . . . . . 26 101 6. Encapsulations . . . . . . . . . . . . . . . . . . . . . . . . 26 102 7. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 27 103 8. Carrier-grade NAT considerations . . . . . . . . . . . . . . . 27 104 9. Port allocation . . . . . . . . . . . . . . . . . . . . . . . 27 105 9.1. Static port reservation . . . . . . . . . . . . . . . . . 28 106 9.2. Dynamic port reservation . . . . . . . . . . . . . . . . . 29 107 9.2.1. UPnP . . . . . . . . . . . . . . . . . . . . . . . . . 29 108 9.2.2. NAT-PMP . . . . . . . . . . . . . . . . . . . . . . . 29 109 9.2.3. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 29 110 10. Other carrier-grade NAT considerations . . . . . . . . . . . . 30 111 10.1. ALG . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 112 10.2. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 113 11. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 31 114 11.1. Multicast considerations . . . . . . . . . . . . . . . . . 32 115 11.2. 3rd party carrier-grade NAT . . . . . . . . . . . . . . . 32 116 11.3. Interface initialization . . . . . . . . . . . . . . . . . 32 117 12. Comparison with an architecture with multiple-layers of NAT . 32 118 13. Comparison with NAT-PT (or its potential replacements) . . . . 33 119 14. Comparison with DSTM . . . . . . . . . . . . . . . . . . . . . 34 120 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 121 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 122 17. Security Considerations . . . . . . . . . . . . . . . . . . . 35 123 18. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 36 124 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 125 19.1. Normative references . . . . . . . . . . . . . . . . . . . 37 126 19.2. Informative references . . . . . . . . . . . . . . . . . . 37 127 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 40 129 1. Introduction 131 This document presents views on IP deployments after the exhaustion 132 of IPv4 addresses and some of the necessary technologies to achieve 133 it. The views expressed are the authors' personal opinions and in no 134 way imply that Comcast plans to deploy or that Cisco will implement 135 the technologies described here. 137 1.1. Requirements language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [RFC2119]. 143 1.2. Terminology 145 This document makes a distinction between a dual-stack capable and a 146 dual-stack provisioned device. The former is a device that has code 147 that implements both IPv4 and IPv6, from the network layer to the 148 applications. The later is a similar device that has been 149 provisioned with both an IPv4 and an IPv6 address on its 150 interface(s). This document will also further refine this notion by 151 distinguishing between interfaces provisioned directly by the service 152 provider from those provisioned by the customer. 154 1.3. IPv4 exhaustion coming sooner than expected 156 Global public IPv4 addresses coming from the IANA free pool are 157 running out faster than many predicted a few years ago. The current 158 model shows that exhaustion could happen as early as 2010 or 2011. 159 See http://ipv4.potaroo.net for more details. Those projection are 160 based on the assumption that tomorrow is going to be very similar to 161 today, i.e., looking at recent address consumption figures is a good 162 indicator of future consumption patterns. This of course, does not 163 take into account any new large scale deployment of IP technology or 164 any human reaction when facing an upcoming shortage. 166 The prediction of the exact date of exhaustion of the IANA free pool 167 is outside the scope of this document, however one conclusion must be 168 drawn from that study: there will be in the near future a point where 169 new global public IPv4 addresses will not be available in large 170 enough quantity thus any new broadband deployment may have to 171 consider the option of not provisioning any (global) IPv4 addresses 172 to the WAN facing interface of edge devices. However, the classic 173 IPv6 deployment model known as "dual stack provisioning" can be a non 174 starter in such environments. 176 2. The two long tails 178 The dual-stack lite technology is intended for maintaining 179 connectivity to legacy IPv4 devices and networks after the exhaustion 180 of the IPv4 address space while service provider networks make a 181 transition to IPv6-only deployments. This section describes some of 182 the specific legacy scenarios addressed by dual-stack lite. 184 2.1. The long tail of IPv4-only devices in the home 186 Broadband home customers have a mix and match of IP enabled devices. 187 The most recent operating systems (e.g., Windows Vista, Mac OS X and 188 various versions of Linux) can operate in an IPv6-only environment; 189 however most of the legacy devices can't. Windows XP, for example, 190 cannot process DNS requests over IPv6 transport. More, having an 191 operating system that support IPv6 does npot garantee that all the 192 application will support IPv6. Many are still only supporting IPv4. 194 Consumer electronic devices (non traditional PCs) are now more and 195 more conected to home networks. Large TVs with a MOCA or ethernet 196 connection, point-and-shoot camera with a Wifi interface to push 197 pictures on the Web, and many others are now comom and most have been 198 reported to only support IPv4. Those devices are generally not 199 upgradables to support IPv6. Expecting broadband customers to 200 massively upgrade their software (and in most cases the corresponding 201 hardware) to deploy IPv6 is a very tall order. 203 2.2. The long tail of content and services available on the Internet 205 IPv6 deployment has taken a very long time to take off, so the 206 current situation is that almost none of the content and services 207 available on the Internet are accessible over IPv6. This situation 208 will probably change in the future, but for now, one has to make the 209 assumption that most of the traffic generated by (and to) broadband 210 customers will be sent to (and originated by) IPv4 nodes. Even when 211 the majority of the most popular content will be accessible via IPv6, 212 there will still be a need to access the long tail of content only 213 reachable with IPv4. 215 2.3. Additional impact on new broadband deployment 217 Even when considering new, green field, broadband deployments, such 218 as always-on 4G, service providers have to face the same situation as 219 described above, that is, content and services available on the 220 Internet are, today, generally accessible only over IPv4 and not 221 IPv6. This makes adoption of IPv6 for green field deployment 222 difficult. Solutions like NAT-PT, now deprecated, do not provide, as 223 of today, a satisfying and scalable answer. 225 2.4. Burden on service providers 227 As a conclusion, broadband service providers may be faced with the 228 situation where they have IPv4 customers who need to communicate with 229 IPv4 servers on the Internet but may not have any IPv4 addresses left 230 to assign to those customers. A service providers may also be in a 231 situation where it wants to deploy IPv6 in its core network, avoiding 232 the use of scarce IPv4 addresses. However, without some form of 233 backward compatibility with IPv4, the cost and the benefits of 234 deploying IPv6 are not aligned, making incremental IPv6 deployment 235 very difficult. 237 2.5. Dual-prong strategy for broadband 239 Facing the reality of the upcoming completion of the IPv4 address 240 space on pne side and the two long IPv4 tails on the other side, 241 broadband providers can implement a dual-prong strategy when they 242 will face a shortage of IPv4 addresses. First prong is to deploy 243 IPv6 natively. Second is to use a transition bridge to offer an IPv4 244 service without relying on a unique IPv4 adress per customer. That 245 means haring IPv4 addresses among customers and implementing some 246 form of NAT inside the provider network. This documment proposes a 247 scalable way of doing so by combining two well-known technologies, IP 248 in IP (IPv4/IPv6) tunneling and NAT. 250 3. Expectations for dual-stack lite deployment 252 3.1. Expectations for home gateway based scenarios 254 This section mainly address home style networks characterized by the 255 presence of a home gateway. 257 Legacy, unmodified, IPv4-only devices inside the home network are 258 expected to keep using [RFC1918] address space, a-la 192.168.0.0/16 259 and should be able to access the IPv4 Internet in a similar way they 260 do it today through a home gateway IPv4 NAT. 262 Unmodified IPv6 capable devices are expected to be able to reach 263 directly the IPv6 Internet, without going through any translation. 264 It is expected that most IPv6 capable devices will also be IPv4 265 capable and will simply be configured with an IPv4 RFC1918 style 266 address within the home network and access the IPv4 Internet the same 267 way as the legacy IPv4-only devices within the home. 269 IPv6-only devices that do not include code for an IPv4 stack are 270 outside of the scope of this document. 272 It is expected that the home gateway is either software upgradable, 273 replaceable or provided by the service provider as part of a new 274 contract. Outside of early IPv6 deployments done prior to IPv4 275 exhaustion using some form of tunnel, this is pretty much a 276 requirement to deploy any IPv6 service to the home. It is expected 277 that this home gateway will be a dual stack capable device that would 278 only be provisioned with IPv6 on its WAN side. IPv4 and IPv6 are 279 expected to be locally provisioned on any LAN interfaces of such 280 devices. IPv4 addresses on such interfaces are expected to be 281 RFC1918. The key point here is that the service provider will not 282 provision any IPv4 addresses for those home gateway devices. 284 3.2. Expectations for devices directly connected to the broadband 285 service provider network 287 Under this deployment model, devices directly connected to the 288 broadband service provider network without the presence of a home 289 gateway will have to be dual stack capable devices. The service 290 provider facing interface(s) of such device will only be provisioned 291 with IPv6. IPv4 may or may not be provisioned locally on other 292 interfaces of such devices. Similarly to the above section, the key 293 point here is that the service provider will not provision any IPv4 294 addresses for those directly connected devices. 296 It is expected that directly connected devices will implement code to 297 support the dual-stack lite functionality. The minimum support 298 required is an IPv4-in-IPv6 tunnel [RFC2473]. 300 IPv4-only devices and IPv6-only devices are specifically left out of 301 scope for this document. It is expected that most modern device 302 directly connected to the service provider network would not have 303 memory constraints to implement both stack. 305 3.3. Expectations for IP-enabled wireless devices scenario 307 Simialr to host devices directly connected to the broadband servie 308 provider network, the wireless device will have dual-stack 309 implemented. When the wireless device requests IP connectivity from 310 the service provider, the service provider will only provision an 311 IPv6 address to the WAN facing interface of the wireless device. No 312 IPv4 (public or RFC1918) address will be given to the device. When 313 the wireless device accesses IPv4 services, it will be implemented 314 the dual-stack lite functionality described in section 4. 316 3.4. Application expectations 318 Most applications that today work transparently through an IPv4 home 319 gateway NAT should keep working the same way. However, it is not 320 expected that applications that requires specific port assignment or 321 specific port mapping from the NAT box will keep working. Details 322 and recommendations for application behavior are outside the scope of 323 this document and should be discussed in the behave working group. 325 3.5. Service provider network expectations 327 The dual-stack lite deployment model is based on the notion that IPv4 328 addresses will be shared by several customers. This implies that the 329 NAT functionality will move from the home gateway to a device hosted 330 within the service provider network. It is important to observe that 331 this functionality does not have to be performed deep in the core of 332 the network and that it might be better implemented close to the 333 aggregation point of customer traffic. 335 4. Dual-stack lite 337 The core ideas behind dual-stack lite are: 339 o Move from a deployment model where a globally unique IPv4 address 340 is provisioned per customer and shared among several devices 341 within that customer premise to a deployment model where that 342 globally unique IPv4 address is shared among many customers 344 o Provide transport of IPv4 traffic to customers over a core network 345 that uses only IPv6 347 Instead of relying on a cascade of NATs or NAT-PT, the dual-stack 348 lite model is built on IPv4-in-IPv6 tunnels to cross the network to 349 reach a carrier-grade IPv4-IPv4 NAT. As such, it simplifies the 350 management of the service provider network by using only IPv6 and 351 provides the customer the benefit of having only one layer of NAT. 352 The additional benefit of this model is to gradually introduce IPv6 353 in the Internet by making it virtually backward compatible with IPv4. 355 Details about IPv6 tunneling can be found on [RFC2473], where the 356 next header is simply 4, for IPv4, as explained in [RFC2460] and in 357 [RFC1700]. 359 4.1. Domain of application 361 The dual-stack lite deployment model has been designed with broadband 362 networks in mind. It is certainly applicable to other domains 363 although the authors do not make any specific claim of suitability. 365 4.2. Dual-stack lite interface 367 A dual-stack lite interface on a dual-stack capable device is modeled 368 as a point to point IPv4-in-IPv6 tunnel. Its configuration requires 369 that the device is provisioned with IPv6 but does not require it to 370 be provisioned with a global IPv4 by the service provider. 372 Any locally unique IPv4 address can be configured on the subscriber 373 network end of the dual-stack lite tunnel. In the case of dual-stack 374 lite in which the tunnel endpoint is in a host Section 5.2, it is 375 recommended that dual-stack lite implementations use any address 376 a.b.c.d in the well known range e.f.g.h/p (to be defined by IANA) but 377 the first one (all-zero address in the reserved subnet) as the IPv4 378 host side of the tunnel and the last one of the same range as the 379 address of the IPv4 default gateway, with a netmask to cover a /p 380 network. 382 o Note 1: on a multi-home node, several dual-stack like interfaces 383 could end-up being configured. Each of those interfaces should be 384 configured with a different IPv4 address taken out of the reserved 385 range. 387 o Note 2: because of this static configuration using well known 388 values, there is no need to run a DHCPv4 client on a dual-stack 389 lite interface. 391 The service provider network end point of a dual-stack lite interface 392 is the IPv6 address of a dual-stack lite carrier-grade NAT within the 393 service provider network. 395 4.3. Dual-stack lite device 397 A dual-stack lite device is a dual-stack capable device implementing 398 a dual-stack lite interface. In the absence of better routing 399 information, a dual-stack lite device will configure a static IPv4 400 default route over the dual-stack lite interface. 402 4.4. Dual-stack lite home router 404 A dual-stack lite home router is a dual-stack capable home router 405 implementing a dual-stack lite interface layered on top of its WAN 406 interface. In the absence of better routing information, a dual- 407 stack lite home router will configure a static IPv4 default route 408 over the dual-stack lite interface. The dual-stack lite home router 409 can use any IPv4 address a.b.c.d out of the e.f.g.h/p prefix (TBD by 410 IANA) to source its own IPv4 packets, embedded into the IPv6 tunnel. 411 If the dual-stack lite home router need to configure a router 412 pointing to an IPv4 default router, it can use the last address in 413 the e.f.g.h/p (TBD by IANA) range for that purpose, with a netmask to 414 cover a /p (TBD by IANA) network. 416 For normal IPv4 packets, a dual-stack lite home router MUST NOT 417 perform any IPv4 address translation. From egress traffic, the home 418 router passes packets from the LAN interface to the dual-stack lite 419 interface for IPv6 encapsulation. For ingress traffic, the home 420 router receives packets from the dual-stack lite interface, 421 decapsulates the IPv6 header, and routes the packets to the target 422 based on the destination address in the IPv4 header. Either case, 423 the dual-stack lite home router will not perform address translation. 425 For IPv4 packets fallen into the A+P address space, the A+P enabled 426 home router MUST perform the A+P mechanism described in 427 [I-D.ymbk-aplusp]. For egress traffic, the home router references 428 the A+P table using the source IPv4 address and transport port 429 number, and passes the packets from the LAN interface to the dual- 430 stack lite interface for IPv6 encapsulation. For ingress traffic, 431 the home router receives packets from the dual-stack lite interface, 432 decapsulates the IPv6 header, finds the targeted host using the A+P 433 table, and routes the packets accordingly to the host. The A+P 434 enabled home router handles the A+P table. The dual-stack lite 435 carrier-grade NAT simply forwards the packets to the IPv4-in-IPv6 436 tunnel. 438 Besides, the dual-stack lite router must account the tunnel overhead 439 which reduces the effective MTU size. As such, the router may 440 perform IPv6 fragmentation. More details can be found in 441 Section 10.2. 443 4.5. Dual-stack lite router 445 The concept of a dual-stack lite home router can be extended to any 446 IPv4 router serving as a gateway between a leaf IP domain and the 447 rest of the Internet. 449 4.6. Discovery of the dual-stack lite carrier-grade NAT device 451 The IPv6 address of a dual-stack lite carrier-grade NAT device can be 452 configured on a dual-stack lite interface using a variety of methods, 453 ranging from an out-of-band mechanism, manual configuration, a to-be- 454 defined DHCPv6 option [I-D.dhankins-softwire-tunnel-option] or a to- 455 be-defined IPv6 router advertisement. It is expected that over time 456 some or all the above methods, as well as others, will be defined. 457 The requirements and specifications of such methods are out of scope 458 for this document. 460 4.7. Dual-stack lite carrier-grade NAT 462 A dual-stack lite carrier grade NAT is a special IPv4 to IPv4 NAT 463 deployed within the service provider network. It is reachable by 464 customers via a series of point to point IPv4-in-IPv6 tunnels. 466 A dual-stack lite carrier-grade NAT uses a combination of the IPv6 467 source address of the tunnel and the inner IPv4 source address to 468 establish and maintain the IPv4 NAT mapping table. 470 A dual-stack lite carrier-grade NAT does not have to perform any 471 IPv6-IPv6, IPv6-IPv4 or IPv4-IPv6 NAT. 473 A dual-stack lite carrier-grade NAT can use the last IPv4 address of 474 the range e.f.g.h/p (TBD by IANA) in the IPv4 ICMP packets it will 475 originate toward a dual-stack lite client to enable meaningful ping 476 and traceroute results. 478 A dual-stack lite carrier-grade NAT forwards packets without NAT for 479 those fallen in the A+P address space. 481 5. Example architectures 483 The underlying technology behind dual-stack lite is the combination 484 of two well-known technologies: NAT and tunneling. This combination 485 can be best described using the terminology developed in the softwire 486 working group as Softwire NAT, or SNAT. 488 Two architectures can be deployed for dual-stack lite. One is 489 targeting the legacy installed base of IPv4 only hosts (and dual- 490 stack capable hosts) sitting behind a gateway. The second is 491 targeting dual-stack capable hosts initiating the tunnel themselves. 493 5.1. Router-based architecture 495 This architecture is targeted at residential broadband deployments 496 but can be adapted easily to other types of deployment where the 497 installed base of IPv4-only device is important. 499 Consider a scenario where a Dual-Stack lite home gateway is 500 provisioned only with IPv6 in the WAN port, no IPv4. The home 501 gateway acts as an IPv4 DCHP server for the LAN network (wireline and 502 wireless) handing out RFC1918 addresses. In addition, the home 503 gateway may support IPv6 Auto-Configuration and/or DHCPv6 server for 504 the LAN network. When an IPv4-only device connects to the home 505 gateway, the gateway will hand it out a RFC1918 address. When a 506 dual-stack capable device connects to the home gateway, the gateway 507 will hand out a RFC1918 address and a global IPv6 address to the 508 device. Besides, the home gateway will create an IPv4-in-IPv6 509 softwire tunnel [RFC5571]to a Carrier-Grade NAT. The Carrier-Grade 510 NAT will reside in the service provider network. 512 When the device accesses IPv6 service, it will send the IPv6 datagram 513 to the home gateway natively. The home gateway will route the 514 traffic upstream to the default gateway. 516 When the device accesses IPv4 service, it will source the IPv4 517 datagram with the RFC1918 address and send the IPv4 datagram to the 518 home gateway. The home gateway will encapsulate the IPv4 datagram 519 inside the IPv4-over-IPv6 softwire tunnel and forward the IPv6 520 datagram to the Carrier-Grade NAT. This contrasts what the home 521 gateways normally do today which will NAT the RFC1918 address to the 522 public IPv4 address and route the datagram upstream. When the 523 Carrier-Grade NAT receives the IPv6 datagram, it will de-capsulate 524 the IPv6 header and perform an IPv4-to-IPv4 NAT on the source 525 address. 527 As illustrated in Figure 1, this dual-stack lite deployment model 528 consists of three components: the dual-stack lite home router, the 529 dual-stack lite carrier-grade NAT and a softwire between the softwire 530 initiator (SI) [RFC5571] in the dual-stack lite home router and the 531 softwire concentrator (SC) [RFC5571] in the dual-stack lite carrier- 532 grade NAT. The dual-stack lite carrier-grade NAT performs IPv4-IPv4 533 NAT translations to multiplex multiple subscribers through a single 534 global IPv4 address. Overlapping address spaces used by subscribers 535 are disambiguated through the identification of tunnel endpoints. 537 +-----------+ 538 | Host | 539 +-----+-----+ 540 |10.0.0.1 541 | 542 | 543 |10.0.0.2 544 +---------|---------+ 545 | | | 546 |dual-stack lite home router 547 |+--------+--------+| 548 || SNAT SI || 549 |+--------+--------+| 550 +--------|||--------+ 551 |||2001:0:0:1::1 552 ||| 553 |||<-IPv4-in-IPv6 softwire 554 ||| 555 -------|||------- 556 / ||| \ 557 | ISP core network | 558 \ ||| / 559 -------|||------- 560 ||| 561 |||2001:0:0:2::1 562 +--------|||--------+ 563 |dual-stack lite carrier-grade NAT 564 |+--------+--------+| 565 || SNAT SC || 566 |+--------+--------+| 567 | |NAT| | 568 | +-+-+ | 569 +---------|---------+ 570 |129.0.0.1 571 | 572 --------|-------- 573 / | \ 574 | Internet | 575 \ | / 576 --------|-------- 577 | 578 |128.0.0.1 579 +-----+-----+ 580 | IPv4 Host | 581 +-----------+ 583 Figure 1: SNAT gateway-based architecture 585 Notes: 587 o The dual-stack lite home router is not required to be on the same 588 link as the host 590 o The dual-stack lite home router could be replaced by a dual-stack 591 lite router in the service provider network 593 The resulting solution accepts an IPv4 datagram that is translated 594 into an IPv4-in-IPv6 softwire datagram for transmission across the 595 softwire. At the corresponding endpoint, the IPv4 datagram is 596 decapsulated, and the translated IPv4 address is inserted based on a 597 translation from the softwire. 599 5.1.1. Example message flow 601 In the example shown in Figure 2, the translation tables in the dual- 602 stack lite carrier-grade NAT is configured to forward between IP/TCP 603 (10.0.0.1/10000) and IP/TCP (129.0.0.1/5000). That is, a datagram 604 received by the dual-stack lite home router from the host at address 605 10.0.0.1, using TCP DST port 10000 will be translated a datagram with 606 IP SRC address 129.0.0.1 and TCP SRC port 5000 in the Internet. 608 +-----------+ 609 | Host | 610 +-----+-----+ 611 | |10.0.0.1 612 IPv4 datagram 1 | | 613 | | 614 v |10.0.0.2 615 +---------|---------+ 616 | | | 617 |dual-stack lite home router 618 |+--------+--------+| 619 || SNAT SI || 620 |+--------+--------+| 621 +--------|||--------+ 622 | |||2001:0:0:1::1 623 IPv6 datagram 2| ||| 624 | |||<-IPv4-in-IPv6 softwire 625 | ||| 626 -----|-|||------- 627 / | ||| \ 628 | ISP core network | 629 \ | ||| / 630 -----|-|||------- 631 | ||| 632 | |||2001:0:0:2::1 633 +------|-|||--------+ 634 |dual-stack lite carrier-grade NAT 635 | v ||| | 636 |+--------+--------+| 637 || SNAT SC || 638 |+--------+--------+| 639 | |NAT| | 640 | +-+-+ | 641 +---------|---------+ 642 | |129.0.0.1 643 IPv4 datagram 3 | | 644 | | 645 -----|--|-------- 646 / | | \ 647 | Internet | 648 \ | | / 649 -----|--|-------- 650 | | 651 v |128.0.0.1 652 +-----+-----+ 653 | IPv4 Host | 654 +-----------+ 655 Figure 2: Outbound Datagram 657 +-----------------+--------------+---------------+ 658 | Datagram | Header field | Contents | 659 +-----------------+--------------+---------------+ 660 | IPv4 datagram 1 | IPv4 Dst | 128.0.0.1 | 661 | | IPv4 Src | 10.0.0.1 | 662 | | TCP Dst | 80 | 663 | | TCP Src | 10000 | 664 | --------------- | ------------ | ------------- | 665 | IPv6 Datagram 2 | IPv6 Dst | 2001:0:0:2::1 | 666 | | IPv6 Src | 2001:0:0:1::1 | 667 | | IPv4 Dst | 128.0.0.1 | 668 | | IPv4 Src | 10.0.0.1 | 669 | | TCP Dst | 80 | 670 | | TCP Src | 10000 | 671 | --------------- | ------------ | ------------- | 672 | IPv4 datagram 3 | IPv4 Dst | 128.0.0.1 | 673 | | IPv4 Src | 129.0.0.1 | 674 | | TCP Dst | 80 | 675 | | TCP Src | 5000 | 676 +-----------------+--------------+---------------+ 678 Datagram header contents 680 When datagram 1 is received by the dual-stack lite home router, the 681 SI function encapsulates the datagram in datagram 2 and forwards it 682 to the dual-stack lite carrier-grade NAT over the softwire. 684 When it receives datagram 2, the SC in the dual-stack lite carrier- 685 grade NAT hands the IPv4 datagram to the NAT, which determines from 686 its translation table that the datagram received on Softwire_1 with 687 TCP SRC port 10000 should be translated to datagram 3 with IP SRC 688 address 129.0.0.1 and TCP SRC port 5000. 690 Figure 3 shows an inbound message received at the dual-stack lite 691 carrier-grade NAT. When the NAT function in the dual-stack lite 692 carrier-grade NAT receives datagram 1, it looks up the IP/TCP DST in 693 its translation table. In the example in Figure 3, the NAT 694 translates the TCP DST port to 10000, sets the IP DST address to 695 10.0.0.1 and hands the datagram to the SC for transmission over 696 Softwire_1. The SI in the dual-stack lite home router decapsulates 697 IPv4 datagram from the inbound softwire datagram, and forwards it to 698 the host. 700 +-----------+ 701 | Host | 702 +-----+-----+ 703 ^ |10.0.0.1 704 IPv4 datagram 3 | | 705 | | 706 | |10.0.0.2 707 +---------|---------+ 708 | +-+-+ | 709 |dual-stack lite home router 710 |+--------+--------+| 711 || SNAT SI || 712 |+--------+--------+| 713 +--------|||--------+ 714 ^ |||2001:0:0:1::1 715 IPv6 datagram 2 | ||| 716 | |||<-IPv4-in-IPv6 softwire 717 | ||| 718 -----|-|||------- 719 / | ||| \ 720 | ISP core network | 721 \ | ||| / 722 -----|-|||------- 723 | ||| 724 | |||2001:0:0:2::1 725 +------|-|||--------+ 726 |dual-stack lite carrier-grade NAT 727 |+--------+--------+| 728 || SNAT SC || 729 |+--------+--------+| 730 | |NAT| | 731 | +-+-+ | 732 +---------|---------+ 733 ^ |129.0.0.1 734 IPv4 datagram 1 | | 735 | | 736 -----|--|-------- 737 / | | \ 738 | Internet | 739 \ | | / 740 -----|--|-------- 741 | | 742 | |128.0.0.1 743 +-----+-----+ 744 | IPv4 Host | 745 +-----------+ 747 Figure 3: Inbound Datagram 749 +-----------------+--------------+---------------+ 750 | Datagram | Header field | Contents | 751 +-----------------+--------------+---------------+ 752 | IPv4 datagram 1 | IPv4 Dst | 129.0.0.1 | 753 | | IPv4 Src | 128.0.0.1 | 754 | | TCP Dst | 5000 | 755 | | TCP Src | 80 | 756 | --------------- | ------------ | ------------- | 757 | IPv6 Datagram 2 | IPv6 Dst | 2001:0:0:1::1 | 758 | | IPv6 Src | 2001:0:0:2::1 | 759 | | IPv4 Dst | 10.0.0.1 | 760 | | IP Src | 128.0.0.1 | 761 | | TCP Dst | 10000 | 762 | | TCP Src | 80 | 763 | --------------- | ------------ | ------------- | 764 | IPv4 datagram 3 | IPv4 Dst | 10.0.0.1 | 765 | | IPv4 Src | 128.0.0.1 | 766 | | TCP Dst | 10000 | 767 | | TCP Src | 80 | 768 +-----------------+--------------+---------------+ 770 Datagram header contents 772 5.1.2. Translation details 774 The dual-stack lite carrier-grade NAT has a NAT that translates 775 between softwire/port pairs and IPv4-address/port pairs. The same 776 translation is applied to IPv4 datagrams received on the device's 777 external interface and from the softwire endpoint in the device. 779 In Figure 2, the translator network interface in the dual-stack lite 780 carrier-grade NAT is on the Internet, and the softwire interface 781 connects to the dual-stack lite home router. The dual-stack lite 782 carrier-grade NAT translator is configured as follows: 784 Network interface: Translate IPv4 destination address and TCP 785 destination port to the softwire identifier and TCP destination 786 port 788 Softwire interface: Translate softwire identifier and TCP source 789 port to IPv4 source address and TCP source port 791 Here is how the translation in Figure 3 works: 793 o Datagram 1 is received on the dual-stack lite carrier-grade NAT 794 translator network interface. The translator looks up the IPv4- 795 address/port pair in its translator table, rewrites the IPv4 796 destination address to 10.0.0.1 and the TCP source port to 10000, 797 and hands the datagram to the SE to be forwarded over the 798 softwire. 800 o The IPv4 datagram is received on the dual-stack lite home router 801 SI. The SI function extracts the IPv4 datagram and the dual-stack 802 lite home router forwards datagram 3 to the host. 804 +----------------------------------+--------------------+ 805 | Softwire-Id/IPv4/Port | IPv4/Port | 806 +----------------------------------+--------------------+ 807 | 2001:0:0:1::1/10.0.0.1/TCP 10000 | 129.0.0.1/TCP 5000 | 808 +----------------------------------+--------------------+ 810 Dual-Stack lite carrier-grade NAT translation table 812 The Softwire-Id is the IPv6 address assigned to the Dual-Stack lite 813 home gateway. Hosts behind the same Dual-Stack lite home router have 814 the same Softwire-Id. The source IPv4 is the RFC1918 addressed 815 assigned by the Dual-Stack home router which is unique to each host 816 behind the home gateway. The Dual-Stack lite carrier-grade NAT would 817 receive packets sourced from different IPv4 addresses in the same 818 softwire tunnel. The carrier-grade NAT combines the Softwire-Id and 819 IPv4 address/Port [Softwire-Id, IPv4+Port] to uniquely identify the 820 host behind the same Dual-Stack lite home router. 822 5.2. Host based architecture 824 This architecture is targeted at new, large scale deployments of 825 dual-stack capable devices implementing a dual-stack lite interface. 827 Consider a scenario where a Dual-Stack lite host device is directly 828 connected to the service provider network. The host device is dual- 829 stack capable but only provisioned an IPv6 global address. Besides, 830 the host device will pre-configure a well-known IPv4 non-routable 831 address (see IANA section). This well-known IPv4 non-routable 832 address is similar to the 127.0.0.1 loopback address. Every host 833 device implemented Dual-Stack lite will pre-configure the same 834 address. This address will be used to source the IPv4 datagram when 835 the device accesses IPv4 services. Besides, the host device will 836 create an IPv4-over-IPv6 softwire tunnel to a Carrier Grade NAT. The 837 Carrier Grade NAT will reside in the service provider network. 839 When the device accesses IPv6 service, the device will send the IPv6 840 datagram natively to the default gateway. 842 When the device accesses IPv4 service, it will source the IPv4 843 datagram with the well-known non-routable IPv4 address. Then, the 844 host device will encapsulate the IPv4 datagram inside the IPv4-over- 845 IPv6 softwire tunnel and send the IPv6 datagram to the Carrier-Grade 846 NAT. When the Carrier-Grade NAT receives the IPv6 datagram, it will 847 de-capsulate the IPv6 header and perform IPv4-to-IPv4 NAT on the 848 source address. 850 This scenario works on both wireline and wireless networks. A 851 typical wireless device will connect directly to the service provider 852 without home gateway in between. 854 As illustrated in Figure 4, this dual-stack lite deployment model 855 consists of three components: the dual-stack lite host, the dual- 856 stack lite carrier-grade NAT and a softwire between the softwire 857 initiator (SI) in the host and the softwire concentrator (SC) in the 858 dual-stack lite carrier-grade NAT. The dual-stack lite host is 859 assumed to have IPv6 service and can exchange IPv6 traffic with the 860 dual-stack lite carrier-grade NAT. 862 The dual-stack lite carrier-grade NAT performs IPv4-IPv4 NAT 863 translations to multiplex multiple subscribers through a single 864 global IPv4 address. Overlapping IPv4 address spaces used by the 865 dual-stack lite hosts are disambiguated through the identification of 866 tunnel endpoints. 868 In this situation, the dual-stack lite host configures the IPv4 869 address a.b.c.d out of the well-known range e.f.g.h/p (TBD by IANA) 870 on it dual-stack lite interface acting as the SI. It also configure 871 the last IPv4 address of the reserved range as the address of its 872 default gateway, with a netmask to cover a /p (TBD by IANA) network. 874 +-------------------+ 875 | | 876 |Host a.b.c.d | 877 |+--------+--------+| 878 || SNAT SI || 879 |+--------+--------+| 880 +--------|||--------+ 881 |||2001:0:0:1::1 882 ||| 883 |||<-IPv4-in-IPv6 softwire 884 ||| 885 -------|||------- 886 / ||| \ 887 | ISP core network | 888 \ ||| / 889 -------|||------- 890 ||| 891 |||2001:0:0:2::1 892 +--------|||--------+ 893 |dual-stack lite carrier-grade NAT 894 |+--------+--------+| 895 || SNAT SC || 896 |+--------+--------+| 897 | |NAT| | 898 | +-+-+ | 899 +---------|---------+ 900 |129.0.0.1 901 | 902 --------|-------- 903 / | \ 904 | Internet | 905 \ | / 906 --------|-------- 907 | 908 |128.0.0.1 909 +-----+-----+ 910 | IPv4 Host | 911 +-----------+ 913 Figure 4: SNAT host-based architecture 915 The resulting solution accepts an IPv4 datagram that is translated 916 into an IPv4-in-IPv6 softwire datagram for transmission across the 917 softwire. At the corresponding endpoint, the IPv4 datagram is 918 decapsulated, and the translated IPv4 address is inserted based on a 919 translation from the softwire. 921 5.2.1. Example message flow 923 In the example shown in Figure 5, the translation tables in the dual- 924 stack lite carrier-grade NAT is configured to forward between IP/TCP 925 (a.b.c.d/10000) and IP/TCP (129.0.0.1/5000). That is, a datagram 926 received from the host at address a.b.c.d, using TCP DST port 10000 927 will be translated a datagram with IP SRC address 129.0.0.1 and TCP 928 SRC port 5000 in the Internet. 930 +-------------------+ 931 | | 932 |Host a.b.c.d | 933 |+--------+--------+| 934 || SNAT SI || 935 |+--------+--------+| 936 +--------|||--------+ 937 | |||2001:0:0:1::1 938 IPv6 datagram 1| ||| 939 | |||<-IPv4-in-IPv6 softwire 940 | ||| 941 -----|-|||------- 942 / | ||| \ 943 | ISP core network | 944 \ | ||| / 945 -----|-|||------- 946 | ||| 947 | |||2001:0:0:2::1 948 +------|-|||--------+ 949 |dual-stack lite carrier-grade NAT 950 | v ||| | 951 |+--------+--------+| 952 || SNAT SC || 953 |+--------+--------+| 954 | |NAT| | 955 | +-+-+ | 956 +---------|---------+ 957 | |129.0.0.1 958 IPv4 datagram 2 | | 959 -----|--|-------- 960 / | | \ 961 | Internet | 962 \ | | / 963 -----|--|-------- 964 | | 965 v |128.0.0.1 966 +-----+-----+ 967 | IPv4 Host | 968 +-----------+ 970 Figure 5: Outbound Datagram 972 +-----------------+--------------+---------------+ 973 | Datagram | Header field | Contents | 974 +-----------------+--------------+---------------+ 975 | IPv6 Datagram 1 | IPv6 Dst | 2001:0:0:2::1 | 976 | | IPv6 Src | 2001:0:0:1::1 | 977 | | IPv4 Dst | 128.0.0.1 | 978 | | IPv4 Src | a.b.c.d | 979 | | TCP Dst | 80 | 980 | | TCP Src | 10000 | 981 | --------------- | ------------ | ------------- | 982 | IPv4 datagram 2 | IPv4 Dst | 128.0.0.1 | 983 | | IPv4 Src | 129.0.0.1 | 984 | | TCP Dst | 80 | 985 | | TCP Src | 5000 | 986 +-----------------+--------------+---------------+ 988 Datagram header contents 990 When sending an IPv4 packet, the dual-stack lite host encapsulates it 991 in datagram 1 and forwards it to the dual-stack lite carrier-grade 992 NAT over the softwire. 994 When it receives datagram 1, the SC in the dual-stack lite carrier- 995 grade NAT hands the IPv4 datagram to the NAT, which determines from 996 its translation table that the datagram received on Softwire_1 with 997 TCP SRC port 10000 should be translated to datagram 3 with IP SRC 998 address 129.0.0.1 and TCP SRC port 5000. 1000 Figure 6 shows an inbound message received at the dual-stack lite 1001 carrier-grade NAT. When the NAT function in the dual-stack lite 1002 carrier-grade NAT receives datagram 1, it looks up the IP/TCP DST in 1003 its translation table. In the example in Figure 3, the NAT 1004 translates the TCP DST port to 10000, sets the IP DST address to 1005 a.b.c.d and hands the datagram to the SC for transmission over 1006 Softwire_1. The SI in the dual-stack lite home router decapsulates 1007 IPv4 datagram from the inbound softwire datagram, and forwards it to 1008 the host. 1010 +-------------------+ 1011 | | 1012 |Host a.b.c.d | 1013 |+--------+--------+| 1014 || SNAT SI || 1015 |+--------+--------+| 1016 +--------|||--------+ 1017 ^ |||2001:0:0:1::1 1018 IPv6 datagram 2 | ||| 1019 | |||<-IPv4-in-IPv6 softwire 1020 | ||| 1021 -----|-|||------- 1022 / | ||| \ 1023 | ISP core network | 1024 \ | ||| / 1025 -----|-|||------- 1026 | ||| 1027 | |||2001:0:0:2::1 1028 +------|-|||--------+ 1029 |dual-stack lite carrier-grade NAT 1030 | | ||| | 1031 |+--------+--------+| 1032 || SNAT SC || 1033 |+--------+--------+| 1034 | |NAT| | 1035 | +-+-+ | 1036 +---------|---------+ 1037 ^ |129.0.0.1 1038 IPv4 datagram 1 | | 1039 -----|--|-------- 1040 / | | \ 1041 | Internet | 1042 \ | | / 1043 -----|--|-------- 1044 | | 1045 | |128.0.0.1 1046 +-----+-----+ 1047 | IPv4 Host | 1048 +-----------+ 1050 Figure 6: Inbound Datagram 1052 +-----------------+--------------+---------------+ 1053 | Datagram | Header field | Contents | 1054 +-----------------+--------------+---------------+ 1055 | IPv4 datagram 1 | IPv4 Dst | 129.0.0.1 | 1056 | | IPv4 Src | 128.0.0.1 | 1057 | | TCP Dst | 5000 | 1058 | | TCP Src | 80 | 1059 | --------------- | ------------ | ------------- | 1060 | IPv6 Datagram 2 | IPv6 Dst | 2001:0:0:1::1 | 1061 | | IPv6 Src | 2001:0:0:2::1 | 1062 | | IPv4 Dst | a.b.c.d | 1063 | | IP Src | 128.0.0.1 | 1064 | | TCP Dst | 10000 | 1065 | | TCP Src | 80 | 1066 +-----------------+--------------+---------------+ 1068 Datagram header contents 1070 5.2.2. Translation details 1072 The translations happening in the dual-stack lite carrier-grade NAT 1073 are the same as in the previous examples. The well known IPv4 1074 address a.b.c.d out of the e.f.g.h/p (TBD by IANA) range used by all 1075 the hosts are disambiguated by the IPv6 source address of the 1076 softwire. 1078 +---------------------------------+--------------------+ 1079 | Softwire-Id/IPv4/Port | IPv4/Port | 1080 +---------------------------------+--------------------+ 1081 | 2001:0:0:1::1/a.b.c.d/TCP 10000 | 129.0.0.1/TCP 5000 | 1082 +---------------------------------+--------------------+ 1084 Dual-Stack lite carrier-grade NAT translation table 1086 The Softwire-Id is the IPv6 address assigned to the Dual-Stack host. 1087 Each host has an unique Softwire-Id. The source IPv4 address is one 1088 of the well-known IPv4 address (TBD by INAN). The carrier-grade NAT 1089 could receive packets from different hosts sourced from the same IPv4 1090 well-known address from different softwire tunnels. Similar to the 1091 SNAT gateway architecture, the Dual-Stack lite carrier grade NAT 1092 combines the Softwire-Id and IPv4 address/Port [Softwire-Id, IPv4+ 1093 Port] to uniquely identify the individual host. 1095 6. Encapsulations 1097 In its simplest deployment model, dual-stack lite only requires IPv4 1098 in IPv6 encapsulation. In more complex scenario where a site gateway 1099 would play the role of the softwire initiator, more complex 1100 encapsulation might be desired. Thus dual-stack lite hosts, dual- 1101 stack lite home gateway and dual-stack lite NAT devices MUST at 1102 minimum implement IPv4 in IPv6 encapsulation. On top of that, dual- 1103 stack lite NAT devices MAY also support other encapsulation, like 1104 L2TPv2/v3, GRE, MPLS,... If they do, they SHOULD support L2TPv2 as 1105 defined in the IETF softwire hub & spoke framework. 1107 7. DNS considerations 1109 A dual-satck lite home gateway is only provision on the WAN interface 1110 with IPv6. As such, all configuration information have to be passed 1111 by the broadband service provider over IPv6. This means that the 1112 home gateway will typically use DHCPv6 [RFC3315] to learn the address 1113 of the DNS recursive server as in [RFC3646]. However, DHCPv6 only 1114 defines an option to pass an IPv6 address of a DNS resolver, not an 1115 IPv4 address. IPv6 node inside the home network may very well use 1116 this IPv6 address to reach the DNS resolver, but IPv4 nodes can't. 1117 They need to be configured with an IPv4 address of a recursive DNS 1118 server. 1120 The recommended way to solve this issue is to configure the home 1121 gateway to act as a DNS proxy, advertizing itself internally with 1122 DHCPv4 as an IPv4 DNS resolver and forwarding the DNS request over 1123 IPv6 to the IPv6 DNS resolver address it has received over DHCPv6. 1124 If the home gateway is also acting as a DHCPv6 server for internal 1125 host and is implementing the DHCPv6 DNS option, it can either also 1126 act as a DNS proxy or simply pass through the IPv6 address of the 1127 service provider DNS recursive server. While implementing a DNS 1128 proxy, the home gateway should follow recommendations in 1129 [I-D.ietf-dnsext-dnsproxy]. 1131 8. Carrier-grade NAT considerations 1133 A dual-stack lite carrier-grade NAT SHOULD implement behavior 1134 conforming to the best current practice, currently documented in 1135 [RFC4787], [I-D.ietf-behave-tcp] and [I-D.ietf-behave-nat-icmp]. 1136 Other requirements for carrier-grade NATs can be found in 1137 [I-D.nishitani-cgn]. 1139 9. Port allocation 1141 Because IPv4 addresses will be shared among customers and potentially 1142 a large address space reduction factor may be applied, in average, 1143 only a limited number N of TCP or UDP port numbers will be available 1144 per customer. This means that applications opening a very large 1145 number of TCP ports may have a harder time to work. For example, it 1146 has been reported that a very well know web site was using AJAX 1147 techniques and was opening up to 69 TCP ports per web page. If we 1148 make the hypothesis of an address space reduction of a factor 100 1149 (one IPv4 address per 100 customers), and 65k ports per IPv4 1150 addresses available, that makes a total of N=650 ports available 1151 simultaneously to be shared among the various devices behind the 1152 dual-stack lite tunnel end-point. 1154 There is an important operational difference if those N ports are 1155 pre-allocated in a cookie-cutter fashion versus allocated on demand 1156 by incoming connections. This is a difference between an average of 1157 N ports and a maximum of N ports. Several service providers have 1158 reported an average number of connections per customer in the single 1159 digit. At the opposite end, thousands or tens of thousands of ports 1160 could be use in a peak by any single customer browsing a number of 1161 AJAX/Web 2.0 sites. With that average number of connections per 1162 customers in mind, having an address space reduction of a factor 100 1163 or more is realistic. 1165 Application expecting incoming connections, such a peer-to-peer ones, 1166 have become popular. Those applications use a very limited number of 1167 ports, usually a single one. Making sure those applications keep 1168 working in a dual-stack lite environment is important. Similarly, 1169 there is a growing list of applications that require some king of ALG 1170 to work through a NAT. Service provider carrier-grade NATs should 1171 not to be in the way of the deployment of such applications. As 1172 such, there is a legitimate need to leave certain ports under the 1173 control of the end user. This argue for an hybrid environment, where 1174 most ports are dynamically managed by the carrier-grade NAT in a 1175 shared pool and a limited number are dedicated per users and 1176 controlled by them. 1178 More considerations on sharing IPv4 addresses can be found in 1179 [I-D.ford-shared-addressing-issues]. 1181 9.1. Static port reservation 1183 A service provider can reserve a static number of ports per user. 1184 Note: those could be TCP and/or UDP ports. The simplest way to allow 1185 users to control the associated NAT bindings is to offer a web 1186 interface (for example as part of the service provider portal) where, 1187 once authenticated, a user can configure each dedicated external IPv4 1188 address/port binding on the carrier-grade NAT in one of the following 1189 way: 1191 o either direct the carrier-grade NAT to forward incoming traffic on 1192 this address/port to the dual-stack lite home gateway, and let 1193 this device deal with it. This required support for A+P 1194 [I-D.ymbk-aplusp] semantic on the home gateway. 1196 o or direct the carrier-grade NAT to rewrite the destination address 1197 in those incoming packets to a private IPv4 address within the 1198 home network. For obvious security reasons, redirection to global 1199 IPv4 address should not be authorized. Note: this behavior is 1200 very similar to the port forwarding function found in most home 1201 gateways. 1203 The exact number of ports reserved per user is left at the discretion 1204 of the service provider. 1206 9.2. Dynamic port reservation 1208 9.2.1. UPnP 1210 One could be tempted to have the home gateway relaying UPnP messages 1211 over the tunnel to the carrier-grade NAT. Unfortunately, this would 1212 not work. Some applications insist on running on a well-known port 1213 number (or port range) using UPnP to request the NAT to reserve that 1214 port. Those ports may or may not be available; they could be used by 1215 another customer. Using UPnP, a NAT box does not have any way to 1216 redirect such applications to use another port, the only option is to 1217 deny the request. Those applications typically then cycle through a 1218 small range of ports (typically 10 or so) until they abort. The 1219 likelihood of those ports being all already in use by other users is 1220 very high. As such, UPnP cannot be supported as-is in a dual-stack 1221 lite environment. 1223 oNote: the UPnP forum has been reported to address this issue in an 1224 upcoming version of the IGD profile. 1226 9.2.2. NAT-PMP 1228 NAT-PMP [I-D.cheshire-nat-pmp] offers a better semantic, by enabling 1229 the NAT to redirect the application to use another unallocated port. 1230 A Dual-stack lite home gateway could proxy the NAT-PMP messages to 1231 the carrier-grade NAT through the tunnel. 1233 9.2.3. DHCPv6 1235 If more ports need to be reserved outside of that static dedicated 1236 range, a DHCPv6 option such as 1237 [I-D.bajko-v6ops-port-restricted-ipaddr-assign] may also be an 1238 interesting approach. This may be limited to the A+P semantic 1239 mentioned above, as there might not be a way to explicitly control 1240 the port forwarding semantic. Also, there are concerns that this 1241 would lead to a cooky cutter distribution of ports per customers, 1242 dramatically reducing the ratio of customer per IPv4 address. 1244 10. Other carrier-grade NAT considerations 1246 10.1. ALG 1248 The carrier-grade NAT should only perform a minimum number of ALG for 1249 the classic applications such as FTP, RTSP/RTP, IPsec and PPTP VPN 1250 pass-through and enable the users to use their own ALG on statically 1251 or dynamically reserved port instead. 1253 In particular, the carrier-grade NAT SHOULD NOT perform any ALG on 1254 the ports reserved either statically or dynamically for a user. 1256 10.2. MTU 1258 Using an encapsulation (IP-in-IP or L2TP) to carry IPv4 traffic over 1259 IPv6 will reduce the effective MTU of the datagram. Unfortunately, 1260 path MTU discovery [RFC1191] is not a reliable method to deal with 1261 this problem. For IPv4-in-IPv6 softwire [RFC2473], we suggest to 1262 increase the MTU size to the link-MTU + 40 bytes to all the links 1263 between the Dual-Stack lite Tunnel Entry-Point and Tunnel Exit-Point 1264 [RFC2473]. The extra 40 bytes can accommodate both the IPv6 1265 encapsulation header and the IPv4 datagram without fragmenting the 1266 IPv6 packet. If the link MTU cannot be increased, the Tunnel Entry- 1267 Point and Tunnel Exit-Point MUST fragment and reassemble the over- 1268 sized datagram after IPv6 encapsulation. When the Tunnel Entry-Point 1269 forwards a packet larger than the MTU after encapsulation, it MUST 1270 fragment the over-sized IPv6 packet into two IPv6 packets. 1271 Fragmentation happens because the resulted IPv6 packet after 1272 encapsulation is larger than MTU. Thus, fragmentation MUST happen 1273 after the encapsulation on the IPv6 packet. When the Tunnel Exit- 1274 Point receives the fragmented IPv6 packets, it MUST reassemble and 1275 decapsulate the packets. Detailed procedure has been specified in 1276 [RFC2473] Section 7.2. 1278 There is a performance trade-off for this approach. Fragmentation at 1279 the Tunnel Entry-Point is a light-weighted operation. In contrast, 1280 reassembly at the Tunnel Exit-Point can be expensive. When the 1281 Tunnel Exit-Point receives the first fragmented packet, it must wait 1282 for the second fragmented packet to arrive in order to reassemble the 1283 two fragmented IPv6 packets for decapsulation. This requires the 1284 Tunnel Exit-Point to buffer and keep track of fragmented packets. 1285 Consider that the carrier-grade NAT is the Tunnel Exit-Point for many 1286 tunnels. If many clients simultaneously source large number of 1287 fragmented packets to the carrier-grade NAT, this will demand the 1288 carrier-grade NAT to buffer and consume enormous resources to keep 1289 track of the flows. This reassembly process will significantly 1290 impact the carrier-grade NAT performance. However, this impact only 1291 happens when many clients simultaneously source large IPv4 packets. 1292 Since we believe that majority of the clients will receive large IPv4 1293 packets (such as watching video streams) instead of sourcing large 1294 IPv4 packets (such as sourcing video streams), so reassembly is only 1295 a fraction of the overall carrier-grade NAT's workload. 1297 Fragmentation/Reassembly could be expensive. We suggest a method to 1298 optimize TCP sessions to reduce the need to fragment and reassemble 1299 TCP packets. When the carrier-grade NAT receive the first TCP SYN 1300 packet which is used to initiate a TCP session, the carrier-grade NAT 1301 rewrites the MSS option in the TCP header to a lower value. When the 1302 carrier-grade NAT receives the returned TCP SYN-ACK for that session, 1303 it will also rewrite the MSS option to a lower value. In the case of 1304 using simple IPv4-in-IPv6, the suggested maximum MSS value is MTU 1305 substracts (IPv6 header + TCP header + IPv4 header). For example: If 1306 the MTU is 1500, the MSS value would be re-written to 1500 - 40 - 20 1307 - 20 = 1420. This optimization tries to assure that the TCP client 1308 and server generate packets smaller than the MTU size after 1309 encapsulation. Hence, fragmentation and reassembly can be avoided 1310 throughout the life-time of this TCP session. 1312 TCP Authentication Option (TCP-AO) [I-D.ietf-tcpm-tcp-auth-opt] is 1313 specified to protect against replays for TCP sessions. In TCP-AO, 1314 when the TCP option flag sets to 0, all TCP options are included in 1315 the MAC calculation. Modifying MSS option by carrier-grade NAT will 1316 alter the Message Authentication Codes (MAC) calculation. Thus, the 1317 TCP-AO originator will consider this is a Man-in-the-Middle attack 1318 and fails the TCP-AO check. When the TCP option flag sets to 1, 1319 TCP-AO will exclude all TCP options in the MAC calculation. 1320 Modifying MSS option will not alter the MAC calculation. Thus, 1321 TCP-AO originator will pass the TCP-AO check. The default TCP-AO 1322 behavior is to set TCP option flag to 0, so using TCP-AO in default 1323 mode with this optimization will cause TCP-AO check to fail. For 1324 those consider to use MSS optimization, we recommend to set the TCP 1325 option flag to 1 when using TCP-AO. TCP-AO is specified to replace 1326 TCP MD5 Signature Option (TCP-MD5) [RFC2385]. TCP-MD5 will continue 1327 to work because TCP-MD5 applies the MD5 algorithm on the TCP header, 1328 excluding options, and assuming a checksum of zero. 1330 11. Future work 1332 The items described bellow could be included in a future version of 1333 this document or be the object of a separate document. 1335 11.1. Multicast considerations 1337 This document only describes unicast IPv4 as IPv4 Multicast is not 1338 widely deployed in broadband networks. Some multicast IPv4 1339 considerations might to be discussed as well in a future revision of 1340 this document. 1342 11.2. 3rd party carrier-grade NAT 1344 The dual-stack lite architecture can be easily extended to support 1345 3rd party carrier-grade NATs. The dual-stack lite interface just 1346 need to be pointed to the IPv6 address of that 3rd party carrier- 1347 grade NAT instead of the IPv6 address of the service provider 1348 carrier-grade NAT. Implementation of dual-stack lite should enable 1349 users to override the mechanism used for automatic discovery of the 1350 carrier grade NAT and, for example, manually enter the DNS name of 1351 the selected carrier-grade NAT. 1353 11.3. Interface initialization 1355 The initialization sequence of each interface of a dual-stack lite 1356 node need to be analyzed and heuristics need to be defined to 1357 determined if each interface operates in IPv4 mode, IPv6 mode, dual- 1358 stack mode or dual-stack lite mode. The absence/presence of the 1359 DHCPv6 option discussed above in requests/responses could be a 1360 trigger to decide in which mode to operate. 1362 12. Comparison with an architecture with multiple-layers of NAT 1364 An alternative architecture could consist on layering multiple levels 1365 of IPv4-IPv4 NAT toward the edges of the service provider network. 1366 Such architecture has a key advantage: it would work with any 1367 existing IPv4 home gateway. However, it would have a number of 1368 drawbacks: 1370 o Each NAT device in the path will have its own application level 1371 gateways, increasing the odds of failure or miss-configuration. 1373 o The larger private IPv4 address space available today is Net 1374 10.0.0.0/8. It can in theory accommodate for about 16 million 1375 addresses, in practice, with an 80% allocation efficiency, it can 1376 address about 13 million devices. This may not be enough for 1377 existing and future large scale deployments, thus multiple 1378 overlapping copies of Net 10 might have to be used simultaneously. 1379 This in itself create more complexity: 1381 * If multiple copies of Net 10 are in use, network 1382 troubleshooting gets more difficult. One first need to figure 1383 out in which Net 10 realm the customer is before sending a ping 1384 to a home gateway to test it. This means that provisioning 1385 systems need to be modified to include this information. 1387 * Multiple overlapping copies of Net 10 often intersect in some 1388 places with routers and firewalls. The configuration of such 1389 devices need to carefully take into accounts the overlapping 1390 address space. Debugging problems created by miss- 1391 configuration can be time consuming. 1393 o Both legacy customers with global IPv4 addresses and new customers 1394 with private IPv4 addresses may be connected to the same 1395 aggregation router. That router will have to make the decision to 1396 send packets directly to the Internet or via a translator based on 1397 the source address of those packets, which is known as source- 1398 based routing. Although not impossible to implement, this adds 1399 complexity to the management of the network. 1401 None of the issues described above are show stoppers, but put 1402 together, they seriously increase the complexity of the management of 1403 the network. 1405 13. Comparison with NAT-PT (or its potential replacements) 1407 NAT-PT [RFC2766] deals with the translation from IPv6 to IPv4 and 1408 vice versa. As such, it would not help solving the problem of 1409 offering IPv4 service to legacy IPv4 hosts. NAT-PT is targeted at 1410 green field IPv6 deployments, allowing them to access services and 1411 content on the IPv4 Internet. In that sense, NAT-PT could be in 1412 competition with dual-stack lite for green field deployment of new 1413 devices directly connected to the broadband service provider network. 1415 In this situation, NAT-PT has the advantage of enabling to remove 1416 entirely the IPv4 stack on edge devices. This may be critical on 1417 sensor type devices with a very small memory footprint. However, it 1418 is unclear if such devices really need to have access to the whole 1419 global IPv4 Internet in the first place or if they only need to 1420 communicate with servers that can be made IPv6 enable. 1422 In the more general case, dual-stack lite has several advantages over 1423 NAT-PT: 1425 o Dual-stack lite does not require any hack to the DNS. In other 1426 words, there is no need to synthesize fake AAAA records to 1427 represent IPv4 addresses. This make DNSsec works more reliably. 1429 o Because of the DNS ALG hack, NAT-PT places restriction on the 1430 topology, in most cases requiring that all exiting traffic go 1431 through a single point of contention. Because there is no DNS ALG 1432 with dual-stack lite and because each dual-stack lite device can 1433 be directed independently to a different dual-stack lite NAT, the 1434 dual-stack lite architecture can scale better. 1436 o ALG sometimes need to manipulate literal IP address in the payload 1437 of packets. In the case of an IPv4-IPv4 NAT, this is a simple 32 1438 bit field replacement. In the case of IPv6-IPv4 (or IPv4-IPv6) 1439 NAT, a 128 bit field need to be substituted by a 32 bit field (or 1440 vice versa). This makes NAT-PT ALG more complex than dual-stack 1441 lite NAT ALG. 1443 For more detail on NAT-PT related issues, see [RFC4966]. 1445 14. Comparison with DSTM 1447 DSTM [I-D.bound-dstm-exp] was addressing IPv6 backward compatibility 1448 with IPv4 by providing a temporary IPv4 address to dual-stack nodes. 1449 Connectivity was also provided by the way of IPv4-in-IPv6 tunnels. 1450 However, DSTM was relying on nodes acquiring and releasing IPv4 1451 addresses on a need to have basis. It is the authors' opinion that 1452 such mechanism may not provide the necessary savings in address space 1453 for large scale broadband deployments. 1455 15. Acknowledgements 1457 The authors would like to acknowledge the role of Mark Townsley for 1458 his input on the overall architecture of this technology by pointing 1459 this work in the direction of [I-D.droms-softwires-snat]. Note that 1460 this document results from a merging of [I-D.durand-dual-stack-lite] 1461 and [I-D.droms-softwires-snat].Also to be acknowledged are the many 1462 discussions with a number of people including Shin Miyakawa, 1463 Katsuyasu Toyama, Akihide Hiura, Takashi Uematsu, Tetsutaro Hara, 1464 Yasunori Matsubayashi, Ichiro Mizukoshi. The author would also like 1465 to thank David Ward, Jari Arkko, Thomas Narten and Geoff Huston for 1466 their constructive feedbacks. A special thank you goes to Dave 1467 Thaler for his review and comments. 1469 16. IANA Considerations 1471 This draft request IANA to allocate a well know IPv4 e.f.g.h/29 1472 network prefix. That range is used to number the dual-stack lite 1473 interfaces. Reserving a /29 allows for 6 possible interfaces on a 1474 multi-home node. The last IPv4 address of this range is reserved as 1475 the IPv4 address of the default router for such dual-stack lite 1476 hosts. 1478 17. Security Considerations 1480 Security issues associated with NAT have long been documented. See 1481 [RFC2663] and [RFC2993]. 1483 However, moving the NAT functionality from the home gateway to the 1484 core of the service provider network and sharing IPv4 addresses among 1485 customers create additional requirements when logging data for abuse 1486 usage. With any architecture where an IPv4 address does not uniquely 1487 represent an end host, IPv4 addresses and a timestamps are no longer 1488 sufficient to identify a particular broadband customer. Additional 1489 information such as transport protocol information will be required 1490 for that purpose. For example, we suggest to log the transport port 1491 number for TCP and UDP connections. 1493 The carrier-grade NAT performs translation functions for interior 1494 IPv4 hosts at RFC 1918 addresses or at the IANA reserved address 1495 range (TBA by IANA). If the interior host is properly using the 1496 authorized IPv4 address with the authorized transport protocol port 1497 range such as A+P semantic for the tunnel, the carrier-grade NAT can 1498 simply forward without translation to permit the authorized address 1499 and port range to function properly. All packets with unauthorized 1500 interior IPv4 addresses or with authorized interior IPv4 address but 1501 unauthorized port range MUST NOT be forwarded by the carrier-grade 1502 NAT. This prevents rogue devices from launching denial of service 1503 attacks using unauthorized public IPv4 addresses in the IPv4 source 1504 header field or unauthorized transport port range in the IPv4 1505 transport header field. For example, rogue devices could bombard a 1506 public web server by launching TCP SYN ACK attack. The victim will 1507 receive TCP SYN from random IPv4 source addresses at a rapid rate and 1508 deny TCP services to legitimate users. 1510 Similarly, some attack mitigation techniques put an IPv4 address in a 1511 "penalty box" for a period of time if an abnormal behavior is 1512 observed. Such techniques may need to be revisited as they would 1513 impact more than just one user (presumably the offender) at a time. 1515 With IPv4 addresses shared by multiple users, ports become a critical 1516 resource. As such, some mechanisms need to be put in place by a 1517 carrier-grade NAT to limit port usage, either by rate-limiting new 1518 connections or putting a hard limit on the maximum number of port 1519 usable by single user. If this number is high enough, it should not 1520 interfere with normal usage and still provide reasonable protection 1521 of the shared pool. 1523 More considerations on sharing IPv4 addresses can be found in 1524 "I-D.ford-shared-addressing-issues". 1526 If some form of IPv6 ingress filtering is deployed in the broadband 1527 network and dual-stack lite service is restricted to those customers, 1528 then tunnels terminating at the carrier-grade NAT and coming from 1529 registered customer IPv6 addresses cannot be spoofed. Thus a simple 1530 access control list on the tunnel transport source address is all 1531 what is required to accept traffic on the southbound interface of a 1532 carrier-grade NAT. 1534 18. Author's Address 1536 This document is the result of the work of the following authors: 1538 Alain Durand 1539 Comcast 1540 1, Comcast center 1541 Philadelphia, PA 19103 1542 USA 1543 Email: alain_durand@cable.comcast.com 1545 Ralph Droms 1546 Cisco 1547 1414 Massachusetts Avenue 1548 Boxborough, MA 01714 1549 USA 1550 Phone: +1 978.936.1674 1551 Email: rdroms@cisco.com 1553 Brian Haberman 1554 Johns Hopkins University Applied Physics Lab 1555 11100 Johns Hopkins Road 1556 Laurel, MD 20723-6099 1557 USA 1558 Phone: +1 443 778 1319 1559 Email: brian@innovationslab.net 1560 James Woodyatt 1561 Apple Inc. 1562 1 Infinite Loop 1563 Cupertino, CA 95014 1564 USA 1565 Email: jhw@apple.com 1567 Yiu Lee 1568 Comcast 1569 1, Comcast center 1570 Philadelphia, PA 19103 1571 USA 1572 Email: yiu_lee@cable.comcast.com 1574 Randy Bush 1575 Internet Initiative Japan 1576 5147 Crystal Springs 1577 Bainbridge Island, Washington 98110 1578 USA 1579 Phone: +1 206 780 0431 x1 1580 Email: randy@psg.com 1582 19. References 1584 19.1. Normative references 1586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1587 Requirement Levels", BCP 14, RFC 2119, March 1997. 1589 19.2. Informative references 1591 [I-D.bajko-v6ops-port-restricted-ipaddr-assign] 1592 Bajko, G. and T. Savolainen, "Port Restricted IP Address 1593 Assignment", 1594 draft-bajko-v6ops-port-restricted-ipaddr-assign-02 (work 1595 in progress), November 2008. 1597 [I-D.bound-dstm-exp] 1598 Bound, J., "Dual Stack IPv6 Dominant Transition Mechanism 1599 (DSTM)", draft-bound-dstm-exp-04 (work in progress), 1600 October 2005. 1602 [I-D.cheshire-nat-pmp] 1603 Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 1604 draft-cheshire-nat-pmp-03 (work in progress), April 2008. 1606 [I-D.despres-sam] 1607 Despres, R., "Stateless Address Mapping (SAM) Avoiding 1608 NATs and restoring the end-to-end model in IPv6", 1609 draft-despres-sam-02 (work in progress), March 2009. 1611 [I-D.dhankins-softwire-tunnel-option] 1612 Hankins, D., "Dynamic Host Configuration Protocol Option 1613 for Dual-Stack Lite", 1614 draft-dhankins-softwire-tunnel-option-03 (work in 1615 progress), March 2009. 1617 [I-D.droms-softwires-snat] 1618 Droms, R. and B. Haberman, "Softwires Network Address 1619 Translation (SNAT)", draft-droms-softwires-snat-01 (work 1620 in progress), July 2008. 1622 [I-D.durand-dual-stack-lite] 1623 Durand, A., "Dual-stack lite broadband deployments post 1624 IPv4 exhaustion", draft-durand-dual-stack-lite-00 (work in 1625 progress), July 2008. 1627 [I-D.ford-shared-addressing-issues] 1628 Durand, A., Ford, M., and P. Roberts, "Issues with ISP 1629 Responses to IPv4 Address Exhaustion", 1630 draft-ford-shared-addressing-issues-00 (work in progress), 1631 March 2009. 1633 [I-D.ietf-behave-nat-icmp] 1634 Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 1635 Behavioral Requirements for ICMP protocol", 1636 draft-ietf-behave-nat-icmp-12 (work in progress), 1637 January 2009. 1639 [I-D.ietf-behave-tcp] 1640 Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1641 Srisuresh, "NAT Behavioral Requirements for TCP", 1642 draft-ietf-behave-tcp-08 (work in progress), 1643 September 2008. 1645 [I-D.ietf-dnsext-dnsproxy] 1646 Bellis, R., "DNS Proxy Implementation Guidelines", 1647 draft-ietf-dnsext-dnsproxy-06 (work in progress), 1648 July 2009. 1650 [I-D.ietf-tcpm-tcp-auth-opt] 1651 Touch, J., Mankin, A., and R. Bonica, "The TCP 1652 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-05 1653 (work in progress), July 2009. 1655 [I-D.nishitani-cgn] 1656 Nishitani, T., Miyakawa, S., Nakagawa, A., and H. Ashida, 1657 "Common Functions of Large Scale NAT (LSN)", 1658 draft-nishitani-cgn-02 (work in progress), June 2009. 1660 [I-D.ymbk-aplusp] 1661 Bush, R., Maennel, O., Zorz, J., Bellovin, S., and L. 1662 Cittadini, "The A+P Approach to the IPv4 Address 1663 Shortage", draft-ymbk-aplusp-03 (work in progress), 1664 March 2009. 1666 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1667 November 1990. 1669 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 1670 October 1994. 1672 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1673 E. Lear, "Address Allocation for Private Internets", 1674 BCP 5, RFC 1918, February 1996. 1676 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1677 Signature Option", RFC 2385, August 1998. 1679 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1680 (IPv6) Specification", RFC 2460, December 1998. 1682 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1683 IPv6 Specification", RFC 2473, December 1998. 1685 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1686 Translator (NAT) Terminology and Considerations", 1687 RFC 2663, August 1999. 1689 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 1690 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1691 February 2000. 1693 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 1694 November 2000. 1696 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1697 and M. Carney, "Dynamic Host Configuration Protocol for 1698 IPv6 (DHCPv6)", RFC 3315, July 2003. 1700 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 1701 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1702 December 2003. 1704 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1705 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1706 RFC 4787, January 2007. 1708 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 1709 Address Translator - Protocol Translator (NAT-PT) to 1710 Historic Status", RFC 4966, July 2007. 1712 [RFC5571] Storer, B., Pignataro, C., Dos Santos, M., Stevant, B., 1713 Toutain, L., and J. Tremblay, "Softwire Hub and Spoke 1714 Deployment Framework with Layer Two Tunneling Protocol 1715 Version 2 (L2TPv2)", RFC 5571, June 2009. 1717 [UPnP-IGD] 1718 UPnP Forum, "Universal Plug and Play Internet Gateway 1719 Device Standardized Gateway Device Protocol", 1720 September 2006, 1721 . 1723 Author's Address 1725 Alain Durand (editor) 1726 Comcast 1727 1, Comcast center 1728 Philadelphia, PA 19103 1729 USA 1731 Email: alain_durand@cable.comcast.com