RFC 2473
Generic Packet Tunneling in IPv6 Specification
RFC 2473: Generic Packet Tunneling in IPv6 Specification ✨
okay bestie, this one is RFC 2473 🎀 It's from the Network Working Group and it's a Standards Track doc, so it's a real Internet standards track protocol 💅 Two people wrote it: A. Conta from Lucent Technologies Inc. and S. Deering from Cisco Systems. It's dated December 1998. The header doesn't list anything it obsoletes or updates 🦋
Status of This Memo 🌈
This document specifies an Internet standards track protocol for the Internet community, and it wants discussion and suggestions for improvements 💖 To find out where this protocol stands on standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited 🫶
Copyright Notice 🔐
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract 🧚
So basically this doc is the blueprint for wrapping Internet packets up inside IPv6 packets, like IPv4 and IPv6 packets 🎁 The model and mechanisms can also be used on other protocol packets, like AppleTalk, IPX, CLNP, or others ✨
Table of Contents 🍓
1. Introduction..................................................2
2. Terminology...................................................2
3. IPv6 Tunneling................................................4
3.1 IPv6 Encapsulation.......................................6
3.2 IPv6 Packet Processing in Tunnels........................7
3.3 IPv6 Decapsulation.......................................7
3.4 IPv6 Tunnel Protocol Engine..............................8
4. Nested Encapsulation.........................................11
4.1 Limiting Nested Encapsulation..........................12
4.1.1 Tunnel Encapsulation Limit Option................13
4.1.2 Loopback Encapsulation...........................15
4.1.3 Routing Loop Nested 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...................................19
6.4 IPv6 Tunnel Packet Traffic Class........................20
6.5 IPv6 Tunnel Flow Label..................................20
6.6 IPv6 Tunnel Encapsulation Limit.........................20
6.7 IPv6 Tunnel MTU.........................................20
7. IPv6 Tunnel Packet Size Issues...............................21
7.1 IPv6 Tunnel Packet Fragmentation........................21
7.2 IPv4 Tunnel Packet Fragmentation........................22
8. IPv6 Tunnel Error Reporting and Processing...................22
8.1 Tunnel ICMP Messages....................................27
8.2 ICMP Messages for IPv6 Original Packets.................28
8.3 ICMP Messages for IPv4 Original Packets.................29
8.4 ICMP Messages for Nested Tunnel Packets.................30
9. Security Considerations......................................30
10. Acknowledgments.............................................31
11. References..................................................31
Authors' Addresses..............................................32
Appendix A. Risk Factors in Recursive Encapsulation.............33
Full Copyright Statement........................................361. Introduction 💅
This doc spells out a method and some generic mechanisms for taking a packet, encapsulating it, and carrying it as the payload of an IPv6 packet 🎀 The wrapped-up result is called an IPv6 tunnel packet. The forwarding path between the source and destination of that tunnel packet is called an IPv6 tunnel, and the whole technique is called IPv6 tunneling 🦋
A typical use case for IPv6 tunneling is when an intermediate node wants explicit routing control, so it picks particular forwarding paths for selected packets 🗺️ It does this by sticking IPv6 headers onto each of the selected original packets. Those prepended headers are what identify the forwarding paths ✨
On top of the generic IPv6 tunneling mechanisms, which are the main focus here, this doc also describes specific mechanisms for tunneling IPv6 and IPv4 packets 💖
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined in RFC 2119. 🔥
2. Terminology 🧚
Here's the vocab you need, bestie 📖
- original packet: a packet that undergoes encapsulation. 🎁
- original header: the header of an original packet. 📦
- tunnel: a forwarding path between two nodes on which the payloads of packets are original packets. 🛤️
- tunnel end-node: a node where a tunnel begins or ends. 🏁
- tunnel header: the header prepended to the original packet during encapsulation. It specifies the tunnel end-points as source and destination. 🧾
- tunnel packet: a packet that encapsulates an original packet. 🎀
- tunnel entry-point: the tunnel end-node where an original packet is encapsulated. 🚪
- tunnel exit-point: the tunnel end-node where a tunnel packet is decapsulated. 🚪
- IPv6 tunnel: a tunnel configured as a virtual link between two IPv6 nodes, on which the encapsulating protocol is IPv6. 💜
- tunnel MTU: the maximum size of a tunnel packet payload without requiring fragmentation, that is, the Path MTU between the tunnel entry-point and the tunnel exit-point nodes minus the size of the tunnel header. 📏
- tunnel hop limit: the maximum number of hops that a tunnel packet can travel from the tunnel entry-point to the tunnel exit-point. 🦘
- inner tunnel: a tunnel that is a hop (virtual link) of another tunnel. 🪆
- outer tunnel: a tunnel containing one or more inner tunnels. 🪆
- nested tunnel packet: a tunnel packet that has as payload a tunnel packet. 🙈
- nested tunnel header: the tunnel header of a nested tunnel packet. 🙈
- nested encapsulation: encapsulation of an encapsulated packet. 🌀
- recursive encapsulation: encapsulation of a packet that reenters a tunnel before exiting it. 🔁
- tunnel encapsulation limit: the maximum number of nested encapsulations of a packet. 🚧
3. IPv6 Tunneling 🦋
IPv6 tunneling is a technique for setting up a "virtual link" between two IPv6 nodes, so they can send data packets as payloads of IPv6 packets (see Fig.1) 🌸 From the two nodes' point of view, this "virtual link" (called an IPv6 tunnel) looks like a point to point link, where IPv6 acts like a link-layer protocol 🤯 The two nodes have specific roles. One node encapsulates original packets it gets from other nodes (or from itself) and forwards the resulting tunnel packets through the tunnel. The other node decapsulates the tunnel packets it receives and forwards the resulting original packets toward their destinations, which could be itself 🎁 The encapsulator is called the tunnel entry-point node, and it's the source of the tunnel packets. The decapsulator is called the tunnel exit-point, and it's the destination of the tunnel packets 👑
Note: This doc is mostly about tunnels between two nodes identified by unicast addresses. Those tunnels look like "virtual point to point links" 💖 The mechanisms here also apply to tunnels where the exit-point nodes are identified by other types of addresses, like anycast or multicast. Those tunnels may look like "virtual point to multipoint links" 🌈 At the time of writing, IPv6 anycast addresses were still the subject of ongoing specification and experimental work 🧪
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 TunnelAn IPv6 tunnel is unidirectional 🚂 Tunnel packet flow goes in one direction only, from the IPv6 tunnel entry-point node to the 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 Bi-directional Tunneling MechanismBi-directional tunneling is built by merging two unidirectional mechanisms. In other words, you set up two tunnels pointing in opposite directions, so the entry-point node of one tunnel is the exit-point node of the other (see Fig.2) 🔄✨
3.1. IPv6 Encapsulation ✨
okay so encapsulation is basically wrapping the original packet in a brand new IPv6 header, and sometimes a few IPv6 extension headers too 🎀 All of that wrapping together gets called the tunnel IPv6 headers. It happens at the tunnel entry-point node, the moment an original packet gets forwarded onto the virtual link that the tunnel stands for 🦋 The original packet still gets handled by the forwarding rules of its own protocol while this is happening, so the rules depend on what kind of packet it is:
- (a) IPv6 packet: the original IPv6 header hop limit gets decremented by one. 💅
- (b) IPv4 packet: the original IPv4 header time to live field (TTL) gets decremented by one. 🌸
Then comes the fun part! The source field of the tunnel IPv6 header gets filled with an IPv6 address of the tunnel entry-point node, and the destination field gets an IPv6 address of the tunnel exit-point 💜 After that, the tunnel packet that came out of encapsulation is sent off toward the tunnel exit-point node ✨
+----------------------------------//-----+
| Original | |
| | Original Packet Payload |
| Header | |
+----------------------------------//-----+
< Original Packet >
|
v
<Tunnel IPv6 Headers> < Original Packet >
+---------+ - - - - - +-------------------------//--------------+
| IPv6 | IPv6 | |
| | Extension | Original Packet |
| Header | Headers | |
+---------+ - - - - - +-------------------------//--------------+
< Tunnel IPv6 Packet >
Fig.3 Encapsulating a PacketTunnel extension headers should appear in the order recommended by the specifications that define the extension headers, such as [IPv6-Spec]. Basically, keep the order the spec recommends, bestie 🧚
A source of original packets and a tunnel entry-point that encapsulates those packets can be the same node. So one node can be both the one making the packets and the one wrapping them up 🫶
3.2. Packet Processing in Tunnels 🌈
The intermediate nodes in the tunnel process the IPv6 tunnel packets according to the IPv6 protocol, so they're following the usual IPv6 rules 💖 A few examples, because examples are everything:
- A tunnel
Hop by Hop Optionsextension header gets processed by each receiving node in the tunnel. Everyone gets a look! 👀 - A tunnel
Routingextension header identifies the intermediate processing nodes, and it controls the forwarding path of the tunnel packet through the tunnel at a finer granularity. Main character routing energy 👑 - A tunnel
Destination Optionsextension header gets processed at the tunnel exit-point node. The exit point gets the final say on this one 🦋
3.3. IPv6 Decapsulation 🔥
Here's decapsulation, shown in Fig.4 💅
+---------+- - - - - -+----------------------------------//-----+
| IPv6 | IPv6 | |
| | Extension | Original Packet |
| Header | Headers | |
+---------+- - - - - -+----------------------------------//-----+
< Tunnel IPv6 Packet >
|
v
+----------------------------------//-----+
| Original | |
| | Original Packet Payload |
| Headers | |
+----------------------------------//-----+
< Original Packet >
Fig.4 Decapsulating a PacketSo when an IPv6 packet shows up addressed to an IPv6 address of a tunnel exit-point node, its IPv6 protocol layer goes through the tunnel headers. The strict left-to-right processing rules for extension headers apply here 🎀 Once processing is done, control gets handed to the next protocol engine. That engine is picked by the Next Header field value in the last header that got processed. If that value is a tunnel protocol value, the tunnel protocol engine throws away the tunnel headers and passes the resulting original packet to the Internet or lower layer protocol that the value identifies, so it can keep being processed 🧚
For example, if the Next Header field has the IPv6 Tunnel Protocol value, the resulting original packet gets passed to the IPv6 protocol layer. It's giving nested IPv6 vibes 🌸
The tunnel exit-point node, which decapsulates the tunnel packets, and the destination node, which receives the resulting original packets, can be the same node. One node, two jobs, zero drama 💜
3.4 IPv6 Tunnel Protocol Engine ✨
okay bestie, here's how packets flow through the IPv6 Tunnel Protocol Engine on a node 🦋 Paths #1-7 are mapped out in Fig.5 below, and it's giving organized chaos 💅
Note: In Fig.5, the Upper-Layer Protocols box covers transport protocols like TCP and UDP 💖, control protocols like ICMP, routing protocols like OSPF, and the internet or lower-layer protocol being "tunneled" over IPv6, like IPv4, IPX, etc. The Link-Layer Protocols box covers Ethernet, Token Ring, FDDI, PPP, X.25, Frame Relay, ATM, etc..., plus internet-layer "tunnels" like IPv4 tunnels 🌈
The IPv6 tunnel protocol engine is literally two things at once 👑 It acts as an "upper-layer" AND a "link-layer", and each one has its own input and output:
- (u.i) "tunnel upper-layer input" 🎀 consists of tunnel IPv6 packets that are about to be decapsulated. They come in through the IPv6 layer from:
- (u.i.1) a link-layer (path #1, Fig.5) ✨
- These are tunnel packets destined to this node, and they'll get decapsulated.
- (u.i.2) a tunnel link-layer (path #7, Fig.5) 🌸
- These are tunnel packets that already got one or more decapsulations on this node. So the packets had one or more nested tunnel headers, and one nested tunnel header was just tossed. This node is the exit-point of an outer tunnel AND one or more of its inner tunnels, which is so layered 🧚
- In both of these cases, the resulting original packets get passed back up to the IPv6 layer as "tunnel link-layer" output for more processing (see b.2).
- (u.i.1) a link-layer (path #1, 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 in the IPv6 Tunneling Protocol Engine on a Node
- (u.o) "tunnel upper-layer output" 🦋 consists of tunnel IPv6 packets that get passed down through the IPv6 layer to:
- (u.o.1) a link-layer (path #2, Fig.5) 💜
- These packets already went through encapsulation and are on their way to the tunnel exit-point 🚀
- (u.o.2) a tunnel link-layer (path #8, Fig.5) 🍓
- These tunnel packets go through nested encapsulation. This node is the entry-point node of an outer tunnel AND one or more of its inner tunnels 🌈
- (u.o.1) a link-layer (path #2, Fig.5) 💜
Implementation Note: the tunnel upper-layer input and output can be built the same way as the input and output of the other upper-layer protocols 🫶
The tunnel link-layer input and output work like this:
- (l.i) "tunnel link-layer input" 🌷 consists of original IPv6 packets that are about to be encapsulated.
- The original packets come in through the IPv6 layer from:
- (l.i.1) an upper-layer (path #4, Fig.5) ✨
- These are original packets that start on this node and get encapsulated. The original packet source and the tunnel entry-point are the same node 💅
- (l.i.2) a link-layer (path #6, Fig.5) 🔥
- These are original packets coming in from a different node, which get encapsulated on this tunnel entry-point node.
- (l.i.3) a tunnel upper-layer (path #8, Fig.5) 🧚
- These packets are tunnel packets getting nested encapsulation. This node is the entry-point node of an outer tunnel AND one or more of its inner tunnels.
- (l.i.1) an upper-layer (path #4, Fig.5) ✨
- The resulting tunnel packets are passed out as tunnel upper-layer output packets through the IPv6 layer (see u.o) and down to:
- The original packets come in through the IPv6 layer from:
- (l.o) "tunnel link-layer output" 🌸 consists of original IPv6 packets that come out of decapsulation. These packets are passed through the IPv6 layer to:
- (l.o.1) an upper-layer (path #3, Fig.5) 👑
- These original packets are destined for this node.
- (l.o.2) a link-layer (path #5, Fig.5) 🌊
- These original packets are destined for another node, and they get sent over a link toward their destination.
- (l.o.3) a tunnel upper-layer (path #7, Fig.5) 💖
- These packets get another decapsulation, since they were nested tunnel packets. This node is both the exit-point node of an outer tunnel and one or more inner tunnels 🙈
- (l.o.1) an upper-layer (path #3, Fig.5) 👑
Implementation Note: the tunnel link-layer input and output can be built the same way as the input and output of other link-layer protocols. For example, you can associate an interface or pseudo-interface with the IPv6 tunnel 🎀
The selection of the "IPv6 tunnel link" over other links comes from the packet forwarding decision, which is based on what's in the node's routing table 🗺️ So the routing table is literally the bouncer deciding which link gets the VIP treatment 💅
4. Nested Encapsulation
Nested IPv6 encapsulation is when you encapsulate a tunnel packet 🪆 It happens when a hop of an IPv6 tunnel is itself a tunnel. The tunnel that contains another tunnel is called an outer tunnel, and the tunnel inside it is called an inner tunnel (see Fig.6). Inner tunnels and their outer tunnels are called nested tunnels 💜
The entry-point node of an "inner IPv6 tunnel" receives tunnel IPv6 packets that were encapsulated by the "outer IPv6 tunnel" entry-point node 🌈 The "inner tunnel entry-point node" treats those incoming tunnel packets as original packets and performs encapsulation on them. The results are "tunnel packets" for the "inner IPv6 tunnel", and "nested tunnel packets" for the "outer IPv6 tunnel" ✨
Outer Tunnel
<------------------------------------->
<--links--><-virtual link-><--links--->
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 NodeFig.6. Nested Encapsulation
4.1 Limiting Nested Encapsulation
A tunnel IPv6 packet is limited to the maximum IPv6 packet size [IPv6-Spec]. Every encapsulation adds the size of the tunnel IPv6 headers to the encapsulated packet 📦 So the number of tunnel headers, and therefore the number of nested encapsulations, is capped by the maximum packet size. But honestly? That cap is so big (more than 1600 encapsulations for an original packet of minimum size) that it's not a real limit in most cases 🙃
Here's the spicy part 🌶️ The growth in size from nested encapsulation may force fragmentation [IPv6-Spec] at a tunnel entry point (see section 7). Also, each fragmentation caused by nested encapsulation, of a packet that's already fragmented, doubles the number of fragments 😭 And once fragmentation starts, it's probable that each new nested encapsulation causes even more fragmentation 💀 That's why limiting nested encapsulation is recommended 🫶
The proposed mechanism for limiting excessive nested encapsulation is a "Tunnel Encapsulation Limit" option. It's carried in an IPv6 Destination Options extension header that goes along with an encapsulating IPv6 header 🎀
4.1.1 Tunnel Encapsulation Limit Option
Okay bestie, so a tunnel entry-point node MAY be configured to slap a Tunnel Encapsulation Limit option onto every packet that enters a tunnel there 🎀. The option lives in a Destination Options extension header [IPv6-Spec], tucked between the encapsulating IPv6 header and the original packet's IPv6 header. Other extension headers MAY also be present before or after it, depending on the entry-point node's config 🧚.
The option tells the packet how many more layers of encapsulation it's allowed to pile on, or in other words, how many more times it can get nested 🪆. The count doesn't include the encapsulation the option is sitting in. For example, a limit value of zero means the packet can't enter another tunnel until it has exited the current one 🙈.
Here's the layout of the option 💅:
Option Type Opt Data Len Opt Data Len
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0| 1 | Tun Encap Lim |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each piece means:
- Option Type: decimal value 4. The field breaks down like this:
- The two highest-order bits are set to 00, which means "skip over this option if the option is not recognized".
- The third-highest-order bit is set to 0, which means the option data doesn't change en route to the packet's destination [IPv6-Spec].
- Opt Data Len: value 1, so the data portion of the option is one octet long.
- Opt Data Value: the Tunnel Encapsulation Limit value. It's an 8-bit unsigned integer that specifies how many further levels of encapsulation are permitted for the
Tunnel Encapsulation Limit options only matter to tunnel entry points 👑. A tunnel entry-point node is REQUIRED to run the following procedure for every packet entering a tunnel at that node 🔥:
(a) Check whether the packet has a Tunnel Encapsulation Limit option right after its IPv6 header. The headers after the IPv6 header MUST be examined in strict "left-to-right" order, and the examination stops as soon as any one of these shows up: (i) a Destination Options extension header containing a Tunnel Encapsulation Limit, (ii) another IPv6 header, (iii) a non-extension header, like TCP, UDP, or ICMP, or (iv) a header that can't be parsed, either because it's encrypted or because its type is unknown. Fun fact: this is an exception to the usual IPv6 rule that a Destination Options extension header only needs to be looked at by the packet's destination node 😭. A "cleaner" option would've been a Hop-by-Hop extension header, but that would have added an unwanted processing burden, and possibly extra delay, at every IPv6 node along a tunnel's path 🦋.
(b) If a Tunnel Encapsulation Limit option is found in the packet entering the tunnel and its limit value is zero, the packet is discarded, and an ICMP Parameter Problem message [ICMP-Spec] is sent to the packet's source, which is the previous tunnel entry-point node. The Code field of that Parameter Problem message is set to zero ("erroneous header field encountered"), and the Pointer field points to the third octet of the Tunnel Encapsulation Limit option (the octet holding the limit value of zero) 💀.
(c) If a Tunnel Encapsulation Limit option is found in the packet entering the tunnel and its limit value is non-zero, an additional Tunnel Encapsulation Limit option MUST be included as part of the encapsulating headers added at this entry point. The limit value in the encapsulating option is set to one less than the limit value found in the packet being encapsulated 🌈.
(d) If a Tunnel Encapsulation Limit option is not found in the packet entering the tunnel, and an encapsulation limit has been configured for this tunnel, a Tunnel Encapsulation Limit option MUST be included as part of the encapsulating headers added at this entry point. The limit value in the option is set to the configured limit 🍓.
(e) If a Tunnel Encapsulation Limit option is not found in the packet entering the tunnel, and no encapsulation limit has been configured for this tunnel, then no Tunnel Encapsulation Limit option is included as part of the encapsulating headers added at this entry point ✨.
A Tunnel Encapsulation Limit option added at a tunnel entry-point node gets removed during decapsulation at that tunnel's exit-point node 🫶.
Two cases of encapsulation that SHOULD be avoided are described below 👀:
4.1.2 Loopback Encapsulation
Loopback encapsulation is the one case you MUST avoid at all costs 😱. It happens when a tunnel IPv6 entry-point node encapsulates tunnel IPv6 packets that it originated itself and that are destined for itself. That can make the entry-point node spin in an infinite processing loop 🌀.
To prevent this, it is RECOMMENDED that an implementation have a mechanism that checks and rejects a tunnel configuration in which both the entry-point and exit-point node addresses belong to the same node 🙅♀️. It is also RECOMMENDED that the encapsulating engine check for, and reject, the encapsulation of any packet whose pair of tunnel entry-point and exit-point addresses is identical to its pair of original source and final destination addresses 💜.
4.1.3 Routing-Loop Nested Encapsulation
Okay, this one is scary 🥺. When a forwarding path has multiple levels of nested tunnels, a routing loop from an inner tunnel back to an outer tunnel is especially dangerous, particularly when packets from the inner tunnels re-enter an outer tunnel they haven't exited yet. In that situation, the nested encapsulation turns into recursive encapsulation, with the negative effects described in 4.1 💥. And here's the catch: every nested encapsulation adds a tunnel header with a new hop limit value, so the IPv6 hop limit mechanism can't control how many times the packet reaches the outer tunnel entry-point node. That means it also can't control how many recursive encapsulations happen 😭.
So when a packet's path from source to final destination includes tunnels, the maximum number of hops it can travel SHOULD be controlled by two mechanisms working together, so the recursive encapsulation problems in routing loops are avoided 🛡️:
(a) The original packet hop limit. It's decremented at each forwarding operation performed on an original packet. That includes each encapsulation of the original packet, but it does not include nested encapsulations of the original packet 🦋.
(b) The tunnel IPv6 packet encapsulation limit. It's decremented at each nested encapsulation of the packet 🌸.
For a deeper look at the risk factors of excessive encapsulation in nested encapsulation, check out Appendix A 📚.
5. Tunnel IPv6 Header
Time to build the tunnel IPv6 main header 💖. The tunnel entry-point node fills it out as follows [IPv6-Spec]:
- Version: value 6 ✨.
- Traffic Class: depending on the entry-point node's tunnel configuration, this can be set to either the original packet's traffic class or a pre-configured value. See section 6.4 🎀.
- Flow Label: depending on the entry-point node's tunnel configuration, this can be set to a pre-configured value. The typical value is zero. See section 6.5 🌸.
- Payload Length: the original packet length, plus the length of the encapsulating (prepended) IPv6 extension headers, if there are any 🧚.
- Next Header: the next header value according to [IPv6-Spec], taken from the Assigned Numbers RFC [RFC-1700 or its successors] 🦋.
- For example, if the original packet is an IPv6 packet, this is set to:
- decimal value 41 (Assigned Next Header number for IPv6), if there are no tunnel extension headers.
- value 0 (Assigned Next Header number for IPv6 Hop by Hop Options extension header), if a hop-by-hop options extension header immediately follows the tunnel IPv6 header.
- decimal value 60 (Assigned Next Header number for IPv6 Destination Options extension header), if a destination options extension header immediately follows the tunnel IPv6 header.
- For example, if the original packet is an IPv6 packet, this is set to:
- 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 [ND-Spec]. The default value for routers is the default IPv6 Hop Limit value from the Assigned Numbers RFC (64 at the time of writing this document) 👑.
- Source Address: an IPv6 address of the outgoing interface of the tunnel entry-point node. This address is configured as the tunnel entry-point node address. See section 6.1 💜.
- Destination Address: an IPv6 address of the tunnel exit-point node. This address is configured as the tunnel exit-point node address. See section 6.2 🌈.
5.1 Tunnel IPv6 Extension Headers 💅
okay so, depending on how the IPv6 node is configured, a tunnel entry-point node might tack one or more extension headers onto the tunnel IPv6 main header 🎀 like a Hop-by-Hop Options header, a Routing header, or others ✨
to limit how many times a packet gets nested-encapsulated (if the node was set up to do that, see section 6.6 🫶), a tunnel entry-point includes a Destination Options extension header with a Tunnel Encapsulation Limit option inside 🦋. If that option is the only one in the Destination Options header, the header looks like this:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each field does 🍓
- Next Header: tells you what kind of original packet header comes next 🧚 For example, if the original packet is an IPv6 packet, the value is set to decimal 41 (the assigned payload type number for IPv6).
- Hdr Ext Len: the length of this Destination Options extension header in 8-octet units, not counting the first 8 octets. It's set to
0if there are no other options in this destination options header 💀 - Option Type (
4): see section 4.1.1 ✨ - Opt Data Len (
1): see section 4.1.1 ✨ - Tun Encap Lim: an 8-bit unsigned integer, see section 4.1.1 💜
- Option Type (
1): this is the PadN option, used to line up the header that comes after it 🌸 - Opt Data Len (
1): one octet of option data 🙈 - Option Data (
0): one zero-valued octet 🫶
6. IPv6 Tunnel State Variables 🌈
okay bestie, here are the IPv6 tunnel state variables. Some of them are configured on the tunnel entry-point node, and some of them might be 👀
6.1 IPv6 Tunnel Entry-Point Node Address 🦋
the tunnel entry-point node address is one of the valid IPv6 unicast addresses of the entry-point node 💖 validating it when the tunnel gets configured is recommended, so you catch problems early.
The tunnel entry-point node address gets copied into the source address field of the tunnel IPv6 header during 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. Honestly, a tunnel acts like a virtual point-to-point link between the entry-point node and the exit-point node 🔥
The tunnel exit-point node address gets copied into the destination address field of the tunnel IPv6 header during encapsulation ✨
Configuring the tunnel entry-point and exit-point addresses is not subject to IPv6 Autoconfiguration or IPv6 Neighbor Discovery 🙅♀️
6.3 IPv6 Tunnel Hop Limit 🍓
so an IPv6 tunnel is modeled as a "single-hop virtual link" tunnel 💅 The original packet passing through the tunnel is treated like it crossed a one-hop link, no matter how many hops the tunnel actually has 🌸
The "single-hop" mechanism should be implemented by having the tunnel entry point node set a tunnel IPv6 header hop limit independently of the hop limit of the original header 🫶
The "single-hop" mechanism also hides the number of IPv6 hops in the tunnel from the original IPv6 packets. Main character energy 👑
It is recommended that the tunnel hop limit be configured with a value that ensures:
- (a) that tunnel IPv6 packets can reach the tunnel exit-point node
- (b) 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 IPv6 Neighbor Discovery advertised hop limit [ND-Spec]. The tunnel hop limit default value for routers is the default IPv6 Hop Limit value from the Assigned Numbers RFC (64 at the time of writing this document) 🌈
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 Traffic Class 💜
the IPv6 Tunnel Packet Traffic Class is the value that a tunnel entry-point node sets in the Traffic Class field of a tunnel header. The default is zero 🍓 The configured Packet Traffic Class can also say whether the Traffic Class value in the tunnel header gets copied from the original header, or set to the pre-configured value ✨
6.5 IPv6 Tunnel Flow Label 🦋
the IPv6 Tunnel Flow Label is 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 Tunnel Encapsulation Limit value can show whether the entry-point node is set up to limit how many times tunnel packets originating on that node get encapsulated 🔥 The IPv6 Tunnel Encapsulation Limit is the maximum number of additional encapsulations allowed for packets undergoing encapsulation at that entry-point node. The recommended default value is 4 💅 An entry-point node that's configured to limit nested encapsulations prepends a Destination Options extension header with a Tunnel Encapsulation Limit option to an original packet that's undergoing encapsulation. See sections 4.1 and 4.1.1 ✨
6.7 IPv6 Tunnel MTU 🌸
the tunnel MTU is set dynamically to the Path MTU between the tunnel entry-point and the tunnel exit-point nodes, minus the size of the tunnel headers. That's the maximum size of a tunnel packet payload that can be sent through the tunnel without fragmentation [IPv6-Spec] 🎀 The tunnel entry-point node performs Path MTU discovery on the path between the entry-point and exit-point nodes [PMTU-Spec], [ICMP-Spec] 🔥 The tunnel MTU of a nested tunnel is the tunnel MTU of the outer tunnel minus the size of the nested tunnel headers 🙈
7. IPv6 Tunnel Packet Size Issues 🫧
okay so, prepending a tunnel header makes a packet bigger 😭 That means a tunnel packet made from encapsulating an IPv6 original packet might need fragmentation 💀
A tunnel IPv6 packet made from encapsulating an original packet is treated as an IPv6 packet originating from the tunnel entry-point node. So, like any source of an IPv6 packet, a tunnel entry-point node must support fragmentation of tunnel IPv6 packets 💅
A tunnel intermediate node 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 🧚
A tunnel exit-point node receiving tunnel packets at the end of the tunnel for decapsulation applies the strict left-to-right processing rules for extension headers. If a tunnel packet got fragmented, the fragments are reassembled into a complete tunnel packet before it figures out that an embedded packet is present 🫶
Note: A particular problem shows up when a fragmented tunnel packet's destination is an exit-point node identified by an anycast address 😭 It's similar to the problem with original fragmented IPv6 packets destined to nodes identified by an anycast address. All the fragments of a packet must arrive at the same destination node so that node can reassemble successfully, and packets sent to an anycast address don't necessarily guarantee that 🙈
7.1 IPv6 Tunnel Packet Fragmentation 🦋
when an IPv6 original packet enters a tunnel and its size is bigger than the tunnel MTU (the Path MTU between the tunnel entry-point and exit-point, minus the size of the tunnel header(s)), here's what happens 👀
- (a) if the original IPv6 packet is larger than the IPv6 minimum link MTU [IPv6-Spec], the entry-point node discards the packet and sends an ICMPv6 "Packet Too Big" message to the source address of the original packet. The recommended MTU size field is set to the tunnel MTU or the IPv6 minimum link MTU, whichever is larger, i.e.
max (tunnel MTU, IPv6 minimum link MTU). Also see sections 6.7 and 8.2 💖 - (b) if the original IPv6 packet is equal to or smaller than the IPv6 minimum link MTU, the tunnel entry-point node encapsulates the original packet, then fragments the resulting IPv6 tunnel packet into IPv6 fragments that don't exceed the Path MTU to the tunnel exit-point ✨
7.2 IPv4 Tunnel Packet Fragmentation 🌈
when an IPv4 original packet enters a tunnel and its size is bigger than the tunnel MTU (the Path MTU between the tunnel entry-point and exit-point, minus the size of the tunnel header(s)), it's handled like this 🍓
- (a) if the Don't Fragment - DF - bit flag is SET in the original IPv4 packet header, the entry-point node discards the packet and returns an ICMP message. The ICMP message has
type = "unreachable",code = "packet too big", and the recommended MTU size field set to the size of the tunnel MTU. See sections 6.7 and 8.3 🔥 - (b) if the Don't Fragment - DF - bit flag is CLEAR in the original packet header, the tunnel entry-point node encapsulates the original packet, then fragments the resulting IPv6 tunnel packet into IPv6 fragments that don't exceed the Path MTU to the tunnel exit-point 🧚
8. IPv6 Tunnel Error Processing and Reporting ✨
okay bestie, IPv6 tunneling has a golden rule 👑: if something goes wrong while a node is processing an IPv6 packet, it reports the error with an ICMP message sent back to the source of that packet 💌
If the node is not inside any tunnel, the error goes straight to the source of the original IPv6 packet 💅
If the error is detected by a node inside a tunnel, it gets reported to the source of the tunnel packet, which is the tunnel entry-point node 🦋 The ICMP message sent to that entry-point node has, as its ICMP payload, the tunnel IPv6 packet that carries the original packet as its payload 🎀
The cause of a packet error inside a tunnel can be a problem with:
- (a) the tunnel header, or
- (b) the tunnel packet.
Both tunnel header problems and tunnel packet problems get reported to the tunnel entry-point node 🌸
If a tunnel packet problem is a consequence of a problem with the original packet (the payload of the tunnel packet), then the problem also gets reported to the source of the original packet 😭
To pass a problem detected inside the tunnel along to the source of an original packet, the tunnel entry point node must relay the ICMP message it received from inside the tunnel to the source of that original IPv6 packet 🫶
Okay, the diagrams are the main character here 🎬 Fig.7 shows what happens inside a node's error reporting engine, and Fig.8 shows the header processing. Let's go 💖
Fig.7 path #0 and Fig.8 (a): the IPv6 tunnel entry-point receives an ICMP packet from inside the tunnel, labeled Tunnel ICMPv6 Message in Fig.7. The entry-point node's IPv6 layer hands that ICMP message to the ICMPv6 Input. Based on the ICMP type and code [ICMP-Spec], the ICMPv6 Input generates an internal "error code" ✨
Fig.7 path #1: the internal error code gets passed up, along with the "ICMPv6 message payload", to the upper-layer protocol. In this case that's the IPv6 tunnel upper-layer error input 🧚
+-------+ +-------+ +-----------------------+
| Upper | | Upper | | Upper |
| Layer | | Layer | | Layer |
| Proto.| | Proto | | IPv6 Tunnel |
| Error | | Error | | Error |
| Input | | Input | | Input |
| | | | | Decapsulate |
| | | | | -->--ICMPv6--#2->-- |
| | | | | | Payload | |
+-------+ +-------+ +--|-----------------|--+
| | | |
^ ^ ^ v
| | | |
--------------------#1-- -----Orig.Packet?--- - - - - - - -
#1 #3 Int.Error Code, #5 |
Int.Error Code,^ v Source Address, v v
ICMPv6 Payload | IPv6 | Orig. Packet | IPv4 |
+--------------+ +------------+ +------------+ + - - +
| | | | | |
| ICMP v6 | | ICMP v6 | | ICMP v4 | | |
| Input | | Err Report | | Err Report |
| - - - - +----+ - - - -| + - - - -+ + - - +
| | | |
| IPv6 Layer | | IPv4 Layer | | |
| | | |
+--------------------------------+ +------------+ + - - +
| | |
^ V V
#0 #4 #6
| | |
Tunnel ICMPv6 ICMPv6 ICMPv4
Message Message Message
| | |Fig.7 Error Reporting Flow in a Node (IPv6 Tunneling Protocol Engine)
Fig.7 path #2 and Fig.8 (b): the IPv6 tunnel error input decapsulates the tunnel IPv6 packet (which is the ICMPv6 message payload) to get the original packet, and with it the original headers. Then it dispatches the "internal error code", the source address from the original packet header, and the original packet itself down to the error report block of whichever protocol the Next Header field in the tunnel header immediately before the original packet (in the ICMP message payload) points to 🔍
From here, what happens next depends on the protocol of the original packet 🤔
- (a) For an IPv6 original packet:
- Fig.7 path #3 and Fig.8 (c.1): for an IPv6 original packet, the ICMPv6 error report builds an ICMP message with a type and code based on the "internal error code", and puts the "original packet" in as the ICMP payload 📦
- Fig.7 path #4 and Fig.8 (d.1): the ICMP message gets the tunnel entry-point node address as its source address, and the source node address of the original packet as its destination address. The tunnel entry-point node sends that ICMP message to the source node of the original packet 🚀
- (b) For an IPv4 original packet:
- Fig.7 path #5 and Fig.8 (c.2): for an IPv4 original packet, the ICMPv4 error report builds an ICMP message with a type and code derived from the "internal error code", and puts the "original packet" in as the ICMP payload 📦
- Fig.7 path #6 and Fig.8 (d.2): the ICMP message gets the tunnel entry-point node's IPv4 address as its source address, and the source node IPv4 address of the original packet as its destination address. The tunnel entry-point node sends that ICMP message to the source node of the original packet 🚀
Here's a visual of the header processing going on ✨
< 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 | + | | Packet |
| Header | | Headers | | Headers | Payload |
+--------+ +---------+ +----------+--------//------+
| <Original Packet in Error >
----------------- |
| |
--------------|---------------
| |
V V
+---------+ +--------+ +-------------------//------+
| New | | ICMP | | |
(c.1) | IPv6 | + | | + | Orig. Packet in Error |
| Headers | | Header | | |
+---------+ +--------+ +-------------------//------+
|
v
+---------+--------+-------------------//------+
| New | ICMP | Original |
(d.1) | IPv6 | | |
| Headers | Header | Packet in Error |
+---------+--------+-------------------//------+
< New ICMP Message >
or for an IPv4 original packet
+---------+ +--------+ +-------------------//------+
| New | | ICMP | | |
(c.2) | IPv4 | + | | + | Orig. Packet in Error |
| Header | | Header | | |
+---------+ +--------+ +-------------------//------+
|
v
+---------+--------+-------------------//------+
| New | ICMP | Original |
(d.2) | IPv4 | | |
| Header | Header | Packet in Error |
+---------+--------+-------------------//------+
< New ICMP Message >Fig.8 ICMP Error Reporting and Processing
8.1 Tunnel ICMP Messages ✨
okay, here are the tunnel ICMP messages that get reported to the source of the original packet 🫧
- hop limit exceeded
- The tunnel has a misconfigured hop limit, or contains a routing loop, so packets never reach the tunnel exit-point node 🌀 This problem gets reported to the tunnel entry-point node, where the tunnel hop limit can be reconfigured to a higher value. The problem is then further reported to the source of the original packet, as described in section 8.2 or 8.3 🎯
- unreachable node
- One of the nodes in the tunnel is not reachable, or is no longer reachable 😵 This problem gets reported to the tunnel entry-point node, which should be reconfigured with a valid and active path between the entry and exit-point of the tunnel 🛣️
- The problem is then further reported to the source of the original packet, as described in section 8.2 or 8.3 🎯
- 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 problem is then further reported to the source of the original packet, as described in section 8.2 or 8.3 🎯
The above three problems detected inside the tunnel are tunnel configuration and tunnel topology problems. They get reported to the source of the original IPv6 packet 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 📏
- The information carried by this type of ICMP message is used as follows:
- by a receiving tunnel entry-point node, to set or adjust the tunnel MTU 🔧
- by a sending tunnel entry-point node, to tell the source of an original packet the MTU size that should be used when sending IPv6 packets toward the tunnel entry-point node 💌
8.2 ICMP Messages for IPv6 Original Packets ✨
okay so the tunnel entry-point node is the one building the ICMP and IPv6 headers for the message that goes back to the source of the original packet 💌 here's how it sets everything up:
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 these 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 zero:
Type 1 - unreachable node
Code 3 - address unreachableFor the 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 7.1, an ICMP "packet too big" message is sent to the source of the original packet only if the original packet size is larger than the minimum link MTU size required for IPv6 [IPv6-Spec]. 🎀 so it's not a "send it to everyone" situation, it's specifically when the original packet is bigger than that minimum link MTU 🙈
8.3 ICMP Messages for IPv4 Original Packets 🦋
same vibe, but for IPv4 originals 🌸 the entry-point node builds the ICMP and IPv4 header for the message going to the source of the original packet:
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 these tunnel ICMP error messages:
"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 zero:
Type 3 - destination unreachable
Code 1 - host unreachableFor a tunnel ICMP error message "packet too big":
Type 3 - destination unreachable
Code 4 - packet 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 section 7.2, an ICMP "packet too big" message is sent to the original IPv4 packet source node if the the original IPv4 header has the DF - don't fragment - bit flag SET. 💅 so the DF bit flag being SET is the big deciding factor here, bestie 🫶
8.4 ICMP Messages for Nested Tunnel Packets 🪆
okay nested tunnels are where things get a little layered 🧅 if there's an error found with a nested tunnel packet, the inner tunnel entry-point gets the ICMP error message from the inner tunnel reporting node and then relays it up to the outer tunnel entry-point. it follows the mechanisms in sections 8.,8.1, 8.2, and 8.3 to do this. then the outer tunnel entry-point passes the ICMP message along to the source of the original packet, using those same mechanisms 🔁 it's giving relay race 🏃♀️💨
9. Security Considerations 🔐
this part is serious, so let's get into it 😤 an IPv6 tunnel can be secured by securing the IPv6 path between the tunnel entry-point and exit-point node. the security architecture, mechanisms, and services are described in [RFC2401], [RFC2402], and [RFC2406]. a secure IPv6 tunnel may act as a gateway-to-gateway secure path as described in [RFC2401].
for a secure IPv6 tunnel, on top of the mechanisms we already talked about in this document, the entry-point node of the tunnel performs security algorithms on the packet. it also prepends one or more security headers as part of the tunnel headers, following [IPv6-Spec], [RFC2401], and [RFC2402], or [RFC2406] 🛡️
the exit-point node of a secure IPv6 tunnel performs security algorithms and processes the tunnel security header[s] as part of the tunnel headers processing we covered earlier. this follows [RFC2401], and [RFC2402], or [RFC2406]. once tunnel headers processing is complete, the exit-point node discards the tunnel security header[s] along with the rest of the tunnel headers. 🚨 gone, no trace, periodt 💀
the degree of integrity, authentication, and confidentiality, plus the security processing done on a tunnel packet at the entry-point and exit-point node of a secure IPv6 tunnel, depends on two things: the type of security header (authentication (AH) or encryption (ESP)) and the parameters configured in the Security Association for the tunnel 🔑 here's the big tea ☕: there's no dependency or interaction between the security level and mechanisms applied to the tunnel packets and the security applied to the original packets, which are the payloads of the tunnel packets. and for nested tunnels, each inner tunnel can have its own set of security services, totally independent from the outer tunnels or from whatever is between the source and destination of the original packet ✨ separate lanes, no drama 🛣️
10. Acknowledgments 🙏💖
this doc was partly built on a bunch of discussions about IPv6 tunneling on the IPng Working Group Mailing List, plus feedback from the IPng Working Group on an IPv6 presentation focused on tunneling at the 33rd IETF, in Stockholm, in July 1995 🌍
the following documents about tunneling or encapsulation were super helpful references too: RFC 1933 (R. Gilligan, E. Nordmark), RFC 1241 (R. Woodburn, D. Mills), RFC 1326 (P. Tsuchiya), RFC 1701, RFC 1702 (S. Hanks, D. Farinacci, P. Traina), RFC 1853 (W. Simpson), as well as RFC 2003 (C. Perkins) 📚
Brian Carpenter, Richard Draves, Bob Hinden, Thomas Narten, and Erik Nordmark (in alphabetical order) gave valuable reviewing comments and suggestions 🫶 Scott Bradner, Ross Callon, Dimitry Haskin, Paul Traina, and James Watt (in alphabetical order) shared their view or experience on matters of concern in this document. and Judith Grossman shared a sample of her many years of editorial and writing experience, plus a good amount of probing technical questions 🧠👑
11. References 📖
[IPv6-Spec] Deering, S. and R. Hinden, "Internet Protocol
Version 6 (IPv6) Specification", RFC 2460, December 1998.
[ICMP-Spec] Conta, A. and S. Deering "Internet Control Message
Protocol for the Internet Protocol Version 6 (IPv6)", RFC
2463, December 1998.
[ND-Spec] Narten, T., Nordmark, E., and W. Simpson "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[PMTU-Spec] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery
for IP Version 6 (IPv6)", RFC 1981, August 1996.
[RFC2401] Atkinson, R., "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
[RFC2402] Atkinson, R., "IP Authentication Header", RFC 2402,
November 1998.
[RFC2406] Atkinson, R., "IP Encapsulation Security Payload (ESP)",
RFC 2406, November 1998.
[RFC-1853] Simpson, W., "IP in IP Tunneling", RFC 1853, October
1995.
[Assign-Nr] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994. See also:
http://www.iana.org/numbers.html
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.Authors' Addresses 🖊️
Alex Conta
Lucent Technologies Inc.
300 Baker Ave
Concord, MA 01742-2168
+1-978-287-2842
EMail: aconta@lucent.com
Stephen Deering
Cisco Systems
170 West Tasman Dr
San Jose, CA 95132-1706
Phone: +1-408-527-8213
EMail: deering@cisco.comAppendix A 🌷
A.1 Risk Factors in Nested Encapsulation ⚠️
okay so nested encapsulations of a packet turn into a recursive encapsulation if the packet re-enters an outer tunnel before it exits it 🌀 the riskiest cases are the ones where a tunnel entry-point node can't tell whether a packet being encapsulated will re-enter the tunnel before exiting. routing loops that make tunnel packets re-enter a tunnel before exiting are definitely the main cause of this 🔁 and since routing loops exist and happen, it's important to understand the cases where the risk for recursive encapsulation is higher 🧐
there are two big elements that decide the risk factor of routing loop 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, that is, over the tunnel virtual-link.
A.1.1 Risk Factor in Nested Encapsulation - type of tunnel. 🎯
the type of tunnel identified as a high risk factor for recursive encapsulation in routing loops is:
"inner tunnels with identical exit-points".
so here's the thing 🫠 since the source and destination of an original packet are the main info used to decide whether to forward a packet through a tunnel, you can avoid recursive encapsulation with a single (non-inner) tunnel by checking that the packet being encapsulated didn't originate on the entry-point node. this mechanism is suggested in [RFC-1853].
however, this kind of protection doesn't seem to work well with inner tunnels that have different entry-points but identical exit-points. 😬
inner tunnels with different entry-points and identical exit-points make it ambiguous whether to encapsulate a packet, when a packet encapsulated in an inner tunnel reaches the entry-point node of an outer tunnel through a routing loop. the source of the tunnel packet is the inner tunnel entry-point node, which is different from the entry-point node of the outer tunnel, so the source address checking (mentioned above) fails to catch an invalid encapsulation. as a result, the tunnel packet gets encapsulated at the outer tunnel every single time it reaches it through the routing loop 🌪️ yikes, that's a whole spiral, bestie 💀
A.1.2. Risk Factor in Nested Encapsulation - type of route. 🍓
okay so the type of route to a tunnel exit-point is ALSO a high risk factor for recursive encapsulation in routing loops 😭 it's giving "the route you pick can make or break your whole tunnel situation" 💅
There are three flavours of route to a tunnel exit-point, bestie:
- Route to node 🎀: the destination is one specific, valid IPv6 address. This route gets picked by the longest match between the original packet's destination address and the destination address stored in the tunnel entry-point node's routing table entry for that route. The packet on this route is encapsulated first, and then forwarded toward the tunnel exit-point node.
- Route to net 🦋: the destination is a valid IPv6 prefix. This one gets picked by the longest path match between the original packet's destination address and the prefix destination stored in the tunnel entry-point node's routing table entry for that route. Same deal after that: encapsulated first, then forwarded toward the tunnel exit-point node.
- Default route 🌈: this is a route to an unspecified destination, the "I got nothing else, so here you go" option. It gets selected when no other match for the original packet's destination has been found in the routing table. A tunnel that is the first hop of a default route is called a "default tunnel" ✨
Now the risk levels, because this is where it gets spicy 🌶️
If the route to a tunnel exit-point is a route to node, the risk factor for recursive encapsulation is minimum 🌸 Nice and calm.
If the route to a tunnel exit-point is a route to net, the risk factor is medium 🥲 Here's why: a whole range of destination addresses matches that prefix. So if one or more inner tunnels, each with different tunnel entry-points, have exit-point node addresses that match the route to net of an outer tunnel exit-point, recursive encapsulation can happen. That happens when a tunnel packet gets diverted from inside one of those inner tunnels to the entry-point of the outer tunnel, which has a route to its exit-point that matches the exit-point of an inner tunnel. Hello, loop 🔁
If the route to a tunnel exit-point is a default route, the risk factor is maximum 💀 Packets go through a default tunnel just because nothing better showed up. In lots of situations that means a huge range of destination addresses ends up going through it, and at the most extreme it covers the entire Internet minus the node's own link. So in a routing loop, if a tunnel packet gets diverted from an inner tunnel to an outer tunnel entry-point where that tunnel is a default tunnel, the packet is probably going to get encapsulated again. Why? Because the default routing mechanism can't tell destinations apart, so it can't discern differently 😭🫠
Full Copyright Statement 🌈
okay bestie, the legal bit, but I've kept it faithful so nobody gets confused about what they're allowed to do 🫶
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💜
📦 where this page comes from
- ietf: rfc2473 1998-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms