idnits 2.17.1 draft-ietf-ngtrans-trans-mech-00.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-26) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 a Security Considerations section. ** 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-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 78 has weird spacing: '...A host or r...' == Line 79 has weird spacing: '...v4-only node ...' == Line 80 has weird spacing: '... hosts and ...' -- 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 (March 17, 1995) is 10633 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: '12' is defined on line 1169, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1541 (ref. '2') (Obsoleted by RFC 2131) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Robert E. Gilligan 3 INTERNET-DRAFT Erik Nordmark 4 Sun Microsystems, Inc. 6 March 17, 1995 8 Transition Mechanisms for IPv6 Hosts and Routers 9 11 Abstract 13 This document specifies IPv4 compatibility mechanisms that can be 14 implemented by IPv6 hosts and routers. These mechanisms include 15 providing complete implementations of both versions of the Internet 16 Protocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing 17 infrastructures. They are designed to allow IPv6 nodes to maintain 18 complete compatibility with IPv4, which should greatly simplify the 19 deployment of IPv6 in the Internet, and facilitate the eventual 20 transition of the entire Internet to IPv6. 22 Status of this Memo 24 This document is an Internet-Draft. Internet-Drafts are working 25 documents of the Internet Engineering Task Force (IETF), its areas, and 26 its working groups. Note that other groups may also distribute working 27 documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet- Drafts as reference material 32 or to cite them other than as ``work in progress.'' 34 To learn the current status of any Internet-Draft, please check the 35 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 36 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 37 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 39 This Internet Draft expires on September 17, 1995. 41 1. Introduction 43 This specification defines mechanisms that IPv6 hosts and routers may 44 implement to be compatible with IPv4 hosts and routers. Maintaining 45 compatibility with IPv4 while deploying IPv6 will streamline the task of 46 transitioning the Internet to IPv6. 48 The mechanisms in this document are designed to be employed by IPv6 49 hosts and routers that need to interoperate with IPv4 hosts and utilize 50 IPv4 routing infrastructures. We expect that complete compatibility 51 with IPv4 will be necessary in the Internet for a long time to come, and 52 perhaps even indefinitely. 54 However, IPv6 may be used in some environments where interoperability 55 with IPv4 is not required. IPv6 nodes that are designed to be used in 56 such environments need not use or even implement these mechanisms. 58 The mechanisms specified here include: 60 - Dual IP layer. Providing complete support for both IPv4 and 61 IPv6 in hosts and routers. 63 - IPv6 over IPv4 tunneling. Encapsulating IPv6 packets within 64 IPv4 headers to carry them over IPv4 routing infrastructures. 65 Two types of tunneling are employed: configured and automatic. 67 Additional transition and compatibility mechanisms may be developed in 68 the future. These will be specified in other documents. 70 1.2. Terminology 72 The following terms are used in this document: 74 Types of Nodes 76 IPv4-only node: 78 A host or router that implements only IPv4. An 79 IPv4-only node does not understand IPv6. The installed 80 base of IPv4 hosts and routers existing before the 81 transition begins are IPv4-only nodes. 83 IPv6/IPv4 node: 85 A host or router that implements both IPv4 and IPv6. 87 IPv6-only node: 89 A host or router that implements IPv6, and does not 90 implement IPv4. The operation of IPv6-only nodes is not 91 addressed here. 93 IPv6 node: 95 Any host or router that implements IPv6. IPv6/IPv4 and 96 IPv6-only nodes are both IPv6 nodes. 98 IPv4 node: 100 Any host or router that implements IPv4. IPv6/IPv4 and 101 IPv4-only nodes are both IPv4 nodes. 103 Types of IPv6 Addresses 105 IPv4-compatible IPv6 address: 107 An IPv6 address, assigned to an IPv6/IPv4 node, which 108 bears the high-order 96-bit prefix 0:0:0:0:0:0, and an 109 IPv4 address in the low-order 32-bits. IPv4-compatible 110 addresses are used by the automatic tunneling mechanism. 112 IPv6-only address: 114 The remainder of the IPv6 address space. An IPv6 115 address that bears a prefix other than 0:0:0:0:0:0. 117 Techniques Used in the Transition 119 IPv6-over-IPv4 tunneling: 121 The technique of encapsulating IPv6 packets within IPv4 122 so that they can be carried across IPv4 routing 123 infrastructures. 125 IPv6-in-IPv4 encapsulation: 127 IPv6-over-IPv4 tunneling. 129 Configured tunneling: 131 IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint 132 address is determined by configuration information on 133 the encapsulating node. 135 Automatic tunneling: 137 IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint 138 address is determined from the IPv4 address embedded in 139 the IPv4-compatible destination address of the IPv6 140 packet. 142 1.3. Structure of this Document 144 The remainder of this document is organized into three sections: 146 - Section 2 discusses the IPv4-compatible address format. 148 - Section 3 discusses the operation of nodes with a dual IP 149 layer, IPv6/IPv4 nodes. 151 - Section 4 discusses IPv6-over-IPv4 tunneling. 153 2. Addressing 155 The automatic tunneling mechanism uses a special type of IPv6 address, 156 termed an "IPv4-compatible" address. An IPv4-compatible address is 157 identified by an all-zeros 96-bit prefix, and holds an IPv4 address in 158 the low-order 32-bits. IPv4-compatible addresses are structured as 159 follows: 161 | 96-bits | 32-bits | 162 +--------------------------------------+--------------+ 163 | 0:0:0:0:0:0 | IPv4 Address | 164 +--------------------------------------+--------------+ 166 IPv4-Compatible IPv6 Address Format 168 IPv4-compatible addresses are assigned to IPv6/IPv4 nodes that support 169 automatic tunneling. Nodes that are configured with IPv4-compatible 170 addresses may use the complete address as their IPv6 address, and use 171 the embedded IPv4 address as their IPv4 address. 173 The remainder of the IPv6 address space (that is, all addresses with 174 96-bit prefixes other than 0:0:0:0:0:0) are termed "IPv6-only 175 Addresses." 176 3. Dual IP Layer 178 The most straightforward way for IPv6 nodes to remain compatible with 179 IPv4-only nodes is by providing a complete IPv4 implementation. IPv6 180 nodes that provide a complete IPv4 implementation in addition to their 181 IPv6 implementation are called "IPv6/IPv4 nodes." IPv6/IPv4 nodes have 182 the ability to send and receive both IPv4 and IPv6 packets. They can 183 directly interoperate with IPv4 nodes using IPv4 packets, and also 184 directly interoperate with IPv6 nodes using IPv6 packets. 186 The dual IP layer technique may or may not be used in conjunction with 187 the IPv6-over-IPv4 tunneling techniques, which are described in 188 section 4. An IPv6/IPv4 node that supports tunneling may support only 189 configured tunneling, or both configured and automatic tunneling. 190 Thus three configurations are possible: 192 - IPv6/IPv4 node that does not perform tunneling. 194 - IPv6/IPv4 node that performs configured tunneling only. 196 - IPv6/IPv4 node that performs configured tunneling and 197 automatic tunneling. 199 3.1. Address Configuration 201 Because they support both protocols, IPv6/IPv4 nodes may be configured 202 with both IPv4 and IPv6 addresses. Although the two addresses may be 203 related to each other, this is not required. IPv6/IPv4 nodes may be 204 configured with IPv6 and IPv4 addresses that are unrelated to each 205 other. 207 Nodes that perform automatic tunneling are configured with 208 IPv4-compatible IPv6 addresses. These may be viewed as single 209 addresses that can serve both as IPv6 and IPv4 addresses. The entire 210 128-bit IPv4-compatible IPv6 address is used as the node's IPv6 211 address, while the IPv4 address embedded in low-order 32-bits serves 212 as the node's IPv4 address. 214 IPv6/IPv4 nodes may use the stateless IPv6 address configuration 215 mechanism [5] or DHCP for IPv6 [3] to acquire their IPv6 address. 216 These mechanisms may provide either IPv4-compatible or IPv6-only IPv6 217 addresses. 219 IPv6/IPv4 nodes may use IPv4 mechanisms to acquire their IPv4 220 addresses. 222 IPv6/IPv4 nodes that perform automatic tunneling may also acquire their 223 IPv4-compatible IPv6 addresses from another source: IPv4 address 224 configuration protocols. A node may use any IPv4 address configuration 225 mechanism to acquire its IPv4 address, then "map" that address into an 226 IPv4-compatible IPv6 address by pre-pending it with the 96-bit prefix 227 0:0:0:0:0:0. This mode of configuration allows IPv6/IPv4 nodes to 228 "leverage" the installed base of IPv4 address configuration servers. It 229 can be particularly useful in environments where IPv6 routers and 230 address configuration servers have not yet been deployed. 232 The specific algorithm for acquiring an IPv4-compatible address using 233 IPv4-based address configuration protocols is as follows: 235 1) The IPv6/IPv4 node uses standard IPv4 mechanisms or protocols 236 to acquire its own IPv4 address. These include: 238 - The Dynamic Host Configuration Protocol (DHCP) [2] 239 - The Bootstrap Protocol (BOOTP) [1] 240 - The Reverse Address Resolution Protocol (RARP) [9] 241 - Manual configuration 242 - Any other mechanism which accurately yields the node's 243 own IPv4 address 245 2) The node uses this address as its IPv4 address. 247 3) The node prepends the 96-bit prefix 0:0:0:0:0:0 to the 32-bit 248 IPv4 address that it acquired in step (1). The result is an 249 IPv4-compatible IPv6 address with the node's own IPv4-address 250 embedded in the low-order 32-bits. The node uses this address 251 as its own IPv6 address. 253 3.2. DNS 255 The Domain Naming System (DNS) is used in both IPv4 and IPv6 to map 256 hostnames into addresses. A new resource record type named "AAAA" has 257 been defined for IPv6 addresses [6]. Since IPv6/IPv4 nodes 258 must be able to interoperate directly with both IPv4 and IPv6 nodes, 259 they must must provide resolver libraries capable of dealing with IPv4 260 "A" records as well as IPv6 "AAAA" records. 262 Some sites use local host tables instead of, or in addition to, the 263 DNS. Use of host tables may be particularly useful in the very early 264 stages of transition before the DNS infrastructure has been converted 265 to support AAAA records. Therefore, implementations may provide a 266 host table mechanism in addition to their DNS resolver. 268 Note that the local host table mechanism does not scale very well, so 269 its use is not recommended for large sites. Further discussion of the 270 host table issue can be found in section 6.1.1 of "Requirements for 271 Internet Hosts -- Application and Support" [10]. 273 3.2.1. Handling Records for IPv4-Compatible Addresses 275 When an IPv4-compatible IPv6 addresses is assigned to an IPv6/IPv4 276 host that supports automatic tunneling, both A and AAAA records are 277 listed in the DNS. The AAAA record holds the full IPv4-compatible 278 IPv6 address, while the A record holds the low-order 32-bits of that 279 address. The AAAA record is needed so that queries by IPv6 hosts can 280 be satisfied. The A record is needed so that queries by IPv4-only 281 hosts, whose resolver libraries only support the A record type, will 282 locate the host. 284 DNS resolver libraries on IPv6/IPv4 nodes must be capable of handling 285 both AAAA and A records. However, when a query locates an AAAA record 286 holding an IPv4-compatible IPv6 address, and an A record holding the 287 corresponding IPv4 address, the resolver library need not necessarily 288 return both addresses. It has three options: 290 - Return only the IPv6 address to the application. 292 - Return only the IPv4 address to the application. 294 - Return both addresses to the application. 296 The selection of which address type to return in this case, or, if 297 both addresses are returned, in which order they are listed, can 298 affect what type of IP traffic is generated. If the IPv6 address is 299 returned, the node will communicate with that destination using IPv6 300 packets (in most cases encapsulated in IPv4); If the IPv4 address is 301 returned, the communication will use IPv4 packets. 303 The way that DNS resolver implementations handle redundant records for 304 IPv4-compatible addresses may depend on whether that implementation 305 supports automatic tunneling, or whether it is enabled. For example, an 306 implementation that does not support automatic tunneling would not 307 return IPv4-compatible IPv6 addresses to applications because those 308 destinations are generally only reachable via tunneling. On the other 309 hand, those implementations in which automatic tunneling is supported 310 and enabled may elect to return only the IPv4-compatible IPv6 address 311 and not the IPv4 address. 313 4. IPv6-over-IPv4 Tunneling 315 In most deployment scenarios, the IPv6 routing infrastructure will be 316 built up over time. While the IPv6 infrastructure is being deployed, 317 the existing IPv4 routing infrastructure can remain functional, and 318 can be used to carry IPv6 traffic. Tunneling provides a way to 319 utilize an existing IPv4 routing infrastructure to carry IPv6 traffic. 321 IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of 322 IPv4 routing topology by encapsulating them within IPv4 packets. 323 Tunneling can be used in a variety of ways: 325 - Router-to-Router. IPv6/IPv4 routers interconnected by an IPv4 326 infrastructure can tunnel IPv6 packets between themselves. In 327 this case, the tunnel spans one segment of the end-to-end path 328 that the IPv6 packet takes. 330 - Host-to-Router. IPv6/IPv4 hosts can tunnel IPv6 packets to an 331 intermediary IPv6/IPv4 router that is reachable via an IPv4 332 infrastructure. This type of tunnel spans the first segment 333 of the packet's end-to-end path. 335 - Host-to-Host. IPv6/IPv4 hosts that are interconnected by an 336 IPv4 infrastructure can tunnel IPv6 packets between 337 themselves. In this case, the tunnel spans the entire 338 end-to-end path that the packet takes. 340 - Router-to-Host. IPv6/IPv4 routers can tunnel IPv6 packets to 341 their final destination IPv6/IPv4 host. This tunnel spans 342 only the last segment of the end-to-end path. 344 Tunneling techniques are usually classified according to the mechanism 345 by which the encapsulating node determines the address of the node at 346 the end of the tunnel. In the first two tunneling methods listed above 347 -- router-to-router and host-to-router -- the IPv6 packet is being 348 tunneled to a router. The endpoint of this type of tunnel is an 349 intermediary router which must decapsulate the IPv6 packet and forward 350 it on to its final destination. When tunneling to a router, the 351 endpoint of the tunnel is different from the destination of the packet 352 being tunneled. So the addresses in the IPv6 packet being tunneled do 353 not provide the IPv4 address of the tunnel endpoint. Instead, the 354 tunnel endpoint address must be determined from configuration 355 information on the node performing the tunneling. We use the term 356 "configured tunneling" to describe the type of tunneling where the 357 endpoint is explicitly configured. 359 In the last two tunneling methods -- host-to-host and router-to-host 360 -- the IPv6 packet is tunneled all the way to its final destination. 362 The tunnel endpoint is the node to which the IPv6 packet is addressed. 363 Since the endpoint of the tunnel is the destination of the IPv6 364 packet, the tunnel endpoint can be determined from the destination 365 IPv6 address of that packet: If that address is an IPv4-compatible 366 address, then the low-order 32-bits hold the IPv4 address of the 367 destination node, and that can be used as the tunnel endpoint address. 368 This technique avoids the need to explicitly configure the tunnel 369 endpoint address. Deriving the tunnel endpoint address from the 370 embedded IPv4 address of the packet's IPv6 address is termed 371 "automatic tunneling". 373 The two tunneling techniques -- automatic and configured -- differ 374 primarily in how they determine the tunnel endpoint address. Most of 375 the underlying mechanisms are the same: 377 - The entry node of the tunnel (the encapsulating node) creates an 378 encapsulating IPv4 header and transmits the encapsulated packet. 380 - The exit node of the tunnel (the decapsulating node) receives 381 the encapsulated packet, removes the IPv4 header, updates the 382 IPv6 header, and processes the received IPv6 packet. 384 - The encapsulating node may need to maintain soft state 385 information for each tunnel recording such parameters as the MTU 386 of the tunnel its path length in order to correctly generate 387 IPv6 ICMP error messages. Since the number of tunnels that any 388 one host or router may be using may grow to be quite large, this 389 state information can be cached and discarded when not in use. 391 The next section discusses the common mechanisms that apply to both 392 types of tunneling. Subsequent sections discuss how the tunnel endpoint 393 address is determined for automatic and configured tunneling. 395 4.1. Common Tunneling Mechanisms 397 The encapsulation of an IPv6 datagram in IPv4 is shown below: 399 +-------------+ 400 | IPv4 | 401 | Header | 402 +-------------+ +-------------+ 403 | IPv6 | | IPv6 | 404 | Header | | Header | 405 +-------------+ +-------------+ 406 | Transport | | Transport | 407 | Layer | ===> | Layer | 408 | Header | | Header | 409 +-------------+ +-------------+ 410 | | | | 411 ~ Data ~ ~ Data ~ 412 | | | | 413 +-------------+ +-------------+ 415 Encapsulating IPv6 in IPv4 417 In addition to adding an IPv4 header the encapsulating node also has to 418 handle some more complex issues: 420 - Determine when to fragment and when to report an ICMP "packet 421 too big" error back to the source. 423 - How to account for the tunnel in the IPv6 Hop Limit field. 425 - How to reflect IPv4 ICMP errors from routers along the tunnel 426 path back to the source as IPv6 ICMP errors. 428 Those issues are discussed in the following sections. 430 4.1.1. Tunnel MTU and fragmentation 432 The encapsulating node could view encapsulation as IPv6 using IPv4 as a 433 link layer with a very large MTU (65535-20 bytes to be exact; 20 bytes 434 "extra" are needed for the encapsulating IPv4 header). The 435 encapsulating node would need only to report IPv6 ICMP "packet too big" 436 errors back to the source for packets that exceed this MTU. However, 437 such a scheme would be inefficient for two reasons: 439 1) It would result in more fragmentation than needed. IPv4 layer 440 fragmentation should be avoided due to the performance problems 441 caused by the loss unit being smaller than the retransmission 442 unit. 444 2) Any IPv4 fragmentation occurring inside the tunnel would have to 445 be reassembled at the tunnel endpoint. For tunnels that 446 terminate at a router, this would require additional memory to 447 reassemble the IPv4 fragments into a complete IPv6 packet before 448 that packet could be forwarded onward. 450 The fragmentation inside the tunnel can be reduced to a minimum by 451 having the encapsulating node track the IPv4 Path MTU across the tunnel 452 (using IPv4 Path MTU Discovery [8] and recording the resulting path MTU 453 in the internet layer). The IPv6 layer in the encapsulating node can 454 then view a tunnel as a link layer with an MTU equal to the IPv4 path 455 MTU, minus the size of the encapsulating IPv4 header. 457 Note that this does not completely eliminate IPv4 fragmentation in the 458 case when the IPv4 path MTU would result in an IPv6 MTU less than 576 459 bytes. (Any link layer used by IPv6 has to have an MTU of at least 576 460 bytes [4].) In this case the IPv6 layer has to "see" a link layer 461 with an MTU of 576 bytes and the encapsulating node has to use IPv4 462 fragmentation in order to forward the 576 byte IPv6 packets. 464 The encapsulating node can employ the following algorithm to determine 465 when to forward an IPv6 packet using IPv4 fragmentation, and when to 466 return an IPv6 ICMP "packet too big" message: 468 if (IPv4 path MTU - 20) is less than 576 469 if packet is larger than 576 bytes 470 Send IPv6 ICMP "packet too big" with MTU = 576. 471 else 472 Encapsulate but do not set the Don't Fragment 473 flag in the IPv4 header. The resulting IPv4 474 packet might be fragmented by the IPv4 layer on 475 the encapsulating node. 476 endif 477 else 478 if packet is larger than (IPv4 path MTU - 20) 479 Send IPv6 ICMP "packet too big" with 480 MTU = (IPv4 path MTU - 20). 481 else 482 Encapsulate and set the Don't Fragment flag 483 in the IPv4 header. 484 endif 485 endif 487 Encapsulating nodes that have a large number of tunnels might not be 488 able to store the IPv4 Path MTU for all tunnels. Such nodes can, at the 489 expense of additional fragmentation in the network, avoid using the IPv4 490 Path MTU algorithm across the tunnel and instead use the MTU of the link 491 layer (under IPv4) in the above algorithm instead of the IPv4 path MTU. 492 In this case the Don't Fragment bit must not be set in the encapsulating 493 IPv4 header. 495 4.1.2. Hop Limit 497 The IPv4 hops of an IPv6-over-IPv4 tunnel can be accounted for in one of 498 two ways: 500 1) Each of the "hops" that an encapsulated IPv6 datagram takes 501 through IPv4 routers can be reflected in the IPv6 hop limit 502 field. For example, if the IPv4 path length of a tunnel is 5 503 hops, the IPv6 "hop limit" field is decremented by 5 when an 504 IPv6 packet travels through the tunnel. We use the term 505 "multi-hop" to describe tunnels that use this model. 507 2) The tunnel can be modeled as consuming only one IPv6 hop 508 independent of its IPv4 path length. That is, the IPv6 hop 509 limit is decremented only by 1 when an IPv6 packet traverses the 510 tunnel. We use the term "single-hop" to describe tunnels that 511 use this model. 513 These two models can be used to achieve different objectives. The 514 multi-hop model can be useful to enforce the scope limitations imposed 515 by the sender of the IPv6 datagram. It also makes the tunnel 516 "traceroute detectable": by sending IPv6 packets with hop limit values 517 that will cause them to "expire" within the tunnel, network management 518 programs like "traceroute" can locate tunnels and determine their path 519 length. Such programs can not determine the addresses of the IPv4 520 routers within the tunnel, however. 522 The single-hop model is useful if the administrator wishes to hide the 523 existence of a tunnel. Since a single-hop tunnel only "consumes" one 524 IPv6 hop, it is not detectable by programs like traceroute. 526 The multi-hop model can be implemented by having the encapsulating node 527 copy the IPv6 hop limit into the IPv4 TTL field when it composes the 528 encapsulating packet, and having the decapsulating node copy the IPv4 529 TTL field back into the IPv6 hop limit field. 531 The single-hop model is implemented by having the encapsulating node 532 select the IPv4 TTL independently of the IPv6 hop limit, and the 533 decapsulating node not copying the IPv4 TTL into the the hop limit 534 field. 536 Implementations may provide either model or both. Implementations that 537 provide both models may wish to give administrators the ability to 538 configure which model is used for each tunnel. 540 If implementations provide configurability, it is important that both 541 ends of the tunnel -- the encapsulating and decapsulating nodes -- are 542 configured to use the same model. If the tunnel endpoints are 543 configured differently, packets could end up with an incorrect IPv6 hop 544 limit. 546 No serious problems would result if the encapsulating node were 547 configured to use the multi-hop model, but the decapsulating node was 548 configured to use the single-hop model. The results would the same as 549 if both ends were configured to use the single-hop model. However, two 550 failure modes can occur if the encapsulating node is configured to use 551 the single-hop model and the decapsulating node is configured to use the 552 multi-hop model: 554 - The IPv6 packet exits the tunnel with a larger hop limit than it 555 had when entering the tunnel. This would occur if the amount of 556 IPv4 TTL remaining when the packet reached the decapsulating 557 node was larger than the IPv6 hop count. This failure can be 558 thought of as the IPv6 packet "gaining hop limit" when passing 559 through the tunnel. 561 - The number of IPv6 hops "consumed" in passing through the tunnel 562 is more than IPv4 path length of the tunnel. This would occur 563 if the difference between the IPv6 hop limit in the packet and 564 the remaining IPv4 TTL was greater than the IPv4 path length of 565 the tunnel. This failure can be thought of as the IPv6 packet 566 "loosing too much hop limit" when passing through the tunnel. 568 Note that in both of these cases, the original IPv6 hop limit is lost. 569 Its value after transiting the tunnel is related only to the IPv4 TTL 570 selected by the encapsulating node, which is not related to the hop 571 limit in the IPv6 packet. 573 Of the two potential failure modes above, the first is more serious 574 since it could cause a packet to "live forever". A routing loop which 575 sent IPv6 packets through such a tunnel could cause an infinite cycle of 576 packets, for example. The second failure mode would cause packets to 577 expire prematurely. 579 The decapsulating node can implement a simple algorithm to prevent the 580 "gaining hop count" problem. This algorithm does not prevent the second 581 problem. This algorithm is implemented as part of the process of 582 decapsulating the IPv6 packet: 584 - If the tunnel is configured to use the "single-hop" model, do 585 not modify the IPv6 hop limit field. 587 - If the tunnel is configured to use the "multi-hop" model, then: 589 - If the IPv4 TTL field is greater than or equal to the 590 IPv6 hop limit field, do not modify the IPv6 hop limit 591 field. 593 - Else, copy the IPv4 TTL field into the IPv6 hop limit 594 field. 596 It is an open issue whether the "loosing too much hop count" problem is 597 serious enough to require that a solution be developed. 599 Note that the decision about whether to copy the IPv4 TTL field into the 600 hop limit field does not affect the requirement to decrement the hop 601 limit field; If the encapsulating or decapsulating node is an IPv6 602 router that forwards the packet, it must decrement the IPv6 hop count. 604 Note also that the hop limit problem affects only configured tunnels. 605 Automatic tunnels terminate at the end node, where the packet is 606 consumed, not forwarded, so the remaining hop limit is irrelevant. 608 4.1.3. Handling IPv4 ICMP errors 610 The encapsulating node has to be able to handle IPv4 ICMP errors that 611 are generated by routers interior to the tunnel. All such errors are 612 returned to the encapsulating node since the encapsulating node is the 613 IPv4 source of the packets. 615 Ideally the encapsulating node would want to convert these errors to 616 IPv6 ICMP errors and send them back to the source of the original IPv6 617 datagram. However, this in infeasible since the IPv4 ICMP errors may 618 not return enough of the "offending packet". Many IPv4 implementations 619 only return the IPv4 header plus 8 bytes of the IPv4 payload, which will 620 not even contain the complete IPv6 header, let alone enough higher level 621 headers for the originating node to determine which application 622 originated the packet that experienced the error. 624 For the purpose of this discussion there are two categories of errors: 626 1) ICMP errors that are needed to maintain connectivity. Only ICMP 627 "packet too big" falls in this category; a persistent loss of 628 ICMP "packet too big" message would result in a black hole for 629 large packets. 631 2) ICMP errors that are needed by network management tools like 632 traceroute. These errors include ICMP unreachable and ICMP TTL 633 expired. 635 The ICMP "packet too big" errors are handled according to IPv4 Path MTU 636 Discovery [8] and the resulting path MTU is recorded in the IPv4 layer. 637 The recorded path MTU is used by IPv6 to determine if an IPv6 ICMP 638 "packet too big" error has to be generated as described in section 639 4.1.1. 641 The other errors can be handled as described in the remainder of this 642 section to make multi-hop tunnels be "traceroute detectable." Making a 643 tunnel traceroute detectable is implemented by having the encapsulating 644 node maintain "soft state" information about the tunnel. This state is 645 created based on the IPv4 ICMP errors that are received in response to 646 encapsulated packets. When the encapsulating node prepares to send an 647 IPv6 packet into a tunnel, it consults the tunnel state to determine if 648 the packet is likely to generate an ICMP error inside the tunnel. If 649 so, it generates an appropriate IPv6 ICMP error, which it sends back to 650 the source of the IPv6 packet. It also encapsulates the packet and 651 sends it into the tunnel. The latter is needed to quickly recover from 652 transient error conditions. 654 Note that, since the IPv6 ICMP error message originates at the 655 encapsulating node, not at the IPv4 router within the tunnel, the node 656 that sent the original IPv6 packet does not receive the address of the 657 IPv4 router. Thus a traceroute program may not determine the addresses 658 of the IPv4 routers within a tunnel, but it may detect their presence by 659 noting that a packets with a consecutive range of hop limits expire at 660 the same router (the encapsulating router). 662 Tunnel state information is associated with the IPv4 address of the 663 endpoint of the tunnel and can include: 665 - The MTU of the Tunnel. Its use is described in section 4.1.1. 667 - Reachability of the endpoint of the tunnel. 669 - If the endpoint of the tunnel is unreachable, the IPv4 address 670 of the router reporting unreachability. 672 - Path length of the tunnel (number of IPv4 hops to the endpoint). 674 - For each TTL 't' between 1 and the path length of the tunnel, 675 the IPv4 address of the router that was last known to be 't' 676 hops into the tunnel. 678 Maintaining the IPv4 addresses of the routers internal to the tunnel is 679 not strictly necessary for correct operation, but is useful for network 680 management. 682 The tunnel state does not have to be allocated until an ICMP error is 683 received. In the absence of tunnel state, the tunnel MTU can be assumed 684 to be the MTU of the outgoing interface, the path length one hop and the 685 endpoint being reachable. 687 When the encapsulating node receives an IPv4 ICMP error where the 688 "offending packet" is an IPv6-in-IPv4 packet (i.e. an IPv4 packet with 689 an IP protocol field of 41), the encapsulating node updates the tunnel 690 state associated with the IPv4 destination in the "offending packet". 691 The update depends on the type of ICMP error: 693 - Host or network unreachable: Mark the tunnel endpoint as 694 unreachable and record the source of the ICMP error as the 695 source of unreachability. 697 - Time exceeded in transit: The TTL "consumed" before reaching the 698 router that sent the time exceeded message is extracted from the 699 IPv6 hop limit field in the "offending packet" (the IPv6 hop 700 limit field is in the first 8 bytes of the IPv6 header thus it 701 will be returned in the ICMP packet). Compute the updated tunnel 702 path length as the maximum of the currently recorded path length 703 and the extracted IPv6 hop limit. Record the source of the ICMP 704 error as the router at 'IPv6 hop limit' hops into the tunnel. 706 - "Packet too big": Use the IPv4 Path MTU Discovery [8] 707 algorithm to update the tunnel MTU. 709 - For all other ICMP errors log a network management event. 711 When the encapsulating node prepares to forward an IPv6 packet into the 712 tunnel it performs the following checks against the tunnel state: 714 - If the tunnel endpoint is unreachable, it generates an IPv6 ICMP 715 "destination unreachable" message. 717 - If the hop limit is less than the recorded tunnel TTL, it 718 generates an IPv6 ICMP "time exceeded" message. 720 - If the packet would violate the tunnel MTU, generate an IPv6 721 ICMP "packet too big" message, as specified in section 4.1.1. 723 The IPv6 ICMP error message is sent back to the source of the IPv6 724 packet, and includes as much of the original IPv6 packet as will fit. 725 The source IPv6 address of the ICMP message is that of the encapsulating 726 node. That original IPv6 packet is also forwarded into the tunnel. 728 The algorithm as described above quickly returns IPv6 ICMP errors as a 729 result of IPv4 ICMP errors from inside the tunnel. In order to determine 730 when the error condition is lifted, it relies on: 732 - A timeout. All tunnel state, except the tunnel MTU, should be 733 discarded after at most 30 seconds after it was created. If the 734 error condition still exists and packets continue to flow 735 through that tunnel, IPv4 ICMP errors will continue to arrive 736 and they will cause a refresh of the tunnel state. 738 The tunnel MTU is timed out as described in IPv4 Path MTU 739 Discovery [8]. 741 - Data packets are always sent into the tunnel, even when the 742 encapsulating node generates an IPv6 ICMP error message. This 743 means that packets will get through as soon as the error 744 condition within the tunnel is relieved, although error reports 745 may continue for a short period thereafter. 747 4.1.4. IPv4 Header Construction 749 When encapsulating an IPv6 packet in an IPv4 datagram, the IPv4 header 750 fields are set as follows: 752 Version: 754 4 756 IP Header Length in 32-bit words: 758 5 (There are no IPv4 options in the encapsulating 759 header.) 761 Type of Service: 763 0 765 Total Length: 767 Payload length from IPv6 header plus length of IPv6 and 768 IPv4 headers (i.e. a constant 60 bytes). 770 Identification: 772 Generated uniquely as for any IPv4 packet transmitted by 773 the system. 775 Flags: 777 Set the Don't Fragment (DF) flag as specified in 778 section 4.1.1. Set the More Fragments (MF) bit as 779 necessary if fragmenting. 781 Fragment offset: 783 Set as necessary if fragmenting. 785 Time to Live: 787 If tunnel is configured as multi-hop: 789 Copied from the IPv6 hop limit field. 791 If tunnel is configured as single-hop: 793 Set to pre-configured value. 795 Protocol: 797 41 (Assigned payload type number for IPv6) 799 Header Checksum: 801 Calculate the checksum of the IPv4 header. 803 Source Address: 805 IPv4 address of outgoing interface of the 806 encapsulating node. 808 Destination Address: 810 IPv4 address of of tunnel endpoint. 812 Any IPv6 options are preserved in the packet (after the IPv6 header). 814 4.1.5. Decapsulating IPv6-in-IPv4 Packets 816 When an IPv6/IPv4 host or a router receives an IPv4 datagram that is 817 addressed to one of its own IPv4 address, and the value of the protocol 818 field is 41, it removes the IPv4 header and submits the IPv6 datagram to 819 its IPv6 layer code. 821 The decapsulation is shown below: 823 +-------------+ 824 | IPv4 | 825 | Header | 826 +-------------+ +-------------+ 827 | IPv6 | | IPv6 | 828 | Header | | Header | 829 +-------------+ +-------------+ 830 | Transport | | Transport | 831 | Layer | ===> | Layer | 832 | Header | | Header | 833 +-------------+ +-------------+ 834 | | | | 835 ~ Data ~ ~ Data ~ 836 | | | | 837 +-------------+ +-------------+ 839 Decapsulating IPv6 from IPv4 841 When decapsulating the IPv6-in-IPv4 packet, only the hop limit field of 842 the IPv6 header is modified: 844 If tunnel is configured as single-hop: 846 Do not modify the IPv6 hop limit field. 848 If tunnel is configured as multi-hop: 850 If the IPv4 TTL field is greater than or equal to the 851 IPv6 hop limit field, do not modify the IPv6 hop limit 852 field. Else, copy the IPv4 TTL field into the IPv6 hop 853 limit field. 855 Then the encapsulating IPv4 header is discarded. 857 Note that the decapsulating node performs IPv4 reassembly before 858 decapsulating the IPv6 packet. All IPv6 options are preserved even if 859 the encapsulated IPv4 packet is fragmented. 861 After the IPv6 packet is decapsulated, it is treated the same as any 862 received IPv6 packet. 864 4.2. Configured Tunneling 866 In configured tunneling, the tunnel endpoint address is determined from 867 configuration information in the encapsulating node. For each tunnel, 868 the encapsulating node must store the tunnel endpoint address. When an 869 IPv6 packet is transmitted over a tunnel, the tunnel endpoint address 870 configured for that tunnel is used as the destination address for the 871 encapsulating IPv4 header. 873 The determination of which packets to tunnel is usually made by routing 874 information on the encapsulating node. This is usually done via a 875 routing table, which directs packets based on their destination address 876 using the prefix mask and match technique. 878 4.2.1. Default Configured Tunnel 880 Nodes that are connected to IPv4 routing infrastructures may use a 881 configured tunnel to reach an IPv6 "backbone". If the IPv4 address of 882 an IPv6/IPv4 router bordering the backbone is known, a tunnel can be 883 configured to that router. This tunnel can be configured into the 884 routing table as a "default route". That is, all destinations will 885 match the route and could potentially traverse the tunnel. Since the 886 "mask length" of such default route is zero, it will be used only if 887 there are no other routes with a longer mask that match the destination. 889 The tunnel endpoint address of such a default tunnel could be the IPv4 890 address of one IPv6/IPv4 router at the border of the IPv6 backbone. 891 Alternatively, the tunnel endpoint could be an IPv4 "logical address". 892 With this approach, multiple IPv6/IPv4 routers at the border advertise 893 IPv4 reachability to the same IPv4 logical address. All of these 894 routers accept packets to this address as their own, and will 895 decapsulate IPv6 packets tunneled to this address. This logical address 896 operates something like an "anycast address": When an IPv6/IPv4 node 897 send an encapsulated packet to this address, it will be delivered to 898 only one of border routers, but the sending node will not know which 899 one. The IPv4 routing system will generally carry the traffic to the 900 closest router. 902 Using a default tunnel to a logical IPv4 address provides a high degree 903 of robustness since multiple border router can be provided, and traffic 904 will automatically switch to another router when one goes down. 906 4.3. Automatic Tunneling 908 In automatic tunneling, the tunnel endpoint address is determined from 909 the packet being tunneled. The destination IPv6 address in the packet 910 must be an IPv4-compatible address. If it is, the IPv4 address 911 component of that address -- the low-order 32-bits -- are extracted and 912 used as the tunnel endpoint address. IPv6 packets that are not 913 addressed to an IPv4-compatible address can not be tunneled using 914 automatic tunneling. 916 The determination of which packets to automatically tunnel can be made 917 by routing table information. This can be configured in the routing 918 table as route to the prefix 0:0:0:0:0:0:0:0/96. That is, a route to 919 the all-zeros prefix with a 96-bit mask. Packets to all destinations 920 bearing the all-zeros 96-bit prefix can be sent via automatic tunneling. 922 4.4. Default Sending Algorithm 924 This section presents a combined IPv4 and IPv6 sending algorithm that 925 IPv6/IPv4 nodes can use. The algorithm can be used to determine when to 926 send IPv4 packets, when to send IPv6 packets, and when to perform 927 automatic and configured tunneling. It illustrates how the techniques 928 of dual IP layer, configured tunneling, and automatic tunneling can be 929 used together. The algorithm has the following properties: 931 - Sends IPv4 packets to all IPv4 destinations. 933 - Sends IPv6 packets to all IPv6 destinations on the same link. 935 - Using automatic tunneling, sends IPv6 packets encapsulated in 936 IPv4 to IPv6 destinations with IPv4-compatible addresses that 937 are located off-link. 939 - Sends IPv6 packets to IPv6 destinations located off-link when 940 IPv6 routers are present. 942 - Using the default IPv6 tunnel, sends IPv6 packets encapsulated 943 in IPv4 to IPv6 destinations with IPv6-only addresses when no 944 IPv6 routers are present. 946 The algorithm is as follows: 948 1) If the address of the end node is an IPv4 address then: 950 1.1) If the destination is located on the attached link, then 951 send an IPv4 packet addressed to the end node. 953 1.2) If the destination is located off-link, then; 955 1.2.1) If there is an IPv4 router on link, then send an 956 IPv4 format packet. The IPv4 destination 957 address is the IPv4 address of the end node. 958 The datalink address is the datalink address of 959 the IPv4 router. 961 1.2.2) Else, the destination is treated as 962 "unreachable" because it is located off link and 963 there are no on-link routers. 965 2) If the address of the end node is an IPv4-compatible IPv6 966 address (i.e. bears the prefix 0:0:0:0:0:0), then: 968 2.1) If the destination is located on the attached link, then 969 send an IPv6 format packet (not encapsulated). The IPv6 970 destination address is the IPv6 address of the end node. 971 The datalink address is the datalink address of the end 972 node. 974 2.2) If the destination is located off-link, then: 976 2.2.1) If there is an IPv4 router on the attached link, 977 then send an IPv6 packet encapsulated in IPv4. 978 The IPv6 destination address is the address of 979 the end node. The IPv4 destination address is 980 the low-order 32-bits of the end node's address. 981 The datalink address is the datalink address of 982 the IPv4 router. 984 2.2.2) Else, if there is an IPv6 router on the attached 985 link, then send an IPv6 format packet. The IPv6 986 destination address is the IPv6 address of the 987 end node. The datalink address is the datalink 988 address of the IPv6 router. 990 2.2.3) Else, the destination is treated as 991 "unreachable" because it is located off-link and 992 there are no on-link routers. 994 3) If the address of the end node is an IPv6-only address, then: 996 3.1) If the destination is located on the attached link, then 997 send an IPv6 format packet. The IPv6 destination 998 address is the IPv6 address of the end node. The 999 datalink address is the datalink address of the end 1000 node. 1002 3.2) If the destination is located off-link, then: 1004 2.2.1) If there is an IPv6 router on the attached link, 1005 then send an IPv6 format packet. The IPv6 1006 destination address is the IPv6 address of the 1007 end node. The datalink address is the datalink 1008 address of the IPv6 router. 1010 2.2.2) Else, if the destination is reachable via a 1011 configured tunnel, and there is an IPv4 router 1012 on the attached link link, then send an IPv6 1013 packet encapsulated in IPv4. The IPv6 1014 destination address is the address of the end 1015 node. The IPv4 destination address is the 1016 configured IPv4 address of the tunnel endpoint. 1017 The datalink address is the datalink address of 1018 the IPv4 router. 1020 2.2.3) Else, the destination is treated as 1021 "unreachable" because it is located off-link and 1022 there are no on-link IPv6 routers. 1024 A summary of these sending rules are given in the table below: 1026 End | End | IPv4 | IPv6 | Packet | | | 1027 Node | Node | Router | Router | Format | IPv6 | IPv4 | DLink 1028 Address | On | On | On | To | Dest | Dest | Dest 1029 Type | Link? | Link? | Link? | Send | Addr | Addr | Addr 1030 ------------+---------+---------+---------+--------+------+------+------ 1031 IPv4 | Yes | N/A | N/A | IPv4 | N/A | E4 | EL 1032 ------------+---------+---------+---------+--------+------+------+------ 1033 IPv4 | No | Yes | N/A | IPv4 | N/A | E4 | RL 1034 ------------+---------+---------+---------+--------+------+------+------ 1035 IPv4 | No | No | N/A | UNRCH | N/A | N/A | N/A 1036 ------------+---------+---------+---------+--------+------+------+------ 1037 IPv4-compat | Yes | N/A | N/A | IPv6 | E6 | N/A | EL 1038 ------------+---------+---------+---------+--------+------+------+------ 1039 IPv4-compat | No | Yes | N/A | IPv6/4 | E6 | E4 | RL 1040 ------------+---------+---------+---------+--------+------+------+------ 1041 IPv4-compat | No | No | Yes | IPv6 | E6 | N/A | RL 1042 ------------+---------+---------+---------+--------+------+------+------ 1043 IPv4-compat | No | No | No | UNRCH | N/A | N/A | N/A 1044 ------------+---------+---------+---------+--------+------+------+------ 1045 IPv6-only | Yes | N/A | N/A | IPv6 | E6 | N/A | EL 1046 ------------+---------+---------+---------+--------+------+------+------ 1047 IPv6-only | No | N/A | Yes | IPv6 | E6 | N/A | RL 1048 ------------+---------+---------+---------+--------+------+------+------ 1049 IPv6-only | No | Yes | No | IPv6/4 | E6 | T4 | RL 1050 ------------+---------+---------+---------+--------+------+------+------ 1051 IPv6-only | No | No | No | UNRCH | N/A | N/A | N/A 1052 ------------+---------+---------+---------+--------+------+------+------ 1054 Key to Abbreviations 1055 -------------------- 1056 N/A: Not applicable or does not matter. 1057 E6: IPv6 address of end node. 1058 E4: IPv4 address of end node (low-order 32-bits of 1059 IPv4-compatible address). 1060 EL: Datalink address of end node. 1061 T4: IPv4 address of the tunnel endpoint. 1062 R6: IPv6 address of router. 1063 R4: IPv4 address of router. 1064 RL: Datalink address of router. 1065 IPv4: IPv4 packet format. 1066 IPv6: IPv6 packet format. 1067 IPv6/4: IPv6 encapsulated in IPv4 packet format. 1068 UNRCH: Destination is unreachable. Don't send a packet. 1070 4.4.1 On/Off Link Determination 1072 Part of the process of determining what packet format to use includes 1073 determining whether a destination is located on an attached link or 1074 not. IPv4 and IPv6 employ different mechanisms. IPv4 uses an 1075 algorithm in which the destination address and the interface address 1076 are both logically ANDed with the netmask of the interface and then 1077 compared. If the resulting two values match, then the destination is 1078 located on-link. This algorithm is discussed in more detail in 1079 Section 3.3.1.1 of the document "Requirements for Internet Hosts -- 1080 Communications Layers" [11]. IPv6 uses the neighbor discovery 1081 algorithm described in "IPv6 Neighbor Discovery -- Processing" [7]. 1083 IPv6/IPv4 nodes need to use both methods: 1085 - If a destination is an IPv4 address, then the on/off link 1086 determination is made by comparison with the netmask, as 1087 described in RFC 1122 section 3.3.1.1. 1089 - If a destination is represented by an IPv4-compatible IPv6 1090 address (prefix 0:0:0:0:0:0), the decision is made using the 1091 IPv4 netmask comparison algorithm using the low-order 32-bits 1092 (IPv4 address part) of the destination address. 1094 - If the destination is represented by an IPv6-only address 1095 (prefix other than 0:0:0:0:0:0), the on/off link determination 1096 is made using the IPv6 neighbor discovery mechanism. 1098 5. Acknowledgements 1100 We would like to thank the members of the IPng working group and the 1101 IPng transition working group for their extensive review of this 1102 document. 1104 The IPv4 "logical address" default tunnel technique was originally 1105 suggested by John Moy. 1107 6. Authors' Address 1109 Robert E. Gilligan 1110 Sun Microsystems, Inc. 1111 2550 Garcia Ave. 1112 Mailstop UMTV 05-44 1113 Mountain View, California 94043 1115 415-336-1012 (voice) 1116 415-336-6015 (fax) 1118 Bob.Gilligan@Eng.Sun.COM 1120 Erik Nordmark 1121 Sun Microsystems, Inc. 1122 2550 Garcia Ave. 1123 Mailstop UMTV 05-44 1124 Mountain View, California 94043 1126 415-336-2788 (voice) 1127 415-336-6015 (fax) 1129 Erik.Nordmark@Eng.Sun.COM 1131 7. References 1133 [1] W. Croft, J. Gilmore. "Bootstrap Protocol". RFC 951. 1134 September 1985. 1136 [2] R. Droms. "Dynamic Host Configuration Protocol". RFC 1541. 1137 October 1993. 1139 [3] J. Bound, Y. Rekhter, Sue Thompson. "Dynamic Host 1140 Configuration Protocol for IPv6". Internet Draft 1141 . February 1995. 1143 [4] R. Hinden. "Internet Protocol, Version 6 (IPv6) 1144 Specification". Internet Draft 1145 . October 1994. 1147 [5] IPv6 Address Configuration. Internet Draft to be written. 1149 [6] S. Thompson, C. Huitema. "DNS Extensions to support IP version 1150 6". Internet Draft . October 1151 1994. 1153 [7] W. A. Simpson. "IPv6 Neighbor Discovery -- Processing". 1154 Internet Draft . 1155 October 1994. 1157 [8] J. Mogul, S. Deering. "Path MTU Discovery". RFC 1191. 1158 November 1990. 1160 [9] R. Finlayson, T. Mann, J. Mogul, M. Theimer. "Reverse Address 1161 Resolution Protocol". RFC 903. June 1984. 1163 [10] R. Braden. "Requirements for Internet Hosts - Application And 1164 Support". RFC 1123. October 1989. 1166 [11] R. Braden. "Requirements for Internet Hosts - Communication 1167 Layers". RFC 1122. October 1989. 1169 [12] A. Conta, S. Deering. "ICMP for the Internet Protocol Version 6 1170 (IPv6)". Internet Draft . 1171 February 1995.