idnits 2.17.1 draft-ietf-behave-v6v4-xlate-19.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. -- The draft header indicates that this document obsoletes RFC2765, but the abstract doesn't seem to directly say this. It does mention RFC2765 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 17, 2010) is 5124 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) == Outdated reference: A later version (-10) exists of draft-ietf-behave-address-format-07 == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-11 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) == Outdated reference: A later version (-10) exists of draft-ietf-behave-v6v4-framework-08 -- Obsolete informational reference (is this intentional?): RFC 879 (Obsoleted by RFC 7805, RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 behave X. Li 3 Internet-Draft C. Bao 4 Obsoletes: 2765 (if approved) CERNET Center/Tsinghua University 5 Intended status: Standards Track F. Baker 6 Expires: October 19, 2010 Cisco Systems 7 April 17, 2010 9 IP/ICMP Translation Algorithm 10 draft-ietf-behave-v6v4-xlate-19 12 Abstract 14 This document forms a replacement of the Stateless IP/ICMP 15 Translation Algorithm (SIIT) described in RFC 2765. The algorithm 16 translates between IPv4 and IPv6 packet headers (including ICMP 17 headers). 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 19, 2010. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 66 1.1. IPv4-IPv6 Translation Model . . . . . . . . . . . . . . . 3 67 1.2. Applicability and Limitations . . . . . . . . . . . . . . 3 68 1.3. Stateless vs. Stateful Mode . . . . . . . . . . . . . . . 4 69 1.4. Path MTU Discovery and Fragmentation . . . . . . . . . . . 5 70 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Translating from IPv4 to IPv6 . . . . . . . . . . . . . . . . 5 72 3.1. Translating IPv4 Headers into IPv6 Headers . . . . . . . . 7 73 3.2. Translating ICMPv4 Headers into ICMPv6 Headers . . . . . . 9 74 3.3. Translating ICMPv4 Error Messages into ICMPv6 . . . . . . 13 75 3.4. Translator Sending ICMPv4 Error Message . . . . . . . . . 14 76 3.5. Transport-layer Header Translation . . . . . . . . . . . . 14 77 3.6. Knowing When to Translate . . . . . . . . . . . . . . . . 14 78 4. Translating from IPv6 to IPv4 . . . . . . . . . . . . . . . . 15 79 4.1. Translating IPv6 Headers into IPv4 Headers . . . . . . . . 17 80 4.2. Translating ICMPv6 Headers into ICMPv4 Headers . . . . . . 20 81 4.3. Translating ICMPv6 Error Messages into ICMPv4 . . . . . . 22 82 4.4. Translator Sending ICMPv6 Error Message . . . . . . . . . 23 83 4.5. Transport-layer Header Translation . . . . . . . . . . . . 23 84 4.6. Knowing When to Translate . . . . . . . . . . . . . . . . 24 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 88 8. Appendix: Stateless translation workflow example . . . . . . . 25 89 8.1. H6 establishes communication with H4 . . . . . . . . . . . 26 90 8.2. H4 establishes communication with H6 . . . . . . . . . . . 27 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 29 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 96 1. Introduction and Motivation 98 This document is a product of the 2008-2010 effort to define a 99 replacement for NAT-PT [RFC2766]. It is directly derivative from 100 Erik Nordmark's "Stateless IP/ICMP Translation Algorithm (SIIT)" 101 [RFC2765], which provides stateless translation between IPv4 102 [RFC0791] and IPv6 [RFC2460], and between ICMPv4 [RFC0792] and ICMPv6 103 [RFC4443]. 105 Readers of this document are expected to have read and understood the 106 framework described in [I-D.ietf-behave-v6v4-framework]. 107 Implementations of this IPv4/IPv6 translation specification MUST also 108 support the address translation algorithms in 109 [I-D.ietf-behave-address-format]. Implementations MAY also support 110 stateful translation [I-D.ietf-behave-v6v4-xlate-stateful]. 112 1.1. IPv4-IPv6 Translation Model 114 The translation model consists of two or more network domains 115 connected by one or more IP/ICMP translators (XLATs) as shown in 116 Figure 1. 118 --------- --------- 119 // \\ // \\ 120 / +----+ \ 121 | |XLAT| | XLAT: IPv6/IPv4 122 | IPv4 +----+ IPv6 | Translator 123 | Domain | | Domain | 124 | | | | 125 \ | | / 126 \\ // \\ // 127 -------- --------- 129 Figure 1: IPv4-IPv6 Translation Model 131 The scenarios of the translation model are discussed in 132 [I-D.ietf-behave-v6v4-framework]. 134 1.2. Applicability and Limitations 136 This document specifies the translation algorithms between IPv4 137 packets and IPv6 packets. 139 As with [RFC2765], the translating function specified in this 140 document does not translate any IPv4 options and it does not 141 translate IPv6 extension headers except fragmentation header. 143 The issues and algorithms in the translation of datagrams containing 144 TCP segments are described in [RFC5382]. 146 Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e., 147 the UDP checksum field is zero) are not of significant use in the 148 Internet and will not be translated by the IP/ICMP translator. 150 Fragmented ICMP/ICMPv6 packets will not be translated by the IP/ICMP 151 translator. 153 The IP/ICMP header translation specified in this document is 154 consistent with requirements of multicast IP/ICMP headers. However 155 IPv4 multicast addresses [RFC5771] cannot be mapped to IPv6 multicast 156 addresses [RFC3307] based on the unicast mapping rule 157 [I-D.ietf-behave-address-format]. 159 Translator SHOULD make sure that the packets belonging to the same 160 flow leave the translator in the same order in which they arrived. 162 1.3. Stateless vs. Stateful Mode 164 An IP/ICMP translator has two possible modes of operation: stateless 165 and stateful [I-D.ietf-behave-v6v4-framework]. In both cases, we 166 assume that a system (a node or an application) that has an IPv4 167 address but not an IPv6 address is communicating with a system that 168 has an IPv6 address but no IPv4 address, or that the two systems do 169 not have contiguous routing connectivity and hence are forced to have 170 their communications translated. 172 In the stateless mode, a specific IPv6 address range will represent 173 IPv4 systems (IPv4-converted addresses), and the IPv6 systems have 174 addresses (IPv4-translatable addresses) that can be algorithmically 175 mapped to a subset of the service provider's IPv4 addresses. Note 176 that IPv4-translatable addresses is a subset of IPv4-converted 177 addresses. In general, there is no need to concern oneself with 178 translation tables, as the IPv4 and IPv6 counterparts are 179 algorithmically related. 181 In the stateful mode, a specific IPv6 address range will represent 182 IPv4 systems (IPv4-converted addresses), but the IPv6 systems may use 183 any IPv6 addresses [RFC4291] except in that range. In this case, a 184 translation table is required to bind the IPv6 systems' addresses to 185 the IPv4 addresses maintained in the translator. 187 The address translation mechanisms for the stateless and the stateful 188 translations are defined in [I-D.ietf-behave-address-format]. 190 1.4. Path MTU Discovery and Fragmentation 192 Due to the different sizes of the IPv4 and IPv6 header, which are 20+ 193 octets and 40 octets respectively, handling the maximum packet size 194 is critical for the operation of the IPv4/IPv6 translator. There are 195 three mechanisms to handle this issue: path MTU discovery (PMTUD), 196 fragmentation, and transport-layer negotiation such as the TCP MSS 197 option [RFC0879]. Note that the translator MUST behave as a router, 198 i.e. the translator MUST send a "Packet Too Big" error message or 199 fragment the packet when the packet size exceeds the MTU of the next 200 hop interface. 202 "Don't Fragment", ICMP "Packet Too Big", and packet fragmentation are 203 discussed in sections 3 and 4 of this document. The reassembling of 204 fragmented packets in the stateful translator is discussed in 205 [I-D.ietf-behave-v6v4-xlate-stateful], since it requires state 206 maintenance in the translator. 208 2. Conventions 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 212 document are to be interpreted as described in [RFC2119]. 214 3. Translating from IPv4 to IPv6 216 When an IP/ICMP translator receives an IPv4 datagram addressed to a 217 destination towards the IPv6 domain, it translates the IPv4 header of 218 that packet into an IPv6 header. The original IPv4 header on the 219 packet is removed and replaced by an IPv6 header. Since the ICMPv6 220 [RFC4443], TCP [RFC0793], UDP [RFC0768] and DCCP [RFC4340] headers 221 contain checksums that cover IP header information, if the address 222 mapping algorithm is not checksum-neutral, the checksum MUST be 223 evaluated before translation and the ICMPv6 and transport-layer 224 headers MUST be updated. The data portion of the packet is left 225 unchanged. The IP/ICMP translator then forwards the packet based on 226 the IPv6 destination address. 228 +-------------+ +-------------+ 229 | IPv4 | | IPv6 | 230 | Header | | Header | 231 +-------------+ +-------------+ 232 | Transport | | Fragment | 233 | Layer | ===> | Header | 234 | Header | | (if needed) | 235 +-------------+ +-------------+ 236 | | | Transport | 237 ~ Data ~ | Layer | 238 | | | Header | 239 +-------------+ +-------------+ 240 | | 241 ~ Data ~ 242 | | 243 +-------------+ 245 Figure 2: IPv4-to-IPv6 Translation 247 Path MTU discovery is mandatory in IPv6 but it is optional in IPv4. 248 IPv6 routers never fragment a packet - only the sender can do 249 fragmentation. 251 When an IPv4 node performs path MTU discovery (by setting the Don't 252 Fragment (DF) bit in the header), path MTU discovery can operate end- 253 to-end, i.e., across the translator. In this case either IPv4 or 254 IPv6 routers (including the translator) might send back ICMP "Packet 255 Too Big" messages to the sender. When the IPv6 routers send these 256 ICMPv6 errors they will pass through a translator that will translate 257 the ICMPv6 error to a form that the IPv4 sender can understand. As a 258 result, an IPv6 fragment header is only included if the IPv4 packet 259 is already fragmented. 261 However, when the IPv4 sender does not set the Don't Fragment (DF) 262 bit, the translator MUST ensure that the packet does not exceed the 263 path MTU on the IPv6 side. This is done by fragmenting the IPv4 264 packet so that it fits in 1280-byte IPv6 packets, since that is the 265 minimum IPv6 MTU. Also, when the IPv4 sender does not set the DF bit 266 the translator MUST always include an IPv6 fragment header to 267 indicate that the sender allows fragmentation. 269 The rules in section 3.1 ensure that when packets are fragmented, 270 either by the sender or by IPv4 routers, the low-order 16 bits of the 271 fragment identification are carried end-to-end, ensuring that packets 272 are correctly reassembled. In addition, the rules in section 3.1 use 273 the presence of an IPv6 fragment header to indicate that the sender 274 might not be using path MTU discovery (i.e., the packet should not 275 have the DF flag set should it later be translated back to IPv4). 277 Other than the special rules for handling fragments and path MTU 278 discovery, the actual translation of the packet header consists of a 279 simple translation as defined below. Note that ICMPv4 packets 280 require special handling in order to translate the content of ICMPv4 281 error messages and also to add the ICMPv6 pseudo-header checksum. 283 3.1. Translating IPv4 Headers into IPv6 Headers 285 If the DF flag is not set and the IPv4 packet will result in an IPv6 286 packet larger than 1280 bytes, the packet MUST be fragmented so the 287 resulting IPv6 packet (with Fragment header added to each fragment) 288 will be less than or equal to 1280 bytes. For example, if the packet 289 is fragmented prior to the translation, the IPv4 packets must be 290 fragmented so that their length, excluding the IPv4 header, is at 291 most 1232 bytes (1280 minus 40 for the IPv6 header and 8 for the 292 Fragment header). The resulting fragments are then translated 293 independently using the logic described below. 295 If the DF bit is set and the MTU of the next-hop interface is less 296 than the total length value of the IPv4 packet plus 20, the 297 translator MUST send an ICMPv4 "Fragmentation Needed" error message 298 to the IPv4 source address. 300 If the DF bit is set and the packet is not a fragment (i.e., the MF 301 flag is not set and the Fragment Offset is equal to zero) then the 302 translator SHOULD NOT add a Fragment header to the resulting packet. 303 The IPv6 header fields are set as follows: 305 Version: 6 307 Traffic Class: By default, copied from IP Type Of Service (TOS) 308 octet. According to [RFC2474] the semantics of the bits are 309 identical in IPv4 and IPv6. However, in some IPv4 environments 310 these fields might be used with the old semantics of "Type Of 311 Service and Precedence". An implementation of a translator SHOULD 312 support an administratively-configurable option to ignore the IPv4 313 TOS and always set the IPv6 traffic class (TC) to zero. In 314 addition, if the translator is at an administrative boundary, the 315 filtering and update considerations of [RFC2475] may be 316 applicable. 318 Flow Label: 0 (all zero bits) 320 Payload Length: Total length value from IPv4 header, minus the size 321 of the IPv4 header and IPv4 options, if present. 323 Next Header: For ICMPv4 (1) changed to ICMPv6 (58), otherwise 324 protocol field MUST be copied from IPv4 header. 326 Hop Limit: The hop limit is derived from the TTL value in the IPv4 327 header. Since the translator is a router, as part of forwarding 328 the packet it needs to decrement either the IPv4 TTL (before the 329 translation) or the IPv6 Hop Limit (after the translation). As 330 part of decrementing the TTL or Hop Limit the translator (as any 331 router) MUST check for zero and send the ICMPv4 "TTL Exceeded" or 332 ICMPv6 "Hop Limit Exceeded" error. 334 Source Address: The IPv4-converted address derived from the IPv4 335 source address per [I-D.ietf-behave-address-format] section 2.1. 337 If the translator gets an illegal source address (e.g. 0.0.0.0, 338 127.0.0.1, etc.), the translator SHOULD silently drop the packet 339 (as discussed in Section 5.3.7 of [RFC1812]). 341 Destination Address: In the stateless mode, which is to say that if 342 the IPv4 destination address is within a range of configured IPv4 343 stateless translation prefix, the IPv6 destination address is the 344 IPv4-translatable address derived from the IPv4 destination 345 address per [I-D.ietf-behave-address-format] section 2.1. A 346 workflow example of stateless translation is shown in the Appendix 347 of this document. 349 In the stateful mode, which is to say that if the IPv4 destination 350 address is not within the range of any configured IPv4 stateless 351 translation prefix, the IPv6 destination address and corresponding 352 transport-layer destination port are derived from the Binding 353 Information Bases (BIBs) reflecting current session state in the 354 translator as described in [I-D.ietf-behave-v6v4-xlate-stateful]. 356 If any IPv4 options are present in the IPv4 packet, the IPv4 options 357 MUST be ignored and the packet translated normally; there is no 358 attempt to translate the options. However, if an unexpired source 359 route option is present then the packet MUST instead be discarded, 360 and an ICMPv4 "Destination Unreachable/Source Route Failed" (Type 361 3/Code 5) error message SHOULD be returned to the sender. 363 If there is a need to add a Fragment header (the DF bit is not set or 364 the packet is a fragment) the header fields are set as above with the 365 following exceptions: 367 IPv6 fields: 369 Payload Length: Total length value from IPv4 header, plus 8 for 370 the fragment header, minus the size of the IPv4 header and IPv4 371 options, if present. 373 Next Header: Fragment header (44). 375 Fragment header fields: 377 Next Header: For ICMPv4 (1) changed to ICMPv6 (58), otherwise 378 protocol field MUST be copied from IPv4 header. 380 Fragment Offset: Fragment Offset copied from the IPv4 header. 382 M flag: More Fragments bit copied from the IPv4 header. 384 Identification: The low-order 16 bits copied from the 385 Identification field in the IPv4 header. The high-order 16 386 bits set to zero. 388 3.2. Translating ICMPv4 Headers into ICMPv6 Headers 390 All ICMPv4 messages that are to be translated require that the ICMPv6 391 checksum field be calculated as part of the translation since ICMPv6, 392 unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP. 394 In addition, all ICMPv4 packets MUST have the Type value translated 395 and, for ICMPv4 error messages, the included IP header also MUST be 396 translated. 398 The actions needed to translate various ICMPv4 messages are as 399 follows: 401 ICMPv4 query messages: 403 Echo and Echo Reply (Type 8 and Type 0): Adjust the Type values 404 to 128 and 129, respectively, and adjust the ICMP checksum both 405 to take the type change into account and to include the ICMPv6 406 pseudo-header. 408 Information Request/Reply (Type 15 and Type 16): Obsoleted in 409 ICMPv6. Silently drop. 411 Timestamp and Timestamp Reply (Type 13 and Type 14): Obsoleted in 412 ICMPv6. Silently drop. 414 Address Mask Request/Reply (Type 17 and Type 18): Obsoleted in 415 ICMPv6. Silently drop. 417 ICMP Router Advertisement (Type 9): Single hop message. Silently 418 drop. 420 ICMP Router Solicitation (Type 10): Single hop message. Silently 421 drop. 423 Unknown ICMPv4 types: Silently drop. 425 IGMP messages: While the MLD messages [RFC2710][RFC3590][RFC3810] 426 are the logical IPv6 counterparts for the IPv4 IGMP messages 427 all the "normal" IGMP messages are single-hop messages and 428 SHOULD be silently dropped by the translator. Other IGMP 429 messages might be used by multicast routing protocols and, 430 since it would be a configuration error to try to have router 431 adjacencies across IP/ICMP translators those packets SHOULD 432 also be silently dropped. 434 ICMPv4 error messages: 436 Destination Unreachable (Type 3): Translate the Code field as 437 described below, set the Type field to 1, and adjust the 438 ICMP checksum both to take the type/code change into account 439 and to include the ICMPv6 pseudo-header. 441 Translate the Code field as follows: 443 Code 0, 1 (Net, host unreachable): Set Code value to 0 (no 444 route to destination). 446 Code 2 (Protocol unreachable): Translate to an ICMPv6 447 Parameter Problem (Type 4, Code value 1) and make the 448 Pointer point to the IPv6 Next Header field. 450 Code 3 (Port unreachable): Set Code value to 4 (port 451 unreachable). 453 Code 4 (Fragmentation needed and DF set): Translate to an 454 ICMPv6 Packet Too Big message (Type 2) with Code value 455 set to 0. The MTU field MUST be adjusted for the 456 difference between the IPv4 and IPv6 header sizes, i.e. 457 minimum(advertised MTU+20, MTU_of_IPv6_nexthop, 458 (MTU_of_IPv4_nexthop)+20). Note that if the IPv4 router 459 set the MTU field to zero, i.e., the router does not 460 implement [RFC1191], then the translator MUST use the 461 plateau values specified in [RFC1191] to determine a 462 likely path MTU and include that path MTU in the ICMPv6 463 packet. (Use the greatest plateau value that is less 464 than the returned Total Length field.) In order to avoid 465 back holes caused by ICMPv4 filtering or non [RFC2460] 466 compatible IPv6 hosts (a workaround discussed in Section 467 4), the translator MAY set the MTU to 1280 for any MTU 468 values which are smaller than 1280. The translator 469 SHOULD provide a method for operators to enable or 470 disable this function. 472 Code 5 (Source route failed): Set Code value to 0 (No route 473 to destination). Note that this error is unlikely since 474 source routes are not translated. 476 Code 6, 7, 8: Set Code value to 0 (No route to 477 destination). 479 Code 9, 10 (Communication with destination host 480 administratively prohibited): Set Code value to 1 481 (Communication with destination administratively 482 prohibited) 484 Code 11, 12: Set Code value to 0 (no route to destination). 486 Code 13 (Communication Administratively Prohibited): Set 487 Code value to 1 (Communication with destination 488 administratively prohibited). 490 Code 14 (Host Precedence Violation): Silently drop. 492 Code 15 (Precedence cutoff in effect): Set Code value to 1 493 (Communication with destination administratively 494 prohibited). 496 Other Code values: Silently drop. 498 Redirect (Type 5): Single hop message. Silently drop. 500 Alternative Host Address (Type 6): Silently drop. 502 Source Quench (Type 4): Obsoleted in ICMPv6. Silently drop. 504 Time Exceeded (Type 11): Set the Type field to 3, and adjust 505 the ICMP checksum both to take the type change into account 506 and to include the ICMPv6 pseudo-header. The Code field is 507 unchanged. 509 Parameter Problem (Type 12): Set the Type field to 4, and 510 adjust the ICMP checksum both to take the type/code change 511 into account and to include the ICMPv6 pseudo-header. 513 Translate the Code field as follows: 515 Code 0 (Pointer indicates the error): Set the Code value to 516 0 (Erroneous header field encountered) and update the 517 pointer as defined in Figure 3 (If the Original IPv4 518 Pointer Value is not listed or the Translated IPv6 519 Pointer Value is listed as "n/a", silently drop the 520 packet). 522 Code 1 (Missing a required option): Silently drop 524 Code 2 (Bad length): Set the Code value to 0 (Erroneous 525 header field encountered) and update the pointer as 526 defined in Figure 3 (If the Original IPv4 Pointer Value 527 is not listed or the Translated IPv6 Pointer Value is 528 listed as "n/a", silently drop the packet). 530 Other Code values: Silently drop 532 Unknown ICMPv4 types: Silently drop. 534 | Original IPv4 Pointer Value | Translated IPv6 Pointer Value | 535 +--------------------------------+--------------------------------+ 536 | 0 | Version/IHL | 0 | Version/Traffic Class | 537 | 1 | Type Of Service | 1 | Traffic Class/Flow Label | 538 | 2,3 | Total Length | 4 | Payload Length | 539 | 4,5 | Identification | n/a | | 540 | 6 | Flags/Fragment Offset | n/a | | 541 | 7 | Fragment Offset | n/a | | 542 | 8 | Time to Live | 7 | Hop Limit | 543 | 9 | Protocol | 6 | Next Header | 544 |10,11| Header Checksum | n/a | | 545 |12-15| Source Address | 8 | Source Address | 546 |16-19| Destination Address | 24 | Destination Address | 547 +--------------------------------+--------------------------------+ 549 Figure 3: Pointer value for translating from IPv4 to IPv6 551 ICMP Error Payload: If the received ICMPv4 packet contains an 552 ICMPv4 Extension [RFC4884], the translation of the ICMPv4 553 packet will cause the ICMPv6 packet to change length. When 554 this occurs, the ICMPv6 Extension length attribute MUST be 555 adjusted accordingly (e.g., longer due to the translation 556 from IPv4 to IPv6). If the ICMPv4 Extension exceeds the 557 maximum size of an ICMPv6 message on the outgoing interface, 558 the ICMPv4 extension SHOULD be simply truncated. For 559 extensions not defined in [RFC4884], the translator passes 560 the extensions as opaque bit strings and those containing 561 IPv4 address literals will not have those addresses 562 translated to IPv6 address literals; this may cause problems 563 with processing of those ICMP extensions. 565 3.3. Translating ICMPv4 Error Messages into ICMPv6 567 There are some differences between the ICMPv4 and the ICMPv6 error 568 message formats as detailed above. In addition, the ICMP error 569 messages contain the packet in error, which MUST be translated just 570 like a normal IP packet. If the translation of this "packet in 571 error" changes the length of the datagram, the Total Length field in 572 the outer IPv6 header MUST be updated. 574 +-------------+ +-------------+ 575 | IPv4 | | IPv6 | 576 | Header | | Header | 577 +-------------+ +-------------+ 578 | ICMPv4 | | ICMPv6 | 579 | Header | | Header | 580 +-------------+ +-------------+ 581 | IPv4 | ===> | IPv6 | 582 | Header | | Header | 583 +-------------+ +-------------+ 584 | Partial | | Partial | 585 | Transport | | Transport | 586 | Layer | | Layer | 587 | Header | | Header | 588 +-------------+ +-------------+ 590 Figure 4: IPv4-to-IPv6 ICMP Error Translation 592 The translation of the inner IP header can be done by invoking the 593 function that translated the outer IP headers. This process MUST 594 stop at the first embedded header and drop the packet if it contains 595 more. 597 3.4. Translator Sending ICMPv4 Error Message 599 If the IPv4 packet is discarded, then the translator SHOULD be able 600 to send back an ICMPv4 error message to the original sender of the 601 packet, unless the discarded packet is itself an ICMPv4 message. The 602 ICMPv4 message, if sent, has a Type value of 3 (Destination 603 Unreachable) and a Code value of 13 (Communication Administratively 604 Prohibited), unless otherwise specified in this document or in 605 [I-D.ietf-behave-v6v4-xlate-stateful]. The translator SHOULD allow 606 an administrator to configure whether the ICMPv4 error messages are 607 sent, rate-limited, or not sent. 609 3.5. Transport-layer Header Translation 611 If the address translation algorithm is not checksum neutral, the 612 recalculation and updating of the transport-layer headers which 613 contain pseudo headers (e.g. of TCP, UDP and DCCP) MUST be performed. 614 For ESP or undefined transport protocol, the translator MUST forward 615 the packets to the destination without touching the transport-layer 616 header. 618 When a translator receives an unfragmented UDP IPv4 packet and the 619 checksum field is zero, the translator SHOULD compute the missing UDP 620 checksum as part of translating the packet. Also, the translator 621 SHOULD maintain a counter of how many UDP checksums are generated in 622 this manner. 624 When a stateless translator receives the first fragment of a 625 fragmented UDP IPv4 packet and the checksum field is zero, the 626 translator SHOULD drop the packet and generate a system management 627 event specifying at least the IP addresses and port numbers in the 628 packet. 630 For stateful translator, the handling of fragmented UDP IPv4 packets 631 with a zero checksum is discussed in 632 [I-D.ietf-behave-v6v4-xlate-stateful] section 3.1. 634 3.6. Knowing When to Translate 636 If the IP/ICMP translator also provides normal forwarding function, 637 and the destination IPv4 address is reachable by a more specific 638 route without translation, the translator MUST forward it without 639 translating it. Otherwise, when an IP/ICMP translator receives an 640 IPv4 datagram addressed to an IPv4 destination representing a host in 641 the IPv6 domain, the packet MUST be translated to IPv6. 643 4. Translating from IPv6 to IPv4 645 When an IP/ICMP translator receives an IPv6 datagram addressed to a 646 destination towards the IPv4 domain, it translates the IPv6 header of 647 the received IPv6 packet into an IPv4 header. The original IPv6 648 header on the packet is removed and replaced by an IPv4 header. 649 Since the ICMPv6 [RFC4443], TCP [RFC0793], UDP [RFC0768] and DCCP 650 [RFC4340] headers contain checksums that cover the IP header, if the 651 address mapping algorithm is not checksum-neutral, the checksum MUST 652 be evaluated before translation and the ICMP and transport-layer 653 headers MUST be updated. The data portion of the packet is left 654 unchanged. The IP/ICMP translator then forwards the packet based on 655 the IPv4 destination address. 657 +-------------+ +-------------+ 658 | IPv6 | | IPv4 | 659 | Header | | Header | 660 +-------------+ +-------------+ 661 | Fragment | | Transport | 662 | Header | ===> | Layer | 663 |(if present) | | Header | 664 +-------------+ +-------------+ 665 | Transport | | | 666 | Layer | ~ Data ~ 667 | Header | | | 668 +-------------+ +-------------+ 669 | | 670 ~ Data ~ 671 | | 672 +-------------+ 674 Figure 5: IPv6-to-IPv4 Translation 676 There are some differences between IPv6 and IPv4 in the area of 677 fragmentation and the minimum link MTU that affect the translation. 678 An IPv6 link has to have an MTU of 1280 bytes or greater. The 679 corresponding limit for IPv4 is 68 bytes. Path MTU Discovery across 680 a translator relies on ICMP Packet Too Big messages being received 681 and processed by IPv6 hosts, including an ICMP Packet Too Big that 682 indicates the MTU is less than the IPv6 minimum MTU. This 683 requirement is described in Section 5 of [RFC2460] (for IPv6's 1280 684 octet minimum MTU) and Section 5 of [RFC1883] (for IPv6's previous 685 576 octet minimum MTU). 687 In an environment where an ICMPv4 Packet Too Big message is 688 translated to an ICMPv6 Packet Too Big messages, and the ICMPv6 689 Packet Too Big message is successfully delivered to and correctly 690 processed by the IPv6 hosts (e.g., a network owned/operated by the 691 same entity that owns/operates the translator), the translator can 692 rely on IPv6 hosts sending subsequent packets to the same IPv6 693 destination with IPv6 fragment headers. In such an environment, when 694 the translator receives an IPv6 packet with a fragmentation header, 695 the translator SHOULD generate the IPv4 packet with a cleared Don't 696 Fragment bit, and with its identification value from the IPv6 697 fragment header, for all of the IPv6 fragments (MF=0 or MF=1). 699 In an environment where an ICMPv4 Packet Too Big message are filtered 700 (by a network firewall or by the host itself) or not correctly 701 processed by the IPv6 hosts, the IPv6 host will never generate an 702 IPv6 packet with the IPv6 fragment header. In such an environment, 703 the translator SHOULD set the IPv4 Don't Fragment bit. While setting 704 the Don't Fragment bit may create PMTUD black holes [RFC2923] if 705 there are IPv4 links smaller than 1260 octets, this is considered 706 safer than causing IPv4 reassembly errors [RFC4963]. 708 A recent study indicates that only 43.46% of IPv6-capable web servers 709 include an IPv6 fragmentation header in their respond packets after 710 they were sent an ICMPv6 Packet Too Big message specifying an 711 MTU<1280 bytes. A workaround to this problem (ICMPv6 Packet Too Big 712 message with MTU<1280) is that (1) in the IPv4 to IPv6 direction, the 713 MTU value in the ICMPv4 Packet Too Big should be maximized with 1280, 714 and (2) in the IPv6 to IPv4 direction, if there is no fragmentation 715 header in the IPv6 packet, the translator SHOULD set DF to 0 for the 716 packets equal to or smaller than 1280 bytes and set DF to 1 for 717 packets larger than 1280 bytes. In addition, the translator SHOULD 718 take the identification value from the IPv6 fragmentation header if 719 present or generate the identification value otherwise. This avoids 720 the introduction of the path MTU discovery black hole. Note that 721 translator generating the IPv4 identification value is tricky in 722 stateless mode. The Internet Protocol standard [RFC0791] specifies: 724 "The choice of the Identifier for a datagram is based on the need 725 to provide a way to uniquely identify the fragments of a 726 particular datagram. The protocol module assembling fragments 727 judges fragments to belong to the same datagram if they have the 728 same source, destination, protocol, and Identifier. Thus, the 729 sender must choose the Identifier to be unique for this source, 730 destination pair and protocol for the time the datagram (or any 731 fragment of it) could be alive in the Internet." 733 Therefore, the translator may require states per three tuple IPv4 734 identification field. However, this does not prevent the deployment 735 of the stateless translator, since as discussed in 736 [I-D.ietf-behave-v6v4-framework], the stateless translation can be 737 used in scenarios 1, 2, 5 and 6. All of these scenarios involve "An 738 IPv6 network" which are managed networks and network firewall, host 739 firewall or host misbehavior can be controlled. In such a controlled 740 environment, it can be assured that hosts and firewalls properly 741 process ICMPv6 messages as described in Section 5 of [RFC2460]. 743 Other than the special rules for handling fragments and path MTU 744 discovery, the actual translation of the packet header consists of a 745 simple translation as defined below. Note that ICMPv6 packets 746 require special handling in order to translate the contents of ICMPv6 747 error messages and also to remove the ICMPv6 pseudo-header checksum. 749 4.1. Translating IPv6 Headers into IPv4 Headers 751 If there is no IPv6 Fragment header, the IPv4 header fields are set 752 as follows: 754 Version: 4 756 Internet Header Length: 5 (no IPv4 options) 758 Type of Service (TOS) Octet: By default, copied from the IPv6 759 Traffic Class (all 8 bits). According to [RFC2474] the semantics 760 of the bits are identical in IPv4 and IPv6. However, in some IPv4 761 environments, these bits might be used with the old semantics of 762 "Type Of Service and Precedence". An implementation of a 763 translator SHOULD provide the ability to ignore the IPv6 traffic 764 class and always set the IPv4 TOS Octet to a specified value. In 765 addition, if the translator is at an administrative boundary, the 766 filtering and update considerations of [RFC2475] may be 767 applicable. 769 Total Length: Payload length value from IPv6 header, plus the size 770 of the IPv4 header. 772 Identification: All zero. In order to avoid back holes caused by 773 ICMPv4 filtering or non [RFC2460] compatible IPv6 hosts (a 774 workaround discussed in Section 4), the translator MAY provide a 775 function such as if the packet size is equal to or smaller than 776 1280 bytes and greater than 88 bytes, generate the identification 777 value. The translator SHOULD provide a method for operators to 778 enable or disable this function. 780 Flags: The More Fragments flag is set to zero. The Don't Fragments 781 flag is set to one. In order to avoid back holes caused by ICMPv4 782 filtering or non [RFC2460] compatible IPv6 hosts (a workaround 783 discussed in Section 4), the translator MAY provide a function 784 such as if the packet size is equal to or smaller than 1280 bytes 785 and greater than 88 bytes, the Don't Fragments (DF) flag is set to 786 zero, otherwise the Don't Fragments (DF) flag is set to one. The 787 translator SHOULD provide a method for operators to enable or 788 disable this function. 790 Fragment Offset: All zeros. 792 Time to Live: Time to Live is derived from Hop Limit value in IPv6 793 header. Since the translator is a router, as part of forwarding 794 the packet it needs to decrement either the IPv6 Hop Limit (before 795 the translation) or the IPv4 TTL (after the translation). As part 796 of decrementing the TTL or Hop Limit the translator (as any 797 router) MUST check for zero and send the ICMPv4 "TTL Exceeded" or 798 ICMPv6 "Hop Limit Exceeded" error. 800 Protocol: For ICMPv6 (58) changed to ICMPv4 (1), otherwise skip 801 extension headers, copy the Next Header field (ESP, transport 802 protocol or undefined next header value) in the last known next 803 header. 805 Header Checksum: Computed once the IPv4 header has been created. 807 Source Address: In the stateless mode, which is to say that if the 808 IPv6 source address is within the range of a configured IPv6 809 translation prefix, the IPv4 source address is derived from the 810 IPv6 source address per [I-D.ietf-behave-address-format] section 811 2.1. Note that the original IPv6 source address is an IPv4- 812 translatable address. A workflow example of stateless translation 813 is shown in Appendix of this document. If the translator only 814 supports stateless mode and if the IPv6 source address is not 815 within the range of configured IPv6 prefix(es), the translator 816 SHOULD drop the packet and respond with an ICMPv6 Type=1, Code=5 817 (Destination Unreachable, Source address failed ingress/egress 818 policy). 820 In the stateful mode, which is to say that if the IPv6 source 821 address is not within the range of any configured IPv6 stateless 822 translation prefix, the IPv4 source address and transport-layer 823 source port corresponding to the IPv4-related IPv6 source address 824 and source port are derived from the Binding Information Bases 825 (BIBs) as described in [I-D.ietf-behave-v6v4-xlate-stateful]. 827 In stateless and stateful modes, if the translator gets an illegal 828 source address (e.g. ::1, etc.), the translator SHOULD silently 829 drop the packet. 831 Destination Address: The IPv4 destination address is derived from 832 the IPv6 destination address of the datagram being translated per 833 [I-D.ietf-behave-address-format] section 2.1. Note that the 834 original IPv6 destination address is an IPv4-converted address. 836 Certain IPv6 headers cannot be translated because they have no 837 meaning in IPv4. These headers are skipped over during processing 838 and include HOPOPT (0), IPv6-Route (43), and IPv6-Opts (60). The 839 IPv6-Frag (44) header is handled as discussed below. For the first 840 'next header' that does not match one of the values above, its next 841 header value (which contains the transport protocol number) is copied 842 to the protocol field in the IPv4 header. This means that all 843 transport protocols are translated. Some translated protocols will 844 fail at the receiver for various reasons: some are known to fail when 845 translated (e.g., IPsec AH (51)), others are malformed IPv6 packets 846 with a useless IPv4 protocol number (e.g., IPv6-NoNxt (59)), and 847 others will fail checksum validation if the address translation is 848 not checksum neutral [I-D.ietf-behave-address-format] and the 849 translator does not update the transport protocol's checksum (because 850 the translator doesn't support recalculating the checksum for that 851 transport protocol, e.g., SCTP (132)). 853 If a Routing header with a non-zero Segments Left field is present 854 then the packet MUST NOT be translated, and an ICMPv6 "parameter 855 problem/erroneous header field encountered" (Type 4/Code 0) error 856 message, with the Pointer field indicating the first byte of the 857 Segments Left field, SHOULD be returned to the sender. 859 If the IPv6 packet contains a Fragment header, the header fields are 860 set as above with the following exceptions: 862 Total Length: Payload length value from IPv6 header, minus 8 for the 863 Fragment header, plus the size of the IPv4 header. 865 Identification: Copied from the low-order 16-bits in the 866 Identification field in the Fragment header. 868 Flags: The More Fragments (MF) flag is copied from the M flag in the 869 Fragment header. The Don't Fragments (DF) flag is set to zero 870 allowing this packet to be fragmented if required by IPv4 routers. 872 Fragment Offset: Copied from the Fragment Offset field in the 873 Fragment header. 875 Protocol: For ICMPv6 (58) changed to ICMPv4 (1), otherwise skip 876 extension headers, Next Header field copied from the last IPv6 877 header. 879 If a translated packet with DF set to 1 will be larger than the MTU 880 of the next-hop interface, then the translator MUST drop the packet 881 and send the ICMPv6 "Packet Too Big" (Type 2/Code 0) error message to 882 the IPv6 host with an adjusted MTU in the ICMPv6 message. 884 4.2. Translating ICMPv6 Headers into ICMPv4 Headers 886 All ICMPv6 messages that are to be translated require that the ICMPv4 887 checksum field be updated as part of the translation since ICMPv6 888 (unlike ICMPv4) includes a pseudo-header in the checksum just like 889 UDP and TCP. 891 In addition all ICMP packets MUST have the Type value translated and, 892 for ICMP error messages, the included IP header also MUST be 893 translated. Note that the IPv6 addresses in the IPv6 header may not 894 be IPv4-translatable addresses and there will be no corresponding 895 IPv4 addresses representing this IPv6 address. In this case, the 896 translator can do stateful translation. A mechanism by which the 897 translator can instead do stateless translation is left for future 898 work. 900 The actions needed to translate various ICMPv6 messages are: 902 ICMPv6 informational messages: 904 Echo Request and Echo Reply (Type 128 and 129): Adjust the Type 905 values to 8 and 0, respectively, and adjust the ICMP checksum 906 both to take the type change into account and to exclude the 907 ICMPv6 pseudo-header. 909 MLD Multicast Listener Query/Report/Done (Type 130, 131, 132): 910 Single hop message. Silently drop. 912 Neighbor Discover messages (Type 133 through 137): Single hop 913 message. Silently drop. 915 Unknown informational messages: Silently drop. 917 ICMPv6 error messages: 919 Destination Unreachable (Type 1) Set the Type field to 3, and 920 adjust the ICMP checksum both to take the type/code change into 921 account and to exclude the ICMPv6 pseudo-header. 923 Translate the Code field as follows: 925 Code 0 (no route to destination): Set Code value to 1 (Host 926 unreachable). 928 Code 1 (Communication with destination administratively 929 prohibited): Set Code value to 10 (Communication with 930 destination host administratively prohibited). 932 Code 2 (Beyond scope of source address): Set Code value to 1 933 (Host unreachable). Note that this error is very unlikely 934 since an IPv4-translatable source address is typically 935 considered to have global scope. 937 Code 3 (Address unreachable): Set Code value to 1 (Host 938 unreachable). 940 Code 4 (Port unreachable): Set Code value to 3 (Port 941 unreachable). 943 Other Code values: Silently drop. 945 Packet Too Big (Type 2): Translate to an ICMPv4 Destination 946 Unreachable (Type 3) with Code value equal to 4, and adjust the 947 ICMPv4 checksum both to take the type change into account and 948 to exclude the ICMPv6 pseudo-header. The MTU field MUST be 949 adjusted for the difference between the IPv4 and IPv6 header 950 sizes taking into account whether or not the packet in error 951 includes a Fragment header, i.e. minimum(advertised MTU-20, 952 MTU_of_IPv4_nexthop, (MTU_of_IPv6_nexthop)-20) 954 Time Exceeded (Type 3): Set the Type value to 11, and adjust the 955 ICMPv4 checksum both to take the type change into account and 956 to exclude the ICMPv6 pseudo-header. The Code field is 957 unchanged. 959 Parameter Problem (Type 4): Translate the Type and Code field as 960 follows, and adjust the ICMPv4 checksum both to take the type/ 961 code change into account and to exclude the ICMPv6 pseudo- 962 header. 964 Translate the Code field as follows: 966 Code 0 (Erroneous header field encountered): Set Type 12, Code 967 0 and update the pointer as defined in Figure 6 (If the 968 Original IPv6 Pointer Value is not listed or the Translated 969 IPv4 Pointer Value is listed as "n/a", silently drop the 970 packet). 972 Code 1 (Unrecognized Next Header type encountered): Translate 973 this to an ICMPv4 protocol unreachable (Type 3, Code 2). 975 Code 2 (Unrecognized IPv6 option encountered): Silently drop. 977 Unknown error messages: Silently drop. 979 | Original IPv6 Pointer Value | Translated IPv4 Pointer Value | 980 +--------------------------------+--------------------------------+ 981 | 0 | Version/Traffic Class | 0 | Version/IHL, Type Of Ser | 982 | 1 | Traffic Class/Flow Label | 1 | Type Of Service | 983 | 2,3 | Flow Label | n/a | | 984 | 4,5 | Payload Length | 2 | Total Length | 985 | 6 | Next Header | 9 | Protocol | 986 | 7 | Hop Limit | 8 | Time to Live | 987 | 8-23| Source Address | 12 | Source Address | 988 |24-39| Destination Address | 16 | Destination Address | 989 +--------------------------------+--------------------------------+ 991 Figure 6: Pointer Value for translating from IPv6 to IPv4 993 ICMP Error Payload: If the received ICMPv6 packet contains an 994 ICMPv6 Extension [RFC4884], the translation of the ICMPv6 995 packet will cause the ICMPv4 packet to change length. When 996 this occurs, the ICMPv6 Extension length attribute MUST be 997 adjusted accordingly (e.g., shorter due to the translation from 998 IPv6 to IPv4). For extensions not defined in [RFC4884], the 999 translator passes the extensions as opaque bit strings and 1000 those containing IPv6 address literals will not have those 1001 addresses translated to IPv4 address literals; this may cause 1002 problems with processing of those ICMP extensions. 1004 4.3. Translating ICMPv6 Error Messages into ICMPv4 1006 There are some differences between the ICMPv4 and the ICMPv6 error 1007 message formats as detailed above. In addition, the ICMP error 1008 messages contain the packet in error, which MUST be translated just 1009 like a normal IP packet. The translation of this "packet in error" 1010 is likely to change the length of the datagram thus the Total Length 1011 field in the outer IPv4 header MUST be updated. 1013 +-------------+ +-------------+ 1014 | IPv6 | | IPv4 | 1015 | Header | | Header | 1016 +-------------+ +-------------+ 1017 | ICMPv6 | | ICMPv4 | 1018 | Header | | Header | 1019 +-------------+ +-------------+ 1020 | IPv6 | ===> | IPv4 | 1021 | Header | | Header | 1022 +-------------+ +-------------+ 1023 | Partial | | Partial | 1024 | Transport | | Transport | 1025 | Layer | | Layer | 1026 | Header | | Header | 1027 +-------------+ +-------------+ 1029 Figure 7: IPv6-to-IPv4 ICMP Error Translation 1031 The translation of the inner IP header can be done by invoking the 1032 function that translated the outer IP headers. This process MUST 1033 stop at first embedded header and drop the packet if it contains 1034 more. Note that the IPv6 addresses in the IPv6 header may not be 1035 IPv4-translatable addresses and there will be no corresponding IPv4 1036 addresses. In this case, the translator can do stateful translation. 1037 A mechanism by which the translator can instead do stateless 1038 translation is left for future work. 1040 4.4. Translator Sending ICMPv6 Error Message 1042 If the IPv6 packet is discarded, then the translator SHOULD be able 1043 to send back an ICMPv6 error message to the original sender of the 1044 packet, unless the discarded packet is itself an ICMPv6 message. 1046 If the ICMPv6 error message is being sent because the IPv6 source 1047 address is not an IPv4-translatable address and the translator is 1048 stateless, the ICMPv6 message, if sent, has a Type value 1 and Code 1049 value 5 (Source address failed ingress/egress policy). In other 1050 cases, the ICMPv6 message has a Type value of 1 (Destination 1051 Unreachable) and a Code value of 1 (Communication with destination 1052 administratively prohibited), unless otherwise specified in this 1053 document or [I-D.ietf-behave-v6v4-xlate-stateful]. The translator 1054 SHOULD allow an administrator to configure whether the ICMPv6 error 1055 messages are sent, rate-limited, or not sent. 1057 4.5. Transport-layer Header Translation 1059 If the address translation algorithm is not checksum neutral, the 1060 recalculation and updating of the known transport-layer headers which 1061 contain pseudo headers (e.g. of TCP, UDP and DCCP) MUST be performed. 1062 For ESP or undefined transport protocol, the translator MUST forward 1063 the packets to the destination without touching the transport-layer 1064 header. 1066 4.6. Knowing When to Translate 1068 If the IP/ICMP translator also provides a normal forwarding function, 1069 and the destination address is reachable by a more specific route 1070 without translation, the router MUST forward it without translating 1071 it. When an IP/ICMP translator receives an IPv6 datagram addressed 1072 to an IPv6 address representing a host in the IPv4 domain, the IPv6 1073 packet MUST be translated to IPv4. 1075 5. IANA Considerations 1077 This memo adds no new IANA considerations. 1079 Note to RFC Editor: This section will have served its purpose if it 1080 correctly tells IANA that no new assignments or registries are 1081 required, or if those assignments or registries are created during 1082 the RFC publication process. From the author's perspective, it may 1083 therefore be removed upon publication as an RFC at the RFC Editor's 1084 discretion. 1086 6. 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. The [I-D.ietf-behave-address-format] addresses these issues. 1098 As the Authentication Header [RFC4302] is specified to include the 1099 IPv4 Identification field and the translating function is not able to 1100 always preserve the Identification field, it is not possible for an 1101 IPv6 endpoint to verify the AH on received packets that have been 1102 translated from IPv4 packets. Thus AH does not work through a 1103 translator. 1105 Packets with ESP can be translated since ESP does not depend on 1106 header fields prior to the ESP header. Note that ESP transport mode 1107 is easier to handle than ESP tunnel mode; in order to use ESP tunnel 1108 mode, the IPv6 node MUST be able to generate an inner IPv4 header 1109 when transmitting packets and remove such an IPv4 header when 1110 receiving packets. 1112 7. Acknowledgements 1114 This is under development by a large group of people. Those who have 1115 posted to the list during the discussion include Andrew Sullivan, 1116 Andrew Yourtchenko, Brian Carpenter, Dan Wing, Dave Thaler, David 1117 Harrington, Ed Jankiewicz, Hiroshi Miyata, Iljitsch van Beijnum, Jari 1118 Arkko, Jerry Huang, John Schnizlein, Jouni Korhonen, Kentaro Ebisawa, 1119 Kevin Yin, Magnus Westerlund, Marcelo Bagnulo Braun, Margaret 1120 Wasserman, Masahito Endo, Phil Roberts, Philip Matthews, Reinaldo 1121 Penno, Remi Denis-Courmont, Remi Despres, Senthil Sivakumar, Simon 1122 Perreault and Zen Cao. 1124 8. Appendix: Stateless translation workflow example 1126 A stateless translation workflow example is depicted in the following 1127 figure. The documentation address blocks 2001:DB8::/32 [RFC3849], 1128 192.0.2.0/24 and 198.51.100.0/24 [RFC5737] are used in this example. 1130 +--------------+ +--------------+ 1131 | IPv4 network | | IPv6 network | 1132 | | +-------+ | | 1133 | +----+ |-----| XLAT |---- | +----+ | 1134 | | H4 |-----| +-------+ |--| H6 | | 1135 | +----+ | | +----+ | 1136 +--------------+ +--------------+ 1138 Figure 8 1140 A translator (XLAT) connects the IPv6 network to the IPv4 network. 1141 This XLAT uses the Network Specific Prefix (NSP) 2001:DB8:100::/40 1142 defined in [I-D.ietf-behave-address-format] to represent IPv4 1143 addresses in the IPv6 address space (IPv4-converted addresses) and to 1144 represent IPv6 addresses (IPv4-translatable addresses) in the IPv4 1145 address space. In this example, 192.0.2.0/24 is the IPv4 block of 1146 the corresponding IPv4-translatable addresses. 1148 Based on the address mapping rule, the IPv6 node H6 has an IPv4- 1149 translatable IPv6 address 2001:DB8:1C0:2:21:: (address mapping from 1150 192.0.2.33). The IPv4 node H4 has IPv4 address 198.51.100.2. 1152 The IPv6 routing is configured in such a way that the IPv6 packets 1153 addressed to a destination address in 2001:DB8:100::/40 are routed to 1154 the IPv6 interface of the XLAT. 1156 The IPv4 routing is configured in such a way that the IPv4 packets 1157 addressed to a destination address in 192.0.2.0/24 are routed to the 1158 IPv4 interface of the XLAT. 1160 8.1. H6 establishes communication with H4 1162 The steps by which H6 establishes communication with H4 are: 1164 1. H6 performs the destination address mapping, so the IPv4- 1165 converted address 2001:DB8:1C6:3364:200:: is formed from 1166 198.51.100.2 based on the address mapping algorithm 1167 [I-D.ietf-behave-address-format]. 1169 2. H6 sends a packet to H4. The packet is sent from a source 1170 address 2001:DB8:1C0:2:21:: to a destination address 1171 2001:DB8:1C6:3364:200::. 1173 3. The packet is routed to the IPv6 interface of the XLAT (since 1174 IPv6 routing is configured that way). 1176 4. The XLAT receives the packet and performs the following actions: 1178 * The XLAT translates the IPv6 header into an IPv4 header using 1179 the IP/ICMP Translation Algorithm defined in this document. 1181 * The XLAT includes 192.0.2.33 as source address in the packet 1182 and 198.51.100.2 as destination address in the packet. Note 1183 that 192.0.2.33 and 198.51.100.2 are extracted directly from 1184 the source IPv6 address 2001:DB8:1C0:2:21:: (IPv4-translatable 1185 address) and destination IPv6 address 2001:DB8:1C6:3364:200:: 1186 (IPv4-converted address) of the received IPv6 packet that is 1187 being translated. 1189 5. The XLAT sends the translated packet out its IPv4 interface and 1190 the packet arrives at H4. 1192 6. H4 node responds by sending a packet with destination address 1193 192.0.2.33 and source address 198.51.100.2. 1195 7. The packet is routed to the IPv4 interface of the XLAT (since 1196 IPv4 routing is configured that way). The XLAT performs the 1197 following operations: 1199 * The XLAT translates the IPv4 header into an IPv6 header using 1200 the IP/ICMP Translation Algorithm defined in this document. 1202 * The XLAT includes 2001:DB8:1C0:2:21:: as destination address 1203 in the packet and 2001:DB8:1C6:3364:200:: as source address in 1204 the packet. Note that 2001:DB8:1C0:2:21:: and 1205 2001:DB8:1C6:3364:200:: 1206 are formed directly from the destination IPv4 1207 address 192.0.2.33 and source IPv4 address 198.51.100.2 of the 1208 received IPv4 packet that is being translated. 1210 8. The translated packet is sent out the IPv6 interface to H6. 1212 The packet exchange between H6 and H4 continues until the session is 1213 finished. 1215 8.2. H4 establishes communication with H6 1217 The steps by which H4 establishes communication with H6 are: 1219 1. H4 performs the destination address mapping, so 192.0.2.33 is 1220 formed from IPv4-translatable address 2001:DB8:1C0:2:21:: based 1221 on the address mapping algorithm 1222 [I-D.ietf-behave-address-format]. 1224 2. H4 sends a packet to H6. The packet is sent from a source 1225 address 198.51.100.2 to a destination address 192.0.2.33. 1227 3. The packet is routed to the IPv4 interface of the XLAT (since 1228 IPv4 routing is configured that way). 1230 4. The XLAT receives the packet and performs the following actions: 1232 * The XLAT translates the IPv4 header into an IPv6 header using 1233 the IP/ICMP Translation Algorithm defined in this document. 1235 * The XLAT includes 2001:DB8:1C6:3364:200:: as source address in 1236 the packet and 2001:DB8:1C0:2:21:: as destination address in 1237 the packet. Note that 2001:DB8:1C6:3364:200:: (IPv4-converted 1238 address) and 2001:DB8:1C0:2:21:: (IPv4-translatable address) 1239 are obtained directly from the source IPv4 address 1240 198.51.100.2 and destination IPv4 address 192.0.2.33 of the 1241 received IPv4 packet that is being translated. 1243 5. The XLAT sends the translated packet out its IPv6 interface and 1244 the packet arrives at H6. 1246 6. H6 node responds by sending a packet with destination address 1247 2001:DB8:1C6:3364:200:: and source address 2001:DB8:1C0:2:21::. 1249 7. The packet is routed to the IPv6 interface of the XLAT (since 1250 IPv6 routing is configured that way). The XLAT performs the 1251 following operations: 1253 * The XLAT translates the IPv6 header into an IPv4 header using 1254 the IP/ICMP Translation Algorithm defined in this document. 1256 * The XLAT includes 198.51.100.2 as destination address in the 1257 packet and 192.0.2.33 as source address in the packet. Note 1258 that 198.51.100.2 and 192.0.2.33 are formed directly from the 1259 destination IPv6 address 2001:DB8:1C6:3364:200:: and source 1260 IPv6 address 2001:DB8:1C0:2:21:: of the received IPv6 packet 1261 that is being translated. 1263 8. The translated packet is sent out the IPv4 interface to H4. 1265 The packet exchange between H4 and H6 continues until the session 1266 finished. 1268 9. References 1270 9.1. Normative References 1272 [I-D.ietf-behave-address-format] 1273 Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1274 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 1275 draft-ietf-behave-address-format-07 (work in progress), 1276 April 2010. 1278 [I-D.ietf-behave-v6v4-xlate-stateful] 1279 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 1280 NAT64: Network Address and Protocol Translation from IPv6 1281 Clients to IPv4 Servers", 1282 draft-ietf-behave-v6v4-xlate-stateful-11 (work in 1283 progress), March 2010. 1285 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1286 August 1980. 1288 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1289 September 1981. 1291 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1292 RFC 792, September 1981. 1294 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1295 RFC 793, September 1981. 1297 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1298 RFC 1812, June 1995. 1300 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1301 (IPv6) Specification", RFC 1883, December 1995. 1303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1304 Requirement Levels", BCP 14, RFC 2119, March 1997. 1306 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1307 (IPv6) Specification", RFC 2460, December 1998. 1309 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1310 (SIIT)", RFC 2765, February 2000. 1312 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1313 Architecture", RFC 4291, February 2006. 1315 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1316 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1318 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1319 Message Protocol (ICMPv6) for the Internet Protocol 1320 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1322 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 1323 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 1324 April 2007. 1326 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1327 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1328 RFC 5382, October 2008. 1330 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 1331 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 1332 March 2010. 1334 9.2. Informative References 1336 [I-D.ietf-behave-v6v4-framework] 1337 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1338 IPv4/IPv6 Translation", 1339 draft-ietf-behave-v6v4-framework-08 (work in progress), 1340 March 2010. 1342 [RFC0879] Postel, J., "TCP maximum segment size and related topics", 1343 RFC 879, November 1983. 1345 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1346 November 1990. 1348 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1349 "Definition of the Differentiated Services Field (DS 1350 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1351 December 1998. 1353 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1354 and W. Weiss, "An Architecture for Differentiated 1355 Services", RFC 2475, December 1998. 1357 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1358 Listener Discovery (MLD) for IPv6", RFC 2710, 1359 October 1999. 1361 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 1362 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1363 February 2000. 1365 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 1366 RFC 2923, September 2000. 1368 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 1369 Addresses", RFC 3307, August 2002. 1371 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 1372 Listener Discovery (MLD) Protocol", RFC 3590, 1373 September 2003. 1375 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1376 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1378 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 1379 Reserved for Documentation", RFC 3849, July 2004. 1381 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1382 December 2005. 1384 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 1385 Errors at High Data Rates", RFC 4963, July 2007. 1387 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 1388 Reserved for Documentation", RFC 5737, January 2010. 1390 Authors' Addresses 1392 Xing Li 1393 CERNET Center/Tsinghua University 1394 Room 225, Main Building, Tsinghua University 1395 Beijing, 100084 1396 China 1398 Phone: +86 10-62785983 1399 Email: xing@cernet.edu.cn 1401 Congxiao Bao 1402 CERNET Center/Tsinghua University 1403 Room 225, Main Building, Tsinghua University 1404 Beijing, 100084 1405 China 1407 Phone: +86 10-62785983 1408 Email: congxiao@cernet.edu.cn 1410 Fred Baker 1411 Cisco Systems 1412 Santa Barbara, California 93117 1413 USA 1415 Phone: +1-408-526-4257 1416 Email: fred@cisco.com