idnits 2.17.1 draft-ietf-ngtrans-siit-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 14, 1998) is 9266 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) == Missing Reference: 'RFC 2133' is mentioned on line 264, but not defined ** Obsolete undefined reference: RFC 2133 (Obsoleted by RFC 2553) == Unused Reference: 'IPv4' is defined on line 935, but no explicit reference was found in the text == Unused Reference: 'DISCOVERY' is defined on line 943, but no explicit reference was found in the text == Unused Reference: 'IPv6-SA' is defined on line 946, but no explicit reference was found in the text == Unused Reference: 'IPv6-AUTH' is defined on line 949, but no explicit reference was found in the text == Unused Reference: 'IPv6-ESP' is defined on line 952, but no explicit reference was found in the text == Unused Reference: 'ICMPv4' is defined on line 955, but no explicit reference was found in the text == Unused Reference: 'ICMPv6' is defined on line 958, but no explicit reference was found in the text == Unused Reference: 'IGMP' is defined on line 962, but no explicit reference was found in the text == Unused Reference: 'PMTUv6' is defined on line 968, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1883 (ref. 'IPv6') (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1884 (ref. 'ADDR-ARCH') (Obsoleted by RFC 2373) ** Obsolete normative reference: RFC 1933 (ref. 'TRANS-MECH') (Obsoleted by RFC 2893) ** Obsolete normative reference: RFC 1970 (ref. 'DISCOVERY') (Obsoleted by RFC 2461) ** Obsolete normative reference: RFC 1825 (ref. 'IPv6-SA') (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1826 (ref. 'IPv6-AUTH') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (ref. 'IPv6-ESP') (Obsoleted by RFC 2406) ** Obsolete normative reference: RFC 1885 (ref. 'ICMPv6') (Obsoleted by RFC 2463) ** Obsolete normative reference: RFC 1981 (ref. 'PMTUv6') (Obsoleted by RFC 8201) -- Possible downref: Non-RFC (?) normative reference: ref. 'DIFFSERV' -- Possible downref: Non-RFC (?) normative reference: ref. 'MLD' Summary: 18 errors (**), 0 flaws (~~), 13 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Erik Nordmark, Sun Microsystems 3 December 14, 1998 5 Stateless IP/ICMP Translator (SIIT) 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 25 Rim). 27 Distribution of this memo is unlimited. 29 This Internet Draft expires June 14, 1999. 31 Abstract 33 This document specifies a transition mechanism in addition to those 34 already specified in RFC 1933. The new mechanism can be used as part 35 of a solution that allows IPv6 hosts that do not have a permanently 36 assigned IPv4 address to communication with IPv4-only hosts. 38 Acknowledgements 40 Some text has been extracted from an old Internet Draft titled "IPAE: 41 The SIPP Interoperability and Transition Mechanism" authored by R. 42 Gilligan, E. Nordmark, and B. Hinden. George Tsirtsis provides the 43 figures for Section 1. 45 Contents 47 Status of this Memo.......................................... 1 49 1. INTRODUCTION AND MOTIVATION.............................. 2 50 1.1. Applicability and Limitations....................... 4 51 1.2. Impact Outside the Network Layer.................... 6 53 2. TERMINOLOGY.............................................. 7 54 2.1. Addresses........................................... 7 55 2.2. Requirements........................................ 8 57 3. OVERVIEW................................................. 8 58 3.1. Assumptions......................................... 8 60 4. TRANSLATING FROM IPv4 TO IPv6............................ 9 61 4.1. Translating IPv4 Headers............................ 10 62 4.2. Translating ICMPv4.................................. 12 63 4.3. Translating ICMPv4 Error Messages................... 14 64 4.4. Knowing when to Translate........................... 15 66 5. TRANSLATING FROM IPv6 TO IPv4............................ 15 67 5.1. Translating IPv6 Headers............................ 17 68 5.2. Translating ICMPv6.................................. 19 69 5.3. Translating ICMPv6 Error Messages................... 20 70 5.4. Knowing when to Translate........................... 21 72 6. SECURITY CONSIDERATIONS.................................. 21 74 REFERENCES................................................... 21 76 AUTHOR'S ADDRESS............................................. 23 78 1. INTRODUCTION AND MOTIVATION 80 The transition mechanisms specified in [TRANS-MECH] handle the case 81 of dual IPv4/IPv6 hosts interoperating with both dual hosts and 82 IPv4-only hosts which is needed early in the transition to IPv6. The 83 dual hosts are assigned both an IPv4 and one or more IPv6 addresses. 84 As the pool of globally unique IPv4 addresses becomes smaller and 85 smaller as the Internet grows there will be a desire to take 86 advantage of the large IPv6 address and not require that every new 87 Internet node have a permanently assigned IPv4 address. 89 There are several different scenarios where there might be IPv6-only 90 hosts that need to communicate with IPv4-only hosts. These IPv6 91 hosts might be IPv4-capable, i.e. include an IPv4 implementation but 92 not be assigned an IPv4 address, or they might not even include an 93 IPv4 implementation. 95 - A completely new network with new devices that all support IPv6. 96 In this case it might be beneficial to not have to configure the 97 routers within the new network to route IPv4 since none of the 98 hosts in the new network are configured with IPv4 addresses. But 99 these new IPv6 devices might occasionally need to communicate with 100 some IPv4 nodes out on the Internet. 102 - An existing network where a large number of IPv6 devices are 103 added. The IPv6 devices might have both an IPv4 and an IPv6 104 protocol stack but there is not enough global IPv4 address space 105 to give each one of them a permanent IPv4 address. In this case 106 it is more likely that the routers in the network already route 107 IPv4 and are upgraded to dual routers. 109 If there is no IPv4 routing inside the network i.e., the cloud that 110 contains the new devices, some possible solutions are to either use 111 the translators specified in this document at the boundary of the 112 cloud, or to use Application Layer Gateways (ALG) on dual nodes at 113 the cloud's boundary. The ALG solution is less flexible in that it 114 is application protocol specific and it is also less robust since a 115 the ALG box is likely to be a single point of failure for a 116 connection using that box. 118 If there IPv4 routing is supported inside the cloud and the 119 implementations support both IPv6 and IPv4 it might suffice to have a 120 mechanism for allocating temporary IPv4 and use IPv4 end to end when 121 communicating with IPv4-only nodes. However, it would seem that such 122 a solution would require the pool of temporary IPv4 addresses to be 123 partitioned across all the subnets in the cloud which would either 124 require a larger pool of IPv4 addresses or result in cases where 125 communication would fail due to no available IPv4 address for the 126 node's subnet. 128 This document specifies a mechanism by which IPv6-only nodes can 129 interoperate with IPv4-only nodes by having the IPv6-only nodes 130 somehow acquire a temporary IPv4 address. That IPv4 address will be 131 used as an IPv4-compatible IPv6 address and the packets will travel 132 through a stateless IP/ICMP translator that will translate the packet 133 headers between IPv4 and IPv6 and translate the addresses in those 134 headers between IPv4 addresses on one side and IPv4-compatible or 135 IPv4-mapped IPv6 addresses on the other side. 137 This specification does not cover how an IPv6 node can acquire a 138 temporary IPv4 address and how such a temporary address be registered 139 in the DNS. The DHCP protocol, perhaps with some extensions, could 140 probably be used to acquire temporary addresses with short leases but 141 that is outside the scope of this document. The mechanism for 142 routing this temporary IPv4 address (or the IPv4-compatible IPv6 143 address) in the site is currently not specified in this document. 145 The figures below show how the Stateless IP/ICMP Translator (SIIT) 146 can be used initially for small networks (e.g., a single subnet) and 147 later for a site which has IPv6-only hosts in a dual IPv4/IPv6 148 network. This use assumes a mechanism for the IPv6 nodes to acquire 149 an temporary address from the pool of IPv4 addresses. Note that SIIT 150 is not likely to be useful later during transition when most of the 151 Internet is IPv6 and there are only small islands of IPv4 nodes, 152 since such use would either require the IPv6 nodes to acquire 153 temporary IPv4 addresses from a "distant" SIIT box operated by a 154 different administration, or require that the IPv6 routing contain 155 routes for IPv6-mapped addresses. (The latter is known to be a very 156 bad idea.) 158 ___________ 159 / \ 160 [IPv6 Host]---[SIIT]---------< IPv4 network>--[IPv4 Host] 161 | \___________/ 162 (pool of IPv4 addresses) 164 Figure 1. Using SIIT for a single IPv6-only subnet. 166 ___________ ___________ 167 / \ / \ 168 [IPv6 Host]--< Dual network>--[SIIT]--< IPv4 network>--[IPv4 Host] 169 \___________/ | \___________/ 170 (pool of IPv4 addresses) 172 Figure 2. Using SIIT for an IPv6-only or dual cloud (e.g. a site) 173 which contains some IPv6-only hosts as well as IPv4 hosts. 175 1.1. Applicability and Limitations 177 The IPv6 protocol [IPv6] has been designed so that the transport 178 pseudo-header checksums are not affected by such a translation thus 179 the translator does not need to modify TCP and UDP headers. However, 180 ICMPv6 include a pseudo-header checksum but it is not present in 181 ICMPv4 thus the checksum in ICMP messages need to be modified by the 182 translator. In addition, ICMP error messages contain an IP header as 183 part of the payload thus the translator need to rewrite those parts 184 of the packets to make the receiver be able to understand the 185 included IP header. However, all of the translators operations, 186 including path MTU discovery, are stateless in the sense that the 187 translator operates independently of each packet and does not retain 188 any state from one packet to another. This allows redundant 189 translator boxes without any coordination and a given TCP connection 190 can have the two directions of packets go through different 191 translator boxes. 193 The translating function as specified in this document does not 194 translate any IPv4 options and it does not translate IPv6 routing 195 headers, hop-by-hop extension headers, or destination options 196 headers. It could be possible to define a translation between source 197 routing in IPv4 and IPv6. However such a translation would not be 198 semantically correct since the IPv4 source routing option performs a 199 "record route" function as the nodes listed in the source route are 200 traversed and the IPv6 routing header does not include the record 201 route aspect. Also, the usefulness of source routing when going 202 through a header translator might be limited since all the routers 203 would need to have an IPv4 address (or an IPv4-compatible IPv6 204 address) since the IPv4-only node will send a source option 205 containing only IPv4 addresses. 207 At first sight it might appear that the IPsec functionality [IPv6-SA, 208 IPv6-ESP, IPv6-AH] can not be carried across the translator. 209 However, since the translator does not modify any headers above the 210 logical IP layer (IP headers, IPv6 fragment headers, and ICMP 211 messages) packets encrypted using ESP in Transport-mode can be 212 carried through the translator. [Note that this assumes that the key 213 management can operate between the IPv6-only and the IPv4-only node.] 214 The use of AH headers is more complex since the AH computation covers 215 most of the fields in the IP header. Should it be possible for the 216 IPv6 node to predict the value of all the IPv4 header fields on the 217 other side of the translator then the IPv6 node could calculate the 218 authentication data using an IPv4 header instead of the IPv6 header 219 even though it is sending and receiving IPv6 packets. [Currently 220 this is not possible since the IP fragment identification field is 221 not carried end-to-end through the translator in all cases. This 222 could be resolved by changing AH to not include the fragment 223 identification field in the AH computation for either IPv4 or IPv6.] 224 For ESP Tunnel-mode the IPv6 node would have to be able to parse and 225 generate "inner" IPv4 headers since the inner IP will be encrypted 226 together with the transport protocol. 228 IPv4 multicast addresses can not be mapped to IPv6 multicast 229 addresses. For instance, ::ffff:224.1.2.3 is an IPv4 mapped IPv6 230 address with a class D address, however it is not an IPv6 multicast 231 address. While the IP/ICMP translation aspect of this draft works 232 for multicast packets this address mapping limitation makes it hard 233 to the techniques in this draft for multicast traffic. 235 1.2. Impact Outside the Network Layer 237 The potential existence of stateless IP/ICMP translators is already 238 taken care of from a protocol perspective in [IPv6]. However, an 239 IPv6 node that wants to be able to use translators need some 240 additional logic in the network layer. 242 The network layer in an IPv6-only node when presented with either an 243 IPv4 destination address or an IPv4-mapped IPv6 destination address 244 by the application is likely to drop the packet and return some error 245 message to the application. In order to take advantage of 246 translators such a node should instead send an IPv6 packet where the 247 destination address is the IPv4-mapped address and the source address 248 is the nodes temporarily assigned IPv4-compatible address. If the 249 node does not have a temporarily assigned IPv4-compatible address it 250 should acquire one using mechanisms that are not discussed in this 251 document. 253 Note that the above also applies to a dual implementation node which 254 is not configured with any IPv4 address. 256 There are no extra changes needed to applications to operate through 257 a translator. The applications that have been modified to work on a 258 dual node already have the mechanisms to determine whether they are 259 communicating with an IPv4 or an IPv6 peer. Thus if the applications 260 need to modify their behavior depending on the type of the peer, such 261 as ftp determining which flavor of PORT command to use, they already 262 need to do that when running on dual nodes and the presense of 263 translators does not add anything. For example, when using the 264 socket API [RFC 2133] the applications know that the peer is IPv6 if 265 they get an AF_INET6 address from the name service and the address is 266 not an IPv4-mapped address (i.e., IN6_IS_ADDR_V4MAPPED returns 267 false). If this is not the case, i.e., the address is AF_INET or an 268 IPv4-mapped IPv6 address, the peer is IPv4. 270 One way of viewing the translator, which might help clarify why 271 applications do not need to know that a translator is used, is to 272 look at the information that is passed from the transport layer to 273 the network layer. If the transport passes down an IPv4 address 274 (whether or not is in the IPv4-mapped encoding) this means that at 275 some point there will be IPv4 packets generated. In a dual node the 276 generation of the IPv4 packets takes place in the sending node. In 277 an IPv6-only node conceptually the only difference is that the IPv4 278 packet is generated by the translator - all the information that the 279 transport layer passed to the network layer will be conveyed to the 280 translator in some form. That form just "happens" to be in the form 281 of an IPv6 header. 283 2. TERMINOLOGY 285 This documents uses the terminology defined in [IPv6] and [TRANS- 286 MECH] with these clarifications: 288 IPv4 capable node: 290 A node which has an IPv4 protocol stack. In order 291 for the stack to be usable the node must be assigned 292 one or more IPv4 addresses. 294 IPv4 enabled node: A node which has an IPv4 protocol stack 295 and is assigned one or more IPv4 addresses. Both 296 IPv4-only and IPv6/IPv4 nodes are IPv4 enabled. 298 IPv6 capable node: 300 A node which has an IPv6 protocol stack. In order 301 for the stack to be usable the node must be assigned 302 one or more IPv6 addresses. 304 IPv6 enabled node: A node which has an IPv6 protocol stack 305 and is assigned one or more IPv6 addresses. Both 306 IPv6-only and IPv6/IPv4 nodes are IPv6 enabled. 308 2.1. Addresses 310 In addition to the forms of addresses defined in [ADDR-ARCH] this 311 document also introduces the new form of IPv4-translated address to 312 avoid using IPv4-compatible addresses outside the intended use of 313 automatic tunneling. Thus the address forms are: 315 IPv4-mapped: 316 An address of the form 0::ffff:a.b.c.d which refers 317 to a node that is not IPv6-capable. In addition to 318 its use in the API this protocol uses IPv4-mapped 319 addresses in IPv6 packets to refer to an IPv4 node. 320 IPv4-compatible: 321 An address of the form 0::0:a.b.c.d which refers to 322 an IPv6/IPv4 node that supports automatic tunneling. 323 Such addresses are not used in this protocol. 324 IPv4-translated: 325 An address of the form 0::ffff:0:a.b.c.d which refers 326 to an IPv6-enabled node. Note that the prefix 327 0::ffff:0:0:0/96 is chosen to checksum to zero to 328 avoid any changes to the transport protocol's pseudo 329 header checksum. 331 2.2. Requirements 333 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 334 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 335 document, are to be interpreted as described in [KEYWORDS]. 337 3. OVERVIEW 339 The protocol translators are assumed to fit around some piece of 340 topology that includes some IPv6-only nodes and can also include IPv4 341 nodes and dual nodes. There has to be a translator on each path in 342 and out of this cloud to ensure that the packets always get 343 translated. This does not require a translator at every physical 344 connection between the cloud and the rest of the Internet since the 345 routing can be used to deliver the packets to the translator. 347 For outbound packets i.e., packets that need to be translated from 348 IPv6 to IPv4, it is sufficient to have a route for the IPv4-mapped 349 address prefix (::ffff:0:0/96) injected in the internal IPv6 routing 350 tables. This route will deliver packets to the translator since all 351 IPv6 packets that need translation will have an IPv4-mapped IPv6 352 destination address. 354 Inbound IPv4 packets needing translation are likely to have some 355 temporary IPv4 address that is drawn from a pool of such addresses. 356 Thus the internal IPv4 routing tables could have one or more routes 357 for the whole pool that direct the packets to the translator. 359 3.1. Assumptions 361 The IPv6 nodes using the translator must have an IPv4-translated IPv6 362 address while it is communicating with IPv4 nodes. 364 4. TRANSLATING FROM IPv4 TO IPv6 366 When an IPv4-to-IPv6 translator receives an IPv4 datagram addressed 367 to a destination that lies outside of the attached IPv4 island, it 368 translates the IPv4 header of that packet into an IPv6 header. It 369 then forwards the packet based on the IPv6 destination address. The 370 original IPv4 header on the packet is removed and replaced by a IPv6 371 header. Except for ICMP packets the transport layer header and data 372 portion of the packet are left unchanged. 374 +-------------+ +-------------+ 375 | IPv4 | | IPv6 | 376 | Header | | Header | 377 +-------------+ +-------------+ 378 | Transport | | Fragment | 379 | Layer | ===> | Header | 380 | Header | |(not always) | 381 +-------------+ +-------------+ 382 | | | Transport | 383 ~ Data ~ | Layer | 384 | | | Header | 385 +-------------+ +-------------+ 386 | | 387 ~ Data ~ 388 | | 389 +-------------+ 391 IPv4-to-IPv6 Translation 393 One of the differences between IPv4 and IPv6 is that in IPv6 path MTU 394 discovery is mandatory but it is optional in IPv4. This implies that 395 IPv6 routers will never fragment a packet - only the sender can do 396 fragmentation. 398 When the IPv4 node performs path MTU discovery (by setting the DF bit 399 in the header) the path MTU discovery can operate end-to-end i.e. 400 across the translator. In this case either IPv4 or IPv6 routers 401 might send back ICMP "packet too big" messages to the sender. When 402 these ICMP errors are sent by the IPv6 routers they will pass through 403 a translator which will translate the ICMP error to a form that the 404 IPv4 sender can understand. In this case an IPv6 fragment header is 405 only included if the IPv4 packet is already fragmented. 407 However, when the IPv4 sender does not perform path MTU discovery the 408 translator has to ensure that the packet does not exceed the path MTU 409 on the IPv6 side. This is done by fragmenting the IPv4 packet so 410 that it fits in 1280 byte IPv6 packet since IPv6 guarantees that 1280 411 byte packets never need to be fragment. Also, when the IPv4 sender 412 does not perform path MTU discovery the translator MUST always 413 include an IPv6 fragment header to indicate that the sender allows 414 fragmentation. That is needed should the packet pass through an 415 IPv6-to-IPv4 translator. 417 The above rules ensure that when packets are fragmented either by the 418 sender or by IPv4 routers that the low-order 16 bits of the fragment 419 identification is carried end-end to ensure that packets are 420 correctly reassembled. In addition, the rules use the presence of an 421 IPv6 fragment header to indicate that the sender might not be using 422 path MTU discovery i.e. the packet should not have the DF flag set 423 should it later be translated back to IPv4. 425 Other than the special rules for handling fragments and path MTU 426 discovery the actual translation of the packet header consists of a 427 simple mapping as defined below. Note that ICMP packets require 428 special handling in order to translate the content of ICMP error 429 message and also to add the ICMP pseudo-header checksum. 431 4.1. Translating IPv4 Headers 433 If the DF flag is not set and the IPv4 packet will result in an IPv6 434 packet larger than 1280 bytes the IPv4 packet MUST be fragmented 435 prior to translating it. Since IPv4 packets with DF not set will 436 always result in a fragment header being added to the packet the IPv4 437 packets must be fragmented so that their length, excluding the IPv4 438 header, is at most 1232 bytes (1280 minus 40 for the IPv6 header and 439 8 for the Fragment header). The resulting fragments are then 440 translated independently using the logic described below. 442 If the DF bit is set and the packet is not a fragment (i.e., the MF 443 flag is not set and the Fragment Offset is zero) then there is no 444 need to add a fragment header to the packet. The IPv6 header fields 445 are set as follows: 447 Version: 448 6 450 Traffic Class: 451 Copied from IP Type Of Service and Precedence field 452 (all 8 bits are copied). According to [DIFFSERV] the 453 semantics of the bits are identical in IPv4 and IPv6. 454 However, in some IPv4 environments these fileds might 455 be used with the old semantics of "Type Of Service 456 and Precedence". An implementation of a translator 457 SHOULD provide a the ability to ignore the IPv4 "TOS" 458 and always set the IPv6 traffic class to zero. 460 Flow Label: 461 0 (all zero bits) 463 Payload Length: 464 Total length value from IPv4 header, minus the size 465 of the IPv4 header and IPv4 options, if present. 467 Next Header: 468 Protocol field copied from IPv4 header 470 Hop Limit: 471 TTL value copied from IPv4 header. Since the 472 translator is a router, as part of forwarding the 473 packet it needs to decrement either the IPv4 TTL 474 (before the translation) or the IPv6 Hop Limit (after 475 the translation). As part of decrementing the TTL or 476 Hop Limit the translator (as any router) needs to 477 check for zero and send the ICMPv4 or ICMPv6 "ttl 478 exceeded" error. 480 Source Address: 481 The low-order 32 bits is the IPv4 source address. 482 The high-order 96 bits is the IPv4-mapped prefix 483 (::ffff:0:0/96) 485 Destination Address: 486 The low-order 32 bits is the IPv4 destination 487 address. The high-order 96 bits is the IPv4- 488 translated prefix (0::ffff:0:0:0/96) 490 If IPv4 options are present in the IPv4 packet, they are ignored 491 i.e., there is no attempt to translate them. 493 If there is need to add a fragment header (the DF bit is not set or 494 the packet is a fragment) the header fields are set as above with the 495 following exceptions: 497 IPv6 fields: 499 Payload Length: 500 Total length value from IPv4 header, plus 8 for the 501 fragment header, minus the size of the IPv4 header 502 and IPv4 options, if present. 504 Next Header: 506 Fragment Header (44). 508 Fragment header fields: 510 Next Header: 511 Protocol field copied from IPv4 header. 513 Fragment Offset: 514 Fragment Offset copied from the IPv4 header. 516 M flag: 517 More Fragments bit copied from the IPv4 header. 519 Identification: 520 The low-order 16 bits copied from the Identification 521 field in the IPv4 header. The high-order 16 bits set 522 to zero. 524 4.2. Translating ICMPv4 526 All ICMP messages that are to be translated require that the ICMP 527 checksum field be updated as part of the translation since ICMPv6, 528 unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP. 530 In addition all ICMP packets needs to have the Type value translated 531 and for ICMP error messages the included IP header also needs 532 translation. 534 The actions needed to translate various ICMPv4 messages are: 536 ICMPv4 query messages: 538 Echo and Echo Reply (Type 8 and Type 0) 539 Adjust the type to 128 and 129, respectively, and adjust the 540 ICMP checksum both take the type change into account and to 541 include the ICMPv6 pseudo-header. 543 Information Request/Reply (Type 15 and Type 16) 544 Obsoleted in ICMPv4. Silently drop. 546 Timestamp and Timestamp Reply (Type 13 and Type 14) 547 Obsoleted in ICMPv6. Silently drop. 549 Address Mask Request/Reply (Type 17 and Type 18) 550 Obsoleted in ICMPv6. Silently drop. 552 ICMP Router Advertisement (Type 9) 553 Single hop message. Silently drop. 555 ICMP Router Solicitation (Type 10) 556 Single hop message. Silently drop. 558 Unknown ICMPv4 types 559 Silently drop. 561 IGMP messages: 563 While the MLD messages [MLD] are the logical IPv6 564 counterparts for the IPv4 IGMP messages all the "normal" IGMP 565 messages are single-hop messages and should be silently 566 dropped by the translator. Other IGMP messages might be used 567 by multicast routing protocols and, since it would be a 568 configuration error to try to have router adjacencies across 569 IPv4/IPv6 translators those packets should also be silently 570 dropped. 572 ICMPv4 error messages: 574 Destination Unreachable (Type 3) 575 For all that are not explicitly listed below set the Type to 576 1. 578 Translate the code field as follows: 579 Code 0, 1: Set Code to 0 (no route to destination). 581 Code 2: Translate to an ICMPv6 Parameter Problem (Type 4, 582 Code 1) and make the Pointer point to the IPv6 Next Header 583 field. 585 Code 3: Set Code to 4 (port unreachable). 587 Code 4: Translate to an ICMPv6 Packet Too Big message 588 (Type 2) with code 0. The MTU field needs to be adjusted 589 for the difference between the IPv4 and IPv6 header sizes. 590 Note that if the IPv4 router did not set the MTU field 591 i.e. the router does not implement [PMTUv4], then the 592 translator must use the plateau values specified in 593 [PMTUv4] to determine a likely path MTU and include that 594 path MTU in the ICMPv6 packet. (Use the greatest plateau 595 value that is less than the returned Total Length field.) 597 Code 5: Set Code to 2 (not a neighbor). 599 Code 6,7: Set Code to 0 (no route to destination). 601 Code 8: Set Code to 0 (no route to destination). 603 Code 9, 10: Set Code to 1 (communication with destination 604 administratively prohibited) 606 Code 11, 12: Set Code to 0 (no route to destination). 608 Redirect (Type 5) 609 Single hop message. Silently drop. 611 Source Quench (Type 4) 612 Obsoleted in ICMPv6. Silently drop. 614 Time Exceeded (Type 11) 615 Set the Type field to 3. The Code field is unchanged. 617 Parameter Problem (Type 12) 618 Set the Type field to 4. The Pointer needs to be updated to 619 point to the corresponding field in the translated include IP 620 header. 622 4.3. Translating ICMPv4 Error Messages 624 There are some differences between the IPv4 and the IPv6 ICMP error 625 message formats as detailed above. In addition, the ICMP error 626 messages contain the IP header for the packet in error which needs to 627 be translated just like a normal IP header. This translated is 628 likely to change the length of the datagram thus the Payload Length 629 field in the outer IPv6 header might need to be updated. 631 +-------------+ +-------------+ 632 | IPv4 | | IPv6 | 633 | Header | | Header | 634 +-------------+ +-------------+ 635 | ICMPv4 | | ICMPv6 | 636 | Header | | Header | 637 +-------------+ +-------------+ 638 | IPv4 | ===> | IPv6 | 639 | Header | | Header | 640 +-------------+ +-------------+ 641 | Partial | | Partial | 642 | Transport | | Transport | 643 | Layer | | Layer | 644 | Header | | Header | 645 +-------------+ +-------------+ 647 IPv4-to-IPv6 ICMP Error Translation 649 The translation of the inner IP header can be done by recursively 650 invoking the function that translated the outer IP headers. 652 4.4. Knowing when to Translate 654 The translator is assumed to know the pool(s) of IPv4 address that 655 are used to represent the internal IPv6-only nodes. Thus if the 656 destination address falls in these configured sets of prefixes the 657 packet needs to be translated to IPv6. 659 5. TRANSLATING FROM IPv6 TO IPv4 661 When an IPv6-to-IPv4 translator receives an IPv6 datagram addressed 662 to an IPv4-mapped IPv6 address, it translates the IPv6 header of that 663 packet into an IPv6 header. It then forwards the packet based on the 664 IPv4 destination address. The original IPv6 header on the packet is 665 removed and replaced by a IPv4 header. Except for ICMP packets the 666 transport layer header and data portion of the packet are left 667 unchanged. 669 +-------------+ +-------------+ 670 | IPv6 | | IPv4 | 671 | Header | | Header | 672 +-------------+ +-------------+ 673 | Fragment | | Transport | 674 | Header | ===> | Layer | 675 |(if present) | | Header | 676 +-------------+ +-------------+ 677 | Transport | | | 678 | Layer | ~ Data ~ 679 | Header | | | 680 +-------------+ +-------------+ 681 | | 682 ~ Data ~ 683 | | 684 +-------------+ 686 IPv6-to-IPv4 Translation 688 There are some differences between IPv6 and IPv4 in the area of 689 fragmentation and the minimum link MTU that effect the translation. 690 An IPv6 link has to have an MTU of 1280 bytes or greater. The 691 corresponding limit for IPv4 is 68 bytes. Thus, unless there were 692 special measures, it would not be possible to do end-to-end path MTU 693 discovery when the path includes an IPv6-to-IPv4 translator since the 694 IPv6 node might receive ICMP "packet too big" messages originated by 695 an IPv4 router that report an MTU less than 1280. However, [IPv6] 696 requires that IPv6 nodes handle such an ICMP "packet too big" message 697 by reducing the path MTU to 1280 and including an IPv6 fragment 698 header with each packet. This allows end-to-end path MTU discovery 699 across the translator as long as the path MTU is 1280 bytes or 700 greater. When the path MTU drops below the 1280 limit the IPv6 701 sender will originate 1280 byte packets that will be fragmented by 702 IPv4 routers along the path after being translated to IPv4. 704 The only drawback with this scheme is that it is not possible to use 705 PMTU to do optimal UDP fragmentation at sender. The presence of an 706 IPv6 Fragment header is interpreted that is it OK to fragment the 707 packet on the IPv4 side thus if the Fragment header is present 708 because UDP wants to send e.g. 8 kbyte packets even though the path 709 MTU is smaller the path MTU discovery will not be end-to-end but only 710 up to and including the translator. 712 Other than the special rules for handling fragments and path MTU 713 discovery the actual translation of the packet header consists of a 714 simple mapping as defined below. Note that ICMP packets require 715 special handling in order to translate the content of ICMP error 716 message and also to add the ICMP pseudo-header checksum. 718 5.1. Translating IPv6 Headers 720 If there is no IPv6 Fragment header the IPv4 header fields are set as 721 follows: 723 Version: 724 4 726 Internet Header Length: 727 5 (no IPv4 options) 729 Type of Service and Precedence: 730 Copied from the IPv6 Traffic Class (all 8 bits). 731 According to [DIFFSERV] the semantics of the bits are 732 identical in IPv4 and IPv6. 734 Total Length: 735 Payload length value from IPv6 header, plus the size 736 of the IPv4 header. 738 Identification: 739 All zero. 741 Flags: 742 The More Fragments flag is set to zero. The Don't 743 Fragments flag is set to one. 745 Fragment Offset: 746 All zero. 748 Time to Live: 749 Hop Limit value copied from IPv6 header. Since the 750 translator is a router, as part of forwarding the 751 packet it needs to decrement either the IPv6 Hop 752 Limit (before the translation) or the IPv4 TTL (after 753 the translation). As part of decrementing the TTL or 754 Hop Limit the translator (as any router) needs to 755 check for zero and send the ICMPv4 or ICMPv6 "ttl 756 exceeded" error. 758 Protocol: 759 Next Header field copied from IPv6 header. 761 Header Checksum: 762 Computed once the IPv4 header has been created. 764 Source Address: 765 If the IPv6 source address is an IPv4-translated or 766 an IPv4-mapped address then the low-order 32 bits of 767 the IPv6 source address is copied to the IPv4 source 768 address. Otherwise, the source address is set to 769 127.0.0.1. 771 Destination Address: 772 IPv6 packets that are translated have a destination 773 address that is either an IPv4-translated or an 774 IPv4-mapped address. Thus the low-order 32 bits of 775 the IPv6 destination address is copied to the IPv4 776 source address. 778 If any of an IPv6 hop-by-hop options header, destination options 779 header, or routing header are present in the IPv6 packet, they are 780 ignored i.e., there is no attempt to translate them. However, the 781 Total Length field and the Protocol field would have to be adjusted 782 to "skip" these extension headers. 784 If the IPv6 packet contains a Fragment header the header fields are 785 set as above with the following exceptions: 787 Total Length: 788 Payload length value from IPv6 header, minus 8 for 789 the Fragment header, plus the size of the IPv4 790 header. 792 Identification: 793 Copied from the low-order 16-bits in the 794 Identification field in the Fragment header. 796 Flags: 797 The More Fragments flag is copied from the M flag in 798 the Fragment header. The Don't Fragments flag is set 799 to zero allowing this packet to be fragmented by IPv4 800 routers. 802 Fragment Offset: 803 Copied from the Fragment Offset field in the Fragment 804 Header. 806 Protocol: 807 Next Header value copied from Fragment header. 809 5.2. Translating ICMPv6 811 All ICMP messages that are to be translated require that the ICMP 812 checksum field be updated as part of the translation since ICMPv6, 813 unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP. 815 In addition all ICMP packets needs to have the Type value translated 816 and for ICMP error messages the included IP header also needs 817 translation. 819 The actions needed to translate various ICMPv6 messages are: 821 ICMPv6 informational messages: 823 Echo Request and Echo Reply (Type 128 and 129) 824 Adjust the type to 0 and 8, respectively, and adjust the ICMP 825 checksum both take the type change into account and to 826 exclude the ICMPv6 pseudo-header. 828 MLD Multicast Listener Query/Report/Done (Type 130, 131, 132) 829 Single hop message. Silently drop. 831 Neighbor Discover messages (Type 133 through 137) 832 Single hop message. Silently drop. 834 Unknown informational messages 835 Silently drop. 837 ICMPv6 error messages: 839 Destination Unreachable (Type 1) 840 Set the Type field to 3. Translate the code field as 841 follows: 842 Code 0: Set Code to 1 (host unreachable). 844 Code 1: Set Code to 10 (communication with destination 845 host administratively prohibited). 847 Code 2: Set Code to 5 (source route failed). 849 Code 3: Set Code to 1 (host unreachable). 851 Code 4: Set Code to 3 (port unreachable). 853 Packet Too Big (Type 2) 854 Translate to an ICMPv4 Destination Unreachable with code 4. 856 The MTU field needs to be adjusted for the difference between 857 the IPv4 and IPv6 header sizes taking into account whether or 858 not the packet in error includes a Fragment header. 860 Time Exceeded (Type 3) 861 Set the Type to 11. The Code field is unchanged. 863 Parameter Problem (Type 4) 864 If the Code is 1 translate this to an ICMPv4 protocol 865 unreachable (Type 3, Code 2). Otherwise set the Type to 12 866 and the Code to zero. The Pointer needs to be updated to 867 point to the corresponding field in the translated include IP 868 header. 870 Unknown error messages 871 Silently drop. 873 5.3. Translating ICMPv6 Error Messages 875 There are some differences between the IPv4 and the IPv6 ICMP error 876 message formats as detailed above. In addition, the ICMP error 877 messages contain the IP header for the packet in error which needs to 878 be translated just like a normal IP header. This translated is 879 likely to change the length of the datagram thus the Payload Length 880 field in the outer IPv6 header might need to be updated. 882 +-------------+ +-------------+ 883 | IPv6 | | IPv4 | 884 | Header | | Header | 885 +-------------+ +-------------+ 886 | ICMPv6 | | ICMPv4 | 887 | Header | | Header | 888 +-------------+ +-------------+ 889 | IPv6 | ===> | IPv4 | 890 | Header | | Header | 891 +-------------+ +-------------+ 892 | Partial | | Partial | 893 | Transport | | Transport | 894 | Layer | | Layer | 895 | Header | | Header | 896 +-------------+ +-------------+ 898 IPv6-to-IPv4 ICMP Error Translation 900 The translation of the inner IP header can be done by recursively 901 invoking the function that translated the outer IP headers. 903 5.4. Knowing when to Translate 905 When the translator receives a IPv6 packet with an IPv4-mapped 906 destination address the packet will be translated to IPv4. 908 6. SECURITY CONSIDERATIONS 910 The use of stateless IP/ICMP translators does not introduce any new 911 security issues beyond the security issues that are already present 912 in the IPv4 and IPv6 protocols and in the routing protocols which are 913 used to make the packets reach the translator. 915 As the Authentication Header is currently specified to include the 916 IPv4 Identification field and the translating function not being able 917 to always preserve the Identification field, it is not possible for 918 an IPv6 endpoint to predict the content of a packet at the IPv4 side 919 of the translator. As such it is impossible to translate packets 920 with AH headers. 922 Packets with ESP can be translated since ESP does not depend on 923 header fields prior to the ESP header. Note that ESP transport mode 924 is preferred over ESP tunnel mode since it does not contain an 925 "extra" encrypted IP header which could confuse the peer. 927 REFERENCES 929 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 930 Requirement Levels", RFC 2119, March 1997. 932 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 933 6 (IPv6) Specification", RFC 1883, January 1996. 935 [IPv4] J. Postel, "Internet Protocol", RFC 791, September 1981. 937 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 938 Addressing Architecture", RFC 1884, January 1996. 940 [TRANS-MECH] R. Gilligan, E. Nordmark, "Transition Mechanisms for 941 IPv6 Hosts and Routers", RFC 1933, April 1996. 943 [DISCOVERY] T. Narten, E. Nordmark, and W. Simpson, "Neighbor 944 Discovery for IP Version 6 (IPv6)", RFC 1970, August 1996. 946 [IPv6-SA] R. Atkinson. "Security Architecture for the Internet 947 Protocol". RFC 1825, August 1995. 949 [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 1826, 950 August 1995. 952 [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)", 953 RFC 1827, August 1995. 955 [ICMPv4] J. Postel, "Internet Control Message Protocol", RFC 792, 956 September 1981. 958 [ICMPv6] A. Conta, S. Deering, "Internet Control Message Protocol 959 (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 960 1885, January 1996. 962 [IGMP] S. Deering, "Host extensions for IP multicasting", RFC 1112, 963 August 1989. 965 [PMTUv4] J. Mogul, S. Deering, "Path MTU Discovery", RFC 1191, 966 November 1990. 968 [PMTUv6] J. McCann, S. Deering, J. Mogul, "Path MTU Discovery for 969 IP version 6", RFC 1981, August 1996. 971 [DIFFSERV] K. Nichols, S. Blake, F. Baker, and D. L. Black, 972 "Definition of the Differentiated Services Field (DS Field) 973 in the IPv4 and IPv6 Headers", Internet Draft, October 974 1998. 976 [MLD] S. Deering, W. Fenner, and B. Haberman, "Multicast Listener 977 Discovery (MLD) for IPv6", Internet Draft, September 1998. 979 AUTHOR'S ADDRESS 981 Erik Nordmark 982 Sun Microsystems, Inc. 983 901 San Antonio Road 984 Palo Alto, CA 94303 985 USA 987 phone: +1 650 786 5166 988 fax: +1 650 786 5896 989 email: nordmark@sun.com