idnits 2.17.1 draft-ietf-ngtrans-siit-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 pages 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 (November 15, 1999) is 8929 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) == Unused Reference: 'IPv4' is defined on line 1123, but no explicit reference was found in the text == Unused Reference: 'DISCOVERY' is defined on line 1131, but no explicit reference was found in the text == Unused Reference: 'IPv6-SA' is defined on line 1135, but no explicit reference was found in the text == Unused Reference: 'IPv6-ESP' is defined on line 1141, but no explicit reference was found in the text == Unused Reference: 'ICMPv4' is defined on line 1144, but no explicit reference was found in the text == Unused Reference: 'ICMPv6' is defined on line 1147, but no explicit reference was found in the text == Unused Reference: 'IGMP' is defined on line 1151, but no explicit reference was found in the text == Unused Reference: 'PMTUv6' is defined on line 1157, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2373 (ref. 'ADDR-ARCH') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 1933 (ref. 'TRANS-MECH') (Obsoleted by RFC 2893) ** Obsolete normative reference: RFC 2461 (ref. 'DISCOVERY') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2401 (ref. 'IPv6-SA') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. 'IPv6-AUTH') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. 'IPv6-ESP') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2463 (ref. 'ICMPv6') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 1981 (ref. 'PMTUv6') (Obsoleted by RFC 8201) -- Possible downref: Non-RFC (?) normative reference: ref. 'MLD' -- Possible downref: Non-RFC (?) normative reference: ref. 'MILLER' ** Obsolete normative reference: RFC 2553 (ref. 'BSDAPI') (Obsoleted by RFC 3493) Summary: 13 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Erik Nordmark, Sun Microsystems 2 November 15, 1999 4 Stateless IP/ICMP Translation Algorithm (SIIT) 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet Draft expires May 15, 2000. 31 Abstract 33 This document specifies a transition mechanism algorithm in addition 34 to the mechanisms already specified in RFC 1933. The algorithm 35 translates between IPv4 and IPv6 packet headers (including ICMP 36 headers) without requiring any per-connection state. This new 37 algorithm can be used as part of a solution that allows IPv6 hosts, 38 which do not have a permanently assigned IPv4 addresses, to 39 communicate with IPv4-only hosts. The document neither specifies 40 address assignment nor routing to and from the IPv6 hosts when they 41 communicate with the IPv4-only hosts. 43 Acknowledgements 45 This document is a product of the NGTRANS working group. Some text 46 has been extracted from an old Internet Draft titled "IPAE: The SIPP 47 Interoperability and Transition Mechanism" authored by R. Gilligan, 48 E. Nordmark, and B. Hinden. George Tsirtsis provides the figures for 49 Section 1. Keith More provided a careful review of the document. 51 Contents 53 Status of this Memo.......................................... 1 55 1. INTRODUCTION AND MOTIVATION.............................. 3 56 1.1. Applicability and Limitations....................... 6 57 1.2. Assumptions......................................... 7 58 1.3. Impact Outside the Network Layer.................... 8 60 2. TERMINOLOGY.............................................. 9 61 2.1. Addresses........................................... 9 62 2.2. Requirements........................................ 10 64 3. TRANSLATING FROM IPv4 TO IPv6............................ 10 65 3.1. Translating IPv4 Headers............................ 12 66 3.2. Translating UDP over IPv4........................... 14 67 3.3. Translating ICMPv4.................................. 14 68 3.4. Translating ICMPv4 Error Messages................... 17 69 3.5. Knowing when to Translate........................... 17 71 4. TRANSLATING FROM IPv6 TO IPv4............................ 18 72 4.1. Translating IPv6 Headers............................ 19 73 4.2. Translating ICMPv6.................................. 21 74 4.3. Translating ICMPv6 Error Messages................... 23 75 4.4. Knowing when to Translate........................... 23 77 5. IMPLICATIONS FOR IPv6-ONLY NODES......................... 24 79 6. SECURITY CONSIDERATIONS.................................. 24 81 7. CHANGE LOG............................................... 25 83 REFERENCES................................................... 26 85 AUTHOR'S ADDRESS............................................. 27 87 1. INTRODUCTION AND MOTIVATION 89 The transition mechanisms specified in [TRANS-MECH] handle the case 90 of dual IPv4/IPv6 hosts interoperating with both dual hosts and 91 IPv4-only hosts, which is needed early in the transition to IPv6. 92 The dual hosts are assigned both an IPv4 and one or more IPv6 93 addresses. As the number of available globally unique IPv4 addresses 94 becomes smaller and smaller as the Internet grows there will be a 95 desire to take advantage of the large IPv6 address and not require 96 that every new Internet node have a permanently assigned IPv4 97 address. 99 There are several different scenarios where there might be IPv6-only 100 hosts that need to communicate with IPv4-only hosts. These IPv6 101 hosts might be IPv4-capable, i.e. include an IPv4 implementation but 102 not be assigned an IPv4 address, or they might not even include an 103 IPv4 implementation. 105 - A completely new network with new devices that all support IPv6. 106 In this case it might be beneficial to not have to configure the 107 routers within the new network to route IPv4 since none of the 108 hosts in the new network are configured with IPv4 addresses. But 109 these new IPv6 devices might occasionally need to communicate with 110 some IPv4 nodes out on the Internet. 112 - An existing network where a large number of IPv6 devices are 113 added. The IPv6 devices might have both an IPv4 and an IPv6 114 protocol stack but there is not enough global IPv4 address space 115 to give each one of them a permanent IPv4 address. In this case 116 it is more likely that the routers in the network already route 117 IPv4 and are upgraded to dual routers. 119 However, there are other potential solutions in this area: 120 - If there is no IPv4 routing inside the network i.e., the cloud 121 that contains the new devices, some possible solutions are to 122 either use the translators specified in this document at the 123 boundary of the cloud, or to use Application Layer Gateways (ALG) 124 on dual nodes at the cloud's boundary. The ALG solution is less 125 flexible in that it is application protocol specific and it is 126 also less robust since a the ALG box is likely to be a single 127 point of failure for a connection using that box. 129 - Otherwise, if there IPv4 routing is supported inside the cloud and 130 the implementations support both IPv6 and IPv4 it might suffice to 131 have a mechanism for allocating temporary IPv4 and use IPv4 end to 132 end when communicating with IPv4-only nodes. However, it would 133 seem that such a solution would require the pool of temporary IPv4 134 addresses to be partitioned across all the subnets in the cloud 135 which would either require a larger pool of IPv4 addresses or 136 result in cases where communication would fail due to no available 137 IPv4 address for the node's subnet. 139 This document specifies an algorithm that is one of the components 140 needed to make IPv6-only nodes interoperate with IPv4-only nodes. 141 Other components, not specified in this document, are a mechanism for 142 the IPv6-only node to somehow acquire a temporary IPv4 address, and a 143 mechanism for providing routing (perhaps using tunneling) to and from 144 the temporary IPv4 address assigned to the node. 146 The temporary IPv4 address will be used as an IPv4-translated IPv6 147 address and the packets will travel through a stateless IP/ICMP 148 translator that will translate the packet headers between IPv4 and 149 IPv6 and translate the addresses in those headers between IPv4 150 addresses on one side and IPv4-translated or IPv4-mapped IPv6 151 addresses on the other side. 153 This specification does not cover how an IPv6 node can acquire a 154 temporary IPv4 address and how such a temporary address be registered 155 in the DNS. The DHCP protocol, perhaps with some extensions, could 156 probably be used to acquire temporary addresses with short leases but 157 that is outside the scope of this document. Also, the mechanism for 158 routing this IPv4-translated IPv6 address in the site is not 159 specified in this document. 161 The figures below show how the Stateless IP/ICMP Translation 162 algorithm (SIIT) can be used initially for small networks (e.g., a 163 single subnet) and later for a site which has IPv6-only hosts in a 164 dual IPv4/IPv6 network. This use assumes a mechanism for the IPv6 165 nodes to acquire an temporary address from the pool of IPv4 166 addresses. Note that SIIT is not likely to be useful later during 167 transition when most of the Internet is IPv6 and there are only small 168 islands of IPv4 nodes, since such use would either require the IPv6 169 nodes to acquire temporary IPv4 addresses from a "distant" SIIT box 170 operated by a different administration, or require that the IPv6 171 routing contain routes for IPv6-mapped addresses. (The latter is 172 known to be a very bad idea due to the size of the IPv4 routing table 173 that would potentially be injected into IPv6 routing in the form of 174 IPv4-mapped addresses.) 175 ___________ 176 / \ 177 [IPv6 Host]---[SIIT]---------< IPv4 network>--[IPv4 Host] 178 | \___________/ 179 (pool of IPv4 addresses) 181 IPv4-translatable -> IPv4->IPv4 addresser 182 IPv4-mapped 183 Figure 1. Using SIIT for a single IPv6-only subnet. 185 ___________ ___________ 186 / \ / \ 187 [IPv6 Host]--< Dual network>--[SIIT]--< IPv4 network>--[IPv4 Host] 188 \___________/ | \___________/ 189 (pool of IPv4 addresses) 191 IPv4-translatable -> IPv4->IPv4 addresser 192 IPv4-mapped 194 Figure 2. Using SIIT for an IPv6-only or dual cloud (e.g. a site) 195 which contains some IPv6-only hosts as well as IPv4 hosts. 197 The protocol translators are assumed to fit around some piece of 198 topology that includes some IPv6-only nodes and that may also include 199 IPv4 nodes as well as dual nodes. There has to be a translator on 200 each path used by routing the "translatable" packets in and out of 201 this cloud to ensure that such packets always get translated. This 202 does not require a translator at every physical connection between 203 the cloud and the rest of the Internet since the routing can be used 204 to deliver the packets to the translator. 206 The IPv6-only node communicating with an IPv4 node through a 207 translator will see an IPv4-mapped address for the peer and use an 208 IPv4-translatable address for its local address for that 209 communication. When the IPv6-only node sends packets the IPv4-mapped 210 address indicates that the translator needs to translate the packets. 211 When the IPv4 node sends packets those will translated to have the 212 IPv4-translatable address as a destination; it is not possible to use 213 an IPv4-mapped or an IPv4-compatible address as a destination since 214 that would either route the packet back to the translator (for the 215 IPv4-mapped address) or make the packet be encapsulated in IPv4 (for 216 the IPv4-compatible address). Thus this specification introduces the 217 new notion of an IPv4-translatable address. 219 1.1. Applicability and Limitations 221 The use of this translation algorithm assumes that the IPv6 network 222 is somehow well connected i.e. when an IPv6 node wants to communicate 223 with another IPv6 node there is an IPv6 path between them. Various 224 tunneling schemes exist that can provide such a path, but those 225 mechanisms and their use is outside the scope of this document. 227 The IPv6 protocol [IPv6] has been designed so that the transport 228 pseudo-header checksums are not affected by such a translation thus 229 the translator does not need to modify normal TCP and UDP headers. 230 The only exceptions are unfragmented IPv4 UDP packets which need to 231 have a UDP checksum computed since a pseudo-header checksum is 232 required for UDP in IPv6. Also, ICMPv6 include a pseudo-header 233 checksum but it is not present in ICMPv4 thus the checksum in ICMP 234 messages need to be modified by the translator. In addition, ICMP 235 error messages contain an IP header as part of the payload thus the 236 translator need to rewrite those parts of the packets to make the 237 receiver be able to understand the included IP header. However, all 238 of the translator's operations, including path MTU discovery, are 239 stateless in the sense that the translator operates independently on 240 each packet and does not retain any state from one packet to another. 241 This allows redundant translator boxes without any coordination and a 242 given TCP connection can have the two directions of packets go 243 through different translator boxes. 245 The translating function as specified in this document does not 246 translate any IPv4 options and it does not translate IPv6 routing 247 headers, hop-by-hop extension headers, or destination options 248 headers. It could be possible to define a translation between source 249 routing in IPv4 and IPv6. However such a translation would not be 250 semantically correct due to the slight differences between the IPv4 251 and IPv6 source routing. Also, the usefulness of source routing when 252 going through a header translator might be limited since all the 253 IPv6-only routers would need to have an IPv4-translated IPv6 address 254 since the IPv4-only node will send a source route option containing 255 only IPv4 addresses. 257 At first sight it might appear that the IPsec functionality [IPv6-SA, 258 IPv6-ESP, IPv6-AH] can not be carried across the translator. 259 However, since the translator does not modify any headers above the 260 logical IP layer (IP headers, IPv6 fragment headers, and ICMP 261 messages) packets encrypted using ESP in Transport-mode can be 262 carried through the translator. [Note that this assumes that the key 263 management can operate between the IPv6-only node and the IPv4-only 264 node.] The AH computation covers parts of the IPv4 header fields 265 such as IP addresses, and the identification field (fields that are 266 either immutable or predictable by the sender) [IPv6-AUTH]. While 267 the SIIT algorithm is specified so that those IPv4 fields can be 268 predicted by the IPv6 sender it is not possible for the IPv6 receiver 269 to determine the value of the IPv4 Identification field in packets 270 sent by the IPv4 node. Thus as the translation algorithm is 271 specified in this document it is not possible to use end-to-end AH 272 through the translator. 274 For ESP Tunnel-mode to work through the translator the IPv6 node 275 would have to be able to both parse and generate "inner" IPv4 headers 276 since the inner IP will be encrypted together with the transport 277 protocol. 279 Thus in practise, only ESP transport mode is relatively easy to make 280 work through a translator. 282 IPv4 multicast addresses can not be mapped to IPv6 multicast 283 addresses. For instance, ::ffff:224.1.2.3 is an IPv4 mapped IPv6 284 address with a class D address, however it is not an IPv6 multicast 285 address. While the IP/ICMP header translation aspect of this draft 286 in theory works for multicast packets this address mapping limitation 287 makes it impossible to apply the techniques in this draft for 288 multicast traffic. 290 1.2. Assumptions 292 The IPv6 nodes using the translator must have an IPv4-translated IPv6 293 address while it is communicating with IPv4-only nodes. 295 The use of the algorithm assumes that there is an IPv4 address pool 296 used to generate IPv4-translated addresses. Routing needs to be able 297 to route any IPv4 packets, whether generated "outside" or "inside" 298 the translator, destined to addresses in this pool towards the 299 translator. This implies that the address pool can not be assigned 300 to subnets but must be separated from the IPv4 subnets used on the 301 "inside" of the translator. 303 Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e. 304 the UDP checksum field is zero) are not of significant use over 305 wide-areas in the Internet and will not be translated by the 306 translator. An informal trace [MILLER] in the backbone showed that 307 out of 34,984,468 IP packets there were 769 fragmented UDP packets 308 with a zero checksum. However, all of them were due to malicious or 309 broken behavior; a port scan and first fragments of IP packets that 310 are not a multiple of 8 bytes. 312 1.3. Impact Outside the Network Layer 314 The potential existence of stateless IP/ICMP translators is already 315 taken care of from a protocol perspective in [IPv6]. However, an 316 IPv6 node that wants to be able to use translators needs some 317 additional logic in the network layer. 319 The network layer in an IPv6-only node, when presented by the 320 application with either an IPv4 destination address or an IPv4-mapped 321 IPv6 destination address, is likely to drop the packet and return 322 some error message to the application. In order to take advantage of 323 translators such a node should instead send an IPv6 packet where the 324 destination address is the IPv4-mapped address and the source address 325 is the node's temporarily assigned IPv4-translated address. If the 326 node does not have a temporarily assigned IPv4-translated address it 327 should acquire one using mechanisms that are not discussed in this 328 document. 330 Note that the above also applies to a dual IPv4/IPv6 implementation 331 node which is not configured with any IPv4 address. 333 There are no extra changes needed to applications to operate through 334 a translator beyond what applications already need to do to operate 335 on a dual node. The applications that have been modified to work on 336 a dual node already have the mechanisms to determine whether they are 337 communicating with an IPv4 or an IPv6 peer. Thus if the applications 338 need to modify their behavior depending on the type of the peer, such 339 as ftp determining whether to fallback to using the PORT/PASV command 340 when EPRT/EPSV fails (as specified in [FTPEXT]), they already need to 341 do that when running on dual nodes and the presense of translators 342 does not add anything. For example, when using the socket API 343 [BSDAPI] the applications know that the peer is IPv6 if they get an 344 AF_INET6 address from the name service and the address is not an 345 IPv4-mapped address (i.e., IN6_IS_ADDR_V4MAPPED returns false). If 346 this is not the case, i.e., the address is AF_INET or an IPv4-mapped 347 IPv6 address, the peer is IPv4. 349 One way of viewing the translator, which might help clarify why 350 applications do not need to know that a translator is used, is to 351 look at the information that is passed from the transport layer to 352 the network layer. If the transport passes down an IPv4 address 353 (whether or not is in the IPv4-mapped encoding) this means that at 354 some point there will be IPv4 packets generated. In a dual node the 355 generation of the IPv4 packets takes place in the sending node. In 356 an IPv6-only node conceptually the only difference is that the IPv4 357 packet is generated by the translator - all the information that the 358 transport layer passed to the network layer will be conveyed to the 359 translator in some form. That form just "happens" to be in the form 360 of an IPv6 header. 362 2. TERMINOLOGY 364 This documents uses the terminology defined in [IPv6] and [TRANS- 365 MECH] with these clarifications: 367 IPv4 capable node: 369 A node which has an IPv4 protocol stack. In order 370 for the stack to be usable the node must be assigned 371 one or more IPv4 addresses. 373 IPv4 enabled node: A node which has an IPv4 protocol stack 374 and is assigned one or more IPv4 addresses. Both 375 IPv4-only and IPv6/IPv4 nodes are IPv4 enabled. 377 IPv6 capable node: 379 A node which has an IPv6 protocol stack. In order 380 for the stack to be usable the node must be assigned 381 one or more IPv6 addresses. 383 IPv6 enabled node: A node which has an IPv6 protocol stack 384 and is assigned one or more IPv6 addresses. Both 385 IPv6-only and IPv6/IPv4 nodes are IPv6 enabled. 387 2.1. Addresses 389 In addition to the forms of addresses defined in [ADDR-ARCH] this 390 document also introduces the new form of IPv4-translated address. 391 This is needed to avoid using IPv4-compatible addresses outside the 392 intended use of automatic tunneling. Thus the address forms are: 394 IPv4-mapped: 395 An address of the form 0::ffff:a.b.c.d which refers 396 to a node that is not IPv6-capable. In addition to 397 its use in the API this protocol uses IPv4-mapped 398 addresses in IPv6 packets to refer to an IPv4 node. 400 IPv4-compatible: 401 An address of the form 0::0:a.b.c.d which refers to 402 an IPv6/IPv4 node that supports automatic tunneling. 403 Such addresses are not used in this protocol. 405 IPv4-translated: 406 An address of the form 0::ffff:0:a.b.c.d which refers 407 to an IPv6-enabled node. Note that the prefix 408 0::ffff:0:0:0/96 is chosen to checksum to zero to 409 avoid any changes to the transport protocol's pseudo 410 header checksum. 412 2.2. Requirements 414 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 415 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 416 document, are to be interpreted as described in [KEYWORDS]. 418 3. TRANSLATING FROM IPv4 TO IPv6 420 When an IPv4-to-IPv6 translator receives an IPv4 datagram addressed 421 to a destination that lies outside of the attached IPv4 island, it 422 translates the IPv4 header of that packet into an IPv6 header. It 423 then forwards the packet based on the IPv6 destination address. The 424 original IPv4 header on the packet is removed and replaced by an IPv6 425 header. Except for ICMP packets the transport layer header and data 426 portion of the packet are left unchanged. 428 +-------------+ +-------------+ 429 | IPv4 | | IPv6 | 430 | Header | | Header | 431 +-------------+ +-------------+ 432 | Transport | | Fragment | 433 | Layer | ===> | Header | 434 | Header | |(not always) | 435 +-------------+ +-------------+ 436 | | | Transport | 437 ~ Data ~ | Layer | 438 | | | Header | 439 +-------------+ +-------------+ 440 | | 441 ~ Data ~ 442 | | 443 +-------------+ 445 IPv4-to-IPv6 Translation 447 One of the differences between IPv4 and IPv6 is that in IPv6 path MTU 448 discovery is mandatory but it is optional in IPv4. This implies that 449 IPv6 routers will never fragment a packet - only the sender can do 450 fragmentation. 452 When the IPv4 node performs path MTU discovery (by setting the DF bit 453 in the header) the path MTU discovery can operate end-to-end i.e. 454 across the translator. In this case either IPv4 or IPv6 routers 455 might send back ICMP "packet too big" messages to the sender. When 456 these ICMP errors are sent by the IPv6 routers they will pass through 457 a translator which will translate the ICMP error to a form that the 458 IPv4 sender can understand. In this case an IPv6 fragment header is 459 only included if the IPv4 packet is already fragmented. 461 However, when the IPv4 sender does not perform path MTU discovery the 462 translator has to ensure that the packet does not exceed the path MTU 463 on the IPv6 side. This is done by fragmenting the IPv4 packet so 464 that it fits in 1280 byte IPv6 packet since IPv6 guarantees that 1280 465 byte packets never need to be fragmented. Also, when the IPv4 sender 466 does not perform path MTU discovery the translator MUST always 467 include an IPv6 fragment header to indicate that the sender allows 468 fragmentation. That is needed should the packet pass through an 469 IPv6-to-IPv4 translator. 471 The above rules ensure that when packets are fragmented either by the 472 sender or by IPv4 routers that the low-order 16 bits of the fragment 473 identification is carried end-end to ensure that packets are 474 correctly reassembled. In addition, the rules use the presence of an 475 IPv6 fragment header to indicate that the sender might not be using 476 path MTU discovery i.e. the packet should not have the DF flag set 477 should it later be translated back to IPv4. 479 Other than the special rules for handling fragments and path MTU 480 discovery the actual translation of the packet header consists of a 481 simple mapping as defined below. Note that ICMP packets require 482 special handling in order to translate the content of ICMP error 483 message and also to add the ICMP pseudo-header checksum. 485 3.1. Translating IPv4 Headers 487 If the DF flag is not set and the IPv4 packet will result in an IPv6 488 packet larger than 1280 bytes the IPv4 packet MUST be fragmented 489 prior to translating it. Since IPv4 packets with DF not set will 490 always result in a fragment header being added to the packet the IPv4 491 packets must be fragmented so that their length, excluding the IPv4 492 header, is at most 1232 bytes (1280 minus 40 for the IPv6 header and 493 8 for the Fragment header). The resulting fragments are then 494 translated independently using the logic described below. 496 If the DF bit is set and the packet is not a fragment (i.e., the MF 497 flag is not set and the Fragment Offset is zero) then there is no 498 need to add a fragment header to the packet. The IPv6 header fields 499 are set as follows: 501 Version: 502 6 504 Traffic Class: 505 By default, copied from IP Type Of Service and 506 Precedence field (all 8 bits are copied). According 507 to [DIFFSERV] the semantics of the bits are identical 508 in IPv4 and IPv6. However, in some IPv4 environments 509 these fields might be used with the old semantics of 510 "Type Of Service and Precedence". An implementation 511 of a translator SHOULD provide a the ability to 512 ignore the IPv4 "TOS" and always set the IPv6 traffic 513 class to zero. 515 Flow Label: 516 0 (all zero bits) 518 Payload Length: 519 Total length value from IPv4 header, minus the size 520 of the IPv4 header and IPv4 options, if present. 522 Next Header: 523 Protocol field copied from IPv4 header 525 Hop Limit: 526 TTL value copied from IPv4 header. Since the 527 translator is a router, as part of forwarding the 528 packet it needs to decrement either the IPv4 TTL 529 (before the translation) or the IPv6 Hop Limit (after 530 the translation). As part of decrementing the TTL or 531 Hop Limit the translator (as any router) needs to 532 check for zero and send the ICMPv4 or ICMPv6 "ttl 533 exceeded" error. 535 Source Address: 536 The low-order 32 bits is the IPv4 source address. 537 The high-order 96 bits is the IPv4-mapped prefix 538 (::ffff:0:0/96) 540 Destination Address: 541 The low-order 32 bits is the IPv4 destination 542 address. The high-order 96 bits is the IPv4- 543 translated prefix (0::ffff:0:0:0/96) 545 If IPv4 options are present in the IPv4 packet, they are ignored 546 i.e., there is no attempt to translate them. However, if an 547 unexpired source route option is present then the packet MUST instead 548 be discarded, and an ICMPv4 "destination unreachable/source route 549 failed" (Type 3/Code 5) error message SHOULD be returned to the 550 sender. 552 If there is need to add a fragment header (the DF bit is not set or 553 the packet is a fragment) the header fields are set as above with the 554 following exceptions: 556 IPv6 fields: 558 Payload Length: 559 Total length value from IPv4 header, plus 8 for the 560 fragment header, minus the size of the IPv4 header 561 and IPv4 options, if present. 563 Next Header: 564 Fragment Header (44). 566 Fragment header fields: 568 Next Header: 570 Protocol field copied from IPv4 header. 572 Fragment Offset: 573 Fragment Offset copied from the IPv4 header. 575 M flag: 576 More Fragments bit copied from the IPv4 header. 578 Identification: 579 The low-order 16 bits copied from the Identification 580 field in the IPv4 header. The high-order 16 bits set 581 to zero. 583 3.2. Translating UDP over IPv4 585 If a UDP packet has a zero UDP checksum then a valid checksum must be 586 calculated in order to translate the packet. A stateless translator 587 can not do this for fragmented packets but [MILLER] indicates that 588 fragmented UDP packets with a zero checksum appear to only be used 589 for malicious purposes. Thus this is not believed to be a noticeable 590 limitation. 592 When a translator receives the first fragment of a fragmented UDP 593 IPv4 packet and the checksum field is zero the translator SHOULD drop 594 the packet and generate a system management event specifying at least 595 the IP addresses and port numbers in the packet. When it receives 596 fragments other than the first it SHOULD silently drop the packet, 597 since there is no port information to log. 599 When a translator receives an unfragmented UDP IPv4 packet and the 600 checksum field is zero the translator MUST compute the missing UDP 601 checksum as part of translating the packet. Also, the translator 602 SHOULD maintain a counter of how many UDP checksums are generated in 603 this manner. 605 3.3. Translating ICMPv4 607 All ICMP messages that are to be translated require that the ICMP 608 checksum field be updated as part of the translation since ICMPv6, 609 unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP. 611 In addition all ICMP packets needs to have the Type value translated 612 and for ICMP error messages the included IP header also needs 613 translation. 615 The actions needed to translate various ICMPv4 messages are: 617 ICMPv4 query messages: 619 Echo and Echo Reply (Type 8 and Type 0) 620 Adjust the type to 128 and 129, respectively, and adjust the 621 ICMP checksum both to take the type change into account and 622 to include the ICMPv6 pseudo-header. 624 Information Request/Reply (Type 15 and Type 16) 625 Obsoleted in ICMPv4. Silently drop. 627 Timestamp and Timestamp Reply (Type 13 and Type 14) 628 Obsoleted in ICMPv6. Silently drop. 630 Address Mask Request/Reply (Type 17 and Type 18) 631 Obsoleted in ICMPv6. Silently drop. 633 ICMP Router Advertisement (Type 9) 634 Single hop message. Silently drop. 636 ICMP Router Solicitation (Type 10) 637 Single hop message. Silently drop. 639 Unknown ICMPv4 types 640 Silently drop. 642 IGMP messages: 644 While the MLD messages [MLD] are the logical IPv6 645 counterparts for the IPv4 IGMP messages all the "normal" IGMP 646 messages are single-hop messages and should be silently 647 dropped by the translator. Other IGMP messages might be used 648 by multicast routing protocols and, since it would be a 649 configuration error to try to have router adjacencies across 650 IPv4/IPv6 translators those packets should also be silently 651 dropped. 653 ICMPv4 error messages: 655 Destination Unreachable (Type 3) 656 For all that are not explicitly listed below set the Type to 657 1. 659 Translate the code field as follows: 660 Code 0, 1 (net, host unreachable): 661 Set Code to 0 (no route to destination). 663 Code 2 (protocol unreachable): 664 Translate to an ICMPv6 Parameter Problem (Type 4, 665 Code 1) and make the Pointer point to the IPv6 Next 666 Header field. 668 Code 3 (port unreachable): 669 Set Code to 4 (port unreachable). 671 Code 4 (fragmentation needed and DF set): 672 Translate to an ICMPv6 Packet Too Big message (Type 673 2) with code 0. The MTU field needs to be adjusted 674 for the difference between the IPv4 and IPv6 header 675 sizes. Note that if the IPv4 router did not set 676 the MTU field i.e. the router does not implement 677 [PMTUv4], then the translator must use the plateau 678 values specified in [PMTUv4] to determine a likely 679 path MTU and include that path MTU in the ICMPv6 680 packet. (Use the greatest plateau value that is 681 less than the returned Total Length field.) 683 Code 5 (source route failed): 684 Set Code to 0 (no route to destination). Note that 685 this error is unlikely since source routes are not 686 translated. 688 Code 6,7: 689 Set Code to 0 (no route to destination). 691 Code 8: 692 Set Code to 0 (no route to destination). 694 Code 9, 10 (communication with destination host 695 administratively prohibited): 696 Set Code to 1 (communication with destination 697 administratively prohibited) 699 Code 11, 12: 700 Set Code to 0 (no route to destination). 702 Redirect (Type 5) 703 Single hop message. Silently drop. 705 Source Quench (Type 4) 706 Obsoleted in ICMPv6. Silently drop. 708 Time Exceeded (Type 11) 709 Set the Type field to 3. The Code field is unchanged. 711 Parameter Problem (Type 12) 712 Set the Type field to 4. The Pointer needs to be updated to 713 point to the corresponding field in the translated include IP 714 header. 716 3.4. Translating ICMPv4 Error Messages 718 There are some differences between the IPv4 and the IPv6 ICMP error 719 message formats as detailed above. In addition, the ICMP error 720 messages contain the IP header for the packet in error which needs to 721 be translated just like a normal IP header. This translated is 722 likely to change the length of the datagram thus the Payload Length 723 field in the outer IPv6 header might need to be updated. 725 +-------------+ +-------------+ 726 | IPv4 | | IPv6 | 727 | Header | | Header | 728 +-------------+ +-------------+ 729 | ICMPv4 | | ICMPv6 | 730 | Header | | Header | 731 +-------------+ +-------------+ 732 | IPv4 | ===> | IPv6 | 733 | Header | | Header | 734 +-------------+ +-------------+ 735 | Partial | | Partial | 736 | Transport | | Transport | 737 | Layer | | Layer | 738 | Header | | Header | 739 +-------------+ +-------------+ 741 IPv4-to-IPv6 ICMP Error Translation 743 The translation of the inner IP header can be done by recursively 744 invoking the function that translated the outer IP headers. 746 3.5. Knowing when to Translate 748 The translator is assumed to know the pool(s) of IPv4 address that 749 are used to represent the internal IPv6-only nodes. Thus if the IPv4 750 destination field contains an address that falls in these configured 751 sets of prefixes the packet needs to be translated to IPv6. 753 4. TRANSLATING FROM IPv6 TO IPv4 755 When an IPv6-to-IPv4 translator receives an IPv6 datagram addressed 756 to an IPv4-mapped IPv6 address, it translates the IPv6 header of that 757 packet into an IPv4 header. It then forwards the packet based on the 758 IPv4 destination address. The original IPv6 header on the packet is 759 removed and replaced by an IPv4 header. Except for ICMP packets the 760 transport layer header and data portion of the packet are left 761 unchanged. 763 +-------------+ +-------------+ 764 | IPv6 | | IPv4 | 765 | Header | | Header | 766 +-------------+ +-------------+ 767 | Fragment | | Transport | 768 | Header | ===> | Layer | 769 |(if present) | | Header | 770 +-------------+ +-------------+ 771 | Transport | | | 772 | Layer | ~ Data ~ 773 | Header | | | 774 +-------------+ +-------------+ 775 | | 776 ~ Data ~ 777 | | 778 +-------------+ 780 IPv6-to-IPv4 Translation 782 There are some differences between IPv6 and IPv4 in the area of 783 fragmentation and the minimum link MTU that effect the translation. 784 An IPv6 link has to have an MTU of 1280 bytes or greater. The 785 corresponding limit for IPv4 is 68 bytes. Thus, unless there were 786 special measures, it would not be possible to do end-to-end path MTU 787 discovery when the path includes an IPv6-to-IPv4 translator since the 788 IPv6 node might receive ICMP "packet too big" messages originated by 789 an IPv4 router that report an MTU less than 1280. However, [IPv6] 790 requires that IPv6 nodes handle such an ICMP "packet too big" message 791 by reducing the path MTU to 1280 and including an IPv6 fragment 792 header with each packet. This allows end-to-end path MTU discovery 793 across the translator as long as the path MTU is 1280 bytes or 794 greater. When the path MTU drops below the 1280 limit the IPv6 795 sender will originate 1280 byte packets that will be fragmented by 796 IPv4 routers along the path after being translated to IPv4. 798 The only drawback with this scheme is that it is not possible to use 799 PMTU to do optimal UDP fragmentation (as opposed to completely 800 avoiding fragmentation) at sender since the presence of an IPv6 801 Fragment header is interpreted that is it OK to fragment the packet 802 on the IPv4 side. Thus if a UDP application wants to send large 803 packets independent of the PMTU, the sender will only be able to 804 determine the path MTU on the IPv6 side of the translator. If the 805 path MTU on the IPv4 side of the translator is smaller then the IPv6 806 sender will not receive any ICMP "too big" errors and can not adjust 807 the size fragments it is sending. 809 Other than the special rules for handling fragments and path MTU 810 discovery the actual translation of the packet header consists of a 811 simple mapping as defined below. Note that ICMP packets require 812 special handling in order to translate the content of ICMP error 813 message and also to add the ICMP pseudo-header checksum. 815 4.1. Translating IPv6 Headers 817 If there is no IPv6 Fragment header the IPv4 header fields are set as 818 follows: 820 Version: 821 4 823 Internet Header Length: 824 5 (no IPv4 options) 826 Type of Service and Precedence: 827 By default, copied from the IPv6 Traffic Class (all 8 828 bits). According to [DIFFSERV] the semantics of the 829 bits are identical in IPv4 and IPv6. However, in 830 some IPv4 environments these bits might be used with 831 the old semantics of "Type Of Service and 832 Precedence". An implementation of a translator 833 SHOULD provide the ability to ignore the IPv6 traffic 834 class and always set the IPv4 "TOS" to zero. 836 Total Length: 837 Payload length value from IPv6 header, plus the size 838 of the IPv4 header. 840 Identification: 841 All zero. 843 Flags: 844 The More Fragments flag is set to zero. The Don't 845 Fragments flag is set to one. 847 Fragment Offset: 848 All zero. 850 Time to Live: 851 Hop Limit value copied from IPv6 header. Since the 852 translator is a router, as part of forwarding the 853 packet it needs to decrement either the IPv6 Hop 854 Limit (before the translation) or the IPv4 TTL (after 855 the translation). As part of decrementing the TTL or 856 Hop Limit the translator (as any router) needs to 857 check for zero and send the ICMPv4 or ICMPv6 "ttl 858 exceeded" error. 860 Protocol: 861 Next Header field copied from IPv6 header. 863 Header Checksum: 864 Computed once the IPv4 header has been created. 866 Source Address: 867 If the IPv6 source address is an IPv4-translated 868 address then the low-order 32 bits of the IPv6 source 869 address is copied to the IPv4 source address. 870 Otherwise, the source address is set to 0.0.0.0. The 871 use of 0.0.0.0 is to avoid completely dropping e.g. 872 ICMPv6 error messages sent by IPv6-only routers which 873 makes e.g. traceroute present something for the 874 IPv6-only hops. 876 Destination Address: 877 IPv6 packets that are translated have an IPv4-mapped 878 destination address. Thus the low-order 32 bits of 879 the IPv6 destination address is copied to the IPv4 880 destination address. 882 If any of an IPv6 hop-by-hop options header, destination options 883 header, or routing header with the Segments Left field equal to zero 884 are present in the IPv6 packet, they are ignored i.e., there is no 885 attempt to translate them. However, the Total Length field and the 886 Protocol field would have to be adjusted to "skip" these extension 887 headers. 889 If a routing header with a non-zero Segments Left field is present 890 then the packet MUST NOT be translated, and an ICMPv6 "parameter 891 problem/ erroneous header field encountered" (Type 4/Code 0) error 892 message, with the Pointer field indicating the first byte of the 893 Segments Left field, SHOULD be returned to the sender. 895 If the IPv6 packet contains a Fragment header the header fields are 896 set as above with the following exceptions: 898 Total Length: 899 Payload length value from IPv6 header, minus 8 for 900 the Fragment header, plus the size of the IPv4 901 header. 903 Identification: 904 Copied from the low-order 16-bits in the 905 Identification field in the Fragment header. 907 Flags: 908 The More Fragments flag is copied from the M flag in 909 the Fragment header. The Don't Fragments flag is set 910 to zero allowing this packet to be fragmented by IPv4 911 routers. 913 Fragment Offset: 914 Copied from the Fragment Offset field in the Fragment 915 Header. 917 Protocol: 918 Next Header value copied from Fragment header. 920 4.2. Translating ICMPv6 922 All ICMP messages that are to be translated require that the ICMP 923 checksum field be updated as part of the translation since ICMPv6, 924 unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP. 926 In addition all ICMP packets needs to have the Type value translated 927 and for ICMP error messages the included IP header also needs 928 translation. 930 The actions needed to translate various ICMPv6 messages are: 932 ICMPv6 informational messages: 934 Echo Request and Echo Reply (Type 128 and 129) 935 Adjust the type to 0 and 8, respectively, and adjust the ICMP 936 checksum both to take the type change into account and to 937 exclude the ICMPv6 pseudo-header. 939 MLD Multicast Listener Query/Report/Done (Type 130, 131, 132) 940 Single hop message. Silently drop. 942 Neighbor Discover messages (Type 133 through 137) 943 Single hop message. Silently drop. 945 Unknown informational messages 946 Silently drop. 948 ICMPv6 error messages: 950 Destination Unreachable (Type 1) 951 Set the Type field to 3. Translate the code field as 952 follows: 953 Code 0 (no route to destination): 954 Set Code to 1 (host unreachable). 956 Code 1 (communication with destination administratively 957 prohibited): 958 Set Code to 10 (communication with destination host 959 administratively prohibited). 961 Code 2 (beyond scope of source address): 962 Set Code to 1 (host unreachable). Note that this 963 error is very unlikely since the IPv4-translatable 964 source address is considered to have global scope. 966 Code 3 (address unreachable): 967 Set Code to 1 (host unreachable). 969 Code 4 (port unreachable): 970 Set Code to 3 (port unreachable). 972 Packet Too Big (Type 2) 973 Translate to an ICMPv4 Destination Unreachable with code 4. 974 The MTU field needs to be adjusted for the difference between 975 the IPv4 and IPv6 header sizes taking into account whether or 976 not the packet in error includes a Fragment header. 978 Time Exceeded (Type 3) 979 Set the Type to 11. The Code field is unchanged. 981 Parameter Problem (Type 4) 982 If the Code is 1 translate this to an ICMPv4 protocol 983 unreachable (Type 3, Code 2). Otherwise set the Type to 12 984 and the Code to zero. The Pointer needs to be updated to 985 point to the corresponding field in the translated include IP 986 header. 988 Unknown error messages 989 Silently drop. 991 4.3. Translating ICMPv6 Error Messages 993 There are some differences between the IPv4 and the IPv6 ICMP error 994 message formats as detailed above. In addition, the ICMP error 995 messages contain the IP header for the packet in error which needs to 996 be translated just like a normal IP header. This translated is 997 likely to change the length of the datagram thus the Payload Length 998 field in the outer IPv6 header might need to be updated. 1000 +-------------+ +-------------+ 1001 | IPv6 | | IPv4 | 1002 | Header | | Header | 1003 +-------------+ +-------------+ 1004 | ICMPv6 | | ICMPv4 | 1005 | Header | | Header | 1006 +-------------+ +-------------+ 1007 | IPv6 | ===> | IPv4 | 1008 | Header | | Header | 1009 +-------------+ +-------------+ 1010 | Partial | | Partial | 1011 | Transport | | Transport | 1012 | Layer | | Layer | 1013 | Header | | Header | 1014 +-------------+ +-------------+ 1016 IPv6-to-IPv4 ICMP Error Translation 1018 The translation of the inner IP header can be done by recursively 1019 invoking the function that translated the outer IP headers. 1021 4.4. Knowing when to Translate 1023 When the translator receives a IPv6 packet with an IPv4-mapped 1024 destination address the packet will be translated to IPv4. 1026 5. IMPLICATIONS FOR IPv6-ONLY NODES 1028 An IPv6-only node which works through SIIT translators need some 1029 modifications beyond a normal IPv6-only node. 1031 As specified in Section 1.3 the application protocols need to handle 1032 operation on a dual stack node. In addition the protocol stack needs 1033 to be able to: 1035 o Determine when an IPv4-translatable address needs to be allocated 1036 and the allocation needs to be refreshed/renewed. This can 1037 presumably be done without involving the applications by e.g. 1038 handling this under the socket API. For instance, when the 1039 connect or sendto socket calls are invoked they could check if the 1040 destination is an IPv4-mapped address and in that case 1041 allocate/refresh the IPv4-translatable address. 1043 o Ensure, as part of the source address selection mechanism, that 1044 when the destination address is an IPv4-mapped address the source 1045 address MUST be an IPv4-translatable address. And an IPv4- 1046 translatable address MUST NOT be used with other forms of IPv6 1047 destination addresses. 1049 o Should the peer have AAAA/A6 address records the application (or 1050 resolver) SHOULD never fall back to looking for A address records 1051 even if communication fails using the available AAAA/A6 records. 1052 The reason for this restriction is to prevent traffic between two 1053 IPv6 nodes (which AAAA/A6 records in the DNS) from accidentally 1054 going through SIIT translators twice; from IPv6 to IPv4 and to 1055 IPv6 again. It is considered preferable to instead signal a 1056 failure to communicate to the application. 1058 6. SECURITY CONSIDERATIONS 1060 The use of stateless IP/ICMP translators does not introduce any new 1061 security issues beyond the security issues that are already present 1062 in the IPv4 and IPv6 protocols and in the routing protocols which are 1063 used to make the packets reach the translator. 1065 As the Authentication Header is specified to include the IPv4 1066 Identification field and the translating function not being able to 1067 always preserve the Identification field, it is not possible for an 1068 IPv6 endpoint to compute AH on received packets that have been 1069 translated from IPv4 packets. Thus AH does not work through a 1070 translator. 1072 Packets with ESP can be translated since ESP does not depend on 1073 header fields prior to the ESP header. Note that ESP transport mode 1074 is easier to handle than ESP tunnel mode; in order to use ESP tunnel 1075 mode the IPv6 node needs to be able to generate an inner IPv4 header 1076 when transmitting packets and remove such an IPv4 header when 1077 receiving packets. 1079 7. CHANGE LOG 1081 Changes since version -05 of the draft: 1083 o Added description on how to handle UDP/IPv4 packets with a zero 1084 UDP checksum. 1085 o Clarified the scope of the document to be a component of a 1086 solution. 1087 o Updated ftp text to talk about EPRT/EPSV and RFC 2428. 1088 o Editorial fixes. 1090 Changes since version -06 of the draft: 1092 o Added specification on how to handle unexpired source routes and 1093 routing headers when translating. Drop such packets to avoid 1094 misdelivery. 1095 o Specified a knob to Traffic Class to TOS translation. Previously 1096 there was a knob for the reverse direction. 1097 o Updated translation of ICMP messages in the face of code 2 for 1098 ICMPv6 unreachable having new semantics (beyond scope of source 1099 address). 1100 o Changed 127.0.0.1 to 0.0.0.0 when translating IPv6 packets, such 1101 as ICMP errors, that do not have an IPv4-translatable source 1102 address. 1103 o Change the name of the draft to include "algorithm" to make it 1104 more clear that this is just a component of a solution. 1105 o Clarified that the IPv4 address pool should not be allocation to 1106 regular IPv4 subnets "inside" a dual site. 1107 o Clarified why IPv4-translatable addresses are needed. 1108 o Made it clear that AH does not work through a translator. 1109 o Stated the assumption that fragmented UDP IPv4 packets with a zero 1110 UDP checksum are rare and appears only to occur in security 1111 attacks thus can be dropped by the translator. 1112 o Clarified PMTU discovery issue for fragmented UDP packets. 1113 o Specified implications for IPv6-nodes in Section 5. 1115 REFERENCES 1117 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 1118 Requirement Levels", RFC 2119, March 1997. 1120 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 1121 6 (IPv6) Specification", RFC 2460, December 1998. 1123 [IPv4] J. Postel, "Internet Protocol", RFC 791, September 1981. 1125 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 1126 Addressing Architecture", RFC 2373, July 1998. 1128 [TRANS-MECH] R. Gilligan, E. Nordmark, "Transition Mechanisms for 1129 IPv6 Hosts and Routers", RFC 1933, April 1996. 1131 [DISCOVERY] T. Narten, E. Nordmark, and W. Simpson, "Neighbor 1132 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1133 1998. 1135 [IPv6-SA] R. Atkinson. "Security Architecture for the Internet 1136 Protocol". RFC 2401, November 1998. 1138 [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 2402, 1139 November 1998. 1141 [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)", 1142 RFC 2406, November 1998. 1144 [ICMPv4] J. Postel, "Internet Control Message Protocol", RFC 792, 1145 September 1981. 1147 [ICMPv6] A. Conta, S. Deering, "Internet Control Message Protocol 1148 (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 1149 2463, December 1998. 1151 [IGMP] S. Deering, "Host extensions for IP multicasting", RFC 1112, 1152 August 1989. 1154 [PMTUv4] J. Mogul, S. Deering, "Path MTU Discovery", RFC 1191, 1155 November 1990. 1157 [PMTUv6] J. McCann, S. Deering, J. Mogul, "Path MTU Discovery for 1158 IP version 6", RFC 1981, August 1996. 1160 [DIFFSERV] K. Nichols, S. Blake, F. Baker, and D. L. Black, 1161 "Definition of the Differentiated Services Field (DS Field) 1162 in the IPv4 and IPv6 Headers", RFC 2474, December 1998. 1164 [MLD] S. Deering, W. Fenner, and B. Haberman, "Multicast Listener 1165 Discovery (MLD) for IPv6", Internet Draft, September 1998. 1167 [FTPEXT] M. Allman, S. Ostermann, C. Metz, "FTP Extensions for IPv6 1168 and NATs.", RFC 2428, September 1998. 1170 [MILLER] G. Miller, Email to the ngtrans mailing list on 26 March 1171 1999. 1172 [BSDAPI] Gilligan, R. E., Thomson, S., Bound, J., Stevens, W., 1173 "Basic Socket Interface Extensions for IPv6", RFC 2553, 1174 March 1999. 1176 AUTHOR'S ADDRESS 1178 Erik Nordmark 1179 Sun Microsystems, Inc. 1180 901 San Antonio Road 1181 Palo Alto, CA 94303 1182 USA 1184 phone: +1 650 786 5166 1185 fax: +1 650 786 5896 1186 email: nordmark@sun.com