IPng Working Group A. Conta (Transwitch)
INTERNET-DRAFT
November 2000
Generic Packet Tunneling in IPv6 - Bi-directional Tunneling
Specification
draft-conta-extensions-ipv6-tunnel-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document defines extensions to the model and generic mechanisms
specified in "Generic Packet Tunneling in IPv6" [IPv6-TUNNEL]. These
extensions apply specifically to bi-directional IPv6 tunnels.
Conta Expires in six months [Page 1]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 November 22, 19100
Table of Contents
Status of this Memo...........................................1
Table of Contents.............................................2
Terminology...................................................3
1. Introduction..................................................4
2. Uni-Directional, and Bi-Directional Tunnels...................4
3. Invariable Path IPv6 Tunnels..................................7
4. IPv6 Tunnels Invariable State Variable........................8
5. IPv6 Tunnel Type State Variables..............................8
5.1 IPv6 Tunnel Type -- Uni-Directional.......................9
5.2 IPv6 Tunnel Type -- Bi-Directional........................9
5.2.1 IPv6 Tunnel Type -- Symmetric Bi-Directional...........10
6. Security Considerations......................................11
7. Acknowledgments..............................................12
8. References...................................................13
Author's Address................................................14
Fig.1.................................................6
Fig.2.................................................7
Conta Expires in six months [Page 2]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 November 22, 19100
Terminology
The terminology defined in [IPv6-TUNNEL] is used at a large extent
throughout this document. Several additional definitions for bi-
directional tunneling follow:
bi-directional tunnel
a tunnel in which tunnel data traffic takes place in both
directions, e.g., direct direction, from the entry-point to
the exit-point node, and reverse direction, from the exit-
point node to the entry-point node.
direct tunnel
the term is used with a bi-directional tunnel, to identify the
direct tunnel path, e.g., the tunnel from the entry-point to
the exit-point node.
reverse tunnel
the term is used with a bi-directional tunnel, to identify the
reverse tunnel path, e.g., the tunnel from the exit-point to
the entry-point node.
tunnel entry
synonym for the tunnel entry-point node [IPv6-Tunnel]
tunnel exit
synonym for the tunnel exit-point node [IPv6-Tunnel]
Conta Expires in six months [Page 3]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 November 22, 19100
1. Introduction
In conformance with [IPv6-TUNNEL], IPv6 tunneling is a technique for
establishing a "virtual link" between two IPv6 nodes for transmitting
data packets as payloads of IPv6 packets (see Fig.1). From the point
of view of the two nodes, this "virtual link", called an IPv6 tunnel,
appears as a point to point link on which IPv6 acts like a link-layer
protocol. The two IPv6 nodes play specific roles. One node
encapsulates original packets received from other nodes or from
itself and forwards the resulting tunnel packets through the tunnel.
The other node decapsulates the received tunnel packets and forwards
the resulting original packets towards their destinations, possibly
itself. The encapsulator node is called the tunnel entry-point node,
and it is the source of the tunnel packets. The decapsulator node is
called the tunnel exit-point, and it is the destination of the tunnel
packets.
This document defines extensions to the model and generic mechanisms
for IPv6 encapsulation of Internet packets specified in "Generic
Packet Tunneling in IPv6" [IPv6-TUNNEL]. These extensions are
related to the character of the data traffic in the tunnel, as well
as the tunnel configuration performed at the end-nodes of the tunnel.
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as
defined in RFC 2119.
2. Uni-Directional, and Bi-Directional Tunnels
Configuring an IPv6 tunnel involves in principle the following basic
operations:
"At the Tunnel Entry-Point"
The enabling/configuring of the mechanism that will encapsulate
packets originated or forwarded by the node, and forward them into
the tunnel. This likely may, but not exclusively, or uniquely,
involve:
o The creation/configuration of a pseudo or logical interface,
called "tunnel" interface, on the top or as an "off-spring" of an
existent "parent" interface, which can be a physical interface, or
another tunnel interface. In the former case, original packets
are encapsulated before being transmitted onto the physical
Conta Expires in six months [Page 4]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 November 22, 19100
interface. In the latter case, the tunnel is a nested tunnel:
tunnel packets will be encapsulated in tunnel packets, but
ultimately will be transmitted on the physical interface which is
the parent of the tunnel interface of the most outer tunnel
[IPv6-Tunnel].
o The creation of a routing table entry, pointing to the tunnel
interface, as the outgoing interface, that determines the
forwarding of IP packets onto the tunnel interface, into the
tunnel encapsulation engine.
o A node, which is down-stream for the traffic that will be
tunneled, and where the tunnel traffic must end, is configured as
tunnel exit. The tunnel exit is specified by ways of an IPv6
address. This is the address that will be filled in as destination
address in the IPv6 tunnel header [IPv6-Tunnel].
o The configuring of the tunnel entry address that will be used as
source address of the tunnel packets. This address will be filled
in the IPv6 tunnel header as the source address [IPv6-Tunnel].
Note: The operations specified above have a protocol engine
implementation characteristic. It is the uni-directional and bi-
directional behavior that are to be standardized and not the
mechanisms through which they are achieved. An implementation may
have different ways in which the same functionality is achieved.
"At the Tunnel Exit-Point"
o Enable tunnel packet decapsulation. Tunnel exit-point nodes need
not explicitly know that they are the exit-point of a particular
tunnel. However, a tunnel-exit point node needs the capability of
decapsulating tunnel packets, therefore if such a capability is
provided with an enable/disable switch, the switch must be toggled
onto the "enable" position.
These basic configuration operations affect only the traffic from the
entry-point node to the exit-point node, that is packets will be
tunneled in one direction, from the entry-point node to the exit-
point node. They will not affect the traffic in reverse direction,
that is packets transmitted in reverse direction, from the exit-point
node to the entry-point node, are not being tunneled. The result is
Conta Expires in six months [Page 5]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 November 22, 19100
that the tunnel has the characteristic of a "uni-directional"
mechanism. For instance in Fig.1, Node B is the entry-point node in
the tunnel, and node C is the exit-point from the tunnel, and the
tunnel traffic flows in one direction from B to C.
Tunnel from node B to node C
<---------------------->
Tunnel Tunnel
Entry-Point Exit-Point
Node Node
+-+ +-+ +-+ +-+
|A|-->--//-->--|B|=====>=====//=====>=====|C|-->--//-->--|D|
+-+ +-+ +-+ +-+
Original Original
Packet Packet
Source Destination
Node Node
Fig.1 Tunnel
To tunnel the reverse traffic, the basic tunnel configuration
operations specified above or their equivalent must be repeated in
reverse direction, that is, a tunnel interface must be configured on
the exit-point node and the decapsulation of tunnel packets must be
enabled on the tunnel entry-point node. In Fig.2, this additional
configuration adds to Node B, which was an entry-point node, the
characteristic of an exit-point node, and conversely, to Node C,
which was an exit-point node, the characteristic of an entry-point
node.
In conclusion, bi-directional tunneling is achieved in fact by
merging two unidirectional mechanisms, that is, configuring two
tunnels, a "direct" tunnel, and a "reverse" tunnel, each in opposite
direction to the other -- the entry-point node of the "direct" tunnel
is the exit-point node of the "reverse" tunnel (see Fig.2). By
default a tunnel is a "direct" tunnel.
Conta Expires in six months [Page 6]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 November 22, 19100
Tunnel from Node B to Node C
<------------------------>
Tunnel Tunnel
Original Entry-Point Exit-Point Original
Packet Node Node Packet
Source Destination
Node Node
+-+ +-+ +-+ +-+
| |-->--//-->--| |=====>=====//=====>======| |-->--//-->--| |
|A| |B| |C| |D|
| |--<--//--<--| |=====<=====//=====<======| |--<--//--<--| |
+-+ +-+ +-+ +-+
Original Original
Packet Packet
Destination Tunnel Tunnel Source
Node Exit-Point Entry-Point Node
Node Node
<------------------------->
Tunnel from Node C to Node B
Fig.2 Bi-directional Tunneling Mechanism
It is important to note that by the nature of IP routing, in case it
relies on the dynamic routing protocols mechanisms to forward the
tunnel packets, a bi-directional tunnel, if it has more than one hop,
will have most likely an asymmetric characteristic. That means that
there is no guarantee that the "reverse" traffic will follow hop by
hop the reverted "direct" path. It is likely that to ensure a perfect
symmetry, that is a "reverse" path identical to the "direct" path in
reverse, it is either necessary to configure statically the routes
each router in the tunnel to forward "reverse" tunnel packets on the
reverted direct path, either to use traffic engineering, like strict
source routing by inserting IPv6 routing headers to force the reverse
traffic strictly on the reverted direct path.
3. Invariable Path IPv6 Tunnels
IPv6 tunnel packets are forwarded inside a tunnel in a similar
fashion as IPv6 packets are forwarded on a normal IPv6 path, that is,
outside an IPv6 tunnel [IPv6-Tunnel]. An IPv6 path, which is based on
dynamic routing, may change in time, that is, the order, the member
routers, and/or the number of hops may be different at distinct
times. This change is often occurring because of changes in the
network topology, the availability of routers, and links that inter-
connects them. Similarly, an IPv6 tunnel path, that is the set of
nodes, and the order in which they are reached by forwarded tunnel
packets, may change for the same reasons, as an IPv6 path. The effect
Conta Expires in six months [Page 7]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 November 22, 19100
of this is that not only the set of nodes, and their order, may
change, but also the number of hops that tunnel packets travel in the
tunnel. This may have an impact on the configuration of the tunnel,
in particular the Hop Limit Tunnel State variable [IPv6-Tunnel].
In some cases, it is useful to pin the tunnel path, that is, to make
the set of nodes and their order constant for the entire life of the
tunnel. Such a tunnel is called Invariable Path IPv6 Tunnel. An
invariable path tunnel can be constructed by means of statically
configuring the routes that determine the path in the tunnel. Also,
an invariable path tunnel can be constructed by configuring a tunnel
to use source routing to forward packets inside the tunnel, from the
entry point to the exit point. The source route is the enumeration of
the set of nodes in the tunnel in the exact order of the desired
tunnel path. The tunnel entry, where the configuration parameters of
the tunnel are being stored, will insert an IPv6 routing header with
the source route as part of the tunnel headers.
A case in which an Invariable Path Tunnel is useful is when a network
operator needs to redirect traffic from a congested portion of a path
chosen by dynamic routing. The method in which this can be achieved
is by configuring an invariable path tunnel, that is away, and around
the congested portion of the path. This invariable path tunnel has as
end points two nodes, that are, one upstream, and the other one
downstream from the congested portion of the path.
4. IPv6 Tunnel Invariable Path State Variable
The IPv6 Tunnel Invariable Path State variable captures the source
route used for pinning the set of nodes and their order in an
invariable path tunnel. It is a set of valid IPv6 addresses, that are
valid in an IPv6 routing header, in the appropriate order of the
desired tunnel path. The IPv6 routing header is made part of the
tunnel headers prepended to the original packet during tunnel
encapsulation.
5. IPv6 Tunnel Type State Variable
More configuration operations can be performed on the tunnel entry
and tunnel exit nodes besides the basic configuration operations to
control or affect the tunnel traffic. For instance a node can be
attached filtering options with each tunnel, to enable traffic from
particular nodes, and disable or drop traffic from others.
Conta Expires in six months [Page 8]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 November 22, 19100
The configuration of a tunnel entry or exit node is captured in
several state variables [IPv6-Tunnel]. The Tunnel type state variable
is introduced to indicate the type of control that is applied to the
traffic in a tunnel. It indicates the uni-directional or bi-
directional character of the data traffic in the tunnel, as well as
the extent of tunnel configuration at the entry-node to filter
traffic flows.
The tunnel type can be one of the following:
- "uni-directional",
- "bi-directional".
- "symmetric bi-directional"
5.1 IPv6 Tunnel Type -- Uni-Directional
A "uni-directional" tunnel is a tunnel that meets all of the
following criteria:
- a node which is placed ahead of other nodes on the path of a
traffic flow is configured as the Tunnel Entry node (see Section
above).
- the node specified as exit node in the configuring of the tunnel
entry, is enabled to perform tunnel packet decapsulation.
These criteria qualify the tunnel as a "direct" tunnel between the
tunnel entry and tunnel exit.
Note: In conformance with its definition, a "uni-directional tunnel"
allows tunnel packet traffic only in one direction, that is, it acts
as a uni-directional virtual link. This MUST be considered in case
Neighbor Discovery mechanisms [ND-Spec] are to be used.
5.2 IPv6 Tunnel Type -- Bi-Directional
A "bi-directional" tunnel is a tunnel that meets all of the following
criteria:
- a "direct" tunnel is configured between two nodes.
- a "reverse" tunnel is configured between the "direct" tunnel entry
Conta Expires in six months [Page 9]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 November 22, 19100
end exit.
A "bi-directional" tunnel, allows tunnel traffic to flow in both
directions, but it is likely that it will behave as an asymmetric
link, since the direct path may contain different nodes than the
reverse one. The bi-directional and asymmetrical characteristics of
the tunnel MUST be considered if Neighbor Discovery [ND-Spec]
mechanisms are to be used.
5.2.1 IPv6 Tunnel Type -- Symmetric Bi-Directional
A "symmetric bi-directional" tunnel is a bi-directional tunnel that
meets all of the following criteria:
- the reverse path is identical with the reverted direct path.
This can be achieved through various means, such as static
configuration of the routing tables of the the routers in the reverse
tunnel, or inserting a routing header that will force the tunnel
packets on the reverse tunnel on a path identical to the reverted
direct path. A Symmetric Bi-Directional tunnel is most likely an
invariable path tunnel. If that is the case, then that is reflected
by the Tunnel Invariable State Variable.
Note: A "symmetrical bi-directional" tunnel, allows tunnel traffic to
flow in both directions, on paths that contain the same nodes, that
is the reverse path is identical with reverted direct path. The bi-
directional and symmetrical characteristics of the tunnel MUST be
considered if Neighbor Discovery [ND-Spec] mechanisms are to be used.
Conta Expires in six months [Page 10]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 November 22, 19100
9. Security Considerations
The security considerations of [IPv6-Tunnel] apply to this
specification as well.
An IPv6 tunnel can be secured by securing the IPv6 path between the
tunnel entry-point and exit-point node. The security architecture,
mechanisms, and services are described in [IPsec-Arch], [IPsec-Auth],
and [IPsec-Encr]. A secure IPv6 tunnel may act as a gateway-to-
gateway secure path as described in [IPsec-Encr].
For a secure IPv6 tunnel, in addition to the mechanisms described
earlier in this document, the entry-point node of the tunnel performs
security algorithms on the packet and prepends as part of the tunnel
headers one or more security headers in conformance with [IPv6-Spec],
[IPsec-Arch], and [IPsec-Auth], or [IPsec-Encr].
The exit-point node of a secure IPv6 tunnel performs security
algorithms and processes the tunnel security header[s] as part of the
tunnel headers processing described earlier, and in conformance with
[IPsec-Arch], and [IPsec-Auth], or [IPsec-Encr]. The exit-point node
discards the tunnel security header[s] with the rest of the tunnel
headers after tunnel headers processing completion.
The degree of integrity, authentication, and confidentiality and the
security processing performed on a tunnel packet at the entry-point
and exit-point node of a secure IPv6 tunnel depend on the type of
security header - authentication (AH) or encryption (ESP) - and
parameters configured in the Security Association for the tunnel.
There is no dependency or interaction between the security level and
mechanisms applied to the tunnel packets and the security applied to
the original packets which are the payloads of the tunnel packets.
In case of nested tunnels, each inner tunnel may have its own set of
security services, independently from those of the outer tunnels, or
of those between the source and destination of the original packet.
Conta Expires in six months [Page 11]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 November 22, 19100
10. Acknowledgments
Thanks to Erik Nordmark, and Brian Zill for their
comments/suggestions.
Conta Expires in six months [Page 12]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 November 22, 19100
11. References
[IPv6-Tunnel] Conta, A. and Deering, S. "Generic Packet Tunneling in
IPv6 Specification", RFC 2473 December 1998
[IPv6-Spec] Deering, S. and R. Hinden, "Internet Protocol Version 6
(IPv6) Specification", RFC 2460, December 1998
[ICMP-Spec] Conta, A., and S. Deering "Internet Control Message
Protocol for the Internet Protocol Version 6 (IPv6)", RFC 2463,
December 1998.
[ND-Spec] Narten, T., Nordmark, E., and W. Simpson "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[PMTU-Spec] McCann, J., Deering S., J. Mogul "Path MTU Discovery for
IP Version 6 (IPv6)" , RFC-1981
[IPsec-Arch] R. Atkinson, "Security Architecture for the Internet
Protocol",
RFC 2401, November 1998.
[IPsec-Auth] R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[IPsec-Encr] R. Atkinson, "IP Encapsulation Security Payload (ESP)",
RFC 2406, November 1998.
[RFC-1853] Simpson,W., "IP in IP Tunneling", RFC 1853, October 1995.
[Assign-Nr] J. Reynolds, J. Postel, "Assigned Numbers",RFC 2200
10/20/1994
[RFC2119] S. Bradner "Key words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Conta Expires in six months [Page 13]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 November 22, 19100
Authors' Addresses:
Alex Conta
Transwitch Corporation
3 Enterprise Drive
Shelton, CT 06903
+1-203-929-8810
email: aconta@txc.com
Conta Expires in six months [Page 14]
826