idnits 2.17.1 draft-mdt-softwire-map-translation-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 18) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of lines with control characters in the document. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2012) is 4429 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: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwires C. Bao 3 Internet-Draft X. Li 4 Intended status: Standards Track Y. Zhai 5 Expires: September 10, 2012 CERNET Center/Tsinghua 6 University 7 T. Murakami, Ed. 8 IP Infusion 9 W. Dec, Ed. 10 Cisco Systems 11 March 9, 2012 13 MAP Translation (MAP-T) - specification 14 draft-mdt-softwire-map-translation-01 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 September 10, 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 . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . 10 70 7. MAP-T IPv4/IPv6 Translation Specifications . . . . . . . . . . 10 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 . . . . . . . . . . . . 11 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 . . . . . . . . . . . 13 82 8. MAP-T Packet Forwarding considerations . . . . . . . . . . . . 14 83 8.1. Mesh Model . . . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . 15 88 11. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16 89 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 90 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 13.1. Normative References . . . . . . . . . . . . . . . . . . . 16 92 13.2. Informative References . . . . . . . . . . . . . . . . . . 17 93 Appendix A. Example of MAP-T translation . . . . . . . . . . . . 19 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 96 1. Extended Contributors List 98 This document is the result of the IETF Softwire MAP design team 99 effort and numerous previous individual contributions in this area 100 initiated by dIVI [I-D.xli-behave-divi] along with a similar idea 101 proposed by [I-D.murakami-softwire-4v6-translation]. The following 102 are the authors who contributed in a major way to this document: 104 Chongfeng Xie (China Telecom) 106 Room 708, No.118, Xizhimennei Street Beijing 100035 CN 108 Phone: +86-10-58552116 110 Email: xiechf@ctbri.com.cn 112 Chongfeng Xie (China Telecom) 113 Room 708, No.118, Xizhimennei Street Beijing 100035 CN 114 Phone: +86-10-58552116 115 Email: xiechf@ctbri.com.cn 117 Qiong Sun (China Telecom) 118 Room 708, No.118, Xizhimennei Street Beijing 100035 CN 119 Phone: +86-10-58552936 120 Email: sunqiong@ctbri.com.cn 122 Satoru Matsushima (Softbank Telecom) 123 1-9-1 Higashi-Shinbashi, Munato-ku, Tokyo, Japan 124 Email: satoru.matsushima@tm.softbank.co.jp 126 Gang Chen (China Mobile) 127 53A,Xibianmennei Ave. Beijing 100053 P.R.China 128 Email: chengang@chinamobile.com 130 Wentao Shang (CERNET Center/Tsinghua University) 131 Room 225, Main Building, Tsinghua University Beijing 100084 CN 132 Email: wentaoshang@gmail.com 133 Guoliang Han (CERNET Center/Tsinghua University) 134 Room 225, Main Building, Tsinghua University Beijing 100084 CN 135 Email: bupthgl@gmail.com 137 Rajiv Asati (Cisco Systems) 138 7025-6 Kit Creek Road Research Triangle Park NC 27709 USA 139 Email: rajiva@cisco.com 141 2. Introduction 143 Experiences from several years of IPv6 deployment [RFC6219] indicates 144 that transitioning a service providers' domain fully to IPv6-only 145 requires not only the continued support of legacy IPv4 communication 146 across that domain, but also the need for an ultimate IPv4 exit 147 strategy allowing communication between IPv4 and IPv6 address 148 families in that domain. The use of an IPv4/IPv6 translation based 149 solution is an optimal way to address these requirements, 150 particularly in combination with stateless translation techniques 151 that seek to minimize complexities as described in 152 [I-D.operators-softwire-stateless-4v6-motivation]. The double Pv4/ 153 IPv6 translation based solution, MAP-T, is such a solution, and one 154 that builds on existing stateless IPv4/IPv6 address translation 155 techniques specified in [RFC6052], [RFC6144], and [RFC6145], by: 157 o Extending stateless IPv4/IPv6 translation with algorithmic address 158 and port mapping rules as defined in MAP MAP 159 [I-D.mdt-softwire-mapping-address-and-port]. 161 o Introducing the notion of stateless double IPv4/IPv6 translation 162 that can restore the original IPv4 address. 164 o Allowing IPv4-translatable addresses to be either fully or 165 partially encoded in IPv6 prefixes (or addresses) assigned to 166 customers. 168 The MAP-T solution presents an operator with the prospect of a full 169 transition of a domain to IPv6-only, in a manner that: 171 o Retains the ability for IPv4 end hosts to communicate across the 172 IPv6 domain with other IPv4 hosts. 174 o Permits both individual IPv4 address assignment as well as IPv4 175 address sharing, with predefined port ranges, to be enacted using 176 IPv6. 178 o Allows communication between IPv4-only, as well as any IPv6 179 enabled end hosts, to native IPv6-only servers in the domain that 180 are using IPv4-mapped IPv6 address. 182 o Does not require the operation of an IPv4 overlay network, nor the 183 introduction of non native-IPv6 network device or server 184 functionality. 186 o Allows the use of IPv6 native network operations, including the 187 ability to classify IP traffic, as well as to perform IP traffic 188 routing optimization policies, e.g. routing optimization based on 189 peering policies for Internet IPv4 destinations outside of the 190 domain. 192 3. Requirements Language 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in RFC 2119 [RFC2119]. 198 4. Terminology 200 MAP-T: Mapping of Address and Port - Translation mode. 201 MAP-T utilizes IPv4/IP6 translation as per 202 [RFC6145] along with the MAP extensions for 203 mapping between IPv4 and IPv6 defined in MAP 204 [I-D.mdt-softwire-mapping-address-and-port] and 205 this draft. 207 MAP-T domain (Domain): A set of MAP-T CEs and BRs,. A service 208 provider may deploy MAP-T with a single MAP-T 209 domain, or may utilize multiple MAP-T domains. 210 Each domain requires a separate MAP-T rule set. 212 MAP-T Border Relay (BR): A MAP-T enabled router/translator at the 213 edge of a MAP-T domain, providing connectivity 214 to the MAP-T domain. A Border Relay router has 215 at least an IPv6- enabled interface and an IPv4 216 interface connected to the native IPv4 network, 217 and it can serve multiple MAP-T domains. 219 MAP-T Customer Edge (CE): A router/translator node functioning as a 220 Customer Edge Router/translator in a MAP-T 221 domain. This type of device is sometimes 222 referred to as a "Residential Gateway" (RG) or 223 "Customer Premises Equipment" (CPE). A typical 224 MAP-T CE adopting MAP rules will serve a 225 residential site with one WAN side interface, 226 one or more LAN side interfaces. A MAP-T CE 227 may also be referred to simply as a "CE" within 228 the context of MAP-T. 230 Shared IPv4 address: An IPv4 address that is shared among multiple 231 MAP CE nodes. Each node has a separate part of 232 the transport layer port space. 234 MAP-T Rule: A MAP rule defining the mapping relationship 235 for a given MAP-T domain between IPv4 and IPv6, 236 defined in MAP 237 [I-D.mdt-softwire-mapping-address-and-port]. 238 Three such rules are the BMR, DMR, and FMR. 240 Basic Mapping Rule (BMR): A mandatory rule governing the 241 relationship between the IPv4 prefix, address 242 or port set IPv6 address and MAP domain 243 configuration information. The BMR is used for 244 configuring the MAP CE. The BMR is effectively 245 a type of FMR. 247 Default Mapping Rule (DMR): A mandatory rule used for mapping of 248 IPv4 information into IPv6 for destinations 249 outside a MAP domain. Can be thought of as 250 representing an IPv4 0.0.0.0/0 default route. 252 Forward Mapping Rule (FMR): An optional rule for mapping between 253 specific IPv4 and IPv6 destinations within a 254 MAP domain. Can be thought of as representing 255 a more specific IPv4 route in the MAP domain. 256 Finds application primarily on CEs where 257 forwarding using more specific routes is 258 desired. To a BR, the BMR and FMR are 259 effectively the same. 261 5. MAP-T Translation Framework 263 Figure 1 depicts the overall MAP-T architecture with IPv4 users (N 264 and M) networks connected to a routed IPv6 network. 266 User N 267 Private IPv4 268 | Network 269 | 270 O--+---------------O 271 | | MAP-T CE | 272 | +-----+--------+ | 273 | NAPT44| MAP-T | `-. 274 | +-----+ | | -._ ,-------. .------. 275 | +--------+ | ,-' `-. ,-' `-. 276 O------------------O / \ O---------O / Public \ 277 / IPv6 only \ | MAP-T |/ IPv4 \ 278 ( Network --+ Border +- Network ) 279 \ (MAP-T Domain)/ | Relay |\ / 280 O------------------O \ / O---------O \ / 281 | MAP-T CE | ;". ,-' `-. ,-' 282 | +-----+--------+ | ," `----+--' ------' 283 | NAPT44| MAP-T | | ," | 284 | +-----+ | | IPv6 Server(s) 285 | | +--------+ | (v4 mapped 286 O---.--------------O address) 287 | 288 User M 289 Private IPv4 290 Network 292 Figure 1: Network Topology 294 Figure 1: Network Topology 296 The MAP-T solution relies on IPv4/IPv6 translating components, the 297 MAP-T CE and MAP-T BR, connected to a MAP-T domain. The MAP-T CE is 298 responsible for connecting a users' private IPv4, along with any 299 native IPv6 network to the IPv6-only MAP-T domain. To multiplex 300 multiple IPv4 user hosts, the CE relies on regular NAT44 301 functionality, which is however configured based on MAP-T settings. 302 The CE's stateless IPv4/IPv6 translation function [RFC6145], again 303 configured to operate based on MAP-T settings, completes the model of 304 the CE defined in Figure 1. The CE's MAP-T domain facing interface 305 is configured with a regular operator assigned IPv6 prefix that can 306 be the same as that used to address any native IPv6 (non MAP-T) user 307 network devices i.e. MAP-T does not require more than one IPv6 308 prefix per user network, and supports regular IPv6 prefix or address 309 assignment mechanism including SLAAC and DHCPv6 stateful. 311 The MAP-T BR is responsible for connecting external IPv4 networks to 312 all devices in one or more MAP-T domains, using stateless IPv4/IPv6 313 translation [RFC6145]extended by the MAP-T rules as per this 314 document. Besides the CE and BR, the MAP-T domain can contain any 315 regular IPv6-only hosts/servers that have an IPv4 mapped IPv6 address 316 (IPv4-translatable address per [RFC6052]) using a prefix assigned to 317 the MAP-T domain. Communication with such devices is naturally 318 possible using native IPv6 means from inside or outside the domain as 319 well as from any IPv4-only hosts inside or outside of the MAP-T 320 domain. 322 The IPv4 in IPv6 address mapping scheme employed by the MAP-T 323 solution, along with the avoidance of using any additional 324 encapsulating headers allows the MAP-T domain to be operated using 325 regular native IPv6 functionality. This includes also the ability to 326 classify traffic based on specific source and destination addresses 327 (including any IPv4 in IPv6 mapped source and destinations), and 328 higher layer packet payload. Similarly, the address mapping 329 characteristic allows IPv6 traffic forwarding in the MAP-T domain to 330 be optimized in line with an operators' policies, e.g. native IPv6 331 routing selection of MAP-T domain egress points based on peering 332 policies bound to IPv4 destination. IP Traffic between CEs in any 333 MAP-T can flow either in hub & spoke modes, with a BR acting as the 334 spoke, or in mesh mode directly between the CEs. 336 6. MAP-T Node Behavior 338 6.1. Provisioning of MAP-T CE 340 A MAP-T CE requires the following parameters for provisioning: 342 o The MAP Domain IPv4 and IPv6 prefix, and their lengths (Basic 343 Mapping Rule) 345 o The MAP EA-bits (CE index), including IPv4 suffix, length and any 346 port-range (including any excluded ports and the port number 347 continuity parameter) 349 o The MAP domain BR IPv6 prefix and its length (Default Mapping Rule) 351 A MAP-T CE that receives a MAP DHCP option 352 [I-D.mdt-softwire-map-dhcp-option] and performs the following (MAP 353 initialization) functions: 355 o Configures the IPv4 address along with any applicable NAT44 port- 356 range function parameters (BMR) 358 o Configures additional IPv4/IPv6 stateless translation parameters - 359 optional FMRs. 361 6.2. Packet Forwarding Behavior of MAP-T CE 363 6.2.1. IPv4 to IPv6 365 A MAP-T CE receiving IPv4 packets SHOULD perform NAT44 function first 366 and create appropriate NAT44 stateful bindings. The resulting IPv4 367 packets MUST contain the source IPv4 address and source transport 368 number defined by MAP-T. The resulting IPv4 packet is forwarded to 369 the CE's MAP-T function that performs IPv4 to IPv6 stateless 370 translation. The IPv6 source and destination addresses MUST then be 371 derived as per Section 6 of this draft, and the IPv4 header MUST be 372 replaced with an IPv6 header following [RFC6145]. 374 6.2.2. IPv6 to IPv4 376 A MAP-T CE receiving an IPv6 packet performs its regular IPv6 377 operations, whereby only packets that are addressed to the MAP-T CE's 378 MAP derived BMR address are forwarded to the CE's MAP-T function. 379 All other IPv6 traffic is forwarded as per the CE's IPv6 routing 380 rules. The CE SHOULD check that MAP-T received packets' transport- 381 layer destination port number is in the range configured by MAP for 382 the CE and the CE SHOULD drop any non conforming packet and respond 383 with an ICMPv6 "Address Unreachable" (Type 1, Code 3). In other 384 cases, the MAP-T function MUST derive the IPv4 source and destination 385 addresses as per Section 6 of this draft and MUST replace the IPv6 386 header with an IPv4 header in accordance with [RFC6145]. The 387 resulting IPv4 packet is then forwarded to the CE's NAT44 function 388 where the destination port number MUST be checked against the 389 stateful port mapping session table and the destination port number 390 MUST be mapped to its original value. 392 6.3. Provisioning of MAP-T BR 394 The MAP-T BR needs to be provisioned with information for the MAP-T 395 domain or domains it is expected to handle, along with any necessary 396 routing processes. For each MAP-T domain, the BR will have the 397 following parameters: 399 o The MAP Domain IPv4 and IPv6 prefix and their lengths (Basic 400 Mapping Rule). 402 o The BR prefix and its length (Default Mapping Rule) 403 o Optionally, any specific Forward Mapping Rules applicable to the 404 domain. 406 6.4. Packet Forwarding Behavior on MAP-T BR 408 6.4.1. IPv6 to IPv4 410 A MAP-T BR receiving IPv6 packets selects a best matching MAP-T 411 domain rule based on a longest address match of the packets' source 412 address against the BR's configured MAP-T BMR prefix(es), as well as 413 a match of the packet destination address against the configured BR 414 prefixes or FMR prefix(es). The selected MAP rule allows the BR to 415 determine the CE-index from the source IPv6 address. The BR MUST 416 perform a validation of the consistency of the source IPv6 address 417 and source port number for the packet using BMR. If the packets 418 source port number is found to be outside the range allowed for this 419 CE-index and the BMR, the BR MUST drop the packet and respond with an 420 ICMPv6 "Destination Unreachable, Source address failed ingress/egress 421 policy" (Type 1, Code 5). 423 For packets that are to be forwarded outside of a MAP-T domain, the 424 BR MUST derive the source and destination IPv4 addresses as per 425 Section 7 of this draft and translate the IPv6 to IPv4 headers 426 following [RFC6145]. The resulting IPv4 packets are then passed to 427 regular IPv4 forwarding. 429 6.4.2. IPv4 to IPv6 431 A MAP-T BR receiving IPv4 packets uses a longest match IPv4 lookup to 432 select the target MAP-T domain and rule. The BR MUST then derive the 433 IPv6 source and destination addresses from the IPv4 source and 434 destination address and port as per Section 7 of this draft. 435 Following this, the BR MUST translate the IPv4 to IPv6 headers 436 following [RFC6145]. The resulting IPv6 packets are then passed to 437 regular IPv6 forwarding. 439 Note that the operation of a BR when forwarding to MAP-T domains that 440 do not utilize IPv4 address sharing, is the same as stateless IPv4/ 441 IPv6 translation. 443 7. MAP-T IPv4/IPv6 Translation Specifications 445 This section specifies the MAP-T IPv6 address format and IPv4-IPv6 446 address mapping behaviour, based on the MAP MAP 447 [I-D.mdt-softwire-mapping-address-and-port] specification. Numeric 448 examples of the MAP-T address translation in action are given in 449 Appendix A. 451 7.1. Address Formats 453 The MAP-T address format of the (mapped) CE address adopts the format 454 defined in MAP [I-D.mdt-softwire-mapping-address-and-port]. It is 455 used in mapping rules operations to construct the source and 456 destination IPv6 addresses. An example, is shown in Figure 2 for the 457 specific case of n+o+m bits less or equal to 64 bit length, where the 458 (optional) well known m subnet-Id bits are used to auto-complete a 459 prefix up to the 64th bit. In cases where the End-user IPv6 prefix 460 n+o bits exceed a length of 64, the excess bits are "bit spread" 461 across the fixed u-octet boundary as needed, however for practical 462 purposes operators may find it easier to work at octet aligned 463 boundaries. In any case, the maximum length of the End-user IPv6 464 prefix is 96 minus the length of PSID, to allow for the encoding of 465 the IPv4 address and PSID. The EA bits are composed of the IPv4 466 suffix and PSID as per MAP 467 [I-D.mdt-softwire-mapping-address-and-port], and thus the same PSID 468 is repeated twice in the overall encoding. 469 <-- n bits -->||<-m bits>|< 8>|<----- L>=32 ----->|<--56-L--> 470 +-------------+--------+---------+----+--------------+----+---------+ 471 | IPv6 prefix |EA bits |Subnet-id| u | IPv4 address |PSID| 0 | 472 +-------------+--------+---------+----+--------------+----+---------+ 473 | 475 Figure 2: IPv4-translatable address for BMR and FMR 477 The address format used by the MAP-T Default Mapping Rule (DMR, IPv4 478 converted address used to represent IPv4 destinations outside of the 479 MAP-T domain) is specific to MAP-T. An example is as shown in Figure 480 3. Note that the BR-prefix length is variable and can be both 481 shorter or longer than 64 bits, up to 96 bits. In the respective 482 cases the IPv4 address and the BR prefix are shifted and "bit spread" 483 across the fixed u-octet boundary as per [RFC6052]. All trailing 484 bits after the IPv4 address are set to 0x0. 486 <---------- 64 ------------>< 8 ><----- 32 -----><--- 24 ---> 487 +--------------------------+----+---------------+-----------+ 488 | BR prefix | u | IPv4 address | 0 | 489 +--------------------------+----+---------------+-----------+ 491 Figure 3: Example of IPv4-converted address for DMR 493 In all cases the "u-octet" is taken to be 0x00. 495 7.2. Translating IPv4 Address and Port Number into IPv6 Address and 496 Port Number at the BR 498 IPv6 Source Address and Source Port Number: 500 At the BR, the IPv6 source address (IPv4-converted address) MUST be 501 derived from the IPv4 source Address as per DMR. The source Layer 4 502 TCP/UDP port number MUST be unchanged. 504 IPv6 Destination Address and Destination Port Number: 506 At the BR, the IPv6 destination address (IPv4-translatable address) 507 MUST be derived from the IPv4 destination address and the destination 508 port number as per FMR. The destination port number MUST be 509 unchanged. 511 7.3. Translating IPv6 Address and Port Number into IPv4 Address and 512 Port Number at the BR 514 IPv4 Source Address and Source Port Number: 516 At the BR, the IPv4 source address MUST be derived from the IPv6 517 source address (IPv4-translatable address) as per FMR. The source 518 port number MUST be unchanged. 520 IPv4 Destination Address and Destination Port Number: 522 At the BR, the IPv4 destination address MUST be derived from the IPv6 523 destination address (IPv4-converted address) as per DMR. The 524 destination port number MUST be unchanged. 526 7.4. Translating IPv4 Address and Port Number into IPv6 Address and 527 Port Number at the CE 529 IPv6 Source Address and Source Port Number: 531 At the CE, the IPv6 source address (IPv4-translatable address) MUST 532 be derived from the IPv4 source address as per BMR. The source port 533 number MUST be unchanged. 535 IPv6 Destination Address and Destination Port Number: 537 At the CE, if Forwarding Mapping Rules (FMRs) are enabled, the IPv4 538 packet MUST be checked to see if the IPv4 destination address matches 539 the FMR. If matching, the IPv6 destination address (IPv4- 540 translatable address) MUST be derived from the IPv4 destination 541 address and the destination port number per FMR. Otherwise, the IPv6 542 destination address (IPv4-translateable address) MUST be derived from 543 the received IPv4 destination address per DMR. The destination port 544 number MUST be unchanged. 546 7.5. Translating IPv6 Address and Port Number into IPv4 Address and 547 Port Number at the CE 549 IPv4 Source Address and Source Port Number: 551 At the CE, the IPv4 source address MUST be derived from the IPv6 552 source address (IPv6-converted address) as per the DMR, or as per the 553 FMR. The source port number MUST be unchanged. 555 IPv4 Destination Address and Destination Port Number: At the CE, the 556 IPv4 destination address MUST be derived from the IPv6 destination 557 address (IPv6-translatable address) as per BMR. The destination port 558 number 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 during the IPv4 to IPv6 ICMPv6 translation 573 operation. A BR can translate the resulting ICMPv6 packets back to 574 ICMP preserving the ID field on its way to an IPv4 destination. In 575 the return path, when MAP-T BR receives an ICMP packet containing an 576 ID field which is bound for a shared address in the MAP-T domain, the 577 MAP-T BR SHOULD use the ID value as a substitute for the destination 578 port in determining the IPv6 destination address according to Section 579 5.1. In all other cases, the MAP-T BR MUST derive the destination 580 IPv6 address by simply mapping the destination IPv4 address without 581 additional port info. 583 7.7. Path MTU Discovery and Fragmentation 585 Due to the different sizes of the IPv4 and IPv6 header, which are 20+ 586 octets and 40 octets respectively, handling the maximum packet size 587 is relevant for the operation of any system connecting the two 588 address families. There are three mechanisms to handle this issue: 589 path MTU discovery (PMTUD), fragmentation, and transport-layer 590 negotiation such as the TCP Maximum Segment Size (MSS) option 591 [RFC0897]. MAP-T uses all three mechanisms to deal with different 592 cases. 594 Following [RFC6145], when an IPv4 node performs path MTU discovery 595 (by setting the Don't Fragment (DF) bit in the header), path MTU 596 discovery can operate end-to-end across the MAP-T BR and CE 597 translators. In this case, either IPv4 or IPv6 routers (including 598 the translators) can send back ICMP Packet Too Big messages to the 599 sender. When IPv6 routers send these as ICMPv6 errors, these packets 600 will pass through the translator and will result in an appropriate 601 ICMP error sent to the IPv4 sender. When the IPv4 sender does not 602 set the DF bit, the translator MUST ensure that the packet does not 603 exceed the path MTU on the IPv6 side. This is done, if necessary, by 604 fragmenting the IPv4 packet and including with Fragment Headers to 605 fit in the minimum MTU 1280-byte IPv6 packets. When the IPv4 sender 606 does not set the DF bit, the translator SHOULD include an IPv6 607 Fragment Header to indicate that the sender allows fragmentation. 608 The rules defined in [RFC6145] ensure that when packets are 609 fragmented, either by the sender or by IPv4 routers, the low-order 16 610 bits of the fragment identification are carried end-to-end, ensuring 611 that packets are correctly reassembled. The above mechanism ensures 612 that the Don't Fragment (DF) bit in the IPv4 header can be carried 613 end-to-end via double stateless translation in most of the cases. 614 For example, the IPv4 packets with DF=1 will be translated to IPv6 615 packets without fragmentation header and will be translated back to 616 IPv4 packets with DF=1. The IPv4 packets with DF=0 will be 617 translated to IPv6 packets with fragmentation header (keeping the ID 618 value) and will be translated back to IPv4 packets with DF=0. An 619 open corner case left up for specific handling by implementations 620 [RFC6145] is for when IPv4 packets with DF=1 and MF=1 are received by 621 a translator. MAP-T devices SHOULD translate such IPv4 packets into 622 IPv6 with a fragmentation header present. Experimental evidence 623 [operational-exp] and [IMC-07}, indicate that only 27,474 packets 624 observed with DF=1/MF=1 among 10 billion samples. This indicates 625 that IPv4 packets with DF=1 and MF=1 are rare in production networks 626 (10e-5) and that their handling by this rule causes no negative 627 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. If the 640 corresponding mapping rule is not found, CE must forward the packet 641 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 need to be disabled (not defined). 655 8.3. Communication with IPv6 servers in the MAP-T domain 657 MAP-T allows communication between both IPv4-only and any IPv6 658 enabled end hosts, with native IPv6-only servers which are using 659 IPv4-mapped IPv6 address based on DMR in the MAP-T domain. In this 660 mode, the IPv6-only servers SHOULD have both A and AAAA records in 661 the authorities DNS server [RFC6219]. DNS64 [RFC6147] become 662 required only when IPv6 servers in the MAP-T domain are expected 663 themselves to initiate communication to external IPv4-only hosts. 665 9. NAT44 considerations 667 The NAT44 implemented in MAP-T CE SHOULD conform with the behavior 668 and best current practice documented in [RFC4787], [RFC5508] and 669 [RFC5382]. In MAP-T address sharing mode (determined by the MAP-T 670 configuration parameters) the operation of the NAT44 must be 671 restricted to the available port numbers derived via BMR. 673 10. Security Considerations 675 Spoofing attacks: With consistency checks between IPv4 and IPv6 676 sources that are performed on IPv4/IPv6 packets received by BR's 677 and CE's (Section 6), MAP-T does not introduce any opportunity for 678 spoofing attack that would not pre-exist in IPv6. 680 Denial-of-service attacks: In MAP-T domains where IPv4 addresses are 681 shared, the fact that IPv4 datagram reassembly may be necessary 682 introduces an opportunity for DOS attacks. This is inherent to 683 address sharing, and is common with other address sharing 684 approaches such as DS-Lite and NAT64/ DNS64. The best protection 685 against such attacks is to accelerate IPv6 enablement in both 686 clients and servers so that, where MAP-T is supported, it is less 687 and less used. 689 Routing-loop attacks: This attack may exist in some automatic- 690 tunneling scenarios are documented in 691 [I-D.ietf-v6ops-tunnel-loops]. They cannot exist with MAP-T 692 because each BRs checks that the IPv6 source address of a received 693 IPv6 packet is a CE address based on Forwarding Mapping Rule 694 defined in MAP [I-D.mdt-softwire-mapping-address-and-port]. 696 Attacks facilitated by restricted port set: From hosts that are not 697 subject to ingress filtering of [RFC2827], some attacks are 698 possible by intervening with faked packets during ongoing 699 transport connections ([RFC4953], [RFC5961], [RFC6056]. The 700 attacks depend on guessing which ports are currently used by 701 target hosts, and using an unrestricted port set is preferable, 702 i.e. using native IPv6 connections that are not subject to MAP 703 port range restrictions. To minimize this type of attacks when 704 using a restricted port set, the MAP CE's NAT44 filtering behavior 705 SHOULD be "Address-Dependent Filtering". Furthermore, the MAP CEs 706 SHOULD use a DNS transport proxy function to handle DNS traffic, 707 and source such traffic from IPv6 interfaces not assigned to 708 MAP-T. Practicalities of these methods are discussed in Section 709 5.9 of [I-D.dec-stateless-4v6]. 711 11. IANA Consideration 713 This document has no IANA actions. 715 12. Acknowledgements 717 The authors would like to thank Maoke Chen, Leaf Yeh and Senthil 718 Sivakumar for their review and comments. 720 13. References 722 13.1. Normative References 724 [I-D.mdt-softwire-mapping-address-and-port] 725 Troan, O., "Mapping of Address and Port (MAP)", 726 draft-mdt-softwire-mapping-address-and-port-02 (work in 727 progress), November 2011. 729 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 730 Requirement Levels", BCP 14, RFC 2119, March 1997. 732 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 733 Algorithm", RFC 6145, April 2011. 735 13.2. Informative References 737 [I-D.dec-stateless-4v6] 738 Dec, W., Asati, R., and H. Deng, "Stateless 4Via6 Address 739 Sharing", draft-dec-stateless-4v6-04 (work in progress), 740 October 2011. 742 [I-D.ietf-v6ops-tunnel-loops] 743 Nakibly, G. and F. Templin, "Routing Loop Attack using 744 IPv6 Automatic Tunnels: Problem Statement and Proposed 745 Mitigations", draft-ietf-v6ops-tunnel-loops-07 (work in 746 progress), May 2011. 748 [I-D.mdt-softwire-map-dhcp-option] 749 Mrugalski, T., Boucadair, M., and O. Troan, "DHCPv6 750 Options for Mapping of Address and Port", 751 draft-mdt-softwire-map-dhcp-option-00 (work in progress), 752 October 2011. 754 [I-D.murakami-softwire-4v6-translation] 755 Murakami, T., Chen, G., Deng, H., Dec, W., and S. 756 Matsushima, "4via6 Stateless Translation", 757 draft-murakami-softwire-4v6-translation-00 (work in 758 progress), July 2011. 760 [I-D.operators-softwire-stateless-4v6-motivation] 761 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 762 Borges, I., and G. Chen, "Motivations for Stateless IPv4 763 over IPv6 Migration Solutions", 764 draft-operators-softwire-stateless-4v6-motivation-02 (work 765 in progress), June 2011. 767 [I-D.xli-behave-divi] 768 Shang, W., Li, X., Zhai, Y., and C. Bao, "dIVI: Dual- 769 Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-04 770 (work in progress), October 2011. 772 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 773 RFC 792, September 1981. 775 [RFC0897] Postel, J., "Domain name system implementation schedule", 776 RFC 897, February 1984. 778 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 779 Defeating Denial of Service Attacks which employ IP Source 780 Address Spoofing", BCP 38, RFC 2827, May 2000. 782 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 783 Message Protocol (ICMPv6) for the Internet Protocol 784 Version 6 (IPv6) Specification", RFC 4443, March 2006. 786 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 787 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 788 RFC 4787, January 2007. 790 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 791 RFC 4953, July 2007. 793 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 794 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 795 RFC 5382, October 2008. 797 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 798 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 799 April 2009. 801 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 802 Robustness to Blind In-Window Attacks", RFC 5961, 803 August 2010. 805 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 806 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 807 October 2010. 809 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 810 Protocol Port Randomization", BCP 156, RFC 6056, 811 January 2011. 813 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 814 IPv4/IPv6 Translation", RFC 6144, April 2011. 816 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 817 Beijnum, "DNS64: DNS Extensions for Network Address 818 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 819 April 2011. 821 [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 822 China Education and Research Network (CERNET) IVI 823 Translation Design and Deployment for the IPv4/IPv6 824 Coexistence and Transition", RFC 6219, May 2011. 826 [operational-exp] John, Wolfgang; Tafvelin, Sven: Analysis of 827 Internet Backbone Traffic and Header Anomalies 828 Observed. IMC '07: Proceedings of the 7th ACM SIGCOMM 829 conference on Internet measurement, pp. 111-116. 830 ISBN/ISSN: 978-1-59593-908-1 831 http://conferences.sigcomm.org/imc/2007/papers/imc91.pdf 832 Appendix A. Example of MAP-T translation 834 The following is a MAP-T example derived from the general MAP example 835 in MAP [I-D.mdt-softwire-mapping-address-and-port]. 837 Example 1. 839 Given the MAP domain information and an IPv6 address of an endpoint: 841 IPv6 prefix assigned to the end user: 2001:db8:0012:3400::/56 843 Basic Mapping Rule: {2001:db8:0000::/40 (Rule IPv6 prefix), 844 192.0.2.0/24 (Rule IPv4 prefix), 16 (Rule EA-bits length)} 846 Sharing ratio: 256 (16 - (32 - 24) = 8. 2^8 = 256) 848 PSID offset: 4 850 A MAP node (CE or BR) can via the BMR determine the IPv4 address and 851 port-set as shown below: 853 EA bits offset: 40 855 IPv4 suffix bits (p) Length of IPv4 address (32) - IPv4 prefix 856 length (24) = 8 858 IPv4 address 192.0.2.18 (0xc0000212) 860 PSID start: 40 + p = 40 + 8 = 48 862 PSID length: o - p = 16 (56 - 40) - 8 = 8 864 PSID: 0x34 866 Port-set-1: 4928, 4929, 4930, 4931, 4932, 4933, 4934, 4935, 4936, 867 4937, 4938, 4939, 4940, 4941, 4942, 4943 869 Port-set-2: 9024, 9025, 9026, 9027, 9028, 9029, 9030, 9031, 9032, 870 9033, 9034, 9035, 9036, 9037, 9038, 9039 872 ... ... 874 Port-set-15 62272, 62273, 62274, 62275, 62276, 62277, 62278, 62279, 875 62280, 62281, 62282, 62283, 62284, 62285, 62286, 62287 877 The BMR information allows a MAP-T CE also to determine (complete) 878 its IPv6 address within the indicated IPv6 prefix. 880 IPv6 address of MAP-T CE: 2001:db8:0012:3400:00c0:0002:1200:3400 882 Example 2. 884 Another example can be made of a hypothetical MAP-T BR, configured 885 with the following FMR when receiving a packet with the following 886 characteristics: 888 IPv4 source address: 1.2.3.4 (0x01020304) 890 IPv4 source port: 80 892 IPv4 destination address: 192.0.2.18 (0xc0000212) 894 IPv4 destination port: 9030 896 Configured Forwarding Mapping Rule: {2001:db8:0000::/40 (Rule IPv6 897 prefix), 192.0.2.0/24 (Rule IPv4 prefix), 16 (Rule EA-bits 898 length)} 900 MAP-T BR Prefix 2001:db8:ffff::/64 902 The above information allows the BR to derive as follows the mapped 903 destination IPv6 address for the corresponding MAP-T CE, and also the 904 mapped source IPv6 address for the IPv4 source. 906 IPv4 suffix bits (p) 32 - 24 = 8 (18 (0x12)) 908 PSID length: 8 910 PSID: 0x34 (9030 (0x2346)) 912 The resulting IPv6 packet will have the following key fields 914 IPv6 source address 2001:db8:ffff:0:0001:0203:0400:: 916 IPv6 destination address: 2001:db8:0012:3400:00c0:0002:1200:3400 918 IPv6 source Port: 80 920 IPv6 destination Port: 9030 922 Example 3: 924 An IPv4 host behind the MAP-T CE (addressed as per the previous 925 examples) corresponding with IPv4 host 1.2.3.4 will have its packets 926 converted into IPv6 using the DMR configured on the MAP-T CE as 927 follows: 929 Default Mapping Rule used by MAP-T CE: {2001:db8:ffff::/64 (Rule 930 IPv6 prefix), 0.0.0.0/0 (Rule IPv4 prefix), null (BR IPv4 931 address)} 933 IPv4 source address (post NAT44 if present) 192.0.2.18 935 IPv4 destination address: 1.2.3.4 937 IPv4 source port (post NAT44 if present): 9030 939 IPv4 destination port: 80 941 IPv6 source address of MAP-T CE: 2001:db8:0012:3400:00c0:0002:1200: 942 3400 944 IPv6 destination address: 2001:db8:ffff:0:0001:0203:0400:: 946 Authors' Addresses 948 Congxiao Bao 949 CERNET Center/Tsinghua University 950 Room 225, Main Building, Tsinghua University 951 Beijing 100084 952 CN 954 Email: congxiao@cernet.edu.cn 956 Xing Li 957 CERNET Center/Tsinghua University 958 Room 225, Main Building, Tsinghua University 959 Beijing 100084 960 CN 962 Email: xing@cernet.edu.cn 964 Yu Zhai 965 CERNET Center/Tsinghua University 966 Room 225, Main Building, Tsinghua University 967 Beijing 100084 968 CN 970 Email: jacky.zhai@gmail.com 971 Tetsuya Murakami (editor) 972 IP Infusion 973 1188 East Arques Avenue 974 Sunnyvale 975 USA 977 Email: tetsuya@ipinfusion.com 979 Wojciech Dec (editor) 980 Cisco Systems 981 Haarlerbergpark Haarlerbergweg 13-19 982 Amsterdam, NOORD-HOLLAND 1101 CH 983 Netherlands 985 Phone: 986 Email: wdec@cisco.com