idnits 2.17.1 draft-mdt-softwire-mapping-address-and-port-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 30, 2012) is 4460 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) == Missing Reference: 'I-D.mdt-softwire-map-deployment' is mentioned on line 163, but not defined == Unused Reference: 'RFC2766' is defined on line 741, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-mdt-softwire-map-dhcp-option-02 ** Downref: Normative reference to an Experimental RFC: RFC 6346 == Outdated reference: A later version (-05) exists of draft-ietf-softwire-stateless-4v6-motivation-00 -- Obsolete informational reference (is this intentional?): RFC 1933 (Obsoleted by RFC 2893) -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Troan 3 Internet-Draft cisco 4 Intended status: Standards Track S. Matsushima 5 Expires: August 2, 2012 SoftBank Telecom 6 T. Murakami 7 IP Infusion 8 X. Li 9 C. Bao 10 CERNET Center/Tsinghua 11 University 12 January 30, 2012 14 Mapping of Address and Port (MAP) 15 draft-mdt-softwire-mapping-address-and-port-03 17 Abstract 19 This document describes a generic mechanism for mapping between IPv4 20 addresses and IPv6 addresses and transport layer ports. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 2, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Mapping Rules . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5.1. Port mapping algorithm . . . . . . . . . . . . . . . . . . 8 62 5.1.1. Bit Representation of the Algorithm . . . . . . . . . 9 63 5.1.2. GMA examples . . . . . . . . . . . . . . . . . . . . . 9 64 5.1.3. GMA Provisioning Considerations . . . . . . . . . . . 10 65 5.2. Basic mapping rule (BMR) . . . . . . . . . . . . . . . . . 10 66 5.3. Forwarding mapping rule (FMR) . . . . . . . . . . . . . . 13 67 5.4. Default mapping rule (DMR) . . . . . . . . . . . . . . . . 14 68 6. The IPv6 Interface Identifier . . . . . . . . . . . . . . . . 15 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 75 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 78 1. Introduction 80 The mechanism of mapping IPv4 addresses in IPv6 addresses has been 81 described in numerous mechanisms dating back to 1996 [RFC1933]. The 82 Automatic tunneling mechanism described in RFC1933, assigned a 83 globally unique IPv6 address to a host by combining the host's IPv4 84 address with a well-known IPv6 prefix. Given an IPv6 packet with a 85 destination address with an embedded IPv4 address, a node could 86 automatically tunnel this packet by extracting the IPv4 tunnel end- 87 point address from the IPv6 destination address. 89 There are numerous variations of this idea, described in 6over4 90 [RFC2529], 6to4 [RFC3056], ISATAP [RFC5214], and 6rd [RFC5969]. The 91 differences between these are the use of well-known IPv6 prefixes, or 92 Service Provider assigned IPv6 prefixes, and the position of the 93 embedded IPv4 bits in the IPv6 address. Teredo [RFC4380] added a 94 twist to this to achieve NAT traversal by also encoding transport 95 layer ports into the IPv6 address. 6rd, to achieve more efficient 96 encoding, allowed for only the suffix of an IPv4 address to be 97 embedded, with the IPv4 prefix being deduced from other provisioning 98 mechanisms. 100 NAT-PT [RFC2766](deprecated) combined with a DNS ALG used address 101 mapping to put NAT state, namely the IPv6 to IPv4 binding encoded in 102 an IPv6 address. This characteristic has been inherited by NAT64 103 [RFC6146] and DNS64 [RFC6147] which rely on an address format defined 104 in [RFC6052]. [RFC6052] specifies the algorithmic translation of an 105 IPv6 address to IPv4 address. In particular, [RFC6052] specifies the 106 address format to build IPv4-converted and IPv4-translatable IPv6 107 addresses. RFC6052 discusses the transport of the port-set 108 information in an IPv4-embedded IPv6 address but the conclusion was 109 the following (excerpt from [RFC6052]): 111 "There have been proposals to complement stateless translation with a 112 port range feature. Instead of mapping an IPv4 address to exactly 113 one IPv6 prefix, the options would allow several IPv6 nodes to share 114 an IPv4 address, with each node managing a different set of ports. 115 If a port-set extension is needed, it could be defined later, using 116 bits currently reserved as null in the suffix." 118 The commonalities of all these IPv6 over IPv4 mechanisms are: 120 o Automatically provisions an IPv6 address for a host or an IPv6 121 prefix for a site 123 o Algorithmic or implicit address resolution for tunneling or 124 encapsulation. Given an IPv6 destination address, an IPv4 tunnel 125 endpoint address can be calculated. Likewise for translation, an 126 IPv4 address can be calculated from an IPv6 destination address 127 and vice versa. 129 o Embedding of an IPv4 address or part thereof and optionally 130 transport layer ports into an IPv6 address. 132 In phases of IPv4 to IPv6 migration, IPv6 only networks will be 133 common, while there will still be a need for residual IPv4 134 deployment. This document describes a more generic mapping of IPv4 135 to IPv6 that can be used both for encapsulation (IPv4 over IPv6) and 136 for translation between the two protocols. 138 Just as the IPv6 over IPv4 mechanisms referred to above, the residual 139 IPv4 over IPv6 mechanisms must be capable of: 141 o Provisioning an IPv4 prefix, an IPv4 address or a shared IPv4 142 address. 144 o Algorithmically map between an IPv4 prefix, IPv4 address or a 145 shared IPv4 address and an IPv6 address. 147 The unified mapping scheme described here supports translation mode, 148 encapsulation mode, in both mesh and hub and spoke topologies. 150 This document describes delivery of IPv4 unicast service across an 151 IPv6 infrastructure. IPv4 multicast is not considered further in 152 this document. 154 The A+P (Address and Port) architecture of sharing an IPv4 address by 155 distributing the port space is described in [RFC6346]. Specifically 156 section 4 of [RFC6346] covers stateless mapping. The corresponding 157 stateful solution DS-lite is described in [RFC6333]. The motivation 158 for work is described in 159 [I-D.ietf-softwire-stateless-4v6-motivation]. 161 A companion document defines a DHCPv6 option for provisioning of MAP 162 [I-D.mdt-softwire-map-dhcp-option]. Deployment considerations are 163 described in [I-D.mdt-softwire-map-deployment]. 165 2. Conventions 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119 [RFC2119]. 171 3. Terminology 173 MAP domain: A set of MAP CEs and BRs connected to the same 174 virtual link. A service provider may deploy a 175 single MAP domain, or may utilize multiple MAP 176 domains. 178 MAP Rule A set of parameters describing the mapping 179 between an IPv4 prefix, IPv4 address or shared 180 IPv4 address and an IPv6 prefix or address. 181 Each MAP node in the domain has the same set of 182 rules. 184 MAP node A device that implements MAP. 186 MAP Border Relay (BR): A MAP enabled router managed by the service 187 provider at the edge of a MAP domain. A Border 188 Relay router has at least an IPv6-enabled 189 interface and an IPv4 interface connected to 190 the native IPv4 network. A MAP BR may also be 191 referred to simply as a "BR" within the context 192 of MAP. 194 MAP Customer Edge (CE): A device functioning as a Customer Edge 195 router in a MAP deployment. A typical MAP CE 196 adopting MAP rules will serve a residential 197 site with one WAN side interface, and one or 198 more LAN side interfaces. A MAP CE may also be 199 referred to simply as a "CE" within the context 200 of MAP. 202 Port-set: Each node has a separate part of the transport 203 layer port space; denoted as a port-set. 205 Port-set ID (PSID): Algorithmically identifies a set of ports 206 exclusively assigned to the CE. 208 Shared IPv4 address: An IPv4 address that is shared among multiple 209 CEs. Only ports that belong to the assigned 210 port-set can be used for communication. Also 211 known as a Port-Restricted IPv4 address. 213 End-user IPv6 prefix: The IPv6 prefix assigned to an End-user CE by 214 other means than MAP itself. E.g. provisioned 215 using DHCPv6 PD [RFC3633] or configured 216 manually. It is unique for each CE. 218 MAP IPv6 address: The IPv6 address used to reach the MAP function 219 of a CE from other CE's and from BR's. 221 Rule IPv6 prefix: An IPv6 prefix assigned by a Service Provider 222 for a mapping rule. 224 Rule IPv4 prefix: An IPv4 prefix assigned by a Service Provider 225 for a mapping rule. 227 IPv4 Embedded Address (EA) bits: The IPv4 EA-bits in the IPv6 228 address identify an IPv4 prefix/address (or 229 part thereof) or a shared IPv4 address (or part 230 thereof) and a port-set identifier. 232 MRT: MAP Rule table. Address and Port aware 233 datastructure, supporting longest match 234 lookups. The MRT is used by the MAP forwarding 235 function. 237 4. Architecture 239 A full IPv4 address or IPv4 prefix can be used like today, e.g. for 240 identifying an interface or as a DHCP pool. A shared IPv4 address on 241 the other hand, MUST NOT be used to identify an interface. While it 242 is theoretically possible to make host stacks and applications port- 243 aware, that is considered a too drastic change to the IP model 244 [RFC6250]. 246 The MAP architecture described here, restricts the use of the shared 247 IPv4 address to only be used as the global address (outside) of the 248 NAPT [RFC2663] running on the CE. The NAPT MUST in turn be connected 249 to a MAP aware forwarding function, that does encapsulation/ 250 decapsulation or translation to IPv6. 252 For packets outbound from the private IPv4 network, the CE NAPT MUST 253 translate transport identifiers (e.g. TCP and UDP port numbers) so 254 that they fall within the assigned CE's port-range. 256 The forwarding function uses the MRT to make forwarding decisions. 257 The table consist of the mapping rules. An entry in the table 258 consists of an IPv4 prefix and PSID. The normal best matching prefix 259 algorithm is used. With a maximum key length of 48 (32 + 16). E.g. 260 with a sharing ratio of 64 (6 bit PSID length) a host route for this 261 CE would be a /38 (32 + 6). 263 5. Mapping Rules 265 A MAP node is provisioned with one or more mapping rules. 267 Mapping rules are used differently depending on their function. 268 Every MAP node must be provisioned with a Basic mapping rule. This 269 is used by the node to configure itself with an IPv4 address, IPv4 270 prefix or shared IPv4 address from an End-user IPv6 prefix. This 271 same basic rule can also be used for forwarding, where an IPv4 272 destination address and optionally a destination port is mapped into 273 an IPv6 address or prefix. Additional mapping rules can be specified 274 to allow for e.g. multiple different IPv4 subnets to exist within the 275 domain. Additional mapping rules are recognized by having a Rule 276 IPv6 prefix different from the base End-user IPv6 prefix. 278 Traffic outside of the domain (IPv4 address not matching (using 279 longest matching prefix) any Rule IPv4 prefix in the Rules database) 280 will be forward using the Default mapping rule. The Default mapping 281 rule maps outside destinations to the BR's IPv6 address or prefix. 283 There are three types of mapping rules: 285 1. Basic Mapping Rule - used for IPv4 prefix, address or port set 286 assignment. There can only be one Basic Mapping Rule per End- 287 user IPv6 prefix. The Basic Mapping Rule is used to configure 288 the MAP IPv6 address or prefix. 290 * Rule IPv6 prefix (including prefix length) 292 * Rule IPv4 prefix (including prefix length) 294 * Rule EA-bits length (in bits) 296 * Rule Port Parameters (optional) 298 2. Forwarding Mapping Rule - used for forwarding. The Basic Mapping 299 Rule is also a Forwarding Mapping Rule. Each Forwarding Mapping 300 Rule will result in an entry in the MRT for the Rule IPv4 prefix. 302 * Rule IPv6 prefix (including prefix length) 304 * Rule IPv4 prefix (including prefix length) 306 * Rule EA-bits length (in bits) 308 * Rule Port Parameters (optional) 310 3. Default Mapping Rule - used for destinations outside the MAP 311 domain. A 0.0.0.0/0 entry is installed in the MRT for this rule. 313 * Rule IPv6 prefix (including prefix length) 315 * Rule BR IPv4 address 317 A MAP node finds its Basic Mapping Rule by doing a longest match 318 between the End-user IPv6 prefix and the Rule IPv6 prefix in the 319 Mapping Rule database. The rule is then used for IPv4 prefix, 320 address or shared address assignment. 322 A MAP IPv6 address (or prefix) is formed from the BMR Rule IPv6 323 prefix. This address MUST be assigned to an interface of the MAP 324 node and is used to terminate all MAP traffic being sent or received 325 to the node. 327 Port-aware IPv4 entries in the MRT are installed for all the 328 Forwarding Mapping Rules and an IPv4 default route for the Default 329 Mapping Rule. 331 In hub and spoke mode, all traffic MUST be forwarded using the 332 Default Mapping Rule. 334 5.1. Port mapping algorithm 336 Different Port-Set Identifiers (PSID) MUST have non-overlapping port- 337 sets. The two extreme cases are: (1) the port numbers are not 338 contiguous for each PSID, but uniformly distributed across the port 339 range (0-65535); (2) the port numbers are contiguous in a single 340 range for each PSID. The port mapping algorithm proposed here is 341 called the Generalized Modulus Algorithm (GMA) and supports both 342 these cases. 344 For a given sharing ratio (R) and the maximum number of contiguous 345 ports (M), the GMA algorithm is defined as: 347 1. The port number (P) of a given PSID (K) is composed of: 349 P = R * M * j + M * K + i 351 Where: 353 * PSID: K = 0 to R - 1 355 * Port range index: j = (4096 / M) / R to ((65536 / M) / R) - 1, 356 if the port numbers (0 - 4095) are excluded. 358 * Contiguous Port index: i = 0 to M - 1 360 2. The PSID (K) of a given port number (P) is determined by: 362 K = (floor(P/M)) % R 364 Where: 366 * % is the modulus operator 368 * floor(arg) is a function that returns the largest integer not 369 greater than arg. 371 5.1.1. Bit Representation of the Algorithm 373 Given a sharing ratio (R=2^k), the maximum number of contiguous ports 374 (M=2^m), for any PSID (K) and available ports (P) can be represented 375 as: 377 0 8 15 378 +---------------+----------+------+-------------------+ 379 | P | 380 ----------------+-----------------+-------------------+ 381 | A (j) | PSID (K) | M (i) | 382 +---------------+----------+------+-------------------+ 383 |<----a bits--->|<-----k bits---->|<------m bits----->| 385 Figure 1: Bit representation 387 Where j and i are the same indexes defined in the port mapping 388 algorithm. 390 For any port number, the PSID can be obtained by bit mask operation. 392 For a > 0, j MUST be larger than 0. This ensures that the algorithm 393 excludes the system ports ([I-D.ietf-tsvwg-iana-ports]). For a = 0, 394 j MAY be 0 to allow for the provisioning of the system ports. 396 5.1.2. GMA examples 397 For example, for R = 1024, PSID offset: a = 4 and PSID length: k = 10 398 bits 400 Port-set-1 Port-set-2 401 PSID=0 | 4096, 4097, 4098, 4099, | 8192, 8193, 8194, 8195, | ... 402 PSID=1 | 4100, 4101, 4102, 4103, | 8196, 8197, 8198, 8199, | ... 403 PSID=2 | 4104, 4105, 4106, 4107, | 8200, 8201, 8202, 8203, | ... 404 PSID=3 | 4108, 4109, 4110, 4111, | 8204, 8205, 8206, 8207, | ... 405 ... 406 PSID=1023| 8188, 8189, 8190, 8191, | 12284, 12285, 12286, 12287,| ... 408 Example 1: with offset = 4 (a = 4) 410 For example, for R = 64, a = 0 (PSID offset = 0 and PSID length = 6 411 bits): 413 Port-set 414 PSID=0 | [ 0 - 1023] 415 PSID=1 | [1024 - 2047] 416 PSID=2 | [2048 - 3071] 417 PSID=3 | [3072 - 4095] 418 ... 419 PSID=63 | [64512 - 65535] 421 Example 2: with offset = 0 (a = 0) 423 5.1.3. GMA Provisioning Considerations 425 The number of offset bits (a) and excluded ports are optionally 426 provisioned via the "Rule Port Mapping Parameters" in the Basic 427 Mapping Rule. 429 The defaults are: 431 o Excluded ports : 0-4095 433 o Offset bits (a) : 4 435 To simplify the GMA port mapping algorithm the defaults are chosen so 436 that the PSID field starts on a nibble boundary and the excluded port 437 range (0-1023) is extended to 0-4095. 439 5.2. Basic mapping rule (BMR) 440 | n bits | o bits | m bits | 128-n-o-m bits | 441 +--------------------+-----------+---------+------------+----------+ 442 | Rule IPv6 prefix | EA bits |subnet ID| interface ID | 443 +--------------------+-----------+---------+-----------------------+ 444 |<--- End-user IPv6 prefix --->| 446 Figure 2: IPv6 address format 448 The Embedded Address bits (EA bits) are unique per end user within a 449 Rule IPv6 prefix. The Rule IPv6 prefix is the part of the End-user 450 IPv6 prefix that is common among all CEs using the same Basic Mapping 451 Rule within the MAP domain. The EA bits encode the CE specific IPv4 452 address and port information. The EA bits can contain a full or part 453 of an IPv4 prefix or address, and in the shared IPv4 address case 454 contains a Port-Set Identifier (PSID). 456 The MAP IPv6 address is created by concatenating the End-user IPv6 457 prefix with the MAP subnet-id and the interface-id as specified in 458 Section 6. 460 The MAP subnet ID is defined to be the first subnet (all bits set to 461 zero). A MAP node MUST reserve the first IPv6 prefix in a End-user 462 IPv6 prefix for the purpose of MAP. 464 Shared IPv4 address: 466 | r bits | p bits | | q bits | 467 +-------------+---------------------+ +------------+ 468 | Rule IPv4 | IPv4 Address suffix | |Port-Set ID | 469 +-------------+---------------------+ +------------+ 470 | 32 bits | 472 Figure 3: Shared IPv4 address 474 Complete IPv4 address: 476 | r bits | p bits | 477 +-------------+---------------------+ 478 | Rule IPv4 | IPv4 Address suffix | 479 +-------------+---------------------+ 480 | 32 bits | 482 Figure 4: Complete IPv4 address 483 IPv4 prefix: 485 | r bits | p bits | 486 +-------------+---------------------+ 487 | Rule IPv4 | IPv4 Address suffix | 488 +-------------+---------------------+ 489 | < 32 bits | 491 Figure 5: IPv4 prefix 493 The length of r MAY be zero, in which case the complete IPv4 address 494 or prefix is encoded in the EA bits. If only a part of the IPv4 495 address/prefix is encoded in the EA bits, the Rule IPv4 prefix is 496 provisioned to the CE by other means (e.g. a DHCPv6 option). To 497 create a complete IPv4 address (or prefix), the IPv4 address suffix 498 (p) from the EA bits, are concatenated with the Rule IPv4 prefix (r 499 bits). 501 The offset of the EA bits field in the IPv6 address is equal to the 502 BMR Rule IPv6 prefix length. The length of the EA bits field (o) is 503 given by the BMR Rule EA-bits length. The sum of the Rule IPv6 504 Prefix length and the Rule EA-bits length MUST be less or equal than 505 the End-user IPv6 prefix length. 507 If o + r < 32 (length of the IPv4 address in bits), then an IPv4 508 prefix is assigned. 510 If o + r is equal to 32, then a full IPv4 address is to be assigned. 511 The address is created by concatenating the Rule IPv4 prefix and the 512 EA-bits. 514 If o + r is > 32, then a shared IPv4 address is to be assigned. The 515 number of IPv4 address suffix bits (p) in the EA bits is given by 32 516 - r bits. The PSID bits are used to create a port-set. The length 517 of the PSID bit field within EA bits is: o - p. 519 In the following examples, only the suffix (last 8 bits) of the IPv4 520 address is embedded in the EA bits (r = 24), while the IPv4 prefix 521 (first 24 bits) is given in the BMR Rule IPv4 prefix. 523 Example: 525 Given: 526 End-user IPv6 prefix: 2001:db8:0012:3400::/56 527 Basic Mapping Rule: {2001:db8:0000::/40 (Rule IPv6 prefix), 528 192.0.2.0/24 (Rule IPv4 prefix), 529 16 (Rule EA-bits length)} 530 Sharing ratio: 256 (16 - (32 - 24) = 8. 2^8 = 256) 531 PSID offset: 4 533 We get IPv4 address and port-set: 534 EA bits offset: 40 535 IPv4 suffix bits (p): Length of IPv4 address (32) - 536 IPv4 prefix length (24) = 8 537 IPv4 address: 192.0.2.18 539 PSID start: 40 + p = 40 + 8 = 48 540 PSID length: o - p = 16 (56 - 40) - 8 = 8 541 PSID: 0x34 542 Port-set-1: 4928, 4929, 4930, 4931, 4932, 4933, 4934, 4935, 543 4936, 4937, 4938, 4939, 4940, 4941, 4942, 4943 544 Port-set-2: 9024, 9025, 9026, 9027, 9028, 9029, 9030, 9031, 545 9032, 9033, 9034, 9035, 9036, 9037, 9038, 9039 546 ... 547 Port-set-15: 62272, 62273, 62274, 62275, 548 62276, 62277, 62278, 62279, 549 62280, 62281, 62282, 62283, 550 62284, 62285, 62286, 62287, 552 5.3. Forwarding mapping rule (FMR) 554 On adding an FMR rule, an IPv4 route is installed in the AP RIB for 555 the Rule IPv4 prefix. 557 On forwarding an IPv4 packet, a best matching prefix lookup is done 558 in the IPv4 routing table and the correct FMR is chosen. 560 | 32 bits | | 16 bits | 561 +--------------------------+ +-------------------+ 562 | IPv4 destination address | | IPv4 dest port | 563 +--------------------------+ +-------------------+ 564 : : ___/ : 565 | p bits | / q bits : 566 +----------+ +------------+ 567 |IPv4 sufx| |Port-Set ID | 568 +----------+ +------------+ 569 \ / ____/ ________/ 570 \ : __/ _____/ 571 \ : / / 572 | n bits | o bits | m bits | 128-n-o-m bits | 573 +--------------------+-----------+---------+------------+----------+ 574 | Rule IPv6 prefix | EA bits |subnet ID| interface ID | 575 +--------------------+-----------+---------+-----------------------+ 576 |<--- End-user IPv6 prefix --->| 578 Figure 6: Deriving of MAP IPv6 address 580 Example: 582 Given: 583 IPv4 destination address: 192.0.2.18 584 IPv4 destination port: 9030 585 Forwarding Mapping Rule: {2001:db8:0000::/40 (Rule IPv6 prefix), 586 192.0.2.0/24 (Rule IPv4 prefix), 587 16 (Rule EA-bits length)} 588 PSID offset: 4 590 We get IPv6 address: 591 IPv4 suffix bits (p): 32 - 24 = 8 (18 (0x12)) 592 PSID length: 8 593 PSID: 0x34 (9030 (0x2346)) 594 EA bits: 0x1234 595 MAP IPv6 address: 2001:db8:0012:3400:00c0:0002:1200:3400 597 5.4. Default mapping rule (DMR) 599 The Default Mapping rule is used to reach IPv4 destinations outside 600 of the MAP domain. Traffic using this rule will be sent from a CE to 601 a BR. 603 The Rule IPv4 prefix in the DMR is: 0.0.0.0/0. The Rule IPv6 prefix 604 is the IPv6 address or prefix of the BR. Which is used, is dependent 605 on the mode used. For example translation requires that the IPv4 606 destination address is encoded in the BR IPv6 address, so only a 607 prefix is used in the DMR to allow for a generated interface 608 identifier. For the encapsulation mode the Rule IPv6 prefix can be 609 the full IPv6 address of the BR. 611 There MUST be only one Default Mapping Rule within a MAP domain. 613 Default Mapping Rule: 614 {2001:db8:0001:0000:<interface-id>:/128 (Rule IPv6 prefix), 615 0.0.0.0/0 (Rule IPv4 prefix), 616 192.0.2.1 (BR IPv4 address)} 618 Example 3: Default Mapping Rule 620 In most implementations of a routing table, the next-hop address must 621 be of the same address family as the prefix. To satisfy this 622 requirement a BR IPv4 address is included in the rule. Giving a 623 default route in the IPv4 routing table: 625 0.0.0.0 -> 192.0.2.1, MAP-Interface0 627 6. The IPv6 Interface Identifier 629 The Interface identifier format is based on the format specified in 630 section 2.2 of [RFC6052], with the added PSID format field. 632 In an encapsulation solution, an IPv4 address and port is mapped to 633 an IPv6 address. This is the address of the tunnel end point of the 634 receiving MAP CE. For traffic outside the MAP domain, the IPv6 635 tunnel end point address is the IPv6 address of the BR. The 636 interface-id used for all MAP nodes in the domain MUST be 637 deterministic. 639 When translating, the destination IPv4 address is translated into a 640 corresponding IPv6 address. In the case of traffic outside of the 641 MAP domain, it is translated to the BR's IPv6 prefix. For the BR to 642 be able to reverse the translation, the full destination IPv4 address 643 must be encoded in the IPv6 address. The same thing applies if an 644 IPv4 prefix is encoded in the IPv6 address, then the reverse 645 translator needs to know the full destination IPv4 address, which has 646 to be encoded in the interface-id. 648 The encoding of the full IPv4 address into the interface identifier, 649 both for the source and destination IPv6 addresses have been shown to 650 be useful for troubleshooting. 652 +--+---+---+---+---+---+---+---+---+ 653 |PL| 8 16 24 32 40 48 56 | 654 +--+---+---+---+---+---+---+---+---+ 655 |64| u | IPv4 address | PSID | 0 | 656 +--+---+---+---+---+---+---+---+---+ 658 Figure 7 660 In the case of an IPv4 prefix, the IPv4 address field is right-padded 661 with zeroes up to 32 bits. The PSID field is left-padded to create a 662 16 bit field. For an IPv4 prefix or a complete IPv4 address, the 663 PSID field is zero. 665 If the End-user IPv6 prefix length is larger than 64, the most 666 significant parts of the interface identifier is overwritten by the 667 prefix. For translation mode the End-user IPv6 prefix MUST be 64 or 668 shorter. 670 7. IANA Considerations 672 This specification does not require any IANA actions. 674 8. Security Considerations 676 Specific security considerations with the MAP mechanism are detailed 677 in the encapsulation and translation documents [I-D.mdt-map-t/ 678 I-D.mdt-map-e]. 680 [RFC6269] outlines general issues with IPv4 address sharing. 682 9. Contributors 684 Mohamed Boucadair, Gang Chen, Maoke Chen, Wojciech Dec, Xiaohong 685 Deng, Jouni Korhonen, Tomasz Mrugalski, Jacni Qin, Chunfa Sun, Qiong 686 Sun, Leaf Yeh. 688 10. Acknowledgements 690 This document is based on the ideas of many. In particular Remi 691 Despres, who has tirelessly worked on generalized mechanisms for 692 stateless address mapping. 694 The authors would like to thank Guillaume Gottard, Dan Wing, Jan 695 Zorz, Necj Scoberne, Tina Tsou for their thorough review and 696 comments. 698 11. References 700 11.1. Normative References 702 [I-D.mdt-softwire-map-dhcp-option] 703 Mrugalski, T., Boucadair, M., Deng, X., Troan, O., and C. 704 Bao, "DHCPv6 Options for Mapping of Address and Port", 705 draft-mdt-softwire-map-dhcp-option-02 (work in progress), 706 January 2012. 708 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 709 Requirement Levels", BCP 14, RFC 2119, March 1997. 711 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 712 IPv4 Address Shortage", RFC 6346, August 2011. 714 11.2. Informative References 716 [I-D.ietf-softwire-stateless-4v6-motivation] 717 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 718 Borges, I., and G. Chen, "Motivations for Stateless IPv4 719 over IPv6 Migration Solutions", 720 draft-ietf-softwire-stateless-4v6-motivation-00 (work in 721 progress), September 2011. 723 [I-D.ietf-tsvwg-iana-ports] 724 Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 725 Cheshire, "Internet Assigned Numbers Authority (IANA) 726 Procedures for the Management of the Service Name and 727 Transport Protocol Port Number Registry", 728 draft-ietf-tsvwg-iana-ports-10 (work in progress), 729 February 2011. 731 [RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 732 IPv6 Hosts and Routers", RFC 1933, April 1996. 734 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 735 Domains without Explicit Tunnels", RFC 2529, March 1999. 737 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 738 Translator (NAT) Terminology and Considerations", 739 RFC 2663, August 1999. 741 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 742 Translation - Protocol Translation (NAT-PT)", RFC 2766, 743 February 2000. 745 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 746 via IPv4 Clouds", RFC 3056, February 2001. 748 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 749 Host Configuration Protocol (DHCP) version 6", RFC 3633, 750 December 2003. 752 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 753 Network Address Translations (NATs)", RFC 4380, 754 February 2006. 756 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 757 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 758 March 2008. 760 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 761 Infrastructures (6rd) -- Protocol Specification", 762 RFC 5969, August 2010. 764 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 765 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 766 October 2010. 768 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 769 NAT64: Network Address and Protocol Translation from IPv6 770 Clients to IPv4 Servers", RFC 6146, April 2011. 772 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 773 Beijnum, "DNS64: DNS Extensions for Network Address 774 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 775 April 2011. 777 [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, 778 May 2011. 780 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 781 Roberts, "Issues with IP Address Sharing", RFC 6269, 782 June 2011. 784 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 785 Stack Lite Broadband Deployments Following IPv4 786 Exhaustion", RFC 6333, August 2011. 788 Authors' Addresses 790 Ole Troan 791 cisco 792 Oslo 793 Norway 795 Email: ot@cisco.com 797 Satoru Matsushima 798 SoftBank Telecom 799 1-9-1 Higashi-Shinbashi, Munato-ku 800 Tokyo 801 Japan 803 Email: satoru.matsushima@tm.softbank.co.jp 805 Tetsuya Murakami 806 IP Infusion 807 1188 East Arques Avenue 808 Sunnyvale 809 USA 811 Email: tetsuya@ipinfusion.com 813 Xing Li 814 CERNET Center/Tsinghua University 815 Room 225, Main Building, Tsinghua University 816 Beijing 100084 817 CN 819 Email: xing@cernet.edu.cn 821 Congxiao Bao 822 CERNET Center/Tsinghua University 823 Room 225, Main Building, Tsinghua University 824 Beijing 100084 825 CN 827 Email: congxiao@cernet.edu.cn