idnits 2.17.1 draft-ietf-behave-v6v4-xlate-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (March 30, 2010) is 5138 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-06 == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-10 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** 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 1, 2010 Cisco Systems 7 March 30, 2010 9 IP/ICMP Translation Algorithm 10 draft-ietf-behave-v6v4-xlate-14 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 to IETF 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), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 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 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on October 1, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 4 72 1.1. IPv4-IPv6 Translation Model . . . . . . . . . . . . . . . 4 73 1.2. Applicability and Limitations . . . . . . . . . . . . . . 4 74 1.3. Stateless vs. Stateful Mode . . . . . . . . . . . . . . . 5 75 1.4. Path MTU Discovery and Fragmentation . . . . . . . . . . . 6 76 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 3. Translating from IPv4 to IPv6 . . . . . . . . . . . . . . . . 6 78 3.1. Translating IPv4 Headers into IPv6 Headers . . . . . . . . 8 79 3.2. Translating ICMPv4 Headers into ICMPv6 Headers . . . . . . 10 80 3.3. Translating ICMPv4 Error Messages into ICMPv6 . . . . . . 14 81 3.4. Translator Sending ICMPv4 Error Message . . . . . . . . . 14 82 3.5. Transport-layer Header Translation . . . . . . . . . . . . 15 83 3.6. Knowing When to Translate . . . . . . . . . . . . . . . . 15 84 4. Translating from IPv6 to IPv4 . . . . . . . . . . . . . . . . 15 85 4.1. Translating IPv6 Headers into IPv4 Headers . . . . . . . . 18 86 4.2. Translating ICMPv6 Headers into ICMPv4 Headers . . . . . . 20 87 4.3. Translating ICMPv6 Error Messages into ICMPv4 . . . . . . 23 88 4.4. Translator Sending ICMPv6 Error Message . . . . . . . . . 24 89 4.5. Transport-layer Header Translation . . . . . . . . . . . . 24 90 4.6. Knowing When to Translate . . . . . . . . . . . . . . . . 24 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 94 8. Appendix: Stateless translation workflow example . . . . . . . 25 95 8.1. H6 establishes communication with H4 . . . . . . . . . . . 26 96 8.2. H4 establishes communication with H6 . . . . . . . . . . . 27 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 98 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 99 9.2. Informative References . . . . . . . . . . . . . . . . . . 30 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 102 1. Introduction and Motivation 104 This document is a product of the 2008-2010 effort to define a 105 replacement for NAT-PT [RFC2766]. It is directly derivative from 106 Erik Nordmark's "Stateless IP/ICMP Translation Algorithm (SIIT)" 107 [RFC2765], which provides stateless translation between IPv4 108 [RFC0791] and IPv6 [RFC2460], and between ICMPv4 [RFC0792] and ICMPv6 109 [RFC4443]. 111 Readers of this document are expected to have read and understood the 112 framework described in [I-D.ietf-behave-v6v4-framework]. 113 Implementations of this IPv4/IPv6 translation specification MUST also 114 support the address translation algorithms in 115 [I-D.ietf-behave-address-format]. Implementations MAY also support 116 stateful translation [I-D.ietf-behave-v6v4-xlate-stateful]. 118 1.1. IPv4-IPv6 Translation Model 120 The translation model consists of two or more network domains 121 connected by one or more IP/ICMP translators (XLATs) as shown in 122 Figure 1. 124 --------- --------- 125 // \\ // \\ 126 / +----+ \ 127 | |XLAT| | XLAT: IPv6/IPv4 128 | IPv4 +----+ IPv6 | Translator 129 | Domain | | Domain | 130 | | | | 131 \ | | / 132 \\ // \\ // 133 -------- --------- 135 Figure 1: IPv4-IPv6 Translation Model 137 The scenarios of the translation model are discussed in 138 [I-D.ietf-behave-v6v4-framework]. 140 1.2. Applicability and Limitations 142 This document specifies the translation algorithms between IPv4 143 packets and IPv6 packets. 145 As with [RFC2765], the translating function specified in this 146 document does not translate any IPv4 options and it does not 147 translate IPv6 extension headers except fragmentation header. 149 The issues and algorithms in the translation of datagrams containing 150 TCP segments are described in [RFC5382]. 152 Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e., 153 the UDP checksum field is zero) are not of significant use in the 154 Internet and will not be translated by the IP/ICMP translator. 156 Fragmented ICMP/ICMPv6 packets will not be translated by the IP/ICMP 157 translator. 159 The IP/ICMP header translation specified in this document is 160 consistent with requirements of multicast IP/ICMP headers. However 161 IPv4 multicast addresses [RFC5771] cannot be mapped to IPv6 multicast 162 addresses [RFC3307] based on the unicast mapping rule 163 [I-D.ietf-behave-address-format]. 165 Translator SHOULD make sure that the packets belonging to the same 166 flow leave the translator in the same order in which they arrived. 168 1.3. Stateless vs. Stateful Mode 170 An IP/ICMP translator has two possible modes of operation: stateless 171 and stateful [I-D.ietf-behave-v6v4-framework]. In both cases, we 172 assume that a system (a node or an application) that has an IPv4 173 address but not an IPv6 address is communicating with a system that 174 has an IPv6 address but no IPv4 address, or that the two systems do 175 not have contiguous routing connectivity and hence are forced to have 176 their communications translated. 178 In the stateless mode, a specific IPv6 address range will represent 179 IPv4 systems (IPv4-converted addresses), and the IPv6 systems have 180 addresses (IPv4-translatable addresses) that can be algorithmically 181 mapped to a subset of the service provider's IPv4 addresses. Note 182 that IPv4-translatable addresses is a subset of IPv4-converted 183 addresses. In general, there is no need to concern oneself with 184 translation tables, as the IPv4 and IPv6 counterparts are 185 algorithmically related. 187 In the stateful mode, a specific IPv6 address range will represent 188 IPv4 systems (IPv4-converted addresses), but the IPv6 systems may use 189 any IPv6 addresses [RFC4291] except in that range. In this case, a 190 translation table is required to bind the IPv6 systems' addresses to 191 the IPv4 addresses maintained in the translator. 193 The address translation mechanisms for the stateless and the stateful 194 translations are defined in [I-D.ietf-behave-address-format]. 196 1.4. Path MTU Discovery and Fragmentation 198 Due to the different sizes of the IPv4 and IPv6 header, which are 20+ 199 octets and 40 octets respectively, handling the maximum packet size 200 is critical for the operation of the IPv4/IPv6 translator. There are 201 three mechanisms to handle this issue: path MTU discovery (PMTUD), 202 fragmentation, and transport-layer negotiation such as the TCP MSS 203 option [RFC0879]. Note that the translator MUST behave as a router, 204 i.e. the translator MUST send a "Packet Too Big" error message or 205 fragment the packet when the packet size exceeds the MTU of the next 206 hop interface. 208 "Don't Fragment", ICMP "Packet Too Big", and packet fragmentation are 209 discussed in sections 3 and 4 of this document. The reassembling of 210 fragmented packets in the stateful translator is discussed in 211 [I-D.ietf-behave-v6v4-xlate-stateful], since it requires state 212 maintenance in the translator. 214 2. Conventions 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 218 document are to be interpreted as described in [RFC2119]. 220 3. Translating from IPv4 to IPv6 222 When an IP/ICMP translator receives an IPv4 datagram addressed to a 223 destination towards the IPv6 domain, it translates the IPv4 header of 224 that packet into an IPv6 header. The original IPv4 header on the 225 packet is removed and replaced by an IPv6 header. Since the ICMPv6 226 [RFC4443], TCP [RFC0793], UDP [RFC0768] and DCCP [RFC4340] headers 227 contain checksums that cover IP header information, if the address 228 mapping algorithm is not checksum-neutral, the checksum MUST be 229 evaluated before translation and the ICMPv6 and transport-layer 230 headers MUST be updated. The data portion of the packet is left 231 unchanged. The IP/ICMP translator then forwards the packet based on 232 the IPv6 destination address. 234 +-------------+ +-------------+ 235 | IPv4 | | IPv6 | 236 | Header | | Header | 237 +-------------+ +-------------+ 238 | Transport | | Fragment | 239 | Layer | ===> | Header | 240 | Header | | (if needed) | 241 +-------------+ +-------------+ 242 | | | Transport | 243 ~ Data ~ | Layer | 244 | | | Header | 245 +-------------+ +-------------+ 246 | | 247 ~ Data ~ 248 | | 249 +-------------+ 251 Figure 2: IPv4-to-IPv6 Translation 253 Path MTU discovery is mandatory in IPv6 but it is optional in IPv4. 254 IPv6 routers never fragment a packet - only the sender can do 255 fragmentation. 257 When an IPv4 node performs path MTU discovery (by setting the Don't 258 Fragment (DF) bit in the header), path MTU discovery can operate end- 259 to-end, i.e., across the translator. In this case either IPv4 or 260 IPv6 routers (including the translator) might send back ICMP "Packet 261 Too Big" messages to the sender. When the IPv6 routers send these 262 ICMPv6 errors they will pass through a translator that will translate 263 the ICMPv6 error to a form that the IPv4 sender can understand. As a 264 result, an IPv6 fragment header is only included if the IPv4 packet 265 is already fragmented. 267 However, when the IPv4 sender does not set the Don't Fragment (DF) 268 bit, the translator MUST ensure that the packet does not exceed the 269 path MTU on the IPv6 side. This is done by fragmenting the IPv4 270 packet so that it fits in 1280-byte IPv6 packets, since that is the 271 minimum IPv6 MTU. Also, when the IPv4 sender does not set the DF bit 272 the translator MUST always include an IPv6 fragment header to 273 indicate that the sender allows fragmentation. 275 The rules in section 3.1 ensure that when packets are fragmented, 276 either by the sender or by IPv4 routers, the low-order 16 bits of the 277 fragment identification are carried end-to-end, ensuring that packets 278 are correctly reassembled. In addition, the rules in section 3.1 use 279 the presence of an IPv6 fragment header to indicate that the sender 280 might not be using path MTU discovery (i.e., the packet should not 281 have the DF flag set should it later be translated back to IPv4). 283 Other than the special rules for handling fragments and path MTU 284 discovery, the actual translation of the packet header consists of a 285 simple translation as defined below. Note that ICMPv4 packets 286 require special handling in order to translate the content of ICMPv4 287 error messages and also to add the ICMPv6 pseudo-header checksum. 289 3.1. Translating IPv4 Headers into IPv6 Headers 291 If the DF flag is not set and the IPv4 packet will result in an IPv6 292 packet larger than 1280 bytes, the packet MUST be fragmented so the 293 resulting IPv6 packet (with Fragment header added to each fragment) 294 will be less than or equal to 1280 bytes. For example, if the packet 295 is fragmented prior to the translation, the IPv4 packets must be 296 fragmented so that their length, excluding the IPv4 header, is at 297 most 1232 bytes (1280 minus 40 for the IPv6 header and 8 for the 298 Fragment header). The resulting fragments are then translated 299 independently using the logic described below. 301 If the DF bit is set and the MTU of the next-hop interface is less 302 than the total length value of the IPv4 packet plus 20, the 303 translator MUST send an ICMPv4 "Fragmentation Needed" error message 304 to the IPv4 source address. 306 If the DF bit is set and the packet is not a fragment (i.e., the MF 307 flag is not set and the Fragment Offset is equal to zero) then the 308 translator SHOULD NOT add a Fragment header to the resulting packet. 309 The IPv6 header fields are set as follows: 311 Version: 6 313 Traffic Class: By default, copied from IP Type Of Service (TOS) 314 octet. According to [RFC2474] the semantics of the bits are 315 identical in IPv4 and IPv6. However, in some IPv4 environments 316 these fields might be used with the old semantics of "Type Of 317 Service and Precedence". An implementation of a translator SHOULD 318 support an administratively-configurable option to ignore the IPv4 319 TOS and always set the IPv6 traffic class (TC) to zero. In 320 addition, if the translator is at an administrative boundary, the 321 filtering and update considerations of [RFC2475] may be 322 applicable. 324 Flow Label: 0 (all zero bits) 326 Payload Length: Total length value from IPv4 header, minus the size 327 of the IPv4 header and IPv4 options, if present. 329 Next Header: For ICMPv4 (1) changed to ICMPv6 (58), otherwise 330 protocol field MUST be copied from IPv4 header. 332 Hop Limit: The hop limit is derived from the TTL value in the IPv4 333 header. Since the translator is a router, as part of forwarding 334 the packet it needs to decrement either the IPv4 TTL (before the 335 translation) or the IPv6 Hop Limit (after the translation). As 336 part of decrementing the TTL or Hop Limit the translator (as any 337 router) MUST check for zero and send the ICMPv4 "TTL Exceeded" or 338 ICMPv6 "Hop Limit Exceeded" error. 340 Source Address: The IPv4-converted address derived from the IPv4 341 source address per [I-D.ietf-behave-address-format] section 2.1. 343 If the translator gets an illegal source address (e.g. 0.0.0.0, 344 127.0.0.1, etc.), the translator SHOULD silently drop the packet 345 (as discussed in Section 5.3.7 of [RFC1812]). 347 Destination Address: In the stateless mode, which is to say that if 348 the IPv4 destination address is within a range of configured IPv4 349 stateless translation prefix, the IPv6 destination address is the 350 IPv4-translatable address derived from the IPv4 destination 351 address per [I-D.ietf-behave-address-format] section 2.1. A 352 workflow example of stateless translation is shown in the Appendix 353 of this document. 355 In the stateful mode, which is to say that if the IPv4 destination 356 address is not within the range of any configured IPv4 stateless 357 translation prefix, the IPv6 destination address and corresponding 358 transport-layer destination port are derived from the Binding 359 Information Bases (BIBs) reflecting current session state in the 360 translator as described in [I-D.ietf-behave-v6v4-xlate-stateful]. 362 If any IPv4 options are present in the IPv4 packet, the IPv4 options 363 MUST be ignored and the packet translated normally; there is no 364 attempt to translate the options. However, if an unexpired source 365 route option is present then the packet MUST instead be discarded, 366 and an ICMPv4 "Destination Unreachable/Source Route Failed" (Type 367 3/Code 5) error message SHOULD be returned to the sender. 369 If there is a need to add a Fragment header (the DF bit is not set or 370 the packet is a fragment) the header fields are set as above with the 371 following exceptions: 373 IPv6 fields: 375 Payload Length: Total length value from IPv4 header, plus 8 for 376 the fragment header, minus the size of the IPv4 header and IPv4 377 options, if present. 379 Next Header: Fragment header (44). 381 Fragment header fields: 383 Next Header: For ICMPv4 (1) changed to ICMPv6 (58), otherwise 384 protocol field MUST be copied from IPv4 header. 386 Fragment Offset: Fragment Offset copied from the IPv4 header. 388 M flag: More Fragments bit copied from the IPv4 header. 390 Identification: The low-order 16 bits copied from the 391 Identification field in the IPv4 header. The high-order 16 392 bits set to zero. 394 3.2. Translating ICMPv4 Headers into ICMPv6 Headers 396 All ICMPv4 messages that are to be translated require that the ICMPv6 397 checksum field be calculated as part of the translation since ICMPv6, 398 unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP. 400 In addition, all ICMPv4 packets MUST have the Type value translated 401 and, for ICMPv4 error messages, the included IP header also MUST be 402 translated. 404 The actions needed to translate various ICMPv4 messages are as 405 follows: 407 ICMPv4 query messages: 409 Echo and Echo Reply (Type 8 and Type 0): Adjust the Type values 410 to 128 and 129, respectively, and adjust the ICMP checksum both 411 to take the type change into account and to include the ICMPv6 412 pseudo-header. 414 Information Request/Reply (Type 15 and Type 16): Obsoleted in 415 ICMPv6. Silently drop. 417 Timestamp and Timestamp Reply (Type 13 and Type 14): Obsoleted in 418 ICMPv6. Silently drop. 420 Address Mask Request/Reply (Type 17 and Type 18): Obsoleted in 421 ICMPv6. Silently drop. 423 ICMP Router Advertisement (Type 9): Single hop message. Silently 424 drop. 426 ICMP Router Solicitation (Type 10): Single hop message. Silently 427 drop. 429 Unknown ICMPv4 types: Silently drop. 431 IGMP messages: While the MLD messages [RFC2710][RFC3590][RFC3810] 432 are the logical IPv6 counterparts for the IPv4 IGMP messages 433 all the "normal" IGMP messages are single-hop messages and 434 SHOULD be silently dropped by the translator. Other IGMP 435 messages might be used by multicast routing protocols and, 436 since it would be a configuration error to try to have router 437 adjacencies across IP/ICMP translators those packets SHOULD 438 also be silently dropped. 440 ICMPv4 error messages: 442 Destination Unreachable (Type 3): Translate the Code field as 443 described below, set the Type field to 1, and adjust the 444 ICMP checksum both to take the code and type change into 445 account and to include the ICMPv6 pseudo-header. 447 Translate the Code field as follows: 449 Code 0, 1 (Net, host unreachable): Set Code value to 0 (no 450 route to destination). 452 Code 2 (Protocol unreachable): Translate to an ICMPv6 453 Parameter Problem (Type 4, Code value 1) and make the 454 Pointer point to the IPv6 Next Header field. 456 Code 3 (Port unreachable): Set Code value to 4 (port 457 unreachable). 459 Code 4 (Fragmentation needed and DF set): Translate to an 460 ICMPv6 Packet Too Big message (Type 2) with Code value 461 set to 0. The MTU field MUST be adjusted for the 462 difference between the IPv4 and IPv6 header sizes, i.e. 463 minimum(advertised MTU+20, MTU_of_IPv6_nexthop, 464 (MTU_of_IPv4_nexthop)+20). Note that if the IPv4 router 465 set the MTU field to zero, i.e., the router does not 466 implement [RFC1191], then the translator MUST use the 467 plateau values specified in [RFC1191] to determine a 468 likely path MTU and include that path MTU in the ICMPv6 469 packet. (Use the greatest plateau value that is less 470 than the returned Total Length field.) 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 change into 511 account and to include the ICMPv6 pseudo-header. Translate 512 the Code field as follows: 514 Code 0 (Pointer indicates the error): Set the Code value to 515 0 (Erroneous header field encountered) and update the 516 pointer as defined in Figure 3 (If the Original IPv4 517 Pointer Value is not listed or the Translated IPv6 518 Pointer Value is listed as "n/a", silently drop the 519 packet). 521 Code 1 (Missing a required option): Silently drop 523 Code 2 (Bad length): Set the Code value to 0 (Erroneous 524 header field encountered) and update the pointer as 525 defined in Figure 3 (If the Original IPv4 Pointer Value 526 is not listed or the Translated IPv6 Pointer Value is 527 listed as "n/a", silently drop the packet). 529 Other Code values: Silently drop 531 Unknown ICMPv4 types: Silently drop. 533 | Original IPv4 Pointer Value | Translated IPv6 Pointer Value | 534 +--------------------------------+--------------------------------+ 535 | 0 | Version/IHL | 0 | Version/Traffic Class | 536 | 1 | Type Of Service | 1 | Traffic Class/Flow Label | 537 | 2,3 | Total Length | 4 | Payload Length | 538 | 4,5 | Identification | n/a | | 539 | 6 | Flags/Fragment Offset | n/a | | 540 | 7 | Fragment Offset | n/a | | 541 | 8 | Time to Live | 7 | Hop Limit | 542 | 9 | Protocol | 6 | Next Header | 543 |10,11| Header Checksum | n/a | | 544 |12-15| Source Address | 8 | Source Address | 545 |16-19| Destination Address | 24 | Destination Address | 546 +--------------------------------+--------------------------------+ 548 Figure 3: Pointer value for translating from IPv4 to IPv6 550 ICMP Error Payload: If the received ICMPv4 packet contains an 551 ICMPv4 Extension [RFC4884], the translation of the ICMPv4 552 packet will cause the ICMPv6 packet to change length. When 553 this occurs, the ICMPv6 Extension length attribute MUST be 554 adjusted accordingly (e.g., longer due to the translation 555 from IPv4 to IPv6). If the ICMPv4 Extension exceeds the 556 maximum size of an ICMPv6 message on the outgoing interface, 557 the ICMPv4 extension SHOULD be simply truncated. For 558 extensions not defined in [RFC4884], the translator passes 559 the extensions as opaque bit strings and those containing 560 IPv4 address literals will not have those addresses 561 translated to IPv6 address literals; this may cause problems 562 with processing of those ICMP extensions. 564 3.3. Translating ICMPv4 Error Messages into ICMPv6 566 There are some differences between the ICMPv4 and the ICMPv6 error 567 message formats as detailed above. In addition, the ICMP error 568 messages contain the packet in error, which MUST be translated just 569 like a normal IP packet. If the translation of this "packet in 570 error" changes the length of the datagram, the Total Length field in 571 the outer IPv6 header MUST be updated. 573 +-------------+ +-------------+ 574 | IPv4 | | IPv6 | 575 | Header | | Header | 576 +-------------+ +-------------+ 577 | ICMPv4 | | ICMPv6 | 578 | Header | | Header | 579 +-------------+ +-------------+ 580 | IPv4 | ===> | IPv6 | 581 | Header | | Header | 582 +-------------+ +-------------+ 583 | Partial | | Partial | 584 | Transport | | Transport | 585 | Layer | | Layer | 586 | Header | | Header | 587 +-------------+ +-------------+ 589 Figure 4: IPv4-to-IPv6 ICMP Error Translation 591 The translation of the inner IP header can be done by invoking the 592 function that translated the outer IP headers. This process MUST 593 stop at the first embedded header and drop the packet if it contains 594 more. 596 3.4. Translator Sending ICMPv4 Error Message 598 If the IPv4 packet is discarded, then the translator SHOULD be able 599 to send back an ICMPv4 error message to the original sender of the 600 packet, unless the discarded packet is itself an ICMPv4 message. The 601 ICMPv4 message, if sent, has a Type value of 3 (Destination 602 Unreachable) and a Code value of 13 (Communication Administratively 603 Prohibited), unless otherwise specified in this document or in 604 [I-D.ietf-behave-v6v4-xlate-stateful]. The translator SHOULD allow 605 an administrator to configure whether the ICMPv4 error messages are 606 sent, rate-limited, or not sent. 608 3.5. Transport-layer Header Translation 610 If the address translation algorithm is not checksum neutral, the 611 recalculation and updating of the transport-layer headers which 612 contain pseudo headers (e.g. of TCP, UDP and DCCP) MUST be performed. 614 When a translator receives an unfragmented UDP IPv4 packet and the 615 checksum field is zero, the translator SHOULD compute the missing UDP 616 checksum as part of translating the packet. Also, the translator 617 SHOULD maintain a counter of how many UDP checksums are generated in 618 this manner. 620 When a stateless translator receives the first fragment of a 621 fragmented UDP IPv4 packet and the checksum field is zero, the 622 translator SHOULD drop the packet and generate a system management 623 event specifying at least the IP addresses and port numbers in the 624 packet. When it receives fragments other than the first, it SHOULD 625 silently drop the packet, since there is no port information to log. 627 For stateful translator, the handling of fragmented UDP IPv4 packets 628 with a zero checksum is discussed in 629 [I-D.ietf-behave-v6v4-xlate-stateful] section 3.1. 631 3.6. Knowing When to Translate 633 If the IP/ICMP translator also provides normal forwarding function, 634 and the destination IPv4 address is reachable by a more specific 635 route without translation, the translator MUST forward it without 636 translating it. Otherwise, when an IP/ICMP translator receives an 637 IPv4 datagram addressed to an IPv4 destination representing a host in 638 the IPv6 domain, the packet MUST be translated to IPv6. 640 4. Translating from IPv6 to IPv4 642 When an IP/ICMP translator receives an IPv6 datagram addressed to a 643 destination towards the IPv4 domain, it translates the IPv6 header of 644 the received IPv6 packet into an IPv4 header. The original IPv6 645 header on the packet is removed and replaced by an IPv4 header. 646 Since the ICMPv6 [RFC4443], TCP [RFC0793], UDP [RFC0768] and DCCP 647 [RFC4340] headers contain checksums that cover the IP header, if the 648 address mapping algorithm is not checksum-neutral, the checksum MUST 649 be evaluated before translation and the ICMP and transport-layer 650 headers MUST be updated. The data portion of the packet is left 651 unchanged. The IP/ICMP translator then forwards the packet based on 652 the IPv4 destination address. 654 +-------------+ +-------------+ 655 | IPv6 | | IPv4 | 656 | Header | | Header | 657 +-------------+ +-------------+ 658 | Fragment | | Transport | 659 | Header | ===> | Layer | 660 |(if present) | | Header | 661 +-------------+ +-------------+ 662 | Transport | | | 663 | Layer | ~ Data ~ 664 | Header | | | 665 +-------------+ +-------------+ 666 | | 667 ~ Data ~ 668 | | 669 +-------------+ 671 Figure 5: IPv6-to-IPv4 Translation 673 There are some differences between IPv6 and IPv4 in the area of 674 fragmentation and the minimum link MTU that affect the translation. 675 An IPv6 link has to have an MTU of 1280 bytes or greater. The 676 corresponding limit for IPv4 is 68 bytes. Thus, unless there were 677 special measures, it would not be possible to do end-to-end path MTU 678 discovery when the path includes a translator, since the IPv6 node 679 might receive ICMPv6 "Packet Too Big" messages originated by an IPv4 680 router that report an MTU less than 1280. However, [RFC2460] section 681 5 requires that IPv6 nodes handle such an ICMPv6 "Packet Too Big" 682 message by reducing the path MTU to 1280 and including an IPv6 683 fragment header with each packet. In this case, the translator 684 SHOULD set DF to 0 and take the identification value from the IPv6 685 fragment header when a fragmentation header with (MF=0; Offset=0) is 686 present or set DF to 1 otherwise. This allows end-to-end path MTU 687 discovery across the translator as long as the path MTU is 1280 bytes 688 or greater. When the path MTU drops below the 1280 limit, the IPv6 689 sender will originate 1280-byte packets that will be fragmented by 690 IPv4 routers along the path after being translated to IPv4. 692 The drawback with this scheme is that it is not possible to use PMTU 693 discovery to do optimal UDP fragmentation (as opposed to completely 694 avoiding fragmentation) at the sender, since the presence of an IPv6 695 Fragment header is interpreted that it is okay to fragment the packet 696 on the IPv4 side. Thus if a UDP application wants to send large 697 packets independent of the PMTU, the sender will only be able to 698 determine the path MTU on the IPv6 side of the translator. If the 699 path MTU on the IPv4 side of the translator is smaller, then the IPv6 700 sender will not receive any ICMPv6 "Too Big" errors and cannot adjust 701 the size fragments it is sending. 703 On the other hand, a recent study indicates that only 43.46% of IPv6- 704 capable web servers include an IPv6 fragmentation header in their 705 respond packets after they were sent an ICMPv6 "Packet Too Big" 706 message specifying an MTU<1280 bytes. A workaround to this problem 707 (ICMPv6 "Packet Too Big" message with MTU<1280) is that if there is 708 no fragmentation header in the IPv6 packet, the translator SHOULD set 709 DF to 0 for the packets equal to or smaller than 1280 bytes and set 710 DF to 1 for packets larger than 1280 bytes. In addition, the 711 translator SHOULD take the identification value from the IPv6 712 fragmentation header if present or generate the identification value 713 otherwise. This avoids the introduction of the path MTU discovery 714 black hole. The header translation defined in the next section uses 715 this method. Note that translator generating the IPv4 identification 716 value is tricky in stateless mode. The Internet Protocol standard 717 [RFC0791] specifies: 719 "The choice of the Identifier for a datagram is based on the need 720 to provide a way to uniquely identify the fragments of a 721 particular datagram. The protocol module assembling fragments 722 judges fragments to belong to the same datagram if they have the 723 same source, destination, protocol, and Identifier. Thus, the 724 sender must choose the Identifier to be unique for this source, 725 destination pair and protocol for the time the datagram (or any 726 fragment of it) could be alive in the Internet." 728 Therefore, the translator may require states per three tuple IPv4 729 identification field. However, this does not prevent the deployment 730 of the stateless translator, since as discussed in 731 [I-D.ietf-behave-v6v4-framework], the stateless translation can be 732 used in scenarios 1, 2, 5 and 6. All of these scenarios involve "An 733 IPv6 network" which are managed networks and network firewall, host 734 firewall or host misbehavior can be controlled. In such a controlled 735 environment, it can be assured that hosts and firewalls properly 736 process ICMPv6 messages as described in Section 5 of [RFC2460]. 738 The translator does not translate IPv6 routing headers, hop-by-hop 739 extension headers, destination options headers, source routing 740 headers, authentication header (AH) and encapsulating security 741 payload (ESP) headers. However, the translator needs to traverse the 742 IPv6 next header chain and copy the next header value (ESP, transport 743 protocol or undefined next header value) in the last known next 744 header to the protocol field in IPv4 header. This implies that the 745 translator MUST forward ESP or unknown protocols to avoid black 746 holing. Some protocols are known to fail when translated (e.g., 747 IPsec AH) and will fail at the receiver. 749 Other than the special rules for handling fragments and path MTU 750 discovery, the actual translation of the packet header consists of a 751 simple translation as defined below. Note that ICMPv6 packets 752 require special handling in order to translate the contents of ICMPv6 753 error messages and also to remove the ICMPv6 pseudo-header checksum. 755 4.1. Translating IPv6 Headers into IPv4 Headers 757 If there is no IPv6 Fragment header, the IPv4 header fields are set 758 as follows: 760 Version: 4 762 Internet Header Length: 5 (no IPv4 options) 764 Type of Service (TOS) Octet: By default, copied from the IPv6 765 Traffic Class (all 8 bits). According to [RFC2474] the semantics 766 of the bits are identical in IPv4 and IPv6. However, in some IPv4 767 environments, these bits might be used with the old semantics of 768 "Type Of Service and Precedence". An implementation of a 769 translator SHOULD provide the ability to ignore the IPv6 traffic 770 class and always set the IPv4 TOS Octet to a specified value. In 771 addition, if the translator is at an administrative boundary, the 772 filtering and update considerations of [RFC2475] may be 773 applicable. 775 Total Length: Payload length value from IPv6 header, plus the size 776 of the IPv4 header. 778 Identification: If the packet size is equal to or smaller than 1280 779 bytes and greater than 88 bytes, generate the identification 780 value. If the packet size is greater than 1280 bytes or smaller 781 than 88 bytes, set the Identification field to all zeros 783 Flags: The More Fragments (MF) flag is set to zero. If the packet 784 size is equal to or smaller than 1280 bytes and greater than 88 785 bytes, the Don't Fragments (DF) flag is set to zero. If the 786 packet size is greater than 1280 bytes or smaller than 88 bytes, 787 the Don't Fragments (DF) flag is set to one. 789 Fragment Offset: All zeros. 791 Time to Live: Time to Live is derived from Hop Limit value in IPv6 792 header. Since the translator is a router, as part of forwarding 793 the packet it needs to decrement either the IPv6 Hop Limit (before 794 the translation) or the IPv4 TTL (after the translation). As part 795 of decrementing the TTL or Hop Limit the translator (as any 796 router) MUST check for zero and send the ICMPv4 "TTL Exceeded" or 797 ICMPv6 "Hop Limit Exceeded" error. 799 Protocol: For ICMPv6 (58) changed to ICMPv4 (1), otherwise skip 800 extension headers, copy the Next Header field (ESP, transport 801 protocol or undefined next header value) in the last known next 802 header. 804 Header Checksum: Computed once the IPv4 header has been created. 806 Source Address: In the stateless mode, which is to say that if the 807 IPv6 source address is within the range of a configured IPv6 808 translation prefix, the IPv4 source address is derived from the 809 IPv6 source address per [I-D.ietf-behave-address-format] section 810 2.1. Note that the original IPv6 source address is an IPv4- 811 translatable address. A workflow example of stateless translation 812 is shown in Appendix of this document. If the translator only 813 supports stateless mode and if the IPv6 source address is not 814 within the range of configured IPv6 prefix(es), the translator 815 SHOULD drop the packet and respond with an ICMPv6 Type=1, Code=5 816 (Destination Unreachable, Source address failed ingress/egress 817 policy). 819 In the stateful mode, which is to say that if the IPv6 source 820 address is not within the range of any configured IPv6 stateless 821 translation prefix, the IPv4 source address and transport-layer 822 source port corresponding to the IPv4-related IPv6 source address 823 and source port are derived from the Binding Information Bases 824 (BIBs) as described in [I-D.ietf-behave-v6v4-xlate-stateful]. 826 In stateless and stateful modes, if the translator gets an illegal 827 source address (e.g. ::1, etc.), the translator SHOULD silently 828 drop the packet. 830 Destination Address: The IPv4 destination address is derived from 831 the IPv6 destination address of the datagram being translated per 832 [I-D.ietf-behave-address-format] section 2.1. Note that the 833 original IPv6 destination address is an IPv4-converted address. 835 If any of an IPv6 Hop-by-Hop Options header, Destination Options 836 header, or Routing header with the Segments Left field equal to zero 837 are present in the IPv6 packet, those IPv6 extension headers MUST be 838 ignored (i.e., there is no attempt to translate the extension 839 headers) and the packet translated normally. However, the Total 840 Length field and the Protocol field are adjusted to "skip" these 841 extension headers. 843 If a Routing header with a non-zero Segments Left field is present 844 then the packet MUST NOT be translated, and an ICMPv6 "parameter 845 problem/erroneous header field encountered" (Type 4/Code 0) error 846 message, with the Pointer field indicating the first byte of the 847 Segments Left field, SHOULD be returned to the sender. 849 If the IPv6 packet contains a Fragment header, the header fields are 850 set as above with the following exceptions: 852 Total Length: Payload length value from IPv6 header, minus 8 for the 853 Fragment header, plus the size of the IPv4 header. 855 Identification: Copied from the low-order 16-bits in the 856 Identification field in the Fragment header. 858 Flags: The More Fragments (MF) flag is copied from the M flag in the 859 Fragment header. The Don't Fragments (DF) flag is set to zero 860 allowing this packet to be fragmented if required by IPv4 routers. 862 Fragment Offset: Copied from the Fragment Offset field in the 863 Fragment header. 865 Protocol: For ICMPv6 (58) changed to ICMPv4 (1), otherwise skip 866 extension headers, Next Header field copied from the last IPv6 867 header. 869 If a translated packet with DF set to 1 will be larger than the MTU 870 of the next-hop interface, then the translator MUST drop the packet 871 and send the ICMPv6 "Packet Too Big" (Type 2/Code 0) error message to 872 the IPv6 host with an adjusted MTU in the ICMPv6 message. 874 4.2. Translating ICMPv6 Headers into ICMPv4 Headers 876 All ICMPv6 messages that are to be translated require that the ICMPv4 877 checksum field be updated as part of the translation since ICMPv6 878 (unlike ICMPv4) includes a pseudo-header in the checksum just like 879 UDP and TCP. 881 In addition all ICMP packets MUST have the Type value translated and, 882 for ICMP error messages, the included IP header also MUST be 883 translated. Note that the IPv6 addresses in the IPv6 header may not 884 be IPv4-translatable addresses and there will be no corresponding 885 IPv4 addresses representing this IPv6 address. In this case, the 886 translator can do stateful translation. A mechanism by which the 887 translator can instead do stateless translation is left for future 888 work. 890 The actions needed to translate various ICMPv6 messages are: 892 ICMPv6 informational messages: 894 Echo Request and Echo Reply (Type 128 and 129): Adjust the Type 895 values to 8 and 0, respectively, and adjust the ICMP checksum 896 both to take the type change into account and to exclude the 897 ICMPv6 pseudo-header. 899 MLD Multicast Listener Query/Report/Done (Type 130, 131, 132): 900 Single hop message. Silently drop. 902 Neighbor Discover messages (Type 133 through 137): Single hop 903 message. Silently drop. 905 Unknown informational messages: Silently drop. 907 ICMPv6 error messages: 909 Destination Unreachable (Type 1) Set the Type field to 3, and 910 adjust the ICMP checksum both to take the type change into 911 account and to exclude the ICMPv6 pseudo-header. 913 Translate the Code field as follows: 915 Code 0 (no route to destination): Set Code value to 1 (Host 916 unreachable). 918 Code 1 (Communication with destination administratively 919 prohibited): Set Code value to 10 (Communication with 920 destination host administratively prohibited). 922 Code 2 (Beyond scope of source address): Set Code value to 1 923 (Host unreachable). Note that this error is very unlikely 924 since an IPv4-translatable source address is typically 925 considered to have global scope. 927 Code 3 (Address unreachable): Set Code value to 1 (Host 928 unreachable). 930 Code 4 (Port unreachable): Set Code value to 3 (Port 931 unreachable). 933 Other Code values: Silently drop. 935 Packet Too Big (Type 2): Translate to an ICMPv4 Destination 936 Unreachable (Type 3) with Code value equal to 4, and adjust the 937 ICMPv4 checksum both to take the type change into account and 938 to exclude the ICMPv6 pseudo-header. The MTU field MUST be 939 adjusted for the difference between the IPv4 and IPv6 header 940 sizes taking into account whether or not the packet in error 941 includes a Fragment header, i.e. minimum(advertised MTU-20, 942 MTU_of_IPv4_nexthop, (MTU_of_IPv6_nexthop)-20) 944 Time Exceeded (Type 3): Set the Type value to 11, and adjust the 945 ICMPv4 checksum both to take the type change into account and 946 to exclude the ICMPv6 pseudo-header. The Code field is 947 unchanged. 949 Parameter Problem (Type 4): Translate the Type and Code field as 950 follows, and adjust the ICMPv4 checksum both to take the type 951 change into account and to exclude the ICMPv6 pseudo-header. 953 Code 0 (Erroneous header field encountered): Set Type 12, Code 954 0 and update the pointer as defined in Figure 6 (If the 955 Original IPv6 Pointer Value is not listed or the Translated 956 IPv4 Pointer Value is listed as "n/a", silently drop the 957 packet). 959 Code 1 (Unrecognized Next Header type encountered): Translate 960 this to an ICMPv4 protocol unreachable (Type 3, Code 2). 962 Code 2 (Unrecognized IPv6 option encountered): Silently drop. 964 Unknown error messages: Silently drop. 966 | Original IPv6 Pointer Value | Translated IPv4 Pointer Value | 967 +--------------------------------+--------------------------------+ 968 | 0 | Version/Traffic Class | 0 | Version/IHL, Type Of Ser | 969 | 1 | Traffic Class/Flow Label | 1 | Type Of Service | 970 | 2,3 | Flow Label | n/a | | 971 | 4,5 | Payload Length | 2 | Total Length | 972 | 6 | Next Header | 9 | Protocol | 973 | 7 | Hop Limit | 8 | Time to Live | 974 | 8-23| Source Address | 12 | Source Address | 975 |24-39| Destination Address | 16 | Destination Address | 976 +--------------------------------+--------------------------------+ 978 Figure 6: Pointer Value for translating from IPv6 to IPv4 980 ICMP Error Payload: If the received ICMPv6 packet contains an 981 ICMPv6 Extension [RFC4884], the translation of the ICMPv6 982 packet will cause the ICMPv4 packet to change length. When 983 this occurs, the ICMPv6 Extension length attribute MUST be 984 adjusted accordingly (e.g., shorter due to the translation from 985 IPv6 to IPv4). For extensions not defined in [RFC4884], the 986 translator passes the extensions as opaque bit strings and 987 those containing IPv6 address literals will not have those 988 addresses translated to IPv4 address literals; this may cause 989 problems with processing of those ICMP extensions. 991 4.3. Translating ICMPv6 Error Messages into ICMPv4 993 There are some differences between the ICMPv4 and the ICMPv6 error 994 message formats as detailed above. In addition, the ICMP error 995 messages contain the packet in error, which MUST be translated just 996 like a normal IP packet. The translation of this "packet in error" 997 is likely to change the length of the datagram thus the Total Length 998 field in the outer IPv4 header MUST be updated. 1000 +-------------+ +-------------+ 1001 | IPv6 | | IPv4 | 1002 | Header | | Header | 1003 +-------------+ +-------------+ 1004 | ICMPv6 | | ICMPv4 | 1005 | Header | | Header | 1006 +-------------+ +-------------+ 1007 | IPv6 | ===> | IPv4 | 1008 | Header | | Header | 1009 +-------------+ +-------------+ 1010 | Partial | | Partial | 1011 | Transport | | Transport | 1012 | Layer | | Layer | 1013 | Header | | Header | 1014 +-------------+ +-------------+ 1016 Figure 7: IPv6-to-IPv4 ICMP Error Translation 1018 The translation of the inner IP header can be done by invoking the 1019 function that translated the outer IP headers. This process MUST 1020 stop at first embedded header and drop the packet if it contains 1021 more. Note that the IPv6 addresses in the IPv6 header may not be 1022 IPv4-translatable addresses and there will be no corresponding IPv4 1023 addresses. In this case, the translator can do stateful translation. 1024 A mechanism by which the translator can instead do stateless 1025 translation is left for future work. 1027 4.4. Translator Sending ICMPv6 Error Message 1029 If the IPv6 packet is discarded, then the translator SHOULD be able 1030 to send back an ICMPv6 error message to the original sender of the 1031 packet, unless the discarded packet is itself an ICMPv6 message. 1033 If the ICMPv6 error message is being sent because the IPv6 source 1034 address is not an IPv4-translatable address and the translator is 1035 stateless, the ICMPv6 message, if sent, has a Type value 1 and Code 1036 value 5 (Source address failed ingress/egress policy). In other 1037 cases, the ICMPv6 message has a Type value of 1 (Destination 1038 Unreachable) and a Code value of 1 (Communication with destination 1039 administratively prohibited), unless otherwise specified in this 1040 document or [I-D.ietf-behave-v6v4-xlate-stateful]. The translator 1041 SHOULD allow an administrator to configure whether the ICMPv6 error 1042 messages are sent, rate-limited, or not sent. 1044 4.5. Transport-layer Header Translation 1046 If the address translation algorithm is not checksum neutral, the 1047 recalculation and updating of the known transport-layer headers which 1048 contain pseudo headers (e.g. of TCP, UDP and DCCP) MUST be performed. 1049 For ESP or undefined transport protocol, the translator MUST forward 1050 the packets to the destination without touching the transport-layer 1051 header. 1053 4.6. Knowing When to Translate 1055 If the IP/ICMP translator also provides a normal forwarding function, 1056 and the destination address is reachable by a more specific route 1057 without translation, the router MUST forward it without translating 1058 it. When an IP/ICMP translator receives an IPv6 datagram addressed 1059 to an IPv6 address representing a host in the IPv4 domain, the IPv6 1060 packet MUST be translated to IPv4. 1062 5. IANA Considerations 1064 This memo adds no new IANA considerations. 1066 Note to RFC Editor: This section will have served its purpose if it 1067 correctly tells IANA that no new assignments or registries are 1068 required, or if those assignments or registries are created during 1069 the RFC publication process. From the author's perspective, it may 1070 therefore be removed upon publication as an RFC at the RFC Editor's 1071 discretion. 1073 6. Security Considerations 1075 The use of stateless IP/ICMP translators does not introduce any new 1076 security issues beyond the security issues that are already present 1077 in the IPv4 and IPv6 protocols and in the routing protocols that are 1078 used to make the packets reach the translator. 1080 There are potential issues that might arise by deriving an IPv4 1081 address from an IPv6 address - particularly addresses like broadcast 1082 or loopback addresses and the non IPv4-translatable IPv6 addresses, 1083 etc. The [I-D.ietf-behave-address-format] addresses these issues. 1085 As the Authentication Header [RFC4302] is specified to include the 1086 IPv4 Identification field and the translating function is not able to 1087 always preserve the Identification field, it is not possible for an 1088 IPv6 endpoint to verify the AH on received packets that have been 1089 translated from IPv4 packets. Thus AH does not work through a 1090 translator. 1092 Packets with ESP can be translated since ESP does not depend on 1093 header fields prior to the ESP header. Note that ESP transport mode 1094 is easier to handle than ESP tunnel mode; in order to use ESP tunnel 1095 mode, the IPv6 node MUST be able to generate an inner IPv4 header 1096 when transmitting packets and remove such an IPv4 header when 1097 receiving packets. 1099 7. Acknowledgements 1101 This is under development by a large group of people. Those who have 1102 posted to the list during the discussion include Andrew Sullivan, 1103 Andrew Yourtchenko, Brian Carpenter, Dan Wing, Dave Thaler, David 1104 Harrington, Ed Jankiewicz, Hiroshi Miyata, Iljitsch van Beijnum, Jari 1105 Arkko, Jerry Huang, John Schnizlein, Jouni Korhonen, Kentaro Ebisawa, 1106 Kevin Yin, Magnus Westerlund, Marcelo Bagnulo Braun, Margaret 1107 Wasserman, Masahito Endo, Phil Roberts, Philip Matthews, Reinaldo 1108 Penno, Remi Denis-Courmont, Remi Despres, Senthil Sivakumar, Simon 1109 Perreault and Zen Cao. 1111 8. Appendix: Stateless translation workflow example 1113 A stateless translation workflow example is depicted in the following 1114 figure. The documentation address blocks 2001:DB8::/32 [RFC3849], 1115 192.0.2.0/24 and 198.51.100.0/24 [RFC5737] are used in this example. 1117 +--------------+ +--------------+ 1118 | IPv4 network | | IPv6 network | 1119 | | +-------+ | | 1120 | +----+ |-----| XLAT |---- | +----+ | 1121 | | H4 |-----| +-------+ |--| H6 | | 1122 | +----+ | | +----+ | 1123 +--------------+ +--------------+ 1125 Figure 8 1127 A translator (XLAT) connects the IPv6 network to the IPv4 network. 1128 This XLAT uses the Network Specific Prefix (NSP) 2001:DB8:100::/40 1129 defined in [I-D.ietf-behave-address-format] to represent IPv4 1130 addresses in the IPv6 address space (IPv4-converted addresses) and to 1131 represent IPv6 addresses (IPv4-translatable addresses) in the IPv4 1132 address space. In this example, 192.0.2.0/24 is the IPv4 block of 1133 the corresponding IPv4-translatable addresses. 1135 Based on the address mapping rule, the IPv6 node H6 has an IPv4- 1136 translatable IPv6 address 2001:DB8:1C0:2:21:: (address mapping from 1137 192.0.2.33). The IPv4 node H4 has IPv4 address 198.51.100.2. 1139 The IPv6 routing is configured in such a way that the IPv6 packets 1140 addressed to a destination address in 2001:DB8:100::/40 are routed to 1141 the IPv6 interface of the XLAT. 1143 The IPv4 routing is configured in such a way that the IPv4 packets 1144 addressed to a destination address in 192.0.2.0/24 are routed to the 1145 IPv4 interface of the XLAT. 1147 8.1. H6 establishes communication with H4 1149 The steps by which H6 establishes communication with H4 are: 1151 1. H6 performs the destination address mapping, so the IPv4- 1152 converted address 2001:DB8:1C6:3364:200:: is formed from 1153 198.51.100.2 based on the address mapping algorithm 1154 [I-D.ietf-behave-address-format]. 1156 2. H6 sends a packet to H4. The packet is sent from a source 1157 address 2001:DB8:1C0:2:21:: to a destination address 1158 2001:DB8:1C6:3364:200::. 1160 3. The packet is routed to the IPv6 interface of the XLAT (since 1161 IPv6 routing is configured that way). 1163 4. The XLAT receives the packet and performs the following actions: 1165 * The XLAT translates the IPv6 header into an IPv4 header using 1166 the IP/ICMP Translation Algorithm defined in this document. 1168 * The XLAT includes 192.0.2.33 as source address in the packet 1169 and 198.51.100.2 as destination address in the packet. Note 1170 that 192.0.2.33 and 198.51.100.2 are extracted directly from 1171 the source IPv6 address 2001:DB8:1C0:2:21:: (IPv4-translatable 1172 address) and destination IPv6 address 2001:DB8:1C6:3364:200:: 1173 (IPv4-converted address) of the received IPv6 packet that is 1174 being translated. 1176 5. The XLAT sends the translated packet out its IPv4 interface and 1177 the packet arrives at H4. 1179 6. H4 node responds by sending a packet with destination address 1180 192.0.2.33 and source address 198.51.100.2. 1182 7. The packet is routed to the IPv4 interface of the XLAT (since 1183 IPv4 routing is configured that way). The XLAT performs the 1184 following operations: 1186 * The XLAT translates the IPv4 header into an IPv6 header using 1187 the IP/ICMP Translation Algorithm defined in this document. 1189 * The XLAT includes 2001:DB8:1C0:2:21:: as destination address 1190 in the packet and 2001:DB8:1C6:3364:200:: as source address in 1191 the packet. Note that 2001:DB8:1C0:2:21:: and 1192 2001:DB8:1C6:3364:200:: 1193 are formed directly from the destination IPv4 1194 address 192.0.2.33 and source IPv4 address 198.51.100.2 of the 1195 received IPv4 packet that is being translated. 1197 8. The translated packet is sent out the IPv6 interface to H6. 1199 The packet exchange between H6 and H4 continues until the session is 1200 finished. 1202 8.2. H4 establishes communication with H6 1204 The steps by which H4 establishes communication with H6 are: 1206 1. H4 performs the destination address mapping, so 192.0.2.33 is 1207 formed from IPv4-translatable address 2001:DB8:1C0:2:21:: based 1208 on the address mapping algorithm 1209 [I-D.ietf-behave-address-format]. 1211 2. H4 sends a packet to H6. The packet is sent from a source 1212 address 198.51.100.2 to a destination address 192.0.2.33. 1214 3. The packet is routed to the IPv4 interface of the XLAT (since 1215 IPv4 routing is configured that way). 1217 4. The XLAT receives the packet and performs the following actions: 1219 * The XLAT translates the IPv4 header into an IPv6 header using 1220 the IP/ICMP Translation Algorithm defined in this document. 1222 * The XLAT includes 2001:DB8:1C6:3364:200:: as source address in 1223 the packet and 2001:DB8:1C0:2:21:: as destination address in 1224 the packet. Note that 2001:DB8:1C6:3364:200:: (IPv4-converted 1225 address) and 2001:DB8:1C0:2:21:: (IPv4-translatable address) 1226 are obtained directly from the source IPv4 address 1227 198.51.100.2 and destination IPv4 address 192.0.2.33 of the 1228 received IPv4 packet that is being translated. 1230 5. The XLAT sends the translated packet out its IPv6 interface and 1231 the packet arrives at H6. 1233 6. H6 node responds by sending a packet with destination address 1234 2001:DB8:1C6:3364:200:: and source address 2001:DB8:1C0:2:21::. 1236 7. The packet is routed to the IPv6 interface of the XLAT (since 1237 IPv6 routing is configured that way). The XLAT performs the 1238 following operations: 1240 * The XLAT translates the IPv6 header into an IPv4 header using 1241 the IP/ICMP Translation Algorithm defined in this document. 1243 * The XLAT includes 198.51.100.2 as destination address in the 1244 packet and 192.0.2.33 as source address in the packet. Note 1245 that 198.51.100.2 and 192.0.2.33 are formed directly from the 1246 destination IPv6 address 2001:DB8:1C6:3364:200:: and source 1247 IPv6 address 2001:DB8:1C0:2:21:: of the received IPv6 packet 1248 that is being translated. 1250 8. The translated packet is sent out the IPv4 interface to H4. 1252 The packet exchange between H4 and H6 continues until the session 1253 finished. 1255 9. References 1256 9.1. Normative References 1258 [I-D.ietf-behave-address-format] 1259 Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1260 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 1261 draft-ietf-behave-address-format-06 (work in progress), 1262 March 2010. 1264 [I-D.ietf-behave-v6v4-xlate-stateful] 1265 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 1266 NAT64: Network Address and Protocol Translation from IPv6 1267 Clients to IPv4 Servers", 1268 draft-ietf-behave-v6v4-xlate-stateful-10 (work in 1269 progress), March 2010. 1271 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1272 August 1980. 1274 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1275 September 1981. 1277 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1278 RFC 792, September 1981. 1280 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1281 RFC 793, September 1981. 1283 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1284 RFC 1812, June 1995. 1286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1287 Requirement Levels", BCP 14, RFC 2119, March 1997. 1289 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1290 (IPv6) Specification", RFC 2460, December 1998. 1292 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1293 (SIIT)", RFC 2765, February 2000. 1295 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1296 Architecture", RFC 4291, February 2006. 1298 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1299 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1301 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1302 Message Protocol (ICMPv6) for the Internet Protocol 1303 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1305 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 1306 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 1307 April 2007. 1309 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1310 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1311 RFC 5382, October 2008. 1313 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 1314 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 1315 March 2010. 1317 9.2. Informative References 1319 [I-D.ietf-behave-v6v4-framework] 1320 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1321 IPv4/IPv6 Translation", 1322 draft-ietf-behave-v6v4-framework-08 (work in progress), 1323 March 2010. 1325 [RFC0879] Postel, J., "TCP maximum segment size and related topics", 1326 RFC 879, November 1983. 1328 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1329 November 1990. 1331 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1332 "Definition of the Differentiated Services Field (DS 1333 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1334 December 1998. 1336 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1337 and W. Weiss, "An Architecture for Differentiated 1338 Services", RFC 2475, December 1998. 1340 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1341 Listener Discovery (MLD) for IPv6", RFC 2710, 1342 October 1999. 1344 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 1345 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1346 February 2000. 1348 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 1349 Addresses", RFC 3307, August 2002. 1351 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 1352 Listener Discovery (MLD) Protocol", RFC 3590, 1353 September 2003. 1355 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1356 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1358 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 1359 Reserved for Documentation", RFC 3849, July 2004. 1361 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1362 December 2005. 1364 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 1365 Reserved for Documentation", RFC 5737, January 2010. 1367 Authors' Addresses 1369 Xing Li 1370 CERNET Center/Tsinghua University 1371 Room 225, Main Building, Tsinghua University 1372 Beijing, 100084 1373 China 1375 Phone: +86 10-62785983 1376 Email: xing@cernet.edu.cn 1378 Congxiao Bao 1379 CERNET Center/Tsinghua University 1380 Room 225, Main Building, Tsinghua University 1381 Beijing, 100084 1382 China 1384 Phone: +86 10-62785983 1385 Email: congxiao@cernet.edu.cn 1387 Fred Baker 1388 Cisco Systems 1389 Santa Barbara, California 93117 1390 USA 1392 Phone: +1-408-526-4257 1393 Email: fred@cisco.com