[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force               Robert E. Gilligan
INTERNET-DRAFT                                Erik Nordmark
                                              Sun Microsystems, Inc.

                                              November 18, 1994


           Transition Mechanisms for IPv6 Hosts and Routers
               <draft-gilligan-ipv6-trans-mech-00.txt>

Abstract

This document specifies the required and optional mechanisms that IPv6
hosts and routers implement in order to interoperate with IPv4 hosts
and routers.  These mechanisms are designed to make the transition of
the global Internet from IPv4 to to IPv6 as easy as possible.


Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups.  Note that other groups may also distribute working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

This Internet Draft expires on May 11, 1995.















draft-gilligan-ipv6-trans-mech-00.txt                           [Page 1]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


1. Introduction

This specification defines the mechanisms that are to be implemented
by IPv6 hosts and routers so that they may be compatible with IPv4
hosts and routers.  Maintaining compatibility with IPv4 while
deploying IPv6 is the primary objective of the transition.

Some of the mechanisms discussed here are optional, while others are
mandatory.  We use the terms MUST, SHOULD, MAY, SHOULD NOT, and MUST
NOT to specify the level of support required of each feature.

The document is written primarily as descriptive text.  Some specific
requirements are given in indented paragraphs offset with a star
character, like this:

   *    This spec MUST have lots of requirements.

Other requirements are included in the body of the document.

The companion document "Simple Internet Transition Overview"
[TRANS-OVER] gives an introduction and overall summary of the
transition mechanisms and how they are expected to operate.  It
provides important background information that is useful for
understanding this specification.  IPv6 implementors should read the
overview document before reading this document.

1.1. Applicability

The requirements in this document apply to IPv6 hosts and routers that
need to interoperate with IPv4 hosts and routers.  It is expected that
in the operational Internet, complete compatibility with IPv4 will be
necessary for a long time to come, and perhaps even indefinitely.

However, IPv6 may be used in some environments where interoperability
with IPv4 is not necessary.  IPv6 nodes that are designed to be used
in such environments need not not adhere to these specifications.

This document specifies the mechanisms to be implemented by IPv6/IPv4
hosts and routers, as well as IPv6-only hosts and routers.  It does
not specify the mechanisms that IPv6/IPv4 header translating routers
must implement.  That information is covered in the companion document
"Transition Mechanisms for Header Translating Routers" [TRANS-XLATE].

1.2. Terminology

This document employs the terminology defined section 2 in the
Transition Overview document [TRANS-OVER] and in the IPv6
specification [IPv6].  Readers should be familiar with this



draft-gilligan-ipv6-trans-mech-00.txt                           [Page 2]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


terminology before reading this document.

1.3. Structure of this Document

The specifications are organized into three sections:

   -    Section 2 lists the requirements that apply to both IPv6/IPv4
        dual nodes, and IPv6-only nodes.

   -    Section 3 lists the requirements that apply only to IPv6/IPv4
        dual nodes.

   -    Section 4 lists the requirements that apply only to IPv6-only
        nodes.

Thus someone implementing an IPv6/IPv4 host or router would need to
comply with sections 2 and 3, while someone implementing an IPv6-only
node would need to comply with sections 2 and 4.

































draft-gilligan-ipv6-trans-mech-00.txt                           [Page 3]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


2.  Common Requirements

This section details the requirements that are common to IPv6/IPv4 and
IPv6-only hosts and routers.

2.1. General Requirements

The transition is designed so that IPv6 hosts and routers may be
implemented either as IPv6/IPv4 dual nodes, or as IPv6-only nodes.
IPv6/IPv4 nodes can directly interoperate with IPv4-only nodes, while
IPv6-only nodes require a translator.  Since translators are complex
to set up and manage, they are not expected to be deployed during
early transition period.  Thus IPv6-only nodes will not be able to
interoperate with IPv4-only nodes during that period.  Therefore:

  *     During the first phase of transition, IPv6 hosts and routers
        SHOULD be IPv6/IPv4 dual nodes.

We don't know how long the first transition phase will last.  For
planning purposes, implementors should expect that it will last for at
least five years after the date of this document was written.

2.2. Addressing Requirements

IPv6 nodes use a special type of address, termed an "IPv4-compatible"
IPv6 address, when interoperating with IPv4-only nodes.  An
IPv4-compatible holds an IPv4 address in the low-order 32-bits, and
this property allows it to be used both as an IPv6 address and as an
IPv4 address.  Another type of address, termed an "IPv6-only" address,
is used by IPv6 nodes exclusively for interoperating with other IPv6
nodes.  An IPv6-only address can not be used when interoperating with
an IPv4-only node.

Since IPv6/IPv4 and IPv6-only nodes must be capable of operating in
environments where they interoperate with IPv4 nodes, as well as
environments where they interoperate with IPv6 nodes, they must be
configurable with both types of address:

   *    IPv6/IPv4 and IPv6-only nodes MUST be capable of being
        configured with an IPv4-compatible IPv6 address.

   *    IPv6/IPv4 and IPv6-only nodes MUST be capable of being
        configured with an IPv6-only IPv6 address.

In addition, one feature of IPv6 is that nodes must be configurable
with multiple addresses per interfaces.  For maximum flexibility,
these addresses should be of either type:




draft-gilligan-ipv6-trans-mech-00.txt                           [Page 4]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


   *    IPv6/IPv4 and IPv6-only nodes SHOULD be capable of being
        configured with multiple IPv4-compatible and multiple
        IPv6-only addresses on the same interface at the same time.

2.3.  DNS Requirements

Both IPv4 and IPv6 use the Domain Naming System (DNS) to map hostnames
into addresses.  A new resource record type named "AAAA" has been
defined for IPv6 addresses.  Support for this record type is an
essential part of the transition, and can not be left out of an
implementation:

   *    IPv6/IPv4 and IPv6-only hosts MUST implement a DNS resolver
        capable of handling the AAAA resource record type.

Some sites use local host tables instead of or in addition to the DNS.
Use of host tables may be particularly useful in the very early stages
of transition before the DNS infrastructure has been converted to
support AAAA records.  Therefore, implementations may choose to
provide a host table mechanism:

   *    IPv6 hosts MAY implement a local IPv6 host table mechanism in
        addition to the DNS resolver.

Note that the local host table mechanism does not scale very well, so
its use is not recommended for large sites.  Further discussion of the
host table issue can be found in section 6.1.1 of "Requirements for
Internet Hosts -- Application and Support" [RFC-1123].

2.3.1.  Handling "A" Records

Even though the addresses of IPv4-only nodes can be represented as
IPv4-mapped IPv6 addresses, and thus could be stored in DNS AAAA
address records, this is not done.  In order to simplify the
administration of the DNS, only "A" type address records are listed in
the DNS for IPv4-only nodes.  Morever, even if IPv4-mapped IPv6
addresses were stored in the DNS, IPv6 nodes would need to be able to
interoperate with IPv4 hosts whose addresses are stored in DNS servers
that have not been upgraded.  Therefore, IPv6 hosts must continue to
support "A" records:

   *    IPv6/IPv4 and IPv6-only hosts MUST implement a DNS resolver
        capable of handling the A resource record type.

The specific manner by which an IPv6 host handles A records is up to
each implementation.  Two approaches that will work are:

   1)   The resolver library can take the IPv4 address given in the A



draft-gilligan-ipv6-trans-mech-00.txt                           [Page 5]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


        record, pre-pend the prefix 0:0:0:0:0:0, and return the
        resulting IPv4-mapped IPv6 address to the application.  The
        application can then pass this IPv6 address to the transport
        layer, which in turn can pass it down to the Internet layer.

   2)   The resolver library can return the IPv4 address given in the A
        record directly to the application.  The application can then
        pass this IPv4 address to the transport layer.

Both of these approaches will have the same affect.  They will both
cause the same format of datagram to be sent according to the sending
rules given in sections 3.3 and 4.2.

The first approach has the advantage that it allows applications to
treat addresses of IPv4-only hosts and IPv6 hosts the same, and it
allows the interface between the application and the transport layer
to be cast entirely in terms of IPv6 addresses.  If the second
approach is used, the interface between the application and transport
layer must be designed to carry IPv4 addresses.  For this reason, the
second approach is probably not appropriate for IPv6-only hosts, while
IPv6/IPv4 hosts could implement either approach.

2.3.2.  Redundant A Records

When an IPv4-compatible IPv6 addresses is assigned to an IPv6 host,
that address is listed in the DNS in both A and AAAA resource records.
Thus, there are typically two resource records associated with the
domain name of an IPv6 host that has been assigned an IPv4-compatible
address: the full 128-bit IPv4-compatible address is listed in an AAAA
record, while the low-order 32-bits of that address is listed in an A
record.  The AAAA record is provided to satisfy DNS queries made by
IPv6 hosts, and the A record is provided for queries by IPv4 hosts.

DNS resolver libraries on IPv6 nodes must be capable of handling both
AAAA and A records.  However, when a query locates both an AAAA record
and an A record representing the same IPv4-compatible IPv6 address,
both should not be returned to the application, since doing so would
give the application two versions of the same address.  Instead, the
resolver library should return only the AAAA record address to the
application.

DNS resolvers can implement a variety of algorithms to accomplish this.
One algorithm is as follows:

   -    First query for a AAAA records.  If one or more is found,
        return it (them) to the application.

   -    If no AAAA records are found, query for "A" records.  If one



draft-gilligan-ipv6-trans-mech-00.txt                           [Page 6]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


        or more is found, return it (them) to the application.

   -    Return failure to the application only if no AAAA or A records
        are found.

The resolver may implement any algorithm so long as it has the affect
that, if both AAAA and A records representing the same IPv4-compatible
IPv6 address are found, only the addresses contained in the AAAA
record is returned to the application:

   *    The DNS resolver library MUST implement an algorithm that
        prevents A record addresses from being returned to the
        application when IPv4-compatible IPv6 address were also
        received.





































draft-gilligan-ipv6-trans-mech-00.txt                           [Page 7]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


3. IPv6/IPv4 Node Requirements

This section covers the requirements of IPv6/IPv4 dual hosts and
routers.

3.1 General Requirements

IPv6/IPv4 nodes implement both the old and new versions of the Internet
Protocol.  Providing both protocols allows these nodes to directly
interoperate with both IPv4 and IPv6 nodes.  The important aspect of
this for transition is that IPv6/IPv4 nodes fully interoperate with the
large installed base of IPv4 nodes.  Thus:

   *    IPv6/IPv4 nodes MUST directly interoperate with IPv4 nodes.

It is important that the implementations of both protocols be complete,
so that interoperation with both IPv4 and IPv6 nodes is assured:

   *    IPv6/IPv4 nodes MUST provide a complete IPv4 implementation and
        MUST provide a complete IPv6 implementation.


3.2. IPv6-over-IPv4 Tunneling

IPv6/IPv4 hosts and routers tunnel IPv6 datagrams over regions of IPv4
routing topology by encapsulating them within IPv4 packets.  Two types
of tunneling are used: "Automatic tunnels" and "Configured tunnels".

Automatic tunnels are used to deliver IPv6 datagrams to their final end
destination.  In automatic tunneling, the IPv6 packet is encapsulated
within an IPv4 header that is addressed to the final destination IPv6
node.  The "tunnel endpoint" address (the destination address of the
encapsulating IPv4 header) is taken from the embedded IPv4 address in
the destination address of the IPv6 header.  In most cases, the packet
is carried via IPv4 routing all the way to the end node, which
de-capsulates the IPv6 packet and "consumes" it.  The term "automatic"
is given to this type of tunneling because the IPv4 tunnel endpoint
address is automatically determined from the destination address of the
IPv6 packet; No other configuration information is necessary.

Configured tunnels are used to deliver IPv6 datagrams to an intermediary
IPv6 router.  In configured tunneling, the IPv6 packet is encapsulated
in an IPv4 header that is address to an intermediary IPv6/IPv4 router.
The tunnel endpoint address is the IPv4 address of that router.  The
packet is carried by IPv4 routing to this router, which de-capsulates
the IPv6 packet.  That IPv6 router then routes the packet based on its
IPv6 destination address and forwards it on toward its final
destination.  The term "configured" is used to describe this type of



draft-gilligan-ipv6-trans-mech-00.txt                           [Page 8]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


tunneling because the IPv4 tunnel endpoint address is determined by
external configuration information; It can not be determined from the
packet being tunneled.

The same underlying mechanisms are used for both types of tunneling.
These mechanisms consists of:

   -    The entry node of the tunnel (the encapsulating node) creates an
        encapsulating IPv4 header.

   -    The exit node of the tunnel (the decapsulating node) removes the
        IPv4 header and updates the IPv6 header.

   -    The encapsulating node maintains soft state for each tunnel in
        order to generate IPv6 ICMP errors.

IPv6/IPv4 hosts and routers may need to keep state information about the
tunnels they are using, and the number of tunnels any one host or router
may be using may grow to be quite large.  Therefore the tunnel state
information should be cached so that it can be discarded when no longer
used and later recreated.

3.2.1. General Tunneling Requirements

  *     IPv6/IPv4 hosts and routers MUST be able to perform automatic
        tunneling.

  *     IPv6/IPv4 hosts and routers SHOULD be able to perform
        configured tunneling.

  *     IPv6/IPv4 hosts and routers MUST be able to perform
        de-capsulation of IPv6-in-IPv4 packets.

3.2.2. Detailed Tunneling Requirements

The encapsulation of an IPv6 datagram in IPv4 is shown below:















draft-gilligan-ipv6-trans-mech-00.txt                           [Page 9]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


                                        +-------------+
                                        |    IPv4     |
                                        |   Header    |
        +-------------+                 +-------------+
        |    IPv6     |                 |    IPv6     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |  Transport  |                 |  Transport  |
        |   Layer     |      ===>       |   Layer     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |             |                 |             |
        ~    Data     ~                 ~    Data     ~
        |             |                 |             |
        +-------------+                 +-------------+

                      Encapsulating IPv6 in IPv4

3.2.2.1.  Tunnel MTU

The encapsulating node MUST be able to pass an IPv6 datagram of any size
over a tunnel.  This can be accomplished in one of the following ways:

  1)    The encapsulating node can perform IPv4 Path MTU Discovery
        [RFC-1191] on the tunnel.  It may do this by setting the Don't
        Fragment (DF) bit in the IPv4 header of all IPv6-in-IPv4
        packets, and using the ICMP "packet too big" messages that are
        returned to determine the tunnel MTU.  The encapsulating node
        keeps a cache of the tunnel MTU of all active tunnels. If an
        encapsulated IPv6 datagram would exceed the tunnel MTU, the
        encapsulating node sends the packet in multiple IPv4 fragments.

  2)    The encapsulating node may opt not to perform IPv4 Path MTU
        Discovery on the tunnel.  In this case, it must perform IPv4
        fragmentation if an encapsulated IPv6 packet would exceed the
        MTU of the outgoing interface.  The Don't Fragment flag is
        cleared (set to zero) in all IPv6-in-IPv4 packets so that IPv4
        routers along the tunnel path may further fragment the packet.
        If the packet is fragmented, the decapsulating node will
        reassemble it before decapsulating the IPv6 packet.

3.2.2.2.  Hop Limit

Each of the "hops" that an encapsulated IPv6 datagram takes through
IPv4 routers must be reflected in the IPv6 hop limit field.  This is
necessary so that scope limitations imposed by the sender of the IPv6
datagram can be enforced.




draft-gilligan-ipv6-trans-mech-00.txt                          [Page 10]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


To accomplish this, the encapsulating node MUST copy the the IPv6 hop
limit field into the IPv4 TTL field.  The decapsulating node MUST copy
the IPv4 TTL field into the IPv6 hop limit field.

In addition, if the encapsulating node is an IPv6 router forwarding
the packet, it MUST decrement the IPv6 hop count.

3.2.2.3. Tracking the Tunnel State

In addition to limiting packets' scope, reflecting the "hops" taken
through a tunnel in the IPv6 hop limit field allows the IPv4 routers
along the path to be "traceroute visible."  This means that a
traceroute program running on an IPv6 host will report all the routers
internal to the tunnel.  Making a tunnel traceroute visible is
accomplished by having the encapsulating node maintain "soft state"
about the number of IPv4 hops there are in the tunnel, and returning
an ICMP "time exceeded" messages a packet would "expire" within the
tunnel.

Soft state can also be kept about other characteristics of the tunnel,
and then used to accurately return ICMP errors back to the originators
of datagrams that pass through the tunnel.  Since it is complex to
implement and only used for generating accurate ICMP error indications,
maintaining tunnel state is not mandatory:

   *    IPv6/IPv4 nodes SHOULD implement a mechanism to track the state
        of the tunnel.

The soft state information for a tunnel is based on the ICMP errors that
are received from IPv4 routers interior to the tunnel.  Tunnel state
information is associated with the IPv4 address of the endpoint of the
tunnel and consists of:

  -     Tunnel MTU.

  -     Path length of the tunnel (number of hops).

  -     For each TTL 't' between 1 and the path length of the tunnel,
        the IPv4 address of the router that was last known to be 't'
        hops into the tunnel.

  -     Reachability of the end of the tunnel.

  -     The IPv4 address of the router reporting unreachability.

The tunnel state does not have to be allocated until an ICMP error is
received.  In the absence of tunnel state, the tunnel MTU can be assumed
to be the MTU of the outgoing interface, the path length one hop and the



draft-gilligan-ipv6-trans-mech-00.txt                          [Page 11]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


endpoint being reachable.

When an IPv6 datagram is encapsulated, the encapsulating node consults
the tunnel state to check if the packet is likely to generate an ICMP
error from a router interior to the tunnel.  In such a case (e.g. packet
size is greater than the tunnel MTU, or the hop limit is less than the
path limit of the tunnel), and the node is a router, it generates the
appropriate IPv6 ICMP error. If the encapsulating node is a host, it
passes an error indication up to the transport layer.  After generating
the error indication, it forwards the packet into the tunnel.  Any IPv4
ICMP error caused by the tunneled packet will return to the
encapsulating node, and are used to refresh the tunnel state.

When the encapsulator receives an IPv4 ICMP error where the "offending
packet" is IPv4 with the IP protocol field being 41, it updates the
tunnel state associated with the IPv4 destination in the "offending
packet". The update depends on the type of ICMP error:

   -    Host or network unreachable: Mark the tunnel endpoint as
        unreachable and record the source of the ICMP error as the
        source of unreachability.

   -    Time exceeded in transit: The TTL "consumed" before reaching the
        router that sent the time exceeded message is extracted from the
        IPv6 hop limit field in the "offending packet" (the IPv6 hop
        limit field is in the first 8 bytes of the IPv6 header thus it
        will be returned in the ICMP packet). Compute the updated tunnel
        path length as the maximum of the currently recorded path length
        and the extracted IPv6 hop limit. Record the source of the ICMP
        error as the router at 'IPv6 hop limit' hops into the tunnel.

   -    "Packet too big": If the ICMP packet contains the MTU (see "Path
        MTU Discovery" [RFC-1191]) update the tunnel MTU to be that
        value.  If the ICMP packet does not contain the MTU use the IPv4
        "total length" field in the "offending packet" and the
        recommended plateaus in RFC-1191 to compute the new MTU for the
        tunnel.  Note that this can either increment or decrement the
        recorded tunnel MTU.

   -    For all other ICMP errors log a network management event.

When the encapsulating node forwards a packet into the tunnel it
performs the following checks against the tunnel state:

   -    If the tunnel endpoint is unreachable, it generates a IPv6 ICMP
        "network unreachable" message with the source address being the
        router that reported the unreachability. The IPv4 address of
        that router, which should be recorded in the tunnel state



draft-gilligan-ipv6-trans-mech-00.txt                          [Page 12]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


        information, is mapped into an IPv6 address by prepending it
        with a 96-bit all-zeros prefix (0:0:0:0:0:0).  The resulting
        IPv6 address is used as the source address of the IPv6 ICMP
        error message.

   -    If the hop limit is less than the recorded tunnel TTL, it
        generates an IPv6 ICMP "time exceeded in transit" message with
        the source address being the address of the IPv4 router that is
        'hop limit' hops into the tunnel.  As in the previous case, this
        router's address is stored in the tunnel state information and
        may be mapped into an IPv6 address for use as the source address
        of the IPv6 ICMP error message.  If there is no router address
        recorded for the specified hop limit, the router generates an
        ICMP time exceeded with a source address of all zeros
        (0:0:0:0:0:0:0:0).

   -    If the MTU exceeds the recorded tunnel MTU it generates a IPv6
        ICMP "packet too big" using its own IPv6 address as the source,
        and setting the returned MTU to the recorded tunnel MTU minus
        the size of the IPv4 header (20 bytes).  (The 20 byte adjustment
        is needed since the packets will "expand" by 20 bytes when being
        encapsulated.)

In all of these cases, the datagram is also forwarded into the tunnel.

The mechanism described so far does not detect when an error condition
in the tunnel is lifted (e.g. the tunnel endpoint becomes reachable or
when the tunnel path length decreases). The simple solution to detecting
such "improvements" is to periodically discard the recorded tunnel
state.  More elaborate schemes are possible, such as counting the number
of 1) datagrams that should have generated a certain ICMP error and 2)
the actual number of such ICMP errors received, and discarding the state
when the ratio between them exceeds some value.

3.2.2.4.  IPv4 Header Construction

When encapsulating a IPv6 packet in an IPv4 datagram, the IPv4 header
fields are set as follows:

        Version:

                4

        IP Header Length in 32-bit words:

                5 (There are no IPv4 options in the encapsulating
                header.)




draft-gilligan-ipv6-trans-mech-00.txt                          [Page 13]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


        Type of Service:

                0

        Total Length:

                Payload length from IPv6 header plus length of IPv6 and
                IPv4 headers (i.e. a constant 60 bytes).

        Identification:

                Generated uniquely as for any IPv4 packet transmitted by
                the host function in the system.

        Flags:

                Set the Don't Fragment (DF) flag if performing IPv4
                Path MTU Discovery; Clear the DF flag otherwise.  Set
                the More Fragments (MF) bit as necessary if
                fragmenting.

        Fragment offset:

                Set as necessary if fragmenting.

        Time to Live:

                Copied from the IPv6 hop limit field.

        Protocol:

                41 (Assigned payload type number for IPv6)

        Header Checksum:

                Calculate the checksum of the IPv4 header.

        Source Address:

                IPv4 address of outgoing interface of the
                encapsulating node.

        Destination Address:

                IPv4 address of of tunnel endpoint.

Any IPv6 options are preserved in the packet (after the IPv6 header).




draft-gilligan-ipv6-trans-mech-00.txt                          [Page 14]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


3.2.2.5 Decapsulating IPv6-in-IPv4 Packets

When an IPv6/IPv4 host or a router receives an IPv4 datagram destined to
one of its IPv4 address with the protocol field set to 41 it MUST
decapsulate the IPv6 datagram and submit it to the IPv6 layer code.

The decapsulation is shown below:

        +-------------+
        |    IPv4     |
        |   Header    |
        +-------------+                 +-------------+
        |    IPv6     |                 |    IPv6     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |  Transport  |                 |  Transport  |
        |   Layer     |      ===>       |   Layer     |
        |   Header    |                 |   Header    |
        +-------------+                 +-------------+
        |             |                 |             |
        ~    Data     ~                 ~    Data     ~
        |             |                 |             |
        +-------------+                 +-------------+

                    Decapsulating IPv6 from IPv4

When decapsulating the IPv6-in-IPv4 packet only one field in the IPv6
header is modified:

        Hop Limit:
                TTL value copied from the encapsulating IPv4 header.

Then the encapsulating IPv4 header is discarded.

Note that the decapsulating node performs IPv4 reassembly before
decapsulating the IPv6 packet.  So all IPv6 options are preserved even
if the encapsulated IPv4 packet is fragmented.

After the IPv6 packet is decapsulated, it is treated the same as any
received IPv6 packet.


3.3. Packet Format Sending Algorithms

IPv6/IPv4 nodes need to directly interoperate with both IPv4 and IPv6
nodes, and be able to tunnel IPv6 traffic over IPv4.  This means that
they must be capable of sending datagrams with three different header
formats:



draft-gilligan-ipv6-trans-mech-00.txt                          [Page 15]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


   -    IPv4
   -    IPv6
   -    IPv6 encapsulated within IPv4

The determination of which header format to use in which circumstances
is termed the "sending rules".  These rules were designed with a few
general objectives in mind:

   1)   The sender should formulate a datagram in a format (IPv4 or
        IPv6) that the recipient can accept.  By generating the correct
        packet at the sender, the packet will not have to be translated
        before it is delivered to the final destination.

   2)   The sender should use an IPv6 format in the case where the
        recipient can accept both IPv4 and IPv6.  This will cause IPv6
        to be used as early as possible in the transition.

   3)   The sender should use the "raw" (un-encapsulated) IPv4 or IPv6
        packet format when the recipient is located on the same subnet
        as the sender.  Encapsulation is never necessary when the
        destination is located on the same subnet.

   4)   Automatic tunneling (IPv6 encapsulated in IPv4 carried all the
        way to the end destination) should only be used if it is not
        possible to send IPv6 format packets.

   5)   Nodes should not use configured tunneling unless explicitly
        configured to do so.  The administrative complexity of
        configured tunneling is high, so it should be avoided if
        possible.

The sending rules take into account a number of things:

  -     What packet format (IPv4 or IPv6) the intended recipient is
        capable of accepting.

  -     Whether the destination is located on-subnet or off-subnet.

  -     What type of packet the next hop router (if there is one) can
        accept.

3.3.1. Default Sending Rules

The default sending rules for IPv6/IPv4 hosts are:

  1)    If the address of the end node is an IPv4 address or an
        IPv4-mapped IPv6 address (i.e. bears the prefix 0:0:0:0:0:0),
        then:



draft-gilligan-ipv6-trans-mech-00.txt                          [Page 16]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


          1.1)  If the destination is located on the attached subnet,
                then send an IPv4 packet.  The IPv4 destination address
                is the IPv4 address of the end node (low-order 32-bits
                of the end node's IPv4-mapped IPv6 address).

          1.2)  If the destination is located off subnet, then;

                1.2.1)  If there is an IPv4 router on subnet, then send
                        an IPv4 format packet.  The IPv4 destination
                        address is the IPv4 address of the end node.
                        The datalink address is the datalink address of
                        the IPv4 router.

                1.2.2)  Else, if there is an IPv6 router on subnet, then
                        send an IPv6 format packet.  The IPv6 address is
                        the IPv4-mapped IPv6 address of the end node
                        (its IPv4 address prefixed by 0:0:0:0:0:0).  The
                        datalink address is the datalink address of the
                        IPv6 router.

                1.2.3)  Else, the destination is treated as
                        "unreachable" because it is located off subnet
                        and there are no on subnet routers.

  2)    If the address of the end node is an IPv4-compatible IPv6
        address (i.e. bears the prefix 0:0:0:0:0:ffff), then:

          2.1)  If the destination is located on the attached subnet,
                then send an IPv6 format packet.  The IPv6
                destination address is the IPv6 address of the end
                node.  The datalink address is the datalink address of
                the end node.

          2.2)  If the destination is located off subnet, then:

                2.2.1)  If there is an IPv6 router on the attached
                        subnet, then send an IPv6 format packet.  The
                        IPv6 destination address is the IPv6 address of
                        the end node.  The datalink address is the
                        datalink address of the IPv6 router.

                2.2.2)  Else, if there is an IPv4 router on the attached
                        subnet, then send an IPv6 packet encapsulated in
                        IPv4.  The IPv6 destination address is address
                        of the end node.  The IPv4 destination address
                        is the low-order 32-bits of the end node's
                        address.  The datalink address is the datalink
                        address of the IPv4 router.



draft-gilligan-ipv6-trans-mech-00.txt                          [Page 17]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


                2.2.3)  Else, the destination is treated as
                        "unreachable" because it is located off-subnet
                        and there are no on-subnet routers.

   3)   If the address of the end node is an IPv6-only address, then:

          3.1)  If the destination is located on the attached subnet,
                then send an IPv6 format packet.  The IPv6
                destination address is the IPv6 address of the end
                node.  The datalink address is the datalink address of
                the end node.

          3.2)  If the destination is located off subnet, then:

                2.2.1)  If there is an IPv6 router on the attached
                        subnet, then send an IPv6 format packet.  The
                        IPv6 destination address is the IPv6 address
                        of the end node.  The datalink address is the
                        datalink address of the IPv6 router.

                2.2.3)  Else, the destination is treated as
                        "unreachable" because it is located off-subnet
                        and there are no on-subnet IPv6 routers.

A summary of the default sending rules are given in the table below:


























draft-gilligan-ipv6-trans-mech-00.txt                          [Page 18]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


End         | End     | IPv4    | IPv6    | packet |      |      |
Node        | Node    | Router  | Router  | Format | IPv6 | IPv4 | DLink
Address     | On      | On      | On      | To     | Dest | Dest | Dest
Type        | Subnet? | Subnet? | Subnet? | Send   | Addr | Addr | Addr
------------+---------+---------+---------+--------+------+------+------
IPv4 or     |         |         |         |        |      |      |
IPv4-mapped | Yes     |  N/A    |  N/A    | IPv4   | N/A  |  E4  | EL
------------+---------+---------+---------+--------+------+------+------
IPv4 or     |         |         |         |        |      |      |
IPv4-mapped | No      |  Yes    |  N/A    | IPv4   | N/A  |  E4  | RL
------------+---------+---------+---------+--------+------+------+------
IPv4 or     |         |         |         |        |      |      |
IPv4-mapped | No      |  No     |  Yes    | IPv6   |  E6  | N/A  | RL
------------+---------+---------+---------+--------+------+------+------
IPv4-compat | Yes     |  N/A    |  N/A    | IPv6   |  E6  | N/A  | EL
------------+---------+---------+---------+--------+------+------+------
IPv4-compat | No      |  N/A    |  Yes    | IPv6   |  E6  | N/A  | RL
------------+---------+---------+---------+--------+------+------+------
IPv4-compat | No      |  Yes    |  No     | IPv6/4 |  E6  | E4   | RL
------------+---------+---------+---------+--------+------+------+------
IPv6-only   | Yes     |  N/A    |  N/A    | IPv6   |  E6  | N/A  | EL
------------+---------+---------+---------+--------+------+------+------
IPv6-only   | No      |  N/A    |  Yes    | IPv6   |  E6  | N/A  | RL
------------+---------+---------+---------+--------+------+------+------

        Key to Abbreviations
        --------------------
        N/A:    Not applicable or does not matter.
        E6:     IPv6 address of end node.
        E4:     IPv4 address of end node (low-order 32-bits of
                IPv4-mapped or IPv4-compatible address).
        EL:     Datalink address of end node.
        R6:     IPv6 address of router.
        R4:     IPv4 address of router.
        RL:     Datalink address of router.
        IPv4:   IPv4 packet format.
        IPv6:   IPv6 packet format.
        IPv6/4: IPv6 encapsulated in IPv4 packet format.

The general requirements for implementing the default sending rules are:

   *    IPv6/IPv4 hosts MUST implement the default sending rules.

   *    IPv6/IPv4 hosts SHOULD provide a mechanism for the administrator
        to over-ride the default sending rules and provide some other
        rules.

   *    IPv6/IPv4 routers MAY implement the default sending rules.



draft-gilligan-ipv6-trans-mech-00.txt                          [Page 19]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


3.3.2. Host On/Off Subnet Determination

Part of the process of determining what packet format to use includes
determining whether a destination is located on an attached subnet or
not.  IPv4 and IPv6 hosts employ different mechanisms.  IPv4 hosts
uses an algorithm in which the destination address and the interface
address are both logically ANDed with the netmask of the interface.
If the resulting two values are equivalent, then the destination is
located on-subnet.  This algorithm is discussed in more detail in
Section 3.3.1.1 of the document "Requirements for Internet Hosts --
Communications Layers" [RFC1122].  IPv6 uses the neighbor discovery
algorithm described in "IPv6 Neighbor Discovery -- Processing"
[IPv6-NABOR].

When IPv6/IPv4 nodes are sending packets, they must employ both methods
as follows:

   -    If a destination is represented by an IPv4 address or an
        IPv4-mapped IPv6 address (prefix 0:0:0:0:0:0), then the on/off
        subnet determination is made by comparison with the netmask, as
        described in RFC 1122 section 3.3.1.1.  If the destination is an
        IPv4-mapped address, the algorithm uses only the low-order
        32-bits of that address (the IPv4 address part).

   -    If a destination is represented by an IP4-compatible IPv6
        address (prefix 0:0:0:0:0:ffff) or an IPv6-only address (any
        other prefix), and IPv6 router advertisements have been heard,
        then the on/off subnet determination is made using the IPv6
        system discovery mechanism.  If no IPv6 router advertisements
        have been heard, then the decision is made using the IPv4
        netmask comparison algorithm using the low-order 32-bits (IPv4
        address part) of the destination address.

  -     If the destination is represented by an IPv6-only address
        (prefix other than 0:0:0:0:0:0 or 0:0:0:0:0:ffff), the on/off
        subnet determination is made using the IPv6 system discovery
        mechanism.

3.4. Address Configuration

Because they provide a complete IPv6 implementation, IPv6/IPv4 hosts are
expected to implement the IPv6 address configuration mechanisms
specified in the IPv6 Address Configuration specification [IPv6-ACONF].
The address configuration protocol may provide an IPv6/IPv4 host with an
IPv4-compatible or an IPv6-only address.

There is also another mode of address configuration available to
IPv6/IPv4 nodes: They may use an IPv4-based address configuration



draft-gilligan-ipv6-trans-mech-00.txt                          [Page 20]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


protocol to acquire an IPv4 address, then "map" that address into an
IPv4-compatible IPv6 address.  This mode of configuration allows
IPv6/IPv4 nodes to "leverage" the installed base of IPv4 address
configuration servers.  It is particularly useful in the early stages of
transition before IPv6 routers and address configuration servers are
deployed.

The specific algorithm for acquiring an IPv4-compatible address using
IPv4-based address configuration protocols is as follows:

   1)   The IPv6/IPv4 host uses standard IPv4 mechanisms protocols to
        acquire its own IPv4 address.  These include:

           -    Dynamic Host Configuration Protocol [DHCP]
           -    Bootp [BOOTP]
           -    Reverse Address Resolution Protocol [RARP]
           -    Manual configuration
           -    Any other mechanism which accurately yields the host's
                own IPv4 address

   2)   The host prepends the 96-bit prefix 0:0:0:0:0:ffff to the
        32-bit IPv4 address that it acquired in step (1).  The result
        is an IPv4-compatible IPv6 address with its own IPv4-address
        embedded in the low-order 32-bits.

   3)   The host uses the resulting IPv6 address as its own IPv6
        address.

Because of its utility in the early stages of transition, address
configuration based on IPv4 protocols is a feature that should be
supported by all IPv6/IPv4 nodes.  Support of IPv4-based address
configuration does not relieve a host of its requirement to implement
the IPv6 address configuration protocol, however:

   *    IPv6/IPv4 hosts SHOULD support address configuration using
        IPv4-based address configuration protocols.

   *    IPv6/IPv4 hosts MUST support address configuration using the
        IPv6 address configuration protocol [IPv6-ACONF].

3.5. Source Address Selection

IPv6/IPv4 nodes may be configured with both IPv6-only and
IPv4-compatible addresses, and may even have one or more of both types
of address configured on a single interface.  In order to properly
interoperate with IPv4 nodes, they must choose the correct source
address.  When interoperating with an IPv4-only node, only an
IPv4-compatible address may be used as a source address.  An IPv6-only



draft-gilligan-ipv6-trans-mech-00.txt                          [Page 21]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


address can not be used used as a source address when interoperating
with an IPv4-only node.

The source address selection rules are:

   *    When originating an IPv4 datagram, an IPv6/IPv4 node MUST use
        the low-order 32-bits of one of its own IPv4-compatible
        addresses as the source IPv4 address.  If the originating node
        is configured with no IPv4-compatible addresses, it MUST treat
        the destination as "unreachable".

   *    When originating an IPv6 datagram to a destination represented
        by IPv4-mapped addresses, an IPv6/IPv4 node MUST use one its own
        IPv4-compatible addresses as the source IPv6 address.  If the
        originating node is configured with no IPv4-compatible
        addresses, it MUST treat the destination as "unreachable".

There are no restrictions on which source addresses may be used when
originating datagrams to other IPv6 nodes.  Either IPv4-compatible or
IPv6-only addresses may be used.































draft-gilligan-ipv6-trans-mech-00.txt                          [Page 22]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


4. IPv6-only Node Requirements

This section presents the requirements of IPv6-only hosts and routers.

4.1. General Requirements

   *    IPv6-only hosts and routers MUST provide a complete IPv6
        implementation [IPv6].

4.2. Sending Rules

No special sending rules are required for IPv6-only nodes.  Since they
nodes are not capable of sending IPv4 or IPv6-in-IPv4 format packets,
all packets originated by IPv6-only nodes are IPv6 datagrams.

IPv6-only nodes route datagrams addressed to IPv4-mapped,
IPv4-compatible and IPv6-only addresses the same way.  All are routed
according to the algorithms given in the IPv6 and neighbor discovery
specifications ([IPv6] and [IPv6-NBOR]).

On a correctly configured IPv6-only node, no IPv4-mapped address will
ever appear to be on a locally attached subnet.  So, when originating
a packet destined to an IPv4-mapped addresses, an IPv6 node wil alway
send the packet to an IPv6 router.  The packet will be translated to
IPv4 before being delivered to the destination IPv4 node.

4.3. Source Address Selection

IPv6-only nodes have similar requirements to IPv6/IPv4 nodes regarding
selection of source address when interoperating with IPv4-only nodes.
Like IPv6/IPv4 nodes, IPv6-only nodes may be configured with both
IPv6-only and IPv4-compatible addresses, and a single interface may be
configured with both types of address.

The source address selection rule for IPv6-only nodes are:

   *    When originating an IPv6 datagram to a destination represented
        by an IPv4-mapped addresses, an IPv6-only node MUST use one its
        own IPv4-compatible addresses as the source IPv6 address.  If
        the originating node is configured with no IPv4-compatible
        addresses, it MUST treat the destination as "unreachable".

There are no restrictions on which source addresses may be used when
originating datagrams to other IPv6 nodes.  Either IPv4-compatible or
IPv6-only addresses may be used.






draft-gilligan-ipv6-trans-mech-00.txt                          [Page 23]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


5. Author's Address

        Robert E. Gilligan
        Sun Microsystems, Inc.
        2550 Garcia Ave.
        Mailstop UMTV 05-44
        Mountain View, California 94043

        415-336-1012 (voice)
        415-336-6015 (fax)

        Bob.Gilligan@Eng.Sun.COM


        Erik Nordmark
        Sun Microsystems, Inc.
        2550 Garcia Ave.
        Mailstop UMTV 05-44
        Mountain View, California 94043

        415-336-2788 (voice)
        415-336-6015 (fax)

        Erik.Nordmark@Eng.Sun.COM



6. References

[BOOTP]         W. Croft, J. Gilmore.  Bootstrap Protocol.  RFC 951.
                September 1985.

[DHCP]          R. Droms.  Dynamic Host Configuration Protocol.  RFC
                1541.  October 1993.

[IPv6]          R. Hinden. Internet Protocol, Version 6 (IPv6)
                Specification.  Internet Draft
                <draft-hinden-ipng-ipv6-spec-00.txt>.  October 1994.

[IPv6-ACONF]    IPv6 Address Configuration.  Internet Draft to be
                written.

[IPv6-ADDR]     R. Hinden. IP Next Generation Addressing Architecture.
                Internet Draft <draft-hinden-ipng-addr-00.txt>.  October
                1994.

[IPv6-DISC]     W. A. Simpson.  IPv6 Neighbor Discovery -- ICMP Message
                Formats. Internet Draft



draft-gilligan-ipv6-trans-mech-00.txt                          [Page 24]


INTERNET-DRAFT         IPv6 Transition Mechanisms          November 1994


                <draft-simpson-ipv6-discov-formats-00.txt>.  September
                1994.

[IPv6-NBOR]     W. A. Simpson. IPv6 Neighbor Discovery -- Processing.
                Internet Draft
                <draft-simpson-ipv6-discov-process-00.txt>.  October
                1994.

[TRANS-OVER]    R. Gilligan.  Simple Internet Transition Overview.
                Internet Draft
                <draft-gilligan-ipv6-sit-overview-00.txt>.  October
                1994.

[TRANS-XLATE]   IPv6 Transition Mechanisms for Header Translating
                Routers.  Internet Draft to be written.

[TRANS-PLAN]    IPv6 Transition Plan.  Internet Draft to be written.

[RFC-1191]      J. Mogul, S. Deering.  Path MTU Discovery. RFC 1191.
                November 1990.

[RARP]          R. Finlayson, T. Mann, J. Mogul, M. Theimer. Reverse
                Address Resolution Protocol.  RFC 903.  June 1984.

[RFC-1123]      R. Braden. Requirements for Internet Hosts - Application
                And Support. RFC 1123. October 1989.

























draft-gilligan-ipv6-trans-mech-00.txt                          [Page 25]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/