[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 2473

Network Working Group           A. Conta (Digital Equipment Corporation)
INTERNET-DRAFT                        S. Deering (Xerox PARC)
                                            February 1996


                    Generic Packet Tunneling in IPv6

                             Specification

                  draft-ietf-ipngwg-ipv6-tunnel-01.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 mechanisms for IPv6 tunneling  of
   various Internet or lower layer protocol packets, such as IPv6, IPv4,
   AppleTalk, IPX, etc.













Conta & Deering       Expires in six months         [Page 1]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


Table of Contents


   Status of this Memo...........................................1
   Table of Contents.............................................2
1. Introduction..................................................3
2. Terminology...................................................3
3. Generic IPv6 Tunneling........................................7
    3.1 IPv6 Encapsulation.......................................9
    3.2 IPv6 Decapsulation......................................10
    3.3 IPv6 Tunnel Protocol Engine.............................11
    3.4 IPv6 Tunnels and Address Formats........................13
    3.5 IPv6 Tunnels and IPv6 Autoconfiguration.................13
    3.6 IPv6 Tunnels and IPv6 Neighbor Discovery................13
4. Recursive Encapsulation......................................13
    4.1  Limiting Recursive Encapsulation.......................14
        4.1.1  Tunnel Encapsulation Limit.......................14
        4.1.2  Loopback Recursive Encapsulation.................16
        4.1.3  Routing Loop Recursive Encapsulation.............16
        4.1.4  Risk Factors in Recursive Encapsulation..........17
5. Generic Tunnel IPv6 Header...................................19
    5.1 Tunnel IPv6 Extension Headers...........................21
6. IPv6 Tunnel State Variables..................................23
    6.1 IPv6 Tunnel Entry Point Node............................23
    6.2 IPv6 Tunnel Exit Point Node.............................23
    6.3 IPv6 Tunnel Hop Limit...................................24
    6.4 IPv6 Tunnel Packet Priority.............................24
    6.5 IPv6 Tunnel Flow Label..................................24
    6.6 IPv6 Tunnel Encapsulation Limit.........................25
    6.7 IPv6 Tunnel MTU.........................................25
7. IPv6 Tunnel Packet Fragmentation.............................25
    7.1 IPv6 Packet Fragmentation...............................26
    7.2 IPv4 Packet Fragmentation...............................26
8. IPv6 Tunnel Error Reporting and Processing...................27
    8.1 Tunnel ICMP Messages....................................30
    8.2 ICMP Messages for IPv6 Original Packets.................31
    8.3 ICMP Messages for IPv4 Original Packets.................32
9. Open Issues..................................................33
10. References..................................................34
11. Acknowledgements............................................35
12. Security Considerations.....................................35
Authors' Addresses..............................................35
Appendix A..Inner tunnels.......................................35
Appendix B..Default tunnels.....................................37
Changes from previous version...................................38

Fig. 1.................................................8
Fig. 2.................................................8



Conta & Deering       Expires in six months         [Page 2]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


Fig. 3.................................................9
Fig. 4................................................10
Fig. 5................................................11
Fig. 6................................................13
Fig. 7................................................28
Fig. 8................................................29













































Conta & Deering       Expires in six months         [Page 3]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


1. Introduction

   This document specifies a method and generic mechanisms  by  which  a
   packet  may  be  encapsulated  and  carried as payload within an IPv6
   packet. The technique of encapsulating packets within  IPv6  packets,
   called  also  tunneling  in  IPv6,  is recommended for use in various
   cases of communications.

   Such a case is when a node, that is not the source node of a  packet,
   wishes  to  exert  explicit routing control over the packet - such as
   causing the packet to be forwarded to a particular destination on the
   way  to  the final destination identified in the original header. The
   control is exerted by prepending to the packet  a  new  IPv6  header,
   with a new source and destination address (see section 3.1).

   The tunnel IPv6  packet  is  forwarded  to  the  tunnel  IPv6  header
   destination which is the IPv6 tunnel exit-point node. The IPv6 tunnel
   exit-point node removes the IPv6 tunnel header, and forwards the IPv6
   packet further towards the original IPv6 header destination node (see
   section 3.2).

   The sections of this document describe generic  mechanisms  for  IPv6
   tunneling  that apply to tunneling of various Internet or lower layer
   protocol packets.  section 7. and 8. describe specific IPv6 tunneling
   mechanisms for IPv6 packets and respectively IPv4 packets.

2. Terminology


   node

      a device that implements IPv6.


   upper-layer

      a protocol layer immediately above IPv6.  Examples  are  transport
      protocols such as TCP and UDP, control protocols such as ICMP, and
      internet or lower-layer protocols  being  "tunneled"  over  (i.e.,
      encapsulated in) IPv6 such as IPX, AppleTalk, or IPv6 itself.


   link

      a  communication  facility  or  medium  over   which   nodes   can
      communicate  at  the link layer, i.e., the layer immediately below
      IPv6.  Examples are Ethernets  (simple  or  bridged);  PPP  links;
      X.25, Frame Relay, or ATM networks; and internet (or higher) layer



Conta & Deering       Expires in six months         [Page 4]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


      "tunnels", such as tunnels over IPv4 or IPv6 itself.


   interface

      a node's attachment to a link.

   address

      an IPv6-layer identifier for an interface or a set of interfaces.

   packet

      an IPv6 header plus payload.

   link MTU

      the maximum  transmission  unit,  i.e.,  maximum  packet  size  in
      octets, that can be conveyed in one piece over a link.

   path MTU

      the minimum link MTU of all the links in a path between  a  source
      node and a destination node.

   prefix-net

      a network of nodes with identical prefix.

   original packet

      an Internet or lower layer packet that undergoes encapsulation  in
      a tunnel packet.

   original header

      the header of an original packet.

   tunnel

      a virtual link between two nodes, on which an  Internet  or  lower
      layer   protocol   packet  travels  after  the  entry  point  node
      encapsulates that packet in a tunnel protocol packet.

   tunnel header

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



Conta & Deering       Expires in six months         [Page 5]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


   tunnel packet

      an original packet encapsulated by prepending tunnel header(s)  to
      the original header(s).

   tunnel entry point

      the tunnel end-node where an original packet is encapsulated,  and
      where  a  tunnel  packet  originates;  the source node of a tunnel
      packet identified in the tunnel header.

   tunnel exit-point

      the tunnel end-node where a tunnel  packet  is  decapsulated,  and
      processed further as original packet based on the original header;
      the destination node of a tunnel packet, identified in the  tunnel
      header.

   free-exit tunnel

      a tunnel that has an unspecified exit-point  address  (unspecified
      IPv6 address).

   fixed-exit tunnel

      a  tunnel  that  has  a  specified  exit-point  address  (not  the
      unspecified IPv6 address).

   tunnel MTU

      the Path MTU in the tunnel, i.e. between the  tunnel  entry  point
      node and the tunnel exit-point node.

   tunnel hop limit

      the maximum number of hops that a  tunnel  packet  is  allowed  to
      travel  in  a tunnel, i.e. between the tunnel entry point node and
      the tunnel exit-point node.

   inner tunnel

      a tunnel which serves as one (virtual) hop in another tunnel.

   outer tunnel

      a tunnel in which one or more hops are themselves tunnels.

   recursive tunnel IPv6 packet



Conta & Deering       Expires in six months         [Page 6]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


      a tunnel IPv6 packet encapsulated within a tunnel IPv6 packet,  by
      prepending  IPv6  tunnel  header(s)  to  previously prepended IPv6
      tunnel header(s).

   recursive encapsulation

      encapsulation  of  a  tunnel  packet,  i.e.  encapsulation  of  an
      encapsulated packet.

   tunnel encapsulation limit

      the maximum number of recursive encapsulations of a packet.

   default tunnel

      a tunnel which is the preferred  link  (virtual)  to  the  default
      router.



3. IPv6 Tunneling

   Tunneling in IPv6 is a technique which  consists  in  establishing  a
   "virtual  link"  between  two  IPv6  nodes  and using that "link" for
   transmitting data packets. The two IPv6 nodes view the IPv6  "virtual
   link",  also  called an "IPv6 tunnel", as a "link", on which the IPv6
   protocol acts like a "link  layer"  protocol.  Consequently  the  two
   nodes  at  the  two  ends  of the IPv6 tunnel exchange an Internet or
   lower layer protocol packet by  encapsulating  in  and  decapsulating
   from  an  IPv6  packet,  as they would encapsulate in and decapsulate
   from a link layer protocol packet.

   The two IPv6 nodes which are at the two ends of the IPv6 tunnel,  the
   IPv6 tunnel entry point node and the IPv6 tunnel exit point node play
   specific roles:

   A tunnel entry point node can be seen as an original packet source  -
   the  source of the IPv6 tunnel packet is the tunnel entry point node.
   An IPv6 tunnel main header and its extension  headers,  if  any,  are
   processed by the IPv6 layer similarly to processing the headers of an
   original IPv6 packet. Additionally, an IPv6 tunnel  packet  resulting
   from  encapsulation  is  an  IPv6  packet that may be the object of a
   subsequent IPv6 encapsulation, similar to any original packet.

   A  tunnel  exit  point  node  can  be  seen  as  an  original  packet
   destination - the destination of the IPv6 tunnel packet is the tunnel
   exit-point node. The tunnel exit point node processes the  IPv6  main
   header  and  its  extension headers, if any, of an IPv6 tunnel packet



Conta & Deering       Expires in six months         [Page 7]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


   destined to it  similarly  to  processing  the  IPv6  headers  of  an
   original packet destined to it.


                   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 node
   and exit point node (see Fig. 1).


                     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. Bidirectional tunneling mechanism effect





Conta & Deering       Expires in six months         [Page 8]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


A bidirectional tunneling mechanism effect can be  achieved  by  merging
two unidirectional mechanisms, by defining two tunnels that are each one
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).

   A tunnel entry point node can be  the  original  packet  source,  and
   similarly  a  tunnel  exit-point  node  can  be  the  original packet
   destination, i.e. the beginning or ending of a  tunnel  can  coincide
   with the source or destination of an original packet.


3.1 IPv6 Encapsulation

   The IPv6 encapsulation of a packet  consists  in  prepending  to  the
   original  packet,  an  IPv6  header  and  optionally  a  set  of IPv6
   extension headers, called tunnel IPv6 headers, as  graphically  shown
   below in Fig. 3:

   The IPv6 encapsulation takes place in  an  IPv6  tunnel  entry  point
   node,  when  transmitting  an original packet through the tunnel that
   begins at that entry point node.  The  tunnel  packet  resulted  from
   encapsulation  is sent towards the tunnel exit-point node. The tunnel
   headers are used to  control  the  packet's  processing  (forwarding)
   through the tunnel.

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

            Fig. 3. Encapsulating a packet

   If the transmitting of the original packet through the tunnel is  the
   result  of  a  forwarding  operation,  the  original packet header is
   processed before encapsulation according to the forwarding  rules  of
   the  protocol  of  the  original header. For instance if the original
   packet is an:



Conta & Deering       Expires in six months         [Page 9]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


    (a)  IPv6 packet, and it is tunneled as result of an IPv6 forwarding
         operation, the IPv6 original packet hop limit is decremented by
         one during forwarding.

    (b)  IPv4 packet, and it is tunneled as result of an IPv4 forwarding
         operation through an IPv6 tunnel, the IPv4 original packet time
         to live field (TTL) is decremented by one during forwarding.



3.2 IPv6 Decapsulation

    The decapsulation is graphically shown below in Fig. 4:

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


     Fig. 4. Decapsulating a packet from the tunnel IPv6 headers

   The IPv6 protocol layer of a tunnel exit-point node receiving an IPv6
   packet  destined  to  one  of the node's IPv6 addresses processes the
   packet according to the IPv6 protocol. A Next Header field value  set
   to a Tunnel Protocol Value (value 41 for IPv6) in the IPv6 header, or
   the last IPv6 extension header of the packet identifies the packet as
   a  tunnel  packet.   Upon  the  completion of the IPv6 protocol layer
   processing of a  tunnel  packet,  control  is  given  to  the  Tunnel
   Protocol layer. The Tunnel Protocol layer discards the tunnel headers
   and passes the resulting original packet to  the  Internet  or  lower
   layer protocol for further processing - for Next Header value 41, the
   resulting original packet is passed to the IPv6 protocol layer.








Conta & Deering       Expires in six months        [Page 10]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


3.3 IPv6 Tunnel Protocol Engine

   The  packet  flow  through  the  IPv6  Tunnel  Protocol   Engine   is
   graphically shown below 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  - IPv6 Tunneling Protocol Engine

   The "tunnel-layer" acts as both an "upper-layer" and a "link layer":

    (a)  The "tunnel upper-layer" has as  "input"  tunnel  IPv6  packets
         which  are  going  to  be  decapsulated. The tunnel packets are
         incoming through the IPv6 layer from a link-layer - (path #1 in
         Fig.  5)  - or from a tunneling link-layer (the exit-point node
         of an inner tunnel coincides with the  exit-point  node  of  an



Conta & Deering       Expires in six months        [Page 11]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


         outer  tunnel)  -  (path  #7 in Fig. 5). The resulting original
         packets are passed back to the  IPv6  layer  as  "tunnel  link-
         layer" output for further processing - see (d).


    (b)  The "tunnel upper-layer" has as "output"  tunnel  IPv6  packets
         resulting from encapsulation of original packets - see (c) - or
         packets resulted from previous encapsulations - when this  node
         is  an  entry  point to an outer tunnel and to an inner tunnel.
         The "output" tunnel packets are passed through the  IPv6  layer
         down  to  a link-layer for transmission - (path #2 Fig. 5) - or
         to a tunnel link-layer for  another  encapsulation  (the  entry
         point  node  in  an inner tunnel coincides with the entry point
         node in an outer tunnel) - (path #8 in Fig. 5).

         Implementation Note:

         the "tunnel upper-layer" input and output  may  be  implemented
         similar to the other upper layer protocols input and output.


    (c)  The "tunnel link-layer" has as "input"  original  IPv6  packets
         which  are  going  to be encapsulated. The original packets are
         incoming through the IPv6 layer from an  upper-layer  (original
         packets  originated  on  this  node) - (path #4 in Fig. 5) - or
         from a link layer (original packets originated on  a  different
         node)  -  (path #6 in Fig. 5). The resulting tunnel packets are
         passed  through  the  IPv6  layer  down  to  a  link-layer  for
         transmission - see (b).


    (d)  The "tunnel link-layer" has as "output" original  IPv6  packets
         resulting  from  decapsulation  -  see  (a)  - which are passed
         through the IPv6 layer  up  to  an  upper-layer  (the  original
         packet  is  destined  to this node) - (path #3 in Fig.  5) - or
         down to a  link-layer  (the  original  packet  is  destined  to
         another node, so it is forwarded) - (path #5 in Fig. 5).

         Implementation Note:

         the  "IPv6  tunnel  link  layer"  input  and  output   may   be
         implemented  similar  to  other  link layer protocols input and
         output, for instance by 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.



Conta & Deering       Expires in six months        [Page 12]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


3.4 IPv6 Tunnels and Address Formats

   Although the IPv6 addresses of the two end-nodes of  an  IPv6  tunnel
   can  be viewed as "virtual link" addresses, they have an IPv6 address
   format - [RFC-1884].


3.5 IPv6 Tunnels and IPv6 Autoconfiguration

   Although the IPv6 addresses of the two end-nodes of  an  IPv6  tunnel
   can  be viewed as "virtual link" addresses of a pseudo-interface, the
   IPv6 Autoconfiguration [ADDRCONF] mechanisms do  not  apply  for  the
   pseudo-interface.


3.6 IPv6 Tunnels and IPv6 Neighbor Discovery

   Although the IPv6 addresses of the two ends of an IPv6 tunnel can  be
   viewed  as  "virtual  link"  addresses,  the  IPv6 Neighbor Discovery
   mechanisms do not apply.


4. Recursive Encapsulation

   Recursive IPv6 encapsulation takes place when  portions  of  an  IPv6
   tunnel  are  IPv6  tunnels  themselves,  i.e. a tunnel contains inner
   tunnels - see Fig. 6.

                 Outer Tunnel
                 <------------------------------------->
                            <--------------> 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. Recursive Encapsulation

   The entry point node of  an  "inner  IPv6  tunnel"  may  receive  and



Conta & Deering       Expires in six months        [Page 13]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


   encapsulate  packets  that are tunnel IPv6 packets encapsulated at an
   "outer IPv6 tunnel" entry point  node.  These  packets  are  original
   packets  for  the "inner IPv6 tunnel" entry point node, the result of
   their encapsulation at the "inner IPv6 tunnel entry point node" is  a
   "tunnel  IPv6  packet"  for the "inner IPv6 tunnel", and a "recursive
   tunnel IPv6 packet" for the "outer IPv6 tunnel".


4.1 Limiting Recursive Encapsulation


   There is a practical limit on how many "inner IPv6 tunnels" an "outer
   IPv6  tunnel"  may  have  which  results  from  the maximum number of
   possible IPv6 encapsulations of a packet.

   Each encapsulation adds to the size of a tunnel packet  the  size  of
   the  tunnel IPv6 headers. Consequently, in the case of inner tunnels,
   the number of recursive encapsulations is practically limited by  the
   number  of  tunnel IPv6 headers that can be prepended to the original
   packet before the resulting  tunnel  packet  hits  the  maximum  IPv6
   datagram size [RFC-1883].

   The increase in the size of a tunnel  IPv6  packet  due  to  repeated
   recursive  encapsulation  may require fragmentation at a tunnel entry
   point node [RFC-1883] - see section 7.

   Each next recursive encapsulation  of  a  tunnel  IPv6  fragment  may
   result  in  a  new  fragmentation  and  thus the addition of one more
   fragment to the previous existing fragments. Therefore, it is  highly
   probable  that  once  the  fragmentation  of a tunnel IPv6 packet was
   triggered, each next recursive encapsulation may result in additional
   fragmentation,  and  thus IPv6 fragment multiplication. Therefore, it
   is recommended to keep recursive encapsulation to a minimum.


The proposed mechanism for controlling excessive recursive encapsulation
is a "tunnel encapsulation limit" that is carried in an IPv6 Destination
Option header.


4.1.1 Tunnel Encapsulation Limit

   The "Tunnel Encapsulation Limit" destination option header  is  built
   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.

   It is defined according to [RFC-1883] as follows:



Conta & Deering       Expires in six months        [Page 14]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


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


      Option Type     decimal value 4 - the highest-order two bits - set
                      to  00  -  specify  "skip  over this option if the
                      option is not recognized". The third-highest-order
                      bit - set to 0 - specifies that the option data in
                      this  option  does  not  change  en-route  to  the
                      packet's destination [RFC-1883].

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

      Tun Encap Lim   the Tunnel Encapsulation Limit  -  8-bit  unsigned
                      integer (u_8int).

   To avoid excessive recursive  encapsulation,  an  IPv6  tunnel  entry
   point node may prepend, as part of the IPv6 tunnel headers, a "Tunnel
   Encapsulation Limit - Destination Extension Header" - with  the  "Tun
   Encap Lim - tunnel encapsulation limit" - field set to:

        (a)  a pre-configured value - if  the  packet  has  no  previous
             "Tunnel Encapsulation Limit" header - see section 6.6.


        (b)  a value resulting from a pre-existent value - if the packet
             has  a  "Tunnel  Encapsulation  Limit" header, the value is
             copied  into  the  newly  prepended  "Tunnel  Encapsulation
             Limit" header and then decremented by one.

             This  is  an  exception  from  the   rule   of   processing
             destination  extension  headers, in that although the entry
             point  node  is  not  a  destination   node,   during   the
             encapsulation  of  a  packet,  the  IPv6 tunneling protocol
             engine looks ahead in the extant  tunnel  headers  of  that
             packet  for  the  "Tunnel  Encapsulation Limit" destination
             option header.

             If the Tunnel Encapsulation Limit is decremented  to  zero,
             the  packet  undergoing  encapsulation  is  discarded. Upon
             discarding the packet, a  Parameter  Problem  ICMP  message
             [RFC-1885]  is  returned  to  the  packet  originator - the
             Parameter Problem  ICMP  message  points  into  the  Tunnel
             Encapsulation  Limit  destination  header of the packet, to



Conta & Deering       Expires in six months        [Page 15]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


             the Tun Encap Lim field, which has the value one.


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



4.1.2 Loopback Recursive Encapsulation


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

   To avoid such an infinite processing loop in the tunnel  entry  point
   node   IPv6   protocol   engine,  the  tunneling  engine  should  not
   encapsulate packets that have the pair  of  tunnel  entry  point  and
   exit-point  addresses  the same as the pair of original packet source
   address and  final  destination  address.  To  avoid  the  additional
   processing in the tunneling protocol engine that the above validation
   mechanism would require, it is recommended  that  the  validation  be
   done   at  tunnel  configuration  time:  a  node  should  not  permit
   configuring tunnels that the pair of tunnel  entry  point  and  exit-
   point addresses are identical with the pair of original packet source
   address and final destination address, and both the entry point  node
   and exit-point node addresses belong to the entry point node.


4.1.3 Routing Loop Recursive Encapsulation


   In case of a packet path involving multiple levels of inner  tunnels,
   a   routing  loop  from  an  inner  tunnel  to  an  outer  tunnel  is
   particularly dangerous when the loop  is  such  that  a  tunnel  IPv6
   packet  encapsulated  at  a  certain  tunnel entry point node reaches
   again that tunnel entry point node before reaching that tunnel  exit-
   point node.

   Because there is no relationship between the tunnel IPv6  header  hop
   limit and the original packet hop limit, a tunnel packet reaching its
   originator - a tunnel entry point - in a routing loop may expire only
   after an excessively large number of encapsulations.

   Additionally, in such a routing loop case, because the prepending  of



Conta & Deering       Expires in six months        [Page 16]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


   the  tunnel  IPv6  headers  adds to the size of the packets, a tunnel
   packet  may  grow  to  the  maximum  packet  size  limit  [RFC-1883],
   resulting    in    tunnel    packet   fragmentation,   and   fragment
   multiplication.

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


        (a)  the original IPv6 packet  hop  limit,  at  each  forwarding
             operation  performed  on  the original packet, including at
             the points where it is encapsulated and decapsulated.

        (b)  the  tunnel  IPv6  packet  encapsulation  limit,  at   each
             recursive encapsulation of the packet.


4.1.4 Risk Factors in Recursive Encapsulation


   The  cases  which  present  a  high  risk  of   excessive   recursive
   encapsulation  are  those  in  which a tunnel entry point node cannot
   discern between a  valid  and  an  invalid  recursive  encapsulation.
   Routing loops that cause tunnel packets reach nodes that were already
   reached before 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  excessive  recursive
   encapsulation is higher.

   There are two significant elements that determine the risk factor  of
   routing loop excessive 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, i.e.
             over the tunnel virtual-link.

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

              "inner tunnels with identical exit-points".

   These tunnels can be:




Conta & Deering       Expires in six months        [Page 17]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


              "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
   information  used  to  decide  whether  to forward a packet through a
   tunnel or not, an excessive recursive encapsulation can be avoided in
   case  of  a single tunnel (non-inner), by checking that the packet to
   be encapsulated was not originated by  the  entry  point  node.  This
   mechanism is suggested in [IPv4TUN].

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

   Inner tunnels with different entry-points, and identical  exit-points
   introduce  ambiguity  in  deciding  whether  to  encapsulate or not 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  fails  to  detect  an  invalid
   encapsulation, and as consequence the tunnel packet gets encapsulated
   at the outer tunnel, each time it  reaches  it  through  the  routing
   loop.

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

   One type of route to a  tunnel  exit-point  node  is  a  route  to  a
   specified destination node, i.e. the destination is a valid specified
   IPv6 address (route to node). Such a route can be selected  based  on
   the longest path 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, i.e. 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



Conta & Deering       Expires in six months        [Page 18]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


   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
   route, or a route to an unspecified destination, i.e. the destination
   is the "unspecified" IPv6 address. 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 virtual-link of a  default
   route, i.e. the link to a default router, is a "default tunnel".

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

   If the route to a tunnel exit-point is  a  route  to  net,  the  risk
   factor  for  excessive  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 an excessive
   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 excessive 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 - see Appendix B.


5. Tunnel IPv6 Header


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


          Version:




Conta & Deering       Expires in six months        [Page 19]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


            6

          Priority:

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

          Flow label:

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


          Payload Length:

            The original packet length.

            In case the packet is prepended with tunnel  IPv6  extension
            headers,  this  value  is  set to the original packet length
            plus the length of the encapsulating IPv6 extension headers.


          Next header:

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

            For example, if the original packet is an IPv6  packet,  and
            there  are no intermediate headers, the next header protocol
            value is set to 41 (Assigned payload type number for IPv6).

            If a hop by hop option header is immediately  following  the
            tunnel  IPv6  header, then the next header protocol value in
            this field is set to 0 (Assigned  payload  type  number  for
            IPv6 Hop by Hop Options header).

            If a Tunnel Encapsulation Limit destination option header is
            immediately  following the tunnel IPv6 header, then the next
            header protocol value in this field is set to  60  (Assigned
            payload type number for IPv6 Destination Options header).


          Hop limit:

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



Conta & Deering       Expires in six months        [Page 20]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


            The default  value  for  hosts  is  the  neighbor  discovery
            advertised hop limit [IPv6ND]. The default value for routers
            is the default IPv6 Hop Limit [TBD] value from the  Assigned
            Numbers RFC.


          Source Address:

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


          Destination Address:

            IPv6 address of the tunnel exit-point node.  If  the  tunnel
            is  configured  with an unspecified exit-point node address,
            then the IPv6 address of the destination from  the  original
            IPv6 header - see section 6.2.


5.1 Tunnel IPv6 Extension Headers


   Depending on various IPv6  node  configuration  parameters  a  tunnel
   entry  point  node  may append to the tunnel IPv6 main header, one or
   more  IPv6  extension  headers  that  are  not  directly  related  to
   tunneling, such as hop by hop, routing,...etc, and therefore they are
   not discussed here.

   To limit the number of recursive encapsulations of a  packet,  if  it
   was  configured  to  do  so  - see section 6.6 - a tunnel entry point
   appends after the tunnel IPv6 main header, or after the  hop  by  hop
   extension  header,  if  any, 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       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+










Conta & Deering       Expires in six months        [Page 21]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


          Next Header:

            Identifies the type  of  header  immediately  following  the
            Tunnel  Encapsulation  Limit destination option header [RFC-
            1883].

            If the original packet is an IPv6 packet, and there  are  no
            intermediate  headers, the next header protocol value is set
            to 41 (Assigned payload type number for IPv6).

          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.

          Option Type:

            4 - see 4.1.1.


          Opt Data Len:

            1 - see 4.1.1.


          Tun Encap Lim:

            8 bit unsigned integer - see 4.1.1.

          Option Type:

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


          Opt Data Len:

            1 - one octet of option data.


          Option Data:

            One zero-valued octet.








Conta & Deering       Expires in six months        [Page 22]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


6. IPv6 Tunnel State Variables


   The IPv6 tunnel  state  variables,  some  of  which  are  or  may  be
   configured, are:


        (a)  the tunnel entry point node address - is configured

        (b)  the tunnel exit-point node address - is configured

        (c)  the tunnel hop limit - is configured

        (d)  the tunnel packet priority - is configured

        (e)  the tunnel packet flow label - is configured

        (f)  the tunnel encapsulation limit - may be configured

        (g)  the tunnel MTU


6.1 IPv6 Tunnel Entry Point Node Address


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

   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  the  IPv6  destination
   address  for  the  tunnel  IPv6  header.  The  tunnel exit-point node
   address may be configured with a specific IPv6 address, in which case
   the  tunnel acts like a virtual point to point link between the entry
   point node and exit-point node, or with the Unspecified IPv6  address
   [RFC-1884],  in  which  case  the 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.



Conta & Deering       Expires in six months        [Page 23]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


6.3 IPv6 Tunnel Hop Limit


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

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

   The "single-hop" mechanism  hides to the original  IPv6  packets  the
   IPv6 topology of the tunnel.

   The tunnel hop limit is configured into the tunnel entry  point  node
   with a value that:

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

        (b)  ensures a quick  expiration  of  the  tunnel  packet  if  a
             routing loop occurs within the IPv6 tunnel.

   The tunnel  hop  limit  default  value  for  hosts  is  the  neighbor
   discovery advertised hop limit [IPv6ND]. The tunnel hop limit default
   value for routers is the default IPv6 Hop Limit [TBD] value from  the
   Assigned Numbers RFC.

   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 Packet Priority may 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 configured value.


6.5 IPv6 Tunnel Flow Label


   The IPv6 Tunnel Flow Label indicates the value that  a  tunnel  entry



Conta & Deering       Expires in six months        [Page 24]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


   point  node  sets  in  the flow label of a tunnel header. The default
   value is zero.


6.6 IPv6 Tunnel Encapsulation Limit


   The IPv6 Tunnel Encapsulation Limit may be  configured  in  an  entry
   point  node  as  the  maximum  number of encapsulations permitted for
   original packets entering  the  tunnel  at  that  entry  point  node.
   Recommended default value is 5.

   An entry point node configured to limit the number of encapsulations,
   prepends  a  Tunnel  Encapsulation  Limit  Destination  header  to an
   original packet undergoing encapsulation - see section 5.1.


6.7 IPv6 Tunnel MTU


   The tunnel MTU is set dynamically to the Path MTU of the tunnel - the
   maximum  size of a packet that can be sent through the tunnel without
   fragmentation - see [RFC-1883]. The tunnel entry point node  performs
   Path MTU discovery on the tunnel [IPv6PMTU], [RFC-1885].

   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 informing 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 Fragmentation


   Although the fragmentation of tunnel packets depends on the  protocol
   of  the  original  packet, the primary condition for fragmentation is
   the size of the original packet.

   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 IPv6  packet  source  node,  a  tunnel
   entry point node must support fragmentation of tunnel packets.

   A node inside the tunnel, 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.




Conta & Deering       Expires in six months        [Page 25]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


   Depending on the tunnel packet protocol, the following  fragmentation
   can take place:

7.1 IPv6 Packet Fragmentation


   The fragmentation of tunnel packets containing IPv6 original  packets
   is performed as follows:


        (a)  if the original packet size is larger than 576 octets, then
             the  entry  point  node  returns an ICMPv6 "Packet Too Big"
             message  to  the  source  node  of  the   original   packet
             indicating  the  MTU size to be used by that node in sizing
             original packets sent towards the tunnel entry  point.  The
             MTU  is  the  original  packet  size  minus the size of the
             tunnel headers - see 8.2, and 8.3.


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



7.2 IPv4 Packet Fragmentation


   Although the fragmentation of tunnel packets depends on the  protocol
   of  the  original  packet, the primary condition for fragmentation is
   the size of the original packet:


        (a)  if the original packet size is larger than 576 octets,  and
             the  Don't  Fragment  -  DF - bit in the IPv4 header is set
             then the entry point node returns an ICMP message with type
             =  "unreachable",  code  =  "datagram too big", and the MTU
             size to be used by the original  node  in  sizing  original
             packets  sent  towards the tunnel entry point, which is the
             original packet MTU minus the size of the tunnel headers  -
             see 8.2, and 8.3.


        (b)  if the original packet is equal or smaller than 576  octets
             then  the tunnel entry point node encapsulates the original
             packet, and after encapsulation  it  breaks  the  resulting



Conta & Deering       Expires in six months        [Page 26]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


             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 errors  detected  during
   the  processing of IPv6 packets are reported to the packet originator
   through ICMP messages.

   For errors detected by nodes that are outside an IPv6  tunnel,  on  a
   path  that  includes  IPv6  tunnels,  the  errors are reported to the
   original IPv6 packet source node.

   For errors detected by  nodes  inside  an  IPv6  tunnel,  ICMP  error
   messages are sent to the tunnel IPv6 packet source node, which is the
   IPv6 tunnel entry point node. The ICMP messages sent  to  the  tunnel
   entry  point  node  have  as ICMP payload the tunnel IPv6 packet that
   includes the original packet.

   The cause of an error uncovered inside a tunnel can be:

        (a)  the tunnel header, or

        (b)  the tunnel packet.


   The tunnel header problems are reported to  the  tunnel  entry  point
   node which is the tunnel IPv6 packet originator.

   The tunnel packet problems that result from  bad  encapsulation,  are
   reported also to the tunnel entry point node.

   If the tunnel packet problems are a consequence of an original packet
   problem  and  if  they can be corrected by the source of the original
   packet, then they must be reported to both  the  tunnel  entry  point
   node and the source of the original packet.

   To report to the source of original packet a problem detected  inside
   the  tunnel  and  reported  from  inside  the  tunnel through an ICMP
   message, the tunnel entry point node must relay the ICMP  message  to
   the  source  of original IPv6 packet.  To relay the ICMP message, the
   IPv6 tunnel entry point node builds and sends an ICMP message to  the
   original  packet  originator, based on the tunnel ICMP message, as it
   is graphically described below:




Conta & Deering       Expires in six months        [Page 27]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


 +-------+   +-------+   +-----------------------+
 | Upper |   | Upper |   | Upper                 |
 | Layer |   | Layer |   | Layer                 |
 | Prot. |   | Prot. |   | IPv6 Tunnel           |
 | Error |   | Error |   | Error                 |
 | Input |   | Input |   | Input                 |
 |       |   |       |   |       Decapsulate     |
 |       |   |       |   |  -->--ICMPv6--#2->--  |
 |       |   |       |   |  |    Payload      |  |
 +-------+   +-------+   +--|-----------------|--+
     |           |          |                 |
     ^           ^          ^                 v
     |           |          |                 |
     --------------------#1--      -----Orig.Packet?--- - - - - - - - - -
error code,    |                  #3  error code,     |                 |
ICMPv6 payload ^                   v  source address, v                 v
               |            IPv6   |  orig. packet    | IPv4            |
      +--------------+    +--------------+    +--------------+    + - - - - +
      |              |    |              |    |              |
      | ICMP v6      |    | ICMP v6      |    | ICMP v4      |    |         |
      | Input        |    | Error Report |    | Error Report |
      |  -  -  -  -  +----+  -  -  -  -  |    +  -  -  -  -  +    + - - - - +
      |                                  |    |              |
      |            IPv6 Layer            |    |  IPv4 Layer  |    |         |
      |                                  |    |              |
      +----------------------------------+    +--------------+    + - - - - +

     Fig. 7. Error Reporting Flow - IPv6 Tunneling Protocol Engine

   For example, in case of IPv6 original packets, 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" which is passed with the "ICMPv6
   message payload" to the upper layer protocol - in this case the  IPv6
   tunnel  upper layer - error input (path #1 in Fig. 7, and (a) in Fig.
   8).

   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 - path #2 in Fig. 7 and (b) in Fig. 8 -
   and dispatches the "error code", the source address from the 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  -  in this example ICMPv6.  The ICMPv6 error report
   builds an ICMP message of a type and code  according  to  the  "error
   code",  containing  the "original packet" as ICMP payload - - path #3
   in Fig. 7 and (c) in Fig. 8. The ICMP message has  the  tunnel  entry



Conta & Deering       Expires in six months        [Page 28]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


   point  node address as source address, and the original packet source
   node address as destination address - (d)  in  Fig.  8.   The  tunnel
   entry  point  node  sends  the  ICMP  message  to the original packet
   originator node.

   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
        <                    Tunnel ICMP message                   >
                        <       Tunnel IPv6 packet in error        >
       +--------+      +---------+      +----------+--------//------+
       | ICMP   |      | Tunnel  |      | Original | Original       |
(b)    |        |  <-  | IPv6    |  <-  | IPv6     | IPv6 packet    |
       | Header |      | Headers |      | Headers  | payload        |
       +--------+      +---------+      +----------+--------//------+
           |                    |        <Orig. IPv6 pck. in error >
           -----------------    |         |
                 ----------|---------------
                 |         |
                 V         V
       +---------+      +--------+      +-------------------//------+
       | New     |      | ICMP   |      |                           |
(c)    | IPv6    |  ->  |        |  ->  | Orig. IPv6 packet in error|
       | Headers |      | Header |      |                           |
       +---------+      +--------+      +-------------------//------+

                             |
                             v
                 +---------+--------+-------------------//------+
                 | New     | ICMP   |  Original                 |
(d)              | IPv6    |        |  IPv6                     |
                 | Headers | Header |  packet in error          |
                 +---------+--------+-------------------//------+
                  <             new ICMP message               >

                Fig. 8.  ICMP Error reporting and processing





Conta & Deering       Expires in six months        [Page 29]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


8.1 Tunnel ICMP Messages


   The tunnel ICMP messages which are reported to  the  original  packet
   originator 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 - the tunnel hop limit must be reconfigured to a
             higher value  -  and  also  to  the  original  IPv6  packet
             originator.


        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  reconfigure  the  tunnel  with  a
             valid  and  active path between the entry and exit-point of
             the tunnel.


        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 three above problems detected inside  the  tunnel,  which  are  a
   tunnel  configuration  and a tunnel topology problem, are reported to
   the  original  IPv6  packet   originator,   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.

             When received, this ICMP message  is  used  by  the  tunnel
             entry point node to determine the tunnel MTU.

             When sent, according to  the  general  rules  described  in



Conta & Deering       Expires in six months        [Page 30]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


             section  7.1, this ICMP message is used by the tunnel entry
             point node to indicate to an original  packet  source  node
             that  original  packets  sent  from that node to the tunnel
             entry point node should be resized to the MTU indicated  by
             the ICMP message.



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 original packet source node 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:












Conta & Deering       Expires in six months        [Page 31]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


     Type           1 - unreachable node

     Code           3 - address unreachable

   For tunnel ICMP error message "packet too big":


     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 6.3, an ICMP "packet  too
   big"  message  is sent to the original packet source node only if the
   original packet size is larger than 576 octets.

   If the original packet size is smaller or equal  to  576  octets  the
   tunnel  entry  point  encapsulates  the original IPv6 packet and then
   breaks the resulting IPv6 tunnel packet into IPv6 fragments  that  do
   not exceed the tunnel MTU.


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 original packet source node 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:



Conta & Deering       Expires in six months        [Page 32]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


        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


   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 7.2,  an  ICMP  "datagram
   too big" message is sent to the original IPv4 packet source node only
   if the original packet size is larger than 576 octets.

   An additionally condition that has to be met  for  sending  the  ICMP
   message  is  that  the original IPv4 packet header must have the DF -
   don't fragment - bit flag set in the IPv6 original header.

   If the DF bit is clear,  the  tunnel  entry  point  encapsulates  the
   original IPv4 packet and then breaks the resulting IPv6 tunnel packet
   into IPv6 fragments that do not exceed the tunnel MTU.


9. Open Issues

   Open issues are:

   (a) Multicast exit point

        Does it make sense to have an IPv6 multicast address  as  tunnel
        exit-point node address?



Conta & Deering       Expires in six months        [Page 33]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


   (b) Anycast exit point

        Does it make sense to have an IPv6  anycast  address  as  tunnel
        exit-point node address?

   (c) Tunnel default hop limit value

        At this time, there is no  definition  for  an  IPv6  hop  limit
        default value.  The Assigned Numbers [RFC-1700] IPv4 TTL default
        value could be used instead.



10.References



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


   [RFC-1884]
        S. Deering, R. Hinden, "IP Version 6 Addressing Architecture".


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


   [IPv6ND]
        T. Narten, E. Nordmark, "IPv6 Neighbor Discovery Specification"


   [IPv6PMTU]
        J. McCann and S. Deering, "IPv6 Path MTU Discovery"


   [ADDRCONF]
        T. Narten, and S. Thomson, "IPv6 Address Autoconfiguration"


   [IPv6PMTU]
        J. McCann and S. Deering, "IPv6 Path MTU Discovery"


   [RFC-1700]



Conta & Deering       Expires in six months        [Page 34]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


        J. Reynolds, J. Postel, "Assigned Numbers", 10/20/1994


   [RFC-1853]
        W. Simpson, "IPv4 Tunneling",



11.Acknowledgements

   The document is partially derived from several ideas about tunneling,
   from  several  discussions  about  IPv6 in IPv6 tunneling on the IPng
   Working Group Mailing List, and from feedback from an IPv6  tunneling
   focused  IPng  Working  Group session at the 33th IETF, in Stockholm,
   July 1995.

   Additionally, several documents focused on tunneling or encapsulation
   were  used  as a reference: "Transition Mechanisms for IPv6 Hosts and
   Routers" document by Robert Gilligan and Erik Nordmark, RFC 1241  (R.
   Woodburn,  and  D.  Mills), RFC 1326 (P. Tsuchiya), RFC 1701, and RFC
   1702 (S. Hanks, D. Farinacci, P. Traina), RFC 1834 (W. Simpson),  and
   Mobile IP working Group drafts (C. Perkins).

   Also an important contribution was made  by  the  reviewers  of  this
   document:

   Brian Carpenter, Erik Nordmark.  [TBD]

12.Security Considerations


   Security considerations are not discussed in this memo.

Authors' Addresses:

   Alex Conta                               Stephen Deering
   Digital Equipment Corporation            Xerox Palo Alto Research Center
   110 Spitbrook Rd                         3333 Coyote Hill Road
   Nashua, NH 03062                         Palo Alto, CA 94304
   +1-603-881-0744                          +1-415-812-4839

   email: conta@zk3.dec.com                 email: deering@parc.xerox.com

Appendix A

   Fixed-end Inner tunnels with different entry-points and
   identical exit-points




Conta & Deering       Expires in six months        [Page 35]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


      node    node    node       node   node   node    node

      a.a.1   b.b.1   c.c.1 ...  x ...  y ...  d.d.1   z.z.1
              *       **                               * **

   tunnel I from b.b.1 to z.z.1
   tunnel II from c.c.1 to z.z.1

   1. node a.a.1:

           xmt: aa1/zz1   (source=aa1 destination=zz1)
                     to bb1

   2. node b.b.1:

           rcv: aa1/zz1

           forwarding: anything that is destined to prefix 'z' => tunnel 'bb1/z
z1'
                           and send to cc1

           xmt: bb1/zz1 | aa1/zz1
                     to cc1

   3. node cc1:

           rcv: bb1/zz1 | aa1/zz1

           forwarding: anything that is destined to prefix 'z' => tunnel 'cc1/z
z1'
                           and send to next router on the way to dd1

           xmt: cc1/zz1 | bb1/zz1 | aa1/zz1
                     to next router on the way to dd1

   4. before reaching node dd1, routing loop brings packet to bb1

   loop::
   node bb1:

           rcv: cc1/zz1 | bb1/zz1 | aa1/zz1

           forwarding: anything that is destined  to prefix 'z' => tunnel 'bb1/
zz1'
                           and send to cc1

           xmt: bb1/zz1 | cc1/zz1 | bb1/zz1 | aa1/zz1
                     to cc1

   5. node cc1:




Conta & Deering       Expires in six months        [Page 36]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


           rcv: bb1/zz1 | cc1/zz1 | bb1/zz1 | aa1/zz1

           forwarding: anything that is destined  to prefix 'z' => tunnel 'cc1/
zz1'

           xmt: cc1/zz1 | bb1/zz1 | cc1/zz1 | bb1/zz1 | aa1/zz1
                     to next router on the way to dd1

   NOTE: check on source address = packet source DOES NOT eliminate the recursi
ve
           encapsulation

Appendix B


   Default Tunnel - maximum risk for excessive recursive
   encapsulation in case of routing loops.

   node    node    node    node    node    node    node

   a.a.1   b.b.1   c.c.1   d.d.1   e.e.1   f.f.1   z.z.1
           *       **              **      *

   tunnel I        from b.b.1 to f.f.1
   tunnel II       from c.c.1 to e.e.1



   1. node aa1:

           xmt: aa1/zz1   (source=aa1 destination=zz1)

   2. node bb1:

           rcv: aa1/zz1

           forwarding:
                   anything that does not go to prefix 'a' or 'c'
                           => tunnel 'bb1/ff1' and send to cc1

           xmt: bb1/ff1 | aa1/zz1

   3. node cc1:

           rcv: bb1/ff1 | aa1/zz1

           forwarding: anything that does not go to prefix 'a', or 'b', or 'd'
                           => tunnel 'cc1/ee1' and send to next router on
                                   the way to ee1




Conta & Deering       Expires in six months        [Page 37]


INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


           xmt: cc1/ee1 | bb1/ff1 | aa1/zz1
                   to next router on the way to ee1

   4. before reaching node ee1, routing loop brings packet to bb1

   loop::
   node bb1:

           rcv: cc1/ee1 | bb1/ff1 | aa1/zz1

           forwarding:
                   anything that does not go to prefix 'a' or 'c'
                           => tunnel 'bb1/ff1' and send to cc1

           xmt: bb1/ff1 | cc1/ee1 | bb1/ff1 | aa1/zz1
                   to cc1

   5. node cc1:

           rcv: bb1/ff1 | cc1/ee1 | bb1/ff1 | aa1/zz1

           forwarding: anything that does not go to prefix 'a', or 'b', or 'd'
                           => tunnel 'cc1/ee1'

           xmt: cc1/ee1 | bb1/ff1 | cc1/ee1 | bb1/ff1 | aa1/zz1

   NOTE: check on source address = packet source DOES NOT eliminate the recursi
ve
           encapsulation


Changes from previous version.


   - add new sections:

           3.4 IPv6 Tunnels and Address Formats........................13
           3.5 IPv6 Tunnels and IPv6 Autoconfiguration.................13
           3.6 IPv6 Tunnels and IPv6 Neighbor Discovery................13
           4.1.4  Risk Factors in Recursive Encapsulation..............17
           Appendix A..Inner tunnels...................................35
           Appendix B..Default tunnels.................................37

   - separate fragmentation from section 6.7 into a new
   section:

           7. IPv6 Tunnel Packet Fragmentation.........................25
               7.1 IPv6 Packet Fragmentation...........................25
               7.2 IPv4 Packet Fragmentation...........................26



Conta & Deering       Expires in six months        [Page 38]

INTERNET-DRAFT             Tunneling in IPv6           February 22, 1996


   - include comments from Erik Nordmark

           - some of the comments are part of the modifications
                   mentioned above.

           - Section 5: flow label
                   "tipical" corrected to "typical".

           - Section 6.2:
                   changed from multi-point to point-to-point

           - section 8.1
                   replace "original packet originator" with
                   "source of original packet".






































------- End of Forwarded Message


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