idnits 2.17.1 draft-murakami-softwire-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 (September 22, 2011) is 4593 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) == Missing Reference: 'TR069' is mentioned on line 232, but not defined == Missing Reference: 'RFC2578' is mentioned on line 234, but not defined == Unused Reference: 'RFC3315' is defined on line 708, but no explicit reference was found in the text == Unused Reference: 'I-D.mrugalski-dhc-dhcpv6-4rd' is defined on line 735, 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) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Murakami 3 Internet-Draft IP Infusion 4 Intended status: Standards Track O. Troan 5 Expires: March 25, 2012 cisco 6 S. Matsushima 7 SoftBank 8 September 22, 2011 10 IPv4 Residual Deployment on IPv6 infrastructure - protocol specification 11 draft-murakami-softwire-4rd-01 13 Abstract 15 This document specifies an automatic tunneling mechanism for 16 providing IPv4 connectivity service to end users over a service 17 provider's IPv6 network. Key aspects include stateless operation, 18 sharing of IPv4 addresses, and an algorithmic mapping between IPv4 19 addresses and IPv6 tunnel endpoints. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 25, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. 4rd Configuration . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1. Customer Edge Configuration . . . . . . . . . . . . . . . 6 60 5. Algorithmic mapping . . . . . . . . . . . . . . . . . . . . . 6 61 5.1. Mapping Rules . . . . . . . . . . . . . . . . . . . . . . 6 62 5.1.1. From a CE IPv6 Prefix to a CE 4rd Prefix . . . . . . . 6 63 5.1.2. From a CE 4rd Prefix to a Port-set ID . . . . . . . . 7 64 5.1.3. From a Port-Set ID to a Port Set . . . . . . . . . . . 8 65 5.1.4. From an IPv4 Address or IPv4 Address + Port to a 66 CE IPv6 Address . . . . . . . . . . . . . . . . . . . 10 67 6. Encapsulation and Fragmentation Consideration . . . . . . . . 11 68 7. BR and CE behaviors . . . . . . . . . . . . . . . . . . . . . 12 69 8. NAT considerations . . . . . . . . . . . . . . . . . . . . . . 14 70 9. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 72 11. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16 73 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 74 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 13.1. Normative References . . . . . . . . . . . . . . . . . . . 17 76 13.2. Informative References . . . . . . . . . . . . . . . . . . 17 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 79 1. Introduction 81 4rd is a protocol mechanism to deploy IPv4 to sites via a service 82 provider's (SP's) IPv6 network. Similar to Dual-Stack Lite 83 [I-D.ietf-softwire-dual-stack-lite], 4rd is designed to allow IPv4 84 traffic to be delivered over an IPv6 network without the direct 85 provisioning of IPv4 addresses. 4rd can provide an IPv4 prefix, an 86 IPv4 address or a shared IPv4 address. Like 6rd [RFC5969], 4rd is 87 operated in a fully stateless manner within the SP network. The 88 motivation for a stateless alternative to Dual-Stack Lite is 89 described in "Motivations for Stateless IPv4 over IPv6 Migration 90 Solutions" [I-D.operators-softwire-stateless-4v6-motivation]. 92 4rd relies on IPv6 and is designed to deliver production-quality 93 dual-stack service while allowing IPv4 to be phased out within the SP 94 network. The phasing out of IPv4 within the SP network is 95 independent of whether the end user disables IPv4 service or not. 96 Further, "Greenfield" IPv6-only networks may use 4rd in order to 97 deliver IPv4 to sites via the IPv6 network in a way that does not 98 require protocol translation between IPv4 and IPv6. 100 4rd utilizes an algorithmic mapping between the IPv6 and IPv4 101 addresses that are assigned for use within the SP network. This 102 mapping provides automatic determination of IPv6 tunnel endpoints 103 from IPv4 destination addresses, allowing the stateless operation of 104 4rd. 4rd views the IPv6 network as a link layer for IPv4 and supports 105 an automatic tunneling abstraction similar to the Non-Broadcast 106 Multiple Access (NBMA) [RFC2491] model. 108 The 4rd algorithmic mapping is also used to automatically provision 109 IPv4 addresses and allocating a set of non-overlapping ports for each 110 4rd CE. The "SP-facing" (i.e., "WAN") side of the 4rd CE, operate as 111 native IPv6 interface with no need for IPv4 operation or support. On 112 the "end-user-facing" (i.e., "LAN") side of a CE, IPv6 and IPv4 are 113 implemented as for any native dual-stack service delivered by the SP. 115 A 4rd domain consists of 4rd Customer Edge (CE) routers and one or 116 more 4rd Border Relays (BRs). IPv4 packets encapsulated by 4rd 117 follow the IPv6 routing topology within the SP network between CEs 118 and among CEs and BRs. CE to CE traffic is direct, while BRs are 119 traversed only for IPv4 packets that are destined to or are arriving 120 from outside a given 4rd domain. As 4rd is stateless, BRs may be 121 reached using anycast for failover and resiliency. 123 4rd does not require any stateful NAPT [RFC3022] functions at the BRs 124 or elsewhere within the SP network. Instead, 4rd allows for sharing 125 of IPv4 addresses among multiple sites by automatically allocating a 126 set of non-overlapping ports for each CE as part of the stateless 127 mapping function. It is expected that the CE will, in turn, perform 128 local IPv4 Network Address and Port Translation (NAPT) [RFC3022] 129 functions for the site as is commonly performed today, except 130 avoiding ports outside of the allocated port set. Although 4rd is 131 designed primarily to support IPv4 deployment to a customer site 132 (such as a residential home network) by an SP, it can equally be 133 applied to an individual host acting as a CE router. 135 2. Requirements Language 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 3. Terminology 143 4rd domain (Domain): A set of 4rd CEs and BRs connected to the same 144 virtual 4rd link. A service provider may 145 deploy 4rd with a single 4rd domain, or may 146 utilize multiple 4rd domains. Each domain 147 requires a separate 4rd prefix. 149 4rd Border Relay (BR): A 4rd-enabled router managed by the service 150 provider at the edge of a 4rd domain. A Border 151 Relay router has at least one of each of the 152 following: an IPv6-enabled interface, a 4rd 153 virtual interface acting as an endpoint for the 154 4rd IPv4 in IPv6 tunnel, and an IPv4 interface 155 connected to the native IPv4 network. A 4rd BR 156 may also be referred to simply as a "BR" within 157 the context of 4rd. 159 4rd Customer Edge (CE): A device functioning as a Customer Edge 160 router in a 4rd deployment. In a residential 161 broadband deployment, this type of device is 162 sometimes referred to as a "Residential 163 Gateway" (RG) or "Customer Premises Equipment" 164 (CPE). A typical 4rd CE serving a residential 165 site has one WAN side interface, one or more 166 LAN side interfaces, and a 4rd virtual 167 interface. A 4rd CE may also be referred to 168 simply as a "CE" within the context of 4rd. 170 CE IPv6 prefix: The IPv6 prefix assigned to a CE by other means 171 than 4rd itself, and used by 4rd to derive a CE 172 4rd prefix. 174 CE IPv6 address: In the context of 4rd, the IPv6 address used to 175 reach the 4rd function of a CE from other CE's 176 and from BR's. The IID of this address differs 177 from that of host interface address that start 178 with the CE IPv6 prefix. 180 CE 4rd prefix: The 4rd prefix of the CE. It is derived from 181 the CE IPv6 prefix by a mapping rule according 182 to Section 5.1. Depending on its length, it is 183 an IPv4 prefix, an IPv4 address, or a shared 184 IPv4 address followed by a Port-set ID 185 (Section 5.1.2). 187 Port-set ID: In a CE 4rd prefix longer than 32 bits, bits 188 that follow the first 32. It algorithmically 189 identifies a set of ports exclusively assigned 190 to the CE. As specified in Section 191 Section 5.1.2, the set can comprise up to 4 192 disjoint port ranges. 194 Domain IPv6 prefix: An IPv6 prefix assigned by an ISP to a 4rd 195 domain. 197 Domain IPv4 prefix: A 4rd prefix assigned by an ISP to the 4rd 198 domain. 200 IPv4 Embedded Address (EA) bits: The IPv4 EA-bits in the IPv6 201 address identify an IPv4 prefix, IPv4 address 202 or part of IPv4 address and port set. 204 Shared IPv4 address: An IPv4 address that is shared among multiple 205 nodes. Each node has a separate part of the 206 transport layer port space. 208 4. 4rd Configuration 210 The IPv4 prefix, IPv4 address or shared IPv4 address for use at a 211 customer site is created by extracting the IPv4 embedded address (EA- 212 bits) from the IPv6 prefix delegated to the site. Combined with the 213 4rd IPv4 prefix, the IPv4 prefix, IPv4 address or shared IPv4 address 214 is automatically created by the CE for the customer site when IPv6 215 service is obtained. 217 For a given 4rd domain, the BR and CE MUST be configured with a set 218 of mapping rules and BR IPv6 addresses. The configured values for 219 these elements MUST be consistent for all CEs and BRs within a given 220 4rd domain. 222 A mapping rule consist of the following elements: a Domain IPv6 223 prefix and prefix length, a Domain 4rd prefix and prefix length, CE 224 IPv6 Prefix length, and a Domain IPv6 suffix and length. See section 225 (Section 5.1) for a detailed description of mapping rules. 227 4.1. Customer Edge Configuration 229 The 4rd configuration elements are set to values that are the same 230 across all CEs within a 4rd domain. The values may be configured in 231 a variety of manners, including provisioning methods such as the 232 Broadband Forum's "TR-69" [TR069] Residential Gateway management 233 interface, an XML-based object retrieved after IPv6 connectivity is 234 established, a DNS record, an SMIv2 MIB [RFC2578], or manual 235 configuration by an administrator. A companion document 236 [I-D.mrugalski-dhc-dhcpv6-4rd]describes how to configure the 237 necessary parameters via IPv6 DHCP. A CE that allows IPv6 238 configuration by IPv6 DHCP SHOULD implement this option. Other 239 configuration and management methods may use the format described by 240 this option for consistency and convenience of implementation on CEs 241 that support multiple configuration methods. 243 The only remaining provisioning information the CE requires in order 244 to calculate the 4rd address and enable IPv6 connectivity is an IPv6 245 prefix for the CE. This CE IPv6 prefix is configured as part of 246 obtaining IPv6 Internet access (i.e., configured via SLAAC, DHCPv6, 247 DHCPv6 PD, or otherwise). 249 A single 4rd CE MAY be connected to more than one 4rd domain. Each 250 domain a given CE operates within would require its own set of 4rd 251 configuration elements and would generate its own 4rd address. 253 5. Algorithmic mapping 255 5.1. Mapping Rules 257 5.1.1. From a CE IPv6 Prefix to a CE 4rd Prefix 259 A 4rd mapping rule establishes a 1:1 mapping between CE IPv6 prefixes 260 and CE 4rd prefixes. 262 <---------------- CE IPv6 prefix (max 128) --------------> 263 +-------------------------------+------------------------+ 264 | Domain IPv6 prefix | EA-bits | 265 +-------------------------------+------------------------+ 266 <-- Domain IPv6 Prefix length ->:<-- EA-bits length -->: 267 : : 268 : || : 269 : \/ : 270 : : 271 :<-- EA-bits length -->: 272 +-------------------+------------------------+ 273 | Domain 4rd prefix | EA-bits | 274 +-------------------+------------------------+ 275 <----------- CE 4rd prefix (max 47) ---------> 277 Figure 1: From a CE IPv6 Prefix to a CE 4rd Prefix 279 A CE derives its CE 4rd prefix from the CE IPv6 prefix, using 280 parameters of the applicable mapping rule. If the domain has several 281 mapping rules, the rule that applies is that whose Domain IPv6 prefix 282 has the longest match with the CE IPv6 prefix. As shown in Figure 1, 283 the CE 4rd prefix is created by concatenating the Domain 4rd prefix 284 with the IPv4 EA-bits, where the IPv4 EA-bits is the remainder of the 285 CE IPv6 prefix after the Domain IPv6 prefix (the length of the Domain 286 IPv6 prefix is defined by the mapping rule). 288 5.1.2. From a CE 4rd Prefix to a Port-set ID 290 Depending on its length, a CE 4rd prefix is either an IPv4 prefix, a 291 full IPv4 address, or a shared IPv4 address followed by a Port-set ID 292 (Figure 2). If it includes a port set ID, this ID specifies which 293 ports are assigned to the the CE for its exclusive use 294 (Section 5.1.3). 296 <-- CE 4rd prefix length --> 297 +--------------------------+- - -+ 298 Shorter than 32 bits | IPv4 prefix | ... | 299 + -------------------------+- - -+ 300 <--------------- 32 -------------> 302 <----- CE 4rd prefix length -----> 303 +--------------------------------+ 304 32 bits | IPv4 address | 305 +--------------------------------+ 306 <--------------- 32 -------------> 308 <----------- CE 4rd prefix length ----------> 309 +-------------------------------+-----------+ 310 33 to 47 bits | IPv4 shared address |Port-set ID| 311 +-------------------------------+-----------+ 312 <--------------- 32 -----------><- max 15 --> 314 Figure 2: Variants of CE 4rd prefixes 316 5.1.3. From a Port-Set ID to a Port Set 318 The value of a Port-set ID specifies which ports can be used by a 319 transport layer protocol (UDP, TCP, SCTP etc). Design constraint of 320 the algorithm are the following: 322 Fairness with respect to special-value ports: No port-set must 323 contain any well-known ports [IANA reference]. 325 Fairness with respect to the number of ports For a Port-set-ID's 326 having the same length, all sets must have the 327 same number of ports. 329 Exhaustiveness For any Port-set-ID length, the aggregate of 330 port sets assigned for all values must include 331 all ordinary-value ports. 333 If the Port-set ID has 1 to 12 bits, the set comprises 4 port ranges. 334 As shown in Figure 3, each port range is defined by its port prefix, 335 made of a range-specific "head" followed by the Port-set ID. Head 336 values are in binary 1, 01, 001, and 0001. They are chosen to 337 exclude ports 0-4095 and only them. 339 <------- Port (16 bits) --------> 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 Port-range a |1|x x x x x x x x| | 0xF780 - 0xF7FF 342 (head = 1) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 \ \ 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 Port-range b |0 1|x x x x x x x x| | 0x7BC0 - 0x7BFF 346 (head = 01) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 \ \ 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Port-range c |0 0 1|x x x x x x x x| | 0x3DE0 - 0x3DFF 350 (head = 001) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 \ \ 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Port-range d |0 0 0 1|x x x x x x x x| | 0x1EF0 - 0x1EFF 354 (head = 0001) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 <- head-><--Port-set ID-> /\ 356 <-- Port-range prefix --><-tail-> || 357 || 358 Example of Port-ranges 359 if the Port-set ID is 0xEF 361 Figure 3: From Port-set ID to Port ranges 363 In the Port-set ID has 13 bits, only the 3 port ranges are assigned, 364 having heads 1, 01, and 001. If it has 14 bits, only the 2 port 365 ranges having heads 1 and 01 are assigned. If it has 15 bits, only 366 the port range having head 1 is assigned. (In these three cases, the 367 smallest port range has only one element). 369 5.1.4. From an IPv4 Address or IPv4 Address + Port to a CE IPv6 Address 371 Port-set ID 372 | 373 <--- CE 4rd prefix ---|-> 374 +---------------+---+-|--+ 375 |IPv4 shared address| ' | 376 +---------------+---+----+ 377 <--------> 378 EA-bit length 379 : : 380 : || : 381 : || : 382 : \/ : Domain IPv6 suffix 383 : : | 384 +------------------+--------+--|-+----------------------------------+ 385 |Domain IPv6 prefix| EA-bits| ' | 0 | 386 +------------------+--------+----+----------------------------------+ 387 <------------ max 64 ------------> 388 <---------------------- CE IPv6 address (128) ---------------------> 390 Figure 4: From 4rd Prefix to IPv6 address (shared IPv4 address case) 392 In order to find whether a CE IPv6 address can be derived from an 393 IPv4 address, or an IPv4 address + a port, a mapping rule has to be 394 found that matches the IPv4 information: 396 o If a mapping rule has a length L of CE IPv4 prefixes which does 397 not exceed 32 bits, there is a match if the IPv4 address starts 398 with the Domain 4rd prefix. The CE 4rd prefix is then the first L 399 bits of the IPv4 address. 401 o If a mapping rule has a length L of CE IPv4 prefixes which exceeds 402 32 bits, the match can only be found with the IPv4 address and the 403 port. For this, the port is examined to determine which port- 404 range head it starts with: 1, 01,001, or 0001. The N bits that 405 follow this head are taken as Port-set ID, where N is the length 406 of Port set ID of the mapping rule. The CE 4rd prefix is then 407 made of the IPv4 address followed by the Port-set ID. 409 If a match has been found, the CE IPv6 prefix is then made of the 410 Domain IPv6 prefix followed by bits of the CE 4rd prefix that follow 411 the Domain 4rd prefix, followed by the Domain IPv6 prefix of the 412 mapping rule if there is one, and followed by 0's up to 128 bits to 413 make a complete IPv6 address ([RFC4291]. Figure 4 illustrates this 414 process in the case of a shared IPv4 address. 416 6. Encapsulation and Fragmentation Consideration 418 Maximum transmission unit (MTU) and fragmentation issues for IPv4 in 419 IPv6 tunneling are discussed in detail in Section 7.2 of [RFC2473]. 420 4rd's scope is limited to a service provider network. IPv6 Path MTU 421 discovery MAY be used to adjust the MTU of the tunnel as described in 422 Section 7.2 of [RFC2473], or the 4rd Tunnel MTU might be explicitly 423 configured. 425 The use of an anycast source address could lead to any ICMP error 426 message generated on the path being sent to a different BR. 427 Therefore, using dynamic tunnel MTU Section 7.2 of [RFC2473] is 428 subject to IPv6 Path MTU blackholes. 430 Multiple BRs using the same anycast source address could send 431 fragmented packets to the same 4rd CE at the same time. If the 432 fragmented packets from different BRs happen to use the same fragment 433 ID, incorrect reassembly might occur. For this reason, a BR using an 434 anycast source address MUST NOT fragment the IPv6 encapsulated packet 435 unless BR's having identical rules are required to use disjoint 436 ranges of fragment ID. 438 If the MTU is well-managed such that the IPv6 MTU on the CE WAN side 439 interface is set so that no fragmentation occurs within the boundary 440 of the SP, then the 4rd Tunnel MTU should be set to the known IPv6 441 MTU minus the size of the encapsulating IPv6 header (40 bytes). For 442 example, if the IPv6 MTU is known to be 1500 bytes, the 4rd Tunnel 443 MTU might be set to 1460 bytes. Absent more specific information, 444 the 4rd Tunnel MTU SHOULD default to 1280 bytes. 446 Alternatively, if BR's having identical rule are required to use 447 disjoint ranges of fragment ID, a BR using an anycast source address 448 SHOULD fragment the IPv6 encapsulated packet correctly. 450 For 4rd domain traversal, IPv4 packets are encapsulated in IPv6 451 packets whose Next header is set to 4 (i.e. IPv4). If fragmentation 452 of IPv6 packets is needed, it is performed according to [RFC2460]. 453 Absent more specific information, the path MTU of a 4rd Domain has to 454 be set to 1280 [RFC2460]. 456 In domains where IPv4 addresses are not shared, IPv6 destinations are 457 derived from IPv4 addresses alone. Thus, each IPv4 packet can be 458 encapsulated and decapsulated independently of each other. 4rd 459 processing is completely stateless. 461 On the other hand, in domains where IPv4 addresses are shared, BR's 462 and CE's can have to encapsulate IPv4 packets whose IPv6 destinations 463 depend on destination ports. Precautions are needed, due to the fact 464 that the destination port of a fragmented datagram is available only 465 in its first fragment. A sufficient precaution consists in 466 reassembling each datagram received in multiple packets, and to treat 467 it as though it would have been received in single packet. This 468 function is such that 4rd is in this case stateful at the IP layer. 469 (This is common with DS-lite and NAT64/DNS64 which, in addition, are 470 stateful at the transport layer.) At Domain entrance, this ensures 471 that all pieces of all received IPv4 datagrams go to the right IPv6 472 destinations. 474 Another peculiarity of shared IPv4 addresses is that, without 475 precaution, a destination could simultaneously receive from different 476 sources fragmented datagrams that have the same Datagram ID (the 477 Identification field of [RFC0791]. This would disturb the reassembly 478 process. To eliminate this risk, CE MUST rewrite the datagram ID to 479 an unique value among CEs having same shared IPv4 address upon 480 sending the packets over 4rd tunnel. This value SHOULD be generated 481 locally within the port-range assigned to a given CE. Note that 482 replacing a Datagram ID in an IPv4 header implies an update of its 483 Header-checksum fieald, by adding to it the one's complement 484 difference between the old and the new values. 486 7. BR and CE behaviors 488 (a) BR reception of an IPv4 packet 490 Step 1 BR looks up an appropriate mapping rule with a 491 specific Domain 4rd prefix which has the 492 longest match with an IPv4 destination address 493 in the received IPv4 packet. If the mapping 494 rule is not found, the received packet should 495 be discarded. If the length of CE 4rd prefix 496 associated with the mapping rule does not 497 exceed 32 bits, BR proceeds to step 2. If the 498 length of CE 4rd prefix exceeds 32 bits, BR 499 checks that the received packet contains a 500 complete IPv4 datagram. If the packet is 501 fragmented, BR should reassemble the packet. 502 Once BR can obtain the complete IPv4 datagram, 503 BR proceeds to step 2 as though the datagram 504 has been received in a single packet. 506 Step 2 BR generates a CE IPv6 address from the IPv4 507 destination address or the IPv4 destination 508 address and the destination port based on the 509 mapping rule found in step 1. If the CE IPv6 510 address can be successfully generated, BR 511 encapsulates the IPv4 packet in IPv6 and 512 forwards the IPv6 packet via the IPv6 513 interface. If the length of the IPv6 514 encapsulated packet exceeds the MTU of the IPv6 515 interface, the fragmentation should be done in 516 IPv6. 518 (b) BR reception of an IPv6 packet 520 Step 1 If the received IPv6 packet is fragmented, the 521 reassembly should be done in IPv6 at first. 522 Once BR obtains a complete IPv6 packet, BR 523 looks up an appropriate mapping rule with a 524 specific Domain 4rd prefix which has the 525 longest match with an IPv4 source address in 526 the encapsulated IPv4 packet. If the mapping 527 rule is not found, the received IPv6 packet 528 should be discarded. BR derives a CE IPv6 529 address from the IPv4 source address or the 530 IPv4 source address and the source port in the 531 encapsulated IPv4 packet based on the mapping 532 rule. If the CE IPv6 address is eqaul to the 533 IPv6 source address in the received IPv6 534 packet, BR decapsulates the IPv4 packet and 535 then forward it via the IPv4 interface. 537 (c) CE reception of an IPv4 packet 539 Step 1 CE looks up an appropriate mapping rule with a 540 specific Doamin 4rd prefix which has the 541 longest match with an IPv4 destination address 542 in the received IPv4 packet. If the mapping 543 rule is found, the CE 4rd prefix must be 544 checked. If the length does not exceeds 32 545 bits, CE proceeds to step 2. If the length 546 exceeds 32 bits, CE checks that the received 547 IPv4 packet contains a complete IPv4 datagram. 548 If the packet is fragmented, CE should 549 reassemble the packet. Once CE can obtain the 550 complete IPv4 datagram, CE proceeds to step 2 551 as though the datagram has been received in a 552 single packet. If the mapping rule is not 553 found, CE proceeds to step 2. 555 Step 2 If the mapping rule is found in step 1, CE 556 derives a IPv6 destination address from the 557 IPv4 destination address or the IPv4 558 destination address and the destination port 559 based on the mapping rule. If the IPv6 560 destination address can be derived 561 successfully, CE encapsulates the IPv4 packet 562 in IPv6 whose destination address is set to the 563 derived IPv6 address. If the mapping rule is 564 not found in step 1, CE encapsulates the IPv4 565 packet in IPv6 whose destination address is set 566 to BR IPv6 address. Then CE forwards the IPv6 567 packet via IPv6 interface. If the length of 568 the IPv6 packet exceeds the MTU of the IPv6 569 interface, the fragmentation should be done in 570 IPv6. Moreover, if using IPv4 shared address, 571 a Datagram ID in the received IPv4 header must 572 be over-written before encapsulating the IPv4 573 packet in IPv6. In case of shared IPv4 574 address, the Datagram ID must be unique among 575 CEs sharing the same IPv4 address. Hence, CE 576 should assign the unique value and set this 577 value to the datagram ID in IPv4 header. This 578 value may be generated from the port-range 579 assigned to the CE to keep the uniqueness among 580 CEs sharing same IPv4 address. 582 (d) CE reception of an IPv6 packet 584 Step 1 If the received IPv6 packet is fragmented, the 585 reassembly should be done in IPv6 at first. 586 Once CE obtains a complete IPv6 packet, CE 587 looks up an appropriate mapping rule with s 588 specific Domain 4rd prefix which has the 589 longest match with an IPv4 source address in 590 the encapsulated IPv4 packet. If the mapping 591 rule is found, CE derives a CE IPv6 address 592 from the IPv4 source address or the IPv4 source 593 address and the source port based on the 594 mapping rule and then checks that the IPv6 595 source address of the received IPv6 packet is 596 matched to it. If the mapping rule is not 597 found, CE checks that the IPv6 source address 598 is matched to BR IPv6 address. In case of 599 success, CE decapsulates the IPv4 packet and 600 forward it via the IPv4 interface. 602 8. NAT considerations 604 NAT44 should be implemented in CPE which has 4rd CE function. The 605 NAT44 must conform that best current practice documented in 607 [RFC4787], [RFC5508] and [RFC5382]. When there are restricted 608 available port numbers in a given 4rd CE described in Section 5.1.3, 609 the NAT44 must restrict mapping ports within the port-set. 611 9. ICMP 613 ICMP message should be supported in 4rd domain. Hence, the NAT44 in 614 4rd CE must implement the behavior for ICMP message conforming to the 615 best current practice documented in [RFC5508]. 617 If a 4rd CE receives an ICMP message having ICMP identifier field in 618 ICMP header, NAT44 in the 4rd CE must rewrite this field to a 619 specific value assigned from the port-set described in Section 5.1.3. 620 BR and other CEs must handle this field similar to the port number in 621 tcp/udp header upon receiving the ICMP message with ICMP identifier 622 field. 624 If a 4rd BR and CE receives an ICMP error message without ICMP 625 identifier field for some errors that is detected inside a IPv6 626 tunnel, a 4rd BR and CE should replay the ICMP error message to the 627 original source. This behavior should be implemented conforming to 628 the section 8 of [RFC2473]. The 4rd BR and CE obtain the origianl 629 IPv6 tunnel packet storing in ICMP payload and then decapsulate IPv4 630 packet. Finally the 4rd BR and CE generate a new ICMP error message 631 from the decapsulated IPv4 packet and then forward it. 633 If a 4rd BR receives an ICMP error message on its IPv4 interface, the 634 4rd BR should replay the ICMP message to an appropriate 4rd CE. If 635 IPv4 address is not shared, the 4rd BR generates a CE IPv6 address 636 from the IPv4 destination address in the ICMP error message and 637 encapsulates the ICMP message in IPv6. If IPv4 address is shared, 638 the 4rd BR derives an original IPv4 packet from the ICMP payload and 639 generates a CE IPv6 address from the source address and the source 640 port in the original IPv4 packet. If the 4rd BR can generate the CE 641 IPv6 address, the 4rd BR encapsulates the ICMP error message in IPv6 642 and then forward it to its IPv6 interface. 644 10. Security Considerations 646 Spoofing attacks: With consistency checks between IPv4 and IPv6 647 sources that are performed on IPv4/IPv6 packets 648 received by BR's and CE's (Section 7), 4rd does 649 not introduce any opportunity for spoofing 650 attack that would not pre-exist in IPv6. 652 Denial-of-service attacks: In 4rd domains where IPv4 addresses are 653 shared, the fact that IPv4 datagram reassembly 654 may be necessary introduces an opportunity for 655 DOS attacks (Section 4.4). This is inherent to 656 address sharing, and is common with other 657 address sharing approaches such as DS- lite and 658 NAT64/DNS64. The best protection against such 659 attacks is to accelerate IPv6 enablement in 660 both clients and servers so that, where 4rd is 661 supported, it is less and less used. 663 Routing-loop attacks: This attack may exist in some automatic- 664 tunneling scenarios are documented in 665 [I-D.ietf-v6ops-tunnel-loops]. They cannot 666 exist with 4rd because each BRs checks that the 667 IPv6 source address of a received IPv6 packet 668 is a CE address Section 5.1. 670 Attacks facilitated by restricted port set: From hosts that are not 671 subject to ingress filtering of [RFC2827], some 672 attacks are possible by intervening with faked 673 packets during ongoing transport connections 674 ([RFC4953], [RFC5961], [RFC6056]. The attacks 675 depend on guessing which ports are currently 676 used by target hosts. Using unrestricted port 677 set which mean that are IPv6 is exactly 678 preferable. To avoid this attacks using 679 restricted port set, NAT44 filtering behavior 680 SHOULD be "Address-Dependent Filtering". 682 11. IANA Consideration 684 This document makes no request of IANA. 686 12. Acknowledgements 688 This draft is based on original idea described in 689 [I-D.despres-softwire-sam]. The authors would like to thank Remi 690 Despres, Mark Townsley, Wojciech Dec and Olivier Vautrin. 692 13. References 693 13.1. Normative References 695 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 696 September 1981. 698 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 699 Requirement Levels", BCP 14, RFC 2119, March 1997. 701 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 702 (IPv6) Specification", RFC 2460, December 1998. 704 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 705 over Non-Broadcast Multiple Access (NBMA) networks", 706 RFC 2491, January 1999. 708 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 709 and M. Carney, "Dynamic Host Configuration Protocol for 710 IPv6 (DHCPv6)", RFC 3315, July 2003. 712 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 713 Architecture", RFC 4291, February 2006. 715 13.2. Informative References 717 [I-D.despres-softwire-sam] 718 Despres, R., "Stateless Address Mapping (SAM) - a 719 Simplified Mesh-Softwire Model", 720 draft-despres-softwire-sam-01 (work in progress), 721 July 2010. 723 [I-D.ietf-softwire-dual-stack-lite] 724 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 725 Stack Lite Broadband Deployments Following IPv4 726 Exhaustion", draft-ietf-softwire-dual-stack-lite-11 (work 727 in progress), May 2011. 729 [I-D.ietf-v6ops-tunnel-loops] 730 Nakibly, G. and F. Templin, "Routing Loop Attack using 731 IPv6 Automatic Tunnels: Problem Statement and Proposed 732 Mitigations", draft-ietf-v6ops-tunnel-loops-07 (work in 733 progress), May 2011. 735 [I-D.mrugalski-dhc-dhcpv6-4rd] 736 Mrugalski, T., "DHCPv6 Options for IPv4 Residual 737 Deployment (4rd)", draft-mrugalski-dhc-dhcpv6-4rd-00 (work 738 in progress), July 2011. 740 [I-D.operators-softwire-stateless-4v6-motivation] 741 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 742 Borges, I., and G. Chen, "Motivations for Stateless IPv4 743 over IPv6 Migration Solutions", 744 draft-operators-softwire-stateless-4v6-motivation-02 (work 745 in progress), June 2011. 747 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 748 IPv6 Specification", RFC 2473, December 1998. 750 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 751 Defeating Denial of Service Attacks which employ IP Source 752 Address Spoofing", BCP 38, RFC 2827, May 2000. 754 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 755 Address Translator (Traditional NAT)", RFC 3022, 756 January 2001. 758 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 759 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 760 RFC 4787, January 2007. 762 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 763 RFC 4953, July 2007. 765 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 766 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 767 RFC 5382, October 2008. 769 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 770 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 771 April 2009. 773 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 774 Robustness to Blind In-Window Attacks", RFC 5961, 775 August 2010. 777 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 778 Infrastructures (6rd) -- Protocol Specification", 779 RFC 5969, August 2010. 781 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 782 Protocol Port Randomization", BCP 156, RFC 6056, 783 January 2011. 785 Authors' Addresses 787 Tetsuya Murakami 788 IP Infusion 789 1188 East Arques Avenue 790 Sunnyvale 791 USA 793 Email: tetsuya@ipinfusion.com 795 Ole Troan 796 cisco 797 Oslo 798 Norway 800 Email: ot@cisco.com 802 Satoru Matsushima 803 SoftBank 804 1-9-1 Higashi-Shinbashi, Munato-ku 805 Tokyo 806 Japan 808 Email: satoru.matsushima@tm.softbank.co.jp