idnits 2.17.1 draft-ietf-behave-v6v4-xlate-05.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-behave-v6v4-framework], [RFC0791], [RFC0792], [I-D.ietf-behave-address-format], [RFC2119], [RFC2460], [RFC2765], [RFC4443]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- 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 (December 17, 2009) is 5243 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-02 == Outdated reference: A later version (-10) exists of draft-ietf-behave-v6v4-framework-03 == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-05 == Outdated reference: A later version (-03) exists of draft-venaas-behave-v4v6mc-framework-01 == Outdated reference: A later version (-07) exists of draft-xli-behave-ivi-05 -- Obsolete informational reference (is this intentional?): RFC 3171 (Obsoleted by RFC 5771) Summary: 5 errors (**), 0 flaws (~~), 7 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: June 20, 2010 Cisco Systems 7 December 17, 2009 9 IP/ICMP Translation Algorithm 10 draft-ietf-behave-v6v4-xlate-05 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). 19 This specification addresses both a stateless and a stateful mode. 20 In the stateless mode, translation information is carried in the 21 address itself, permitting both IPv4->IPv6 and IPv6->IPv4 session 22 establishment without maintaining state in the IP/ICMP translator. 23 In the stateful mode, translation state is maintained between IPv4 24 address/transport port tuples and IPv6 address/transport port tuples, 25 enabling IPv6 systems to open sessions with IPv4 systems. The choice 26 of operational mode is made by the operator deploying the network and 27 is critical to the operation of the applications using it. 29 Acknowledgement of previous work 31 This document is a product of the 2008-2009 effort to define a 32 replacement for NAT-PT. It is an update to and directly derivative 33 from Erik Nordmark's [RFC2765], which similarly provides both 34 stateless and stateful translation between IPv4 [RFC0791] and IPv6 35 [RFC2460], and between ICMPv4 [RFC0792] and ICMPv6 [RFC4443]. The 36 original document was a product of the NGTRANS working group. 38 The changes in this document reflect five components: 40 1. Redescribing the network model to map to present and projected 41 usage [I-D.ietf-behave-v6v4-framework]. 43 2. Moving the address format to the address format document 44 [I-D.ietf-behave-address-format], to coordinate with other drafts 45 on the topic. 47 3. Describing both stateful and stateless operation. 49 4. Some changes in ICMP. 51 5. Updating references. 53 Requirements 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in [RFC2119]. 59 Status of this Memo 61 This Internet-Draft is submitted to IETF in full conformance with the 62 provisions of BCP 78 and BCP 79. 64 Internet-Drafts are working documents of the Internet Engineering 65 Task Force (IETF), its areas, and its working groups. Note that 66 other groups may also distribute working documents as Internet- 67 Drafts. 69 Internet-Drafts are draft documents valid for a maximum of six months 70 and may be updated, replaced, or obsoleted by other documents at any 71 time. It is inappropriate to use Internet-Drafts as reference 72 material or to cite them other than as "work in progress." 74 The list of current Internet-Drafts can be accessed at 75 http://www.ietf.org/ietf/1id-abstracts.txt. 77 The list of Internet-Draft Shadow Directories can be accessed at 78 http://www.ietf.org/shadow.html. 80 This Internet-Draft will expire on June 20, 2010. 82 Copyright Notice 84 Copyright (c) 2009 IETF Trust and the persons identified as the 85 document authors. All rights reserved. 87 This document is subject to BCP 78 and the IETF Trust's Legal 88 Provisions Relating to IETF Documents 89 (http://trustee.ietf.org/license-info) in effect on the date of 90 publication of this document. Please review these documents 91 carefully, as they describe your rights and restrictions with respect 92 to this document. Code Components extracted from this document must 93 include Simplified BSD License text as described in Section 4.e of 94 the Trust Legal Provisions and are provided without warranty as 95 described in the BSD License. 97 This document may contain material from IETF Documents or IETF 98 Contributions published or made publicly available before November 99 10, 2008. The person(s) controlling the copyright in some of this 100 material may not have granted the IETF Trust the right to allow 101 modifications of such material outside the IETF Standards Process. 102 Without obtaining an adequate license from the person(s) controlling 103 the copyright in such materials, this document may not be modified 104 outside the IETF Standards Process, and derivative works of it may 105 not be created outside the IETF Standards Process, except to format 106 it for publication as an RFC or to translate it into languages other 107 than English. 109 Table of Contents 111 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 4 112 1.1. Translation Model . . . . . . . . . . . . . . . . . . . . 4 113 1.2. Applicability and Limitations . . . . . . . . . . . . . . 5 114 1.3. Stateless vs. Stateful Mode . . . . . . . . . . . . . . . 6 115 1.4. Path MTU discovery and fragmentation . . . . . . . . . . . 6 116 2. Translating from IPv4 to IPv6 . . . . . . . . . . . . . . . . 7 117 2.1. Translating IPv4 Headers into IPv6 Headers . . . . . . . . 8 118 2.2. Translating UDP over IPv4 . . . . . . . . . . . . . . . . 10 119 2.3. Translating ICMPv4 Headers into ICMPv6 Headers . . . . . . 11 120 2.4. Translating ICMPv4 Error Messages into ICMPv6 . . . . . . 14 121 2.5. Translator sending ICMP error message . . . . . . . . . . 14 122 2.6. Transport-layer Header Translation . . . . . . . . . . . . 14 123 2.7. Knowing when to Translate . . . . . . . . . . . . . . . . 15 124 3. Translating from IPv6 to IPv4 . . . . . . . . . . . . . . . . 15 125 3.1. Translating IPv6 Headers into IPv4 Headers . . . . . . . . 16 126 3.2. Translating ICMPv6 Headers into ICMPv4 Headers . . . . . . 18 127 3.3. Translating ICMPv6 Error Messages into ICMPv4 . . . . . . 20 128 3.4. Translator sending ICMPv6 error message . . . . . . . . . 21 129 3.5. Transport-layer Header Translation . . . . . . . . . . . . 21 130 3.6. Knowing when to Translate . . . . . . . . . . . . . . . . 21 131 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 132 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 133 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 134 7. Appendix A: Translating pointer in Parameter Problem . . . . . 23 135 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 136 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 137 8.2. Informative References . . . . . . . . . . . . . . . . . . 24 138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 140 1. Introduction and Motivation 142 An understanding of the framework presented in 143 [I-D.ietf-behave-v6v4-framework] is presumed in this document. 145 The transition mechanisms specified in [RFC4213] handle the case of 146 dual IPv4/IPv6 hosts interoperating with both dual IPv4/IPv6 hosts 147 and IPv4-only hosts, which is needed early in the transition to IPv6. 148 The dual IPv4/IPv6 hosts are assigned both an IPv4 and one or more 149 IPv6 addresses. The number of available globally unique IPv4 150 addresses is becoming smaller and smaller as the Internet grows; we 151 expect that there will be a desire to take advantage of the large 152 IPv6 address space and not require that every new Internet node have 153 a permanently assigned IPv4 address. 155 SIIT [RFC2765] is designed for the case of small networks (e.g., a 156 single subnet) and for a site that has IPv6-only hosts in a dual 157 IPv4/IPv6 network. This use assumes a mechanism for IPv6 nodes to 158 acquire a temporary address from the pool of IPv4 addresses. 159 However, SIIT is not useful in the case when the IPv6 nodes need to 160 acquire temporary IPv4 addresses from a "distant" SIIT box operated 161 by a different administration, or require that the IPv6 Internet 162 contain routes for IPv4-mapped addresses (The latter is known to be a 163 very bad idea due to the size of the IPv4 routing table that would 164 potentially be injected into IPv6 routing in the form of IPv4-mapped 165 addresses.) 167 In addition, due to the IPv4 address depletion problem, it is 168 desirable that a single IPv4 address needs to be shared via transport 169 port multiplexing for different IPv6 nodes when they communicate with 170 other IPv4 hosts. 172 Furthermore, in SIIT [RFC2765], an IPv6-only node that works through 173 SIIT translators needs some modifications beyond a normal IPv6-only 174 node. These modifications are not strictly implied in this document, 175 since normal IPv6 addresses can be used in the IPv6 end nodes. 177 A detailed discussion of translation scenarios is presented in 178 [I-D.ietf-behave-v6v4-framework], while the technical specification 179 of the translation algorithm itself is covered in this document. 181 1.1. Translation Model 183 This document specifies the translation algorithm that is one of the 184 components described in [I-D.ietf-behave-v6v4-framework] needed to 185 make IPv6-only nodes interoperate with IPv4-only nodes as shown in 186 Figure 1. 188 -------- -------- 189 // IPv4 \\ // IPv6 \\ 190 / Domain \ / Domain \ 191 / +----+ +--+ \ 192 | |XLAT| |S2| | Sn: Servers 193 | +--+ +----+ +--+ | Hn: Clients 194 | |S1| +----+ | 195 | +--+ |DNS | +--+ | XLAT: V4/V6 Translator 196 \ +--+ +----+ |H2| / DNS: DNS Server 197 \ |H1| / \ +--+ / 198 \\ +--+ // \\ // 199 -------- -------- 201 Figure 1: Translation Model 203 The translation model consists of two or more network domains 204 connected by one or more IP/ICMP translators. One of those networks 205 either routes IPv4 but not IPv6, or contains some hosts that only 206 implement IPv4 or have IPv4 only applications (even if the host and 207 the network support IPv6). The other network either routes IPv6 but 208 not IPv4, or contains some hosts that only implement IPv6 or has IPv6 209 only applications. Both networks contain clients, servers, and 210 peers. 212 1.2. Applicability and Limitations 214 The use of this translation algorithm assumes that the IPv6 network 215 is somehow well-connected i.e., when an IPv6 node wants to 216 communicate with another IPv6 node there is an IPv6 path between 217 them. Various tunneling schemes exist that can provide such a path, 218 but those mechanisms and their use is outside the scope of this 219 document and [RFC2765]. 221 The translation algorithm can be used not only in a subnet, but can 222 also be used in service provider's backbone network. 224 The translating function specified in this document does not 225 translate any IPv4 options and it does not translate IPv6 routing 226 headers, hop-by-hop extension headers, destination options headers or 227 source routing headers, same as in [RFC2765]. 229 The issues and algorithms in the translation of datagram containing 230 TCP segments are described in [RFC5382]. The considerations of that 231 document are applicable in this case as well. 233 Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e. 234 the UDP checksum field is zero) are not of significant use in the 235 Internet and will not be translated by the IP/ICMP translator 237 [Miller][Dongjin]. 239 IPv4 multicast addresses [RFC3171] cannot be mapped to IPv6 multicast 240 addresses [RFC3307] based on the unicast mapping rule. However, a 241 special rule for address translation can be created for the multicast 242 packet translation algorithm; if that is done, the IP/ICMP header 243 translation aspect of this memo works. 245 1.3. Stateless vs. Stateful Mode 247 The IP/ICMP translator has two possible modes of operation: stateless 248 and stateful [I-D.ietf-behave-v6v4-framework]. In both cases, we 249 assume that a system that has an IPv4 address but not an IPv6 address 250 is communicating with a system that has an IPv6 address but no IPv4 251 address, or that the two systems do not have contiguous routing 252 connectivity and hence are forced to have their communications 253 translated. 255 In the stateless mode, a specific IPv6 address range will represent 256 IPv4 systems (IPv4-converted addresses), and the IPv6 systems have 257 addresses that can be algorithmatically mapped to a subset of the 258 service provider's IPv4 addresses (IPv4-translatable addresses). In 259 this mode, there is no need to concern oneself with port translation 260 or translation tables, as the IPv4 and IPv6 counterparts are 261 algorithmically related. An implementation example of the stateless 262 translation is summarized in [I-D.xli-behave-ivi]. 264 In the stateful mode, a specific IPv6 address range will represent 265 IPv4 systems (IPv4-converted addresses), but the IPv6 systems may use 266 any [RFC4291] addresses except in that range. In this case, a 267 translation table is required to bind the IPv6 systems' addresses to 268 the IPv4 addresses maintained in the translator. 270 The address translation mechanisms for the stateless and the stateful 271 translations are defined in [I-D.ietf-behave-address-format]. 273 1.4. Path MTU discovery and fragmentation 275 Due to the different sizes of the IPv4 and IPv6 header, which are 20+ 276 octets and 40+ octets respectively, handling the maximum packet size 277 is critical for the operation of the IPv4/IPv6 translator. There are 278 three mechanisms to handle this issue: the path MTU discovery, 279 fragmentation and transport layer negotiation such as the TCP MSS 280 option. Note that the translator MUST behave as a router, i.e. the 281 translator MUST send packet too big error message when the packet 282 size exceeds the MTU of the next hop interface. 284 "Don't Fragment", ICMP "too big", and packet fragmentation are 285 discussed in "Translating from IPv4 to IPv6" and "Translating from 286 IPv6 to IPv4" sections of this document. The reassembling of the 287 fragmented packets in the stateful translator is discussed in 288 [I-D.ietf-behave-v6v4-xlate-stateful], since it requires the state 289 maintenance in the translator. 291 2. Translating from IPv4 to IPv6 293 When an IP/ICMP translator receives an IPv4 datagram addressed to a 294 destination towards the IPv6 domain, it translates the IPv4 header of 295 that packet into an IPv6 header. Since the ICMP [RFC0792][RFC4443], 296 TCP [RFC0793] and UDP [RFC0768] headers contain checksums that cover 297 IP header information, if the address mapping algorithm is not 298 checksum-neutral, the ICMP and transport-layer headers MUST be 299 updated. The data portion of the packet is left unchanged. The IP/ 300 ICMP translator then forwards the packet based on the IPv6 301 destination address. The original IPv4 header on the packet is 302 removed and replaced by an IPv6 header. 304 +-------------+ +-------------+ 305 | IPv4 | | IPv6 | 306 | Header | | Header | 307 +-------------+ +-------------+ 308 | Transport | | Fragment | 309 | Layer | ===> | Header | 310 | Header | |(not always) | 311 +-------------+ +-------------+ 312 | | | Transport | 313 ~ Data ~ | Layer | 314 | | | Header | 315 +-------------+ +-------------+ 316 | | 317 ~ Data ~ 318 | | 319 +-------------+ 321 Figure 2: IPv4-to-IPv6 Translation 323 One of the differences between IPv4 and IPv6, is that in IPv6 path 324 MTU discovery is mandatory but it is optional in IPv4. This implies 325 that IPv6 routers will never fragment a packet - only the sender can 326 do fragmentation. 328 When the IPv4 node performs path MTU discovery (by setting the DF bit 329 in the header) the path MTU discovery can operate end-to-end, i.e., 330 across the translator. In this case either IPv4 or IPv6 routers 331 (including the translator) might send back ICMP "packet too big" 332 messages to the sender. When the IPv6 routers send these ICMP errors 333 they will pass through a translator that will translate the ICMP 334 error to a form that the IPv4 sender can understand. In this case, 335 an IPv6 fragment header is only included if the IPv4 packet is 336 already fragmented. 338 However, when the IPv4 sender does not set the DF bit, the translator 339 has to ensure that the packet does not exceed the path MTU on the 340 IPv6 side. This is done by fragmenting the IPv4 packet so that it 341 fits in 1280 byte IPv6 packets, since that is the minimum IPv6 packet 342 size. Also, when the IPv4 sender does not set the DF bit the 343 translator MUST always include an IPv6 fragment header to indicate 344 that the sender allows fragmentation. That is needed should the 345 packet pass through an IP/ICMP translator. 347 The above rules ensure that when packets are fragmented, either by 348 the sender or by IPv4 routers, the low-order 16 bits of the fragment 349 identification are carried end-to-end, ensuring that packets are 350 correctly reassembled. In addition, the rules use the presence of an 351 IPv6 fragment header to indicate that the sender might not be using 352 path MTU discovery, i.e., the packet should not have the DF flag set 353 should it later be translated back to IPv4. 355 Other than the special rules for handling fragments and path MTU 356 discovery, the actual translation of the packet header consists of a 357 simple mapping as defined below. Note that ICMP packets require 358 special handling in order to translate the content of ICMP error 359 message and also to add the ICMP pseudo-header checksum. 361 2.1. Translating IPv4 Headers into IPv6 Headers 363 If the DF flag is not set and the IPv4 packet will result in an IPv6 364 packet larger than 1280 bytes the IPv4 packet MUST be fragmented 365 prior to translating it. Since IPv4 packets with DF not set will 366 always result in a fragment header being added to the packet the IPv4 367 packets must be fragmented so that their length, excluding the IPv4 368 header, is at most 1232 bytes (1280 minus 40 for the IPv6 header and 369 8 for the Fragment header). The resulting fragments are then 370 translated independently using the logic described below. 372 If the DF bit is set and the MTU of the next-hop interface is less 373 than or equal to the total length value of the IPv4 packet minus 20, 374 Send ICMP (packet too big) to IPv4 source address. 376 If the DF bit is set and the packet is not a fragment (i.e., the MF 377 flag is not set and the Fragment Offset is zero) then the translator 378 SHOULD NOT add a fragment header to the packet. The IPv6 header 379 fields are set as follows: 381 Version: 6 383 Traffic Class: By default, copied from IP Type Of Service octet. 384 According to [RFC2474] the semantics of the bits are identical in 385 IPv4 and IPv6. However, in some IPv4 environments these fields 386 might be used with the old semantics of "Type Of Service and 387 Precedence". An implementation of a translator SHOULD provide the 388 ability to ignore the IPv4 "TOS" and always set the IPv6 traffic 389 class to zero. In addition, if the translator is at an 390 administrative boundary, the filtering and update considerations 391 of [RFC2475] may be applicable. 393 Flow Label: 0 (all zero bits) 395 Payload Length: Total length value from IPv4 header, minus the size 396 of the IPv4 header and IPv4 options, if present. 398 Next Header: For ICMP (1) changed to ICMPv6 (58), otherwise protocol 399 field copied from IPv4 header. 401 Hop Limit: TTL value copied from IPv4 header. Since the translator 402 is a router, as part of forwarding the packet it needs to 403 decrement either the IPv4 TTL (before the translation) or the IPv6 404 Hop Limit (after the translation). As part of decrementing the 405 TTL or Hop Limit the translator (as any router) needs to check for 406 zero and send the ICMPv4 "ttl exceeded" or ICMPv6 "hop limit 407 exceeded" error. 409 Source Address: The IPv6 source address is derived from the IPv4 410 source address. Note that the IPv6 source address is the IPv4- 411 converted address. 413 Destination Address: In stateless mode, which is to say that if the 414 IPv4 destination address is within the range of the IPv4 stateless 415 translation prefix, the IPv6 destination address is derived from 416 the IPv4 destination address. Note that the IPv6 destination 417 address is the IPv4-translatable address. 419 In stateful mode, which is to say that if the IPv4 destination 420 address is not within the range of the IPv4 stateless translation 421 prefix, the IPv6 address and corresponding transport-layer 422 destination port are derived from the database reflecting current 423 session state in the translator. Database maintenance is as 424 described in [I-D.ietf-behave-v6v4-xlate-stateful]. 426 If the destination address is in the multicast range, the 427 multicast address mapping method should be applied. 429 If IPv4 options are present in the IPv4 packet, they are ignored 430 i.e., there is no attempt to translate them. However, if an 431 unexpired source route option is present then the packet MUST instead 432 be discarded, and an ICMPv4 "destination unreachable/source route 433 failed" (Type 3/Code 5) error message SHOULD be returned to the 434 sender. 436 If there is a need to add a fragment header (the DF bit is not set or 437 the packet is a fragment) the header fields are set as above with the 438 following exceptions: 440 IPv6 fields: 442 Payload Length: Total length value from IPv4 header, plus 8 for 443 the fragment header, minus the size of the IPv4 header and IPv4 444 options, if present. 446 Next Header: Fragment Header (44). 448 Fragment header fields: 450 Next Header: For ICMP (1) changed to ICMPv6 (58), otherwise 451 protocol field copied from IPv4 header. 453 Fragment Offset: Fragment Offset copied from the IPv4 header. 455 M flag More Fragments bit copied from the IPv4 header. 457 Identification The low-order 16 bits copied from the 458 Identification field in the IPv4 header. The high-order 16 459 bits set to zero. 461 2.2. Translating UDP over IPv4 463 When a translator receives an unfragmented UDP IPv4 packet and the 464 checksum field is zero, the translator SHOULD compute the missing UDP 465 checksum as part of translating the packet. Also, the translator 466 SHOULD maintain a counter of how many UDP checksums are generated in 467 this manner. 469 When a stateless translator receives the first fragment of a 470 fragmented UDP IPv4 packet and the checksum field is zero, the 471 translator SHOULD drop the packet and generate a system management 472 event specifying at least the IP addresses and port numbers in the 473 packet. When it receives fragments other than the first it SHOULD 474 silently drop the packet, since there is no port information to log. 476 The handling of the fragmented UDP IPv4 packets with zero checksum 477 field is discussed in [I-D.ietf-behave-v6v4-xlate-stateful]. 479 2.3. Translating ICMPv4 Headers into ICMPv6 Headers 481 All ICMP messages that are to be translated require that the ICMP 482 checksum field be updated as part of the translation since ICMPv6, 483 unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP. 485 In addition, all ICMP packets need to have the Type value translated 486 and, for ICMP error messages, the included IP header also needs 487 translation. 489 The actions needed to translate various ICMPv4 messages are: 491 ICMPv4 query messages: 493 Echo and Echo Reply (Type 8 and Type 0) Adjust the type to 128 494 and 129, respectively, and adjust the ICMP checksum both to 495 take the type change into account and to include the ICMPv6 496 pseudo-header. 498 Information Request/Reply (Type 15 and Type 16) Obsoleted in 499 ICMPv6. Silently drop. 501 Timestamp and Timestamp Reply (Type 13 and Type 14) Obsoleted in 502 ICMPv6. Silently drop. 504 Address Mask Request/Reply (Type 17 and Type 18) Obsoleted in 505 ICMPv6. Silently drop. 507 ICMP Router Advertisement (Type 9) Single hop message. Silently 508 drop. 510 ICMP Router Solicitation (Type 10) Single hop message. Silently 511 drop. 513 Unknown ICMPv4 types Silently drop. 515 IGMP messages: While the MLD messages [RFC2710][RFC3590][RFC3810] 516 are the logical IPv6 counterparts for the IPv4 IGMP messages 517 all the "normal" IGMP messages are single-hop messages and 518 should be silently dropped by the translator 519 [I-D.venaas-behave-v4v6mc-framework]. Other IGMP messages 520 might be used by multicast routing protocols and, since it 521 would be a configuration error to try to have router 522 adjacencies across IP/ICMP translators those packets should 523 also be silently dropped. 525 ICMPv4 error messages: 527 Destination Unreachable (Type 3) For all codes that are not 528 explicitly listed below, set the Type to 1. 530 Translate the code field as follows: 532 Code 0, 1 (net, host unreachable): Set Code to 0 (no route 533 to destination). 535 Code 2 (protocol unreachable): Translate to an ICMPv6 536 Parameter Problem (Type 4, Code 1) and make the Pointer 537 point to the IPv6 Next Header field. 539 Code 3 (port unreachable): Set Code to 4 (port 540 unreachable). 542 Code 4 (fragmentation needed and DF set): Translate to an 543 ICMPv6 Packet Too Big message (Type 2) with code 0. The 544 MTU field needs to be adjusted for the difference between 545 the IPv4 and IPv6 header sizes, i.e. minimum(advertised 546 MTU+20, MTU_t6, MTU_t4+20). Note that if the IPv4 router 547 did not set the MTU field, i.e., the router does not 548 implement [RFC1191], then the translator must use the 549 plateau values specified in [RFC1191] to determine a 550 likely path MTU and include that path MTU in the ICMPv6 551 packet. (Use the greatest plateau value that is less 552 than the returned Total Length field.) 554 Code 5 (source route failed): Set Code to 0 (no route to 555 destination). Note that this error is unlikely since 556 source routes are not translated. 558 Code 6,7: Set Code to 0 (no route to destination). 560 Code 8: Set Code to 0 (no route to destination). 562 Code 9, 10 (communication with destination host 563 administratively prohibited): Set Code to 1 (communication 564 with destination administratively prohibited) 566 Code 11, 12: Set Code to 0 (no route to destination). 568 Code 13 (Communication Administratively Prohibited): Set 569 Code to 1 (communication with destination 570 administratively prohibited). 572 Code 14 (Host Precedence Violation): Silently drop. 574 Code 15 (Precedence cutoff in effect): Set Code to 1 575 (communication with destination administratively 576 prohibited). 578 Redirect (Type 5) Single hop message. Silently drop. 580 Alternative Host Address (Type 6) Silently drop. 582 Source Quench (Type 4) Obsoleted in ICMPv6. Silently drop. 584 Time Exceeded (Type 11) Set the Type field to 3. The Code 585 field is unchanged. 587 Parameter Problem (Type 12) Set the Type field to 4. 588 Translate the code field as follows: 590 Code 0 (Pointer indicates the error): Set the code to 0 591 (erroneous header field encountered) and update the 592 pointer as defined in Appendix A. 594 Code 1 (Missing a required option): Silently drop 596 Code 2 (Bad length): Set the code to 0 (erroneous header 597 field encountered) and update the pointer as defined in 598 Appendix A. 600 Other Code values: Silently drop 602 Unknown ICMPv4 types Silently drop. 604 ICMP Error Payload If the received ICMP packet contains an 605 ICMP Extension [RFC4884] the translation of the ICMP packet 606 will cause the ICMP packet to change length. When this 607 occurs, the ICMP Extension length attribute MUST be adjusted 608 accordingly (e.g., longer due to the translation from IPv4 609 to IPv6). If the ICMP Extension exceeds the maximum size of 610 an ICMPv6 message on the outgoing interface, the ICMP 611 extension should be simply truncated. For extensions not 612 defined in [RFC4884], the translator passes the extensions 613 as opaque bit strings and those containing IPv4 address 614 literals will not have those addresses translated to IPv6 615 address literals; this is likely to cause problems with 616 processing of those ICMP extensions. 618 2.4. Translating ICMPv4 Error Messages into ICMPv6 620 There are some differences between the IPv4 and the IPv6 ICMP error 621 message formats as detailed above. In addition, the ICMP error 622 messages contain the IP header for the packet in error, which needs 623 to be translated just like a normal IP header. The translation of 624 this "packet in error" is likely to change the length of the 625 datagram. Thus the Payload Length field in the outer IPv6 header 626 might need to be updated. 628 +-------------+ +-------------+ 629 | IPv4 | | IPv6 | 630 | Header | | Header | 631 +-------------+ +-------------+ 632 | ICMPv4 | | ICMPv6 | 633 | Header | | Header | 634 +-------------+ +-------------+ 635 | IPv4 | ===> | IPv6 | 636 | Header | | Header | 637 +-------------+ +-------------+ 638 | Partial | | Partial | 639 | Transport | | Transport | 640 | Layer | | Layer | 641 | Header | | Header | 642 +-------------+ +-------------+ 644 Figure 3: IPv4-to-IPv6 ICMP Error Translation 646 The translation of the inner IP header can be done by recursively 647 invoking the function that translated the outer IP headers. 649 2.5. Translator sending ICMP error message 651 If the packet is discarded, then the translator SHOULD be able to 652 send back an ICMP message to the original sender of the packet, 653 unless the discarded packet is itself an ICMP message. The ICMP 654 message, if sent, has a type of 3 (Destination Unreachable) and a 655 code of 13 (Communication Administratively Prohibited). The 656 translator device MUST allow to configure whether the ICMP error 657 messages are sent, rate-limited or not sent. 659 2.6. Transport-layer Header Translation 661 If the address translation algorithm is not checksum neutral, the 662 recalculation and updating of the transport-layer headers MUST be 663 performed. UDP/IPv4 datagrams with a checksum of zero MAY be dropped 664 and MAY have their checksum calculated for injection into the IPv6 665 domain. This choice SHOULD be under configuration control. 667 2.7. Knowing when to Translate 669 If the IP/ICMP translator is implemented in a router providing both 670 translation and normal forwarding, and the address is reachable by a 671 more specific route without translation, the router MUST forward it 672 without translating it. Otherwise, when an IP/ICMP translator 673 receives an IPv4 datagram addressed to a destination towards the IPv6 674 domain, the packet will be translated to IPv6. 676 3. Translating from IPv6 to IPv4 678 When an IP/ICMP translator receives an IPv6 datagram addressed to a 679 destination towards the IPv4 domain, it translates the IPv6 header of 680 that packet into an IPv4 header. Since the ICMP [RFC0792][RFC4443], 681 TCP [RFC0793] and UDP [RFC0768] headers contain checksums that cover 682 the IP header, if the address mapping algorithm is not checksum- 683 neutral, the ICMP and transport-layer headers MUST be updated. The 684 data portion of the packet is left unchanged. The IP/ICMP translator 685 then forwards the packet based on the IPv4 destination address. The 686 original IPv6 header on the packet is removed and replaced by an IPv4 687 header. 689 +-------------+ +-------------+ 690 | IPv6 | | IPv4 | 691 | Header | | Header | 692 +-------------+ +-------------+ 693 | Fragment | | Transport | 694 | Header | ===> | Layer | 695 |(if present) | | Header | 696 +-------------+ +-------------+ 697 | Transport | | | 698 | Layer | ~ Data ~ 699 | Header | | | 700 +-------------+ +-------------+ 701 | | 702 ~ Data ~ 703 | | 704 +-------------+ 706 Figure 4: IPv6-to-IPv4 Translation 708 There are some differences between IPv6 and IPv4 in the area of 709 fragmentation and the minimum link MTU that affect the translation. 710 An IPv6 link has to have an MTU of 1280 bytes or greater. The 711 corresponding limit for IPv4 is 68 bytes. Thus, unless there were 712 special measures, it would not be possible to do end-to-end path MTU 713 discovery when the path includes a translator since the IPv6 node 714 might receive ICMP "packet too big" messages originated by an IPv4 715 router that report an MTU less than 1280. However, [RFC2460] section 716 5 requires that IPv6 nodes handle such an ICMP "packet too big" 717 message by reducing the path MTU to 1280 and including an IPv6 718 fragment header with each packet. This allows end-to-end path MTU 719 discovery across the translator as long as the path MTU is 1280 bytes 720 or greater. When the path MTU drops below the 1280 limit the IPv6 721 sender will originate 1280-byte packets that will be fragmented by 722 IPv4 routers along the path after being translated to IPv4. 724 The only drawback with this scheme is that it is not possible to use 725 PMTU to do optimal UDP fragmentation (as opposed to completely 726 avoiding fragmentation) at the sender, since the presence of an IPv6 727 fragment header is interpreted that it is okay to fragment the packet 728 on the IPv4 side. Thus if a UDP application wants to send large 729 packets independent of the PMTU, the sender will only be able to 730 determine the path MTU on the IPv6 side of the translator. If the 731 path MTU on the IPv4 side of the translator is smaller, then the IPv6 732 sender will not receive any ICMP "too big" errors and cannot adjust 733 the size fragments it is sending. 735 Other than the special rules for handling fragments and path MTU 736 discovery the actual translation of the packet header consists of a 737 simple mapping as defined below. Note that ICMP packets require 738 special handling in order to translate the contents of ICMP error 739 message and also to add the ICMP pseudo-header checksum. 741 3.1. Translating IPv6 Headers into IPv4 Headers 743 If there is no IPv6 Fragment header, the IPv4 header fields are set 744 as follows: 746 Version: 4 748 Internet Header Length: 5 (no IPv4 options) 750 Type of Service (TOS) Octet: By default, copied from the IPv6 751 Traffic Class (all 8 bits). According to [RFC2474] the semantics 752 of the bits are identical in IPv4 and IPv6. However, in some IPv4 753 environments, these bits might be used with the old semantics of 754 "Type Of Service and Precedence". An implementation of a 755 translator SHOULD provide the ability to ignore the IPv6 traffic 756 class and always set the IPv4 TOS Octet to a specified value. In 757 addition, if the translator is at an administrative boundary, the 758 filtering and update considerations of [RFC2475] may be 759 applicable. 761 Total Length: Payload length value from IPv6 header, plus the size 762 of the IPv4 header. 764 Identification: All zero. 766 Flags: The More Fragments flag is set to zero. The Don't Fragments 767 flag is set to one. 769 Fragment Offset: All zero. 771 Time to Live: Hop Limit value copied from IPv6 header. Since the 772 translator is a router, as part of forwarding the packet it needs 773 to decrement either the IPv6 Hop Limit (before the translation) or 774 the IPv4 TTL (after the translation). As part of decrementing the 775 TTL or Hop Limit the translator (as any router) needs to check for 776 zero and send the ICMPv4 "ttl exceeded" or ICMPv6 "hop limit 777 exceeded" error. 779 Protocol: For ICMPv6 (58) changed to ICMP (1), otherwise Next Header 780 field copied from IPv6 header. 782 Header Checksum: Computed once the IPv4 header has been created. 784 Source Address: In stateless mode, which is to say that if the IPv6 785 source address is within the range of the IPv6 stateless 786 translation prefix, the IPv4 source address is derived from the 787 IPv6 address. Note that the original IPv6 source address is the 788 IPv4-translatable address. 790 In stateful mode, which is to say that if the IPv6 source address 791 is not within the range of the IPv6 stateless translation prefix, 792 the IPv4 source address and transport layer source port 793 corresponding to the IPv4-related IPv6 source address and source 794 port are derived from the database reflecting current session 795 state in the translator. Database maintenance is described in 796 [I-D.ietf-behave-v6v4-xlate-stateful]. 798 Destination Address: The IPv4 destination address is derived from 799 the IPv6 destination address of the datagram being translated. 800 Note that the original IPv6 destination address is the IPv4- 801 converted address. 803 If the destination address is in the multicast range, the 804 multicast address mapping method should be applied. 806 If any of an IPv6 hop-by-hop options header, destination options 807 header, or routing header with the Segments Left field equal to zero 808 are present in the IPv6 packet, they are ignored i.e., there is no 809 attempt to translate them. However, the Total Length field and the 810 Protocol field is adjusted to "skip" these extension headers. 812 If a routing header with a non-zero Segments Left field is present 813 then the packet MUST NOT be translated, and an ICMPv6 "parameter 814 problem/erroneous header field encountered" (Type 4/Code 0) error 815 message, with the Pointer field indicating the first byte of the 816 Segments Left field, SHOULD be returned to the sender. 818 If the IPv6 packet contains a Fragment header the header fields are 819 set as above with the following exceptions: 821 Total Length: Payload length value from IPv6 header, minus 8 for the 822 Fragment header, plus the size of the IPv4 header. 824 Identification: Copied from the low-order 16-bits in the 825 Identification field in the Fragment header. 827 Flags: The More Fragments flag is copied from the M flag in the 828 Fragment header. The Don't Fragments flag is set to zero allowing 829 this packet to be fragmented by IPv4 routers. 831 Fragment Offset: Copied from the Fragment Offset field in the 832 Fragment header. 834 Protocol: For ICMPv6 (58) changed to ICMP (1), otherwise Next Header 835 field copied from Fragment header. 837 3.2. Translating ICMPv6 Headers into ICMPv4 Headers 839 All ICMP messages that are to be translated require that the ICMP 840 checksum field be updated as part of the translation since ICMPv6 841 (unlike ICMPv4) includes a pseudo-header in the checksum just like 842 UDP and TCP. 844 In addition all ICMP packets need to have the Type value translated 845 and, for ICMP error messages, the included IP header also needs 846 translation. Note that the IPv6 addresses in the IPv6 header may not 847 be the IPv4-translatable addresses and there will be no corresponding 848 IPv4 addresses. In this case, a special block of the IPv4 address 849 can be used to indicate this phenomenon. 851 The actions needed to translate various ICMPv6 messages are: 853 ICMPv6 informational messages: 855 Echo Request and Echo Reply (Type 128 and 129) Adjust the type to 856 8 and 0, respectively, and adjust the ICMP checksum both to 857 take the type change into account and to exclude the ICMPv6 858 pseudo-header. 860 MLD Multicast Listener Query/Report/Done (Type 130, 131, 132) 861 Single hop message. Silently drop. 863 Neighbor Discover messages (Type 133 through 137) Single hop 864 message. Silently drop. 866 Unknown informational messages Silently drop. 868 ICMPv6 error messages: 870 Destination Unreachable (Type 1) Set the Type field to 3. 871 Translate the code field as follows: 873 Code 0 (no route to destination): Set Code to 1 (host 874 unreachable). 876 Code 1 (communication with destination administratively 877 prohibited): Set Code to 10 (communication with destination 878 host administratively prohibited). 880 Code 2 (beyond scope of source address): Set Code to 1 (host 881 unreachable). Note that this error is very unlikely since 882 the IPv4-translatable source address is considered to have 883 global scope. 885 Code 3 (address unreachable): Set Code to 1 (host 886 unreachable). 888 Code 4 (port unreachable): Set Code to 3 (port unreachable). 890 Packet Too Big (Type 2) Translate to an ICMPv4 Destination 891 Unreachable with code 4. The MTU field needs to be adjusted 892 for the difference between the IPv4 and IPv6 header sizes 893 taking into account whether or not the packet in error includes 894 a Fragment header, i.e. minimum(advertised MTU-20, MTU_t4, 895 MTU_t6-20) 897 Time Exceeded (Type 3) Set the Type to 11. The Code field is 898 unchanged. 900 Parameter Problem (Type 4) Translate the type and code field as 901 follows: 903 Code 1 (unrecognized Next Header type encountered): Translate 904 this to an ICMPv4 protocol unreachable (Type 3, Code 2). 906 Code 0 (erroneous header field encountered): Set Type 12, Code 907 0 and update the pointer as defined in Appendix A. 909 Code 2 (unrecognized IPv6 option encountered): Silently drop. 911 Unknown error messages Silently drop. 913 ICMP Error Payload If the received ICMPv6 packet contains an ICMP 914 Extension [RFC4884], the translation of the ICMPv6 packet will 915 cause the ICMPv6 packet to change length. When this occurs, 916 the ICMPv6 Extension length attribute MUST be adjusted 917 accordingly (e.g., shorter due to the translation from IPv6 to 918 IPv4). For extensions not defined in [RFC4884], the translator 919 passes the extensions as opaque bit strings and those 920 containing IPv6 address literals will not have those addresses 921 translated to IPv4 address literals; this is likely to cause 922 problems with processing of those ICMP extensions. 924 3.3. Translating ICMPv6 Error Messages into ICMPv4 926 There are some differences between the IPv4 and the IPv6 ICMP error 927 message formats as detailed above. In addition, the ICMP error 928 messages contain the IP header for the packet in error, which needs 929 to be translated just like a normal IP header. The translation of 930 this "packet in error" is likely to change the length of the datagram 931 thus the Total Length field in the outer IPv4 header might need to be 932 updated. 934 +-------------+ +-------------+ 935 | IPv6 | | IPv4 | 936 | Header | | Header | 937 +-------------+ +-------------+ 938 | ICMPv6 | | ICMPv4 | 939 | Header | | Header | 940 +-------------+ +-------------+ 941 | IPv6 | ===> | IPv4 | 942 | Header | | Header | 943 +-------------+ +-------------+ 944 | Partial | | Partial | 945 | Transport | | Transport | 946 | Layer | | Layer | 947 | Header | | Header | 948 +-------------+ +-------------+ 950 Figure 5: IPv6-to-IPv4 ICMP Error Translation 952 The translation of the inner IP header can be done by recursively 953 invoking the function that translated the outer IP headers. Note 954 that the IPv6 addresses in the IPv6 header may not be the IPv4- 955 translatable addresses and there will be no corresponding IPv4 956 addresses. In this case, a special block of the IPv4 address can be 957 used to indicate this phenomenon. 959 3.4. Translator sending ICMPv6 error message 961 If the packet is discarded, then the translator SHOULD be able to 962 send back an ICMPv6 message to the original sender of the packet, 963 unless the discarded packet is itself an ICMPv6 message. The ICMPv6 964 message, if sent, has a type of 1 (Destination Unreachable) and a 965 code of 1 (Communication with destination administratively 966 prohibited). The translator device MUST allow configuring whether 967 the ICMPv6 error messages are sent, rate-limited or not sent. 969 3.5. Transport-layer Header Translation 971 If the address translation algorithm is not checksum neutral, the 972 recalculation and updating of the transport-layer headers MUST be 973 performed. 975 3.6. Knowing when to Translate 977 If the IP/ICMP translator is implemented in a router providing both 978 translation and normal forwarding, and the address is reachable by a 979 more specific route without translation, the router MUST forward it 980 without translating it. When an IP/ICMP translator receives an IPv6 981 datagram addressed to a destination towards the IPv4 domain, the 982 packet will be translated to IPv4. 984 4. IANA Considerations 986 This memo adds no new IANA considerations. 988 Note to RFC Editor: This section will have served its purpose if it 989 correctly tells IANA that no new assignments or registries are 990 required, or if those assignments or registries are created during 991 the RFC publication process. From the author's perspective, it may 992 therefore be removed upon publication as an RFC at the RFC Editor's 993 discretion. 995 5. Security Considerations 997 The use of stateless IP/ICMP translators does not introduce any new 998 security issues beyond the security issues that are already present 999 in the IPv4 and IPv6 protocols and in the routing protocols that are 1000 used to make the packets reach the translator. 1002 There are potential issues that might arise by extracting an IPv4 1003 address from the IPv6 address - particularly addresses like broadcast 1004 or loopback addresses and the non IPv4-translatable IPv6 addresses, 1005 etc. Special action SHOULD be taken to avoid security problems. 1007 As the Authentication Header [RFC4302] is specified to include the 1008 IPv4 Identification field and the translating function is not able to 1009 always preserve the Identification field, it is not possible for an 1010 IPv6 endpoint to verify the AH on received packets that have been 1011 translated from IPv4 packets. Thus AH does not work through a 1012 translator. 1014 Packets with ESP can be translated since ESP does not depend on 1015 header fields prior to the ESP header. Note that ESP transport mode 1016 is easier to handle than ESP tunnel mode; in order to use ESP tunnel 1017 mode, the IPv6 node needs to be able to generate an inner IPv4 header 1018 when transmitting packets and remove such an IPv4 header when 1019 receiving packets. 1021 6. Acknowledgements 1023 This is under development by a large group of people. Those who have 1024 posted to the list during the discussion include Andrew Sullivan, 1025 Andrew Yourtchenko, Brian Carpenter, Dan Wing, Dave Thaler, Ed 1026 Jankiewicz, Hiroshi Miyata, Iljitsch van Beijnum, Jari Arkko, Jerry 1027 Huang, John Schnizlein, Kentaro Ebisawa, Kevin Yin, Magnus 1028 Westerlund, Marcelo Bagnulo Braun, Margaret Wasserman, Masahito Endo, 1029 Phil Roberts, Philip Matthews, Remi Denis-Courmont, Remi Despres, 1030 Senthil Sivakumar, Simon Perreault and Zen Cao. 1032 7. Appendix A: Translating pointer in Parameter Problem 1034 * Translating from IPv4 to IPv6: 1036 | Original IPv4 Pointer | Translated IPv6 Pointer Vaule | 1037 +--------------------------------+--------------------------------+ 1038 | 0 | Version/IHL | 0 | Version/Traffic Class | 1039 | 1 | Type Of Service | 0or1| Traffic Class/Flow Label | 1040 | 2,3 | Total Length | 4,5 | Payload Length | 1041 | 4,5 | Identification | - | | 1042 | 6 | Flags/Fragment Offset | - | | 1043 | 7 | Fragment Offset | - | | 1044 | 8 | Time to Live | 7 | Hop Limit | 1045 | 9 | Protocol | 6 | Next Header | 1046 |10,11| Header Checksum | - | | 1047 |12-15| Source Address | 8-23| Source Address | 1048 |16-19| Destination Address |24-39| Destination Address | 1049 +--------------------------------+--------------------------------+ 1051 * Translating from IPv6 to IPv4: 1053 | Original IPv6 Pointer | Translated IPv4 Pointer Vaule | 1054 +--------------------------------+--------------------------------+ 1055 | 0 | Version/Traffic Class | 0or1| Version/IHL, Type Of Ser | 1056 | 1 | Traffic Class/Flow Label | 1 | Type Of Service | 1057 | 2,3 | Flow Label | - | | 1058 | 4,5 | Payload Length | 2,3 | Total Length | 1059 | 6 | Next Header | 9 | Protocol | 1060 | 7 | Hop Limit | 8 | Time to Live | 1061 | 8-23| Source Address |12-15| Source Address | 1062 |24-39| Destination Address |16-19| Destination Address | 1063 +--------------------------------+--------------------------------+ 1065 Figure 6 1067 8. References 1068 8.1. Normative References 1070 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1071 August 1980. 1073 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1074 September 1981. 1076 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1077 RFC 792, September 1981. 1079 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1080 RFC 793, September 1981. 1082 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1083 Requirement Levels", BCP 14, RFC 2119, March 1997. 1085 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1086 (IPv6) Specification", RFC 2460, December 1998. 1088 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 1089 (SIIT)", RFC 2765, February 2000. 1091 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1092 Architecture", RFC 4291, February 2006. 1094 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1095 Message Protocol (ICMPv6) for the Internet Protocol 1096 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1098 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 1099 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 1100 April 2007. 1102 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 1103 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 1104 RFC 5382, October 2008. 1106 8.2. Informative References 1108 [Dongjin] Lee, D., "Email to the behave mailing list", Sept 2009. 1110 [I-D.ietf-behave-address-format] 1111 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 1112 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 1113 draft-ietf-behave-address-format-02 (work in progress), 1114 December 2009. 1116 [I-D.ietf-behave-v6v4-framework] 1117 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1118 IPv4/IPv6 Translation", 1119 draft-ietf-behave-v6v4-framework-03 (work in progress), 1120 October 2009. 1122 [I-D.ietf-behave-v6v4-xlate-stateful] 1123 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 1124 Address and Protocol Translation from IPv6 Clients to IPv4 1125 Servers", draft-ietf-behave-v6v4-xlate-stateful-05 (work 1126 in progress), December 2009. 1128 [I-D.venaas-behave-v4v6mc-framework] 1129 Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6 1130 Multicast Translation", 1131 draft-venaas-behave-v4v6mc-framework-01 (work in 1132 progress), October 2009. 1134 [I-D.xli-behave-ivi] 1135 Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 1136 CERNET IVI Translation Design and Deployment for the IPv4/ 1137 IPv6 Coexistence and Transition", draft-xli-behave-ivi-05 1138 (work in progress), December 2009. 1140 [Miller] Miller, G., "Email to the ngtrans mailing list", 1141 March 1999. 1143 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1144 November 1990. 1146 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1147 "Definition of the Differentiated Services Field (DS 1148 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1149 December 1998. 1151 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1152 and W. Weiss, "An Architecture for Differentiated 1153 Services", RFC 2475, December 1998. 1155 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1156 Listener Discovery (MLD) for IPv6", RFC 2710, 1157 October 1999. 1159 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 1160 "IANA Guidelines for IPv4 Multicast Address Assignments", 1161 BCP 51, RFC 3171, August 2001. 1163 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 1164 Addresses", RFC 3307, August 2002. 1166 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 1167 Listener Discovery (MLD) Protocol", RFC 3590, 1168 September 2003. 1170 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1171 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1173 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1174 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1176 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1177 December 2005. 1179 Authors' Addresses 1181 Xing Li 1182 CERNET Center/Tsinghua University 1183 Room 225, Main Building, Tsinghua University 1184 Beijing, 100084 1185 China 1187 Phone: +86 10-62785983 1188 Email: xing@cernet.edu.cn 1190 Congxiao Bao 1191 CERNET Center/Tsinghua University 1192 Room 225, Main Building, Tsinghua University 1193 Beijing, 100084 1194 China 1196 Phone: +86 10-62785983 1197 Email: congxiao@cernet.edu.cn 1199 Fred Baker 1200 Cisco Systems 1201 Santa Barbara, California 93117 1202 USA 1204 Phone: +1-408-526-4257 1205 Email: fred@cisco.com