IPng Working Group A. Conta (Lucent Technologies Inc.)
INTERNET-DRAFT S. Deering (Cisco Systems)
November 1996
Generic Packet Tunneling in IPv6
Specification
draft-ietf-ipngwg-ipv6-tunnel-05.txt
Status of this Memo
This document is an Internet Draft. Internet Drafts are working doc-
uments of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute work-
ing 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 26 November 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.......................13
4.1.2 Loopback Encapsulation...........................15
4.1.3 Routing Loop Nested Encapsulation................15
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.............................19
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.........................................21
7. IPv6 Tunnel Packet Size Issues...............................22
7.1 IPv6 Tunnel Packet Fragmentation........................22
7.2 IPv4 Tunnel Packet Fragmentation........................23
8. IPv6 Tunnel Error Reporting and Processing...................23
8.1 Tunnel ICMP Messages....................................27
8.2 ICMP Messages for IPv6 Original Packets.................28
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 26 November 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 encapsula-
tion. It specifies the tunnel end-points as source and destina-
tion.
tunnel packet
a packet that encapsulates an original packet.
Conta & Deering Expires in six months [Page 3]
INTERNET-DRAFT Tunneling in IPv6 26 November 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 tun-
nel 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.
Conta & Deering Expires in six months [Page 4]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
nested tunnel header
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 pack-
ets received from other nodes or from itself and forwards the result-
ing tunnel packets through the tunnel. The other node decapsulates
the received tunnel packets and forwards the resulting original pack-
ets 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 iden-
tified by unicast addresses - such tunnels look like "virtual point
to point links". Some of the mechanisms described herein apply also
to tunnels in which the entry and exit-point nodes are identified by
other types of addresses, such as anycast or multicast. These tun-
nels look like "virtual point to multipoint links". At the time of
writing this document, such addresses, in particular anycast
addresses are a subject of ongoing specification and experimental
work. Therefore it is not in the scope of this document to describe
in detail mechanisms of tunnels between nodes identified by anycast
or multicast addresses.
Conta & Deering Expires in six months [Page 5]
INTERNET-DRAFT Tunneling in IPv6 26 November 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 direc-
tion 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 26 November 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 encap-
sulation 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 encapsu-
lates 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 26 November 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 head-
ers 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 Proto-
col value, the resulting original packet is passed to the IPv6 proto-
col layer.
Conta & Deering Expires in six months [Page 8]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
The tunnel exit-point node, which decapsulates the tunnel packets,
and the destination node, which receives the resulting original pack-
ets 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 26 November 1996
Note:
In Fig.5, the Upper-Layer Protocols box represents transport proto-
cols such as TCP, UDP, control protocols such as ICMP, routing proto-
cols such as OSPF, and internet or lower-layer protocol being "tun-
neled" 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 tun-
nels.
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 tun-
nel 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 fur-
ther 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 26 November 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 tun-
nels.
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 26 November 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 destina-
tion.
(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 tun-
nels 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 pack-
ets 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 26 November 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 encapsula-
tions, 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 encap-
sulations may require fragmentation [RFC-1883] - see section 7. Fur-
thermore, 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 frag-
mentation. 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 Destina-
tion Option header.
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-
Conta & Deering Expires in six months [Page 13]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
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 - indi-
cate "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 des-
tination [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 "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
Conta & Deering Expires in six months [Page 14]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
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 tun-
nel 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 loop-
back 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.
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 particu-
larly 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 nega-
tive 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
Conta & Deering Expires in six months [Page 15]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
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 orig-
inal 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
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.
Conta & Deering Expires in six months [Page 16]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
Payload Length:
The original packet length, plus the length of the encapsu-
lating (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 adver-
tised 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 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
Conta & Deering Expires in six months [Page 17]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
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 exam-
ple, 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).
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 des-
tination options header.
Option Type:
value 4 - see section 4.1.1.
Opt Data Len:
value 1 - see section 4.1.1.
Conta & Deering Expires in six months [Page 18]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
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 config-
ured 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.
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 con-
figured 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
Conta & Deering Expires in six months [Page 19]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
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.
Note:
This document refers to tunnels in which the exit-point node is iden-
tified by a unicast address. Although some of the mechanisms
described herein apply also to tunnels in which the entry and exit-
point nodes are identified by other types of addresses, such as any-
cast or multicast, specific mechanisms for such tunnels may need fur-
ther specification.
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
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
Conta & Deering Expires in six months [Page 20]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
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 indi-
cate 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 Encapsula-
tion Limit is the maximum number of encapsulations permitted for
packets undergoing encapsulation at that entry-point node. Recom-
mended 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.
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 tun-
nel 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 tun-
nel minus the size of the tunnel headers.
Conta & Deering Expires in six months [Page 21]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
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 tun-
nel 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 tun-
nel packet is an exit-point node identified by an anycast address.
The problem is similar to that of original fragmented IPv6 packets
destined to nodes identified by an anycast address. As in that case,
a mechanism must be used to make sure that all the fragments of a
packet arrive to one node, for that node to be able to perform a suc-
cessful reassembly.
7.1 IPv6 Tunnel Packet Fragmentation
Tunnel packets that exceed the tunnel MTU are candidates for fragmen-
tation. The fragmentation of tunnel packets containing IPv6 original
packets is performed as follows:
Conta & Deering Expires in six months [Page 22]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
(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 recom-
mended MTU size field set to the size of the tunnel MTU - see
section 6.7, and 8.3.
(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 tun-
nel 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.
Conta & Deering Expires in six months [Page 23]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
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 mes-
sage 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 report-
ing 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
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.
Fig.7 path #2 and Fig.8 (b) - The IPv6 tunnel error input decapsu-
lates the tunnel IPv6 packet, which is the ICMPv6 message payload,
obtaining the original packet, and thus the original headers and dis-
patches the "internal error code", the source address from the origi-
nal packet header, and the original packet, down to the error report
block of the protocol identified by the Next Header field in the tun-
nel header immediately preceding the original packet in the ICMP
Conta & Deering Expires in six months [Page 24]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
message payload.
+-------+ +-------+ +-----------------------+
| 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)
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.
Conta & Deering Expires in six months [Page 25]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
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
< Tunnel ICMP Message >
< Tunnel IPv6 Packet in Error >
+--------+ +---------+ +----------+--------//------+
| ICMP | | Tunnel | | Original | Original |
(b) | | + | IPv6 | + | | Packet |
| Header | | Headers | | Headers | Payload |
+--------+ +---------+ +----------+--------//------+
| <Original Packet in Error >
----------------- |
| |
Conta & Deering Expires in six months [Page 26]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
--------------|---------------
| |
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
8.1 Tunnel ICMP Messages
The tunnel ICMP messages that are reported to the source of the orig-
inal packet are:
hop limit exceeded
The tunnel has a misconfigured hop limit, or contains a rout-
ing 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.
Conta & Deering Expires in six months [Page 27]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
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 reach-
able. 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 tun-
nel 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:
- 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
Conta & Deering Expires in six months [Page 28]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
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":
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.
Conta & Deering Expires in six months [Page 29]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
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
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 -
Conta & Deering Expires in six months [Page 30]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
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 a security header in conformance with [RFC1883], [RFC1825],
and [RFC1826], or [RFC1827].
The exit-point node of a secure IPv6 tunnel performs security algo-
rithms and processes the tunnel security header as part of the tunnel
headers processing described earlier, and in conformance with
[RFC1825], and [RFC1826], or [RFC1827]. The tunnel security header
is discarded with the rest of the tunnel headers after tunnel headers
processing completion.
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 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 tun-
nels, each inner tunnel may have its own set of security services,
independently from the outer tunnels security services, or of the
path between the source and destination of the original packet.
Conta & Deering Expires in six months [Page 31]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
10. Acknowledgments
This document is partially derived from several discussions about
IPv6 tunneling on the IPng Working Group Mailing List and from feed-
back 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, and (in alphabetical order) gave valuable reviewing com-
ments 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 Speci-
fication"
[RFC-1885] A. Conta, and S. Deering "Internet Control Message Proto-
col for the Internet Protocol Version 6 (IPv6)"
[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 Pro-
tocol"
[RFC-1826] R. Atkinson, "IP Authentication Header"
Conta & Deering Expires in six months [Page 32]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
[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 26 November 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 26 November 1996
information used to decide whether to forward a packet through a tun-
nel or not, a recursive encapsulation can be avoided in case of a
single tunnel (non-inner), by checking that the packet to be encapsu-
lated 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 dif-
ferent than the entry-point node of the outer tunnel, the source
address checking (mentioned above) fails to detect an invalid encap-
sulation, 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 identi-
fied 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 speci-
fied 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
route, or a route to an unspecified destination. This route is
Conta & Deering Expires in six months [Page 35]
INTERNET-DRAFT Tunneling in IPv6 26 November 1996
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 fac-
tor for recursive encapsulation is minimum.
If the route to a tunnel exit-point is a route to net, the risk fac-
tor for recursive encapsulation is medium. There is a range of desti-
nation 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 fac-
tor for recursive encapsulation is maximum. Packets are forwarded
through a default tunnel for lack of a better route. In many situa-
tions, 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 differ-
ently, based on the destination.
Conta & Deering Expires in six months [Page 36]
