Network Working Group A. Conta (Digital Equipment Corporation) INTERNET-DRAFT S. Deering (Xerox PARC) November 1995 Generic Packet Tunneling in IPv6 Specification draft-ietf-ipngwg-ipv6-tunnel-00.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 mechanisms for IPv6 tunneling of various Internet or lower layer protocol packets, such as IPv6, IPv4, AppleTalk, IPX, etc. Conta & Deering Expires in six months [Page 1] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 Table of Contents Status of this Memo.................................1 Table of Contents...................................2 1. Introduction........................................3 2. Terminology.........................................3 3. IPv6 Tunneling......................................6 3.1 IPv6 Encapsulation.............................8 3.2 IPv6 Decapsulation.............................9 3.3 IPv6 Tunnel Protocol Engine...................10 4. Recursive Encapsulation............................12 4.1 Limiting Recursive Encapsulation.............12 4.1.1 Tunnel Encapsulation Limit.............13 4.1.2 Loopback Recursive Encapsulation.......14 4.1.3 Routing Loop Recursive Encapsulation...15 5. Tunnel IPv6 Header.................................16 5.1 Tunnel IPv6 Extension Headers.................17 6. IPv6 Tunnel State Variables........................19 6.1 IPv6 Tunnel Entry-Point Node..................19 6.2 IPv6 Tunnel Exit-Point Node...................19 6.3 IPv6 Tunnel Hop Limit.........................20 6.4 IPv6 Tunnel Packet Priority...................20 6.5 IPv6 Tunnel Flow Label........................21 6.6 IPv6 Tunnel Encapsulation Limit...............21 6.7 IPv6 Tunnel MTU...............................21 7. IPv6 Tunnel Error Reporting and Processing.........23 7.1 Tunnel ICMP Messages..........................25 7.2 ICMP Messages for IPv6 Original Packets.......26 7.3 ICMP Messages for IPv4 Original Packets.......27 8. Open Issues........................................28 9. References.........................................28 10. Acknowledgements..................................29 11. Security Considerations...........................29 Authors' Addresses....................................30 Fig. 1.................................................7 Fig. 2.................................................8 Fig. 3.................................................8 Fig. 4.................................................9 Fig. 5................................................10 Fig. 6................................................12 Fig. 7................................................23 Fig. 8................................................25 Conta & Deering Expires in six months [Page 2] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 1. Introduction This document specifies a method and generic mechanisms by which a packet may be encapsulated and carried as payload within an IPv6 packet. The technique of encapsulating packets within IPv6 packets, called also tunneling in IPv6, is recommended for use in various cases of communications. Such a case is when a node, that is not the source node of a packet, wishes to exert explicit routing control over the packet - such as causing the packet to be forwarded to a particular destination on the way to the final destination identified in the original header. The control is exerted by prepending to the packet a new IPv6 header, with a new source and destination address (see section 3.1). The tunnel IPv6 packet is forwarded to the tunnel IPv6 header destination 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 of this document describe generic mechanisms for IPv6 tunneling that apply to tunneling of various Internet or lower layer protocol packets. section 7.2, and 7.3 are an exception; they describe a specific IPv6 tunneling mechanism for IPv6 packets and respectively IPv4 packets. 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; Conta & Deering Expires in six months [Page 3] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 X.25, Frame Relay, or ATM networks; and internet (or higher) layer "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. original packet an Internet or lower layer packet that undergoes encapsulation in a tunnel packet. original header the header of an original packet. tunnel a virtual link between two nodes, on which an Internet or lower layer protocol packet travels after the entry-point node encapsulates that packet in a tunnel protocol packet. Conta & Deering Expires in six months [Page 4] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 tunnel header the header prepended to the original packet during encapsulation. It specifies the tunnel end-points as source and destination. tunnel packet an original packet encapsulated by prepending tunnel header(s) to the original header(s). tunnel 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. 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. tunnel MTU the Path MTU in the tunnel, i.e. between the tunnel entry-point node and the tunnel exit-point node. tunnel hop limit the maximum number of hops that a tunnel packet is allowed to travel in a tunnel, i.e. between the tunnel entry-point node and the tunnel exit-point node. inner tunnel a tunnel which serves as one (virtual) hop in another tunnel. outer tunnel a tunnel in which one or more hops are themselves tunnels. Conta & Deering Expires in six months [Page 5] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 recursive tunnel IPv6 packet 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. 3. IPv6 Tunneling Tunneling in IPv6 is a technique which consists in establishing a "virtual link" between two IPv6 nodes and using that "link" for transmitting data packets. The two IPv6 nodes view the IPv6 "virtual link", also called an "IPv6 tunnel", as a "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 protocol packet. The two IPv6 nodes which are at the two ends of the IPv6 tunnel, the IPv6 tunnel entry point node and the IPv6 tunnel exit point node play specific roles: The tunnel entry-point node encapsulates an original packet within an IPv6 packet by prepending an IPv6 header (and optionally a set of IPv6 extension headers) to the original packet and then transmits the resulting tunnel packet towards the tunnel exit-point node. The tunnel headers (IPv6 header and IPv6 extension headers) are used to control the packet's processing (forwarding) through the tunnel (see section 3.1). The tunnel exit-point node decapsulates a tunnel packet and then it processes further the resulting original packet like any original packet (see section 3.2). Conta & Deering Expires in six months [Page 6] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 A tunnel entry point node can be seen as an original packet source - the source of the IPv6 tunnel packet is the tunnel entry point node. An IPv6 tunnel main header 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 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 of the IPv6 tunnel packet is the tunnel exit-point node. The tunnel exit point node processes the IPv6 main header and its extension headers, if any, of an IPv6 tunnel packet destined to it similarly to processing the IPv6 headers of an original packet destined to it. 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 An IPv6 tunnel is a unidirectional mechanism - tunnel packet flow takes place in one direction between the IPv6 tunnel entry point node and exit point node (see Fig. 1). 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. Conta & Deering Expires in six months [Page 7] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 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. Bidirectional tunneling mechanism effect 3.1 IPv6 Encapsulation The IPv6 encapsulation of a packet consists in prepending to the original packet, an IPv6 header and optionally a set of IPv6 extension headers, called tunnel IPv6 headers, as graphically shown below in Fig. 3: +----------------------------------//-----+ | Original | | | | Original Packet Payload | | Headers | | +----------------------------------//-----+ < Original packet > | v < Original Packet > +---------+ - - - - - +-------------------------//--------------+ | IPv6 | IPv6 | | | | Extension | Original Packet | | Header | Headers | | +---------+ - - - - - +-------------------------//--------------+ < Tunnel IPv6 packet > Fig. 3. Encapsulating a packet Conta & Deering Expires in six months [Page 8] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 The IPv6 encapsulation takes place in an IPv6 tunnel entry-point node, when transmitting an original packet through the tunnel that begins at that entry-point node. If the transmitting of the original packet through the tunnel is the result of a forwarding operation, the original packet header is processed before encapsulation according to the forwarding rules. For instance if the original packet is an: (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: +---------+- - - - - -+----------------------------------//-----+ | IPv6 | IPv6 | | | | Extension | Original Packet | | Headers | Headers | | +---------+- - - - - -+----------------------------------//-----+ < Tunnel IPv6 packet > | v +----------------------------------//-----+ | Original | | | | Original Packet Payload | | Headers | | +----------------------------------//-----+ < Original packet > Fig. 4. Decapsulating a packet from the tunnel IPv6 headers The IPv6 protocol layer of a tunnel exit-point node receiving an IPv6 packet destined to one of the node's IPv6 addresses processes the packet according to the IPv6 protocol. A 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 a tunnel packet. Upon the completion of the IPv6 protocol layer processing of a tunnel packet, control is given to the Tunnel Conta & Deering Expires in six months [Page 9] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 Protocol layer. The Tunnel Protocol layer discards the tunnel headers and passes the resulting original packet to the Internet or lower layer protocol for further processing - for Next Header value 41, the resulting original packet is passed to the IPv6 protocol layer. 3.3 IPv6 Tunnel Protocol Engine The packet flow through the IPv6 Tunnel Protocol Engine is graphically shown below in Fig. 5: +-----------------------+ +-----------------------------------+ | Upper Layer Protocols | | IPv6 Tunnel Upper-Layer | | | | | | | | ---<-------------------<------- | | | | | ---->---|------>--------- | | | | | | | | | | | | +-----------------------+ +-----------------------+ | | | | | | | | | | | | v ^ | v ^ v ^ v ^ v ^ Tunnel | | | | | | | | | | | | packets| | | | +---------------------------------------------+ | | | | | | | | | / / | | | | D E | | v ^ IPv6 | --<-3--/-/--<---- | | | | E N | | | | Layer ---->-4-/-/--->-- | | | | | C C | | v ^ / / | | | | | | A A | | | | 2 1 | | | | | | P P | | v ^ -----<---5---/-/-<---- v ^ v ^ | | S S | | | | | -->---6---/-/-->-- | | | | | | | U U | | v ^ | | / / 6 5 4 3 8 7 | | L L | | | | | | / / | | | | | | | | A A | | v ^ v ^ / / v ^ | | | | | | T T | +---------------------------------------------+ | E E | | | | | | | | | | | | | | | | | v ^ v ^ v ^ v ^ v ^ v ^ Original| | | | | | | | | | | | | | | | packets | v ^ | +-----------------------+ +-----------------------+ | | | | | | | | | | | | | | | | | | | ---|----|-------<-------- | | | | | --->--------------->------>---- | | | | | | Link Layer Protocols | | IPv6 Tunnel Link Layer | +-----------------------+ +-----------------------------------+ Fig. 5. Packet Flow - IPv6 Tunneling Protocol Engine The "tunnel-layer" acts as both an "upper-layer" and a "link layer": Conta & Deering Expires in six months [Page 10] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 (a) The "tunnel upper-layer" has as "input" tunnel IPv6 packets which are going to be decapsulated. The tunnel packets are incoming through the IPv6 layer from a link-layer - (path #1 in Fig. 5) - or from a tunneling link-layer (the exit-point node of an inner tunnel coincides with the exit-point node of an outer tunnel) - (path #7 in Fig. 5). The resulting original packets are passed back to the IPv6 layer as "tunnel link- layer" output for further processing - see (d). (b) The "tunnel upper-layer" has as "output" tunnel IPv6 packets resulting from encapsulation of original packets - see (c) - or packets resulted from previous encapsulations - when this node is an entry-point to an outer tunnel and to an inner tunnel. The "output" tunnel packets are passed through the IPv6 layer down to a link-layer for transmission - (path #2 Fig. 5) - or to a tunnel link-layer for another encapsulation (the entry- point node in an inner tunnel coincides with the entry-point node in an outer tunnel) - (path #8 in Fig. 5). Implementation Note: the "tunnel upper-layer" input and output may be implemented similar to the other upper layer protocols input and output. (c) The "tunnel link-layer" has as "input" original IPv6 packets which are going to be encapsulated. The original packets are incoming through the IPv6 layer from an upper-layer (original packets originated on this node) - (path #4 in Fig. 5) - or from a link layer (original packets originated on a different node) - (path #6 in Fig. 5). The resulting tunnel packets are passed through the IPv6 layer down to a link-layer for transmission - see (b). (d) The "tunnel link-layer" has as "output" original IPv6 packets resulting from decapsulation - see (a) - which are passed through the IPv6 layer up to an upper-layer (the original packet is destined to this node) - (path #3 in Fig. 5) - or down to a link-layer (the original packet is destined to another node, so it is forwarded) - (path #5 in Fig. 5). Implementation Note: the "IPv6 tunnel link layer" input and output may be implemented similar to other link layer protocols input and output, for instance by associating an interface or pseudo- Conta & Deering Expires in six months [Page 11] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 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. 4. Recursive Encapsulation Recursive IPv6 encapsulation takes place when portions of an IPv6 tunnel are IPv6 tunnels themselves, i.e. a tunnel contains inner tunnels - see Fig. 6. The entry-point node of an "inner IPv6 tunnel" may receive and encapsulate packets that are tunnel IPv6 packets encapsulated at an "outer IPv6 tunnel" entry-point node. These packets are original packets for the "inner IPv6 tunnel" entry-point node, the result of their encapsulation at 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 IPv6 tunnel". Outer Tunnel <-------------------------------------> <--------------> Inner Tunnel Outer Tunnel Outer Tunnel Entry-Point Exit-Point Node Node +-+ +-+ +-+ +-+ +-+ +-+ | | | | | | | | | | | | | |->-//->-| |=>=//=>=| |**>**//**>**| |=>=//=>==| |->-//-->-| | | | | | | | | | | | | | +-+ +-+ +-+ +-+ +-+ +-+ Original Inner Tunnel Inner Tunnel Original Packet Entry-Point Exit-Point Packet Source Node Node Destination Node Node Fig. 6. Recursive Encapsulation 4.1 Limiting Recursive Encapsulation There is a practical limit on how many "inner IPv6 tunnels" an "outer IPv6 tunnel" may have which results from the maximum number of possible IPv6 encapsulations of a packet. Conta & Deering Expires in six months [Page 12] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 Each encapsulation adds to the size of a tunnel packet the size of the tunnel IPv6 headers. Consequently, in the case of inner tunnels, the number of recursive encapsulations is practically limited by the number of tunnel IPv6 headers that can be prepended to the original packet before the resulting tunnel packet reaches the maximum IPv6 datagram size [IPv6]. The increase in the size of a tunnel IPv6 packet due to repeated recursive encapsulation may require fragmentation at a tunnel entry point node [IPv6] - see section 6.7. Each next recursive encapsulation of a tunnel IPv6 fragment may result in a new fragmentation and thus the addition of one more fragment to the previous existing fragments. Therefore, it is highly probable that once the fragmentation of a tunnel IPv6 packet was triggered, each next recursive encapsulation may result in additional fragmentation, and thus IPv6 fragment multiplication. Therefore, it is recommended to keep recursive encapsulation to a minimum. The proposed mechanism for controlling excessive recursive encapsulation is a "tunnel encapsulation limit" that 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 nodes, it is discarded only by tunnel exit-point nodes, and it is used to carry optional information [IPv6] that need be examined only by tunnel entry-point nodes. It is defined according to [IPv6] as follows: Option Type Opt Data Len Tun Encap Lim 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 1 0 0| 1 | u_8int | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type decimal value 4 - the highest-order two bits - set to 00 - specify "skip over this option if the option is not recognized". The third-highest-order bit - set to 0 - specifies that the option data in this option does not change en-route to the packet's destination [IPv6]. Conta & Deering Expires in six months [Page 13] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 Opt Data Len 1 - the data portion of the Option is one byte long. Tun Encap Lim the Tunnel Encapsulation Limit - 8-bit unsigned integer (u_8int). To avoid excessive recursive encapsulation, an IPv6 tunnel entry- point node may prepend, as part of the IPv6 tunnel headers, a "Tunnel Encapsulation Limit - Destination Extension Header" - with the "Tun Encap Lim - tunnel encapsulation limit" - 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 "Tunnel Encapsulation Limit" header, the value is copied into the newly prepended "Tunnel Encapsulation Limit" header and then decremented by one. This is an exception from the rule of processing destination extension headers, in that although the entry- point node is not a destination node, during the encapsulation of a packet, the IPv6 tunneling protocol engine looks ahead 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 dicarding the packet, a Parameter Problem ICMP message [IPv6ICMP] is returned to the packet originator - the Parameter Problem ICMP message points into the Tunnel Encapsulation Limit destination header of the packet, to the Tun Encap Lim field, which has the value 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 node encapsulates tunnel IPv6 packets originated from itself, and destined Conta & Deering Expires in six months [Page 14] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 to itself. This may generate an infinite processing loop in the 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 that have the pair of tunnel entry-point and exit-point addresses 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 is recommended that the validation be done at tunnel configuration time: a node should not permit configuring tunnels where both the entry-point node and exit-point node addresses belong to the entry-point node. 4.1.3 Routing Loop Recursive Encapsulation In case of a packet path involving mulitple levels of inner tunnels, a routing loop from an inner tunnel to an outer tunnel is particularly dangerous when the loop is such that a tunnel IPv6 packet encapsulated at a certain tunnel entry-point node reaches again that tunnel entry-point node before reaching that tunnel exit- point node. Because there is no relationship between the tunnel IPv6 header 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 the tunnel IPv6 headers adds to the size of the packets, a tunnel packet may grow to the maximum packet size limit [IPv6], resulting in tunnel packet fragmentation, and fragment multiplication. When the path of a packet from source to final destination includes tunnels, the maximum number of hops that the packet can traverse is controlled by: (a) the original IPv6 packet hop limit, at each forwarding operation performed on the orirginal packet, including at the points where it is encapsulated and decapsulated. (b) the tunnel IPv6 packet encapsulation limit, at each recursive encapsulation of the packet. The two mechanisms mentioned above are used together to avoid the negative effects of routing loops in tunnels. Conta & Deering Expires in six months [Page 15] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 5. Tunnel IPv6 Header The tunnel entry point node fills out a tunnel IPv6 main header [IPv6] as follows: Version: 6 Priority: Depending on the entry-point node tunnel configuration, the priority may be set to that of the original packet, or to a pre-configured value - see section 6.3. Flow label: Depending on the entry-point node tunnel configuration, the flow label may be set to a pre-configured value. The tipical value is zero - see section 6.4. Payload Length: The original packet length. In case the packet is prepended with tunnel IPv6 extension headers, this value is set to the original packet length plus the length of the encapsulating IPv6 extension headers. Next header: The next header value according to [IPv6] from the Assigned Numbers RFC [RFC-1700]. If the original packet is an IPv6 packet, and there are no intermediate headers, 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 the tunnel IPv6 header, then the next header protocol value in this field is set to 0 (Assigned payload type number for IPv6 Hop by Hop Options header). If a Tunnel Encapsulation Limit destination option header is Conta & Deering Expires in six months [Page 16] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 immediately following the tunnel IPv6 header, then the next header protocol value in this field is set to 60 (Assigned payload type number for IPv6 Destination Options header). Hop limit: The tunnel IPv6 header hop limit is set to a 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: IPv6 address of the outgoing interface of the tunnel entry- point node. This address is configured as 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 the IPv6 address of the destination from the original IPv6 header - see section 6.2. 5.1 Tunnel IPv6 Extension Headers Depending on various IPv6 node configuration parameters a tunnel entry-point node may append to the tunnel IPv6 main header, one or more IPv6 extension headers that are not directly related 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, a Tunnel Encapsulation Limit destination option header with fields set as follows: Conta & Deering Expires in six months [Page 17] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header |Hdr Ext Len = 0| Opt Type = 4 |Opt Data Len=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tun Encap Lim |PadN Opt Type=1|Opt Data Len=1 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header: Identifies the type of header immediately following the Tunnel Encapsulation Limit destination option header [IPv6]. If the original packet is an IPv6 packet, 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: Conta & Deering Expires in six months [Page 18] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 One zero-valued octet. 6. IPv6 Tunnel State Variables The IPv6 tunnel state variables, some of which are or may be configured, are: (a) the tunnel entry-point node address - is configured (b) the tunnel exit-point node address - is configured (c) the tunnel hop limit - is configured (d) the tunnel packet priority - is configured (e) the tunnel packet flow label - is configured (f) the tunnel encapsulation limit - may be configured (g) the tunnel MTU 6.1 IPv6 Tunnel Entry-Point Node Address The tunnel entry-point node address is one of the valid IPv6 unicast addresses belonging to the entry-point node - it is recommended to validate the address at configuration time. The tunnel entry-point node address is copied to the 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 used as the IPv6 destination address for the tunnel IPv6 header. The tunnel exit-point node address may be configured with a specific IPv6 address, in which case the tunnel acts like a virtual point to point link between the entry-point node and exit-point node, or with the unspecified IPv6 address, in which case the tunnel acts like a virtual multi-point link, between the entry-point node and many exit-point nodes, in which case the destination address from each original packet header Conta & Deering Expires in six months [Page 19] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 is used as tunnel IPv6 exit-point node for encapsulating that packet. The tunnel exit-point node address is copied to the destination address field in the tunnel IPv6 header during packet encapsulation. 6.3 IPv6 Tunnel Hop Limit An IPv6 tunnel is modeled as a "single-hop virtual link" tunnel, in which regardless of the number of hops in the IPv6 tunnel, the original packet's passing through the tunnel is like the original packet's passing over a one hop link. The "single-hop" mechanism should be implemented by having the tunnel entry point node set a tunnel IPv6 header hop limit independently of the original headers. The "single-hop" mechanism hides to the original IPv6 packets the IPv6 topology of the tunnel. The tunnel hop limit is configured into the tunnel entry-point node with a value that: (a) ensures that tunnel IPv6 packets reach the tunnel exit- point node (b) ensures a quick expiration of the tunnel packet if a routing loop occurs within the IPv6 tunnel. The tunnel hop limit default value for hosts is the neighbor discovery advertised hop limit [IPv6ND]. The tunnel hop limit default value for routers is the default IPv6 Hop Limit [TBD] value from the Assigned Numbers RFC. The tunnel hop limit is copied into the hop limit field of the tunnel IPv6 header of each packet encapsulated by the tunnel entry-point node. 6.4 IPv6 Tunnel Packet Priority The IPv6 Tunnel Packet Priority indicates the value that a tunnel entry-point node sets in the priority field of a tunnel header. The default value is zero. The Packet Priority may also indicate whether the value of the priority field in the tunnel header is copied from the original header, or it is set to the configured value. Conta & Deering Expires in six months [Page 20] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 6.5 IPv6 Tunnel Flow Label The IPv6 Tunnel Flow Label indicates the value that a tunnel entry- 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. An entry-point node configured to limit the number of encapsulations, prepends 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 to the Path MTU of the tunnel - the maximum size of a packet that can be sent through the tunnel without fragmentation - see [IPv6]. The tunnel entry point node performs Path MTU discovery on the tunnel [IPv6PMTU], [IPv6ICMP]. The tunnel's entry-point - the encapsulating node - should be able to send an encapsulated IPv6 packet of any valid size over an IPv6 tunnel. If the tunnel entry-point node determines that a packet does not exceed the tunnel MTU after encapsulation, then the tunnel entry- point node encapsulates and sends that packet. If the tunnel entry-point node determines that a packet exceeds the tunnel MTU after encapsulation, then the tunnel entry-point node does one of the following depending on the size of the original packet: (a) if the original packet is larger than 576 octets then the entry-point node returns an ICMP "packet too big" message to the packet originator. The IPv6 node source of the original IPv6 packet resizes - makes packets of smaller size - and retransmits the resulting smaller packets. Conta & Deering Expires in six months [Page 21] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 (b) if the original packet is equal or smaller than 576 octets then the tunnel entry-point node, after encapsulating the original packet, breaks the tunnel packet into fragments that do not exceed the tunnel MTU. The IPv6 packet encapsulation is considered an IPv6 packet originating operation, therefore an IPv6 node that is an IPv6 tunnel entry-point must support fragmentation to encapsulate a packet of any size. A tunnel packet being forwarded follows, like any IPv6 packet, the rule that it must not be fragmented by any IPv6 node other than the originating node - the tunnel entry-point node. 7. IPv6 Tunnel Error Processing and Reporting IPv6 Tunneling follows the general rule that errors detected during the processing of IPv6 packets are reported to the packet originator through 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. For errors detected by nodes inside an IPv6 tunnel, ICMP error messages are sent to the tunnel IPv6 packet source node, which is the IPv6 tunnel entry-point node. The ICMP messages sent to the tunnel entry-point node have as ICMP payload the tunnel IPv6 packet that includes the original packet. The cause of an error uncovered inside a tunnel can be: (a) the tunnel header, or (b) the tunnel packet. The tunnel header problems are of concern to the tunnel entry-point node which is the tunnel IPv6 packet originator. The tunnel packet problems that result from bad encapsulation, are of concern also to the tunnel entry-point node. If the tunnel packet problems are a consequence of an original packet problem and if they can be corrected by the original packet Conta & Deering Expires in six months [Page 22] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 originator, then they must be reported to both the tunnel entry-point node and the original packet originator. To report to the original packet originator a problem detected inside the tunnel and reported from inside the tunnel through an ICMP message, the tunnel entry-point node must relay the ICMP message to the original IPv6 packet originator. To relay the ICMP message, the IPv6 tunnel entry-point node builds and sends an ICMP message to the original packet originator, based on the tunnel ICMP message, as it is graphically described below: +-------+ +-------+ +-----------------------+ | Upper | | Upper | | Upper | | Layer | | Layer | | Layer | | Prot. | | Prot. | | IPv6 Tunnel | | Error | | Error | | Error | | Input | | Input | | Input | | | | | | Decapsulate | | | | | | -->--ICMPv6--#2->-- | | | | | | | Payload | | +-------+ +-------+ +--|-----------------|--+ | | | | ^ ^ ^ v | | | | --------------------#1-- -----Orig.Packet?--- - - - - - - - - - error code, | #3 error code, | | ICMPv6 payload ^ v source address, v v | IPv6 | orig. packet | IPv4 | +--------------+ +--------------+ +--------------+ + - - - - + | | | | | | | ICMP v6 | | ICMP v6 | | ICMP v4 | | | | Input | | Error Report | | Error Report | | - - - - +----+ - - - - | + - - - - + + - - - - + | | | | | IPv6 Layer | | IPv4 Layer | | | | | | | +----------------------------------+ +--------------+ + - - - - + Fig. 7. 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 ICMP message to the ICMPv6 Input. The ICMPv6 Input, based on the ICMP type and code [IPv6ICMP] generates an internal "error code" which is passed with the "ICMPv6 message payload" to the upper layer protocol - in this case the IPv6 tunnel upper layer - error input (path #1 in Fig. 7, and (a) in Fig. 8). Conta & Deering Expires in six months [Page 23] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 The IPv6 tunnel error input decapsulates the tunnel IPv6 packet, which is the ICMPv6 message payload, obtaining the original packet, and thus the original headers - path #2 in Fig. 7 and (b) in Fig. 8 - and dispatches the "error code", the source address from the original packet header, and the original packet, down to the error report block of the protocol identified by the Next Header field in the tunnel header immediately preceding the original packet in the ICMP message payload - in this example ICMPv6. The ICMPv6 error report builds an ICMP message of a type and code according to the "error code", containing the "original packet" as ICMP payload - - path #3 in Fig. 7 and (c) in Fig. 8. The ICMP message has the tunnel entry- point node address as source address, and the original packet source node address as destination address - (d) in Fig. 8. The tunnel entry point node sends the ICMP message to the original packet originator node. A graphical description of the header processing taking place is the following: < Tunnel packet > +--------+- - - - - -+--------+------------------------------//------+ | IPv6 | IPv6 | ICMP | Tunnel | (a)| | Extension | | IPv6 | | Header | Headers | Header | Packet in error | +--------+- - - - - -+--------+------------------------------//------+ < Tunnel headers > < 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 | +--------+ +---------+ +----------+--------//------+ | | ----------------- | | ----------|--------------- | | V V +---------+ +--------+ +-------------------//------+ | New | | ICMP | | | (c) | IPv6 | -> | | -> | Orig. IPv6 packet in error| | Headers | | Header | | | +---------+ +--------+ +-------------------//------+ | Conta & Deering Expires in six months [Page 24] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 v +---------+--------+-------------------//------+ | New | ICMP | Original | (d) | IPv6 | | IPv6 | | Headers | Header | packet in error | +---------+--------+-------------------//------+ < new ICMP message > Fig. 8. ICMP Error reporting and processing 7.1 Tunnel ICMP Messages The tunnel ICMP messages which are reported to the original packet originator are: hop limit exceeded The tunnel is misconfigured, or contains a routing loop, and packets do not reach the tunnel exit-point node. This problem is of concern to the tunnel entry point node - the tunnel hop limit must be reconfigured - and also to the original IPv6 packet originator. unreachable node One of the nodes in the tunnel is not or is no longer reachable. This is a problem of concern to the tunnel entry-point node, which should reconfigure the tunnel with a valid and active path between the entry and exit-point of the tunnel. parameter problem A Parameter Problem ICMP message pointing to a valid Tunnel Encapsulation Limit Destination header with a 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 IPv6 packet originator, as a tunnel generic "unreachable" problem caused by a "link problem" - see section 7.2 Conta & Deering Expires in six months [Page 25] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 and 7.3. packet too big The tunnel packet exceeds the tunnel Path MTU. The original packet originator is notified - see section 6.3. If the original packet is an IPv6 packet, the ICMP message sent to the packet originator has the same ICMP type/code as the ICMP message sent from inside the tunnel to the tunnel entry-point node - see section 7.2, and 7.3. This ICMP message is used by the tunnel entry point node to determine the tunnel MTU. 7.2 ICMP Messages for IPv6 Original Packets The tunnel entry-point node builds the ICMP and IPv6 headers of the new ICMP message as follows: IPv6 Fields: Source Address A valid unicast IPv6 address of the outgoing interface. Destination Address Copied from the Source Address field of the Original IPv6 header. ICMP Fields: For tunnel ICMP error message "hop limit exceeded", or "unreachable node", or "parameter problem" pointing to a valid Tunnel Enacpsulation Limit destination header with the Tun Encap Lim field set to a value one: Conta & Deering Expires in six months [Page 26] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 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. 7.3 ICMP Messages for IPv4 Original Packets The tunnel entry-point node builds the ICMP and IPv4 header of the new ICMP message as follows: IPv4 Fields: Source Address A valid unicast IPv4 address of the outgoing interface. Destination Address Copied from the Source Address field of the Original IPv4 header. ICMP Fields: For tunnel ICMP error message "hop limit exceeded", or "unreachable node", or "parameter problem" pointing to a valid Tunnel Enacpsulation Limit destination header with the Tun Encap Lim field set to a value one: Conta & Deering Expires in six months [Page 27] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 Type 3 - destination unreachable Code 1 - host unreachable For tunnel ICMP error message "packet too big": Type 3 - destination unreachable Code 4 - datagram too big MTU The MTU field from the tunnel ICMP message minus the length of the tunnel headers. 8. Open Issues Open issues are: (a) Multicast exit point Does it make sense to have an IPv6 multicast address as tunnel exit-point node address? (b) Anycast exit point Does it make sense to have an IPv6 anycast address as tunnel exit-point node address? (c) Tunnel default hop limit value 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. 9. References [IPv6]S. Deering, R. Hinden, "Internet Protocol Version 6 Specification" [IPv6ICMP] Conta & Deering Expires in six months [Page 28] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 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" [RFC-1700] J. Reynolds, J. Postel, "Assigned Numbers", 10/20/1994 10.Acknowledgements The document 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 an IPv6 tunneling focused IPng Working Group session at the 33th IETF, in Stockholm, July 1995. Additionally, several documents focused on tunneling or encapsulation were used as a reference: "Transition Mechanisms for 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 the reviewers of this document: [TBD] 11.Security Considerations Security considerations are not discussed in this memo. Conta & Deering Expires in six months [Page 29] INTERNET-DRAFT Tunneling in IPv6 November 22, 1995 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