Internet Engineering Task Force Robert E. Gilligan INTERNET-DRAFT Erik Nordmark Sun Microsystems, Inc. January 23, 1994 Transition Mechanisms for IPv6 Hosts and Routers Abstract This document specifies a set of mechanisms that IPv6 hosts and routers may implement in order to interoperate with IPv4 hosts and routers. These mechanisms are designed to make the transition of the global Internet from IPv4 to to IPv6 as easy as possible. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). This Internet Draft expires on July 23, 1995. draft-gilligan-ipv6-trans-mech-01.txt [Page 1] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 1. Introduction This specification defines mechanisms that may be implemented by IPv6 hosts and routers so that they may be compatible with IPv4 hosts and routers. Maintaining compatibility with IPv4 while deploying IPv6 is the primary objective of the transition. The mechanisms in this document are designed to be employed by IPv6 hosts and routers that need to interoperate with IPv4 hosts and utilize IPv4 routing infrastructures. It is expected that in the operational Internet, complete compatibility with IPv4 will be necessary for a long time to come, and perhaps even indefinitely. However, IPv6 may be used in some environments where interoperability with IPv4 is not necessary. IPv6 nodes that are designed to be used in such environments need not use or even impelement these mechanisms. The mechanisms discussed here include: - IPv6 Addressing schemes designed to be compatible with IPv4. - DNS resolver algorithms for dealing with IPv4 and IPv6 address records. - Automatic and configured tunneling of IPv6 packets over IPv4 routing infrastructures. - IPv4/IPv6 header translation is discussed briefly here, and in more detail in a companion document "Transition Mechanisms for Header Translating Routers" [TRANS-XLATE]. 1.2. Terminology The following terms are used in this document: Types of Nodes IPv4-only node: A host or router that implements only IPv4. An IPv4-only node does not understand IPv6. The installed base of IPv4 hosts and routers existing before the transition begins are all IPv4-only nodes. IPv6/IPv4 (dual) node: A host or router that implements both IPv4 and IPv6 as well as IPv6-over-IPv4 tunneling and other transition draft-gilligan-ipv6-trans-mech-01.txt [Page 2] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 mechanisms. IPv6-only node: A host or router that implements IPv6, and does not implement IPv4. IPv6-only nodes also implement a few minimal transition mechanisms, but do not implement tunneling. IPv6 node: Any host or router that implements IPv6. IPv6/IPv4 and IPv6-only nodes are both IPv6 nodes. IPv4 node: Any host or router that implements IPv4. IPv6/IPv4 and IPv4-only nodes are both IPv4 nodes. IPv6/IPv4 header translating router: An IPv6/IPv4 router that performs IPv6/IPv4 header translation. Types of IPv6 Addresses IPv4-compatible IPv6 address: An address, assigned to an IPv6 node, that can be used for both IPv6 and IPv4. An IPv4-compatible IPv6 address holds an IPv4 address in the low-order 32-bits. The high-order 96 bits bear the prefix 0:0:0:0:0:ffff. The entire 128-bit address can be used when sending IPv6 packets. The low-order 32-bits can be used when sending IPv4 packets. IPv4-compatible IPv6 addresses always identify IPv6 nodes (either IPv6/IPv4 or IPv6-only nodes); they never identify IPv4-only nodes. IPv4-mapped IPv6 address: The address of an IPv4-only node represented as an IPv6 address. The IPv4 address is stored in the low-order 32 bits of an IPv4-mapped IPv6 address. The high-order 96 bits bear the prefix 0:0:0:0:0:0. The address of any IPv4-only node may be mapped into the the IPv6 address draft-gilligan-ipv6-trans-mech-01.txt [Page 3] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 space by prepending the prefix 0:0:0:0:0:0 to its IPv4 address. IPv4-mapped IPv6 addresses always identify IPv4-only nodes; they never identify IPv6/IPv4 or IPv6-only nodes. IPv6-only address: An IPv6 address that does not necessarily hold an IPv4-address embedded in the low-order 32-bits. IPv6-only addresses bear prefixes other than 0:0:0:0:0:0 and 0:0:0:0:0:ffff. IPv6-only addresses always identify IPv6/IPv4 or IPv6-only nodes; they never identify IPv4-only nodes. Types of Routing Infrastructures IPv4-complete area: A region of infrastructure that routes IPv4 completely. IPv6-complete area: A region of infrastructure that routes IPv6 completely. Techniques Used in the Transition IPv6-over-IPv4 tunneling: The technique of encapsulating IPv6 packets within IPv4 so that it can be carried across an IPv4-complete area. IPv6-in-IPv4 encapsulation: IPv6-over-IPv4 tunneling. IPv6/IPv4 header translation: The technique of translating the Internet headers of IPv6 packets into IPv4, and IPv4 packets into IPv6, so that IPv4-only and IPv6-only hosts can interoperate. 1.3. Structure of this Document draft-gilligan-ipv6-trans-mech-01.txt [Page 4] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 The specifications are organized into three sections: - Section 2 specifies the mechanisms that can be implemented in both IPv6/IPv4 dual nodes, and IPv6-only nodes. - Section 3 details the mechanisms that can only be implemented in IPv6/IPv4 dual nodes. - Section 4 specifies the mechanisms that only apply to IPv6-only nodes. Thus someone implementing an IPv6/IPv4 host or router should read sections 2 and 3, while someone implementing an IPv6-only node should read sections 2 and 4. draft-gilligan-ipv6-trans-mech-01.txt [Page 5] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 2. Common Mechanisms This section details the mechanisms that can be implemented in both IPv6/IPv4 as well as IPv6-only hosts and routers. 2.1. Addressing All IPv6 nodes can use a special type of address, termed an "IPv4-compatible" IPv6 address. An IPv4-compatible address holds an IPv4 address in the low-order 32-bits, and this property allows it to be used both as an IPv6 address and as an IPv4 address: | 96-bits | 32-bits | +--------------------------------------+--------------+ | 0:0:0:0:0:ffff | IPv4 Address | +--------------------------------------+--------------+ IPv4-Compatible IPv6 Address Format IPv4-compatible addresses can be used in a number of ways: - An IPv6 node that is configured with an IPv4-compatible address can use that address when interoperating with other IPv6 nodes. It can use its IPv4-compatible address for sending or receiving IPv6 packets. - When sending or receiving IPv4 packets, an IPv6/IPv4 node that is configured with an IPv4-compatible address can use the low-order 32-bits of that address as its own IPv4 address. - An IPv6-only node that is configured with an IPv4-compatible address can use that address when interoperating with IPv4-only nodes. The addresses of IPv4-only nodes may be represented as IPv6 addresses. These addresses are termed "IPv4-mapped" IPv6 addresses and have the format: | 96-bits | 32-bits | +--------------------------------------+--------------+ | 0:0:0:0:0:0 | IPv4 Address | +--------------------------------------+--------------+ IPv4-Mapped IPv6 Address Format IPv4-mapped addresses can also be used in a variety of ways: - When an IPv4 packet sent by an IPv4-only node is translated into draft-gilligan-ipv6-trans-mech-01.txt [Page 6] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 IPv6, the source address of the resulting IPv6 packet is an IPv4-mapped address, indicating to the recipient that the sender is an IPv4-only node. - When IPv6-only nodes send IPv6 packets to IPv4-only nodes, the destination address is an IPv4-mapped address, indicating that the IPv6 packet must be translated to IPv4 before its final delivery. - They can be used internally within implementations to represent an IPv4 address in a data structure designed to hold an IPv6 address. The remainder of the IPv6 address space (that is, all addresses with 96-bit prefixes other than 0:0:0:0:0:0 or 0:0:0:0:0:ffff) are termed "IPv6-only Addresses" because they are only used by IPv6 nodes to interoperate with other IPv6 nodes. 2.2. DNS Both IPv4 and IPv6 use the Domain Naming System (DNS) to map hostnames into addresses. A new resource record type named "AAAA" has been defined for IPv6 addresses [IPv6-DNS]. IPv6 nodes that are designed to interoperate with IPv4-only nodes must must provide resolver libraries capable of dealing with IPv4 "A" records as well as IPv6 "AAAA" records. Some sites use local host tables instead of, or in addition to, the DNS. Use of host tables may be particularly useful in the very early stages of transition before the DNS infrastructure has been converted to support AAAA records. Therefore, implementations may provide a host table mechanism in addition to their DNS resolver. Note that the local host table mechanism does not scale very well, so its use is not recommended for large sites. Further discussion of the host table issue can be found in section 6.1.1 of "Requirements for Internet Hosts -- Application and Support" [RFC-1123]. 2.2.1. Records for IPv4-only Node Even though the addresses of IPv4-only nodes can be represented as IPv4-mapped IPv6 addresses, and stored in DNS AAAA address records, this is not done. Instead, the addresses of IPv4-only nodes are listed only in "A" type records. This arrangement simplifies the administration of the DNS, since only one record type need be listed for IPv4-only nodes, not two. It is also avoids the need to upgrade the DNS records of all of the existing IPv4-only nodes, which would be time consuming and expensive. draft-gilligan-ipv6-trans-mech-01.txt [Page 7] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 2.2.2. Handling A Records Since the addresses of IPv4-only nodes are stored in A records, IPv6 hosts that wish to interoperate with them must implement resolver libraries capable of supporting A records. The specific manner by which an IPv6 host handles A records may vary in different implementations. Two possible approaches are: 1) The resolver library can take the IPv4 address given in the A record, pre-pend the prefix 0:0:0:0:0:0, and return the resulting IPv4-mapped IPv6 address to the application. The application can then pass this IPv6 address to the transport layer, which in turn can pass it down to the Internet layer. 2) The resolver library can return the IPv4 address given in the A record directly to the application. The application can then pass this IPv4 address to the transport layer. Both of these approaches will have the same affect. They will both cause the same format of datagram to be sent. The first approach has the advantage that it allows applications to treat addresses of IPv4-only hosts and IPv6 hosts the same, and it allows the interface between the application and the transport layer to be cast entirely in terms of IPv6 addresses. If the second approach is used, the interface between the application and transport layer must be designed to carry IPv4 addresses. For this reason, the second approach is probably not appropriate for IPv6-only hosts, while IPv6/IPv4 hosts could implement either approach. 2.2.3. Redundant A Records When an IPv4-compatible IPv6 addresses is assigned to an IPv6 host, that address is listed in the DNS in both A and AAAA resource records. The A record is needed so that queries by IPv4-only hosts, whose resolver libraries only support the A record type, will locate the host. The AAAA record is needed so that queries by IPv6 hosts can be satisfied. Both records hold the same addressing information: the full 128-bit IPv4-compatible address is listed in an AAAA record, while the low-order 32-bits of that address is listed in an A record. DNS resolver libraries on IPv6 nodes that are designed to interoperate with IPv4-only nodes must be capable of handling both AAAA and A records. However, when a query locates both an AAAA record and an A record representing the same IPv4-compatible IPv6 address, the resolver should not return both to the application, since doing so would give the application redundant information: two versions of the same address. Instead, it should return only the AAAA record address to the draft-gilligan-ipv6-trans-mech-01.txt [Page 8] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 application. DNS resolvers can implement a variety of algorithms to accomplish this. One algorithm is as follows: - First query for a AAAA records. If one or more is found, return it (them) to the application. - If no AAAA records are found, query for "A" records. If one or more is found, return it (them) to the application. - Return failure to the application only if no AAAA or A records are found. The resolver may implement any algorithm so long as it has the affect that, if both AAAA and A records representing the same IPv4-compatible IPv6 address are found, only the addresses contained in the AAAA record is returned to the application. draft-gilligan-ipv6-trans-mech-01.txt [Page 9] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 3. Mechanisms for IPv6/IPv4 Nodes This section discusses mechanisms that apply only to IPv6/IPv4 dual hosts or routers. 3.1 Dual IP Layer The most straighforward way for IPv6 nodes to remain compatible with IPv4-only nodes is to provide a complete IPv4 implementation. IPv6 nodes that provide a complete IPv4 implementation in addition to their IPv6 implementation are called "IPv6/IPv4 nodes." IPv6/IPv4 nodes have the ability to send and receive both IPv4 and IPv6 packets. They can directly interoperate with IPv4 nodes using IPv4 packets, and also directly interoperate with IPv6 nodes using IPv6 packets. 3.2. IPv6-over-IPv4 Tunneling In most deployment scenarios, the IPv6 routing infrastructure will be built up over time. While the IPv6 infrastructure is being deployed, the existing IPv4 routing infrastructure can remain functional, and can be used to carry IPv6 traffic. Tunneling provides a way to utilize an existing IPv4 routing infrastructure to carry IPv6 traffic. IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of IPv4 routing topology by encapsulating them within IPv4 packets. Tunneling can be used in a variety of ways: - Router-to-Router. IPv6/IPv4 routers interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. In this case, the tunnel spans one segment of the end-to-end path that the IPv6 packet takes. - Host-to-Router. IPv6/IPv4 hosts can tunnel IPv6 packets to an intermediary IPv6/IPv4 router that is reachable via an IPv4 infrastructure. This type of tunnel spans the first segment of the packet's end-to-end path. - Host-to-Host. IPv6/IP4 hosts that are interconnected by an IPv4 infrastructure can tunnel IPv6 packets between themselves. In this case, the tunnel spans the entire end-to-end path that the packet takes. - Router-to-Host. IPv6/IPv4 routers can tunnel IPv6 packets to their final destination IPv6/IPv4 host. This tunnel spans only the last segment of the end-to-end path. Tunneling techniques are usually calssified according to the mechanism by which the encapsulating node determines the address of the node at draft-gilligan-ipv6-trans-mech-01.txt [Page 10] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 the end of the tunnel. In the first two tunneling methods listed above -- router-to-router and host-to-router -- the IPv6 packet is being tunneled to a router. The endpoint of this type of tunnel is an intermediary router which must de-capsulate the IPv6 packet and forward it on to its final destination. When tunneling to a router, the endpoint of the tunnel is different from the destination of the packet being tunneled. So the packet being tunneled does not provide the address of the tunnel endpoint. Instead, the tunnel endpoint address must be determined from configuration information on the node performing the tunneling. We use the term "configured tunneling" to describe the type of tunneling where the endpoint is explicitly configured. In the last two tunneling methods -- host-to-host and router-to-host -- the IPv6 packet is tunneled all the way to its final destination. The tunnel endpoint is the node to which the IPv6 packet is addressed. Since the endpoint of the tunnel is the destination of the IPv6 packet, the tunnel endpoint can be determined from the destination IPv6 address of that packet: If that address is an IPv4-compatible address, then the low-order 32-bits hold the IPv4 address of the destination node, and that can be used as the tunnel endpoint address. This technique avoids the need to explicitly configure the tunnel endpoint address. Deriving the tunnel endpoint address from the embedded IPv4 address of the packet's IPv6 address is termed "automatic tunneling". The two tunneling techniques -- automatic and configured -- differ primarily in how they determine the tunnel endpoint address. Most of the underlying mechanisms are the same: - The entry node of the tunnel (the encapsulating node) creates an encapsulating IPv4 header and transmits the encapsulated packet. - The exit node of the tunnel (the decapsulating node) receives the encapsulated packet, removes the IPv4 header, updates the IPv6 header, and processes the received IPv6 packet. - The encapsulating node may need to maintain soft state information for each tunnel recording such parameters as the MTU of the tunnel its path length in order to correctly generate IPv6 ICMP error messages. Since the number of tunnels that any one host or router may be using may grow to be quite large, this state information can be cached so that it can be discarded when no longer used and later recreated. The next section discusses the common mechanisms that apply to both types of tunneling. Subsequent sections discuss how the tunnel endpoint address is determined for automatic and configured tunneling. draft-gilligan-ipv6-trans-mech-01.txt [Page 11] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 3.2.1. Common Tunneling Mechanisms The encapsulation of an IPv6 datagram in IPv4 is shown below: +-------------+ | IPv4 | | Header | +-------------+ +-------------+ | IPv6 | | IPv6 | | Header | | Header | +-------------+ +-------------+ | Transport | | Transport | | Layer | ===> | Layer | | Header | | Header | +-------------+ +-------------+ | | | | ~ Data ~ ~ Data ~ | | | | +-------------+ +-------------+ Encapsulating IPv6 in IPv4 3.2.1.1. Tunnel MTU The encapsulating node must be able to pass an IPv6 datagram of any size over a tunnel. This can be accomplished in one of the following ways: 1) The encapsulating node can perform IPv4 Path MTU Discovery [RFC-1191] on the tunnel. It may do this by setting the Don't Fragment (DF) bit in the IPv4 header of all IPv6-in-IPv4 packets, and using the ICMP "packet too big" messages that are returned to determine the tunnel MTU. The encapsulating node keeps a cache of the tunnel MTU of all active tunnels. If an encapsulated IPv6 datagram would exceed the tunnel MTU, the encapsulating node sends the packet in multiple IPv4 fragments. 2) The encapsulating node may opt not to perform IPv4 Path MTU Discovery on the tunnel. In this case, it must perform IPv4 fragmentation if an encapsulated IPv6 packet would exceed the MTU of the outgoing interface. The Don't Fragment flag is cleared (set to zero) in all IPv6-in-IPv4 packets so that IPv4 routers along the tunnel path may further fragment the packet. If the packet is fragmented, the decapsulating node will reassemble it before decapsulating the IPv6 packet. 3.2.1.2. Hop Limit The IPv4 hops of an IPv6-over-IPv4 tunnel can be accounted for in one of draft-gilligan-ipv6-trans-mech-01.txt [Page 12] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 two ways: 1) Each of the "hops" that an encapsulated IPv6 datagram takes through IPv4 routers can be reflected in the IPv6 hop limit field. For example, if the IPv4 path length of a tunnel is 5 hops, the IPv6 "hop limit" field is decremented by 5 when an IPv6 packet travels through the tunnel. We use the term "multi-hop" to describe tunnels that use this model. 2) The tunnel can be modeled as consuming only one IPv6 hop independent of its IPv4 path length. That is, the IPv6 hop limit is decremented only by 1 when an IPv6 packet traverses the tunnel. We use the term "single-hop" to describe tunnels that use this model. These two models can be used to implement different policies. The multi-hop model can be useful to enforce the scope limitations imposed by the sender of the IPv6 datagram. It also makes the tunnel "traceroute visible"; Network management programs can "see" the internal structure of the tunnel by sending IPv6 packets with hop limits that will "expire" within the tunnel. The single-hop model is uesful if the administrator wishes to hide the IPv4 topology. The multi-hop model can be implemented by having the encapsulating node copy the IPv6 hop limit into the IPv4 TTL field when it composes the encapsulating packet, and having the decapsulating node copy the IPv4 TTL field back into the IPv6 hop limit field. The single-hop model is implemented by having the encapsulating node select the IPv4 TTL independently of the IPv6 hop limit, and the decapsulating node not copying the IPv4 TTL into the the hop limit field. Implementations may provide either model or both. Implementations that provide both models may provide administrators the ability to configure which model is used for each tunnel. If implementations provide configurability, it is important that both ends of the tunnel -- the encapsulating and decapsulating nodes -- are configured to use the same model. If the tunnel endpoints are configured differently, packets could end up with an incorrect IPv6 hop limit. No serious problems would result if the encapsulating node is configured to use the multi-hop model, but the decapsulating node was configured to use the single-hop model. The results are the same as if both ends were draft-gilligan-ipv6-trans-mech-01.txt [Page 13] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 configured to use the single-hop model. However, two failure modes can occur if the encapsulating node is configured to use the single-hop model and the de-capsulating node is configured to use the multi-hop model: - The IPv6 packet exits the tunnel with a larger hop limit than it had when entering the tunnel. This would occur if the amount of IPv4 TTL remaining when the packet reached the decapsulating node was larger than the IPv6 hop count. This failure can be thought of as the IPv6 packet "gaining hop count" when passing through the tunnel. - The number of IPv6 hops "consumed" in passing through the tunnel is more than IPv4 path length of the tunnel. This would occur if the difference between the IPv6 hop limit in the packet and the remaining IPv4 TTL was greater than the IPv4 path length of the tunnel. This failure can be thought of as the IPv6 packet "loosing too much hop count" when passing through the tunnel. Note that in both of these cases, the original IPv6 hop limit is lost. Its value after transiting the tunnel is related only to the IPv4 TTL selected by the encapsulating node, which is not related to the hop limit in the IPv6 packet. Of the two potential failure modes above, the first is more serious since it could cause a packet to "live forever". A routing loop which sent IPv6 packets through such a tunnel would cause an infinite cycle of packets, for example. The second failure mode would cause packets to expire prematurely. The de-capsulating node can implement a simple algorithm to prevent the "gaining hop count" problem. This algorithm does not prevent the second problem. The algorithm is: - If the tunnel is configured to use the "single-hop" model, do not modify the IPv6 hop limit field. - If the tunnel is configured to use the "multi-hop" model, then: - If the IPv4 TTL field is greater than or equal to the IPv6 hop limit field, do not modify the IPv6 hop limit field. - Else, copy the IPv4 TTL field into the IPv6 hop limit field. It is an open issue whether the "loosing too much hop count" problem is serious enough to require that a solution be developed. draft-gilligan-ipv6-trans-mech-01.txt [Page 14] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 Note that the decision about whether to copy the IPv4 TTL field into the hop limit field does not affect the requirement to decrement the hop limit field; If the encapsulating or decapsulating node is an IPv6 router that forwards the packet, it must decrement the IPv6 hop count. Note also that the hop limit problem affects only configured tunnels. Automatic tunnels terminate at the end node, where the packet is consumed, not forwarded, so the remaining hop limit is irrelevant. 3.2.1.3. Tracking the Tunnel State In addition to limiting packets' scope, the multi-hop tunneling model allows the IPv4 routers along the path to be "traceroute visible." This means that a traceroute program running on an IPv6 host will report all the routers internal to the tunnel. Making a tunnel traceroute visible is implemented by having the encapsulating node maintain "soft state" information about the tunnel, which includes the IPv4 path length of the tunnel. Whenever the encapsulating node receives an IPv6 packet that would traverse the tunnel, but the IPv6 hop limit is less than the path length of the tunnel, it returns an IPv6 ICMP "time exceeded in transit" message to the sender of that packet. Soft state can also be kept about other characteristics of the tunnel, and then used to accurately return IPv6 ICMP errors back to the originators of datagrams that pass through the tunnel. The soft state information for a tunnel is constructed based on the IPv4 ICMP error messages that are received from IPv4 routers interior to the tunnel. Tunnel state information is associated with the IPv4 address of the endpoint of the tunnel and can include: - The MTU of the Tunnel. - Reachability of the endpiong of the tunnel. - If the endpoint of the tunnel is unreachable, the IPv4 address of the router reporting unreachability. - Path length of the tunnel (number of IPv4 hops to the endpoint). - For each TTL 't' between 1 and the path length of the tunnel, the IPv4 address of the router that was last known to be 't' hops into the tunnel. The tunnel state does not have to be allocated until an ICMP error is received. In the absence of tunnel state, the tunnel MTU can be assumed to be the MTU of the outgoing interface, the path length one hop and the endpoint being reachable. draft-gilligan-ipv6-trans-mech-01.txt [Page 15] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 When an IPv6 datagram is encapsulated, the encapsulating node consults the tunnel state to check if the packet is likely to generate an ICMP error from a router interior to the tunnel. In such a case (e.g. packet size is greater than the tunnel MTU, or the hop limit is less than the path limit of the tunnel), and the node is a router, it generates the appropriate IPv6 ICMP error. If the encapsulating node is a host, it passes an error indication up to the transport layer. After generating the error indication, it forwards the packet into the tunnel. Any IPv4 ICMP error caused by the tunneled packet will return to the encapsulating node, and is used to refresh the tunnel state. When the encapsulating node receives an IPv4 ICMP error where the "offending packet" is IPv4 with the IP protocol field is 41, it updates the tunnel state associated with the IPv4 destination in the "offending packet". The update depends on the type of ICMP error: - Host or network unreachable: Mark the tunnel endpoint as unreachable and record the source of the ICMP error as the source of unreachability. - Time exceeded in transit: The TTL "consumed" before reaching the router that sent the time exceeded message is extracted from the IPv6 hop limit field in the "offending packet" (the IPv6 hop limit field is in the first 8 bytes of the IPv6 header thus it will be returned in the ICMP packet). Compute the updated tunnel path length as the maximum of the currently recorded path length and the extracted IPv6 hop limit. Record the source of the ICMP error as the router at 'IPv6 hop limit' hops into the tunnel. - "Packet too big": If the ICMP packet contains the MTU (see "Path MTU Discovery" [RFC-1191]) update the tunnel MTU to be that value. If the ICMP packet does not contain the MTU use the IPv4 "total length" field in the "offending packet" and the recommended plateaus in RFC-1191 to compute the new MTU for the tunnel. Note that this can either increment or decrement the recorded tunnel MTU. - For all other ICMP errors log a network management event. When the encapsulating node forwards a packet into the tunnel it performs the following checks against the tunnel state: - If the tunnel endpoint is unreachable, it generates a IPv6 ICMP "network unreachable" message with the source address being the router that reported the unreachability. The IPv4 address of that router, which should be recorded in the tunnel state information, is mapped into an IPv6 address by prepending it with the 96-bit all-zeros prefix (0:0:0:0:0:0). The resulting draft-gilligan-ipv6-trans-mech-01.txt [Page 16] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 IPv6 address is used as the source address of the IPv6 ICMP error message. - If the hop limit is less than the recorded tunnel TTL, it generates an IPv6 ICMP "time exceeded in transit" message with the source address being the address of the IPv4 router that is 'hop limit' hops into the tunnel. As in the previous case, this router's address is stored in the tunnel state information and may be mapped into an IPv6 address for use as the source address of the IPv6 ICMP error message. If there is no router address recorded for the specified hop limit, the router generates an ICMP time exceeded with a source address of all zeros (0:0:0:0:0:0:0:0). - If the MTU exceeds the recorded tunnel MTU it generates a IPv6 ICMP "packet too big" using its own IPv6 address as the source, and setting the returned MTU to the recorded tunnel MTU minus the size of the IPv4 header (20 bytes). (The 20 byte adjustment is needed since the packets will "expand" by 20 bytes when being encapsulated.) In all of these cases, the datagram is also forwarded into the tunnel. The mechanism described so far does not detect when an error condition in the tunnel is lifted (e.g. the tunnel endpoint becomes reachable or when the tunnel path length decreases). The simple solution to detecting such "improvements" is to periodically discard the recorded tunnel state. More elaborate schemes are possible, such as counting the number of 1) datagrams that should have generated a certain ICMP error and 2) the actual number of such ICMP errors received, and discarding the state when the ratio between them exceeds some value. 3.2.1.4. IPv4 Header Construction When encapsulating a IPv6 packet in an IPv4 datagram, the IPv4 header fields are set as follows: Version: 4 IP Header Length in 32-bit words: 5 (There are no IPv4 options in the encapsulating header.) Type of Service: draft-gilligan-ipv6-trans-mech-01.txt [Page 17] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 0 Total Length: Payload length from IPv6 header plus length of IPv6 and IPv4 headers (i.e. a constant 60 bytes). Identification: Generated uniquely as for any IPv4 packet transmitted by the system. Flags: Set the Don't Fragment (DF) flag if performing IPv4 Path MTU Discovery; Clear the DF flag otherwise. Set the More Fragments (MF) bit as necessary if fragmenting. Fragment offset: Set as necessary if fragmenting. Time to Live: If tunnel is configured as multi-hop: Copied from the IPv6 hop limit field. If tunnel is configured as single-hop: Set to pre-configured value. Protocol: 41 (Assigned payload type number for IPv6) Header Checksum: Calculate the checksum of the IPv4 header. Source Address: IPv4 address of outgoing interface of the encapsulating node. Destination Address: draft-gilligan-ipv6-trans-mech-01.txt [Page 18] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 IPv4 address of of tunnel endpoint. Any IPv6 options are preserved in the packet (after the IPv6 header). 3.2.1.5 Decapsulating IPv6-in-IPv4 Packets When an IPv6/IPv4 host or a router receives an IPv4 datagram destined to one of its IPv4 address with the protocol field set to 41 it decapsulates the IPv6 datagram and submits it to the IPv6 layer code. The decapsulation is shown below: +-------------+ | IPv4 | | Header | +-------------+ +-------------+ | IPv6 | | IPv6 | | Header | | Header | +-------------+ +-------------+ | Transport | | Transport | | Layer | ===> | Layer | | Header | | Header | +-------------+ +-------------+ | | | | ~ Data ~ ~ Data ~ | | | | +-------------+ +-------------+ Decapsulating IPv6 from IPv4 When decapsulating the IPv6-in-IPv4 packet only the hop limit field of the IPv6 header is modified: If tunnel is configured as single-hop: Do not modify the IPv6 hop limit field. If tunnel is configured as multi-hop: If the IPv4 TTL field is greater than or equal to the IPv6 hop limit field, do not modify the IPv6 hop limit field. Else, copy the IPv4 TTL field into the IPv6 hop limit field. Then the encapsulating IPv4 header is discarded. Note that the decapsulating node performs IPv4 reassembly before draft-gilligan-ipv6-trans-mech-01.txt [Page 19] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 decapsulating the IPv6 packet. So all IPv6 options are preserved even if the encapsulated IPv4 packet is fragmented. After the IPv6 packet is decapsulated, it is treated the same as any received IPv6 packet. 3.2.2. Configured Tunneling In configured tunneling, the tunnel endpoint address is determined from configuration information in the encapsulating node. For each tunnel, the encapsulating node must store the tunnel endpoint address. When an IPv6 packet is transmitted over a tunnel, the tunnel endpoint address configured for that tunnel is used as the destination address for the encapsulating IPv4 header. The determination of which packets to tunnel is usually made by routing information on the encapsulating node. A routing table entry directs IPv6 packets whose destination address matches a particular prefix to be sent via the tunnel. 3.2.3. Automatic Tunneling In automatic tunneling, the tunnel endpoint address is determined from the packet being tunneled. The destination IPv6 address in the packet must be an IPv4-compatible address. If it is, the IPv4 address component of that address -- the low-order 32-bits -- are extracted and used as the tunnel endpoint address. IPv6 packets that are not addressed to an IPv4-compatible address can not be tunneled using automatic tunneling. The determination of which packets to automatically tunnel can be made by routing table information. Alternatively, an encapsulating node can implement the algorithm in the next section. This algorithm is designed to have the property that all elegible IPv6 packets to off-link destinations are automatically tunneled when there are no IPv6 routers present on the link, but that automatic tunneling stops when IPv6 routers are deployed. 3.2.3.1 Automatic Tunneling Sending Algorithm This section presents an algorithm that nodes can use to implement automatic tunneling. It is a general-purpose sending algorithm that determines which packet format to use -- IPv4, IPv6 or tunneled -- based on a number of parameters. The algorithm has the following properties: - Sends "raw" IPv4 packets when interoperating with an IPv4-only node on the same link. draft-gilligan-ipv6-trans-mech-01.txt [Page 20] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 - Sends "raw" IPv6 packets when interoperating with an IPv6 node on the same link. - Only uses automatic tunneling when the destination is located off-link and there are no IPv6 routers present. The algorithm is as follows: 1) If the address of the end node is an IPv4 address or an IPv4-mapped IPv6 address (i.e. bears the prefix 0:0:0:0:0:0), then: 1.1) If the destination is located on the attached link, then send an IPv4 packet. The IPv4 destination address is the IPv4 address of the end node (low-order 32-bits of the end node's IPv4-mapped IPv6 address). 1.2) If the destination is located off-link, then; 1.2.1) If there is an IPv4 router on link, then send an IPv4 format packet. The IPv4 destination address is the IPv4 address of the end node. The datalink address is the datalink address of the IPv4 router. 1.2.2) Else, if there is an IPv6 router on link, then send an IPv6 format packet. The IPv6 address is the IPv4-mapped IPv6 address of the end node (its IPv4 address prefixed by 0:0:0:0:0:0). The datalink address is the datalink address of the IPv6 router. 1.2.3) Else, the destination is treated as "unreachable" because it is located off link and there are no on-link routers. 2) If the address of the end node is an IPv4-compatible IPv6 address (i.e. bears the prefix 0:0:0:0:0:ffff), then: 2.1) If the destination is located on the attached link, then send an IPv6 format packet. The IPv6 destination address is the IPv6 address of the end node. The datalink address is the datalink address of the end node. 2.2) If the destination is located off-link, then: draft-gilligan-ipv6-trans-mech-01.txt [Page 21] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 2.2.1) If there is an IPv6 router on the attached link, then send an IPv6 format packet. The IPv6 destination address is the IPv6 address of the end node. The datalink address is the datalink address of the IPv6 router. 2.2.2) Else, if there is an IPv4 router on the attached link, then send an IPv6 packet encapsulated in IPv4. The IPv6 destination address is the address of the end node. The IPv4 destination address is the low-order 32-bits of the end node's address. The datalink address is the datalink address of the IPv4 router. 2.2.3) Else, the destination is treated as "unreachable" because it is located off-link and there are no on-link routers. 3) If the address of the end node is an IPv6-only address, then: 3.1) If the destination is located on the attached link, then send an IPv6 format packet. The IPv6 destination address is the IPv6 address of the end node. The datalink address is the datalink address of the end node. 3.2) If the destination is located off-link, then: 2.2.1) If there is an IPv6 router on the attached link, then send an IPv6 format packet. The IPv6 destination address is the IPv6 address of the end node. The datalink address is the datalink address of the IPv6 router. 2.2.3) Else, the destination is treated as "unreachable" because it is located off-link and there are no on-link IPv6 routers. A summary of these sending rules are given in the table below: draft-gilligan-ipv6-trans-mech-01.txt [Page 22] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 End | End | IPv4 | IPv6 | packet | | | Node | Node | Router | Router | Format | IPv6 | IPv4 | DLink Address | On | On | On | To | Dest | Dest | Dest Type | Link? | Link? | Link? | Send | Addr | Addr | Addr ------------+---------+---------+---------+--------+------+------+------ IPv4 or | | | | | | | IPv4-mapped | Yes | N/A | N/A | IPv4 | N/A | E4 | EL ------------+---------+---------+---------+--------+------+------+------ IPv4 or | | | | | | | IPv4-mapped | No | Yes | N/A | IPv4 | N/A | E4 | RL ------------+---------+---------+---------+--------+------+------+------ IPv4 or | | | | | | | IPv4-mapped | No | No | Yes | IPv6 | E6 | N/A | RL ------------+---------+---------+---------+--------+------+------+------ IPv4-compat | Yes | N/A | N/A | IPv6 | E6 | N/A | EL ------------+---------+---------+---------+--------+------+------+------ IPv4-compat | No | N/A | Yes | IPv6 | E6 | N/A | RL ------------+---------+---------+---------+--------+------+------+------ IPv4-compat | No | Yes | No | IPv6/4 | E6 | E4 | RL ------------+---------+---------+---------+--------+------+------+------ IPv6-only | Yes | N/A | N/A | IPv6 | E6 | N/A | EL ------------+---------+---------+---------+--------+------+------+------ IPv6-only | No | N/A | Yes | IPv6 | E6 | N/A | RL ------------+---------+---------+---------+--------+------+------+------ Key to Abbreviations -------------------- N/A: Not applicable or does not matter. E6: IPv6 address of end node. E4: IPv4 address of end node (low-order 32-bits of IPv4-mapped or IPv4-compatible address). EL: Datalink address of end node. R6: IPv6 address of router. R4: IPv4 address of router. RL: Datalink address of router. IPv4: IPv4 packet format. IPv6: IPv6 packet format. IPv6/4: IPv6 encapsulated in IPv4 packet format. 3.2.3.2. Host On/Off Link Determination Part of the process of determining what packet format to use includes determining whether a destination is located on an attached link or not. IPv4 and IPv6 employ different mechanisms. IPv4 uses an algorithm in which the destination address and the interface address are both logically ANDed with the netmask of the interface and then compared. If the resulting two values match, then the destination is located on-link. This algorithm is discussed in more detail in Section 3.3.1.1 of the draft-gilligan-ipv6-trans-mech-01.txt [Page 23] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 document "Requirements for Internet Hosts -- Communications Layers" [RFC1122]. IPv6 uses the neighbor discovery algorithm described in "IPv6 Neighbor Discovery -- Processing" [IPv6-NABOR]. IPv6/IPv4 nodes need to use both methods: - If a destination is represented by an IPv4 address or an IPv4-mapped IPv6 address (prefix 0:0:0:0:0:0), then the on/off link determination is made by comparison with the netmask, as described in RFC 1122 section 3.3.1.1. If the destination is an IPv4-mapped address, the algorithm uses only the low-order 32-bits of that address (the IPv4 address part). - If a destination is represented by an IP4-compatible IPv6 address (prefix 0:0:0:0:0:ffff), and IPv6 router advertisements have been heard, then the on/off link determination is made using the IPv6 system discovery mechanism. If no IPv6 router advertisements have been heard, then the decision is made using the IPv4 netmask comparison algorithm using the low-order 32-bits (IPv4 address part) of the destination address. - If the destination is represented by an IPv6-only address (prefix other than 0:0:0:0:0:0 or 0:0:0:0:0:ffff), the on/off link determination is made using the IPv6 system discovery mechanism. 3.3. Address Configuration Because they provide a complete IPv6 implementation, IPv6/IPv4 hosts should implement the IPv6 address configuration mechanisms specified in the IPv6 Address Configuration specification [IPv6-ACONF]. The address configuration protocol may provide an IPv6/IPv4 host with an IPv4-compatible or an IPv6-only address. There is also another mode of address configuration available to IPv6/IPv4 nodes: They may use an IPv4-based address configuration protocol to acquire an IPv4 address, then "map" that address into an IPv4-compatible IPv6 address. This mode of configuration allows IPv6/IPv4 nodes to "leverage" the installed base of IPv4 address configuration servers. It technique can be particularly useful in environments where IPv6 routers and address configuration servers have not yet been deployed. The specific algorithm for acquiring an IPv4-compatible address using IPv4-based address configuration protocols is as follows: 1) The IPv6/IPv4 host uses standard IPv4 mechanisms protocols to acquire its own IPv4 address. These include: draft-gilligan-ipv6-trans-mech-01.txt [Page 24] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 - Dynamic Host Configuration Protocol [DHCP] - Bootp [BOOTP] - Reverse Address Resolution Protocol [RARP] - Manual configuration - Any other mechanism which accurately yields the host's own IPv4 address 2) The host prepends the 96-bit prefix 0:0:0:0:0:ffff to the 32-bit IPv4 address that it acquired in step (1). The result is an IPv4-compatible IPv6 address with the host's own IPv4-address embedded in the low-order 32-bits. 3) The host uses the resulting IPv6 address as its own IPv6 address. 3.4. Source Address Selection IPv6/IPv4 nodes may be configured with both IPv6-only and IPv4-compatible addresses, and may even have one or more of both types of address configured on a single interface. When interoperating with an IPv4-only node, only an IPv4-compatible address may be used as a source address; an IPv6-only address can not be used used becuase it does not hold an embedded IPv4 address, and thus can not be represented by the IPv4-only node. An IPv6/IPv4 node can use the following source address selection rules to guarantee that the correct type of source address is always used: - When originating an IPv4 datagram, an IPv6/IPv4 node must use the low-order 32-bits of one of its own IPv4-compatible addresses as the source IPv4 address. If the originating node is configured with no IPv4-compatible addresses, it treats the destination as "unreachable". - When originating an IPv6 datagram to a destination represented by an IPv4-mapped address, an IPv6/IPv4 node must use one of its own IPv4-compatible addresses as the source IPv6 address. If the originating node is configured with no IPv4-compatible addresses, it treats the destination as "unreachable". Any of the host's IPv6 addresses may be used as the source addresses when originating datagrams to other IPv6 nodes. If the host is configured with both IPv4-compatible and IPv6-only addresses, either may be used. draft-gilligan-ipv6-trans-mech-01.txt [Page 25] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 4. Mechanims for IPv6-only Nodes. This section discusses the mechanisms that are used by IPv6-only hosts and routers. Few special transition mechanisms are needed IPv6-only nodes. IPv6-only nodes can interoperate with IPv4-only nodes via a header translator. The header translation mechanism is designed to allow standard IPv6-only nodes to interoperate with IPv4-only nodes. Header translation is discussed in more detail in the companion specification "IPv6 Transition Mechanisms for Header Translating Routers" [TRANS-XLATE]. 4.1. Sending Rules No special sending rules are required for IPv6-only nodes. Since they are not capable of sending IPv4 or IPv6-in-IPv4 format packets, all packets originated by IPv6-only nodes are IPv6 datagrams. IPv6-only nodes datagrams addressed to IPv4-mapped, IPv4-compatible and IPv6-only addresses the same way. All are sent according to the algorithms given in the IPv6 and neighbor discovery specifications ([IPv6] and [IPv6-NBOR]). On a correctly configured IPv6-only node, no IPv4-mapped address will ever appear to be on a locally attached link. So, when originating a packet destined to an IPv4-mapped addresses, an IPv6 node wil alway send the packet to an IPv6 router. The packet will be translated to IPv4 before being delivered to the destination IPv4 node. 4.2. Source Address Selection Like IPv6/IPv4 nodes, IPv6-only nodes may be configured with both IPv6-only and IPv4-compatible addresses. But they may use only IPv4-compatible addresses when interoperating with IPv4-only nodes. IPv6-only addresses can not be used because they can not be translated into IPv4 addresses. IPv6-only nodes can use the following source address selection rules to guarantee that the correct type of source address is always used: - When originating an IPv6 datagram to a destination represented by an IPv4-mapped addresses, an IPv6-only node must use one of its own IPv4-compatible addresses as the source IPv6 address. If the originating node is configured with no IPv4-compatible addresses, it treats the destination as "unreachable". Any of the host's IPv6 addresses may be used as the source addresses when originating datagrams to other IPv6 nodes. If the host is configured with both IPv4-compatible and IPv6-only addresses, either may be used. draft-gilligan-ipv6-trans-mech-01.txt [Page 26] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 5. Author's Address Robert E. Gilligan Sun Microsystems, Inc. 2550 Garcia Ave. Mailstop UMTV 05-44 Mountain View, California 94043 415-336-1012 (voice) 415-336-6015 (fax) Bob.Gilligan@Eng.Sun.COM Erik Nordmark Sun Microsystems, Inc. 2550 Garcia Ave. Mailstop UMTV 05-44 Mountain View, California 94043 415-336-2788 (voice) 415-336-6015 (fax) Erik.Nordmark@Eng.Sun.COM 6. References [BOOTP] W. Croft, J. Gilmore. Bootstrap Protocol. RFC 951. September 1985. [DHCP] R. Droms. Dynamic Host Configuration Protocol. RFC 1541. October 1993. [IPv6] R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. Internet Draft . October 1994. [IPv6-ACONF] IPv6 Address Configuration. Internet Draft to be written. [IPv6-ADDR] R. Hinden. IP Next Generation Addressing Architecture. Internet Draft . October 1994. [IPv6-DISC] W. A. Simpson. IPv6 Neighbor Discovery -- ICMP Message Formats. Internet Draft draft-gilligan-ipv6-trans-mech-01.txt [Page 27] INTERNET-DRAFT IPv6 Transition Mechanisms January 1995 . September 1994. [IPv6-DNS] S. Thompson, C. Huitema. DNS Extensions to support IP version 6. Internet Draft . October 1994. [IPv6-NBOR] W. A. Simpson. IPv6 Neighbor Discovery -- Processing. Internet Draft . October 1994. [TRANS-XLATE] IPv6 Transition Mechanisms for Header Translating Routers. Internet Draft to be written. [TRANS-PLAN] IPv6 Transition Plan. Internet Draft to be written. [RFC-1191] J. Mogul, S. Deering. Path MTU Discovery. RFC 1191. November 1990. [RARP] R. Finlayson, T. Mann, J. Mogul, M. Theimer. Reverse Address Resolution Protocol. RFC 903. June 1984. [RFC-1123] R. Braden. Requirements for Internet Hosts - Application And Support. RFC 1123. October 1989. draft-gilligan-ipv6-trans-mech-01.txt [Page 28]