doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

diff --git a/doc/rfc/rfc2893.txt b/doc/rfc/rfc2893.txt
new file mode 100644
index 0000000..8095f31
--- /dev/null
+++ b/doc/rfc/rfc2893.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Network Working Group                                        R. Gilligan
+Request for Comments: 2893                                FreeGate Corp.
+Obsoletes: 1933                                              E. Nordmark
+Category: Standards Track                         Sun Microsystems, Inc.
+                                                             August 2000
+
+
+            Transition Mechanisms for IPv6 Hosts and Routers
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document specifies IPv4 compatibility mechanisms that can be
+   implemented by IPv6 hosts and routers.  These mechanisms include
+   providing complete implementations of both versions of the Internet
+   Protocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4
+   routing infrastructures.  They are designed to allow IPv6 nodes to
+   maintain complete compatibility with IPv4, which should greatly
+   simplify the deployment of IPv6 in the Internet, and facilitate the
+   eventual transition of the entire Internet to IPv6.  This document
+   obsoletes RFC 1933.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan & Nordmark         Standards Track                     [Page 1]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+Table of Contents
+
+   1.  Introduction.............................................    2
+      1.1.  Terminology.........................................    3
+      1.2.  Structure of this Document..........................    5
+   2.  Dual IP Layer Operation..................................    6
+      2.1.  Address Configuration...............................    7
+      2.2.  DNS.................................................    7
+      2.3.  Advertising Addresses in the DNS....................    8
+   3.  Common Tunneling Mechanisms..............................    9
+      3.1.  Encapsulation.......................................   11
+      3.2.  Tunnel MTU and Fragmentation........................   11
+      3.3.  Hop Limit...........................................   13
+      3.4.  Handling IPv4 ICMP errors...........................   13
+      3.5.  IPv4 Header Construction............................   15
+      3.6.  Decapsulation.......................................   16
+      3.7.  Link-Local Addresses................................   17
+      3.8.  Neighbor Discovery over Tunnels.....................   18
+   4.  Configured Tunneling.....................................   18
+      4.1.  Default Configured Tunnel...........................   19
+      4.2.  Default Configured Tunnel using IPv4 "Anycast Address" 19
+      4.3.  Ingress Filtering...................................   20
+   5.  Automatic Tunneling......................................   20
+      5.1.  IPv4-Compatible Address Format......................   20
+      5.2.  IPv4-Compatible Address Configuration...............   21
+      5.3.  Automatic Tunneling Operation.......................   22
+      5.4.  Use With Default Configured Tunnels.................   22
+      5.5.  Source Address Selection............................   23
+      5.6.  Ingress Filtering...................................   23
+   6.  Acknowledgments..........................................   24
+   7.  Security Considerations..................................   24
+   8.  Authors' Addresses.......................................   24
+   9.  References...............................................   25
+   10.  Changes from RFC 1933...................................   26
+   11.  Full Copyright Statement................................   29
+
+1.  Introduction
+
+   The key to a successful IPv6 transition is compatibility with the
+   large installed base of IPv4 hosts and routers.  Maintaining
+   compatibility with IPv4 while deploying IPv6 will streamline the task
+   of transitioning the Internet to IPv6.  This specification defines a
+   set of mechanisms that IPv6 hosts and routers may implement in order
+   to be compatible with IPv4 hosts and routers.
+
+   The mechanisms in this document are designed to be employed by IPv6
+   hosts and routers that need to interoperate with IPv4 hosts and
+   utilize IPv4 routing infrastructures.  We expect that most nodes in
+
+
+
+Gilligan & Nordmark         Standards Track                     [Page 2]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+   the Internet will need such compatibility for a long time to come,
+   and perhaps even indefinitely.
+
+   However, IPv6 may be used in some environments where interoperability
+   with IPv4 is not required.  IPv6 nodes that are designed to be used
+   in such environments need not use or even implement these mechanisms.
+
+   The mechanisms specified here include:
+
+   -  Dual IP layer (also known as Dual Stack):  A technique for
+      providing complete support for both Internet protocols -- IPv4 and
+      IPv6 -- in hosts and routers.
+
+   -  Configured tunneling of IPv6 over IPv4:  Point-to-point tunnels
+      made by encapsulating IPv6 packets within IPv4 headers to carry
+      them over IPv4 routing infrastructures.
+
+   -  IPv4-compatible IPv6 addresses:  An IPv6 address format that
+      employs embedded IPv4 addresses.
+
+   -  Automatic tunneling of IPv6 over IPv4:  A mechanism for using
+      IPv4-compatible addresses to automatically tunnel IPv6 packets
+      over IPv4 networks.
+
+   The mechanisms defined here are intended to be part of a "transition
+   toolbox" -- a growing collection of techniques which implementations
+   and users may employ to ease the transition.  The tools may be used
+   as needed.  Implementations and sites decide which techniques are
+   appropriate to their specific needs.  This document defines the
+   initial core set of transition mechanisms, but these are not expected
+   to be the only tools available.  Additional transition and
+   compatibility mechanisms are expected to be developed in the future,
+   with new documents being written to specify them.
+
+1.1.  Terminology
+
+   The following terms are used in this document:
+
+   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 IPv4-only
+         nodes.
+
+
+
+
+
+Gilligan & Nordmark         Standards Track                     [Page 3]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+      IPv6/IPv4 node:
+
+         A host or router that implements both IPv4 and IPv6.
+
+      IPv6-only node:
+
+         A host or router that implements IPv6, and does not implement
+         IPv4.  The operation of IPv6-only nodes is not addressed here.
+
+      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.
+
+   Types of IPv6 Addresses
+
+      IPv4-compatible IPv6 address:
+
+         An IPv6 address bearing the high-order 96-bit prefix
+         0:0:0:0:0:0, and an IPv4 address in the low-order 32-bits.
+         IPv4-compatible addresses are used by IPv6/IPv4 nodes which
+         perform automatic tunneling,
+
+      IPv6-native address:
+
+         The remainder of the IPv6 address space.  An IPv6 address that
+         bears a prefix other than 0:0:0:0:0:0.
+
+   Techniques Used in the Transition
+
+      IPv6-over-IPv4 tunneling:
+
+         The technique of encapsulating IPv6 packets within IPv4 so that
+         they can be carried across IPv4 routing infrastructures.
+
+      Configured tunneling:
+
+         IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address
+         is determined by configuration information on the encapsulating
+         node.  The tunnels can be either unidirectional or
+         bidirectional.  Bidirectional configured tunnels behave as
+         virtual point-to-point links.
+
+
+
+
+Gilligan & Nordmark         Standards Track                     [Page 4]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+      Automatic tunneling:
+
+         IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address
+         is determined from the IPv4 address embedded in the IPv4-
+         compatible destination address of the IPv6 packet being
+         tunneled.
+
+      IPv4 multicast tunneling:
+
+         IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address
+         is determined using Neighbor Discovery [7].  Unlike configured
+         tunneling this does not require any address configuration and
+         unlike automatic tunneling it does not require the use of
+         IPv4-compatible addresses.  However, the mechanism assumes that
+         the IPv4 infrastructure supports IPv4 multicast.  Specified in
+         [3] and not further discussed in this document.
+
+   Other transition mechanisms, including other tunneling mechanisms,
+   are outside the scope of this document.
+
+   Modes of operation of IPv6/IPv4 nodes
+
+      IPv6-only operation:
+
+         An IPv6/IPv4 node with its IPv6 stack enabled and its IPv4
+         stack disabled.
+
+      IPv4-only operation:
+
+         An IPv6/IPv4 node with its IPv4 stack enabled and its IPv6
+         stack disabled.
+
+      IPv6/IPv4 operation:
+
+         An IPv6/IPv4 node with both stacks enabled.
+
+   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
+   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
+   document, are to be interpreted as described in [16].
+
+1.2.  Structure of this Document
+
+   The remainder of this document is organized as follows:
+
+   -  Section 2 discusses the operation of nodes with a dual IP layer,
+      IPv6/IPv4 nodes.
+
+
+
+
+
+Gilligan & Nordmark         Standards Track                     [Page 5]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+   -  Section 3 discusses the common mechanisms used in both of the
+      IPv6-over-IPv4 tunneling techniques.
+
+   -  Section 4 discusses configured tunneling.
+
+   -  Section 5 discusses automatic tunneling and the IPv4-compatible
+      IPv6 address format.
+
+2.  Dual IP Layer Operation
+
+   The most straightforward way for IPv6 nodes to remain compatible with
+   IPv4-only nodes is by providing a complete IPv4 implementation.  IPv6
+   nodes that provide a complete IPv4 and IPv6 implementations are
+   called "IPv6/IPv4 nodes."  IPv6/IPv4 nodes have the ability to send
+   and receive both IPv4 and IPv6 packets.  They can directly
+   interoperate with IPv4 nodes using IPv4 packets, and also directly
+   interoperate with IPv6 nodes using IPv6 packets.
+
+   Even though a node may be equipped to support both protocols, one or
+   the other stack may be disabled for operational reasons.  Thus
+   IPv6/IPv4 nodes may be operated in one of three modes:
+
+   -  With their IPv4 stack enabled and their IPv6 stack disabled.
+
+   -  With their IPv6 stack enabled and their IPv4 stack disabled.
+
+   -  With both stacks enabled.
+
+   IPv6/IPv4 nodes with their IPv6 stack disabled will operate like
+   IPv4-only nodes.  Similarly, IPv6/IPv4 nodes with their IPv4 stacks
+   disabled will operate like IPv6-only nodes.  IPv6/IPv4 nodes MAY
+   provide a configuration switch to disable either their IPv4 or IPv6
+   stack.
+
+   The dual IP layer technique may or may not be used in conjunction
+   with the IPv6-over-IPv4 tunneling techniques, which are described in
+   sections 3, 4 and 5.  An IPv6/IPv4 node that supports tunneling MAY
+   support only configured tunneling, or both configured and automatic
+   tunneling.  Thus three modes of tunneling support are possible:
+
+   -  IPv6/IPv4 node that does not perform tunneling.
+
+   -  IPv6/IPv4 node that performs configured tunneling only.
+
+   -  IPv6/IPv4 node that performs configured tunneling and automatic
+      tunneling.
+
+
+
+
+
+Gilligan & Nordmark         Standards Track                     [Page 6]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+2.1.  Address Configuration
+
+   Because they support both protocols, IPv6/IPv4 nodes may be
+   configured with both IPv4 and IPv6 addresses.  IPv6/IPv4 nodes use
+   IPv4 mechanisms (e.g. DHCP) to acquire their IPv4 addresses, and IPv6
+   protocol mechanisms (e.g. stateless address autoconfiguration) to
+   acquire their IPv6-native addresses.  Section 5.2 describes a
+   mechanism by which IPv6/IPv4 nodes that support automatic tunneling
+   MAY use IPv4 protocol mechanisms to acquire their IPv4-compatible
+   IPv6 address.
+
+2.2.  DNS
+
+   The Domain Naming System (DNS) is used in both IPv4 and IPv6 to map
+   between hostnames and IP addresses.  A new resource record type named
+   "A6" has been defined for IPv6 addresses [6] with support for an
+   earlier record named "AAAA".  Since IPv6/IPv4 nodes must be able to
+   interoperate directly with both IPv4 and IPv6 nodes, they must
+   provide resolver libraries capable of dealing with IPv4 "A" records
+   as well as IPv6 "A6" and "AAAA" records.
+
+   DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of handling
+   both A6/AAAA and A records.  However, when a query locates an A6/AAAA
+   record holding an IPv6 address, and an A record holding an IPv4
+   address, the resolver library MAY filter or order the results
+   returned to the application in order to influence the version of IP
+   packets used to communicate with that node.  In terms of filtering,
+   the resolver library has three alternatives:
+
+   -  Return only the IPv6 address to the application.
+
+   -  Return only the IPv4 address to the application.
+
+   -  Return both addresses to the application.
+
+   If it returns only the IPv6 address, the application will communicate
+   with the node using IPv6.  If it returns only the IPv4 address, the
+   application will communicate with the node using IPv4.  If it returns
+   both addresses, the application will have the choice which address to
+   use, and thus which IP protocol to employ.
+
+   If it returns both, the resolver MAY elect to order the addresses --
+   IPv6 first, or IPv4 first.  Since most applications try the addresses
+   in the order they are returned by the resolver, this can affect the
+   IP version "preference" of applications.
+
+
+
+
+
+
+Gilligan & Nordmark         Standards Track                     [Page 7]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+   The decision to filter or order DNS results is implementation
+   specific.  IPv6/IPv4 nodes MAY provide policy configuration to
+   control filtering or ordering of addresses returned by the resolver,
+   or leave the decision entirely up to the application.
+
+   An implementation MUST allow the application to control whether or
+   not such filtering takes place.
+
+2.3.  Advertising Addresses in the DNS
+
+   There are some constraint placed on the use of the DNS during
+   transition.  Most of these are obvious but are stated here for
+   completeness.
+
+   The recommendation is that A6/AAAA records for a node should not be
+   added to the DNS until all of these are true:
+
+      1) The address is assigned to the interface on the node.
+
+      2) The address is configured on the interface.
+
+      3) The interface is on a link which is connected to the IPv6
+         infrastructure.
+
+   If an IPv6 node is isolated from an IPv6 perspective (e.g. it is not
+   connected to the 6bone to take a concrete example) constraint #3
+   would mean that it should not have an address in the DNS.
+
+   This works great when other dual stack nodes tries to contact the
+   isolated dual stack node.  There is no IPv6 address in the DNS thus
+   the peer doesn't even try communicating using IPv6 but goes directly
+   to IPv4 (we are assuming both nodes have A records in the DNS.)
+
+   However, this does not work well when the isolated node is trying to
+   establish communication.  Even though it does not have an IPv6
+   address in the DNS it will find A6/AAAA records in the DNS for the
+   peer.  Since the isolated node has IPv6 addresses assigned to at
+   least one interface it will try to communicate using IPv6.  If it has
+   no IPv6 route to the 6bone (e.g. because the local router was
+   upgraded to advertise IPv6 addresses using Neighbor Discovery but
+   that router doesn't have any IPv6 routes) this communication will
+   fail.  Typically this means a few minutes of delay as TCP times out.
+   The TCP specification says that ICMP unreachable messages could be
+   due to routing transients thus they should not immediately terminate
+   the TCP connection.  This means that the normal TCP timeout of a few
+   minutes apply.  Once TCP times out the application will hopefully try
+   the IPv4 addresses based on the A records in the DNS, but this will
+   be painfully slow.
+
+
+
+Gilligan & Nordmark         Standards Track                     [Page 8]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+   A possible implication of the recommendations above is that, if one
+   enables IPv6 on a node on a link without IPv6 infrastructure, and
+   choose to add A6/AAAA records to the DNS for that node, then external
+   IPv6 nodes that might see these A6/AAAA records will possibly try to
+   reach that node using IPv6 and suffer delays or communication failure
+   due to unreachability.  (A delay is incurred if the application
+   correctly falls back to using IPv4 if it can not establish
+   communication using IPv6 addresses.  If this fallback is not done the
+   application would fail to communicate in this case.)  Thus it is
+   suggested that either the recommendations be followed, or care be
+   taken to only do so with nodes that will not be impacted by external
+   accessing delays and/or communication failure.
+
+   In the future when a site or node removes the support for IPv4 the
+   above recommendations apply to when the A records for the node(s)
+   should be removed from the DNS.
+
+3.  Common Tunneling Mechanisms
+
+   In most deployment scenarios, the IPv6 routing infrastructure will be
+   built up over time.  While the IPv6 infrastructure is being deployed,
+   the existing IPv4 routing infrastructure can remain functional, and
+   can be used to carry IPv6 traffic.  Tunneling provides a way to
+   utilize an existing IPv4 routing infrastructure to carry IPv6
+   traffic.
+
+   IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of
+   IPv4 routing topology by encapsulating them within IPv4 packets.
+   Tunneling can be used in a variety of ways:
+
+   -  Router-to-Router.  IPv6/IPv4 routers interconnected by an IPv4
+      infrastructure can tunnel IPv6 packets between themselves.  In
+      this case, the tunnel spans one segment of the end-to-end path
+      that the IPv6 packet takes.
+
+   -  Host-to-Router.  IPv6/IPv4 hosts can tunnel IPv6 packets to an
+      intermediary IPv6/IPv4 router that is reachable via an IPv4
+      infrastructure.  This type of tunnel spans the first segment of
+      the packet's end-to-end path.
+
+   -  Host-to-Host.  IPv6/IPv4 hosts that are interconnected by an IPv4
+      infrastructure can tunnel IPv6 packets between themselves.  In
+      this case, the tunnel spans the entire end-to-end path that the
+      packet takes.
+
+   -  Router-to-Host.  IPv6/IPv4 routers can tunnel IPv6 packets to
+      their final destination IPv6/IPv4 host.  This tunnel spans only
+      the last segment of the end-to-end path.
+
+
+
+Gilligan & Nordmark         Standards Track                     [Page 9]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+   Tunneling techniques are usually classified according to the
+   mechanism by which the encapsulating node determines the address of
+   the node at the end of the tunnel.  In the first two tunneling
+   methods listed above -- router-to-router and host-to-router -- the
+   IPv6 packet is being tunneled to a router.  The endpoint of this type
+   of tunnel is an intermediary router which must decapsulate the IPv6
+   packet and forward it on to its final destination.  When tunneling to
+   a router, the endpoint of the tunnel is different from the
+   destination of the packet being tunneled.  So the addresses in the
+   IPv6 packet being tunneled can not provide the IPv4 address of the
+   tunnel endpoint.  Instead, the tunnel endpoint address must be
+   determined from configuration information on the node performing the
+   tunneling.  We use the term "configured tunneling" to describe the
+   type of tunneling where the endpoint is explicitly configured.
+
+   In the last two tunneling methods -- host-to-host and router-to-host
+   -- the IPv6 packet is tunneled all the way to its final destination.
+   In this case, the destination address of both the IPv6 packet and the
+   encapsulating IPv4 header identify the same node!  This fact can be
+   exploited by encoding information in the IPv6 destination address
+   that will allow the encapsulating node to determine tunnel endpoint
+   IPv4 address automatically.  Automatic tunneling employs this
+   technique, using an special IPv6 address format with an embedded IPv4
+   address to allow tunneling nodes to automatically derive the tunnel
+   endpoint IPv4 address.  This eliminates the need to explicitly
+   configure the tunnel endpoint address, greatly simplifying
+   configuration.
+
+   The two tunneling techniques -- automatic and configured -- differ
+   primarily in how they determine the tunnel endpoint address.  Most of
+   the underlying mechanisms are the same:
+
+   -  The entry node of the tunnel (the encapsulating node) creates an
+      encapsulating IPv4 header and transmits the encapsulated packet.
+
+   -  The exit node of the tunnel (the decapsulating node) receives the
+      encapsulated packet, reassembles the packet if needed, removes the
+      IPv4 header, updates the IPv6 header, and processes the received
+      IPv6 packet.
+
+   -  The encapsulating node MAY need to maintain soft state information
+      for each tunnel recording such parameters as the MTU of the tunnel
+      in order to process IPv6 packets forwarded into the tunnel.  Since
+      the number of tunnels that any one host or router may be using may
+      grow to be quite large, this state information can be cached and
+      discarded when not in use.
+
+
+
+
+
+Gilligan & Nordmark         Standards Track                    [Page 10]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+   The remainder of this section discusses the common mechanisms that
+   apply to both types of tunneling.  Subsequent sections discuss how
+   the tunnel endpoint address is determined for automatic and
+   configured tunneling.
+
+3.1.  Encapsulation
+
+   The encapsulation of an IPv6 datagram in IPv4 is shown below:
+
+                                             +-------------+
+                                             |    IPv4     |
+                                             |   Header    |
+             +-------------+                 +-------------+
+             |    IPv6     |                 |    IPv6     |
+             |   Header    |                 |   Header    |
+             +-------------+                 +-------------+
+             |  Transport  |                 |  Transport  |
+             |   Layer     |      ===>       |   Layer     |
+             |   Header    |                 |   Header    |
+             +-------------+                 +-------------+
+             |             |                 |             |
+             ~    Data     ~                 ~    Data     ~
+             |             |                 |             |
+             +-------------+                 +-------------+
+
+                      Encapsulating IPv6 in IPv4
+
+   In addition to adding an IPv4 header, the encapsulating node also has
+   to handle some more complex issues:
+
+   -  Determine when to fragment and when to report an ICMP "packet too
+      big" error back to the source.
+
+   -  How to reflect IPv4 ICMP errors from routers along the tunnel path
+      back to the source as IPv6 ICMP errors.
+
+   Those issues are discussed in the following sections.
+
+3.2.  Tunnel MTU and Fragmentation
+
+   The encapsulating node could view encapsulation as IPv6 using IPv4 as
+   a link layer with a very large MTU (65535-20 bytes to be exact; 20
+   bytes "extra" are needed for the encapsulating IPv4 header).  The
+   encapsulating node would need only to report IPv6 ICMP "packet too
+   big" errors back to the source for packets that exceed this MTU.
+   However, such a scheme would be inefficient for two reasons:
+
+
+
+
+
+Gilligan & Nordmark         Standards Track                    [Page 11]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+   1) It would result in more fragmentation than needed.  IPv4 layer
+      fragmentation SHOULD be avoided due to the performance problems
+      caused by the loss unit being smaller than the retransmission unit
+      [11].
+
+   2) Any IPv4 fragmentation occurring inside the tunnel would have to
+      be reassembled at the tunnel endpoint.  For tunnels that terminate
+      at a router, this would require additional memory to reassemble
+      the IPv4 fragments into a complete IPv6 packet before that packet
+      could be forwarded onward.
+
+   The fragmentation inside the tunnel can be reduced to a minimum by
+   having the encapsulating node track the IPv4 Path MTU across the
+   tunnel, using the IPv4 Path MTU Discovery Protocol [8] and recording
+   the resulting path MTU.  The IPv6 layer in the encapsulating node can
+   then view a tunnel as a link layer with an MTU equal to the IPv4 path
+   MTU, minus the size of the encapsulating IPv4 header.
+
+   Note that this does not completely eliminate IPv4 fragmentation in
+   the case when the IPv4 path MTU would result in an IPv6 MTU less than
+   1280 bytes. (Any link layer used by IPv6 has to have an MTU of at
+   least 1280 bytes [4].) In this case the IPv6 layer has to "see" a
+   link layer with an MTU of 1280 bytes and the encapsulating node has
+   to use IPv4 fragmentation in order to forward the 1280 byte IPv6
+   packets.
+
+   The encapsulating node can employ the following algorithm to
+   determine when to forward an IPv6 packet that is larger than the
+   tunnel's path MTU using IPv4 fragmentation, and when to return an
+   IPv6 ICMP "packet too big" message:
+
+        if (IPv4 path MTU - 20) is less than or equal to 1280
+                if packet is larger than 1280 bytes
+                        Send IPv6 ICMP "packet too big" with MTU = 1280.
+                        Drop packet.
+                else
+                        Encapsulate but do not set the Don't Fragment
+                        flag in the IPv4 header.  The resulting IPv4
+                        packet might be fragmented by the IPv4 layer on
+                        the encapsulating node or by some router along
+                        the IPv4 path.
+                endif
+        else
+                if packet is larger than (IPv4 path MTU - 20)
+                        Send IPv6 ICMP "packet too big" with
+                        MTU = (IPv4 path MTU - 20).
+                        Drop packet.
+                else
+
+
+
+Gilligan & Nordmark         Standards Track                    [Page 12]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+                        Encapsulate and set the Don't Fragment flag
+                        in the IPv4 header.
+                endif
+        endif
+
+   Encapsulating nodes that have a large number of tunnels might not be
+   able to store the IPv4 Path MTU for all tunnels.  Such nodes can, at
+   the expense of additional fragmentation in the network, avoid using
+   the IPv4 Path MTU algorithm across the tunnel and instead use the MTU
+   of the link layer (under IPv4) in the above algorithm instead of the
+   IPv4 path MTU.
+
+   In this case the Don't Fragment bit MUST NOT be set in the
+   encapsulating IPv4 header.
+
+3.3.  Hop Limit
+
+   IPv6-over-IPv4 tunnels are modeled as "single-hop".  That is, the
+   IPv6 hop limit is decremented by 1 when an IPv6 packet traverses the
+   tunnel.  The single-hop model serves to hide the existence of a
+   tunnel.  The tunnel is opaque to users of the network, and is not
+   detectable by network diagnostic tools such as traceroute.
+
+   The single-hop model is implemented by having the encapsulating and
+   decapsulating nodes process the IPv6 hop limit field as they would if
+   they were forwarding a packet on to any other datalink.  That is,
+   they decrement the hop limit by 1 when forwarding an IPv6 packet.
+   (The originating node and final destination do not decrement the hop
+   limit.)
+
+   The TTL of the encapsulating IPv4 header is selected in an
+   implementation dependent manner.  The current suggested value is
+   published in the "Assigned Numbers RFC.  Implementations MAY provide
+   a mechanism to allow the administrator to configure the IPv4 TTL such
+   as the one specified in the IP Tunnel MIB [17].
+
+3.4.  Handling IPv4 ICMP errors
+
+   In response to encapsulated packets it has sent into the tunnel, the
+   encapsulating node might receive IPv4 ICMP error messages from IPv4
+   routers inside the tunnel.  These packets are addressed to the
+   encapsulating node because it is the IPv4 source of the encapsulated
+   packet.
+
+
+
+
+
+
+
+
+Gilligan & Nordmark         Standards Track                    [Page 13]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+   The ICMP "packet too big" error messages are handled according to
+   IPv4 Path MTU Discovery [8] and the resulting path MTU is recorded in
+   the IPv4 layer.  The recorded path MTU is used by IPv6 to determine
+   if an IPv6 ICMP "packet too big" error has to be generated as
+   described in section 3.2.
+
+   The handling of other types of ICMP error messages depends on how
+   much information is included in the "packet in error" field, which
+   holds the encapsulated packet that caused the error.
+
+   Many older IPv4 routers return only 8 bytes of data beyond the IPv4
+   header of the packet in error, which is not enough to include the
+   address fields of the IPv6 header.  More modern IPv4 routers are
+   likely to return enough data beyond the IPv4 header to include the
+   entire IPv6 header and possibly even the data beyond that.
+
+   If the offending packet includes enough data, the encapsulating node
+   MAY extract the encapsulated IPv6 packet and use it to generate an
+   IPv6 ICMP message directed back to the originating IPv6 node, as
+   shown below:
+
+                  +--------------+
+                  | IPv4 Header  |
+                  | dst = encaps |
+                  |       node   |
+                  +--------------+
+                  |     ICMP     |
+                  |    Header    |
+           - -    +--------------+
+                  | IPv4 Header  |
+                  | src = encaps |
+          IPv4    |       node   |
+                  +--------------+   - -
+          Packet  |    IPv6      |
+                  |    Header    |   Original IPv6
+           in     +--------------+   Packet -
+                  |  Transport   |   Can be used to
+          Error   |    Header    |   generate an
+                  +--------------+   IPv6 ICMP
+                  |              |   error message
+                  ~     Data     ~   back to the source.
+                  |              |
+           - -    +--------------+   - -
+
+      IPv4 ICMP Error Message Returned to Encapsulating Node
+
+
+
+
+
+
+Gilligan & Nordmark         Standards Track                    [Page 14]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+3.5.  IPv4 Header Construction
+
+   When encapsulating an 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.)
+
+      Type of Service:
+
+         0. [Note that work underway in the IETF is redefining the Type
+         of Service byte and as a result future RFCs might define a
+         different behavior for the ToS byte when tunneling.]
+
+      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
+         system.
+
+      Flags:
+
+         Set the Don't Fragment (DF) flag as specified in section 3.2.
+         Set the More Fragments (MF) bit as necessary if fragmenting.
+
+      Fragment offset:
+
+         Set as necessary if fragmenting.
+
+      Time to Live:
+
+         Set in implementation-specific manner.
+
+      Protocol:
+
+         41 (Assigned payload type number for IPv6)
+
+
+
+
+
+
+Gilligan & Nordmark         Standards Track                    [Page 15]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+      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 tunnel endpoint.
+
+   Any IPv6 options are preserved in the packet (after the IPv6 header).
+
+3.6.  Decapsulation
+
+   When an IPv6/IPv4 host or a router receives an IPv4 datagram that is
+   addressed to one of its own IPv4 address, and the value of the
+   protocol field is 41, it reassembles if the packet if it is
+   fragmented at the IPv4 level, then it removes the IPv4 header and
+   submits the IPv6 datagram to its IPv6 layer code.
+
+   The decapsulating node MUST be capable of reassembling an IPv4 packet
+   that is 1300 bytes (1280 bytes plus IPv4 header).
+
+   The decapsulation is shown below:
+
+           +-------------+
+           |    IPv4     |
+           |   Header    |
+           +-------------+                 +-------------+
+           |    IPv6     |                 |    IPv6     |
+           |   Header    |                 |   Header    |
+           +-------------+                 +-------------+
+           |  Transport  |                 |  Transport  |
+           |   Layer     |      ===>       |   Layer     |
+           |   Header    |                 |   Header    |
+           +-------------+                 +-------------+
+           |             |                 |             |
+           ~    Data     ~                 ~    Data     ~
+           |             |                 |             |
+           +-------------+                 +-------------+
+
+                       Decapsulating IPv6 from IPv4
+
+
+
+
+
+
+
+Gilligan & Nordmark         Standards Track                    [Page 16]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+   When decapsulating the packet, the IPv6 header is not modified.
+   [Note that work underway in the IETF is redefining the Type of
+   Service byte and as a result future RFCs might define a different
+   behavior for the ToS byte when decapsulating a tunneled packet.]  If
+   the packet is subsequently forwarded, its hop limit is decremented by
+   one.
+
+   As part of the decapsulation the node SHOULD silently discard a
+   packet with an invalid IPv4 source address such as a multicast
+   address, a broadcast address, 0.0.0.0, and 127.0.0.1.  In general it
+   SHOULD apply the rules for martian filtering in [18] and ingress
+   filtering [13] on the IPv4 source address.
+
+   The encapsulating IPv4 header is discarded.
+
+   After the decapsulation the node SHOULD silently discard a packet
+   with an invalid IPv6 source address.  This includes IPv6 multicast
+   addresses, the unspecified address, and the loopback address but also
+   IPv4-compatible IPv6 source addresses where the IPv4 part of the
+   address is an (IPv4) multicast address, broadcast address, 0.0.0.0,
+   or 127.0.0.1.  In general it SHOULD apply the rules for martian
+   filtering in [18] and ingress filtering [13] on the IPv4-compatible
+   source address.
+
+   The decapsulating node performs IPv4 reassembly before decapsulating
+   the IPv6 packet.  All IPv6 options are preserved even if the
+   encapsulating IPv4 packet is fragmented.
+
+   After the IPv6 packet is decapsulated, it is processed almost the
+   same as any received IPv6 packet.  The only difference being that a
+   decapsulated packet MUST NOT be forwarded unless the node has been
+   explicitly configured to forward such packets for the given IPv4
+   source address.  This configuration can be implicit in e.g., having a
+   configured tunnel which matches the IPv4 source address.  This
+   restriction is needed to prevent tunneling to be used as a tool to
+   circumvent ingress filtering [13].
+
+3.7.  Link-Local Addresses
+
+   Both the configured and automatic tunnels are IPv6 interfaces (over
+   the IPv4 "link layer") thus MUST have link-local addresses.  The
+   link-local addresses are used by routing protocols operating over the
+   tunnels.
+
+   The Interface Identifier [14] for such an Interface SHOULD be the
+   32-bit IPv4 address of that interface, with the bytes in the same
+   order in which they would appear in the header of an IPv4 packet,
+   padded at the left with zeros to a total of 64 bits.  Note that the
+
+
+
+Gilligan & Nordmark         Standards Track                    [Page 17]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+   "Universal/Local" bit is zero, indicating that the Interface
+   Identifier is not globally unique.  When the host has more than one
+   IPv4 address in use on the physical interface concerned, an
+   administrative choice of one of these IPv4 addresses is made.
+
+   The IPv6 Link-local address [14] for an IPv4 virtual interface is
+   formed by appending the Interface Identifier, as defined above, to
+   the prefix FE80::/64.
+
+   +-------+-------+-------+-------+-------+-------+------+------+
+   |  FE      80      00      00      00      00      00     00  |
+   +-------+-------+-------+-------+-------+-------+------+------+
+   |  00      00   |  00   |  00   |   IPv4 Address              |
+   +-------+-------+-------+-------+-------+-------+------+------+
+
+3.8.  Neighbor Discovery over Tunnels
+
+   Automatic tunnels and unidirectional configured tunnels are
+   considered to be unidirectional.  Thus the only aspects of Neighbor
+   Discovery [7] and Stateless Address Autoconfiguration [5] that apply
+   to these tunnels is the formation of the link-local address.
+
+   If an implementation provides bidirectional configured tunnels it
+   MUST at least accept and respond to the probe packets used by
+   Neighbor Unreachability Detection [7].  Such implementations SHOULD
+   also send NUD probe packets to detect when the configured tunnel
+   fails at which point the implementation can use an alternate path to
+   reach the destination.  Note that Neighbor Discovery allows that the
+   sending of NUD probes be omitted for router to router links if the
+   routing protocol tracks bidirectional reachability.
+
+   For the purposes of Neighbor Discovery the automatic and configured
+   tunnels specified in this document as assumed to NOT have a link-
+   layer address, even though the link-layer (IPv4) does have address.
+   This means that a sender of Neighbor Discovery packets
+
+   -  SHOULD NOT include Source Link Layer Address options or Target
+      Link Layer Address options on the tunnel link.
+
+   -  MUST silently ignore any received SLLA or TLLA options on the
+      tunnel link.
+
+4.  Configured Tunneling
+
+   In configured tunneling, the tunnel endpoint address is determined
+   from configuration information in the encapsulating node.  For each
+   tunnel, the encapsulating node must store the tunnel endpoint
+   address.  When an IPv6 packet is transmitted over a tunnel, the
+
+
+
+Gilligan & Nordmark         Standards Track                    [Page 18]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+   tunnel endpoint address configured for that tunnel is used as the
+   destination address for the encapsulating IPv4 header.
+
+   The determination of which packets to tunnel is usually made by
+   routing information on the encapsulating node.  This is usually done
+   via a routing table, which directs packets based on their destination
+   address using the prefix mask and match technique.
+
+4.1.  Default Configured Tunnel
+
+   IPv6/IPv4 hosts that are connected to datalinks with no IPv6 routers
+   MAY use a configured tunnel to reach an IPv6 router.  This tunnel
+   allows the host to communicate with the rest of the IPv6 Internet
+   (i.e. nodes with IPv6-native addresses).  If the IPv4 address of an
+   IPv6/IPv4 router bordering the IPv6 backbone is known, this can be
+   used as the tunnel endpoint address.  This tunnel can be configured
+   into the routing table as an IPv6 "default route".  That is, all IPv6
+   destination addresses will match the route and could potentially
+   traverse the tunnel.  Since the "mask length" of such a default route
+   is zero, it will be used only if there are no other routes with a
+   longer mask that match the destination.  The default configured
+   tunnel can be used in conjunction with automatic tunneling, as
+   described in section 5.4.
+
+4.2.  Default Configured Tunnel using IPv4 "Anycast Address"
+
+   The tunnel endpoint address of such a default tunnel could be the
+   IPv4 address of one IPv6/IPv4 router at the border of the IPv6
+   backbone.  Alternatively, the tunnel endpoint could be an IPv4
+   "anycast address".  With this approach, multiple IPv6/IPv4 routers at
+   the border advertise IPv4 reachability to the same IPv4 address.  All
+   of these routers accept packets to this address as their own, and
+   will decapsulate IPv6 packets tunneled to this address.  When an
+   IPv6/IPv4 node sends an encapsulated packet to this address, it will
+   be delivered to only one of the border routers, but the sending node
+   will not know which one.  The IPv4 routing system will generally
+   carry the traffic to the closest router.
+
+   Using a default tunnel to an IPv4 "anycast address" provides a high
+   degree of robustness since multiple border router can be provided,
+   and, using the normal fallback mechanisms of IPv4 routing, traffic
+   will automatically switch to another router when one goes down.
+   However, care must be taking when using such a default tunnel to
+   prevent different IPv4 fragments from arriving at different routers
+   for reassembly.  This can be prevented by either avoiding
+   fragmentation of the encapsulated packets (by ensuring an IPv4 MTU of
+   at least 1300 bytes) or by preventing frequent changes to IPv4
+   routing.
+
+
+
+Gilligan & Nordmark         Standards Track                    [Page 19]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+4.3.  Ingress Filtering
+
+   The decapsulating node MUST verify that the tunnel source address is
+   acceptable before forwarding decapsulated packets to avoid
+   circumventing ingress filtering [13].  Note that packets which are
+   delivered to transport protocols on the decapsulating node SHOULD NOT
+   be subject to these checks.  For bidirectional configured tunnels
+   this is done by verifying that the source address is the IPv4 address
+   of the other end of the tunnel.  For unidirectional configured
+   tunnels the decapsulating node MUST be configured with a list of
+   source IPv4 address prefixes that are acceptable.  Such a list MUST
+   default to not having any entries i.e. the node has to be explicitly
+   configured to forward decapsulated packets received over
+   unidirectional configured tunnels.
+
+5.  Automatic Tunneling
+
+   In automatic tunneling, the tunnel endpoint address is determined by
+   the IPv4-compatible destination address of the IPv6 packet being
+   tunneled.  Automatic tunneling allows IPv6/IPv4 nodes to communicate
+   over IPv4 routing infrastructures without pre-configuring tunnels.
+
+5.1.  IPv4-Compatible Address Format
+
+   IPv6/IPv4 nodes that perform automatic tunneling are assigned IPv4-
+   compatible address.  An IPv4-compatible address is identified by an
+   all-zeros 96-bit prefix, and holds an IPv4 address in the low-order
+   32-bits.  IPv4-compatible addresses are structured as follows:
+
+          |              96-bits                 |   32-bits    |
+          +--------------------------------------+--------------+
+          |            0:0:0:0:0:0               | IPv4 Address |
+          +--------------------------------------+--------------+
+                       IPv4-Compatible IPv6 Address Format
+
+   IPv4-compatible addresses are assigned exclusively to nodes that
+   support automatic tunneling.  A node SHOULD be configured with an
+   IPv4-compatible address only if it is prepared to accept IPv6 packets
+   destined to that address encapsulated in IPv4 packets destined to the
+   embedded IPv4 address.
+
+   An IPv4-compatible address is globally unique as long as the IPv4
+   address is not from the private IPv4 address space [15].  An
+   implementation SHOULD behave as if its IPv4-compatible address(es)
+   are assigned to the node's automatic tunneling interface, even if the
+   implementation does not implement automatic tunneling using a concept
+   of interfaces.  Thus the IPv4-compatible address SHOULD NOT be viewed
+   as being attached to e.g. an Ethernet interface i.e. implications
+
+
+
+Gilligan & Nordmark         Standards Track                    [Page 20]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+   should not use the Neighbor Discovery mechanisms like NUD [7] at the
+   Ethernet.  Any such interactions should be done using the
+   encapsulated packets i.e. over the automatic tunneling (conceptual)
+   interface.
+
+5.2.  IPv4-Compatible Address Configuration
+
+   An IPv6/IPv4 node with an IPv4-compatible address uses that address
+   as one of its IPv6 addresses, while the IPv4 address embedded in the
+   low-order 32-bits serves as the IPv4 address for one of its
+   interfaces.
+
+   An IPv6/IPv4 node MAY acquire its IPv4-compatible IPv6 addresses via
+   IPv4 address configuration protocols.  It MAY use any IPv4 address
+   configuration mechanism to acquire its IPv4 address, then "map" that
+   address into an IPv4-compatible IPv6 address by pre-pending it with
+   the 96-bit prefix 0:0:0:0:0:0.  This mode of configuration allows
+   IPv6/IPv4 nodes to "leverage" the installed base of IPv4 address
+   configuration servers.
+
+   The specific algorithm for acquiring an IPv4-compatible address using
+   IPv4-based address configuration protocols is as follows:
+
+   1) The IPv6/IPv4 node uses standard IPv4 mechanisms or protocols to
+      acquire the IPv4 address for one of its interfaces.  These
+      include:
+
+      -  The Dynamic Host Configuration Protocol (DHCP) [2]
+
+      -  The Bootstrap Protocol (BOOTP) [1]
+
+      -  The Reverse Address Resolution Protocol (RARP) [9]
+
+      -  Manual configuration
+
+      -  Any other mechanism which accurately yields the node's own IPv4
+         address
+
+   2) The node uses this address as the IPv4 address for this interface.
+
+   3) The node prepends the 96-bit prefix 0:0:0:0:0:0 to the 32-bit IPv4
+      address that it acquired in step (1).  The result is an IPv4-
+      compatible IPv6 address with one of the node's IPv4-addresses
+      embedded in the low-order 32-bits.  The node uses this address as
+      one of its IPv6 addresses.
+
+
+
+
+
+
+Gilligan & Nordmark         Standards Track                    [Page 21]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+5.3.  Automatic Tunneling Operation
+
+   In automatic tunneling, the tunnel endpoint address is determined
+   from the packet being tunneled.  If the destination IPv6 address is
+   IPv4-compatible, then the packet can be sent via automatic tunneling.
+   If the destination is IPv6-native, the packet can not be sent via
+   automatic tunneling.
+
+   A routing table entry can be used to direct automatic tunneling.  An
+   implementation can have a special static routing table entry for the
+   prefix 0:0:0:0:0:0/96.  (That is, a route to the all-zeros prefix
+   with a 96-bit mask.)  Packets that match this prefix are sent to a
+   pseudo-interface driver which performs automatic tunneling.  Since
+   all IPv4-compatible IPv6 addresses will match this prefix, all
+   packets to those destinations will be auto-tunneled.
+
+   Once it is delivered to the automatic tunneling module, the IPv6
+   packet is encapsulated within an IPv4 header according to the rules
+   described in section 3.  The source and destination addresses of the
+   encapsulating IPv4 header are assigned as follows:
+
+      Destination IPv4 address:
+
+         Low-order 32-bits of IPv6 destination address
+
+      Source IPv4 address:
+
+         IPv4 address of interface the packet is sent via
+
+   The automatic tunneling module always sends packets in this
+   encapsulated form, even if the destination is on an attached
+   datalink.
+
+   The automatic tunneling module MUST NOT send to IPv4 broadcast or
+   multicast destinations.  It MUST drop all IPv6 packets destined to
+   IPv4-compatible destinations when the embedded IPv4 address is
+   broadcast, multicast, the unspecified (0.0.0.0) address, or the
+   loopback address (127.0.0.1).  Note that the sender can only tell if
+   an address is a network or subnet broadcast for broadcast addresses
+   assigned to directly attached links.
+
+5.4.  Use With Default Configured Tunnels
+
+   Automatic tunneling is often used in conjunction with the default
+   configured tunnel technique.  "Isolated" IPv6/IPv4 hosts -- those
+   with no on-link IPv6 routers -- are configured to use automatic
+   tunneling and IPv4-compatible IPv6 addresses, and have at least one
+   default configured tunnel to an IPv6 router.  That IPv6 router is
+
+
+
+Gilligan & Nordmark         Standards Track                    [Page 22]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+   configured to perform automatic tunneling as well.  These isolated
+   hosts send packets to IPv4-compatible destinations via automatic
+   tunneling and packets for IPv6-native destinations via the default
+   configured tunnel.  IPv4-compatible destinations will match the 96-
+   bit all-zeros prefix route discussed in the previous section, while
+   IPv6-native destinations will match the default route via the
+   configured tunnel.  Reply packets from IPv6-native destinations are
+   routed back to the an IPv6/IPv4 router which delivers them to the
+   original host via automatic tunneling.  Further examples of the
+   combination of tunneling techniques are discussed in [12].
+
+5.5.  Source Address Selection
+
+   When an IPv6/IPv4 node originates an IPv6 packet, it must select the
+   source IPv6 address to use.  IPv6/IPv4 nodes that are configured to
+   perform automatic tunneling may be configured with global IPv6-native
+   addresses as well as IPv4-compatible addresses.  The selection of
+   which source address to use will determine what form the return
+   traffic is sent via.  If the IPv4-compatible address is used, the
+   return traffic will have to be delivered via automatic tunneling, but
+   if the IPv6-native address is used, the return traffic will not be
+   automatic-tunneled.  In order to make traffic as symmetric as
+   possible, the following source address selection preference is
+   RECOMMENDED:
+
+      Destination is IPv4-compatible:
+
+         Use IPv4-compatible source address associated with IPv4 address
+         of outgoing interface
+
+      Destination is IPv6-native:
+
+         Use IPv6-native address of outgoing interface
+
+   If an IPv6/IPv4 node has no global IPv6-native address, but is
+   originating a packet to an IPv6-native destination, it MAY use its
+   IPv4-compatible address as its source address.
+
+5.6.  Ingress Filtering
+
+   The decapsulating node MUST verify that the encapsulated packets are
+   acceptable before forwarding decapsulated packets to avoid
+   circumventing ingress filtering [13].  Note that packets which are
+   delivered to transport protocols on the decapsulating node SHOULD NOT
+   be subject to these checks.  Since automatic tunnels always
+   encapsulate to the destination (i.e.  the IPv4 destination will be
+   the destination) any packet received over an automatic tunnel SHOULD
+   NOT be forwarded.
+
+
+
+Gilligan & Nordmark         Standards Track                    [Page 23]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+6.  Acknowledgments
+
+   We would like to thank the members of the IPng working group and the
+   Next Generation Transition (ngtrans) working group for their many
+   contributions and extensive review of this document.  Special thanks
+   are due to Jim Bound, Ross Callon, and Bob Hinden for many helpful
+   suggestions and to John Moy for suggesting the IPv4 "anycast address"
+   default tunnel technique.
+
+7.  Security Considerations
+
+   Tunneling is not known to introduce any security holes except for the
+   possibility to circumvent ingress filtering [13].  This is prevented
+   by requiring that decapsulating routers only forward packets if they
+   have been configured to accept encapsulated packets from the IPv4
+   source address in the receive packet.  Additionally, in the case of
+   automatic tunneling, nodes are required by not forwarding the
+   decapsulated packets since automatic tunneling ends the tunnel and
+   the destination.
+
+8.  Authors' Addresses
+
+   Robert E. Gilligan
+   FreeGate Corp
+   1208 E. Arques Ave
+   Sunnyvale, CA 94086
+   USA
+
+   Phone:  +1-408-617-1004
+   Fax:    +1-408-617-1010
+   EMail:  gilligan@freegate.com
+
+
+   Erik Nordmark
+   Sun Microsystems, Inc.
+   901 San Antonio Rd.
+   Palo Alto, CA 94303
+   USA
+
+   Phone:  +1-650-786-5166
+   Fax:    +1-650-786-5896
+   EMail:  nordmark@eng.sun.com
+
+
+
+
+
+
+
+
+
+Gilligan & Nordmark         Standards Track                    [Page 24]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+9.  References
+
+   [1]  Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
+        September 1985.
+
+   [2]  Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
+        October 1993.
+
+   [3]  Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
+        Domains without Explicit Tunnels", RFC 2529, March 1999.
+
+   [4]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+        Specification", RFC 2460, December 1998.
+
+   [5]  Thomson, S. and T. Narten, "IPv6 Stateless Address
+        Autoconfiguration," RFC 2462, December 1998.
+
+   [6]  Crawford, M., Thomson, S., and C. Huitema. "DNS Extensions to
+        Support IPv6 Address Allocation and Renumbering", RFC 2874, July
+        2000.
+
+   [7]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
+        IP Version 6 (IPv6)", RFC 2461, December 1998.
+
+   [8]  Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
+        November 1990.
+
+   [9]  Finlayson, R., Mann, T., Mogul, J. and M. Theimer, "Reverse
+        Address Resolution Protocol", STD 38, RFC 903, June 1984.
+
+   [10] Braden, R., "Requirements for Internet Hosts - Communication
+        Layers", STD 3, RFC 1122, October 1989.
+
+   [11] Kent, C. and J. Mogul, "Fragmentation Considered Harmful".  In
+        Proc.  SIGCOMM '87 Workshop on Frontiers in Computer
+        Communications Technology.  August 1987.
+
+   [12] Callon, R. and D. Haskin, "Routing Aspects of IPv6 Transition",
+        RFC 2185, September 1997.
+
+   [13] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating
+        Denial of Service Attacks which employ IP Source Address
+        Spoofing", RFC 2267, January 1998.
+
+   [14] Hinden, R. and S. Deering, "IP Version 6 Addressing
+        Architecture", RFC 2373, July 1998.
+
+
+
+
+
+Gilligan & Nordmark         Standards Track                    [Page 25]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+   [15] Rechter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.J. and
+        E. Lear, "Address Allocation for Private Internets", BCP 5, RFC
+        1918, February 1996.
+
+   [16] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [17] Thaler, D., "IP Tunnel MIB", RFC 2667, August 1999.
+
+   [18] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
+        June 1995.
+
+10.  Changes from RFC 1933
+
+   -  Deleted section 3.1.1 (IPv4 loopback address) in order to prevent
+      it from being mis-construed as requiring routers to filter the
+      address ::127.0.0.1, which would put another test in the
+      forwarding path for IPv6 routers.
+
+   -  Deleted section 4.4 (Default Sending Algorithm).  This section
+      allowed nodes to send packets in "raw form" to IPv4-compatible
+      destinations on the same datalink.  Implementation experience has
+      shown that this adds complexity which is not justified by the
+      minimal savings in header overhead.
+
+   -  Added definitions for operating modes for IPv6/IPv4 nodes.
+
+   -  Revised DNS section to clarify resolver filtering and ordering
+      options.
+
+   -  Re-wrote the discussion of IPv4-compatible addresses to clarify
+      that they are used exclusively in conjunction with the automatic
+      tunneling mechanism.  Re-organized document to place definition of
+      IPv4-compatible address format with description of automatic
+      tunneling.
+
+   -  Changed the term "IPv6-only address" to "IPv6-native address" per
+      current usage.
+
+   -  Updated to algorithm for determining tunnel MTU to reflect the
+      change in the IPv6 minimum MTU from 576 to 1280 bytes [4].
+
+   -  Deleted the definition for the term "IPv6-in-IPv4 encapsulation."
+      It has not been widely used.
+
+   -  Revised IPv4-compatible address configuration section (5.2) to
+      recognize multiple interfaces.
+
+
+
+
+Gilligan & Nordmark         Standards Track                    [Page 26]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+   -  Added discussion of source address selection when using IPv4-
+      compatible addresses.
+
+   -  Added section on the combination of the default configured
+      tunneling technique with hosts using automatic tunneling.
+
+   -  Added prohibition against automatic tunneling to IPv4 broadcast or
+      multicast destinations.
+
+   -  Clarified that configured tunnels can be unidirectional or
+      bidirectional.
+
+   -  Added description of bidirectional virtual links as another type
+      of tunnels.  Nodes MUST respond to NUD probes on such links and
+      SHOULD send NUD probes.
+
+   -  Added reference to [16] specification as an alternative for
+      tunneling over a multicast capable IPv4 cloud.
+
+   -  Clarified that IPv4-compatible addresses are assigned exclusively
+      to nodes that support automatic tunnels i.e. nodes that can
+      receive such packets.
+
+   -  Added text about formation of link-local addresses and use of
+      Neighbor Discovery on tunnels.
+
+   -  Added restriction that decapsulated packets not be forwarded
+      unless the source address is acceptable to the decapsulating
+      router.
+
+   -  Clarified that decapsulating nodes MUST be capable of reassembling
+      an IPv4 packet that is 1300 bytes (1280 bytes plus IPv4 header).
+
+   -  Clarified that when using a default tunnel to an IPv4 "anycast
+      address" the network must either have an IPv4 MTU of least 1300
+      bytes (to avoid fragmentation of minimum size IPv6 packets) or be
+      configured to avoid frequent changes to IPv4 routing to the
+      "anycast address" (to avoid different IPv4 fragments arriving at
+      different tunnel endpoints).
+
+   -  Using A6/AAAA instead of AAAA to reference IPv6 address records in
+      the DNS.
+
+   -  Specified when to put IPv6 addresses in the DNS.
+
+   -  Added reference to the tunnel mib for TTL specification for the
+      tunnels.
+
+
+
+
+Gilligan & Nordmark         Standards Track                    [Page 27]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+   -  Added a table of contents.
+
+   -  Added recommendations for use of source and target link layer
+      address options for the tunnel links.
+
+   -  Added checks in the decapsulation checking both an IPv4-compatible
+      IPv6 source address and the outer IPv4 source addresses for
+      multicast, broadcast, all-zeros etc.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan & Nordmark         Standards Track                    [Page 28]
+
+RFC 2893               IPv6 Transition Mechanisms            August 2000
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan & Nordmark         Standards Track                    [Page 29]
+