idnits 2.17.1 draft-despres-6a44-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5991], [RFC6081], [RFC4380]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC6890-compliant IPv4 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 711 has weird spacing: '... v4-add v ...' -- The document date (June 22, 2012) is 4325 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Despres, Ed. 3 Internet-Draft RD-IPtech 4 Intended status: Experimental B. Carpenter 5 Expires: December 24, 2012 Univ. of Auckland 6 D. Wing 7 Cisco 8 S. Jiang 9 Huawei Technologies Co., Ltd 10 June 22, 2012 12 Native IPv6 Behind NAT44 CPEs (6a44) 13 draft-despres-6a44-02 15 Abstract 17 In customer sites having IPv4-only CPEs, Teredo provides a last 18 resort IPv6 connectivity [RFC4380] [RFC5991] [RFC6081]. However, 19 because it is designed to work without involvement of Internet 20 service providers, it has significant limitations (connectivity 21 between IPv6 native addresses and Teredo addresses is uncertain; 22 connectivity between Teredo addresses fails for some combinations of 23 NAT types). 6a44 is a complementary solution that, being base on ISP 24 cooperation, avoids these limitations. At the beginning of IPv6 25 addresses, it replaces the Teredo well-known prefix by network 26 specific /48 prefixes assigned by local ISP's (an evolution similar 27 to that from 6to4 to 6rd). The specification is complete enough for 28 actual deployment, including with independently written codes. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 24, 2012. 47 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 65 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Design Goals, Requirements, and Model of Operation . . . . . . 6 67 4.1. Hypotheses about NAT Behavior . . . . . . . . . . . . . . 6 68 4.2. Native IPv6 Connectivity for unmanaged Hosts behind 69 NAT44s . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.3. Operational Requirements . . . . . . . . . . . . . . . . . 7 71 4.4. Model of Operation . . . . . . . . . . . . . . . . . . . . 8 72 5. 6a44 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 73 6. Specification of Clients and Relays . . . . . . . . . . . . . 13 74 6.1. Packet Formats . . . . . . . . . . . . . . . . . . . . . . 13 75 6.2. IPv6 Packet Encapsulations . . . . . . . . . . . . . . . . 13 76 6.3. 6a44 Bubbles . . . . . . . . . . . . . . . . . . . . . . . 13 77 6.4. Maximum-Transmission-Unit Considerations . . . . . . . . . 15 78 6.5. 6a44 Client Specification . . . . . . . . . . . . . . . . 16 79 6.5.1. Tunnel Maintenance . . . . . . . . . . . . . . . . . . 16 80 6.5.2. Client Transmission . . . . . . . . . . . . . . . . . 18 81 6.5.3. Client Reception . . . . . . . . . . . . . . . . . . . 20 82 6.6. 6a44 Relay Specification . . . . . . . . . . . . . . . . . 22 83 6.6.1. Relay Reception in IPv6 . . . . . . . . . . . . . . . 22 84 6.6.2. Relay Reception in IPv4 . . . . . . . . . . . . . . . 23 85 6.7. Implementation of Automatic Sunset . . . . . . . . . . . . 26 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 87 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 30 88 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 90 10.1. Normative References . . . . . . . . . . . . . . . . . . . 31 91 10.2. Informative References . . . . . . . . . . . . . . . . . . 31 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 94 1. Introduction 96 Although most customer premise equipments (CPE's) should soon be 97 dual-stack capable, a large installed base of IPv4-only CPE's is 98 likely to remain for several years. Their operation is based on IPv4 99 NAT's (NAT44's). Also, due to the IPv4 address shortage, more and 100 more Internet service providers (ISP's), and more and more mobile 101 operators, will assign private IPv4 addresses of [RFC1918] to their 102 customers (the [NAT444] model). For a rapid and extensive use of 103 IPv6 [RFC2460], there is therefore a need for IPv6 connectivity 104 behind NAT44's, including those of the [NAT444] model. 106 At the moment, there are two tunneling techniques specified for IPv6 107 connectivity behind NAT44's: 109 o Configured tunnels. They involve tunnel brokers with which users 110 must register [RFC3053]. Well-known examples include deployments 111 of the Hexago tool, and the SixXs collaboration, which are 112 suitable for IPv6 early trials. However, this approach is not 113 adequate for mass deployment: it imposes that, even if two hosts 114 are in the same customer site, IPv6 packets between them must 115 transit via tunnel servers, which may be far away. 117 o Automatic Teredo tunnels [RFC4380] [RFC5991]. Teredo is specified 118 as a last resort solution which, due to its objective to work 119 without local ISP involvement, has the following limitations: 121 * Connectivity between IPv6 native addresses and Teredo addresses 122 is uncertain. (As explained in [RFC4380] section 8.3, this 123 connectivity depends on paths being available from all IPv6 124 native addresses to some Teredo Relays. ISP's lack sufficient 125 motivations to ensure it). 127 * Between two Teredo addresses, IPv6 connectivity fails for some 128 combinations of NAT44 types([RFC6081] section 3). 130 * According to [RFC4380] section 5.2, each Teredo host has to be 131 configured with the IPv4 address of a Teredo server (a 132 constraint that can however be avoided in some 133 implementations). 135 6a44 is designed to avoid Teredo limitations where ISP's can 136 participate to the solution. The approach for this is similar to 137 that which permitted 6rd [RFC5569] [RFC5969] to avoid limitations of 138 6to4 [RFC3056] [RFC3068]: at the beginning of IPv6 addresses, the 139 Teredo well-known prefix is replaced by network specific prefixes 140 assigned by local ISP's. 142 This document is organized as follows: terms used in the document are 143 defined in Section 3; design goals and model of operation are 144 presented in Section 4; Section 5 describes the format of 6a44 IPv6 145 addresses; Section 6 specifies in details behaviors of 6a44 clients 146 and 6a44 relays; security and IANA considerations are respectively 147 covered in Section 7 and Section 8. 149 The specification is expected to be complete enough for running codes 150 to be independently written and the solution to be incrementally 151 deployed and used. Its intended status is Experimental rather than 152 Standard to reflect uncertainty as to which major Internet players 153 may be willing to support it. 155 2. Requirements Language 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in [RFC2119]. 161 3. Definitions 163 The following definitions are used in this document: 165 MAJOR NEW DEFINITIONS 167 "6a44 ISP network": An IPv4-capable ISP network that supports at 168 least one 6a44 relay. Additional conditions are that it assigns 169 individual IPv4 addresses to its customer sites (global or 170 private), that it supports ingress filtering [RFC2827], and that 171 its path MTU's are at least 1308 octets. 173 "6a44 relay": A node that supports the 6a44 relay function defined 174 in this document, and that has interfaces to an IPv6-capable 175 upstream network and to an an IPv4-capable downstream network. 177 "6a44 client": A host that supports the 6a44 client function defined 178 in this document, and has no other mean than 6a44 to have a IPv6 179 native address. 181 "6a44 tunnel": A tunnel established and maintained between a 6a44 182 client and 6a44 relays of its ISP network. 184 "6a44 bubble": A UDP/IPv4 packet sent from a 6a44 client to the 185 6a44-relay address, or conversely, and having a UDP payload that 186 cannot be confused with an IPv6 packet. In the client to relay 187 direction, it is a request for a response bubble. In the relay to 188 client direction, it conveys the up-to-date IPv6 prefix of the 189 client. 191 SECONDARY NEW DEFINITIONS 192 (for reference, can be skipped by readers familiar with usual 193 terminology) 195 "6a44 service": The service offered by a 6a44 ISP network to its 196 6a44 clients. 198 "6a44-client IPv6 address": The IPv6 address of a 6a44 client. It 199 is composed of the client IPv6 prefix, received from a 6a44 relay, 200 followed by the client local IPv4 address. 202 "6a44-client IPv6 prefix": For a 6a44 client, the IPv6 prefix (/96) 203 composed of the IPv6 prefix of the local 6a44-network (/48) 204 followed by the UDP/IPv4 mapped address of the client (32 + 16 205 bits). 207 "6a44-client UDP/IPv4 mapped address": For a 6a44 client, the 208 external UDP/IPv4 address that, in the CPE NAT44 of the site, is 209 that of its 6a44 tunnel. 211 "6a44-client UDP/IPv4 local address": For a 6a44 client, the 212 combination of its local IPv4 address and the 6a44 port. 214 "6a44 port": The UDP port used for 6a44 (see Section 8). 216 "6a44-relay UDP/IPv4 address": The UDP/IPv4 address composed of the 217 6a44-relay anycast address and the 6a44 port. 219 "6a44-relay anycast address": The well-known IPv4 anycast address of 220 6a44 relays, to be reserved by IANA (see Section 8). 222 "6a44-network IPv6 prefix": An IPv6 /48 prefix assigned by an ISP to 223 a 6a44 network. 225 USUAL DEFINITIONS 226 (for reference, can be skipped by readers familiar with usual 227 terminology) 229 "Upstream direction": For a network border node, the direction 230 toward the Internet core. 232 "Downstream direction": For a network border node, the direction 233 toward end-user nodes (opposite to the upstream direction). 235 "IPv4 private address": An address that starts with one of the three 236 prefixes of [RFC1918] (10/8, 172.16/12, or 192.168/16). 238 "IPv6 native address": An IPv6 global unicast address that starts 239 with an aggregetable prefix assigned to an ISP. 241 "UDP/IPv4 address": The combination of an IPv4 address and a UDP 242 port. 244 "UDP/IPv4 packet": A UDP datagram contained in an IPv4 packet. 246 "IPv6/UDP/IPv4 packet": An IPv6 packet contained in a UDP/IPv4 247 packet. 249 4. Design Goals, Requirements, and Model of Operation 251 4.1. Hypotheses about NAT Behavior 253 6a44 is designed to work with NAT44 behaviors identified in section 3 254 of [RFC6081]. In particular, it has to work with endpoint-dependent 255 mappings as well as with endpoint-independent mappings, including if 256 there are dynamic changes from one mode to the other. 258 The only assumption is that, after a mapping has been established in 259 the NAT44, it is maintained as long as it is re-used at least once, 260 in each direction, every 30 seconds. 262 NOTE: 30 seconds is the value used for the same mapping-maintenance 263 purpose in Teredo [RFC4380], and in SIP [RFC5626]. 265 4.2. Native IPv6 Connectivity for unmanaged Hosts behind NAT44s 267 The objective remains that, as soon as possible, CPEs and ISPs 268 support IPv6 native prefixes. 6a44 is therefore designed only as a 269 temporary solution for hosts to obtain IPv6 native addresses in sites 270 whose CPEs are not IPv6-capable yet. 272 As noted in Section 1, IPv6 native addresses obtainable with 273 configured tunnels have important limitations. However, compared to 274 6a44 addresses, they have the advantage of remaining unchanged in 275 case of NAT44 reset. 6a44 remains therefore the last resort solution 276 for IPv6 native addresses in unmanaged hosts of IPv4-only-CPE sites, 277 while configured tunnels may still be preferred for some managed 278 hosts if reported limitations of configured tunnels are consciously 279 found acceptable. Their scopes being different, the two solutions 280 can usefully coexist. 282 Note that Teredo remains a last resort solution for hosts to have 283 IPv6 addresses where IPv6 native addresses cannot be available (and 284 where Teredo limitations are consciously found acceptable). 286 4.3. Operational Requirements 288 Operational requirements of 6a44 include the following: 290 "Robust IPv6 connectivity": A node having a 6a44 address must have 291 paths across the Internet to and from all IPv6 native addresses 292 that are not subject to voluntary firewall filtering. 294 "Intra-site path efficiency": Packets exchanged between 6a44 clients 295 that are behind the same CPE NAT44 must not have to traverse it. 296 If these clients have IPv4 connectivity using their private IPv4 297 addresses, they must also have IPv6 connectivity using their 6a44 298 addresses. 300 "Plug-and-play operation of 6a44 clients": In order to obtain a 6a44 301 address from its local ISP, a 6a44 client must need no parameter 302 configuration. 304 "Scalability of ISP functions": For the solution to be easily 305 scalable, ISP-supported functions have to be completely stateless. 307 "Anti-spoofing Protection": Where address anti-spoofing is ensured 308 in IPv4 with ingress filtering of [RFC2827] [RFC3704], IPv6 309 addresses must benefit from the same degree of anti-spoofing 310 protection. 312 "Overall operational simplicity": As Antoine de Saint-Exupery said 313 in [The Tool], "it seems that perfection is attained not when 314 there is nothing more to add, but when there is nothing more to 315 remove". 317 "Incremental deployability": Hosts and ISP networks must be able to 318 become 6a44 capable independently of each other. IPv6 must be 319 operational where both are available, and there must be no 320 perceptible effect where they are not both available. 322 4.4. Model of Operation 324 (A) GLOBAL-IPv4 ISP NETWORK 325 +------------------+ 326 6a44 customer network(s) |GLOBAL IPv4 | Upstream 327 +-----------+ ---| MTU >= 1308 +--- IPv4 network 328 ---| Private | | ingress filtering| (<== no route 329 +----+ | IPv4 +-----+ | IPv6 optional | to 6a44 relays) 330 | |-----| |NAT44|----+ | 331 +----+ | +-----+ | +-------------+ 332 6a44 ---|MTU >= 1308| | --+6a44 relay(s)|--- Upstream 333 client(s) | no | ---| +-------------+ IPv6 network 334 |native IPv6| | | 335 +-----------+ +------------------+ 337 (B) PRIVATE-IPv4 ISP NETWORK 338 +------------------+ 339 |PRIVATE IPv4 | 340 | as above | 341 ---| | 342 | +--------------+ 343 | --+ ISP NAT44(s) |--- Upstream 344 as above ----+ +--------------+ IPv4 network 345 | | 346 | +--------------+ 347 ---| --+6a44 relay(s) |--- Upstream 348 | +--------------+ IPv6 network 349 | | 350 +------------------+ 352 6a44 APPLICABILITY SCENARIOS 354 Figure 1 356 The operation of 6a44 involves two types of nodes: 6a44 clients and 357 6a44 relays. Figure 1 shows the two applicability scenarios: 359 o In the first one, IPv4 addresses assigned to customer sites are 360 global IPv4. 362 o In the second one, they are private IPv4 addresses ([NAT444] model 363 where ISPs operate one or several NAT44's, also called carrier- 364 grade NATs, or CGN's). 366 In both configurations, the ISP network may also assign IPv6 prefixes 367 to customer sites: 369 o If customer sites are only assigned IPv4 addresses (IPv6 prefix 370 available neither natively nor with any tunnel), 6a44 applies not 371 only to sites whose CPE's are IPv4-only capable, but also to those 372 whose CPE's are dual-stack capable. 374 o If customer sites are assigned both IPv4 addresses and IPv6 375 prefixes, 6a44 only applies to sites whose CPE's are IPv4-only 376 capable. 378 CUSTOMER +-------------------------+ 379 SITES | ISP NETWORK | 380 +---------+ +----------------+ | 381 | | |6a44 ISP NETWORK| | GLOBAL 382 | | | | | INTERNET 383 HOSTS | IPv6/UDP/IPv4 +---------+ | HOST 384 +-+ | +-----+ | | 6a44 | | IPv6 +-+ 385 |H|---|--.---|NAT44|----|----------.---------.----|--- - - - ---|D| 386 +-+ | \ +-----+ | /| relay(s)|\ | +-+ 387 +-+ | / | | ' +---------+ ' | 388 |A|---|--' | | | | | | 389 +-+ IPv6/IPv4 | | | | | | 390 +---------+ | | | | | 391 | | | | | 392 +---------+ | | | | | 393 | IPv6/UDP/IPv4 . | | | 394 +-+ | +-----+ | / | | | 395 |B|---|------|NAT44|----|------' | | | 396 +-+ | +-----+ | | | | 397 | | +----------------+ | | 398 +---------+ | . | 399 +-+ | / | 400 |C|---- - - - - - - ----|--------------------' | 401 +-+ IPv6 | | 402 +-------------------------+ 404 IPv6 PATHS H-A: A is a 6a44 client in the same site 405 H-B: B is a 6a44 client in another site of the same ISP 406 H-C: C is IPv6 of the same ISP, other than 6a44 407 H-D: D is IPv6 of another ISP 409 IPv6 PATHS BETWEEN 6a44 HOSTS AND REMOTE HOSTS 411 Figure 2 413 Figure 2 illustrates paths of IPv6 packets in between a 6a44 client H 414 and various possible locations of remote hosts (A in the same site, B 415 in another 6a44 site of the same ISP, C in a non-6a44 IPv6 site of 416 the same ISP, D in an IPv6 site of another ISP). Between 6a44 417 clients of a same site, IPv6 packets are encapsulated in IPv4 418 packets. Those Between 6a44 clients and 6a44 relays are encapsulated 419 in UDP/IPv4 packets. 421 6a44 operates as follows (details in Section 6): 423 1. A 6a44 client starts operation by sending a 6a44 bubble to the 424 6a44-relay UDP/IPv4 address. 426 2. When a 6a44 relay receives a bubble from one of its 6a44 427 clients, it returns to this client a bubble containing the IPv6 428 prefix of this client. 430 3. When a 6a44 client receives a bubble from a 6a44 relay, it 431 updates (or confirms) its 6a44 address. It is an update if the 432 client has no IPv6 address yet or if, due to a CPE reset, this 433 address has changed. After receiving a bubble, a client is 434 ready to start, or to continue, IPv6 operation. 436 4. When a 6a44 client having a 6a44 address has an IPv6 packet to 437 send whose destination IS in the same customer site, it 438 encapsulates it in an IPv4 packet whose destination is found in 439 the IPv6 destination address. It then sends the resulting IPv6/ 440 IPv4 packet. 442 5. When a 6a44 client receives a valid IPv6/IPv4 packet from a 6a44 443 client of the same site, it decapsulates the IPv6 packet and 444 submits it to further IPv6 processing. 446 6. When a 6a44 client having a 6a44 address has an IPv6 packet to 447 send whose destination IS NOT in the same the same customer 448 site, it encapsulates the packet in a UDP/IPv4 packet whose 449 destination is UDP/IPv4 address of 6a44 relays. It then sends 450 the IPv6/UDP/IPv4 packet. 452 7. When a 6a44 relay receives via its IPv4 interface a valid IPv6/ 453 UDP/IPv4 packet whose destination IS one of its 6a44 clients, it 454 forwards the contained IPv6 packet in a modified IPv6/UDP/IPv4 455 packet. The UDP/IPv4 destination of this packet is found in the 456 IPv6 destination address. 458 8. When a 6a44 client receives a valid IPv6/UDP/IPv4 packet from a 459 6a44 relay, it decapsulates the IPv6 packet and submits it to 460 further IPv6 processing. 462 9. When a 6a44 relay receives via its IPv4 interface a valid IPv6/ 463 UDP/IPv4 packet whose IPv6 destination IS NOT one of its 6a44 464 clients, it decapsulates the IPv6 packet and sends it via its 465 IPv6 interface. 467 10. When a 6a44 relay receives via its IPv6 interface a valid IPv6 468 packet whose destination is one of its 6a44 clients, it 469 encapsulates the packet in a UDP/IPv4 packet whose destination 470 is the UDP/IPv4 address found in the IPv6 destination address. 471 It then sends the resulting IPv6/UDP/IPv4 packet via its IPv4 472 interface. 474 11. To maintain the NAT44 mapping of its 6a44 tunnel, and to quickly 475 detect the need to change its 6a44 address in case of NAT44 476 reset, a 6a44 client sends from time to time a bubble to the 477 6a44 relay address (see Section 6.5.1). 479 12. When a 6a44 relay receives via its IPv4 interface an IPv6/UDP/ 480 IPv4 packet whose IPv6 and UDP/IPv4 source addresses are not 481 consistent, it discards the invalid packet, and returns a bubble 482 to the UDP/IPv4 source address. (This permits the 6a44 client 483 at this address to update its IPv6 address). 485 5. 6a44 Addresses 487 The 6a44 IPv6 address an ISP assigns to a host must contain all 488 pieces of information needed to reach it from other IPv6 addresses. 489 These pieces are, as illustrated in Figure 3: 491 o the 6a44-network IPv6 prefix D (a /48 the ISP has assigned to its 492 6a44 relays); 494 o the customer-site IPv4 address N (either global IPv4 or, if the 495 ISP uses a [NAT444] model, private IPv4); 497 o the mapped port Z of the 6a44 tunnel (i.e. the external port 498 assigned by the NAT44 to the tunnel that the client maintains 499 between its UDP/IPv4 local address A:W and the 6a44-relay UDP/IPv4 500 address B:W). 502 o the client local IPv4 address A (i.e. the private IPv4 address 503 assigned to the client in its customer site; it is needed for 504 intra-site IPv6 connectivity). 506 Customer network ISP network 507 +--------------+ +------------------+ 508 Client |IPv4 CPE |IPv4 | 509 +----+ | +-----+ | +----------+ 510 | ^ |-----| |NAT44|----+ |6a44 relay|---- IPv6 511 +-|-^+ | +-----+ | +----------+^ 512 | | | ^ | ^ | ^ | | 513 | | +----------|---+ | +---------|--------+ | 514 | | | ^ | | | 515 | | >0/0| | |N/32< | | 516 | | | | | 517 | | Mapping | | 518 | | - (*) | | 519 | | | | 520 | |A:W< >B:W| | 521 | | 522 IPv6 |D.N.Z.A/128< |D/48< 524 (*) With NAT44(s) between client and CPE, a:w may differ from A:W 526 |0 47|48 79|80 95|96 127| 527 +-------+-------+-------+-------+-------+-------+-------+-------+ 528 | 6a44-network | Customer-site |Tunnel | 6a44-client | 529 | IPv6 prefix | IPv4 address |mapped | local IPv4 | 530 | (D) | (N) |port(Z)| address (A)| 531 +-------+-------+-------+-------+-------+-------+-------+-------+ 532 6a44-client 533 <-- UDP/IPv4 address --> 534 <------------ 6a44-client IPv6 prefix ---------> 535 <---------------- 6a44-client IPv6 address ---------------------> 537 HOST-ADDRESS CONSTRUCTION 539 Figure 3 541 NOTE: 6a44 addresses are not guaranteed to comply with the rule of 542 [RFC4291] according to which bits 64-127 of aggregetable unicast 543 addresses have to be the Modified-EUI-64 IID format. However, these 544 bits of 6a44 addresses are interpreted only where 6a44 addresses are 545 processed, i.e. in 6a44 relays and clients. No operational problem 546 is therefore foreseen. Besides, because it is a purely transitional 547 tool, it shouldn't prevent any "development of future technology that 548 can take advantage of interface identifiers with universal scope" 549 (the purpose of this format expressed in [RFC4291]. 551 6. Specification of Clients and Relays 553 6.1. Packet Formats 555 6.2. IPv6 Packet Encapsulations 557 For NAT44 traversal, an IPv6 packet transmitted from a 6a44 client to 558 a 6a44 relay or conversely is encapsulated in a UDP/IP packet whose 559 source and destinations addresses are those of the two endpoints (A:W 560 and B:W in notations of Figure 3). The IPv4 packet is that of a 561 complete datagram (its more-fragment bit is set to 0, its offset is 562 set to 0, and its datagram identification may be set to 0). The UDP 563 checksum is set to 0 (there is no need for an additional layer of 564 checksum protection). The length of the IPv6 packet SHOULD NOT 565 exceed 1280 octets (see Section 6.4). 567 Octets: |0 |20 |28 |68 | 568 +----------+---+-------------------+-------//-----+ 569 | IPv4 |UDP| IPv6 header | IPv6 payload | 570 +----------+---+-------------------+-------//-----+ 572 An IPv6 packet transmitted from a 6a44 client to another 6a44 client 573 of the same site is encapsulated in an IPv4 packet whose source and 574 destination addresses are the private-IPv4 addresses of the two 575 hosts. The IPv4 packet is that of a complete datagram (its more- 576 fragment bit is set to 0, its offset is set to 0, and its datagram 577 identification may be set to 0). The size of the IPv6 packet SHOULD 578 NOT exceed 1280 octets for off-link destinations, and MUST NOT exceed 579 the link MTU minus 20 octets for on-link destinations (see 580 Section 6.4). 582 Octets: |0 |20 |60 | 583 +----------+-------------------+-------//-----+ 584 | IPv4 | IPv6 header | IPv6 payload | 585 +----------+-------------------+-------//-----+ 587 6.3. 6a44 Bubbles 589 A Bubble is a UDP/IPv4 packet whose UDP payload comprises a "6a44- 590 client IPv6 prefix" field and a "Bubble ID" field, and whose UDP 591 checksum is set to 0. Having no UDP checksum protection in bubbles 592 is a simplification that is acceptable because bubble contents are 593 regularly updated and non-critical (a client accepting a corrupted 594 IPv6 prefix never leads to any IPv6 packet being accepted by any 595 wrong destination). 597 "6a44-client IPv6 prefix" field 598 . from a 6a44 client = 0 599 . from a 6a44 relay = 6a44-client IPv6 prefix 600 | 601 Octets: |0 |20 |28| |40 |48 602 +----------+---+--|-+---+ 603 | IPv4 |UDP| . | . | 604 +----------+---+----+-|-+ 605 | 606 "Bubble ID" field 607 . from a 6a44 client: a client-selected value 608 . from a 6a44 relay: 609 - in a response bubble, copy of the received bubble ID 610 - in an error signaling bubble, 0 612 6a44 BUBBLE FORMAT 614 Figure 4 616 In a bubble from a 6a44 client to a 6a44 relay, the "6a44-client IPv6 617 prefix" field is only reserved space for the response. It is set to 618 0. In a bubble from a 6a44 relay to a 6a44 client, it contains the 619 IPv6 prefix of the client, left justified. 621 In a bubble from a 6a44 client to a 6a44 relay, the "Bubble ID" field 622 contains a randomly chosen value, renewed in circumstances defined in 623 Section 6.5.1. In a bubble from a 6a44 relay to a 6a44 client: if 624 the bubble is a response to a bubble received from the client, the 625 field contains the value found in the received bubble; if the bubble 626 is a reaction to a received IPv6/UDP/IPv4 packet whose IPv6 and UDP/ 627 IPv4 sources are inconsistent (i.e. not conforming to R44-2 (3) of 628 Section 6.6.2), the field is set to 0. The purpose of this field is 629 a protection against 6a44-relay spoofing attacks (see Section 7). 631 In order to preserve forward compatibility with any extension of 632 bubble formats, should one prove useful in the future, 6a44 clients 633 and 6a44 relays MUST accept to receive bubbles whose UDP payloads 634 lengths are longer than 20 octets (up to that of an IPv6-packet 635 header since, as detailed in Section Section 6.5.3 and Section 6.6.2, 636 bubbles are recognized by their lengths being shorter than that of 637 tunneled IPv6 packets). 639 6.4. Maximum-Transmission-Unit Considerations 641 Reassembly of a fragmented IPv4 datagram necessitates to remember its 642 identifier from reception of the first fragment to reception the last 643 one, and necessitates a timeout protection against packet losses. If 644 such an IP-layer stateful processing would be necessary for 6a44, it 645 would make it more complex than needed, would introduce a 646 vulnerability to denial of service attacks, and would impose that all 647 fragments of a fragmented IPv4 datagram go to the same relay. This 648 last point would be a constraint on how load balancing may be 649 performed between multiple 6a44 relays, and would therefore be 650 detrimental to scalability. 652 For 6a44 processing to remain completely stateless, IPv4 packets 653 containing encapsulated IPv6 packets must never be fragmented (DF 654 always set to 1). For this: 656 o In customer sites, 6a44 clients MUST have IPv4 link MTU's that 657 support encapsulated IPv6 packets of lengths up to 1280 octets, 658 i.e., for IPv6/UDP/IPv4 packets that traverse the CPE, link MTU's 659 of at least 1280+20+8=1308 octets. (This condition is in general 660 satisfied). 662 o For the same reason, 6a44 ISP networks must have IPv4 path MTU's 663 of at least 1308 octets. (This condition is in general 664 satisfied). 666 o 6a44 clients SHOULD limit the size of IPv6 packets they transmit 667 to 1280 octets. 669 o 6a44 relays SHOULD set their IPv6 MTU to 1280. (If a relay 670 receives an IPv6 packets longer than this MTU via its IPv6 671 upstream interface, it MUST return ICMPv6 Packet Too Big message). 672 Typical ISP networks have a path MTU's that would permit IPv6 673 MTU's of 6a44 to be longer than 1280, but taking 1280 octets is a 674 precaution that guarantees against problems with customer sites 675 that may have internal path MTU's smaller than those supported by 676 their ISP networks. 678 6.5. 6a44 Client Specification 680 6.5.1. Tunnel Maintenance 682 For a 6a44-client IPv6 address to remain valid, the port mapping of 683 the 6a44 tunnel MUST be maintained in the CPE NAT44. 685 Initialization 686 ________v________ 687 / \ 688 | "6a44 disabled" |------------<-----------------+ 689 \_________________/ ^ 690 v no v6-add AND v4-add ^ 691 +--------->--------------v ^ 692 ^ +--------------v--------------+ ^ 693 ^ | Reset the attempt count | ^ 694 ^ | Renew the bubble ID | ^ 695 ^ +--------------+--------------+ ^ 696 ^ +----->-------------v ^ 697 ^ ^ +--------------v--------------+ ^ 698 ^ ^ | Send a bubble | ^ 699 ^ ^ +--------------v--------------+ ^ 700 ^ ^ ________v________ ^ 701 ^ ^ Timer T1 / \ 4 attempts without answer ^ 702 ^ +----<-----| "Bubble sent" |-------->----------------+ ^ 703 ^ (1 to 1.5s)\_________________/ v ^ 704 ^ v \ v6-add OR no v4-add v ^ 705 ^ Bubble received v +-----------------------------+ 706 ^ v-----------------<-----------+ v ^ 707 ^ _________v_________ ^ v ^ 708 ^ Timer T2 / \Bubble received ^ v ^ 709 +----------<---| "Bubble Received" |-------->----------+ v ^ 710 ^ (30s - 4*T1)\___________________/ v ^ 711 ^ \ v6-add OR no v4-add v ^ 712 ^ +------->--------------------+ 713 ^ v ^ 714 ^ +----------------------------------+ ^ 715 ^ _______v________ ^ 716 ^ Timer T3 / \ v6-add OR no v4-add ^ 717 +-----------<----| "No 6a44 relay" |----->-----------------------+ 718 (30 min) \_________________/ 720 TUNNEL MAINTENANCE ALGORITHM 722 Figure 5 724 For this, the 6a44 client SHOULD apply the equivalent of the 725 following TM-x rules, illustrated in Figure 5: 727 TM-1 At initialization, a timer value T1 is randomly chosen in the 728 recommended range 1 to 1.5 seconds, and the "6a44 disabled" 729 state is entered. (Randomness of this value is a precaution to 730 avoid that, if many hosts happen to be re-initialized at the 731 same time, the bubble traffic resulting from the following 732 rules be synchronized.) 734 TM-2 In the "6a44-disabled" state, if it appears that the the 735 interface has no IPv6 native address BUT has a private IPv4 736 address, then: the Attempt count (a local variable) is set to 737 1; a new Bubble ID (another local variable) is randomly chosen 738 (how much random is this new value is not critical, as 739 explained in Section 7); a bubble is sent with this bubble ID; 740 the "Bubble sent" state is entered with the timer set to T1. 742 TM-3 In the "Bubble sent" state, if the timer expires AND the 743 Attempt count is less than 4, then: the Attempt count is 744 increased by 1; a new bubble is sent with the current Bubble 745 ID; the "bubble sent" state is re-entered with the timer reset 746 to T1. 748 TM-4 In the "Bubble sent" state, if a bubble is received, then: the 749 6a44-client IPv6 address is set to the received 6a44-client 750 IPv6 prefix followed by the host local IPv4 address; the 751 "Bubble received" state is entered with the timer set to T2 752 whose recommended value is 30 seconds minus 4 times T1. 754 TM-5 In the "Bubble sent" state, if timer T1 expires AND the Attempt 755 count is equal to 4, then: the "No 6a44 relay" state is entered 756 with the timer set to T3 whose recommended value is 30 minutes. 758 TM-6 In the "Bubble sent" state, OR the "Bubble received" state, OR 759 the "No 6a44 relay" state, if a IPv6 native address is obtained 760 by some other mean, OR if the private IPv4 address of the host 761 is no longer valid, then: the timer is disarmed; the "6a44 762 disabled" state is entered. 764 TM-7 In the "Bubble received" state, if the timer T2 expires, then: 765 the Attempt count is reset to 1; a new Bubble ID is randomly 766 chosen; a bubble is sent with this bubble ID; the "Bubble sent" 767 state is entered with the timer set to T1. 769 TM-8 In the "Bubble received" state, if a bubble is received, then: 770 the timer is reset to T2. (NOTE: Since a bubble is received by 771 a 6a44 client either in response to a bubble it has sent or in 772 reaction to a packet it has sent with inconsistent IPv6 and 773 UDP/IPv4 source addresses, receiving a bubble is a sign that 774 the tunnel mapping reported in the received bubble prefix has 775 recently been used in BOTH directions, a condition required by 776 some NAT44s to maintain their mappings). 778 TM-9 In the "no 6a44 relay" state, if the timer expires, then: the 779 Attempt count is reset to 1; a new Bubble ID is randomly 780 chosen; a bubble is sent with this bubble ID; the "Bubble sent" 781 state is entered with the timer set to T1. 783 6.5.2. Client Transmission 785 An 6a44 client transmits packets according to the following CT-x 786 rules. In figures which illustrate these rules, symbols of Section 5 787 are re-used; packets are represented as a succession of significant 788 fields separated by commas, with sources preceding destinations as 789 usual; != means different from. 791 CT-1 BUBBLE SENT BY A 6a44 CLIENT 793 (IPv4, A, B, UDP[::/96, ]) 794 | 795 +-------+--------+ | 796 | | 6a44 | | 797 | | client +------>---------- >B:W 798 | |function|A:W< UDP/IPv4 799 +-------+--------+ 800 Host 802 Bubbles are transmitted from time to time. Conditions of their 803 transmission are specified specified in Section 6.5.1, and 804 their format is specified in Section 6.3. 806 CT-2 IPv6/IPv4 PACKET SENT TO A HOST OF THE SAME SITE 808 [IPv6, , ,...] 809 | 810 | (IPv4, A, A2, IP-in-IP[encapsulated packet]) 811 | | 812 +----|--+--------+ | 813 | | | 6a44 | | 814 | -->--+ client +------>------ >A2 815 | IPv6 |function|, X != , ...] 834 | 835 | (IPv4, B, A, UDP(W, W, [encapsulated packet]) 836 | | 837 +----|--+--------+ | 838 | | | 6a44 | | 839 | -->--+ client +------>---------- >B:W 840 | IPv6 |function|A:W< UDP/IPv4 841 +-------+--------+ 842 Host 844 If an IPv6 packet is submitted for transmission and ALL the 845 following conditions are satisfied, the IPv6 packet MUST be 846 encapsulated in a UDP/IPv4 packet whose destination is the 847 6a44-relay anycast address, and whose source and destination 848 ports are both the 6a44 port: (1) the source address is the 849 local 6a44-client IPV6 address; (2) The destination is not a 850 6a44 address of the same site (its first 80 bits differ from 851 those of the 6a44-client IPv6 address); (3) The IPv6 packet 852 does not exceed 1280 octets. 854 CT-4 IPv6 PACKET THAT DOESN'T CONCERN 6a44 856 If an IPv6 packet is submitted to the 6a44 client function for 857 transmission with an IPv6 source address that is not the 6a44- 858 client IPv6 address, the packet does not concern 6a44. It MUST 859 be left for any other IPv6 transmission function that may apply 860 (the source address can be a link-local address or a ULA of 861 [RFC4193]. 863 6.5.3. Client Reception 865 Upon reception of an IPv4 packet, a 6a44 client applies the following 866 CR-x rules: 868 CR-1 BUBBLE RECEIVED FROM A 6a44 RELAY 870 (IPv4, B, A, UDP(w, w, [, ]) 871 | 872 +-------+--------+ | 873 | | 6a44 | | 874 | | client +------<---------- , , ...]) 895 | 896 [decapsulated packet] | 897 | | 898 +----|--+--------+ | 899 | | | 6a44 | | 900 | --<--+ client +------<------ ,...]) 921 | 922 [decapsulated packet] | 923 | | 924 +----|--+--------+ | 925 | | | 6a44 | | 926 | --<--+ client +------<---------- 0); (3) the IPv4 packet contains the 961 first or unique fragment of a UDP datagram (protocol = 17, 962 offset = 0), with neither port equal to the 6a44 port. 964 6.6. 6a44 Relay Specification 966 6.6.1. Relay Reception in IPv6 968 Upon reception of a packet via its IPv6 interface with a destination 969 address starting with the 6a44-network IPv6 prefix, a 6a44 relay MUST 970 apply the following RR6-x rules: 972 RR6-1 VALID IPv6 PACKET FROM OUTSIDE THE 6a44 ISP NETWORK 974 [IPv6, (X != AND != ), .Z...>,...] 975 | 976 (IPv4, B, N, UDP(W, Z, | 977 [encapsulated packet])) | 978 | | 979 | +--------+ | 980 | >B:W | 6a44 |D/48< | 981 N:Z< ---<--------| relay |-------<---- D.N.Z...< 982 IPv4 | | IPv6 983 +--------+ 985 If ALL the following conditions are satisfied, the IPv6 packet 986 MUST be encapsulated in an UDP/IPv4 packet whose UDP/IPv4 987 destination is copied from bits 48 to 95 of the IPv6 988 destination address: (1) the IPv6 source address is not that 989 of a 6a44 client of the ISP (it does not start with the 6a44- 990 network IPv6 prefix); (2) the IPv6 source address is not a 991 Teredo address whose embedded UDP/IPv4 address is the 6a44- 992 relay anycast address; (3) the customer-site IPv4 address 993 embedded in the 6a44 destination address is not the 6a44-relay 994 anycast address; (4) the packet has at most 1280 octets. 996 RR6-2 INVALID IPv6 PACKET FROM OUTSIDE THE 6a44 ISP NETWORK 998 If ANY of the following conditions is satisfied, the IPv6 999 packet MUST be discarded : (1) the packet has more than 1280 1000 octets (in this case, an ICMP Packet Too Big error message 1001 MUST be returned to the source); (2) the customer-site IPv4 1002 address embedded in the IPv6 destination address is the 6a44- 1003 relay anycast address; (3) the IPv6 source address is a Teredo 1004 address whose embedded IPv4 address is the 6a44-relay anycast 1005 address. 1007 6.6.2. Relay Reception in IPv4 1009 Upon reception via its IPv4 downstream interface of an IPv4 packet 1010 that contains a complete IP datagram (fragment offset = 0 and more- 1011 fragment bit = 0), and that contain a UDP datagram whose UDP/IPv4 1012 destination is the 6a44-relay UDP/IPv4 address, a 6a44 relay MUST 1013 apply the following rules: 1015 RR4-1 BUBBLE FROM 6a44 CLIENT 1017 (IPv4, N, B, UDP(Z, W, [::/96, bubble ID])) 1018 | 1019 IPv4 | +--------+ 1020 >B:W ------->----| | 1021 >B:W| 6a44 | 1022 | relay | 1023 N:Z< -------<----| | 1024 IPv4 | +--------+ 1025 | 1026 | 1027 (IPv4, B, N, UDP(B, W, [, bubble ID])) 1029 If the following condition is satisfied, the 6a 44 relay MUST 1030 return to the source a bubble derived from the received one by 1031 permuting its UDP/IPv4 source and destination, and by putting 1032 in its 6a44-client-IPv6-prefix field the received UDP/IPv4 1033 source address: the UDP payload is a bubble, i.e has at least 1034 20 octets and less than 40 octets 1036 RR4-2 IPv6 PACKET FROM A 6a44 CLIENT TO ANOTHER 6a44 CLIENT 1037 (IPv4, N1, B, UDP(Z1, W, [IPv6, , , ...])) 1038 | 1039 IPv4 | +--------+ 1040 >B:W ------->----| | 1041 >B:W| 6a44 | 1042 | relay | 1043 | | 1044 N2.Z2< -------<----| | 1045 IPv4 | +--------+ 1046 | 6a44 Relay 1047 | 1048 (IPv4, B, N2, UDP(B, Z2, [encapsulated packet])) 1050 If ALL the following conditions are satisfied, the 6a44 relay 1051 MUST return back via its downstream IPv4 interface an IPv6/ 1052 UDP/IPv4 packet containing the same encapsulated packet, 1053 having its UDP/IPv4 destination set to the UDP/IPv4 address 1054 found in the 6a44 destination address, and having its UDP/IPv4 1055 source set to the 6a44-relay UDP/IPv4 address: (1) the IPv4 1056 packet contains a complete UDP datagram (protocol = 17, offset 1057 = 0, more-fragment bit = 0); (2) the UDP payload is an IPv6 1058 packet (length of at least 40 octets, version = 6); (3) the 1059 IPv6 source address starts with the 6a44-network IPv6 prefix 1060 followed by the UDP/IPv4 source address of the received 1061 packet; (3) the IPv6 destination address starts with the 6a44- 1062 network IPv6 prefix. 1064 RR4-3 IPv6 PACKET FROM A 6a44 CLIENT TO A NON-6a44-CLIENT 1066 (IPv4, N, B, UDP(Z, W, [IPv6, , 1067 | (X != AND != | 6a44 |B:W --->----------| relay |------->---- > 1074 IPv4 | | IPv6 1075 +--------+ 1077 If ALL the following conditions are satisfied, the 6a44 relay 1078 MUST decapsulate the IPv6 packet and forward it via the IPv6 1079 interface: (1) the IPv4 packet contains a complete UDP 1080 datagram (protocol = 17, offset = 0, more-fragment bit = 0); 1081 (2) the UDP payload is an IPv6 packet (length of at least 40 1082 octets, version = 6); (3) the IPv6 source address starts with 1083 the 6a44-network IPv6 prefix, followed by the UDP/IPv4 source 1084 address of the received packet; (4) the IPv6 destination 1085 address does not start with the 6a44-network IPv6 prefix and 1086 is not a Teredo address whose embedded IPv4 address is the 1087 6a44-relay anycast address. 1089 RR4-4 RECEIVED ICMPv4 ERROR MESSAGE CONCERNING A 6a44 PACKET 1091 If the 6a44 relay receives an IPv4 error message of [RFC0792] 1092 that concerns a discarded 6a44 packet (i.e. if the copied 1093 header of the discarded packet is that of a transmitted packet 1094 according to RR6-1 or RR4-2), it SHOULD translate it into an 1095 ICMPv6 error message of [RFC4443], and then treat it as a 1096 received IPv6 packet. Translation of Type and Code 1097 conversions between IPv4 and IPv6 are described in [RFC6145] 1098 (Section 4.2. - IPv4 error messages). 1100 RR4-5 INVALID IPv6/UDP/IPv4 PACKET 1102 If ANY other case, the 6a44 relay MUST discard the packet. 1104 6.7. Implementation of Automatic Sunset 1106 6a44 is designed as an interim transition mechanism, not to be used 1107 any longer than strictly necessary. Its sole purpose is to 1108 accelerate availability of IPv6 native addresses where, for any 1109 reason, CPE's cannot quickly be replaced, or where, for any reason, 1110 ISP networks cannot quickly support dual-stack routing or 6rd. 1112 A 6a44-capable ISP can first have an increase of its 6a44 traffic, as 1113 more and more hosts behind IPv4-only CPEs support the 6a44 client 1114 function. But it should later have a decrease of this traffic as 1115 more and more CPE's operate in dual stack. 1117 When this traffic becomes sufficiently negligible, it may, after due 1118 prior notice, discontinue 6a44-relay operation. This terminates its 1119 sunset procedure. 1121 In a host that obtains a IPv6 native address by some other mean than 1122 6a44, the effect of having the 6a44 function in its protocol stack is 1123 inexistent. OS providers may therefore keep this function in their 1124 code for many years. When it becomes clear that the number of users 1125 of this unction has become negligible they can delete it from later 1126 releases. This terminates their sunset procedure. 1128 7. Security Considerations 1129 Incoming reachability: 1131 Hosts that acquire 6a44 addresses become reachable from the 1132 Internet in IPv6 while they remain unreachable in IPv4 at their 1133 private IPv4 addresses. 1135 For ordinary use, this should not introduce a perceptible new 1136 security risk for two reasons: (1) hosts can, without IPv6, use 1137 NAT44 hole-punching techniques such as ICE of [RFC5245]) to 1138 receive incoming connections; (2) modern operating systems that 1139 support IPv6 have by default their own protections against 1140 incoming connections. 1142 If nevertheless 6a44 reachability across an ordinary NAT44 has to 1143 be barred, this can be done by configuring its port-forwarding 1144 function with the 6a44 port bound to any internal address that is 1145 not assigned to any host. Thus, no bubble from a 6a44 relay can 1146 reach any 6a44-capable host, and this is sufficient to prevent 1147 hosts from using 6a44. 1149 For more sophisticated uses with managed firewalls, default 1150 configuration are in general such that packets that are not 1151 explicitly authorized are discarded. Thus, 6a44 can be used only 1152 if the 6a44 port is consciously opened to incoming traffic. 1154 Subscriber authentication: 1156 Any authentication that applies to an IPv4 address extends its 1157 effect to 6a44 addresses that are derived from it. 1159 Host-address spoofing: 1161 With ingress filtering required in 6a44 ISP networks, and with 1162 address checks of Section 6, no new IPv6 address-spoofing 1163 vulnerability is introduced by 6a44. 1165 Address-and-port scanning: 1167 To mitigate the (limited) risk of a malicious user trying to scan 1168 address-and-port IPv4 couples to reach a host, Teredo addresses 1169 contain 12 random bits [RFC5991]. 6a44 addresses have no random 1170 bits but contain local IPv4 addresses of clients. Since possible 1171 values of these addresses are not deterministically known from 1172 outside customer sites, and are in ranges that can be configured 1173 in typical NAT44s, some protection against address and port 1174 scanning is thus achieved. This protection may be less effective 1175 than that achieved with random bits, but is in any case better for 1176 6a44 IPv6 addresses than for IPv4 addresses alone. 1178 Denial-of-service: 1180 Provided 6a44 relays are provisioned with enough processing power, 1181 which is facilitated by their being completely stateless, 6a44 1182 introduces no denial of service vulnerabilities of its own. 1184 Routing-loops: 1186 A risk of routing-loop attacks has been identified in 1187 [draft-ietf-v6ops-tunnel-loops]. Without precaution, it applies 1188 to some combinations of automatic-tunnel mechanisms such as 6to4, 1189 ISATAP, 6rd and Teredo. This risk does not exist with 6a44 for 1190 the following reasons: 1192 1. When an packet enters a 6a44 relay via its IPv6 interface: 1194 + An IPv6/UDP/IPv4 packet cannot be sent to another 6a44 1195 relay because its IPv4 destination would have to be 6a44- 1196 relay IPv4 address. This is prevented by rule RR6-1 of 1197 Section 6.6.1. 1199 + If an IPv6/UDP/IPv4 packet is sent to the address of a 6to4 1200 relay, 6rd relay, or ISATAP relay, it will be discarded 1201 there because these relays don't accept UDP/IPv4 packets. 1203 + If an IPv6/UDP/IPv4 packet is sent to a Teredo relay, it 1204 will be discarded there because: (1) Teredo relays check 1205 that the IPv4 addresses that is embedded in the IPv6 source 1206 address of a received IPv6/IPv4 packet does match the IPv4 1207 source address of the encapsulating packet (section 5.4.2 1208 of [RFC4380]); (2) encapsulating packets sent by 6a44 1209 relays have the 6a44-relay anycast address as IPv4 source 1210 address; (3) a 6a44 relay forwards a received IPv6 packet 1211 as an IPv6/UDP/IPv4 packets only if its IPv6 source address 1212 is not a Teredo address whose embedded IPv4 address is the 1213 6a44-relay IPv4 address. 1215 2. When a packet enters a 6a44 relay via its IPv4 interface: 1217 + The received packet cannot come from another 6a44 relay (as 1218 just explained, 6rd relays do not send IPv6/UDP/IPv4 1219 packets to other 6a44-relays). 1221 + If the IPv4 packet comes a 6to4 relay, a 6rd relay, or an 1222 ISATAP relay, its IPv6 encapsulated packet cannot be 1223 forwarded (the received packet is IPv6/IPv4 instead of 1224 being IPv6/UDP/IPv4, as required by rules RR4-2 and RR4-3 1225 of Section 6.6.2). 1227 + If the received packet is an IPv6/UDP/IPv4 packet coming 1228 from a Teredo relay, this packet cannot have been sent to 1229 the Teredo relay by a 6a44 relay ((1) in order to reach the 1230 6a44 relay, the IPv6 destination of the IPv6 encapsulated 1231 packet must be a Teredo address whose embedded IPv4 address 1232 is the 6a44-relay anycast address (section 5.4.1 of 1233 [RFC4380]); (2) a 6a44 relay does not forward via its IPv6 1234 interface an IPv6 packet whose destination is a Teredo 1235 address whose embedded IPv4 address is the 6a44-relay 1236 anycast address (rule RR4-3 of Section 6.6.2). 1238 6a44-relay spoofing: 1240 In a 6a44 network, no node can spoof a 6a44 relay because ingress 1241 filtering prevents any 6a44-relay anycast address to be spoofed. 1243 In a network that does not support ingress filtering (and 1244 therefore is not a 6a44 network): 1246 * 6a44 packets sent by 6a44-capable hosts are discarded in the 1247 IPv4 backbone because their IPv4 destination, the 6a44-relay 1248 anycast address, does not start with any ISP assigned prefix. 1250 * If an attacker tries to send to a 6a44-capable host a faked 1251 relay-to-client bubble, the probability that it would be 1252 accepted by its destination is negligible. It would require 1253 that all the following conditions be simultaneously satisfied: 1255 + The UDP/IPv4 destination set by the attacker must reach a 1256 NAT44 node in which it is the external mapping of a 6a44 1257 tunnel established by a 6a44-capable host. 1259 + This host must be in the "Bubble sent" state, the only one 1260 in which it listens to bubbles when its ISP is not 6a44 1261 capable. This state is taken only for a few seconds every 1262 30 minutes (rule TM-5 of Section 6.5.1). 1264 + This host accepts the bubble only if its bubble ID has the 1265 right value, an extremely unlikely possibility with a 64- 1266 bits randomly chosen Bubble ID (see Section 6.5.1). 1268 * If a 6a44-capable host, despite this being very unlikely, 1269 accepts a faked bubble, the effect is that it wrongly believes, 1270 for about 30 seconds, that it has an assigned public IPv6 1271 address. All IPv6 packets it then sends with this address as 1272 source cannot be accepted by any destination (no relay will 1273 forward them, and and no host of the same site will accept 1274 them). The consequence would therefore not impair security. 1276 8. IANA considerations 1278 IANA is solicited to assign: 1280 1. 192.88.99.2 as the 6a44 IPv4 anycast address; 1282 2. a registered UDP port as the 6a44 well known port. Proposed 1283 value is the currently unused 1027. 1285 The choice of 192.88.99.2 as 6a44 IPv4 anycast address doesn't 1286 conflict with any existing IETF specification because: 1288 o It starts with the 6to4 prefix 192.88.99.0/24 [RFC3068]. 1290 o It differs from the only currently assigned address that starts 1291 with this prefix (the anycast address of 6to4 relays 192.88.99.1 1292 of [RFC3068]. 1294 This choice is made to permit implementations of 6a44 relays both in 1295 physical nodes that are independent from any 6to4 relay or, if found 1296 more optimum, in nodes in which 6to4 relays and 6a44 relays are 1297 collocated. 1299 9. Acknowledgments 1301 This specification, whose origin is a convergence effort based on two 1302 independent proposals, [6rd+] and [SAMPLE], has benefited from 1303 various suggestions. Comments have been received during this 1304 process, in particular from Dave Thaler, Fred Templin, Ole Troan, 1305 Olivier Vautrin, Pascal Thubert, Washam Fan, and Yu Lee. Authors wish 1306 to thank them, and all others, for their useful contributions. 1307 Special recognition is due to Dave Thaler whose detailed review led 1308 to a few useful modifications. 1310 10. References 1311 10.1. Normative References 1313 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1314 RFC 792, September 1981. 1316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1317 Requirement Levels", BCP 14, RFC 2119, March 1997. 1319 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1320 (IPv6) Specification", RFC 2460, December 1998. 1322 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1323 Architecture", RFC 4291, February 2006. 1325 10.2. Informative References 1327 [6rd+] Despres, R., "Rapid Deployment of Native IPv6 Behind IPv4 1328 NATs (6rd+) - draft-despres-softwire-6rdplus-00", 1329 July 2010. 1331 [NAT444] Yamaguchi, J., Shirasaki, Y., Miyakawa, S., Nakagawa, A., 1332 and H. Ashida, "NAT444 addressing models - 1333 draft-shirasaki-nat444-isp-shared-addr-03 - Work in 1334 progress", March 2010. 1336 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1337 E. Lear, "Address Allocation for Private Internets", 1338 BCP 5, RFC 1918, February 1996. 1340 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1341 Defeating Denial of Service Attacks which employ IP Source 1342 Address Spoofing", BCP 38, RFC 2827, May 2000. 1344 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 1345 Tunnel Broker", RFC 3053, January 2001. 1347 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1348 via IPv4 Clouds", RFC 3056, February 2001. 1350 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 1351 RFC 3068, June 2001. 1353 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1354 Networks", BCP 84, RFC 3704, March 2004. 1356 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1357 Addresses", RFC 4193, October 2005. 1359 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1360 Network Address Translations (NATs)", RFC 4380, 1361 February 2006. 1363 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1364 Message Protocol (ICMPv6) for the Internet Protocol 1365 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1367 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1368 (ICE): A Protocol for Network Address Translator (NAT) 1369 Traversal for Offer/Answer Protocols", RFC 5245, 1370 April 2010. 1372 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1373 Infrastructures (6rd)", RFC 5569, January 2010. 1375 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 1376 Initiated Connections in the Session Initiation Protocol 1377 (SIP)", RFC 5626, October 2009. 1379 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1380 Infrastructures (6rd) -- Protocol Specification", 1381 RFC 5969, August 2010. 1383 [RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo 1384 Security Updates", RFC 5991, September 2010. 1386 [RFC6081] Thaler, D., "Teredo Extensions", RFC 6081, January 2011. 1388 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1389 Algorithm", RFC 6145, April 2011. 1391 [SAMPLE] Carpenter, B. and S. Jiang, "Legacy NAT Traversal for 1392 IPv6: Simple Address Mapping for Premises - Legacy 1393 Equipment (SAMPLE) - draft-carpenter-softwire-sample-00", 1394 July 2010. 1396 [The Tool] 1397 Saint-Exupery, A de., "Wind, sand and Stars, Chap. III - 1398 The tool", 1939. 1400 [draft-ietf-v6ops-tunnel-loops] 1401 Nakibly, G. and F. Templin, "Routing Loop Attack using 1402 IPv6 Automatic Tunnels: Problem Statement and Proposed 1403 Mitigations (Work in progress)". 1405 Authors' Addresses 1407 Remi Despres (editor) 1408 RD-IPtech 1409 3 rue du President Wilson 1410 Levallois, 1411 France 1413 Email: despres.remi@laposte.net 1415 Brian Carpenter 1416 University of Auckland 1417 Department of Computer Science 1418 PB 92019 1419 Auckland, 1142 1420 New Zealand 1422 Email: brian.e.carpenter@gmail.com 1424 Dan Wing 1425 Cisco Systems, Inc. 1426 170 West Tasman Drive 1427 San Jose, California 95134 1428 USA 1430 Email: dwing@cisco.com 1432 Sheng Jiang 1433 Huawei Technologies Co., Ltd 1434 Q14, Huawei Campus - No.156 Beiqing Road 1435 Hai-Dian District, Beijing 100095, 1436 P.R. China 1438 Email: shengjiang@huawei.com