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