idnits 2.17.1 draft-ietf-softwire-map-t-06.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 private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 14, 2014) is 3479 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-10 ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-09 == Outdated reference: A later version (-06) exists of draft-maglione-softwire-map-t-scenarios-04 -- 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: April 17, 2015 W. Dec, Ed. 6 O. Troan 7 Cisco Systems 8 S. Matsushima 9 SoftBank Telecom 10 T. Murakami 11 IP Infusion 12 October 14, 2014 14 Mapping of Address and Port using Translation (MAP-T) 15 draft-ietf-softwire-map-t-06 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 April 17, 2015. 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 . . . . . . . . . 12 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 . . 13 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 . . . . . . . . . . . 18 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-to-end 100 dual IP stack deployment. However, due to public IPv4 address 101 exhaustion this requires an IPv6 technology that supports IPv4 users 102 utilizing shared IPv4 addressing, while also allowing the network 103 operator to optimize their operations around IPv6 network practices. 104 The use of double NAT64 translation based solutions is an optimal way 105 to address these requirements, especially in combination with 106 stateless translation techniques that minimize operational challenges 107 outlined 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-T Mapping of Address and Port by means of 132 address Translation. 134 MAP Customer Edge (CE): A device functioning as a Customer Edge (CE) 135 router in a MAP deployment. A typical MAP CE 136 adopting MAP rules will serve a residential 137 site with one WAN side IPv6 addressed 138 interface, and one or more LAN side 139 interfaces addressed using private IPv4 140 addressing. 142 MAP Border Relay (BR): A MAP enabled router managed by the service 143 provider at the edge of a MAP domain. A 144 Border Relay (BR) router has at least an 145 IPv6-enabled interface and an IPv4 interface 146 connected to the native IPv4 network. A MAP 147 BR may also be referred to simply as a "BR" 148 within the context of MAP. 150 MAP domain: One or more MAP CEs and BRs connected by 151 means of an IPv6 network and sharing a common 152 set of MAP Rules. A service provider may 153 deploy a single MAP domain, or may utilize 154 multiple MAP domains. 156 MAP Rule: A set of parameters describing the mapping 157 between an IPv4 prefix, IPv4 address or 158 shared IPv4 address and an IPv6 prefix or 159 address. Each MAP domain uses a different 160 mapping rule set. 162 MAP Rule set: A Rule set is composed out of all the MAP 163 Rules communicated to a device, that are 164 intended for determining the devices' IP+port 165 mapping and forwarding operations. The MAP 166 Rule set is interchangeably referred to in 167 this document as a MAP Rule table or simply 168 Rule table. Two specific types of rules, 169 Basic Mapping Rule (BMR) and Forward Mapping 170 Rule (FMR), are defined in Section 5 of 171 [I-D.ietf-softwire-map]. The Default Mapping 172 Rule (DMR) is defined in this document. 174 MAP Rule table: See MAP Rule set. 176 MAP node: A device that implements MAP. 178 Port-set: Each node has a separate part of the 179 transport layer port space; denoted as a 180 port-set. 182 Port-set ID (PSID): Algorithmically identifies a set of ports 183 exclusively assigned to the CE. 185 Shared IPv4 address: An IPv4 address that is shared among multiple 186 CEs. Only ports that belong to the assigned 187 port-set can be used for communication. Also 188 known as a Port-Restricted IPv4 address. 190 End-user IPv6 prefix: The IPv6 prefix assigned to an End-user CE by 191 other means than MAP itself. E.g. 192 Provisioned using DHCPv6 PD [RFC3633], 193 assigned via SLAAC [RFC4862], or configured 194 manually. It is unique for each CE. 196 MAP IPv6 address: The IPv6 address used to reach the MAP 197 function of a CE from other CEs and from BRs. 199 Rule IPv6 prefix: An IPv6 prefix assigned by a Service Provider 200 for a MAP rule. 202 Rule IPv4 prefix: An IPv4 prefix assigned by a Service Provider 203 for a MAP rule. 205 Embedded Address (EA) bits: The IPv4 EA-bits in the IPv6 address 206 identify an IPv4 prefix/address (or part 207 thereof) or a shared IPv4 address (or part 208 thereof) and a port-set identifier. 210 4. Architecture 212 Figure 1 depicts the overall MAP-T architecture, which sees any 213 number of privately addressed IPv4 users (N and M) connected by means 214 of MAP-T CEs to an IPv6 network that is equipped with one or more 215 MAP-T BR. CEs and BRs that share MAP configuration parameters, 216 referred to as MAP rules, form a MAP-T Domain. 218 Functionally the MAP-T CE and BR utilize and extend some well 219 established technology building blocks to allow the IPv4 users to 220 correspond with nodes on the Public IPv4 network, or IPv6 network as 221 follows: 223 o A (NAT44) NAPT [RFC2663] function on a MAP CE is extended with 224 support for restricting the allowable TCP/UDP ports for a given 225 IPv4 address. The IPv4 address and port range used are determined 226 by the MAP provisioning process and identical to MAP-E 227 [I-D.ietf-softwire-map]. 229 o A stateless NAT64 function [RFC6145] is extended to allow 230 stateless mapping of IPv4 and transport layer port ranges to IPv6 231 address space. 233 User N 234 Private IPv4 235 | Network 236 | 237 O--+---------------O 238 | | MAP-T CE | 239 | +-----+--------+ | 240 | NAPT44| MAP-T | | 241 | +-----+ | +-._ ,-------. .------. 242 | +--------+ | ,-' `-. ,-' `-. 243 O------------------O / \ O---------O / Public \ 244 / IPv6 only \ | MAP-T |/ IPv4 \ 245 ( Network --+ Border +- Network ) 246 \ / | Relay |\ / 247 O------------------O \ / O---------O \ / 248 | MAP-T CE | ;". ,-' `-. ,-' 249 | +-----+--------+ | ," `----+--' ------' 250 | NAPT44| MAP-T | |, | 251 | +-----+ | + IPv6 node(s) 252 | | +--------+ | (w/ v4-embedded-v6 address) 253 O---+--------------O 254 | 255 User M 256 Private IPv4 257 Network 259 Figure 1: MAP-T Architecture 261 Each MAP-T CE is assigned with a regular IPv6 prefix from the 262 operator's IPv6 network. This, in conjunction with MAP domain 263 configuration settings and the use of the MAP procedures allows the 264 computation of a MAP IPv6 address and a corresponding IPv4 address. 265 To allow for IPv4 address sharing, the CE may also have be configured 266 with a TCP/UDP port-range that is identified by means of a MAP Port 267 Set Identifier (PSID) value. Each CE is responsible for forwarding 268 traffic between a given user's private IPv4 address space and the MAP 269 domain's IPv6 address space. The IPv4-IPv6 adaptation uses stateless 270 NAT64, in conjunction with the MAP algorithm for address computation. 272 The MAP-T BR connects one or more MAP-T domains to external IPv4 273 networks using stateless NAT64 as extended by the MAP-T behaviour 274 described in this document. 276 In contrast to MAP-E, NAT64 technology is used in the architecture 277 for two purposes. Firstly, it is intended to diminish encapsulation 278 overhead and allow IPv4 and IPv6 traffic to be treated as similarly 279 as possible. Secondly, it is intended to allow IPv4-only nodes to 280 correspond directly with IPv6 nodes in the MAP-T domain that have 281 IPv4 embedded IPv6 addresses as per [RFC6052]). 283 The MAP-T architecture is based on the following key properties i) 284 algorithmic IPv4-IPv6 address mapping codified as MAP Rules covered 285 in Section 5 ii) A MAP IPv6 address identifier, described in 286 Section 6 iii) MAP-T IPv4-IPv6 forwarding behavior described in 287 Section 8. 289 5. Mapping Rules 291 The MAP-T algorithmic mapping rules are identical to those in 292 Section 5 of the MAP-E specification [I-D.ietf-softwire-map], with 293 the following exception. The forwarding of traffic to and from IPv4 294 destinations outside a MAP-T domain is to be performed as described 295 here under, instead of Section 5.4 of the MAP-E specification. 297 5.1. Destinations outside the MAP domain 299 IPv4 traffic sent by MAP nodes that are all within one MAP domain is 300 translated to IPv6, with the sender's MAP IPv6 address, derived via 301 the Basic Mapping Rule (BMR), as the IPv6 source address and the 302 recipient's MAP IPv6 address, derived via the Forward Mapping Rule 303 (FMR), as the IPv6 destination address. 305 IPv4 addressed destinations outside of the MAP domain are represented 306 by means of IPv4-Embedded IPv6 address as per [RFC6052], using the 307 BR's IPv6 prefix. For a CE sending traffic to any such destination, 308 the source address of the IPv6 packet will be that of the CE's MAP 309 IPv6 address, and the destination IPv6 address will be the 310 destination IPv4-embedded-IPv6 address. This address mapping is 311 termed as following the MAP-T Default Mapping Rule (DMR) and is 312 defined in terms of the IPv6 prefix advertised by one or more BRs, 313 which provide external connectivity. A typical MAP-T CE will install 314 an IPv4 default route using this rule. A BR will use this rule when 315 translating all outside IPv4 source addresses to the IPv6 MAP domain. 317 The DMR IPv6 prefix-length SHOULD be by default 64 bits long, and in 318 any case MUST NOT exceed 96 bits. The mapping of the IPv4 319 destination behind the IPv6 prefix will by default follow the /64 320 rule as per [RFC6052]. Any trailing bits after the IPv4 address are 321 set to 0x0. 323 6. The IPv6 Interface Identifier 325 The Interface identifier format of a MAP-T node is the same as 326 described in section 6 of [I-D.ietf-softwire-map]. For convenience 327 this is cited below: 329 | 128-n-o-s bits | 330 | 16 bits| 32 bits | 16 bits| 331 +--------+----------------+--------+ 332 | 0 | IPv4 address | PSID | 333 +--------+----------------+--------+ 335 Figure 2 337 In the case of an IPv4 prefix, the IPv4 address field is right-padded 338 with zeros up to 32 bits. The PSID is zero left-padded to create a 339 16 bit field. For an IPv4 prefix or a complete IPv4 address, the 340 PSID field is zero. 342 If the End-user IPv6 prefix length is larger than 64, the most 343 significant parts of the interface identifier is overwritten by the 344 prefix. 346 7. MAP-T Configuration 348 For a given MAP domain, the BR and CE MUST be configured with the 349 following MAP parameters. The values for these parameters are 350 identical for all CEs and BRs within a given MAP-T domain. 352 o The Basic Mapping Rule and optionally the Forwarding Mapping 353 Rules, including the Rule IPv6 prefix, Rule IPv4 prefix, and 354 Length of Embedded Address bits 356 o Use of Hub and spoke mode or Mesh mode. (If all traffic should be 357 sent to the BR, or if direct CE to CE correspondence should be 358 supported). 360 o Use of IPv4-IPv6 Translation (MAP-T) 362 o The BR's IPv6 prefix used in the DMR 364 7.1. MAP CE 366 For a given MAP domain, the MAP configuration parameters are the same 367 across all CEs within that domain. These values may be conveyed and 368 configured on the CEs using a variety of methods, including; DHCPv6, 369 Broadband Forum's "TR-69" Residential Gateway management interface, 370 Netconf, or manual configuration. This document does not prescribe 371 any of these methods, but recommends that a MAP CE SHOULD implement 372 DHCPv6 options as per [I-D.ietf-softwire-map-dhcp]. Other 373 configuration and management methods may use the data model described 374 by this option for consistency and convenience of implementation on 375 CEs that support multiple configuration methods. 377 Besides the MAP configuration parameters, a CE requires an the IPv6 378 prefix to be assigned to the CE. This End-user IPv6 prefix is 379 configured as part of obtaining IPv6 Internet access, and is acquired 380 using standard IPv6 means applicable in the network where the CE is 381 located. 383 The MAP provisioning parameters, and hence the IPv4 service itself, 384 are tied to the End-user IPv6 prefix; thus, the MAP service is also 385 tied to this in terms of authorization, accounting, etc. 387 A single MAP CE MAY be connected to more than one MAP domain, just as 388 any router may have more than one IPv4-enabled service provider 389 facing interface and more than one set of associated addresses 390 assigned by DHCPv6. Each domain a given CE operates within would 391 require its own set of MAP configuration elements and would generate 392 its own IPv4 address. Each MAP domain requires a distinct End-user 393 IPv6 prefix. 395 7.2. MAP BR 397 The MAP BR MUST be configured with the same MAP elements as the MAP 398 CEs operating within the same domain. 400 For increased reliability and load balancing, the BR IPv6 prefix MAY 401 be shared across a given MAP domain. As MAP is stateless, any BR may 402 be used for forwarding to/from the domain at any time. 404 Since MAP uses provider address space, no specific routes need to be 405 advertised externally for MAP to operate, neither in IPv6 nor IPv4 406 BGP. However, the BR prefix needs to be advertised in the service 407 provider's IGP. 409 8. MAP-T Packet Forwarding 411 The end-to-end packet flow in MAP-T involves an IPv4 or IPv6 packet 412 being forwarded by a CE of BR in one of two directions for each such 413 case. This section presents a conceptual view of the operations 414 involved in such forwarding. 416 8.1. IPv4 to IPv6 at the CE 418 A MAP-T CE receiving IPv4 packets SHOULD perform NAPT NAT44 419 processing, and create any necessary NAPT44 bindings. The source 420 address and source port-range of packets resulting from the NAPT44 421 processing MUST correspond to the source IPv4 address and source 422 transport port-range assigned to the CE by means of the MAP Basic 423 Mapping Rule (BMR). 425 The IPv4 packet is subject to a longest IPv4 destination address + 426 port match MAP rule selection, which then determines the parameters 427 for the subsequent NAT64 operation. By default, all traffic is 428 matched to the default mapping rule (DMR), and subject to the 429 stateless NAT64 operation using the DMR parameters for NAT64 430 Section 5.1. Packets that are matched to (optional) Forward Mapping 431 Rules (FMRs) are subject to the stateless NAT64 operation using the 432 FMR parameters Section 5 for the MAP algorithm. In all cases the 433 CE's MAP IPv6 address Section 6 is used as a source address. 435 A MAP-T CE MUST support a Default Mapping Rule and SHOULD support one 436 or more Forward Mapping Rules. 438 8.2. IPv6 to IPv4 at the CE 440 A MAP-T CE receiving an IPv6 packet performs its regular IPv6 441 operations (filtering, pre-routing, etc). Only packets that are 442 addressed to the CE's MAP-T IPv6 addresses, and with source addresses 443 matching the IPv6 map-rule prefixes of a DMR or FMR, are processed by 444 the MAP-T CE, with the DMR or FMR being selected based on a longest 445 match. The CE MUST check that each MAP-T received packet's 446 destination transport-layer destination port number is in the range 447 allowed for by the CE's MAP BMR configuration. The CE MUST silently 448 drop any non conforming packet and an appropriate counter 449 incremented. When receiving a packet whose source IP address longest 450 matches an FMR prefix, the CE MUST perform a check of consistency of 451 the source address against the allowed values as per the derived 452 allocated source port-range. If the source port number of a packet 453 is found to be outside the allocated range, the CE MUST drop the 454 packet and SHOULD respond with an ICMPv6 "Destination Unreachable, 455 Source address failed ingress/egress policy" (Type 1, Code 5). 457 For each MAP-T processed packet, the CE's NAT64 function MUST compute 458 an IPv4 source and destination addresses. The IPv4 destination 459 address is computed by extracting relevant information from the IPv6 460 destination and the information stored in the BMR as per Section 5. 461 The IPv4 source address is formed by classifying a packet's source as 462 longest matching a DMR or FMR rule prefix, and then using the 463 respective rule parameters for the NAT64 operation. 465 The resulting IPv4 packet is then forwarded to the CE's NAPT NAPT44 466 function, where the destination IPv4 address and port number MUST be 467 mapped to their original value, before being forwarded according to 468 the CE's regular IPv4 rules. When the NAPT44 function is not 469 enabled, by virtue of MAP configuration, the traffic from the 470 stateless NAT64 function is directly forwarded according to the CE's 471 IPv4 rules. 473 8.3. IPv6 to IPv4 at the BR 475 A MAP-T BR receiving an IPv6 packet MUST select a matching MAP rule 476 based on a longest address match of the packet's source address 477 against the MAP Rules present on the BR. In combination with the 478 Port-Set-Id derived from the packet's source IPv6 address, the 479 selected MAP rule allows the BR to verify that the CE is using its 480 allowed address and port range. Thus, the BR MUST perform a 481 validation of the consistency of the source against the allowed 482 values from the identified port-range. If the packet's source port 483 number is found to be outside the range allowed, the BR MUST drop the 484 packet and increment a counter to indicate the event. The BR SHOULD 485 also respond with an ICMPv6 "Destination Unreachable, Source address 486 failed ingress/egress policy" (Type 1, Code 5). 488 When constructing the IPv4 packet, the BR MUST derive the source and 489 destination IPv4 addresses as per Section 5 of this document and 490 translate the IPv6 to IPv4 headers as per [RFC6145]. The resulting 491 IPv4 packet is then passed to regular IPv4 forwarding. 493 8.4. IPv4 to IPv6 at the BR 495 A MAP-T BR receiving IPv4 packets uses a longest match IPv4 + 496 transport layer port lookup to identify the target MAP-T domain and 497 select the FMR and DMR rules. The MAP-T BR MUST then compute and 498 apply the IPv6 destination addresses from the IPv4 destination 499 address and port as per the selected FMR. The MAP-T BR MUST also 500 compute and apply the IPv6 source addresses from the IPv4 source 501 address as per Section 5.1 (i.e. Using the IPv4 source and the BR's 502 IPv6 prefix it forms an IPv6 embedded IPv4 address). Throughout the 503 generic IPv4 to IPv6 header translation procedures following 504 [RFC6145] apply. The resulting IPv6 packets are then passed to 505 regular IPv6 forwarding. 507 Note that the operation of a BR when forwarding to/from MAP-T domains 508 that are defined without IPv4 address sharing is the same as that of 509 stateless NAT64 IPv4/IPv6 translation. 511 9. ICMP Handling 513 MAP-T CEs and BRs MUST follow ICMP/ICMPv6 translation as per 514 [RFC6145], however additional behavior is also required due to the 515 presence of NAPT44. Unlike TCP and UDP, which provide two transport 516 protocol port fields to represent both source and destination, the 517 ICMP/ICMPv6 [RFC0792], [RFC4443] Query message header has only one ID 518 field which needs to be used to identify a sending IPv4 host. When 519 receiving IPv4 ICMP messages, the MAP-T CE MUST rewrite the ID field 520 to a port value derived from the CE's Port-Set-Id. 522 A MAP-T BR receiving an IPv4 ICMP packet , which contains an ID field 523 that is bound for a shared address in the MAP-T domain, SHOULD use 524 the ID value as a substitute for the destination port in determining 525 the IPv6 destination address. In all other cases, the MAP-T BR MUST 526 derive the destination IPv6 address by simply mapping the destination 527 IPv4 address without additional port info. 529 10. Fragmentation and Path MTU Discovery 531 Due to the different sizes of the IPv4 and IPv6 header, handling the 532 maximum packet size is relevant for the operation of any system 533 connecting the two address families. There are three mechanisms to 534 handle this issue: Path MTU discovery (PMTUD), fragmentation, and 535 transport-layer negotiation such as the TCP Maximum Segment Size 536 (MSS) option [RFC0897]. MAP uses all three mechanisms to deal with 537 different cases. 539 10.1. Fragmentation in the MAP domain 541 Translating an IPv4 packet to carry it across the MAP domain will 542 increase its size typically by 20 bytes. The MTU in the MAP domain 543 should be well managed and the IPv6 MTU on the CE WAN side interface 544 SHOULD be configured so that no fragmentation occurs within the 545 boundary of the MAP domain. 547 Fragmentation in MAP-T domain SHOULD be handled as described in 548 section 4 and 5 of [RFC6145]. 550 10.2. Receiving IPv4 Fragments on the MAP domain borders 552 Forwarding of an IPv4 packet received from the outside of the MAP 553 domain requires the IPv4 destination address and the transport 554 protocol destination port. The transport protocol information is 555 only available in the first fragment received. As described in 556 section 5.3.3 of [RFC6346] a MAP node receiving an IPv4 fragmented 557 packet from outside SHOULD reassemble the packet before sending the 558 packet onto the MAP domain. If the first packet received contains 559 the transport protocol information, it is possible to optimize this 560 behavior by using a cache and forwarding the fragments unchanged. A 561 description of such a caching algorithm is outside the scope of this 562 document. 564 10.3. Sending IPv4 fragments to the outside 566 Two IPv4 hosts behind two different MAP CE's with the same IPv4 567 address sending fragments to an IPv4 destination host outside the 568 domain may happen to use the same IPv4 fragmentation identifier, 569 resulting in incorrect reassembly of the fragments at the destination 570 host. Given that the IPv4 fragmentation identifier is a 16 bit 571 field, it can be used similarly to port ranges. Thus, a MAP CE 572 SHOULD rewrite the IPv4 fragmentation identifier to a value 573 equivalent to a port of its allocated port-set. 575 11. NAT44 Considerations 577 The NAT44 implemented in the MAP CE SHOULD conform with the behavior 578 and best current practice documented in [RFC4787], [RFC5508], and 579 [RFC5382]. In MAP address sharing mode (determined by the MAP domain 580 /rule configuration parameters) the operation of the NAT44 MUST be 581 restricted to the available port numbers derived via the basic 582 mapping rule. 584 12. Usage Considerations 586 12.1. EA-bit length 0 588 The MAP solution supports use and configuration of domains where a 589 BMR expresses an EA-bit length of 0. This results in independence 590 between the IPv6 prefix assigned to the CE and the IPv4 address and/ 591 or port-range used by MAP. The k-bits of PSID information may in 592 this case be derived from the BMR. 594 The constraint imposed is that each such MAP domain be composed of 595 just 1 MAP CE which has a predetermined IPv6 end-user prefix. The BR 596 would be configured with an FMR for each such CPE, where the rule 597 would uniquely associate the IPv4 address + optional PSID and the 598 IPv6 prefix of that given CE. 600 12.2. Mesh and Hub and spoke modes 602 The hub and spoke mode of communication, whereby all traffic sent by 603 a MAP-T CE is forwarded via a BR, and the mesh mode, whereby a CE is 604 directly able to forward traffic to another CE, are governed by the 605 activation of Forward Mapping Rule that cover the IPv4-prefix 606 destination, and port-index range. By default, a MAP CE configured 607 only with a BMR, as per this specification, will use it to configure 608 its IPv4 parameters and IPv6 MAP address without enabling mesh mode. 610 12.3. Communication with IPv6 servers in the MAP-T domain 612 By default, MAP-T allows communication between both IPv4-only and any 613 IPv6 enabled devices, as well as with native IPv6-only servers 614 provided that the servers are configured with an IPv4-mapped IPv6 615 address. This address could be part of the IPv6 prefix used by the 616 DMR in the MAP-T domain. Such IPv6 servers (e.g. An HTTP server, or 617 a web content cache device) are thus able to serve both IPv6 users as 618 well as IPv4-only users alike utilizing IPv6. Any such IPv6-only 619 servers SHOULD have both A and AAAA records in DNS. DNS64 [RFC6147] 620 become required only when IPv6 servers in the MAP-T domain are 621 expected themselves to initiate communication to external IPv4-only 622 hosts. 624 12.4. Compatibility with other NAT64 solutions 626 The MAP-T CEs NAT64 function is by default compatible for use with 627 [RFC6146] stateful NAT64 devices that are placed in the operator's 628 network. In such a case the MAP-T CE's DMR prefix is configured to 629 correspond to the NAT64 device prefix. This in effect allows the use 630 of MAP-T CEs in environments that need to perform statistical 631 multiplexing of IPv4 addresses, while utilizing stateful NAT64 632 devices, and can take the role of a CLAT as defined in [RFC6877]. 634 13. IANA Considerations 636 This specification does not require any IANA actions. 638 14. Security Considerations 640 Spoofing attacks: With consistency checks between IPv4 and IPv6 641 sources that are performed on IPv4/IPv6 packets received by MAP 642 nodes, MAP does not introduce any new opportunity for spoofing 643 attacks that would not already exist in IPv6. 645 Denial-of-service attacks: In MAP domains where IPv4 addresses are 646 shared, the fact that IPv4 datagram reassembly may be necessary 647 introduces an opportunity for DOS attacks. This is inherent to 648 address sharing, and is common with other address sharing 649 approaches such as DS-Lite and NAT64/DNS64. The best protection 650 against such attacks is to accelerate IPv6 support in both clients 651 and servers. 653 Routing-loop attacks: This attack may exist in some automatic 654 tunneling scenarios are documented in [RFC6324]. They cannot 655 exist with MAP because each BRs checks that the IPv6 source 656 address of a received IPv6 packet is a CE address based on 657 Forwarding Mapping Rule. 659 Attacks facilitated by restricted port-set: From hosts that are not 660 subject to ingress filtering of [RFC2827], some attacks are 661 possible by an attacker injecting spoofed packets during ongoing 662 transport connections ([RFC4953], [RFC5961], [RFC6056]. The 663 attacks depend on guessing which ports are currently used by 664 target hosts, and using an unrestricted port-set is preferable, 665 i.e. Using native IPv6 connections that are not subject to MAP 666 port-range restrictions. To minimize this type of attacks when 667 using a restricted port set, the MAP CE's NAT44 filtering behavior 668 SHOULD be "Address-Dependent Filtering". Furthermore, the MAP CEs 669 SHOULD use a DNS transport proxy function to handle DNS traffic, 670 and source such traffic from IPv6 interfaces not assigned to MAP- 671 T. Practicalities of these methods are discussed in Section 5.9 672 of [I-D.dec-stateless-4v6]. 674 ICMP Flooding Given the necessity to process and translate ICMP and 675 ICMPv6 messages by the BR and CE nodes, a foreseeable attack 676 vector is that of a flood of such messages leading to a saturation 677 of the node's ICMP computing resources. This attack vector is not 678 specific to MAP, and its mitigation lies a combination of policing 679 the rate of ICMP messages, policing the rate at which such 680 messages can get processed by the MAP nodes, and of course 681 identifying and blocking off the source(s) of such traffic. 683 [RFC6269] outlines general issues with IPv4 address sharing. 685 15. Contributors 687 The following individuals authored major contributions to this 688 document, and made the document possible: 690 Chongfeng Xie (China Telecom) Room 708, No.118, Xizhimennei Street 691 Beijing 100035 CN Phone: +86-10-58552116 Email: xiechf@ctbri.com.cn 693 Qiong Sun (China Telecom) Room 708, No.118, Xizhimennei Street 694 Beijing 100035 CN Phone: +86-10-58552936 Email: sunqiong@ctbri.com.cn 696 Rajiv Asati (Cisco Systems) 7025-6 Kit Creek Road Research Triangle 697 Park NC 27709 USA Email: rajiva@cisco.comc 699 Gang Chen (China Mobile) 53A,Xibianmennei Ave. Beijing 100053 700 P.R.China Email: chengang@chinamobile.com 702 Wentao Shang (CERNET Center/Tsinghua University) Room 225, Main 703 Building, Tsinghua University Beijing 100084 CN Email: 704 wentaoshang@gmail.com 706 Guoliang Han (CERNET Center/Tsinghua University) Room 225, Main 707 Building, Tsinghua University Beijing 100084 CN Email: 708 bupthgl@gmail.com 710 Yu Zhai CERNET Center/Tsinghua University Room 225, Main Building, 711 Tsinghua University Beijing 100084 CN Email: jacky.zhai@gmail.com 713 16. Acknowledgements 715 This document is based on the ideas of many. In particular Remi 716 Despres, who has tirelessly worked on generalized mechanisms for 717 stateless address mapping. 719 The authors would also like to thank Mohamed Boucadair, Guillaume 720 Gottard, Dan Wing, Jan Zorz, Nejc Scoberne, Tina Tsou, Gang Chen, 721 Maoke Chen, Xiaohong Deng, Jouni Korhonen, Tomasz Mrugalski, Jacni 722 Qin, Chunfa Sun, Qiong Sun, Leaf Yeh, Andrew Yourtchenko, Roberta 723 Maglione and Hongyu Chen for their review and comments. 725 17. References 727 17.1. Normative References 729 [I-D.ietf-softwire-map] 730 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 731 Murakami, T., and T. Taylor, "Mapping of Address and Port 732 with Encapsulation (MAP)", draft-ietf-softwire-map-10 733 (work in progress), January 2014. 735 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 736 Requirement Levels", BCP 14, RFC 2119, March 1997. 738 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 739 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 740 October 2010. 742 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 743 Algorithm", RFC 6145, April 2011. 745 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 746 IPv4 Address Shortage", RFC 6346, August 2011. 748 17.2. Informative References 750 [I-D.dec-stateless-4v6] 751 Dec, W., Asati, R., and H. Deng, "Stateless 4Via6 Address 752 Sharing", draft-dec-stateless-4v6-04 (work in progress), 753 October 2011. 755 [I-D.ietf-softwire-map-dhcp] 756 Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, 757 W., Bao, C., leaf.yeh.sdo@gmail.com, l., and X. Deng, 758 "DHCPv6 Options for configuration of Softwire Address and 759 Port Mapped Clients", draft-ietf-softwire-map-dhcp-09 760 (work in progress), October 2014. 762 [I-D.ietf-softwire-stateless-4v6-motivation] 763 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 764 Borges, I., and G. Chen, "Motivations for Carrier-side 765 Stateless IPv4 over IPv6 Migration Solutions", draft-ietf- 766 softwire-stateless-4v6-motivation-05 (work in progress), 767 November 2012. 769 [I-D.maglione-softwire-map-t-scenarios] 770 Maglione, R., Dec, W., Leung, I., and E. Mallette, "Use 771 cases for MAP-T", draft-maglione-softwire-map- 772 t-scenarios-04 (work in progress), April 2014. 774 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 775 RFC 792, September 1981. 777 [RFC0897] Postel, J., "Domain name system implementation schedule", 778 RFC 897, February 1984. 780 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 781 Translator (NAT) Terminology and Considerations", RFC 782 2663, August 1999. 784 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 785 Defeating Denial of Service Attacks which employ IP Source 786 Address Spoofing", BCP 38, RFC 2827, May 2000. 788 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 789 Host Configuration Protocol (DHCP) version 6", RFC 3633, 790 December 2003. 792 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 793 Message Protocol (ICMPv6) for the Internet Protocol 794 Version 6 (IPv6) Specification", RFC 4443, March 2006. 796 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 797 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 798 RFC 4787, January 2007. 800 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 801 Address Autoconfiguration", RFC 4862, September 2007. 803 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 804 4953, July 2007. 806 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 807 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 808 RFC 5382, October 2008. 810 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 811 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 812 April 2009. 814 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 815 Robustness to Blind In-Window Attacks", RFC 5961, August 816 2010. 818 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 819 Protocol Port Randomization", BCP 156, RFC 6056, January 820 2011. 822 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 823 NAT64: Network Address and Protocol Translation from IPv6 824 Clients to IPv4 Servers", RFC 6146, April 2011. 826 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 827 Beijnum, "DNS64: DNS Extensions for Network Address 828 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 829 April 2011. 831 [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 832 China Education and Research Network (CERNET) IVI 833 Translation Design and Deployment for the IPv4/IPv6 834 Coexistence and Transition", RFC 6219, May 2011. 836 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 837 Roberts, "Issues with IP Address Sharing", RFC 6269, June 838 2011. 840 [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using 841 IPv6 Automatic Tunnels: Problem Statement and Proposed 842 Mitigations", RFC 6324, August 2011. 844 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 845 Combination of Stateful and Stateless Translation", RFC 846 6877, April 2013. 848 Appendix A. Examples of MAP-T translation 849 Example 1 - Basic Mapping Rule: 851 Given the following MAP domain information and IPv6 end-user 852 prefix assigned to a MAP CE: 854 End-user IPv6 prefix: 2001:db8:0012:3400::/56 855 Basic Mapping Rule: {2001:db8:0000::/40 (Rule IPv6 prefix), 856 192.0.2.0/24 (Rule IPv4 prefix), 857 16 (Rule EA-bits length)} 858 PSID length: (16 - (32 - 24) = 8. (Sharing ratio of 256) 859 PSID offset: 6 (default) 861 A MAP node (CE or BR) can via the BMR, or equivalent FMR, 862 determine the IPv4 address and port-set as shown below: 864 EA bits offset: 40 865 IPv4 suffix bits (p): Length of IPv4 address (32) - IPv4 prefix 866 length (24) = 8 867 IPv4 address: 192.0.2.18 (0xc0000212) 868 PSID start: 40 + p = 40 + 8 = 48 869 PSID length (q): o - p = (End-user prefix len - 870 rule IPv6 prefix len) - p 871 = (56 - 40) - 8 = 8 872 PSID: 0x34 874 Available ports (63 ranges): 1232-1235, 2256-2259, ...... , 875 63696-63699, 64720-64723 877 The BMR information allows a MAP CE to determine (complete) 878 its IPv6 address within the indicated end-user IPv6 prefix. 880 IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212:0034 882 Example 2 - BR: 884 Another example can be made of a MAP-T BR, 885 configured with the following FMR when receiving a packet 886 with the following characteristics: 888 IPv4 source address: 10.2.3.4 (0x0a020304) 889 TCP source port: 80 890 IPv4 destination address: 192.0.2.18 (0xc0000212) 891 TCP destination port: 1232 893 Forwarding Mapping Rule: {2001:db8::/40 (Rule IPv6 prefix), 894 192.0.2.0/24 (Rule IPv4 prefix), 895 16 (Rule EA-bits length)} 897 MAP-T BR Prefix (DMR): 2001:db8:ffff::/64 899 The above information allows the BR to derive as follows 900 the mapped destination IPv6 address for the corresponding 901 MAP-T CE, and also the source IPv6 address for 902 the mapped IPv4 source address. 904 IPv4 suffix bits (p): 32 - 24 = 8 (18 (0x12)) 905 PSID length: 8 906 PSID: 0 x34 (1232) 908 The resulting IPv6 packet will have the following header fields: 910 IPv6 source address: 2001:db8:ffff:0:000a:0203:0400:: 911 IPv6 destination address: 2001:db8:0012:3400:0000:c000:0212:0034 912 TCP source Port: 80 913 TCP destination Port: 1232 915 Example 3- FMR: 917 An IPv4 host behind a MAP-T CE (configured as per the previous 918 examples) corresponding with an IPv4 host 10.2.3.4 will have its 919 packets converted into IPv6 using the DMR configured on the MAP-T 920 CE as follows: 922 Default Mapping Rule: {2001:db8:ffff::/64 (Rule IPv6 prefix), 923 0.0.0.0/0 (Rule IPv4 prefix)} 925 IPv4 source address: 192.0.2.18 926 IPv4 destination address: 10.2.3.4 927 IPv4 source port: 1232 928 IPv4 destination port: 80 929 MAP-T CE IPv6 source address: 2001:db8:0012:3400:0000:c000:0212:0034 930 IPv6 destination address: 2001:db8:ffff:0:000a:0203:0400:: 932 Example 4 - Rule with no embedded address bits and no address sharing 934 End-user IPv6 prefix: 2001:db8:0012:3400::/56 935 Basic Mapping Rule: {2001:db8:0012:3400::/56 (Rule IPv6 prefix), 936 192.0.2.1/32 (Rule IPv4 prefix), 937 0 (Rule EA-bits length)} 938 PSID length: 0 (Sharing ratio is 1) 939 PSID offset: n/a 941 A MAP node can via the BMR or equivalent FMR, determine 942 the IPv4 address and port-set as shown below: 944 EA bits offset: 0 945 IPv4 suffix bits (p): Length of IPv4 address - IPv4 prefix 946 length = 32 - 32 = 0 947 IPv4 address: 192.0.2.18 (0xc0000212) 948 PSID start: 0 949 PSID length: 0 950 PSID: null 952 The BMR information allows a MAP CE also to determine (complete) 953 its full IPv6 address by combining the IPv6 prefix with the MAP 954 interface identifier (that embeds the IPv4 address). 956 IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0201:0000 957 Example 5 - Rule with no embedded address bits and address sharing 958 (sharing ratio 256) 960 End-user IPv6 prefix: 2001:db8:0012:3400::/56 961 Basic Mapping Rule: {2001:db8:0012:3400::/56 (Rule IPv6 prefix), 962 192.0.2.18/32 (Rule IPv4 prefix), 963 0 (Rule EA-bits length)} 964 PSID length: (16 - (32 - 24)) = 8. Sharing ratio of 256. 965 Provisioned with DHCPv6. 966 PSID offset: 6 (default) 967 PSID: 0x20 (Provisioned with DHCPv6) 969 A MAP node can via the BMR determine the IPv4 address and port-set 970 as shown below: 972 EA bits offset: 0 973 IPv4 suffix bits (p): Length of IPv4 address - IPv4 prefix 974 length = 32 -32 = 0 975 IPv4 address 192.0.2.18 (0xc0000212) 976 PSID start: 0 977 PSID length: 8 978 PSID: 0x34 980 Available ports (63 ranges) : 1232-1235, 2256-2259, ...... , 981 63696-63699, 64720-64723 983 The BMR information allows a MAP CE also to determine (complete) 984 its full IPv6 address by combining the IPv6 prefix with the MAP 985 interface identifier (that embeds the IPv4 address and PSID). 987 IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212:0034 989 Note that the IPv4 address and PSID is not derived from the IPv6 990 prefix assigned to the CE, but provisioned separately using for 991 example MAP options in DHCPv6. 993 Appendix B. Port mapping algorithm 995 The driving principles and the mathematical expression of the mapping 996 algorithm used by MAP can be found in Appendix B of 997 [I-D.ietf-softwire-map] 999 Authors' Addresses 1000 Xing Li 1001 CERNET Center/Tsinghua University 1002 Room 225, Main Building, Tsinghua University 1003 Beijing 100084 1004 CN 1006 Email: xing@cernet.edu.cn 1008 Congxiao Bao 1009 CERNET Center/Tsinghua University 1010 Room 225, Main Building, Tsinghua University 1011 Beijing 100084 1012 CN 1014 Email: congxiao@cernet.edu.cn 1016 Wojciech Dec (editor) 1017 Cisco Systems 1018 Haarlerbergpark Haarlerbergweg 13-19 1019 Amsterdam, NOORD-HOLLAND 1101 CH 1020 Netherlands 1022 Email: wdec@cisco.com 1024 Ole Troan 1025 Cisco Systems 1026 Oslo 1027 Norway 1029 Email: ot@cisco.com 1031 Satoru Matsushima 1032 SoftBank Telecom 1033 1-9-1 Higashi-Shinbashi, Munato-ku 1034 Tokyo 1035 Japan 1037 Email: satoru.matsushima@tm.softbank.co.jp 1038 Tetsuya Murakami 1039 IP Infusion 1040 1188 East Arques Avenue 1041 Sunnyvale 1042 USA 1044 Email: tetsuya@ipinfusion.com