idnits 2.17.1 draft-ietf-softwire-dual-stack-lite-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 15 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 8 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 3, 2011) is 4800 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) == Outdated reference: A later version (-10) exists of draft-ietf-softwire-ds-lite-tunnel-option-09 == Outdated reference: A later version (-04) exists of draft-ietf-intarea-server-logging-recommendations-03 == Outdated reference: A later version (-05) exists of draft-ietf-intarea-shared-addressing-issues-04 == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-06 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Durand 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track R. Droms 5 Expires: September 4, 2011 Cisco 6 J. Woodyatt 7 Apple 8 Y. Lee 9 Comcast 10 March 3, 2011 12 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion 13 draft-ietf-softwire-dual-stack-lite-07 15 Abstract 17 This document revisits the dual-stack model and introduces the dual- 18 stack lite technology aimed at better aligning the costs and benefits 19 of deploying IPv6 in service provider networks. Dual-stack lite 20 enables a broadband service provider to share IPv4 addresses among 21 customers by combining two well-known technologies: IP in IP (IPv4- 22 in-IPv6) and Network Address Translation (NAT). 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 4, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Requirements language . . . . . . . . . . . . . . . . . . . . 4 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Deployment scenarios . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. Access model . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.2. CPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.3. Directly connected device . . . . . . . . . . . . . . . . 7 65 5. B4 element . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 7 68 5.3. Fragmentation and Reassembly . . . . . . . . . . . . . . . 7 69 5.4. AFTR discovery . . . . . . . . . . . . . . . . . . . . . . 8 70 5.5. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.6. Interface initialization . . . . . . . . . . . . . . . . . 8 72 5.7. Well-known IPv4 address . . . . . . . . . . . . . . . . . 9 73 6. AFTR element . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 6.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 9 75 6.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 9 76 6.3. Fragmentation and Reassembly . . . . . . . . . . . . . . . 9 77 6.4. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 6.5. Well-known IPv4 address . . . . . . . . . . . . . . . . . 10 79 6.6. Extended binding table . . . . . . . . . . . . . . . . . . 10 80 7. Network Considerations . . . . . . . . . . . . . . . . . . . . 10 81 7.1. Tunneling . . . . . . . . . . . . . . . . . . . . . . . . 10 82 7.2. VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 7.3. Multicast considerations . . . . . . . . . . . . . . . . . 11 84 8. NAT considerations . . . . . . . . . . . . . . . . . . . . . . 11 85 8.1. NAT pool . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 8.2. NAT conformance . . . . . . . . . . . . . . . . . . . . . 11 87 8.3. Application Level Gateways (ALG) . . . . . . . . . . . . . 11 88 8.4. Sharing global IPv4 addresses . . . . . . . . . . . . . . 11 89 8.5. Port forwarding / keep alive . . . . . . . . . . . . . . . 12 90 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 92 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 93 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 12.1. Normative references . . . . . . . . . . . . . . . . . . . 14 95 12.2. Informative references . . . . . . . . . . . . . . . . . . 14 97 Appendix A. Deployment considerations . . . . . . . . . . . . . . 16 98 A.1. AFTR service distribution and horizontal scaling . . . . . 16 99 A.2. Horizontal scaling . . . . . . . . . . . . . . . . . . . . 16 100 A.3. High availability . . . . . . . . . . . . . . . . . . . . 16 101 A.4. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 16 102 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 17 103 B.1. Gateway based architecture . . . . . . . . . . . . . . . . 17 104 B.1.1. Example message flow . . . . . . . . . . . . . . . . . 19 105 B.1.2. Translation details . . . . . . . . . . . . . . . . . 23 106 B.2. Host based architecture . . . . . . . . . . . . . . . . . 24 107 B.2.1. Example message flow . . . . . . . . . . . . . . . . . 27 108 B.2.2. Translation details . . . . . . . . . . . . . . . . . 31 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 111 1. Introduction 113 The common thinking for more than 10 years has been that the 114 transition to IPv6 will be based solely on the dual stack model and 115 that most things would be converted this way before we ran out of 116 IPv4. However, this has not happened. The IANA free pool of IPv4 117 addresses has now depleted, well before sufficient IPv6 deployment 118 had taken place. As a result, many IPv4 services have to continue to 119 be provided even under severely limited address space. 121 This document specifies the dual-stack lite technology which is aimed 122 at better aligning the costs and benefits in service provider 123 networks. Dual-stack lite will enable both continued support for 124 IPv4 services and incentives for the deployment of IPv6. It also de- 125 couples IPv6 deployment in the service provider network from the rest 126 of the Internet, making incremental deployment easier. 128 Dual-stack lite enables a broadband service provider to share IPv4 129 addresses among customers by combining two well-known technologies: 130 IP in IP (IPv4-in-IPv6) and NAT. 132 This document makes a distinction between a dual-stack capable and a 133 dual-stack provisioned device. The former is a device that has code 134 that implements both IPv4 and IPv6, from the network layer to the 135 applications. The latter is a similar device that has been 136 provisioned with both an IPv4 and an IPv6 address on its 137 interface(s). This document will also further refine this notion by 138 distinguishing between interfaces provisioned directly by the service 139 provider from those provisioned by the customer. 141 Pure IPv6-only devices (i.e. devices that do not include an IPv4 142 stack) are outside of the scope of this document. 144 This document will first present some deployment scenario and then 145 define the behavior of the two elements of the dual-stack lite 146 technology: the B4 and the AFTR. It will then go into networking and 147 NAT-ing considerations. 149 2. Requirements language 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in RFC 2119 [RFC2119]. 155 3. Terminology 157 The technology described in this document is known as dual-stack 158 lite. The abbreviation DS-Lite will be used along this text. 160 This document also introduces two new terms: the DS-Lite Basic 161 Bridging BroadBand element (B4) and the DS-Lite Address Family 162 Transition Router element (AFTR). 164 Dual-stack is defined in [RFC4213]. 166 NAT related terminology is defined in [RFC4787]. 168 CPE stands for Customer Premise Equipment. This is the layer 3 169 device in the customer premise that is connected to the service 170 provider network. That device is often a home gateway. However, 171 sometimes computers are directly attached to the service provider 172 network. In such cases, such computers can be viewed as CPEs as 173 well. 175 4. Deployment scenarios 177 4.1. Access model 179 Instead of relying on a cascade of NATs, the dual-stack lite model is 180 built on IPv4-in-IPv6 tunnels to cross the network to reach a 181 carrier-grade IPv4-IPv4 NAT (the AFTR) where customers will share 182 IPv4 addresses. There are numbers of benefits to this approach: 184 o This technology decouples the deployment of IPv6 in the service 185 provider network (up to the customer premise equipment or CPE) 186 from the deployment of IPv6 in the global Internet and in customer 187 applications & devices. 189 o The management of the service provider access networks is 190 simplified by leveraging the large IPv6 address space. 191 Overlapping private IPv4 address spaces are not required to 192 support very large customer bases. 194 o As tunnels can terminate anywhere in the service provider network, 195 this architecture leads itself to horizontal scaling and provides 196 great flexibility to adapt to changing traffic load. 198 o Tunnels provide a direct connection between B4 and the AFTR. This 199 can be leveraged to enable customers and their applications to 200 control how the NAT function of the AFTR is performed. 202 A key characteristic of this approach is that communications between 203 end-nodes stay within their address family. IPv6 sources only 204 communicate with IPv6 destinations, IPv4 sources only communicate 205 with IPv4 destinations. There is no protocol family translation 206 involved in this approach. This simplifies greatly the task of 207 applications that may carry literal IP addresses in their payload. 209 4.2. CPE 211 This section describes home Local Area networks characterized by the 212 presence of a home gateway, or CPE, provisioned only with IPv6 by the 213 service provider. 215 A DS-Lite CPE is an IPv6 aware CPE with a B4 Interface implemented in 216 the WAN interface. 218 A DS-Lite CPE SHOULD NOT operate a NAT function between an internal 219 interface and a B4 interface, as the NAT function will be performed 220 by the AFTR in the service provider's network. That will avoid 221 accidentally operating in a double NAT environment. 223 However, it SHOULD operate its own DHCP(v4) server handing out 224 [RFC1918] address space (e.g. 192.168.0.0/16) to hosts in the home. 225 It SHOULD advertise itself as the default IPv4 router to those home 226 hosts. It SHOULD also advertise itself as a DNS server in the DHCP 227 Option 6 (DNS Server). Additionally, it SHOULD operate a DNS proxy 228 to accept DNS IPv4 requests from home hosts and send them using IPv6 229 to the service provider DNS servers, as described in Section 5.5. 231 Note: if an IPv4 home host decides to use another IPv4 DNS server, 232 the DS-Lite CPE will forward those DNS requests via the B4 interface, 233 the same way it forwards any regular IPv4 packets. However, each DNS 234 request will create a binding in the AFTR. A large number of DNS 235 requests may have direct impact to the AFTR's NAT table utilization. 237 IPv6 capable devices directly reach the IPv6 Internet. Packets 238 simply follow IPv6 routing, they do not go through the tunnel, and 239 are not subject to any translation. It is expected that most IPv6 240 capable devices will also be IPv4 capable and will simply be 241 configured with an IPv4 RFC1918 style address within the home network 242 and access the IPv4 Internet the same way as the legacy IPv4-only 243 devices within the home. 245 Pure IPv6-only devices (i.e. devices that do not include an IPv4 246 stack) are outside of the scope of this document. 248 4.3. Directly connected device 250 In broadband home networks, some devices are directly connected to 251 the broadband service provider. They are connected straight to a 252 modem, without a home gateway. Those devices are, in fact, acting as 253 CPEs. 255 Under this scenario, the customer device is a dual-stack capable host 256 that is only provisioned by the service provider with IPv6 only. The 257 device itself acts as a B4 element and the IPv4 service is provided 258 by an IPv4-in-IPv6 tunnel, just as in the home gateway/CPE case. 259 That device can run any combinations of IPv4 and/or IPv6 260 applications. 262 A directly connected DS-Lite device SHOULD send its DNS requests over 263 IPv6 to the IPv6 DNS server it has been configured to use. 265 Similarly to the previous sections, IPv6 packets follow IPv6 routing, 266 they do not go through the tunnel, and are not subject to any 267 translation. 269 The support of IPv4-only devices and IPv6-only devices in this 270 scenario is out of scope for this document. 272 5. B4 element 274 5.1. Definition 276 The B4 element is a function implemented on a dual-stack capable 277 node, either a directly connected device or a CPE, that creates a 278 tunnel to an AFTR. 280 5.2. Encapsulation 282 The tunnel is a multi-point to point IPv4-in-IPv6 tunnel ending on a 283 service provider AFTR. 285 See section 7.1 for additional tunneling considerations. 287 Note: at this point, DS-Lite only defines IPv4-in-IPv6 tunnels, 288 however other types of encapsulation could be defined in the future. 290 5.3. Fragmentation and Reassembly 292 Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4 293 traffic over IPv6 will reduce the effective MTU of the datagram. 294 Unfortunately, path MTU discovery [RFC1191] is not a reliable method 295 to deal with this problem. 297 A solution to deal with this problem is for the service provider to 298 increase the MTU size of all the links between the B4 element and the 299 AFTR elements by at least 40 bytes to accommodate both the IPv6 300 encapsulation header and the IPv4 datagram without fragmenting the 301 IPv6 packet. 303 However, as not all service providers will be able to increase their 304 link MTU, the B4 element MUST perform fragmentation and reassembly if 305 the outgoing link MTU cannot accommodate for the extra IPv6 header. 306 Fragmentation MUST happen after the encapsulation on the IPv6 packet. 307 Reassembly MUST happen before the decapsulation of the IPv6 header. 308 Detailed procedure has been specified in [RFC2473] Section 7.2. 310 5.4. AFTR discovery 312 In order to configure the IPv4-in-IPv6 tunnel, the B4 element needs 313 the IPv6 address of the AFTR element. This IPv6 address can be 314 configured using a variety of methods, ranging from an out-of-band 315 mechanism, manual configuration or a variety of DHCPv6 options. 317 In order to guarantee interoperability, a B4 element SHOULD implement 318 the DHCPv6 option defined in 319 [I-D.ietf-softwire-ds-lite-tunnel-option]. 321 5.5. DNS 323 A B4 element is only configured from the service provider with IPv6. 324 As such, it can only learn the address of a DNS recursive server 325 through DHCPv6 (or other similar method over IPv6). As DHCPv6 only 326 defines an option to get the IPv6 address of such a DNS recursive 327 server, the B4 element cannot easily discover the IPv4 address of 328 such a recursive DNS server, and as such will have to perform all DNS 329 resolution over IPv6. 331 The B4 element can pass this IPv6 address to downstream IPv6 nodes, 332 but not to downstream IPv4 nodes. As such, the B4 element SHOULD 333 implement a DNS proxy, following the recommendations of [RFC5625]. 335 5.6. Interface initialization 337 Initialization of the interface including a B4 element is out-of- 338 scope in this specification. 340 5.7. Well-known IPv4 address 342 Any locally unique IPv4 address could be configured on the IPv4-in- 343 IPv6 tunnel to represent the B4 element. Configuring such an address 344 is often necessary when the B4 element is sourcing IPv4 datagrams 345 directly over the tunnel. In order to avoid conflicts with any other 346 address, IANA has defined a well-known range, 192.0.0.0/29. 348 192.0.0.0 is the reserved subnet address. 192.0.0.1 is reserved for 349 the AFTR element. The B4 element MAY use any other addresses within 350 the 192.0.0.0/29 range. 352 Note: a range of addresses has been reserved for this purpose. The 353 intent is to accommodate nodes implementing multiple B4 elements. 355 6. AFTR element 357 6.1. Definition 359 An AFTR element is the combination of an IPv4-in-IPv6 tunnel end- 360 point and an IPv4-IPv4 NAT implemented on the same node. 362 6.2. Encapsulation 364 The tunnel is a point-to-multipoint IPv4-in-IPv6 tunnel ending at the 365 B4 elements. 367 See section 7.1 for additional tunneling considerations. 369 Note: at this point, DS-Lite only defines IPv4-in-IPv6 tunnels, 370 however other types of encapsulation could be defined in the future. 372 6.3. Fragmentation and Reassembly 374 As noted previously, fragmentation and reassembly need to be taken 375 care of by the tunnel end-points. As such, the AFTR MUST perform 376 fragmentation and reassembly if the underlying link MTU cannot 377 accommodate the extra IPv6 header of the tunnel. Fragmentation MUST 378 happen after the encapsulation on the IPv6 packet. Reassembly MUST 379 happen before the decapsulation of the IPv6 header. Detailed 380 procedure has been specified in [RFC2473] Section 7.2. 382 Fragmentation at the Tunnel Entry-Point is a light-weight operation. 383 In contrast, reassembly at the Tunnel Exit-Point can be expensive. 384 When the Tunnel Exit-Point receives the first fragmented packet, it 385 must wait for the second fragmented packet to arrive in order to 386 reassemble the two fragmented IPv6 packets for decapsulation. This 387 requires the Tunnel Exit-Point to buffer and keep track of fragmented 388 packets. Consider that the AFTR is the Tunnel Exit-Point for many 389 tunnels. If many clients simultaneously source large number of 390 fragmented packets to the AFTR, this will require the AFTR to buffer 391 and consume enormous resources to keep track of the flows. This 392 reassembly process will significantly impact the AFTR performance. 393 However, this impact only happens when many clients simultaneously 394 source large IPv4 packets. Since we believe that majority of the 395 clients will receive large IPv4 packets (such as watching video 396 streams) instead of sourcing large IPv4 packets (such as sourcing 397 video streams), so reassembly is only a fraction of the overall 398 AFTR's workload. 400 Methods to avoid fragmentation, such as rewriting the TCP MSS option 401 or using technologies such as Subnetwork Encapsulation and Adaptation 402 Layer defined in [RFC5320] are out of scope for this document. 404 6.4. DNS 406 As noted previously, DS-Lite node implementing a B4 elements will 407 perform DNS resolution over IPv6. As such, very few, if any, DNS 408 packets will flow through the AFTR element. 410 6.5. Well-known IPv4 address 412 The AFTR MAY use the well-known IPv4 address 192.0.0.1 reserved by 413 IANA to configure the IPv4-in-IPv6 tunnel. That address can then be 414 used to report ICMP problems and will appear in traceroute outputs. 416 6.6. Extended binding table 418 The NAT binding table of the AFTR element is extended to include the 419 source IPv6 address of the incoming packets. This IPv6 address is 420 used to disambiguate between the overlapping IPv4 address space of 421 the service provider customers. 423 By doing a reverse look-up in the extended IPv4 NAT binding table, 424 the AFTR knows how to reconstruct the IPv6 encapsulation when the 425 packets comes back from the Internet. That way, there is no need to 426 keep a static configuration for each tunnel. 428 7. Network Considerations 430 7.1. Tunneling 432 Tunneling MUST be done in accordance to [RFC2473] and [RFC4213]. 433 Traffic classes ([RFC2474]) from the IPv4 headers SHOULD be carried 434 over to the IPv6 headers and vice versa. 436 7.2. VPN 438 Dual-stack lite implementations SHOULD NOT interfere with the 439 functioning of IPv4 or IPv6 VPNs. 441 7.3. Multicast considerations 443 Multicast is out-of-scope in this document. 445 8. NAT considerations 447 8.1. NAT pool 449 The AFTR MAY be provisioned with different NAT pools. The address 450 range in the pools may be disjoint but must not be overlapped. 451 Operators may implement policies in the AFTR to assign clients in 452 different pools. For example, a AFTR can have two interfaces. Each 453 interface will have a disjoint pool NAT assigned to it. In another 454 case, a policy can apply to the AFTR that a set of B4s will use NAT 455 pool 1 and a different set of B4s will use NAT pool 2. 457 8.2. NAT conformance 459 A dual-stack lite AFTR SHOULD implement behavior conforming to the 460 best current practice, currently documented in [RFC4787] and 461 [RFC5382]. Other discusions about carrier-grade NATs can be found in 462 [I-D.nishitani-cgn]. 464 8.3. Application Level Gateways (ALG) 466 AFTR performs NAT-44 and inherits the limitations of NAT. Some 467 protocols required ALGs in the NAT device to traverse through the 468 NAT. For example: SIP and ICMP require ALG to work properly. ALGs 469 consume resources and there are many different types of ALGs. The 470 AFTR is a shared network device that supports a large number of B4 471 elements. It is impossible for the AFTR to implement every current 472 and future ALGs. This specification only requires that the AFTR MUST 473 support [RFC5508]. Implementers can decide to implement other ALGs 474 in their implementations. 476 8.4. Sharing global IPv4 addresses 478 AFTR shares a single IP to multiple users. This helps to increase 479 the IPv4 address utilization. However, it also brings some issues 480 such as logging and lawful intercept. More considerations on sharing 481 the port space of IPv4 addresses can be found in 482 [I-D.ietf-intarea-shared-addressing-issues]. 484 8.5. Port forwarding / keep alive 486 Work on a control plane to the carrier-grade NAT is done in the PCP 487 working group at IETF. The PCP protocol enables applications to 488 directly negotiate with the NAT to open ports and negotiate liefetime 489 values to avoid keep-alive traffic. More on PCP can be found in 490 [I-D.ietf-pcp-base]. 492 9. Acknowledgements 494 The authors would like to acknowledge the role of Mark Townsley for 495 his input on the overall architecture of this technology by pointing 496 this work in the direction of [I-D.droms-softwires-snat]. Note that 497 this document results from a merging of [I-D.durand-dual-stack-lite] 498 and [I-D.droms-softwires-snat].Also to be acknowledged are the many 499 discussions with a number of people including Shin Miyakawa, 500 Katsuyasu Toyama, Akihide Hiura, Takashi Uematsu, Tetsutaro Hara, 501 Yasunori Matsubayashi, Ichiro Mizukoshi. The author would also like 502 to thank David Ward, Jari Arkko, Thomas Narten and Geoff Huston for 503 their constructive feedback. Special thanks go to Dave Thaler and 504 Dan Wing for their reviews and comments. 506 10. IANA Considerations 508 This draft request IANA to allocate a well know IPv4 192.0.0.0/29 509 network prefix. That range is used to number the dual-stack lite 510 interfaces. Reserving a /29 allows for 6 possible interfaces on a 511 multi-home node. The IPv4 address 192.0.0.1 is reserved as the IPv4 512 address of the default router for such dual-stack lite hosts. 514 11. Security Considerations 516 Security issues associated with NAT have long been documented. See 517 [RFC2663] and [RFC2993]. 519 However, moving the NAT functionality from the CPE to the core of the 520 service provider network and sharing IPv4 addresses among customers 521 create additional requirements when logging data for abuse usage. 522 With any architecture where an IPv4 address does not uniquely 523 represent an end host, IPv4 addresses and a timestamps are no longer 524 sufficient to identify a particular broadband customer. The AFTR 525 should have the capability to log the tunnel-id, protocol, ports/IP 526 addresses, and the creation time of the NAT binding to uniquely 527 identify the user sessions. Exact details of what is logged are 528 implementation specific and out of scope for this document. 530 The AFTR performs translation functions for interior IPv4 hosts using 531 RFC 1918 addresses or the IANA reserved address range (TBA by IANA). 532 In some circumstances, ISP may provision policies in the AFTR and 533 instructs the AFTR to bypass translation functions based on . When the AFTR receives a packet 535 with matching information of the policy from the interior host, the 536 AFTR can simply forward without translation. The addresses, ports 537 and protocols information must be provisioned on the AFTR before 538 receiving the packet. The provisioning mechanism is out-of-scope of 539 this specification. 541 When decapsulating packets, the AFTR MUST only forward packets 542 sourced by RFC 1918 addresses, IANA reserved address range, or any 543 other out-of-band pre-authorized addresses. The AFTR MUST drop all 544 others packets. This prevents rogue devices from launching denial of 545 service attacks using unauthorized public IPv4 addresses in the IPv4 546 source header field or unauthorized transport port range in the IPv4 547 transport header field. For example, rogue devices could bombard a 548 public web server by launching a TCP SYN ACK attack [RFC4987]. The 549 victim will receive TCP SYN from random IPv4 source addresses at a 550 rapid rate and deny TCP services to legitimate users. 552 With IPv4 addresses shared by multiple users, ports become a critical 553 resource. As such, some mechanisms need to be put in place by an 554 AFTR to limit port usage, either by rate-limiting new connections or 555 putting a hard limit on the maximum number of port usable by a single 556 user. If this number is high enough, it should not interfere with 557 normal usage and still provide reasonable protection of the shared 558 pool. More considerations on sharing IPv4 addresses can be found in 559 [I-D.ietf-intarea-shared-addressing-issues]. Other considerations 560 and recommendations on logging can be found in 561 [I-D.ietf-intarea-server-logging-recommendations]. 563 AFTRs should support ways to limit service only to registered 564 customers. One simple option is to implement IPv6 ingress filter on 565 the AFTR's tunnel interface to accept only the IPv6 address range 566 defined in the filter. 568 12. References 569 12.1. Normative references 571 [I-D.ietf-softwire-ds-lite-tunnel-option] 572 Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 573 Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite", 574 draft-ietf-softwire-ds-lite-tunnel-option-09 (work in 575 progress), March 2011. 577 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 578 Requirement Levels", BCP 14, RFC 2119, March 1997. 580 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 581 IPv6 Specification", RFC 2473, December 1998. 583 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 584 "Definition of the Differentiated Services Field (DS 585 Field) in the IPv4 and IPv6 Headers", RFC 2474, 586 December 1998. 588 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 589 for IPv6 Hosts and Routers", RFC 4213, October 2005. 591 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 592 BCP 152, RFC 5625, August 2009. 594 12.2. Informative references 596 [I-D.droms-softwires-snat] 597 Droms, R. and B. Haberman, "Softwires Network Address 598 Translation (SNAT)", draft-droms-softwires-snat-01 (work 599 in progress), July 2008. 601 [I-D.durand-dual-stack-lite] 602 Durand, A., "Dual-stack lite broadband deployments post 603 IPv4 exhaustion", draft-durand-dual-stack-lite-00 (work in 604 progress), July 2008. 606 [I-D.ietf-intarea-server-logging-recommendations] 607 Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 608 "Logging recommendations for Internet facing servers", 609 draft-ietf-intarea-server-logging-recommendations-03 (work 610 in progress), February 2011. 612 [I-D.ietf-intarea-shared-addressing-issues] 613 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 614 Roberts, "Issues with IP Address Sharing", 615 draft-ietf-intarea-shared-addressing-issues-04 (work in 616 progress), February 2011. 618 [I-D.ietf-pcp-base] 619 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and F. 620 Dupont, "Port Control Protocol (PCP)", 621 draft-ietf-pcp-base-06 (work in progress), February 2011. 623 [I-D.nishitani-cgn] 624 Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, 625 "Common requirements for IP address sharing schemes", 626 draft-nishitani-cgn-05 (work in progress), July 2010. 628 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 629 November 1990. 631 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 632 E. Lear, "Address Allocation for Private Internets", 633 BCP 5, RFC 1918, February 1996. 635 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 636 Translator (NAT) Terminology and Considerations", 637 RFC 2663, August 1999. 639 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 640 November 2000. 642 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 643 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 644 RFC 4787, January 2007. 646 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 647 Mitigations", RFC 4987, August 2007. 649 [RFC5320] Templin, F., "The Subnetwork Encapsulation and Adaptation 650 Layer (SEAL)", RFC 5320, February 2010. 652 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 653 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 654 RFC 5382, October 2008. 656 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 657 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 658 April 2009. 660 [RFC5571] Storer, B., Pignataro, C., Dos Santos, M., Stevant, B., 661 Toutain, L., and J. Tremblay, "Softwire Hub and Spoke 662 Deployment Framework with Layer Two Tunneling Protocol 663 Version 2 (L2TPv2)", RFC 5571, June 2009. 665 Appendix A. Deployment considerations 667 A.1. AFTR service distribution and horizontal scaling 669 One of the key benefits of the dual-stack lite technology lies in the 670 fact it is tunnel based. That is, tunnel end-points may be anywhere 671 in the service provider network. 673 Using the DHCPv6 tunnel end-point option, service providers can 674 create groups of users sharing the same AFTR. Those groups can be 675 merged or divided at will. This leads to an horizontally scaled 676 solution, where more capacity is added simply by adding more boxes. 677 As those groups of users can evolve over time, it is best to make 678 sure that AFTRs do not require per-user configuration in order to 679 provide service. 681 A.2. Horizontal scaling 683 A service provider can start using just a few AFTR centrally located. 684 Later, when more capacity is needed, more boxes can be added and 685 pushed to the edges of the access network. In case of a spike of 686 traffic, for example during the Olympic games or an important 687 political event, capacity can be quickly added in any location of the 688 network (tunnels can terminate anywhere) simply by splitting user 689 groups. Extra capacity can be later removed when the traffic returns 690 to normal by resetting the DHCPv6 tunnel end-point settings. 692 A.3. High availability 694 An important element in the design of the dual-stack lite technology 695 is the simplicity of implementation on the customer side. A simple 696 IP4-in-IPv6 tunnel and a default route over it is all is needed to 697 get IPv4 connectivity. Dealing with high availability is the 698 responsibility of the service provider, not the customer devices 699 implementing dual-stack lite. As such, a single IPv6 address of the 700 tunnel end-point is provided in the DHCPv6 option defined in 701 [I-D.ietf-softwire-ds-lite-tunnel-option]. The service provider can 702 use techniques such as anycast or various types of clusters to ensure 703 availability of the IPv4 service. The exact synchronization (or lack 704 thereof) between redundant AFTRs is out of scope for this document. 706 A.4. Logging 708 DS-Lite AFTR implementation should offer the possibility to log NAT 709 binding creations or other ways to keep track of the ports/IP 710 addresses used by customers. This is both to support 711 troubleshooting, which is very important to service providers trying 712 to figure out why something may not be working, as well as to meet 713 region-specific requirements for responding to legally-binding 714 requests for information from law enforcement authorities. 716 Appendix B. Examples 718 B.1. Gateway based architecture 720 This architecture is targeted at residential broadband deployments 721 but can be adapted easily to other types of deployment where the 722 installed base of IPv4-only devices is important. 724 Consider a scenario where a Dual-Stack lite CPE is provisioned only 725 with IPv6 in the WAN port, no IPv4. The CPE acts as an IPv4 DCHP 726 server for the LAN network (wireline and wireless) handing out 727 RFC1918 addresses. In addition, the CPE may support IPv6 Auto- 728 Configuration and/or DHCPv6 server for the LAN network. When an 729 IPv4-only device connects to the CPE, that CPE will hand it out a 730 RFC1918 address. When a dual-stack capable device connects to the 731 CPE, that CPE will hand out a RFC1918 address and a global IPv6 732 address to the device. Besides, the CPE will create an IPv4-in-IPv6 733 softwire tunnel [RFC5571]to an AFTR that resides in the service 734 provider network. 736 When the device accesses IPv6 service, it will send the IPv6 datagram 737 to the CPE natively. The CPE will route the traffic upstream to the 738 default gateway. 740 When the device accesses IPv4 service, it will source the IPv4 741 datagram with the RFC1918 address and send the IPv4 datagram to the 742 CPE. The CPE will encapsulate the IPv4 datagram inside the IPv4-in- 743 IPv6 softwire tunnel and forward the IPv6 datagram to the AFTR. This 744 contrasts what the CPE normally does today, which is, NAT the RFC1918 745 address to the public IPv4 address and route the datagram upstream. 746 When the AFTR receives the IPv6 datagram, it will decapsulate the 747 IPv6 header and perform an IPv4-to-IPv4 NAT on the source address. 749 As illustrated in Figure 1, this dual-stack lite deployment model 750 consists of three components: the dual-stack lite home router with a 751 B4 element, the AFTR and a softwire between the B4 element acting as 752 softwire initiator (SI) [RFC5571] in the dual-stack lite home router 753 and the softwire concentrator (SC) [RFC5571] in the AFTR. The AFTR 754 performs IPv4-IPv4 NAT translations to multiplex multiple subscribers 755 through a pool of global IPv4 address. Overlapping address spaces 756 used by subscribers are disambiguated through the identification of 757 tunnel endpoints. 759 +-----------+ 760 | Host | 761 +-----+-----+ 762 |10.0.0.1 763 | 764 | 765 |10.0.0.2 766 +---------|---------+ 767 | | | 768 | Home router | 769 |+--------+--------+| 770 || B4 || 771 |+--------+--------+| 772 +--------|||--------+ 773 |||2001:db8:0:1::1 774 ||| 775 |||<-IPv4-in-IPv6 softwire 776 ||| 777 -------|||------- 778 / ||| \ 779 | ISP core network | 780 \ ||| / 781 -------|||------- 782 ||| 783 |||2001:db8:0:2::1 784 +--------|||--------+ 785 | AFTR | 786 |+--------+--------+| 787 || Concentrator || 788 |+--------+--------+| 789 | |NAT| | 790 | +-+-+ | 791 +---------|---------+ 792 |192.0.2.1 793 | 794 --------|-------- 795 / | \ 796 | Internet | 797 \ | / 798 --------|-------- 799 | 800 |198.51.100.1 801 +-----+-----+ 802 | IPv4 Host | 803 +-----------+ 805 Figure 1: gateway-based architecture 807 Notes: 809 o The dual-stack lite home router is not required to be on the same 810 link as the host 812 o The dual-stack lite home router could be replaced by a dual-stack 813 lite router in the service provider network 815 The resulting solution accepts an IPv4 datagram that is translated 816 into an IPv4-in-IPv6 softwire datagram for transmission across the 817 softwire. At the corresponding endpoint, the IPv4 datagram is 818 decapsulated, and the translated IPv4 address is inserted based on a 819 translation from the softwire. 821 B.1.1. Example message flow 823 In the example shown in Figure 2, the translation tables in the AFTR 824 is configured to forward between IP/TCP (10.0.0.1/10000) and IP/TCP 825 (192.0.2.1/5000). That is, a datagram received by the dual-stack 826 lite home router from the host at address 10.0.0.1, using TCP DST 827 port 10000 will be translated a datagram with IP SRC address 828 192.0.2.1 and TCP SRC port 5000 in the Internet. 830 +-----------+ 831 | Host | 832 +-----+-----+ 833 | |10.0.0.1 834 IPv4 datagram 1 | | 835 | | 836 v |10.0.0.2 837 +---------|---------+ 838 | | | 839 | home router | 840 |+--------+--------+| 841 || B4 || 842 |+--------+--------+| 843 +--------|||--------+ 844 | |||2001:db8:0:1::1 845 IPv6 datagram 2| ||| 846 | |||<-IPv4-in-IPv6 softwire 847 | ||| 848 -----|-|||------- 849 / | ||| \ 850 | ISP core network | 851 \ | ||| / 852 -----|-|||------- 853 | ||| 854 | |||2001:db8:0:2::1 855 +------|-|||--------+ 856 | | AFTR | 857 | v ||| | 858 |+--------+--------+| 859 || Concentrartor || 860 |+--------+--------+| 861 | |NAT| | 862 | +-+-+ | 863 +---------|---------+ 864 | |192.0.2.1 865 IPv4 datagram 3 | | 866 | | 867 -----|--|-------- 868 / | | \ 869 | Internet | 870 \ | | / 871 -----|--|-------- 872 | | 873 v |198.51.100.1 874 +-----+-----+ 875 | IPv4 Host | 876 +-----------+ 877 Figure 2: Outbound Datagram 879 +-----------------+--------------+-----------------+ 880 | Datagram | Header field | Contents | 881 +-----------------+--------------+-----------------+ 882 | IPv4 datagram 1 | IPv4 Dst | 198.51.100.1 | 883 | | IPv4 Src | 10.0.0.1 | 884 | | TCP Dst | 80 | 885 | | TCP Src | 10000 | 886 | --------------- | ------------ | ------------- | 887 | IPv6 Datagram 2 | IPv6 Dst | 2001:db8:0:2::1 | 888 | | IPv6 Src | 2001:db8:0:1::1 | 889 | | IPv4 Dst | 198.51.100.1 | 890 | | IPv4 Src | 10.0.0.1 | 891 | | TCP Dst | 80 | 892 | | TCP Src | 10000 | 893 | --------------- | ------------ | ------------- | 894 | IPv4 datagram 3 | IPv4 Dst | 198.51.100.1 | 895 | | IPv4 Src | 192.0.2.1 | 896 | | TCP Dst | 80 | 897 | | TCP Src | 5000 | 898 +-----------------+--------------+-----------------+ 900 Datagram header contents 902 When datagram 1 is received by the dual-stack lite home router, the 903 B4 function encapsulates the datagram in datagram 2 and forwards it 904 to the dual-stack lite carrier-grade NAT over the softwire. 906 When it receives datagram 2, the tunnel concentrator in the AFTR 907 hands the IPv4 datagram to the NAT, which determines from its 908 translation table that the datagram received on Softwire_1 with TCP 909 SRC port 10000 should be translated to datagram 3 with IP SRC address 910 192.0.2.1 and TCP SRC port 5000. 912 Figure 3 shows an inbound message received at the AFTR. When the NAT 913 function in the AFTR receives datagram 1, it looks up the IP/TCP DST 914 in its translation table. In the example in Figure 3, the NAT 915 translates the TCP DST port to 10000, sets the IP DST address to 916 10.0.0.1 and hands the datagram to the SC for transmission over 917 Softwire_1. The B4 in the home router decapsulates IPv4 datagram 918 from the inbound softwire datagram, and forwards it to the host. 920 +-----------+ 921 | Host | 922 +-----+-----+ 923 ^ |10.0.0.1 924 IPv4 datagram 3 | | 925 | | 926 | |10.0.0.2 927 +---------|---------+ 928 | +-+-+ | 929 | home router | 930 |+--------+--------+| 931 || B4 || 932 |+--------+--------+| 933 +--------|||--------+ 934 ^ |||2001:db8:0:1::1 935 IPv6 datagram 2 | ||| 936 | |||<-IPv4-in-IPv6 softwire 937 | ||| 938 -----|-|||------- 939 / | ||| \ 940 | ISP core network | 941 \ | ||| / 942 -----|-|||------- 943 | ||| 944 | |||2001:db8:0:2::1 945 +------|-|||--------+ 946 | AFTR | 947 |+--------+--------+| 948 || Concentrator || 949 |+--------+--------+| 950 | |NAT| | 951 | +-+-+ | 952 +---------|---------+ 953 ^ |192.0.2.1 954 IPv4 datagram 1 | | 955 | | 956 -----|--|-------- 957 / | | \ 958 | Internet | 959 \ | | / 960 -----|--|-------- 961 | | 962 | |198.51.100.1 963 +-----+-----+ 964 | IPv4 Host | 965 +-----------+ 967 Figure 3: Inbound Datagram 969 +-----------------+--------------+-----------------+ 970 | Datagram | Header field | Contents | 971 +-----------------+--------------+-----------------+ 972 | IPv4 datagram 1 | IPv4 Dst | 192.0.2.1 | 973 | | IPv4 Src | 198.51.100.1 | 974 | | TCP Dst | 5000 | 975 | | TCP Src | 80 | 976 | --------------- | ------------ | ------------- | 977 | IPv6 Datagram 2 | IPv6 Dst | 2001:db8:0:1::1 | 978 | | IPv6 Src | 2001:db8:0:2::1 | 979 | | IPv4 Dst | 10.0.0.1 | 980 | | IP Src | 198.51.100.1 | 981 | | TCP Dst | 10000 | 982 | | TCP Src | 80 | 983 | --------------- | ------------ | ------------- | 984 | IPv4 datagram 3 | IPv4 Dst | 10.0.0.1 | 985 | | IPv4 Src | 198.51.100.1 | 986 | | TCP Dst | 10000 | 987 | | TCP Src | 80 | 988 +-----------------+--------------+-----------------+ 990 Datagram header contents 992 B.1.2. Translation details 994 The AFTR has a NAT that translates between softwire/port pairs and 995 IPv4-address/port pairs. The same translation is applied to IPv4 996 datagrams received on the device's external interface and from the 997 softwire endpoint in the device. 999 In Figure 2, the translator network interface in the AFTR is on the 1000 Internet, and the softwire interface connects to the dual-stack lite 1001 home router. The AFTR translator is configured as follows: 1003 Network interface: Translate IPv4 destination address and TCP 1004 destination port to the softwire identifier and TCP destination 1005 port 1007 Softwire interface: Translate softwire identifier and TCP source 1008 port to IPv4 source address and TCP source port 1010 Here is how the translation in Figure 3 works: 1012 o Datagram 1 is received on the AFTR translator network interface. 1013 The translator looks up the IPv4-address/port pair in its 1014 translator table, rewrites the IPv4 destination address to 1015 10.0.0.1 and the TCP source port to 10000, and hands the datagram 1016 to the SE to be forwarded over the softwire. 1018 o The IPv4 datagram is received on the dual-stack lite home router 1019 B4. The B4 function extracts the IPv4 datagram and the dual-stack 1020 lite home router forwards datagram 3 to the host. 1022 +------------------------------------+--------------------+ 1023 | Softwire-Id/IPv4/Prot/Port | IPv4/Prot/Port | 1024 +------------------------------------+--------------------+ 1025 | 2001:db8:0:1::1/10.0.0.1/TCP/10000 | 192.0.2.1/TCP/5000 | 1026 +------------------------------------+--------------------+ 1028 Dual-Stack lite carrier-grade NAT translation table 1030 The Softwire-Id is the IPv6 address assigned to the Dual-Stack lite 1031 CPE. Hosts behind the same Dual-Stack lite home router have the same 1032 Softwire-Id. The source IPv4 is the RFC1918 addressed assigned by 1033 the Dual-Stack home router which is unique to each host behind the 1034 CPE. The AFTR would receive packets sourced from different IPv4 1035 addresses in the same softwire tunnel. The AFTR combines the 1036 Softwire-Id and IPv4 address/Port [Softwire-Id, IPv4+Port] to 1037 uniquely identify the host behind the same Dual-Stack lite home 1038 router. 1040 B.2. Host based architecture 1042 This architecture is targeted at new, large scale deployments of 1043 dual-stack capable devices implementing a dual-stack lite interface. 1045 Consider a scenario where a Dual-Stack lite host device is directly 1046 connected to the service provider network. The host device is dual- 1047 stack capable but only provisioned an IPv6 global address. Besides, 1048 the host device will pre-configure a well-known IPv4 non-routable 1049 address (see IANA section). This well-known IPv4 non-routable 1050 address is similar to the 127.0.0.1 loopback address. Every host 1051 device implemented Dual-Stack lite will pre-configure the same 1052 address. This address will be used to source the IPv4 datagram when 1053 the device accesses IPv4 services. Besides, the host device will 1054 create an IPv4-in-IPv6 softwire tunnel to an AFTR. The Carrier Grade 1055 NAT will reside in the service provider network. 1057 When the device accesses IPv6 service, the device will send the IPv6 1058 datagram natively to the default gateway. 1060 When the device accesses IPv4 service, it will source the IPv4 1061 datagram with the well-known non-routable IPv4 address. Then, the 1062 host device will encapsulate the IPv4 datagram inside the IPv4-in- 1063 IPv6 softwire tunnel and send the IPv6 datagram to the AFTR. When 1064 the AFTR receives the IPv6 datagram, it will decapsulate the IPv6 1065 header and perform IPv4-to-IPv4 NAT on the source address. 1067 This scenario works on both wireline and wireless networks. A 1068 typical wireless device will connect directly to the service provider 1069 without CPE in between. 1071 As illustrated in Figure 4, this dual-stack lite deployment model 1072 consists of three components: the dual-stack lite host, the AFTR and 1073 a softwire between the softwire initiator B4 in the host and the 1074 softwire concentrator in the AFTR. The dual-stack lite host is 1075 assumed to have IPv6 service and can exchange IPv6 traffic with the 1076 AFTR. 1078 The AFTR performs IPv4-IPv4 NAT translations to multiplex multiple 1079 subscribers through a pool of global IPv4 address. Overlapping IPv4 1080 address spaces used by the dual-stack lite hosts are disambiguated 1081 through the identification of tunnel endpoints. 1083 In this situation, the dual-stack lite host configures the IPv4 1084 address 192.0.0.2 out of the well-known range 192.0.0.0/29 (defined 1085 by IANA) on its B4 interface. It also configure the first non- 1086 reserved IPv4 address of the reserved range, 192.0.0.1 as the address 1087 of its default gateway. 1089 +-------------------+ 1090 | | 1091 | Host 192.0.0.2 | 1092 |+--------+--------+| 1093 || B4 || 1094 |+--------+--------+| 1095 +--------|||--------+ 1096 |||2001:db8:0:1::1 1097 ||| 1098 |||<-IPv4-in-IPv6 softwire 1099 ||| 1100 -------|||------- 1101 / ||| \ 1102 | ISP core network | 1103 \ ||| / 1104 -------|||------- 1105 ||| 1106 |||2001:db8:0:2::1 1107 +--------|||--------+ 1108 | AFTR | 1109 |+--------+--------+| 1110 || Concentrator || 1111 |+--------+--------+| 1112 | |NAT| | 1113 | +-+-+ | 1114 +---------|---------+ 1115 |192.0.2.1 1116 | 1117 --------|-------- 1118 / | \ 1119 | Internet | 1120 \ | / 1121 --------|-------- 1122 | 1123 |198.51.100.1 1124 +-----+-----+ 1125 | IPv4 Host | 1126 +-----------+ 1128 Figure 4: host-based architecture 1130 The resulting solution accepts an IPv4 datagram that is translated 1131 into an IPv4-in-IPv6 softwire datagram for transmission across the 1132 softwire. At the corresponding endpoint, the IPv4 datagram is 1133 decapsulated, and the translated IPv4 address is inserted based on a 1134 translation from the softwire. 1136 B.2.1. Example message flow 1138 In the example shown in Figure 5, the translation tables in the AFTR 1139 is configured to forward between IP/TCP (a.b.c.d/10000) and IP/TCP 1140 (192.0.2.1/5000). That is, a datagram received from the host at 1141 address 192.0.0.2, using TCP DST port 10000 will be translated a 1142 datagram with IP SRC address 192.0.2.1 and TCP SRC port 5000 in the 1143 Internet. 1145 +-------------------+ 1146 | | 1147 |Host 192.0.0.2 | 1148 |+--------+--------+| 1149 || B4 || 1150 |+--------+--------+| 1151 +--------|||--------+ 1152 | |||2001:db8:0:1::1 1153 IPv6 datagram 1| ||| 1154 | |||<-IPv4-in-IPv6 softwire 1155 | ||| 1156 -----|-|||------- 1157 / | ||| \ 1158 | ISP core network | 1159 \ | ||| / 1160 -----|-|||------- 1161 | ||| 1162 | |||2001:db8:0:2::1 1163 +------|-|||--------+ 1164 | | AFTR | 1165 | v ||| | 1166 |+--------+--------+| 1167 || Concentrator || 1168 |+--------+--------+| 1169 | |NAT| | 1170 | +-+-+ | 1171 +---------|---------+ 1172 | |192.0.2.1 1173 IPv4 datagram 2 | | 1174 -----|--|-------- 1175 / | | \ 1176 | Internet | 1177 \ | | / 1178 -----|--|-------- 1179 | | 1180 v |198.51.100.1 1181 +-----+-----+ 1182 | IPv4 Host | 1183 +-----------+ 1185 Figure 5: Outbound Datagram 1187 +-----------------+--------------+-----------------+ 1188 | Datagram | Header field | Contents | 1189 +-----------------+--------------+-----------------+ 1190 | IPv6 Datagram 1 | IPv6 Dst | 2001:db8:0:2::1 | 1191 | | IPv6 Src | 2001:db8:0:1::1 | 1192 | | IPv4 Dst | 198.51.100.1 | 1193 | | IPv4 Src | a.b.c.d | 1194 | | TCP Dst | 80 | 1195 | | TCP Src | 10000 | 1196 | --------------- | ------------ | ------------- | 1197 | IPv4 datagram 2 | IPv4 Dst | 198.51.100.1 | 1198 | | IPv4 Src | 192.0.2.1 | 1199 | | TCP Dst | 80 | 1200 | | TCP Src | 5000 | 1201 +-----------------+--------------+-----------------+ 1203 Datagram header contents 1205 When sending an IPv4 packet, the dual-stack lite host encapsulates it 1206 in datagram 1 and forwards it to the AFTR over the softwire. 1208 When it receives datagram 1, the concentrator in the AFTR hands the 1209 IPv4 datagram to the NAT, which determines from its translation table 1210 that the datagram received on Softwire_1 with TCP SRC port 10000 1211 should be translated to datagram 3 with IP SRC address 192.0.2.1 and 1212 TCP SRC port 5000. 1214 Figure 6 shows an inbound message received at the AFTR. When the NAT 1215 function in the AFTR receives datagram 1, it looks up the IP/TCP DST 1216 in its translation table. In the example in Figure 3, the NAT 1217 translates the TCP DST port to 10000, sets the IP DST address to 1218 a.b.c.d and hands the datagram to the concentrator for transmission 1219 over Softwire_1. The B4 in the dual-stack lite hosts decapsulates 1220 IPv4 datagram from the inbound softwire datagram, and forwards it to 1221 the host. 1223 +-------------------+ 1224 | | 1225 |Host 192.0.0.2 | 1226 |+--------+--------+| 1227 || B4 || 1228 |+--------+--------+| 1229 +--------|||--------+ 1230 ^ |||2001:db8:0:1::1 1231 IPv6 datagram 2 | ||| 1232 | |||<-IPv4-in-IPv6 softwire 1233 | ||| 1234 -----|-|||------- 1235 / | ||| \ 1236 | ISP core network | 1237 \ | ||| / 1238 -----|-|||------- 1239 | ||| 1240 | |||2001:db8:0:2::1 1241 +------|-|||--------+ 1242 | AFTR | 1243 | | ||| | 1244 |+--------+--------+| 1245 || Concentrator || 1246 |+--------+--------+| 1247 | |NAT| | 1248 | +-+-+ | 1249 +---------|---------+ 1250 ^ |192.0.2.1 1251 IPv4 datagram 1 | | 1252 -----|--|-------- 1253 / | | \ 1254 | Internet | 1255 \ | | / 1256 -----|--|-------- 1257 | | 1258 | |198.51.100.1 1259 +-----+-----+ 1260 | IPv4 Host | 1261 +-----------+ 1263 Figure 6: Inbound Datagram 1265 +-----------------+--------------+-----------------+ 1266 | Datagram | Header field | Contents | 1267 +-----------------+--------------+-----------------+ 1268 | IPv4 datagram 1 | IPv4 Dst | 192.0.2.1 | 1269 | | IPv4 Src | 198.51.100.1 | 1270 | | TCP Dst | 5000 | 1271 | | TCP Src | 80 | 1272 | --------------- | ------------ | ------------- | 1273 | IPv6 Datagram 2 | IPv6 Dst | 2001:db8:0:1::1 | 1274 | | IPv6 Src | 2001:db8:0:2::1 | 1275 | | IPv4 Dst | a.b.c.d | 1276 | | IP Src | 198.51.100.1 | 1277 | | TCP Dst | 10000 | 1278 | | TCP Src | 80 | 1279 +-----------------+--------------+-----------------+ 1281 Datagram header contents 1283 B.2.2. Translation details 1285 The translations happening in the AFTR are the same as in the 1286 previous examples. The well known IPv4 address 192.0.0.2 out of the 1287 192.0.0.0/29 (defined by IANA) range used by all the hosts are 1288 disambiguated by the IPv6 source address of the softwire. 1290 +-----------------------------------+--------------------+ 1291 | Softwire-Id/IPv4/Prot/Port | IPv4/Prot/Port | 1292 +-----------------------------------+--------------------+ 1293 | 2001:db8:0:1::1/a.b.c.d/TCP/10000 | 192.0.2.1/TCP/5000 | 1294 +-----------------------------------+--------------------+ 1296 Dual-Stack lite carrier-grade NAT translation table 1298 The Softwire-Id is the IPv6 address assigned to the Dual-Stack host. 1299 Each host has an unique Softwire-Id. The source IPv4 address is one 1300 of the well-known IPv4 address. The AFTR could receive packets from 1301 different hosts sourced from the same IPv4 well-known address from 1302 different softwire tunnels. Similar to the gateway architecture, the 1303 AFTR combines the Softwire-Id and IPv4 address/Port [Softwire-Id, 1304 IPv4+Port] to uniquely identify the individual host. 1306 Authors' Addresses 1308 Alain Durand 1309 Juniper Networks 1310 1194 North Mathilda Avenue 1311 Sunnyvale, CA 94089-1206 1312 USA 1314 Email: adurand@juniper.net 1316 Ralph Droms 1317 Cisco 1318 1414 Massachusetts Avenue 1319 Boxborough, MA 01714 1320 USA 1322 Email: rdroms@cisco.com 1324 James Woodyatt 1325 Apple 1326 1 Infinite Loop 1327 Cupertino, CA 95014 1328 USA 1330 Email: jhw@apple.com 1332 Yiu L. Lee 1333 Comcast 1334 One Comcast Center 1335 Philadelphia, PA 19103 1336 USA 1338 Email: yiu_lee@cable.comcast.com