HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 03:47:11 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 23 Feb 1996 23:00:00 GMT ETag: "2f52df-13049-312e46f0" Accept-Ranges: bytes Content-Length: 77897 Connection: close Content-Type: text/plain Network Working Group A. Conta (Digital Equipment Corporation) INTERNET-DRAFT S. Deering (Xerox PARC) February 1996 Generic Packet Tunneling in IPv6 Specification draft-ietf-ipngwg-ipv6-tunnel-01.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 February 22, 1996 Table of Contents Status of this Memo...........................................1 Table of Contents.............................................2 1. Introduction..................................................3 2. Terminology...................................................3 3. Generic IPv6 Tunneling........................................7 3.1 IPv6 Encapsulation.......................................9 3.2 IPv6 Decapsulation......................................10 3.3 IPv6 Tunnel Protocol Engine.............................11 3.4 IPv6 Tunnels and Address Formats........................13 3.5 IPv6 Tunnels and IPv6 Autoconfiguration.................13 3.6 IPv6 Tunnels and IPv6 Neighbor Discovery................13 4. Recursive Encapsulation......................................13 4.1 Limiting Recursive Encapsulation.......................14 4.1.1 Tunnel Encapsulation Limit.......................14 4.1.2 Loopback Recursive Encapsulation.................16 4.1.3 Routing Loop Recursive Encapsulation.............16 4.1.4 Risk Factors in Recursive Encapsulation..........17 5. Generic Tunnel IPv6 Header...................................19 5.1 Tunnel IPv6 Extension Headers...........................21 6. IPv6 Tunnel State Variables..................................23 6.1 IPv6 Tunnel Entry Point Node............................23 6.2 IPv6 Tunnel Exit Point Node.............................23 6.3 IPv6 Tunnel Hop Limit...................................24 6.4 IPv6 Tunnel Packet Priority.............................24 6.5 IPv6 Tunnel Flow Label..................................24 6.6 IPv6 Tunnel Encapsulation Limit.........................25 6.7 IPv6 Tunnel MTU.........................................25 7. IPv6 Tunnel Packet Fragmentation.............................25 7.1 IPv6 Packet Fragmentation...............................26 7.2 IPv4 Packet Fragmentation...............................26 8. IPv6 Tunnel Error Reporting and Processing...................27 8.1 Tunnel ICMP Messages....................................30 8.2 ICMP Messages for IPv6 Original Packets.................31 8.3 ICMP Messages for IPv4 Original Packets.................32 9. Open Issues..................................................33 10. References..................................................34 11. Acknowledgements............................................35 12. Security Considerations.....................................35 Authors' Addresses..............................................35 Appendix A..Inner tunnels.......................................35 Appendix B..Default tunnels.....................................37 Changes from previous version...................................38 Fig. 1.................................................8 Fig. 2.................................................8 Conta & Deering Expires in six months [Page 2] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 Fig. 3.................................................9 Fig. 4................................................10 Fig. 5................................................11 Fig. 6................................................13 Fig. 7................................................28 Fig. 8................................................29 Conta & Deering Expires in six months [Page 3] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 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. and 8. describe specific IPv6 tunneling mechanisms 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; X.25, Frame Relay, or ATM networks; and internet (or higher) layer Conta & Deering Expires in six months [Page 4] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 "tunnels", such as tunnels over IPv4 or IPv6 itself. interface a node's attachment to a link. address an IPv6-layer identifier for an interface or a set of interfaces. packet an IPv6 header plus payload. link MTU the maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed in one piece over a link. path MTU the minimum link MTU of all the links in a path between a source node and a destination node. prefix-net a network of nodes with identical prefix. original packet an Internet or lower layer 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. tunnel header the header prepended to the original packet during encapsulation. It specifies the tunnel end-points as source and destination. Conta & Deering Expires in six months [Page 5] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 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. free-exit tunnel a tunnel that has an unspecified exit-point address (unspecified IPv6 address). fixed-exit tunnel a tunnel that has a specified exit-point address (not the unspecified IPv6 address). 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. recursive tunnel IPv6 packet Conta & Deering Expires in six months [Page 6] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 a tunnel IPv6 packet encapsulated within a tunnel IPv6 packet, by prepending IPv6 tunnel header(s) to previously prepended IPv6 tunnel header(s). recursive encapsulation encapsulation of a tunnel packet, i.e. encapsulation of an encapsulated packet. tunnel encapsulation limit the maximum number of recursive encapsulations of a packet. default tunnel a tunnel which is the preferred link (virtual) to the default router. 3. IPv6 Tunneling Tunneling in IPv6 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: 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 Conta & Deering Expires in six months [Page 7] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 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). 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 Conta & Deering Expires in six months [Page 8] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 A bidirectional tunneling mechanism effect can be achieved by merging two unidirectional mechanisms, by defining two tunnels that are each one in opposite direction to the other - the entry point node of one tunnel is the exit point node of the other tunnel (see Fig. 2). A tunnel entry point node can be the original packet source, and similarly a tunnel exit-point node can be the original packet destination, i.e. the beginning or ending of a tunnel can coincide with the source or destination of an original packet. 3.1 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: 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. The tunnel packet resulted from encapsulation is sent towards the tunnel exit-point node. The tunnel headers are used to control the packet's processing (forwarding) through the tunnel. +----------------------------------//-----+ | 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 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 of the protocol of the original header. For instance if the original packet is an: Conta & Deering Expires in six months [Page 9] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 (a) IPv6 packet, and it is tunneled as result of an IPv6 forwarding operation, the IPv6 original packet hop limit is decremented by one during forwarding. (b) IPv4 packet, and it is tunneled as result of an IPv4 forwarding operation through an IPv6 tunnel, the IPv4 original packet time to live field (TTL) is decremented by one during forwarding. 3.2 IPv6 Decapsulation The decapsulation is graphically shown below in Fig. 4: +---------+- - - - - -+----------------------------------//-----+ | 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 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. Conta & Deering Expires in six months [Page 10] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 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": (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 Conta & Deering Expires in six months [Page 11] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 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- interface with the IPv6 tunnel. The selection of the "IPv6 tunnel link" over other links results from the packet forwarding decision taken based on the content of the node's routing table. Conta & Deering Expires in six months [Page 12] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 3.4 IPv6 Tunnels and Address Formats Although the IPv6 addresses of the two end-nodes of an IPv6 tunnel can be viewed as "virtual link" addresses, they have an IPv6 address format - [RFC-1884]. 3.5 IPv6 Tunnels and IPv6 Autoconfiguration Although the IPv6 addresses of the two end-nodes of an IPv6 tunnel can be viewed as "virtual link" addresses of a pseudo-interface, the IPv6 Autoconfiguration [ADDRCONF] mechanisms do not apply for the pseudo-interface. 3.6 IPv6 Tunnels and IPv6 Neighbor Discovery Although the IPv6 addresses of the two ends of an IPv6 tunnel can be viewed as "virtual link" addresses, the IPv6 Neighbor Discovery mechanisms do not apply. 4. Recursive Encapsulation Recursive IPv6 encapsulation takes place when portions of an IPv6 tunnel are IPv6 tunnels themselves, i.e. a tunnel contains inner tunnels - see Fig. 6. 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 The entry point node of an "inner IPv6 tunnel" may receive and Conta & Deering Expires in six months [Page 13] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 encapsulate packets that are 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". 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. 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 hits the maximum IPv6 datagram size [RFC-1883]. The increase in the size of a tunnel IPv6 packet due to repeated recursive encapsulation may require fragmentation at a tunnel entry point node [RFC-1883] - see section 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 [RFC- 1883] that need be examined only by tunnel entry point nodes. It is defined according to [RFC-1883] as follows: Conta & Deering Expires in six months [Page 14] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 Option Type Opt Data Len Tun Encap Lim 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 [RFC-1883]. 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 discarding the packet, a Parameter Problem ICMP message [RFC-1885] is returned to the packet originator - the Parameter Problem ICMP message points into the Tunnel Encapsulation Limit destination header of the packet, to Conta & Deering Expires in six months [Page 15] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 the Tun Encap Lim field, which has the 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 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 that the pair of tunnel entry point and exit- point addresses are identical with the pair of original packet source address and final destination address, and both the entry point node and exit-point node addresses belong to the entry point node. 4.1.3 Routing Loop Recursive Encapsulation In case of a packet path involving multiple 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 Conta & Deering Expires in six months [Page 16] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 the tunnel IPv6 headers adds to the size of the packets, a tunnel packet may grow to the maximum packet size limit [RFC-1883], 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 two mechanisms that are used together to avoid the negative effects of routing loops in tunnels: (a) the original IPv6 packet hop limit, at each forwarding operation performed on the original 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. 4.1.4 Risk Factors in Recursive Encapsulation The cases which present a high risk of excessive recursive encapsulation are those in which a tunnel entry point node cannot discern between a valid and an invalid recursive encapsulation. Routing loops that cause tunnel packets reach nodes that were already reached before are certainly the major cause of the problem. But since routing loops exist, and happen, it is important to understand and describe, the cases in which the risk for excessive recursive encapsulation is higher. There are two significant elements that determine the risk factor of routing loop excessive recursive encapsulation: (a) the type of tunnel, (b) the type of route to the tunnel exit-point, which determines the packet forwarding through the tunnel, i.e. over the tunnel virtual-link. The type of tunnels which were identified as a high risk factor of excessive recursive encapsulation in routing loops are: "inner tunnels with identical exit-points". These tunnels can be: Conta & Deering Expires in six months [Page 17] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 "fixed-end inner tunnels with different entry-points", or: "free-end inner tunnels with different entry-points" Note that free-end inner tunnels fall always into the category of identical exit-point tunnels. Since the source and destination of an original packet is the main information used to decide whether to forward a packet through a tunnel or not, an excessive recursive encapsulation can be avoided in case of a single tunnel (non-inner), by checking that the packet to be encapsulated was not originated by the entry point node. This mechanism is suggested in [IPv4TUN]. However, this type of protection does not seem to work well in case of inner tunnels with different entry-points, and identical exit- points - see Appendix A. Inner tunnels with different entry-points, and identical exit-points introduce ambiguity in deciding whether to encapsulate or not a packet, when a packet encapsulated in an inner tunnel reaches the entry point node of an outer tunnel by means of a routing loop. Because the source of the tunnel packet is the inner tunnel entry point node which is different than the entry point node of the outer tunnel, the source address checking fails to detect an invalid encapsulation, and as consequence the tunnel packet gets encapsulated at the outer tunnel, each time it reaches it through the routing loop. The type of route to a tunnel exit-point node has been also identified as a high risk factor of excessive recursive encapsulation in routing loops. One type of route to a tunnel exit-point node is a route to a specified destination node, i.e. the destination is a valid specified IPv6 address (route to node). Such a route can be selected based on the longest path match of an original packet destination address with the destination address stored in the tunnel entry point node routing table entry for that route. The packet forwarded on such a route is first encapsulated and then forwarded towards the tunnel exit-point node. Another type of route to a tunnel exit-point node is a route to a specified prefix-net, i.e. the destination is a valid specified IPv6 prefix (route to net). Such a route can be selected based on the longest path match of an original packet destination address with the Conta & Deering Expires in six months [Page 18] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 prefix destination stored in the tunnel entry point node routing table entry for that route. The packet forwarded on such a route is first encapsulated and then forwarded towards the tunnel exit-point node. And finally another type of route to a tunnel exit-point is a default route, or a route to an unspecified destination, i.e. the destination is the "unspecified" IPv6 address. This route is selected when no- other match for the destination of the original packet has been found in the routing table. A tunnel that is the virtual-link of a default route, i.e. the link to a default router, is a "default tunnel". If the route to a tunnel exit-point is a route to node, the risk factor for excessive recursive encapsulation is minimum. If the route to a tunnel exit-point is a route to net, the risk factor for excessive recursive encapsulation is medium. There is a range of destination addresses that will match the prefix the route is associated with. If one or more inner tunnels with different tunnel entry-points have exit-point node addresses that match the route to net of an outer tunnel exit-point, then an excessive recursive encapsulation may occur if a tunnel packet gets diverted from inside such an inner tunnel to the entry point of the outer tunnel that has a route to its exit-point that matches the exit-point of an inner tunnel. If the route to a tunnel exit-point is a default route, the risk factor for excessive recursive encapsulation is maximum. Packets are forwarded through a default tunnel for lack of a better route. In many situations, forwarding through a default tunnel can happen for a wide range of destination addresses which at the maximum extent is the entire Internet minus the node's link. As consequence, it is likely that in a routing loop case, if a tunnel packet gets diverted from an inner tunnel to an outer tunnel entry point in which the tunnel is a default tunnel, the packet will be once more encapsulated, because the default routing mechanism will not be able to discern differently, based on the destination - see Appendix B. 5. Tunnel IPv6 Header The tunnel entry point node fills out a tunnel IPv6 main header [RFC-1883] as follows: Version: Conta & Deering Expires in six months [Page 19] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 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 typical 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 [RFC-1883] from the Assigned Numbers RFC [RFC-1700]. For example, 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 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. Conta & Deering Expires in six months [Page 20] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 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: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Conta & Deering Expires in six months [Page 21] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 Next Header: Identifies the type of header immediately following the Tunnel Encapsulation Limit destination option header [RFC- 1883]. 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: One zero-valued octet. Conta & Deering Expires in six months [Page 22] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 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 - the validation of the address at tunnel configuration time is recommended. 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 [RFC-1884], in which case the tunnel acts like a virtual point to point link between the entry point node and an exit-point node identified by the destination address from the original packet header. The tunnel exit-point node address is copied to the destination address field in the tunnel IPv6 header during packet encapsulation. Conta & Deering Expires in six months [Page 23] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 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. 6.5 IPv6 Tunnel Flow Label The IPv6 Tunnel Flow Label indicates the value that a tunnel entry Conta & Deering Expires in six months [Page 24] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 point node sets in the flow label of a tunnel header. The default value is zero. 6.6 IPv6 Tunnel Encapsulation Limit The IPv6 Tunnel Encapsulation Limit may be configured in an entry point node as the maximum number of encapsulations permitted for original packets entering the tunnel at that entry point node. Recommended default value is 5. 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 [RFC-1883]. The tunnel entry point node performs Path MTU discovery on the tunnel [IPv6PMTU], [RFC-1885]. Although it should be able to send a tunnel IPv6 packet of any valid size, a tunnel entry point node attempts to avoid the fragmentation of tunnel packets, by informing source nodes of original packets the MTU to be used in sizing original packets sent towards that tunnel entry point node. 7. IPv6 Tunnel Packet Fragmentation Although the fragmentation of tunnel packets depends on the protocol of the original packet, the primary condition for fragmentation is the size of the original packet. A tunnel IPv6 packet resulting from the encapsulation of an original packet is considered an IPv6 packet originating from the tunnel entry point node, therefore like any IPv6 packet source node, a tunnel entry point node must support fragmentation of tunnel packets. A node inside the tunnel, that forwards a tunnel packet to another node in the tunnel, follows the general IPv6 rule that it must not fragment a packet undergoing forwarding. Conta & Deering Expires in six months [Page 25] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 Depending on the tunnel packet protocol, the following fragmentation can take place: 7.1 IPv6 Packet Fragmentation The fragmentation of tunnel packets containing IPv6 original packets is performed as follows: (a) if the original packet size is larger than 576 octets, then the entry point node returns an ICMPv6 "Packet Too Big" message to the source node of the original packet indicating the MTU size to be used by that node in sizing original packets sent towards the tunnel entry point. The MTU is the original packet size minus the size of the tunnel headers - see 8.2, and 8.3. (b) if the original packet is equal or smaller than 576 octets then the tunnel entry point node encapsulates the original packet, and after encapsulation it breaks the resulting IPv6 tunnel packet into IPv6 fragments that do not exceed the tunnel MTU. 7.2 IPv4 Packet Fragmentation Although the fragmentation of tunnel packets depends on the protocol of the original packet, the primary condition for fragmentation is the size of the original packet: (a) if the original packet size is larger than 576 octets, and the Don't Fragment - DF - bit in the IPv4 header is set then the entry point node returns an ICMP message with type = "unreachable", code = "datagram too big", and the MTU size to be used by the original node in sizing original packets sent towards the tunnel entry point, which is the original packet MTU minus the size of the tunnel headers - see 8.2, and 8.3. (b) if the original packet is equal or smaller than 576 octets then the tunnel entry point node encapsulates the original packet, and after encapsulation it breaks the resulting Conta & Deering Expires in six months [Page 26] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 IPv6 tunnel packet into IPv6 fragments that do not exceed the tunnel MTU. 8. 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 reported to the tunnel entry point node which is the tunnel IPv6 packet originator. The tunnel packet problems that result from bad encapsulation, are reported 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 source of the original packet, then they must be reported to both the tunnel entry point node and the source of the original packet. To report to the source of original packet 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 source of original IPv6 packet. 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: Conta & Deering Expires in six months [Page 27] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 +-------+ +-------+ +-----------------------+ | 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 [RFC-1885] 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). 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 Conta & Deering Expires in six months [Page 28] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 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 | | | +---------+ +--------+ +-------------------//------+ | v +---------+--------+-------------------//------+ | New | ICMP | Original | (d) | IPv6 | | IPv6 | | Headers | Header | packet in error | +---------+--------+-------------------//------+ < new ICMP message > Fig. 8. ICMP Error reporting and processing Conta & Deering Expires in six months [Page 29] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 8.1 Tunnel ICMP Messages The tunnel ICMP messages which are reported to the original packet originator are: hop limit exceeded The tunnel has a misconfigured hop limit, or contains a routing loop, and packets do not reach the tunnel exit- point node. This problem is reported to the tunnel entry point node - the tunnel hop limit must be reconfigured to a higher value - 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 problem is reported 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 8.2 and 8.3. packet too big The tunnel packet exceeds the tunnel Path MTU. When received, this ICMP message is used by the tunnel entry point node to determine the tunnel MTU. When sent, according to the general rules described in Conta & Deering Expires in six months [Page 30] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 section 7.1, this ICMP message is used by the tunnel entry point node to indicate to an original packet source node that original packets sent from that node to the tunnel entry point node should be resized to the MTU indicated by the ICMP message. 8.2 ICMP Messages for IPv6 Original Packets The tunnel entry point node builds the ICMP and IPv6 headers of the ICMP message that is sent to the original packet source node 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 any of the following tunnel ICMP error messages: hop limit exceeded unreachable node parameter problem pointing to a valid Tunnel Encapsulation Limit destination header with the Tun Encap Lim field set to a value one: Conta & Deering Expires in six months [Page 31] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 Type 1 - unreachable node Code 3 - address unreachable For tunnel ICMP error message "packet too big": Type 2 - packet too big Code 0 MTU The MTU field from the tunnel ICMP message minus the length of the tunnel headers. According to the general rules described in 6.3, an ICMP "packet too big" message is sent to the original packet source node only if the original packet size is larger than 576 octets. If the original packet size is smaller or equal to 576 octets the tunnel entry point encapsulates the original IPv6 packet and then breaks the resulting IPv6 tunnel packet into IPv6 fragments that do not exceed the tunnel MTU. 8.3 ICMP Messages for IPv4 Original Packets The tunnel entry point node builds the ICMP and IPv4 header of the ICMP message that is sent to the original packet source node 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 any of the following tunnel ICMP error messages: Conta & Deering Expires in six months [Page 32] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 hop limit exceeded unreachable node parameter problem pointing to a valid Tunnel Enacpsulation Limit destination header with the Tun Encap Lim field set to a value one: Type 3 - destination unreachable Code 1 - host unreachable For a 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. According to the general rules described in 7.2, an ICMP "datagram too big" message is sent to the original IPv4 packet source node only if the original packet size is larger than 576 octets. An additionally condition that has to be met for sending the ICMP message is that the original IPv4 packet header must have the DF - don't fragment - bit flag set in the IPv6 original header. If the DF bit is clear, the tunnel entry point encapsulates the original IPv4 packet and then breaks the resulting IPv6 tunnel packet into IPv6 fragments that do not exceed the tunnel MTU. 9. 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? Conta & Deering Expires in six months [Page 33] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 (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. 10.References [RFC-1883] S. Deering, R. Hinden, "Internet Protocol Version 6 Specification" [RFC-1884] S. Deering, R. Hinden, "IP Version 6 Addressing Architecture". [RFC-1885] A. Conta, and S. Deering "Internet Control Message Protocol for the Internet Protocol Version 6 (IPv6)" [IPv6ND] T. Narten, E. Nordmark, "IPv6 Neighbor Discovery Specification" [IPv6PMTU] J. McCann and S. Deering, "IPv6 Path MTU Discovery" [ADDRCONF] T. Narten, and S. Thomson, "IPv6 Address Autoconfiguration" [IPv6PMTU] J. McCann and S. Deering, "IPv6 Path MTU Discovery" [RFC-1700] Conta & Deering Expires in six months [Page 34] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 J. Reynolds, J. Postel, "Assigned Numbers", 10/20/1994 [RFC-1853] W. Simpson, "IPv4 Tunneling", 11.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: Brian Carpenter, Erik Nordmark. [TBD] 12.Security Considerations Security considerations are not discussed in this memo. Authors' Addresses: Alex Conta Stephen Deering Digital Equipment Corporation Xerox Palo Alto Research Center 110 Spitbrook Rd 3333 Coyote Hill Road Nashua, NH 03062 Palo Alto, CA 94304 +1-603-881-0744 +1-415-812-4839 email: conta@zk3.dec.com email: deering@parc.xerox.com Appendix A Fixed-end Inner tunnels with different entry-points and identical exit-points Conta & Deering Expires in six months [Page 35] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 node node node node node node node a.a.1 b.b.1 c.c.1 ... x ... y ... d.d.1 z.z.1 * ** * ** tunnel I from b.b.1 to z.z.1 tunnel II from c.c.1 to z.z.1 1. node a.a.1: xmt: aa1/zz1 (source=aa1 destination=zz1) to bb1 2. node b.b.1: rcv: aa1/zz1 forwarding: anything that is destined to prefix 'z' => tunnel 'bb1/z z1' and send to cc1 xmt: bb1/zz1 | aa1/zz1 to cc1 3. node cc1: rcv: bb1/zz1 | aa1/zz1 forwarding: anything that is destined to prefix 'z' => tunnel 'cc1/z z1' and send to next router on the way to dd1 xmt: cc1/zz1 | bb1/zz1 | aa1/zz1 to next router on the way to dd1 4. before reaching node dd1, routing loop brings packet to bb1 loop:: node bb1: rcv: cc1/zz1 | bb1/zz1 | aa1/zz1 forwarding: anything that is destined to prefix 'z' => tunnel 'bb1/ zz1' and send to cc1 xmt: bb1/zz1 | cc1/zz1 | bb1/zz1 | aa1/zz1 to cc1 5. node cc1: Conta & Deering Expires in six months [Page 36] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 rcv: bb1/zz1 | cc1/zz1 | bb1/zz1 | aa1/zz1 forwarding: anything that is destined to prefix 'z' => tunnel 'cc1/ zz1' xmt: cc1/zz1 | bb1/zz1 | cc1/zz1 | bb1/zz1 | aa1/zz1 to next router on the way to dd1 NOTE: check on source address = packet source DOES NOT eliminate the recursi ve encapsulation Appendix B Default Tunnel - maximum risk for excessive recursive encapsulation in case of routing loops. node node node node node node node a.a.1 b.b.1 c.c.1 d.d.1 e.e.1 f.f.1 z.z.1 * ** ** * tunnel I from b.b.1 to f.f.1 tunnel II from c.c.1 to e.e.1 1. node aa1: xmt: aa1/zz1 (source=aa1 destination=zz1) 2. node bb1: rcv: aa1/zz1 forwarding: anything that does not go to prefix 'a' or 'c' => tunnel 'bb1/ff1' and send to cc1 xmt: bb1/ff1 | aa1/zz1 3. node cc1: rcv: bb1/ff1 | aa1/zz1 forwarding: anything that does not go to prefix 'a', or 'b', or 'd' => tunnel 'cc1/ee1' and send to next router on the way to ee1 Conta & Deering Expires in six months [Page 37] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 xmt: cc1/ee1 | bb1/ff1 | aa1/zz1 to next router on the way to ee1 4. before reaching node ee1, routing loop brings packet to bb1 loop:: node bb1: rcv: cc1/ee1 | bb1/ff1 | aa1/zz1 forwarding: anything that does not go to prefix 'a' or 'c' => tunnel 'bb1/ff1' and send to cc1 xmt: bb1/ff1 | cc1/ee1 | bb1/ff1 | aa1/zz1 to cc1 5. node cc1: rcv: bb1/ff1 | cc1/ee1 | bb1/ff1 | aa1/zz1 forwarding: anything that does not go to prefix 'a', or 'b', or 'd' => tunnel 'cc1/ee1' xmt: cc1/ee1 | bb1/ff1 | cc1/ee1 | bb1/ff1 | aa1/zz1 NOTE: check on source address = packet source DOES NOT eliminate the recursi ve encapsulation Changes from previous version. - add new sections: 3.4 IPv6 Tunnels and Address Formats........................13 3.5 IPv6 Tunnels and IPv6 Autoconfiguration.................13 3.6 IPv6 Tunnels and IPv6 Neighbor Discovery................13 4.1.4 Risk Factors in Recursive Encapsulation..............17 Appendix A..Inner tunnels...................................35 Appendix B..Default tunnels.................................37 - separate fragmentation from section 6.7 into a new section: 7. IPv6 Tunnel Packet Fragmentation.........................25 7.1 IPv6 Packet Fragmentation...........................25 7.2 IPv4 Packet Fragmentation...........................26 Conta & Deering Expires in six months [Page 38] INTERNET-DRAFT Tunneling in IPv6 February 22, 1996 - include comments from Erik Nordmark - some of the comments are part of the modifications mentioned above. - Section 5: flow label "tipical" corrected to "typical". - Section 6.2: changed from multi-point to point-to-point - section 8.1 replace "original packet originator" with "source of original packet". ------- End of Forwarded Message