Internet Engineering Task Force Robert E. Gilligan INTERNET-DRAFT Sun Microsystems, Inc. November 18, 1994 Simple Internet Transition Overview Abstract This paper presents an overview of the mechanisms, operational practices, and transition plans that will be used for transitioning the Internet from IPv4 to IPv6. These techniques are collectively termed the Simple Internet Transition (SIT). While specifically designed to transition the IPv4 Internet to IPv6, the methods described here could be adapted to transition other internet layer protocols such as IPX or CLNP to IPv6. 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 18, 1995. History and Acknowledgements This design is derived from a proposal [IPAE] originally developed by Dave Crocker and Bob Hinden. Erik Nordmark, Ron Jacoby, and Steve Deering also contributed to the original IPAE design. A number of changes to that design were incorporated into this proposal, including the dual-stack concepts suggested by Dave Piscitello and Ross Callon. draft-gilligan-ipv6-sit-overview-01.txt [Page 1] INTERNET-DRAFT Simple Internet Transition Overview November 1994 Many others helped shape this design through discussions in a variety of forums over the two year period leading up to the IPng recommendation in August 1994. As part of the IPng working group, a number of people have provided feedback and suggested changes to drafts of this proposal, including: Jim Bound, Ross Callon, Brian Carpenter, Dino Farinacci, Christian Huitema, Fred Rabouw, Bill Simpson, Scott Bradner, Alex Conta, and others. draft-gilligan-ipv6-sit-overview-01.txt [Page 2] INTERNET-DRAFT Simple Internet Transition Overview November 1994 1. Introduction In order to address problems of scaling and address space, a new version of the Internet Protocol (IP) has been developed. The IP that is currently deployed is version number 4 (IPv4); The new protocol is version 6 (IPv6). If IPv6 is to be widely adopted in the global Internet, the transition from the current IP must be simple and easy for users as well as network operators. Maintaining complete compatibility with IPv4 while deploying IPv6 is a basic requirement for transition. Hosts and routers implementing the new protocol must interoperate with the large installed base of systems which continue to use IPv4. The new features of IPv6 will give users the "incentive" to convert, while the compatibility features will protect their investment in IPv4. Another requirement of the transition process is that it must disrupt the operation of the Internet as little as possible. The Internet must remain completely functional throughout the transition period. A number of mechanisms and operational practices are employed to facilitate the transition. These include standard required mechanisms to be implemented in every host and router as well as optional mechanisms. In the early part of the transition, three techniques will be used which make interoperability with IPv4 hosts and routers quite straightforward: - Use of a dual Internet Protocol layer (IPv4 and IPv6) in hosts and routers for direct interoperability with nodes implementing both protocols. - IPv6 address formats that embed IPv4 addresses within IPv6 addresses. These structures allow IPv6 hosts and routers to be assigned addresses that can be used to interoperate with IPv4 nodes, and allow the addresses of IPv4 nodes to be represented as IPv6 addresses. - A mechanism for tunneling IPv6 packets over IPv4 routing infrastructures. This technique uses the embedded IPv4 address structure to eliminate the need for tunnel configuration in most cases. Later on in the transition, additional OPTIONAL mechanisms may be introduced. These mechanisms are designed to allow for the eventual de-commissioning of IPv4 routing in most areas of the Internet, and the elimination of the IPv4 code in most host and router implementations: draft-gilligan-ipv6-sit-overview-01.txt [Page 3] INTERNET-DRAFT Simple Internet Transition Overview November 1994 - A mechanism for translating headers of IPv4 packets into IPv6, and the headers of IPv6 packet into IPv4. Special dual (IPv4 and IPv6) routers perform the translation of packet headers. - The deployment and use of hosts and routers that implement only IPv6. Even though they do not themselves implement IPv4, these nodes will continue to be able to interoperate with IPv4 nodes by routing their traffic through header translators. The header translation mechanism is reserved for later deployment because it is more complex than the early transition mechanisms. It also requires more configuration and co-ordination among sites deploying translators. For these reasons, the use of translation is optional. It will only be employed ONLY if it is determined that the benefits it provides (primarily, the ability to deploy hosts that only implement IPv6, and routing areas that only carry IPv6) out weigh the cost of its deployment. Transitioning the global Internet also involves a number of operational issues. Some of the issues that must be considered are: - Practices for assigning IPv4 and IPv6 addresses. - Practices for upgrading hosts and routers and deploying new hosts and routers. - Practices for deploying DNS servers that support the IPv6 address record type. - Operational plans for transitioning individual Internet sites to IPv6. - Operational plans for transitioning the global Internet to IPv6. The mechanisms and practices specified here provide a number of features. Some of these are: - Incremental upgrade. Existing installed IPv4 hosts and routers may be upgraded to IPv6 at any time without being dependent on any other hosts or routers being upgraded. - Incremental new deployment. New IPv6 hosts and routers can be installed at any time without any prerequisites. - Easy addressing. The existing IPv4 addressing structure can be re-used for IPv6. When existing installed IPv4 hosts or routers are upgraded to IPv6, they may continue to use their existing address. They do not need to be assigned new addresses. draft-gilligan-ipv6-sit-overview-01.txt [Page 4] INTERNET-DRAFT Simple Internet Transition Overview November 1994 - Low start-up costs. Little or no preparation work is needed in order to upgrade existing IPv4 systems to IPv6, or to deploy new IPv6 systems. 1.1. Additional Documents This paper provides an overview of the IPv6 transition. It gives an introduction to the concepts that are applied, and describes the mechanisms that are employed. But it is not a specification document. The specific requirements on the hosts, routers and header translating routers are detailed in two companion documents: - Transition Mechanisms for IPv6 Hosts and Routers [TRANS-MECH] This is a detailed specification of the transition mechanisms that hosts and routers implement. This is a specification document, written with the standard MUST/SHOULD/MAY wording. - Transition Mechanisms for IPv6 Header Translating Routers [TRANS-XLATE] This a detailed specification of the special mechanisms that translating routers must implement. This is a specification document, written with the standard MUST/SHOULD/MAY wording. Another document covers routing: - Routing Aspects of IPv6 Transition [TRANS-ROUT] This document details how IPv4 and IPv6 routing systems are implemented during the transition. No transition can succeed without a detailed plan for how the transition will be carried out operationally. For the Internet, this information is detailed in a companion document: - IPv6 Transition Plan [TRANS-PLAN] This is an informational paper detailing the specific operational steps that must be taken to transition the Internet to using IPv6 globally. This paper includes time lines for the transition, and identifies specific milestones. 1.2. Intended Audience Since this is an overview document, it is intended to be read by a wide audience. Individuals such as end users and system administrators who are interested in the concepts of the IPv6 transition may wish to read draft-gilligan-ipv6-sit-overview-01.txt [Page 5] INTERNET-DRAFT Simple Internet Transition Overview November 1994 this paper by itself. People implementing IPv6 host and router software which will incorporate the transition mechanisms should read this paper in conjunction with the specification documents. People who will be involved in transitioning the operational Internet or individual Internet sites should read this paper along with the IPv6 Transition Plan. All readers should be familiar with IPv6 and IPv4. The IPv6 specification [IPv6] and its companion documents should be read before reading this document. We use the address notation defined in the IPv6 addressing architecture specification [IPv6-ADDR] here. 1.3. Adaptability to Other Internet Layer Protocols If IPv6 is successful as a successor to IPv4, then organizations operating networks of other internet layer protocols, such as CLNP or IPX, may wish to transition them also to IPv6. The techniques described here can be adapted to transition virtually any existing internet layer infrastructure to IPv6 so long as the following assumptions hold: - Addresses in the other internet layer protocol can be mapped into the IPv6 address space efficiently. - The semantics of the other internet layer protocol are similar enough for header translation to work. Even if these assumptions do not hold, or if the population of nodes running the other protocol is small, a "pure dual stack" transition approach may succeed. The first assumption appears to be true for both CLNP and IPX. Portions of the IPv6 address space have been reserved to map CLNP NSAP and IPX addresses. See the IPv6 Routing and Addressing specification document [IPv6-ADDR]. And both CLNP and IPX are semantically close enough to IPv6 to believe that header translation may be possible. draft-gilligan-ipv6-sit-overview-01.txt [Page 6] INTERNET-DRAFT Simple Internet Transition Overview November 1994 2. Definitions A number of new terms are introduced in this paper. 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 other transition mechanisms such as tunneling. 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 in both IPv6 and IPv4 packets. An IPv4-compatible IPv6 address holds an IPv4 address in the low-order 32-bits. draft-gilligan-ipv6-sit-overview-01.txt [Page 7] INTERNET-DRAFT Simple Internet Transition Overview November 1994 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/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 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: draft-gilligan-ipv6-sit-overview-01.txt [Page 8] INTERNET-DRAFT Simple Internet Transition Overview November 1994 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. draft-gilligan-ipv6-sit-overview-01.txt [Page 9] INTERNET-DRAFT Simple Internet Transition Overview November 1994 3. Transition Model The design of the transition is based on two fundamental assumptions about how the transition will take place. The first is that the Internet will transition to IPv6 in an evolutionary fashion over an extended period of time. The second is that the sites that make up the Internet will transition at different rates and on different time schedules. It is expected that most Internet sites will need to maintain the ability to interoperate with IPv4 hosts for a very long time. The transition design makes it possible for sites to maintain IPv4 interoperability indefinitely. Individual sites may choose to stop interoperating with IPv4 hosts at any time, but the transition does not require them ever to stop. It is expected that, for most Internet sites, the transition will occur in two phases. First, they will evolve from their initial state, in which all hosts and routers support only IPv4, to a state where most hosts and routers support both IPv6 and IPv4. In the second phase, Internet sites would evolve to a state where all of the hosts and routers support only IPv6, and none directly support IPv4. The second phase is optional. Sites may elect to complete only the first phase, and operate an infrastructure that supports both protocols indefinitely. The transition design assumes that, even at the end of the second phase, when IPv4 implementations have been eliminated from a site, many sites will continue to require interoperability with IPv4 hosts outside of the site. The ability of hosts that only support IPv6 to interoperate with those that only support IPv4 is made possible by the IPv6/IPv4 header translation technique. The transition from an "IPv4-only" infrastructure to a "dual IPv6 and IPv4" infrastructure will take place at different speeds in different Internet sites. Some organizations will transition rapidly, while others will delay transition for quite some time. This transition phase can begin immediately, but may be carried out over an extended period of time. The eventual transition of some areas of the Internet to an "IPv6-only" infrastructure is unlikely to begin immediately. It will more likely begin only after the first phase of transition is completed, or at least well under way. Even after some areas begin a transition to IPv6-only, other areas of the Internet may choose to remain IPv4-only or IPv6/IPv4 indefinitely. The transition of individual sites need not be synchronize with others. Most organizations that do decide to transition to an IPv6-only draft-gilligan-ipv6-sit-overview-01.txt [Page 10] INTERNET-DRAFT Simple Internet Transition Overview November 1994 infrastructure will likely do so only after first transitioning to a dual IPv6/IPv4 infrastructure. However, this is not strictly required. Sites may transition directly from IPv4-only to IPv6-only if they wish. And organizations building entirely new infrastructures may elect to make them IPv6-only. The general timeline of transition for the Internet can be viewed as: IPv4 only -----> Dual IPv6/IPv4 -----> IPv6 only (first phase) (second phase) Today --- Time ---> Future The transition techniques are designed to optimize what is expected to be the common case for most sites: a two-phase transition. The first phase -- transition to dual IPv6/IPv4 -- is designed to be quite easy, requiring virtually no interdependencies. The second phase -- transition to an IPv6-only infrastructure that maintains its ability to interoperate with IPv4 nodes -- requires somewhat more effort. Some planning is needed, and translating routers must be deployed, before any such IPv6-only infrastructure can be built. Because of the complexity of deploying and managing translators, executing the second phase is optional. The transition ends for a site when it no longer requires interoperability with IPv4. At that point, the site is freed from the restrictions imposed by the transition. When (or if ever) to stop interoperating with IPv4 hosts is an individual decision for each site to make. draft-gilligan-ipv6-sit-overview-01.txt [Page 11] INTERNET-DRAFT Simple Internet Transition Overview November 1994 4. System Components The transition is designed so that three different types hosts and routers may be implemented: - "IPv4-only nodes" are routers and hosts that only support IPv4; They do not support IPv6. Before the transition, all hosts and routers in the Internet are IPv4-only. - "IPv6/IPv4 nodes" are hosts and routers that support both IPv6 and IPv4, as well as some additional transition mechanisms such as IPv6-over-IPv4 tunneling. IPv6/IPv4 nodes can directly interoperate with both IPv6 and IPv4 nodes, although to interoperate with IPv4-only nodes, they must be configured with an "IPv4-compatible" IPv6 address. The first transition phase in a site involves converting most or all hosts and routers in that site from IPv4-only to IPv6/IPv4. - "IPv6-only nodes" are hosts and routers that support only IPv6. IPv6-only nodes do not provide an IPv4 protocol implementation. Like IPv6/IPv4 nodes, IPv6-only nodes must be configured with "IPv4-compatible" IPv6 addresses in order to interoperate with IPv4 nodes. The second phase of transition in a site involves converting all of the hosts and routers in that site to IPv6-only. One additional type of node is used in the transition: - "IPv6/IPv4 header translating routers" are IPv6/IPv4 routers that translate IPv4 packets into IPv6, and IPv6 packets into IPv4. Translating routers are needed in order for IPv6-only nodes that are configured with IPv4-compatible addresses to interoperate with IPv4-only nodes. It is expected that for the next several years, most products that implement the Internet Protocols will evolve to become "IPv6/IPv4", and that this change will be delivered to customers as part of the normal product release cycle. Users will install IPv6/IPv4 upgrades as part of their normal operational procedures. Thus existing deployed hosts and routers may transition from IPv4-only to IPv6/IPv4 as part of a routine software upgrade. Since IPv6/IPv4 hosts and routers keep their complete IPv4 implementation, any IPv4-only host or router can be upgraded to IPv6/IPv4 without affecting its IPv4 functionallity in any way. Thus most IPv4-only nodes can be upgraded to IPv6/IPv4 at any time. draft-gilligan-ipv6-sit-overview-01.txt [Page 12] INTERNET-DRAFT Simple Internet Transition Overview November 1994 5. Dual IP Layer IPv6/IPv4 dual nodes are hosts or routers that provide a full IPv4 implementation along with their IPv6 implementation. The standard Internet transport layer protocols (TCP, UDP, etc.) are layered above both IPv4 and IPv6 in dual nodes, and the standard application protocols are layered above the transport protocols. And both IP layer protocols may make use of the standard datalink layer protocols (e.g. 10 MB ethernet, FDDI, etc.). Conceptually, the protocol layering in IPv6/IPv4 dual nodes looks something like this: +------------------+ | | | Telnet, FTP, | Application Layer Protocols | SMTP, etc. | | | +------------------+ | | +------------------+ | | | TCP, UDP, etc. | Transport Layer Protocols | | +------------------+ / \ / \ / \ / \ / \ +--------+ +--------+ | | | | | IPv4 | | IPv6 | Internet Layer Protocols | | | | +--------+ +--------+ \ / \ / \ / \ / \ / +------------------+ | | | Ethernet, FDDI, | Datalink Layer Protocols | PPP, etc. | | | +------------------+ Protocol Layering in IPv6/IPv4 Nodes draft-gilligan-ipv6-sit-overview-01.txt [Page 13] INTERNET-DRAFT Simple Internet Transition Overview November 1994 6. Addressing This section described the address forms used in the transition and how they will be operationally deployed. 6.1. Address Formats The transition uses two special formats of IPv6 addresses, both of which hold an embedded IPv4 address. IPv4-compatible addresses are assigned to IPv6 nodes, and have the following structure: | 96-bits | 32-bits | +--------------------------------------+--------------+ | 0:0:0:0:0:ffff | IPv4 Address | +--------------------------------------+--------------+ IPv4-Compatible IPv6 Address Format The addresses of IPv4 nodes are represented as IPv4-mapped IPv6 addresses. These addresses have the following structure: | 96-bits | 32-bits | +--------------------------------------+--------------+ | 0:0:0:0:0:0 | IPv4 Address | +--------------------------------------+--------------+ IPv4-Mapped IPv6 Address Format 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 may only be used to interoperate with other IPv6 nodes. IPv4-compatible IPv6 addresses are designed to be used by IPv6 nodes that wish to interoperate with IPv4 nodes. These addresses are listed in the DNS in both IPv6 "AAAA" records and IPv4 "A" records. The AAAA record holds the entire 128-bit address, while the "A" record holds the IPv4 address portion (the low-order 32-bits). Both types of address records are listed so that proper responses are made to queries from both IPv4 and IPv6 hosts. IPv4-mapped IPv6 addresses are only used to represent the addresses of IPv4 nodes. They are never assigned to IPv6 nodes. Thus they are listed in the DNS only in "A" records. Even though the addresses of all IPv4 nodes can be represented as IPv4-mapped IPv6 addresses, they are not listed in "AAAA" records. This practice simplifies DNS administration, draft-gilligan-ipv6-sit-overview-01.txt [Page 14] INTERNET-DRAFT Simple Internet Transition Overview November 1994 IPv6-only addresses are only assigned to IPv6 nodes and can not be used for interoperating with IPv4 nodes. Thus these addresses are listed in the DNS only with "AAAA" records. They can not be listed in "A" records because they do not hold an embedded IPv4 address. When administrators assign IPv4-compatible IPv6 addresses to IPv6 nodes, they must assign the low-order 32-bits (the IPv4 address portion) according to the IPv4 numbering plan used on the subnet to which that node is attached. The IPv4 address part must be a valid, globally unique, IPv4 address. The entire space of IPv6-only addresses is available for use in a global IPv6 addressing plan that is not burdened with transition requirements. This allows, for example, the addressing plan for auto-configured addresses to be developed independent of the transition mechanisms. The table below summarizes, for each of the three types of IPv6 address, what type of DNS record is required, what type of node may be assigned that type of address, and whether the address holds an embedded IPv4 address: DNS Embedded Record Address High-order IPv4 Type of Type Type 96-bit prefix Addr Node Required ------- ------------- ------- ---------- ------- IPv4-mapped 0:0:0:0:0:0 Yes IPv4-only A only IPv4-compat 0:0:0:0:0:ffff Yes IPv6/IPv4 or A and IPv6-only AAAA IPv6-only All others No IPv6/IPv4 or AAAA IPv6-only only The ability of IPv4-only, IPv6/IPv4 and IPv6-only nodes configured with the various types of address to interoperate is as follows: draft-gilligan-ipv6-sit-overview-01.txt [Page 15] INTERNET-DRAFT Simple Internet Transition Overview November 1994 --------------------------- IPv6-only node \ w/ IPv6-only \ Address \ ------------------------ \ IPv6-only node \ \ w/ IPv4-compatible \ \ Address \ \ --------------------- \ \ IPv6/IPv4 node \ \ \ w/ IPv6-only \ \ \ Address \ \ | ------------------ \ \ | IPv6/IPv4 node \ \ | | w/ IPv4-compatible \ \ | | Address \ | | | --------------- \ | | | IPv4-only node \ | | | | ------------\ \ | | | | ---------------------+---+----+----+----+----+ IPv4-only node | D | D | N | T | N | ---------------------+---+----+----+----+----+ IPv6/IPv4 node | | | | | | w/ IPv4-compatible | D | D | D | D | D | Address | | | | | | ---------------------+---+----+----+----+----+ IPv6/IPv4 node | | | | | | w/ IPv6-only | N | D | D | D | D | Address | | | | | | ---------------------+---+----+----+----+----+ IPv6-only node | | | | | | w/ IPv4-compatible | T | D | D | D | D | Address | | | | | | ---------------------+---+----+----+----+----+ IPv6-only node | | | | | | w/ IPv6-only | N | D | D | D | D | Address | | | | | | ---------------------+---+----+----+----+----+ D = Direct Interoperability T = Interoperability with aid of a translating router N = Non Interoperable 6.2. Address Deployment The transition design allows a high degree of flexibility in the ways that the IPv6 address formats can be used. The basic assumption is that IPv6 nodes can support both IPv4-compatible and IPv6-only IPv6 addresses, and that they are capable of using both types of address draft-gilligan-ipv6-sit-overview-01.txt [Page 16] INTERNET-DRAFT Simple Internet Transition Overview November 1994 simultaneously. This means that IPv6 nodes can be used in environments where either type of address is employed. While the transition mechanisms do not constrain how or when each type of address may be used, it is likely that IPv4-compatible addresses will be used extensively in the early phases of transition, in the time period before IPv6 routers are widely deployed. Using IPv4-compatible addresses is simple and straightforward for most sites because they can use their existing IPv4 address assignments to compose IPv6 addresses with no additional administrative overhead. All nodes with IPv4 address assignments already have IPv4-compatible IPv6 address assignments. Eventually the Internet will evolve to an environment where IPv6-only addresses are used extensively. In the middle, there will likely be a time period when both types of address are widely used. Those sites that no longer require IPv4 interoperability may utilize IPv6-only addresses exclusively. Since they do not require IPv4 address assignments, those sites help to relieve the pressure on IPv4 address assignment for the remaining sites that do. draft-gilligan-ipv6-sit-overview-01.txt [Page 17] INTERNET-DRAFT Simple Internet Transition Overview November 1994 7. Topologies The two major protocol mechanisms used in the transition -- tunneling and header translation -- are based on some assumptions about the way that routing topologies will develop. The general model is that IPv4 routing infrastructures will incrementally evolve into IPv6. In most cases, IPv6 routing will initially be deployed in parallel with an already existing IPv4 routing infrastructure. The deployment of IPv6 routing will take place by upgrading existing IPv4-only routers to IPv6/IPv4. This will occur over a period of time, not all at once. The site will eventually be transformed into a complete dual IPv6/IPv4 infrastructure. At some later point, IPv4 routing will be turned off. This process will also likely be incremental. The latter transition may take place by upgrading IPv6/IPv4 routers to IPv6-only, or by "turning off" the IPv4 software in IPv6/IPv4 routers. Eventually a pure IPv6 infrastructure will be formed. The design takes into account the likelyhood that both the process of "building up" the IPv6 routing, and "tearing down" the IPv4 routing, will take place over an extended period of time. Using this model, we can classify routing topologies into two categories: - "IPv4-complete areas" are topologies that are completely connected by IPv4 routing. There is at least one IPv4 router attached to every subnet in an IPv4-complete area. These areas may also have partial IPv6 routing to some subnets, but no IPv6 routing is required. An area that provides only IPv4 routing would be considered an IPv4-complete area, as would one in which IPv6 routing was in the process of being deployed. IPv4-complete areas naturally impose some restrictions on what types of hosts can operate within their boundaries. Since there is no guarantee that IPv6 traffic can be handled, only hosts that can send and receive IPv4 can safely be deployed. That means that IPv4-only and IPv6/IPv4 hosts can be freely deployed within IPv4-complete areas, but that IPv6-only hosts generally can not. - "IPv6-complete areas" are topologies that are completely connected by IPv6 routing. There is at least one IPv6 router attached to every subnet in an IPv6-complete area. These areas may also have partial IPv4 routing to some subnets, but this is not required. A topology of dual IPv6/IPv4 routing, with IPv4 routing in the process of being de-commissioned, would be considered an IPv6-complete area, as would one which provided only IPv6 routing. Like IPv4-complete areas, IPv6-complete areas have natural draft-gilligan-ipv6-sit-overview-01.txt [Page 18] INTERNET-DRAFT Simple Internet Transition Overview November 1994 restrictions on what types of hosts they can support. Since an IPv6-complete area carries only IPv6 traffic completely, only hosts that can send and receive IPv6 packets can be deployed. That means that IPv6/IPv4 and IPv6-only hosts can be freely deployed within IPv6-complete areas, but that IPv4-only hosts generally can not. A summary of which types of host may be deployed in each of the two types of topology is given in the table below: TOPOLOGY TYPE | IPv4-complete | IPv6-complete | -----------+---------------+---------------+ IPv4-only | Yes | No | -----------+---------------+---------------+ HOST TYPE IPv6/IPv4 | Yes | Yes | -----------+---------------+---------------+ IPv6-only | No | Yes | -----------+---------------+---------------+ Note that an area may actually be both IPv4-complete and IPv6-complete if it provides complete dual routing to all subnets. However, it is usually simpler to treat such areas as being one type or the other. Note we do not attempt to deal with a single area that is composed of a mixture of IPv4-only and IPv6-only routers. Such a topology does not work. IPv6-only and IPv4-only routers will not interoperate because the two can not exchange packets because the two do not share a common protocol. However, area sizes may be quite flexible: a single node may be treated as an area, as may the entire Internet. When IPv4-complete and IPv6-complete areas can be interconnected with header translating routers. For example: IPv4-complete area ---- Translating router ---- IPv6-complete area The translating router allows IPv4-only hosts in the IPv4-complete are to interoperate with IPv6-only hosts in the IPv6-complete area. Header translating routers are discussed in section 8. draft-gilligan-ipv6-sit-overview-01.txt [Page 19] INTERNET-DRAFT Simple Internet Transition Overview November 1994 8. IPv6-over-IPv4 Tunneling IPv6 packets can be carried across segments of an IPv4-complete topology by using the IPv6-over-IPv4 tunneling technique. An IPv6/IPv4 node that has IPv4 reachability to another IPv6/IPv4 node may send IPv6 packets to that node by encapsulating them within IPv4 headers. In order for this technique to work, both nodes must be assigned IPv4-compatible IPv6 addresses. This is necessary because the low-order 32-bits of those addresses are used as source and destination addresses of the encapsulating IPv4 header. Two types of tunneling are used. "Automatic tunnels" are used to deliver IPv6 packets all the way to their end destinations. "Configured tunnels" are used to deliver IPv6 packets to an intermediary IPv6/IPv4 router. Both types of tunneling make use of the IPv4 address embedded in IPv4-compatible IPv6 addresses. In automatic tunneling, the "tunnel endpoint" address is taken from the IPv4 address embedded in the IPv6 destination address. No additional configuration information is needed because the destination address is carried in the IPv6 packet being tunneled. In configured tunneling, the "tunnel endpoint" address is that of an intermediate IPv6/IPv4 router. That address must be configured. This configuration information could come in the form of a routing table entry on a host, or neighbor configuration information on a router. Automatic tunneling is a basic feature of the transition. Hosts and routers make extensive use of automatic tunneling when there is still a significant amount of IPv4 routing infrastructure. Hosts use configured tunneling less often, while routers may commonly use configured tunnels. 8.1. Automatic IPv6-over-IPv4 Tunneling Automatic tunneling is generally used between IPv6/IPv4 hosts that are connected to a common IPv4-complete area. For example, consider two IPv6/IPv4 hosts H1 and H2: IPv6/IPv4 ------- IPv4-complete area ------- IPv6/IPv4 Host H1 Host H2 (0:0:0:0:0:ffff:129.144.1.2) (0:0:0:0:0:ffff:192.9.5.3) If H1 wishes to send an IPv6 packet to H2, it could encapsulate that packet within an IPv4 packet as follows: draft-gilligan-ipv6-sit-overview-01.txt [Page 20] INTERNET-DRAFT Simple Internet Transition Overview November 1994 +-------------------------------------+ | | | src = 129.144.1.2 | IPv4 Header | dst = 192.9.5.3 | | | +-------------------------------------+ | | | src = 0:0:0:0:0:ffff:129.144.1.2 | | dst = 0:0:0:0:0:ffff:192.9.5.3 | IPv6 Header | | +-------------------------------------+ | | . . . . . . When H2 receives this packet, it decapsulates it (remove the IPv4 header), and then process the IPv6 header as it would any received IPv6 packet. Note that the source address of the encapsulating IPv4 packet is the low-order 32-bits of H1's IPv4-compatible IPv6 address, and the destination address is the low-order 32-bits of H2's IPv4-compatible IPv6 address. When automatic IPv6-over-IPv4 tunneling is used between two IPv6/IPv4 hosts, it is "end-to-end". Automatic tunneling can also be used "router-to-host". IPv6/IPv4 routers may send IPv6-in-IPv4 packets to IPv6/IPv4 hosts that are connected to a common IPv4-complete area without requiring any configuration information. 8.2. Configured IPv6-over-IPv4 Tunneling Tunneling can also be used between two IPv6/IPv4 routers, or by an IPv6/IPv4 host to an IPv6/IPv4 router. In these cases, the tunnel does not extend all the way to the packet's final destination; It runs only as far as an intermediary router. For example, consider two IPv6/IPv4 hosts H1 and H2 and router R1: IPv6/IPv4 ------- IPv4-complete area ------- IPv6/IPv4 Host H1 Router R1 (0:0:0:0:0:ffff:129.144.1.2) (0:0:0:0:0:ffff:129.146.9.8) | | | IPv6/IPv4 Host H2 (0:0:0:0:0:ffff:192.9.5.3) draft-gilligan-ipv6-sit-overview-01.txt [Page 21] INTERNET-DRAFT Simple Internet Transition Overview November 1994 If H1 wishes to send an IPv6 packet to H2 by tunneling to router R1, it could encapsulate that packet within an IPv4 packet as follows: +-------------------------------------+ | | | src = 129.144.1.2 | IPv4 Header | dst = 129.146.9.8 | | | +-------------------------------------+ | | | src = 0:0:0:0:0:ffff:129.144.1.2 | | dst = 0:0:0:0:0:ffff:192.9.5.3 | IPv6 Header | | +-------------------------------------+ | | . . . . . . Note that the IPv4 destination address is the low-order 32-bits of R1's IPv6 address, while the IPv6 destination address is H2's address. In this case, R1 is the tunnel endpoint. When R1 receives this packet, it decapsulates it (remove the IPv4 header), and then process the IPv6 header as it would any received IPv6 packet. It then forwards the IPv6 packet based on its IPv6 destination address, and delivers the packet to H2. 8.3. Tunnel Addressing In both types of tunneling, the source address of the IPv4 header of the tunneled packet is the low-order 32-bits of the IPv4-compatible IPv6 address of the node that performs the encapsulation. The IPv4 destination address is low-order 32-bits of the IPv4-compatible IPv6 address of the tunnel endpoint. Except for the case of header translating routers (see next section), the intermediary routers on the path between the encapsulating node and the decapsulating node do not look at the IPv6 header of the packet. They route the packet entirely based on its IPv4 header. This is the case even if the routers along the path are IPv6/IPv4 routers. The table below summarizes the two types of tunneling: draft-gilligan-ipv6-sit-overview-01.txt [Page 22] INTERNET-DRAFT Simple Internet Transition Overview November 1994 Tunneling Encapsulating Decapsulating Tunnel Endpoint Type Node Node IPv4 Address ----------- ------------- ------------- --------------- Automatic Source Host Dest Host Low-order 32-bits of dest host's IPv6 address Automatic Router Dest Host Low-order 32-bits of dest host's IPv6 address Configured Source Host Router Low-order 32-bits of router's IPv6 address Configured Router Router Low-order 32-bits of router's IPv6 address 8.4. Host Sending Decisions When sending IPv6 packets, an IPv6/IPv4 host must decide whether to use IPv6-over-IPv4 tunneling technique or not. Generally speaking, a host may follow these simple rules: - If the destination is located on-subnet, send directly to destination using IPv6. - If the destination is located off-subnet, and there is at least one on-subnet default IPv6 router, send in IPv6 form to the router. (The IPv6 neighbor discovery protocol allows the sending node to determine whether the destination is located off-subnet, and whether there is an on-subnet IPv6 router.) - Otherwise, send using automatic IPv6-over-IPv4 tunneling. Note that the destination must be represented by an IPv4-compatible IPv6 address in order to tunnel to it. And the sending IPv6/IPv4 host must itself be configured with an IPv4-compatible IPv6 address. These sending rules bring about a preference for sending IPv6 packets via IPv6 routers, rather than tunneling. This is desirable for a number of reasons: - Less overhead because non-encapsulated IPv6 packets are smaller than IPv6-over-IPv4 packets. - Traffic can take advantage of IPv6 routing features such as draft-gilligan-ipv6-sit-overview-01.txt [Page 23] INTERNET-DRAFT Simple Internet Transition Overview November 1994 special handling by flow ID. - Ensures that IPv6 routing topology will be used as it is deployed. Note that a host does not explicitly need to know whether it is attached to an IPv4-complete or IPv6-complete area. If it is attached to an IPv6-complete area, there will be an IPv6 router attached to every subnet, and the host will never send tunneled packets. If it is attached to an IPv4-complete area, it will send IPv6 packets if there is an IPv6 router on-subnet, and tunneled packets if there is none. draft-gilligan-ipv6-sit-overview-01.txt [Page 24] INTERNET-DRAFT Simple Internet Transition Overview November 1994 9. Header Translation. Header translation is an OPTIONAL mechanism that is used when one wishes to allow IPv6-only nodes to interoperate with IPv4-only nodes. Header translation is performed by header translating routers, which interconnect IPv4-complete and IPv6-complete areas. Most of the traffic crossing the boundary between these areas must be translated. This traffic can come in a number of different forms: 1) Terminating IPv4 traffic: IPv4 packets that are addresses to a node inside the IPv6-complete area. 2) Transit IPv4 traffic: IPv4 packets that are addressed to a node that is outside the IPv6-complete area, but that must pass through the IPv6-complete area. 3) Terminating IPv6 traffic: IPv6 packets that are addressed to a node inside the IPv4-complete area. 4) Transit IPv6 traffic: IPv6 packets that are addressed to a node outside the IPv4-complete area, but that must pass through the IPv4-complete area. 5) Encapsulated IPv6 traffic: IPv6 packets encapsulated in IPv4 headers. (This is the special case.) Header translators are IPv6/IPv4 routers. They operate by translating the headers of IPv4 packets into IPv6, and IPv6 headers into IPv4. They require some configuration information in order to know which packets should be translated, and which should be simply forwarded unmodified: - Translating IPv4 packets. Header translators must translate all IPv4 packets that are addressed to nodes located within the IPv6-complete area, or that must transit the IPv6-complete are: (IPv4 packet) --> (Translate to IPv6) --> (IPv6 Packet) IPv4-complete area -- Translating router -- IPv6-complete area | | | | IPv4-only node IPv6-only node - Translating IPv6 packets. Header translators must translate all IPv6 packets that are addressed to nodes located within the IPv4-complete area, or that must transit the IPv4-complete area: draft-gilligan-ipv6-sit-overview-01.txt [Page 25] INTERNET-DRAFT Simple Internet Transition Overview November 1994 (IPv4 packet) <-- (Translate to IPv4) <-- (IPv6 Packet) IPv4-complete area -- Translating router ----- IPv6-complete area | | | | IPv4-only node IPv6-only node When translating IPv6 packets to IPv4, translating routers use the low-order 32-bits of the source and destination IPv6 addresses to generate the addresses for the IPv4 packet. Both the source and destination must be IPv4-compatible IPv6 addresses in order for the packet to be translated. When translating IPv4 packets to IPv6, translating routers pre-pend the prefix 0:0:0:0:0:0 to the IPv4 source address to generate the source address for the IPv6 packet. They prepend either the prefix 0:0:0:0:0:ffff or 0:0:0:0:0:0 to generate the destination address. Determining which prefix to prepend requires some configuration information. Translators use the 0:0:0:0:0:ffff prefix if the destination is located within the attached IPv6-complete area, and the prefix 0:0:0:0:0:0 if the destination is located outside. When IPv6-in-IPv4 format packets arrive at a header translator, they are de-capsulated, not translated: (IPv6 packet encapsulated in IPv4) --> (Decapsulate) --> (IPv6 Packet) IPv4-complete area -- Translating routers ----- IPv6-complete area | | | | IPv6/IPv4 node IPv6-only node This is necessary to prevent the encapsulating IPv4 header of an IPv6-in-IPv4 packet from being translated to IPv6 header, yielding an IPv6-in-IPv6 packet! The "early decapsulation" by header translators has the affect that all IPv6-over-IPv4 tunnels terminate when they reach a header translator. draft-gilligan-ipv6-sit-overview-01.txt [Page 26] INTERNET-DRAFT Simple Internet Transition Overview November 1994 10. Upgrade Dependencies Perhaps the most important issue for those who must carry out the transition from IPv4 to IPv6 is that of upgrade dependencies: Which transition steps must be performed before other steps can be taken? The transition is designed so that the prerequisites to installation of IPv6/IPv4 nodes are minimal, while the steps that must be taken before IPv6-only nodes may be deployed are more involved. The table below summarizes the operational dependencies that network and system administrators must consider in planning the upgrade of systems to IPv6: | Transition Step | Depends On | +-------------------------------+------------------------------+ | DNS upgrade to support | None | | AAAA records (1) | | +-------------------------------+------------------------------+ | Upgrade IPv4 host or router | DNS upgrade to support | | to IPv6/IPv4 | AAAA records (2) | +-------------------------------+------------------------------+ | Deploy new IPv6/IPv4 host or | DNS upgrade to support | | router | AAAA records (2) | +-------------------------------+------------------------------+ | Change IPv4-complete area to | Install Translating router | | IPv6-complete | at border | | | Upgrade all routers within | | | area to IPv6/IPv4 | +-------------------------------+------------------------------+ | Upgrade IPv6/IPv4 host or | Change area from IPv4-complt | | router to IPv6-only | to IPv6-complete | +-------------------------------+------------------------------+ | Deploy new IPv6-only | Change area from IPv4-complt | | host or router | to IPv6-complete | +-------------------------------+------------------------------+ Notes: (1) Note that a DNS server being upgraded to support the IPv6 AAAA address record type does not itself need to be upgraded to IPv6. An IPv4-only DNS server may support AAAA record types. (2) The DNS upgrade is only required if the node being upgraded or installed is going to be listed in the DNS. If the node is to be "unlisted," or listed in local host tables, its upgrade is not dependent on the upgrade of the DNS. Host files should be used sparingly. draft-gilligan-ipv6-sit-overview-01.txt [Page 27] INTERNET-DRAFT Simple Internet Transition Overview November 1994 11. Examples Two IPv6/IPv4 hosts may use IPv6-over-IPv4 tunneling to communicate via an IPv4 infrastructure: IPv6/IPv4 Host H1 (0:0:0:0:0:ffff:129.144.1.2) | --+--------------------------+-- (subnet A) | (0:0:0:0:0:0:129.144.1.3) IPv4-only Router R1 (0:0:0:0:0:0:129.144.2.3) | -------+-----------------+----- (subnet B) | (0:0:0:0:0:ffff:129.144.2.4) IPv6/IPv4 Host H2 When H1 sends a packet to H2, the packets that will be transmitted on subnets A and B are: Subnet Packet IPv4 header Datalink Hop Type IPv6 header dest addr dest addr dest addr ------ ----- ----------------------------- ---------- --------- A Encap. 0:0:0:0:0:ffff:129.144.2.4 129.144.2.4 R1 B Encap. 0:0:0:0:0:ffff:129.144.2.4 129.144.2.4 H2 Note: Encap. = IPv6-over-IPv4 encapsulation If an IPv6/IPv4 router is added to this topology, H1 will have multiple routes to reach H2. It could use IPv6-over-IPv4 tunneling, sending the traffic via R1 or R2, or use the raw IPv6 format routing via R2. Since IPv6/IPv4 hosts prefer routes via IPv6 routers, H1 will use send the traffic via R2: draft-gilligan-ipv6-sit-overview-01.txt [Page 28] INTERNET-DRAFT Simple Internet Transition Overview November 1994 IPv6/IPv4 Host H1 (0:0:0:0:0:ffff:129.144.1.2) | --+-----+-------------------------------+-- (subnet A) | | (0:0:0:0:0:ffff:129.144.1.4) (0:0:0:0:0:0:129.144.1.3) IPv6/IPv4 Router R2 IPv4-only Router R1 (0:0:0:0:0:ffff:129.144.2.6) (0:0:0:0:0:0:129.144.2.3) | | ----+--+----------------------------+----- (subnet B) | (0:0:0:0:0:ffff:129.144.2.4) IPv6/IPv4 Host H2 Now when H1 sends a packet to H2, the packets that will be transmitted on subnets A and B are: Subnet Packet Datalink Hop Type IPv6 header dest addr dest addr ------ ----- ----------------------------- --------- A IPv6 0:0:0:0:0:ffff:129.144.2.4 R2 B IPv6 0:0:0:0:0:ffff:129.144.2.4 H2 draft-gilligan-ipv6-sit-overview-01.txt [Page 29] INTERNET-DRAFT Simple Internet Transition Overview November 1994 12. Changes Since the Previous Version of this Document Some of the terminology was changed in order to make the concepts more understandable: IPv4-incompatible address ==> IPv6-only address IPv4-dominant area ==> IPv4-complete area IPv6-dominant area ==> IPv6-complete area Section 9, the "node requirements" section was eliminated. It is no longer needed since the information it contained is covered in more detail in the new "transitions mechanisms" spec. A bug in the prefix of the IPv4-compatible IPv6 address was fixed. It was written as 0:0:0:0:ffff:ffff in the previous document, but the correct perfix is 0:0:0:0:0:ffff. A small note was added to section 9 (Upgrade Dependencies) to clarify that the DNS upgrade dependency does not apply to sites that use local host files instead of the DNS. Section 6 (addressing) was expanded to explain how the IPv6 address formats can be deployed. Many parts of the document were re-written to improve their clarity. 13. 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 14. References [IPAE] R. E. Gilligan. IPAE: The SIPP Interoperability and Transition Mechanism. Internet Draft. March 1994. [IPv6] R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. Internet Draft draft-gilligan-ipv6-sit-overview-01.txt [Page 30] INTERNET-DRAFT Simple Internet Transition Overview November 1994 . October 1994. [IPv6-ADDR] R. Hinden. IP Next Generation Addressing Architecture. Internet Draft . October 1994. [TRANS-MECH] R. E. Gilligan, E. Nordmark. IPv6 Transition Mechanisms for Hosts and Routers. Internet Draft . November 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. [TRANS-ROUT] Routing Aspects of IPv6 Transition. Internet Draft to be written. draft-gilligan-ipv6-sit-overview-01.txt [Page 31]