idnits 2.17.1 draft-bao-v6ops-rfc6145bis-07.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 1 instance 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 (April 26, 2016) is 2921 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) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-13) exists of draft-ietf-6man-rfc2460bis-04 -- Obsolete informational reference (is this intentional?): RFC 879 (Obsoleted by RFC 7805, RFC 9293) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops C. Bao 3 Internet-Draft X. Li 4 Obsoletes: 6145 (if approved) CERNET Center/Tsinghua 5 Intended status: Standards Track University 6 Expires: October 28, 2016 F. Baker 7 Cisco Systems 8 T. Anderson 9 Redpill Linpro 10 F. Gont 11 Huawei Technologies 12 April 26, 2016 14 IP/ICMP Translation Algorithm (rfc6145bis) 15 draft-bao-v6ops-rfc6145bis-07 17 Abstract 19 This document describes the Stateless IP/ICMP Translation Algorithm 20 (SIIT), which translates between IPv4 and IPv6 packet headers 21 (including ICMP headers). This document obsoletes RFC 6145. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 28, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 58 1.1. IPv4-IPv6 Translation Model . . . . . . . . . . . . . . . 3 59 1.2. Applicability and Limitations . . . . . . . . . . . . . . 3 60 1.3. Stateless vs. Stateful Mode . . . . . . . . . . . . . . . 4 61 1.4. Path MTU Discovery and Fragmentation . . . . . . . . . . . 5 62 2. Changes from RFC 6145 . . . . . . . . . . . . . . . . . . . . 5 63 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Translating from IPv4 to IPv6 . . . . . . . . . . . . . . . . 6 65 4.1. Translating IPv4 Headers into IPv6 Headers . . . . . . . . 7 66 4.2. Translating ICMPv4 Headers into ICMPv6 Headers . . . . . . 9 67 4.3. Translating ICMPv4 Error Messages into ICMPv6 . . . . . . 13 68 4.4. Generation of ICMPv4 Error Message . . . . . . . . . . . . 14 69 4.5. Transport-Layer Header Translation . . . . . . . . . . . . 14 70 4.6. Knowing When to Translate . . . . . . . . . . . . . . . . 15 71 5. Translating from IPv6 to IPv4 . . . . . . . . . . . . . . . . 15 72 5.1. Translating IPv6 Headers into IPv4 Headers . . . . . . . . 17 73 5.1.1. IPv6 Fragment Processing . . . . . . . . . . . . . . . 19 74 5.2. Translating ICMPv6 Headers into ICMPv4 Headers . . . . . . 19 75 5.3. Translating ICMPv6 Error Messages into ICMPv4 . . . . . . 22 76 5.4. Generation of ICMPv6 Error Messages . . . . . . . . . . . 22 77 5.5. Transport-Layer Header Translation . . . . . . . . . . . . 23 78 5.6. Knowing When to Translate . . . . . . . . . . . . . . . . 23 79 6. Mapping of IP Addresses . . . . . . . . . . . . . . . . . . . 23 80 7. Special Considerations for ICMPv6 Packet Too Big . . . . . . . 24 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 28 87 Appendix A. Stateless Translation Workflow Example . . . . . . . 33 88 A.1. H6 Establishes Communication with H4 . . . . . . . . . . . 34 89 A.2. H4 Establishes Communication with H6 . . . . . . . . . . . 35 91 1. Introduction and Motivation 93 This document obsoletes [RFC6145]. 95 Readers of this document are expected to have read and understood the 96 framework described in [RFC6144]. Implementations of this IPv4/IPv6 97 translation specification MUST support one or more address mapping 98 algorithms which are defined in Section 6. 100 1.1. IPv4-IPv6 Translation Model 102 The translation model consists of two or more network domains 103 connected by one or more IP/ICMP translators (XLATs) as shown in 104 Figure 1. 106 --------- --------- 107 // \\ // \\ 108 / +----+ \ 109 | |XLAT| | XLAT: IP/ICMP 110 | IPv4 +----+ IPv6 | Translator 111 | Domain | | Domain | 112 | | | | 113 \ | | / 114 \\ // \\ // 115 -------- --------- 117 Figure 1: IPv4-IPv6 Translation Model 119 The scenarios of the translation model are discussed in [RFC6144]. 121 1.2. Applicability and Limitations 123 This document specifies the translation algorithms between IPv4 124 packets and IPv6 packets. 126 As with [RFC6145], the translating function specified in this 127 document does not translate any IPv4 options, and it does not 128 translate IPv6 extension headers except the Fragment Header. 130 The issues and algorithms in the translation of datagrams containing 131 TCP segments are described in [RFC5382]. 133 Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e., 134 the UDP checksum field is zero) are not of significant use in the 135 Internet, and in general will not be translated by the IP/ICMP 136 translator [Section 4.5]. However, when the translator is configured 137 to forward the packet without a UDP checksum, the fragmented IPv4 UDP 138 packets will be translated. 140 Fragmented ICMP/ICMPv6 packets will not be translated by IP/ICMP 141 translators. 143 The IP/ICMP header translation specified in this document is 144 consistent with requirements of multicast IP/ICMP headers. However, 145 IPv4 multicast addresses [RFC5771] cannot be mapped to IPv6 multicast 146 addresses [RFC3307] based on the unicast mapping rule [RFC6052]. An 147 example of experiments of the multicast address mapping can be found 148 in [RFC6219]. 150 1.3. Stateless vs. Stateful Mode 152 An IP/ICMP translator has two possible modes of operation: stateless 153 and stateful [RFC6144]. In both cases, we assume that a system (a 154 node or an application) that has an IPv4 address but not an IPv6 155 address is communicating with a system that has an IPv6 address but 156 no IPv4 address, or that the two systems do not have contiguous 157 routing connectivity, or they might have contiguous routing 158 connectivity but are interacting via masking addresses (i.e. 159 hairpinning) [RFC4787] and hence are forced to have their 160 communications translated. 162 In the stateless mode, an IP/ICMP translator will convert IPv4 163 addresses to IPv6 and vice versa solely based on the configuration of 164 the stateless IP/ICMP translator and information contained within the 165 packet being translated. For example, for the default behavior 166 defined in [RFC6052], a specific IPv6 address range will represent 167 IPv4 systems (IPv4-converted addresses), and the IPv6 systems have 168 addresses (IPv4-translatable addresses) that can be algorithmically 169 mapped to a subset of the service provider's IPv4 addresses. Other 170 stateless translation algorithms are defined in Section 6. The 171 stateless translator does not keep any dynamic session or binding 172 state, thus there is no requirement that the packets in a single 173 session or flow traverses a single translator. 175 In the stateful mode, a specific IPv6 address range (consisting of 176 IPv4-converted IPv6 addresses) will typically represent IPv4 systems. 177 The IPv6 nodes may use any IPv6 addresses [RFC4291] except in that 178 range. A stateful IP/ICMP translator continuously maintains a 179 dynamic translation table containing bindings between the IPv4 and 180 IPv6 addresses, and likely also the Layer-4 identifiers, that are 181 used in the translated packets. The exact address translations of 182 any given packet thus become dependent on how packets belonging to 183 the same session or flow have been translated. For this reason, 184 stateful translation generally requires that all packets belonging to 185 a single flow must traverse the same translator. 187 In order to be able to successfully translate a packet from IPv4 to 188 IPv6 or vice versa, the translator must implement an address mapping 189 algorithm. This document does not specify any such algorithms, 190 instead these are referenced from Section 6. 192 1.4. Path MTU Discovery and Fragmentation 194 Due to the different sizes of the IPv4 and IPv6 header, which are 20+ 195 octets and 40 octets respectively, handling the maximum packet size 196 is critical for the operation of the IPv4/IPv6 translator. There are 197 three mechanisms to handle this issue: path MTU discovery (PMTUD), 198 fragmentation, and transport-layer negotiation such as the TCP 199 Maximum Segment Size (MSS) option [RFC0879]. Note that the 200 translator MUST behave as a router, i.e., the translator MUST send a 201 Packet Too Big error message or fragment the packet when the packet 202 size exceeds the MTU of the next-hop interface. 204 Don't Fragment, ICMP Packet Too Big, and packet fragmentation are 205 discussed in Sections 4 and 5 of this document. The reassembling of 206 fragmented packets in the stateful translator is discussed in 207 [RFC6146], since it requires state maintenance in the translator. 209 2. Changes from RFC 6145 211 The changes from RFC 6145 are the following: 213 1. Insert the notes for the IPv6 extension header handling 214 [Erratum]. 216 2. Deprecate the algorithm which generates the IPv6 atomic 217 fragments, as a result of the analysis in 218 [I-D.ietf-6man-deprecate-atomfrag-generation] and specification 219 in [I-D.ietf-6man-rfc2460bis]. 221 3. Insert the notes for stateless source address mapping for ICMPv6 222 packets [RFC6791]. 224 4. Support new address mapping algorithms and move the discussion of 225 these algorithms to Section 6. 227 3. Conventions 229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 231 document are to be interpreted as described in [RFC2119]. 233 4. Translating from IPv4 to IPv6 235 When an IP/ICMP translator receives an IPv4 datagram addressed to a 236 destination towards the IPv6 domain, it translates the IPv4 header of 237 that packet into an IPv6 header. The original IPv4 header on the 238 packet is removed and replaced by an IPv6 header, and the transport 239 checksum is updated as needed, if that transport is supported by the 240 translator. The data portion of the packet is left unchanged. The 241 IP/ICMP translator then forwards the packet based on the IPv6 242 destination address. 244 +-------------+ +-------------+ 245 | IPv4 | | IPv6 | 246 | Header | | Header | 247 +-------------+ +-------------+ 248 | Transport- | | Fragment | 249 | Layer | ===> | Header | 250 | Header | | (if needed) | 251 +-------------+ +-------------+ 252 | | | Transport- | 253 ~ Data ~ | Layer | 254 | | | Header | 255 +-------------+ +-------------+ 256 | | 257 ~ Data ~ 258 | | 259 +-------------+ 261 Figure 2: IPv4-to-IPv6 Translation 263 Path MTU discovery is mandatory in IPv6, but it is optional in IPv4. 264 IPv6 routers never fragment a packet -- only the sender can do 265 fragmentation. 267 When an IPv4 node performs path MTU discovery (by setting the Don't 268 Fragment (DF) bit in the header), path MTU discovery can operate end- 269 to-end, i.e., across the translator. In this case, either IPv4 or 270 IPv6 routers (including the translator) might send back ICMP Packet 271 Too Big messages to the sender. When the IPv6 routers send these 272 ICMPv6 errors, they will pass through a translator that will 273 translate the ICMPv6 error to a form that the IPv4 sender can 274 understand. As a result, an IPv6 Fragment Header is only included if 275 the IPv4 packet is already fragmented. 277 However, when the IPv4 sender does not set the DF bit, the translator 278 MUST ensure that the packet does not exceed the path MTU on the IPv6 279 side. This is done by fragmenting the IPv4 packet (with Fragment 280 Headers) so that it fits in 1280-byte IPv6 packets, since that is the 281 minimum IPv6 MTU. The IPv6 Fragment Header has been shown to cause 282 operational difficulties in practice due to limited firewall 283 fragmentation support, etc. In an environment where the network 284 owned/operated by the same entity that owns/operates the translator, 285 the translator MUST provide a configuration function for the network 286 administrator to adjust the threshold of the minimum IPv6 MTU to a 287 value that reflects the real value of the minimum IPv6 MTU in the 288 network (greater than 1280 bytes). This will help reduce the chance 289 of including the Fragment Header in the packets. 291 When the IPv4 sender does not set the DF bit, the translator MUST NOT 292 include the Fragment Header for the non-fragmented IPv6 packets. 294 The rules in Section 4.1 ensure that when packets are fragmented, 295 either by the sender or by IPv4 routers, the low-order 16 bits of the 296 fragment identification are carried end-to-end, ensuring that packets 297 are correctly reassembled. 299 Other than the special rules for handling fragments and path MTU 300 discovery, the actual translation of the packet header consists of a 301 simple translation as defined below. Note that ICMPv4 packets 302 require special handling in order to translate the content of ICMPv4 303 error messages and also to add the ICMPv6 pseudo-header checksum. 305 The translator SHOULD make sure that the packets belonging to the 306 same flow leave the translator in the same order in which they 307 arrived. 309 4.1. Translating IPv4 Headers into IPv6 Headers 311 If the DF flag is not set and the IPv4 packet will result in an IPv6 312 packet larger than a user-defined length (hereinafter referred to as 313 "lowest-ipv6-mtu", and which defaults to 1280 bytes), the packet 314 SHOULD be fragmented so the resulting IPv6 packet (with Fragment 315 Header added to each fragment) will be less than or equal to lowest- 316 ipv6-mtu, For example, if the packet is fragmented prior to the 317 translation, the IPv4 packets should be fragmented so that their 318 length, excluding the IPv4 header, is at most 1232 bytes (1280 minus 319 40 for the IPv6 header and 8 for the Fragment Header). The 320 translator MUST provide a configuration function for the network 321 administrator to adjust the threshold of the minimum IPv6 MTU to a 322 value greater than 1280-byte if the real value of the minimum IPv6 323 MTU in the network is known to the administrator. The resulting 324 fragments are then translated independently using the logic described 325 below. 327 If the DF bit is set and the MTU of the next-hop interface is less 328 than the total length value of the IPv4 packet plus 20, the 329 translator MUST send an ICMPv4 "Fragmentation Needed" error message 330 to the IPv4 source address. 332 The IPv6 header fields are set as follows: 334 Version: 6 336 Traffic Class: By default, copied from the IP Type Of Service (TOS) 337 octet. According to [RFC2474], the semantics of the bits are 338 identical in IPv4 and IPv6. However, in some IPv4 environments 339 these fields might be used with the old semantics of "Type Of 340 Service and Precedence". An implementation of a translator SHOULD 341 support an administratively configurable option to ignore the IPv4 342 TOS and always set the IPv6 traffic class (TC) to zero. In 343 addition, if the translator is at an administrative boundary, the 344 filtering and update considerations of [RFC2475] may be 345 applicable. 347 Flow Label: 0 (all zero bits) 349 Payload Length: Total length value from the IPv4 header, minus the 350 size of the IPv4 header and IPv4 options, if present. 352 Next Header: For ICMPv4 (1), it is changed to ICMPv6 (58); 353 otherwise, the protocol field MUST be copied from the IPv4 header. 355 Hop Limit: The hop limit is derived from the TTL value in the IPv4 356 header. Since the translator is a router, as part of forwarding 357 the packet it needs to decrement either the IPv4 TTL (before the 358 translation) or the IPv6 Hop Limit (after the translation). As 359 part of decrementing the TTL or Hop Limit, the translator (as any 360 router) MUST check for zero and send the ICMPv4 "TTL Exceeded" or 361 ICMPv6 "Hop Limit Exceeded" error. 363 Source Address: Mapped to an IPv6 address based on the algorithms 364 presented in Section 6. 366 If the translator gets an illegal source address (e.g., 0.0.0.0, 367 127.0.0.1, etc.), the translator SHOULD silently discard the 368 packet (as discussed in Section 5.3.7 of [RFC1812]). Note when 369 translating ICMPv4 Error Messages into ICMPv6, the "illegal" 370 source address will be translated for the purpose of trouble 371 shooting. 373 Destination Address: Mapped to an IPv6 address based on the 374 algorithms presented in Section 6. 376 If any IPv4 options are present in the IPv4 packet, they MUST be 377 ignored and the packet translated normally; there is no attempt to 378 translate the options. However, if an unexpired source route option 379 is present then the packet MUST instead be discarded, and an ICMPv4 380 "Destination Unreachable, Source Route Failed" (Type 3, Code 5) error 381 message SHOULD be returned to the sender. 383 If there is a need to add a Fragment Header (the packet is a fragment 384 or the DF bit is not set and the packet size is greater than the 385 minimum IPv6 MTU in the network set by the translator configuration 386 function), the header fields are set as above with the following 387 exceptions: 389 IPv6 fields: 391 Payload Length: Total length value from the IPv4 header, plus 8 392 for the Fragment Header, minus the size of the IPv4 header and 393 IPv4 options, if present. 395 Next Header: Fragment Header (44). 397 Fragment Header fields: 399 Next Header: For ICMPv4 (1), it is changed to ICMPv6 (58); 400 otherwise, the protocol field MUST be copied from the IPv4 401 header. 403 Fragment Offset: Fragment Offset copied from the IPv4 header. 405 M flag: More Fragments bit copied from the IPv4 header. 407 Identification: The low-order 16 bits copied from the 408 Identification field in the IPv4 header. The high-order 16 409 bits set to zero. 411 4.2. Translating ICMPv4 Headers into ICMPv6 Headers 413 All ICMPv4 messages that are to be translated require that the ICMPv6 414 checksum field be calculated as part of the translation since ICMPv6, 415 unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP. 417 In addition, all ICMPv4 packets MUST have the Type translated and, 418 for ICMPv4 error messages, the included IP header also MUST be 419 translated. 421 The actions needed to translate various ICMPv4 messages are as 422 follows: 424 ICMPv4 query messages: 426 Echo and Echo Reply (Type 8 and Type 0): Adjust the Type values 427 to 128 and 129, respectively, and adjust the ICMP checksum both 428 to take the type change into account and to include the ICMPv6 429 pseudo-header. 431 Information Request/Reply (Type 15 and Type 16): Obsoleted in 432 ICMPv6. Silently drop. 434 Timestamp and Timestamp Reply (Type 13 and Type 14): Obsoleted in 435 ICMPv6. Silently drop. 437 Address Mask Request/Reply (Type 17 and Type 18): Obsoleted in 438 ICMPv6. Silently drop. 440 ICMP Router Advertisement (Type 9): Single-hop message. Silently 441 drop. 443 ICMP Router Solicitation (Type 10): Single-hop message. Silently 444 drop. 446 Unknown ICMPv4 types: Silently drop. 448 IGMP messages: While the Multicast Listener Discovery (MLD) 449 messages [RFC2710] [RFC3590] [RFC3810] are the logical IPv6 450 counterparts for the IPv4 IGMP messages, all the "normal" IGMP 451 messages are single-hop messages and SHOULD be silently dropped 452 by the translator. Other IGMP messages might be used by 453 multicast routing protocols and, since it would be a 454 configuration error to try to have router adjacencies across 455 IP/ICMP translators, those packets SHOULD also be silently 456 dropped. 458 ICMPv4 error messages: 460 Destination Unreachable (Type 3): Translate the Code as 461 described below, set the Type to 1, and adjust the ICMP 462 checksum both to take the type/code change into account and 463 to include the ICMPv6 pseudo-header. 465 Translate the Code as follows: 467 Code 0, 1 (Net Unreachable, Host Unreachable): Set the Code 468 to 0 (No route to destination). 470 Code 2 (Protocol Unreachable): Translate to an ICMPv6 471 Parameter Problem (Type 4, Code 1) and make the Pointer 472 point to the IPv6 Next Header field. 474 Code 3 (Port Unreachable): Set the Code to 4 (Port 475 unreachable). 477 Code 4 (Fragmentation Needed and DF was Set): Translate to 478 an ICMPv6 Packet Too Big message (Type 2) with Code set 479 to 0. The MTU field MUST be adjusted for the difference 480 between the IPv4 and IPv6 header sizes, but MUST NOT be 481 set to a value smaller than the minimum IPv6 MTU (1280 482 bytes). That is, it should be set to maximum(1280, 483 minimum((MTU value in the Packet Too Big Message)+20, 484 MTU_of_IPv6_nexthop, (MTU_of_IPv4_nexthop)+20)). Note 485 that if the IPv4 router set the MTU field to zero, i.e., 486 the router does not implement [RFC1191], then the 487 translator MUST use the plateau values specified in 488 [RFC1191] to determine a likely path MTU and include that 489 path MTU in the ICMPv6 packet. (Use the greatest plateau 490 value that is less than the returned Total Length field, 491 but that is larger than or equal to 1280.) 493 See also the requirements in Section 7. 495 Code 5 (Source Route Failed): Set the Code to 0 (No route 496 to destination). Note that this error is unlikely since 497 source routes are not translated. 499 Code 6, 7, 8: Set the Code to 0 (No route to destination). 501 Code 9, 10 (Communication with Destination Host 502 Administratively Prohibited): Set the Code to 1 503 (Communication with destination administratively 504 prohibited). 506 Code 11, 12: Set the Code to 0 (No route to destination). 508 Code 13 (Communication Administratively Prohibited): Set 509 the Code to 1 (Communication with destination 510 administratively prohibited). 512 Code 14 (Host Precedence Violation): Silently drop. 514 Code 15 (Precedence cutoff in effect): Set the Code to 1 515 (Communication with destination administratively 516 prohibited). 518 Other Code values: Silently drop. 520 Redirect (Type 5): Single-hop message. Silently drop. 522 Alternative Host Address (Type 6): Silently drop. 524 Source Quench (Type 4): Obsoleted in ICMPv6. Silently drop. 526 Time Exceeded (Type 11): Set the Type to 3, and adjust the 527 ICMP checksum both to take the type change into account and 528 to include the ICMPv6 pseudo-header. The Code is unchanged. 530 Parameter Problem (Type 12): Set the Type to 4, and adjust the 531 ICMP checksum both to take the type/code change into account 532 and to include the ICMPv6 pseudo-header. 534 Translate the Code as follows: 536 Code 0 (Pointer indicates the error): Set the Code to 0 537 (Erroneous header field encountered) and update the 538 pointer as defined in Figure 3. (If the Original IPv4 539 Pointer Value is not listed or the Translated IPv6 540 Pointer Value is listed as "n/a", silently drop the 541 packet.) 543 Code 1 (Missing a required option): Silently drop. 545 Code 2 (Bad length): Set the Code to 0 (Erroneous header 546 field encountered) and update the pointer as defined in 547 Figure 3. (If the Original IPv4 Pointer Value is not 548 listed or the Translated IPv6 Pointer Value is listed as 549 "n/a", silently drop the packet.) 551 Other Code values: Silently drop. 553 Unknown ICMPv4 types: Silently drop. 555 +--------------------------------+--------------------------------+ 556 | Original IPv4 Pointer Value | Translated IPv6 Pointer Value | 557 +--------------------------------+--------------------------------+ 558 | 0 | Version/IHL | 0 | Version/Traffic Class | 559 | 1 | Type Of Service | 1 | Traffic Class/Flow Label | 560 | 2,3 | Total Length | 4 | Payload Length | 561 | 4,5 | Identification | n/a | | 562 | 6 | Flags/Fragment Offset | n/a | | 563 | 7 | Fragment Offset | n/a | | 564 | 8 | Time to Live | 7 | Hop Limit | 565 | 9 | Protocol | 6 | Next Header | 566 |10,11| Header Checksum | n/a | | 567 |12-15| Source Address | 8 | Source Address | 568 |16-19| Destination Address | 24 | Destination Address | 569 +--------------------------------+--------------------------------+ 571 Figure 3: Pointer Value for Translating from IPv4 to IPv6 573 ICMP Error Payload: If the received ICMPv4 packet contains an 574 ICMPv4 Extension [RFC4884], the translation of the ICMPv4 575 packet will cause the ICMPv6 packet to change length. When 576 this occurs, the ICMPv6 Extension length attribute MUST be 577 adjusted accordingly (e.g., longer due to the translation 578 from IPv4 to IPv6). If the ICMPv4 Extension exceeds the 579 maximum size of an ICMPv6 message on the outgoing interface, 580 the ICMPv4 extension SHOULD be simply truncated. For 581 extensions not defined in [RFC4884], the translator passes 582 the extensions as opaque bit strings, and those containing 583 IPv4 address literals will not have their included addresses 584 translated to IPv6 address literals; this may cause problems 585 with processing of those ICMP extensions. 587 4.3. Translating ICMPv4 Error Messages into ICMPv6 589 There are some differences between the ICMPv4 and the ICMPv6 error 590 message formats as detailed above. The ICMP error messages 591 containing the packet in error MUST be translated just like a normal 592 IP packet (except the TTL value of the inner IPv4/IPv6 packet). If 593 the translation of this "packet in error" changes the length of the 594 datagram, the Total Length field in the outer IPv6 header MUST be 595 updated. 597 +-------------+ +-------------+ 598 | IPv4 | | IPv6 | 599 | Header | | Header | 600 +-------------+ +-------------+ 601 | ICMPv4 | | ICMPv6 | 602 | Header | | Header | 603 +-------------+ +-------------+ 604 | IPv4 | ===> | IPv6 | 605 | Header | | Header | 606 +-------------+ +-------------+ 607 | Partial | | Partial | 608 | Transport- | | Transport- | 609 | Layer | | Layer | 610 | Header | | Header | 611 +-------------+ +-------------+ 613 Figure 4: IPv4-to-IPv6 ICMP Error Translation 615 The translation of the inner IP header can be done by invoking the 616 function that translated the outer IP headers. This process MUST 617 stop at the first embedded header and drop the packet if it contains 618 more embedded headers. 620 4.4. Generation of ICMPv4 Error Message 622 If the IPv4 packet is discarded, then the translator SHOULD be able 623 to send back an ICMPv4 error message to the original sender of the 624 packet, unless the discarded packet is itself an ICMPv4 error 625 message. The ICMPv4 message, if sent, has a Type of 3 (Destination 626 Unreachable) and a Code of 13 (Communication Administratively 627 Prohibited), unless otherwise specified in this document or in 628 [RFC6146]. The translator SHOULD allow an administrator to configure 629 whether the ICMPv4 error messages are sent, rate-limited, or not 630 sent. 632 4.5. Transport-Layer Header Translation 634 If the address translation algorithm is not checksum neutral (see 635 Section 4.1 of [RFC6052]), the recalculation and updating of the 636 transport-layer headers that contain pseudo-headers need to be 637 performed. Translators MUST do this for TCP and ICMP packets and for 638 UDP packets that contain a UDP checksum (i.e., the UDP checksum field 639 is not zero). 641 For UDP packets that do not contain a UDP checksum (i.e., the UDP 642 checksum field is zero), the translator SHOULD provide a 643 configuration function to allow: 645 1. Dropping the packet and generating a system management event that 646 specifies at least the IP addresses and port numbers of the 647 packet. 649 2. Calculating an IPv6 checksum and forwarding the packet (which has 650 performance implications). 652 A stateless translator cannot compute the UDP checksum of 653 fragmented packets, so when a stateless translator receives the 654 first fragment of a fragmented UDP IPv4 packet and the checksum 655 field is zero, the translator SHOULD drop the packet and generate 656 a system management event that specifies at least the IP 657 addresses and port numbers in the packet. 659 For a stateful translator, the handling of fragmented UDP IPv4 660 packets with a zero checksum is discussed in [RFC6146], Section 661 3.4. 663 Other transport protocols (e.g., DCCP) are OPTIONAL to support. In 664 order to ease debugging and troubleshooting, translators MUST forward 665 all transport protocols as described in the "Next Header" step of 666 Section 4.1. 668 4.6. Knowing When to Translate 670 If the IP/ICMP translator also provides a normal forwarding function, 671 and the destination IPv4 address is reachable by a more specific 672 route without translation, the translator MUST forward it without 673 translating it. Otherwise, when an IP/ICMP translator receives an 674 IPv4 datagram addressed to an IPv4 destination representing a host in 675 the IPv6 domain, the packet MUST be translated to IPv6. 677 5. Translating from IPv6 to IPv4 679 When an IP/ICMP translator receives an IPv6 datagram addressed to a 680 destination towards the IPv4 domain, it translates the IPv6 header of 681 the received IPv6 packet into an IPv4 header. The original IPv6 682 header on the packet is removed and replaced by an IPv4 header. 683 Since the ICMPv6 [RFC4443], TCP [RFC0793], UDP [RFC0768], and DCCP 684 [RFC4340] headers contain checksums that cover the IP header, if the 685 address mapping algorithm is not checksum neutral, the checksum MUST 686 be evaluated before translation and the ICMP and transport-layer 687 headers MUST be updated. The data portion of the packet is left 688 unchanged. The IP/ICMP translator then forwards the packet based on 689 the IPv4 destination address. 691 +-------------+ +-------------+ 692 | IPv6 | | IPv4 | 693 | Header | | Header | 694 +-------------+ +-------------+ 695 | Fragment | | Transport | 696 | Header | ===> | Layer | 697 |(if present) | | Header | 698 +-------------+ +-------------+ 699 | Transport | | | 700 | Layer | ~ Data ~ 701 | Header | | | 702 +-------------+ +-------------+ 703 | | 704 ~ Data ~ 705 | | 706 +-------------+ 708 Figure 5: IPv6-to-IPv4 Translation 710 There are some differences between IPv6 and IPv4 (in the areas of 711 fragmentation and the minimum link MTU) that affect the translation. 712 An IPv6 link has to have an MTU of 1280 bytes or greater. The 713 corresponding limit for IPv4 is 68 bytes. Path MTU discovery across 714 a translator relies on ICMP Packet Too Big messages being received 715 and processed by IPv6 hosts. 717 The difference in the minimum MTUs of IPv4 and IPv6 is accommodated 718 as follows: 720 o When translating an ICMPv4 "Fragmentation Needed" packet, the 721 indicated MTU in the resulting ICMPv6 "Packet Too Big" will never 722 be set to a value lower than 1280. This ensures that the IPv6 723 nodes will never have to encounter or handle Path MTU values lower 724 than the minimum IPv6 link MTU of 1280. See Section 4.2. 726 o When the resulting IPv4 packet is smaller than or equal to 1260 727 bytes, the translator MUST send the packet with a cleared Don't 728 Fragment bit. Otherwise, the packet MUST be sent with the Don't 729 Fragment bit set. See Section 5.1. 731 This approach allows Path MTU Discovery to operate end-to-end for 732 paths whose MTU are not smaller than minimum IPv6 MTU of 1280 (which 733 corresponds to MTU of 1260 in the IPv4 domain). On paths that have 734 IPv4 links with MTU < 1260, the IPv4 router(s) connected to those 735 links will fragment the packets in accordance with Section 2.3 of 736 [RFC0791]. 738 Other than the special rules for handling fragments and path MTU 739 discovery, the actual translation of the packet header consists of a 740 simple translation as defined below. Note that ICMPv6 packets 741 require special handling in order to translate the contents of ICMPv6 742 error messages and also to remove the ICMPv6 pseudo-header checksum. 744 The translator SHOULD make sure that the packets belonging to the 745 same flow leave the translator in the same order in which they 746 arrived. 748 5.1. Translating IPv6 Headers into IPv4 Headers 750 If there is no IPv6 Fragment Header, the IPv4 header fields are set 751 as follows: 753 Version: 4 755 Internet Header Length: 5 (no IPv4 options) 757 Type of Service (TOS) Octet: By default, copied from the IPv6 758 Traffic Class (all 8 bits). According to [RFC2474], the semantics 759 of the bits are identical in IPv4 and IPv6. However, in some IPv4 760 environments, these bits might be used with the old semantics of 761 "Type Of Service and Precedence". An implementation of a 762 translator SHOULD provide the ability to ignore the IPv6 traffic 763 class and always set the IPv4 TOS Octet to a specified value. In 764 addition, if the translator is at an administrative boundary, the 765 filtering and update considerations of [RFC2475] may be 766 applicable. 768 Total Length: Payload length value from the IPv6 header, plus the 769 size of the IPv4 header. 771 Identification: Set according to a Fragment Identification generator 772 at the translator. 774 Flags: The More Fragments flag is set to zero. The Don't Fragment 775 (DF) flag is set as follows: If the size of the translated IPv4 776 packet is less than or equal to 1260 bytes, it is set to zero; 777 otherwise, it is set to one. 779 Fragment Offset: All zeros. 781 Time to Live: Time to Live is derived from Hop Limit value in IPv6 782 header. Since the translator is a router, as part of forwarding 783 the packet it needs to decrement either the IPv6 Hop Limit (before 784 the translation) or the IPv4 TTL (after the translation). As part 785 of decrementing the TTL or Hop Limit the translator (as any 786 router) MUST check for zero and send the ICMPv4 "TTL Exceeded" or 787 ICMPv6 "Hop Limit Exceeded" error. 789 Protocol: The IPv6-Frag (44) header is handled as discussed in 790 Section 5.1.1. ICMPv6 (58) is changed to ICMPv4 (1), and the 791 payload is translated as discussed in Section 5.2. The IPv6 792 headers HOPOPT (0), IPv6-Route (43), and IPv6-Opts (60) are 793 skipped over during processing as they have no meaning in IPv4. 794 For the first 'next header' that does not match one of the cases 795 above, its Next Header value (which contains the transport 796 protocol number) is copied to the protocol field in the IPv4 797 header. This means that all transport protocols are translated. 799 Note: Some translated protocols will fail at the receiver for 800 various reasons: some are known to fail when translated (e.g., 801 IPsec Authentication Header (51)), and others will fail 802 checksum validation if the address translation is not checksum 803 neutral [RFC6052] and the translator does not update the 804 transport protocol's checksum (because the translator doesn't 805 support recalculating the checksum for that transport protocol; 806 see Section 5.5). 808 Header Checksum: Computed once the IPv4 header has been created. 810 Source Address: Mapped to an IPv4 address based on the algorithms 811 presented in Section 6. 813 If the translator gets an illegal source address (e.g., ::1, 814 etc.), the translator SHOULD silently drop the packet. 816 Destination Address: Mapped to an IPv4 address based on the 817 algorithms presented in Section 6. 819 If any of an IPv6 Hop-by-Hop Options header, Destination Options 820 header, or Routing header with the Segments Left field equal to zero 821 are present in the IPv6 packet, those IPv6 extension headers MUST be 822 ignored (i.e., there is no attempt to translate the extension 823 headers) and the packet translated normally. However, the Total 824 Length field and the Protocol field are adjusted to "skip" these 825 extension headers. 827 If a Routing header with a non-zero Segments Left field is present, 828 then the packet MUST NOT be translated, and an ICMPv6 "parameter 829 problem/erroneous header field encountered" (Type 4, Code 0) error 830 message, with the Pointer field indicating the first byte of the 831 Segments Left field, SHOULD be returned to the sender. 833 5.1.1. IPv6 Fragment Processing 835 If the IPv6 packet contains a Fragment Header, the header fields are 836 set as above with the following exceptions: 838 Total Length: If the Next Header field of the Fragment Header is an 839 extension header (except ESP, but including AH) then the packet 840 SHOULD be dropped and logged. For other cases, the Total Length 841 MUST be set to Payload Length value from IPv6 header, minus length 842 of extension headers up to Fragmentation Header, minus 8 for the 843 Fragment Header, plus the size of the IPv4 header. 845 Identification: Copied from the low-order 16 bits in the 846 Identification field in the Fragment Header. 848 Flags: The IPv4 More Fragments (MF) flag is copied from the M flag 849 in the IPv6 Fragment Header. The IPv4 Don't Fragment (DF) flag is 850 cleared (set to zero), allowing this packet to be further 851 fragmented by IPv4 routers. 853 Fragment Offset: If the Next Header field of the Fragment Header is 854 not an extension header (except ESP) then Fragment Offset MUST be 855 copied from the Fragment Offset field of the IPv6 Fragment Header. 856 If the Next Header field of the Fragment Header is an extension 857 header (except ESP) then the packet SHOULD be dropped and logged. 859 Protocol: For ICMPv6 (58), it is changed to ICMPv4 (1); otherwise, 860 extension headers are skipped, and the Next Header field is copied 861 from the last IPv6 header. 863 If an IPv6 packet that is smaller than or equal to 1280 bytes results 864 (after translation) in an IPv4 packet that is larger than the MTU of 865 the next-hop interface, then the translator MUST perform IPv4 866 fragmentation on that packet such that it can be transferred over the 867 constricting link. 869 5.2. Translating ICMPv6 Headers into ICMPv4 Headers 871 If a non-checksum-neutral translation address is being used, ICMPv6 872 messages MUST have their ICMPv4 checksum field be updated as part of 873 the translation since ICMPv6 (unlike ICMPv4) includes a pseudo-header 874 in the checksum just like UDP and TCP. 876 In addition, all ICMP packets MUST have the Type translated and, for 877 ICMP error messages, the included IP header also MUST be translated. 879 The actions needed to translate various ICMPv6 messages are: 881 ICMPv6 informational messages: 883 Echo Request and Echo Reply (Type 128 and 129): Adjust the Type 884 values to 8 and 0, respectively, and adjust the ICMP checksum 885 both to take the type change into account and to exclude the 886 ICMPv6 pseudo-header. 888 MLD Multicast Listener Query/Report/Done (Type 130, 131, 132): 889 Single-hop message. Silently drop. 891 Neighbor Discover messages (Type 133 through 137): Single-hop 892 message. Silently drop. 894 Unknown informational messages: Silently drop. 896 ICMPv6 error messages: 898 Destination Unreachable (Type 1) Set the Type to 3, and adjust 899 the ICMP checksum both to take the type/code change into 900 account and to exclude the ICMPv6 pseudo-header. 902 Translate the Code as follows: 904 Code 0 (No route to destination): Set the Code to 1 (Host 905 unreachable). 907 Code 1 (Communication with destination administratively 908 prohibited): Set the Code to 10 (Communication with 909 destination host administratively prohibited). 911 Code 2 (Beyond scope of source address): Set the Code to 1 912 (Host unreachable). Note that this error is very unlikely 913 since an IPv4-translatable source address is typically 914 considered to have global scope. 916 Code 3 (Address unreachable): Set the Code to 1 (Host 917 unreachable). 919 Code 4 (Port unreachable): Set the Code to 3 (Port 920 unreachable). 922 Other Code values: Silently drop. 924 Packet Too Big (Type 2): Translate to an ICMPv4 Destination 925 Unreachable (Type 3) with Code 4, and adjust the ICMPv4 926 checksum both to take the type change into account and to 927 exclude the ICMPv6 pseudo-header. The MTU field MUST be 928 adjusted for the difference between the IPv4 and IPv6 header 929 sizes, taking into account whether or not the packet in error 930 includes a Fragment Header, i.e., minimum((MTU value in the 931 Packet Too Big Message)-20, MTU_of_IPv4_nexthop, 932 (MTU_of_IPv6_nexthop)-20). 934 See also the requirements in Section 7. 936 Time Exceeded (Type 3): Set the Type to 11, and adjust the ICMPv4 937 checksum both to take the type change into account and to 938 exclude the ICMPv6 pseudo-header. The Code is unchanged. 940 Parameter Problem (Type 4): Translate the Type and Code as 941 follows, and adjust the ICMPv4 checksum both to take the type/ 942 code change into account and to exclude the ICMPv6 pseudo- 943 header. 945 Translate the Code as follows: 947 Code 0 (Erroneous header field encountered): Set to Type 12, 948 Code 0, and update the pointer as defined in Figure 6. (If 949 the Original IPv6 Pointer Value is not listed or the 950 Translated IPv4 Pointer Value is listed as "n/a", silently 951 drop the packet.) 953 Code 1 (Unrecognized Next Header type encountered): Translate 954 this to an ICMPv4 protocol unreachable (Type 3, Code 2). 956 Code 2 (Unrecognized IPv6 option encountered): Silently drop. 958 Unknown error messages: Silently drop. 960 +--------------------------------+--------------------------------+ 961 | Original IPv6 Pointer Value | Translated IPv4 Pointer Value | 962 +--------------------------------+--------------------------------+ 963 | 0 | Version/Traffic Class | 0 | Version/IHL, Type Of Ser | 964 | 1 | Traffic Class/Flow Label | 1 | Type Of Service | 965 | 2,3 | Flow Label | n/a | | 966 | 4,5 | Payload Length | 2 | Total Length | 967 | 6 | Next Header | 9 | Protocol | 968 | 7 | Hop Limit | 8 | Time to Live | 969 | 8-23| Source Address | 12 | Source Address | 970 |24-39| Destination Address | 16 | Destination Address | 971 +--------------------------------+--------------------------------+ 973 Figure 6: Pointer Value for Translating from IPv6 to IPv4 975 ICMP Error Payload: If the received ICMPv6 packet contains an 976 ICMPv6 Extension [RFC4884], the translation of the ICMPv6 977 packet will cause the ICMPv4 packet to change length. When 978 this occurs, the ICMPv6 Extension length attribute MUST be 979 adjusted accordingly (e.g., shorter due to the translation from 980 IPv6 to IPv4). For extensions not defined in [RFC4884], the 981 translator passes the extensions as opaque bit strings and any 982 IPv6 address literals contained therein will not be translated 983 to IPv4 address literals; this may cause problems with 984 processing of those ICMP extensions. 986 5.3. Translating ICMPv6 Error Messages into ICMPv4 988 There are some differences between the ICMPv4 and the ICMPv6 error 989 message formats as detailed above. The ICMP error messages 990 containing the packet in error MUST be translated just like a normal 991 IP packet (except that the TTL/Hop Limit value of the inner IPv4/IPv6 992 packet are not decremented). The translation of this "packet in 993 error" is likely to change the length of the datagram; thus, the 994 Total Length field in the outer IPv4 header MUST be updated. 996 +-------------+ +-------------+ 997 | IPv6 | | IPv4 | 998 | Header | | Header | 999 +-------------+ +-------------+ 1000 | ICMPv6 | | ICMPv4 | 1001 | Header | | Header | 1002 +-------------+ +-------------+ 1003 | IPv6 | ===> | IPv4 | 1004 | Header | | Header | 1005 +-------------+ +-------------+ 1006 | Partial | | Partial | 1007 | Transport- | | Transport- | 1008 | Layer | | Layer | 1009 | Header | | Header | 1010 +-------------+ +-------------+ 1012 Figure 7: IPv6-to-IPv4 ICMP Error Translation 1014 The translation of the inner IP header can be done by invoking the 1015 function that translated the outer IP headers. This process MUST 1016 stop at the first embedded header and drop the packet if it contains 1017 more embedded headers. 1019 5.4. Generation of ICMPv6 Error Messages 1021 If the IPv6 packet is discarded, then the translator SHOULD send back 1022 an ICMPv6 error message to the original sender of the packet, unless 1023 the discarded packet is itself an ICMPv6 message. 1025 The ICMPv6 message MUST have Type 1 (Destination Unreachable) and 1026 Code 1 (Communication with destination administratively prohibited), 1027 unless otherwise specified in this document or [RFC6146]. The 1028 translator SHOULD allow an administrator to configure whether the 1029 ICMPv6 error messages are sent, rate-limited, or not sent. 1031 5.5. Transport-Layer Header Translation 1033 If the address translation algorithm is not checksum neutral (see 1034 Section 4.1 of [RFC6052]), the recalculation and updating of the 1035 transport-layer headers that contain pseudo-headers need to be 1036 performed. Translators MUST do this for TCP, UDP, and ICMP. 1038 Other transport protocols (e.g., DCCP) are OPTIONAL to support. In 1039 order to ease debugging and troubleshooting, translators MUST forward 1040 all transport protocols as described in the "Protocol" step of 1041 Section 5.1. 1043 5.6. Knowing When to Translate 1045 If the IP/ICMP translator also provides a normal forwarding function, 1046 and the destination address is reachable by a more specific route 1047 without translation, the router MUST forward it without translating 1048 it. When an IP/ICMP translator receives an IPv6 datagram addressed 1049 to an IPv6 address representing a host in the IPv4 domain, the IPv6 1050 packet MUST be translated to IPv4. 1052 6. Mapping of IP Addresses 1054 The translator MUST support stateless address mapping algorithm 1055 defined in [RFC6052], which is the default behavior. A workflow 1056 example is shown in Appendix A of this document. Note that [RFC7136] 1057 updates [RFC4291] which allows the use of unicast addresses without 1058 u-bit, as long as they're not derived from an IEEE MAC-layer address. 1059 Therefore the address mapping algorithm defined in [RFC6219] also 1060 complies with the IPv6 address architecture. 1062 The stateless translator SHOULD support explicit address mapping 1063 algorithm defined in [RFC7757]. 1065 The stateless translator SHOULD support [RFC6791] for handling ICMP/ 1066 ICMPv6 packets. 1068 Implementations may support both stateless and stateful translation 1069 modes (e.g., NAT64 [RFC6146]). 1071 Implementations may support stateless NAT64 function, e.g., MAP-T CE 1072 or MAP-T BR [RFC7599]. 1074 7. Special Considerations for ICMPv6 Packet Too Big 1076 A number of studies [I-D.ietf-6man-deprecate-atomfrag-generation] 1077 indicate that it not unusual for networks to drop ICMPv6 Packet Too 1078 Big error messages. Such packet drops will result in PMTUD 1079 blackholes [RFC2923], which can only be overcome with PLPMTUD 1080 [RFC4821]. 1082 8. IANA Considerations 1084 This document makes no requests of the IANA. 1086 9. Security Considerations 1088 The use of stateless IP/ICMP translators does not introduce any new 1089 security issues beyond the security issues that are already present 1090 in the IPv4 and IPv6 protocols and in the routing protocols that are 1091 used to make the packets reach the translator. 1093 There are potential issues that might arise by deriving an IPv4 1094 address from an IPv6 address -- particularly addresses like broadcast 1095 or loopback addresses and the non-IPv4-translatable IPv6 addresses, 1096 etc. [RFC6052] addresses these issues. 1098 As with network address translation of IPv4 to IPv4, the IPsec 1099 Authentication Header [RFC4302] cannot be used across an IPv6-to-IPv4 1100 translator. 1102 As with network address translation of IPv4 to IPv4, packets with 1103 tunnel mode Encapsulating Security Payload (ESP) can be translated 1104 since tunnel mode ESP does not depend on header fields prior to the 1105 ESP header. Similarly, transport mode ESP will fail with IPv6-to- 1106 IPv4 translation unless checksum-neutral addresses are used. In both 1107 cases, the IPsec ESP endpoints will normally detect the presence of 1108 the translator and encapsulate ESP in UDP packets [RFC3948]. 1110 10. Acknowledgements 1112 The authors would like to thank Gandhar Gokhale, Wesley Eddy and 1113 Fernando Gont for the errata report of [RFC6145]. Thanks to Fernando 1114 Gont, Will(Shucheng) Liu and Tore Anderson for the security analysis 1115 and the suggestions of the updates concerning atomic fragments. 1116 Thanks to Tore Anderson and Alberto Leiva for the proposal of the 1117 explicit address mapping (EAM) algorithm. 1119 11. References 1121 11.1. Normative References 1123 [RFC0768] Postel, J., "User 1124 Datagram Protocol", 1125 STD 6, RFC 768, 1126 DOI 10.17487/RFC0768, 1127 August 1980, . 1131 [RFC0791] Postel, J., "Internet 1132 Protocol", STD 5, 1133 RFC 791, DOI 10.17487/ 1134 RFC0791, 1135 September 1981, . 1139 [RFC0793] Postel, J., 1140 "Transmission Control 1141 Protocol", STD 7, 1142 RFC 793, DOI 10.17487/ 1143 RFC0793, 1144 September 1981, . 1148 [RFC1812] Baker, F., Ed., 1149 "Requirements for IP 1150 Version 4 Routers", 1151 RFC 1812, 1152 DOI 10.17487/RFC1812, 1153 June 1995, . 1157 [RFC2119] Bradner, S., "Key 1158 words for use in RFCs 1159 to Indicate 1160 Requirement Levels", 1161 BCP 14, RFC 2119, 1162 DOI 10.17487/RFC2119, 1163 March 1997, . 1167 [RFC3948] Huttunen, A., Swander, 1168 B., Volpe, V., 1169 DiBurro, L., and M. 1170 Stenberg, "UDP 1171 Encapsulation of IPsec 1172 ESP Packets", 1173 RFC 3948, 1174 DOI 10.17487/RFC3948, 1175 January 2005, . 1179 [RFC4291] Hinden, R. and S. 1180 Deering, "IP Version 6 1181 Addressing 1182 Architecture", 1183 RFC 4291, 1184 DOI 10.17487/RFC4291, 1185 February 2006, . 1189 [RFC4340] Kohler, E., Handley, 1190 M., and S. Floyd, 1191 "Datagram Congestion 1192 Control Protocol 1193 (DCCP)", RFC 4340, 1194 DOI 10.17487/RFC4340, 1195 March 2006, . 1199 [RFC4443] Conta, A., Deering, 1200 S., and M. Gupta, Ed., 1201 "Internet Control 1202 Message Protocol 1203 (ICMPv6) for the 1204 Internet Protocol 1205 Version 6 (IPv6) 1206 Specification", 1207 RFC 4443, 1208 DOI 10.17487/RFC4443, 1209 March 2006, . 1213 [RFC4884] Bonica, R., Gan, D., 1214 Tappan, D., and C. 1216 Pignataro, "Extended 1217 ICMP to Support Multi- 1218 Part Messages", 1219 RFC 4884, 1220 DOI 10.17487/RFC4884, 1221 April 2007, . 1225 [RFC5382] Guha, S., Ed., Biswas, 1226 K., Ford, B., 1227 Sivakumar, S., and P. 1228 Srisuresh, "NAT 1229 Behavioral 1230 Requirements for TCP", 1231 BCP 142, RFC 5382, 1232 DOI 10.17487/RFC5382, 1233 October 2008, . 1237 [RFC5771] Cotton, M., Vegoda, 1238 L., and D. Meyer, 1239 "IANA Guidelines for 1240 IPv4 Multicast Address 1241 Assignments", BCP 51, 1242 RFC 5771, 1243 DOI 10.17487/RFC5771, 1244 March 2010, . 1248 [RFC6052] Bao, C., Huitema, C., 1249 Bagnulo, M., 1250 Boucadair, M., and X. 1251 Li, "IPv6 Addressing 1252 of IPv4/IPv6 1253 Translators", 1254 RFC 6052, 1255 DOI 10.17487/RFC6052, 1256 October 2010, . 1260 [RFC6145] Li, X., Bao, C., and 1261 F. Baker, "IP/ICMP 1262 Translation 1263 Algorithm", RFC 6145, 1264 DOI 10.17487/RFC6145, 1265 April 2011, . 1269 [RFC6146] Bagnulo, M., Matthews, 1270 P., and I. van 1271 Beijnum, "Stateful 1272 NAT64: Network Address 1273 and Protocol 1274 Translation from IPv6 1275 Clients to IPv4 1276 Servers", RFC 6146, 1277 DOI 10.17487/RFC6146, 1278 April 2011, . 1282 [RFC6791] Li, X., Bao, C., Wing, 1283 D., Vaithianathan, R., 1284 and G. Huston, 1285 "Stateless Source 1286 Address Mapping for 1287 ICMPv6 Packets", 1288 RFC 6791, 1289 DOI 10.17487/RFC6791, 1290 November 2012, . 1294 [RFC7757] Anderson, T. and A. 1295 Leiva Popper, 1296 "Explicit Address 1297 Mappings for Stateless 1298 IP/ICMP Translation", 1299 RFC 7757, 1300 DOI 10.17487/RFC7757, 1301 February 2016, . 1305 11.2. Informative References 1307 [Erratum] "Erratum: http:// 1308 www.rfc-editor.org/ 1309 errata_search.php?rfc= 1310 6145". 1312 [I-D.ietf-6man-deprecate-atomfrag-generation] Gont, F., LIU, S., and 1313 T. Anderson, 1314 "Generation of IPv6 1315 Atomic Fragments 1316 Considered Harmful", d 1317 raft-ietf-6man- 1318 deprecate-atomfrag- 1319 generation-06 (work in 1320 progress), April 2016. 1322 [I-D.ietf-6man-rfc2460bis] Deering, S. and R. 1323 Hinden, "Internet 1324 Protocol, Version 6 1325 (IPv6) Specification", 1326 draft-ietf-6man- 1327 rfc2460bis-04 (work in 1328 progress), March 2016. 1330 [RFC0879] Postel, J., "The TCP 1331 Maximum Segment Size 1332 and Related Topics", 1333 RFC 879, DOI 10.17487/ 1334 RFC0879, 1335 November 1983, . 1339 [RFC1191] Mogul, J. and S. 1340 Deering, "Path MTU 1341 discovery", RFC 1191, 1342 DOI 10.17487/RFC1191, 1343 November 1990, . 1347 [RFC2474] Nichols, K., Blake, 1348 S., Baker, F., and D. 1349 Black, "Definition of 1350 the Differentiated 1351 Services Field (DS 1352 Field) in the IPv4 and 1353 IPv6 Headers", 1354 RFC 2474, 1355 DOI 10.17487/RFC2474, 1356 December 1998, . 1360 [RFC2475] Blake, S., Black, D., 1361 Carlson, M., Davies, 1362 E., Wang, Z., and W. 1363 Weiss, "An 1364 Architecture for 1365 Differentiated 1366 Services", RFC 2475, 1367 DOI 10.17487/RFC2475, 1368 December 1998, . 1372 [RFC2710] Deering, S., Fenner, 1373 W., and B. Haberman, 1374 "Multicast Listener 1375 Discovery (MLD) for 1376 IPv6", RFC 2710, 1377 DOI 10.17487/RFC2710, 1378 October 1999, . 1382 [RFC2923] Lahey, K., "TCP 1383 Problems with Path MTU 1384 Discovery", RFC 2923, 1385 DOI 10.17487/RFC2923, 1386 September 2000, . 1390 [RFC3307] Haberman, B., 1391 "Allocation Guidelines 1392 for IPv6 Multicast 1393 Addresses", RFC 3307, 1394 DOI 10.17487/RFC3307, 1395 August 2002, . 1399 [RFC3590] Haberman, B., "Source 1400 Address Selection for 1401 the Multicast Listener 1402 Discovery (MLD) 1403 Protocol", RFC 3590, 1404 DOI 10.17487/RFC3590, 1405 September 2003, . 1409 [RFC3810] Vida, R., Ed. and L. 1410 Costa, Ed., "Multicast 1411 Listener Discovery 1412 Version 2 (MLDv2) for 1413 IPv6", RFC 3810, 1414 DOI 10.17487/RFC3810, 1415 June 2004, . 1419 [RFC3849] Huston, G., Lord, A., 1420 and P. Smith, "IPv6 1421 Address Prefix 1422 Reserved for 1423 Documentation", 1424 RFC 3849, 1425 DOI 10.17487/RFC3849, 1426 July 2004, . 1430 [RFC4302] Kent, S., "IP 1431 Authentication 1432 Header", RFC 4302, 1433 DOI 10.17487/RFC4302, 1434 December 2005, . 1438 [RFC4787] Audet, F., Ed. and C. 1439 Jennings, "Network 1440 Address Translation 1441 (NAT) Behavioral 1442 Requirements for 1443 Unicast UDP", BCP 127, 1444 RFC 4787, 1445 DOI 10.17487/RFC4787, 1446 January 2007, . 1450 [RFC4821] Mathis, M. and J. 1451 Heffner, 1452 "Packetization Layer 1453 Path MTU Discovery", 1454 RFC 4821, 1455 DOI 10.17487/RFC4821, 1456 March 2007, . 1460 [RFC5737] Arkko, J., Cotton, M., 1461 and L. Vegoda, "IPv4 1462 Address Blocks 1463 Reserved for 1464 Documentation", 1465 RFC 5737, 1466 DOI 10.17487/RFC5737, 1467 January 2010, . 1471 [RFC6144] Baker, F., Li, X., 1472 Bao, C., and K. Yin, 1473 "Framework for IPv4/ 1474 IPv6 Translation", 1475 RFC 6144, 1476 DOI 10.17487/RFC6144, 1477 April 2011, . 1481 [RFC6219] Li, X., Bao, C., Chen, 1482 M., Zhang, H., and J. 1483 Wu, "The China 1484 Education and Research 1485 Network (CERNET) IVI 1486 Translation Design and 1487 Deployment for the 1488 IPv4/IPv6 Coexistence 1489 and Transition", 1490 RFC 6219, 1491 DOI 10.17487/RFC6219, 1492 May 2011, . 1496 [RFC7136] Carpenter, B. and S. 1497 Jiang, "Significance 1498 of IPv6 Interface 1499 Identifiers", 1500 RFC 7136, 1501 DOI 10.17487/RFC7136, 1502 February 2014, . 1506 [RFC7599] Li, X., Bao, C., Dec, 1507 W., Ed., Troan, O., 1508 Matsushima, S., and T. 1509 Murakami, "Mapping of 1510 Address and Port using 1511 Translation (MAP-T)", 1512 RFC 7599, 1513 DOI 10.17487/RFC7599, 1514 July 2015, . 1518 Appendix A. Stateless Translation Workflow Example 1520 A stateless translation workflow example is depicted in the following 1521 figure. The documentation address blocks 2001:db8::/32 [RFC3849], 1522 192.0.2.0/24, and 198.51.100.0/24 [RFC5737] are used in this example. 1524 +--------------+ +--------------+ 1525 | IPv4 network | | IPv6 network | 1526 | | +-------+ | | 1527 | +----+ |-----| XLAT |---- | +----+ | 1528 | | H4 |-----| +-------+ |--| H6 | | 1529 | +----+ | | +----+ | 1530 +--------------+ +--------------+ 1532 Figure 8 1534 A translator (XLAT) connects the IPv6 network to the IPv4 network. 1535 This XLAT uses the Network-Specific Prefix (NSP) 2001:db8:100::/40 1536 defined in [RFC6052] to represent IPv4 addresses in the IPv6 address 1537 space (IPv4-converted addresses) and to represent IPv6 addresses 1538 (IPv4-translatable addresses) in the IPv4 address space. In this 1539 example, 192.0.2.0/24 is the IPv4 block of the corresponding IPv4- 1540 translatable addresses. 1542 Based on the address mapping rule, the IPv6 node H6 has an IPv4- 1543 translatable IPv6 address 2001:db8:1c0:2:21:: (address mapping from 1544 192.0.2.33). The IPv4 node H4 has IPv4 address 198.51.100.2. 1546 The IPv6 routing is configured in such a way that the IPv6 packets 1547 addressed to a destination address in 2001:db8:100::/40 are routed to 1548 the IPv6 interface of the XLAT. 1550 The IPv4 routing is configured in such a way that the IPv4 packets 1551 addressed to a destination address in 192.0.2.0/24 are routed to the 1552 IPv4 interface of the XLAT. 1554 A.1. H6 Establishes Communication with H4 1556 The steps by which H6 establishes communication with H4 are: 1558 1. H6 performs the destination address mapping, so the IPv4- 1559 converted address 2001:db8:1c6:3364:2:: is formed from 1560 198.51.100.2 based on the address mapping algorithm [RFC6052]. 1562 2. H6 sends a packet to H4. The packet is sent from a source 1563 address 2001:db8:1c0:2:21:: to a destination address 2001:db8: 1564 1c6:3364:2::. 1566 3. The packet is routed to the IPv6 interface of the XLAT (since 1567 IPv6 routing is configured that way). 1569 4. The XLAT receives the packet and performs the following actions: 1571 * The XLAT translates the IPv6 header into an IPv4 header using 1572 the IP/ICMP Translation Algorithm defined in this document. 1574 * The XLAT includes 192.0.2.33 as the source address in the 1575 packet and 198.51.100.2 as the destination address in the 1576 packet. Note that 192.0.2.33 and 198.51.100.2 are extracted 1577 directly from the source IPv6 address 2001:db8:1c0:2:21:: 1578 (IPv4-translatable address) and destination IPv6 address 2001: 1579 db8:1c6:3364:2:: (IPv4-converted address) of the received IPv6 1580 packet that is being translated. 1582 5. The XLAT sends the translated packet out of its IPv4 interface, 1583 and the packet arrives at H4. 1585 6. H4 node responds by sending a packet with destination address 1586 192.0.2.33 and source address 198.51.100.2. 1588 7. The packet is routed to the IPv4 interface of the XLAT (since 1589 IPv4 routing is configured that way). The XLAT performs the 1590 following operations: 1592 * The XLAT translates the IPv4 header into an IPv6 header using 1593 the IP/ICMP Translation Algorithm defined in this document. 1595 * The XLAT includes 2001:db8:1c0:2:21:: as the destination 1596 address in the packet and 2001:db8:1c6:3364:2:: as the source 1597 address in the packet. Note that 2001:db8:1c0:2:21:: and 1598 2001:db8:1c6:3364:2:: are formed directly from the destination 1599 IPv4 address 192.0.2.33 and the source IPv4 address 1600 198.51.100.2 of the received IPv4 packet that is being 1601 translated. 1603 8. The translated packet is sent out of the IPv6 interface to H6. 1605 The packet exchange between H6 and H4 continues until the session is 1606 finished. 1608 A.2. H4 Establishes Communication with H6 1610 The steps by which H4 establishes communication with H6 are: 1612 1. H4 performs the destination address mapping, so 192.0.2.33 is 1613 formed from the IPv4-translatable address 2001:db8:1c0:2:21:: 1614 based on the address mapping algorithm [RFC6052]. 1616 2. H4 sends a packet to H6. The packet is sent from a source 1617 address 198.51.100.2 to a destination address 192.0.2.33. 1619 3. The packet is routed to the IPv4 interface of the XLAT (since 1620 IPv4 routing is configured that way). 1622 4. The XLAT receives the packet and performs the following actions: 1624 * The XLAT translates the IPv4 header into an IPv6 header using 1625 the IP/ICMP Translation Algorithm defined in this document. 1627 * The XLAT includes 2001:db8:1c6:3364:2:: as the source address 1628 in the packet and 2001:db8:1c0:2:21:: as the destination 1629 address in the packet. Note that 2001:db8:1c6:3364:2:: (IPv4- 1630 converted address) and 2001:db8:1c0:2:21:: (IPv4-translatable 1631 address) are obtained directly from the source IPv4 address 1632 198.51.100.2 and destination IPv4 address 192.0.2.33 of the 1633 received IPv4 packet that is being translated. 1635 5. The XLAT sends the translated packet out its IPv6 interface, and 1636 the packet arrives at H6. 1638 6. H6 node responds by sending a packet with destination address 1639 2001:db8:1c6:3364:2:: and source address 2001:db8:1c0:2:21::. 1641 7. The packet is routed to the IPv6 interface of the XLAT (since 1642 IPv6 routing is configured that way). The XLAT performs the 1643 following operations: 1645 * The XLAT translates the IPv6 header into an IPv4 header using 1646 the IP/ICMP Translation Algorithm defined in this document. 1648 * The XLAT includes 198.51.100.2 as the destination address in 1649 the packet and 192.0.2.33 as the source address in the packet. 1650 Note that 198.51.100.2 and 192.0.2.33 are formed directly from 1651 the destination IPv6 address 2001:db8:1c6:3364:2:: and source 1652 IPv6 address 2001:db8:1c0:2:21:: of the received IPv6 packet 1653 that is being translated. 1655 8. The translated packet is sent out the IPv4 interface to H4. 1657 The packet exchange between H4 and H6 continues until the session is 1658 finished. 1660 Authors' Addresses 1662 Congxiao Bao 1663 CERNET Center/Tsinghua University 1664 Room 225, Main Building, Tsinghua University 1665 Beijing, 100084 1666 China 1668 Phone: +86 10-62785983 1669 EMail: congxiao@cernet.edu.cn 1671 Xing Li 1672 CERNET Center/Tsinghua University 1673 Room 225, Main Building, Tsinghua University 1674 Beijing, 100084 1675 China 1677 Phone: +86 10-62785983 1678 EMail: xing@cernet.edu.cn 1680 Fred Baker 1681 Cisco Systems 1682 Santa Barbara, California 93117 1683 USA 1685 Phone: +1-408-526-4257 1686 EMail: fred@cisco.com 1687 Tore Anderson 1688 Redpill Linpro 1689 Vitaminveien 1A 1690 0485 Oslo 1691 Norway 1693 Phone: +47 959 31 212 1694 EMail: tore@redpill-linpro.com 1695 URI: http://www.redpill-linpro.com 1697 Fernando Gont 1698 Huawei Technologies 1699 Evaristo Carriego 2644 1700 Haedo, Provincia de Buenos Aires 1706 1701 Argentina 1703 Phone: +54 11 4650 8472 1704 EMail: fgont@si6networks.com 1705 URI: http://www.si6networks.com