WDIFF

draft-ietf-ipngwg-ipv6-tunnel-01.txt --> draft-ietf-ipngwg-ipv6-tunnel-02.txt

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

Generic Packet Tunneling in IPv6

Specification

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

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

Status of this Memo

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

Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).

Distribution of this memo is unlimited.

Abstract

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

Conta & Deering Expires in six months [Page 1]

INTERNET-DRAFT Tunneling in IPv6 February 22, June 13, 1996

Table of Contents

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

Fig. 1.................................................8
Fig. 2.................................................8 version........................36

Fig.1.................................................6
Fig.2.................................................7
Fig.3.................................................8
Fig.4.................................................9
Fig.5................................................10

Conta & Deering Expires in six months [Page 2]

INTERNET-DRAFT Tunneling in IPv6 February 22, June 13, 1996

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

Fig.6................................................13
Fig.7................................................24
Fig.8................................................26/27

Conta & Deering Expires in six months [Page 3]

INTERNET-DRAFT Tunneling in IPv6 February 22, June 13, 1996

1. Introduction

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

A typical scenario for use in various
cases of communications.

Such a case is when a node, that IPv6 tunneling is not the source case in which an
intermediate node of a packet,
wishes to exert exerts explicit routing control over the packet - such as
causing the packet to be forwarded to a by specifying
particular destination on the
way to the final destination identified in the original header. The forwarding paths for selected packets. This control is exerted
achieved by prepending to each of the packet a new IPv6 header,
with a new source and destination address (see section 3.1).

The tunnel selected original packets IPv6 packet is forwarded
headers that identify the forwarding path.

In addition to the tunnel description of generic IPv6 header
destination tunneling mechanisms,
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 focus 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 document, specific IPv6 tunneling mechanisms for
tunneling IPv6 packets and respectively IPv4 packets. packets are also described herein.

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

a packet that undergoes encapsulation in
a tunnel packet. encapsulation.

original header

the header of an original packet.

tunnel

a virtual link forwarding path between two nodes, nodes on which an Internet or lower
layer protocol packet travels after the entry point packets payloads
are original packets.

tunnel end-node

a node
encapsulates that packet in where a tunnel protocol packet. begins or ends.

tunnel header

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

tunnel packet

a packet that encapsulates an original packet.

Conta & Deering Expires in six months [Page 5] 4]

INTERNET-DRAFT Tunneling in IPv6 February 22, June 13, 1996

tunnel packet

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

tunnel entry point 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. encapsulated.

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 decapsulated.

IPv6 tunnel

a tunnel that has an unspecified exit-point address (unspecified configured as a virtual link between two IPv6 address). nodes, on
which the encapsulating protocol is IPv6.

free-exit tunnel

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

fixed-exit tunnel

a tunnel that has for which a specified specific exit-point address (not the
unspecified IPv6 address). was configured.

tunnel MTU

the Path MTU in the tunnel, i.e. between the tunnel entry point
node entry-point and the tunnel
exit-point node. nodes; it includes the tunnel headers.

tunnel hop limit

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

inner tunnel

a tunnel which serves as one (virtual) that is a hop in (virtual link) of another tunnel.

outer tunnel

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

recursive tunnel IPv6 packet

a tunnel packet that has as payload a tunnel packet.

recursive tunnel header

the tunnel header of a recursive tunnel packet.

recursive encapsulation

Conta & Deering Expires in six months [Page 6] 5]

INTERNET-DRAFT Tunneling in IPv6 February 22, June 13, 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 tunneling is a technique which consists in for establishing a "virtual link"
between two IPv6 nodes and using that "link" for transmitting data packets. The two packets as payloads of
IPv6 nodes packets (see Fig.1). From the point of view of the IPv6 two nodes,
this "virtual link", also called an "IPv6 tunnel", IPv6 tunnel, appears as a "link", 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 link-layer protocol packet. The two IPv6 nodes which are at play specific
roles. One node encapsulates original packets received from other
nodes or from itself and forwards the two ends of resulting tunnel packets
through the IPv6 tunnel, tunnel. The other node decapsulates the
IPv6 received tunnel entry point node
packets and forwards the IPv6 tunnel exit point node play
specific roles:

A tunnel entry point node can be seen as an resulting original packet source -
the source of the IPv6 tunnel packet packets towards their
destination, possibly itself. The encapsulator node is called the
tunnel entry point node.
An IPv6 tunnel main header entry-point node, 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 it 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 source of the IPv6 tunnel packet is the tunnel
exit-point node. packets.
The tunnel exit point decapsulator node processes is called 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 exit-point, and it similarly to processing is the IPv6 headers
destination of an
original packet destined to it. the tunnel packets.

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

Fig. 1.

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

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

Conta & Deering Expires in six months [Page 6]

INTERNET-DRAFT Tunneling in IPv6 June 13, 1996

exit-point node of the other tunnel (see Fig. 1). Fig.2).

Tunnel from node Node B to node Node C
<--------------------------------------->
<------------------------>
Tunnel Tunnel
Original Entry Point 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 Entry-Point Node
Node Node
<------------------------------------->
<------------------------->
Tunnel from node Node C to node Node B

Fig. 2. Bidirectional tunneling mechanism effect

Conta & Deering Expires in six months [Page 8]

INTERNET-DRAFT

Fig.2 Bi-directional 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 Mechanism

3.1 IPv6 Encapsulation

The

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

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

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

At encapsulation, the source field of the tunnel IPv6 header is
filled with the IPv6 address of the tunnel entry-point node, and the

Conta & Deering Expires in six months [Page 7]

INTERNET-DRAFT Tunneling in IPv6 June 13, 1996

destination field with the IPv6 address of the tunnel exit-point.
Subsequently, the tunnel packet resulted resulting from encapsulation is sent
towards the tunnel exit-point node. The tunnel

Tunnel extension headers are used to control should appear in the packet's processing (forwarding)
through order recommended by
the tunnel. specifications that define the extension headers, such as [RFC-
1883].

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

Fig. 3.

Fig.3 Encapsulating a packet

If the transmitting of Packet

3.2 Packet Processing in Tunnels

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

3.3 IPv6 Decapsulation

Decapsulation is an: graphically shown in Fig.4:

Conta & Deering Expires in six months [Page 9] 8]

INTERNET-DRAFT Tunneling in IPv6 February 22, June 13, 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:

Fig. 4.

Fig.4 Decapsulating a packet from the tunnel IPv6 headers

The IPv6 protocol layer of a tunnel exit-point node Packet

Upon receiving an IPv6 packet destined to one an IPv6 address of the node's a tunnel
entry-point node, its IPv6 addresses protocol layer processes the
packet according tunnel
headers. When processing is complete, control is handed to the IPv6 protocol. A next
protocol engine, which is identified by the 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 processed. If this is set to a tunnel packet. Upon the completion of protocol
value, the IPv6 tunnel protocol layer
processing of a tunnel packet, control is given to the Tunnel
Protocol layer. The Tunnel Protocol layer discards the engine discards the tunnel headers and
passes the resulting original packet to the Internet or lower layer
protocol identified by that value for further processing - for processing. For
example, in the case the Next Header value 41, field has the IPv6 Tunnel
Protocol value, the resulting original packet is passed to the IPv6
protocol layer.

Conta & Deering Expires in six months [Page 10]

INTERNET-DRAFT Tunneling in IPv6 February 22, 1996

3.3

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

3.4 IPv6 Tunnel Protocol Engine

The packet

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

Conta & Deering Expires in six months [Page 9]

INTERNET-DRAFT Tunneling in IPv6 June 13, 1996

+-----------------------+ +-----------------------------------+
| Upper Layer Upper-Layer Protocols | | IPv6 Tunnel Upper-Layer |
| | | |
| | | ---<-------------------<------- |
| | | | ---->---|------>--------- | |
| | | | | | | | | |
+-----------------------+ +-----------------------+ | | |
| | | | | | | | | v ^ |
v ^ v ^ v ^ v ^ Tunnel | | | |
| | | | | | | | packets| 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 Packets | v ^ |
+-----------------------+ +-----------------------+ | | |
| | | | | | | | | | | |
| | | | ---|----|-------<-------- | |
| | | --->--------------->------>---- |
| | | |
| Link Layer Link-Layer Protocols | | IPv6 Tunnel Link Layer Link-Layer |
+-----------------------+ +-----------------------------------+

Fig. 5.

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

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

(a) The "tunnel upper-layer" has "link-layer", each with a specific input and output as "input" follows:

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

(u.i.1) a link-layer - (path #1 in
Fig. 5) - or from a tunneling link-layer (the exit-point node
of an inner #1, Fig.5)

These are tunnel coincides with the exit-point packets destined to this node of an and will
undergo decapsulation.

Conta & Deering Expires in six months [Page 11] 10]

INTERNET-DRAFT Tunneling in IPv6 February 22, June 13, 1996

outer tunnel)

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

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

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

(b) The (see b.2).

(u.o) "tunnel upper-layer" has as "output" upper-layer output" - consists of tunnel IPv6 packets
resulting from encapsulation of original packets - see (c)
that are passed through the IPv6 layer down to:

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

These packets resulted from previous encapsulations - when this node
is an entry point to an outer tunnel underwent encapsulation and to an inner tunnel.
The "output" tunnel packets are passed through sent
towards the IPv6 layer
down to tunnel exit-point

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

These tunnel link-layer for another encapsulation (the entry
point packets are going to be recursively
encapsulated. This node in an inner tunnel coincides with is the entry point entry-point node in of both
an outer tunnel) - (path #8 in Fig. 5). tunnel and one or more of its inner tunnel.

Implementation Note:

the "tunnel upper-layer"

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

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

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

The original packets are incoming through the IPv6 layer from from:

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

These are original packets originated originating on this node) - (path #4 node
that undergo encapsulation. The original packet source
and tunnel entry-point are the same node.

Conta & Deering Expires in six months [Page 11]

INTERNET-DRAFT Tunneling in Fig. 5) IPv6 June 13, 1996

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

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

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

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

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

(l.o) "tunnel link-layer for
transmission output" - see (b).

(d) The "tunnel link-layer" has as "output" consists of original IPv6 packets
resulting from decapsulation - see (a) - which decapsulation. These packets are passed through
the IPv6 layer up to to:

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

These original
packet is packets are destined to this node) - (path #3 in Fig. 5) - or
down to node.

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

These original packet is packets are destined to another node, so it is forwarded) - (path #5 in Fig. 5).

Implementation Note:

the "IPv6 tunnel link layer" node;
they are transmitted on a link towards their
destination.

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

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

Implementation Note:

The tunnel link-layer input and output may can be implemented similar
to other link layer protocols the input and
output, output of other link-layer protocols, for instance by
instance, associating an interface or pseudo-
interface 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, June 13, 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 is the encapsulation of a tunnel packet.
It takes place when portions a hop of an IPv6 tunnel are IPv6 tunnels themselves, i.e. is a tunnel. The tunnel contains
containing a tunnel is called an outer tunnel. The tunnel contained
in the outer tunnel is called an inner
tunnels tunnel - see Fig. 6. Fig.6.

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

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

Fig. 6.

Fig.6. Recursive Encapsulation

The entry point 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 receives tunnel IPv6
packets encapsulated at an by the "outer IPv6 tunnel" entry point entry-point node. These The
"inner tunnel entry-point node" treats the receiving tunnel packets are
as original packets and performs encapsulation. The resulting
packets are "tunnel packets" for the "inner IPv6 tunnel" entry point node, the result of
their encapsulation at tunnel", and
"recursive tunnel packets" for 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 "outer IPv6 tunnel".

4.1 Limiting Recursive Encapsulation

There is a practical limit on how many "inner IPv6 tunnels" an "outer

A tunnel IPv6 tunnel" may have which results from packet size is limited to the maximum number of
possible IPv6 encapsulations of a packet. datagram
size [RFC 1883]. Each encapsulation adds to the size of a tunnel
packet the size of the tunnel IPv6 headers. Consequently, in the case number
of inner tunnels, recursive tunnel headers, and therefore, the number of recursive encapsulations is practically limited by
encapsulations, and furthermore, the number of tunnel "inner IPv6 headers tunnels"
that an "outer IPv6 tunnel" can be prepended to the original
packet before the resulting tunnel packet hits have are limited by the maximum IPv6
datagram size [RFC-1883].
packet size.

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

Conta & Deering Expires in six months [Page 13]

INTERNET-DRAFT Tunneling in IPv6 June 13, 1996

section 7.

Each next Furthermore, each fragmentation, due to recursive encapsulation
encapsulation, of a an already fragmented tunnel IPv6 fragment may
result packet results in a new fragmentation and thus the addition
doubling of one more
fragment to the previous existing number of fragments. Therefore, Moreover, it is highly probable that
once the this fragmentation of a tunnel IPv6 packet was
triggered, begins, each next new recursive encapsulation may result
results in yet additional
fragmentation, and thus IPv6 fragment multiplication. Therefore, it
is recommended to keep fragmentation. Therefore limiting
recursive encapsulation to a minimum. is recommended.

The proposed mechanism for controlling limiting excessive recursive encapsulation
is a "tunnel encapsulation limit" that limit", which 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 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 entry-point nodes.

The "Tunnel Encapsulation Limit" destination option header 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 Opt Data Len
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| 1 | u_8int Tun Encap Lim |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option Type decimal value 4

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

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

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

Tun Encap Lim

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

To avoid excessive recursive encapsulation, an IPv6 tunnel entry entry-

Conta & Deering Expires in six months [Page 14]

INTERNET-DRAFT Tunneling in IPv6 June 13, 1996

point node may prepend, as part of the IPv6 tunnel headers, prepend to a packet undergoing encapsulation a "Tunnel
Encapsulation Limit - Destination Extension Header" - Options" tunnel header with the "Tun
Encap Lim - tunnel encapsulation limit" -
"Opt Data Value" 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 previous "Tunnel Encapsulation Limit" header, the header. The
value from the previous header is copied into the newly
prepended "Tunnel Encapsulation Limit" header and then
decremented by one.

This is an exception from to the rule of processing destination
extension headers, headers in that that, although the entry
point entry-point node is
not a destination node, during the
encapsulation of a packet, the IPv6 tunneling protocol engine
looks ahead during the encapsulation of a packet 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 When the packet,
packet is discarded, a Parameter Problem ICMP message
[RFC-1885] is returned to the packet originator - originator, which is
the
Parameter Problem ICMP previous tunnel entry-point. The message points into to the
Opt Data Value field within the Tunnel Encapsulation Limit
destination header of the packet, packet. The field pointed 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
a value of 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 entry-point node
encapsulates tunnel IPv6 packets originated from itself, and destined
to itself. This may can generate an infinite processing loop in the
entry point
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 a case, it is recommended that an implementation have a
mechanism that checks and rejects the pair configuration of a tunnel entry point in

Conta & Deering Expires in six months [Page 15]

INTERNET-DRAFT Tunneling in IPv6 June 13, 1996

which both the entry-point and exit-point node addresses belong to
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 node. It is also recommended that the validation be
done at tunnel configuration time: encapsulating engine
checks for and rejects the encapsulation of a node should not permit
configuring tunnels packet that has the
pair of tunnel entry point entry-point and exit-
point 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. addresses.

4.1.3 Routing Loop Recursive Encapsulation

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

Because there is no relationship between may recursively
encapsulate packets excessively, with the negative effects described
in 4.1. Because each encapsulation adds a tunnel IPv6 header with a new
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 value, the tunnel IPv6 headers adds to hop limit mechanism cannot control the size
number of times the packets, a tunnel packet may grow to reaches the maximum packet size limit [RFC-1883],
resulting in outer tunnel packet fragmentation, entry-point node,
and fragment
multiplication. thus cannot control the number of recursive encapsulations.

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

(a) the original IPv6 packet hop limit, limit.

It is decremented at each forwarding operation performed on
an original packet. This includes each encapsulation of the
original packet, including at packet. It does not include recursive
encapsulations of the points where it is encapsulated and decapsulated. original packet

(b) the tunnel IPv6 packet encapsulation limit, limit.

It is decremented at each recursive encapsulation of the
packet.

4.1.4 Risk Factors in Recursive Encapsulation

The cases which present

For a high risk discussion of the excessive recursive encapsulation are those risk factors in which a
recursive encapsulation see Appendix A.

5. Tunnel IPv6 Header

The tunnel entry point entry-point node cannot
discern between fills out a valid and an invalid recursive encapsulation.
Routing loops that cause tunnel packets reach nodes that were already
reached before are certainly IPv6 main header
[RFC-1883] as follows:

Conta & Deering Expires in six months [Page 16]

INTERNET-DRAFT Tunneling in IPv6 June 13, 1996

Version:

value 6

Priority:

Depending on the major cause of entry-point node tunnel configuration, the problem. But
since routing loops exist, and happen, it is important
priority can be set to understand
and describe, that of either the cases in which original packet or
a pre-configured value - see section 6.3.

Flow label:

Depending on the risk for excessive recursive
encapsulation entry-point node tunnel configuration, the
flow label can be set to a pre-configured value. The typical
value is higher.

There are two significant elements that determine zero - see section 6.4.

Payload Length:

The original packet length.

If the risk factor of
routing loop excessive recursive encapsulation:

(a) packet is prepended with tunnel IPv6 extension
headers, this value is set to the type of tunnel,

(b) original packet length
plus the type length of route the encapsulating IPv6 extension headers.

Next header:

The next header value according to [RFC-1883] from the tunnel exit-point, which
determines
Assigned Numbers RFC [RFC-1700 or its succesors ].

For example, if the original packet forwarding through the tunnel, i.e.
over is an IPv6 packet, this
is set to:

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

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

The IPv6 header.

- decimal value 60 (Assigned payload type of tunnels which were identified as number for
IPv6 Destination Options header) - if a high risk factor of
excessive recursive encapsulation in routing loops are:

"inner tunnels with identical exit-points".

These tunnels can be: Tunnel
Encapsulation Limit destination option header
immediately follows the tunnel IPv6 header.

Conta & Deering Expires in six months [Page 17]

INTERNET-DRAFT Tunneling in IPv6 February 22, June 13, 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

Hop limit:

The tunnel IPv6 header hop limit is the main
information used to decide whether set to forward a packet through a
tunnel or not, an excessive recursive encapsulation can be avoided in
case pre-configured
value - see section 6.3.

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:

An IPv6 address of a single tunnel (non-inner), by checking that the packet to
be encapsulated was not originated by outgoing interface of the entry point tunnel
entry-point node. This
mechanism address 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 configured as tunnel
entry-point node address - 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 section 6.1.

Destination Address:

An IPv6 address of the tunnel reaches exit-point node. If the
entry point node of an outer tunnel by means of
is configured as a routing loop.
Because free-exit tunnel, then the source IPv6 address
of the tunnel packet is destination from the inner original IPv6 header - see
section 6.2.

5.1 Tunnel IPv6 Extension Headers

Depending on IPv6 node configuration parameters, a tunnel entry
point entry-point
node which is different than may append to 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 IPv6 main header one or more IPv6
extension headers, such as a high risk factor hop by hop, routing, or others.

To limit the number of excessive recursive encapsulation
in routing loops.

One type encapsulations 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 packet, if it
was configured to node). Such do so - see section 6.6 - 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 entry-point
appends as the last 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 extension header a route can be selected based on the
longest path match of an original packet Tunnel Encapsulation
Limit destination address option header with the fields set as follows:

Conta & Deering Expires in six months [Page 18]

INTERNET-DRAFT Tunneling in IPv6 February 22, June 13, 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

Next Header:

Identifies 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 original packet header. For
example, if the "unspecified" original packet is an IPv6 address. This route packet, the next
header protocol value is selected when no-
other match set to decimal value 41 (Assigned
payload type number for IPv6).

Hdr Ext Len:

Length of the Tunnel Encapsulation Limit destination of option
header in 8-octet units, not including the original packet has been found first 8 octets.
Set to value 0.

Option Type:

value 4 - see section 4.1.1.

Opt Data Len:

value 1 - see section 4.1.1.

Tun Encap Lim:

8 bit unsigned integer - see section 4.1.1.

Option Type:

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

Opt Data Len:

value 1 - one octet of option data.

Option Data:

value 0 - one zero-valued octet.

6. IPv6 Tunnel State Variables

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

Conta & Deering Expires in six months [Page 19]

INTERNET-DRAFT Tunneling in IPv6 June 13, 1996

configured on the routing table. A tunnel that enrty-point node, are:

6.1 IPv6 Tunnel Entry-Point Node Address

The tunnel entry-point node address is one of the virtual-link valid IPv6 unicast
addresses of a default
route, i.e. the link to a default router, is a "default tunnel".

If entry-point node - the route to a validation of the address at
tunnel exit-point configuration time is a route to node, the risk
factor for excessive recursive encapsulation is minimum.

If the route to a recommended.

The tunnel exit-point entry-point node address is a route copied to net, the risk
factor for excessive recursive encapsulation is medium. There 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 a
range of used as IPv6 destination addresses that will match the prefix
address for the route
is associated with. If one or more inner tunnels with different tunnel entry-points have IPv6 header. The tunnel exit-point node addresses that match
address can be configured with a specific IPv6 address, in which case
the
route to net of an outer tunnel exit-point, then an excessive
recursive encapsulation may occur if is called a fixed-exit tunnel. Such a tunnel packet gets diverted
from inside such an inner tunnel acts like a
virtual point to point link between the entry entry-point node and exit-
point of node. Alternatively, a tunnel exit-point address can be
configured with no specific address, in which case the outer tunnel that has is
called a route free-exit tunnel. Such a tunnel acts like a virtual point to its exit-point that matches
point link between the exit-point
of entry-point node and an inner tunnel.

If exit-point node
identified by the route to a destination address from the original packet
header.

The tunnel exit-point node address is a default route, copied to the destination
address field in the risk
factor for excessive recursive encapsulation is maximum. Packets are
forwarded through a default tunnel for lack IPv6 header during packet encapsulation.

The configuration of a better route. In
many situations, forwarding through a default the tunnel can happen for a
wide range of destination entry-point and exit-point 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 not subject to an outer IPv6 Autoconfiguration, or IPv6 Neighbor Discovery.

6.3 IPv6 Tunnel Hop Limit

An IPv6 tunnel entry point is modeled as a "single-hop virtual link" tunnel, in
which the passing of the original packet through the tunnel is a default tunnel, like
the passing of the original packet will be once more
encapsulated, because over a one hop link, regardless of
the default routing mechanism will not be able
to discern differently, based on number of hops in the destination - see Appendix B.

5. Tunnel IPv6 Header tunnel.

The "single-hop" mechanism should be implemented by having the tunnel
entry point node fills out set a tunnel IPv6 main header
[RFC-1883] as follows:

Version: hop limit independently of
the hop limit of the original header.

The "single-hop" mechanism hides from the original IPv6 packets the

Conta & Deering Expires in six months [Page 19] 20]

INTERNET-DRAFT Tunneling in IPv6 February 22, June 13, 1996

Priority:

Depending on the entry point node tunnel configuration,

number of IPv6 hops of the
priority may be set to tunnel.

It is recommended that of the original packet, or to tunnel hop limit be configured with a
pre-configured
value - see section 6.3.

Flow label:

Depending on that ensures:

(a) tunnel IPv6 packets can reach the entry point node tunnel configuration, exit-point node

(b) quick expiration of the
flow label may be set to tunnel packet if a pre-configured value. routing loop
occurs within the IPv6 tunnel.

The typical tunnel hop limit default value for hosts is zero - see section 6.4.

Payload Length:

The original packet length.

In case the packet is prepended with tunnel IPv6 extension
headers, this Neighbor
Discovery advertised hop limit [IPv6ND]. The tunnel hop limit default
value for routers is set to the original packet length
plus the length of the encapsulating default IPv6 extension headers.

Next header:

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

For example, if the original packet RFC.

The tunnel hop limit is an IPv6 packet, and
there are no intermediate headers, copied into 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 limit field of the tunnel
IPv6 header, then the next header protocol value in
this field is set to 0 (Assigned payload type number for
IPv6 Hop of each packet encapsulated by Hop Options header).

If a Tunnel Encapsulation Limit destination option header is
immediately following the tunnel entry-point
node.

6.4 IPv6 header, then Tunnel Packet Priority

The IPv6 Tunnel Packet Priority indicates the next
header protocol value that a tunnel
entry-point node sets in this the priority field of a tunnel header. The
default value is set to 60 (Assigned
payload type number for IPv6 Destination Options header).

Hop limit: zero. The Packet Priority can also indicate whether
the value of the priority field in the tunnel IPv6 header hop limit is copied from
the original header, or it is set to a the pre-configured
value - see Section 6.3.

Conta & Deering Expires in six months [Page 20]

INTERNET-DRAFT Tunneling in value.

6.5 IPv6 February 22, 1996 Tunnel Flow Label

The default IPv6 Tunnel Flow Label indicates the value for hosts is that a tunnel entry-
point node sets in the neighbor discovery
advertised hop limit [IPv6ND]. flow label of a tunnel header. The default
value for routers is the default zero.

6.6 IPv6 Hop Tunnel Encapsulation Limit

The Tunnel Encapsulation Limit [TBD] value from the Assigned
Numbers RFC.

Source Address:

IPv6 address of the outgoing interface of can indicate whether the tunnel entry
point node. This address is configured as entry 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 to limit the IPv6 address number of the destination from the original
IPv6 header - see section 6.2.

5.1 Tunnel IPv6 Extension Headers

Depending encapsulations of
tunnel packets originating on various that node. The IPv6 node configuration parameters a tunnel
entry point node may append to Tunnel
Encapsulation Limit is the tunnel IPv6 main header, one or
more IPv6 extension headers maximum number of encapsulations permitted
for packets undergoing encapsulation at that are not directly related entry-point node.
Recommended default value is 5. An entry-point node configured 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, prepends a Tunnel Encapsulation Limit destination
option header with fields set as follows:

Conta & Deering Expires in six months [Page 21]

INTERNET-DRAFT Tunneling in IPv6 February 22, June 13, 1996

Next Header:

Identifies the type of header immediately following the
Tunnel

Encapsulation Limit destination option options header [RFC-
1883].

If the to an original packet is an IPv6 packet,
undergoing encapsulation - see section 4.1, 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.7 IPv6 Tunnel State Variables MTU

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

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

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

(d) tunnel: the tunnel
maximum size of a packet priority - is configured

(e) that can be sent through the tunnel packet flow label - is configured

(f) without
fragmentation [RFC-1883]. The tunnel entry-point node performs Path
MTU discovery on the tunnel encapsulation limit - may [IPv6PMTU], [RFC-1885].

Although it should be configured

(g) the able to send a tunnel MTU

6.1 IPv6 Tunnel Entry Point Node Address

The tunnel entry point node address is one packet of the any valid IPv6 unicast
addresses belonging to the entry point
size, a tunnel entry-point node - attempts to avoid the validation fragmentation
of the
address at tunnel configuration time is recommended.

The tunnel entry point node address is copied packets, by reporting to the source address
field in nodes of original packets
the tunnel IPv6 header during packet encapsulation.

6.2 MTU to be used in sizing original packets sent towards that
tunnel entry-point node.

7. IPv6 Tunnel Exit-Point Node Address

The Packet Size Issues

A tunnel exit-point node address is used as packet resulting from the encapsulation of an IPv6 destination
address for the original
packet may require fragmentation.

A tunnel IPv6 header. The tunnel exit-point node
address may be configured with a specific packet resulting from the encapsulation of an original
packet is considered an IPv6 address, in which case packet originating from the tunnel acts
entry-point node. Therefore, like any source of an IPv6 packet, a virtual point to point link between the entry
point
tunnel entry-point node and exit-point node, or with the Unspecified must support fragmentation of tunnel IPv6 address
[RFC-1884], in which case the
packets.

A tunnel acts like intermediate node that forwards a virtual point tunnel packet to
point link between the entry point node and an exit-point another
node
identified by in the destination address from tunnel follows the original general IPv6 rule that it must not
fragment a packet
header. undergoing forwarding.

7.1 IPv6 Tunnel Packet Fragmentation

Tunnel packets that exceed the tunnel MTU are candidates for
fragmentation. The fragmentation of tunnel exit-point node address packets containing IPv6
original packets is copied performed as follows:

(a) if the original IPv6 packet size is larger than 576 octets,
the entry-point node discards the packet and it returns an
ICMPv6 "Packet Too Big" message to the destination
address field in source node of the tunnel IPv6 header during
original packet encapsulation. indicating the MTU size to be used by that

Conta & Deering Expires in six months [Page 23] 22]

INTERNET-DRAFT Tunneling in IPv6 February 22, June 13, 1996

6.3 IPv6 Tunnel Hop Limit

An IPv6 tunnel is modeled as a "single-hop virtual link" tunnel,

node in
which regardless of sizing original packets sent towards the number of hops in the IPv6 tunnel, tunnel
entry-point. The MTU is the original packet's passing through packet size minus the
size of the tunnel is like headers - see section 8.2.

(b) if the original
packet's passing over a one hop link.

The "single-hop" mechanism should be implemented by having IPv6 packet is equal or smaller than 576
octets, the tunnel
entry point entry-point node set a tunnel IPv6 header hop limit independently of
the original headers.

The "single-hop" mechanism hides to encapsulates the
original IPv6 packets packet, and subsequently fragments the resulting
IPv6 topology of the tunnel.

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

(a) ensures IPv6 fragments that do not exceed
the tunnel IPv6 MTU.

7.2 IPv4 Tunnel Packet Fragmentation

Tunnel packets reach that exceed the tunnel exit-
point node

(b) ensures a quick expiration MTU are candidates for
fragmentation. The conditions that determine IPv4 fragmentation of the
tunnel packet packets are as follows:

(a) if a
routing loop occurs within in the IPv6 tunnel.

The tunnel hop limit default value for hosts is original IPv4 packet header the neighbor
discovery advertised hop limit [IPv6ND]. The tunnel hop limit default
value for routers Don't Fragment -
DF - bit flag is SET, the default IPv6 Hop Limit [TBD] value from entry-point node discards the
Assigned Numbers RFC.
packet and returns an ICMP message. The tunnel hop limit is copied into ICMP message has
the hop limit type = "unreachable", the code = "datagram too big",
and the recommended MTU size field of set to the tunnel
IPv6 header size of each the
original packet encapsulated by minus the tunnel entry point
node.

6.4 IPv6 Tunnel Packet Priority

The IPv6 Tunnel Packet Priority indicates size of the value that a tunnel
entry point node sets headers - see
section 8.3.

(b) if in the priority field of a tunnel header. The
default value is zero. The Packet Priority may also indicate whether
the value of original packet header the priority field in Don't Fragment - DF -
bit flag is CLEAR, the tunnel header is copied from entry-point node encapsulates
the original header, or it is set to packet, and subsequently fragments the configured value.

6.5
resulting IPv6 Tunnel Flow Label

The tunnel packet into IPv6 fragments that do
not exceed the tunnel MTU.

8. IPv6 Tunnel Flow Label indicates Error Processing and Reporting

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

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

Conta & Deering Expires in six months [Page 24] 23]

INTERNET-DRAFT Tunneling in IPv6 February 22, June 13, 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. IPv6 packet.

An entry point error detected by a node configured to limit the number of encapsulations,
prepends inside 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 reported to the Path MTU source
of the tunnel - the
maximum size of a packet packet, that can be sent through is, the tunnel without
fragmentation - see [RFC-1883]. entry-point node. The tunnel entry point node performs
Path MTU discovery on ICMP
message sent to the tunnel [IPv6PMTU], [RFC-1885].

Although it should be able to send a entry-point node has as ICMP payload the
tunnel IPv6 packet that has the original packet as its payload.

The cause of any valid
size, a packet error encountered inside a tunnel entry point node attempts to avoid can be a
problem with:

(a) the fragmentation
of tunnel packets, by informing source nodes of original packets header, or

(b) the
MTU tunnel packet.

Both tunnel header and tunnel packet problems are reported to be used in sizing original packets sent towards that the
tunnel
entry point entry-point node.

7. IPv6 Tunnel Packet Fragmentation

Although the fragmentation of

If a tunnel packets depends on the protocol packet problem is a consequence of a problem with the
original packet, which is the primary condition for fragmentation payload of the tunnel packet, then the
problem is also reported to the size source of the original packet.

To report a problem detected inside the tunnel IPv6 packet resulting from to the encapsulation source of an
original
packet is considered an IPv6 packet originating from packet, 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 relay the ICMP
message received from inside the tunnel, that forwards a tunnel packet to another
node in the tunnel, follows the general source of that
original IPv6 rule packet.

An example of the processing that it must not
fragment a packet undergoing forwarding.

Conta & Deering Expires can take place in six months [Page 25]

INTERNET-DRAFT Tunneling the error
reporting mechanism of a node is illustrated in Fig.7, and Fig.8:

Fig.7 path #0 and Fig.8 (a) - The IPv6 February 22, 1996

Depending on the tunnel entry-point receives an
ICMP packet protocol, from inside the following fragmentation
can take place:

7.1 IPv6 Packet Fragmentation

The fragmentation of tunnel, marked Tunnel ICMPv6 Message in
Fig.7. The tunnel packets containing entry-point node IPv6 original packets
is performed as follows:

(a) if the original packet size is larger than 576 octets, then layer passes the entry point node returns an ICMPv6 "Packet Too Big" received
ICMP 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 ICMPv6 Input. The ICMPv6 Input, based on the tunnel entry point. ICMP
type and code [RFC-1885] generates an internal "error code".

Fig.7 path #1 - The
MTU internal error code, is passed with the original packet size minus "ICMPv6
message payload" to the size of upper-layer protocol - in this case the IPv6
tunnel headers - see 8.2, upper-layer error input.

Fig.7 path #2 and 8.3. Fig.8 (b) if - The IPv6 tunnel error input
decapsulates the original packet tunnel IPv6 packet, which is equal or smaller than 576 octets
then the tunnel entry point node encapsulates ICMPv6 message
payload, obtaining the original packet, and after encapsulation it breaks thus the resulting
IPv6 tunnel packet into IPv6 fragments that do not exceed original headers
and dispatches the tunnel MTU.

7.2 IPv4 Packet Fragmentation

Although "internal error code", the fragmentation of tunnel packets depends on source address from the protocol
of
original packet header, and the original packet, down to the primary condition for fragmentation is
the size error
report block of the original packet:

(a) if the original packet size is larger than 576 octets, and protocol identified by the Don't Fragment - DF - bit Next Header field in
the IPv4 tunnel 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 immediately preceding the original node packet 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
ICMP message payload.

Conta & Deering Expires in six months [Page 26] 24]

INTERNET-DRAFT Tunneling in IPv6 February 22, June 13, 1996

IPv6 tunnel packet into IPv6 fragments that do not exceed
the tunnel MTU.

IPv6 Tunneling follows the general rule that errors detected during
the processing of | | Error | | Error |
| Input | | Input | | Input |
| | | | | Decapsulate |
| | | | | -->--ICMPv6--#2->-- |
| | | | | | Payload | |
+-------+ +-------+ +--|-----------------|--+
| | | |
^ ^ ^ v
| | | |
--------------------#1-- -----Orig.Packet?--- - - - - - - - - -
#1 #3 Int.Error Code, #5 |
Int.Error Code,^ v Source Address, v v
ICMPv6 Payload | IPv6 packets are reported to the packet originator
through | Orig. Packet | IPv4 |
+--------------+ +--------------+ +--------------+ + - - - - +
| | | | | |
| 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.

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

From here the
IPv6 tunnel entry point node. The ICMP messages sent to processing depends on the tunnel
entry point node have as ICMP payload protocol of the tunnel original
packet:

(a) - for an IPv6 packet that
includes the original packet.

The cause of packet

Fig.7 path #3 and Fig.8 (c.1)- for an IPv6 original packet, the
ICMPv6 error uncovered inside report builds an ICMP message of a tunnel can be:

(a) type and code
according to the tunnel header, or

(b) "internal error code", containing the tunnel packet. "original
packet" as ICMP payload.

Fig.7 path #4 and Fig.8 (d.1)- The tunnel header problems are reported to ICMP message has the tunnel entry point

Conta & Deering Expires in six months [Page 25]

INTERNET-DRAFT Tunneling in IPv6 June 13, 1996

entry-point node which is address as source address, and the tunnel IPv6 original packet originator.
source node address as destination address. The tunnel packet problems that result from bad encapsulation, are
reported also entry-point
node sends the ICMP message to the tunnel entry point node.

If source node of the tunnel packet problems are a consequence of original
packet.

(b) - for an IPv4 original packet
problem

Fig.7 path #5 and if they can be corrected by the source of the Fig.8 (c.2) - for an IPv4 original packet, then they must be reported to both the tunnel entry point
node and the source of the original packet.

To
ICMPv4 error report to the source builds an ICMP message of original packet a problem detected inside
the tunnel type and reported code
derived from inside the tunnel through an ICMP
message, the tunnel entry point node must relay "internal error code", containing the
"original packet" as ICMP payload.

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

A graphical description of the tunnel ICMP message, as it header processing taking place is graphically described below:

Conta & Deering Expires in six months [Page 27]

INTERNET-DRAFT Tunneling in IPv6 February 22, 1996

+-------+ +-------+ +-----------------------+
| Upper | | Upper the
following:

Conta & Deering Expires in six months [Page 26]

INTERNET-DRAFT Tunneling in IPv6 June 13, 1996

--------------|---------------
| |
V V
+---------+ +--------+ +-------------------//------+
| New | Payload | ICMP |
+-------+ +-------+ +--|-----------------|--+ | |
(c.1) | IPv6 |
^ ^ ^ v + | | + | Orig. Packet in Error |
--------------------#1-- -----Orig.Packet?--- - - - - - - - - -
error code,
| #3 error code, Headers | |
ICMPv6 payload ^ v source address, v Header | | |
+---------+ +--------+ +-------------------//------+
|
v
+---------+--------+-------------------//------+
| IPv6 New | orig. packet ICMP | IPv4 Original |
+--------------+ +--------------+ +--------------+ + - - - - +
(d.1) | IPv6 | | |
| Headers | Header | Packet in Error |
+---------+--------+-------------------//------+
< New ICMP v6 Message >

or for an IPv4 original packet

+---------+ +--------+ +-------------------//------+
| New | | ICMP v6 | | ICMP v4 |
(c.2) | IPv4 | + | Input | + | Orig. Packet in Error Report |
| Error Report Header | | - - - - +----+ - - - - Header | | + - - - - + + - - - - + |
+---------+ +--------+ +-------------------//------+
|
v
+---------+--------+-------------------//------+
| New | ICMP | IPv6 Layer Original |
(d.2) | IPv4 Layer | | |
| Header | Header | Packet in Error |
+----------------------------------+ +--------------+ + - - - - +

Fig. 7.
+---------+--------+-------------------//------+
< New ICMP Message >

Fig.8. ICMP 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 and Processing

8.1 Tunnel ICMP message to the ICMPv6 Input. Messages

The ICMPv6 Input, based on the tunnel ICMP type and code [RFC-1885]
generates an internal "error code" which is passed with the "ICMPv6
message payload" messages that are reported to the upper layer protocol - in this case source of the IPv6
tunnel upper layer - error input (path #1
original packet are:

hop limit exceeded

The tunnel has a misconfigured hop limit, or contains a

Conta & Deering Expires in Fig. 7, and (a) six months [Page 27]

INTERNET-DRAFT Tunneling in Fig.
8).

The IPv6 tunnel error input decapsulates June 13, 1996

routing loop, and packets do not reach the tunnel IPv6 packet,
which exit-
point node. This problem is reported to the ICMPv6 message payload, obtaining tunnel entry-
point node, where the original packet,
and thus tunnel hop limit can be reconfigured
to a higher value. The problem is further reported to the
source of the original headers - path #2 packet as described in Fig. 7 and (b) section 8.2,
or 8.3.

unreachable node

One of the nodes in Fig. 8 -
and dispatches the "error code", tunnel is not or is no longer
reachable. This problem is reported to the source address from tunnel entry-
point node, which should be reconfigured with a valid and
active path between the original
packet header, entry and exit-point of the original packet, down tunnel.
The problem is further reported to the error report
block source of the protocol identified by the Next Header field in the
tunnel header immediately preceding the
original packet as described in the section 8.2, or 8.3.

parameter problem

A Parameter Problem ICMP message payload - in this example ICMPv6. The ICMPv6 error report
builds pointing to a valid Tunnel
Encapsulation Limit Destination header with a Tun Encap Lim
field value set to one is an ICMP message indication that the tunnel
packet exceeded the maximum number of a type and code according encapsulations
allowed. The problem is further reported to the "error
code", containing source of
the "original packet" original packet as ICMP payload - - path #3 described in Fig. 7 and (c) in Fig. 8. section 8.2, or 8.3.

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

packet too big

The tunnel packet exceeds the tunnel Path MTU.

This type of ICMP message has is used as follows:

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

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

Conta & Deering Expires in six months [Page 28]

INTERNET-DRAFT Tunneling in IPv6 February 22, June 13, 1996

point node address as source address, and the original packet source
node address as destination address - (d) in Fig. 8.

8.2 ICMP Messages for IPv6 Original Packets

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

IPv6 Fields:

Source Address

A graphical description valid unicast IPv6 address of the header processing taking place is outgoing interface.

Destination Address

Copied from the
following:

< Tunnel packet >
+--------+- - - - - -+--------+------------------------------//------+
| IPv6 | Source Address field of the Original
IPv6 | header.

ICMP Fields:

hop limit exceeded

unreachable node

parameter problem

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

Type 1 - unreachable node

Code 3 - address unreachable

For tunnel ICMP 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 | message "packet too big":

Type 2 - packet in error |
+---------+--------+-------------------//------+
< new too big

Code 0

MTU The MTU field from the tunnel ICMP message >

Fig. 8. ICMP Error reporting and processing minus
the length of the tunnel headers.

Conta & Deering Expires in six months [Page 29]

INTERNET-DRAFT Tunneling in IPv6 February 22, June 13, 1996

8.1 Tunnel ICMP Messages

The tunnel

According to the general rules described in 7.1, an ICMP messages which are reported "packet too
big" message is sent to the source of the original packet
originator are:

hop limit exceeded only if the
original packet size is larger than 576 octets.

8.3 ICMP Messages for IPv4 Original Packets

The tunnel has a misconfigured hop limit, or contains a
routing loop, entry-point node builds the ICMP and packets do not reach IPv4 header of the tunnel exit-
point node. This problem
ICMP message that is reported sent to the tunnel entry
point node - the tunnel hop limit must be reconfigured to a
higher value - and also to source of the original IPv6 packet
originator.

unreachable node

One as
follows:

IPv4 Fields:

Source Address

A valid unicast IPv4 address 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 outgoing interface.

Destination Address

Copied from the tunnel with a
valid and active path between Source Address field of the entry and exit-point Original
IPv4 header.

ICMP Fields:

For any of the tunnel. following tunnel ICMP error messages:

hop limit exceeded

unreachable node

parameter problem

A Parameter Problem ICMP message

pointing to a valid Tunnel
Encapsulation Enacpsulation Limit Destination destination
header with a the 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 value one:

Conta & Deering Expires in six months [Page 30]

INTERNET-DRAFT Tunneling in IPv6 packet originator, as June 13, 1996

Type 3 - destination unreachable

Code 1 - host unreachable

For a tunnel generic
"unreachable" problem caused by a "link problem" ICMP error message "packet too big":

Type 3 - see section 8.2
and 8.3.

packet destination unreachable

Code 4 - datagram too big

MTU The tunnel packet exceeds MTU field from the tunnel Path MTU.

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

When sent, according headers.

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 7.2, an ICMP
"datagram too big" message is used by the tunnel entry
point node to indicate sent to an the original IPv4 packet source
node
that original packets sent from that node to if the tunnel
entry point node should be resized to the MTU indicated by original IPv4 header has the ICMP message.

8.2 DF - don't fragment -
bit flag SET.

8.4 ICMP Messages for IPv6 Original Recursive Tunnel Packets

The

In case of an error uncovered with a recursive tunnel entry point node builds packet, the
inner tunnel entry-point, which receives the ICMP and IPv6 headers of error message from
the inner tunnel reporting node, relays the ICMP message that is sent to the original packet source node as
follows:

IPv6 Fields:

Source Address

A valid unicast IPv6 address of outer
tunnel entry-point following the outgoing interface.

Destination Address

Copied from mechanisms described in sections
8.,8.1, 8.2, and 8.3. Further, the Source Address field of outer tunnel entry-point relays
the Original
IPv6 header. ICMP Fields:

For any message to the source of the original packet, following tunnel ICMP error messages: the
same mechanisms.

9. Open Issues

(a) Tunnel default 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:

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.

Conta & Deering Expires in six months [Page 31]

INTERNET-DRAFT Tunneling in IPv6 February 22, June 13, 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

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 then
breaks the resulting IPv6 tunnel packet into IPv6 fragments that do
not exceed the tunnel MTU.

8.3 ICMP Messages S. Deering "Internet Control Message Protocol for IPv4 Original Packets

The tunnel entry point node builds
the ICMP Internet Protocol Version 6 (IPv6)"

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

[IPv6PMTU]
J. McCann and IPv4 header of the
ICMP message that is sent to the original packet source node as
follows:

IPv4 Fields:

Source S. Deering, "IPv6 Path MTU Discovery"

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

A valid unicast IPv4 address of Autoconfiguration"

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

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

11.Acknowledgments

This document is partially derived from several discussions about
IPv6 tunneling on the outgoing interface.

Destination Address

Copied IPng Working Group Mailing List and from
feedback from the Source Address field of IPng Working Group to an IPv6 presentation that
focused on IPv6 tunneling at the Original
IPv4 header.

ICMP Fields:

For any of 33rd IETF, in Stockholm, in July
1995.

Additionally, the following tunnel ICMP error messages: documents that focused on tunneling or

Conta & Deering Expires in six months [Page 32]

INTERNET-DRAFT Tunneling in IPv6 February 22, June 13, 1996

hop limit exceeded

unreachable node

parameter problem

pointing to a valid Tunnel Enacpsulation Limit destination
header with

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 the Tun Encap Lim field set IP encapsulation draft of the Mobile IP
working Group (C. Perkins).

Important contributions were made by Brian Carpenter and Erik
Nordmark, both of whom gave numerous and valuable reviewing comments
and suggestions for the improvement of this document. Also many
thanks to Judith Grossman, who provided a value one:

Type 3 - destination unreachable

Code 1 - host unreachable

For sample of her many years of
editorial and writing experience as well as a tunnel ICMP error message "packet too big":

Type 3 - destination unreachable

Code 4 - datagram too big

MTU good amount of probing
technical questions.

[TBD]

12.Security Considerations

Security considerations are not discussed in this memo.

Authors' Addresses:

Alex Conta Stephen Deering
Cascade Communications Corp. Xerox Palo Alto Research Center
5 Carlisle Rd 3333 Coyote Hill Road
Westford, MA 03062 Palo Alto, CA 94304
+1-508-952-1534 +1-415-812-4839

email: conta@casc.com email: deering@parc.xerox.com

Appendix A

A.1 Risk Factors in Recursive Encapsulation

The MTU field from the tunnel ICMP message minus
the length cases which present a high risk of the excessive recursive
encapsulation are those in which a tunnel headers.

According entry-point node cannot
discern between a valid and an invalid recursive encapsulation.
Routing loops that cause tunnel packets to reach nodes that were
already reached before are certainly the general rules described in 7.2, an ICMP "datagram
too big" message major cause of the problem.
But since routing loops exist, and happen, it is sent important to

Conta & Deering Expires in six months [Page 33]

INTERNET-DRAFT Tunneling in IPv6 June 13, 1996

understand and describe, the original IPv4 packet source node only
if cases in which the original packet size risk for excessive
recursive encapsulation is larger than 576 octets.

An additionally condition higher.

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

(a) the type of tunnel,

(b) the type of route to be met for sending the ICMP
message is that tunnel exit-point, which
determines the original IPv4 packet header must have forwarding through the DF -
don't fragment tunnel, that
is, over the tunnel virtual-link.

A.1.1 Risk Factor in Recursive Encapsulation - bit flag set type of tunnel.

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

"inner tunnels with identical exit-points".

These tunnels can be:

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

or:

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

Note that free-end inner tunnels fall always into the IPv6 original header.

If the DF bit is clear, the tunnel entry point encapsulates category of
identical exit-point tunnels.

Since the source and destination of an original IPv4 packet and then breaks is the resulting IPv6 tunnel main
information used to decide whether to forward a packet
into IPv6 fragments through a
tunnel or not, an excessive recursive encapsulation can be avoided in
case of a single tunnel (non-inner), by checking that do the packet to
be encapsulated is not exceed originated on the tunnel MTU.

9. Open Issues

Open issues are:

(a) Multicast exit point

Does it make sense entry-point node. This
mechanism is suggested in [IPv4TUN].

However, this type of protection does not seem to have an IPv6 multicast address as tunnel
exit-point node address?

Conta & Deering Expires work well in six months [Page 33]

INTERNET-DRAFT Tunneling case
of inner tunnels with different entry-points, and identical exit-
points.

Inner tunnels with different entry-points and identical exit-points
introduce ambiguity in IPv6 February 22, 1996

(b) Anycast exit point

Does it make sense deciding whether to have encapsulate a packet, when
a packet encapsulated in an IPv6 anycast address as inner tunnel
exit-point reaches the entry-point node address?

At this time, there is no definition for
of 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] outer tunnel by means of a routing loop. Because the source of

Conta & Deering Expires in six months [Page 34]

INTERNET-DRAFT Tunneling in IPv6 February 22, June 13, 1996

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

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

11.Acknowledgements

The document

the tunnel packet 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 inner tunnel entry-point node which is
different than the entry-point node of the outer tunnel, the source
address checking (mentioned above) fails to detect an IPv6 tunneling
focused IPng Working Group session invalid
encapsulation, and as a consequence the tunnel packet gets
encapsulated at the 33th IETF, outer tunnel each time it reaches it through the
routing loop.

A.1.2 Risk Factor in Stockholm,
July 1995.

Additionally, several documents focused on tunneling or encapsulation
were used Recursive Encapsulation - type of route.

The type of route to a tunnel exit-point node has been also
identified as a reference: "Transition Mechanisms for 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, that is, the destination is a valid
specified 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 address (route to node). Such a route can be selected
based on the reviewers longest match 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 an original packet destination address
with different entry-points and
identical exit-points

Conta & Deering Expires in six months [Page 35]

INTERNET-DRAFT Tunneling the destination address stored in IPv6 February 22, 1996

node node node node node node the tunnel entry-point 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
routing table entry for that route. The packet forwarded on such a
route is first encapsulated and then forwarded towards the tunnel II from c.c.1
exit-point node.

Another type of route to z.z.1

1. a tunnel exit-point node a.a.1:

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

2. node b.b.1:

rcv: aa1/zz1

forwarding: anything a
specified prefix-net, that is, the destination is destined a valid specified
IPv6 prefix (route to net). Such a route can be selected based on the
longest path match of an original packet destination address with the
prefix 'z' => destination stored in the tunnel 'bb1/z
z1'
and send to cc1

xmt: bb1/zz1 | aa1/zz1
to cc1

3. entry-point node cc1:

rcv: bb1/zz1 | aa1/zz1

forwarding: anything routing
table entry for that route. The packet forwarded on such a route is destined to prefix 'z' => tunnel 'cc1/z
z1'
first encapsulated and send to next router on then forwarded towards the way tunnel exit-point
node.

And finally another type of route to dd1

xmt: cc1/zz1 | bb1/zz1 | aa1/zz1 a tunnel exit-point is a default
route, or a route to next router on an unspecified destination. This route is
selected when no-other match for the way to dd1

4. before reaching node dd1, routing loop brings destination of the original
packet to bb1

loop::
node bb1:

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

forwarding: anything has been found in the routing table. A tunnel that is destined the
first hop of a default route is a "default tunnel".

If the route to prefix 'z' => a tunnel 'bb1/
zz1'
and send to cc1

xmt: bb1/zz1 | cc1/zz1 | bb1/zz1 | aa1/zz1 exit-point is a route 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 node, the risk
factor for excessive recursive encapsulation is destined minimum.

If the route to prefix 'z' => a tunnel 'cc1/
zz1'

xmt: cc1/zz1 | bb1/zz1 | cc1/zz1 | bb1/zz1 | aa1/zz1
to next router on the way exit-point is a route to dd1

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

Appendix B

Default Tunnel - maximum risk
factor for excessive recursive encapsulation in case is medium. There is a
range 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 destination addresses that does not go to will match the prefix 'a' the route
is associated with. If one or 'c'
=> more inner tunnels with different
tunnel 'bb1/ff1' and send to cc1

xmt: bb1/ff1 | aa1/zz1

3. entry-points have exit-point node cc1:

rcv: bb1/ff1 | aa1/zz1

forwarding: anything addresses that does not go to prefix 'a', or 'b', or 'd'
=> tunnel 'cc1/ee1' and send to next router on match the way
route to ee1 net of an outer tunnel exit-point, then an excessive

Conta & Deering Expires in six months [Page 37] 35]

INTERNET-DRAFT Tunneling in IPv6 February 22, June 13, 1996

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

recursive encapsulation may occur if a tunnel packet gets diverted
from inside such an inner tunnel to next router on the way entry-point of the outer
tunnel that has a route to ee1

4. before reaching node ee1, 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 brings case, if a tunnel packet to bb1

loop::
node bb1:

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

forwarding:
anything that does not go to prefix 'a' or 'c'
=> gets diverted
from an inner 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 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 go be able
to prefix 'a', or 'b', or 'd'
=> tunnel 'cc1/ee1'

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

NOTE: check discern differently, based on source address = packet source DOES NOT eliminate the recursi
ve
encapsulation

Changes from previous version. destination.

Appendix B Changes:

B.1 From draft 00 to draft 01

- add new sections:

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

- separate fragmentation from section 6.7 into a new
section:

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

Conta & Deering Expires in six months [Page 38]

INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 Fragmentation

- include comments from Erik Nordmark

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

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

Conta & Deering Expires in six months [Page 36]

INTERNET-DRAFT Tunneling in IPv6 June 13, 1996

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

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

------- End of Forwarded Message

B.2 From draft 01 to draft 02

- deleted - Appendix A
- Appendix B

- moved section 4.1.4 to new Appendix A.

- added new section 3.2 "IPv6 Packet Processing in Tunnels".

- added new section 8.4 "ICMP Messages for Recursive Tunnel Packets".

- improved, reduced, or extended text in
(this includes comments from Erik Nordmark)

1. Introduction
2. Terminology
3. Generic IPv6 Tunneling
3.1 IPv6 Encapsulation
3.2 IPv6 Packet Processing in Tunnels...
3.3 IPv6 Decapsulation...
3.4 IPv6 Tunnel Protocol Engine...
4. Recursive Encapsulation...
4.1 Limiting Recursive Encapsulation...
4.1.1 Tunnel Encapsulation Limit...
4.1.2 Loopback Recursive Encapsulation...
4.1.3 Routing Loop Recursive Encapsulation...
7. IPv6 Tunnel Packet Fragmentation...
7.1 IPv6 Packet Fragmentation...
7.2 IPv4 Packet Fragmentation...
8. IPv6 Tunnel Error Reporting and Processing...
8.1 Tunnel ICMP Messages...
8.2 ICMP Messages for IPv6 Original Packets...
8.3 ICMP Messages for IPv4 Original Packets...

- changed sections title:

7. IPv6 Tunnel Packet Fragmentation
to:

Conta & Deering Expires in six months [Page 37]

INTERNET-DRAFT Tunneling in IPv6 June 13, 1996

7. IPv6 Tunnel Packet Size Issues

7.1 IPv6 Packet Fragmentation
to:
7.1 IPv6 Tunnel Packet Fragmentation

7.2 IPv4 Packet Fragmentation
to:
7.2 IPv4 Tunnel Packet Fragmentation

Conta & Deering Expires in six months [Page 38]

----