idnits 2.17.1 draft-ietf-behave-v6v4-xlate-12.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 23, 2010) is 5147 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-05 == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-09 ** 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: September 24, 2010 Cisco Systems 7 March 23, 2010 9 IP/ICMP Translation Algorithm 10 draft-ietf-behave-v6v4-xlate-12 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 September 24, 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 . . . . . . . . . . . . 14 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 . . . . . . . . 17 86 4.2. Translating ICMPv6 Headers into ICMPv4 Headers . . . . . . 19 87 4.3. Translating ICMPv6 Error Messages into ICMPv4 . . . . . . 22 88 4.4. Translator Sending ICMPv6 Error Message . . . . . . . . . 23 89 4.5. Transport-layer Header Translation . . . . . . . . . . . . 23 90 4.6. Knowing When to Translate . . . . . . . . . . . . . . . . 24 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 98 9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 99 9.2. Informative References . . . . . . . . . . . . . . . . . . 29 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 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 routing headers, hop-by-hop extension headers, 148 destination options headers or source routing headers. 150 The issues and algorithms in the translation of datagrams containing 151 TCP segments are described in [RFC5382]. 153 Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e., 154 the UDP checksum field is zero) are not of significant use in the 155 Internet and will not be translated by the IP/ICMP translator. 157 The IP/ICMP header translation specified in this document is 158 consistent with requirements of multicast IP/ICMP headers. However 159 IPv4 multicast addresses [RFC5771] cannot be mapped to IPv6 multicast 160 addresses [RFC3307] based on the unicast mapping rule 161 [I-D.ietf-behave-address-format]. 163 Translator SHOULD make sure that the packets belonging to the same 164 flow leave the translator in the same order in which they arrived. 166 1.3. Stateless vs. Stateful Mode 168 An IP/ICMP translator has two possible modes of operation: stateless 169 and stateful [I-D.ietf-behave-v6v4-framework]. In both cases, we 170 assume that a system (a node or an application) that has an IPv4 171 address but not an IPv6 address is communicating with a system that 172 has an IPv6 address but no IPv4 address, or that the two systems do 173 not have contiguous routing connectivity and hence are forced to have 174 their communications translated. 176 In the stateless mode, a specific IPv6 address range will represent 177 IPv4 systems (IPv4-converted addresses), and the IPv6 systems have 178 addresses (IPv4-translatable addresses) that can be algorithmically 179 mapped to a subset of the service provider's IPv4 addresses. Note 180 that IPv4-translatable addresses is a subset of IPv4-converted 181 addresses. In general, there is no need to concern oneself with 182 translation tables, as the IPv4 and IPv6 counterparts are 183 algorithmically related. 185 In the stateful mode, a specific IPv6 address range will represent 186 IPv4 systems (IPv4-converted addresses), but the IPv6 systems may use 187 any IPv6 addresses [RFC4291] except in that range. In this case, a 188 translation table is required to bind the IPv6 systems' addresses to 189 the IPv4 addresses maintained in the translator. 191 The address translation mechanisms for the stateless and the stateful 192 translations are defined in [I-D.ietf-behave-address-format]. 194 1.4. Path MTU Discovery and Fragmentation 196 Due to the different sizes of the IPv4 and IPv6 header, which are 20+ 197 octets and 40 octets respectively, handling the maximum packet size 198 is critical for the operation of the IPv4/IPv6 translator. There are 199 three mechanisms to handle this issue: path MTU discovery (PMTUD), 200 fragmentation, and transport-layer negotiation such as the TCP MSS 201 option [RFC0879]. Note that the translator MUST behave as a router, 202 i.e. the translator MUST send a "Packet Too Big" error message or 203 fragment the packet when the packet size exceeds the MTU of the next 204 hop interface. 206 "Don't Fragment", ICMP "Packet Too Big", and packet fragmentation are 207 discussed in sections 3 and 4 of this document. The reassembling of 208 fragmented packets in the stateful translator is discussed in 209 [I-D.ietf-behave-v6v4-xlate-stateful], since it requires state 210 maintenance in the translator. 212 2. Conventions 214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 216 document are to be interpreted as described in [RFC2119]. 218 3. Translating from IPv4 to IPv6 220 When an IP/ICMP translator receives an IPv4 datagram addressed to a 221 destination towards the IPv6 domain, it translates the IPv4 header of 222 that packet into an IPv6 header. The original IPv4 header on the 223 packet is removed and replaced by an IPv6 header. Since the ICMPv6 224 [RFC4443], TCP [RFC0793], UDP [RFC0768] and DCCP [RFC4340] headers 225 contain checksums that cover IP header information, if the address 226 mapping algorithm is not checksum-neutral, the checksum MUST be 227 evaluated before translation and the ICMPv6 and transport-layer 228 headers MUST be updated. The data portion of the packet is left 229 unchanged. The IP/ICMP translator then forwards the packet based on 230 the IPv6 destination address. 232 +-------------+ +-------------+ 233 | IPv4 | | IPv6 | 234 | Header | | Header | 235 +-------------+ +-------------+ 236 | Transport | | Fragment | 237 | Layer | ===> | Header | 238 | Header | | (if needed) | 239 +-------------+ +-------------+ 240 | | | Transport | 241 ~ Data ~ | Layer | 242 | | | Header | 243 +-------------+ +-------------+ 244 | | 245 ~ Data ~ 246 | | 247 +-------------+ 249 Figure 2: IPv4-to-IPv6 Translation 251 Path MTU discovery is mandatory in IPv6 but it is optional in IPv4. 252 IPv6 routers never fragment a packet - only the sender can do 253 fragmentation. 255 When an IPv4 node performs path MTU discovery (by setting the Don't 256 Fragment (DF) bit in the header), path MTU discovery can operate end- 257 to-end, i.e., across the translator. In this case either IPv4 or 258 IPv6 routers (including the translator) might send back ICMP "Packet 259 Too Big" messages to the sender. When the IPv6 routers send these 260 ICMPv6 errors they will pass through a translator that will translate 261 the ICMPv6 error to a form that the IPv4 sender can understand. As a 262 result, an IPv6 fragment header is only included if the IPv4 packet 263 is already fragmented. 265 However, when the IPv4 sender does not set the Don't Fragment (DF) 266 bit, the translator MUST ensure that the packet does not exceed the 267 path MTU on the IPv6 side. This is done by fragmenting the IPv4 268 packet so that it fits in 1280-byte IPv6 packets, since that is the 269 minimum IPv6 MTU. Also, when the IPv4 sender does not set the DF bit 270 the translator MUST always include an IPv6 fragment header to 271 indicate that the sender allows fragmentation. 273 The rules in section 3.1 ensure that when packets are fragmented, 274 either by the sender or by IPv4 routers, the low-order 16 bits of the 275 fragment identification are carried end-to-end, ensuring that packets 276 are correctly reassembled. In addition, the rules in section 3.1 use 277 the presence of an IPv6 fragment header to indicate that the sender 278 might not be using path MTU discovery (i.e., the packet should not 279 have the DF flag set should it later be translated back to IPv4). 281 Other than the special rules for handling fragments and path MTU 282 discovery, the actual translation of the packet header consists of a 283 simple translation as defined below. Note that ICMPv4 packets 284 require special handling in order to translate the content of ICMPv4 285 error messages and also to add the ICMPv6 pseudo-header checksum. 287 3.1. Translating IPv4 Headers into IPv6 Headers 289 If the DF flag is not set and the IPv4 packet will result in an IPv6 290 packet larger than 1280 bytes, the packet MUST be fragmented so the 291 resulting IPv6 packet (with Fragment header added to each fragment) 292 will be less than or equal to 1280 bytes. For example, if the packet 293 is fragmented prior to the translation, the IPv4 packets must be 294 fragmented so that their length, excluding the IPv4 header, is at 295 most 1232 bytes (1280 minus 40 for the IPv6 header and 8 for the 296 Fragment header). The resulting fragments are then translated 297 independently using the logic described below. 299 If the DF bit is set and the MTU of the next-hop interface is less 300 than the total length value of the IPv4 packet plus 20, the 301 translator MUST send an ICMPv4 "Fragmentation Needed" error message 302 to the IPv4 source address. 304 If the DF bit is set and the packet is not a fragment (i.e., the MF 305 flag is not set and the Fragment Offset is equal to zero) then the 306 translator SHOULD NOT add a Fragment header to the resulting packet. 307 The IPv6 header fields are set as follows: 309 Version: 6 311 Traffic Class: By default, copied from IP Type Of Service (TOS) 312 octet. According to [RFC2474] the semantics of the bits are 313 identical in IPv4 and IPv6. However, in some IPv4 environments 314 these fields might be used with the old semantics of "Type Of 315 Service and Precedence". An implementation of a translator SHOULD 316 support an administratively-configurable option to ignore the IPv4 317 TOS and always set the IPv6 traffic class (TC) to zero. In 318 addition, if the translator is at an administrative boundary, the 319 filtering and update considerations of [RFC2475] may be 320 applicable. 322 Flow Label: 0 (all zero bits) 324 Payload Length: Total length value from IPv4 header, minus the size 325 of the IPv4 header and IPv4 options, if present. 327 Next Header: For ICMPv4 (1) changed to ICMPv6 (58), otherwise 328 protocol field MUST be copied from IPv4 header. 330 Hop Limit: The hop limit is derived from the TTL value in the IPv4 331 header. Since the translator is a router, as part of forwarding 332 the packet it needs to decrement either the IPv4 TTL (before the 333 translation) or the IPv6 Hop Limit (after the translation). As 334 part of decrementing the TTL or Hop Limit the translator (as any 335 router) MUST check for zero and send the ICMPv4 "TTL Exceeded" or 336 ICMPv6 "Hop Limit Exceeded" error. 338 Source Address: The IPv4-converted address derived from the IPv4 339 source address per [I-D.ietf-behave-address-format] section 2.1. 341 If the translator gets an illegal source address (e.g. 0.0.0.0, 342 127.0.0.1, etc.), the translator SHOULD silently drop the packet 343 (as discussed in Section 5.3.7 of [RFC1812]). 345 Destination Address: In the stateless mode, which is to say that if 346 the IPv4 destination address is within a range of configured IPv4 347 stateless translation prefix, the IPv6 destination address is the 348 IPv4-translatable address derived from the IPv4 destination 349 address per [I-D.ietf-behave-address-format] section 2.1. A 350 workflow example of stateless translation is shown in the Appendix 351 of this document. 353 In the stateful mode, which is to say that if the IPv4 destination 354 address is not within the range of any configured IPv4 stateless 355 translation prefix, the IPv6 destination address and corresponding 356 transport-layer destination port are derived from the Binding 357 Information Bases (BIBs) reflecting current session state in the 358 translator as described in [I-D.ietf-behave-v6v4-xlate-stateful]. 360 If any IPv4 options are present in the IPv4 packet, the IPv4 options 361 MUST be ignored and the packet translated normally; there is no 362 attempt to translate the options. However, if an unexpired source 363 route option is present then the packet MUST instead be discarded, 364 and an ICMPv4 "Destination Unreachable/Source Route Failed" (Type 365 3/Code 5) error message SHOULD be returned to the sender. 367 If there is a need to add a Fragment header (the DF bit is not set or 368 the packet is a fragment) the header fields are set as above with the 369 following exceptions: 371 IPv6 fields: 373 Payload Length: Total length value from IPv4 header, plus 8 for 374 the fragment header, minus the size of the IPv4 header and IPv4 375 options, if present. 377 Next Header: Fragment header (44). 379 Fragment header fields: 381 Next Header: For ICMPv4 (1) changed to ICMPv6 (58), otherwise 382 protocol field MUST be copied from IPv4 header. 384 Fragment Offset: Fragment Offset copied from the IPv4 header. 386 M flag: More Fragments bit copied from the IPv4 header. 388 Identification: The low-order 16 bits copied from the 389 Identification field in the IPv4 header. The high-order 16 390 bits set to zero. 392 3.2. Translating ICMPv4 Headers into ICMPv6 Headers 394 All ICMPv4 messages that are to be translated require that the ICMPv6 395 checksum field be calculated as part of the translation since ICMPv6, 396 unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP. 398 In addition, all ICMPv4 packets MUST have the Type value translated 399 and, for ICMPv4 error messages, the included IP header also MUST be 400 translated. 402 The actions needed to translate various ICMPv4 messages are as 403 follows: 405 ICMPv4 query messages: 407 Echo and Echo Reply (Type 8 and Type 0): Adjust the Type values 408 to 128 and 129, respectively, and adjust the ICMP checksum both 409 to take the type change into account and to include the ICMPv6 410 pseudo-header. 412 Information Request/Reply (Type 15 and Type 16): Obsoleted in 413 ICMPv6. Silently drop. 415 Timestamp and Timestamp Reply (Type 13 and Type 14): Obsoleted in 416 ICMPv6. Silently drop. 418 Address Mask Request/Reply (Type 17 and Type 18): Obsoleted in 419 ICMPv6. Silently drop. 421 ICMP Router Advertisement (Type 9): Single hop message. Silently 422 drop. 424 ICMP Router Solicitation (Type 10): Single hop message. Silently 425 drop. 427 Unknown ICMPv4 types: Silently drop. 429 IGMP messages: While the MLD messages [RFC2710][RFC3590][RFC3810] 430 are the logical IPv6 counterparts for the IPv4 IGMP messages 431 all the "normal" IGMP messages are single-hop messages and 432 SHOULD be silently dropped by the translator. Other IGMP 433 messages might be used by multicast routing protocols and, 434 since it would be a configuration error to try to have router 435 adjacencies across IP/ICMP translators those packets SHOULD 436 also be silently dropped. 438 ICMPv4 error messages: 440 Destination Unreachable (Type 3): For all codes that are not 441 explicitly listed below, set the Type field to 1, and adjust 442 the ICMP checksum both to take the type change into account 443 and to include the ICMPv6 pseudo-header. 445 Translate the Code field as follows: 447 Code 0, 1 (Net, host unreachable): Set Code value to 0 (no 448 route to destination). 450 Code 2 (Protocol unreachable): Translate to an ICMPv6 451 Parameter Problem (Type 4, Code value 1) and make the 452 Pointer point to the IPv6 Next Header field. 454 Code 3 (Port unreachable): Set Code value to 4 (port 455 unreachable). 457 Code 4 (Fragmentation needed and DF set): Translate to an 458 ICMPv6 Packet Too Big message (Type 2) with Code value 459 set to 0. The MTU field MUST be adjusted for the 460 difference between the IPv4 and IPv6 header sizes, i.e. 461 minimum(advertised MTU+20, MTU_of_IPv6_nexthop, 462 (MTU_of_IPv4_nexthop)+20). Note that if the IPv4 router 463 set the MTU field to zero, i.e., the router does not 464 implement [RFC1191], then the translator MUST use the 465 plateau values specified in [RFC1191] to determine a 466 likely path MTU and include that path MTU in the ICMPv6 467 packet. (Use the greatest plateau value that is less 468 than the returned Total Length field.) 470 Code 5 (Source route failed): Set Code value to 0 (No route 471 to destination). Note that this error is unlikely since 472 source routes are not translated. 474 Code 6, 7, 8: Set Code value to 0 (No route to 475 destination). 477 Code 9, 10 (Communication with destination host 478 administratively prohibited): Set Code value to 1 479 (Communication with destination administratively 480 prohibited) 482 Code 11, 12: Set Code value to 0 (no route to destination). 484 Code 13 (Communication Administratively Prohibited): Set 485 Code value to 1 (Communication with destination 486 administratively prohibited). 488 Code 14 (Host Precedence Violation): Silently drop. 490 Code 15 (Precedence cutoff in effect): Set Code value to 1 491 (Communication with destination administratively 492 prohibited). 494 Redirect (Type 5): Single hop message. Silently drop. 496 Alternative Host Address (Type 6): Silently drop. 498 Source Quench (Type 4): Obsoleted in ICMPv6. Silently drop. 500 Time Exceeded (Type 11): Set the Type field to 3, and adjust 501 the ICMP checksum both to take the type change into account 502 and to include the ICMPv6 pseudo-header. The Code field is 503 unchanged. 505 Parameter Problem (Type 12): Set the Type field to 4, and 506 adjust the ICMP checksum both to take the type change into 507 account and to include the ICMPv6 pseudo-header. Translate 508 the Code field as follows: 510 Code 0 (Pointer indicates the error): Set the Code value to 511 0 (Erroneous header field encountered) and update the 512 pointer as defined in Figure 3 (If the Original IPv4 513 Pointer Value is not listed or the Translated IPv6 514 Pointer Value is listed as "n/a", silently drop the 515 packet). 517 Code 1 (Missing a required option): Silently drop 519 Code 2 (Bad length): Set the Code value to 0 (Erroneous 520 header field encountered) and update the pointer as 521 defined in Figure 3 (If the Original IPv4 Pointer Value 522 is not listed or the Translated IPv6 Pointer Value is 523 listed as "n/a", silently drop the packet). 525 Other Code values: Silently drop 527 Unknown ICMPv4 types: Silently drop. 529 | Original IPv4 Pointer Value | Translated IPv6 Pointer Value | 530 +--------------------------------+--------------------------------+ 531 | 0 | Version/IHL | 0 | Version/Traffic Class | 532 | 1 | Type Of Service | 1 | Traffic Class/Flow Label | 533 | 2,3 | Total Length | 4 | Payload Length | 534 | 4,5 | Identification | n/a | | 535 | 6 | Flags/Fragment Offset | n/a | | 536 | 7 | Fragment Offset | n/a | | 537 | 8 | Time to Live | 7 | Hop Limit | 538 | 9 | Protocol | 6 | Next Header | 539 |10,11| Header Checksum | n/a | | 540 |12-15| Source Address | 8 | Source Address | 541 |16-19| Destination Address | 24 | Destination Address | 542 +--------------------------------+--------------------------------+ 544 Figure 3: Pointer value for translating from IPv4 to IPv6 546 ICMP Error Payload: If the received ICMPv4 packet contains an 547 ICMPv4 Extension [RFC4884], the translation of the ICMPv4 548 packet will cause the ICMPv6 packet to change length. When 549 this occurs, the ICMPv6 Extension length attribute MUST be 550 adjusted accordingly (e.g., longer due to the translation 551 from IPv4 to IPv6). If the ICMPv4 Extension exceeds the 552 maximum size of an ICMPv6 message on the outgoing interface, 553 the ICMPv4 extension SHOULD be simply truncated. For 554 extensions not defined in [RFC4884], the translator passes 555 the extensions as opaque bit strings and those containing 556 IPv4 address literals will not have those addresses 557 translated to IPv6 address literals; this may cause problems 558 with processing of those ICMP extensions. 560 3.3. Translating ICMPv4 Error Messages into ICMPv6 562 There are some differences between the ICMPv4 and the ICMPv6 error 563 message formats as detailed above. In addition, the ICMP error 564 messages contain the packet in error, which MUST be translated just 565 like a normal IP packet. If the translation of this "packet in 566 error" changes the length of the datagram, the Total Length field in 567 the outer IPv6 header MUST be updated. 569 +-------------+ +-------------+ 570 | IPv4 | | IPv6 | 571 | Header | | Header | 572 +-------------+ +-------------+ 573 | ICMPv4 | | ICMPv6 | 574 | Header | | Header | 575 +-------------+ +-------------+ 576 | IPv4 | ===> | IPv6 | 577 | Header | | Header | 578 +-------------+ +-------------+ 579 | Partial | | Partial | 580 | Transport | | Transport | 581 | Layer | | Layer | 582 | Header | | Header | 583 +-------------+ +-------------+ 585 Figure 4: IPv4-to-IPv6 ICMP Error Translation 587 The translation of the inner IP header can be done by invoking the 588 function that translated the outer IP headers. This process MUST 589 stop at the first embedded header and drop the packet if it contains 590 more. 592 3.4. Translator Sending ICMPv4 Error Message 594 If the IPv4 packet is discarded, then the translator SHOULD be able 595 to send back an ICMPv4 error message to the original sender of the 596 packet, unless the discarded packet is itself an ICMPv4 message. The 597 ICMPv4 message, if sent, has a Type value of 3 (Destination 598 Unreachable) and a Code value of 13 (Communication Administratively 599 Prohibited), unless otherwise specified in this document or in 600 [I-D.ietf-behave-v6v4-xlate-stateful]. The translator SHOULD allow 601 an administrator to configure whether the ICMPv4 error messages are 602 sent, rate-limited, or not sent. 604 3.5. Transport-layer Header Translation 606 If the address translation algorithm is not checksum neutral, the 607 recalculation and updating of the transport-layer headers which 608 contain pseudo headers (e.g. of TCP, UDP and DCCP) MUST be performed. 610 When a translator receives an unfragmented UDP IPv4 packet and the 611 checksum field is zero, the translator SHOULD compute the missing UDP 612 checksum as part of translating the packet. Also, the translator 613 SHOULD maintain a counter of how many UDP checksums are generated in 614 this manner. 616 When a stateless translator receives the first fragment of a 617 fragmented UDP IPv4 packet and the checksum field is zero, the 618 translator SHOULD drop the packet and generate a system management 619 event specifying at least the IP addresses and port numbers in the 620 packet. When it receives fragments other than the first, it SHOULD 621 silently drop the packet, since there is no port information to log. 623 For stateful translator, the handling of fragmented UDP IPv4 packets 624 with a zero checksum is discussed in 625 [I-D.ietf-behave-v6v4-xlate-stateful] section 3.1. 627 3.6. Knowing When to Translate 629 If the IP/ICMP translator also provides normal forwarding function, 630 and the destination IPv4 address is reachable by a more specific 631 route without translation, the translator MUST forward it without 632 translating it. Otherwise, when an IP/ICMP translator receives an 633 IPv4 datagram addressed to an IPv4 destination representing a host in 634 the IPv6 domain, the packet MUST be translated to IPv6. 636 4. Translating from IPv6 to IPv4 638 When an IP/ICMP translator receives an IPv6 datagram addressed to a 639 destination towards the IPv4 domain, it translates the IPv6 header of 640 the received IPv6 packet into an IPv4 header. The original IPv6 641 header on the packet is removed and replaced by an IPv4 header. 642 Since the ICMPv6 [RFC4443], TCP [RFC0793], UDP [RFC0768] and DCCP 643 [RFC4340] headers contain checksums that cover the IP header, if the 644 address mapping algorithm is not checksum-neutral, the checksum MUST 645 be evaluated before translation and the ICMP and transport-layer 646 headers MUST be updated. The data portion of the packet is left 647 unchanged. The IP/ICMP translator then forwards the packet based on 648 the IPv4 destination address. 650 +-------------+ +-------------+ 651 | IPv6 | | IPv4 | 652 | Header | | Header | 653 +-------------+ +-------------+ 654 | Fragment | | Transport | 655 | Header | ===> | Layer | 656 |(if present) | | Header | 657 +-------------+ +-------------+ 658 | Transport | | | 659 | Layer | ~ Data ~ 660 | Header | | | 661 +-------------+ +-------------+ 662 | | 663 ~ Data ~ 664 | | 665 +-------------+ 667 Figure 5: IPv6-to-IPv4 Translation 669 There are some differences between IPv6 and IPv4 in the area of 670 fragmentation and the minimum link MTU that affect the translation. 671 An IPv6 link has to have an MTU of 1280 bytes or greater. The 672 corresponding limit for IPv4 is 68 bytes. Thus, unless there were 673 special measures, it would not be possible to do end-to-end path MTU 674 discovery when the path includes a translator, since the IPv6 node 675 might receive ICMPv6 "Packet Too Big" messages originated by an IPv4 676 router that report an MTU less than 1280. However, [RFC2460] section 677 5 requires that IPv6 nodes handle such an ICMPv6 "Packet Too Big" 678 message by reducing the path MTU to 1280 and including an IPv6 679 fragment header with each packet. In this case, the translator 680 SHOULD set DF to 0 and take the identification value from the IPv6 681 fragment header when a fragmentation header with (MF=0; Offset=0) is 682 present or set DF to 1 otherwise. This allows end-to-end path MTU 683 discovery across the translator as long as the path MTU is 1280 bytes 684 or greater. When the path MTU drops below the 1280 limit, the IPv6 685 sender will originate 1280-byte packets that will be fragmented by 686 IPv4 routers along the path after being translated to IPv4. 688 The drawback with this scheme is that it is not possible to use PMTU 689 discovery to do optimal UDP fragmentation (as opposed to completely 690 avoiding fragmentation) at the sender, since the presence of an IPv6 691 Fragment header is interpreted that it is okay to fragment the packet 692 on the IPv4 side. Thus if a UDP application wants to send large 693 packets independent of the PMTU, the sender will only be able to 694 determine the path MTU on the IPv6 side of the translator. If the 695 path MTU on the IPv4 side of the translator is smaller, then the IPv6 696 sender will not receive any ICMPv6 "Too Big" errors and cannot adjust 697 the size fragments it is sending. 699 On the other hand, a recent study indicates that only 43.46% of IPv6- 700 capable web servers include an IPv6 fragmentation header in their 701 respond packets after they were sent an ICMPv6 "Packet Too Big" 702 message specifying an MTU<1280 bytes. A workaround to this problem 703 (ICMPv6 "Packet Too Big" message with MTU<1280) is that if there is 704 no fragmentation header in the IPv6 packet, the translator SHOULD set 705 DF to 0 for the packets equal to or smaller than 1280 bytes and set 706 DF to 1 for packets larger than 1280 bytes. In addition, the 707 translator SHOULD take the identification value from the IPv6 708 fragmentation header if present or generate the identification value 709 otherwise. This avoids the introduction of the path MTU discovery 710 black hole. The header translation defined in the next section uses 711 this method. 713 Other than the special rules for handling fragments and path MTU 714 discovery, the actual translation of the packet header consists of a 715 simple translation as defined below. Note that ICMPv6 packets 716 require special handling in order to translate the contents of ICMPv6 717 error messages and also to remove the ICMPv6 pseudo-header checksum. 719 4.1. Translating IPv6 Headers into IPv4 Headers 721 If there is no IPv6 Fragment header, the IPv4 header fields are set 722 as follows: 724 Version: 4 726 Internet Header Length: 5 (no IPv4 options) 728 Type of Service (TOS) Octet: By default, copied from the IPv6 729 Traffic Class (all 8 bits). According to [RFC2474] the semantics 730 of the bits are identical in IPv4 and IPv6. However, in some IPv4 731 environments, these bits might be used with the old semantics of 732 "Type Of Service and Precedence". An implementation of a 733 translator SHOULD provide the ability to ignore the IPv6 traffic 734 class and always set the IPv4 TOS Octet to a specified value. In 735 addition, if the translator is at an administrative boundary, the 736 filtering and update considerations of [RFC2475] may be 737 applicable. 739 Total Length: Payload length value from IPv6 header, plus the size 740 of the IPv4 header. 742 Identification: If the packet size is equal to or smaller than 1280 743 bytes, generate the identification value. If the packet size is 744 greater than 1280 bytes, MAY set Identification All zeros. 746 Flags: The More Fragments (MF) flag is set to zero. If the packet 747 size is equal to or smaller than 1280 bytes, the Don't Fragments 748 (DF) flag is set to zero. If the packet size is greater than 1280 749 bytes, the Don't Fragments (DF) flag is set to one. 751 Fragment Offset: All zeros. 753 Time to Live: Time to Live is derived from Hop Limit value in IPv6 754 header. Since the translator is a router, as part of forwarding 755 the packet it needs to decrement either the IPv6 Hop Limit (before 756 the translation) or the IPv4 TTL (after the translation). As part 757 of decrementing the TTL or Hop Limit the translator (as any 758 router) MUST check for zero and send the ICMPv4 "TTL Exceeded" or 759 ICMPv6 "Hop Limit Exceeded" error. 761 Protocol: For ICMPv6 (58) changed to ICMPv4 (1), otherwise skip 762 extension headers, Next Header field copied from the last IPv6 763 header. 765 Header Checksum: Computed once the IPv4 header has been created. 767 Source Address: In the stateless mode, which is to say that if the 768 IPv6 source address is within the range of a configured IPv6 769 translation prefix, the IPv4 source address is derived from the 770 IPv6 source address per [I-D.ietf-behave-address-format] section 771 2.1. Note that the original IPv6 source address is an IPv4- 772 translatable address. A workflow example of stateless translation 773 is shown in Appendix of this document. If the translator only 774 supports stateless mode and if the IPv6 source address is not 775 within the range of configured IPv6 prefix(es), the translator 776 SHOULD drop the packet and respond with an ICMPv6 Type=1, Code=5 777 (Destination Unreachable, Source address failed ingress/egress 778 policy). 780 In the stateful mode, which is to say that if the IPv6 source 781 address is not within the range of any configured IPv6 stateless 782 translation prefix, the IPv4 source address and transport-layer 783 source port corresponding to the IPv4-related IPv6 source address 784 and source port are derived from the Binding Information Bases 785 (BIBs) as described in [I-D.ietf-behave-v6v4-xlate-stateful]. 787 In stateless and stateful modes, if the translator gets an illegal 788 source address (e.g. ::1, etc.), the translator SHOULD silently 789 drop the packet. 791 Destination Address: The IPv4 destination address is derived from 792 the IPv6 destination address of the datagram being translated per 793 [I-D.ietf-behave-address-format] section 2.1. Note that the 794 original IPv6 destination address is an IPv4-converted address. 796 If any of an IPv6 Hop-by-Hop Options header, Destination Options 797 header, or Routing header with the Segments Left field equal to zero 798 are present in the IPv6 packet, those IPv6 extension headers MUST be 799 ignored (i.e., there is no attempt to translate the extension 800 headers) and the packet translated normally. However, the Total 801 Length field and the Protocol field are adjusted to "skip" these 802 extension headers. 804 If a Routing header with a non-zero Segments Left field is present 805 then the packet MUST NOT be translated, and an ICMPv6 "parameter 806 problem/erroneous header field encountered" (Type 4/Code 0) error 807 message, with the Pointer field indicating the first byte of the 808 Segments Left field, SHOULD be returned to the sender. 810 If the IPv6 packet contains a Fragment header, the header fields are 811 set as above with the following exceptions: 813 Total Length: Payload length value from IPv6 header, minus 8 for the 814 Fragment header, plus the size of the IPv4 header. 816 Identification: Copied from the low-order 16-bits in the 817 Identification field in the Fragment header. 819 Flags: The More Fragments (MF) flag is copied from the M flag in the 820 Fragment header. The Don't Fragments (DF) flag is set to zero 821 allowing this packet to be fragmented if required by IPv4 routers. 823 Fragment Offset: Copied from the Fragment Offset field in the 824 Fragment header. 826 Protocol: For ICMPv6 (58) changed to ICMPv4 (1), otherwise skip 827 extension headers, Next Header field copied from the last IPv6 828 header. 830 If a translated packet with DF set to 1 will be larger than the MTU 831 of the next-hop interface, then the translator MUST drop the packet 832 and send the ICMPv6 "Packet Too Big" (Type 2/Code 0) error message to 833 the IPv6 host with an adjusted MTU in the ICMPv6 message. 835 4.2. Translating ICMPv6 Headers into ICMPv4 Headers 837 All ICMPv6 messages that are to be translated require that the ICMPv4 838 checksum field be updated as part of the translation since ICMPv6 839 (unlike ICMPv4) includes a pseudo-header in the checksum just like 840 UDP and TCP. 842 In addition all ICMP packets MUST have the Type value translated and, 843 for ICMP error messages, the included IP header also MUST be 844 translated. Note that the IPv6 addresses in the IPv6 header may not 845 be IPv4-translatable addresses and there will be no corresponding 846 IPv4 addresses representing this IPv6 address. In this case, the 847 translator can do stateful translation. A mechanism by which the 848 translator can instead do stateless translation is left for future 849 work. 851 The actions needed to translate various ICMPv6 messages are: 853 ICMPv6 informational messages: 855 Echo Request and Echo Reply (Type 128 and 129): Adjust the Type 856 values to 8 and 0, respectively, and adjust the ICMP checksum 857 both to take the type change into account and to exclude the 858 ICMPv6 pseudo-header. 860 MLD Multicast Listener Query/Report/Done (Type 130, 131, 132): 861 Single hop message. Silently drop. 863 Neighbor Discover messages (Type 133 through 137): Single hop 864 message. Silently drop. 866 Unknown informational messages: Silently drop. 868 ICMPv6 error messages: 870 Destination Unreachable (Type 1) Set the Type field to 3, and 871 adjust the ICMP checksum both to take the type change into 872 account and to exclude the ICMPv6 pseudo-header. Translate the 873 Code field as follows: 875 Code 0 (no route to destination): Set Code value to 1 (Host 876 unreachable). 878 Code 1 (Communication with destination administratively 879 prohibited): Set Code value to 10 (Communication with 880 destination host administratively prohibited). 882 Code 2 (Beyond scope of source address): Set Code value to 1 883 (Host unreachable). Note that this error is very unlikely 884 since an IPv4-translatable source address is typically 885 considered to have global scope. 887 Code 3 (Address unreachable): Set Code value to 1 (Host 888 unreachable). 890 Code 4 (Port unreachable): Set Code value to 3 (Port 891 unreachable). 893 Other Code values: Silently drop. 895 Packet Too Big (Type 2): Translate to an ICMPv4 Destination 896 Unreachable (Type 3) with Code value equal to 4, and adjust the 897 ICMPv4 checksum both to take the type change into account and 898 to exclude the ICMPv6 pseudo-header. The MTU field MUST be 899 adjusted for the difference between the IPv4 and IPv6 header 900 sizes taking into account whether or not the packet in error 901 includes a Fragment header, i.e. minimum(advertised MTU-20, 902 MTU_of_IPv4_nexthop, (MTU_of_IPv6_nexthop)-20) 904 Time Exceeded (Type 3): Set the Type value to 11, and adjust the 905 ICMPv4 checksum both to take the type change into account and 906 to exclude the ICMPv6 pseudo-header. The Code field is 907 unchanged. 909 Parameter Problem (Type 4): Translate the Type and Code field as 910 follows, and adjust the ICMPv4 checksum both to take the type 911 change into account and to exclude the ICMPv6 pseudo-header. 913 Code 0 (Erroneous header field encountered): Set Type 12, Code 914 0 and update the pointer as defined in Figure 6 (If the 915 Original IPv6 Pointer Value is not listed or the Translated 916 IPv4 Pointer Value is listed as "n/a", silently drop the 917 packet). 919 Code 1 (Unrecognized Next Header type encountered): Translate 920 this to an ICMPv4 protocol unreachable (Type 3, Code 2). 922 Code 2 (Unrecognized IPv6 option encountered): Silently drop. 924 Unknown error messages: Silently drop. 926 | Original IPv6 Pointer Value | Translated IPv4 Pointer Value | 927 +--------------------------------+--------------------------------+ 928 | 0 | Version/Traffic Class | 0 | Version/IHL, Type Of Ser | 929 | 1 | Traffic Class/Flow Label | 1 | Type Of Service | 930 | 2,3 | Flow Label | n/a | | 931 | 4,5 | Payload Length | 2 | Total Length | 932 | 6 | Next Header | 9 | Protocol | 933 | 7 | Hop Limit | 8 | Time to Live | 934 | 8-23| Source Address | 12 | Source Address | 935 |24-39| Destination Address | 16 | Destination Address | 936 +--------------------------------+--------------------------------+ 938 Figure 6: Pointer Value for translating from IPv6 to IPv4 940 ICMP Error Payload: If the received ICMPv6 packet contains an 941 ICMPv6 Extension [RFC4884], the translation of the ICMPv6 942 packet will cause the ICMPv4 packet to change length. When 943 this occurs, the ICMPv6 Extension length attribute MUST be 944 adjusted accordingly (e.g., shorter due to the translation from 945 IPv6 to IPv4). For extensions not defined in [RFC4884], the 946 translator passes the extensions as opaque bit strings and 947 those containing IPv6 address literals will not have those 948 addresses translated to IPv4 address literals; this may cause 949 problems with processing of those ICMP extensions. 951 4.3. Translating ICMPv6 Error Messages into ICMPv4 953 There are some differences between the ICMPv4 and the ICMPv6 error 954 message formats as detailed above. In addition, the ICMP error 955 messages contain the packet in error, which MUST be translated just 956 like a normal IP packet. The translation of this "packet in error" 957 is likely to change the length of the datagram thus the Total Length 958 field in the outer IPv4 header MUST be updated. 960 +-------------+ +-------------+ 961 | IPv6 | | IPv4 | 962 | Header | | Header | 963 +-------------+ +-------------+ 964 | ICMPv6 | | ICMPv4 | 965 | Header | | Header | 966 +-------------+ +-------------+ 967 | IPv6 | ===> | IPv4 | 968 | Header | | Header | 969 +-------------+ +-------------+ 970 | Partial | | Partial | 971 | Transport | | Transport | 972 | Layer | | Layer | 973 | Header | | Header | 974 +-------------+ +-------------+ 976 Figure 7: IPv6-to-IPv4 ICMP Error Translation 978 The translation of the inner IP header can be done by invoking the 979 function that translated the outer IP headers. This process MUST 980 stop at first embedded header and drop the packet if it contains 981 more. Note that the IPv6 addresses in the IPv6 header may not be 982 IPv4-translatable addresses and there will be no corresponding IPv4 983 addresses. In this case, the translator can do stateful translation. 984 A mechanism by which the translator can instead do stateless 985 translation is left for future work. 987 4.4. Translator Sending ICMPv6 Error Message 989 If the IPv6 packet is discarded, then the translator SHOULD be able 990 to send back an ICMPv6 error message to the original sender of the 991 packet, unless the discarded packet is itself an ICMPv6 message. 993 If the ICMPv6 error message is being sent because the IPv6 source 994 address is not an IPv4-translatable address and the translator is 995 stateless, the ICMPv6 message, if sent, has a Type value 1 and Code 996 value 5 (Source address failed ingress/egress policy). In other 997 cases, the ICMPv6 message has a Type value of 1 (Destination 998 Unreachable) and a Code value of 1 (Communication with destination 999 administratively prohibited), unless otherwise specified in this 1000 document or [I-D.ietf-behave-v6v4-xlate-stateful]. The translator 1001 SHOULD allow an administrator to configure whether the ICMPv6 error 1002 messages are sent, rate-limited, or not sent. 1004 4.5. Transport-layer Header Translation 1006 If the address translation algorithm is not checksum neutral, the 1007 recalculation and updating of the transport-layer headers which 1008 contain pseudo headers (e.g. of TCP, UDP and DCCP) MUST be performed. 1010 4.6. Knowing When to Translate 1012 If the IP/ICMP translator also provides a normal forwarding function, 1013 and the destination address is reachable by a more specific route 1014 without translation, the router MUST forward it without translating 1015 it. When an IP/ICMP translator receives an IPv6 datagram addressed 1016 to an IPv6 address representing a host in the IPv4 domain, the IPv6 1017 packet MUST be translated to IPv4. 1019 5. IANA Considerations 1021 This memo adds no new IANA considerations. 1023 Note to RFC Editor: This section will have served its purpose if it 1024 correctly tells IANA that no new assignments or registries are 1025 required, or if those assignments or registries are created during 1026 the RFC publication process. From the author's perspective, it may 1027 therefore be removed upon publication as an RFC at the RFC Editor's 1028 discretion. 1030 6. Security Considerations 1032 The use of stateless IP/ICMP translators does not introduce any new 1033 security issues beyond the security issues that are already present 1034 in the IPv4 and IPv6 protocols and in the routing protocols that are 1035 used to make the packets reach the translator. 1037 There are potential issues that might arise by deriving an IPv4 1038 address from an IPv6 address - particularly addresses like broadcast 1039 or loopback addresses and the non IPv4-translatable IPv6 addresses, 1040 etc. The [I-D.ietf-behave-address-format] addresses these issues. 1042 As the Authentication Header [RFC4302] is specified to include the 1043 IPv4 Identification field and the translating function is not able to 1044 always preserve the Identification field, it is not possible for an 1045 IPv6 endpoint to verify the AH on received packets that have been 1046 translated from IPv4 packets. Thus AH does not work through a 1047 translator. 1049 Packets with ESP can be translated since ESP does not depend on 1050 header fields prior to the ESP header. Note that ESP transport mode 1051 is easier to handle than ESP tunnel mode; in order to use ESP tunnel 1052 mode, the IPv6 node MUST be able to generate an inner IPv4 header 1053 when transmitting packets and remove such an IPv4 header when 1054 receiving packets. 1056 7. Acknowledgements 1058 This is under development by a large group of people. Those who have 1059 posted to the list during the discussion include Andrew Sullivan, 1060 Andrew Yourtchenko, Brian Carpenter, Dan Wing, Dave Thaler, David 1061 Harrington, Ed Jankiewicz, Hiroshi Miyata, Iljitsch van Beijnum, Jari 1062 Arkko, Jerry Huang, John Schnizlein, Jouni Korhonen, Kentaro Ebisawa, 1063 Kevin Yin, Magnus Westerlund, Marcelo Bagnulo Braun, Margaret 1064 Wasserman, Masahito Endo, Phil Roberts, Philip Matthews, Reinaldo 1065 Penno, Remi Denis-Courmont, Remi Despres, Senthil Sivakumar, Simon 1066 Perreault and Zen Cao. 1068 8. Appendix: Stateless translation workflow example 1070 A stateless translation workflow example is depicted in the following 1071 figure. The documentation address blocks 2001:DB8::/32 [RFC3849], 1072 192.0.2.0/24 and 198.51.100.0/24 [RFC5737] are used in this example. 1074 +--------------+ +--------------+ 1075 | IPv4 network | | IPv6 network | 1076 | | +-------+ | | 1077 | +----+ |-----| XLAT |---- | +----+ | 1078 | | H4 |-----| +-------+ |--| H6 | | 1079 | +----+ | | +----+ | 1080 +--------------+ +--------------+ 1082 Figure 8 1084 A translator (XLAT) connects the IPv6 network to the IPv4 network. 1085 This XLAT uses the Network Specific Prefix (NSP) 2001:DB8:100::/40 1086 defined in [I-D.ietf-behave-address-format] to represent IPv4 1087 addresses in the IPv6 address space (IPv4-converted addresses) and to 1088 represent IPv6 addresses (IPv4-translatable addresses) in the IPv4 1089 address space. In this example, 192.0.2.0/24 is the IPv4 block of 1090 the corresponding IPv4-translatable addresses. 1092 Based on the address mapping rule, the IPv6 node H6 has an IPv4- 1093 translatable IPv6 address 2001:DB8:1C0:2:21:: (address mapping from 1094 192.0.2.33). The IPv4 node H4 has IPv4 address 198.51.100.2. 1096 The IPv6 routing is configured in such a way that the IPv6 packets 1097 addressed to a destination address in 2001:DB8:100::/40 are routed to 1098 the IPv6 interface of the XLAT. 1100 The IPv4 routing is configured in such a way that the IPv4 packets 1101 addressed to a destination address in 192.0.2.0/24 are routed to the 1102 IPv4 interface of the XLAT. 1104 8.1. H6 establishes communication with H4 1106 The steps by which H6 establishes communication with H4 are: 1108 1. H6 performs the destination address mapping, so the IPv4- 1109 converted address 2001:DB8:1C6:3364:200:: is formed from 1110 198.51.100.2 based on the address mapping algorithm 1111 [I-D.ietf-behave-address-format]. 1113 2. H6 sends a packet to H4. The packet is sent from a source 1114 address 2001:DB8:1C0:2:21:: to a destination address 1115 2001:DB8:1C6:3364:200::. 1117 3. The packet is routed to the IPv6 interface of the XLAT (since 1118 IPv6 routing is configured that way). 1120 4. The XLAT receives the packet and performs the following actions: 1122 * The XLAT translates the IPv6 header into an IPv4 header using 1123 the IP/ICMP Translation Algorithm defined in this document. 1125 * The XLAT includes 192.0.2.33 as source address in the packet 1126 and 198.51.100.2 as destination address in the packet. Note 1127 that 192.0.2.33 and 198.51.100.2 are extracted directly from 1128 the source IPv6 address 2001:DB8:1C0:2:21:: (IPv4-translatable 1129 address) and destination IPv6 address 2001:DB8:1C6:3364:200:: 1130 (IPv4-converted address) of the received IPv6 packet that is 1131 being translated. 1133 5. The XLAT sends the translated packet out its IPv4 interface and 1134 the packet arrives at H4. 1136 6. H4 node responds by sending a packet with destination address 1137 192.0.2.33 and source address 198.51.100.2. 1139 7. The packet is routed to the IPv4 interface of the XLAT (since 1140 IPv4 routing is configured that way). The XLAT performs the 1141 following operations: 1143 * The XLAT translates the IPv4 header into an IPv6 header using 1144 the IP/ICMP Translation Algorithm defined in this document. 1146 * The XLAT includes 2001:DB8:1C0:2:21:: as destination address 1147 in the packet and 2001:DB8:1C6:3364:200:: as source address in 1148 the packet. Note that 2001:DB8:1C0:2:21:: and 1149 2001:DB8:1C6:3364:200:: 1150 are formed directly from the destination IPv4 1151 address 192.0.2.33 and source IPv4 address 198.51.100.2 of the 1152 received IPv4 packet that is being translated. 1154 8. The translated packet is sent out the IPv6 interface to H6. 1156 The packet exchange between H6 and H4 continues until the session is 1157 finished. 1159 8.2. H4 establishes communication with H6 1161 The steps by which H4 establishes communication with H6 are: 1163 1. H4 performs the destination address mapping, so 192.0.2.33 is 1164 formed from IPv4-translatable address 2001:DB8:1C0:2:21:: based 1165 on the address mapping algorithm 1166 [I-D.ietf-behave-address-format]. 1168 2. H4 sends a packet to H6. The packet is sent from a source 1169 address 198.51.100.2 to a destination address 192.0.2.33. 1171 3. The packet is routed to the IPv4 interface of the XLAT (since 1172 IPv4 routing is configured that way). 1174 4. The XLAT receives the packet and performs the following actions: 1176 * The XLAT translates the IPv4 header into an IPv6 header using 1177 the IP/ICMP Translation Algorithm defined in this document. 1179 * The XLAT includes 2001:DB8:1C6:3364:200:: as source address in 1180 the packet and 2001:DB8:1C0:2:21:: as destination address in 1181 the packet. Note that 2001:DB8:1C6:3364:200:: (IPv4-converted 1182 address) and 2001:DB8:1C0:2:21:: (IPv4-translatable address) 1183 are obtained directly from the source IPv4 address 1184 198.51.100.2 and destination IPv4 address 192.0.2.33 of the 1185 received IPv4 packet that is being translated. 1187 5. The XLAT sends the translated packet out its IPv6 interface and 1188 the packet arrives at H6. 1190 6. H6 node responds by sending a packet with destination address 1191 2001:DB8:1C6:3364:200:: and source address 2001:DB8:1C0:2:21::. 1193 7. The packet is routed to the IPv6 interface of the XLAT (since 1194 IPv6 routing is configured that way). The XLAT performs the 1195 following operations: 1197 * The XLAT translates the IPv6 header into an IPv4 header using 1198 the IP/ICMP Translation Algorithm defined in this document. 1200 * The XLAT includes 198.51.100.2 as destination address in the 1201 packet and 192.0.2.33 as source address in the packet. Note 1202 that 198.51.100.2 and 192.0.2.33 are formed directly from the 1203 destination IPv6 address 2001:DB8:1C6:3364:200:: and source 1204 IPv6 address 2001:DB8:1C0:2:21:: of the received IPv6 packet 1205 that is being translated. 1207 8. The translated packet is sent out the IPv4 interface to H4. 1209 The packet exchange between H4 and H6 continues until the session 1210 finished. 1212 9. References 1214 9.1. Normative References 1216 [I-D.ietf-behave-address-format] 1217 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 1218 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 1219 draft-ietf-behave-address-format-05 (work in progress), 1220 March 2010. 1222 [I-D.ietf-behave-v6v4-xlate-stateful] 1223 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 1224 NAT64: Network Address and Protocol Translation from IPv6 1225 Clients to IPv4 Servers", 1226 draft-ietf-behave-v6v4-xlate-stateful-09 (work in 1227 progress), March 2010. 1229 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1230 August 1980. 1232 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1233 September 1981. 1235 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1236 RFC 792, September 1981. 1238 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1239 RFC 793, September 1981. 1241 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1242 RFC 1812, June 1995. 1244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1245 Requirement Levels", BCP 14, RFC 2119, March 1997. 1247 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1248 (IPv6) Specification", RFC 2460, December 1998. 1250 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1251 (SIIT)", RFC 2765, February 2000. 1253 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1254 Architecture", RFC 4291, February 2006. 1256 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1257 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1259 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1260 Message Protocol (ICMPv6) for the Internet Protocol 1261 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1263 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 1264 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 1265 April 2007. 1267 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1268 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1269 RFC 5382, October 2008. 1271 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 1272 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 1273 March 2010. 1275 9.2. Informative References 1277 [I-D.ietf-behave-v6v4-framework] 1278 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1279 IPv4/IPv6 Translation", 1280 draft-ietf-behave-v6v4-framework-08 (work in progress), 1281 March 2010. 1283 [RFC0879] Postel, J., "TCP maximum segment size and related topics", 1284 RFC 879, November 1983. 1286 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1287 November 1990. 1289 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1290 "Definition of the Differentiated Services Field (DS 1291 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1292 December 1998. 1294 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1295 and W. Weiss, "An Architecture for Differentiated 1296 Services", RFC 2475, December 1998. 1298 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1299 Listener Discovery (MLD) for IPv6", RFC 2710, 1300 October 1999. 1302 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 1303 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1304 February 2000. 1306 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 1307 Addresses", RFC 3307, August 2002. 1309 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 1310 Listener Discovery (MLD) Protocol", RFC 3590, 1311 September 2003. 1313 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1314 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1316 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 1317 Reserved for Documentation", RFC 3849, July 2004. 1319 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1320 December 2005. 1322 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 1323 Reserved for Documentation", RFC 5737, January 2010. 1325 Authors' Addresses 1327 Xing Li 1328 CERNET Center/Tsinghua University 1329 Room 225, Main Building, Tsinghua University 1330 Beijing, 100084 1331 China 1333 Phone: +86 10-62785983 1334 Email: xing@cernet.edu.cn 1335 Congxiao Bao 1336 CERNET Center/Tsinghua University 1337 Room 225, Main Building, Tsinghua University 1338 Beijing, 100084 1339 China 1341 Phone: +86 10-62785983 1342 Email: congxiao@cernet.edu.cn 1344 Fred Baker 1345 Cisco Systems 1346 Santa Barbara, California 93117 1347 USA 1349 Phone: +1-408-526-4257 1350 Email: fred@cisco.com