idnits 2.17.1 draft-ietf-softwire-map-13.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 (March 09, 2015) is 3307 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6052' is defined on line 1029, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-softwire-map-deployment-03 == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-06 -- Obsolete informational reference (is this intentional?): RFC 1933 (Obsoleted by RFC 2893) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Troan, Ed. 3 Internet-Draft W. Dec 4 Intended status: Standards Track Cisco Systems 5 Expires: September 10, 2015 X. Li 6 C. Bao 7 CERNET Center/Tsinghua University 8 S. Matsushima 9 SoftBank Telecom 10 T. Murakami 11 IP Infusion 12 T. Taylor, Ed. 13 Huawei Technologies 14 March 09, 2015 16 Mapping of Address and Port with Encapsulation (MAP) 17 draft-ietf-softwire-map-13 19 Abstract 21 This document describes a mechanism for transporting IPv4 packets 22 across an IPv6 network using IP encapsulation, and a generic 23 mechanism for mapping between IPv6 addresses and IPv4 addresses and 24 transport layer ports. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 10, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Mapping Algorithm . . . . . . . . . . . . . . . . . . . . . . 7 65 5.1. Port mapping algorithm . . . . . . . . . . . . . . . . . 8 66 5.2. Basic mapping rule (BMR) . . . . . . . . . . . . . . . . 10 67 5.3. Forwarding mapping rule (FMR) . . . . . . . . . . . . . . 12 68 5.4. Destinations outside the MAP domain . . . . . . . . . . . 13 69 6. The IPv6 Interface Identifier . . . . . . . . . . . . . . . . 13 70 7. MAP Configuration . . . . . . . . . . . . . . . . . . . . . . 14 71 7.1. MAP CE . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 7.2. MAP BR . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 8. Forwarding Considerations . . . . . . . . . . . . . . . . . . 15 74 8.1. Receiving Rules . . . . . . . . . . . . . . . . . . . . . 15 75 8.2. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 8.3. Fragmentation and Path MTU Discovery . . . . . . . . . . 17 77 8.3.1. Fragmentation in the MAP domain . . . . . . . . . . . 17 78 8.3.2. Receiving IPv4 Fragments on the MAP domain borders . 17 79 8.3.3. Sending IPv4 fragments to the outside . . . . . . . . 18 80 9. NAT44 Considerations . . . . . . . . . . . . . . . . . . . . 18 81 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 83 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 84 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 85 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 14.1. Normative References . . . . . . . . . . . . . . . . . . 20 87 14.2. Informative References . . . . . . . . . . . . . . . . . 21 88 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 23 89 Appendix B. A More Detailed Description of the Derivation of the 90 Port Mapping Algorithm . . . . . . . . . . . . . . . 27 91 B.1. Bit Representation of the Algorithm . . . . . . . . . . . 29 92 B.2. GMA examples . . . . . . . . . . . . . . . . . . . . . . 30 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 95 1. Introduction 97 Mapping of IPv4 addresses in IPv6 addresses has been described in 98 numerous mechanisms dating back to 1995 [RFC1933]. The Automatic 99 tunneling mechanism described in RFC1933 assigned a globally unique 100 IPv6 address to a host by combining the host's IPv4 address with a 101 well-known IPv6 prefix. Given an IPv6 packet with a destination 102 address with an embedded IPv4 address, a node could automatically 103 tunnel this packet by extracting the IPv4 tunnel end-point address 104 from the IPv6 destination address. 106 There are numerous variations of this idea, described in 6over4 107 [RFC2529], 6to4 [RFC3056], ISATAP [RFC5214], and 6rd [RFC5969]. 109 The commonalities of all these IPv6 over IPv4 mechanisms are: 111 o Automatically provisions an IPv6 address for a host or an IPv6 112 prefix for a site 114 o Algorithmic or implicit address resolution of tunnel end point 115 addresses. Given an IPv6 destination address, an IPv4 tunnel 116 endpoint address can be calculated. 118 o Embedding of an IPv4 address or part thereof into an IPv6 address. 120 In later phases of IPv4 to IPv6 migration, it is expected that 121 IPv6-only networks will be common, while there will still be a need 122 for residual IPv4 deployment. This document describes a generic 123 mapping of IPv4 to IPv6, and a mechanism for encapsulating IPv4 over 124 IPv6. 126 Just as the IPv6 over IPv4 mechanisms referred to above, the residual 127 IPv4 over IPv6 mechanism must be capable of: 129 o Provisioning an IPv4 prefix, an IPv4 address or a shared IPv4 130 address. 132 o Algorithmically map between either an IPv4 prefix, an IPv4 address 133 or a shared IPv4 address and an IPv6 address. 135 The mapping scheme described here supports encapsulation of IPv4 136 packets in IPv6 in both mesh and hub-and-spoke topologies, including 137 address mappings with full independence between IPv6 and IPv4 138 addresses. 140 This document describes delivery of IPv4 unicast service across an 141 IPv6 infrastructure. IPv4 multicast is not considered further in 142 this document. 144 The A+P (Address and Port) architecture of sharing an IPv4 address by 145 distributing the port space is described in [RFC6346]. Specifically 146 section 4 of [RFC6346] covers stateless mapping. The corresponding 147 stateful solution DS-lite is described in [RFC6333]. The motivation 148 for this work is described in 149 [I-D.ietf-softwire-stateless-4v6-motivation]. 151 A companion document defines a DHCPv6 option for provisioning of MAP 152 [I-D.ietf-softwire-map-dhcp]. Other means of provisioning are 153 possible. Deployment considerations are described in 154 [I-D.ietf-softwire-map-deployment]. 156 MAP relies on IPv6 and is designed to deliver dual-stack service 157 while allowing IPv4 to be phased out within the service provider's 158 (SP) network. The phasing out of IPv4 within the SP network is 159 independent of whether the end user disables IPv4 service or not. 160 Further, "greenfield"; IPv6-only networks may use MAP in order to 161 deliver IPv4 to sites via the IPv6 network. 163 2. Conventions 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in RFC 2119 [RFC2119]. 169 3. Terminology 171 MAP domain: One or more MAP CEs and BRs connected to the 172 same virtual link. A service provider may 173 deploy a single MAP domain, or may utilize 174 multiple MAP domains. 176 MAP rule A set of parameters describing the mapping 177 between an IPv4 prefix, IPv4 address or 178 shared IPv4 address and an IPv6 prefix or 179 address. Each domain uses a different 180 mapping rule set. 182 MAP node A device that implements MAP. 184 MAP Border Relay (BR): A MAP enabled router managed by the service 185 provider at the edge of a MAP domain. A 186 Border Relay router has at least an 187 IPv6-enabled interface and an IPv4 interface 188 connected to the native IPv4 network. A MAP 189 BR may also be referred to simply as a "BR" 190 within the context of MAP. 192 MAP Customer Edge (CE): A device functioning as a Customer Edge 193 router in a MAP deployment. A typical MAP CE 194 adopting MAP rules will serve a residential 195 site with one WAN side interface, and one or 196 more LAN side interfaces. A MAP CE may also 197 be referred to simply as a "CE" within the 198 context of MAP. 200 Port-set: The separate part of the transport layer port 201 space; denoted as a port-set. 203 Port-set ID (PSID): Algorithmically identifies a set of ports 204 exclusively assigned to a CE. 206 Shared IPv4 address: An IPv4 address that is shared among multiple 207 CEs. Only ports that belong to the assigned 208 port-set can be used for communication. Also 209 known as a Port-Restricted IPv4 address. 211 End-user IPv6 prefix: The IPv6 prefix assigned to an End-user CE by 212 other means than MAP itself. E.g., 213 Provisioned using DHCPv6 PD [RFC3633], 214 assigned via SLAAC [RFC4862], or configured 215 manually. It is unique for each CE. 217 MAP IPv6 address: The IPv6 address used to reach the MAP 218 function of a CE from other CEs and from BRs. 220 Rule IPv6 prefix: An IPv6 prefix assigned by a Service Provider 221 for a mapping rule. 223 Rule IPv4 prefix: An IPv4 prefix assigned by a Service Provider 224 for a mapping rule. 226 Embedded Address (EA) bits: The IPv4 EA-bits in the IPv6 address 227 identify an IPv4 prefix/address (or part 228 thereof) or a shared IPv4 address (or part 229 thereof) and a port-set identifier. 231 4. Architecture 233 In accordance with the requirements stated above, the MAP mechanism 234 can operate with shared IPv4 addresses, full IPv4 addresses or IPv4 235 prefixes. Operation with shared IPv4 addresses is described here, 236 and the differences for full IPv4 addresses and prefixes are 237 described below. 239 The MAP mechanism uses existing standard building blocks. The 240 existing NAPT [RFC2663] on the CE is used with additional support for 241 restricting transport protocol ports, ICMP identifiers and fragment 242 identifiers to the configured port-set. For packets outbound from 243 the private IPv4 network, the CE NAPT MUST translate transport 244 identifiers (e.g., TCP and UDP port numbers) so that they fall within 245 the CE's assigned port-range. 247 The NAPT MUST in turn be connected to a MAP-aware forwarding 248 function, that does encapsulation / decapsulation of IPv4 packets in 249 IPv6. MAP supports the encapsulation mode specified in [RFC2473]. 250 In addition MAP specifies an algorithm to do "address resolution" 251 from an IPv4 address and port to an IPv6 address. This algorithmic 252 mapping is specified in Section 5. 254 The MAP architecture described here restricts the use of the shared 255 IPv4 address to only be used as the global address (outside) of the 256 NAPT running on the CE. A shared IPv4 address MUST NOT be used to 257 identify an interface. While it is theoretically possible to make 258 host stacks and applications port-aware, it would be a drastic change 259 to the IP model [RFC6250]. 261 For full IPv4 addresses and IPv4 prefixes, the architecture just 262 described applies with two differences. First, a full IPv4 address 263 or IPv4 prefix can be used as it is today, e.g., for identifying an 264 interface or as a DHCP pool, respectively. Secondly, the NAPT is not 265 required to restrict the ports used on outgoing packets. 267 This architecture is illustrated in Figure 1. 269 User N 270 Private IPv4 271 | Network 272 | 273 O--+---------------O 274 | | MAP CE | 275 | +-----+--------+ | 276 | NAPT44| MAP | | 277 | +-----+ | |\ ,-------. .------. 278 | +--------+ | \ ,-' `-. ,-' `-. 279 O------------------O / \ O---------O / Public \ 280 / IPv6 only \ | MAP | / IPv4 \ 281 ( Network --+ Border +- Network ) 282 \ (MAP Domain) / | Relay | \ / 283 O------------------O \ / O---------O \ / 284 | MAP CE | /". ,-' `-. ,-' 285 | +-----+--------+ | / `----+--' ------' 286 | NAPT44| MAP | |/ 287 | +-----+ | | 288 | | +--------+ | 289 O---+--------------O 290 | 291 User M 292 Private IPv4 293 Network 295 Figure 1: Network Topology 297 The MAP BR connects one or more MAP domains to external IPv4 298 networks. 300 5. Mapping Algorithm 302 A MAP node is provisioned with one or more mapping rules. 304 Mapping rules are used differently depending on their function. 305 Every MAP node must be provisioned with a Basic mapping rule. This 306 is used by the node to configure its IPv4 address, IPv4 prefix or 307 shared IPv4 address. This same basic rule can also be used for 308 forwarding, where an IPv4 destination address and optionally a 309 destination port are mapped into an IPv6 address. Additional mapping 310 rules are specified to allow for multiple different IPv4 sub-nets to 311 exist within the domain and optimize forwarding between them. 313 Traffic outside of the domain (i.e., when the destination IPv4 314 address does not match (using longest matching prefix) any Rule IPv4 315 prefix in the Rules database) is forwarded to the BR. 317 There are two types of mapping rules: 319 1. Basic Mapping Rule (BMR) - mandatory. A CE can be provisioned 320 with multiple End-user IPv6 prefixes. There can only be one 321 Basic Mapping Rule per End-user IPv6 prefix. However all CE's 322 having End-user IPv6 prefixes within (aggregated by) the same 323 Rule IPv6 prefix may share the same Basic Mapping Rule. In 324 combination with the End-user IPv6 prefix, the Basic Mapping Rule 325 is used to derive the IPv4 prefix, address, or shared address and 326 the PSID assigned to the CE. 328 2. Forwarding Mapping Rule (FMR) - optional, used for forwarding. 329 The Basic Mapping Rule may also be a Forwarding Mapping Rule. 330 Each Forwarding Mapping Rule will result in an entry in the Rules 331 table for the Rule IPv4 prefix. Given a destination IPv4 address 332 and port within the MAP domain, a MAP node can use the matching 333 FMR to derive the End-user IPv6 address of the interface through 334 which that IPv4 destination address and port combination can be 335 reached. In hub and spoke mode there are no FMRs. 337 Both mapping rules share the same parameters: 339 o Rule IPv6 prefix (including prefix length) 341 o Rule IPv4 prefix (including prefix length) 343 o Rule EA-bits length (in bits) 345 A MAP node finds its BMR by doing a longest match between the End- 346 user IPv6 prefix and the Rule IPv6 prefix in the Mapping Rules table. 347 The rule is then used for IPv4 prefix, address or shared address 348 assignment. 350 A MAP IPv6 address is formed from the BMR Rule IPv6 prefix. This 351 address MUST be assigned to an interface of the MAP node and is used 352 to terminate all MAP traffic being sent or received to the node. 354 Port-restricted IPv4 routes are installed in the Rules table for all 355 the Forwarding Mapping Rules, and a default route is installed to the 356 MAP BR (see Section 5.4). 358 Forwarding Mapping Rules are used to allow direct communication 359 between MAP CEs, known as mesh mode. In hub and spoke mode, there 360 are no forwarding mapping rules, all traffic MUST be forwarded 361 directly to the BR. 363 While an FMR is optional in the sense that a MAP CE MAY be configured 364 with zero or more FMRs depending on the deployment, all MAP CEs MUST 365 implement support for both rule types. 367 5.1. Port mapping algorithm 369 The port mapping algorithm is used in domains whose rules allow IPv4 370 address sharing. 372 The simplest way to represent a port range is using a notation 373 similar to CIDR [RFC4632]. For example the first 256 ports are 374 represented as port prefix 0.0/8. The last 256 ports as 255.0/8. In 375 hexadecimal, 0x0000/8 (PSID = 0) and 0xFF00/8 (PSID = 0xFF). Using 376 this technique, but wishing to avoid allocating the system ports 377 [RFC6335] to the user, one would have to exclude the use of one or 378 more PSIDs (e.g., PSIDs 0 to 3 in the example just given). 380 When the PSID is embedded in the End-user IPv6 prefix, then to 381 minimize dependencies between the End-user IPv6 prefix and the 382 assigned port-set, it is desirable to minimize the restrictions of 383 possible PSID values. This is achieved by using an infix 384 representation of the port value. Using such a representation, the 385 well-known ports are excluded by restrictions on the value of the 386 high-order bitfield (A) rather than the PSID. 388 The infix algorithm allocates ports to a given CE as a series of 389 contiguous ranges spaced at regular intervals throughout the complete 390 range of possible port-set values. 392 0 1 393 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 394 +-----------+-----------+-------+ 395 Ports in | A | PSID | M | 396 the CE port-set | > 0 | | | 397 +-----------+-----------+-------+ 398 | a bits | k bits |m bits | 400 Figure 2: Structure of a port-restricted port field 402 a bits: The number of offset bits. 6 by default as this excludes the 403 system ports (0-1023). To guarantee non-overlapping port sets, 404 the offset 'a' MUST be the same for every MAP CE sharing the same 405 address. 407 A: Selects the range of the port number. For 'a' > 0, A MUST be 408 larger than 0. This ensures that the algorithm excludes the 409 system ports. For the default value of 'a' (6), the system ports, 410 are excluded by requiring that A be greater than 0. Smaller 411 values of 'a' excludes a larger initial range. E.g., 'a' = 4, 412 will exclude ports 0 - 4095. The interval between initial port 413 numbers of successive contiguous ranges assigned to the same user 414 is 2^(16-a). 416 k bits: The length in bits of the PSID field. To guarantee non- 417 overlapping port sets, the length 'k' MUST be the same for every 418 MAP CE sharing the same address. The sharing ratio is 2^k. The 419 number of ports assigned to the user is 2^(16-k) - 2^m (excluded 420 ports) 422 PSID: The Port-Set Identifier (PSID). Different PSID values 423 guarantee non-overlapping port-sets thanks to the restrictions on 424 'a' and 'k' stated above, because the PSID always occupies the 425 same bit positions in the port number. 427 m bits: The number of contiguous ports is given by 2^m. 429 M: Selects the specific port within a particular range specified by 430 the concatenation of A and the PSID. 432 5.2. Basic mapping rule (BMR) 434 The Basic Mapping Rule is mandatory, used by the CE to provision 435 itself with an IPv4 prefix, IPv4 address or shared IPv4 address. 436 Recall from Section 5 that the BMR consists of the following 437 parameters: 439 o Rule IPv6 prefix (including prefix length) 441 o Rule IPv4 prefix (including prefix length) 443 o Rule EA-bits length (in bits) 445 Figure 3 shows the structure of the complete MAP IPv6 address as 446 specified in this document. 448 | n bits | o bits | s bits | 128-n-o-s bits | 449 +--------------------+-----------+---------+-----------------------+ 450 | Rule IPv6 prefix | EA bits |subnet ID| interface ID | 451 +--------------------+-----------+---------+-----------------------+ 452 |<--- End-user IPv6 prefix --->| 454 Figure 3: MAP IPv6 Address Format 456 The Rule IPv6 prefix (which is part of the End-user IPv6 prefix) that 457 is common among all CEs using the same Basic Mapping Rule within the 458 MAP domain. The EA bits encode the CE specific IPv4 address and port 459 information. The EA bits, which are unique for a given Rule IPv6 460 prefix, can contain a full or part of an IPv4 address and, in the 461 shared IPv4 address case, a Port-Set Identifier (PSID). An EA-bit 462 length of 0 signifies that all relevant MAP IPv4 addressing 463 information is passed directly in the BMR, and not derived from the 464 End-user IPv6 prefix. 466 The MAP IPv6 address is created by concatenating the End-user IPv6 467 prefix with the MAP subnet identifier (if the End-user IPv6 prefix is 468 shorter than 64 bits) and the interface identifier as specified in 469 Section 6. 471 The MAP subnet identifier is defined to be the first subnet (s bits 472 set to zero). 474 Define: 476 r = length of the IPv4 prefix given by the BMR; 478 o = length of the EA bit field as given by the BMR; 480 p = length of the IPv4 suffix contained in the EA bit field. 482 The length r MAY be zero, in which case the complete IPv4 address or 483 prefix is encoded in the EA bits. If only a part of the IPv4 address 484 / prefix is encoded in the EA bits, the Rule IPv4 prefix is 485 provisioned to the CE by other means (e.g., a DHCPv6 option). To 486 create a complete IPv4 address (or prefix), the IPv4 address suffix 487 (p) from the EA bits, is concatenated with the Rule IPv4 prefix (r 488 bits). 490 The offset of the EA bits field in the IPv6 address is equal to the 491 BMR Rule IPv6 prefix length. The length of the EA bits field (o) is 492 given by the BMR Rule EA-bits length, and can be between 0 and 48. A 493 length of 48 means that the complete IPv4 address and port is 494 embedded in the End-user IPv6 prefix (a single port is assigned). A 495 length of 0 means that no part of the IPv4 address or port is 496 embedded in the address. The sum of the Rule IPv6 Prefix length and 497 the Rule EA-bits length MUST be less or equal than the End-user IPv6 498 prefix length. 500 If o + r < 32 (length of the IPv4 address in bits), then an IPv4 501 prefix is assigned. This case is shown in Figure 4. 503 IPv4 prefix: 505 | r bits | o bits = p bits | 506 +-------------+---------------------+ 507 | Rule IPv4 | IPv4 Address suffix | 508 +-------------+---------------------+ 509 | < 32 bits | 511 Figure 4: IPv4 prefix 513 If o + r is equal to 32, then a full IPv4 address is to be assigned. 514 The address is created by concatenating the Rule IPv4 prefix and the 515 EA-bits. This case is shown in Figure 5. 517 Complete IPv4 address: 519 | r bits | o bits = p bits | 520 +-------------+---------------------+ 521 | Rule IPv4 | IPv4 Address suffix | 522 +-------------+---------------------+ 523 | 32 bits | 525 Figure 5: Complete IPv4 address 527 If o + r is > 32, then a shared IPv4 address is to be assigned. The 528 number of IPv4 address suffix bits (p) in the EA bits is given by 32 529 - r bits. The PSID bits are used to create a port set. The length 530 of the PSID bit field within EA bits is: q = o - p. 532 Shared IPv4 address: 534 | r bits | p bits | | q bits | 535 +-------------+---------------------+ +------------+ 536 | Rule IPv4 | IPv4 Address suffix | |Port-Set ID | 537 +-------------+---------------------+ +------------+ 538 | 32 bits | 540 Figure 6: Shared IPv4 address 542 The length of r MAY be 32, with no part of the IPv4 address embedded 543 in the EA bits. This results in a mapping with no dependence between 544 the IPv4 address and the IPv6 address. In addition the length of o 545 MAY be zero (no EA bits embedded in the End-User IPv6 prefix), 546 meaning that also the PSID is provisioned using e.g., the DHCP 547 option. 549 See Appendix A for an example of the Basic Mapping Rule. 551 5.3. Forwarding mapping rule (FMR) 553 The Forwarding Mapping Rule is optional, and used in mesh mode to 554 enable direct CE to CE connectivity. 556 On adding an FMR rule, an IPv4 route is installed in the Rules table 557 for the Rule IPv4 prefix. 559 | 32 bits | | 16 bits | 560 +--------------------------+ +-------------------+ 561 | IPv4 destination address | | IPv4 dest port | 562 +--------------------------+ +-------------------+ 563 : : ___/ : 564 | p bits | / q bits : 565 +-----------+ +------------+ 566 |IPv4 suffix| |Port-Set ID | 567 +-----------+ +------------+ 568 \ / ____/ ________/ 569 \ : __/ _____/ 570 \ : / / 571 | n bits | o bits | s bits | 128-n-o-s bits | 572 +--------------------+-----------+---------+------------+----------+ 573 | Rule IPv6 prefix | EA bits |subnet ID| interface ID | 574 +--------------------+-----------+---------+-----------------------+ 575 |<--- End-user IPv6 prefix --->| 577 Figure 7: Derivation of MAP IPv6 address 579 See Appendix A for an example of the Forwarding Mapping Rule. 581 5.4. Destinations outside the MAP domain 583 IPv4 traffic between MAP nodes that are all within one MAP domain is 584 encapsulated in IPv6, with the sender's MAP IPv6 address as the IPv6 585 source address and the receiving MAP node's MAP IPv6 address as the 586 IPv6 destination address. To reach IPv4 destinations outside of the 587 MAP domain, traffic is also encapsulated in IPv6, but the destination 588 IPv6 address is set to the configured IPv6 address of the MAP BR. 590 On the CE, the path to the BR can be represented as a point to point 591 IPv4 over IPv6 tunnel [RFC2473] with the source address of the tunnel 592 being the CE's MAP IPv6 address and the BR IPv6 address as the remote 593 tunnel address. When MAP is enabled, a typical CE router will 594 install a default IPv4 route to the BR. 596 The BR forwards traffic received from the outside to CE's using the 597 normal MAP forwarding rules. 599 6. The IPv6 Interface Identifier 601 The Interface identifier format of a MAP node is described below. 603 | 128-n-o-s bits | 604 | 16 bits| 32 bits | 16 bits| 605 +--------+----------------+--------+ 606 | 0 | IPv4 address | PSID | 607 +--------+----+-----------+--------+ 608 Figure 8 610 In the case of an IPv4 prefix, the IPv4 address field is right-padded 611 with zeroes up to 32 bits. The PSID field is left-padded to create a 612 16 bit field. For an IPv4 prefix or a complete IPv4 address, the 613 PSID field is zero. 615 If the End-user IPv6 prefix length is larger than 64, the most 616 significant parts of the interface identifier is overwritten by the 617 prefix. 619 7. MAP Configuration 621 For a given MAP domain, the BR and CE MUST be configured with the 622 following MAP elements. The configured values for these elements are 623 identical for all CEs and BRs within a given MAP domain. 625 o The Basic Mapping Rule and optionally the Forwarding Mapping 626 Rules, including the Rule IPv6 prefix, Rule IPv4 prefix, and 627 Length of EA bits 629 o Hub and spoke mode or Mesh mode. (If all traffic should be sent 630 to the BR, or if direct CE to CE traffic should be supported). 632 In addition the MAP CE MUST be configured with the IPv6 address(es) 633 of the MAP BR (Section 5.4). 635 7.1. MAP CE 637 The MAP elements are set to values that are the same across all CEs 638 within a MAP domain. The values may be configured in a variety of 639 manners, including provisioning methods such as the Broadband Forum's 640 "TR-69" Residential Gateway management interface, an XML-based object 641 retrieved after IPv6 connectivity is established, or manual 642 configuration by an administrator. IPv6 DHCP options for MAP 643 configuration is defined in [I-D.ietf-softwire-map-dhcp]. Other 644 configuration and management methods may use the format described by 645 this option for consistency and convenience of implementation on CEs 646 that support multiple configuration methods. 648 The only remaining provisioning information the CE requires in order 649 to calculate the MAP IPv4 address and enable IPv4 connectivity is the 650 IPv6 prefix for the CE. The End-user IPv6 prefix is configured as 651 part of obtaining IPv6 Internet access. 653 The MAP provisioning parameters, and hence the IPv4 service itself, 654 are tied to the associated End-user IPv6 prefix lifetime; thus, the 655 MAP service is also tied to this in terms of authorization, 656 accounting, etc. 658 A single MAP CE MAY be connected to more than one MAP domain, just as 659 any router may have more than one IPv4-enabled service provider 660 facing interface and more than one set of associated addresses 661 assigned by DHCP. Each domain a given CE operates within would 662 require its own set of MAP configuration elements and would generate 663 its own IPv4 address. Each MAP domain requires a distinct End-user 664 IPv6 prefix. 666 The MAP DHCP option is specified in [I-D.ietf-softwire-map-dhcp]. 668 7.2. MAP BR 670 The MAP BR MUST be configured with corresponding mapping rules for 671 each MAP domain which it is acting as BR for. 673 For increased reliability and load balancing, the BR IPv6 address MAY 674 be an anycast address shared across a given MAP domain. As MAP is 675 stateless, any BR may be used at any time. If the BR IPv6 address is 676 anycast the relay MUST use this anycast IPv6 address as the source 677 address in packets relayed to CEs. 679 Since MAP uses provider address space, no specific routes need to be 680 advertised externally for MAP to operate, neither in IPv6 nor IPv4 681 BGP. However, if anycast is used for the MAP IPv6 relays, the 682 anycast addresses must be advertised in the service provider's IGP. 684 8. Forwarding Considerations 686 Figure 1 depicts the overall MAP architecture with IPv4 users (N and 687 M) networks connected to a routed IPv6 network. 689 MAP uses Encapsulation mode as specified in [RFC2473]. 691 For a shared IPv4 address, a MAP CE forwarding IPv4 packets from the 692 LAN performs NAT44 functions first and creates appropriate NAT44 693 bindings. The resulting IPv4 packets MUST contain the source IPv4 694 address and source transport identifiers specified by the MAP 695 provisioning parameters. The IPv4 packet is forwarded using the CE's 696 MAP forwarding function. The IPv6 source and destination addresses 697 MUST then be derived as per Section 5 of this draft. 699 8.1. Receiving Rules 700 A MAP CE receiving an IPv6 packet to its MAP IPv6 address sends this 701 packet to the CE's MAP function where it is decapsulated. The 702 resulting IPv4 packet is then forwarded to the CE's NAT44 function 703 where it is handled according to the NAT's translation table. 705 A MAP BR receiving IPv6 packets selects a best matching MAP domain 706 rule (Rule IPv6 prefix) based on a longest address match of the 707 packet's IPv6 source address, as well as a match of the packet 708 destination address against the configured BR IPv6 address(es). The 709 selected MAP rule allows the BR to determine the EA-bits from the 710 source IPv6 address. 712 To prevent spoofing of IPv4 addresses, any MAP node (CE and BR) MUST 713 perform the following validation upon reception of a packet. First, 714 the embedded IPv4 address or prefix, as well as PSID (if any), are 715 extracted from the source IPv6 address using the matching MAP rule. 716 These represent the range of what is acceptable as source IPv4 717 address and port. Secondly, the node extracts the source IPv4 718 address and port from the IPv4 packet encapsulated inside the IPv6 719 packet. If they are found to be outside the acceptable range, the 720 packet MUST be silently discard and a counter incremented to indicate 721 that a potential spoofing attack may be underway. The source 722 validation checks just described are not done for packets whose 723 source IPv6 address is that of the BR (BR IPv6 address). 725 By default, the CE router MUST drop packets received on the MAP 726 virtual interface (i.e., after decapsulation of IPv6) for IPv4 727 destinations not for its own IPv4 shared address, full IPv4 address 728 or IPv4 prefix. 730 8.2. ICMP 732 ICMP message should be supported in MAP domain. Hence, the NAT44 in 733 MAP CE MUST implement the behavior for ICMP message conforming to the 734 best current practice documented in [RFC5508]. 736 If a MAP CE receives an ICMP message having ICMP identifier field in 737 ICMP header, NAT44 in the MAP CE MUST rewrite this field to a 738 specific value assigned from the port set. BR and other CEs must 739 handle this field similar to the port number in the TCP/UDP header 740 upon receiving the ICMP message with ICMP identifier field. 742 If a MAP node receives an ICMP error message without the ICMP 743 identifier field for errors that is detected inside a IPv6 tunnel, a 744 node should relay the ICMP error message to the original source. 745 This behavior SHOULD be implemented conforming to the section 8 of 746 [RFC2473]. 748 8.3. Fragmentation and Path MTU Discovery 750 Due to the different sizes of the IPv4 and IPv6 header, handling the 751 maximum packet size is relevant for the operation of any system 752 connecting the two address families. There are three mechanisms to 753 handle this issue: Path MTU discovery (PMTUD), fragmentation, and 754 transport-layer negotiation such as the TCP Maximum Segment Size 755 (MSS) option [RFC0897]. MAP uses all three mechanisms to deal with 756 different cases. 758 8.3.1. Fragmentation in the MAP domain 760 Encapsulating an IPv4 packet to carry it across the MAP domain will 761 increase its size (typically by 40 bytes). It is strongly 762 recommended that the MTU in the MAP domain be well managed and that 763 the IPv6 MTU on the CE WAN side interface be set so that no 764 fragmentation occurs within the boundary of the MAP domain. 766 Fragmentation on MAP domain entry is described in section 7.2 of 767 [RFC2473]. 769 The use of an anycast source address could lead to an ICMP error 770 message generated on the path being sent to a different BR. 771 Therefore, using dynamic tunnel MTU Section 6.7 of [RFC2473] is 772 subject to IPv6 Path MTU black-holes. A MAP BR using an anycast 773 source address SHOULD NOT by default use Path MTU discovery across 774 the MAP domain. 776 Multiple BRs using the same anycast source address could send 777 fragmented packets to the same CE at the same time. If the 778 fragmented packets from different BRs happen to use the same fragment 779 ID, incorrect reassembly might occur. See [RFC4459] for an analysis 780 of the problem. Section 3.4 suggests solving the problem by 781 fragmenting the inner packet. 783 8.3.2. Receiving IPv4 Fragments on the MAP domain borders 785 Forwarding of an IPv4 packet received from the outside of the MAP 786 domain requires the IPv4 destination address and the transport 787 protocol destination port. The transport protocol information is 788 only available in the first fragment received. As described in 789 section 5.3.3 of [RFC6346] a MAP node receiving an IPv4 fragmented 790 packet from outside has to reassemble the packet before sending the 791 packet onto the MAP link. If the first packet received contains the 792 transport protocol information, it is possible to optimize this 793 behavior by using a cache and forwarding the fragments unchanged. 794 Implementers of MAP should be aware that there are a number of well- 795 known attacks against IP fragmentation; see [RFC1858] and [RFC3128]. 797 Implementers should also be aware of additional issues with 798 reassembling packets at high rates, as described in [RFC4963]. 800 8.3.3. Sending IPv4 fragments to the outside 802 If two IPv4 host behind two different MAP CEs with the same IPv4 803 address sends fragments to an IPv4 destination host outside the 804 domain, those hosts may use the same IPv4 fragmentation identifier, 805 resulting in incorrect reassembly of the fragments at the destination 806 host. Given that the IPv4 fragmentation identifier is a 16 bit 807 field, it could be used similarly to port ranges. A MAP CE could 808 rewrite the IPv4 fragmentation identifier to be within its allocated 809 port-set, if the resulting fragment identifier space was large enough 810 related to the rate fragments was sent. However, splitting the 811 identifier space in this fashion would increase the probability of 812 reassembly collision for all connections through the CPE. See also 813 [RFC6864] 815 9. NAT44 Considerations 817 The NAT44 implemented in the MAP CE SHOULD conform with the behavior 818 and best current practice documented in [RFC4787], [RFC5508], and 819 [RFC5382]. In MAP address sharing mode (determined by the MAP domain 820 /rule configuration parameters) the operation of the NAT44 MUST be 821 restricted to the available port numbers derived via the basic 822 mapping rule. 824 10. IANA Considerations 826 This specification does not require any IANA actions. 828 11. Security Considerations 830 Spoofing attacks: With consistency checks between IPv4 and IPv6 831 sources that are performed on IPv4/IPv6 packets received by MAP 832 nodes, MAP does not introduce any new opportunity for spoofing 833 attacks that would not already exist in IPv6. 835 Denial-of-service attacks: In MAP domains where IPv4 addresses are 836 shared, the fact that IPv4 datagram reassembly may be necessary 837 introduces an opportunity for DOS attacks. This is inherent to 838 address sharing, and is common with other address sharing 839 approaches such as DS-Lite and NAT64/DNS64. The best protection 840 against such attacks is to accelerate IPv6 deployment, so that, 841 where MAP is supported, it is less and less used. 843 Routing-loop attacks: This attack may exist in some automatic 844 tunneling scenarios are documented in [RFC6324]. They cannot 845 exist with MAP because each BRs checks that the IPv6 source 846 address of a received IPv6 packet is a CE address based on 847 Forwarding Mapping Rule. 849 Attacks facilitated by restricted port set: From hosts 850 that are not subject to ingress filtering of [RFC2827], some 851 attacks are possible by an attacker injecting spoofed packets 852 during ongoing transport connections ([RFC4953], [RFC5961], 853 [RFC6056]. The attacks depend on guessing which ports are 854 currently used by target hosts, and using an unrestricted port-set 855 is preferable, i.e., using native IPv6 connections that are not 856 subject to MAP port range restrictions. To minimize this type of 857 attacks when using a restricted port-set, the MAP CE's NAT44 858 filtering behavior SHOULD be "Address-Dependent Filtering 859 [RFC4787], Section 5. Furthermore, the MAP CEs SHOULD use a DNS 860 transport proxy [RFC5625] function to handle DNS traffic, and 861 source such traffic from IPv6 interfaces not assigned to MAP. 863 [RFC6269] outlines general issues with IPv4 address sharing. 865 12. Contributors 867 This document is the result of the IETF Softwire MAP design team 868 effort and numerous previous individual contributions in this area: 870 Chongfeng Xie (China Telecom) 871 Room 708, No.118, Xizhimennei Street Beijing 100035 872 People's Republic of China 873 Phone: +86-10-58552116 874 Email: xiechf@ctbri.com.cn 876 Qiong Sun (China Telecom) 877 Room 708, No.118, Xizhimennei Street Beijing 100035 878 People's Republic of China 879 Phone: +86-10-58552936 880 Email: sunqiong@ctbri.com.cn 882 Gang Chen (China Mobile) 883 53A,Xibianmennei Ave. Beijing 100053 884 People's Republic of China 885 Email: chengang@chinamobile.com 887 Yu Zhai 888 CERNET Center/Tsinghua University 889 Room 225, Main Building, Tsinghua University 890 Beijing 100084 891 People's Republic of China 892 Email: jacky.zhai@gmail.com 894 Wentao Shang (CERNET Center/Tsinghua University) 895 Room 225, Main Building, Tsinghua University Beijing 100084 896 People's Republic of China 897 Email: wentaoshang@gmail.com 899 Guoliang Han (CERNET Center/Tsinghua University) 900 Room 225, Main Building, Tsinghua University Beijing 100084 901 People's Republic of China 902 Email: bupthgl@gmail.com 904 Rajiv Asati (Cisco Systems) 905 7025-6 Kit Creek Road Research Triangle Park NC 27709 USA 906 Email: rajiva@cisco.com 908 13. Acknowledgments 910 This document is based on the ideas of many, including Masakazu 911 Asama, Mohamed Boucadair, Gang Chen, Maoke Chen, Wojciech Dec, 912 Xiaohong Deng, Jouni Korhonen, Tomasz Mrugalski, Jacni Qin, Chunfa 913 Sun, Qiong Sun, and Leaf Yeh. The authors want in particular to 914 recognize Remi Despres, who has tirelessly worked on generalized 915 mechanisms for stateless address mapping. 917 The authors would like to thank Lichun Bao, Guillaume Gottard, Dan 918 Wing, Jan Zorz, Necj Scoberne, Tina Tsou, Kristian Poscic, and 919 especially Tom Taylor and Simon Perreault for the thorough review and 920 comments of this document. Useful IETF Last Call comments were 921 received from Brian Weis and Lei Yan. 923 14. References 925 14.1. Normative References 927 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 928 Requirement Levels", BCP 14, RFC 2119, March 1997. 930 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 931 IPv6 Specification", RFC 2473, December 1998. 933 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 934 152, RFC 5625, August 2009. 936 14.2. Informative References 938 [I-D.ietf-softwire-map-deployment] 939 Qiong, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault, 940 "Mapping of Address and Port (MAP) - Deployment 941 Considerations", draft-ietf-softwire-map-deployment-03 942 (work in progress), October 2013. 944 [I-D.ietf-softwire-map-dhcp] 945 Mrugalski, T., Troan, O., Dec, W., Bao, C., 946 leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options 947 for configuration of Softwire Address and Port Mapped 948 Clients", draft-ietf-softwire-map-dhcp-06 (work in 949 progress), November 2013. 951 [I-D.ietf-softwire-stateless-4v6-motivation] 952 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 953 Borges, I., and G. Chen, "Motivations for Carrier-side 954 Stateless IPv4 over IPv6 Migration Solutions", draft-ietf- 955 softwire-stateless-4v6-motivation-05 (work in progress), 956 November 2012. 958 [RFC0897] Postel, J., "Domain name system implementation schedule", 959 RFC 897, February 1984. 961 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 962 Considerations for IP Fragment Filtering", RFC 1858, 963 October 1995. 965 [RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 966 IPv6 Hosts and Routers", RFC 1933, April 1996. 968 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 969 Domains without Explicit Tunnels", RFC 2529, March 1999. 971 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 972 Translator (NAT) Terminology and Considerations", RFC 973 2663, August 1999. 975 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 976 Defeating Denial of Service Attacks which employ IP Source 977 Address Spoofing", BCP 38, RFC 2827, May 2000. 979 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 980 via IPv4 Clouds", RFC 3056, February 2001. 982 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 983 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 985 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 986 Host Configuration Protocol (DHCP) version 6", RFC 3633, 987 December 2003. 989 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 990 Network Tunneling", RFC 4459, April 2006. 992 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 993 (CIDR): The Internet Address Assignment and Aggregation 994 Plan", BCP 122, RFC 4632, August 2006. 996 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 997 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 998 RFC 4787, January 2007. 1000 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1001 Address Autoconfiguration", RFC 4862, September 2007. 1003 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 1004 4953, July 2007. 1006 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1007 Errors at High Data Rates", RFC 4963, July 2007. 1009 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1010 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1011 March 2008. 1013 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1014 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1015 RFC 5382, October 2008. 1017 [RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT 1018 Behavioral Requirements for ICMP", BCP 148, RFC 5508, 1019 April 2009. 1021 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 1022 Robustness to Blind In-Window Attacks", RFC 5961, August 1023 2010. 1025 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1026 Infrastructures (6rd) -- Protocol Specification", RFC 1027 5969, August 2010. 1029 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1030 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1031 October 2010. 1033 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 1034 Protocol Port Randomization", BCP 156, RFC 6056, January 1035 2011. 1037 [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, May 1038 2011. 1040 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 1041 Roberts, "Issues with IP Address Sharing", RFC 6269, June 1042 2011. 1044 [RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using 1045 IPv6 Automatic Tunnels: Problem Statement and Proposed 1046 Mitigations", RFC 6324, August 2011. 1048 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1049 Stack Lite Broadband Deployments Following IPv4 1050 Exhaustion", RFC 6333, August 2011. 1052 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 1053 Cheshire, "Internet Assigned Numbers Authority (IANA) 1054 Procedures for the Management of the Service Name and 1055 Transport Protocol Port Number Registry", BCP 165, RFC 1056 6335, August 2011. 1058 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 1059 IPv4 Address Shortage", RFC 6346, August 2011. 1061 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 1062 RFC 6864, February 2013. 1064 Appendix A. Examples 1066 Example 1 - Basic Mapping Rule 1067 Given the MAP domain information and an IPv6 address of 1068 an endpoint: 1070 End-user IPv6 prefix: 2001:db8:0012:3400::/56 1071 Basic Mapping Rule: {2001:db8:0000::/40 (Rule IPv6 prefix), 1072 192.0.2.0/24 (Rule IPv4 prefix), 1073 16 (Rule EA-bits length)} 1074 PSID length: (16 - (32 - 24) = 8. (Sharing ratio of 256) 1075 PSID offset: 6 (default) 1077 A MAP node (CE or BR) can via the BMR, or equivalent FMR, 1078 determine the IPv4 address and port-set as shown below: 1080 EA bits offset: 40 1081 IPv4 suffix bits (p) Length of IPv4 address (32) - 1082 IPv4 prefix length (24) = 8 1083 IPv4 address: 192.0.2.18 (0xc0000212) 1084 PSID start: 40 + p = 40 + 8 = 48 1085 PSID length: o - p = (56 - 40) - 8 = 8 1086 PSID: 0x34 1088 Available ports (63 ranges) : 1232-1235, 2256-2259, ...... , 1089 63696-63699, 64720-64723 1091 The BMR information allows a MAP CE to determine (complete) 1092 its IPv6 address within the indicated IPv6 prefix. 1094 IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212:0034 1096 Example 2 - BR: 1098 Another example can be made of a MAP BR, 1099 configured with the following FMR when receiving a packet 1100 with the following characteristics: 1102 IPv4 source address: 1.2.3.4 (0x01020304) 1103 IPv4 source port: 80 1104 IPv4 destination address: 192.0.2.18 (0xc0000212) 1105 IPv4 destination port: 1232 1107 Forwarding Mapping Rule: {2001:db8::/40 (Rule IPv6 prefix), 1108 192.0.2.0/24 (Rule IPv4 prefix), 1109 16 (Rule EA-bits length)} 1111 IPv6 address of MAP BR: 2001:db8:ffff::1 1113 The above information allows the BR to derive as follows 1114 the mapped destination IPv6 address for the corresponding 1115 MAP CE, and also the mapped source IPv6 address for 1116 the IPv4 source address. 1118 IPv4 suffix bits (p): 32 - 24 = 8 (18 (0x12)) 1119 PSID length: 8 1120 PSID: 0x34 (1232) 1122 The resulting IPv6 packet will have the following key fields: 1124 IPv6 source address: 2001:db8:ffff::1 1125 IPv6 destination address: 2001:db8:0012:3400:0000:c000:0212:0034 1127 Example 3 - Forwarding Mapping Rule: 1129 An IPv4 host behind the MAP CE (addressed as per the previous 1130 examples) corresponding with IPv4 host 1.2.3.4 will have its 1131 packets encapsulated by IPv6 using the IPv6 address of the BR 1132 configured on the MAP CE as follows: 1134 IPv6 address of BR: 2001:db8:ffff::1 1135 IPv4 source address: 192.0.2.18 1136 IPv4 destination address: 1.2.3.4 1137 IPv4 source port: 1232 1138 IPv4 destination port: 80 1139 MAP CE IPv6 source address: 2001:db8:0012:3400:0000:c000:0212:0034 1140 IPv6 destination address: 2001:db8:ffff::1 1141 Example 4 - Rule with no embedded address bits and no address sharing 1143 End-User IPv6 prefix: 2001:db8:0012:3400::/56 1144 Basic Mapping Rule: {2001:db8:0012:3400::/56 (Rule IPv6 prefix), 1145 192.0.2.18/32 (Rule IPv4 prefix), 1146 0 (Rule EA-bits length)} 1147 PSID length: 0 (Sharing ratio is 1) 1148 PSID offset: n/a 1150 A MAP node (CE or BR) can via the BMR or equivalent FMR, determine 1151 the IPv4 address and port-set as shown below: 1153 EA bits offset: 0 1154 IPv4 suffix bits (p): Length of IPv4 address (32) - 1155 IPv4 prefix length (32) = 0 1156 IPv4 address: 192.0.2.18 (0xc0000212) 1157 PSID start: 0 1158 PSID length: 0 1159 PSID: null 1161 The BMR information allows a MAP CE also to determine (complete) 1162 its full IPv6 address by combining the IPv6 prefix with the MAP 1163 interface identifier (that embeds the IPv4 address). 1165 IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212:0000 1167 Example 5 - Rule with no embedded address bits and address sharing 1168 (sharing ratio 256) 1169 End-User IPv6 prefix: 2001:db8:0012:3400::/56 1170 Basic Mapping Rule: {2001:db8:0012:3400::/56 (Rule IPv6 prefix), 1171 192.0.2.18/32 (Rule IPv4 prefix), 1172 0 (Rule EA-bits length)} 1173 PSID length: 8. (From DHCP. Sharing ratio of 256) 1174 PSID offset: 6 (Default) 1175 PSID : 0x34 (From DHCP.) 1177 A MAP node can via the Basic Mapping Rule determine the IPv4 1178 address and port-set as shown below: 1180 EA bits offset: 0 1181 IPv4 suffix bits (p): Length of IPv4 address (32) - 1182 IPv4 prefix length (32) = 0 1183 IPv4 address: 192.0.2.18 (0xc0000212) 1184 PSID offset: 6 1185 PSID length: 8 1186 PSID: 0x34 1188 Available ports (63 ranges) : 1232-1235, 2256-2259, ...... , 1189 63696-63699, 64720-64723 1191 The Basic Mapping Rule information allows a MAP CE also to 1192 determine (complete) its full IPv6 address by combining the IPv6 1193 prefix with the MAP interface identifier (that embeds the IPv4 1194 address and PSID). 1196 IPv6 address of MAP CE: 2001:db8:0012:3400:0000:c000:0212:0034 1198 Note that the IPv4 address and PSID is not derived from the IPv6 1199 prefix assigned to the CE, but provisioned separately using 1200 e.g., DHCP. 1202 Appendix B. A More Detailed Description of the Derivation of the Port 1203 Mapping Algorithm 1205 This Appendix describes how the port mapping algorithm described in 1206 Section 5.1 was derived. The algorithm is used in domains whose 1207 rules allow IPv4 address sharing. 1209 The basic requirement for a port mapping algorithm is that the port- 1210 sets it assigns to different MAP CEs MUST be non-overlapping. A 1211 number of other requirements guided the choice of the algorithm: 1213 o In keeping with the general MAP algorithm the port-set MUST be 1214 derivable from a port-set identifier (PSID) that can be embedded 1215 in the End-user IPv6 prefix. 1217 o The mapping MUST be reversible, such that, given the port number, 1218 the PSID of the port-set to which it belongs can be quickly 1219 derived. 1221 o The algorithm MUST allow a broad range of address sharing ratios. 1223 o It SHOULD be possible to exclude subsets of the complete port 1224 numbering space from assignment. Most operators would exclude the 1225 system ports (0-1023). A conservative operator might exclude all 1226 but the transient ports (49152-65535). 1228 o The effect of port exclusion on the possible values of the End- 1229 user IPv6 prefix (i.e., due to restrictions on the PSID value) 1230 SHOULD be minimized. 1232 o For administrative simplicity, the algorithm SHOULD allocate the 1233 the same or almost the same number of ports to each CE sharing a 1234 given IPv4 address. 1236 The two extreme cases that an algorithm satisfying those conditions 1237 might support are: (1) the port numbers are not contiguous for each 1238 PSID, but uniformly distributed across the allowed port range; (2) 1239 the port numbers are contiguous in a single range for each PSID. The 1240 port mapping algorithm proposed here is called the Generalized 1241 Modulus Algorithm (GMA) and supports both these cases. 1243 For a given IPv4 address sharing ratio (R) and the maximum number of 1244 contiguous ports (M) in a port-set, the GMA is defined as: 1246 a. The port numbers (P) corresponding to a given PSID are generated 1247 by: 1249 (1) ... P = (R * M) * i + M * PSID + j 1251 where i and j are indices and the ranges of i, j, and the PSID 1252 are discussed in a moment. 1254 b. For any given port number P, the PSID is calculated as: 1256 (2) ... PSID = trunc((P modulo (R * M)) / M) 1257 where trunc() is the operation of rounding down to the nearest 1258 integer. 1260 Formula (1) can be interpreted as follows. First, the available port 1261 space is divided into blocks of size R * M. Each block is divided 1262 into R individual ranges of length M. The index i in formula (1) 1263 selects a block, PSID selects a range within that block, and the 1264 index j selects a specific port value within the range. On the basis 1265 of this interpretation: 1267 o i ranges from ceil(N / (R * M)) to trunc(65536/(R * M)) - 1, where 1268 ceil is the operation of rounding up to the nearest integer and N 1269 is the number of ports (e.g., 1024) excluded from the lower end of 1270 the range. That is, any block containing excluded values is 1271 discarded at the lower end, and if the final block has fewer than 1272 R * M values it is discarded. This ensures that the same number 1273 of ports is assigned to every PSID. 1275 o PSID ranges from 0 to R - 1; 1277 o j ranges from 0 to M - 1. 1279 B.1. Bit Representation of the Algorithm 1281 If R and M are powers of 2 (R = 2^k, M = 2^m), formula (1) translates 1282 to a computationally convenient structure for any port number 1283 represented as a 16-bit binary number. This structure is shown in 1284 Figure 9. 1286 0 8 15 1287 +---------------+----------+------+-------------------+ 1288 | P | 1289 ----------------+-----------------+-------------------+ 1290 | i | PSID | j | 1291 +---------------+----------+------+-------------------+ 1292 |<----a bits--->|<-----k bits---->|<------m bits----->| 1294 Figure 9: Bit Representation of a Port Number 1296 As shown in the figure, the index value i of formula (1) is given by 1297 the first a = 16 - k - m bits of the port number. The PSID value is 1298 given by the next k bits, and the index value j is given by the last 1299 m bits. 1301 Because the PSID is always in the same position in the port number 1302 and always the same length, different PSID values are guaranteed to 1303 generate different sets of port numbers. In the reverse direction, 1304 the generating PSID can be extracted from any port number by a bit 1305 mask operation. 1307 Note that when M and R are powers of 2, 65536 divides evenly by R * 1308 M. Hence the final block is complete and the upper bound on i is 1309 exactly 65536/(R * M) - 1. The lower bound on i is still the minimum 1310 required to ensure that the required set of ports is excluded. No 1311 port numbers are wasted through discarding of blocks at the lower end 1312 if block size R * M is a factor of N, the number of ports to be 1313 excluded. 1315 As a final note, the number of blocks into which the range 0-65535 is 1316 being divided in the above representation is given by 2^a. Hence the 1317 case where a = 0 can be interpreted as one where the complete range 1318 has been divided into a single block, and individual port-sets are 1319 contained in contiguous ranges in that block. We cannot throw away 1320 the whole block in that case, so port exclusion has to be achieved by 1321 putting a lower bound equal to ceil(N / M) on the allowed set of PSID 1322 values instead. 1324 B.2. GMA examples 1326 For example, for R = 256, PSID = 0, offset: a = 6 and PSID length: k 1327 = 8 bits 1329 Available ports (63 ranges) : 1024-1027, 2048-2051, ...... , 1330 63488-63491, 64512-64515 1332 Example 1: with offset = 6 (a = 6) 1334 For example, for R = 64, PSID = 0, a = 0 (PSID offset = 0 and PSID 1335 length = 6 bits), no port exclusion: 1337 Available ports (1 range) : 0-1023 1339 Example 2: with offset = 0 (a = 0) and N = 0 1341 Authors' Addresses 1343 Ole Troan (editor) 1344 Cisco Systems 1345 Philip Pedersens vei 1 1346 Lysaker 1366 1347 Norway 1349 Email: ot@cisco.com 1350 Wojciech Dec 1351 Cisco Systems 1352 Haarlerbergpark Haarlerbergweg 13-19 1353 Amsterdam, NOORD-HOLLAND 1101 CH 1354 Netherlands 1356 Email: wdec@cisco.com 1358 Xing Li 1359 CERNET Center/Tsinghua University 1360 Room 225, Main Building, Tsinghua University 1361 Beijing 100084 1362 People's Republic of China 1364 Email: xing@cernet.edu.cn 1366 Congxiao Bao 1367 CERNET Center/Tsinghua University 1368 Room 225, Main Building, Tsinghua University 1369 Beijing 100084 1370 People's Republic of China 1372 Email: congxiao@cernet.edu.cn 1374 Satoru Matsushima 1375 SoftBank Telecom 1376 1-9-1 Higashi-Shinbashi, Munato-ku 1377 Tokyo 1378 Japan 1380 Email: satoru.matsushima@g.softbank.co.jp 1382 Tetsuya Murakami 1383 IP Infusion 1384 1188 East Arques Avenue 1385 Sunnyvale 1386 USA 1388 Email: tetsuya@ipinfusion.com 1389 Tom Taylor (editor) 1390 Huawei Technologies 1391 Ottawa 1392 Canada 1394 Email: tom.taylor.stds@gmail.com