idnits 2.17.1 draft-ietf-behave-v6v4-xlate-09.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 7 instances 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 (February 11, 2010) is 5181 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 879 (Obsoleted by RFC 7805, RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2766 (Obsoleted by RFC 4966) == Outdated reference: A later version (-10) exists of draft-ietf-behave-address-format-04 == Outdated reference: A later version (-10) exists of draft-ietf-behave-v6v4-framework-06 == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-08 -- Obsolete informational reference (is this intentional?): RFC 3171 (Obsoleted by RFC 5771) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 3 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: August 15, 2010 Cisco Systems 7 February 11, 2010 9 IP/ICMP Translation Algorithm 10 draft-ietf-behave-v6v4-xlate-09 12 Abstract 14 This document specifies an update to 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) for both stateless and stateful modes. 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 August 15, 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 . . . . . . . . . . . . . . . 6 75 1.4. Path MTU Discovery and Fragmentation . . . . . . . . . . . 6 76 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 3. Translating from IPv4 to IPv6 . . . . . . . . . . . . . . . . 7 78 3.1. Translating IPv4 Headers into IPv6 Headers . . . . . . . . 8 79 3.2. Translating ICMPv4 Headers into ICMPv6 Headers . . . . . . 11 80 3.3. Translating ICMPv4 Error Messages into ICMPv6 . . . . . . 14 81 3.4. Translator Sending ICMPv4 Error Message . . . . . . . . . 15 82 3.5. Transport-layer Header Translation . . . . . . . . . . . . 15 83 3.6. Knowing when to Translate . . . . . . . . . . . . . . . . 16 84 4. Translating from IPv6 to IPv4 . . . . . . . . . . . . . . . . 16 85 4.1. Translating IPv6 Headers into IPv4 Headers . . . . . . . . 18 86 4.2. Translating ICMPv6 Headers into ICMPv4 Headers . . . . . . 20 87 4.3. Translating ICMPv6 Error Messages into ICMPv4 . . . . . . 23 88 4.4. Translator Sending ICMPv6 Error Message . . . . . . . . . 24 89 4.5. Transport-layer Header Translation . . . . . . . . . . . . 24 90 4.6. Knowing when to Translate . . . . . . . . . . . . . . . . 24 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 29 98 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 99 9.2. Informative References . . . . . . . . . . . . . . . . . . 30 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 102 1. Introduction and Motivation 104 This document is a product of the 2008-2010 effort to define a 105 replacement for NAT-PT [RFC2766]. It is an update to and directly 106 derivative from Erik Nordmark's [RFC2765], which similarly provides 107 both stateless and stateful translation between IPv4 [RFC0791] and 108 IPv6 [RFC2460], and between ICMPv4 [RFC0792] and ICMPv6 [RFC4443]. 109 The original document was a product of the NGTRANS working group. 111 The transition mechanisms specified in [RFC4213] handle the case of 112 dual IPv4/IPv6 hosts interoperating with both dual IPv4/IPv6 hosts 113 and IPv4-only hosts, which is needed early in the transition to IPv6. 114 The dual IPv4/IPv6 hosts are assigned both one or more IPv4 and one 115 or more IPv6 addresses. The number of available globally unique IPv4 116 addresses is becoming smaller and smaller as the Internet grows; we 117 expect that there will be a desire to take advantage of the large 118 IPv6 address space and not require that every new Internet node have 119 a permanently and full assigned IPv4 address. Indeed, due to the 120 IPv4 address depletion problem, it is desirable that a single IPv4 121 address needs to be shared via transport port multiplexing for 122 different IPv6 nodes when they communicate with other IPv4 hosts. 124 SIIT [RFC2765] was designed for the case of small networks (e.g., a 125 single subnet) and for a site that has IPv6-only hosts in a dual 126 IPv4/IPv6 network. This use case assumes a mechanism for IPv6 nodes 127 to acquire a temporary address from the pool of IPv4 addresses. 128 However, SIIT is not useful in the case when the IPv6 nodes need to 129 acquire temporary IPv4 addresses from a "distant" SIIT box operated 130 by a different administration, or require that the IPv6 Internet 131 contain routes for IPv4-mapped addresses (the latter is considered to 132 be a very bad idea due to the size of the IPv4 routing table that 133 would potentially be injected into IPv6 routing in the form of IPv4- 134 mapped addresses.) 136 Furthermore, in SIIT [RFC2765], an IPv6-only node that works through 137 SIIT translators needs some modifications beyond a normal IPv6-only 138 node. These modifications are not required in this document, since 139 normal IPv6 addresses can be used in the IPv6 end nodes. 141 A detailed discussion of translation scenarios is presented in 142 [I-D.ietf-behave-v6v4-framework], while the technical specification 143 of the translation algorithm itself is covered in this document. 145 1.1. IPv4-IPv6 Translation Model 147 The translation model is consists of two or more network domains 148 connected by one or more IP/ICMP translators (XLATEs) as shown in 149 Figure 1. One of those networks either routes IPv4 but not IPv6, or 150 contains some hosts that only implement IPv4 or have IPv4-only 151 applications (even if the host and the network support IPv6). The 152 other network either routes IPv6 but not IPv4, or contains some hosts 153 that only implement IPv6 or has IPv6-only applications. Both 154 networks contain clients, servers, and peers. A network domain may 155 also consist of a single host. DNS servers include DNS64 and DNS46, 156 while DNS64 translates A record to AAAA record and DNS46 translates 157 AAAA record to A record. 159 -------- -------- 160 // IPv4 \\ // IPv6 \\ 161 / Domain \ / Domain \ 162 / +-----+ +--+ \ 163 | |XLATE| |S2| | Sn: Servers 164 | +--+ +-----+ +--+ | Hn: Clients 165 | |S1| +-----+ | 166 | +--+ | DNS | +--+ | XLATE: IPv4/IPv6 Translator 167 \ +--+ +-----+ |H2| / DNS: DNS64/DNS46 168 \ |H1| / \ +--+ / 169 \\ +--+ // \\ // 170 -------- -------- 172 Figure 1: IPv4-IPv6 Translation Model 174 The general IPv4/IPv6 translation framework is described in 175 [I-D.ietf-behave-v6v4-framework]. This document specifies the 176 translation algorithms between IPv4 packets and IPv6 packets. The 177 mapping algorithms between IPv4 addresses and IPv6 addresses in the 178 packet headers are specified in [I-D.ietf-behave-address-format]. 180 1.2. Applicability and Limitations 182 The use of this translation algorithm assumes that the IPv6 network 183 is somehow well-connected i.e., when an IPv6 node wants to 184 communicate with another IPv6 node there is an IPv6 path between 185 them. The IPv4 network is also assumed to be well-connected. 186 Various tunneling schemes exist that can provide such paths, but 187 those mechanisms and their use is outside the scope of this document 188 and [RFC2765]. 190 As with [RFC2765], the translating function specified in this 191 document does not translate any IPv4 options and it does not 192 translate IPv6 routing headers, hop-by-hop extension headers, 193 destination options headers or source routing headers. 195 The issues and algorithms in the translation of datagrams containing 196 TCP segments are described in [RFC5382]. The considerations of that 197 document are applicable in this case as well. 199 Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e., 200 the UDP checksum field is zero) are not of significant use in the 201 Internet [Miller][Dongjin] and will not be translated by the IP/ICMP 202 translator. 204 IPv4 multicast addresses [RFC3171] cannot be mapped to IPv6 multicast 205 addresses [RFC3307] based on the unicast mapping rule. However, if 206 multicast address mapping rule is defined, the IP/ICMP header 207 translation aspect of this document works. 209 1.3. Stateless vs. Stateful Mode 211 An IP/ICMP translator has two possible modes of operation: stateless 212 and stateful [I-D.ietf-behave-v6v4-framework]. In both cases, we 213 assume that a system (a node or an application) that has an IPv4 214 address but not an IPv6 address is communicating with a system that 215 has an IPv6 address but no IPv4 address, or that the two systems do 216 not have contiguous routing connectivity and hence are forced to have 217 their communications translated. 219 In the stateless mode, a specific IPv6 address range will represent 220 IPv4 systems (IPv4-converted addresses), and the IPv6 systems have 221 addresses (IPv4-translatable addresses) that can be algorithmically 222 mapped to a subset of the service provider's IPv4 addresses. In 223 general, there is no need to concern oneself with translation tables, 224 as the IPv4 and IPv6 counterparts are algorithmically related. 226 In the stateful mode, a specific IPv6 address range will represent 227 IPv4 systems (IPv4-converted addresses), but the IPv6 systems may use 228 any [RFC4291] addresses except in that range. In this case, a 229 translation table is required to bind the IPv6 systems' addresses to 230 the IPv4 addresses maintained in the translator. 232 The address translation mechanisms for the stateless and the stateful 233 translations are defined in [I-D.ietf-behave-address-format]. 235 1.4. Path MTU Discovery and Fragmentation 237 Due to the different sizes of the IPv4 and IPv6 header, which are 20+ 238 octets and 40 octets respectively, handling the maximum packet size 239 is critical for the operation of the IPv4/IPv6 translator. There are 240 three mechanisms to handle this issue: path MTU discovery (PMTUD), 241 fragmentation, and transport-layer negotiation such as the TCP MSS 242 option [RFC0879]. Note that the translator MUST behave as a router, 243 i.e. the translator MUST send a "Packet Too Big" error message or 244 fragment the packet when the packet size exceeds the MTU of the next 245 hop interface. 247 "Don't Fragment", ICMP "Packet Too Big", and packet fragmentation are 248 discussed in sections 3 and 4 of this document. The reassembling of 249 fragmented packets in the stateful translator is discussed in 250 [I-D.ietf-behave-v6v4-xlate-stateful], since it requires state 251 maintenance in the translator. 253 2. Conventions 255 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 256 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 257 document are to be interpreted as described in [RFC2119]. 259 3. Translating from IPv4 to IPv6 261 When an IP/ICMP translator receives an IPv4 datagram addressed to a 262 destination towards the IPv6 domain, it translates the IPv4 header of 263 that packet into an IPv6 header. The original IPv4 header on the 264 packet is removed and replaced by an IPv6 header. Since the ICMPv6 265 [RFC4443], TCP [RFC0793] and UDP [RFC0768] headers contain checksums 266 that cover IP header information, if the address mapping algorithm is 267 not checksum-neutral, the ICMPv6 and transport-layer headers MUST be 268 updated. The data portion of the packet is left unchanged. The IP/ 269 ICMP translator then forwards the packet based on the IPv6 270 destination address. 272 +-------------+ +-------------+ 273 | IPv4 | | IPv6 | 274 | Header | | Header | 275 +-------------+ +-------------+ 276 | Transport | | Fragment | 277 | Layer | ===> | Header | 278 | Header | | (if needed) | 279 +-------------+ +-------------+ 280 | | | Transport | 281 ~ Data ~ | Layer | 282 | | | Header | 283 +-------------+ +-------------+ 284 | | 285 ~ Data ~ 286 | | 287 +-------------+ 289 Figure 2: IPv4-to-IPv6 Translation 291 One of the differences between IPv4 and IPv6, is that in IPv6, path 292 MTU discovery is mandatory but it is optional in IPv4. This implies 293 that IPv6 routers will never fragment a packet - only the sender can 294 do fragmentation. 296 When IPv4 node performs path MTU discovery (by setting the Don't 297 Fragment (DF) bit in the header), path MTU discovery can operate end- 298 to-end, i.e., across the translator. In this case either IPv4 or 299 IPv6 routers (including the translator) might send back ICMP "Packet 300 Too Big" messages to the sender. When the IPv6 routers send these 301 ICMPv6 errors they will pass through a translator that will translate 302 the ICMPv6 error to a form that the IPv4 sender can understand. As a 303 result, an IPv6 fragment header is only included if the IPv4 packet 304 is already fragmented. 306 However, when the IPv4 sender does not set the Don't Fragment (DF) 307 bit, the translator has to ensure that the packet does not exceed the 308 path MTU on the IPv6 side. This is done by fragmenting the IPv4 309 packet so that it fits in 1280-byte IPv6 packets, since that is the 310 minimum IPv6 MTU. Also, when the IPv4 sender does not set the DF bit 311 the translator MUST always include an IPv6 fragment header to 312 indicate that the sender allows fragmentation. 314 The rules in section 3.1 ensure that when packets are fragmented, 315 either by the sender or by IPv4 routers, the low-order 16 bits of the 316 fragment identification are carried end-to-end, ensuring that packets 317 are correctly reassembled. In addition, the rules in section 3.1 use 318 the presence of an IPv6 fragment header to indicate that the sender 319 might not be using path MTU discovery (i.e., the packet should not 320 have the DF flag set should it later be translated back to IPv4). 322 Other than the special rules for handling fragments and path MTU 323 discovery, the actual translation of the packet header consists of a 324 simple mapping as defined below. Note that ICMPv4 packets require 325 special handling in order to translate the content of ICMPv4 error 326 messages and also to add the ICMPv6 pseudo-header checksum. 328 3.1. Translating IPv4 Headers into IPv6 Headers 330 If the DF flag is not set and the IPv4 packet will result in an IPv6 331 packet larger than 1280 bytes, the packet MUST be fragmented so the 332 resulting IPv6 packet (with Fragment header added to each fragment) 333 will be less than or equal to 1280 bytes. For example, if the packet 334 is fragmented prior to the translation, the IPv4 packets must be 335 fragmented so that their length, excluding the IPv4 header, is at 336 most 1232 bytes (1280 minus 40 for the IPv6 header and 8 for the 337 Fragment header). The resulting fragments are then translated 338 independently using the logic described below. 340 If the DF bit is set and the MTU of the next-hop interface is less 341 than the total length value of the IPv4 packet plus 20, the 342 translator MUST send an ICMPv4 "Fragmentation Needed" error message 343 to the IPv4 source address. 345 If the DF bit is set and the packet is not a fragment (i.e., the MF 346 flag is not set and the Fragment Offset is equal to zero) then the 347 translator SHOULD NOT add a Fragment header to the resulting packet. 348 The IPv6 header fields are set as follows: 350 Version: 6 352 Traffic Class: By default, copied from IP Type Of Service (TOS) 353 octet. According to [RFC2474] the semantics of the bits are 354 identical in IPv4 and IPv6. However, in some IPv4 environments 355 these fields might be used with the old semantics of "Type Of 356 Service and Precedence". An implementation of a translator SHOULD 357 provide the ability to ignore the IPv4 TOS and always set the IPv6 358 traffic class (TC) to zero. In addition, if the translator is at 359 an administrative boundary, the filtering and update 360 considerations of [RFC2475] may be applicable. 362 Flow Label: 0 (all zero bits) 364 Payload Length: Total length value from IPv4 header, minus the size 365 of the IPv4 header and IPv4 options, if present. 367 Next Header: For ICMPv4 (1) changed to ICMPv6 (58), otherwise 368 protocol field copied from IPv4 header. 370 Hop Limit: The hop limit is derived from the TTL value in the IPv4 371 header. Since the translator is a router, as part of forwarding 372 the packet it needs to decrement either the IPv4 TTL (before the 373 translation) or the IPv6 Hop Limit (after the translation). As 374 part of decrementing the TTL or Hop Limit the translator (as any 375 router) needs to check for zero and send the ICMPv4 "TTL Exceeded" 376 or ICMPv6 "Hop Limit Exceeded" error. 378 Source Address: The IPv4-converted address derived from the IPv4 379 source address per [I-D.ietf-behave-address-format] section 2.1. 381 If the translator gets an illegal source address (e.g. 0.0.0.0, 382 127.0.0.1, etc.), the translator SHOULD silently drop the packet 383 (as discussed in Section 5.3.7 of [RFC1812]). 385 Destination Address: In the stateless mode, which is to say that if 386 the IPv4 destination address is within a range of configured IPv4 387 stateless translation prefix, the IPv6 destination address is the 388 IPv4-translatable address derived from the IPv4 destination 389 address per [I-D.ietf-behave-address-format] section 2.1. A 390 workflow example of stateless translation is shown in Appendix of 391 this document. 393 In the stateful mode, which is to say that if the IPv4 destination 394 address is not within the range of any configured IPv4 stateless 395 translation prefix, the IPv6 destination address and corresponding 396 transport-layer destination port are derived from the Binding 397 Information Bases (BIBs) reflecting current session state in the 398 translator as described in [I-D.ietf-behave-v6v4-xlate-stateful]. 400 If any IPv4 options are present in the IPv4 packet, the IPv4 options 401 MUST be ignored (i.e., there is no attempt to translate the options) 402 and the packet translated normally. However, if an unexpired source 403 route option is present then the packet MUST instead be discarded, 404 and an ICMPv4 "Destination Unreachable/Source Route Failed" (Type 405 3/Code 5) error message SHOULD be returned to the sender. 407 If there is a need to add a Fragment header (the DF bit is not set or 408 the packet is a fragment) the header fields are set as above with the 409 following exceptions: 411 IPv6 fields: 413 Payload Length: Total length value from IPv4 header, plus 8 for 414 the fragment header, minus the size of the IPv4 header and IPv4 415 options, if present. 417 Next Header: Fragment header (44). 419 Fragment header fields: 421 Next Header: For ICMPv4 (1) changed to ICMPv6 (58), otherwise 422 protocol field copied from IPv4 header. 424 Fragment Offset: Fragment Offset copied from the IPv4 header. 426 M flag: More Fragments bit copied from the IPv4 header. 428 Identification: The low-order 16 bits copied from the 429 Identification field in the IPv4 header. The high-order 16 430 bits set to zero. 432 3.2. Translating ICMPv4 Headers into ICMPv6 Headers 434 All ICMPv4 messages that are to be translated require that the ICMPv6 435 checksum field be calculated as part of the translation since ICMPv6, 436 unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP. 438 In addition, all ICMPv4 packets need to have the Type value 439 translated and, for ICMPv4 error messages, the included IP header 440 also needs translation. 442 The actions needed to translate various ICMPv4 messages are as 443 follows: 445 ICMPv4 query messages: 447 Echo and Echo Reply (Type 8 and Type 0): Adjust the Type values 448 to 128 and 129, respectively, and adjust the ICMP checksum both 449 to take the type change into account and to include the ICMPv6 450 pseudo-header. 452 Information Request/Reply (Type 15 and Type 16): Obsoleted in 453 ICMPv6. Silently drop. 455 Timestamp and Timestamp Reply (Type 13 and Type 14): Obsoleted in 456 ICMPv6. Silently drop. 458 Address Mask Request/Reply (Type 17 and Type 18): Obsoleted in 459 ICMPv6. Silently drop. 461 ICMP Router Advertisement (Type 9): Single hop message. Silently 462 drop. 464 ICMP Router Solicitation (Type 10): Single hop message. Silently 465 drop. 467 Unknown ICMPv4 types: Silently drop. 469 IGMP messages: While the MLD messages [RFC2710][RFC3590][RFC3810] 470 are the logical IPv6 counterparts for the IPv4 IGMP messages 471 all the "normal" IGMP messages are single-hop messages and 472 should be silently dropped by the translator. Other IGMP 473 messages might be used by multicast routing protocols and, 474 since it would be a configuration error to try to have router 475 adjacencies across IP/ICMP translators those packets should 476 also be silently dropped. 478 ICMPv4 error messages: 480 Destination Unreachable (Type 3): For all codes that are not 481 explicitly listed below, set the Type field to 1, and adjust 482 the ICMP checksum both to take the type change into account 483 and to include the ICMPv6 pseudo-header. 485 Translate the Code field as follows: 487 Code 0, 1 (Net, host unreachable): Set Code value to 0 (no 488 route to destination). 490 Code 2 (Protocol unreachable): Translate to an ICMPv6 491 Parameter Problem (Type 4, Code value 1) and make the 492 Pointer point to the IPv6 Next Header field. 494 Code 3 (Port unreachable): Set Code value to 4 (port 495 unreachable). 497 Code 4 (Fragmentation needed and DF set): Translate to an 498 ICMPv6 Packet Too Big message (Type 2) with Code value 499 set to 0. The MTU field needs to be adjusted for the 500 difference between the IPv4 and IPv6 header sizes, i.e. 501 minimum(advertised MTU+20, MTU_of_IPv6_nexthop, 502 (MTU_of_IPv4_nexthop)+20). Note that if the IPv4 router 503 did not set the MTU field (zero), i.e., the router does 504 not implement [RFC1191], then the translator MUST use the 505 plateau values specified in [RFC1191] to determine a 506 likely path MTU and include that path MTU in the ICMPv6 507 packet. (Use the greatest plateau value that is less 508 than the returned Total Length field.) 510 Code 5 (Source route failed): Set Code value to 0 (No route 511 to destination). Note that this error is unlikely since 512 source routes are not translated. 514 Code 6,7: Set Code value to 0 (No route to destination). 516 Code 8: Set Code value to 0 (No route to destination). 518 Code 9, 10 (Communication with destination host 519 administratively prohibited): Set Code value to 1 520 (Communication with destination administratively 521 prohibited) 523 Code 11, 12: Set Code value to 0 (no route to destination). 525 Code 13 (Communication Administratively Prohibited): Set 526 Code value to 1 (Communication with destination 527 administratively prohibited). 529 Code 14 (Host Precedence Violation): Silently drop. 531 Code 15 (Precedence cutoff in effect): Set Code value to 1 532 (Communication with destination administratively 533 prohibited). 535 Redirect (Type 5): Single hop message. Silently drop. 537 Alternative Host Address (Type 6): Silently drop. 539 Source Quench (Type 4): Obsoleted in ICMPv6. Silently drop. 541 Time Exceeded (Type 11): Set the Type field to 3, and adjust 542 the ICMP checksum both to take the type change into account 543 and to include the ICMPv6 pseudo-header. The Code field is 544 unchanged. 546 Parameter Problem (Type 12): Set the Type field to 4, and 547 adjust the ICMP checksum both to take the type change into 548 account and to include the ICMPv6 pseudo-header. Translate 549 the Code field as follows: 551 Code 0 (Pointer indicates the error): Set the Code value to 552 0 (Erroneous header field encountered) and update the 553 pointer as defined in Figure 3 (If the Original IPv4 554 Pointer Value is not listed or the Translated IPv6 555 Pointer Value is listed as "n/a", silently drop the 556 packet). 558 Code 1 (Missing a required option): Silently drop 560 Code 2 (Bad length): Set the Code value to 0 (Erroneous 561 header field encountered) and update the pointer as 562 defined in Figure 3 (If the Original IPv4 Pointer Value 563 is not listed or the Translated IPv6 Pointer Value is 564 listed as "n/a", silently drop the packet). 566 Other Code values: Silently drop 568 Unknown ICMPv4 types: Silently drop. 570 | Original IPv4 Pointer Value | Translated IPv6 Pointer Value | 571 +--------------------------------+--------------------------------+ 572 | 0 | Version/IHL | 0 | Version/Traffic Class | 573 | 1 | Type Of Service | 1 | Traffic Class/Flow Label | 574 | 2,3 | Total Length | 4 | Payload Length | 575 | 4,5 | Identification | n/a | | 576 | 6 | Flags/Fragment Offset | n/a | | 577 | 7 | Fragment Offset | n/a | | 578 | 8 | Time to Live | 7 | Hop Limit | 579 | 9 | Protocol | 6 | Next Header | 580 |10,11| Header Checksum | n/a | | 581 |12-15| Source Address | 8 | Source Address | 582 |16-19| Destination Address | 24 | Destination Address | 583 +--------------------------------+--------------------------------+ 585 Figure 3: Pointer value for translating from IPv4 to IPv6 587 ICMP Error Payload: If the received ICMPv4 packet contains an 588 ICMPv4 Extension [RFC4884], the translation of the ICMPv4 589 packet will cause the ICMPv6 packet to change length. When 590 this occurs, the ICMPv6 Extension length attribute MUST be 591 adjusted accordingly (e.g., longer due to the translation 592 from IPv4 to IPv6). If the ICMPv4 Extension exceeds the 593 maximum size of an ICMPv6 message on the outgoing interface, 594 the ICMPv4 extension should be simply truncated. For 595 extensions not defined in [RFC4884], the translator passes 596 the extensions as opaque bit strings and those containing 597 IPv4 address literals will not have those addresses 598 translated to IPv6 address literals; this may cause problems 599 with processing of those ICMP extensions. 601 3.3. Translating ICMPv4 Error Messages into ICMPv6 603 There are some differences between the ICMPv4 and the ICMPv6 error 604 message formats as detailed above. In addition, the ICMP error 605 messages contain for the packet in error, which needs to be 606 translated just like a normal IP packet. The translation of this 607 "packet in error" is likely to change the length of the datagram. 608 Thus the Payload Length field in the outer IPv6 header might need to 609 be updated. 611 +-------------+ +-------------+ 612 | IPv4 | | IPv6 | 613 | Header | | Header | 614 +-------------+ +-------------+ 615 | ICMPv4 | | ICMPv6 | 616 | Header | | Header | 617 +-------------+ +-------------+ 618 | IPv4 | ===> | IPv6 | 619 | Header | | Header | 620 +-------------+ +-------------+ 621 | Partial | | Partial | 622 | Transport | | Transport | 623 | Layer | | Layer | 624 | Header | | Header | 625 +-------------+ +-------------+ 627 Figure 4: IPv4-to-IPv6 ICMP Error Translation 629 The translation of the inner IP header can be done by invoking the 630 function that translated the outer IP headers. This process SHOULD 631 stop at first embedded header and drop the packet if it contains 632 more. 634 3.4. Translator Sending ICMPv4 Error Message 636 If the IPv4 packet is discarded, then the translator SHOULD be able 637 to send back an ICMPv4 error message to the original sender of the 638 packet, unless the discarded packet is itself an ICMPv4 message. The 639 ICMPv4 message, if sent, has a Type value of 3 (Destination 640 Unreachable) and a Code value of 13 (Communication Administratively 641 Prohibited), unless otherwise specified in this document or in 642 [I-D.ietf-behave-v6v4-xlate-stateful]. The translator SHOULD allow 643 an administrator to configure whether the ICMPv4 error messages are 644 sent, rate-limited, or not sent. 646 3.5. Transport-layer Header Translation 648 If the address translation algorithm is not checksum neutral, the 649 recalculation and updating of the transport-layer headers MUST be 650 performed. 652 When a translator receives an unfragmented UDP IPv4 packet and the 653 checksum field is zero, the translator SHOULD compute the missing UDP 654 checksum as part of translating the packet. Also, the translator 655 SHOULD maintain a counter of how many UDP checksums are generated in 656 this manner. 658 When a stateless translator receives the first fragment of a 659 fragmented UDP IPv4 packet and the checksum field is zero, the 660 translator SHOULD drop the packet and generate a system management 661 event specifying at least the IP addresses and port numbers in the 662 packet. When it receives fragments other than the first, it SHOULD 663 silently drop the packet, since there is no port information to log. 665 For stateful translator, the handling of fragmented UDP IPv4 packets 666 with a zero checksum is discussed in 667 [I-D.ietf-behave-v6v4-xlate-stateful] section 3.1. 669 3.6. Knowing when to Translate 671 If the IP/ICMP translator also provides normal forwarding function, 672 and the destination IPv4 address is reachable by a more specific 673 route without translation, the translator MUST forward it without 674 translating it. Otherwise, when an IP/ICMP translator receives an 675 IPv4 datagram addressed to an IPv4 destination representing a host in 676 the IPv6 domain, the packet MUST be translated to IPv6. 678 4. Translating from IPv6 to IPv4 680 When an IP/ICMP translator receives an IPv6 datagram addressed to a 681 destination towards the IPv4 domain, it translates the IPv6 header of 682 the received IPv6 packet into an IPv4 header. The original IPv6 683 header on the packet is removed and replaced by an IPv4 header. 684 Since the ICMPv6 [RFC4443], TCP [RFC0793], and UDP [RFC0768] headers 685 contain checksums that cover the IP header, if the address mapping 686 algorithm is not checksum-neutral, the ICMP and transport-layer 687 headers MUST be updated. The data portion of the packet is left 688 unchanged. The IP/ICMP translator then forwards the packet based on 689 the IPv4 destination address. 691 +-------------+ +-------------+ 692 | IPv6 | | IPv4 | 693 | Header | | Header | 694 +-------------+ +-------------+ 695 | Fragment | | Transport | 696 | Header | ===> | Layer | 697 |(if present) | | Header | 698 +-------------+ +-------------+ 699 | Transport | | | 700 | Layer | ~ Data ~ 701 | Header | | | 702 +-------------+ +-------------+ 703 | | 704 ~ Data ~ 705 | | 706 +-------------+ 708 Figure 5: IPv6-to-IPv4 Translation 710 There are some differences between IPv6 and IPv4 in the area of 711 fragmentation and the minimum link MTU that affect the translation. 712 An IPv6 link has to have an MTU of 1280 bytes or greater. The 713 corresponding limit for IPv4 is 68 bytes. Thus, unless there were 714 special measures, it would not be possible to do end-to-end path MTU 715 discovery when the path includes a translator, since the IPv6 node 716 might receive ICMPv6 "Packet Too Big" messages originated by an IPv4 717 router that report an MTU less than 1280. However, [RFC2460] section 718 5 requires that IPv6 nodes handle such an ICMPv6 "Packet Too Big" 719 message by reducing the path MTU to 1280 and including an IPv6 720 fragment header with each packet. In this case, the translator 721 SHOULD set DF to 0 and take the identification value from the IPv6 722 fragment header when a fragmentation header with (MF=0; Offset=0) is 723 present or set DF to 1 otherwise. This allows end-to-end path MTU 724 discovery across the translator as long as the path MTU is 1280 bytes 725 or greater. When the path MTU drops below the 1280 limit, the IPv6 726 sender will originate 1280-byte packets that will be fragmented by 727 IPv4 routers along the path after being translated to IPv4. 729 The drawback with this scheme is that it is not possible to use PMTU 730 discovery to do optimal UDP fragmentation (as opposed to completely 731 avoiding fragmentation) at the sender, since the presence of an IPv6 732 Fragment header is interpreted that it is okay to fragment the packet 733 on the IPv4 side. Thus if a UDP application wants to send large 734 packets independent of the PMTU, the sender will only be able to 735 determine the path MTU on the IPv6 side of the translator. If the 736 path MTU on the IPv4 side of the translator is smaller, then the IPv6 737 sender will not receive any ICMPv6 "Too Big" errors and cannot adjust 738 the size fragments it is sending. 740 On the other hand, the recent study indicates that only 43.46% of 741 IPv6-capable web servers include an IPv6 fragmentation header in 742 their respond packets after they were sent an ICMPv6 "Packet Too Big" 743 message specifying an MTU<1280 bytes [Stasiewicz]. A workaround to 744 this problem (ICMPv6 "Packet Too Big" message with MTU<1280) is that 745 if there is no fragmentation header in the IPv6 packet, the 746 translator SHOULD set DF to 0 for the packets equal to or smaller 747 than 1280 bytes and set DF to 1 for packets larger than 1280 bytes. 748 In addition, the translator SHOULD take the identification value from 749 the IPv6 fragmentation header if presents or generate the 750 identification value otherwise. This avoids the introduction of the 751 path MTU discovery black hole. The header translation defined in the 752 next section uses this method. 754 Other than the special rules for handling fragments and path MTU 755 discovery, the actual translation of the packet header consists of a 756 simple mapping as defined below. Note that ICMPv6 packets require 757 special handling in order to translate the contents of ICMPv6 error 758 messages and also to remove the ICMPv6 pseudo-header checksum. 760 4.1. Translating IPv6 Headers into IPv4 Headers 762 If there is no IPv6 Fragment header, the IPv4 header fields are set 763 as follows: 765 Version: 4 767 Internet Header Length: 5 (no IPv4 options) 769 Type of Service (TOS) Octet: By default, copied from the IPv6 770 Traffic Class (all 8 bits). According to [RFC2474] the semantics 771 of the bits are identical in IPv4 and IPv6. However, in some IPv4 772 environments, these bits might be used with the old semantics of 773 "Type Of Service and Precedence". An implementation of a 774 translator SHOULD provide the ability to ignore the IPv6 traffic 775 class and always set the IPv4 TOS Octet to a specified value. In 776 addition, if the translator is at an administrative boundary, the 777 filtering and update considerations of [RFC2475] may be 778 applicable. 780 Total Length: Payload length value from IPv6 header, plus the size 781 of the IPv4 header. 783 Identification: If the packet size is equal to or smaller than 1280 784 bytes, generate the identification value. If the packet size is 785 greater than 1280 bytes, set Identification All zeros. 787 Flags: The More Fragments (MF) flag is set to zero. If the packet 788 size is equal to or smaller than 1280 bytes, the Don't Fragments 789 (DF) flag is set to zero. If the packet size is greater than 1280 790 bytes, the Don't Fragments (DF) flag is set to one. 792 Fragment Offset: All zeros. 794 Time to Live: Time to Live is derived from Hop Limit value in IPv6 795 header. Since the translator is a router, as part of forwarding 796 the packet it needs to decrement either the IPv6 Hop Limit (before 797 the translation) or the IPv4 TTL (after the translation). As part 798 of decrementing the TTL or Hop Limit the translator (as any 799 router) needs to check for zero and send the ICMPv4 "TTL Exceeded" 800 or ICMPv6 "Hop Limit Exceeded" error. 802 Protocol: For ICMPv6 (58) changed to ICMPv4 (1), otherwise Next 803 Header field copied from IPv6 header. 805 Header Checksum: Computed once the IPv4 header has been created. 807 Source Address: In the stateless mode, which is to say that if the 808 IPv6 source address is within the range of a configured IPv6 809 translation prefix, the IPv4 source address is derived from the 810 IPv6 source address per [I-D.ietf-behave-address-format] section 811 2.1. Note that the original IPv6 source address is an IPv4- 812 translatable address. A workflow example of stateless translation 813 is shown in Appendix of this document. If the translator only 814 supports stateless mode and if the IPv6 source address is not 815 within the range of configured IPv6 prefix(es), the translator 816 SHOULD drop the packet and respond with an ICMPv6 Type=1, Code=5 817 (Destination Unreachable, Source address failed ingress/egress 818 policy). 820 In the stateful mode, which is to say that if the IPv6 source 821 address is not within the range of any configured IPv6 stateless 822 translation prefix, the IPv4 source address and transport-layer 823 source port corresponding to the IPv4-related IPv6 source address 824 and source port are derived from the Binding Information Bases 825 (BIBs) as described in [I-D.ietf-behave-v6v4-xlate-stateful]. 827 In stateless and stateful modes, if the translator gets an illegal 828 source address (e.g. ::1, etc.), the translator SHOULD silently 829 drop the packet. 831 Destination Address: The IPv4 destination address is derived from 832 the IPv6 destination address of the datagram being translated per 833 [I-D.ietf-behave-address-format] section 2.1. Note that the 834 original IPv6 destination address is an IPv4-converted address. 836 If any of an IPv6 Hop-by-Hop Options header, Destination Options 837 header, or Routing header with the Segments Left field equal to zero 838 are present in the IPv6 packet, those IPv6 extension headers MUST be 839 ignored (i.e., there is no attempt to translate the extension 840 headers) and the packet translated normally. However, the Total 841 Length field and the Protocol field is adjusted to "skip" these 842 extension headers. 844 If a Routing header with a non-zero Segments Left field is present 845 then the packet MUST NOT be translated, and an ICMPv6 "parameter 846 problem/erroneous header field encountered" (Type 4/Code 0) error 847 message, with the Pointer field indicating the first byte of the 848 Segments Left field, SHOULD be returned to the sender. 850 If the IPv6 packet contains a Fragment header, the header fields are 851 set as above with the following exceptions: 853 Total Length: Payload length value from IPv6 header, minus 8 for the 854 Fragment header, plus the size of the IPv4 header. 856 Identification: Copied from the low-order 16-bits in the 857 Identification field in the Fragment header. 859 Flags: The More Fragments (MF) flag is copied from the M flag in the 860 Fragment header. The Don't Fragments (DF) flag is set to zero 861 allowing this packet to be fragmented if required by IPv4 routers. 863 Fragment Offset: Copied from the Fragment Offset field in the 864 Fragment header. 866 Protocol: For ICMPv6 (58) changed to ICMPv4 (1), otherwise Next 867 Header field copied from Fragment header. 869 4.2. Translating ICMPv6 Headers into ICMPv4 Headers 871 All ICMPv6 messages that are to be translated require that the ICMPv4 872 checksum field be updated as part of the translation since ICMPv6 873 (unlike ICMPv4) includes a pseudo-header in the checksum just like 874 UDP and TCP. 876 In addition all ICMP packets need to have the Type value translated 877 and, for ICMP error messages, the included IP header also needs 878 translation. Note that the IPv6 addresses in the IPv6 header may not 879 be IPv4-translatable addresses and there will be no corresponding 880 IPv4 addresses represented of this IPv6 address. In this case, the 881 translator can ether do stateful translation or map them to an IPv4 882 address block as a holder for all non IPv4-translatable IPv6 883 addresses in a stateless manner. 885 The actions needed to translate various ICMPv6 messages are: 887 ICMPv6 informational messages: 889 Echo Request and Echo Reply (Type 128 and 129): Adjust the Type 890 values to 8 and 0, respectively, and adjust the ICMP checksum 891 both to take the type change into account and to exclude the 892 ICMPv6 pseudo-header. 894 MLD Multicast Listener Query/Report/Done (Type 130, 131, 132): 895 Single hop message. Silently drop. 897 Neighbor Discover messages (Type 133 through 137): Single hop 898 message. Silently drop. 900 Unknown informational messages: Silently drop. 902 ICMPv6 error messages: 904 Destination Unreachable (Type 1) Set the Type field to 3, and 905 adjust the ICMP checksum both to take the type change into 906 account and to exclude the ICMPv6 pseudo-header. Translate the 907 Code field as follows: 909 Code 0 (no route to destination): Set Code value to 1 (Host 910 unreachable). 912 Code 1 (Communication with destination administratively 913 prohibited): Set Code value to 10 (Communication with 914 destination host administratively prohibited). 916 Code 2 (Beyond scope of source address): Set Code value to 1 917 (Host unreachable). Note that this error is very unlikely 918 since an IPv4-translatable source address is typically 919 considered to have global scope. 921 Code 3 (Address unreachable): Set Code value to 1 (Host 922 unreachable). 924 Code 4 (Port unreachable): Set Code value to 3 (Port 925 unreachable). 927 Other Code values: Silently drop. 929 Packet Too Big (Type 2): Translate to an ICMPv4 Destination 930 Unreachable (Type 3) with Code value equal to 4, and adjust the 931 ICMPv4 checksum both to take the type change into account and 932 to exclude the ICMPv6 pseudo-header. The MTU field needs to be 933 adjusted for the difference between the IPv4 and IPv6 header 934 sizes taking into account whether or not the packet in error 935 includes a Fragment header, i.e. minimum(advertised MTU-20, 936 MTU_of_IPv4_nexthop, (MTU_of_IPv6_nexthop)-20) 938 Time Exceeded (Type 3): Set the Type value to 11, and adjust the 939 ICMPv4 checksum both to take the type change into account and 940 to exclude the ICMPv6 pseudo-header. The Code field is 941 unchanged. 943 Parameter Problem (Type 4): Translate the Type and Code field as 944 follows, and adjust the ICMPv4 checksum both to take the type 945 change into account and to exclude the ICMPv6 pseudo-header. 947 Code 0 (Erroneous header field encountered): Set Type 12, Code 948 0 and update the pointer as defined in Figure 6 (If the 949 Original IPv6 Pointer Value is not listed or the Translated 950 IPv4 Pointer Value is listed as "n/a", silently drop the 951 packet). 953 Code 1 (Unrecognized Next Header type encountered): Translate 954 this to an ICMPv4 protocol unreachable (Type 3, Code 2). 956 Code 2 (Unrecognized IPv6 option encountered): Silently drop. 958 Unknown error messages: Silently drop. 960 | Original IPv6 Pointer Value | Translated IPv4 Pointer Value | 961 +--------------------------------+--------------------------------+ 962 | 0 | Version/Traffic Class | 0 | Version/IHL, Type Of Ser | 963 | 1 | Traffic Class/Flow Label | 1 | Type Of Service | 964 | 2,3 | Flow Label | n/a | | 965 | 4,5 | Payload Length | 2 | Total Length | 966 | 6 | Next Header | 9 | Protocol | 967 | 7 | Hop Limit | 8 | Time to Live | 968 | 8-23| Source Address | 12 | Source Address | 969 |24-39| Destination Address | 16 | Destination Address | 970 +--------------------------------+--------------------------------+ 972 Figure 6: Pointer Value for translating from IPv6 to IPv4 974 ICMP Error Payload: If the received ICMPv6 packet contains an 975 ICMPv6 Extension [RFC4884], the translation of the ICMPv6 976 packet will cause the ICMPv4 packet to change length. When 977 this occurs, the ICMPv6 Extension length attribute MUST be 978 adjusted accordingly (e.g., shorter due to the translation from 979 IPv6 to IPv4). For extensions not defined in [RFC4884], the 980 translator passes the extensions as opaque bit strings and 981 those containing IPv6 address literals will not have those 982 addresses translated to IPv4 address literals; this may cause 983 problems with processing of those ICMP extensions. 985 4.3. Translating ICMPv6 Error Messages into ICMPv4 987 There are some differences between the ICMPv4 and the ICMPv6 error 988 message formats as detailed above. In addition, the ICMP error 989 messages contain for the packet in error, which needs to be 990 translated just like a normal IP packet. The translation of this 991 "packet in error" is likely to change the length of the datagram thus 992 the Total Length field in the outer IPv4 header might need to be 993 updated. 995 +-------------+ +-------------+ 996 | IPv6 | | IPv4 | 997 | Header | | Header | 998 +-------------+ +-------------+ 999 | ICMPv6 | | ICMPv4 | 1000 | Header | | Header | 1001 +-------------+ +-------------+ 1002 | IPv6 | ===> | IPv4 | 1003 | Header | | Header | 1004 +-------------+ +-------------+ 1005 | Partial | | Partial | 1006 | Transport | | Transport | 1007 | Layer | | Layer | 1008 | Header | | Header | 1009 +-------------+ +-------------+ 1011 Figure 7: IPv6-to-IPv4 ICMP Error Translation 1013 The translation of the inner IP header can be done by invoking the 1014 function that translated the outer IP headers. This process SHOULD 1015 stop at first embedded header and drop the packet if it contains 1016 more. Note that the IPv6 addresses in the IPv6 header may not be 1017 IPv4-translatable addresses and there will be no corresponding IPv4 1018 addresses. In this case, the translator can ether do stateful 1019 translation or map them to an IPv4 address block as a holder for all 1020 non IPv4-translatable IPv6 addresses. 1022 4.4. Translator Sending ICMPv6 Error Message 1024 If the IPv6 packet is discarded, then the translator SHOULD be able 1025 to send back an ICMPv6 error message to the original sender of the 1026 packet, unless the discarded packet is itself an ICMPv6 message. 1028 If the reason of sending ICMPv6 is due to that the IPv6 source 1029 address is not an IPv4-translatable address and the translator is 1030 stateless, the ICMPv6 message, if sent, has a Type value 1 and Code 1031 value 5 (Source address failed ingress/egress policy). In other 1032 cases, the ICMPv6 message has a Type value of 1 (Destination 1033 Unreachable) and a Code value of 1 (Communication with destination 1034 administratively prohibited), unless otherwise specified in this 1035 document or [I-D.ietf-behave-v6v4-xlate-stateful]. The translator 1036 SHOULD allow an administrator to configure whether the ICMPv6 error 1037 messages are sent, rate-limited, or not sent. 1039 4.5. Transport-layer Header Translation 1041 If the address translation algorithm is not checksum neutral, the 1042 recalculation and updating of the transport-layer headers MUST be 1043 performed. 1045 4.6. Knowing when to Translate 1047 If the IP/ICMP translator also provides normal forwarding function, 1048 and the destination address is reachable by a more specific route 1049 without translation, the router MUST forward it without translating 1050 it. When an IP/ICMP translator receives an IPv6 datagram addressed 1051 to an IPv6 address representing an host in IPv4 domain, the IPv6 1052 packet MUST be translated to IPv4. 1054 5. IANA Considerations 1056 This memo adds no new IANA considerations. 1058 Note to RFC Editor: This section will have served its purpose if it 1059 correctly tells IANA that no new assignments or registries are 1060 required, or if those assignments or registries are created during 1061 the RFC publication process. From the author's perspective, it may 1062 therefore be removed upon publication as an RFC at the RFC Editor's 1063 discretion. 1065 6. Security Considerations 1067 The use of stateless IP/ICMP translators does not introduce any new 1068 security issues beyond the security issues that are already present 1069 in the IPv4 and IPv6 protocols and in the routing protocols that are 1070 used to make the packets reach the translator. 1072 There are potential issues that might arise by deriving an IPv4 1073 address from an IPv6 address - particularly addresses like broadcast 1074 or loopback addresses and the non IPv4-translatable IPv6 addresses, 1075 etc. The [I-D.ietf-behave-address-format] addresses these issues. 1077 As the Authentication Header [RFC4302] is specified to include the 1078 IPv4 Identification field and the translating function is not able to 1079 always preserve the Identification field, it is not possible for an 1080 IPv6 endpoint to verify the AH on received packets that have been 1081 translated from IPv4 packets. Thus AH does not work through a 1082 translator. 1084 Packets with ESP can be translated since ESP does not depend on 1085 header fields prior to the ESP header. Note that ESP transport mode 1086 is easier to handle than ESP tunnel mode; in order to use ESP tunnel 1087 mode, the IPv6 node needs to be able to generate an inner IPv4 header 1088 when transmitting packets and remove such an IPv4 header when 1089 receiving packets. 1091 7. Acknowledgements 1093 This is under development by a large group of people. Those who have 1094 posted to the list during the discussion include Andrew Sullivan, 1095 Andrew Yourtchenko, Brian Carpenter, Dan Wing, Dave Thaler, Ed 1096 Jankiewicz, Hiroshi Miyata, Iljitsch van Beijnum, Jari Arkko, Jerry 1097 Huang, John Schnizlein, Jouni Korhonen, Kentaro Ebisawa, Kevin Yin, 1098 Magnus Westerlund, Marcelo Bagnulo Braun, Margaret Wasserman, 1099 Masahito Endo, Phil Roberts, Philip Matthews, Remi Denis-Courmont, 1100 Remi Despres, Senthil Sivakumar, Simon Perreault and Zen Cao. 1102 8. Appendix: Stateless translation workflow example 1104 A stateless translation workflow example is depicted in the following 1105 figure: 1107 +--------------+ +--------------+ 1108 | IPv4 network | | IPv6 network | 1109 | | +-------+ | | 1110 | +----+ |-----| XLATE |---- | +----+ | 1111 | | H4 |-----| +-------+ |--| H6 | | 1112 | +----+ | | +----+ | 1113 +--------------+ +--------------+ 1115 Figure 8 1117 A translator (XLATE) connects the IPv6 network to the IPv4 network. 1118 This XLATE uses the Network Specific Prefix (NSP) 2001:DB8:100::/40 1119 defined in [I-D.ietf-behave-address-format] to represent IPv4 1120 addresses in the IPv6 address space (IPv4-converted addresses) and to 1121 represent IPv6 addresses (IPv4-translatable addresses) in the IPv4 1122 address space. In this example, 192.0.2.0/24 is the IPv4 block of 1123 the corresponding IPv4-translatable addresses. 1125 Based on the address mapping rule, the IPv6 node H6 has an IPv4- 1126 translatable IPv6 address 2001:DB8:1C0:2:21:: (address mapping from 1127 192.0.2.33). The IPv4 node H4 has IPv4 address 166.111.1.2. 1129 The IPv6 routing is configured in such a way that the IPv6 packets 1130 addressed to a destination address in 2001:DB8:100::/40 are routed to 1131 the IPv6 interface of the XLATE. 1133 The IPv4 routing is configured in such a way that the IPv4 packets 1134 addressed to a destination address in 192.0.2.0/24 are routed to the 1135 IPv4 interface of the XLATE. 1137 8.1. H6 establishes communication with H4 1139 The steps by which H6 establishes communication with H4 are: 1141 1. H6 performs the destination address mapping, so the IPv4- 1142 converted address 2001:DB8:1a6:6f01:200:: is formed from 1143 166.111.1.2 based on the address mapping algorithm 1144 [I-D.ietf-behave-address-format]. 1146 2. H6 sends a packet to H4. The packet is sent from a source 1147 address 2001:DB8:1C0:2:21:: to a destination address 2001:DB8: 1148 1a6:6f01:200::. 1150 3. The packet is routed to the IPv6 interface of the XLATE (since 1151 IPv6 routing is configured that way). 1153 4. The XLATE receives the packet and performs the following actions: 1155 * The XLATE translates the IPv6 header into an IPv4 header using 1156 the IP/ICMP Translation Algorithm defined in this document. 1158 * The XLATE includes 192.0.2.33 as source address in the packet 1159 and 166.111.1.2 as destination address in the packet. Note 1160 that 192.0.2.33 and 166.111.1.2 are extracted directly from 1161 the source IPv6 address 2001:DB8:1C0:2:21:: (IPv4-translatable 1162 address) and destination IPv6 address 2001:DB8:1a6:6f01:200:: 1163 (IPv4-converted address) of the received IPv6 packet that is 1164 being translated. 1166 5. The XLATE sends the translated packet out its IPv4 interface and 1167 the packet arrives at H4. 1169 6. H4 node responds by sending a packet with destination address 1170 192.0.2.33 and source address 166.111.1.2. 1172 7. The packet is routed to the IPv4 interface of the XLATE (since 1173 IPv4 routing is configured that way). The XLATE performs the 1174 following operations: 1176 * The XLATE translates the IPv4 header into an IPv6 header using 1177 the IP/ICMP Translation Algorithm defined in this document. 1179 * The XLATE includes 2001:DB8:1C0:2:21:: as destination address 1180 in the packet and 2001:DB8:1a6:6f01:200:: as source address in 1181 the packet. Note that 2001:DB8:1C0:2:21:: and 2001:DB8:1a6: 1182 6f01:200:: are formed directly from the destination IPv4 1183 address 192.0.2.33 and source IPv4 address 166.111.1.2 of the 1184 received IPv4 packet that is being translated. 1186 8. The translated packet is sent out the IPv6 interface to H6. 1188 The packet exchange between H6 and H4 continues until the session is 1189 finished. 1191 8.2. H4 establishes communication with H6 1193 The steps by which H4 establishes communication with H6 are: 1195 1. H4 performs the destination address mapping, so 192.0.2.33 is 1196 formed from IPv4-translatable address 2001:DB8:1C0:2:21:: based 1197 on the address mapping algorithm 1198 [I-D.ietf-behave-address-format]. 1200 2. H4 sends a packet to H6. The packet is sent from a source 1201 address 166.111.1.2 to a destination address 192.0.2.33. 1203 3. The packet is routed to the IPv6 interface of the XLATE (since 1204 IPv6 routing is configured that way). 1206 4. The XLATE receives the packet and performs the following actions: 1208 * The XLATE translates the IPv4 header into an IPv6 header using 1209 the IP/ICMP Translation Algorithm defined in this document. 1211 * The XLATE includes 2001:DB8:1a6:6f01:200:: as source address 1212 in the packet and 2001:DB8:1C0:2:21:: as destination address 1213 in the packet. Note that 2001:DB8:1a6:6f01:200:: (IPv4- 1214 converted address) and 2001:DB8:1C0:2:21:: (IPv4-translatable 1215 address) are obtained directly from the source IPv4 address 1216 166.111.1.2 and destination IPv4 address 192.0.2.33 of the 1217 received IPv4 packet that is being translated. 1219 5. The XLATE sends the translated packet out its IPv6 interface and 1220 the packet arrives at H6. 1222 6. H6 node responds by sending a packet with destination address 1223 2001:DB8:1a6:6f01:200:: and source address 2001:DB8:1C0:2:21::. 1225 7. The packet is routed to the IPv6 interface of the XLATE (since 1226 IPv6 routing is configured that way). The XLATE performs the 1227 following operations: 1229 * The XLATE translates the IPv6 header into an IPv4 header using 1230 the IP/ICMP Translation Algorithm defined in this document. 1232 * The XLATE includes 166.111.1.2 as destination address in the 1233 packet and 192.0.2.33 as source address in the packet. Note 1234 that 166.111.1.2 and 192.0.2.33 are formed directly from the 1235 destination IPv6 address 2001:DB8:1a6:6f01:200:: and source 1236 IPv6 address 2001:DB8:1C0:2:21:: of the received IPv6 packet 1237 that is being translated. 1239 8. The translated packet is sent out the IPv4 interface to H4. 1241 The packet exchange between H4 and H6 continues until the session 1242 finished. 1244 9. References 1245 9.1. Normative References 1247 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1248 August 1980. 1250 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1251 September 1981. 1253 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1254 RFC 792, September 1981. 1256 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1257 RFC 793, September 1981. 1259 [RFC0879] Postel, J., "TCP maximum segment size and related topics", 1260 RFC 879, November 1983. 1262 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1263 RFC 1812, June 1995. 1265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1266 Requirement Levels", BCP 14, RFC 2119, March 1997. 1268 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1269 (IPv6) Specification", RFC 2460, December 1998. 1271 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1272 (SIIT)", RFC 2765, February 2000. 1274 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 1275 Translation - Protocol Translation (NAT-PT)", RFC 2766, 1276 February 2000. 1278 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1279 Architecture", RFC 4291, February 2006. 1281 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1282 Message Protocol (ICMPv6) for the Internet Protocol 1283 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1285 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 1286 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 1287 April 2007. 1289 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1290 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1291 RFC 5382, October 2008. 1293 9.2. Informative References 1295 [Dongjin] Lee, D., "Email to the behave mailing list (http:// 1296 www.ietf.org/mail-archive/web/behave/current/ 1297 msg06856.html)", Sept 2009. 1299 [I-D.ietf-behave-address-format] 1300 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 1301 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 1302 draft-ietf-behave-address-format-04 (work in progress), 1303 January 2010. 1305 [I-D.ietf-behave-v6v4-framework] 1306 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1307 IPv4/IPv6 Translation", 1308 draft-ietf-behave-v6v4-framework-06 (work in progress), 1309 February 2010. 1311 [I-D.ietf-behave-v6v4-xlate-stateful] 1312 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 1313 NAT64: Network Address and Protocol Translation from IPv6 1314 Clients to IPv4 Servers", 1315 draft-ietf-behave-v6v4-xlate-stateful-08 (work in 1316 progress), January 2010. 1318 [Miller] Miller, G., "Email to the ngtrans mailing list 1319 (http://www.mail-archive.com/ipv6@ietf.org/ 1320 msg10159.html)", March 1999. 1322 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1323 November 1990. 1325 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1326 "Definition of the Differentiated Services Field (DS 1327 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1328 December 1998. 1330 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1331 and W. Weiss, "An Architecture for Differentiated 1332 Services", RFC 2475, December 1998. 1334 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1335 Listener Discovery (MLD) for IPv6", RFC 2710, 1336 October 1999. 1338 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 1339 "IANA Guidelines for IPv4 Multicast Address Assignments", 1340 BCP 51, RFC 3171, August 2001. 1342 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 1343 Addresses", RFC 3307, August 2002. 1345 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 1346 Listener Discovery (MLD) Protocol", RFC 3590, 1347 September 2003. 1349 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1350 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1352 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1353 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1355 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1356 December 2005. 1358 [Stasiewicz] 1359 Stasiewicz, B., "Email to the behave mailing list (http:// 1360 www.ietf.org/mail-archive/web/behave/current/ 1361 msg08093.html)", Feb 2010. 1363 Authors' Addresses 1365 Xing Li 1366 CERNET Center/Tsinghua University 1367 Room 225, Main Building, Tsinghua University 1368 Beijing, 100084 1369 China 1371 Phone: +86 10-62785983 1372 Email: xing@cernet.edu.cn 1374 Congxiao Bao 1375 CERNET Center/Tsinghua University 1376 Room 225, Main Building, Tsinghua University 1377 Beijing, 100084 1378 China 1380 Phone: +86 10-62785983 1381 Email: congxiao@cernet.edu.cn 1382 Fred Baker 1383 Cisco Systems 1384 Santa Barbara, California 93117 1385 USA 1387 Phone: +1-408-526-4257 1388 Email: fred@cisco.com