One document matched: draft-conta-extensions-ipv6-tunnel-00.txt
IPng Working Group A. Conta (Transwitch)
INTERNET-DRAFT
July 2000
Generic Packet Tunneling in IPv6 - Bi-directional Tunneling
Specification
draft-conta-extensions-ipv6-tunnel-00.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.
Copnta Expires in six months [Page 1]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 July 14, 19100
Table of Contents
Status of this Memo...........................................1
Table of Contents.............................................2
Terminology...................................................5
1. Introduction..................................................4
2. Uni-DIrectional, and Bi-Directional Tunnels...................4
3. IPv6 Tunnel Type State Variables..............................7
3.1 IPv6 Tunnel Type -- Uni-Directional.......................8
3.2 IPv6 Tunnel Type -- Bi-Directional........................8
3.2.1 IPv6 Tunnel Type -- Symmetric Bi-Directional............9
4. Security Considerations......................................10
5. Acknowledgments..............................................11
6. References...................................................12
Author's Address................................................13
Fig.1.................................................6
Fig.2.................................................7
Copnta Expires in six months [Page 2]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 July 14, 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
synonim for the tunnel entry-point node [IPv6-Tunnel]
tunnel exit
synonim for the tunnel exit-point node [IPv6-Tunnel]
Copnta Expires in six months [Page 3]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 July 14, 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 transmiited onto the physical
Copnta Expires in six months [Page 4]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 July 14, 19100
interface. In the latter case, the tunnel is a nested tunnel:
tunnel packets will be encapsulated in tunnel packets, but
uiltimately will be transmiited on the physical interface [IPv6-
Tunnel].
o The tunnel interface has an attached routing table entry, that
determines the redirection of IP packets onto the "parent"
interface, which ultimately is a physical interface.
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-direcional 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 muast be
toggled onto the "enable" position.
These basic configuration operations affect 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. Packets transmiited in reverse direction, from the exit-
point node to the entry-point node are not tunneled. This is giving
the tunnel the characteristic of a "uni-directional" mechanism. For
instancfe in Fig.1, Node B sio the entry-point node in the tunnel,
and node C is the exit-point from the tunnel, and the tunnel traffic
Copnta Expires in six months [Page 5]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 July 14, 19100
flows in one direcion 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.
Copnta Expires in six months [Page 6]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 July 14, 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. 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.
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
Copnta Expires in six months [Page 7]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 July 14, 19100
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-direcional"
3.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 the tunnel packet decaspulating.
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.
3.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
end exit.
Copnta Expires in six months [Page 8]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 July 14, 19100
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
MUST be considered if Neighbor Discovery [ND-Spec] mechanisms are to
be used.
3..2.1 IPv6 Tunnel Type -- Symmetric Bi-Directional
A "symmetric bi-directional" tunnel is a bi-direcional 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.
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 identcal with reverted direct path. The bi-
directional and symmetrical characetristics MUST be considered if
Neighbor Discovery [ND-Spec] mechanisms are to be used.
Copnta Expires in six months [Page 9]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 July 14, 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.
Copnta Expires in six months [Page 10]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 July 14, 19100
10. Acknowledgments
TBD
Copnta Expires in six months [Page 11]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 July 14, 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.
Copnta Expires in six months [Page 12]
INTERNET-DRAFT Bi-Directional Tunneling in IPv6 July 14, 19100
Authors' Addresses:
Alex Conta
Transwitch Corporation
3 Enterprise Drive
Shelton, CT 06903
+1-203-929-8810
email: aconta@txc.com m
Copnta Expires in six months [Page 13]
767
| PAFTECH AB 2003-2026 | 2026-04-24 01:58:23 |