idnits 2.17.1 draft-mdt-softwire-map-encapsulation-00.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 (January 27, 2012) is 4470 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 646, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'I-D.operators-softwire-stateless-4v6-motivation' is defined on line 673, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-mdt-softwire-map-dhcp-option-01 == Outdated reference: A later version (-03) exists of draft-mdt-softwire-mapping-address-and-port-01 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) 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 T. Murakami, Ed. 3 Internet-Draft IP Infusion 4 Intended status: Standards Track O. Troan 5 Expires: July 30, 2012 cisco 6 S. Matsushima 7 SoftBank 8 January 27, 2012 10 MAP Encapsulation (MAP-E) - specification 11 draft-mdt-softwire-map-encapsulation-00 13 Abstract 15 This document specifies the "Mapping of Address and Port" (MAP) 16 encapsulation based solution (MAP-E) with an automatic tunneling 17 mechanism for providing IPv4 connectivity service to end users over a 18 service provider's IPv6 network. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 30, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. MAP-E Configuration . . . . . . . . . . . . . . . . . . . . . 5 58 5. MAP-E Node Behavior . . . . . . . . . . . . . . . . . . . . . 5 59 5.1. Provisioning of MAP-E BR . . . . . . . . . . . . . . . . . 5 60 5.2. Packet Forwarding Behavior on MAP-E BR . . . . . . . . . . 6 61 5.3. Provisioning of MAP-E CE . . . . . . . . . . . . . . . . . 7 62 5.4. Packet Forwarding Behavior on MAP-E CE . . . . . . . . . . 8 63 6. Deriving IPv6 address from IPv4 . . . . . . . . . . . . . . . 9 64 6.1. Deriving IPv6 address from IPv4 Address and Port 65 Number at the BR . . . . . . . . . . . . . . . . . . . . . 9 66 6.2. Deriving IPv6 address from IPv4 Address and Port 67 Number at the CE . . . . . . . . . . . . . . . . . . . . . 10 68 7. Encapsulation and Fragmentation Considerations . . . . . . . . 10 69 8. Packet Forwarding Considerations . . . . . . . . . . . . . . . 11 70 8.1. Mesh model . . . . . . . . . . . . . . . . . . . . . . . . 12 71 8.2. Hub & Spoke model . . . . . . . . . . . . . . . . . . . . 12 72 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 12 73 10. ICMP Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 12. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 14 76 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 77 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 14.1. Normative References . . . . . . . . . . . . . . . . . . . 14 79 14.2. Informative References . . . . . . . . . . . . . . . . . . 15 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 82 1. Introduction 84 MAP-E is a protocol mechanism of the &ldque;Mapping of Address and 85 Port" (MAP) encapsulation based solution to deploy IPv4 to sites via 86 a service provider's (SP's) IPv6 network with the automatic tunneling 87 mechanism (IPv4-in-IPv6). Similar to Dual-Stack Lite 88 [I-D.ietf-softwire-dual-stack-lite], MAP-E is designed to allow IPv4 89 traffic to be delivered over an IPv6 network without the direct 90 provisioning of IPv4 addresses. Like 6rd [RFC5969], MAP-E is 91 operated in a fully stateless manner within the SP network. 93 MAP-E relies on IPv6 and is designed to deliver production-quality 94 dual-stack service while allowing IPv4 to be phased out within the SP 95 network. The phasing out of IPv4 within the SP network is 96 independent of whether the end user disables IPv4 service or not. 97 Further, &ldque;Greenfield&ldque; IPv6-only networks may use MAP-E in 98 order to deliver IPv4 to sites via the IPv6 network in a way that 99 does not require protocol translation between IPv4 and IPv6. 101 MAP-E utilizes an algorithmic mapping, defined in MAP 102 [I-D.mdt-softwire-mapping-address-and-port], between the IPv6 and 103 IPv4 addresses that are assigned for use within the SP network. This 104 mapping can provide automatic determination of IPv6 tunnel endpoints 105 from IPv4 destination addresses, allowing the stateless operation of 106 MAP-E. MAP-E views the IPv6 network as a link layer for IPv4 and 107 supports an automatic tunneling abstraction similar to the Non- 108 Broadcast Multiple Access (NBMA) [RFC2491] model. 110 The MAP algorithmic mapping is also used to automatically provision 111 IPv4 addresses and allocating a set of non-overlapping ports for each 112 MAP-E CE. The "SP-facing" (i.e., "WAN") side of the MAP-E CE, 113 operate as native IPv6 interface with no need for IPv4 operation or 114 support. On the "end-user-facing" (i.e., "LAN") side of a CE, IPv6 115 and IPv4 might be implemented as for any native dual-stack service 116 delivered by the SP. 118 A MAP-E domain consists of MAP-E Customer Edge (CE) routers and one 119 or more MAP-E Border Relays (BRs). IPv4 packets encapsulated by 120 MAP-E follow the IPv6 routing topology within the SP network between 121 CEs and among CEs and BRs. CE to CE traffic is direct, while BRs are 122 traversed only for IPv4 packets that are destined to or are arriving 123 from outside a given MAP-E domain. As MAP-E is stateless, BRs may be 124 reached using anycast for failover and resiliency. 126 MAP-E does not require any stateful NAPT [RFC3022] functions at the 127 BRs or elsewhere within the SP network. Instead, MAP-E allows for 128 sharing of IPv4 addresses among multiple sites by automatically 129 allocating a set of non-overlapping ports for each CE as part of the 130 stateless mapping function. It is expected that the CE will, in 131 turn, perform local IPv4 Network Address and Port Translation (NAPT) 132 [RFC3022] functions for the site as is commonly performed today, 133 except avoiding ports outside of the allocated port set. Although 134 MAP-E is designed primarily to support IPv4 deployment to a customer 135 site (such as a residential home network) by an SP, it can equally be 136 applied to an individual host acting as a CE router. 138 2. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 3. Terminology 146 MAP-E: Mapping of Address and Port - Encapsulation 147 mode. MAP-E utilizes a simple IPv4-in-IPv6 148 tunneling along with the MAP extensions for 149 mapping between IPv4 and IPv6 defined in MAP 150 [I-D.mdt-softwire-mapping-address-and-port] and 151 this draft. 153 MAP-E domain (Domain): A set of MAP-E CEs and BRs connected to the 154 same virtual MAP-E link. A service provider 155 may deploy MAP-E with a single MAP-E domain, or 156 may utilize multiple MAP-E domains. Each 157 domain requires a separate MAP-E rule set. 159 MAP-E Border Relay (BR): A MAP-E enabled router managed by the 160 service provider at the edge of a MAP-E domain. 161 A Border Relay router has at least one of each 162 of the following: an IPv6-enabled interface, a 163 MAP-E virtual interface acting as an endpoint 164 for the MAP-E IPv4 in IPv6 tunnel, and an IPv4 165 interface connected to the native IPv4 network. 166 A MAP-E BR may also be referred to simply as a 167 "BR" within the context of MAP-E. 169 MAP-E Customer Edge (CE): A device functioning as a Customer Edge 170 router in a MAP-E deployment. In a residential 171 broadband deployment, this type of device is 172 sometimes referred to as a "Residential 173 Gateway" (RG) or "Customer Premises Equipment" 174 (CPE). A typical MAP-E CE serving a 175 residential site has one WAN side interface, 176 one or more LAN side interfaces, and a MAP-E 177 virtual interface. A MAP-E CE may also be 178 referred to simply as a "CE" within the context 179 of MAP-E. 181 Shared IPv4 address: An IPv4 address that is shared among multiple 182 nodes. Each node has a separate part of the 183 transport layer port space. 185 MAP-E Rule: A MAP rule defining the mapping relationship 186 for a given MAP-E domain between IPv4 and IPv6, 187 defined in MAP 188 [I-D.mdt-softwire-mapping-address-and-port] 190 4. MAP-E Configuration 192 The IPv4 prefix, IPv4 address or shared IPv4 address for use at a 193 customer site is automatically obtained based on BMR defined in MAP 194 [I-D.mdt-softwire-mapping-address-and-port] from the IPv6 prefix 195 delegated to the site. 197 For a given MAP-E domain, the BR and CE MUST be configured with a set 198 of mapping rules (BMR, FMR and DMR) defined in 199 [I-D.mdt-softwire-mapping-address-and-port] . The configured values 200 for these elements MUST be consistent for all CEs and BRs within a 201 given MAP-E domain. 203 The configuration elements in the set of mapping rules (BMR, FMR and 204 DMR) may be provisioned via IPv6 DHCP defined in 205 [I-D.mdt-softwire-map-dhcp-option] or manually. 207 The only remaining provisioning information in order to enable MAP-E 208 is an IPv6 prefix. This IPv6 prefix is configured as part of 209 obtaining IPv6 Internet access (i.e., configured via SLAAC, DHCPv6, 210 DHCPv6 PD, manual or otherwise). 212 5. MAP-E Node Behavior 214 5.1. Provisioning of MAP-E BR 216 The MAP-E BR needs to be provisioned with information for the MAP-E 217 domain or domains it is expected to handle, along with any necessary 218 routing processes. For each MAP-E domain, the BR will have the 219 following parameters: 221 o The MAP Domain IPv4 and IPv6 prefix, and their lengths (Basic 222 Mapping Rule) 224 o The MAP EA-bits (CE index), including IPv4 suffix, length and any 225 port-range (including any excluded ports and the port number 226 continuity parameter) 228 o The BR prefix and its length (Default Mapping Rule) 230 o The subnet ID 232 A BR when configured for BMR, FMR and DMR, and performs the following 233 functions: 235 o Configures the IPv4/IPv6 stateless encapsulation parameters (BMR, 236 FMR and DMR) 238 Based on the above configuration, the IPv4-in-IPv6 encapsulation 239 function can be performed by the BR. 241 o Derive IPv4 address along with any applicable port-range from IPv4- 242 translatable address (BMR) 244 o Derive IPv4-translatable address from IPv4 address and port number 245 (FMR) 247 5.2. Packet Forwarding Behavior on MAP-E BR 249 (a) BR reception of an IPv4 packet 251 Step 1 BR looks up an appropriate mapping rule (FMR) 252 with a specific Domain IPv4 prefix which has 253 the longest match with an IPv4 destination 254 address in the received IPv4 packet. If the 255 FMR is not found, the received packet should be 256 discarded. If the length of Domain IPv4 prefix 257 plus EA-bits associated with the FMR does not 258 exceed 32 bits, BR proceeds to step 2. If the 259 length exceeds 32 bits, BR checks that the 260 received packet contains a complete IPv4 261 datagram. If the packet is fragmented, BR 262 should reassemble the packet. Once BR can 263 obtain the complete IPv4 datagram, BR proceeds 264 to step 2 as though the datagram has been 265 received in a single packet. 267 Step 2 BR generates a CE IPv6 address from the IPv4 268 destination address or the IPv4 destination 269 address and the destination port based on the 270 FMR found in step 1. If the CE IPv6 address 271 can be successfully generated, BR encapsulates 272 the IPv4 packet in IPv6 and forwards the IPv6 273 packet via the IPv6 interface. If the length 274 of the IPv6 encapsulated packet exceeds the MTU 275 of the IPv6 interface, the fragmentation should 276 be done in IPv6. 278 (b) BR reception of an IPv6 packet 280 Step 1 If the received IPv6 packet is fragmented, the 281 reassembly should be done in IPv6 at first. 282 Once BR obtains a complete IPv6 packet, BR 283 looks up an appropriate mapping rule (BMR) with 284 a specific Domain IPv6 prefix which has the 285 longest match with an IPv6 source address in 286 the received IPv6 packet. If the BMR rule is 287 not found, the received IPv6 packet should be 288 discarded. BR derives a CE IPv6 address from 289 the IPv4 source address or the IPv4 source 290 address and the source port in the encapsulated 291 IPv4 packet based on the BMR. If the CE IPv6 292 address is eqaul to the IPv6 source address in 293 the received IPv6 packet, BR decapsulates the 294 IPv4 packet and then forward it via the IPv4 295 interface. 297 5.3. Provisioning of MAP-E CE 299 A MAP-E CE requires the following parameters for provisioning: 301 o The MAP Domain IPv4 and IPv6 prefix, and their lengths (Basic 302 Mapping Rule) 304 o The MAP EA-bits (CE index), including IPv4 suffix, length and any 305 port-range (including any excluded ports and the port number 306 continuity parameter) 308 o The BR prefix and its length (Default Mapping Rule) 310 A MAP-E CE that receives a MAP DHCP option 311 [I-D.mdt-softwire-map-dhcp-option] for BMR, FMR and DMR and performs 312 the following (MAP initialization) functions: 314 o Configures the NAT44 port-range mapping function parameters (BMR) 315 o Configures the IPv4/IPv6 stateless encapsulation parameters (BMR, 316 FMR and DMR) Based on the above configuration, the IPv4/IPv6 317 encapsulation function can be performed in CE. 319 o Derives IPv4 address along with any applicable port-range from 320 IPv4-translatable address (BMR) 322 o Derives IPv4-translatable address from IPv4 address (FMR) 324 5.4. Packet Forwarding Behavior on MAP-E CE 326 (a) CE reception of an IPv4 packet 328 Step 1 CE looks up an appropriate mapping rule (FMR) 329 with a specific Doamin IPv4 prefix which has 330 the longest match with an IPv4 destination 331 address in the received IPv4 packet. If the 332 FMR is found, the length of Domain IPv4 prefix 333 plus EA-bits must be checked. If the length 334 does not exceeds 32 bits, CE proceeds to step 335 2. If the length exceeds 32 bits, CE checks 336 that the received IPv4 packet contains a 337 complete IPv4 datagram. If the packet is 338 fragmented, CE should reassemble the packet. 339 Once CE can obtain the complete IPv4 datagram, 340 CE proceeds to step 2 as though the datagram 341 has been received in a single packet. If the 342 FMR is not found, CE proceeds to step 2. 344 Step 2 If the FMR is found in step 1, CE derives a 345 IPv6 destination address from the IPv4 346 destination address or the IPv4 destination 347 address and the destination port based on the 348 FMR. If the IPv6 destination address can be 349 derived successfully, CE encapsulates the IPv4 350 packet in IPv6 whose destination address is set 351 to the derived IPv6 address. If the FMR is not 352 found in step 1, CE uses the DMR and then CE 353 encapsulates the IPv4 packet in IPv6 whose 354 destination address is set to the BR IPv6 355 address. Then CE forwards the IPv6 packet via 356 IPv6 interface. If the length of the IPv6 357 packet exceeds the MTU of the IPv6 interface, 358 the fragmentation should be done in IPv6. 359 Moreover, if using IPv4 shared address, a 360 Datagram ID in the received IPv4 header must be 361 over-written before encapsulating the IPv4 362 packet in IPv6. In case of shared IPv4 363 address, the Datagram ID must be unique among 364 CEs sharing the same IPv4 address. Hence, CE 365 should assign the unique value and set this 366 value to the datagram ID in IPv4 header. This 367 value may be generated from the port-range 368 assigned to the CE to keep the uniqueness among 369 CEs sharing same IPv4 address. 371 (b) CE reception of an IPv6 packet 373 Step 1 If the received IPv6 packet is fragmented, the 374 reassembly should be done in IPv6 at first. 375 Once CE obtains a complete IPv6 packet, CE 376 looks up an appropriate mapping rule (BMR) with 377 a specific Domain IPv6 prefix which has the 378 longest match with an IPv6 source address in 379 the recieved IPv6 packet. If the BMR is found, 380 the CE derives a CE IPv6 address from the IPv4 381 source address or the IPv4 source address and 382 the source port based on the BMR and then 383 checks that the IPv6 source address of the 384 received IPv6 packet is matched to it. If the 385 BMR is not found, CE checks that the IPv6 386 source address is matched to the BR IPv6 387 address. In case of success, the CE can 388 decapsulate the IPv4 packet and forward it via 389 the IPv4 interface. 391 6. Deriving IPv6 address from IPv4 393 6.1. Deriving IPv6 address from IPv4 Address and Port Number at the BR 395 IPv6 Source Address and Source Port Number: 397 At the BR, the IPv6 source address MUST be set to the BR IPv6 address 398 as per DMR MAP [I-D.mdt-softwire-mapping-address-and-port]. The 399 source Layer 4 port number MUST be unchanged. 401 IPv6 Destination Address and Destination Port Number: 403 At the BR, the IPv6 destination address (IPv4-translatable address) 404 MUST be derived from the IPv4 destination address and the destination 405 port number per FMR MAP [I-D.mdt-softwire-mapping-address-and-port]. 406 The destination Layer 4 port number MUST be unchanged. 408 6.2. Deriving IPv6 address from IPv4 Address and Port Number at the CE 410 IPv6 Source Address and Source Port Number: 412 At the CE, the IPv6 source address (IPv4-translatable address) MUST 413 be derived from the IPv4 source address as per BMR MAP 414 [I-D.mdt-softwire-mapping-address-and-port]. The source port number 415 MUST be unchanged. 417 IPv6 Destination Address and Destination Port Number: 419 At the CE, if Forwarding Mapping Rules (FMRs) are enabled, the IPv4 420 packet MUST be checked to see if the IPv4 destination address matches 421 the FMR. If matching, the IPv6 destination address (IPv4-converted 422 address) MUST be derived from the IPv4 destination address and the 423 destination port number as per FMR. Otherwise, the IPv6 destination 424 address MUST be set to the BR IPv6 address per DMR MAP 425 [I-D.mdt-softwire-mapping-address-and-port]. The destination port 426 number MUST be unchanged. 428 7. Encapsulation and Fragmentation Considerations 430 Maximum transmission unit (MTU) and fragmentation issues for IPv4 in 431 IPv6 tunneling are discussed in detail in Section 7.2 of [RFC2473]. 432 MAP-E's scope is limited to a service provider network. IPv6 Path 433 MTU discovery MAY be used to adjust the MTU of the tunnel as 434 described in Section 7.2 of [RFC2473], or the MAP-E Tunnel MTU might 435 be explicitly configured. 437 The use of an anycast source address could lead to any ICMP error 438 message generated on the path being sent to a different BR. 439 Therefore, using dynamic tunnel MTU Section 7.2 of [RFC2473] is 440 subject to IPv6 Path MTU blackholes. 442 Multiple BRs using the same anycast source address could send 443 fragmented packets to the same MAP-E CE at the same time. If the 444 fragmented packets from different BRs happen to use the same fragment 445 ID, incorrect reassembly might occur. For this reason, a BR using an 446 anycast source address MUST NOT fragment the IPv6 encapsulated packet 447 unless BR's having identical rules are required to use disjoint 448 ranges of fragment ID. 450 If the MTU is well-managed such that the IPv6 MTU on the CE WAN side 451 interface is set so that no fragmentation occurs within the boundary 452 of the SP, then the MAP-E Tunnel MTU should be set to the known IPv6 453 MTU minus the size of the encapsulating IPv6 header (40 bytes). For 454 example, if the IPv6 MTU is known to be 1500 bytes, the MAP-E Tunnel 455 MTU might be set to 1460 bytes. Absent more specific information, 456 the MAP-E Tunnel MTU SHOULD default to 1280 bytes. 458 Alternatively, if BR's having identical rule are required to use 459 disjoint ranges of fragment ID, a BR using an anycast source address 460 SHOULD fragment the IPv6 encapsulated packet correctly. 462 For MAP-E domain traversal, IPv4 packets are encapsulated in IPv6 463 packets whose Next header is set to 4 (i.e. IPv4). If fragmentation 464 of IPv6 packets is needed, it is performed according to [RFC2460]. 465 Absent more specific information, the path MTU of a MAP-E Domain has 466 to be set to 1280 [RFC2460]. 468 In domains where IPv4 addresses are not shared, IPv6 destinations are 469 derived from IPv4 addresses alone. Thus, each IPv4 packet can be 470 encapsulated and decapsulated independently of each other. MAP-E 471 processing is completely stateless. 473 On the other hand, in domains where IPv4 addresses are shared, BR's 474 and CE's can have to encapsulate IPv4 packets whose IPv6 destinations 475 depend on destination ports. Precautions are needed, due to the fact 476 that the destination port of a fragmented datagram is available only 477 in its first fragment. A sufficient precaution consists in 478 reassembling each datagram received in multiple packets, and to treat 479 it as though it would have been received in single packet. This 480 function is such that MAP-E is in this case stateful at the IP layer. 481 (This is common with DS-lite and NAT64/DNS64 which, in addition, are 482 stateful at the transport layer.) At Domain entrance, this ensures 483 that all pieces of all received IPv4 datagrams go to the right IPv6 484 destinations. 486 Another peculiarity of shared IPv4 addresses is that, without 487 precaution, a destination could simultaneously receive from different 488 sources fragmented datagrams that have the same Datagram ID (the 489 Identification field of [RFC0791]. This would disturb the reassembly 490 process. To eliminate this risk, CE MUST rewrite the datagram ID to 491 an unique value among CEs having same shared IPv4 address upon 492 sending the packets over MAP-E tunnel. This value SHOULD be 493 generated locally within the port-range assigned to a given CE. Note 494 that replacing a Datagram ID in an IPv4 header implies an update of 495 its Header-checksum fieald, by adding to it the one's complement 496 difference between the old and the new values. 498 8. Packet Forwarding Considerations 499 8.1. Mesh model 501 Basically, MAP-E should allow the mesh model in order for all CEs to 502 communicate each others directly. If one mapping rules is applied to 503 a given MAP-E domain, all CEs can communicate each others directly. 504 If multiple mapping rules are applied to a given MAP-E domain, or if 505 multiple MAP-E domains are existed, CE can communicate each others 506 directly only if all CEs know all mapping rules. When a CE receives 507 an IPv4 packet from its LAN side, the CE looks up a mapping rule 508 corresponding to an IPv4 destination address in the received IPv4 509 packet. If the corresponding mapping rule is found, CE can 510 communicate to another CE directly based on the mapping rule defined 511 as Forwarding mapping rule (FMR) in 512 [I-D.mdt-softwire-mapping-address-and-port] . If the corresponding 513 mapping rule is not found, CE must forward the packet to a given BR. 515 8.2. Hub & Spoke model 517 In order to allow the mesh topology so that all CEs can communicate 518 each others directly, all CE should know all mapping rules applied to 519 a given MAP-E domain or MAP-E domains. However, if a CE knows only 520 subset of mapping rules applied to a given MAP-E domain or MAP-E 521 domains, a CE can not communicate to some CEs due to the lack of 522 mapping rules. In this case, an IPv4 packet toward to these CEs must 523 be forwarded to a given BR. In order to achieve the hub & spoke mode 524 fully, Forwarding mapping rule (FMR) defined in 525 [I-D.mdt-softwire-mapping-address-and-port] should be disabled. In 526 this case, all CEs do not look up the mapping rules upon receiving an 527 IPv4 packet from its LAN side and then CE must encapsulate the IPv4 528 packet with IPv6 whose destination must be a given BR. 530 9. NAT Considerations 532 NAT44 should be implemented in CPE which has MAP-E CE function. The 533 NAT44 must conform that best current practice documented in 534 [RFC4787], [RFC5508] and [RFC5382]. When there are restricted 535 available port numbers in a given MAP-E CE, the NAT44 must restrict 536 mapping ports within the port-set. 538 10. ICMP Considerations 540 ICMP message should be supported in MAP-E domain. Hence, the NAT44 541 in MAP-E CE must implement the behavior for ICMP message conforming 542 to the best current practice documented in [RFC5508]. 544 If a MAP-E CE receives an ICMP message having ICMP identifier field 545 in ICMP header, NAT44 in the MAP-E CE must rewrite this field to a 546 specific value assigned from the port-set. BR and other CEs must 547 handle this field similar to the port number in tcp/udp header upon 548 receiving the ICMP message with ICMP identifier field. 550 If a MAP-E BR and CE receives an ICMP error message without ICMP 551 identifier field for some errors that is detected inside a IPv6 552 tunnel, a MAP-E BR and CE should replay the ICMP error message to the 553 original source. This behavior should be implemented conforming to 554 the section 8 of [RFC2473]. The MAP-E BR and CE obtain the origianl 555 IPv6 tunnel packet storing in ICMP payload and then decapsulate IPv4 556 packet. Finally the MAP-E BR and CE generate a new ICMP error 557 message from the decapsulated IPv4 packet and then forward it. 559 If a MAP-E BR receives an ICMP error message on its IPv4 interface, 560 the MAP-E BR should replay the ICMP message to an appropriate MAP-E 561 CE. If IPv4 address is not shared, the MAP-E BR generates a CE IPv6 562 address from the IPv4 destination address in the ICMP error message 563 and encapsulates the ICMP message in IPv6. If IPv4 address is 564 shared, the MAP-E BR derives an original IPv4 packet from the ICMP 565 payload and generates a CE IPv6 address from the source address and 566 the source port in the original IPv4 packet. If the MAP-E BR can 567 generate the CE IPv6 address, the MAP-E BR encapsulates the ICMP 568 error message in IPv6 and then forward it to its IPv6 interface. 570 11. Security Considerations 572 Spoofing attacks: With consistency checks between IPv4 and IPv6 573 sources that are performed on IPv4/IPv6 packets 574 received by BR's and CE's (Section 5), MAP-E 575 does not introduce any opportunity for spoofing 576 attack that would not pre-exist in IPv6. 578 Denial-of-service attacks: In MAP-E domains where IPv4 addresses are 579 shared, the fact that IPv4 datagram reassembly 580 may be necessary introduces an opportunity for 581 DOS attacks. This is inherent to address 582 sharing, and is common with other address 583 sharing approaches such as DS-lite and NAT64/ 584 DNS64. The best protection against such 585 attacks is to accelerate IPv6 enablement in 586 both clients and servers so that, where MAP-E 587 is supported, it is less and less used. 589 Routing-loop attacks: This attack may exist in some automatic- 590 tunneling scenarios are documented in 591 [I-D.ietf-v6ops-tunnel-loops]. They cannot 592 exist with MAP-E because each BRs checks that 593 the IPv6 source address of a received IPv6 594 packet is a CE address. 596 Attacks facilitated by restricted port set: From hosts that are not 597 subject to ingress filtering of [RFC2827], some 598 attacks are possible by intervening with faked 599 packets during ongoing transport connections 600 ([RFC4953], [RFC5961], [RFC6056]. The attacks 601 depend on guessing which ports are currently 602 used by target hosts. Using unrestricted port 603 set which mean that are IPv6 is exactly 604 preferable. To avoid this attacks using 605 restricted port set, NAT44 filtering behavior 606 SHOULD be "Address-Dependent Filtering". 608 12. IANA Consideration 610 This document makes no request of IANA. 612 13. Acknowledgements 614 This draft is based on original idea described in 615 [I-D.despres-softwire-sam]. The authors would like to thank Remi 616 Despres, Mark Townsley, Wojciech Dec and Olivier Vautrin. 618 14. References 620 14.1. Normative References 622 [I-D.mdt-softwire-map-dhcp-option] 623 Mrugalski, T., Boucadair, M., Troan, O., Deng, X., and C. 624 Bao, "DHCPv6 Options for Mapping of Address and Port", 625 draft-mdt-softwire-map-dhcp-option-01 (work in progress), 626 October 2011. 628 [I-D.mdt-softwire-mapping-address-and-port] 629 Troan, O., "Mapping of Address and Port (MAP)", 630 draft-mdt-softwire-mapping-address-and-port-01 (work in 631 progress), October 2011. 633 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 634 September 1981. 636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, March 1997. 639 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 640 (IPv6) Specification", RFC 2460, December 1998. 642 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 643 over Non-Broadcast Multiple Access (NBMA) networks", 644 RFC 2491, January 1999. 646 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 647 and M. Carney, "Dynamic Host Configuration Protocol for 648 IPv6 (DHCPv6)", RFC 3315, July 2003. 650 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 651 Architecture", RFC 4291, February 2006. 653 14.2. Informative References 655 [I-D.despres-softwire-sam] 656 Despres, R., "Stateless Address Mapping (SAM) - a 657 Simplified Mesh-Softwire Model", 658 draft-despres-softwire-sam-01 (work in progress), 659 July 2010. 661 [I-D.ietf-softwire-dual-stack-lite] 662 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 663 Stack Lite Broadband Deployments Following IPv4 664 Exhaustion", draft-ietf-softwire-dual-stack-lite-11 (work 665 in progress), May 2011. 667 [I-D.ietf-v6ops-tunnel-loops] 668 Nakibly, G. and F. Templin, "Routing Loop Attack using 669 IPv6 Automatic Tunnels: Problem Statement and Proposed 670 Mitigations", draft-ietf-v6ops-tunnel-loops-07 (work in 671 progress), May 2011. 673 [I-D.operators-softwire-stateless-4v6-motivation] 674 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 675 Borges, I., and G. Chen, "Motivations for Stateless IPv4 676 over IPv6 Migration Solutions", 677 draft-operators-softwire-stateless-4v6-motivation-02 (work 678 in progress), June 2011. 680 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 681 IPv6 Specification", RFC 2473, December 1998. 683 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 684 Defeating Denial of Service Attacks which employ IP Source 685 Address Spoofing", BCP 38, RFC 2827, May 2000. 687 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 688 Address Translator (Traditional NAT)", RFC 3022, 689 January 2001. 691 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 692 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 693 RFC 4787, January 2007. 695 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 696 RFC 4953, July 2007. 698 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 699 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 700 RFC 5382, October 2008. 702 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 703 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 704 April 2009. 706 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 707 Robustness to Blind In-Window Attacks", RFC 5961, 708 August 2010. 710 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 711 Infrastructures (6rd) -- Protocol Specification", 712 RFC 5969, August 2010. 714 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 715 Protocol Port Randomization", BCP 156, RFC 6056, 716 January 2011. 718 Authors' Addresses 720 Tetsuya Murakami (editor) 721 IP Infusion 722 1188 East Arques Avenue 723 Sunnyvale 724 USA 726 Email: tetsuya@ipinfusion.com 727 Ole Troan 728 cisco 729 Oslo 730 Norway 732 Email: ot@cisco.com 734 Satoru Matsushima 735 SoftBank 736 1-9-1 Higashi-Shinbashi, Munato-ku 737 Tokyo 738 Japan 740 Email: satoru.matsushima@tm.softbank.co.jp