Internet DRAFT - draft-gilligan-ipv6-sit-overview
draft-gilligan-ipv6-sit-overview
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 00:06:37 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Mon, 21 Nov 1994 00:00:00 GMT
ETag: "2e9a24-ee74-2ecfe300"
Accept-Ranges: bytes
Content-Length: 61044
Connection: close
Content-Type: text/plain
Internet Engineering Task Force Robert E. Gilligan
INTERNET-DRAFT Sun Microsystems, Inc.
November 18, 1994
Simple Internet Transition Overview
<draft-gilligan-ipv6-sit-overview-01.txt>
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
<draft-hinden-ipng-ipv6-spec-00.txt>. October 1994.
[IPv6-ADDR] R. Hinden. IP Next Generation Addressing Architecture.
Internet Draft <draft-hinden-ipng-addr-00.txt>. October
1994.
[TRANS-MECH] R. E. Gilligan, E. Nordmark. IPv6 Transition Mechanisms
for Hosts and Routers. Internet Draft
<draft-gilligan-ipv6-trans-mechanisms-00.txt>. 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]
