As per Relevance of the word encapsulation, we have this rfc below:
Network Working Group A.
Request for Comments: 2473 Lucent Technologies Inc
Category: Standards Track S.
Cisco
December 1998
Generic Packet Tunneling in IPv
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document defines the model and generic mechanisms for IPv
encapsulation of Internet packets, such as IPv6 and IPv4. The
and mechanisms can be applied to other protocol packets as well,
as AppleTalk, IPX, CLNP, or others
Table of
1. Introduction..................................................2
2. Terminology...................................................2
3. IPv6 Tunneling................................................4
3.1 IPv6 Encapsulation.......................................6
3.2 IPv6 Packet Processing in Tunnels........................7
3.3 IPv6 Decapsulation.......................................7
3.4 IPv6 Tunnel Protocol Engine..............................8
4. Nested Encapsulation.........................................11
4.1 Limiting Nested Encapsulation..........................12
4.1.1 Tunnel Encapsulation Limit Option................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...........................17
6. IPv6 Tunnel State Variables..................................19
6.1 IPv6 Tunnel Entry-Point Node............................19
6.2 IPv6 Tunnel Exit-Point Node.............................19
Conta & Deering Standards Track [Page 1]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
6.3 IPv6 Tunnel Hop Limit...................................19
6.4 IPv6 Tunnel Packet Traffic Class........................20
6.5 IPv6 Tunnel Flow Label..................................20
6.6 IPv6 Tunnel Encapsulation Limit.........................20
6.7 IPv6 Tunnel MTU.........................................20
7. IPv6 Tunnel Packet Size Issues...............................21
7.1 IPv6 Tunnel Packet Fragmentation........................21
7.2 IPv4 Tunnel Packet Fragmentation........................22
8. IPv6 Tunnel Error Reporting and Processing...................22
8.1 Tunnel ICMP Messages....................................27
8.2 ICMP Messages for IPv6 Original Packets.................28
8.3 ICMP Messages for IPv4 Original Packets.................29
8.4 ICMP Messages for Nested Tunnel Packets.................30
9. Security Considerations......................................30
10. Acknowledgments.............................................31
11. References..................................................31
Authors' Addresses..............................................32
Appendix A. Risk Factors in Recursive Encapsulation.............33
Full Copyright Statement........................................36
1.
This document specifies a method and generic mechanisms by which
packet is encapsulated and carried as payload within an IPv6 packet
The resulting packet is called an IPv6 tunnel packet. The
path between the source and destination of the tunnel packet
called an IPv6 tunnel. The technique is called IPv6 tunneling
A typical scenario for IPv6 tunneling is the case in which
intermediate node exerts explicit routing control by
particular forwarding paths for selected packets. This control
achieved by prepending IPv6 headers to each of the selected
packets. These prepended headers identify the forwarding paths
In addition to the description of generic IPv6 tunneling mechanisms
which is the focus of this document, specific mechanisms
tunneling IPv6 and IPv4 packets are also described herein
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED
SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as
in RFC 2119.
2.
original
a packet that undergoes encapsulation
Conta & Deering Standards Track [Page 2]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
original
the header of an original packet
a forwarding path between two nodes on which the payloads
packets are original packets
tunnel end-
a node where a tunnel begins or ends
tunnel
the header prepended to the original packet
encapsulation. It specifies the tunnel end-points as source
destination
tunnel
a packet that encapsulates an original packet
tunnel entry-
the tunnel end-node where an original packet is encapsulated
tunnel exit-
the tunnel end-node where a tunnel packet is decapsulated
IPv6
a tunnel configured as a virtual link between two IPv6 nodes,
which the encapsulating protocol is IPv6.
tunnel
the maximum size of a tunnel packet payload without
fragmentation, that is, the Path MTU between the tunnel entry
point and the tunnel exit-point nodes minus the size of
tunnel header
tunnel hop
the maximum number of hops that a tunnel packet can travel
the tunnel entry-point to the tunnel exit-point
Conta & Deering Standards Track [Page 3]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
inner
a tunnel that is a hop (virtual link) of another tunnel
outer
a tunnel containing one or more inner tunnels
nested tunnel
a tunnel packet that has as payload a tunnel packet
nested tunnel
the tunnel header of a nested tunnel packet
nested
encapsulation of an encapsulated packet
recursive
encapsulation of a packet that reenters a tunnel before
it
tunnel encapsulation
the maximum number of nested encapsulations of a packet
3. IPv6
IPv6 tunneling is a technique for establishing a "virtual link
between two IPv6 nodes for transmitting data packets as payloads
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
point link on which IPv6 acts like a link-layer protocol. The
IPv6 nodes play specific roles. One node encapsulates
packets received from other nodes or from itself and forwards
resulting tunnel packets through the tunnel. The other
decapsulates the received tunnel packets and forwards the
original packets towards their destinations, possibly itself.
encapsulator node is called the tunnel entry-point node, and it
the source of the tunnel packets. The decapsulator node is called
tunnel exit-point, and it is the destination of the tunnel packets
Conta & Deering Standards Track [Page 4]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
Note
This document refers in particular to tunnels between two
identified by unicast addresses - such tunnels look like "
point to point links". The mechanisms described herein apply also
tunnels in which the exit-point nodes are identified by other
of addresses, such as anycast or multicast. These tunnels may
like "virtual point to multipoint links". At the time of writing
document, IPv6 anycast addresses are a subject of
specification and experimental work
Tunnel from node B to node
<---------------------->
Tunnel
Entry-Point Exit-
Node
+-+ +-+ +-+ +-+
|A|-->--//-->--|B|=====>=====//=====>=====|C|-->--//-->--|D
+-+ +-+ +-+ +-+
Original
Packet
Source
Node
Fig.1
An IPv6 tunnel is a unidirectional mechanism - tunnel packet
takes place in one direction between the IPv6 tunnel entry-point
exit-point nodes (see Fig.1).
Tunnel from Node B to Node
<------------------------>
Tunnel
Original Entry-Point Exit-Point
Packet Node Node
Source
Node
+-+ +-+ +-+ +-+
| |-->--//-->--| |=====>=====//=====>======| |-->--//-->--| |
|A| |B| |C| |D
| |--<--//--<--| |=====<=====//=====<======| |--<--//--<--| |
+-+ +-+ +-+ +-+
Original
Packet
Destination Tunnel Tunnel
Node Exit-Point Entry-Point
Node
<------------------------->
Tunnel from Node C to Node
Fig.2 Bi-directional Tunneling
Conta & Deering Standards Track [Page 5]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
Bi-directional tunneling is achieved by merging two
mechanisms, that is, configuring two tunnels, each in
direction to the other - the entry-point node of one tunnel is
exit-point node of the other tunnel (see Fig.2).
3.1 IPv6
IPv6 encapsulation consists of prepending to the original packet
IPv6 header and, optionally, a set of IPv6 extension headers (
Fig.3), which are collectively called tunnel IPv6 headers.
encapsulation takes place in an IPv6 tunnel entry-point node, as
result of an original packet being forwarded onto the virtual
represented by the tunnel. The original packet is processed
forwarding according to the forwarding rules of the protocol of
packet. For instance if the original packet is an
(a) IPv6 packet, the IPv6 original header hop limit is
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
filled with an IPv6 address of the tunnel entry-point node, and
destination field with an IPv6 address of the tunnel exit-point
Subsequently, the tunnel packet resulting from encapsulation is
towards the tunnel exit-point node
+----------------------------------//-----+
| Original | |
| | Original Packet Payload |
| Header | |
+----------------------------------//-----+
< Original Packet >
|
< Original Packet >
+---------+ - - - - - +-------------------------//--------------+
| IPv6 | IPv6 | |
| | Extension | Original Packet |
| Header | Headers | |
+---------+ - - - - - +-------------------------//--------------+
< Tunnel IPv6 Packet >
Fig.3 Encapsulating a
Conta & Deering Standards Track [Page 6]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
Tunnel extension headers should appear in the order recommended
the specifications that define the extension headers, such as [IPv6-
Spec].
A source of original packets and a tunnel entry-point
encapsulates those packets can be the same node
3.2 Packet Processing in
The intermediate nodes in the tunnel process the IPv6 tunnel
according to the IPv6 protocol. For example, a tunnel Hop by
Options extension header is processed by each receiving node in
tunnel; a tunnel Routing extension header identifies the
processing nodes, and controls at a finer granularity the
path of the tunnel packet through the tunnel; a tunnel
Options extension header is processed at the tunnel exit-point node
3.3 IPv6
Decapsulation is graphically shown in Fig.4:
+---------+- - - - - -+----------------------------------//-----+
| IPv6 | IPv6 | |
| | Extension | Original Packet |
| Header | Headers | |
+---------+- - - - - -+----------------------------------//-----+
< Tunnel IPv6 Packet >
|
+----------------------------------//-----+
| Original | |
| | Original Packet Payload |
| Headers | |
+----------------------------------//-----+
< Original Packet >
Fig.4 Decapsulating a
Upon receiving an IPv6 packet destined to an IPv6 address of a
exit-point node, its IPv6 protocol layer processes the
headers. The strict left-to-right processing rules for
headers is applied. When processing is complete, control is handed
the next protocol engine, which is identified by the Next
field value in the last header processed. If this is set to a
protocol value, the tunnel protocol engine discards the
headers and passes the resulting original packet to the Internet
lower layer protocol identified by that value for further processing
Conta & Deering Standards Track [Page 7]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
For example, in the case the Next Header field has the IPv6
Protocol value, the resulting original packet is passed to the IPv
protocol layer
The tunnel exit-point node, which decapsulates the tunnel packets
and the destination node, which receives the resulting
packets can be the same node
3.4 IPv6 Tunnel Protocol
Packet flow (paths #1-7) through the IPv6 Tunnel Protocol Engine on
node is graphically shown in Fig.5:
Note
In Fig.5, the Upper-Layer Protocols box represents
protocols such as TCP, UDP, control protocols such as ICMP,
protocols such as OSPF, and internet or lower-layer protocol
"tunneled" over IPv6, such as IPv4, IPX, etc. The Link-
Protocols box represents Ethernet, Token Ring, FDDI, PPP, X.25,
Relay, ATM, etc..., as well as internet layer "tunnels" such as IPv
tunnels
The IPv6 tunnel protocol engine acts as both an "upper-layer" and
"link-layer", each with a specific input and output as follows
(u.i) "tunnel upper-layer input" - consists of tunnel IPv6
that are going to be decapsulated. The tunnel packets
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
undergo decapsulation
(u.i.2) a tunnel link-layer - (path #7, Fig.5)
These are tunnel packets that underwent one or
decapsulations on this node, that is, the packets
one or more nested tunnel headers and one nested
header was just discarded. This node is the exit-
of both an outer tunnel and one or more of its
tunnels
For both above cases the resulting original packets are
back to the IPv6 layer as "tunnel link-layer" output
further processing (see b.2).
Conta & Deering Standards Track [Page 8]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
+-----------------------+ +-----------------------------------+
| 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
(u.o) "tunnel upper-layer output" - consists of tunnel IPv6
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
towards the tunnel exit-
(u.o.2) a tunnel link-layer - (path #8, Fig.5)
These tunnel packets undergo nested encapsulation
This node is the entry-point node of both an
tunnel and one or more of its inner tunnel
Conta & Deering Standards Track [Page 9]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
Implementation Note
The tunnel upper-layer input and output can be implemented
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
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
that undergo encapsulation. The original packet
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
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
encapsulation. This node is the entry-point node
both an outer tunnel and one or more of its
tunnels
The resulting tunnel packets are passed as tunnel upper-
output packets through the IPv6 layer (see u.o) down to
(l.o) "tunnel link-layer output" - consists of original IPv6
resulting from decapsulation. These packets are passed through
IPv6 layer to
(l.o.1) an upper-layer - (path #3, Fig.5)
These original packets are destined to this node
(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
destination
Conta & Deering Standards Track [Page 10]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
(l.o.3) a tunnel upper-layer - (path #7, Fig.5)
These packets undergo another decapsulation; they
nested tunnel packets. This node is both the exit
point node of an outer tunnel and one or more
tunnels
Implementation Note
The tunnel link-layer input and output can be implemented
to the input and output of other link-layer protocols,
instance, associating an interface or pseudo-interface with
IPv6 tunnel
The selection of the "IPv6 tunnel link" over other links
from the packet forwarding decision taken based on the content
the node's routing table
4. Nested
Nested IPv6 encapsulation is the encapsulation of a tunnel packet
It takes place when a hop of an IPv6 tunnel is a tunnel. The
containing a tunnel is called an outer tunnel. The tunnel
in the outer tunnel is called an inner tunnel - see Fig.6.
tunnels and their outer tunnels are nested tunnels
The entry-point node of an "inner IPv6 tunnel" receives tunnel IPv
packets encapsulated by the "outer IPv6 tunnel" entry-point node.
"inner tunnel entry-point node" treats the receiving tunnel
as original packets and performs encapsulation. The
packets are "tunnel packets" for the "inner IPv6 tunnel", and "
tunnel packets" for the "outer IPv6 tunnel".
Conta & Deering Standards Track [Page 11]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
Outer
<------------------------------------->
<--links--><-virtual link-><--links--->
Inner
Outer Tunnel Outer
Entry-Point Exit-
Node
+-+ +-+ +-+ +-+ +-+ +-+
| | | | | | | | | | | |
| |->-//->-| |=>=//=>=| |**>**//**>**| |=>=//=>==| |->-//->-| |
| | | | | | | | | | | |
+-+ +-+ +-+ +-+ +-+ +-+
Original Inner Tunnel Inner Tunnel
Packet Entry-Point Exit-Point
Source Node Node
Node
Fig.6. Nested
4.1 Limiting Nested
A tunnel IPv6 packet is limited to the maximum IPv6 packet
[IPv6-Spec]. Each encapsulation adds to the size of an
packet the size of the tunnel IPv6 headers. Consequently, the
of tunnel headers, and therefore, the number of nested
is limited by the maximum packet size. However this limit is
large (more than 1600 encapsulations for an original packet
minimum size) that it is not an effective limit in most cases
The increase in the size of a tunnel IPv6 packet due to
encapsulations may require fragmentation [IPv6-Spec] at a
entry point - see section 7. Furthermore, each fragmentation, due
nested encapsulation, of an already fragmented tunnel packet
in a doubling of the number of fragments. Moreover, it is
that once this fragmentation begins, each new nested
results in yet additional fragmentation. Therefore limiting
encapsulation is recommended
The proposed mechanism for limiting excessive nested encapsulation
a "Tunnel Encapsulation Limit" option, which is carried in an IPv
Destination Options extension header accompanying an
IPv6 header
Conta & Deering Standards Track [Page 12]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
4.1.1 Tunnel Encapsulation Limit
A tunnel entry-point node may be configured to include a
Encapsulation Limit option as part of the information prepended
all packets entering a tunnel at that node. The Tunnel
Limit option is carried in a Destination Options extension
[IPv6-Spec] placed between the encapsulating IPv6 header and the IPv
header of the original packet. (Other IPv6 extension headers
also be present preceding or following the Destination
extension header, depending on configuration information at
tunnel entry-point node.)
The Tunnel Encapsulation Limit option specifies how many
levels of encapsulation are permitted to be prepended to the
-- or, in other words, how many further levels of nesting the
is permitted to undergo -- not counting the encapsulation in
the option itself is contained. For example, a Tunnel
Limit option containing a limit value of zero means that a
carrying that option may not enter another tunnel before exiting
current tunnel
The Tunnel Encapsulation Limit option has the following format
Option Type Opt Data Len Opt Data
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| 1 | Tun Encap Lim |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type decimal value 4
- the highest-order two bits - set to 00 -
indicate "skip over this option if the option
not recognized".
- the third-highest-order bit - set to 0 -
indicates that the option data in this
does not change en route to the packet'
destination [IPv6-Spec].
Opt Data Len value 1 - the data portion of the Option is one
long
Opt Data Value the Tunnel Encapsulation Limit value - 8-
unsigned integer specifying how many
levels of encapsulation are permitted for
Conta & Deering Standards Track [Page 13]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
Tunnel Encapsulation Limit options are of interest only to
entry points. A tunnel entry-point node is required to execute
following procedure for every packet entering a tunnel at that node
(a) Examine the packet to see if a Tunnel Encapsulation
option is present following its IPv6 header. The
following the IPv6 header must be examined in
"left-to-right" order, with the examination stopping
soon as any one of the following headers is encountered
(i) a Destination Options extension header containing
Tunnel Encapsulation Limit, (ii) another IPv6 header, (iii
a non-extension header, such as TCP, UDP, or ICMP, or (iv
a header that cannot be parsed because it is encrypted
its type is unknown. (Note that this requirment is
exception to the general IPv6 rule that a
Options extension header need only be examined by
packet's destination node. An alternative and "cleaner
approach would have been to use a Hop-by-Hop
header for this purpose, but that would have imposed
undesirable extra processing burden, and
consequent extra delay, at every IPv6 node along the
of a tunnel.)
(b) If a Tunnel Encapsulation Limit option is found in
packet entering the tunnel and its limit value is zero,
packet is discarded and an ICMP Parameter Problem
[ICMP-Spec] is sent to the source of the packet, which
the previous tunnel entry-point node. The Code field
the Parameter Problem message is set to zero ("
header field encountered") and the Pointer field is set
point to the third octet of the Tunnel Encapsulation
option (i.e., the octet containing the limit value
zero).
(c) If a Tunnel Encapsulation Limit option is found in
packet entering the tunnel and its limit value is non-zero
an additional Tunnel Encapsulation Limit option must
included as part of the encapsulating headers being
at this entry point. The limit value in the
option is set to one less than the limit value found in
packet being encapsulated
(d) If a Tunnel Encapsulation Limit option is not found in
packet entering the tunnel and if an encapsulation
has been configured for this tunnel, a Tunnel
Limit option must be included as part of the
headers being added at this entry point. The limit
in the option is set to the configured limit
Conta & Deering Standards Track [Page 14]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
(e) If a Tunnel Encapsulation Limit option is not found in
packet entering the tunnel and if no encapsulation
has been configured for this tunnel, then no
Encapsulation Limit option is included as part of
encapsulating headers being added at this entry point
A Tunnel Encapsulation Limit option added at a tunnel entry-
node is removed as part of the decapsulation process at that tunnel'
exit-point node
Two cases of encapsulation that should be avoided are
below
4.1.2 Loopback
A particular case of encapsulation which must be avoided is
loopback encapsulation. Loopback encapsulation takes place when
tunnel IPv6 entry-point node encapsulates tunnel IPv6
originated from itself, and destined to itself. This can generate
infinite processing loop in the entry-point node
To avoid such a case, it is recommended that an implementation have
mechanism that checks and rejects the configuration of a tunnel
which both the entry-point and exit-point node addresses belong
the same node. It is also recommended that the encapsulating
check for and reject the encapsulation of a packet that has the
of tunnel entry-point and exit-point addresses identical with
pair of original packet source and final destination addresses
4.1.3 Routing-Loop Nested
In the case of a forwarding path with multiple-level nested tunnels
a routing-loop from an inner tunnel to an outer tunnel
particularly dangerous when packets from the inner tunnels reenter
outer tunnel from which they have not yet exited. In such a case,
nested encapsulation becomes a recursive encapsulation with
negative effects described in 4.1. Because each nested
adds a tunnel header with a new hop limit value, the IPv6 hop
mechanism cannot control the number of times the packet reaches
outer tunnel entry-point node, and thus cannot control the number
recursive encapsulations
When the path of a packet from source to final destination
tunnels, the maximum number of hops that the packet can
should be controlled by two mechanisms used together to avoid
negative effects of recursive encapsulation in routing loops
Conta & Deering Standards Track [Page 15]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
(a) the original packet hop limit
It is decremented at each forwarding operation performed
an original packet. This includes each encapsulation of
original packet. It does not include nested
of the original
(b) the tunnel IPv6 packet encapsulation limit
It is decremented at each nested encapsulation of
packet
For a discussion of the excessive encapsulation risk factors
nested encapsulation see Appendix A
5. Tunnel IPv6
The tunnel entry-point node fills out a tunnel IPv6 main
[IPv6-Spec] as follows
Version
value 6
Traffic Class
Depending on the entry-point node tunnel configuration,
traffic class can be set to that of either the
packet or a pre-configured value - see section 6.4.
Flow Label
Depending on the entry-point node tunnel configuration,
flow label can be set to a pre-configured value. The
value is zero - see section 6.5.
Payload Length
The original packet length, plus the length of
encapsulating (prepended) IPv6 extension headers, if any
Next Header
The next header value according to [IPv6-Spec] from
Assigned Numbers RFC [RFC-1700 or its successors].
For example, if the original packet is an IPv6 packet,
is set to
Conta & Deering Standards Track [Page 16]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
- decimal value 41 (Assigned Next Header number
IPv6) - if there are no tunnel extension headers
- value 0 (Assigned Next Header number for IPv6 Hop
Hop Options extension header) - if a hop by hop
extension header immediately follows the tunnel IPv
header
- decimal value 60 (Assigned Next Header number
IPv6 Destination Options extension header) - if
destination options extension header
follows the tunnel IPv6 header
Hop Limit
The tunnel IPv6 header hop limit is set to a pre-
value - see section 6.3.
The default value for hosts is the Neighbor
advertised hop limit [ND-Spec]. The default value
routers is the default IPv6 Hop Limit value from
Assigned Numbers RFC (64 at the time of writing
document).
Source Address
An IPv6 address of the outgoing interface of the
entry-point node. This address is configured as the
entry-point node address - see section 6.1.
Destination Address
An IPv6 address of the tunnel exit-point node. This
is configured as the tunnel exit-point node address -
section 6.2.
5.1 Tunnel IPv6 Extension
Depending on IPv6 node configuration parameters, a tunnel entry-
node may append to the tunnel IPv6 main header one or more IPv
extension headers, such as a Hop-by-Hop Options header, a
header, or others
Conta & Deering Standards Track [Page 17]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
To limit the number of nested encapsulations of a packet, if it
configured to do so - see section 6.6 - a tunnel entry-point
a Destination Options extension header containing a
Encapsulation Limit option. If that option is the only option
in the Destination Options header, the header has the
format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
example, if the original packet is an IPv6 packet, the
header protocol value is set to decimal value 41 (
payload type number for IPv6).
Hdr Ext Len
Length of the Destination Options extension header in 8-
octet units, not including the first 8 octets. Set to
0, if no other options are present in this
options header
Option Type
value 4 - see section 4.1.1.
Opt Data Len
value 1 - see section 4.1.1.
Tun Encap Lim
8 bit unsigned integer - see section 4.1.1.
Option Type
value 1 - PadN option, to align the header
this header
Opt Data Len
value 1 - one octet of option data
Conta & Deering Standards Track [Page 18]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
Option Data
value 0 - one zero-valued octet
6. IPv6 Tunnel State
The IPv6 tunnel state variables, some of which are or may
configured on the tunnel entry-point node, are
6.1 IPv6 Tunnel Entry-Point Node
The tunnel entry-point node address is one of the valid IPv6
addresses of the entry-point node - the validation of the address
tunnel configuration time is recommended
The tunnel entry-point node address is copied to the source
field in the tunnel IPv6 header during packet encapsulation
6.2 IPv6 Tunnel Exit-Point Node
The tunnel exit-point node address is used as IPv6
address for the tunnel IPv6 header. A tunnel acts like a
point to point link between the entry-point node and exit-point node
The tunnel exit-point node address is copied to the
address field in the tunnel IPv6 header during packet encapsulation
The configuration of the tunnel entry-point and exit-point
is not subject to IPv6 Autoconfiguration or IPv6 Neighbor Discovery
6.3 IPv6 Tunnel Hop
An IPv6 tunnel is modeled as a "single-hop virtual link" tunnel,
which the passing of the original packet through the tunnel is
the passing of the original packet over a one hop link, regardless
the number of hops in the IPv6 tunnel
The "single-hop" mechanism should be implemented by having the
entry point node set a tunnel IPv6 header hop limit independently
the hop limit of the original header
The "single-hop" mechanism hides from the original IPv6 packets
number of IPv6 hops of the tunnel
It is recommended that the tunnel hop limit be configured with
value that ensures
Conta & Deering Standards Track [Page 19]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
(a) that tunnel IPv6 packets can reach the tunnel exit-
(b) a quick expiration of the tunnel packet if a routing
occurs within the IPv6 tunnel
The tunnel hop limit default value for hosts is the IPv6
Discovery advertised hop limit [ND-Spec]. The tunnel hop
default value for routers is the default IPv6 Hop Limit value
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
IPv6 header of each packet encapsulated by the tunnel entry-
node
6.4 IPv6 Tunnel Packet Traffic
The IPv6 Tunnel Packet Traffic Class indicates the value that
tunnel entry-point node sets in the Traffic Class field of a
header. The default value is zero. The configured Packet
Class can also indicate whether the value of the Traffic Class
in the tunnel header is copied from the original header, or it is
to the pre-configured value
6.5 IPv6 Tunnel Flow
The IPv6 Tunnel Flow Label indicates the value that a tunnel entry
point node sets in the flow label of a tunnel header. The
value is zero
6.6 IPv6 Tunnel Encapsulation
The Tunnel Encapsulation Limit value can indicate whether the entry
point node is configured to limit the number of encapsulations
tunnel packets originating on that node. The IPv6
Encapsulation Limit is the maximum number of
encapsulations permitted for packets undergoing encapsulation at
entry-point node. Recommended default value is 4. An entry-point
configured to limit the number of nested encapsulations prepends
Destination Options extension header containing a
Encapsulation Limit option to an original packet
encapsulation - see sections 4.1 and 4.1.1.
6.7 IPv6 Tunnel
The tunnel MTU is set dynamically to the Path MTU between the
entry-point and the tunnel exit-point nodes, minus the size of
tunnel headers: the maximum size of a tunnel packet payload that
Conta & Deering Standards Track [Page 20]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
be sent through the tunnel without fragmentation [IPv6-Spec].
tunnel entry-point node performs Path MTU discovery on the
between the tunnel entry-point and exit-point nodes [PMTU-Spec],
[ICMP-Spec]. The tunnel MTU of a nested tunnel is the tunnel MTU
the outer tunnel minus the size of the nested tunnel headers
7. IPv6 Tunnel Packet Size
Prepending a tunnel header increases the size of a packet,
a tunnel packet resulting from the encapsulation of an IPv6
packet may require fragmentation
A tunnel IPv6 packet resulting from the encapsulation of an
packet is considered an IPv6 packet originating from the
entry-point node. Therefore, like any source of an IPv6 packet,
tunnel entry-point node must support fragmentation of tunnel IPv
packets
A tunnel intermediate node that forwards a tunnel packet to
node in the tunnel follows the general IPv6 rule that it must
fragment a packet undergoing forwarding
A tunnel exit-point node receiving tunnel packets at the end of
tunnel for decapsulation applies the strict left-to-right
rules for extension headers. In the case of a fragmented
packet, the fragments are reassembled into a complete tunnel
before determining that an embedded packet is present
Note
A particular problem arises when the destination of a
tunnel packet is an exit-point node identified by an anycast address
The problem, which is similar to that of original fragmented IPv
packets destined to nodes identified by an anycast address, is
all the fragments of a packet must arrive at the same
node for that node to be able to perform a successful reassembly,
requirement that is not necessarily satisfied by packets sent to
anycast address
7.1 IPv6 Tunnel Packet
When an IPv6 original packet enters a tunnel, if the original
size exceeds the tunnel MTU (i.e., the Path MTU between the
entry-point and the tunnel exit-point, minus the size of the
header(s)), it is handled as follows
Conta & Deering Standards Track [Page 21]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
(a) if the original IPv6 packet size is larger than the IPv
minimum link MTU [IPv6-Spec], the entry-point node
the packet and sends an ICMPv6 "Packet Too Big" message
the source address of the original packet with
recommended MTU size field set to the tunnel MTU or
IPv6 minimum link MTU, whichever is larger, i.e.
(tunnel MTU, IPv6 minimum link MTU). Also see sections 6.7
and 8.2.
(b) if the original IPv6 packet is equal or smaller than
IPv6 minimum link MTU, the tunnel entry-point
encapsulates the original packet, and
fragments the resulting IPv6 tunnel packet into IPv
fragments that do not exceed the Path MTU to the
exit-point
7.2 IPv4 Tunnel Packet
When an IPv4 original packet enters a tunnel, if the original
size exceeds the tunnel MTU (i.e., the Path MTU between the
entry-point and the tunnel exit-point, minus the size of the
header(s)), it is handled as follows
(a) if in the original IPv4 packet header the Don't Fragment -
DF - bit flag is SET, the entry-point node discards
packet and returns an ICMP message. The ICMP message
the type = "unreachable", the code = "packet too big",
the recommended MTU size field set to the size of
tunnel MTU - see sections 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
the original packet, and subsequently fragments
resulting IPv6 tunnel packet into IPv6 fragments that
not exceed the Path MTU to the tunnel exit-point
8. IPv6 Tunnel Error Processing and
IPv6 Tunneling follows the general rule that an error detected
the processing of an IPv6 packet is reported through an ICMP
to the source of the packet
On a forwarding path that includes IPv6 tunnels, an error detected
a node that is not in any tunnel is directly reported to the
of the original IPv6 packet
Conta & Deering Standards Track [Page 22]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
An error detected by a node inside a tunnel is reported to the
of the tunnel packet, that is, the tunnel entry-point node. The
message sent to the tunnel entry-point node has as ICMP payload
tunnel IPv6 packet that has the original packet as its payload
The cause of a packet error encountered inside a tunnel can be
problem with
(a) the tunnel header,
(b) the tunnel packet
Both tunnel header and tunnel packet problems are reported to
tunnel entry-point node
If a tunnel packet problem is a consequence of a problem with
original packet, which is the payload of the tunnel packet, then
problem is also reported to the source of the original packet
To report a problem detected inside the tunnel to the source of
original packet, the tunnel entry point node must relay the
message received from inside the tunnel to the source of
original IPv6 packet
An example of the processing that can take place in the
reporting mechanism of a node is illustrated in Fig.7, and Fig.8:
Fig.7 path #0 and Fig.8 (a) - The IPv6 tunnel entry-point receives
ICMP packet from inside the tunnel, marked Tunnel ICMPv6 Message
Fig.7. The tunnel entry-point node IPv6 layer passes the
ICMP message to the ICMPv6 Input. The ICMPv6 Input, based on the
type and code [ICMP-Spec] generates an internal "error code".
Fig.7 path #1 - The internal error code, is passed with the "ICMPv
message payload" to the upper-layer protocol - in this case the IPv
tunnel upper-layer error input
Conta & Deering Standards Track [Page 23]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
+-------+ +-------+ +-----------------------+
| Upper | | Upper | | Upper |
| Layer | | Layer | | Layer |
| Proto.| | Proto | | IPv6 Tunnel |
| Error | | Error | | Error |
| Input | | Input | | Input |
| | | | | Decapsulate |
| | | | | -->--ICMPv6--#2->-- |
| | | | | | Payload | |
+-------+ +-------+ +--|-----------------|--+
| | | |
^ ^ ^
| | | |
--------------------#1-- -----Orig.Packet?--- - - - - - - -
#1 #3 Int.Error Code, #5 |
Int.Error Code,^ v Source Address, v
ICMPv6 Payload | IPv6 | Orig. Packet | IPv4 |
+--------------+ +------------+ +------------+ + - - +
| | | | | |
| ICMP v6 | | ICMP v6 | | ICMP v4 | | |
| Input | | Err Report | | Err Report |
| - - - - +----+ - - - -| + - - - -+ + - - +
| | | |
| IPv6 Layer | | IPv4 Layer | | |
| | | |
+--------------------------------+ +------------+ + - - +
| | |
^ V
#0 #4 #6
| | |
Tunnel ICMPv6 ICMPv6 ICMPv
Message Message
| | |
Fig.7 Error Reporting Flow in a Node (IPv6 Tunneling Protocol Engine
Fig.7 path #2 and Fig.8 (b) - The IPv6 tunnel error
decapsulates the tunnel IPv6 packet, which is the ICMPv6
payload, obtaining the original packet, and thus the original
and dispatches the "internal error code", the source address from
original packet header, and the original packet, down to the
report block of the protocol identified by the Next Header field
the tunnel header immediately preceding the original packet in
ICMP message payload
From here the processing depends on the protocol of the
packet
Conta & Deering Standards Track [Page 24]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
(a) - for an IPv6 original
Fig.7 path #3 and Fig.8 (c.1)- for an IPv6 original packet,
ICMPv6 error report builds an ICMP message of a type and
according to the "internal error code", containing the "
packet" as ICMP payload
Fig.7 path #4 and Fig.8 (d.1)- The ICMP message has the
entry-point node address as source address, and the original
source node address as destination address. The tunnel entry-
node sends the ICMP message to the source node of the
packet
(b) - for an IPv4 original
Fig.7 path #5 and Fig.8 (c.2) - for an IPv4 original packet,
ICMPv4 error report builds an ICMP message of a type and
derived from the the "internal error code", containing
"original packet" as ICMP payload
Fig.7 path #6 and Fig.8 (d.2) - The ICMP message has the
entry-point node IPv4 address as source address, and the
packet IPv4 source node address as destination address. The
entry-point node sends the ICMP message to the source node of
original packet
A graphical description of the header processing taking place is
following
Conta & Deering Standards Track [Page 25]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
< Tunnel Packet >
+--------+- - - - - -+--------+------------------------------//------+
| IPv6 | IPv6 | ICMP | Tunnel |
(a)| | Extension | | IPv6 |
| Header | Headers | Header | Packet in error |
+--------+- - - - - -+--------+------------------------------//------+
< Tunnel Headers > < Tunnel ICMP Message >
< ICMPv6 Message Payload >
|
< Tunnel ICMP Message >
< Tunnel IPv6 Packet in Error >
+--------+ +---------+ +----------+--------//------+
| ICMP | | Tunnel | | Original | Original |
(b) | | + | IPv6 | + | | Packet |
| Header | | Headers | | Headers | Payload |
+--------+ +---------+ +----------+--------//------+
| <Original Packet in Error >
----------------- |
| |
--------------|---------------
| |
V
+---------+ +--------+ +-------------------//------+
| New | | ICMP | | |
(c.1) | IPv6 | + | | + | Orig. Packet in Error |
| Headers | | Header | | |
+---------+ +--------+ +-------------------//------+
|
+---------+--------+-------------------//------+
| New | ICMP | Original |
(d.1) | IPv6 | | |
| Headers | Header | Packet in Error |
+---------+--------+-------------------//------+
< New ICMP Message >
Conta & Deering Standards Track [Page 26]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
or for an IPv4 original
+---------+ +--------+ +-------------------//------+
| New | | ICMP | | |
(c.2) | IPv4 | + | | + | Orig. Packet in Error |
| Header | | Header | | |
+---------+ +--------+ +-------------------//------+
|
+---------+--------+-------------------//------+
| New | ICMP | Original |
(d.2) | IPv4 | | |
| Header | Header | Packet in Error |
+---------+--------+-------------------//------+
< New ICMP Message >
Fig.8 ICMP Error Reporting and
8.1 Tunnel ICMP
The tunnel ICMP messages that are reported to the source of
original packet are
hop limit
The tunnel has a misconfigured hop limit, or contains
routing loop, and packets do not reach the tunnel exit
point node. This problem is reported to the tunnel entry
point node, where the tunnel hop limit can be
to a higher value. The problem is further reported to
source of the original packet as described in section 8.2,
or 8.3.
unreachable
One of the nodes in the tunnel is not or is no
reachable. This problem is reported to the tunnel entry
point node, which should be reconfigured with a valid
active path between the entry and exit-point of the tunnel
The problem is further reported to the source of
original packet as described in section 8.2, or 8.3.
parameter
A Parameter Problem ICMP message pointing to a valid
Encapsulation Limit Destination header with a Tun Encap
field value set to one is an indication that the
Conta & Deering Standards Track [Page 27]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
packet exceeded the maximum number of
allowed. The problem is further reported to the source
the original packet as described in section 8.2, or 8.3.
The above three problems detected inside the tunnel, which are
tunnel configuration and a tunnel topology problem, are reported
the source of the original IPv6 packet, as a tunnel
"unreachable" problem caused by a "link problem" - see section 8.2
and 8.3.
packet too
The tunnel packet exceeds the tunnel Path MTU
The information carried by this type of ICMP message
used as follows
- by a receiving tunnel entry-point node to set or
the tunnel
- by a sending tunnel entry-point node to indicate to
source of an original packet the MTU size that should
used in sending IPv6 packets towards the tunnel entry-
node
8.2 ICMP Messages for IPv6 Original
The tunnel entry-point node builds the ICMP and IPv6 headers of
ICMP message that is sent to the source of the original packet
follows
IPv6 Fields
Source
A valid unicast IPv6 address of the
interface
Destination
Copied from the Source Address field of the
IPv6 header
ICMP Fields
For any of the following tunnel ICMP error messages
"hop limit exceeded
Conta & Deering Standards Track [Page 28]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
"unreachable node
"parameter problem" - pointing to a valid Tunnel
Limit destination header with the Tun Encap Lim field set to
value zero
Type 1 - unreachable
Code 3 - address
For tunnel ICMP error message "packet too big":
Type 2 - packet too
Code 0
MTU The MTU field from the tunnel ICMP message
the length of the tunnel headers
According to the general rules described in 7.1, an ICMP "packet
big" message is sent to the source of the original packet only if
original packet size is larger than the minimum link MTU
required for IPv6 [IPv6-Spec].
8.3 ICMP Messages for IPv4 Original
The tunnel entry-point node builds the ICMP and IPv4 header of
ICMP message that is sent to the source of the original packet
follows
IPv4 Fields
Source
A valid unicast IPv4 address of the
interface
Destination
Copied from the Source Address field of the
IPv4 header
ICMP Fields
For any of the following tunnel ICMP error messages
"hop limit exceeded
Conta & Deering Standards Track [Page 29]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
"unreachable node
"parameter problem" - pointing to a valid Tunnel
Limit destination header with the Tun Encap Lim field set to
value zero
Type 3 - destination
Code 1 - host
For a tunnel ICMP error message "packet too big":
Type 3 - destination
Code 4 - packet too
MTU The MTU field from the tunnel ICMP message
the length of the tunnel headers
According to the general rules described in section 7.2, an
"packet too big" message is sent to the original IPv4 packet
node if the the original IPv4 header has the DF - don't fragment -
bit flag SET
8.4 ICMP Messages for Nested Tunnel
In case of an error uncovered with a nested tunnel packet, the
tunnel entry-point, which receives the ICMP error message from
inner tunnel reporting node, relays the ICMP message to the
tunnel entry-point following the mechanisms described in
8.,8.1, 8.2, and 8.3. Further, the outer tunnel entry-point
the ICMP message to the source of the original packet, following
same mechanisms
9. Security
An IPv6 tunnel can be secured by securing the IPv6 path between
tunnel entry-point and exit-point node. The security architecture
mechanisms, and services are described in [RFC2401], [RFC2402],
[RFC2406]. A secure IPv6 tunnel may act as a gateway-to-
secure path as described in [RFC2401].
For a secure IPv6 tunnel, in addition to the mechanisms
earlier in this document, the entry-point node of the tunnel
security algorithms on the packet and prepends as part of the
headers one or more security headers in conformance with [IPv6-Spec],
[RFC2401], and [RFC2402], or [RFC2406].
Conta & Deering Standards Track [Page 30]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
The exit-point node of a secure IPv6 tunnel performs
algorithms and processes the tunnel security header[s] as part of
tunnel headers processing described earlier, and in conformance
[RFC2401], and [RFC2402], or [RFC2406]. The exit-point node
the tunnel security header[s] with the rest of the tunnel
after tunnel headers processing completion
The degree of integrity, authentication, and confidentiality and
security processing performed on a tunnel packet at the entry-
and exit-point node of a secure IPv6 tunnel depend on the type
security header - authentication (AH) or encryption (ESP) -
parameters configured in the Security Association for the tunnel
There is no dependency or interaction between the security level
mechanisms applied to the tunnel packets and the security applied
the original packets which are the payloads of the tunnel packets
In case of nested tunnels, each inner tunnel may have its own set
security services, independently from those of the outer tunnels,
of those between the source and destination of the original packet
10.
This document is partially derived from several discussions
IPv6 tunneling on the IPng Working Group Mailing List and
feedback from the IPng Working Group to an IPv6 presentation
focused on IPv6 tunneling at the 33rd IETF, in Stockholm, in
1995.
Additionally, the following documents that focused on tunneling
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,
Nordmark (in alphabetical order) gave valuable reviewing comments
suggestions for the improvement of this document. Scott Bradner,
Callon, Dimitry Haskin, Paul Traina, and James Watt (in
order) shared their view or experience on matters of concern in
document. Judith Grossman provided a sample of her many years
editorial and writing experience as well as a good amount of
technical questions
11.
[IPv6-Spec] Deering, S. and R. Hinden, "Internet
Version 6 (IPv6) Specification", RFC 2460, December 1998.
Conta & Deering Standards Track [Page 31]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
[ICMP-Spec] Conta, A. and S. Deering "Internet Control
Protocol for the Internet Protocol Version 6 (IPv6)",
2463, December 1998.
[ND-Spec] Narten, T., Nordmark, E., and W. Simpson "
Discovery for IP Version 6 (IPv6)", RFC 2461,
1998.
[PMTU-Spec] McCann, J., Deering, S. and J. Mogul, "Path MTU
for IP Version 6 (IPv6)", RFC 1981, August 1996.
[RFC2401] Atkinson, R., "Security Architecture for the
Protocol", RFC 2401, November 1998.
[RFC2402] Atkinson, R., "IP Authentication Header", RFC 2402,
November 1998.
[RFC2406] Atkinson, R., "IP Encapsulation Security Payload (ESP)",
RFC 2406, November 1998.
[RFC-1853] Simpson, W., "IP in IP Tunneling", RFC 1853,
1995.
[Assign-Nr] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994. See also
http://www.iana.org/numbers.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors'
Alex
Lucent Technologies Inc
300 Baker
Concord, MA 01742-2168
+1-978-287-2842
EMail: aconta@lucent.
Stephen
Cisco
170 West Tasman
San Jose, CA 95132-1706
Phone: +1-408-527-8213
EMail: deering@cisco.
Conta & Deering Standards Track [Page 32]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
Appendix
A.1 Risk Factors in Nested
Nested encapsulations of a packet become a recursive encapsulation
the packet reenters an outer tunnel before exiting it. The
which present a high risk of recursive encapsulation are those
which a tunnel entry-point node cannot determine whether a
that undergoes encapsulation reenters the tunnel before exiting it
Routing loops that cause tunnel packets to reenter a tunnel
exiting it are certainly the major cause of the problem. But
routing loops exist, and happen, it is important to understand
describe, the cases in which the risk for recursive encapsulation
higher
There are two significant elements that determine the risk factor
routing loop recursive encapsulation
(a) the type of tunnel
(b) the type of route to the tunnel exit-point,
determines the packet forwarding through the tunnel,
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
recursive encapsulation in routing loops are
"inner tunnels with identical exit-points".
Since the source and destination of an original packet is the
information used to decide whether to forward a packet through
tunnel or not, a recursive encapsulation can be avoided in case of
single tunnel (non-inner), by checking that the packet to
encapsulated is not originated on the entry-point node.
mechanism is suggested in [RFC-1853].
However, this type of protection does not seem to work well in
of inner tunnels with different entry-points, and identical exit
points
Inner tunnels with different entry-points and identical exit-
introduce ambiguity in deciding whether to encapsulate a packet,
a packet encapsulated in an inner tunnel reaches the entry-point
of an outer tunnel by means of a routing loop. Because the source
the tunnel packet is the inner tunnel entry-point node which
different than the entry-point node of the outer tunnel, the
Conta & Deering Standards Track [Page 33]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
address checking (mentioned above) fails to detect an
encapsulation, and as a consequence the tunnel packet
encapsulated at the outer tunnel each time it reaches it through
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
identified as a high risk factor of recursive encapsulation
routing loops
One type of route to a tunnel exit-point node is a route to
specified destination node, that is, the destination is a
specified IPv6 address (route to node). Such a route can be
based on the longest match of an original packet destination
with the destination address stored in the tunnel entry-point
routing table entry for that route. The packet forwarded on such
route is first encapsulated and then forwarded towards the
exit-point node
Another type of route to a tunnel exit-point node is a route to
specified prefix-net, that is, the destination is a valid
IPv6 prefix (route to net). Such a route can be selected based on
longest path match of an original packet destination address with
prefix destination stored in the tunnel entry-point node
table entry for that route. The packet forwarded on such a route
first encapsulated and then forwarded towards the tunnel exit-
node
And finally another type of route to a tunnel exit-point is a
route, or a route to an unspecified destination. This route
selected when no-other match for the destination of the
packet has been found in the routing table. A tunnel that is
first hop of a default route is a "default tunnel".
If the route to a tunnel exit-point is a route to node, the
factor for recursive encapsulation is minimum
If the route to a tunnel exit-point is a route to net, the
factor for recursive encapsulation is medium. There is a range
destination addresses that will match the prefix the route
associated with. If one or more inner tunnels with different
entry-points have exit-point node addresses that match the route
net of an outer tunnel exit-point, then a recursive encapsulation
occur if a tunnel packet gets diverted from inside such an
tunnel to the entry-point of the outer tunnel that has a route to
exit-point that matches the exit-point of an inner tunnel
Conta & Deering Standards Track [Page 34]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
If the route to a tunnel exit-point is a default route, the
factor for recursive encapsulation is maximum. Packets are
through a default tunnel for lack of a better route. In
situations, forwarding through a default tunnel can happen for a
range of destination addresses which at the maximum extent is
entire Internet minus the node's link. As consequence, it is
that in a routing loop case, if a tunnel packet gets diverted from
inner tunnel to an outer tunnel entry-point in which the tunnel is
default tunnel, the packet will be once more encapsulated,
the default routing mechanism will not be able to
differently, based on the destination
Conta & Deering Standards Track [Page 35]
RFC 2473 Generic Packet Tunneling in IPv6 December 1998
Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright no