Skip to main content

Generic Packet Tunneling in IPv6 Specification
draft-ietf-ipngwg-ipv6-tunnel-07

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 2473.
Authors Dr. Steve E. Deering , Alex Conta
Last updated 2013-03-02 (Latest revision 1996-12-23)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 2473 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-ipngwg-ipv6-tunnel-07
IPng Working Group               A.  Conta  (Lucent  Technologies  Inc.)
INTERNET-DRAFT                        S. Deering (Cisco Systems)
                                            December 1996

                    Generic Packet Tunneling in IPv6

                             Specification

                  draft-ietf-ipngwg-ipv6-tunnel-07.txt

Status of this Memo

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

   Internet Drafts are draft  documents  valid  for  a  maximum  of  six
   months.  Internet  Drafts  may  be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to  use  Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "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).

   Distribution of this memo is unlimited.

Abstract

   This document defines the  model  and  generic  mechanisms  for  IPv6
   encapsulation  of Internet packets, such as IPv6 and IPv4.  The model
   and mechanisms can be applied to other protocol packets as well, such
   as AppleTalk, IPX, CLNP, or others.

Conta & Deering       Expires in six months         [Page 1]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

Table of Contents

   Status of this Memo...........................................1
   Table of Contents.............................................2
1. Introduction..................................................3
2. Terminology...................................................3
3. Generic IPv6 Tunneling........................................5
    3.1 IPv6 Encapsulation.......................................7
    3.2 IPv6 Packet Processing in Tunnels........................8
    3.3 IPv6 Decapsulation.......................................8
    3.4 IPv6 Tunnel Protocol Engine..............................9
4. Nested Encapsulation.........................................12
    4.1  Limiting Nested Encapsulation..........................13
        4.1.1  Tunnel Encapsulation Limit.......................14
        4.1.2  Loopback Encapsulation...........................15
        4.1.3  Routing Loop Nested Encapsulation................16
5. Tunnel IPv6 Header...........................................16
    5.1 Tunnel IPv6 Extension Headers...........................18
6. IPv6 Tunnel State Variables..................................19
    6.1 IPv6 Tunnel Entry-Point Node............................19
    6.2 IPv6 Tunnel Exit-Point Node.............................20
    6.3 IPv6 Tunnel Hop Limit...................................20
    6.4 IPv6 Tunnel Packet Priority.............................21
    6.5 IPv6 Tunnel Flow Label..................................21
    6.6 IPv6 Tunnel Encapsulation Limit.........................21
    6.7 IPv6 Tunnel MTU.........................................22
7. IPv6 Tunnel Packet Size Issues...............................22
    7.1 IPv6 Tunnel Packet Fragmentation........................23
    7.2 IPv4 Tunnel Packet Fragmentation........................23
8. IPv6 Tunnel Error Reporting and Processing...................24
    8.1 Tunnel ICMP Messages....................................28
    8.2 ICMP Messages for IPv6 Original Packets.................29
    8.3 ICMP Messages for IPv4 Original Packets.................30
    8.4 ICMP Messages for Nested Tunnel Packets.................31
9. Security Considerations......................................31
10. Acknowledgments.............................................32
11. References..................................................32
Authors' Addresses..............................................33
Appendix A.Risk Factors in Recursive Encapsulation..............34
Fig.1.................................................6
Fig.2.................................................6
Fig.3.................................................7
Fig.4.................................................8
Fig.5.................................................9
Fig.6................................................13
Fig.7................................................25
Fig.8................................................26/27

Conta & Deering       Expires in six months         [Page 2]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

1. Introduction

   This document specifies a method and generic mechanisms  by  which  a
   packet  is encapsulated and carried as payload within an IPv6 packet.
   The resulting packet is called an IPv6 tunnel packet. The  forwarding
   path  between  the  source  and  destination  of the tunnel packet is
   called an IPv6 tunnel. The technique is called IPv6 tunneling.

   A typical scenario for  IPv6  tunneling  is  the  case  in  which  an
   intermediate  node  exerts  explicit  routing  control  by specifying
   particular forwarding paths for selected  packets.  This  control  is
   achieved  by prepending to each of the selected original packets IPv6
   headers that identify the forwarding path.

   In addition to the description of generic IPv6 tunneling  mechanisms,
   which  is  the  focus  of  this  document,  specific  mechanisms  for
   tunneling IPv6 and IPv4 packets are also described herein.

2. Terminology

   original packet

        a packet that undergoes encapsulation.

   original header

        the header of an original packet.

   tunnel

        a forwarding path between two nodes on  which  packets  payloads
        are original packets.

   tunnel end-node

        a node where a tunnel begins or ends.

   tunnel header

        the   header   prepended   to   the   original   packet   during
        encapsulation.  It specifies the tunnel end-points as source and
        destination.

   tunnel packet

        a packet that encapsulates an original packet.

Conta & Deering       Expires in six months         [Page 3]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

   tunnel entry-point

        the tunnel end-node where an original packet is encapsulated.

   tunnel exit-point

        the tunnel end-node where a tunnel packet is decapsulated.

   IPv6 tunnel

        a tunnel configured as a virtual link between two IPv6 nodes, on
        which the encapsulating protocol is IPv6.

   fixed-exit tunnel

        a tunnel for which a specific exit-point was configured.

   free-exit tunnel

        a tunnel for which no specific exit-point  was  configured;  the
        exit  point  is  extracted  from  the destination of each packet
        encapsulated and sent into the tunnel.

   tunnel MTU

        the maximum size of a tunnel packet  payload  without  requiring
        fragmentation,  that  is, the Path MTU between the tunnel entry-
        point and the tunnel exit-point nodes  minus  the  size  of  the
        tunnel headers.

   tunnel hop limit

        the maximum number of hops that a tunnel packet can travel  from
        the tunnel entry-point to the tunnel exit-point.

   inner tunnel

        a tunnel that is a hop (virtual link) of another tunnel.

   outer tunnel

        a tunnel containing one or more inner tunnels.

   nested tunnel packet

        a tunnel packet that has as payload a tunnel packet.

   nested tunnel header

Conta & Deering       Expires in six months         [Page 4]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

        the tunnel header of a nested tunnel packet.

   nested encapsulation

        encapsulation of an encapsulated packet.

   recursive encapsulation

        encapsulation of a packet that reenters a tunnel before  exiting
        it.

   tunnel encapsulation limit

        the maximum number of nested encapsulations of a packet.

3. IPv6 Tunneling

   IPv6 tunneling is a  technique  for  establishing  a  "virtual  link"
   between  two  IPv6 nodes for transmitting data packets as payloads of
   IPv6 packets (see Fig.1).  From the point of view of the  two  nodes,
   this  "virtual  link",  called  an IPv6 tunnel, appears as a point to
   point link on which IPv6 acts like a  link-layer  protocol.  The  two
   IPv6  nodes  play  specific  roles.  One  node  encapsulates original
   packets received from other nodes or from  itself  and  forwards  the
   resulting   tunnel   packets  through  the  tunnel.  The  other  node
   decapsulates the received tunnel packets and forwards  the  resulting
   original  packets  towards  their  destinations, possibly itself. The
   encapsulator node is called the tunnel entry-point node,  and  it  is
   the source of the tunnel packets. The decapsulator node is called the
   tunnel exit-point, and it is the destination of the tunnel packets.

   Note:

   This document refers in  particular  to  tunnels  between  two  nodes
   identified  by  unicast  addresses  - such tunnels look like "virtual
   point to point links". The mechanisms described herein apply also  to
   tunnels  in  which the exit-point nodes are identified by other types
   of addresses, such as anycast or multicast.  These tunnels  may  look
   like "virtual point to multipoint links". At the time of writing this
   document,  IPv6  anycast  addresses  are   a   subject   of   ongoing
   specification and experimental work.

Conta & Deering       Expires in six months         [Page 5]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

                   Tunnel from node B to node C
                    <---------------------->
                 Tunnel                     Tunnel
                 Entry-Point                Exit-Point
                 Node                       Node
  +-+            +-+                        +-+            +-+
  |A|-->--//-->--|B|=====>=====//=====>=====|C|-->--//-->--|D|
  +-+            +-+                        +-+            +-+
  Original                                                 Original
  Packet                                                   Packet
  Source                                                   Destination
  Node                                                     Node

              Fig.1 Tunnel

   An IPv6 tunnel is a unidirectional mechanism  -  tunnel  packet  flow
   takes  place in one direction between the IPv6 tunnel entry-point and
   exit-point nodes (see Fig.1).

   Bi-directional tunneling is achieved by  merging  two  unidirectional
   mechanisms,  that  is,  configuring  two  tunnels,  each  in opposite
   direction to the other - the entry-point node of one  tunnel  is  the
   exit-point node of the other tunnel (see Fig.2).

                   Tunnel from Node B to Node C
                    <------------------------>
                 Tunnel                      Tunnel
  Original       Entry-Point                 Exit-Point     Original
  Packet         Node                        Node           Packet
  Source                                                    Destination
  Node                                                      Node
  +-+            +-+                         +-+            +-+
  | |-->--//-->--| |=====>=====//=====>======| |-->--//-->--| |
  |A|            |B|                         |C|            |D|
  | |--<--//--<--| |=====<=====//=====<======| |--<--//--<--| |
  +-+            +-+                         +-+            +-+
  Original                                                  Original
  Packet                                                    Packet
  Destination    Tunnel                      Tunnel         Source
  Node           Exit-Point                  Entry-Point    Node
                 Node                        Node
                   <------------------------->
                  Tunnel from Node C to Node B

              Fig.2 Bi-directional Tunneling Mechanism

Conta & Deering       Expires in six months         [Page 6]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

3.1 IPv6 Encapsulation

   IPv6 encapsulation consists of prepending to the original  packet  an
   IPv6  header  and,  optionally,  a set of IPv6 extension headers (see
   Fig.3), which  are  collectively  called  tunnel  IPv6  headers.  The
   encapsulation  takes place in an IPv6 tunnel entry-point node, as the
   result of an original packet being forwarded onto  the  virtual  link
   represented  by  the  tunnel. The original packet is processed during
   forwarding according to the forwarding rules of the protocol of  that
   packet. For instance if the original packet is an:

    (a)  IPv6 packet, the IPv6 original header hop limit is  decremented
         by one.

    (b)  IPv4 packet, the IPv4 original header time to live field  (TTL)
         is decremented by one.

   At encapsulation, the source field  of  the  tunnel  IPv6  header  is
   filled  with  an IPv6 address of the tunnel entry-point node, and the
   destination field with an IPv6  address  of  the  tunnel  exit-point.
   Subsequently,  the tunnel packet resulting from encapsulation is sent
   towards the tunnel exit-point node.

   Tunnel extension headers should appear in the  order  recommended  by
   the  specifications  that define the extension headers, such as [RFC-
   1883].

   A  source  of  original  packets  and  a  tunnel   entry-point   that
   encapsulates those packets can be the same node.

                            +----------------------------------//-----+
                            | Original |                              |
                            |          |   Original Packet Payload    |
                            | Header   |                              |
                            +----------------------------------//-----+
                             <            Original Packet            >
                                              |
                                              v
       <Tunnel IPv6 Headers> <       Original Packet                 >
      +---------+ - - - - - +-------------------------//--------------+
      | IPv6    | IPv6      |                                         |
      |         | Extension |        Original Packet                  |
      | Header  | Headers   |                                         |
      +---------+ - - - - - +-------------------------//--------------+
       <                          Tunnel IPv6 Packet                 >

            Fig.3 Encapsulating a Packet

Conta & Deering       Expires in six months         [Page 7]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

3.2 Packet Processing in Tunnels

   The intermediate nodes in the tunnel process the IPv6 tunnel  packets
   according  to  the  IPv6  protocol.  For example, a tunnel Hop by Hop
   Options extension header is processed by each receiving node  in  the
   tunnel; a tunnel Routing extension header identifies the intermediate
   processing nodes, and controls at a finer granularity the  forwarding
   path  of  the  tunnel packet through the tunnel; a tunnel Destination
   Options extension header is processed at the tunnel exit-point node.

3.3 IPv6 Decapsulation

   Decapsulation is graphically shown in Fig.4:

         +---------+- - - - - -+----------------------------------//-----+
         | IPv6    | IPv6      |                                         |
         |         | Extension |        Original Packet                  |
         | Header  | Headers   |                                         |
         +---------+- - - - - -+----------------------------------//-----+
          <                      Tunnel IPv6 Packet                     >
                                          |
                                          v
                               +----------------------------------//-----+
                               | Original |                              |
                               |          |   Original Packet Payload    |
                               | Headers  |                              |
                               +----------------------------------//-----+
                                <            Original Packet            >

                 Fig.4 Decapsulating a Packet

   Upon receiving an IPv6 packet destined to an IPv6 address of a tunnel
   exit-point   node,  its  IPv6  protocol  layer  processes  the tunnel
   headers. The strict  left-to-right  processing  rules  for  extension
   headers is applied. When processing is complete, control is handed to
   the next protocol engine, which is  identified  by  the  Next  Header
   field  value in the last header processed. If this is set to a tunnel
   protocol value,  the  tunnel  protocol  engine  discards  the  tunnel
   headers  and  passes the resulting original packet to the Internet or
   lower layer protocol identified by that value for further processing.
   For  example,  in  the case the Next Header field has the IPv6 Tunnel
   Protocol value, the resulting original packet is passed to  the  IPv6
   protocol layer.

Conta & Deering       Expires in six months         [Page 8]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

   The tunnel exit-point node, which decapsulates  the  tunnel  packets,
   and  the  destination  node,  which  receives  the resulting original
   packets can be the same node.

3.4 IPv6 Tunnel Protocol Engine

   Packet flow (paths #1-7) through the IPv6 Tunnel Protocol Engine on a
   node is graphically shown in Fig.5:

      +-----------------------+   +-----------------------------------+
      | Upper-Layer Protocols |   | IPv6 Tunnel Upper-Layer           |
      |                       |   |                                   |
      |                       |   | ---<-------------------<-------   |
      |                       |   | | ---->---|------>---------   |   |
      |                       |   | | |       | |             |   |   |
      +-----------------------+   +-----------------------+   |   |   |
         | |             | |        | |       | |         |   v   ^   |
         v ^             v ^        v ^       v ^  Tunnel |   |   |   |
         | |             | |        | |       | |  Packets|   |   |   |
      +---------------------------------------------+     |   |   |   |
      |  | |             | |       / /        | |   |     |   D   E   |
      |  v ^    IPv6     | --<-3--/-/--<----  | |   |     |   E   N   |
      |  | |    Layer    ---->-4-/-/--->-- |  | |   |     |   C   C   |
      |  v ^                    / /      | |  | |   |     |   A   A   |
      |  | |                   2 1       | |  | |   |     |   P   P   |
      |  v ^     -----<---5---/-/-<----  v ^  v ^   |     |   S   S   |
      |  | |     | -->---6---/-/-->-- |  | |  | |   |     |   U   U   |
      |  v ^     | |        / /     6 5  4 3  8 7   |     |   L   L   |
      |  | |     | |       / /      | |  | |  | |   |     |   A   A   |
      |  v ^     v ^      / /       v ^  | |  | |   |     |   T   T   |
      +---------------------------------------------+     |   E   E   |
         | |     | |     | |        | |  | |  | |         |   |   |   |
         v ^     v ^     v ^        v ^  v ^  v ^ Original|   |   |   |
         | |     | |     | |        | |  | |  | | Packets |   v   ^   |
      +-----------------------+   +-----------------------+   |   |   |
      |                       |   | | |  | |  | |             |   |   |
      |                       |   | | ---|----|-------<--------   |   |
      |                       |   | --->--------------->------>----   |
      |                       |   |                                   |
      | Link-Layer Protocols  |   | IPv6 Tunnel Link-Layer            |
      +-----------------------+   +-----------------------------------+

     Fig.5 Packet Flow in the IPv6 Tunneling Protocol Engine on a Node

Conta & Deering       Expires in six months         [Page 9]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

   Note:

   In  Fig.5,  the  Upper-Layer  Protocols  box   represents   transport
   protocols  such  as TCP, UDP, control protocols such as ICMP, routing
   protocols such as OSPF, and internet or  lower-layer  protocol  being
   "tunneled"  over  IPv6,  such  as  IPv4,  IPX,  etc.  The  Link-Layer
   Protocols box represents Ethernet, Token Ring, FDDI, PPP, X.25, Frame
   Relay,  ATM, etc..., as well as internet layer "tunnels" such as IPv4
   tunnels.

   The IPv6 tunnel protocol engine acts as both an "upper-layer"  and  a
   "link-layer", each with a specific input and output as follows:

   (u.i) "tunnel upper-layer input" - consists of  tunnel  IPv6  packets
         that  are  going  to  be  decapsulated.  The tunnel packets are
         incoming through the IPv6 layer from:

         (u.i.1) a link-layer - (path #1, Fig.5)

                 These are tunnel packets destined to this node and will
                 undergo decapsulation.

         (u.i.2) a tunnel link-layer - (path #7, Fig.5)

                 These are tunnel packets that  underwent  one  or  more
                 decapsulations  on  this node, that is, the packets had
                 one or more nested tunnel headers and one nested tunnel
                 header  was just discarded. This node is the exit-point
                 of both an outer tunnel and one or more  of  its  inner
                 tunnels.

         For both above cases the resulting original packets are  passed
         back  to  the  IPv6  layer  as  "tunnel  link-layer" output for
         further processing (see b.2).

   (u.o) "tunnel upper-layer output" - consists of tunnel  IPv6  packets
         that are passed through the IPv6 layer down to:

         (u.o.1) a link-layer - (path #2, Fig.5)

                 These packets  underwent  encapsulation  and  are  sent
                 towards the tunnel exit-point

         (u.o.2) a tunnel link-layer - (path #8, Fig.5)

Conta & Deering       Expires in six months        [Page 10]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

                 These tunnel packets undergo nested encapsulation. This
                 node  is  the  entry-point node of both an outer tunnel
                 and one or more of its inner tunnel.

     Implementation Note:

     The tunnel upper-layer input and output can be implemented  similar
     to the input and output of the other upper-layer protocols.

   The tunnel link-layer input and output are as follows:

    (l.i) "tunnel link-layer input" - consists of original IPv6  packets
          that are going to be encapsulated.

          The original packets are incoming through the IPv6 layer from:

          (l.i.1) an upper-layer - (path #4, Fig.5)

                  These are original packets originating  on  this  node
                  that undergo encapsulation. The original packet source
                  and tunnel entry-point are the same node.

          (l.i.2) a link-layer - (path #6, Fig.5)

                  These are original packets incoming from  a  different
                  node  that undergo encapsulation on this tunnel entry-
                  point node.

          (l.i.3) a tunnel upper-layer - (path #8, Fig.5)

                  These packets are tunnel packets that  undergo  nested
                  encapsulation.  This node is both the entry-point node
                  of an outer tunnel  and  one  or  more  of  its  inner
                  tunnels.

          The resulting tunnel packets are passed as tunnel  upper-layer
          output packets through the IPv6 layer (see u.o) down to:

    (l.o) "tunnel link-layer output" - consists of original IPv6 packets
          resulting from decapsulation. These packets are passed through
          the IPv6 layer to:

          (l.o.1) an upper-layer - (path #3, Fig.5)

                  These original packets are destined to this node.

Conta & Deering       Expires in six months        [Page 11]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

          (l.o.2) a link-layer - (path #5, Fig.5)

                  These original packets are destined to  another  node;
                  they   are   transmitted   on  a  link  towards  their
                  destination.

          (l.o.3) a tunnel upper-layer - (path #7, Fig.5)

                  These packets undergo another decapsulation; they were
                  nested  tunnel  packets.  This  node is both the exit-
                  point node of an outer tunnel and one  or  more  inner
                  tunnels.

      Implementation Note:

      The tunnel link-layer input and output can be implemented  similar
      to  the  input  and  output  of  other  link-layer  protocols, for
      instance, associating an interface or  pseudo-interface  with  the
      IPv6 tunnel.

      The selection of the "IPv6 tunnel link" over other  links  results
      from  the packet forwarding decision taken based on the content of
      the node's routing table.

4. Nested Encapsulation

   Nested IPv6 encapsulation is the encapsulation of  a  tunnel  packet.
   It  takes  place when a hop of an IPv6 tunnel is a tunnel. The tunnel
   containing a tunnel is called an outer tunnel. The  tunnel  contained
   in  the  outer  tunnel  is  called an inner tunnel - see Fig.6. Inner
   tunnels and their outer tunnels are nested tunnels.

   The entry-point node of an "inner IPv6 tunnel" receives  tunnel  IPv6
   packets encapsulated by the "outer IPv6 tunnel" entry-point node. The
   "inner tunnel entry-point node" treats the receiving  tunnel  packets
   as  original  packets  and  performs  encapsulation.   The  resulting
   packets are "tunnel packets" for the "inner IPv6 tunnel", and "nested
   tunnel packets" for the "outer IPv6 tunnel".

Conta & Deering       Expires in six months        [Page 12]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

                 Outer Tunnel
                 <------------------------------------->
                 <--links--><-virtual link-><--links--->
                              Inner Tunnel

                Outer Tunnel                          Outer Tunnel
                Entry-Point                           Exit-Point
                Node                                  Node
     +-+        +-+        +-+            +-+         +-+        +-+
     | |        | |        | |            | |         | |        | |
     | |->-//->-| |=>=//=>=| |**>**//**>**| |=>=//=>==| |->-//->-| |
     | |        | |        | |            | |         | |        | |
     +-+        +-+        +-+            +-+         +-+        +-+
   Original                Inner Tunnel   Inner Tunnel         Original
   Packet                  Entry-Point    Exit-Point           Packet
   Source                  Node           Node                 Destination
   Node                                                        Node

                 Fig.6. Nested Encapsulation

4.1 Limiting Nested Encapsulation

   A tunnel IPv6 packet size is limited to  the  maximum  IPv6  datagram
   size  [RFC  1883].  Each  encapsulation  adds to the size of a tunnel
   packet the size of the tunnel IPv6 headers. Consequently, the  number
   of   tunnel   headers,   and   therefore,   the   number   of  nested
   encapsulations, and furthermore, the number of "inner  IPv6  tunnels"
   that  an  "outer  IPv6  tunnel"  can  have are limited by the maximum
   packet size.

   The increase in the size of  a  tunnel  IPv6  packet  due  to  nested
   encapsulations  may require fragmentation [RFC-1883] - see section 7.
   Furthermore, each fragmentation, due to nested encapsulation,  of  an
   already  fragmented tunnel packet results in a doubling of the number
   of fragments.  Moreover, it is probable that once this  fragmentation
   begins,  each  new  nested  encapsulation  results  in yet additional
   fragmentation.    Therefore   limiting   nested   encapsulation    is
   recommended.

   The proposed mechanism for limiting excessive nested encapsulation is
   a   "tunnel  encapsulation  limit",  which  is  carried  in  an  IPv6
   Destination Option header.

Conta & Deering       Expires in six months        [Page 13]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

4.1.1 Tunnel Encapsulation Limit

   The "Tunnel Encapsulation Limit" destination option is provided  only
   by  tunnel  entry-point  nodes,  it is discarded only by tunnel exit-
   point nodes, and it is used to carry optional information  [RFC-1883]
   that need be examined only by tunnel entry-point nodes.

   The "Tunnel Encapsulation Limit" destination  option  is  defined  as
   follows:

      Option Type     Opt Data Len   Opt Data Len
    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 1 0 0|       1       | Tun Encap Lim |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Type     value 4

                       - the highest-order  two  bits  -  set  to  00  -
                      indicate  "skip  over this option if the option is
                      not recognized".

                       - the  third-highest-order  bit  -  set  to  0  -
                      indicates that the option data in this option does
                      not change en route to  the  packet's  destination
                      [RFC-1883].

      Opt Data Len    value 1 - the data portion of the  Option  is  one
                      byte long.

      Opt Data Value  the  Tunnel  Encapsulation  Limit  value  -  8-bit
                      unsigned integer.

   To avoid excessive nested encapsulation, an IPv6  tunnel  entry-point
   node  may  prepend  to  a  packet  undergoing encapsulation a "Tunnel
   Encapsulation Limit - Destination Option". The "OptData Value"  field
   of the option is set to:

        (a)  a pre-configured value - if the packet  being  encapsulated
             has  no  IPv6  destination  options  header  or  no "Tunnel
             Encapsulation Limit" option in such a header - see  section
             6.6.

        (b)  a  value  resulting  from  a  value  stored  in  the   IPv6
             destination  options header - if such a header exist and if
             it contains a  "Tunnel  Encapsulation  Limit"  option.  The

Conta & Deering       Expires in six months        [Page 14]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

             "OptData  Value"  of  the  extant option is copied into the
             newly prepended "Tunnel  Encapsulation  Limit"  option  and
             then decremented by one.

             This  is  an  exception  to  the  rule  of   processing   a
             destination  options extension header in that, although the
             entry-point  node  is  not  a  destination   node,   during
             encapsulation,  the  IPv6  tunneling  protocol engine looks
             ahead, for  an  IPv6  destination  header  with  a  "Tunnel
             Encapsulation   Limit"  option  immediately  following  the
             current IPv6 main header.

             If the Tunnel Encapsulation Limit is decremented  to  zero,
             the  packet undergoing encapsulation is discarded. When the
             packet is  discarded,  a  Parameter  Problem  ICMP  message
             [RFC-1885]  is  returned to the packet originator, which is
             the previous tunnel entry-point. The message points to  the
             Opt  Data Value field within the Tunnel Encapsulation Limit
             destination header of the packet. The field pointed to  has
             a value of one.

   Two cases of encapsulation  that  should  be  avoided  are  described
   below:

4.1.2 Loopback Encapsulation

   A particular case of encapsulation  which  must  be  avoided  is  the
   loopback  encapsulation.  Loopback  encapsulation  takes place when a
   tunnel  IPv6  entry-point  node  encapsulates  tunnel  IPv6   packets
   originated from itself, and destined to itself.  This can generate an
   infinite processing loop in the entry-point node.

   To avoid such a case, it is recommended that an implementation have a
   mechanism  that  checks  and rejects the configuration of a tunnel in
   which both the entry-point and exit-point node  addresses  belong  to
   the  same  node. It is also recommended that the encapsulating engine
   check for and reject the encapsulation of a packet that has the  pair
   of  tunnel  entry-point  and  exit-point addresses identical with the
   pair of original packet source and final destination addresses.

Conta & Deering       Expires in six months        [Page 15]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

4.1.3 Routing-Loop Nested Encapsulation

   In the case of a forwarding path with multiple level nested  tunnels,
   a   routing-loop   from  an  inner  tunnel  to  an  outer  tunnel  is
   particularly dangerous when packets from the inner tunnels reenter an
   outer tunnel from which they have not yet exited. In such a case, the
   nested encapsulation  becomes  a  recursive  encapsulation  with  the
   negative effects described in 4.1.  Because each nested encapsulation
   adds a tunnel header with a new hop limit value, the IPv6  hop  limit
   mechanism  cannot  control the number of times the packet reaches the
   outer tunnel entry-point node, and thus cannot control the number  of
   recursive encapsulations.

   When the path of a packet from source to final  destination  includes
   tunnels,  the  maximum  number  of  hops that the packet can traverse
   should be controlled by two mechanisms used  together  to  avoid  the
   negative effects of recursive encapsulation in routing loops:

        (a)  the original packet hop limit.

             It is decremented at each forwarding operation performed on
             an original packet. This includes each encapsulation of the
             original packet. It does not include nested  encapsulations
             of the original packet

        (b)  the tunnel IPv6 packet encapsulation limit.

             It is decremented  at  each  nested  encapsulation  of  the
             packet.

   For a discussion of  the  excessive  encapsulation  risk  factors  in
   nested encapsulation see Appendix A.

5. Tunnel IPv6 Header

   The tunnel entry-point node fills  out  a  tunnel  IPv6  main  header
   [RFC-1883] as follows:

          Version:

            value 6

Conta & Deering       Expires in six months        [Page 16]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

          Priority:

            Depending on the entry-point node tunnel configuration,  the
            priority can be set to that of either the original packet or
            a pre-configured value - see section 6.3.

          Flow label:

            Depending on the entry-point node tunnel configuration,  the
            flow label can be set to a pre-configured value. The typical
            value is zero - see section 6.4.

          Payload Length:

            The  original  packet  length,  plus  the  length   of   the
            encapsulating (prepended) IPv6 extension headers, if any.

          Next header:

            The next header  value  according  to  [RFC-1883]  from  the
            Assigned Numbers RFC [RFC-1700 or its succesors ].

            For example, if the original packet is an IPv6 packet,  this
            is set to:

                 - decimal value 41 (Assigned payload  type  number  for
                 IPv6) - if there are no tunnel extension headers.

                 - value 0 (Assigned payload type number for IPv6 Hop by
                 Hop  Options  header)  - if a hop by hop options header
                 immediately follows the tunnel IPv6 header.

                 - decimal value 60 (Assigned payload  type  number  for
                 IPv6   Destination   Options  header)  -  if  a  Tunnel
                 Encapsulation   Limit   destination    option    header
                 immediately follows the tunnel IPv6 header.

          Hop limit:

            The tunnel IPv6 header hop limit is set to a  pre-configured
            value - see section 6.3.

            The default  value  for  hosts  is  the  Neighbor  Discovery
            advertised  hop  limit  [RFC-1970].  The  default  value for
            routers is  the  default  IPv6  Hop  Limit  value  from  the
            Assigned  Numbers  RFC  (64  at  the  time  of  writing this

Conta & Deering       Expires in six months        [Page 17]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

            document).

          Source Address:

            An IPv6 address of the  outgoing  interface  of  the  tunnel
            entry-point  node.  This address is configured as the tunnel
            entry-point node address - see section 6.1.

          Destination Address:

            An IPv6 address of the tunnel exit-point node. If the tunnel
            is  configured  as a free-exit tunnel, then the IPv6 address
            of the destination from  the  original  IPv6  header  -  see
            section 6.2.

5.1 Tunnel IPv6 Extension Headers

   Depending on IPv6 node configuration parameters, a tunnel entry-point
   node  may  append  to  the  tunnel  IPv6 main header one or more IPv6
   extension headers, such as hop by hop, routing, or others.

   To limit the number of nested encapsulations of a packet, if  it  was
   configured  to do so - see section 6.6 - a tunnel entry-point appends
   as the last tunnel extension  header  a  Tunnel  Encapsulation  Limit
   destination option header with fields set as follows:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |Hdr Ext Len = 0| Opt Type = 4  |Opt Data Len=1 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Tun Encap Lim |PadN Opt Type=1|Opt Data Len=1 |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Next Header:

            Identifies the type  of  the  original  packet  header.  For
            example,  if the original packet is an IPv6 packet, the next
            header protocol value is set to decimal value  41  (Assigned
            payload type number for IPv6).

Conta & Deering       Expires in six months        [Page 18]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

          Hdr Ext Len:

            Length of the Tunnel Encapsulation Limit destination  option
            header  in  8-octet units, not including the first 8 octets.
            Set to value 0, if no other  options  are  present  in  this
            destination options header.

          Option Type:

            value 4 - see section 4.1.1.

          Opt Data Len:

            value 1 - see section 4.1.1.

          Tun Encap Lim:

            8 bit unsigned integer - see section 4.1.1.

          Option Type:

            value 1 - PadN option, to align the  header  following  this
            header.

          Opt Data Len:

            value 1 - one octet of option data.

          Option Data:

            value 0 - one zero-valued octet.

6. IPv6 Tunnel State Variables

   The IPv6 tunnel  state  variables,  some  of  which  are  or  may  be
   configured on the tunnel entry-point node, are:

6.1 IPv6 Tunnel Entry-Point Node Address

   The tunnel entry-point node address is one of the valid IPv6  unicast
   addresses  of the entry-point node - the validation of the address at
   tunnel configuration time is recommended.

Conta & Deering       Expires in six months        [Page 19]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

   The tunnel entry-point node address is copied to the  source  address
   field in the tunnel IPv6 header during packet encapsulation.

6.2 IPv6 Tunnel Exit-Point Node Address

   The tunnel exit-point  node  address  is  used  as  IPv6  destination
   address  for  the  tunnel  IPv6  header.  The  tunnel exit-point node
   address can be configured with a specific IPv6 address, in which case
   the  tunnel  is called a fixed-exit tunnel. Such a tunnel acts like a
   virtual point to point link between the entry-point  node  and  exit-
   point  node.   Alternatively,  a  tunnel  exit-point  address  can be
   configured with no specific address, in  which  case  the  tunnel  is
   called a free-exit tunnel. Such a tunnel acts like a virtual point to
   point link between  the  entry-point  node  and  an  exit-point  node
   identified  by  the  destination  address  from  the  original packet
   header.

   The tunnel exit-point node  address  is  copied  to  the  destination
   address field in the tunnel IPv6 header during packet encapsulation.

   The configuration of the tunnel entry-point and exit-point  addresses
   is not subject to IPv6 Autoconfiguration, or IPv6 Neighbor Discovery.

6.3 IPv6 Tunnel Hop Limit

   An IPv6 tunnel is modeled as a "single-hop virtual link"  tunnel,  in
   which  the  passing of the original packet through the tunnel is like
   the passing of the original packet over a one hop link, regardless of
   the number of hops in the IPv6 tunnel.

   The "single-hop" mechanism should be implemented by having the tunnel
   entry  point node set a tunnel IPv6 header hop limit independently of
   the hop limit of the original header.

   The "single-hop" mechanism hides from the original IPv6  packets  the
   number of IPv6 hops of the tunnel.

   It is recommended that the tunnel hop  limit  be  configured  with  a
   value that ensures:

        (a)  that tunnel IPv6 packets can reach  the  tunnel  exit-point
             node

        (b)  a quick expiration of the tunnel packet if a  routing  loop

Conta & Deering       Expires in six months        [Page 20]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

             occurs within the IPv6 tunnel.

   The tunnel hop limit default value for hosts  is  the  IPv6  Neighbor
   Discovery  advertised  hop  limit  [RFC-1970].  The  tunnel hop limit
   default value for routers is the default IPv6 Hop  Limit  value  from
   the Assigned Numbers RFC (64 at the time of writing this document).

   The tunnel hop limit is copied into the hop limit field of the tunnel
   IPv6  header  of  each  packet encapsulated by the tunnel entry-point
   node.

6.4 IPv6 Tunnel Packet Priority

   The IPv6 Tunnel Packet Priority indicates the  value  that  a  tunnel
   entry-point  node  sets in the priority field of a tunnel header. The
   default value is zero.   The  configured  Packet  Priority  can  also
   indicate whether the value of the priority field in the tunnel header
   is copied from the  original  header,  or  it  is  set  to  the  pre-
   configured value.

6.5 IPv6 Tunnel Flow Label

   The IPv6 Tunnel Flow Label indicates the value that a  tunnel  entry-
   point  node  sets  in  the flow label of a tunnel header. The default
   value is zero.

6.6 IPv6 Tunnel Encapsulation Limit

   The Tunnel Encapsulation Limit value can indicate whether the  entry-
   point  node  is  configured  to limit the number of encapsulations of
   tunnel  packets  originating  on   that   node.   The   IPv6   Tunnel
   Encapsulation Limit is the maximum number of encapsulations permitted
   for  packets  undergoing  encapsulation  at  that  entry-point  node.
   Recommended  default  value  is  5. An entry-point node configured to
   limit  the  number  of  nested  encapsulations  prepends   a   Tunnel
   Encapsulation  Limit destination options header to an original packet
   undergoing encapsulation - see section 4.1, and 4.1.1.

Conta & Deering       Expires in six months        [Page 21]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

6.7 IPv6 Tunnel MTU

   The tunnel MTU is set dynamically to the Path MTU between the  tunnel
   entry-point  and  the  tunnel  exit-point nodes minus the size of the
   tunnel headers: the maximum size of a tunnel packet payload that  can
   be  sent  through  the  tunnel  without fragmentation [RFC-1883]. The
   tunnel entry-point node performs  Path  MTU  discovery  on  the  path
   between  the  tunnel  entry-point  and  exit-point  nodes [RFC-1981],
   [RFC-1885]. The tunnel MTU of a nested tunnel is the  tunnel  MTU  of
   the outer tunnel minus the size of the tunnel headers.

   Although it should be able to send a tunnel IPv6 packet of any  valid
   size,  a  tunnel entry-point node attempts to avoid the fragmentation
   of tunnel packets, by reporting to source nodes of  original  packets
   the  MTU  to  be  used  in  sizing original packets sent towards that
   tunnel entry-point node.

7. IPv6 Tunnel Packet Size Issues

   Prepending a tunnel header increases the size of a packet,  therefore
   a tunnel packet resulting from the encapsulation of an IPv6  original
   packet may require fragmentation.

   A tunnel IPv6 packet resulting from the encapsulation of an  original
   packet  is  considered  an  IPv6  packet  originating from the tunnel
   entry-point node. Therefore, like any source of  an  IPv6  packet,  a
   tunnel  entry-point  node  must  support fragmentation of tunnel IPv6
   packets.

   A tunnel intermediate node that forwards a tunnel packet  to  another
   node  in  the  tunnel  follows the general IPv6 rule that it must not
   fragment a packet undergoing forwarding.

   A tunnel exit-point node receiving tunnel packets at the end  of  the
   tunnel  for decapsulation applies the strict left-to-right processing
   rules for extension headers. In the case  of  fragmentation  headers,
   the fragments are reassembled into a tunnel packet before determining
   that an embedded IP packet is present.

   Note:

   A particular problem arises when  the  destination  of  a  fragmented
   tunnel packet is an exit-point node identified by an anycast address.
   The problem, which is similar to that  of  original  fragmented  IPv6
   packets  destined to nodes identified by an anycast address, consists

Conta & Deering       Expires in six months        [Page 22]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

   in the requirement that all the fragments of a packet must arrive  to
   the  same  destination  node,  for  that node to be able to perform a
   successful reassembly.

7.1 IPv6 Tunnel Packet Fragmentation

   Tunnel  packets  that  exceed  the  tunnel  MTU  are  candidates  for
   fragmentation.  The  fragmentation  of tunnel packets containing IPv6
   original packets is performed as follows:

        (a)  if the original IPv6 packet size is larger than 576 octets,
             the  entry-point node discards the packet and it returns an
             ICMPv6 "Packet Too Big" message to the source node  of  the
             original  packet with the recommended MTU size field set to
             the maximum between 576, and the tunnel MTU, i.e.  max(576,
             tunnel  MTU).  Note  that  the  tunnel  MTU is the Path MTU
             between the tunnel entry-point and  the  tunnel  exit-point
             nodes  minus  the  size  of  the  tunnel  headers. Also see
             section 6.7, and 8.2.

        (b)  if the original IPv6 packet is equal or  smaller  than  576
             octets,   the  tunnel  entry-point  node  encapsulates  the
             original packet, and subsequently fragments  the  resulting
             IPv6  tunnel  packet into IPv6 fragments that do not exceed
             the tunnel MTU.

7.2 IPv4 Tunnel Packet Fragmentation

   Tunnel  packets  that  exceed  the  tunnel  MTU  are  candidates  for
   fragmentation.  The  fragmentation  of tunnel packets containing IPv4
   original packets is performed as follows:

        (a)  if in the original IPv4 packet header the Don't Fragment  -
             DF  -  bit  flag  is SET, the entry-point node discards the
             packet and returns an ICMP message.  The ICMP  message  has
             the  type  =  "unreachable", the code = "datagram too big",
             and the recommended MTU size field set to the size  of  the
             tunnel MTU - see section 6.7, and 8.3.

Conta & Deering       Expires in six months        [Page 23]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

        (b)  if in the original packet header the Don't Fragment - DF  -
             bit flag is CLEAR, the tunnel entry-point node encapsulates
             the  original  packet,  and  subsequently   fragments   the
             resulting  IPv6  tunnel  packet into IPv6 fragments that do
             not exceed the tunnel MTU.

8. IPv6 Tunnel Error Processing and Reporting

   IPv6 Tunneling follows the general rule that an error detected during
   the  processing of an IPv6 packet is reported through an ICMP message
   to the source of the packet.

   On a forwarding path that includes IPv6 tunnels, an error detected by
   a  node  that is not in any tunnel is directly reported to the source
   of the original IPv6 packet.

   An error detected by a node inside a tunnel is reported to the source
   of the tunnel packet, that is, the tunnel entry-point node.  The ICMP
   message sent to the tunnel entry-point node has as ICMP  payload  the
   tunnel IPv6 packet that has the original packet as its payload.

   The cause of a packet error encountered inside  a  tunnel  can  be  a
   problem with:

        (a)  the tunnel header, or

        (b)  the tunnel packet.

   Both tunnel header and tunnel packet problems  are  reported  to  the
   tunnel entry-point node.

   If a tunnel packet problem is a consequence of  a  problem  with  the
   original  packet, which is the payload of the tunnel packet, then the
   problem is also reported to the source of the original packet.

   To report a problem detected inside the tunnel to the  source  of  an
   original  packet,  the  tunnel  entry  point node must relay the ICMP
   message received from  inside  the  tunnel  to  the  source  of  that
   original IPv6 packet.

   An example of the  processing  that  can  take  place  in  the  error
   reporting mechanism of a node is illustrated in Fig.7, and Fig.8:

   Fig.7 path #0 and Fig.8 (a) - The IPv6 tunnel entry-point receives an
   ICMP  packet  from inside the tunnel, marked Tunnel ICMPv6 Message in

Conta & Deering       Expires in six months        [Page 24]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

   Fig.7. The tunnel entry-point node IPv6  layer  passes  the  received
   ICMP message to the ICMPv6 Input. The ICMPv6 Input, based on the ICMP
   type and code [RFC-1885] generates an internal "error code".

   Fig.7 path #1 - The internal error code, is passed with  the  "ICMPv6
   message  payload" to the upper-layer protocol - in this case the IPv6
   tunnel upper-layer error input.

 +-------+   +-------+   +-----------------------+
 | Upper |   | Upper |   | Upper                 |
 | Layer |   | Layer |   | Layer                 |
 | Proto.|   | Proto |   | IPv6 Tunnel           |
 | Error |   | Error |   | Error                 |
 | Input |   | Input |   | Input                 |
 |       |   |       |   |       Decapsulate     |
 |       |   |       |   |  -->--ICMPv6--#2->--  |
 |       |   |       |   |  |    Payload      |  |
 +-------+   +-------+   +--|-----------------|--+
     |           |          |                 |
     ^           ^          ^                 v
     |           |          |                 |
     --------------------#1--      -----Orig.Packet?--- - - - - - - - - -
              #1                  #3  Int.Error Code, #5                |
Int.Error Code,^                   v  Source Address, v                 v
ICMPv6 Payload |            IPv6   |  Orig. Packet    | IPv4            |
      +--------------+    +--------------+    +--------------+    + - - - - +
      |              |    |              |    |              |
      | ICMP v6      |    | ICMP v6      |    | ICMP v4      |    |         |
      | Input        |    | Error Report |    | Error Report |
      |  -  -  -  -  +----+  -  -  -  -  |    +  -  -  -  -  +    + - - - - +
      |                                  |    |              |
      |            IPv6 Layer            |    |  IPv4 Layer  |    |         |
      |                                  |    |              |
      +----------------------------------+    +--------------+    + - - - - +
            |                    |                    |
            ^                    V                    V
            #0                   #4                   #6
            |                    |                    |
       Tunnel ICMPv6            ICMPv6               ICMPv4
         Message                Message              Message
            |                    |                    |

   Fig.7 Error Reporting Flow in a Node (IPv6 Tunneling Protocol Engine)

   Fig.7  path  #2  and  Fig.8  (b)  -  The  IPv6  tunnel  error   input
   decapsulates  the  tunnel  IPv6  packet,  which is the ICMPv6 message
   payload, obtaining the original packet, and thus the original headers
   and dispatches the "internal error code", the source address from the

Conta & Deering       Expires in six months        [Page 25]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

   original packet header, and the original packet, down  to  the  error
   report  block  of the protocol identified by the Next Header field in
   the tunnel header immediately preceding the original  packet  in  the
   ICMP message payload.

   From here the processing depends on  the  protocol  of  the  original
   packet:

        (a)  - for an IPv6 original packet

     Fig.7 path #3 and Fig.8 (c.1)- for an  IPv6  original  packet,  the
     ICMPv6  error  report  builds  an  ICMP  message of a type and code
     according to the "internal error code",  containing  the  "original
     packet" as ICMP payload.

     Fig.7 path #4 and Fig.8 (d.1)- The  ICMP  message  has  the  tunnel
     entry-point node address as source address, and the original packet
     source node address as destination address. The tunnel  entry-point
     node  sends  the  ICMP  message  to the source node of the original
     packet.

        (b)  - for an IPv4 original packet

     Fig.7 path #5 and Fig.8 (c.2) - for an IPv4  original  packet,  the
     ICMPv4  error  report  builds  an  ICMP  message of a type and code
     derived  from  the  the  "internal  error  code",  containing   the
     "original packet" as ICMP payload.

     Fig.7 path #6 and Fig.8 (d.2) - The ICMP  message  has  the  tunnel
     entry-point  node  IPv4 address as source address, and the original
     packet IPv4 source node address as destination address. The  tunnel
     entry-point  node  sends the ICMP message to the source node of the
     original packet.

   A graphical description of the header processing taking place is  the
   following:

    <                     Tunnel Packet                                >
   +--------+- - - - - -+--------+------------------------------//------+
   | IPv6   | IPv6      | ICMP   |             Tunnel                   |
(a)|        | Extension |        |             IPv6                     |
   | Header | Headers   | Header |             Packet in error          |
   +--------+- - - - - -+--------+------------------------------//------+
    < Tunnel Headers   > <       Tunnel ICMP Message                   >
                                  <         ICMPv6 Message Payload     >
                                 |
                                 v

Conta & Deering       Expires in six months        [Page 26]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

        <                    Tunnel ICMP Message                   >
                        <       Tunnel IPv6 Packet in Error        >
       +--------+      +---------+      +----------+--------//------+
       | ICMP   |      | Tunnel  |      | Original | Original       |
(b)    |        |  +   | IPv6    |  +   |          | Packet         |
       | Header |      | Headers |      | Headers  | Payload        |
       +--------+      +---------+      +----------+--------//------+
           |                             <Original Packet in Error >
           -----------------              |
                           |              |
             --------------|---------------
             |             |
             V             V
       +---------+      +--------+      +-------------------//------+
       | New     |      | ICMP   |      |                           |
(c.1)  | IPv6    |  +   |        |  +   | Orig. Packet in Error     |
       | Headers |      | Header |      |                           |
       +---------+      +--------+      +-------------------//------+
                             |
                             v
                 +---------+--------+-------------------//------+
                 | New     | ICMP   |  Original                 |
(d.1)            | IPv6    |        |                           |
                 | Headers | Header |  Packet in Error          |
                 +---------+--------+-------------------//------+
                  <             New ICMP Message               >

                  or for an IPv4 original packet

       +---------+      +--------+      +-------------------//------+
       | New     |      | ICMP   |      |                           |
(c.2)  | IPv4    |  +   |        |  +   | Orig. Packet in Error     |
       | Header  |      | Header |      |                           |
       +---------+      +--------+      +-------------------//------+
                             |
                             v
                 +---------+--------+-------------------//------+
                 | New     | ICMP   |  Original                 |
(d.2)            | IPv4    |        |                           |
                 | Header  | Header |  Packet in Error          |
                 +---------+--------+-------------------//------+
                  <             New ICMP Message               >

                Fig.8 ICMP Error Reporting and Processing

Conta & Deering       Expires in six months        [Page 27]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

8.1 Tunnel ICMP Messages

   The tunnel ICMP messages that are  reported  to  the  source  of  the
   original packet are:

        hop limit exceeded

             The tunnel has a misconfigured hop  limit,  or  contains  a
             routing  loop,  and  packets  do not reach the tunnel exit-
             point node. This problem is reported to the  tunnel  entry-
             point  node, where the tunnel hop limit can be reconfigured
             to a higher value. The problem is further reported  to  the
             source  of the original packet as described in section 8.2,
             or 8.3.

        unreachable node

             One of the nodes in the tunnel  is  not  or  is  no  longer
             reachable.  This  problem  is reported to the tunnel entry-
             point node, which should be reconfigured with a  valid  and
             active path between the entry and exit-point of the tunnel.
             The problem is  further  reported  to  the  source  of  the
             original packet as described in section 8.2, or 8.3.

        parameter problem

             A Parameter Problem ICMP message pointing to a valid Tunnel
             Encapsulation Limit Destination header with a Tun Encap Lim
             field value set to one is an  indication  that  the  tunnel
             packet   exceeded  the  maximum  number  of  encapsulations
             allowed. The problem is further reported to the  source  of
             the original packet as described in section 8.2, or 8.3.

   The above three problems detected inside  the  tunnel,  which  are  a
   tunnel  configuration  and a tunnel topology problem, are reported to
   the  source  of  the  original  IPv6  packet,  as  a  tunnel  generic
   "unreachable"  problem  caused  by a "link problem" - see section 8.2
   and 8.3.

        packet too big

             The tunnel packet exceeds the tunnel Path MTU.

             The information carried by this type  of  ICMP  message  is
             used as follows:

Conta & Deering       Expires in six months        [Page 28]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

             - by a receiving tunnel entry-point node to set  or  adjust
             the tunnel MTU

             - by a sending tunnel entry-point node  to indicate to  the
             source  of  an  original packet the MTU size that should be
             used in sending IPv6 packets towards the tunnel entry-point
             node.

8.2 ICMP Messages for IPv6 Original Packets

   The tunnel entry-point node builds the ICMP and IPv6 headers  of  the
   ICMP  message  that  is  sent to the source of the original packet as
   follows:

   IPv6 Fields:

   Source Address

                  A valid unicast IPv6 address of the outgoing interface.

   Destination Address

                  Copied from the Source Address field of the Original
                  IPv6 header.

   ICMP Fields:

   For any of the following tunnel ICMP error messages:

     "hop limit exceeded"

     "unreachable node"

     "parameter problem" - pointing  to  a  valid  Tunnel  Encapsulation
     Limit  destination  header  with  the  Tun Encap Lim field set to a
     value one:

     Type           1 - unreachable node

     Code           3 - address unreachable

   For tunnel ICMP error message "packet too big":

Conta & Deering       Expires in six months        [Page 29]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

     Type           2 - packet too big

     Code           0

     MTU            The MTU field from the tunnel ICMP message minus
                    the length of the tunnel headers.

   According to the general rules described in 7.1, an ICMP "packet  too
   big" message is sent to the source of the original packet only if the
   original packet size is larger than 576 octets.

8.3 ICMP Messages for IPv4 Original Packets

   The tunnel entry-point node builds the ICMP and IPv4  header  of  the
   ICMP  message  that  is  sent to the source of the original packet as
   follows:

   IPv4 Fields:

   Source Address

                  A valid unicast IPv4 address of the outgoing interface.

   Destination Address

                  Copied from the Source Address field of the Original
                  IPv4 header.

   ICMP Fields:

   For any of the following tunnel ICMP error messages:

     "hop limit exceeded"

     "unreachable node"

     "parameter problem" - pointing  to  a  valid  Tunnel  Enacpsulation
     Limit  destination  header  with  the  Tun Encap Lim field set to a
     value one:

     Type           3 - destination unreachable

     Code           1 - host unreachable

Conta & Deering       Expires in six months        [Page 30]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

   For a tunnel ICMP error message "packet too big":

     Type           3 - destination unreachable

     Code           4 - datagram too big

     MTU            The MTU field from the tunnel ICMP message minus
                    the length of the tunnel headers.

   According to the general rules described  in  section  7.2,  an  ICMP
   "datagram too big" message is sent to the original IPv4 packet source
   node if the the original IPv4  header has the DF - don't  fragment  -
   bit flag SET.

8.4 ICMP Messages for Nested Tunnels Packets

   In case of an error uncovered with a nested tunnels packet, the inner
   tunnel  entry-point,  which  receives the ICMP error message from the
   inner tunnel reporting node, relays the ICMP  message  to  the  outer
   tunnel  entry-point  following  the  mechanisms described in sections
   8.,8.1, 8.2, and 8.3. Further, the outer  tunnel  entry-point  relays
   the  ICMP message to the source of the original packet, following the
   same mechanisms.

9. Security Considerations

   An IPv6 tunnel can be secured, by securing the IPv6 path between  the
   tunnel  entry-point  and  exit-point node. The security architecture,
   mechanisms, and services are described in [RFC1825],  [RFC1826],  and
   [RFC1827].  A  secure  IPv6  tunnel  may  act as a gateway-to-gateway
   secure path as described in [RFC1825].

   For a secure IPv6 tunnel, in addition  to  the  mechanisms  described
   earlier in this document, the entry-point node of the tunnel performs
   security algorithms on the packet and prepends as part of the  tunnel
   headers  one  or more security headers in conformance with [RFC1883],
   [RFC1825], and [RFC1826], or [RFC1827].

   The exit-point  node  of  a  secure  IPv6  tunnel  performs  security
   algorithms and processes the tunnel security header[s] as part of the
   tunnel headers processing described earlier, and in conformance  with
   [RFC1825], and [RFC1826], or [RFC1827].  The exit-point node discards
   the tunnel security header[s] with the rest  of  the  tunnel  headers
   after tunnel headers processing completion.

Conta & Deering       Expires in six months        [Page 31]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

   The degree of integrity, authentication, and confidentiality and  the
   security  processing  performed on a tunnel packet at the entry-point
   and exit-point node of a secure IPv6 tunnel depend  on  the  type  of
   security  header  -  authentication  (AH)  or  encryption (ESP) - and
   parameters configured in the Security  Association  for  the  tunnel.
   There  is no dependency or interaction between the security level and
   mechanisms applied to the tunnel packets and the security applied  to
   the original packets which are the payloads of the tunnel packets. In
   case of nested tunnels, each inner tunnel may have  its  own  set  of
   security  services, independently from those of the outer tunnels, or
   of those between the source and destination of the original packet.

10. Acknowledgments

   This document is partially derived  from  several  discussions  about
   IPv6  tunneling  on  the  IPng  Working  Group  Mailing List and from
   feedback from the IPng Working Group to  an  IPv6  presentation  that
   focused  on  IPv6  tunneling  at the 33rd IETF, in Stockholm, in July
   1995.

   Additionally, the following documents that focused  on  tunneling  or
   encapsulation  were  helpful  references:  RFC  1933 (R. Gilligan, E.
   Nordmark), RFC 1241 (R. Woodburn, D. Mills), RFC 1326 (P.  Tsuchiya),
   RFC  1701, RFC 1702 (S. Hanks, D. Farinacci, P. Traina), RFC 1853 (W.
   Simpson), as well as RFC 2003 (C. Perkins).

   Brian Carpenter, Richard Draves,  Bob  Hinden,  Thomas  Narten,  Erik
   Nordmark (in alphabetical order) gave valuable reviewing comments and
   suggestions for the improvement of this document. Scott Bradner, Ross
   Callon,  Dimitry Haskin, Paul Traina, and James Watt (in alphabetical
   order) shared their view or experience on matters of concern in  this
   document.  Judith  Grossman  provided  a  sample of her many years of
   editorial and writing experience as well as a good amount of  probing
   technical questions.

11. References

   [RFC-1883] S.  Deering,  R.  Hinden,  "Internet  Protocol  Version  6
   Specification"

   [RFC-1885]  A.  Conta,  and  S.  Deering  "Internet  Control  Message
   Protocol for the Internet Protocol Version 6 (IPv6)"

Conta & Deering       Expires in six months        [Page 32]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

   [RFC-1970] T. Narten, E. Nordmark, W.Simpson "Neighbor Discovery  for
   IP Version 6 (IPv6)"

   [RFC-1981] J. McCann, S. Deering, J. Mogul "Path MTU Discovery for IP
   Version 6 (IPv6)"

   [RFC-1825] R.  Atkinson,  "Security  Architecture  for  the  Internet
   Protocol"

   [RFC-1826] R. Atkinson, "IP Authentication Header"

   [RFC-1827] R. Atkinson, "IP Encapsulation Security Payload (ESP)"

   [RFC-1853] W. Simpson, "IP in IP Tunneling"

   [RFC-1700] J. Reynolds, J. Postel, "Assigned Numbers", 10/20/1994

Authors' Addresses:

   Alex Conta                               Stephen Deering
   Lucent Technologies Inc.                 Cisco Systems
   1300 Massaschussets Ave                  170 West Tasman Dr
   Boxborough, MA 01719                     San Jose, CA 95132-1706
   +1-508-263-3600/ext 535                  +1-408-527-8213

   email: aconta@lucent.com                  email: deering@cisco.com

Conta & Deering       Expires in six months        [Page 33]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

Appendix A

A.1   Risk Factors in Nested Encapsulation

   Nested encapsulations of a packet become a recursive encapsulation if
   the  packet  reenters  an  outer  tunnel before exiting it. The cases
   which present a high risk of recursive  encapsulation  are  those  in
   which  a  tunnel  entry-point  node cannot determine whether a packet
   that undergoes encapsulation reenters the tunnel before  exiting  it.
   Routing  loops  that  cause tunnel packets to reenter a tunnel before
   exiting it are certainly the major cause of the  problem.  But  since
   routing  loops  exist,  and happen, it is important to understand and
   describe, the cases in which the risk for recursive encapsulation  is
   higher.

   There are two significant elements that determine the risk factor  of
   routing loop recursive encapsulation:

        (a)  the type of tunnel,

        (b)  the  type  of  route  to  the  tunnel   exit-point,   which
             determines  the  packet forwarding through the tunnel, that
             is, over the tunnel virtual-link.

A.1.1  Risk Factor in Nested Encapsulation - type of tunnel.

   The type of tunnels which were identified as a high risk  factor  for
   recursive encapsulation in routing loops are:

              "inner tunnels with identical exit-points".

   These tunnels can be:

              "fixed-end inner tunnels with different entry-points",

   or:

              "free-end inner tunnels with different entry-points"

   Note that free-end inner tunnels fall always  into  the  category  of
   identical exit-point tunnels.

   Since the source and destination of an original packet  is  the  main

Conta & Deering       Expires in six months        [Page 34]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

   information  used  to  decide  whether  to forward a packet through a
   tunnel or not, a recursive encapsulation can be avoided in case of  a
   single  tunnel  (non-inner),  by  checking  that  the  packet  to  be
   encapsulated  is  not  originated  on  the  entry-point  node.   This
   mechanism is suggested in [RFC-1853].

   However, this type of protection does not seem to work well  in  case
   of  inner  tunnels  with  different entry-points, and identical exit-
   points.

   Inner tunnels with different entry-points and  identical  exit-points
   introduce ambiguity in deciding whether to encapsulate a packet, when
   a packet encapsulated in an inner tunnel reaches the entry-point node
   of  an outer tunnel by means of a routing loop. Because the source of
   the tunnel packet is the  inner  tunnel  entry-point  node  which  is
   different  than  the entry-point node of the outer tunnel, the source
   address  checking  (mentioned  above)  fails  to  detect  an  invalid
   encapsulation,   and   as   a  consequence  the  tunnel  packet  gets
   encapsulated at the outer tunnel each time it reaches it through  the
   routing loop.

A.1.2  Risk Factor in Nested Encapsulation - type of route.

   The type  of  route  to  a  tunnel  exit-point  node  has  been  also
   identified  as  a  high  risk  factor  of  recursive encapsulation in
   routing loops.

   One type of route to a  tunnel  exit-point  node  is  a  route  to  a
   specified  destination  node,  that  is,  the  destination is a valid
   specified IPv6 address (route to node). Such a route can be  selected
   based  on the longest match of an original packet destination address
   with the destination address stored in the  tunnel  entry-point  node
   routing  table  entry  for that route. The packet forwarded on such a
   route is first encapsulated and then  forwarded  towards  the  tunnel
   exit-point node.

   Another type of route to a tunnel exit-point node is  a  route  to  a
   specified  prefix-net,  that is, the destination is a valid specified
   IPv6 prefix (route to net). Such a route can be selected based on the
   longest path match of an original packet destination address with the
   prefix destination stored in  the  tunnel  entry-point  node  routing
   table  entry  for that route. The packet forwarded on such a route is
   first encapsulated and then forwarded towards the  tunnel  exit-point
   node.

   And finally another type of route to a tunnel exit-point is a default

Conta & Deering       Expires in six months        [Page 35]


INTERNET-DRAFT             Tunneling in IPv6           December 16, 1996

   route,  or  a  route  to  an  unspecified  destination. This route is
   selected when no-other match for  the  destination  of  the  original
   packet  has  been  found  in  the routing table. A tunnel that is the
   first hop of a default route is a "default tunnel".

   If the route to a tunnel exit-point is a  route  to  node,  the  risk
   factor for recursive encapsulation is minimum.

   If the route to a tunnel exit-point is  a  route  to  net,  the  risk
   factor  for  recursive  encapsulation  is medium. There is a range of
   destination addresses  that  will  match  the  prefix  the  route  is
   associated  with.  If one or more inner tunnels with different tunnel
   entry-points have exit-point node addresses that match the  route  to
   net of an outer tunnel exit-point, then a recursive encapsulation may
   occur if a tunnel packet gets diverted  from  inside  such  an  inner
   tunnel to the entry-point of the outer tunnel that has a route to its
   exit-point that matches the exit-point of an inner tunnel.

   If the route to a tunnel exit-point is  a  default  route,  the  risk
   factor  for recursive encapsulation is maximum. Packets are forwarded
   through a default  tunnel  for  lack  of  a  better  route.  In  many
   situations, forwarding through a default tunnel can happen for a wide
   range of destination addresses which at the  maximum  extent  is  the
   entire  Internet  minus the node's link. As consequence, it is likely
   that in a routing loop case, if a tunnel packet gets diverted from an
   inner  tunnel to an outer tunnel entry-point in which the tunnel is a
   default tunnel, the packet will be once  more  encapsulated,  because
   the   default   routing   mechanism  will  not  be  able  to  discern
   differently, based on the destination.

Conta & Deering       Expires in six months        [Page 36]