Internet Engineering Task Force Robert E. Gilligan INTERNET-DRAFT Erik Nordmark Sun Microsystems, Inc. November 18, 1994 Transition Mechanisms for IPv6 Hosts and Routers Abstract This document specifies the required and optional mechanisms that IPv6 hosts and routers 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 May 11, 1995. draft-gilligan-ipv6-trans-mech-00.txt [Page 1] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 1. Introduction This specification defines the mechanisms that are to 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. Some of the mechanisms discussed here are optional, while others are mandatory. We use the terms MUST, SHOULD, MAY, SHOULD NOT, and MUST NOT to specify the level of support required of each feature. The document is written primarily as descriptive text. Some specific requirements are given in indented paragraphs offset with a star character, like this: * This spec MUST have lots of requirements. Other requirements are included in the body of the document. The companion document "Simple Internet Transition Overview" [TRANS-OVER] gives an introduction and overall summary of the transition mechanisms and how they are expected to operate. It provides important background information that is useful for understanding this specification. IPv6 implementors should read the overview document before reading this document. 1.1. Applicability The requirements in this document apply to IPv6 hosts and routers that need to interoperate with IPv4 hosts and routers. 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 not adhere to these specifications. This document specifies the mechanisms to be implemented by IPv6/IPv4 hosts and routers, as well as IPv6-only hosts and routers. It does not specify the mechanisms that IPv6/IPv4 header translating routers must implement. That information is covered in the companion document "Transition Mechanisms for Header Translating Routers" [TRANS-XLATE]. 1.2. Terminology This document employs the terminology defined section 2 in the Transition Overview document [TRANS-OVER] and in the IPv6 specification [IPv6]. Readers should be familiar with this draft-gilligan-ipv6-trans-mech-00.txt [Page 2] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 terminology before reading this document. 1.3. Structure of this Document The specifications are organized into three sections: - Section 2 lists the requirements that apply to both IPv6/IPv4 dual nodes, and IPv6-only nodes. - Section 3 lists the requirements that apply only to IPv6/IPv4 dual nodes. - Section 4 lists the requirements that apply only to IPv6-only nodes. Thus someone implementing an IPv6/IPv4 host or router would need to comply with sections 2 and 3, while someone implementing an IPv6-only node would need to comply with sections 2 and 4. draft-gilligan-ipv6-trans-mech-00.txt [Page 3] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 2. Common Requirements This section details the requirements that are common to IPv6/IPv4 and IPv6-only hosts and routers. 2.1. General Requirements The transition is designed so that IPv6 hosts and routers may be implemented either as IPv6/IPv4 dual nodes, or as IPv6-only nodes. IPv6/IPv4 nodes can directly interoperate with IPv4-only nodes, while IPv6-only nodes require a translator. Since translators are complex to set up and manage, they are not expected to be deployed during early transition period. Thus IPv6-only nodes will not be able to interoperate with IPv4-only nodes during that period. Therefore: * During the first phase of transition, IPv6 hosts and routers SHOULD be IPv6/IPv4 dual nodes. We don't know how long the first transition phase will last. For planning purposes, implementors should expect that it will last for at least five years after the date of this document was written. 2.2. Addressing Requirements IPv6 nodes use a special type of address, termed an "IPv4-compatible" IPv6 address, when interoperating with IPv4-only nodes. An IPv4-compatible 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. Another type of address, termed an "IPv6-only" address, is used by IPv6 nodes exclusively for interoperating with other IPv6 nodes. An IPv6-only address can not be used when interoperating with an IPv4-only node. Since IPv6/IPv4 and IPv6-only nodes must be capable of operating in environments where they interoperate with IPv4 nodes, as well as environments where they interoperate with IPv6 nodes, they must be configurable with both types of address: * IPv6/IPv4 and IPv6-only nodes MUST be capable of being configured with an IPv4-compatible IPv6 address. * IPv6/IPv4 and IPv6-only nodes MUST be capable of being configured with an IPv6-only IPv6 address. In addition, one feature of IPv6 is that nodes must be configurable with multiple addresses per interfaces. For maximum flexibility, these addresses should be of either type: draft-gilligan-ipv6-trans-mech-00.txt [Page 4] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 * IPv6/IPv4 and IPv6-only nodes SHOULD be capable of being configured with multiple IPv4-compatible and multiple IPv6-only addresses on the same interface at the same time. 2.3. DNS Requirements 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. Support for this record type is an essential part of the transition, and can not be left out of an implementation: * IPv6/IPv4 and IPv6-only hosts MUST implement a DNS resolver capable of handling the AAAA resource record type. 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 choose to provide a host table mechanism: * IPv6 hosts MAY implement a local IPv6 host table mechanism in addition to the 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.3.1. Handling "A" Records Even though the addresses of IPv4-only nodes can be represented as IPv4-mapped IPv6 addresses, and thus could be stored in DNS AAAA address records, this is not done. In order to simplify the administration of the DNS, only "A" type address records are listed in the DNS for IPv4-only nodes. Morever, even if IPv4-mapped IPv6 addresses were stored in the DNS, IPv6 nodes would need to be able to interoperate with IPv4 hosts whose addresses are stored in DNS servers that have not been upgraded. Therefore, IPv6 hosts must continue to support "A" records: * IPv6/IPv4 and IPv6-only hosts MUST implement a DNS resolver capable of handling the A resource record type. The specific manner by which an IPv6 host handles A records is up to each implementation. Two approaches that will work are: 1) The resolver library can take the IPv4 address given in the A draft-gilligan-ipv6-trans-mech-00.txt [Page 5] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 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 according to the sending rules given in sections 3.3 and 4.2. 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.3.2. 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. Thus, there are typically two resource records associated with the domain name of an IPv6 host that has been assigned an IPv4-compatible address: 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. The AAAA record is provided to satisfy DNS queries made by IPv6 hosts, and the A record is provided for queries by IPv4 hosts. DNS resolver libraries on IPv6 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, both should not be returned to the application, since doing so would give the application two versions of the same address. Instead, the resolver library should return only the AAAA record address to the 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 draft-gilligan-ipv6-trans-mech-00.txt [Page 6] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 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: * The DNS resolver library MUST implement an algorithm that prevents A record addresses from being returned to the application when IPv4-compatible IPv6 address were also received. draft-gilligan-ipv6-trans-mech-00.txt [Page 7] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 3. IPv6/IPv4 Node Requirements This section covers the requirements of IPv6/IPv4 dual hosts and routers. 3.1 General Requirements IPv6/IPv4 nodes implement both the old and new versions of the Internet Protocol. Providing both protocols allows these nodes to directly interoperate with both IPv4 and IPv6 nodes. The important aspect of this for transition is that IPv6/IPv4 nodes fully interoperate with the large installed base of IPv4 nodes. Thus: * IPv6/IPv4 nodes MUST directly interoperate with IPv4 nodes. It is important that the implementations of both protocols be complete, so that interoperation with both IPv4 and IPv6 nodes is assured: * IPv6/IPv4 nodes MUST provide a complete IPv4 implementation and MUST provide a complete IPv6 implementation. 3.2. IPv6-over-IPv4 Tunneling IPv6/IPv4 hosts and routers tunnel IPv6 datagrams over regions of IPv4 routing topology by encapsulating them within IPv4 packets. Two types of tunneling are used: "Automatic tunnels" and "Configured tunnels". Automatic tunnels are used to deliver IPv6 datagrams to their final end destination. In automatic tunneling, the IPv6 packet is encapsulated within an IPv4 header that is addressed to the final destination IPv6 node. The "tunnel endpoint" address (the destination address of the encapsulating IPv4 header) is taken from the embedded IPv4 address in the destination address of the IPv6 header. In most cases, the packet is carried via IPv4 routing all the way to the end node, which de-capsulates the IPv6 packet and "consumes" it. The term "automatic" is given to this type of tunneling because the IPv4 tunnel endpoint address is automatically determined from the destination address of the IPv6 packet; No other configuration information is necessary. Configured tunnels are used to deliver IPv6 datagrams to an intermediary IPv6 router. In configured tunneling, the IPv6 packet is encapsulated in an IPv4 header that is address to an intermediary IPv6/IPv4 router. The tunnel endpoint address is the IPv4 address of that router. The packet is carried by IPv4 routing to this router, which de-capsulates the IPv6 packet. That IPv6 router then routes the packet based on its IPv6 destination address and forwards it on toward its final destination. The term "configured" is used to describe this type of draft-gilligan-ipv6-trans-mech-00.txt [Page 8] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 tunneling because the IPv4 tunnel endpoint address is determined by external configuration information; It can not be determined from the packet being tunneled. The same underlying mechanisms are used for both types of tunneling. These mechanisms consists of: - The entry node of the tunnel (the encapsulating node) creates an encapsulating IPv4 header. - The exit node of the tunnel (the decapsulating node) removes the IPv4 header and updates the IPv6 header. - The encapsulating node maintains soft state for each tunnel in order to generate IPv6 ICMP errors. IPv6/IPv4 hosts and routers may need to keep state information about the tunnels they are using, and the number of tunnels any one host or router may be using may grow to be quite large. Therefore the tunnel state information should be cached so that it can be discarded when no longer used and later recreated. 3.2.1. General Tunneling Requirements * IPv6/IPv4 hosts and routers MUST be able to perform automatic tunneling. * IPv6/IPv4 hosts and routers SHOULD be able to perform configured tunneling. * IPv6/IPv4 hosts and routers MUST be able to perform de-capsulation of IPv6-in-IPv4 packets. 3.2.2. Detailed Tunneling Requirements The encapsulation of an IPv6 datagram in IPv4 is shown below: draft-gilligan-ipv6-trans-mech-00.txt [Page 9] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 +-------------+ | IPv4 | | Header | +-------------+ +-------------+ | IPv6 | | IPv6 | | Header | | Header | +-------------+ +-------------+ | Transport | | Transport | | Layer | ===> | Layer | | Header | | Header | +-------------+ +-------------+ | | | | ~ Data ~ ~ Data ~ | | | | +-------------+ +-------------+ Encapsulating IPv6 in IPv4 3.2.2.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.2.2. Hop Limit Each of the "hops" that an encapsulated IPv6 datagram takes through IPv4 routers must be reflected in the IPv6 hop limit field. This is necessary so that scope limitations imposed by the sender of the IPv6 datagram can be enforced. draft-gilligan-ipv6-trans-mech-00.txt [Page 10] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 To accomplish this, the encapsulating node MUST copy the the IPv6 hop limit field into the IPv4 TTL field. The decapsulating node MUST copy the IPv4 TTL field into the IPv6 hop limit field. In addition, if the encapsulating node is an IPv6 router forwarding the packet, it MUST decrement the IPv6 hop count. 3.2.2.3. Tracking the Tunnel State In addition to limiting packets' scope, reflecting the "hops" taken through a tunnel in the IPv6 hop limit field 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 accomplished by having the encapsulating node maintain "soft state" about the number of IPv4 hops there are in the tunnel, and returning an ICMP "time exceeded" messages a packet would "expire" within the tunnel. Soft state can also be kept about other characteristics of the tunnel, and then used to accurately return ICMP errors back to the originators of datagrams that pass through the tunnel. Since it is complex to implement and only used for generating accurate ICMP error indications, maintaining tunnel state is not mandatory: * IPv6/IPv4 nodes SHOULD implement a mechanism to track the state of the tunnel. The soft state information for a tunnel is based on the ICMP errors 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 consists of: - Tunnel MTU. - Path length of the tunnel (number of hops). - 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. - Reachability of the end of the tunnel. - The IPv4 address of the router reporting unreachability. 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 draft-gilligan-ipv6-trans-mech-00.txt [Page 11] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 endpoint being reachable. 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 are used to refresh the tunnel state. When the encapsulator receives an IPv4 ICMP error where the "offending packet" is IPv4 with the IP protocol field being 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 draft-gilligan-ipv6-trans-mech-00.txt [Page 12] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 information, is mapped into an IPv6 address by prepending it with a 96-bit all-zeros prefix (0:0:0:0:0:0). The resulting 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.2.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.) draft-gilligan-ipv6-trans-mech-00.txt [Page 13] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 Type of Service: 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 host function in 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: Copied from the IPv6 hop limit field. 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: IPv4 address of of tunnel endpoint. Any IPv6 options are preserved in the packet (after the IPv6 header). draft-gilligan-ipv6-trans-mech-00.txt [Page 14] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 3.2.2.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 MUST decapsulate the IPv6 datagram and submit 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 one field in the IPv6 header is modified: Hop Limit: TTL value copied from the encapsulating IPv4 header. Then the encapsulating IPv4 header is discarded. Note that the decapsulating node performs IPv4 reassembly before 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.3. Packet Format Sending Algorithms IPv6/IPv4 nodes need to directly interoperate with both IPv4 and IPv6 nodes, and be able to tunnel IPv6 traffic over IPv4. This means that they must be capable of sending datagrams with three different header formats: draft-gilligan-ipv6-trans-mech-00.txt [Page 15] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 - IPv4 - IPv6 - IPv6 encapsulated within IPv4 The determination of which header format to use in which circumstances is termed the "sending rules". These rules were designed with a few general objectives in mind: 1) The sender should formulate a datagram in a format (IPv4 or IPv6) that the recipient can accept. By generating the correct packet at the sender, the packet will not have to be translated before it is delivered to the final destination. 2) The sender should use an IPv6 format in the case where the recipient can accept both IPv4 and IPv6. This will cause IPv6 to be used as early as possible in the transition. 3) The sender should use the "raw" (un-encapsulated) IPv4 or IPv6 packet format when the recipient is located on the same subnet as the sender. Encapsulation is never necessary when the destination is located on the same subnet. 4) Automatic tunneling (IPv6 encapsulated in IPv4 carried all the way to the end destination) should only be used if it is not possible to send IPv6 format packets. 5) Nodes should not use configured tunneling unless explicitly configured to do so. The administrative complexity of configured tunneling is high, so it should be avoided if possible. The sending rules take into account a number of things: - What packet format (IPv4 or IPv6) the intended recipient is capable of accepting. - Whether the destination is located on-subnet or off-subnet. - What type of packet the next hop router (if there is one) can accept. 3.3.1. Default Sending Rules The default sending rules for IPv6/IPv4 hosts are: 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: draft-gilligan-ipv6-trans-mech-00.txt [Page 16] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 1.1) If the destination is located on the attached subnet, 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 subnet, then; 1.2.1) If there is an IPv4 router on subnet, 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 subnet, 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 subnet and there are no on subnet 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 subnet, 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 subnet, then: 2.2.1) If there is an IPv6 router on the attached subnet, 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 subnet, then send an IPv6 packet encapsulated in IPv4. The IPv6 destination address is 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. draft-gilligan-ipv6-trans-mech-00.txt [Page 17] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 2.2.3) Else, the destination is treated as "unreachable" because it is located off-subnet and there are no on-subnet 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 subnet, 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 subnet, then: 2.2.1) If there is an IPv6 router on the attached subnet, 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-subnet and there are no on-subnet IPv6 routers. A summary of the default sending rules are given in the table below: draft-gilligan-ipv6-trans-mech-00.txt [Page 18] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 End | End | IPv4 | IPv6 | packet | | | Node | Node | Router | Router | Format | IPv6 | IPv4 | DLink Address | On | On | On | To | Dest | Dest | Dest Type | Subnet? | Subnet? | Subnet? | 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. The general requirements for implementing the default sending rules are: * IPv6/IPv4 hosts MUST implement the default sending rules. * IPv6/IPv4 hosts SHOULD provide a mechanism for the administrator to over-ride the default sending rules and provide some other rules. * IPv6/IPv4 routers MAY implement the default sending rules. draft-gilligan-ipv6-trans-mech-00.txt [Page 19] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 3.3.2. Host On/Off Subnet Determination Part of the process of determining what packet format to use includes determining whether a destination is located on an attached subnet or not. IPv4 and IPv6 hosts employ different mechanisms. IPv4 hosts uses an algorithm in which the destination address and the interface address are both logically ANDed with the netmask of the interface. If the resulting two values are equivalent, then the destination is located on-subnet. This algorithm is discussed in more detail in Section 3.3.1.1 of the document "Requirements for Internet Hosts -- Communications Layers" [RFC1122]. IPv6 uses the neighbor discovery algorithm described in "IPv6 Neighbor Discovery -- Processing" [IPv6-NABOR]. When IPv6/IPv4 nodes are sending packets, they must employ both methods as follows: - 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 subnet 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) or an IPv6-only address (any other prefix), and IPv6 router advertisements have been heard, then the on/off subnet 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 subnet determination is made using the IPv6 system discovery mechanism. 3.4. Address Configuration Because they provide a complete IPv6 implementation, IPv6/IPv4 hosts are expected to 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 draft-gilligan-ipv6-trans-mech-00.txt [Page 20] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 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 is particularly useful in the early stages of transition before IPv6 routers and address configuration servers are 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: - 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 its own IPv4-address embedded in the low-order 32-bits. 3) The host uses the resulting IPv6 address as its own IPv6 address. Because of its utility in the early stages of transition, address configuration based on IPv4 protocols is a feature that should be supported by all IPv6/IPv4 nodes. Support of IPv4-based address configuration does not relieve a host of its requirement to implement the IPv6 address configuration protocol, however: * IPv6/IPv4 hosts SHOULD support address configuration using IPv4-based address configuration protocols. * IPv6/IPv4 hosts MUST support address configuration using the IPv6 address configuration protocol [IPv6-ACONF]. 3.5. 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. In order to properly interoperate with IPv4 nodes, they must choose the correct source address. When interoperating with an IPv4-only node, only an IPv4-compatible address may be used as a source address. An IPv6-only draft-gilligan-ipv6-trans-mech-00.txt [Page 21] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 address can not be used used as a source address when interoperating with an IPv4-only node. The source address selection rules are: * 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 MUST treat the destination as "unreachable". * When originating an IPv6 datagram to a destination represented by IPv4-mapped addresses, an IPv6/IPv4 node MUST use one its own IPv4-compatible addresses as the source IPv6 address. If the originating node is configured with no IPv4-compatible addresses, it MUST treat the destination as "unreachable". There are no restrictions on which source addresses may be used when originating datagrams to other IPv6 nodes. Either IPv4-compatible or IPv6-only addresses may be used. draft-gilligan-ipv6-trans-mech-00.txt [Page 22] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 4. IPv6-only Node Requirements This section presents the requirements of IPv6-only hosts and routers. 4.1. General Requirements * IPv6-only hosts and routers MUST provide a complete IPv6 implementation [IPv6]. 4.2. Sending Rules No special sending rules are required for IPv6-only nodes. Since they nodes 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 route datagrams addressed to IPv4-mapped, IPv4-compatible and IPv6-only addresses the same way. All are routed 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 subnet. 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.3. Source Address Selection IPv6-only nodes have similar requirements to IPv6/IPv4 nodes regarding selection of source address when interoperating with IPv4-only nodes. Like IPv6/IPv4 nodes, IPv6-only nodes may be configured with both IPv6-only and IPv4-compatible addresses, and a single interface may be configured with both types of address. The source address selection rule for IPv6-only nodes are: * When originating an IPv6 datagram to a destination represented by an IPv4-mapped addresses, an IPv6-only node MUST use one its own IPv4-compatible addresses as the source IPv6 address. If the originating node is configured with no IPv4-compatible addresses, it MUST treat the destination as "unreachable". There are no restrictions on which source addresses may be used when originating datagrams to other IPv6 nodes. Either IPv4-compatible or IPv6-only addresses may be used. draft-gilligan-ipv6-trans-mech-00.txt [Page 23] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 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-00.txt [Page 24] INTERNET-DRAFT IPv6 Transition Mechanisms November 1994 . September 1994. [IPv6-NBOR] W. A. Simpson. IPv6 Neighbor Discovery -- Processing. Internet Draft . October 1994. [TRANS-OVER] R. Gilligan. Simple Internet Transition Overview. 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-00.txt [Page 25]