[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.129b, available from
https://tools.ietf.org/tools/rfcmarkup/