idnits 2.17.1 draft-ietf-softwire-map-t-05.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 : ---------------------------------------------------------------------------- == 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 (February 10, 2014) is 3721 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-06 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-10 == Outdated reference: A later version (-06) exists of draft-maglione-softwire-map-t-scenarios-03 -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Li 3 Internet-Draft C. Bao 4 Intended status: Experimental CERNET Center/Tsinghua University 5 Expires: August 14, 2014 W. Dec, Ed. 6 O. Troan 7 Cisco Systems 8 S. Matsushima 9 SoftBank Telecom 10 T. Murakami 11 IP Infusion 12 February 10, 2014 14 Mapping of Address and Port using Translation (MAP-T) 15 draft-ietf-softwire-map-t-05 17 Abstract 19 This document specifies the "Mapping of Address and Port" stateless 20 IPv6-IPv4 Network Address Translation (NAT64) based solution 21 architecture for providing shared or non-shared IPv4 address 22 connectivity to and across an IPv6 network. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 14, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 62 5. Mapping Rules . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.1. Destinations outside the MAP domain . . . . . . . . . . . 7 64 6. The IPv6 Interface Identifier . . . . . . . . . . . . . . . . 7 65 7. MAP-T Configuration . . . . . . . . . . . . . . . . . . . . . 8 66 7.1. MAP CE . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 7.2. MAP BR . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 8. MAP-T Packet Forwarding . . . . . . . . . . . . . . . . . . . 9 69 8.1. IPv4 to IPv6 at the CE . . . . . . . . . . . . . . . . . 9 70 8.2. IPv6 to IPv4 at the CE . . . . . . . . . . . . . . . . . 10 71 8.3. IPv6 to IPv4 at the BR . . . . . . . . . . . . . . . . . 11 72 8.4. IPv4 to IPv6 at the BR . . . . . . . . . . . . . . . . . 11 73 9. ICMP Handling . . . . . . . . . . . . . . . . . . . . . . . . 11 74 10. Fragmentation and Path MTU Discovery . . . . . . . . . . . . 12 75 10.1. Fragmentation in the MAP domain . . . . . . . . . . . . 12 76 10.2. Receiving IPv4 Fragments on the MAP domain borders . . . 12 77 10.3. Sending IPv4 fragments to the outside . . . . . . . . . 13 78 11. NAT44 Considerations . . . . . . . . . . . . . . . . . . . . 13 79 12. Usage Considerations . . . . . . . . . . . . . . . . . . . . 13 80 12.1. EA-bit length 0 . . . . . . . . . . . . . . . . . . . . 13 81 12.2. Mesh and Hub and spoke modes . . . . . . . . . . . . . . 13 82 12.3. Communication with IPv6 servers in the MAP-T domain . . 14 83 12.4. Compatibility with other NAT64 solutions . . . . . . . . 14 84 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 87 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 88 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 17.1. Normative References . . . . . . . . . . . . . . . . . . 16 90 17.2. Informative References . . . . . . . . . . . . . . . . . 16 91 Appendix A. Examples of MAP-T translation . . . . . . . . . . . 19 92 Appendix B. Port mapping algorithm . . . . . . . . . . . . . . . 22 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 95 1. Introduction 97 Experiences from initial service provider IPv6 network deployments, 98 such as [RFC6219], indicate that successful transition to IPv6 can 99 happen while supporting legacy IPv4 users without a full end-end dual 100 IP stack deployment. However, due to public IPv4 address exhaustion 101 this requires an IPv6 technology that supports IPv4 users utilizing 102 shared IPv4 addressing, while also allowing the network operator to 103 optimalise their operations around IPv6 network practices. The use 104 of double NAT64 translation based solutions is an optimal way to 105 address these requirements, especially in combination with stateless 106 translation techniques that minimize operational challenges outlined 107 in [I-D.ietf-softwire-stateless-4v6-motivation]. 109 The Mapping of Address and Port - Translation (MAP-T) architecture 110 specified in this draft is such a double stateless NAT64 based 111 solution. It builds on existing stateless NAT64 techniques specified 112 in [RFC6145], along with the stateless algorithmic address & 113 transport layer port mapping scheme defined in MAP-E 114 [I-D.ietf-softwire-map]. The MAP-T solution differs from MAP-E in 115 the use of IPv4-IPv6 translation, rather than encapsulation, as the 116 form of IPv6 domain transport. The translation mode is considered 117 advantageous in scenarios where the encapsulation overhead, or IPv6 118 operational practices (e.g. use of IPv6 only servers, or reliance on 119 IPv6 + protocol headers for traffic classification) rule out 120 encapsulation. These scenarios are presented in 121 [I-D.maglione-softwire-map-t-scenarios] 123 2. Conventions 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 3. Terminology 131 MAP Customer Edge (CE): A device functioning as a Customer Edge 132 router in a MAP deployment. A typical MAP CE 133 adopting MAP rules will serve a residential 134 site with one WAN side IPv6 addressed 135 interface, and one or more LAN side 136 interfaces addressed using private IPv4 137 addressing. 139 MAP Border Relay (BR): A MAP enabled router managed by the service 140 provider at the edge of a MAP domain. A 141 Border Relay router has at least an 142 IPv6-enabled interface and an IPv4 interface 143 connected to the native IPv4 network. A MAP 144 BR may also be referred to simply as a "BR" 145 within the context of MAP. 147 MAP domain: One or more MAP CEs and BRs connected by 148 means of an IPv6 network and sharing a common 149 set of MAP Rules. A service provider may 150 deploy a single MAP domain, or may utilize 151 multiple MAP domains. 153 MAP Rule: A set of parameters describing the mapping 154 between an IPv4 prefix, IPv4 address or 155 shared IPv4 address and an IPv6 prefix or 156 address. Each MAP domain uses a different 157 mapping rule set. 159 MAP Rule set: A Rule set is composed out of all the MAP 160 Rules communicated to a device, that are 161 intended for determining the devices' traffic 162 forwarding operations. A set has at least 163 one entry, known as a default map rule. The 164 Rule set is interchangeably referred to in 165 this document as a Rule table. 167 MAP Rule table: See MAP Rule set. 169 MAP node: A device that implements MAP. 171 Port-set: Each node has a separate part of the 172 transport layer port space; denoted as a 173 port-set. 175 Port-set ID (PSID): Algorithmically identifies a set of ports 176 exclusively assigned to the CE. 178 Shared IPv4 address: An IPv4 address that is shared among multiple 179 CEs. Only ports that belong to the assigned 180 port-set can be used for communication. Also 181 known as a Port-Restricted IPv4 address. 183 End-user IPv6 prefix: The IPv6 prefix assigned to an End-user CE by 184 other means than MAP itself. E.g. 185 Provisioned using DHCPv6 PD [RFC3633], 186 assigned via SLAAC [RFC4862], or configured 187 manually. It is unique for each CE. 189 MAP IPv6 address: The IPv6 address used to reach the MAP 190 function of a CE from other CEs and from BRs. 192 Rule IPv6 prefix: An IPv6 prefix assigned by a Service Provider 193 for a MAP rule. 195 Rule IPv4 prefix: An IPv4 prefix assigned by a Service Provider 196 for a MAP rule. 198 Embedded Address (EA) bits: The IPv4 EA-bits in the IPv6 address 199 identify an IPv4 prefix/address (or part 200 thereof) or a shared IPv4 address (or part 201 thereof) and a port-set identifier. 203 4. Architecture 205 Figure 1 depicts the overall MAP-T architecture, which sees any 206 number of privately addressed IPv4 users (N and M) connected by means 207 of MAP-T CEs to an IPv6 network that is equipped with one or more 208 MAP-T BR. CEs and BRs that share MAP configuration parameters, 209 referred to as MAP rules, form a MAP-T Domain. 211 Functionally the MAP-T CE and BR utilize and extend some well 212 established technology building blocks to allow the IPv4 users to 213 correspond with nodes on the Public IPv4 network, or IPv6 network as 214 follows: 216 o A (NAT44) NAPT [RFC2663] function on a MAP CE is extended with 217 support for restricting the allowable TCP/UDP ports for a given 218 IPv4 address. The IPv4 address and port range used are determined 219 by the MAP provisioning process and identical to MAP-E 220 [I-D.ietf-softwire-map]. 222 o A stateless NAT64 function [RFC6145] is extended to allow 223 stateless mapping of IPv4 and transport layer port ranges to IPv6 224 address space. 226 User N 227 Private IPv4 228 | Network 229 | 230 O--+---------------O 231 | | MAP-T CE | 232 | +-----+--------+ | 233 | NAPT44| MAP-T | | 234 | +-----+ | +-._ ,-------. .------. 235 | +--------+ | ,-' `-. ,-' `-. 236 O------------------O / \ O---------O / Public \ 237 / IPv6 only \ | MAP-T |/ IPv4 \ 238 ( Network --+ Border +- Network ) 239 \ / | Relay |\ / 240 O------------------O \ / O---------O \ / 241 | MAP-T CE | ;". ,-' `-. ,-' 242 | +-----+--------+ | ," `----+--' ------' 243 | NAPT44| MAP-T | |, | 244 | +-----+ | + IPv6 node(s) 245 | | +--------+ | (w/ v4-embedded-v6 address) 246 O---+--------------O 247 | 248 User M 249 Private IPv4 250 Network 252 Figure 1: MAP-T Architecture 254 Each MAP-T CE is assigned with a regular IPv6 prefix from the 255 operator's IPv6 network. This, in conjunction with MAP domain 256 configuration settings is expanded using MAP procedures to form a MAP 257 IPv6 address and an IPv4 address. To allow for IPv4 address sharing, 258 the CE may also have be configured with a TCP/UDP port-range that is 259 codified by means of a MAP Port Set Identifier (PSID) value. Each CE 260 is responsible for forwarding traffic between a given users' private 261 IPv4 address space and the CE's MAP derived IPv4 address + port set, 262 as well as adapting traffic between IPv4 and IPv6 using stateless 263 NAT64. 265 The MAP-T BR connects one or more MAP-T domains to external IPv4 266 networks using stateless NAT64 as extended by the MAP-T behaviour 267 described in this document. 269 In contrast to MAP-E, NAT64 technology is used in the architecture 270 for two purposes. Firstly, it is intended to diminish encapsulation 271 overhead and normalize IPv4 traffic to IPv6 as much as possible. 272 Secondly, it is intended to allow IPv4-only nodes to correspond 273 directly with IPv6 nodes in the MAP-T domain that have IPv4 embedded 274 IPv6 addresses as per [RFC6052]). 276 The MAP-T architecture is based on the following key properties i) 277 algorithmic IPv4-IPv6 address mapping codified as MAP Rules covered 278 in Section 5 ii) A MAP IPv6 address identifier, described in 279 Section 6 iii) MAP-T IPv4-IPv6 forwarding behavior described in 280 Section 8. 282 5. Mapping Rules 284 The MAP-T algorithmic mapping rules are identical to those in 285 Section 5 of the MAP-E specification [I-D.ietf-softwire-map], with 286 the exception of Section 5.4 concerning the forwarding of traffic to/ 287 from IPv4 nodes outside the MAP-T. 289 5.1. Destinations outside the MAP domain 291 IPv4 traffic sent by MAP nodes that are all within one MAP domain is 292 translated to IPv6, with the sender's MAP IPv6 address, derived via 293 the BMR, as the IPv6 source address and the recipient's MAP IPv6 294 address, derived via the FMR, as the IPv6 destination address. 296 IPv4 destinations outside of the MAP domain are represented by means 297 of IPv4-Embedded IPv6 address s per [RFC6052], using the BR's IPv6 298 prefix. For a CE sending traffic to any such destination the source 299 address of the IPv6 packet will be the CE's MAP IPv6 address and the 300 destination IPv6 address will be the destination IPv4-embedded-IPv6 301 address. This representation is termed as the MAP-T Default Mapping 302 Rule (DMR) and is specified in terms of an IPv6 prefix advertised by 303 one or more BRs. A typical MAP-T CE will install an IPv4 default 304 route using this rule. A BR will use this rule when translating all 305 outside IPv4 source addresses to the IPv6 MAP domain. 307 It is recommended that the DMR IPv6 prefix-length SHOULD be by 308 default 64 bits long, and in any case MUST NOT exceed 96 bits. The 309 mapping of the IPv4 destination behind the IPv6 prefix will by 310 default follow the /64 rule as per [RFC6052]. Any trailing bits 311 after the IPv4 address are set to 0x0. 313 6. The IPv6 Interface Identifier 315 The Interface identifier format of a MAP-T node is the same as 316 described in section 6 of [I-D.ietf-softwire-map]. For convenience 317 this is cited below: 319 | 128-n-o-s bits | 320 | 16 bits| 32 bits | 16 bits| 321 +--------+----------------+--------+ 322 | 0 | IPv4 address | PSID | 323 +--------+----------------+--------+ 325 Figure 2 327 In the case of an IPv4 prefix, the IPv4 address field is right-padded 328 with zeros up to 32 bits. The PSID is zero left-padded to create a 329 16 bit field. For an IPv4 prefix or a complete IPv4 address, the 330 PSID field is zero. 332 If the End-user IPv6 prefix length is larger than 64, the most 333 significant parts of the interface identifier is overwritten by the 334 prefix. 336 7. MAP-T Configuration 338 For a given MAP domain, the BR and CE MUST be configured with the 339 following MAP parameters. The values for these parameters are 340 identical for all CEs and BRs within a given MAP-T domain. 342 o The Basic Mapping Rule and optionally the Forwarding Mapping 343 Rules, including the Rule IPv6 prefix, Rule IPv4 prefix, and 344 Length of Embedded Address bits 346 o Use of Hub and spoke mode or Mesh mode. (If all traffic should be 347 sent to the BR, or if direct CE to CE correspondence should be 348 supported). 350 o Use of Translation mode (MAP-T) 352 o The BR's IPv6 prefix used in the DMR 354 7.1. MAP CE 356 For a given MAP domain, the MAP configuration parameters that are the 357 same across all CEs within that domain. These values may be 358 configured using a variety of methods, including DHCPv6, Broadband 359 Forum's "TR-69" Residential Gateway management interface, Netconf, or 360 manual configuration. This document does not prescribe any of these 361 methods, but recommends that a MAP CE SHOULD implement DHCPv6 options 362 as per [I-D.ietf-softwire-map-dhcp]. Other configuration and 363 management methods may use the data model described by this option 364 for consistency and convenience of implementation on CEs that support 365 multiple configuration methods. 367 Besides the MAP configuration parameters, a CE requires an the IPv6 368 prefix to be assigned to the CE. This End-user IPv6 prefix is 369 configured as part of obtaining IPv6 Internet access, and is acquired 370 using standard IPv6 means applicable in the network where the CE is 371 located. 373 The MAP provisioning parameters, and hence the IPv4 service itself, 374 are tied to the End-user IPv6 prefix; thus, the MAP service is also 375 tied to this in terms of authorization, accounting, etc. 377 A single MAP CE MAY be connected to more than one MAP domain, just as 378 any router may have more than one IPv4-enabled service provider 379 facing interface and more than one set of associated addresses 380 assigned by DHCPv6. Each domain a given CE operates within would 381 require its own set of MAP configuration elements and would generate 382 its own IPv4 address. Each MAP domain requires a distinct End-user 383 IPv6 prefix. 385 The MAP DHCPv6 option is specified in [I-D.ietf-softwire-map-dhcp] 387 7.2. MAP BR 389 The MAP BR MUST be configured with the same MAP elements as the MAP 390 CEs operating within the same domain. 392 For increased reliability and load balancing, the BR IPv6 prefix MAY 393 be shared across a given MAP domain. As MAP is stateless, any BR may 394 be used for forwarding to/from the domain at any time. 396 Since MAP uses provider address space, no specific routes need to be 397 advertised externally for MAP to operate, neither in IPv6 nor IPv4 398 BGP. However, the BR prefix needs to be advertised in the service 399 provider's IGP. 401 8. MAP-T Packet Forwarding 403 The end-end packet flow in MAP-T involves an IPv4 or IPv6 packet 404 being forwarded by a CE of BR in one of two directions for each such 405 case. This section presents a conceptual view of the operations 406 involved in such forwarding. 408 8.1. IPv4 to IPv6 at the CE 410 A MAP-T CE receiving IPv4 packets SHOULD perform NAPT NAT44 function, 411 and create any necessary NAPT44 bindings. The source address and 412 port of the packet obtained as a result of the NAPT44 process MUST 413 correspond to the source IPv4 address and source transport port 414 number derived to belong to the CE by means of the MAP Basic Mapping 415 Rule (BMR). 417 The IPv4 packet is subject to a longest IPv4 destination address + 418 port match MAP rule selection, which then determines the parameters 419 for the subsequent NAT64 operation. By default, all traffic is 420 matched to the default mapping rule (DMR), and subject to the 421 stateless NAT64 operation using the DMR parameters for NAT64 422 Section 5.1. Packets that are matched to (optional) Forward Mapping 423 Rules (FMRs) are subject to the stateless NAT64 operation using the 424 FMR parameters Section 5 for the MAP algorithm. In all cases the 425 CE's MAP IPv6 address Section 6 is used as a source address. 427 A MAP-T CE MUST support a Default Mapping Rule and SHOULD support one 428 or more Forward Mapping Rules. 430 8.2. IPv6 to IPv4 at the CE 432 A MAP-T CE receiving an IPv6 packet performs its regular IPv6 433 operations (filtering, pre-routing, etc). Only packets that are 434 addressed to the CE's MAP-T IPv6 addresses, and with source addresses 435 matching the IPv6 map-rule prefixes of a DMR or FMR, are processed by 436 the MAP-T CE, with the DMR or FMR being selected based on a longest 437 match. The CE MUST check that MAP-T received packets' destination 438 transport-layer destination port number is in the range allowed for 439 by the CE's MAP BMR configuration. The CE MUST silently drop any non 440 conforming packets and an appropriate counter incremented. For 441 packets whose source address longest matches an FMR prefix, the CE 442 MUST perform a check of consistency of the source address against the 443 allowed values from the derived source port-range. If the packets' 444 source port number is found to be outside the range allowed, the CE 445 MUST drop the packet and SHOULD respond with an ICMPv6 "Destination 446 Unreachable, Source address failed ingress/egress policy" (Type 1, 447 Code 5). 449 For each MAP-T packet, the CE's NAT64 function MUST derive the IPv4 450 source and destination addresses. The IPv4 destination address is 451 derived by extracting relevant information from the IPv6 destination 452 and the information stored in the BMR as per Section 5. The IPv4 453 source address is formed by classifying the packet's source as 454 longest matching a DMR or FMR rule prefix, and then using the 455 respective rule parameters for the NAT64 operation. 457 The resulting IPv4 packet is then forwarded to the CE's NAPT NAPT44 458 function, where the destination IPv4 address and port number MUST be 459 mapped to their original value, before being forwarded according to 460 the CE's regular IPv4 rules. When the NAPT44 function is not 461 enabled, by virtue of MAP configuration, the traffic from the 462 stateless NAT64 function is directly forwarded according to the CE's 463 IPv4 rules. 465 8.3. IPv6 to IPv4 at the BR 467 A MAP-T BR receiving IPv6 packets MUST select a matching MAP rule 468 based on a longest address match of the packets' source address 469 against the BR's configured MAP Rules. In combination with the port- 470 set-id derived from the packet's source IPv6 address, the selected 471 MAP rule allows the BR to verify that the CE is using its allowed 472 address and port range. Thus, the BR MUST perform a validation of 473 the consistency of the source against the allowed values from the 474 identified port-range. If the packets' source port number is found 475 to be outside the range allowed, the BR MUST drop the packet and 476 increment a counter to indicate that a potential spoofing attack may 477 be underway. 479 When constructing the IPv4 packet, the BR MUST derive the source and 480 destination IPv4 addresses as per Section 5 of this document and 481 translate the IPv6 to IPv4 headers as per [RFC6145]. The resulting 482 IPv4 packets are then passed to regular IPv4 forwarding. 484 8.4. IPv4 to IPv6 at the BR 486 A MAP-T BR receiving IPv4 packets uses a longest match IPv4 + 487 transport layer port lookup to identify the target MAP-T domain and 488 select the FMR and DMR rules. The MAP-T BR MUST then compute and 489 apply the IPv6 destination addresses from the IPv4 destination 490 address and port as per the selected FMR. The MAP-T BR MUST also 491 compute and apply the IPv6 source addresses from the IPv4 source 492 address as per Section 5.1 (i.e. Using the IPv4 source and the BR's 493 IPv6 prefix it forms an IPv6 embedded IPv4 address). Throughout the 494 generic IPv4 to IPv6 header translation procedures following 495 [RFC6145] apply. The resulting IPv6 packets are then passed to 496 regular IPv6 forwarding. 498 Note that the operation of a BR when forwarding to/from MAP-T domains 499 that are defined without IPv4 address sharing is the same as that of 500 stateless NAT64 IPv4/IPv6 translation. 502 9. ICMP Handling 504 MAP-T CEs and BRs MUST follow ICMP/ICMPv6 translation as per 505 [RFC6145], however additional behavior is also required due to the 506 presence of NAPT44. Unlike TCP and UDP, which provide two transport 507 protocol port fields to represent both source and destination, the 508 ICMP/ICMPv6 [RFC0792], [RFC4443] Query message header has only one ID 509 field which needs to be used to identify a sending IPv4 host. When 510 receiving IPv4 ICMP messages, the MAP-T CE MUST rewrite the ID field 511 to a port value derived from the CE's Port-set-id. In the return 512 path, a MAP-T BR receiving an IPv4 ICMP packet containing an ID field 513 which is bound for a shared address in the MAP-T domain, the MAP-T BR 514 SHOULD use the ID value as a substitute for the destination port in 515 determining the IPv6 destination address. In all other cases, the 516 MAP-T BR MUST derive the destination IPv6 address by simply mapping 517 the destination IPv4 address without additional port info. 519 10. Fragmentation and Path MTU Discovery 521 Due to the different sizes of the IPv4 and IPv6 header, handling the 522 maximum packet size is relevant for the operation of any system 523 connecting the two address families. There are three mechanisms to 524 handle this issue: Path MTU discovery (PMTUD), fragmentation, and 525 transport-layer negotiation such as the TCP Maximum Segment Size 526 (MSS) option [RFC0897]. MAP uses all three mechanisms to deal with 527 different cases. 529 10.1. Fragmentation in the MAP domain 531 Translating an IPv4 packet to carry it across the MAP domain will 532 increase its size typically by 20 bytes. It is strongly recommended 533 that the MTU in the MAP domain be well managed and that the IPv6 MTU 534 on the CE WAN side interface be set so that no fragmentation occurs 535 within the boundary of the MAP domain. 537 Fragmentation in MAP-T domain is to be handled as described in 538 section 4 and 5 of [RFC6145]. 540 10.2. Receiving IPv4 Fragments on the MAP domain borders 542 Forwarding of an IPv4 packet received from the outside of the MAP 543 domain requires the IPv4 destination address and the transport 544 protocol destination port. The transport protocol information is 545 only available in the first fragment received. As described in 546 section 5.3.3 of [RFC6346] a MAP node receiving an IPv4 fragmented 547 packet from outside has to reassemble the packet before sending the 548 packet onto the MAP domain. If the first packet received contains 549 the transport protocol information, it is possible to optimize this 550 behavior by using a cache and forwarding the fragments unchanged. A 551 description of such a caching algorithm is outside the scope of this 552 document. 554 10.3. Sending IPv4 fragments to the outside 556 Two IPv4 hosts behind two different MAP CE's with the same IPv4 557 address sending fragments to an IPv4 destination host outside the 558 domain may happen to use the same IPv4 fragmentation identifier, 559 resulting in incorrect reassembly of the fragments at the destination 560 host. Given that the IPv4 fragmentation identifier is a 16 bit 561 field, it can be used similarly to port ranges. Thus, a MAP CE 562 SHOULD rewrite the IPv4 fragmentation identifier to a value 563 equivalent to a port of its allocated port-set. 565 11. NAT44 Considerations 567 The NAT44 implemented in the MAP CE SHOULD conform with the behavior 568 and best current practice documented in [RFC4787], [RFC5508], and 569 [RFC5382]. In MAP address sharing mode (determined by the MAP domain 570 /rule configuration parameters) the operation of the NAT44 MUST be 571 restricted to the available port numbers derived via the basic 572 mapping rule. 574 12. Usage Considerations 576 12.1. EA-bit length 0 578 The MAP solution supports use and configuration of domains where a 579 BMR expresses an EA-bit length of 0. This results in independence 580 between the IPv6 prefix assigned to the CE and the IPv4 address and/ 581 or port-range used by MAP. The k-bits of PSID information may in 582 this case be derived from the BMR. 584 The constraint imposed is that each such MAP domain be composed of 585 just 1 MAP CE which has a predetermined IPv6 end-user prefix. The BR 586 would be configured with an FMR for each such CPE, where the rule 587 would uniquely associate the IPv4 address + optional PSID and the 588 IPv6 prefix of that given CE. 590 12.2. Mesh and Hub and spoke modes 592 The hub and spoke mode of communication, whereby all traffic sent by 593 a MAP-T CE is forwarded via a BR, and the mesh mode, whereby a CE is 594 directly able to forward traffic to another CE, are governed by the 595 activation of Forward Mapping Rule that cover the IPv4-prefix 596 destination, and port-index range. By default, a MAP CE configured 597 only with a BMR, as per this specification, will use it to configure 598 its IPv4 parameters and IPv6 MAP address without enabling mesh mode. 600 12.3. Communication with IPv6 servers in the MAP-T domain 602 By default, MAP-T allows communication between both IPv4-only and any 603 IPv6 enabled devices, as well as with native IPv6-only servers 604 provided that the servers are configured with an IPv4-mapped IPv6 605 address. This address could be part of the IPv6 prefix used by the 606 DMR in the MAP-T domain. Such IPv6 servers (e.g. An HTTP server, or 607 a web content cache device) are thus able to serve both IPv6 users as 608 well as IPv4-only users alike utilizing IPv6. Any such IPv6-only 609 servers SHOULD have both A and AAAA records in DNS. DNS64 [RFC6147] 610 become required only when IPv6 servers in the MAP-T domain are 611 expected themselves to initiate communication to external IPv4-only 612 hosts. 614 12.4. Compatibility with other NAT64 solutions 616 The MAP-T CEs NAT64 function is by default compatible for use with 617 [RFC6146] stateful NAT64 devices that are placed in the operator's 618 network. In such a case the MAP-T CE's DMR prefix is configured to 619 correspond to the NAT64 device prefix. This in effect allows the use 620 of MAP-T CEs in environments that need to perform statistical 621 multiplexing of IPv4 addresses, while utilizing stateful NAT64 622 devices, and can take the role of a CLAT as defined in [RFC6877]. 624 13. IANA Considerations 626 This specification does not require any IANA actions. 628 14. Security Considerations 630 Spoofing attacks: With consistency checks between IPv4 and IPv6 631 sources that are performed on IPv4/IPv6 packets received by MAP 632 nodes, MAP does not introduce any new opportunity for spoofing 633 attacks that would not already exist in IPv6. 635 Denial-of-service attacks: In MAP domains where IPv4 addresses are 636 shared, the fact that IPv4 datagram reassembly may be necessary 637 introduces an opportunity for DOS attacks. This is inherent to 638 address sharing, and is common with other address sharing 639 approaches such as DS-Lite and NAT64/DNS64. The best protection 640 against such attacks is to accelerate IPv6 support in both clients 641 and servers. 643 Routing-loop attacks: This attack may exist in some automatic 644 tunneling scenarios are documented in [RFC6324]. They cannot 645 exist with MAP because each BRs checks that the IPv6 source 646 address of a received IPv6 packet is a CE address based on 647 Forwarding Mapping Rule. 649 Attacks facilitated by restricted port-set: From hosts that are not 650 subject to ingress filtering of [RFC2827], some attacks are 651 possible by an attacker injecting spoofed packets during ongoing 652 transport connections ([RFC4953], [RFC5961], [RFC6056]. The 653 attacks depend on guessing which ports are currently used by 654 target hosts, and using an unrestricted port-set is preferable, 655 i.e. Using native IPv6 connections that are not subject to MAP 656 port-range restrictions. To minimize this type of attacks when 657 using a restricted port set, the MAP CE's NAT44 filtering behavior 658 SHOULD be "Address-Dependent Filtering". Furthermore, the MAP CEs 659 SHOULD use a DNS transport proxy function to handle DNS traffic, 660 and source such traffic from IPv6 interfaces not assigned to 661 MAP-T. Practicalities of these methods are discussed in 662 Section 5.9 of [I-D.dec-stateless-4v6]. 664 ICMP Flooding Given the necessity to process and translate ICMP and 665 ICMPv6 messages by the BR and CE nodes, a foreseeable attack 666 vector is that of a flood of such messages leading to a saturation 667 of the nodes' ICMP computing resources. This attack vector is not 668 specific to MAP, and its mitigation lies a combination of policing 669 the rate of ICMP messages, policing the rate at which such 670 messages can get processed by the MAP nodes, and of course 671 identifying and blocking off the source(s) of such traffic. 673 [RFC6269] outlines general issues with IPv4 address sharing. 675 15. Contributors 677 The following individuals authored major contribution to this 678 document: 680 Chongfeng Xie (China Telecom) Room 708, No.118, Xizhimennei Street 681 Beijing 100035 CN Phone: +86-10-58552116 Email: xiechf@ctbri.com.cn 683 Qiong Sun (China Telecom) Room 708, No.118, Xizhimennei Street 684 Beijing 100035 CN Phone: +86-10-58552936 Email: sunqiong@ctbri.com.cn 686 Rajiv Asati (Cisco Systems) 7025-6 Kit Creek Road Research Triangle 687 Park NC 27709 USA Email: rajiva@cisco.comc 689 Gang Chen (China Mobile) 53A,Xibianmennei Ave. Beijing 100053 690 P.R.China Email: chengang@chinamobile.com 692 Wentao Shang (CERNET Center/Tsinghua University) Room 225, Main 693 Building, Tsinghua University Beijing 100084 CN Email: 694 wentaoshang@gmail.com 695 Guoliang Han (CERNET Center/Tsinghua University) Room 225, Main 696 Building, Tsinghua University Beijing 100084 CN Email: 697 bupthgl@gmail.com 699 Yu Zhai CERNET Center/Tsinghua University Room 225, Main Building, 700 Tsinghua University Beijing 100084 CN Email: jacky.zhai@gmail.com 702 16. Acknowledgements 704 This document is based on the ideas of many. In particular Remi 705 Despres, who has tirelessly worked on generalized mechanisms for 706 stateless address mapping. 708 The authors would like to thank Mohamed Boucadair, Guillaume Gottard, 709 Dan Wing, Jan Zorz, Nejc Scoberne, Tina Tsou, Gang Chen, Maoke Chen, 710 Xiaohong Deng, Jouni Korhonen, Tomasz Mrugalski, Jacni Qin, Chunfa 711 Sun, Qiong Sun, Leaf Yeh, Andrew Yourtchenko, Roberta Maglione and 712 Hongyu Chen for their review and comments. 714 17. References 716 17.1. Normative References 718 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 719 Requirement Levels", BCP 14, RFC 2119, March 1997. 721 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 722 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 723 October 2010. 725 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 726 Algorithm", RFC 6145, April 2011. 728 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 729 IPv4 Address Shortage", RFC 6346, August 2011. 731 17.2. Informative References 733 [I-D.dec-stateless-4v6] 734 Dec, W., Asati, R., and H. Deng, "Stateless 4Via6 Address 735 Sharing", draft-dec-stateless-4v6-04 (work in progress), 736 October 2011. 738 [I-D.ietf-softwire-map-dhcp] 739 Mrugalski, T., Troan, O., Dec, W., Bao, C., 740 leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options 741 for configuration of Softwire Address and Port Mapped 742 Clients", draft-ietf-softwire-map-dhcp-06 (work in 743 progress), November 2013. 745 [I-D.ietf-softwire-map] 746 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 747 Murakami, T., and T. Taylor, "Mapping of Address and Port 748 with Encapsulation (MAP)", draft-ietf-softwire-map-10 749 (work in progress), January 2014. 751 [I-D.ietf-softwire-stateless-4v6-motivation] 752 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 753 Borges, I., and G. Chen, "Motivations for Carrier-side 754 Stateless IPv4 over IPv6 Migration Solutions", draft-ietf- 755 softwire-stateless-4v6-motivation-05 (work in progress), 756 November 2012. 758 [I-D.maglione-softwire-map-t-scenarios] 759 Maglione, R., Dec, W., Leung, I., and E. Mallette, "Use 760 cases for MAP-T", draft-maglione-softwire- 761 map-t-scenarios-03 (work in progress), October 2013. 763 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 764 RFC 792, September 1981. 766 [RFC0897] Postel, J., "Domain name system implementation schedule", 767 RFC 897, February 1984. 769 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 770 Translator (NAT) Terminology and Considerations", RFC 771 2663, August 1999. 773 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 774 Defeating Denial of Service Attacks which employ IP Source 775 Address Spoofing", BCP 38, RFC 2827, May 2000. 777 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 778 Host Configuration Protocol (DHCP) version 6", RFC 3633, 779 December 2003. 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 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 790 Address Autoconfiguration", RFC 4862, September 2007. 792 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 793 4953, July 2007. 795 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 796 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 797 RFC 5382, October 2008. 799 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 800 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 801 April 2009. 803 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 804 Robustness to Blind In-Window Attacks", RFC 5961, August 805 2010. 807 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 808 Protocol Port Randomization", BCP 156, RFC 6056, January 809 2011. 811 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 812 NAT64: Network Address and Protocol Translation from IPv6 813 Clients to IPv4 Servers", RFC 6146, 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 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 826 Roberts, "Issues with IP Address Sharing", RFC 6269, June 827 2011. 829 [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using 830 IPv6 Automatic Tunnels: Problem Statement and Proposed 831 Mitigations", RFC 6324, August 2011. 833 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 834 Combination of Stateful and Stateless Translation", RFC 835 6877, April 2013. 837 Appendix A. Examples of MAP-T translation 839 Example 1 - Basic Mapping Rule: 841 Given the following MAP domain information and IPv6 end-user 842 prefix assigned to a MAP CE: 844 End-user IPv6 prefix: 2001:db8:0012:3400::/56 845 Basic Mapping Rule: {2001:db8:0000::/40 (Rule IPv6 prefix), 846 192.0.2.0/24 (Rule IPv4 prefix), 847 16 (Rule EA-bits length)} 848 PSID length: (16 - (32 - 24) = 8. (Sharing ratio of 256) 849 PSID offset: 6 (default) 851 A MAP node (CE or BR) can via the BMR, or equivalent FMR, 852 determine the IPv4 address and port-set as shown below: 854 EA bits offset: 40 855 IPv4 suffix bits (p): Length of IPv4 address (32) - IPv4 prefix 856 length (24) = 8 857 IPv4 address: 192.0.2.18 (0xc0000212) 858 PSID start: 40 + p = 40 + 8 = 48 859 PSID length (q): o - p = (End-user prefix len - 860 rule IPv6 prefix len) - p 861 = (56 - 40) - 8 = 8 862 PSID: 0x34 864 Available ports (63 ranges): 1232-1235, 2256-2259, ...... , 865 63696-63699, 64720-64723 867 The BMR information allows a MAP CE to determine (complete) 868 its IPv6 address within the indicated end-user IPv6 prefix. 870 IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212:0034 872 Example 2 - BR: 874 Another example can be made of a MAP-T BR, 875 configured with the following FMR when receiving a packet 876 with the following characteristics: 878 IPv4 source address: 1.2.3.4 (0x01020304) 879 TCP source port: 80 880 IPv4 destination address: 192.0.2.18 (0xc0000212) 881 TCP destination port: 1232 883 Forwarding Mapping Rule: {2001:db8::/40 (Rule IPv6 prefix), 884 192.0.2.0/24 (Rule IPv4 prefix), 885 16 (Rule EA-bits length)} 887 MAP-T BR Prefix (DMR): 2001:db8:ffff::/64 889 The above information allows the BR to derive as follows 890 the mapped destination IPv6 address for the corresponding 891 MAP-T CE, and also the source IPv6 address for 892 the mapped IPv4 source address. 894 IPv4 suffix bits (p): 32 - 24 = 8 (18 (0x12)) 895 PSID length: 8 896 PSID: 0 x34 (1232) 898 The resulting IPv6 packet will have the following header fields: 900 IPv6 source address: 2001:db8:ffff:0:0001:0203:0400:: 901 IPv6 destination address: 2001:db8:0012:3400:0000:c000:0212:0034 902 TCP source Port: 80 903 TCP destination Port: 1232 905 Example 3- FMR: 907 An IPv4 host behind a MAP-T CE (configured as per the previous 908 examples) corresponding with an IPv4 host 1.2.3.4 will have its 909 packets converted into IPv6 using the DMR configured on the MAP-T 910 CE as follows: 912 Default Mapping Rule: {2001:db8:ffff::/64 (Rule IPv6 prefix), 913 0.0.0.0/0 (Rule IPv4 prefix)} 915 IPv4 source address: 192.0.2.18 916 IPv4 destination address: 1.2.3.4 917 IPv4 source port: 1232 918 IPv4 destination port: 80 919 MAP-T CE IPv6 source address: 2001:db8:0012:3400:0000:c000:0212:0034 920 IPv6 destination address: 2001:db8:ffff:0:0001:0203:0400:: 922 Example 4 - Rule with no embedded address bits and no address sharing 924 End-user IPv6 prefix: 2001:db8:0012:3400::/56 925 Basic Mapping Rule: {2001:db8:0012:3400::/56 (Rule IPv6 prefix), 926 192.0.2.1/32 (Rule IPv4 prefix), 927 0 (Rule EA-bits length)} 928 PSID length: 0 (Sharing ratio is 1) 929 PSID offset: n/a 931 A MAP node can via the BMR or equivalent FMR, determine 932 the IPv4 address and port-set as shown below: 934 EA bits offset: 0 935 IPv4 suffix bits (p): Length of IPv4 address - IPv4 prefix 936 length = 32 - 32 = 0 937 IPv4 address: 192.0.2.18 (0xc0000212) 938 PSID start: 0 939 PSID length: 0 940 PSID: null 942 The BMR information allows a MAP CE also to determine (complete) 943 its full IPv6 address by combining the IPv6 prefix with the MAP 944 interface identifier (that embeds the IPv4 address). 946 IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0201:0000 947 Example 5 - Rule with no embedded address bits and address sharing 948 (sharing ratio 256) 950 End-user IPv6 prefix: 2001:db8:0012:3400::/56 951 Basic Mapping Rule: {2001:db8:0012:3400::/56 (Rule IPv6 prefix), 952 192.0.2.18/32 (Rule IPv4 prefix), 953 0 (Rule EA-bits length)} 954 PSID length: (16 - (32 - 24)) = 8. Sharing ratio of 256. 955 Provisioned with DHCPv6. 956 PSID offset: 6 (default) 957 PSID: 0x20 (Provisioned with DHCPv6) 959 A MAP node can via the BMR determine the IPv4 address and port-set 960 as shown below: 962 EA bits offset: 0 963 IPv4 suffix bits (p): Length of IPv4 address - IPv4 prefix 964 length = 32 -32 = 0 965 IPv4 address 192.0.2.18 (0xc0000212) 966 PSID start: 0 967 PSID length: 8 968 PSID: 0x34 970 Available ports (63 ranges) : 1232-1235, 2256-2259, ...... , 971 63696-63699, 64720-64723 973 The BMR information allows a MAP CE also to determine (complete) 974 its full IPv6 address by combining the IPv6 prefix with the MAP 975 interface identifier (that embeds the IPv4 address and PSID). 977 IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212:0034 979 Note that the IPv4 address and PSID is not derived from the IPv6 980 prefix assigned to the CE, but provisioned separately using for 981 example MAP options in DHCPv6. 983 Appendix B. Port mapping algorithm 985 The driving principles and the mathematical expression of the mapping 986 algorithm used by MAP can be found in Appendix B of 987 [I-D.ietf-softwire-map] 989 Authors' Addresses 990 Xing Li 991 CERNET Center/Tsinghua University 992 Room 225, Main Building, Tsinghua University 993 Beijing 100084 994 CN 996 Email: xing@cernet.edu.cn 998 Congxiao Bao 999 CERNET Center/Tsinghua University 1000 Room 225, Main Building, Tsinghua University 1001 Beijing 100084 1002 CN 1004 Email: congxiao@cernet.edu.cn 1006 Wojciech Dec (editor) 1007 Cisco Systems 1008 Haarlerbergpark Haarlerbergweg 13-19 1009 Amsterdam, NOORD-HOLLAND 1101 CH 1010 Netherlands 1012 Email: wdec@cisco.com 1014 Ole Troan 1015 Cisco Systems 1016 Oslo 1017 Norway 1019 Email: ot@cisco.com 1021 Satoru Matsushima 1022 SoftBank Telecom 1023 1-9-1 Higashi-Shinbashi, Munato-ku 1024 Tokyo 1025 Japan 1027 Email: satoru.matsushima@tm.softbank.co.jp 1028 Tetsuya Murakami 1029 IP Infusion 1030 1188 East Arques Avenue 1031 Sunnyvale 1032 USA 1034 Email: tetsuya@ipinfusion.com