Internet Engineering Task Force Ross Callon Internet Draft Dimitry Haskin Expires April 1996 Bay Networks Inc. October 1995 Routing Aspects Of IPv6 Transition (draft-ietf-ngtrans-routing-aspects-00.txt) 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 ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This paper discusses routing aspects associated with the transition from IPv4 to IPv6. The approach outlined here is designed to be compatible with the existing mechanisms for IPv4 to IPv6 Transition [1]. The proposals contained in this document are based on the work of the Ngtrans working group. Expires April 1996 [Page 1] Internet Draft Routing Aspects Of IPv6 Transition October 1995 1. TERMINOLOGY This paper uses the following terminology: node - a protocol module that implements IPv4 or IPv6. router - a node that forwards packets not explicitly addressed to itself. host - any node that is not a router. border router - a router that forwards packets across routing domain boundaries. link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below internet layer. interface - a node's attachment to a link. address - an network layer identifier for an interface or a group of interfaces. neighbors - nodes attached to the same link. routing domain - a collection of routers which coordinate routing knowledge using a single routing protocol. routing region (or just "region") - a collection of routers interconnected by a single internet protocol (e.g. IPv6) and coordinating their routing knowledge using routing protocols from a single internet protocol stack. A routing region may be a superset of a routing domain. tunneling - encapsulation of protocol A within protocol B, such that A treats B as though it were a datalink layer. reachability information - information describing the set of reachable destinations that can be used for packet forwarding decisions. routing information - same as reachability information. address prefix - the high-order bits in an address. Expires April 1996 [Page 2] Internet Draft Routing Aspects Of IPv6 Transition October 1995 routing prefix - address prefix that expresses destinations which have addresses with the matching address prefixes. It is used by routers to advertise what systems they are capable of reaching. route leaking - advertisement of network layer reachability information across routing region boundaries. 2. ISSUES AND OUTLINE This internet draft gives an overview of the routing aspects of IPv4 to IPv6 transition. The approach outlined here is designed to be compatible with the existing mechanisms for IPv6 transition [1]. During an extended IPv4-to-IPv6 transition period, IPv6-based systems must coexist with the installed base of IPv4 systems. In such a dual internetworking protocol environment, both IPv4 and IPv6 routing infrastructure will be present. Initially, deployed IPv6-capable domains might not be globally interconnected via IPv6-capable internet infrastructure and therefore may need to communicate across IPv4-only routing regions. In order to achieve dynamic routing in such a mixed environment, there need to be mechanisms to globally distribute IPv6 network layer reachability information between dispersed IPv6 routing regions. The same techniques can be used in later stages of IPv4-to-IPv6 transition to route IPv4 packets between isolated IPv4-only routing region over IPv6 infrastructure. The IPng transition provides a dual-IP-layer transition, augmented by use of encapsulation where necessary and appropriate. Routing issues related to this transition include: (1) Routing for IPv4 packets (2) Routing for IPv6 packets (2a) IPv6 packets with IPv6-native addresses (2b) IPv6 packets with IPv4-compatible addresses (3) Operation of manually configured static tunnels (4) Operation of automatic encapsulation (4a) Locating encapsulators (4b) Ensuring that routing is consist with encapsulation Expires April 1996 [Page 3] Internet Draft Routing Aspects Of IPv6 Transition October 1995 Basic mechanisms required to accomplish these goals include: (i) Dual-IP-layer Route Computation; (ii) Manual configuration of point-to-point tunnels; and (iii) Route leaking to support automatic encapsulation. The basic mechanism for routing of IPv4 and IPv6 involves dual-IP-layer routing. This implies that routes are separately calculated for IPv4 addresses and for IPv6 addressing. This is discussed in more detail in section 3.1. Tunnels (either IPv4 over IPv6, or IPv6 over IPv4) may be manually configured. For example, in the early stages of transition this may be used to allow two IPv6 domains to interact over an IPv4 infrastructure. Manually configured static tunnels are treated as if they were a normal data link. This is discussed in more detail in section 3.2. Use of automatic encapsulation requires consistency of routes between IPv4 routes and IPv6 routes for destinations using IPv4-compatible addresses. For example, consider a packet which starts off as an IPv6 packet, but then is encapsulated in an IPv4 packet in the middle of its path from source to destination. This packet must locate an encapsulator at the correct part of its path. Also, this packet has to follow a consistent route for the entire path from source to destination. This is discussed in more detail in section 3.3. 3. MORE DETAIL OF BASIC APPROACHES 3.1 Basic Dual-IP-layer Operation In the basic dual-IP-layer transition scheme, routers may independently support IPv4 and IPv6 routing. Other parts of the transition, such as DNS support, and selection by the source host of which packet format to transmit (IPv4 or IPv6) are discussed in [1]. Forwarding of IPv4 packets is based on routes learned through running IPv4-specific routing protocols. Similarly, forwarding of IPv6 packets (including IPv6-packets with IPv4-compatible addresses) is based on routes learned through running IPv6-specific routing protocols. This implies that separate instances of routing protocols are used for IPv4 and for IPv6 (although note that this could consist of two instances of OSPF and/or two instances of RIP, since both OSPF and RIP are capable of supporting both IPv4 and IPv6 routing). Expires April 1996 [Page 4] Internet Draft Routing Aspects Of IPv6 Transition October 1995 A minor enhancement would be to use an single instance of an integrated routing protocol to support routing for both IPv4 and IPv6. At the time that this is written there is no protocol which has yet been enhanced to support this. This minor enhancement does not change the basic dual-IP-layer nature of the transition. For initial testing of IPv6 with IPv4-compatible addresses, it may be useful to allow forwarding of IPv6 packets without running any IPv6-compatible routing protocol. In this case, a dual (IPv4 and IPv6) router could run routing protocols for IPv4 only. It then forwards IPv4 packets based on routes learned from IPv4 routing protocols. Also, it forwards IPv6 packets with an IPv4-compatible destination address based on the route for the associated IPv4 address. There are a couple of drawbacks with this approach: (i) It does not specifically allow for routing of IPv6 packets via IPv6-capable routers while avoiding and routing around IPv4-only routers; (ii) It does not produce routes for "non-compatible" IPv6 addresses. With this method the routing protocol does not tell the router whether neighboring routers are IPv6-compatible. However, neighbor discovery may be used to determine this. Then if an IPv6 packet needs to be forwarded to an IPv4-only router it can be encapsulated to the destination host. 3.2 Manually Configured Static Tunnels Tunneling techniques are already widely deployed for bridging non-IP network layer protocols (e.g. Appletalk, CLNP, IPX) over IPv4 routed infrastructure. IPv4 tunneling is an encapsulation of arbitrary packets inside IPv4 datagrams that are forwarded over IPv4 infrastructure between tunnel endpoints. For a tunneled protocol, a tunnel appears as a single-hop link (i.e. routers that establish a tunnel over a network layer infrastructure can inter-operate over the tunnel as if it were a one-hop, point-to- point link). Once a tunnel is established, routers at the tunnel endpoints can establish routing adjacencies and exchange routing information. Describing the protocols for performing encapsulation is outside the scope of this paper (see [1]). Static point-to-point tunnels may also be established between a host and a router, or between two hosts. Again, each manually configured point-to-point tunnel is treated as if it was a simple point-to-point link. In order for an IPv6 router to be able to encapsulate IPv6 packets into IPv4 datagrams and to forward encapsulated packets over an IPv4 tunnel, such a router must also be able to speak Expires April 1996 [Page 5] Internet Draft Routing Aspects Of IPv6 Transition October 1995 IPv4 (i.e. must be a dual router). The route tunneling technique requires dual routers to be deployed at boundaries between adjacent IPv6-capable and IPv4-only routing regions: ~~~~~ IPv6 region ~~~~~ ~~~~~ IPv6 region ~~~~~ | | dual router dual router | tunnel | | <=================> | ~~~~~ IPv4 region ~~~~~ Figure 1: Example of Manually Configured Tunnel Forwarding of IPv6 packets between IPv6 routing domains is straightforward -- when a packet reaches a border router, the border router examines it's routing database to find an interface to the next-hop router. If the forwarding interface is connected to a tunneled link, the packet must be encapsulated into an IPv4 datagram according to the adopted encapsulation scheme, and the resulting datagram is forwarded over the tunnel. Intermediate IPv4 routers between the tunnel endpoints forward the datagram as they would any other IPv4 datagram, using information in the encapsulating header. The recipient border router, in an adjacent IPv6 region, strips off the encapsulating header and forwards the original IPv6 packets toward its ultimate destination. Note that the destination and source addresses in the encapsulating header are the IPv4 addresses of the tunnel endpoints, not derivatives of the destination and source addresses of the encapsulated IPv6 packet. In the route tunneling scheme described here, there is a complete separation of the IPv6 network reachability information from the IPv4 routing information; i.e. this is a dual-IP-layer approach. Nevertheless, an IPv4 routing region and an IPv6 routing region can overlap. Each such region can share routers which support both IPv4 and IPv6 routing. There are the following advantages to employ manually configured tunneling for exchanging datagrams and routing information: - The underlying infrastructure which furnishes a tunnel link is transparent to protocols that are bridged with the tunnel (i.e. there is no changes to tunneled protocols). - All types of IPv6 route prefixes without exception can be Expires April 1996 [Page 6] Internet Draft Routing Aspects Of IPv6 Transition October 1995 advertised with routing protocols. Therefore, no restriction needs to be imposed on formats of the addresses in IPv6 packets that can be routed with this scheme. - If a connectivity between IPv6 nodes is all that needed, only border routers at boundaries with IPv4-only routing regions need to be dual protocol routers. - Since IPv6 packets are encapsulated only when they travel over network segments that don't support IPv6, and are forwarded according to their native headers anywhere else, this method does not constrain the types of policy routing which may be employed over the IPv6 portion of the data path. - Routers from major vendors already support the multiprotocol operation that is needed at tunnel endpoints. - Since a manually configured point to point tunnel works like any normal point to point link, IPv6 multicast works over manually configured point to point tunnels. No enhancement nor change to IPv6 multicast is needed for this purpose. The disadvantages of manually configured tunneling are that: - Tunnels need to be manually configured. - Manually configured tunnels are inherently point-to-point. This may be a drawback in a region where for example a large number of (IPv6-capable) dual hosts need to communicate over an IPv4 infrastructure with a small number of (IPv6-capable) dual routers. - Tunnels may circumvent security firewalls of the encapsulating infrastructure -- only addresses of the tunnel endpoints are normally visible to such firewalls, not actual attributes of the encapsulated packets. Note that the same stands true for automatic tunneling described in the next section. - Since a tunnel may appear as a one-hop link, some routing protocols may prefer a tunnel over a real multi-hop link. Therefore, IPv6 packets may be routed across an IPv4 routing region even when an alternative homogeneous IPv6 path is available. Note that this disadvantage may be eliminated by using a routing protocol such as OSPF which allows a considerable dynamic range of metric values to be assigned to links. Expires April 1996 [Page 7] Internet Draft Routing Aspects Of IPv6 Transition October 1995 Though this section describes tunneling of IPv6 routing information and IPv6 packets over IPv4 infrastructure, when a need arises for IPv4 routing regions to communicate via IPv6 routing infrastructure, the similar tunneling technique can be used -- except IPv4 packets will be encapsulated within IPv6 datagrams. 3.3 Automatic Tunnels Automatic tunneling allows the addresses of one or both tunnel endpoints to be determined automatically from the IPv6 source and destination addresses. Automatic tunneling is based on use of IPv4-compatible IPv6 addresses, and is only applicable for IPv6 over IPv4 use (i.e., for encapsulating an IPv6 packet within an IPv4 header in order to allow the packet to be forwarded via IPv4-only routers). Automatic tunneling may be used for IPv6 packets when either source or destination hosts (or both) do not have any adjacent IPv6-capable router. Note that by "adjacent router", this includes routers which are logically adjacent by virtue of a manually configured point-to-point tunnel (which is treated as if it is a simple point-to-point link). In order for automatic tunneling to work, any host which does not have any local adjacent IPv6-capable router must have an IPv4-compatible IPv6 address assigned to it. With automatic tunneling, the resulting IPv4 packet is forwarded by IPv4 routers as a normal IPv4 packet, using IPv4 routes learned from routing protocols. There are therefore no special issues related to IPv4 routing in this case. There are however routing issues relating to how IPv6 routing works in a manner which is compatible with automatic tunneling, and how tunnel endpoint addresses are selected during the encapsulation process. Automatic tunneling is useful from a source host to the destination host, from a source host to a router, and from a router to the destination host. Mechanisms for automatic tunneling from a router to another router are not currently defined. 3.3.1 Host to Host Automatic Tunneling If both source and destination hosts make use of IPv4-compatible IPv6 addresses, then it is possible for automatic tunneling to be used for the entire path from the source host to the destination Expires April 1996 [Page 8] Internet Draft Routing Aspects Of IPv6 Transition October 1995 host. In this case, the IPv6 packet is encapsulated in an IPv4 packet by the source host, and is forwarded by routers as an IPv4 packet all the way to the destination host. This allows initial deployment of IPv6-capable hosts to be done prior to the update of any routers. A source host may make use of Host to Host automatic tunneling provided that the following are both true: - the source address is an IPv4-compatible IPv6 address. - the destination address is an IPv4-compatible IPv6 address. - the source host does know of one or more neighboring IPv4- capable routers, or the source and destination are on the same subnet. If all of these requirements are true, then the source host may encapsulate the IPv6 packet in an IPv4 packet, using a source IPv4 address which is extracted from the associated source IPv6 address, and using a destination IPv4 address which is extracted from the associated destination IPv6 address. Where host to host automatic tunneling is used, the packet is forwarded as a normal IPv4 packet for its entire path, and is decapsulated (i.e., the IPv4 header is removed) only by the destination host. If the source host knows of any neighboring IPv6-capable router, or if the source and destination hosts are on the same subnet, then it is not necessary to use host to host automatic tunneling. In this case other means of forwarding the packet are possible. This document does not specify the preference between various forms of forwarding the packet (such as the preference between end to end encapsulation of IPv6 in IP versus using native IPv6 for part of the path and encapsulation for part of the path). 3.3.2 Host to Router Configured Default Tunneling In some cases "configured default" tunneling may be used to encapsulate the IPv6 packet for transmission from the source host to an IPv6-backbone. However, this requires that the source host be configured with an IPv4 address to use for tunneling to the backbone. Configured default tunneling is particularly useful if the source host does not know of any local IPv6-capable router Expires April 1996 [Page 9] Internet Draft Routing Aspects Of IPv6 Transition October 1995 (implying that the packet cannot be forwarded as a normal IPv6 packet directly over the link layer), and when the destination host does not have an IPv4-compatible IPv6 address (implying that host to host tunneling cannot be used). Host to router configured default tunneling may optionally also be used even when the host does know of a local IPv6 router. In this case it is a policy decision whether the host prefers to send a native IPv6 packet to the IPv6-capable router or prefers to send an encapsulated packet to the configured tunnel endpoint. Similary host to router default configured tunneling may be used even when the destination address is an IPv4-compatible IPv6 address. In this case for example a policy decision may be made to prefer tunneling for part of the path and native IPv6 for part of the path, or alternatively to use tunneling for the entire path from source host to destination host. A source host may make use of host to router configured default tunneling provided that ALL of the following are true: - the source address is an IPv4-compatible IPv6 address. - the source host does know of one or more neighboring IPv4- capable routers - the source host has been configured with an IPv4 address of an dual router which can serve as the tunnel endpoint. If all of these requirements are true, then the source host may encapsulate the IPv6 packet in an IPv4 packet, using a source IPv4 address which is extracted from the associated source IPv6 address, and using a destination IP address which corresponds to the configured address of the dual router which is serving as the tunnel endpoint. When host to router configured default tunneling is used, the packet is forwarded as a normal IPv4 packet from the source host to the dual router serving as tunnel endpoint, is decapsulated by the dual router, and is then forwarded as a normal IPv6 packet by the tunnel endpoint. If the destination address is also IPv4-compatible, then an alternate method in this case is to use end to end automatic tunneling. If the source host does know of at least one neighboring IPv6-capable router, then an alternate method in this case is for the source host to forward a native IPv6 packet to the IPv6-capable router. Expires April 1996 [Page 10] Internet Draft Routing Aspects Of IPv6 Transition October 1995 3.3.2.1 Routing to the Endpoint for the Configured Default Tunnel The dual router which is serving as the end point of the host to router configured default tunnel must advertise reachability into IPv4 routing sufficient to cause the encapsulated packet to be forwarded to it. The simplest approach is for a single IPv4 address to be assigned to the router for use as a tunnel endpoint. The dual router which has connectivity to the IPv6 backbone and which is capable of serving as tunnel endpoint advertises a host route to this address into IPv4 routing in the IPv4-only region. Each dual host in the associated IPv4-only region is configured with the address of this tunnel endpoint. In some cases there may be multiple dual routers which can server as endpoints for configured default tunneling from any one IPv4- only region. In this case again each host may again be configured with a single address representing the tunnel endpoint. However, all dual routers with connectivity to the IPv6 backbone which are capable of serving as configured tunnel endpoints from this region must advertise a host route to the associated IPv4 address. This allows encapsulating packets using host to router configured default tunneling to be forwarded to the tunnel endpoint that is selected by the local routing policy (for example, the nearest tunnel end point, based on whatever metric(s) the local routing protocol is using). Finally, in some cases there may be some reason for specific hosts to prefer one of several tunnel endpoints, while allowing all potential tunnel endpoints to serve as backups in case the preferred endpoint is not reachable. In this case, each dual router with IPv6 backbone connectivity which is serving as potential tunnel endpoint is given a unique IPv4 address taken from a single IPv4 address block (where the IPv4 address block is assigned either to the organization administering the IPv4-only region, or to the organization administering the local part of the IPv6 backbone). In the likely case that there are much less than 250 such dual routers serving as tunnel endpoints, we suggest using multiple IPv4 addresses selected from a single 24-bit IPv4 address prefix for this purpose. Each dual router then advertises two routes into the IPv4 region: A host route corresponding to the tunnel endpoint address specifically assigned to it, and also a standard (prefix) route to the associated IPv4 address block. Each dual host in the IPv4-only region is configured with a tunnel endpoint address which corresponds to the preferred tunnel endpoint for it to use. If Expires April 1996 [Page 11] Internet Draft Routing Aspects Of IPv6 Transition October 1995 the associated dual router is operating, then the packet will be delivered to it based upon the host route that it is advertising into the IPv4-only region. However, if the associated dual router is down, but some other dual router serving as potential tunnel endpoint is operating, then the packet will be delivered to the nearest operating tunnel endpoint. 3.3.3 Router to Host Automatic Tunneling In some cases the source host may have direct connectivity to one or more IPv6-capable routers, but the destination host might not have direct connectivity to any IPv6-capable router. In this case, provided that the destination host has an IPv4-compatible IPv6 address, normal IPv6 forwarding may be used for part of the packet's path, and router to host tunneling may be used to get the packet from an encapsulating dual router to the destination host. In this case, the operation of the encapsulating router is straightforward. The encapsulating router creates the encapsulating IPv4 header using an IPv4 address assigned to itself as the source IPv4 address, and using a destination IPv4 address extracted from the destination IPv4-compatible IPv6 address. The encapsulated packet is forwarded from the encapsulating router to the destination host using normal IPv4 routing. In this case, the hard part is the IPv6 routing required to deliver the IPv6 packet from the source host to the encapsulating router. For this to happen, somehow the encapsulating router has to advertise reachability for the appropriate IPv4-compatible IPv6 addresses into the IPv6 routing region. There are several options for how this may be accomplished: (1) Implicit Routes based on IPv4 Routing IPv4 routing will be used in the dual region to calculate routes for IPv4 packets. It is possible (as mentioned in section 3.1) to also use this to implicitly calculate routes for IPv6 packets with IPv4-compatible addresses. In the case that there is a boundary between a dual region and an IPv4-only region, it is necessary for the dual routers at the boundary to know that they are on the boundary, and that some neighboring routers are not capable of receiving nor forwarding IPv6 packets. This may be specified by manual configuration of the Expires April 1996 [Page 12] Internet Draft Routing Aspects Of IPv6 Transition October 1995 border routers, or may be determined through neighbor discovery. As mentioned in section 3.1, this approach is limited in usefulness. For example, it does not allow use of the full IPv6 address space. (2) Implicit Routes for V4-compatible addresses Plus V6-routing The solution 1 above may be enhanced by also running native IPv6 routing for "native IPv6 addresses" (i.e., for addresses which are not IPv4-compatible). In this case IPv6 packets with v4-compatible addresses would be routed using routes calculated by IPv4 routing, and other IPv6 packets would be routed using routes calculated by IPv6 routing. (3) Route Leaking With this approach, all IPv6 packets (including those with IPv4-compatible addresses) are routed using routes calculated from native IPv6 routing. This implies that encapsulating routers need to advertise into IPv6 routing specific route entries corresponding to any IPv4 addresses which can be reached in an neighboring IPv4-only region. This requires manual configuration of the encapsulating routers to control which routes are to be leaked into IPv6 routing protocols. Depending upon the extent of the IPv4-only and dual routing regions, the leaking of routes may be relatively simple or may be more complex. For example, consider a dual Internet backbone, connected via one or two dual routers to an IPv4-only stub routing domain. In this case, it is likely that there is already one summary address prefix which is being advertised into the Internet backbone in order to summarize IPv4 reachability to the stub domain. With approaches 1 and 2, advertising this one prefix into IPv4 routing in the backbone implies that the same border routers can also route IPv6 packets with corresponding IPv4-compatible addresses into the same stub domain. With approach 3, the border routers would be configured to announce the IPv4 address prefix into the IPv4 routing within the backbone, and also announce the corresponding IPv4-compatible IPv6 address prefix into IPv6 routing within the backbone. A more difficult case involves the border between a major Internet backbone which is IPv4-only, and a major Internet backbone which supports both IPv4 and IPv6. In this case, use of the third approach requires that either (i) the entire IPv4 routing table be fed into IPv6 routing in the dual routing domain (implying a doubling of the size of the routing tables in the dual domain); or (ii) Manual configuration is required to determine which of the addresses contained in the Internet Expires April 1996 [Page 13] Internet Draft Routing Aspects Of IPv6 Transition October 1995 routing table include one or more IPv6-capable systems, and only these addresses be advertised into IPv6 routing in the dual domain. In some cases it is possible that some but not all of the dual routers at a boundary between regions are capable of encapsulation. In this case it is necessary that the IPv6 packets with IPv4-compatible destination addresses are forwarded to the correct boundary router (just any boundary router is not sufficient). However, in this case native IPv4 packets traversing the dual region destined for within the IPv4-only region may be forwarded to any border router. In this case, the first two solutions above are not feasible. Rather, manual configuration of route leaking from IPv4 routing into IPv6 routing must be used. Only those border routers which are actually capable of automatic tunneling may leak routes in this case. It is recommended that this situation be avoided, by having all routers at borders between regions be capable of doing automatic tunneling. Dual routers which implement option 2 above when forwarding IPv6 packets with IPv4-compatible addresses MUST give preference to routes which are obtained directly from v6 routing, and only use the routes implied from IPv4 routing as a last resort. This allows explicit routes to be fed into IPv6 routing at those places where the border routers between regions are not all capable of automatic tunneling, but allows implicit routes based on IPv4 routing to be used in other cases. Clearly specifying the order of preference of routes in this case is necessary in order to prevent looping. 3.3.4 Operation when Multiple Methods are Feasible There may be some cases in which more than one of the forms of communications described here are feasible. In this case, the decision regarding which form is to be used in any one actually case is a policy decision, and is outside of the scope of this document. One example of this may occur if both source and destination hosts have IPv4-compatible IPv6 addresses, and where both source and destination hosts have connectivity to both IPv4 and IPv6 routers. In this case it is possible to either use native IPv6 on an end to end (host to host) basis, or to use IPv6 encapsulated over IPv4 on a host to host basis. Which method to use in any one case may be decided via policy mechanisms which Expires April 1996 [Page 14] Internet Draft Routing Aspects Of IPv6 Transition October 1995 are outside of the scope of this document. As one example of a policy mechanism which could in principle be used in this case: (i) A host might be configured to always use native IPv6 in this case; (ii) A host may be configured to use IPv6 first but then switch to IPv4 encapsulation if an error condition arises; (ii) A host may be configured to use IPv4 encapsulation first but switch to IPv6 if an error condition arises; or (iv) A host may be configured to always use IPv4 encapsulation. It is not necessary to use the same approach in each direction. Another example occurs where an IPv6-capable host has no local IPv6 router, where the host has been configured with the address of a default configured tunnel endpoint, and where both source and destination addresses are IPv4-compatible IPv6 addresses. In this case an IPv6 packet may be transmitted by the host either using host to host tunneling or using host to router tunneling. Again, which form of tunneling to prefer in this case is a policy mechanism and is not specified in this specification. 3.3.5 Example of How Automatic Tunnels May be Combined Clearly tunneling is useful only if communication can be achieved in both directions. However, different forms of tunneling may be used in each direction, depending upon the local environment, the form of address of the two hosts which are exchanging IPv6 packets, and the policies in use. Table 1 summarizes the form of tunneling that will result given each possible combination of host capabilities, and given one possible set of policy decisions. This table is derived directly from the requirements for automatic tunneling discussed above. The example in table 1 uses a specific set of policy decisions: It is assumed in table 1 that the source host will transmit a native IPv6 where possible in preference over encapsulation. It is also assumed that where tunneling is needed, host to host tunneling will be preferred over host to router tunneling. Other combinations are therefore possible if other policies are used. Note that IPv6-capable hosts which do not have any local IPv6 router must be given an IPv4-compatible v6 address in order to make use of their IPv6 capabilities. Thus, there are no entries for IPv6-capable hosts which have an incompatible IPv6 address and which also do not have any connectivity to any local IPv6 router. In fact, such hosts could communicate with other IPv6 hosts on the same local network without the use of a router. Expires April 1996 [Page 15] Internet Draft Routing Aspects Of IPv6 Transition October 1995 However, since this internet draft focuses on routing and router implications of IPv6 transition, direct communication between two hosts on the same local network without any intervening router is outside the scope of this internet draft. Also, table 1 does not consider manually configured point-to-point tunnels. Such tunnels are treated as if they were normal point-to-point links. Thus any two IPv6-capable devices which have a manually configured tunnel between them may be considered to be directly connected. -----------------+------------------+-------------------------- Host A | Host B | Result -----------------+------------------+-------------------------- v4-compat. addr. | v4-compat. addr. | host to host tunneling no local v6 rtr. | no local v6 rtr. | in both directions -----------------+------------------+-------------------------- v4-compat. addr. | v4-compat. addr. | A->B: host to host tunnel no local v6 rtr. | local v6 rtr. | B->A: v6 forwarding plus | | rtr->host tunnel -----------------+------------------+-------------------------- v4-compat. addr. | incompat. addr. | A->B: host to rtr tunnel no local v6 rtr. | local v6 rtr. | plus v6 forwarding | | B->A: v6 forwarding plus | | rtr to host tunnel -----------------+------------------+-------------------------- v4-compat. addr. | v4-compat. addr. | end to end native v6 local v6 rtr. | local v6 rtr. | in both directions -----------------+------------------+-------------------------- v4-compat. addr. | incompat. addr. | end to end native v6 local v6 rtr. | local v6 rtr. | in both directions -----------------+------------------+-------------------------- incompat. addr. | incompat. addr. | end to end native v6 local v6 rtr. | local v6 rtr. | in both directions -----------------+------------------+-------------------------- Table 1: Summary of Automatic Tunneling Combinations 4. EXAMPLE Figure 2 illustrates an example network with two regions A and B. Region A is dual, meaning that the routers within region A are capable of forwarding both IPv4 and IPv6. Region B is IPv4-only, implying that the routers within region B are capable of routing only IPv4. The illustrated routers R1 through R4 are dual. The illustrated routers r5 through r9 are IP-only. Also assume Expires April 1996 [Page 16] Internet Draft Routing Aspects Of IPv6 Transition October 1995 that hosts H3 through H8 are dual. Thus H7 and H8 have been upgraded to be IPv6-capable, even though they exist in a region in which the routers are not IPv4-capable. However, host h1 and h2 are IPv4-only. ......................... ....................... . . . . . h1 . . |-h2 . . | . . | . . H3---R1--------R2---------------r5----r9----+ . . | | . . | |-H7 . . | | . . | . . | | . . | . . H4---R3--------R4---------------r6----r8-----H8 . . . . . ......................... ....................... Region A (Dual Routers) Region B (IP-only Rtrs) Figure 2: Example of Automatic Tunneling Consider a packet from h1 to H8. In this case, since h1 is IPv4- only, it will send an IPv4 packet. This packet will traverse regions A and B as a normal IPv4 packet for the entire path. Routing will take place using normal IPv4 routing methods, with no change from the operation of the current IPv4 Internet (modulo normal advances in the operation of IPv4, of course). Similarly, consider a return packet from H8 to h1. Here again H8 will transmit an IPv4 packet, which will be forwarded as a normal IPv4 packet for the entire path. Consider a packet from H3 to H8. In this case, since H8 is in an IPv4-only routing domain, we can assume that H8 uses an IPv4-compatible IPv6 address. Since both source and destination are IPv6-capable, H3 may transmit an IPv6 packet destined to H8. The packet will be forwarded as far as R2 (or R4) as an IPv6 packet. Router R2 (or R4) will then encapsulate the full IPv6 packet in an IPv4 header for delivery to H8. In this case it is necessary for routing of IPv6 within region A to be capable of delivering this packet correctly to R2 (or R4). As explained in section 3.3, this may either make use of implicit routes (using the v4 routing within region A to provide routes for IPv6 packets with IPv4-compatible addresses), or routers R2 and R4 may leak routes to IPv4-compatible IPv6 addresses into the v6 routing used within region A corresponding to the routes which are available via IPv4 routing within region B. Expires April 1996 [Page 17] Internet Draft Routing Aspects Of IPv6 Transition October 1995 Consider a return packet from H8 to H3. Again, since both source and destination are IPv6-capable, a V6 packet may be transmitted by H8. However, since H8 does not have any direct connectivity to an IPv6-capable router, H8 must make use of an automatic tunnel. Which form of automatic tunnel will be used depends upon the type of address assigned to H3. If H3 is assigned an IPv4-compatible address, then the requirements specified in section 3.3.1 will all be satisfied. In this case host H8 may encapsulate the full IPv6 packet in an IPv4 header using a source IPv4 address extracted from the IPv6 address of H8, and using a destination IPv4 address extracted from the IPv6 address of H3. If H3 has an incompatible IPv6 address, then it is not possible for H8 to extract an IPv4 address to use as the destination tunnel address from the IPv6 address of H3. In this case H8 must use host to router tunneling, as specified in section 3.3.2. In this case one or both of R2 and R4 must have been configured with a tunnel endpoint IPv4 address (R2 and R4 may use either the same address or different addresses for this purpose). R2 and/or R4 therefore advertise reachability to the tunnel endpoint address to r5 and r6 (respectively), which advertise this reachability information into region B. Also, H8 must have been configured to know which tunnel endpoint address to use for host to router tunneling. This will result in the IPv6 packet, encapsulated in an IPv4 header, to be transmitted as far as the border router R2 or R4. The border router will then strip off the IPv4 header, and forward the remaining IPv6 packet as a normal IPv6 packet using the normal IPv6 routing used in region A. 5. INTERACTION BETWEEN IPv4 AND IPv6 INTER-DOMAIN ROUTING As discussed above, if route leaking is employed then IPv4 routes which are acquired by an inter-region dual router may need to be injected into an IPv6 routing region. Such an inter-region dual router may use BGP-4 for IPv4 inter-domain routing. Since the Inter-Domain Routing Protocol (IDRP) has been adopted for IPv6 inter-domain routing, IDRP may need to be used to propagate the IPv4 route into IPv6 routing. When routes learned with BGP are injected into IDRP, it would be highly desirable to preserve routing attributes associated with the routes in order to minimize the effect of the inter-region route leaking onto the routing integrity. Since practically all routing attributes that are carried in BGP-4 are also present in Expires April 1996 [Page 18] Internet Draft Routing Aspects Of IPv6 Transition October 1995 IDRP, the mapping of the BGP-4 attributes to the IDRP attributes is straightforward. However, since addresses and routing domain identifiers that are carried by IDRP and BGP-4 are assigned from different number spaces there is a need to ensure that 32-bit IPv4 addresses and 16-bit routing domain identifiers (Autonomous System numbers in IPv4 terminology) are uniquely represented in the larger IPv6 number space. It has been already agreed that IPv6 addresses with 96 leading zero bits are reserved to represent addresses assigned from the IPv4 address space. Since IPv6 domain identifiers are allocated from the 128-bit IPv6 address space, it will be natural to reserve IPv6 addresses (for use as routing domain identifiers) with 112 leading zero bits to uniquely represent IPv4 Autonomous System numbers. 6. SECURITY CONSIDERATIONS Use of tunneling may violate firewalls of underlying routing infrastructure. No other security issues are discussed in this paper. 7. REFERENCES [1] Transition Mechanisms for IPv6 Hosts and Routers, Bob Gilligan and Erik Nordmark, Sun Microsystems, Internet Draft draft-ietf-ngtrans-trans-mech-01.txt, May 15 1995. 8. AUTHORS' ADDRESSES Ross Callon Bay Networks Inc. 3 Federal Street Billerica, MA 01821 email: rcallon@baynetworks.com Dimitry Haskin Bay Networks, Inc. 2 Federal Street Billerica, MA 01821 email: dhaskin@baynetworks.com Expires April 1996 [Page 19]