idnits 2.17.1 draft-ietf-behave-v6v4-xlate-11.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 16, 2010) is 5153 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 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-address-format-05 == Outdated reference: A later version (-10) exists of draft-ietf-behave-v6v4-framework-07 == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-09 -- 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) -- Obsolete informational reference (is this intentional?): RFC 3171 (Obsoleted by RFC 5771) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 5 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 17, 2010 Cisco Systems 7 March 16, 2010 9 IP/ICMP Translation Algorithm 10 draft-ietf-behave-v6v4-xlate-11 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 17, 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 . . . . . . . . . . . . . . 5 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 . . . . . . . . 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 [RFC2765], which provides stateless translation 107 between IPv4 [RFC0791] and IPv6 [RFC2460], and between ICMPv4 108 [RFC0792] and ICMPv6 [RFC4443]. 110 The general IPv4/IPv6 translation framework is now described in 111 [I-D.ietf-behave-v6v4-framework]. This document specifies the 112 translation algorithms between IPv4 packets and IPv6 packets. The 113 mapping algorithms between IPv4 addresses and IPv6 addresses in the 114 packet headers are specified in [I-D.ietf-behave-address-format]. 116 1.1. IPv4-IPv6 Translation Model 118 The translation model is consists of two or more network domains 119 connected by one or more IP/ICMP translators (XLATEs) as shown in 120 Figure 1. 122 -------- -------- 123 // IPv4 \\ // IPv6 \\ 124 / Domain \ / Domain \ 125 / +-----+ +--+ \ 126 | |XLATE| |S2| | Sn: Servers 127 | +--+ +-----+ +--+ | Hn: Clients 128 | |S1| +-----+ | 129 | +--+ | DNS | +--+ | XLATE: IPv4/IPv6 Translator 130 \ +--+ +-----+ |H2| / DNS: DNS64/DNS46 131 \ |H1| / \ +--+ / 132 \\ +--+ // \\ // 133 -------- -------- 135 Figure 1: IPv4-IPv6 Translation Model 137 One of those networks either routes IPv4 but not IPv6, or contains 138 some hosts that only implement IPv4 or have IPv4-only applications 139 (even if the host and the network support IPv6). The other network 140 either routes IPv6 but not IPv4, or contains some hosts that only 141 implement IPv6 or has IPv6-only applications. Both networks contain 142 clients, servers, and peers. A network domain may also consist of a 143 single host. DNS servers include DNS64 and DNS46, while DNS64 144 translates A record to AAAA record and DNS46 translates AAAA record 145 to A record. 147 1.2. Applicability and Limitations 149 This document specifies the translation algorithms between IPv4 150 packets and IPv6 packets. 152 As with [RFC2765], the translating function specified in this 153 document does not translate any IPv4 options and it does not 154 translate IPv6 routing headers, hop-by-hop extension headers, 155 destination options headers or source routing headers. 157 The issues and algorithms in the translation of datagrams containing 158 TCP segments are described in [RFC5382]. The considerations of that 159 document are applicable in this case as well. 161 Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e., 162 the UDP checksum field is zero) are not of significant use in the 163 Internet [Miller][Dongjin] and will not be translated by the IP/ICMP 164 translator. 166 IPv4 multicast addresses [RFC3171] cannot be mapped to IPv6 multicast 167 addresses [RFC3307] based on the unicast mapping rule. However, if a 168 multicast address mapping mechanism is defined, the IP/ICMP header 169 translation aspect of this document works. 171 A translator SHOULD make sure that the packets belonging to the same 172 flow leave the translator in the same order in which they arrived. 174 1.3. Stateless vs. Stateful Mode 176 An IP/ICMP translator has two possible modes of operation: stateless 177 and stateful [I-D.ietf-behave-v6v4-framework]. In both cases, we 178 assume that a system (a node or an application) that has an IPv4 179 address but not an IPv6 address is communicating with a system that 180 has an IPv6 address but no IPv4 address, or that the two systems do 181 not have contiguous routing connectivity and hence are forced to have 182 their communications translated. 184 In the stateless mode, a specific IPv6 address range will represent 185 IPv4 systems (IPv4-converted addresses), and the IPv6 systems have 186 addresses (IPv4-translatable addresses) that can be algorithmically 187 mapped to a subset of the service provider's IPv4 addresses. In 188 general, there is no need to concern oneself with translation tables, 189 as the IPv4 and IPv6 counterparts are algorithmically related. 191 In the stateful mode, a specific IPv6 address range will represent 192 IPv4 systems (IPv4-converted addresses), but the IPv6 systems may use 193 any [RFC4291] addresses except in that range. In this case, a 194 translation table is required to bind the IPv6 systems' addresses to 195 the IPv4 addresses maintained in the translator. 197 The address translation mechanisms for the stateless and the stateful 198 translations are defined in [I-D.ietf-behave-address-format]. 200 1.4. Path MTU Discovery and Fragmentation 202 Due to the different sizes of the IPv4 and IPv6 header, which are 20+ 203 octets and 40 octets respectively, handling the maximum packet size 204 is critical for the operation of the IPv4/IPv6 translator. There are 205 three mechanisms to handle this issue: path MTU discovery (PMTUD), 206 fragmentation, and transport-layer negotiation such as the TCP MSS 207 option [RFC0879]. Note that the translator MUST behave as a router, 208 i.e. the translator MUST send a "Packet Too Big" error message or 209 fragment the packet when the packet size exceeds the MTU of the next 210 hop interface. 212 "Don't Fragment", ICMP "Packet Too Big", and packet fragmentation are 213 discussed in sections 3 and 4 of this document. The reassembling of 214 fragmented packets in the stateful translator is discussed in 215 [I-D.ietf-behave-v6v4-xlate-stateful], since it requires state 216 maintenance in the translator. 218 2. Conventions 220 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 221 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 222 document are to be interpreted as described in [RFC2119]. 224 3. Translating from IPv4 to IPv6 226 When an IP/ICMP translator receives an IPv4 datagram addressed to a 227 destination towards the IPv6 domain, it translates the IPv4 header of 228 that packet into an IPv6 header. The original IPv4 header on the 229 packet is removed and replaced by an IPv6 header. Since the ICMPv6 230 [RFC4443], TCP [RFC0793] and UDP [RFC0768] headers contain checksums 231 that cover IP header information, if the address mapping algorithm is 232 not checksum-neutral, the ICMPv6 and transport-layer headers MUST be 233 updated. The data portion of the packet is left unchanged. The IP/ 234 ICMP translator then forwards the packet based on the IPv6 235 destination address. 237 +-------------+ +-------------+ 238 | IPv4 | | IPv6 | 239 | Header | | Header | 240 +-------------+ +-------------+ 241 | Transport | | Fragment | 242 | Layer | ===> | Header | 243 | Header | | (if needed) | 244 +-------------+ +-------------+ 245 | | | Transport | 246 ~ Data ~ | Layer | 247 | | | Header | 248 +-------------+ +-------------+ 249 | | 250 ~ Data ~ 251 | | 252 +-------------+ 254 Figure 2: IPv4-to-IPv6 Translation 256 One of the differences between IPv4 and IPv6, is that in IPv6, path 257 MTU discovery is mandatory but it is optional in IPv4. This implies 258 that IPv6 routers will never fragment a packet - only the sender can 259 do fragmentation. 261 When an IPv4 node performs path MTU discovery (by setting the Don't 262 Fragment (DF) bit in the header), path MTU discovery can operate end- 263 to-end, i.e., across the translator. In this case either IPv4 or 264 IPv6 routers (including the translator) might send back ICMP "Packet 265 Too Big" messages to the sender. When the IPv6 routers send these 266 ICMPv6 errors they will pass through a translator that will translate 267 the ICMPv6 error to a form that the IPv4 sender can understand. As a 268 result, an IPv6 fragment header is only included if the IPv4 packet 269 is already fragmented. 271 However, when the IPv4 sender does not set the Don't Fragment (DF) 272 bit, the translator has to ensure that the packet does not exceed the 273 path MTU on the IPv6 side. This is done by fragmenting the IPv4 274 packet so that it fits in 1280-byte IPv6 packets, since that is the 275 minimum IPv6 MTU. Also, when the IPv4 sender does not set the DF bit 276 the translator MUST always include an IPv6 fragment header to 277 indicate that the sender allows fragmentation. 279 The rules in section 3.1 ensure that when packets are fragmented, 280 either by the sender or by IPv4 routers, the low-order 16 bits of the 281 fragment identification are carried end-to-end, ensuring that packets 282 are correctly reassembled. In addition, the rules in section 3.1 use 283 the presence of an IPv6 fragment header to indicate that the sender 284 might not be using path MTU discovery (i.e., the packet should not 285 have the DF flag set should it later be translated back to IPv4). 287 Other than the special rules for handling fragments and path MTU 288 discovery, the actual translation of the packet header consists of a 289 simple mapping as defined below. Note that ICMPv4 packets require 290 special handling in order to translate the content of ICMPv4 error 291 messages and also to add the ICMPv6 pseudo-header checksum. 293 3.1. Translating IPv4 Headers into IPv6 Headers 295 If the DF flag is not set and the IPv4 packet will result in an IPv6 296 packet larger than 1280 bytes, the packet MUST be fragmented so the 297 resulting IPv6 packet (with Fragment header added to each fragment) 298 will be less than or equal to 1280 bytes. For example, if the packet 299 is fragmented prior to the translation, the IPv4 packets must be 300 fragmented so that their length, excluding the IPv4 header, is at 301 most 1232 bytes (1280 minus 40 for the IPv6 header and 8 for the 302 Fragment header). The resulting fragments are then translated 303 independently using the logic described below. 305 If the DF bit is set and the MTU of the next-hop interface is less 306 than the total length value of the IPv4 packet plus 20, the 307 translator MUST send an ICMPv4 "Fragmentation Needed" error message 308 to the IPv4 source address. 310 If the DF bit is set and the packet is not a fragment (i.e., the MF 311 flag is not set and the Fragment Offset is equal to zero) then the 312 translator SHOULD NOT add a Fragment header to the resulting packet. 313 The IPv6 header fields are set as follows: 315 Version: 6 317 Traffic Class: By default, copied from IP Type Of Service (TOS) 318 octet. According to [RFC2474] the semantics of the bits are 319 identical in IPv4 and IPv6. However, in some IPv4 environments 320 these fields might be used with the old semantics of "Type Of 321 Service and Precedence". An implementation of a translator SHOULD 322 provide the ability to ignore the IPv4 TOS and always set the IPv6 323 traffic class (TC) to zero. In addition, if the translator is at 324 an administrative boundary, the filtering and update 325 considerations of [RFC2475] may be applicable. 327 Flow Label: 0 (all zero bits) 329 Payload Length: Total length value from IPv4 header, minus the size 330 of the IPv4 header and IPv4 options, if present. 332 Next Header: For ICMPv4 (1) changed to ICMPv6 (58), otherwise 333 protocol field copied from IPv4 header. 335 Hop Limit: The hop limit is derived from the TTL value in the IPv4 336 header. Since the translator is a router, as part of forwarding 337 the packet it needs to decrement either the IPv4 TTL (before the 338 translation) or the IPv6 Hop Limit (after the translation). As 339 part of decrementing the TTL or Hop Limit the translator (as any 340 router) needs to check for zero and send the ICMPv4 "TTL Exceeded" 341 or ICMPv6 "Hop Limit Exceeded" error. 343 Source Address: The IPv4-converted address derived from the IPv4 344 source address per [I-D.ietf-behave-address-format] section 2.1. 346 If the translator gets an illegal source address (e.g. 0.0.0.0, 347 127.0.0.1, etc.), the translator SHOULD silently drop the packet 348 (as discussed in Section 5.3.7 of [RFC1812]). 350 Destination Address: In the stateless mode, which is to say that if 351 the IPv4 destination address is within a range of configured IPv4 352 stateless translation prefix, the IPv6 destination address is the 353 IPv4-translatable address derived from the IPv4 destination 354 address per [I-D.ietf-behave-address-format] section 2.1. A 355 workflow example of stateless translation is shown in the Appendix 356 of this document. 358 In the stateful mode, which is to say that if the IPv4 destination 359 address is not within the range of any configured IPv4 stateless 360 translation prefix, the IPv6 destination address and corresponding 361 transport-layer destination port are derived from the Binding 362 Information Bases (BIBs) reflecting current session state in the 363 translator as described in [I-D.ietf-behave-v6v4-xlate-stateful]. 365 If any IPv4 options are present in the IPv4 packet, the IPv4 options 366 MUST be ignored (i.e., there is no attempt to translate the options) 367 and the packet translated normally. However, if an unexpired source 368 route option is present then the packet MUST instead be discarded, 369 and an ICMPv4 "Destination Unreachable/Source Route Failed" (Type 370 3/Code 5) error message SHOULD be returned to the sender. 372 If there is a need to add a Fragment header (the DF bit is not set or 373 the packet is a fragment) the header fields are set as above with the 374 following exceptions: 376 IPv6 fields: 378 Payload Length: Total length value from IPv4 header, plus 8 for 379 the fragment header, minus the size of the IPv4 header and IPv4 380 options, if present. 382 Next Header: Fragment header (44). 384 Fragment header fields: 386 Next Header: For ICMPv4 (1) changed to ICMPv6 (58), otherwise 387 protocol field copied from IPv4 header. 389 Fragment Offset: Fragment Offset copied from the IPv4 header. 391 M flag: More Fragments bit copied from the IPv4 header. 393 Identification: The low-order 16 bits copied from the 394 Identification field in the IPv4 header. The high-order 16 395 bits set to zero. 397 3.2. Translating ICMPv4 Headers into ICMPv6 Headers 399 All ICMPv4 messages that are to be translated require that the ICMPv6 400 checksum field be calculated as part of the translation since ICMPv6, 401 unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP. 403 In addition, all ICMPv4 packets need to have the Type value 404 translated and, for ICMPv4 error messages, the included IP header 405 also needs translation. 407 The actions needed to translate various ICMPv4 messages are as 408 follows: 410 ICMPv4 query messages: 412 Echo and Echo Reply (Type 8 and Type 0): Adjust the Type values 413 to 128 and 129, respectively, and adjust the ICMP checksum both 414 to take the type change into account and to include the ICMPv6 415 pseudo-header. 417 Information Request/Reply (Type 15 and Type 16): Obsoleted in 418 ICMPv6. Silently drop. 420 Timestamp and Timestamp Reply (Type 13 and Type 14): Obsoleted in 421 ICMPv6. Silently drop. 423 Address Mask Request/Reply (Type 17 and Type 18): Obsoleted in 424 ICMPv6. Silently drop. 426 ICMP Router Advertisement (Type 9): Single hop message. Silently 427 drop. 429 ICMP Router Solicitation (Type 10): Single hop message. Silently 430 drop. 432 Unknown ICMPv4 types: Silently drop. 434 IGMP messages: While the MLD messages [RFC2710][RFC3590][RFC3810] 435 are the logical IPv6 counterparts for the IPv4 IGMP messages 436 all the "normal" IGMP messages are single-hop messages and 437 should be silently dropped by the translator. Other IGMP 438 messages might be used by multicast routing protocols and, 439 since it would be a configuration error to try to have router 440 adjacencies across IP/ICMP translators those packets should 441 also be silently dropped. 443 ICMPv4 error messages: 445 Destination Unreachable (Type 3): For all codes that are not 446 explicitly listed below, set the Type field to 1, and adjust 447 the ICMP checksum both to take the type change into account 448 and to include the ICMPv6 pseudo-header. 450 Translate the Code field as follows: 452 Code 0, 1 (Net, host unreachable): Set Code value to 0 (no 453 route to destination). 455 Code 2 (Protocol unreachable): Translate to an ICMPv6 456 Parameter Problem (Type 4, Code value 1) and make the 457 Pointer point to the IPv6 Next Header field. 459 Code 3 (Port unreachable): Set Code value to 4 (port 460 unreachable). 462 Code 4 (Fragmentation needed and DF set): Translate to an 463 ICMPv6 Packet Too Big message (Type 2) with Code value 464 set to 0. The MTU field needs to be adjusted for the 465 difference between the IPv4 and IPv6 header sizes, i.e. 466 minimum(advertised MTU+20, MTU_of_IPv6_nexthop, 467 (MTU_of_IPv4_nexthop)+20). Note that if the IPv4 router 468 set the MTU field to zero, i.e., the router does not 469 implement [RFC1191], then the translator MUST use the 470 plateau values specified in [RFC1191] to determine a 471 likely path MTU and include that path MTU in the ICMPv6 472 packet. (Use the greatest plateau value that is less 473 than the returned Total Length field.) 475 Code 5 (Source route failed): Set Code value to 0 (No route 476 to destination). Note that this error is unlikely since 477 source routes are not translated. 479 Code 6,7: Set Code value to 0 (No route to destination). 481 Code 8: Set Code value to 0 (No route to destination). 483 Code 9, 10 (Communication with destination host 484 administratively prohibited): Set Code value to 1 485 (Communication with destination administratively 486 prohibited) 488 Code 11, 12: Set Code value to 0 (no route to destination). 490 Code 13 (Communication Administratively Prohibited): Set 491 Code value to 1 (Communication with destination 492 administratively prohibited). 494 Code 14 (Host Precedence Violation): Silently drop. 496 Code 15 (Precedence cutoff in effect): Set Code value to 1 497 (Communication with destination administratively 498 prohibited). 500 Redirect (Type 5): Single hop message. Silently drop. 502 Alternative Host Address (Type 6): Silently drop. 504 Source Quench (Type 4): Obsoleted in ICMPv6. Silently drop. 506 Time Exceeded (Type 11): Set the Type field to 3, and adjust 507 the ICMP checksum both to take the type change into account 508 and to include the ICMPv6 pseudo-header. The Code field is 509 unchanged. 511 Parameter Problem (Type 12): Set the Type field to 4, and 512 adjust the ICMP checksum both to take the type change into 513 account and to include the ICMPv6 pseudo-header. Translate 514 the Code field as follows: 516 Code 0 (Pointer indicates the error): Set the Code value to 517 0 (Erroneous header field encountered) and update the 518 pointer as defined in Figure 3 (If the Original IPv4 519 Pointer Value is not listed or the Translated IPv6 520 Pointer Value is listed as "n/a", silently drop the 521 packet). 523 Code 1 (Missing a required option): Silently drop 525 Code 2 (Bad length): Set the Code value to 0 (Erroneous 526 header field encountered) and update the pointer as 527 defined in Figure 3 (If the Original IPv4 Pointer Value 528 is not listed or the Translated IPv6 Pointer Value is 529 listed as "n/a", silently drop the packet). 531 Other Code values: Silently drop 533 Unknown ICMPv4 types: Silently drop. 535 | Original IPv4 Pointer Value | Translated IPv6 Pointer Value | 536 +--------------------------------+--------------------------------+ 537 | 0 | Version/IHL | 0 | Version/Traffic Class | 538 | 1 | Type Of Service | 1 | Traffic Class/Flow Label | 539 | 2,3 | Total Length | 4 | Payload Length | 540 | 4,5 | Identification | n/a | | 541 | 6 | Flags/Fragment Offset | n/a | | 542 | 7 | Fragment Offset | n/a | | 543 | 8 | Time to Live | 7 | Hop Limit | 544 | 9 | Protocol | 6 | Next Header | 545 |10,11| Header Checksum | n/a | | 546 |12-15| Source Address | 8 | Source Address | 547 |16-19| Destination Address | 24 | Destination Address | 548 +--------------------------------+--------------------------------+ 550 Figure 3: Pointer value for translating from IPv4 to IPv6 552 ICMP Error Payload: If the received ICMPv4 packet contains an 553 ICMPv4 Extension [RFC4884], the translation of the ICMPv4 554 packet will cause the ICMPv6 packet to change length. When 555 this occurs, the ICMPv6 Extension length attribute MUST be 556 adjusted accordingly (e.g., longer due to the translation 557 from IPv4 to IPv6). If the ICMPv4 Extension exceeds the 558 maximum size of an ICMPv6 message on the outgoing interface, 559 the ICMPv4 extension should be simply truncated. For 560 extensions not defined in [RFC4884], the translator passes 561 the extensions as opaque bit strings and those containing 562 IPv4 address literals will not have those addresses 563 translated to IPv6 address literals; this may cause problems 564 with processing of those ICMP extensions. 566 3.3. Translating ICMPv4 Error Messages into ICMPv6 568 There are some differences between the ICMPv4 and the ICMPv6 error 569 message formats as detailed above. In addition, the ICMP error 570 messages contain the packet in error, which needs to be translated 571 just like a normal IP packet. The translation of this "packet in 572 error" is likely to change the length of the datagram. Thus the 573 Payload Length field in the outer IPv6 header might need to be 574 updated. 576 +-------------+ +-------------+ 577 | IPv4 | | IPv6 | 578 | Header | | Header | 579 +-------------+ +-------------+ 580 | ICMPv4 | | ICMPv6 | 581 | Header | | Header | 582 +-------------+ +-------------+ 583 | IPv4 | ===> | IPv6 | 584 | Header | | Header | 585 +-------------+ +-------------+ 586 | Partial | | Partial | 587 | Transport | | Transport | 588 | Layer | | Layer | 589 | Header | | Header | 590 +-------------+ +-------------+ 592 Figure 4: IPv4-to-IPv6 ICMP Error Translation 594 The translation of the inner IP header can be done by invoking the 595 function that translated the outer IP headers. This process SHOULD 596 stop at the first embedded header and drop the packet if it contains 597 more. 599 3.4. Translator Sending ICMPv4 Error Message 601 If the IPv4 packet is discarded, then the translator SHOULD be able 602 to send back an ICMPv4 error message to the original sender of the 603 packet, unless the discarded packet is itself an ICMPv4 message. The 604 ICMPv4 message, if sent, has a Type value of 3 (Destination 605 Unreachable) and a Code value of 13 (Communication Administratively 606 Prohibited), unless otherwise specified in this document or in 607 [I-D.ietf-behave-v6v4-xlate-stateful]. The translator SHOULD allow 608 an administrator to configure whether the ICMPv4 error messages are 609 sent, rate-limited, or not sent. 611 3.5. Transport-layer Header Translation 613 If the address translation algorithm is not checksum neutral, the 614 recalculation and updating of the transport-layer headers MUST be 615 performed. 617 When a translator receives an unfragmented UDP IPv4 packet and the 618 checksum field is zero, the translator SHOULD compute the missing UDP 619 checksum as part of translating the packet. Also, the translator 620 SHOULD maintain a counter of how many UDP checksums are generated in 621 this manner. 623 When a stateless translator receives the first fragment of a 624 fragmented UDP IPv4 packet and the checksum field is zero, the 625 translator SHOULD drop the packet and generate a system management 626 event specifying at least the IP addresses and port numbers in the 627 packet. When it receives fragments other than the first, it SHOULD 628 silently drop the packet, since there is no port information to log. 630 For stateful translator, the handling of fragmented UDP IPv4 packets 631 with a zero checksum is discussed in 632 [I-D.ietf-behave-v6v4-xlate-stateful] section 3.1. 634 3.6. Knowing when to Translate 636 If the IP/ICMP translator also provides normal forwarding function, 637 and the destination IPv4 address is reachable by a more specific 638 route without translation, the translator MUST forward it without 639 translating it. Otherwise, when an IP/ICMP translator receives an 640 IPv4 datagram addressed to an IPv4 destination representing a host in 641 the IPv6 domain, the packet MUST be translated to IPv6. 643 4. Translating from IPv6 to IPv4 645 When an IP/ICMP translator receives an IPv6 datagram addressed to a 646 destination towards the IPv4 domain, it translates the IPv6 header of 647 the received IPv6 packet into an IPv4 header. The original IPv6 648 header on the packet is removed and replaced by an IPv4 header. 649 Since the ICMPv6 [RFC4443], TCP [RFC0793], and UDP [RFC0768] headers 650 contain checksums that cover the IP header, if the address mapping 651 algorithm is not checksum-neutral, the ICMP and transport-layer 652 headers MUST be updated. The data portion of the packet is left 653 unchanged. The IP/ICMP translator then forwards the packet based on 654 the IPv4 destination address. 656 +-------------+ +-------------+ 657 | IPv6 | | IPv4 | 658 | Header | | Header | 659 +-------------+ +-------------+ 660 | Fragment | | Transport | 661 | Header | ===> | Layer | 662 |(if present) | | Header | 663 +-------------+ +-------------+ 664 | Transport | | | 665 | Layer | ~ Data ~ 666 | Header | | | 667 +-------------+ +-------------+ 668 | | 669 ~ Data ~ 670 | | 671 +-------------+ 673 Figure 5: IPv6-to-IPv4 Translation 675 There are some differences between IPv6 and IPv4 in the area of 676 fragmentation and the minimum link MTU that affect the translation. 677 An IPv6 link has to have an MTU of 1280 bytes or greater. The 678 corresponding limit for IPv4 is 68 bytes. Thus, unless there were 679 special measures, it would not be possible to do end-to-end path MTU 680 discovery when the path includes a translator, since the IPv6 node 681 might receive ICMPv6 "Packet Too Big" messages originated by an IPv4 682 router that report an MTU less than 1280. However, [RFC2460] section 683 5 requires that IPv6 nodes handle such an ICMPv6 "Packet Too Big" 684 message by reducing the path MTU to 1280 and including an IPv6 685 fragment header with each packet. In this case, the translator 686 SHOULD set DF to 0 and take the identification value from the IPv6 687 fragment header when a fragmentation header with (MF=0; Offset=0) is 688 present or set DF to 1 otherwise. This allows end-to-end path MTU 689 discovery across the translator as long as the path MTU is 1280 bytes 690 or greater. When the path MTU drops below the 1280 limit, the IPv6 691 sender will originate 1280-byte packets that will be fragmented by 692 IPv4 routers along the path after being translated to IPv4. 694 The drawback with this scheme is that it is not possible to use PMTU 695 discovery to do optimal UDP fragmentation (as opposed to completely 696 avoiding fragmentation) at the sender, since the presence of an IPv6 697 Fragment header is interpreted that it is okay to fragment the packet 698 on the IPv4 side. Thus if a UDP application wants to send large 699 packets independent of the PMTU, the sender will only be able to 700 determine the path MTU on the IPv6 side of the translator. If the 701 path MTU on the IPv4 side of the translator is smaller, then the IPv6 702 sender will not receive any ICMPv6 "Too Big" errors and cannot adjust 703 the size fragments it is sending. 705 On the other hand, a recent study indicates that only 43.46% of IPv6- 706 capable web servers include an IPv6 fragmentation header in their 707 respond packets after they were sent an ICMPv6 "Packet Too Big" 708 message specifying an MTU<1280 bytes [Stasiewicz]. A workaround to 709 this problem (ICMPv6 "Packet Too Big" message with MTU<1280) is that 710 if there is no fragmentation header in the IPv6 packet, the 711 translator SHOULD set DF to 0 for the packets equal to or smaller 712 than 1280 bytes and set DF to 1 for packets larger than 1280 bytes. 713 In addition, the translator SHOULD take the identification value from 714 the IPv6 fragmentation header if present or generate the 715 identification value otherwise. This avoids the introduction of the 716 path MTU discovery black hole. The header translation defined in the 717 next section uses this method. 719 Other than the special rules for handling fragments and path MTU 720 discovery, the actual translation of the packet header consists of a 721 simple mapping as defined below. Note that ICMPv6 packets require 722 special handling in order to translate the contents of ICMPv6 error 723 messages and also to remove the ICMPv6 pseudo-header checksum. 725 4.1. Translating IPv6 Headers into IPv4 Headers 727 If there is no IPv6 Fragment header, the IPv4 header fields are set 728 as follows: 730 Version: 4 732 Internet Header Length: 5 (no IPv4 options) 734 Type of Service (TOS) Octet: By default, copied from the IPv6 735 Traffic Class (all 8 bits). According to [RFC2474] the semantics 736 of the bits are identical in IPv4 and IPv6. However, in some IPv4 737 environments, these bits might be used with the old semantics of 738 "Type Of Service and Precedence". An implementation of a 739 translator SHOULD provide the ability to ignore the IPv6 traffic 740 class and always set the IPv4 TOS Octet to a specified value. In 741 addition, if the translator is at an administrative boundary, the 742 filtering and update considerations of [RFC2475] may be 743 applicable. 745 Total Length: Payload length value from IPv6 header, plus the size 746 of the IPv4 header. 748 Identification: If the packet size is equal to or smaller than 1280 749 bytes, generate the identification value. If the packet size is 750 greater than 1280 bytes, set Identification All zeros. 752 Flags: The More Fragments (MF) flag is set to zero. If the packet 753 size is equal to or smaller than 1280 bytes, the Don't Fragments 754 (DF) flag is set to zero. If the packet size is greater than 1280 755 bytes, the Don't Fragments (DF) flag is set to one. 757 Fragment Offset: All zeros. 759 Time to Live: Time to Live is derived from Hop Limit value in IPv6 760 header. Since the translator is a router, as part of forwarding 761 the packet it needs to decrement either the IPv6 Hop Limit (before 762 the translation) or the IPv4 TTL (after the translation). As part 763 of decrementing the TTL or Hop Limit the translator (as any 764 router) needs to check for zero and send the ICMPv4 "TTL Exceeded" 765 or ICMPv6 "Hop Limit Exceeded" error. 767 Protocol: For ICMPv6 (58) changed to ICMPv4 (1), otherwise Next 768 Header field copied from IPv6 header. 770 Header Checksum: Computed once the IPv4 header has been created. 772 Source Address: In the stateless mode, which is to say that if the 773 IPv6 source address is within the range of a configured IPv6 774 translation prefix, the IPv4 source address is derived from the 775 IPv6 source address per [I-D.ietf-behave-address-format] section 776 2.1. Note that the original IPv6 source address is an IPv4- 777 translatable address. A workflow example of stateless translation 778 is shown in Appendix of this document. If the translator only 779 supports stateless mode and if the IPv6 source address is not 780 within the range of configured IPv6 prefix(es), the translator 781 SHOULD drop the packet and respond with an ICMPv6 Type=1, Code=5 782 (Destination Unreachable, Source address failed ingress/egress 783 policy). 785 In the stateful mode, which is to say that if the IPv6 source 786 address is not within the range of any configured IPv6 stateless 787 translation prefix, the IPv4 source address and transport-layer 788 source port corresponding to the IPv4-related IPv6 source address 789 and source port are derived from the Binding Information Bases 790 (BIBs) as described in [I-D.ietf-behave-v6v4-xlate-stateful]. 792 In stateless and stateful modes, if the translator gets an illegal 793 source address (e.g. ::1, etc.), the translator SHOULD silently 794 drop the packet. 796 Destination Address: The IPv4 destination address is derived from 797 the IPv6 destination address of the datagram being translated per 798 [I-D.ietf-behave-address-format] section 2.1. Note that the 799 original IPv6 destination address is an IPv4-converted address. 801 If any of an IPv6 Hop-by-Hop Options header, Destination Options 802 header, or Routing header with the Segments Left field equal to zero 803 are present in the IPv6 packet, those IPv6 extension headers MUST be 804 ignored (i.e., there is no attempt to translate the extension 805 headers) and the packet translated normally. However, the Total 806 Length field and the Protocol field is adjusted to "skip" these 807 extension headers. 809 If a Routing header with a non-zero Segments Left field is present 810 then the packet MUST NOT be translated, and an ICMPv6 "parameter 811 problem/erroneous header field encountered" (Type 4/Code 0) error 812 message, with the Pointer field indicating the first byte of the 813 Segments Left field, SHOULD be returned to the sender. 815 If the IPv6 packet contains a Fragment header, the header fields are 816 set as above with the following exceptions: 818 Total Length: Payload length value from IPv6 header, minus 8 for the 819 Fragment header, plus the size of the IPv4 header. 821 Identification: Copied from the low-order 16-bits in the 822 Identification field in the Fragment header. 824 Flags: The More Fragments (MF) flag is copied from the M flag in the 825 Fragment header. The Don't Fragments (DF) flag is set to zero 826 allowing this packet to be fragmented if required by IPv4 routers. 828 Fragment Offset: Copied from the Fragment Offset field in the 829 Fragment header. 831 Protocol: For ICMPv6 (58) changed to ICMPv4 (1), otherwise Next 832 Header field copied from Fragment header. 834 If a translated packet with DF set to 1 will be larger than the MTU 835 of the next-hop interface, then the translator MUST drop the packet 836 and send an ICMPv6 "Packet Too Big" (Type 2/Code 0) error message to 837 the IPv6 host with an adjusted MTU in the ICMPv6 message. 839 4.2. Translating ICMPv6 Headers into ICMPv4 Headers 841 All ICMPv6 messages that are to be translated require that the ICMPv4 842 checksum field be updated as part of the translation since ICMPv6 843 (unlike ICMPv4) includes a pseudo-header in the checksum just like 844 UDP and TCP. 846 In addition all ICMP packets need to have the Type value translated 847 and, for ICMP error messages, the included IP header also needs 848 translation. Note that the IPv6 addresses in the IPv6 header may not 849 be IPv4-translatable addresses and there will be no corresponding 850 IPv4 addresses represented of this IPv6 address. In this case, the 851 translator can do stateful translation. A mechanism by which the 852 translator can instead do stateless translation is left for future 853 work. 855 The actions needed to translate various ICMPv6 messages are: 857 ICMPv6 informational messages: 859 Echo Request and Echo Reply (Type 128 and 129): Adjust the Type 860 values to 8 and 0, respectively, and adjust the ICMP checksum 861 both to take the type change into account and to exclude the 862 ICMPv6 pseudo-header. 864 MLD Multicast Listener Query/Report/Done (Type 130, 131, 132): 865 Single hop message. Silently drop. 867 Neighbor Discover messages (Type 133 through 137): Single hop 868 message. Silently drop. 870 Unknown informational messages: Silently drop. 872 ICMPv6 error messages: 874 Destination Unreachable (Type 1) Set the Type field to 3, and 875 adjust the ICMP checksum both to take the type change into 876 account and to exclude the ICMPv6 pseudo-header. Translate the 877 Code field as follows: 879 Code 0 (no route to destination): Set Code value to 1 (Host 880 unreachable). 882 Code 1 (Communication with destination administratively 883 prohibited): Set Code value to 10 (Communication with 884 destination host administratively prohibited). 886 Code 2 (Beyond scope of source address): Set Code value to 1 887 (Host unreachable). Note that this error is very unlikely 888 since an IPv4-translatable source address is typically 889 considered to have global scope. 891 Code 3 (Address unreachable): Set Code value to 1 (Host 892 unreachable). 894 Code 4 (Port unreachable): Set Code value to 3 (Port 895 unreachable). 897 Other Code values: Silently drop. 899 Packet Too Big (Type 2): Translate to an ICMPv4 Destination 900 Unreachable (Type 3) with Code value equal to 4, and adjust the 901 ICMPv4 checksum both to take the type change into account and 902 to exclude the ICMPv6 pseudo-header. The MTU field needs to be 903 adjusted for the difference between the IPv4 and IPv6 header 904 sizes taking into account whether or not the packet in error 905 includes a Fragment header, i.e. minimum(advertised MTU-20, 906 MTU_of_IPv4_nexthop, (MTU_of_IPv6_nexthop)-20) 908 Time Exceeded (Type 3): Set the Type value to 11, and adjust the 909 ICMPv4 checksum both to take the type change into account and 910 to exclude the ICMPv6 pseudo-header. The Code field is 911 unchanged. 913 Parameter Problem (Type 4): Translate the Type and Code field as 914 follows, and adjust the ICMPv4 checksum both to take the type 915 change into account and to exclude the ICMPv6 pseudo-header. 917 Code 0 (Erroneous header field encountered): Set Type 12, Code 918 0 and update the pointer as defined in Figure 6 (If the 919 Original IPv6 Pointer Value is not listed or the Translated 920 IPv4 Pointer Value is listed as "n/a", silently drop the 921 packet). 923 Code 1 (Unrecognized Next Header type encountered): Translate 924 this to an ICMPv4 protocol unreachable (Type 3, Code 2). 926 Code 2 (Unrecognized IPv6 option encountered): Silently drop. 928 Unknown error messages: Silently drop. 930 | Original IPv6 Pointer Value | Translated IPv4 Pointer Value | 931 +--------------------------------+--------------------------------+ 932 | 0 | Version/Traffic Class | 0 | Version/IHL, Type Of Ser | 933 | 1 | Traffic Class/Flow Label | 1 | Type Of Service | 934 | 2,3 | Flow Label | n/a | | 935 | 4,5 | Payload Length | 2 | Total Length | 936 | 6 | Next Header | 9 | Protocol | 937 | 7 | Hop Limit | 8 | Time to Live | 938 | 8-23| Source Address | 12 | Source Address | 939 |24-39| Destination Address | 16 | Destination Address | 940 +--------------------------------+--------------------------------+ 942 Figure 6: Pointer Value for translating from IPv6 to IPv4 944 ICMP Error Payload: If the received ICMPv6 packet contains an 945 ICMPv6 Extension [RFC4884], the translation of the ICMPv6 946 packet will cause the ICMPv4 packet to change length. When 947 this occurs, the ICMPv6 Extension length attribute MUST be 948 adjusted accordingly (e.g., shorter due to the translation from 949 IPv6 to IPv4). For extensions not defined in [RFC4884], the 950 translator passes the extensions as opaque bit strings and 951 those containing IPv6 address literals will not have those 952 addresses translated to IPv4 address literals; this may cause 953 problems with processing of those ICMP extensions. 955 4.3. Translating ICMPv6 Error Messages into ICMPv4 957 There are some differences between the ICMPv4 and the ICMPv6 error 958 message formats as detailed above. In addition, the ICMP error 959 messages contain the packet in error, which needs to be translated 960 just like a normal IP packet. The translation of this "packet in 961 error" is likely to change the length of the datagram thus the Total 962 Length field in the outer IPv4 header might need to be updated. 964 +-------------+ +-------------+ 965 | IPv6 | | IPv4 | 966 | Header | | Header | 967 +-------------+ +-------------+ 968 | ICMPv6 | | ICMPv4 | 969 | Header | | Header | 970 +-------------+ +-------------+ 971 | IPv6 | ===> | IPv4 | 972 | Header | | Header | 973 +-------------+ +-------------+ 974 | Partial | | Partial | 975 | Transport | | Transport | 976 | Layer | | Layer | 977 | Header | | Header | 978 +-------------+ +-------------+ 980 Figure 7: IPv6-to-IPv4 ICMP Error Translation 982 The translation of the inner IP header can be done by invoking the 983 function that translated the outer IP headers. This process SHOULD 984 stop at first embedded header and drop the packet if it contains 985 more. Note that the IPv6 addresses in the IPv6 header may not be 986 IPv4-translatable addresses and there will be no corresponding IPv4 987 addresses. In this case, the translator can do stateful translation. 988 A mechanism by which the translator can instead do stateless 989 translation is left for future work. 991 4.4. Translator Sending ICMPv6 Error Message 993 If the IPv6 packet is discarded, then the translator SHOULD be able 994 to send back an ICMPv6 error message to the original sender of the 995 packet, unless the discarded packet is itself an ICMPv6 message. 997 If the ICMPv6 error message is being sent because the IPv6 source 998 address is not an IPv4-translatable address and the translator is 999 stateless, the ICMPv6 message, if sent, has a Type value 1 and Code 1000 value 5 (Source address failed ingress/egress policy). In other 1001 cases, the ICMPv6 message has a Type value of 1 (Destination 1002 Unreachable) and a Code value of 1 (Communication with destination 1003 administratively prohibited), unless otherwise specified in this 1004 document or [I-D.ietf-behave-v6v4-xlate-stateful]. The translator 1005 SHOULD allow an administrator to configure whether the ICMPv6 error 1006 messages are sent, rate-limited, or not sent. 1008 4.5. Transport-layer Header Translation 1010 If the address translation algorithm is not checksum neutral, the 1011 recalculation and updating of the transport-layer headers MUST be 1012 performed. 1014 4.6. Knowing when to Translate 1016 If the IP/ICMP translator also provides a normal forwarding function, 1017 and the destination address is reachable by a more specific route 1018 without translation, the router MUST forward it without translating 1019 it. When an IP/ICMP translator receives an IPv6 datagram addressed 1020 to an IPv6 address representing a host in the IPv4 domain, the IPv6 1021 packet MUST be translated to IPv4. 1023 5. IANA Considerations 1025 This memo adds no new IANA considerations. 1027 Note to RFC Editor: This section will have served its purpose if it 1028 correctly tells IANA that no new assignments or registries are 1029 required, or if those assignments or registries are created during 1030 the RFC publication process. From the author's perspective, it may 1031 therefore be removed upon publication as an RFC at the RFC Editor's 1032 discretion. 1034 6. Security Considerations 1036 The use of stateless IP/ICMP translators does not introduce any new 1037 security issues beyond the security issues that are already present 1038 in the IPv4 and IPv6 protocols and in the routing protocols that are 1039 used to make the packets reach the translator. 1041 There are potential issues that might arise by deriving an IPv4 1042 address from an IPv6 address - particularly addresses like broadcast 1043 or loopback addresses and the non IPv4-translatable IPv6 addresses, 1044 etc. The [I-D.ietf-behave-address-format] addresses these issues. 1046 As the Authentication Header [RFC4302] is specified to include the 1047 IPv4 Identification field and the translating function is not able to 1048 always preserve the Identification field, it is not possible for an 1049 IPv6 endpoint to verify the AH on received packets that have been 1050 translated from IPv4 packets. Thus AH does not work through a 1051 translator. 1053 Packets with ESP can be translated since ESP does not depend on 1054 header fields prior to the ESP header. Note that ESP transport mode 1055 is easier to handle than ESP tunnel mode; in order to use ESP tunnel 1056 mode, the IPv6 node needs to be able to generate an inner IPv4 header 1057 when transmitting packets and remove such an IPv4 header when 1058 receiving packets. 1060 7. Acknowledgements 1062 This is under development by a large group of people. Those who have 1063 posted to the list during the discussion include Andrew Sullivan, 1064 Andrew Yourtchenko, Brian Carpenter, Dan Wing, Dave Thaler, Ed 1065 Jankiewicz, Hiroshi Miyata, Iljitsch van Beijnum, Jari Arkko, Jerry 1066 Huang, John Schnizlein, Jouni Korhonen, Kentaro Ebisawa, Kevin Yin, 1067 Magnus Westerlund, Marcelo Bagnulo Braun, Margaret Wasserman, 1068 Masahito Endo, Phil Roberts, Philip Matthews, Reinaldo Penno, Remi 1069 Denis-Courmont, Remi Despres, Senthil Sivakumar, Simon Perreault and 1070 Zen Cao. 1072 8. Appendix: Stateless translation workflow example 1074 A stateless translation workflow example is depicted in the following 1075 figure. The documentation address blocks 2001:DB8::/32 [RFC3849], 1076 192.0.2.0/24 and 198.51.100.0/24 [RFC5737] are used in this example. 1078 +--------------+ +--------------+ 1079 | IPv4 network | | IPv6 network | 1080 | | +-------+ | | 1081 | +----+ |-----| XLATE |---- | +----+ | 1082 | | H4 |-----| +-------+ |--| H6 | | 1083 | +----+ | | +----+ | 1084 +--------------+ +--------------+ 1086 Figure 8 1088 A translator (XLATE) connects the IPv6 network to the IPv4 network. 1089 This XLATE uses the Network Specific Prefix (NSP) 2001:DB8:100::/40 1090 defined in [I-D.ietf-behave-address-format] to represent IPv4 1091 addresses in the IPv6 address space (IPv4-converted addresses) and to 1092 represent IPv6 addresses (IPv4-translatable addresses) in the IPv4 1093 address space. In this example, 192.0.2.0/24 is the IPv4 block of 1094 the corresponding IPv4-translatable addresses. 1096 Based on the address mapping rule, the IPv6 node H6 has an IPv4- 1097 translatable IPv6 address 2001:DB8:1C0:2:21:: (address mapping from 1098 192.0.2.33). The IPv4 node H4 has IPv4 address 198.51.100.2. 1100 The IPv6 routing is configured in such a way that the IPv6 packets 1101 addressed to a destination address in 2001:DB8:100::/40 are routed to 1102 the IPv6 interface of the XLATE. 1104 The IPv4 routing is configured in such a way that the IPv4 packets 1105 addressed to a destination address in 192.0.2.0/24 are routed to the 1106 IPv4 interface of the XLATE. 1108 8.1. H6 establishes communication with H4 1110 The steps by which H6 establishes communication with H4 are: 1112 1. H6 performs the destination address mapping, so the IPv4- 1113 converted address 2001:DB8:1C6:3364:200:: is formed from 1114 198.51.100.2 based on the address mapping algorithm 1115 [I-D.ietf-behave-address-format]. 1117 2. H6 sends a packet to H4. The packet is sent from a source 1118 address 2001:DB8:1C0:2:21:: to a destination address 2001:DB8: 1119 1C6:3364:200::. 1121 3. The packet is routed to the IPv6 interface of the XLATE (since 1122 IPv6 routing is configured that way). 1124 4. The XLATE receives the packet and performs the following actions: 1126 * The XLATE translates the IPv6 header into an IPv4 header using 1127 the IP/ICMP Translation Algorithm defined in this document. 1129 * The XLATE includes 192.0.2.33 as source address in the packet 1130 and 198.51.100.2 as destination address in the packet. Note 1131 that 192.0.2.33 and 198.51.100.2 are extracted directly from 1132 the source IPv6 address 2001:DB8:1C0:2:21:: (IPv4-translatable 1133 address) and destination IPv6 address 2001:DB8:1C6:3364:200:: 1134 (IPv4-converted address) of the received IPv6 packet that is 1135 being translated. 1137 5. The XLATE sends the translated packet out its IPv4 interface and 1138 the packet arrives at H4. 1140 6. H4 node responds by sending a packet with destination address 1141 192.0.2.33 and source address 198.51.100.2. 1143 7. The packet is routed to the IPv4 interface of the XLATE (since 1144 IPv4 routing is configured that way). The XLATE performs the 1145 following operations: 1147 * The XLATE translates the IPv4 header into an IPv6 header using 1148 the IP/ICMP Translation Algorithm defined in this document. 1150 * The XLATE includes 2001:DB8:1C0:2:21:: as destination address 1151 in the packet and 2001:DB8:1C6:3364:200:: as source address in 1152 the packet. Note that 2001:DB8:1C0:2:21:: and 2001:DB8:1C6: 1153 3364:200:: are formed directly from the destination IPv4 1154 address 192.0.2.33 and source IPv4 address 198.51.100.2 of the 1155 received IPv4 packet that is being translated. 1157 8. The translated packet is sent out the IPv6 interface to H6. 1159 The packet exchange between H6 and H4 continues until the session is 1160 finished. 1162 8.2. H4 establishes communication with H6 1164 The steps by which H4 establishes communication with H6 are: 1166 1. H4 performs the destination address mapping, so 192.0.2.33 is 1167 formed from IPv4-translatable address 2001:DB8:1C0:2:21:: based 1168 on the address mapping algorithm 1169 [I-D.ietf-behave-address-format]. 1171 2. H4 sends a packet to H6. The packet is sent from a source 1172 address 198.51.100.2 to a destination address 192.0.2.33. 1174 3. The packet is routed to the IPv6 interface of the XLATE (since 1175 IPv6 routing is configured that way). 1177 4. The XLATE receives the packet and performs the following actions: 1179 * The XLATE translates the IPv4 header into an IPv6 header using 1180 the IP/ICMP Translation Algorithm defined in this document. 1182 * The XLATE includes 2001:DB8:1C6:3364:200:: as source address 1183 in the packet and 2001:DB8:1C0:2:21:: as destination address 1184 in the packet. Note that 2001:DB8:1C6:3364:200:: (IPv4- 1185 converted address) and 2001:DB8:1C0:2:21:: (IPv4-translatable 1186 address) are obtained directly from the source IPv4 address 1187 198.51.100.2 and destination IPv4 address 192.0.2.33 of the 1188 received IPv4 packet that is being translated. 1190 5. The XLATE sends the translated packet out its IPv6 interface and 1191 the packet arrives at H6. 1193 6. H6 node responds by sending a packet with destination address 1194 2001:DB8:1C6:3364:200:: and source address 2001:DB8:1C0:2:21::. 1196 7. The packet is routed to the IPv6 interface of the XLATE (since 1197 IPv6 routing is configured that way). The XLATE performs the 1198 following operations: 1200 * The XLATE translates the IPv6 header into an IPv4 header using 1201 the IP/ICMP Translation Algorithm defined in this document. 1203 * The XLATE includes 198.51.100.2 as destination address in the 1204 packet and 192.0.2.33 as source address in the packet. Note 1205 that 198.51.100.2 and 192.0.2.33 are formed directly from the 1206 destination IPv6 address 2001:DB8:1C6:3364:200:: and source 1207 IPv6 address 2001:DB8:1C0:2:21:: of the received IPv6 packet 1208 that is being translated. 1210 8. The translated packet is sent out the IPv4 interface to H4. 1212 The packet exchange between H4 and H6 continues until the session 1213 finished. 1215 9. References 1217 9.1. Normative References 1219 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1220 August 1980. 1222 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1223 September 1981. 1225 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1226 RFC 792, September 1981. 1228 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1229 RFC 793, September 1981. 1231 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1232 RFC 1812, June 1995. 1234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1235 Requirement Levels", BCP 14, RFC 2119, March 1997. 1237 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1238 (IPv6) Specification", RFC 2460, December 1998. 1240 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1241 (SIIT)", RFC 2765, February 2000. 1243 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1244 Architecture", RFC 4291, February 2006. 1246 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1247 Message Protocol (ICMPv6) for the Internet Protocol 1248 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1250 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 1251 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 1252 April 2007. 1254 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1255 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1256 RFC 5382, October 2008. 1258 9.2. Informative References 1260 [Dongjin] Lee, D., "Email to the behave mailing list (http:// 1261 www.ietf.org/mail-archive/web/behave/current/ 1262 msg06856.html)", Sept 2009. 1264 [I-D.ietf-behave-address-format] 1265 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 1266 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 1267 draft-ietf-behave-address-format-05 (work in progress), 1268 March 2010. 1270 [I-D.ietf-behave-v6v4-framework] 1271 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1272 IPv4/IPv6 Translation", 1273 draft-ietf-behave-v6v4-framework-07 (work in progress), 1274 February 2010. 1276 [I-D.ietf-behave-v6v4-xlate-stateful] 1277 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 1278 NAT64: Network Address and Protocol Translation from IPv6 1279 Clients to IPv4 Servers", 1280 draft-ietf-behave-v6v4-xlate-stateful-09 (work in 1281 progress), March 2010. 1283 [Miller] Miller, G., "Email to the ngtrans mailing list 1284 (http://www.mail-archive.com/ipv6@ietf.org/ 1285 msg10159.html)", March 1999. 1287 [RFC0879] Postel, J., "TCP maximum segment size and related topics", 1288 RFC 879, November 1983. 1290 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1291 November 1990. 1293 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1294 "Definition of the Differentiated Services Field (DS 1295 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1296 December 1998. 1298 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1299 and W. Weiss, "An Architecture for Differentiated 1300 Services", RFC 2475, December 1998. 1302 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1303 Listener Discovery (MLD) for IPv6", RFC 2710, 1304 October 1999. 1306 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 1307 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1308 February 2000. 1310 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 1311 "IANA Guidelines for IPv4 Multicast Address Assignments", 1312 RFC 3171, August 2001. 1314 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 1315 Addresses", RFC 3307, August 2002. 1317 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 1318 Listener Discovery (MLD) Protocol", RFC 3590, 1319 September 2003. 1321 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1322 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1324 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 1325 Reserved for Documentation", RFC 3849, July 2004. 1327 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1328 December 2005. 1330 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 1331 Reserved for Documentation", RFC 5737, January 2010. 1333 [Stasiewicz] 1334 Stasiewicz, B., "Email to the behave mailing list (http:// 1335 www.ietf.org/mail-archive/web/behave/current/ 1336 msg08093.html)", Feb 2010. 1338 Authors' Addresses 1340 Xing Li 1341 CERNET Center/Tsinghua University 1342 Room 225, Main Building, Tsinghua University 1343 Beijing, 100084 1344 China 1346 Phone: +86 10-62785983 1347 Email: xing@cernet.edu.cn 1349 Congxiao Bao 1350 CERNET Center/Tsinghua University 1351 Room 225, Main Building, Tsinghua University 1352 Beijing, 100084 1353 China 1355 Phone: +86 10-62785983 1356 Email: congxiao@cernet.edu.cn 1358 Fred Baker 1359 Cisco Systems 1360 Santa Barbara, California 93117 1361 USA 1363 Phone: +1-408-526-4257 1364 Email: fred@cisco.com