idnits 2.17.1 draft-mdt-softwire-map-translation-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 10, 2012) is 4490 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-03) exists of draft-mdt-softwire-mapping-address-and-port-02 ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-03) exists of draft-mdt-softwire-map-dhcp-option-00 == Outdated reference: A later version (-08) exists of draft-xli-behave-divi-04 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Bao 3 Internet-Draft X. Li 4 Intended status: Standards Track Y. Zhai 5 Expires: July 13, 2012 CERNET Center/Tsinghua 6 University 7 T. Murakami, Ed. 8 IP Infusion 9 W. Dec, Ed. 10 Cisco Systems 11 January 10, 2012 13 MAP Translation (MAP-T) - specification 14 draft-mdt-softwire-map-translation-00 16 Abstract 18 This document specifies the "Mapping of Address and Port" (MAP) 19 double stateless translation based solution (MAP-T) for providing 20 IPv4 hosts connectivity to and across an IPv6 domain. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 13, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Extended Contributors List . . . . . . . . . . . . . . . . . . 3 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 59 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5. MAP-T Translation Framework . . . . . . . . . . . . . . . . . 6 61 6. MAP-T Node Behavior . . . . . . . . . . . . . . . . . . . . . 8 62 6.1. Provisioning of MAP-T CE . . . . . . . . . . . . . . . . . 8 63 6.2. Packet Forwarding Behavior of MAP-T CE . . . . . . . . . . 9 64 6.2.1. IPv4 to IPv6 . . . . . . . . . . . . . . . . . . . . . 9 65 6.2.2. IPv6 to IPv4 . . . . . . . . . . . . . . . . . . . . . 9 66 6.3. Provisioning of MAP-T BR . . . . . . . . . . . . . . . . . 9 67 6.4. Packet Forwarding Behavior on MAP-T BR . . . . . . . . . . 10 68 6.4.1. IPv6 to IPv4 . . . . . . . . . . . . . . . . . . . . . 10 69 6.4.2. IPv4 to IPv6 . . . . . . . . . . . . . . . . . . . . . 11 70 7. P-T IPv4/IPv6 Translation Specifications . . . . . . . . . . . 11 71 7.1. Address Formats . . . . . . . . . . . . . . . . . . . . . 11 72 7.2. Translating IPv4 Address and Port Number into IPv6 73 Address and Port Number at the BR . . . . . . . . . . . . 12 74 7.3. Translating IPv6 Address and Port Number into IPv4 75 Address and Port Number at the BR . . . . . . . . . . . . 12 76 7.4. Translating IPv4 Address and Port Number into IPv6 77 Address and Port Number at the CE . . . . . . . . . . . . 12 78 7.5. Translating IPv6 Address and Port Number into IPv4 79 Address and Port Number at the CE . . . . . . . . . . . . 13 80 7.6. Translating ICMP/ICMPv6 Headers . . . . . . . . . . . . . 13 81 7.7. Path MTU Discovery and Fragmentation . . . . . . . . . . . 14 82 8. MAP-T Packet Forwarding considerations . . . . . . . . . . . . 15 83 8.1. Mesh Model . . . . . . . . . . . . . . . . . . . . . . . . 15 84 8.2. Hub & Spoke model . . . . . . . . . . . . . . . . . . . . 15 85 8.3. Communication with IPv6 servers in the MAP-T domain . . . 15 86 9. NAT44 considerations . . . . . . . . . . . . . . . . . . . . . 15 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 88 11. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16 89 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 90 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 13.1. Normative References . . . . . . . . . . . . . . . . . . . 17 92 13.2. Informative References . . . . . . . . . . . . . . . . . . 17 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 95 1. Extended Contributors List 97 This document is the result of the IETF Softwire MAP design team 98 joint effort and numerous previous individual contributions in this 99 area initiated by dIVI [I-D.xli-behave-divi] and with a similar idea 100 proposed by [I-D.murakami-softwire-4v6-translation]. The following 101 are authors who contributed to the effort: 103 Chongfeng Xie (China Telecom) 105 Room 708, No.118, Xizhimennei Street Beijing 100035 CN 107 Phone: +86-10-58552116 109 Email: xiechf@ctbri.com.cn 111 Qiong Sun (China Telecom) 113 Room 708, No.118, Xizhimennei Street Beijing 100035 CN 115 Phone: +86-10-58552936 117 Email: sunqiong@ctbri.com.cn 119 Satoru Matsushima (Softbank Telecom) 121 1-9-1 Higashi-Shinbashi, Munato-ku, Tokyo, Japan 123 Email: satoru.matsushima@tm.softbank.co.jp 125 Gang Chen (China Mobile) 127 53A,Xibianmennei Ave. Beijing 100053 P.R.China 129 Email: chengang@chinamobile.com 131 Wentao Shang (CERNET Center/Tsinghua University) 133 Room 225, Main Building, Tsinghua University Beijing 100084 CN 134 Email: wentaoshang@gmail.com 136 Guoliang Han (CERNET Center/Tsinghua University) 138 Room 225, Main Building, Tsinghua University Beijing 100084 CN 140 Email: bupthgl@gmail.com 142 Rajiv Asati (Cisco Systems) 144 7025-6 Kit Creek Road Research Triangle Park NC 27709 USA 146 Email: rajiva@cisco.com 148 2. Introduction 150 Experiences from several years of IPv6 deployment [RFC6219] indicates 151 that transitioning a service providers' domain fully to IPv6-only 152 requires not only the continued support of legacy IPv4 communication 153 across that domain, but also the need for an ultimate IPv4 exit 154 strategy allowing communication between IPv4 and IPv6 address 155 families in that domain. The use of an IPv4/IPv6 translation based 156 solution is an optimal way to address these requirements, 157 particularly in combination with stateless translation techniques 158 that seek to minimize complexities as described in 159 [I-D.operators-softwire-stateless-4v6-motivation]. The double Pv4/ 160 IPv6 translation based solution, MAP-T, is such a solution, and one 161 that builds on existing stateless IPv4/IPv6 address translation 162 techniques specified in [RFC6052], [RFC6144], and [RFC6145], by: 164 o Extending stateless IPv4/IPv6 translation with algorithmic address 165 and port mapping rules as defined in MAP MAP 166 [I-D.mdt-softwire-mapping-address-and-port]. 168 o Introducing the notion of stateless double IPv4/IPv6 translation 169 that can restore the original IPv4 address. 171 o Allowing IPv4-translatable addresses to be either fully or 172 partially encoded in IPv6 prefixes (or addresses) assigned to 173 customers. 175 The MAP-T solution presents an operator with the prospect of a full 176 transition of a domain to IPv6-only, in a manner that: 178 o Retains the ability for IPv4 end hosts to communicate across the 179 IPv6 domain with other IPv4 hosts. 181 o Permits both individual IPv4 address assignment as well as IPv4 182 address sharing with predefined port range to be enacted using 183 IPv6. 185 o Allows communication between IPv4-only, as well as any IPv6 186 enabled end hosts, to native IPv6-only servers in the domain that 187 are using IPv4-mapped IPv6 address. 189 o Does not require the operation of an IPv4 overlay network, nor the 190 introduction of non native-IPv6 network device or server 191 functionality. 193 o Allows the use of IPv6 native network operations, including the 194 ability to classify IP traffic, as well as to perform IP traffic 195 routing optimization policies, e.g. routing optimization based on 196 peering policies for Internet IPv4 destinations outside of the 197 domain. 199 3. Requirements Language 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 203 document are to be interpreted as described in RFC 2119 [RFC2119]. 205 4. Terminology 207 MAP-T: Mapping of Address and Port - Translation mode. 208 MAP-T utilizes IPv4/IP6 translation as per 209 [RFC6145] along with the MAP extensions for 210 mapping between IPv4 and IPv6 defined in MAP 211 [I-D.mdt-softwire-mapping-address-and-port] and 212 this draft. 214 MAP-T domain (Domain): A set of MAP-T CEs and BRs,. A service 215 provider may deploy MAP-T with a single MAP-T 216 domain, or may utilize multiple MAP-T domains. 217 Each domain requires a separate MAP-T rule set. 219 MAP-T Border Relay (BR): A MAP-T enabled router/translator at the 220 edge of a MAP-T domain, providing connectivity 221 to the MAP-T domain. A Border Relay router has 222 at least an IPv6- enabled interface and an IPv4 223 interface connected to the native IPv4 network, 224 and it can serve multiple MAP-T domains. 226 MAP-T Customer Edge (CE): A router/translator node functioning as a 227 Customer Edge Router/translator in a MAP-T 228 domain. This type of device is sometimes 229 referred to as a "Residential Gateway" (RG) or 230 "Customer Premises Equipment" (CPE). A typical 231 MAP-T CE adopting MAP rules will serve a 232 residential site with one WAN side interface, 233 one or more LAN side interfaces. A MAP-T CE 234 may also be referred to simply as a "CE" within 235 the context of MAP-T. 237 Shared IPv4 address: An IPv4 address that is shared among multiple 238 MAP CE nodes. Each node has a separate part of 239 the transport layer port space. 241 MAP-T Rule: A MAP rule defining the mapping relationship 242 for a given MAP-T domain between IPv4 and IPv6, 243 defined in MAP 244 [I-D.mdt-softwire-mapping-address-and-port] 246 5. MAP-T Translation Framework 248 Figure 1 depicts the overall MAP-T architecture with IPv4 users (N 249 and M) networks connected to a routed IPv6 network. 251 User N 252 Private IPv4 253 | Network 254 | 255 O--+---------------O 256 | | MAP-T CE | 257 | +-----+--------+ | 258 | NAPT44| MAP-T | `-. 259 | +-----+ | | -._ ,-------. .------. 260 | +--------+ | ,-' `-. ,-' `-. 261 O------------------O / \ O---------O / Public \ 262 / IPv6 only \ | MAP-T |/ IPv4 \ 263 ( Network --+ Border +- Network ) 264 \ (MAP-T Domain)/ | Relay |\ / 265 O------------------O \ / O---------O \ / 266 | MAP-T CE | ;". ,-' `-. ,-' 267 | +-----+--------+ | ," `----+--' ------' 268 | NAPT44| MAP-T | | ," | 269 | +-----+ | | IPv6 Server(s) 270 | | +--------+ | (v4 mapped 271 O---.--------------O address) 272 | 273 User M 274 Private IPv4 275 Network 277 Figure 1: Network Topology 279 Figure 1: Network Topology 281 The MAP-T solution relies on IPv4/IPv6 translating components, the 282 MAP-T CE and MAP-T BR, connected to a MAP-T domain. The MAP-T CE is 283 responsible for connecting a users' private IPv4, along with any 284 native IPv6 network to the IPv6-only MAP-T domain. To multiplex 285 multiple IPv4 user hosts, the CE relies on regular NAT44 286 functionality, which is however configured based on MAP-T settings. 287 The CE's stateless IPv4/IPv6 translation function [RFC6145], again 288 configured to operate based on MAP-T settings, completes the model of 289 the CE defined in Figure 1. The CE's MAP-T domain facing interface 290 is configured with a regular operator assigned IPv6 prefix that can 291 be the same as that used to address any native IPv6 (non MAP-T) user 292 network devices i.e. MAP-T does not require more than one IPv6 293 prefix per user network, and supports regular IPv6 prefix or address 294 assignment mechanism including SLAAC and DHCPv6 stateful. 296 The MAP-T BR is responsible for connecting external IPv4 networks to 297 all devices in one or more MAP-T domains, using stateless IPv4/IPv6 298 translation [RFC6145]extended by the MAP-T rules as per this 299 document. Besides the CE and BR, the MAP-T domain can contain any 300 regular IPv6-only hosts/servers that have an IPv4 mapped IPv6 address 301 (IPv4-translatable address per [RFC6052]) using a prefix assigned to 302 the MAP-T domain. Communication with such devices is naturally 303 possible using native IPv6 means from inside or outside the domain as 304 well as from any IPv4-only hosts inside or outside of the MAP-T 305 domain. 307 The IPv4 in IPv6 address mapping scheme employed by the MAP-T 308 solution, along with the avoidance of using any additional 309 encapsulating headers allows the MAP-T domain to be operated using 310 regular native IPv6 functionality. This includes also the ability to 311 classify traffic based on specific source and destination addresses 312 (including any IPv4 in IPv6 mapped source and destinations), and 313 higher layer packet payload. Similarly, the address mapping 314 characteristic allows IPv6 traffic forwarding in the MAP-T domain to 315 be optimized in line with an operators' policies, e.g. native IPv6 316 routing selection of MAP-T domain egress points based on peering 317 policies bound to IPv4 destination. IP Traffic between CEs in any 318 MAP-T can flow either in hub & spoke modes, with a BR acting as the 319 spoke, or in mesh mode directly between the CEs. 321 6. MAP-T Node Behavior 323 6.1. Provisioning of MAP-T CE 325 A MAP-T CE requires the following parameters for provisioning: 327 o The MAP Domain IPv4 and IPv6 prefix, and their lengths (Basic 328 Mapping Rule) 330 o The MAP EA-bits (CE index), including IPv4 suffix, length and any 331 port-range (including any excluded ports and the port number 332 continuity parameter) 334 o The BR prefix and its length (Default Mapping Rule) 336 A MAP-T CE that receives a MAP DHCP option 337 [I-D.mdt-softwire-map-dhcp-option] for BMR, FMR and DMR and performs 338 the following (MAP initialization) functions: 340 o Configures the NAT44 port-range mapping function parameters (BMR) 342 o Configures the IPv4/IPv6 stateless translation parameters (BMR, FMR 343 and DMR) 345 Based on the above configuration, the IPv4/IPv6 translation functions 346 can be performed by the CE. 348 o Derive IPv4 address along with any applicable port-range from IPv4- 349 translatable address (BMR) 351 o Derive IPv4-translatable address from IPv4 address (BMR) 353 o Derive IPv4-converted address from IPv4 address (FMR and DMR) 355 o Derive IPv4 address from IPv4-converted address (FMR and DMR) 357 6.2. Packet Forwarding Behavior of MAP-T CE 359 6.2.1. IPv4 to IPv6 361 A MAP-T CE receiving IPv4 packets SHOULD perform NAT44 function first 362 and create appropriate NAT44 stateful bindings. The resulting IPv4 363 packets MUST contain the source IPv4 address and source transport 364 number defined by MAP-T. The resulting IPv4 packet is forwarded to 365 the CE's MAP-T function that performs IPv4 to IPv6 stateless 366 translation. The IPv6 source and destination addresses MUST then be 367 derived as per Section 6 of this draft, and the IPv4 header MUST be 368 replaced with an IPv6 header following [RFC6145]. 370 6.2.2. IPv6 to IPv4 372 A MAP-T CE receiving an IPv6 packet performs its regular IPv6 373 operations, whereby only packets that are addressed to the MAP-T CE's 374 MAP derived BMR address are forwarded to the CE's MAP-T function. 375 All other IPv6 traffic is forwarded as per the CE's IPv6 routing 376 rules. The CE SHOULD check that MAP-T received packets' transport- 377 layer destination port number is in the range configured by MAP for 378 the CE and the CE SHOULD drop any non conforming packet and respond 379 with an ICMPv6 "Address Unreachable" (Type 1, Code 3). In other 380 cases, the MAP-T function MUST derive the IPv4 source and destination 381 addresses as per Section 6 of this draft and MUST replace the IPv6 382 header with an IPv4 header in accordance with [RFC6052]. The 383 resulting IPv4 packet is then forwarded to the CE's NAT44 function 384 where the destination port number MUST be checked against the 385 stateful port mapping session table and the destination port number 386 MUST be mapped to its original value. 388 6.3. Provisioning of MAP-T BR 390 The MAP-T BR needs to be provisioned with information for the MAP-T 391 domain or domains it is expected to handle, along with any necessary 392 routing processes. For each MAP-T domain, the BR will have the 393 following parameters: 395 o The MAP Domain IPv4 and IPv6 prefix, and their lengths (Basic 396 Mapping Rule) 398 o The MAP EA-bits (CE index), including IPv4 suffix, length and any 399 port-range (including any excluded ports and the port number 400 continuity parameter) 402 o The BR prefix and its length (Default Mapping Rule) 404 A BR when configured for BMR, FMR and DMR, and performs the following 405 functions: 407 o Configures the IPv4/IPv6 stateless translation parameters (BMR, FMR 408 and DMR) 410 Based on the above configuration, the IPv4/IPv6 translation function 411 can be performed by the BR. 413 o Derive IPv4 address along with any applicable port-range from IPv4- 414 translatable address (BMR) 416 o Derive IPv4-translatable address from IPv4 address (BMR) 418 o Derive IPv4-converted address from IPv4 address (FMR and DMR) 420 o Derive IPv4 address from IPv4-converted address (FMR and DMR) 422 6.4. Packet Forwarding Behavior on MAP-T BR 424 6.4.1. IPv6 to IPv4 426 A MAP-T BR receiving IPv6 packets selects a best matching MAP-T 427 domain rule based on a longest address match of the packets' source 428 address against the BR's configured MAP-T BMR prefix(es), as well as 429 a match of the packet destination address against the configured BR 430 prefixes or FMR prefix(es). The selected MAP rule allows the BR to 431 determine the CE-index from the source IPv6 address. The BR MUST 432 perform a validation of the consistency of the source IPv6 address 433 and source port number for the packet using BMR. If the packets 434 source port number is found to be outside the range allowed for this 435 CE-index and the BMR, the BR MUST drop the packet and respond with an 436 ICMPv6 "Destination Unreachable, Source address failed ingress/egress 437 policy" (Type 1, Code 5). 439 For packets that are to be forwarded outside of a MAP-T domain, the 440 BR MUST derive the source and destination IPv4 addresses as per 441 Section 6 of this draft and translate the IPv6 to IPv4 headers 442 following [RFC6145]. The resulting IPv4 packets are then passed to 443 regular IPv4 forwarding. 445 6.4.2. IPv4 to IPv6 447 A MAP-T BR receiving IPv4 packets uses a longest match IPv4 lookup to 448 select the target MAP-T domain and rule. The BR MUST then derive the 449 IPv6 source and destination addresses from the IPv4 source and 450 destination address and port as per Section 6 of this draft. 451 Following this, the BR MUST translate the IPv4 to IPv6 headers 452 following [RFC6145]. The resulting IPv6 packets are then passed to 453 regular IPv6 forwarding. 455 Note that the operation of a BR when forwarding to MAP-T domains that 456 do not utilize IPv4 address sharing, is the same as stateless IPv4/ 457 IPv6 translation [RFC6145]. 459 7. P-T IPv4/IPv6 Translation Specifications 461 7.1. Address Formats 463 The (mapped) CE address format used is shown in Figure 2 format and 464 is as defined in MAP [I-D.mdt-softwire-mapping-address-and-port]. It 465 is used in both BMR and FMR operation 467 <-------------- 64 ------------>< 8 ><----- L>=32 ------><--56-L--> 468 +-----------+--------+---------+----+--------------+----+---------+ 469 |IPv6 prefix|EA bits |Subnet-id| u | IPv4 address |PSID| 0 | 470 +-----------+--------+---------+----+--------------+----+---------+ 472 Figure 2: IPv4-translatable address for BMR and FMR 474 The address format used by the MAP-T Default Mapping Rule (DMR, IPv4 475 converted address) is specific to MAP-T and is as shown in the Figure 476 3. 478 <---------- 64 ------------>< 8 ><----- 32 -----><--- 24 ---> 479 +--------------------------+----+---------------+-----------+ 480 | BR prefix | u | IPv4 address | 0 | 481 +--------------------------+----+---------------+-----------+ 483 Figure 3: IPv4-converted address for DMR 485 In both cases the "u" octet is taken to be 0x00. 487 7.2. Translating IPv4 Address and Port Number into IPv6 Address and 488 Port Number at the BR 490 IPv6 Source Address and Source Port Number: 492 At the BR, the IPv6 source address (IPv4-converted address) MUST be 493 derived from the IPv4 source Address as per DMR MAP 494 [I-D.mdt-softwire-mapping-address-and-port]. The source Layer 4 port 495 number MUST be unchanged. 497 IPv6 Destination Address and Destination Port Number: 499 At the BR, the IPv6 destination address (IPv4-translatable address) 500 MUST be derived from the IPv4 destination address and the destination 501 port number as per FMR MAP 502 [I-D.mdt-softwire-mapping-address-and-port]. The destination port 503 number MUST be unchanged. 505 7.3. Translating IPv6 Address and Port Number into IPv4 Address and 506 Port Number at the BR 508 IPv4 Source Address and Source Port Number: 510 At the BR, the IPv4 source address MUST be derived from the IPv6 511 source address (IPv4-translatable address) as per BMR MAP 512 [I-D.mdt-softwire-mapping-address-and-port]. The source port number 513 MUST be unchanged. 515 IPv4 Destination Address and Destination Port Number: 517 At the BR, the IPv4 destination address MUST be derived from the IPv6 518 destination address (IPv4-converted address) as per DBR MAP 519 [I-D.mdt-softwire-mapping-address-and-port]. The destination port 520 number MUST be unchanged. 522 7.4. Translating IPv4 Address and Port Number into IPv6 Address and 523 Port Number at the CE 525 IPv6 Source Address and Source Port Number: 527 At the CE, the IPv6 source address (IPv4-translatable address) MUST 528 be derived from the IPv4 source address as per BMR MAP 529 [I-D.mdt-softwire-mapping-address-and-port]. The source port number 530 MUST be unchanged. 532 IPv6 Destination Address and Destination Port Number: 534 At the CE, if Forwarding Mapping Rules (FMRs) are enabled, the IPv4 535 packet MUST be checked to see if the IPv4 destination address matches 536 the FMR. If matching, the IPv6 destination address (IPv4-converted 537 address) MUST be derived from the IPv4 destination address and the 538 destination port number per FMR. Otherwise, the IPv6 destination 539 address (IPv4-converted address) MUST be derived from the received 540 IPv4 destination address per DMR MAP 541 [I-D.mdt-softwire-mapping-address-and-port]. The destination port 542 number MUST be unchanged. 544 7.5. Translating IPv6 Address and Port Number into IPv4 Address and 545 Port Number at the CE 547 IPv4 Source Address and Source Port Number: 549 At the CE, the IPv4 source address MUST be derived from the IPv6 550 source address (IPv6-converted address) as per FMR or DMR MAP 551 [I-D.mdt-softwire-mapping-address-and-port]. The source port number 552 MUST be unchanged. 554 IPv4 Destination Address and Destination Port Number: At the CE, the 555 IPv4 destination address MUST be derived from the IPv6 destination 556 address (IPv6-translatable address) as per BMR MAP 557 [I-D.mdt-softwire-mapping-address-and-port]. The source port number 558 MUST be unchanged. 560 7.6. Translating ICMP/ICMPv6 Headers 562 MAP-T CEs and BRs MUST follow ICMP/ICMPv6 translation as per 563 [RFC6145], with the following extension to cover the address sharing/ 564 port-range feature. 566 Unlike TCP and UDP, which each provide two port fields to represent 567 both source and destination, the ICMP/ICMPv6 Query message header has 568 only one ID field [RFC0792], [RFC4443]. Thus, if the ICMP Query 569 message is originated from an IPv4 host behind a MAP-T CE, the ICMP 570 ID field SHOULD be used to exclusively identify that IPv4 host. This 571 means that the MAP-T CE SHOULD rewrite the ID field to a port-set 572 value obtained via the BMR MAP 573 [I-D.mdt-softwire-mapping-address-and-port] during the IPv4 to IPv6 574 translation per [RFC6145]. The BR will translate the ICMPv6 packets 575 back to ICMP per [RFC6145]. When MAP-T BR receives an ICMP packet 576 containing an ID field which is bound for a shared address in the 577 MAP-T domain, the MAP-T BR SHOULD use the ID value as a substitute 578 for the destination port in determining the IPv6 destination address 579 according to Section 5.1 and per [RFC6145]. In all other cases, the 580 MAP-T BR MUST derive the destination IPv6 address by simply mapping 581 the destination IPv4 address without additional port info per 582 [RFC6145]. The corresponding CE will translate the ICMPv6 packets 583 back to ICMP per [RFC6145]. 585 7.7. Path MTU Discovery and Fragmentation 587 Due to the different sizes of the IPv4 and IPv6 header, which are 20+ 588 octets and 40 octets respectively, handling the maximum packet size 589 is relevant for the operation of any system connecting the two 590 address families. There are three mechanisms to handle this issue: 591 path MTU discovery (PMTUD), fragmentation, and transport-layer 592 negotiation such as the TCP Maximum Segment Size (MSS) option 593 [RFC0897]. MAP-T uses all three mechanisms to deal with different 594 cases. 596 Following [RFC6145], when an IPv4 node performs path MTU discovery 597 (by setting the Don't Fragment (DF) bit in the header), path MTU 598 discovery can operate end-to-end across the MAP-T BR and CE 599 translators. In this case, either IPv4 or IPv6 routers (including 600 the translators) can send back ICMP Packet Too Big messages to the 601 sender. When IPv6 routers send these as ICMPv6 errors, these packets 602 following [RFC6145] will pass through the translator and will result 603 in an appropriate ICMP error sent to the IPv4 sender. When the IPv4 604 sender does not set the DF bit, the translator MUST ensure that the 605 packet does not exceed the path MTU on the IPv6 side. This is done, 606 if necessary, by fragmenting the IPv4 packet and including with 607 Fragment Headers to fit in the minimum MTU 1280-byte IPv6 packets. 608 When the IPv4 sender does not set the DF bit, the translator SHOULD 609 always include an IPv6 Fragment Header to indicate that the sender 610 allows fragmentation. The rules defined in [RFC6145] ensure that 611 when packets are fragmented, either by the sender or by IPv4 routers, 612 the low-order 16 bits of the fragment identification are carried end- 613 to-end, ensuring that packets are correctly reassembled. The above 614 mechanism ensures that the Don't Fragment (DF) bit in the IPv4 header 615 can be carried end-to-end via double stateless translation in most of 616 the cases. For example, the IPv4 packets with DF=1 will be 617 translated to IPv6 packets without fragmentation header and will be 618 translated back to IPv4 packets with DF=1. The IPv4 packets with 619 DF=0 will be translated to IPv6 packets with fragmentation header 620 (keeping the ID value) and will be translated back to IPv4 packets 621 with DF=0. A corner case is for IPv4 packets with DF=1 and MF=1. In 622 this case, IPv4 packets with DF=1 and MF=1 will be translated to IPv6 623 packets with a fragmentation header which will see them translated 624 back to IPv4 packets with DF=0. Experimental evidence [operational- 625 exp] indicates that IPv4 packets with DF=1 and MF=1 are rare in 626 production networks (10e-5) and that their handling by MAP-T devices 627 causes no negative effects in practice. 629 8. MAP-T Packet Forwarding considerations 631 8.1. Mesh Model 633 MAP-T allows the use of the mesh model in order for all CEs to 634 communicate with each other directly (i.e bypassing the BR). When a 635 CE receives an IPv4 packet from its LAN side, the CE looks up a 636 mapping rule corresponding to an IPv4 destination address in the 637 received IPv4 packet. If the corresponding mapping rule is found, CE 638 can communicate to another CE directly based on the mapping rule 639 defined as Forwarding mapping rule (FMR) in MAP MAP 640 [I-D.mdt-softwire-mapping-address-and-port]. If the corresponding 641 mapping rule is not found, CE must forward the packet to a given BR. 643 8.2. Hub & Spoke model 645 In order to allow the mesh topology so that all CEs can communicate 646 each others directly, all CE should know all mapping rules applied to 647 a given MAP-T domain or MAP-T domains. However, if a CE knows only a 648 subset of the mapping rules applied to a given MAP-T domain, a CE can 649 not communicate directly with some of the CEs in that domain due to 650 the lack of mapping rules. In this case, an IPv4 packet toward to 651 these CEs must be forwarded to a given BR. In order to achieve the 652 hub & spoke mode fully, the Forwarding mapping rule (FMR) defined in 653 MAP MAP [I-D.mdt-softwire-mapping-address-and-port] need to be 654 disabled (not defined). 656 8.3. Communication with IPv6 servers in the MAP-T domain 658 MAP-T allows communication between both IPv4-only and any IPv6 659 enabled end hosts, with native IPv6-only servers which are using 660 IPv4-mapped IPv6 address based on DMR in the MAP-T domain. In this 661 mode, the IPv6-only servers SHOULD have both A and AAAA records in 662 the authorities DNS server [RFC6219]. DNS64 [RFC6147] become 663 required only when IPv6 servers in the MAP-T domain are expected 664 themselves to initiate communication to external IPv4-only hosts. 666 9. NAT44 considerations 668 The NAT44 implemented in MAP-T CE SHOULD conform with the behavior 669 and best current practice documented in [RFC4787], [RFC5508] and 670 [RFC5382]. In MAP-T address sharing mode (determined by the MAP-T 671 configuration parameters) the operation of the NAT44 must be 672 restricted to the available port numbers derived via BMR MAP 673 [I-D.mdt-softwire-mapping-address-and-port] 675 10. Security Considerations 677 Spoofing attacks: With consistency checks between IPv4 and IPv6 678 sources that are performed on IPv4/IPv6 packets received by BR's 679 and CE's (Section 6), MAP-T does not introduce any opportunity for 680 spoofing attack that would not pre-exist in IPv6. 682 Denial-of-service attacks: In MAP-T domains where IPv4 addresses are 683 shared, the fact that IPv4 datagram reassembly may be necessary 684 introduces an opportunity for DOS attacks. This is inherent to 685 address sharing, and is common with other address sharing 686 approaches such as DS-Lite and NAT64/ DNS64. The best protection 687 against such attacks is to accelerate IPv6 enablement in both 688 clients and servers so that, where MAP-T is supported, it is less 689 and less used. 691 Routing-loop attacks: This attack may exist in some automatic- 692 tunneling scenarios are documented in 693 [I-D.ietf-v6ops-tunnel-loops]. They cannot exist with MAP-T 694 because each BRs checks that the IPv6 source address of a received 695 IPv6 packet is a CE address based on Forwarding Mapping Rule 696 defined in MAP [I-D.mdt-softwire-mapping-address-and-port]. 698 Attacks facilitated by restricted port set: From hosts that are not 699 subject to ingress filtering of [RFC2827], some attacks are 700 possible by intervening with faked packets during ongoing 701 transport connections ([RFC4953], [RFC5961], [RFC6056]. The 702 attacks depend on guessing which ports are currently used by 703 target hosts, and using an unrestricted port set is preferable, 704 i.e. using native IPv6 connections that are not subject to MAP 705 port range restrictions. To minimize this type of attacks when 706 using a restricted port set, the MAP CE's NAT44 filtering behavior 707 SHOULD be "Address-Dependent Filtering". Furthermore, the MAP CEs 708 SHOULD use a DNS transport proxy function to handle DNS traffic, 709 and source such traffic from IPv6 interfaces not assigned to 710 MAP-T. Practicalities of these methods are discussed in Section 711 5.9 of [I-D.dec-stateless-4v6]. 713 11. IANA Consideration 715 This document has no IANA actions. 717 12. Acknowledgements 719 13. References 720 13.1. Normative References 722 [I-D.mdt-softwire-mapping-address-and-port] 723 Troan, O., "Mapping of Address and Port (MAP)", 724 draft-mdt-softwire-mapping-address-and-port-02 (work in 725 progress), November 2011. 727 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 728 Requirement Levels", BCP 14, RFC 2119, March 1997. 730 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 731 Algorithm", RFC 6145, April 2011. 733 13.2. Informative References 735 [I-D.dec-stateless-4v6] 736 Dec, W., Asati, R., Bao, C., Deng, H., and M. Boucadair, 737 "Stateless 4Via6 Address Sharing", 738 draft-dec-stateless-4v6-04 (work in progress), 739 October 2011. 741 [I-D.ietf-v6ops-tunnel-loops] 742 Nakibly, G. and F. Templin, "Routing Loop Attack using 743 IPv6 Automatic Tunnels: Problem Statement and Proposed 744 Mitigations", draft-ietf-v6ops-tunnel-loops-07 (work in 745 progress), May 2011. 747 [I-D.mdt-softwire-map-dhcp-option] 748 Mrugalski, T., Boucadair, M., and O. Troan, "DHCPv6 749 Options for Mapping of Address and Port", 750 draft-mdt-softwire-map-dhcp-option-00 (work in progress), 751 October 2011. 753 [I-D.murakami-softwire-4v6-translation] 754 Murakami, T., Chen, G., Deng, H., Dec, W., and S. 755 Matsushima, "4via6 Stateless Translation", 756 draft-murakami-softwire-4v6-translation-00 (work in 757 progress), July 2011. 759 [I-D.operators-softwire-stateless-4v6-motivation] 760 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 761 Borges, I., and G. Chen, "Motivations for Stateless IPv4 762 over IPv6 Migration Solutions", 763 draft-operators-softwire-stateless-4v6-motivation-02 (work 764 in progress), June 2011. 766 [I-D.xli-behave-divi] 767 Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual- 768 Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-04 769 (work in progress), October 2011. 771 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 772 RFC 792, September 1981. 774 [RFC0897] Postel, J., "Domain name system implementation schedule", 775 RFC 897, February 1984. 777 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 778 Defeating Denial of Service Attacks which employ IP Source 779 Address Spoofing", BCP 38, RFC 2827, May 2000. 781 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 782 Message Protocol (ICMPv6) for the Internet Protocol 783 Version 6 (IPv6) Specification", RFC 4443, March 2006. 785 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 786 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 787 RFC 4787, January 2007. 789 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 790 RFC 4953, July 2007. 792 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 793 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 794 RFC 5382, October 2008. 796 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 797 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 798 April 2009. 800 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 801 Robustness to Blind In-Window Attacks", RFC 5961, 802 August 2010. 804 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 805 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 806 October 2010. 808 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 809 Protocol Port Randomization", BCP 156, RFC 6056, 810 January 2011. 812 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 813 IPv4/IPv6 Translation", RFC 6144, April 2011. 815 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 816 Beijnum, "DNS64: DNS Extensions for Network Address 817 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 818 April 2011. 820 [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 821 China Education and Research Network (CERNET) IVI 822 Translation Design and Deployment for the IPv4/IPv6 823 Coexistence and Transition", RFC 6219, May 2011. 825 Authors' Addresses 827 Congxiao Bao 828 CERNET Center/Tsinghua University 829 Room 225, Main Building, Tsinghua University 830 Beijing 100084 831 CN 833 Email: congxiao@cernet.edu.cn 835 Xing Li 836 CERNET Center/Tsinghua University 837 Room 225, Main Building, Tsinghua University 838 Beijing 100084 839 CN 841 Email: xing@cernet.edu.cn 843 Yu Zhai 844 CERNET Center/Tsinghua University 845 Room 225, Main Building, Tsinghua University 846 Beijing 100084 847 CN 849 Email: jacky.zhai@gmail.com 851 Tetsuya Murakami (editor) 852 IP Infusion 853 1188 East Arques Avenue 854 Sunnyvale 855 USA 857 Email: tetsuya@ipinfusion.com 858 Wojciech Dec (editor) 859 Cisco Systems 860 Haarlerbergpark Haarlerbergweg 13-19 861 Amsterdam, NOORD-HOLLAND 1101 CH 862 Netherlands 864 Phone: 865 Email: wdec@cisco.com