idnits 2.17.1 draft-despres-intarea-4rd-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 14, 2011) is 4793 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3315' is defined on line 715, but no explicit reference was found in the text == Unused Reference: 'RFC5569' is defined on line 763, but no explicit reference was found in the text == Unused Reference: 'RFC5969' is defined on line 770, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-07 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-tunnel-loops-03 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). 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: Standards Track S. Matsushima 5 Expires: September 15, 2011 SoftBank 6 T. Murakami 7 IP Infusion 8 O. Troan 9 Cisco 10 March 14, 2011 12 IPv4 Residual Deployment across IPv6-Service networks (4rd) 13 ISP-NAT's made optional 14 draft-despres-intarea-4rd-01 16 Abstract 18 This document specifies an automatic tunneling mechanism for 19 providing IPv4 connectivity service to end users over a service 20 provider's IPv6 network. During the long transition period from IPv4 21 to IPv6-only, a service provider's network will have to support IPv6, 22 but will also have to maintain some IPv4 connectivity for a number of 23 customers, for both outgoing and incoming connections, and for both 24 exclusive and shared IPv4 addresses. The 4rd solution (IPv4 Residual 25 Deployment) is designed as a lightweight solution for this. 27 In some scenarios, 4rd can dispense ISPs from supporting any NAT in 28 their networks. In some others it can be used in parallel with NAT- 29 based solutions such as DS-lite and/or NAT64/DNS4. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 15, 2011. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 5 68 4.1. General Principles . . . . . . . . . . . . . . . . . . . . 5 69 4.2. Mapping-Rule Parameters . . . . . . . . . . . . . . . . . 5 70 4.3. Mapping Rules . . . . . . . . . . . . . . . . . . . . . . 6 71 4.3.1. From a CE IPv6 Prefix to a CE 4rd Prefix . . . . . . . 6 72 4.3.2. From a CE 4rd Prefix to a Port-set ID . . . . . . . . 7 73 4.3.3. From a Port-Set ID to a Port Set . . . . . . . . . . . 7 74 4.3.4. From an IPv4 Address or IPv4 address + Port to a 75 CE IPv6 address . . . . . . . . . . . . . . . . . . . 9 76 4.4. Encapsulation and Fragmentation Considerations . . . . . . 10 77 4.5. BR and CE behaviors . . . . . . . . . . . . . . . . . . . 11 78 4.5.1. Domains having only One Mapping rule . . . . . . . . . 11 79 4.5.2. Domains having Multiple Mapping Rules . . . . . . . . 12 80 5. 4rd Configuration . . . . . . . . . . . . . . . . . . . . . . 14 81 6. Security considerations . . . . . . . . . . . . . . . . . . . 15 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 86 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 89 1. Introduction 91 During the transition period from IPv4 to IPv6 Internet Service 92 Providers (ISP's), will deploy networks that are IPv6 only. Some of 93 them will do so while they still have to offer IPv4 connectivity. 94 The IPv4 service can be one or multiple IPv4 addresses per end-user, 95 or it can be an IPv4 address shared among multiple end-users. 97 In this document, Internet Service Provider is used as a generic 98 term. It includes DSL or Broadband service providers, mobile 99 operators, and private operators of networks of any sizes. 101 4rd (IPv4 Residual Deployment) is a generic lightweight solution for 102 providing IPv4 connectivity across an IPv6 only infrastructure. As 103 such, it is the reverse of 6rd (IPv6 Rapid Deployment) whose purpose 104 is to rapidly introduce native IPv6 connectivity across an IPv4 105 network. It applies the same principles of automatic tunneling, an 106 stateless address mappings between IPv4 and IPv6. 108 On the tradeoff scale between efficiency of address sharing ratios 109 and simplicity, 4rd is on the side of design and operational 110 simplicity. 112 The 4rd mechanism tunnels IPv4 over IPv6 using an algorithmic mapping 113 from IPv4 addresses or IPv4 addresses and ports to the IPv6 addresses 114 used as tunnel endpoints. Depending on ISP constraints and policies, 115 4rd can be used either standalone, with NAT44's in CE's but no NAT in 116 ISP networks, or can co-exist with other mechanisms in the network on 117 NAT's like DS-lite [I-D.ietf-softwire-dual-stack-lite] or NAT64/DNS64 118 [I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-dns64]. 120 2. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 3. Terminology 128 4rd domain (Domain): an IPv6 routing network operated by an ISP and 129 comprising one or several 4rd BR's having the 130 same set of parameters. It offers to its 4rd- 131 capable CE's global IPv4 connectivity, both 132 outgoing and incoming, and with exclusive or 133 shared IPv4 addresses. 135 4rd Border Relay (BR): A 4rd-capable router managed by the service 136 provider at the edge of a 4rd domain. A BR has 137 an IPv6-enabled interface connected to the ISP 138 network, and an IPv4 virtual interface acting 139 as an endpoint for the automatic 4rd tunnel. 140 This tunnel (IPv4 in IPv6) is between the BR 141 and all CE's of the Domain. 143 4rd Customer Edge (CE): A node at the border between a customer 144 network and the 4rd domain. This node has an 145 IPv6 interface connected to the ISP network, 146 and a virtual IPv4 interface acting as the end- 147 point of the automatic 4rd tunnel. This tunnel 148 (IPv4 in IPv6) is between the CE and all other 149 CE's and all BR's of the Domain. It may be a 150 host, a router, or both. 152 CE IPv6 prefix: The IPv6 prefix assigned to a CE by other means 153 than 4rd itself, and used by 4rd to derive a CE 154 4rd prefix. 156 CE IPv6 address: In the context of 4rd, the IPv6 address used to 157 reach a CE from other CE's and from BR's. A CE 158 typically has another IPv6 address, assigned to 159 it at its IPv6 interface without relationship 160 with 6rd. 162 CE 4rd prefix: The 4rd prefix of the CE. It is derived from 163 the CE IPv6 prefix by a mapping rule according 164 to Section 4.3. Depending on its length, it is 165 an IPv4 prefix, an IPv4 address, or a shared 166 IPv4 address followed by a Port-set ID 167 (Section 4.3.2). 169 Port-set ID: In a CE 4rd prefix longer than 32 bits, bits 170 that follow the first 32. It algorithmically 171 identifies a set of ports exclusively assigned 172 to the CE. As specified in Section 4.3.3, the 173 set can comprise up to 4 disjoint port ranges. 175 Domain IPv6 prefix: An IPv6 prefix assigned by an ISP to a 4rd 176 domain. 178 Domain 4rd prefix: A 4rd prefix assigned by an ISP to the 4rd 179 domain. In typical operator applications, it 180 is an IPv4 prefix. In a residential site in 181 which an already shared IPv4 address has to be 182 shared even more among several hosts, it may 183 have more than 32 bits. 185 CE index: For a CE, the field that is common to its CE 186 IPv6 prefix and its CE 4rd prefix. In the 187 former, it follows the Domain IPv6 prefix. In 188 the latter, it follows the Domain 4rd prefix. 190 4. Protocol Specification 192 4.1. General Principles 194 The principle of the 4rd protocol is that IPv4 packets, or in case of 195 shared IPv4 addresses IPv4 datagrams, traverse a 4rd domain by means 196 of automatic IPv4 in IPv6 tunnels. IPv6 addresses of destination 197 tunnel endpoints are statelessly derived from IPv4 destinations, 198 based on some mapping rule parameters, in such a way that tunnels 199 between CE's follow direct IPv6 paths (i.e. without having to go via 200 BR's). IPv4 destinations used for these mappings are either IPv4 201 addresses alone or IPv4 addresses + ports depending on whether global 202 addresses assigned to CE's are exclusive or shared. 204 BR's and CE's MAY have the detailed behaviors specified in the 205 following sections. Different behaviors are however permitted, but 206 they MUST be equivalent as far as exchanged packets are concerned. 208 4.2. Mapping-Rule Parameters 210 Both CE's and BR's have to know the BR IPv6 address of their domain 211 as well as, for each mapping rule, the following parameters: 213 o Domain IPv6 prefix 215 o Domain 4rd prefix 217 o IPv6-prefix length 219 o Domain IPv6 suffix (optional - default ::/0) 221 4.3. Mapping Rules 223 4.3.1. From a CE IPv6 Prefix to a CE 4rd Prefix 225 A 4rd mapping rule establishes a 1:1 mapping between CE IPv6 prefixes 226 and CE 4rd prefixes. 228 <---------------- CE IPv6 prefix (max 64) --------------> 229 +-------------------------------+------------------------+ 230 | Domain IPv6 prefix | CE index | 231 +-------------------------------+------------------------+ 232 <-- Domain IPv6 Prefix length -><--- CE index length --->: 233 : : 234 : || : 235 : \/ : 236 : : 237 <--- CE index length --->: 238 +-------------------+------------------------+ 239 | Domain 4rd prefix | CE index | 240 +-------------------+------------------------+ 241 <----------- CE 4rd prefix (max 47) --------> 243 Figure 1: From a CE IPv6 Prefix to a CE 4rd Prefix 245 A CE derives its CE 4rd prefix from the IPv6 prefix it has been 246 delegated on the IPv6 network, using for this parameters of the 247 applicable mapping rule. If the domain has several mapping rules, 248 that which applies is that whose Domain IPv6 prefix is at the 249 beginning of the CE IPv6 prefix. As shown in Figure 1, the CE 4rd 250 prefix is made of the Domain 4rd prefix followed by the CE index, 251 where the CE index is the remainder of the CE IPv6 prefix after the 252 Domain IPv6 prefix (the length of the Domain IPv6 prefix is defined 253 by the mapping rule). 255 4.3.2. From a CE 4rd Prefix to a Port-set ID 257 Depending on its length, a CE 4rd prefix is either an IPv4 prefix, a 258 full IPv4 address, or a shared IPv4 address followed by a Port-set ID 259 (Figure 2). If it includes a port set ID, this ID specifies which 260 ports are assigned to the the CE for its exclusive use 261 (Section 4.3.3). 263 <-- CE 4rd prefix length --> 264 +--------------------------+- - -+ 265 Shorter than 32 bits | IPv4 prefix | ... | 266 + -------------------------+- - -+ 267 <--------------- 32 -------------> 269 <----- CE 4rd prefix length -----> 270 +--------------------------------+ 271 32 bits | IPv4 address | 272 +--------------------------------+ 273 <--------------- 32 -------------> 275 <----------- CE 4rd prefix length ----------> 276 +-------------------------------+-----------+ 277 33 to 47 bits | IPv4 shared address |Port-set ID| 278 +-------------------------------+-----------+ 279 <--------------- 32 -----------><- max 15 --> 281 Figure 2: Variants of CE 4rd prefixes 283 4.3.3. From a Port-Set ID to a Port Set 285 Each value of a Port-set ID specifies which ports can be used by any 286 protocol whose header format starts with source and destination ports 287 (UDP, TCP, SCTP, etc.). Design constraint of the algorithm are the 288 following: 290 "Fairness with respect to special-value ports" 291 No port-set must contain any port from 0 to 4095. (These ports, 292 which have more value than others in OS's, are normally not used 293 in dynamic port assignments to applications). 295 "Fairness with respect to the number of ports" 296 For a Port-set-ID's having the same length, all sets must have 297 the same number of ports. 299 "Exhaustiveness" 300 For a any Port-set-ID length, the aggregate of port sets 301 assigned for all values must include all ordinary-value ports 302 (from 4,096 to 16,384). 304 If the Port-set ID has 1 to 12 bits, the set comprises 4 port ranges. 305 As shown in Figure 3, each port range is defined by its port prefix, 306 made of a range-specific "head" followed by the Port-set ID. Head 307 values are in binary 1, 01, 001, and 0001. They are chosen to 308 exclude ports 0-4095 and only them. 310 <------- Port (16 bits) --------> 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 Port-range a |1|x x x x x x x x| | 0xF780 - 0xF7FF 313 (head = 1) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 \ \ 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Port-range b |0 1|x x x x x x x x| | 0x7BC0 - 0x7BFF 317 (head = 01) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 \ \ 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Port-range c |0 0 1|x x x x x x x x| | 0x3DE0 - 0x3DFF 321 (head = 001) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 \ \ 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Port-range d |0 0 0 1|x x x x x x x x| | 0x1EF0 - 0x1EFF 325 (head = 0001) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 <- head-><--Port-set ID-> /\ 327 <-- Port-range prefix --><-tail-> || 328 || 329 Example of Port-ranges 330 if the Port-set ID is 0xEF 332 Figure 3: From Port-set ID to Port ranges 334 In the Port-set ID has 13 bits, only the 3 port ranges are assigned, 335 having heads 1, 01, and 001. If it has 14 bits, only the 2 port 336 ranges having heads 1 and 01 are assigned. If it has 15 bits, only 337 the port range having head 1 is assigned. (In these three cases, the 338 smallest port range has only one element). 340 NOTE: The port set assigned to a CE may be further subdivided by the 341 CE among several functions such as the following: (1) an IPv4 NAPT 342 (possibly configurable to do port forwarding, and possibly doing 343 dynamic port assignments to hosts with UPnP and/or NAT-PMP); (2) an 344 API for applications in the CE that need dynamic port assignments; 345 (3) a new 4rd BR which assigns to its CE's subsets of its own port 346 set. How to chose among these functions and/or combine them is 347 beyond the scope of this specification. Readers are referred to 348 documents dealing with operational applicability in diverse 349 environments, e.g. [draft-sun-intarea-4rd-applicability] prepared in 350 parallel of this one. 352 4.3.4. From an IPv4 Address or IPv4 address + Port to a CE IPv6 address 354 Port-set ID 355 | 356 <--- CE 4rd prefix ---|-> 357 +---------------+---+-|--+ 358 |IPv4 shared address| ' | 359 +---------------+---+----+ 360 <--------> 361 CE-index length 362 : : 363 : || : 364 : || : 365 : \/ : Domain IPv6 suffix 366 : : | 367 +------------------+--------+--|-+----------------------------------+ 368 |Domain IPv6 prefix|CE index| ' | 0 | 369 +------------------+--------+----+----------------------------------+ 370 <------------ max 64 ------------> 371 <---------------------- CE IPv6 address (128) ---------------------> 373 Figure 4: From 4rd Prefix to IPv6 address (shared IPv4 address case) 375 In order to find whether a CE IPv6 address can be derived from an 376 IPv4 address, or an IPv6 address + a port, a mapping rule has to be 377 found that matches the IPv4 information: 379 o If a mapping rule has a length L of CE IPv4 prefixes which does 380 not exceed 32 bits, there is a match if the IPv4 address starts 381 with the Domain 4rd prefix. The CE 4rd prefix is then the first L 382 bits of the IPv4 address. 384 o If a mapping rule has a length L of CE IPv4 prefixes which exceeds 385 32 bits, the match can only be found with the IPv4 address and the 386 port. For this, the port is examined to determine which port- 387 range head it starts with: 1, 01,001, or 0001. The N bits that 388 follow this head are taken as Port-set ID, where N is the length 389 of Port set ID of the mapping rule. The CE 4rd prefix is then 390 made of the IPv4 address followed by the Port-set ID. 392 If a match has been found, the CE IPv6 prefix is then made of the 393 Domain IPv6 prefix followed by bits of the CE 4rd prefix that 394 follow the Domain 4rd prefix, followed by the Domain IPv6 prefix 395 of the mapping rule if there is one, and followed by 0's up to 128 396 bits to make a complete IPv6 address [RFC4291]. Figure 4 397 illustrates this process in the case of a shared IPv4 address. 399 4.4. Encapsulation and Fragmentation Considerations 401 For 4rd domain traversal, IPv4 packets are encapsulated in IPv6 402 packets whose Next header is set to 4 (i.e. IPv4). If fragmentation 403 of IPv6 packets is needed, it is performed according to [RFC2460], 404 and as illustrated in Figure 5. Absent more specific information, 405 the path MTU of a 4rd Domain has to be set to 1280 [RFC2460]. 407 +--------------------//---------------+ 408 | IPv4 packet | 409 +--------------------//---------------+ 410 : : 411 : : 412 +-----//----+-----//----+--//--+--//--+ 413 | frag 1 | frag 2 | |frag n| 414 IPv6 +-----//----+----//-----+--//--+------+ 415 fragmentation extension : : : : : 416 \ : : : : : 417 |0 \|48 : : : : 418 +----------++-----//----+ : : : 419 | IPv6 || frag 1 | : : : 420 +----------++-----//----+ : : : 421 <---- IPv6 path MTU --->: : : : 422 : : : : 423 +----------++-----//----+ : : 424 | IPv6 || frag 1 | : : 425 +----------++-----//----+ : : 426 <---- IPv6 path MTU ---> : : 427 ... : : 428 : : 429 +----------++--//--+ 430 | IPv6 ||frag n| 431 +----------++------+ 433 Figure 5: Fragmentation of long IPv4 packets for Domain Traversal 435 In domains where IPv4 addresses are not shared, IPv6 destinations are 436 derived from IPv4 addresses alone. Thus, each IPv4 packet can be 437 encapsulated and decapsulated independently of each other. 4rd 438 processing is completely stateless. 440 On the other hand, in domains where IPv4 addresses are shared, BR's 441 and CE's can have to encapsulate IPv4 packets whose IPv6 destinations 442 depend on destination ports. Precautions are needed, due to the fact 443 that the destination port of a fragmented datagram is available only 444 in its first fragment. A sufficient precaution consists in 445 reassembling each datagram received in multiple packets, and to treat 446 it as though it would have been received in single packet. This 447 function is such that 4rd is in this case stateful at the IP layer. 448 (This is common with DS-lite and NAT64/DNS64 which, in addition, are 449 stateful at the transport layer.) At Domain entrance, this ensures 450 that all pieces of all received IPv4 datagrams go to the right IPv6 451 destinations. 453 Another peculiarity of shared IPv4 addresses is that, without 454 precaution, a destination could simultaneously receive from different 455 sources fragmented datagrams that have the same Datagram ID (the 456 Identification field of [RFC0791]). This would disturb the 457 reassembly process. To eliminate this risk, BR's and CE's SHOULD, in 458 datagrams they receive from shared-IPv4-address CE's, replace 459 received Datagram ID's by new ones. New values SHOULD be generated 460 as though these datagrams would have been created locally (and with 461 due respect of [RFC0791]). Note that replacing a Datagram ID in an 462 IPv4 header implies an update of its Header-checksum field, by adding 463 to it the one's complement difference between the old and the new 464 values. 466 4.5. BR and CE behaviors 468 4.5.1. Domains having only One Mapping rule 470 (a) BR reception of an IPv4 packet 472 Step 1 If the length of CE 4rd prefixes does not exceed 32 bits, 473 the BR proceeds to step 2. Otherwise, and unless the 474 packet contains a complete IPv4 datagram, IPv4 datagram 475 reassembly is performed. If a complete datagram is 476 available, the BR proceeds to step 2 as though the 477 datagram had been received in a single packet. 479 Step 2 The BR checks that the IPv4 source doesn't start with the 480 Domain 4rd prefix, and that a CE IPv6 address is 481 successfully derived from the IPv4 destination. In case 482 of success, the packet is encapsulated and forwarded to 483 this CE IPv6 address via the IPv6 interface. 485 (b) BR reception of an IPv6 packet 487 The BR checks that a CE IPv6 address is successfully 488 derived from the source of the IPv4 encapsulated packet, 489 and that the source address of the encapsulating packet is 490 equal to it. In case of success: (1) if the length of CE 491 4rd prefixes exceeds 32 bits, the Datagram ID of the 492 packet is replaced by a locally generated one; (2) the 493 IPv4 packet is forwarded via the IPv4 interface. 495 (c) CE reception of an IPv4 packet 497 Step 1 If the CE 4rd prefix of the CE does not exceed 32 bits and 498 the IPv4 destination address starts with the Domain 4rd 499 prefix, the CE proceeds to step 2. Otherwise, and unless 500 the packet contains a complete IPv4 datagram, IPv4 501 datagram reassembly is performed. If a complete datagram 502 is available, the BR proceeds to step 2 as though the 503 datagram had been received in a single packet. 505 Step 2 The CE tries tries to derive a CE IPv6 address from the 506 IPv4 destination. It then encapsulates the IPv4 packet 507 into an IPv6 packet whose destination is this CE IPv6 508 address, if one is obtained, or the BR IPv6 address 509 otherwise. 511 (d) CE reception of an IPv6 packet (reassembled if applicable) 513 The CE checks that a CE IPv6 address is successfully 514 derived from the source of the IPv4 encapsulated packet, 515 AND that it is equal to the source address of the 516 encapsulating packet. In case of success: (1) if the 517 length of CE 4rd prefixes exceeds 32 bits, the Datagram ID 518 of the packet is replaced by a locally generated one; (2) 519 the IPv4 packet is forwarded via the IPv4 interface. 521 4.5.2. Domains having Multiple Mapping Rules 523 Some ISP will want to use 4rd in networks having several Domain 4rd 524 prefixes, an/or several Domain IPv6 prefixes, and/or assigning CE 4rd 525 prefixes of different lengths. For this several mapping rules are 526 needed. 528 A first possibility consists in establishing several 4rd domains, 529 each on having a single mapping rule. In this case, paths between 530 CE's belonging to different 4rd domains go from one domain to the 531 other in IPv4, and cross two BR's. 533 A second possibility permits direct IPv6 paths between CE's by 534 supporting several mapping rules in a single domain, as described in 535 this section. At time of writing, whether this will be in the 4rd 536 specification a MAY, a SHOULD, or a MUST, remains an open question. 538 (a) BR reception of an IPv4 packet 540 Step 1 If a mapping rule whose length of CE 4rd prefixes does not 541 exceed 32 bits applies to the IPv4 destination, the BR 542 proceeds to step 2. Otherwise, and unless the packet 543 contains a complete IPv4 datagram, IPv4 datagram 544 reassembly is performed. If a complete datagram is 545 available, the BR then proceeds to step 2 as though the 546 datagram had been received in a single packet. 548 Step 2 The BR checks that the IPv4 source doesn't start with the 549 Domain 4rd prefix of any rule. In case of success, the 550 packet is encapsulated and forwarded to this CE IPv6 551 address via the IPv6 interface. 553 (b) BR reception of an IPv6 packet (reassembled if applicable) 555 The BR checks that a CE IPv6 address is successfully 556 derived from the source of the IPv4 encapsulated packet, 557 and that the source address of the encapsulating packet is 558 equal to it. In case of success, the BR tries to derive a 559 CE IPv6 address from the destination of the encapsulated 560 packet. In case of success: (1) if the source CE 4rd 561 prefix exceeds 32 bits, the Datagram ID of the packet is 562 replaced by a locally generated one; (2) the encapsulating 563 packet is retransmitted via the IPv6 interface with this 564 CE IPv6 address as destination (and the BR IPv6 address as 565 source address); in case of failure, the IPv4 packet is 566 decapsulated and forwarded via the IPv4 interface. 568 (c) CE reception of an IPv4 packet 570 Step 1 If the CE 4rd prefix of the CE does not exceed 32 bits, 571 and a mapping rule whose length of CE 4rd prefixes does 572 not exceed 32 bits applies to the IPv4 destination, the CE 573 proceeds to step 2. Otherwise, and unless the packet 574 contains a complete IPv4 datagram, IPv4 datagram 575 reassembly is performed. If a complete datagram is 576 available, the BR then proceeds to step 2 as though the 577 datagram had been received in a single packet. 579 Step 2 The CE tries to derive a CE IPv6 address from the IPv4 580 destination. It then encapsulates the IPv4 packet into an 581 IPv6 packet whose destination is this CE IPv6 address, if 582 one is obtained, or the BR IPv6 address otherwise. 584 (d) CE reception of an IPv6 packet (reassembled if applicable) 586 The CE checks that a CE IPv6 address is successfully 587 derived from the source of the IPv4 encapsulated packet, 588 and that it is equal to the source address of the 589 encapsulating packet. In case of success: (1) if the 590 source CE 4rd prefix exceeds 32 bits, the Datagram ID of 591 the packet is replaced by a locally generated one; (2) the 592 IPv4 packet is decapsulated and forwarded via the IPv4 593 interface. 595 NOTE: With consistency check made between encapsulated and 596 encapsulating sources in BR's and CE's when they received tunneled 597 packets, no CE can forward an invalid IPv4 source address, or address 598 plus port, and have it forwarded at by the egress BR or CE. Yet, if 599 before tunneling a packet, a CE makes an additional check that the 600 IPv4 source is consistent with the CE IPv6 address, it can discard 601 invalid packets earlier than by leaving it to the egress BR or CE. 602 At time of writing, whether this test can remain a MAY, or might 603 require a SHOULD or a MUST remains an open question. 605 5. 4rd Configuration 607 A CE can acquire 4rd parameters of its 4rd domain in various ways: 608 manual configuration by an administrator, software download by the 609 ISP, a new DHCPv6 option, etc. This document describes how to 610 configure the necessary parameters via a single DHCPv6 option. A CE 611 that allows IPv6 configuration by DHCPv6 SHOULD implement this 612 option. Other configuration and management methods, MAY use the 613 format described by this option for consistency and convenience of 614 implementation on CEs that support multiple configuration methods. 616 The format of Figure 6 is proposed for the DCHPv6 option. It is 617 chosen to permit multiple mapping rules: 619 <-2-><-2-><------------------- n octets -----------------> 620 +----+----+-----...-----+-- ... --+-----...-----+-- ... --+ 621 | . | n | parameter 1 | | Parameter j | | 622 +--|-+----+-----...-----+-- ... --+-----...-----+-- ... --+ 623 | _____/ \_____ 624 option code / \ 625 (TBD) +----+----+----+--...--+----+ 626 | . | k | parameter value | 627 +--|-+----+----+--...--+----+ 628 parameter code <--- k octets --> 630 PARAMETER-CODES (in Hexadecimal) 631 0x10 : BR IPv6 address 632 0x11 : Length of CE-IPv6-prefixes 633 0x2m : Domain IPv6 prefix, with m useful bits in last octet 634 0x3m : Domain 4rd prefix, with m useful bits in last octet 635 0x4m : Domain IPv6 suffix, with m useful bits in last octet 637 Figure 6: 4rd DHCPv6 option 639 In the parameter list the BR IPv6 address is first, followed by 640 parameters of each rule. For each rule, the order is . 644 6. Security considerations 646 Spoofing attacks 648 With consistency checks between IPv4 and IPv6 sources that are 649 performed on IPv4/IPv6 packets received by BR's and CE's 650 (Section 4.5), 4rd does not introduce any opportunity for spoofing 651 attack that would not pre-exist in IPv6. 653 Denial-of-service attacks 655 In 4rd domains where IPv4 addresses are shared, the fact that IPv4 656 datagram reassembly may be necessary introduces an opportunity for 657 DOS attacks (Section 4.4). This is inherent to address sharing, 658 and is common with other address sharing approaches such as DS- 659 lite and NAT64/DNS64. 661 The best protection against such attacks is to accelerate IPv6 662 enablement in both clients and servers so that, where 4rd is 663 supported, it is less and less used. 665 Routing-loop attacks 667 Routing-loop attacks that may exist in some automatic-tunneling 668 scenarios are documented in [I-D.ietf-v6ops-tunnel-loops]. They 669 cannot exist with 4rd because each BRs checks that the IPv6 source 670 address of a received IPv6 packet is a CE address (Section 4.5.1 671 (b) and Section 4.5.2 (b) />). 673 Attacks facilitated by restricted port sets 675 From hosts that are not subject to ingress filtering of [RFC2827], 676 some attacks are possible by intervening with faked packets during 677 ongoing transport connections ([RFC4953], [RFC5961], [RFC6056]. 678 These attacks, that have mitigations of their own are easier with 679 hosts that only use restricted port sets (they depend on guessing 680 which ports are currently used by target hosts). To avoid using 681 restricted port sets, the easiest approach consists in increasing 682 the proportion of connections that are IPv6, i.e. using 683 unrestricted port sets. 685 7. IANA Considerations 687 IANA is requested to assign a DHCPv6 option number for 4rd 688 (Section 5). 690 8. Acknowledgments 692 The authors wish to thank Mark Townsley for his active encouragements 693 to pursue the 4rd approach since it was first introduced in 694 [I-D.despres-softwire-sam]. Questions raised by Wojciech Dec have 695 been useful to clarify explanations. Olivier Vautrin, who 696 independently proposed a similar approach with the same acronym 697 deserves special recognition. Particular gratitude is due to 698 decision makers of the Japan ISP's that have announced actual 4rd 699 deployment projects (www.ietf.org/mail-archive/web/v6ops/current/ 700 msg05247). 702 9. References 704 9.1. Normative References 706 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 707 September 1981. 709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 710 Requirement Levels", BCP 14, RFC 2119, March 1997. 712 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 713 (IPv6) Specification", RFC 2460, December 1998. 715 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 716 and M. Carney, "Dynamic Host Configuration Protocol for 717 IPv6 (DHCPv6)", RFC 3315, July 2003. 719 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 720 Architecture", RFC 4291, February 2006. 722 9.2. Informative References 724 [I-D.despres-softwire-sam] 725 Despres, R., "Stateless Address Mapping (SAM) - a 726 Simplified Mesh-Softwire Model", 727 draft-despres-softwire-sam-01 (work in progress), 728 July 2010. 730 [I-D.ietf-behave-dns64] 731 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 732 "DNS64: DNS extensions for Network Address Translation 733 from IPv6 Clients to IPv4 Servers", 734 draft-ietf-behave-dns64-11 (work in progress), 735 October 2010. 737 [I-D.ietf-behave-v6v4-xlate-stateful] 738 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 739 NAT64: Network Address and Protocol Translation from IPv6 740 Clients to IPv4 Servers", 741 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 742 progress), July 2010. 744 [I-D.ietf-softwire-dual-stack-lite] 745 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 746 Stack Lite Broadband Deployments Following IPv4 747 Exhaustion", draft-ietf-softwire-dual-stack-lite-07 (work 748 in progress), March 2011. 750 [I-D.ietf-v6ops-tunnel-loops] 751 Nakibly, G. and F. Templin, "Routing Loop Attack using 752 IPv6 Automatic Tunnels: Problem Statement and Proposed 753 Mitigations", draft-ietf-v6ops-tunnel-loops-03 (work in 754 progress), February 2011. 756 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 757 Defeating Denial of Service Attacks which employ IP Source 758 Address Spoofing", BCP 38, RFC 2827, May 2000. 760 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 761 RFC 4953, July 2007. 763 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 764 Infrastructures (6rd)", RFC 5569, January 2010. 766 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 767 Robustness to Blind In-Window Attacks", RFC 5961, 768 August 2010. 770 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 771 Infrastructures (6rd) -- Protocol Specification", 772 RFC 5969, August 2010. 774 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 775 Protocol Port Randomization", BCP 156, RFC 6056, 776 January 2011. 778 Authors' Addresses 780 Remi Despres (editor) 781 RD-IPtech 782 3 rue du President Wilson 783 Levallois, 784 France 786 Email: remi.despres@free.fr 788 Satoru Matsushima 789 SoftBank 790 1-9-1 Higashi-Shinbashi, Munato-ku 791 Tokyo 792 Japan 794 Email: satoru.matsushima@tm.softbank.co.jp 795 Tetsuya Murakami 796 IP Infusion 797 1188 East Arques Avenue 798 Sunnyvale 799 USA 801 Email: tetsuya@ipinfusion.com 803 Ole Troan 804 Cisco 805 Bergen, Norway 806 France 808 Email: ot@cisco.com