RFC 7059
A Comparison of IPv6-over-IPv4 Tunnel Mechanisms
RFC 7059: A Comparison of IPv6-over-IPv4 Tunnel Mechanisms 🎀
okay bestie, this is part 1 of 10 🦋 so grab your snacks, we're going in!!
This one is RFC 7059, A Comparison of IPv6-over-IPv4 Tunnel Mechanisms 🌈 It came out in November 2013 as an Independent Submission in the Informational category, with ISSN 2070-1721. The authors are S. Steffann (S.J.M. Steffann Consultancy), I. van Beijnum (Institute IMDEA Networks), and R. van Rein (OpenFortress). The title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅
Abstract ✨
okay so the abstract is giving "here's the menu" energy 🍓 It gives an overview of the different ways to tunnel IPv6 packets over IPv4 networks. It covers the mechanisms people actually use, touches on a few that are only of historic interest now, and talks about some newer tunnel mechanisms that weren't widely used yet when this was published. The whole goal is helping anyone with an IPv6-in-IPv4 tunneling need pick the mechanisms that might fit them 🫶
Status of This Memo ✨
this section is the disclaimer part, but make it cute 💜
This document is not an Internet Standards Track specification. It's published purely for informational purposes 🧚
It's a contribution to the RFC Series, made independently of any other RFC stream. The RFC Editor chose to publish it at their discretion, and they make no claims about whether it's valuable for implementation or deployment 🤷♀️ Documents the RFC Editor approves for publication aren't candidates for any level of Internet Standard. (Check Section 2 of RFC 5741 if you want the receipts 🧾)
For the current status, any errata, and how to send feedback, go here:
http://www.rfc-editor.org/info/rfc7059Copyright Notice ✨
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved 💖
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they stood on the publication date. Please read these carefully, bestie, because they explain your rights and restrictions for this document 📜
http://trustee.ietf.org/license-infoTable of Contents 🌸
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Tunnel Mechanisms . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Configured Tunnels (Manual Tunnels / 6in4) . . . . . . . . 7
3.2. Automatic Tunneling . . . . . . . . . . . . . . . . . . . 8
3.3. IPv6 over IPv4 without Explicit Tunnels (6over4) . . . . . 9
3.4. Generic Routing Encapsulation (GRE) . . . . . . . . . . . 10
3.5. Connection of IPv6 Domains via IPv4 Clouds (6to4) . . . . 10
3.5.1. 6to4 Provider Managed Tunnels . . . . . . . . . . . . 11
3.6. Anything In Anything (AYIYA) . . . . . . . . . . . . . . . 12
3.7. Intra-Site Automatic Tunnel Addressing (ISATAP) . . . . . 13
3.8. Tunneling IPv6 over UDP through NATs (Teredo) . . . . . . 14
3.9. IPv6 Rapid Deployment (6rd) . . . . . . . . . . . . . . . 15
3.10. Native IPv6 behind NAT44 CPEs (6a44) . . . . . . . . . . . 16
3.11. Locator/ID Separation Protocol (LISP) . . . . . . . . . . 16
3.12. Subnetwork Encapsulation and Adaptation Layer (SEAL) . . . 18
3.13. Peer-to-Peer IPv6 on Any Internetwork (6bed4) . . . . . . 19
4. Related Protocols . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Tunnel Setup Protocol (TSP) . . . . . . . . . . . . . . . 20
4.2. SixXS Heartbeat Protocol . . . . . . . . . . . . . . . . . 20
4.3. Tunnel Information and Control Protocol (TIC) . . . . . . 21
5. Common Aspects . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Protocol 41 Encapsulation . . . . . . . . . . . . . . . . 22
5.2. NAT and Firewalls . . . . . . . . . . . . . . . . . . . . 22
5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . . 24
5.4. IPv4 Addresses Embedded in IPv6 Addresses . . . . . . . . 25
6. Evaluation of Tunnel Mechanisms . . . . . . . . . . . . . . . 28
6.1. Efficiency of IPv4 Address Use . . . . . . . . . . . . . . 28
6.2. Supported Network Topologies . . . . . . . . . . . . . . . 29
6.3. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 30
6.4. Gateway State . . . . . . . . . . . . . . . . . . . . . . 32
6.5. Performance . . . . . . . . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
10. Informative References . . . . . . . . . . . . . . . . . . . . 35
Appendix A. Evaluation Criteria . . . . . . . . . . . . . . . . . 401. Introduction 🦋
okay so during the move from IPv4 to IPv6, IPv6 islands are basically floating in a giant sea of IPv4 🌊 Tunnels are how those islands talk to each other. They work by wrapping IPv6 packets inside IPv4 packets, like this 👇
+---------------+
| IPv4 |
| Header |
+---------------+
: Optional :
: Encapsulation :
: Header :
+---------------+ +---------------+
| IPv6 | | IPv6 |
| Header | | Header |
+---------------+ +---------------+
| Transport | | Transport |
| Layer | ===> | Layer |
| Header | | Header |
+---------------+ +---------------+
| | | |
~ Data ~ ~ Data ~
| | | |
+---------------+ +---------------+
Encapsulating IPv6 in IPv4There are SO many tunnel mechanisms that have been proposed over time it's honestly hard to keep track 😭 Some got abandoned by the community, some have known problems, and some have proven reliable. A few were built for one specific use case, and others are generic. There can be documented limitations, plus limitations that only showed up once people started deploying them 💀
This document gives an overview of the available and/or noteworthy tunnel mechanisms, so you can pick the best one for your situation ✨ That's why the discussion of each mechanism is limited to how it works and a few important details. It's not a full manual.
If you want the full details, go to the references 📚 The document only cites the most relevant ones for brevity. Those references will point you to additional specs, updates, older versions of protocol specifications, and more general background reading.
The intended audience is everyone who needs a connection to the IPv6 Internet at large, but can't use native (untunneled) IPv6 connectivity, so they need to choose a tunnel mechanism 🫶 Even so, when native IPv6 is available, it should be preferred over tunneled connectivity, per rule 7 in Section 6 of [RFC6724]. It's also meant as a quick reference for the IETF community 🧚
The scope is limited to tunnel mechanisms that give IPv6 connectivity over an IPv4 infrastructure. VPN mechanisms and security architectures like IPsec [RFC4301] are out of scope, as is IPv4-over-IPv6 tunneling 🙅♀️ Those serve a different purpose, even if they could technically be used to provide IPv6 connectivity.
Part 2 is coming up next, bestie 🎀✨
2. Terminology ✨
Okay bestie, here's the glossary! Every term is defined the way this doc uses it, so we're all on the same page 💖
Anycast: a way to offer a service from multiple locations and/or on multiple servers by giving every server the same IP address 🦋
Carrier-Grade NAT (CGN): a Network Address Translation (see NAT) device that an ISP uses so that lots of subscribers can share one IPv4 address 🌸
Dual stack (also known as "dual IP layer"): nodes run IPv4 and IPv6 side by side. They can talk to other dual stack nodes (using IPv4 or IPv6), to IPv4-only nodes (using IPv4), and to IPv6-only nodes (using IPv6). Most current operating systems are set up to use IPv4 when it's available and IPv6 when it's available too, so they can run in IPv4-only, IPv6-only, or dual stack mode depending on what's going on. Apart from a few things about the Domain Name System (DNS), there's no separate spec for dual stack beyond the specs for running IPv4 and IPv6. Dual stack is one of the three IPv4-to-IPv6 transition tools; the others are translation and tunnels ✨
Encapsulation: transporting a packet as data inside another packet, like an IPv6 packet inside an IPv4 packet 🎀
Firewall: a device that selectively filters IP packets, letting some protocols through but not others. A firewall may act as a switch (operating below the IP layer) or as a router 🔥
Host: a device that communicates using the Internet Protocol and only transmits packets from its own address 🧚
ISP: Internet Service Provider; the party connecting the outside of the local network's perimeter to the public Internet 🌈
MTU: Maximum Transmission Unit, the maximum size of a packet that can be transmitted over a link (or tunnel) without splitting it into multiple fragments 💜
NAT: Network Address Translation or Network Address Translator. NAT makes it possible for a number of hosts to share a single IP address. TCP and UDP port numbers are used to tell apart the traffic to and from the different hosts served by the NAT. Protocols other than TCP and UDP may be incompatible with NAT because they lack port numbers. NAT also breaks protocols that depend on the IP addresses used in some way. Typically, NAT devices behave as a host toward the public Internet, and as a router toward the internal network 🙈
NBMA: Non-Broadcast Multi-Access. This is a network configuration where nodes can exchange packets directly by addressing them to the desired destination. However, broadcasts and multicasts aren't supported, so autodiscovery mechanisms such as IPv6 Neighbour Discovery must be modified to use unicast to work 🫶
Node: a device that implements IP, either a host or a router; also known as a system. See note at "NAT" 🍓
Path stretch: the difference between the shortest path through the network and the path that (tunneled) packets actually take 🌸
PMTUD: Path MTU Discovery, a method to determine the smallest MTU on the path between two nodes. There are separate specifications for PMTUD over IPv4 [RFC1191] and IPv6 [RFC1981] 👑
Router: a device that forwards IP packets that it didn't generate itself. See note at "NAT" 🦋
System: a device that implements IP, either a host or a router; a network node ⭐
Translation: the IPv6 and IPv4 headers are similar enough that it's possible to translate between them. This allows IPv6-only hosts to communicate with IPv4-only hosts. The original specification for translating between IPv6 and IPv4 was heavily criticised by the Internet Architecture Board, but new specifications for translating between IPv6 and IPv4 were later published [RFC6145]. Translation is one of the three IPv4-to-IPv6 transition tools; the others are dual stack and tunnels 💅
Tunnel: by encapsulating IPv6 packets inside IPv4 packets, IPv6-capable hosts and IPv6-capable networks that are isolated from other IPv6-capable systems or the IPv6 Internet at large can exchange IPv6 packets over IPv4-only infrastructure. There are numerous ways to tunnel IPv6 over IPv4, and this document compares these mechanisms. Tunneling is one of the three IPv4-to-IPv6 transition tools; the others are translation and dual stack 🌈
Tunnel broker: a service that provides tunneled connectivity to the IPv6 Internet, such as SixXS [SIXXS], tunnelbroker.net [TUNBROKER], and gogo6 [GOGO6] 💖
3. Tunnel Mechanisms 🧚
Okay so the big tunnel crew is: automatic tunnels (Section 3.2), configured tunnels (Section 3.1), 6over4 (Section 3.3), 6to4 (Section 3.5), the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) (Section 3.7), and 6rd (Section 3.9). They all solve similar problems at different scales 🎀 They all wrap IPv6 packets right inside an IPv4 packet, with no extra headers in between. This is called "protocol 41 encapsulation" (see Section 5.1), because the Protocol field in the IPv4 header is set to 41 to say "hey, an IPv6 packet is coming" 💅
6to4, 6rd, ISATAP, and automatic tunneling each generate an IPv6 address or range of IPv6 addresses for the host or router running the protocol, based on the system's IPv4 address somehow (see Section 5.4). That's the magic bit, because it lets them figure out the IPv4 destination address in the outer IPv4 header from the IPv6 address of the destination. So it works automatically, and nobody has to manually configure the remote tunnel endpoint 🦋
6over4 and ISATAP give IPv6 connectivity between IPv6-capable systems inside a single organisation's network that is otherwise IPv4-only. 6rd lets ISPs give their customers IPv6 connectivity over IPv4-only last-mile infrastructure. 6to4 directly connects you to the global IPv6 Internet without involving an ISP 🌸
Configured tunnels (Section 3.1) also use protocol 41 encapsulation, but they rely on manual configuration of the remote tunnel endpoint. (The Heartbeat Protocol (Section 4.2) solves this.) Configured tunnels can be used within an organisation's network, but they're typically used by tunnel-broker services to give people connectivity to the IPv6 Internet. GRE (Section 3.4) is similar to configured tunnels, but it also supports encapsulating protocols other than IPv6 🍓
AYIYA (Section 3.6) is similar to configured tunnels and GRE, but it typically uses a UDP header for better compatibility with NATs. It's generally used with the Tunnel Information and Control (TIC) protocol (Section 4.3) to set up the tunnel, rather than relying on manual configuration 🫶 Teredo (Section 3.8), 6a44 (Section 3.10), and 6bed4 (Section 3.13) are similar to 6to4, except they're designed to work through NATs by running over UDP. Of these, Teredo and 6bed4 assume no ISP involvement, and 6a44 does involve one. 6bed4 is designed to work over direct IPv4 paths between peers whenever possible 👑
The Locator/ID Separation Protocol (LISP) (Section 3.11) is a system for separating the identifying function from the location function of IP addresses. That allows IPv6 to be used for the former and IPv4 for the latter 🌈
The Subnetwork Encapsulation and Adaptation Layer (SEAL) (Section 3.12) and its companion technologies (Virtual Enterprise Traversal (VET), Asymmetric Extended Route Optimization (AERO), Internet Routing Overlay Network (IRON), and Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)) provide a configured tunnel system for IPv6-in-IPv4 tunneling to default routers, as well as automatic tunnel endpoint discovery for optimisation of more-specific routes 💜
Dual-Stack Lite [RFC6333] and MAP [MAP], both developed by the IETF Softwire working group, often come up in discussions about IPv6 tunneling. But they are not IPv6-in-IPv4 tunnel mechanisms. They're IPv4-in-IPv6 mechanisms for providing IPv4 connectivity over an IPv6 infrastructure. Plot twist 🙈
Please refer to Section 5 for more information about issues common to many tunnel mechanisms. Those issues aren't discussed separately for each mechanism. The mechanisms are discussed below in roughly chronological order ⭐
3.1. Configured Tunnels (Manual Tunnels / 6in4) 🎀
Configured and automatic tunnels are the two oldest tunnel mechanisms. They were originally published in "Transition Mechanisms for IPv6 Hosts and Routers" [RFC1933] in 1996. The latest spec for configured tunnels is "Basic Transition Mechanisms for IPv6 Hosts and Routers" [RFC4213], published in 2005. This mechanism is sometimes called "manual tunnels", "static tunnels", "protocol 41 tunnels", or "6in4" ✨
Configured tunnels connect two systems in a point-to-point fashion using protocol 41 encapsulation. The configuration that the name of the mechanism alludes to consists of a remote "tunnel endpoint" 🧚
This is the IPv4 address of the system on the other side of the tunnel. When a system (potentially) has multiple IPv4 addresses, the local tunnel endpoint address may also need to be configured 🌈
Setting up configured tunnels explicitly makes them harder to deploy than automatic mechanisms. But because there's a fixed, single remote tunnel endpoint, performance is predictable and the tunnel is easy to debug 💅
In the early days, it wasn't unheard of for a small network to get IPv6 connectivity from another continent. This excessive path stretch makes communication over short geographic distances much less efficient, because the distance travelled by packets may be larger than the geographic distance by an order of magnitude or more. Yikes 💀
Configured tunnels are widely implemented. Common operating systems can terminate configured tunnels, and so can IPv6-capable routers and home gateways. The mechanism is versatile, but it's mostly used between isolated smaller IPv6-capable networks and the IPv6 Internet, often through a "tunnel broker" such as tunnelbroker.net [TUNBROKER], SixXS [SIXXS], or gogo6 [GOGO6] 🦋
[RFC4891] discusses the use of IPsec to protect the confidentiality and integrity of IPv6 traffic exchanged over configured tunnels 🔥
3.2. Automatic Tunneling 🍓
Automatic tunneling is described in [RFC2893], "Transition Mechanisms for IPv6 Hosts and Routers", but it was removed in [RFC4213], which is a replacement of RFC 2893. Configured tunnels (Section 3.1) are closely related to automatic tunnels, and they're specified in RFCs 2893 and 4213 too. Both use protocol 41 encapsulation 🫶
Hosts that are capable of automatic tunneling use special IPv6 addresses: IPv4-compatible addresses. An IPv4-compatible IPv6 address consists of 96 zero bits followed by the system's IPv4 address. When sending packets to destinations within the IPv4-compatible ::/96 prefix, the IPv4 destination address in the outer IPv4 header is taken from the IPv4 address in the IPv4-compatible IPv6 destination address 👑
Automatic tunneling has a big limitation: it only allows communication between IPv6-capable systems that both support automatic tunneling. There are no provisions for talking to the native IPv6 Internet. So the mechanism is of almost no practical use and isn't implemented in current operating systems. 6to4 (Section 3.5) does what automatic tunneling was supposed to do, but it also gives you connectivity to the rest of the IPv6 Internet 🌸
3.3. IPv6 over IPv4 without Explicit Tunnels (6over4) 🦋
okay so "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels" [RFC2529] dropped in 1999, and the mechanism is commonly called "6over4" ✨
6over4 is built for a single organisation's IPv4 network, where IPv6-capable hosts and routers are separated by IPv4-only routers. It treats the IPv4 network like a "virtual Ethernet" for IPv6 communication 💅. It uses IPv4 multicast to tunnel IPv6 multicast packets. A node's IPv4 address gets baked into the Interface Identifier on the virtual 6over4 interface, so protocol 41 encapsulated packets can flow between 6over4 nodes with no prior administrative configuration 🧚.
Because multicast is supported, standard IPv6 Neighbour Discovery and Stateless Address Autoconfiguration [RFC4862] can be used. Here's the twist, bestie 👀: like automatic tunnels (Section 3.2) and other mechanisms, 6over4 embeds the host's IPv4 address in the IPv6 address. But the destination IPv4 address in the outer IPv4 header is not derived from the IPv6 address in the inner IPv6 header. It's learnt through Neighbour Discovery [RFC4861] instead. So the IPv4 addresses of the hosts act as link-layer addresses, the same way Media Access Control (MAC) addresses work on Ethernet networks 🎀.
One or more routers with connectivity to the global IPv6 Internet send out Router Advertisements, which give 6over4 hosts connectivity to the rest of the IPv6 Internet 🌈.
6over4 has minimal overhead for protocol 41 encapsulation and doesn't need manual configuration. Hosts can only take advantage of 6over4 if they run the mechanism themselves. 6over4 packets can't pass through a NAT successfully, ngl 💀. The IPv4 address exchanged through Neighbour Discovery will be different from the one needed to reach the host, and protocol 41 has no port numbers, so it can't multiplex multiple hosts behind a single IPv4 address. However, 6over4 works within IPv4 domains that sit behind a NAT in their entirety and use RFC 1918 addressing 🌸.
Because it relies on IPv4 multicast, and local IPv6 communication is pretty easy to set up using IPv6 routers, 6over4 is not supported in current operating systems 😭. ISATAP (Section 3.7) provides very similar functionality without requiring IPv4 multicast capability, and it's implemented way more widely ✨.
3.4. Generic Routing Encapsulation (GRE) 🍓
Generic Routing Encapsulation (GRE) [RFC2784] is a generic point-to-point tunnel mechanism that lets many other protocols get encapsulated in IP.
GRE is a simple protocol, lowkey similar to configured tunnels (Section 3.1) when used for IPv6-in-IPv4 tunneling. Its main perk is that it can encapsulate any protocol's packets, not only IPv6 💜. The GRE header adds an extra overhead of 8 to 16 bytes depending on which options are used. GRE sets the Protocol field in the IP header to 47.
The GRE header can optionally contain a checksum, a key to separate different traffic flows (for example, different tunnels) between the same endpoints, and a sequence number that can be used to prevent packets from being processed out of order 🔥.
GRE is implemented in many routers, but not in most consumer-level home gateways or desktop operating systems 🥲.
3.5. Connection of IPv6 Domains via IPv4 Clouds (6to4) 🌸
6to4 is specified in "Connection of IPv6 Domains via IPv4 Clouds" [RFC3056]. It creates a block of IPv6 addresses from a locally configured IPv4 address by concatenating that IPv4 address to the prefix 2002::/16, which gives you a /48 IPv6 prefix. Addresses in 2002::/16 are considered reachable through the tunnel interface, so the 6to4 network functions as a Non-Broadcast Multi-Access (NBMA) network where 6to4 users can communicate with each other. IPv6 packets are encapsulated by adding an IPv4 header with the Protocol field set to 41 ✨.
The /48 prefix lets a single system running 6to4 act as a gateway or router for a large number of IPv6 hosts. Or an individual host can run 6to4 and not act as a gateway or router, which is giving main character energy too 👑. The system running 6to4 must have a globally reachable IPv4 address. Using 6to4 with a private IPv4 address [RFC1918] is not possible 🙅♀️.
"An Anycast Prefix for 6to4 Relay Routers" [RFC3068] specifies an anycast mechanism for 6to4 relays that provide connectivity between the 6to4 network and the regular IPv6 Internet. All public relays share the IPv4 address 192.88.99.1, which corresponds to 2002:c058:6301::. Relays advertise reachability towards 2002::/16 to the native IPv6 Internet, so packets addressed to systems using 6to4 addresses get routed to the closest gateway. The gateway encapsulates these packets and forwards them to the IPv4 address included in the IPv6 address. Systems running 6to4 have a default route pointing to 2002:c058:6301::, so they tunnel packets addressed to non-6to4 IPv6 destinations to the closest relay, which decapsulates the packet and forwards it as an IPv6 packet 🧚.
The 6to4 protocol adds minimal overhead for protocol 41 encapsulation and requires no manual configuration from users. The biggest problem specific to 6to4 is that it's unpredictable which 6to4 anycast relay gets used. These relays are often provided by third parties on a best-effort basis, and in practice this has caused unpredictable performance 😩. Traffic from the 6to4 network to the regular IPv6 Internet will likely use a different 6to4 relay than the traffic going the other way. If either of those relays isn't reliable, the communication between those networks gets affected. Especially the lack of control over the relay used for return traffic is considered to be a problem with 6to4 🫠.
To avoid problems with 6to4, the IPv6 Default Address Selection algorithm [RFC6724] gives IPv4 addresses a higher preference than 6to4 addresses. When making a connection, a system will prefer native IPv6 over IPv4, and IPv4 over 6to4 IPv6. This means 6to4 only gets used when a destination isn't reachable over IPv4 and no other IPv6 connectivity is available 💅.
For more information about 6to4, see "Advisory Guidelines for 6to4 Deployment" [RFC6343] 📚.
Warning: Although many, if not all, 6to4 implementations disable the mechanism when the system only has an RFC 1918 address, a block of IPv4 addresses has recently been set aside for use in service-provider-operated Network Address Translators, also known as Carrier-Grade NATs (CGNs). [RFC6598] sets aside the block100.64.0.0/10for use between CGNs and subscriber devices. As100.64.0.0/10is not an RFC 1918 address block, systems implementing 6to4 may fail to disable the mechanism. But due to the shared nature of the100.64.0.0/10prefix, 6to4 cannot work using these addresses. The same issue is present if an ISP decides to use regular global unicast IPv4 address space behind a CGN 💀.
3.5.1. 6to4 Provider Managed Tunnels 🎀
[RFC6732] describes "6to4 provider managed tunnels", which are a way to make 6to4 work behind a CGN. This is accomplished by running a 6to4 gateway at the 6to4 gateway anycast address, and then translating the IPv6 addresses used by 6to4 users behind the CGN into IPv6 addresses from the ISP's range. Unlike IPv4 NAT, where multiple internal hosts share a single public IPv4 address, prefix translation maps entire prefixes. So each host has its own public IPv6 address and can receive incoming packets as usual 🦋.
However, if IPv6 applications aren't aware that translation is happening (and they have no reason to expect that it is), they may not use their externally visible address in referrals, so applications that use referrals are likely to fail 😬. Additionally, the translation is only specified for packets that flow through the 6to4 gateway, not for packets sent directly to other 6to4 users. So communication with other 6to4 users is not possible. As such, the use of 6to4 provider managed tunnels is discouraged except as a very last resort 🚫.
3.6. Anything In Anything (AYIYA) 🧚
AYIYA [AYIYA] is designed for use by the SixXS [SIXXS] tunnel-broker service. For more information, see the specification [MASSAR] 📖.
The AYIYA protocol defines a method for encapsulating any protocol in any other protocol. The most common way of deploying AYIYA is to use the following sequence of headers: IPv4-UDP-AYIYA-IPv6. Other combinations like IPv4-AYIYA-IPv6 or IPv6-SCTP-AYIYA-IPv4 are also possible. That document doesn't limit the contents nor the protocol that carries the AYIYA packets. In this document, we only look at the most common usage (IPv4-UDP-AYIYA-IPv6), which is deployed on the SixXS tunnel brokers to provide IPv6 access to clients behind NAT devices 🌈.
AYIYA specifies the encapsulation, identification, checksum, security, and certain management operations that can be used once the tunnel is established. It does not specify how the tunnel configuration parameters can be negotiated. Typically, the TIC protocol described in Section 4.3 is used for that part of the tunnel setup, although the Tunnel Setup Protocol (TSP) (Section 4.1) could just as well be used 🛠️.
AYIYA provides a point-to-point tunnel, over which the endpoints can route traffic for any source and destination. When using SHA-1 hashing for authentication, as is common when using the Automatic IPv6 Connectivity Client Utility (AICCU) client with a SixXS tunnel server, the total packet overhead is 72 bytes (20 for the IPv4 header, 8 for UDP, and 44 for AYIYA) 🍓.
AYIYA provides operational commands for querying the hostname, address, contact information, software version, and last error message. There's also an operational command to ask the other side of the tunnel to shut down. These commands in the protocol can make debugging AYIYA tunnels easier, if the tools support them 🔍.
The main advantage of AYIYA is that it can provide a stable tunnel through an IPv4 NAT. The UDP port numbers allow multiple AYIYA users to share a single IPv4 address behind a NAT 💖.
The client contacts the tunnel server at regular intervals, and the tunnel server automatically adapts to changing IPv4 addresses and/or UDP port numbers. To prevent a third party from injecting rogue packets into the tunnel, the client can optionally be authenticated by using the identity and signature fields. A timestamp is included in the AYIYA header to guard against replay attacks 🛡️.
There is currently a single implementation of this protocol: the AICCU [AICCU] client software used with the SixXS [SIXXS] tunnel-broker service 👑.
3.7. Intra-Site Automatic Tunnel Addressing (ISATAP) 🧚
okay so ISATAP ([RFC5214]) uses protocol 41 encapsulation to get isolated IPv6-capable nodes talking to each other inside an organisation's internal network 🏢✨ it's giving 6over4 (Section 3.3) but with one big glow-up: it doesn't need the IPv4 network to support multicast 🙌 the catch is that ISATAP uses a Non-Broadcast Multi-Access (NBMA) communication model, so it doesn't do multicasts at all 💀 the addressing is also super specific: the Interface Identifier is made up entirely of a node's IPv4 address, and the mechanism just assumes that IPv4 address is unique 🫶
to get a /64 prefix, an ISATAP host has to send a unicast Router Solicitation and then wait for a unicast Router Advertisement from an ISATAP router 🥺 since it can't send or receive IPv6 multicasts, the host needs a Potential Router List set up through an all-IPv4 method like manual setup, DHCP, or the DNS 🎀 site admins are encouraged to use a DNS Fully Qualified Domain Name following the "isatap.domainname" pattern, like isatap.example.com 💅 and hosts will accept packets whose IPv4 sender addresses are either on the Potential Router List or embedded in the IPv6 sender address 🦋
the router's prefix plus the IPv4 address together make the IPv6 address for the ISATAP interface, which means there's exactly one ISATAP address for each IPv4 address 😭 so every host has to run ISATAP itself if it wants ISATAP IPv6 connectivity, no exceptions 🙈 the IPv4 address sitting in the destination IPv6 address is what bootstraps Neighbour Discovery ✨
[RFC5214] doesn't explicitly cover ISATAP with private RFC 1918 addresses 🤔 but honestly the mechanism seems compatible with them anyway 🌸 the plot twist is NAT, which breaks the link between the IPv4 address embedded in the IPv6 address, so ISATAP hosts literally couldn't talk to each other 💀 any device that can reach the ISATAP hosts over IPv4 using protocol 41 can join the IPv6 subnet, which is very main character energy 👑
ISATAP is available in Windows, Linux, and Cisco IOS 🌈
3.8. Tunneling IPv6 over UDP through NATs (Teredo) 🦋
okay Teredo is specified in [RFC4380] plus a few updates, and it's designed as an automatic tunnel mechanism of last resort 🥹 it can configure an IPv6 address behind most NAT devices, but not all of them, so it's not a sure thing 💀 because Teredo uses encapsulation in UDP, multiple Teredo clients can be active at the same time behind the same NAT 🙌 each Teredo client gets a single IPv6 address, and that costs a single external UDP port 🫶
Teredo works off a classification of NAT [RFC3489] that gets established during an interaction with a Teredo server 🔍 but that classification has since been obsoleted (by [RFC5389]) because it assigns more properties to NAT than actually happen in reality 😤 which is so real
Teredo is present in Windows XP and later, and it's enabled by default in Windows Vista and later 🪟 however, if IPv6 connectivity is only possible through Teredo, then Windows won't look up AAAA records when resolving domain names 😭 so Teredo only gets used to connect to explicit IPv6 addresses that were obtained some other way than DNS 🎀 there's also an open-source implementation called Miredo for other platforms 🌸
the performance of Teredo is noticeably worse than IPv4 💅 setting up a connection means finding a Teredo relay nearby the native address to encapsulate and decapsulate traffic, and that search can take in the order of seconds ⏳ it's also not very reliable: Teredo fails in about 37% [TERTST] of its attempts to connect to native IPv6 destinations 💀 the roundtrip time can add tenths of a second, and jitter generally gets worse if the traffic depends on a public relay 🙈
Teredo clients need to be configured with a Teredo server when they set up their local IPv6 address and when they start a connection to a native IPv6 destination ✨ the hostnames of those Teredo servers are usually preconfigured by whoever made the Teredo implementation, and all Microsoft Windows implementations use the Microsoft-provided Teredo servers by default 🪟💜
3.9. IPv6 Rapid Deployment (6rd) 🍓
6rd [RFC5969] is used by service providers to connect customer networks behind a CPE (Customer Premises Equipment) to the IPv6 Internet 🌐
the structure of 6rd is based on 6to4, and it has the same minimal overhead as all protocols that use protocol 41 encapsulation 🫶 the main differences are that 6rd is meant to be used inside a service provider's network, and it doesn't use a special IPv6 prefix; it uses one or more prefixes routed to the service provider instead 🌸 that means 6rd users aren't immediately recognisable by their IPv6 address the way 6to4 users are 🕵️♀️ where 6to4 uses relays based on global anycast routing, 6rd uses relays provided and maintained by the service provider 💅 because of this setup, the tunnel doesn't traverse unknown networks, which makes debugging way easier 🙌
6rd is completely stateless once it's configured 🧚 that means the tunnel endpoints can be deployed using anycast, which is commonly done for the 6rd border relays the service provider deploys to get redundancy ✨
since the prefix is different, the 6rd client can't use the hard-coded IPv6 prefix calculation and relay addresses that 6to4 uses 😭 instead, the 6rd client needs to receive configuration information to work at all 🥺 in principle, 6rd nodes can be configured in a bunch of ways, and the most common one is DHCP 🎀 if the client gets its IPv4 address from a DHCPv4 server, then the 6rd configuration can be included in the DHCP message exchange using the 6rd DHCPv4 Option defined in [RFC5969] 🫶 manual configuration of 6rd options, and configuration using [TR-069], are also possible 💜
the big advantage of 6rd is that it lets service providers deploy IPv6 on last-mile access networks that for some reason can't provide native IPv6 connectivity 🌈 it also doesn't share 6to4's lack of predictable routing, because all routing, encapsulation, and decapsulation are handled by the service provider 👑
6rd is intended to be a service managed by an ISP or enterprise IT department, and that department has to explicitly make 6rd available for clients before they can use it 🔥
3.10. Native IPv6 behind NAT44 CPEs (6a44) 🍓
inspired by Teredo, the 6a44 tunnel is described in "Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)" [RFC6751] ✨ its whole purpose is to let Internet Service Providers set up IPv6 connectivity for their customers, even when the customer has a CPE or home gateway that isn't ready for IPv6 🏠 the infrastructure needed is a 6a44 relay in the ISP's network and a 6a44 client in the customer's internal network 🫶
6a44 was explicitly designed to fix the problems with Teredo 🙌 where Teredo was a global solution with no dependency on ISP cooperation, the 6a44 tunnel explicitly assumes the ISP cooperates 🤝 instead of Teredo's well-known prefix, a /48 prefix out of the ISP's address space gets used 🎀 a well-known (anycast) IPv4 address has been assigned to the 6a44 relay, which runs inside the ISP network, and clients don't need to configure it 🌸 that well-known address comes from the same IPv4 /24 as 6to4 💅
as part of its bootstrapping, a 6a44 client requests an address from the 6a44 relay 🧚 a regular keepalive sent by the 6a44 client to the 6a44 relay keeps the mapping state alive in NATs and firewalls on the path ✨ traffic going from the native IPv6 Internet to 6a44 gets encapsulated in UDP and IPv4 by the relay and decapsulated by the 6a44 client, and the opposite happens in the other direction 🦋
3.11. Locator/ID Separation Protocol (LISP) 👑
the Locator/ID Separation Protocol (LISP) [RFC6830] separates the identity of systems from their location on the Internet and/or internal network 🗺️ the addresses of the systems are called Endpoint Identifiers (EIDs), and the addresses of the gateways are called Routing Locators (RLOCs) 💜 it's possible to use IPv6 EIDs with IPv4 RLOCs, and that's how you use LISP for tunneling IPv6 over IPv4 🙌
LISP defines its own packet formats for encapsulating data packets and for control messages 📦 all of those packets then get encapsulated in UDP 💅 data packets use port 4341, and control packets use port 4342 🎀
the LISP specification is made up of several RFCs 📚 the relevant ones for IPv6-in-IPv4 tunneling are the base specification [RFC6830], "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites" [RFC6832], and "Locator/ID Separation Protocol (LISP) Map-Server Interface" [RFC6833] 🫶
here's what a LISP deployment looks like 👀
+----+ +----+
| MS | | MR |
+----+ +----+ +-----+ /-----------\
| | /---| xTR |---| LISP site |
+------+ /------------\---/ +-----+ \-----------/
| PxTR |---| IP network |
+------+ \------------/---\ +-----+ /-----------\
| \---| xTR |---| LISP site |
/---------------\ +-----+ \-----------/
| Non-LISP site |
\---------------/
An Example of a LISP DeploymentLISP brings its own new terminology and concepts 🧠 the relevant ones for this document are:
- ITR: Ingress Tunnel Router, a router encapsulating data packets at the border of a LISP site 📥
- ETR: Egress Tunnel Router, a router decapsulating data packets at the border of a LISP site 📤
- xTR: A router performing both the ITR and the ETR functions 🔄
- PITR: Proxy ITR, a router accepting traffic from non-LISP sites, encapsulating it, and tunneling it to the LISP sites 🧚
- PETR: Proxy ETR, a router accepting traffic from LISP sites to send it to non-LISP sites 🪄
- PxTR: A router performing both the PITR and the PETR functions 💫
- MS: Map Server, a server accepting RLOC registrations from ETRs 🗂️
- MR: Map Resolver, a server that can resolve queries for RLOCs from ITRs 🔎
LISP ETRs register the EID prefixes they can handle traffic for with one or more Map Servers 📝 ITRs and PITRs can then query Map Resolvers to figure out which RLOCs to use when sending traffic to a LISP site 🔍 PITRs advertise aggregates of EID prefixes to the global routing table and provide tunneling services for them, so non-LISP sites can reach LISP sites 🌍 PETRs give LISP sites a way to send traffic to non-LISP sites 🫶
ngl LISP is a complex protocol if you only use it for tunneling 😭 but some features make it worth it: ETRs can advertise their own RLOC addresses, one site can have multiple xTRs with independent RLOCs, and the LISP site administrator can set priorities and weights for those RLOCs 💅 that gives you redundancy and explicit load balancing between RLOCs 🙌 it also allows automatic tunneling between different sites without using a PxTR, as long as both sites use Map Servers and Map Resolvers that are interconnected, for example by participating in the LISP Beta Network [LISPBETA] 🌈 to make those interconnections happen, the LISP Delegated Database Tree (DDT) system is available 🌳
LISP is implemented on most Cisco devices 🪄 there are also implementations for FreeBSD and Linux, plus a platform-independent implementation in the Python programming language 🐍 and just a heads up: for LISP to work, a mapping service not unlike the DNS has to be in place 🧚💖
3.12. Subnetwork Encapsulation and Adaptation Layer (SEAL) 🧚
okay so SEAL is giving hybrid energy 🫶 It's a hybrid configured/automatic tunneling system, which means it does both jobs. SEAL itself adds a mid-layer of encapsulation between the inner IPv6 header and the outer IPv4 header, so the stack looks like IPv4-SEAL-IPv6 🎀. It can also sit inside an outer UDP encapsulation header, for example if NAT traversal is needed 🦋
The SEAL tunnel endpoint makes bidirectional configured tunnels to reach default IPv6 routers 💅 and it discovers unidirectional automatic tunnels too. SEAL tunnels can run over multiple underlying IPv4 links, and that works whether the addresses come from public or private IPv4 addressing domains 🌈 When that happens, multihoming and traffic engineering are naturally supported. slay 👑
SEAL gives you an optional 32-bit identifier and a variable-length Integrity Check Vector. These can be used for packet identification, message origin authentication, anti-replay, and a mid-layer segmentation and reassembly capability ✨ SEAL also has its own SEAL Control Message Protocol (SCMP), which handles neighbour coordinations between tunnel endpoints. Those coordinations cover things like tunnel MTU signalling, route optimisations, neighbour reachability testing, and so on 🍓
Here's the part I'm obsessed with. SEAL makes sure packets no larger than 1500 bytes can get through the tunnel by using a tunnel segmentation function 🙈 IPv6 packets that are too big to go through whole get split into segments. The segments are encapsulated in IPv4 and then reassembled into the original IPv6 packets at the remote tunnel endpoint. SEAL also lets packets bigger than 1500 bytes into the tunnel on a best-effort basis, in case the path between the endpoints can handle the larger size 💖
When SEAL is used alone, without its companion technologies, it can be used in the same scenarios as GRE. But SEAL has advanced capabilities that make it better suited than GRE for lots of use cases 🔥 There is currently an experimental open-source implementation of SEAL 🫶
3.13. Peer-to-Peer IPv6 on Any Internetwork (6bed4)
The 6bed4 tunnel is specified in "6bed4: Peer-to-Peer IPv6 on Any Internetwork" [6BED4] 🦋 The big goal of 6bed4 is direct communication between peers, as long as the intermediate infrastructure doesn't block it. Why do we care? Direct communication gets you performance similar to IPv4, which is so iconic 💅
A 6bed4 peer's address is formed from its publicly visible IPv4 address and UDP port 🧚 The tunnel service used for fallback connectivity can run anywhere. It could be at the local ISP, a third-party service provider for 6bed4, or even on a well-known address. Right now it's an NBMA protocol, but there are openings for expansion with multicast 🌸
6bed4 is kind of like 6to4, except it uses UDP, so it works behind NAT 🎀 It also has bits of Teredo, but without needing to classify NATs and induce behaviour from that. 6bed4 makes no assumptions about NAT devices beyond being able to do straightforward NAT on UDP packets. Given that, 6bed4 can create reliable IPv6 tunnels ✨
When direct connections between 6bed4 peers are possible, extra path stretch compared to IPv4 communication is avoided, so 6bed4 performance gets close to IPv4 performance 🔥 If the direct path between two peers can't be used because a NAT that does not conform to [RFC4787] is on the path, a fallback to a tunnel server happens. That adds path stretch and affects scalability through its impact on roundtrip times and jitter 😭
The tunnel server is also needed for connectivity between 6bed4 peers and native IPv6 hosts. For performance and scalability reasons, connections between 6bed4 peers are preferred over connections between a 6bed4 peer and a native IPv6 host 💜 A default address exists to support zero-config operation. You can also configure a tunnel server locally as a fallback route, and that then also defines the tunnel server for the return path 🍓
6bed4 was specifically designed to support real-time interactive traffic streams, such as SIP calls, between 6bed4-supporting endpoints 📞 That works assuming each one prefers 6bed4-to-6bed4 traffic over 6bed4-to-native traffic. Under that premise, the only hosts that need a tunnel server are the ones behind a NAT with Address-Dependent Mapping or Address and Port-Dependent Mapping. A number of different 6bed4 implementations have been built [6BED4] during the ongoing development of its specification 👑
4. Related Protocols 🎀
The following protocols aren't tunnel mechanisms, but they can be used in the configuration and/or setup phase of such protocols 🧚
4.1. Tunnel Setup Protocol (TSP)
The Tunnel Setup Protocol [RFC5572] is a protocol for negotiating the setup of a variety of tunnel encapsulations 💅 For this document, we only care about IPv6 in IPv4. The Tunnel Setup Protocol can negotiate those as a protocol 41 encapsulated tunnel or as a UDP-encapsulated tunnel. The negotiation is an XML exchange over UDP or TCP 🫶
A TSP client exchanges all its IPv6 traffic with the same tunnel server, so there are no concerns caused by NAT implementations 🙌 The only thing to worry about is sending regular keepalives, and ICMPv6 ping messages to the tunnel server are suggested for that. When you encapsulate IPv6 packets directly in IPv4, all protocol 41 limitations apply 😬 To avoid those, an additional UDP header may be used.
Here's the tea ☕ The Tunnel Setup Protocol treats all protocols and ports for one IPv4 client address as equivalent. That's fine when protocol 41 is used, but for UDP it creates a situation where one user can set up a tunnel behind NAT, and another user could hijack the tunnel privileges 💀
Open-source clients for the Tunnel Setup Protocol, plus a matching tunnel infrastructure, come from the Freenet6 tunnel service [GOGO6] 🌈
4.2. SixXS Heartbeat Protocol
The SixXS Heartbeat Protocol [HEARTBEAT] lets nodes with intermittent connectivity, or a dynamic IPv4 address that changes from time to time, keep tunneled IPv6 connectivity going 🦋 One goal is to figure out when a node is no longer at its previous IPv4 address. Then the protocol stops sending tunneled packets, so they don't get delivered to the wrong node 🙈 The Heartbeat Protocol also lets a tunnel broker work out a client's new IPv4 address and keep sending tunneled packets with minimal interruption ✨
Here's how it works. A node sends periodic heartbeat packets to the tunnel broker. If the tunnel broker doesn't receive valid heartbeat packets, it shuts down the tunnel in question 🔥 Heartbeat packets contain an MD5 message authentication code and a timestamp to avoid replay attacks. The Heartbeat Protocol can work with different tunnel mechanisms, but it's often used with configured tunnels (Section 3.1) 💜
The protocol is implemented in the SixXS tunnel broker, and client implementations are available for common operating systems 🎀 AYIYA can be considered the successor of the Heartbeat Protocol 👑
4.3. Tunnel Information and Control Protocol (TIC)
The Tunnel Information and Control (TIC) protocol [TIC] is the setup protocol for the [SIXXS] tunnel-broker service 🧚
With TIC, a tunnel-broker user can request a list of available tunnels and points of presence (POPs) from the tunnel-broker service 🌸 When the user picks one of the tunnels, its configuration parameters can then be requested through TIC. TIC also has commands to control the tunnel. For example, you can change the tunnel endpoints or enable or disable the tunnel 💅
Users are authenticated with a username and password 🔐 Certain tunnel mechanisms, like AYIYA (Section 3.6) and configured tunnels (Section 3.1) with heartbeat (Section 4.2), need a synchronised clock between the tunnel server and the client ⏰ TIC helps with this by providing a server timestamp on request. The client can use that to check that its clock is synchronised with the server, and it shows an error message to the user if it isn't 🙈
The TIC protocol is implemented in the AICCU client software (see [AICCU]) and in AVM Fritz!Box home routers 🏠
5. Common Aspects 🌈
The following are aspects common to many or all tunnel mechanisms 💖
5.1. Protocol 41 Encapsulation
The most straightforward way to put an IPv6 packet inside an IPv4 packet is to just add an IPv4 header in front of the IPv6 header 🎀 In this case, the Protocol field in the IPv4 header is set to the value 41. This encapsulation is also known as "IPv6 in IPv4" and "IP6 Encapsulation" ✨
This simple "protocol 41" encapsulation is used by a number of tunnel mechanisms 🫶
- configured tunnels (Section 3.1) 🧚
- automatic tunneling (Section 3.2) 🦋
- 6over4 (Section 3.3) 🌸
- 6to4 (Section 3.5) 💅
- ISATAP (Section 3.7) 💜
- 6rd (Section 3.9) 👑
5.2. NAT and Firewalls ✨
okay so NATs and firewalls are lowkey obsessed with blocking protocol 41 packets 💀, especially at the border between an organisation's internal network and the public Internet. 🧱 Tunnel mechanisms that don't use protocol 41 encapsulation usually wrap things in a UDP header, so they're a bit less likely to get filtered, as long as the tunnel gets started from the LAN side 🦋 UDP usually goes through Network Address Port Translation (NAPT) [RFC2663], which also swaps internal and external port numbers 🎀 (fun fact: people say "NAT" when they really mean "NAPT" 🙈).
Protocol 41 can technically get through NAT, but there are two problems 😭. First, when the IPv6 address is built from the IPv4 address (see Section 5.4), NATing the outer IPv4 header breaks the link between the IPv4 and IPv6 addresses 💔. Second, protocol 41 doesn't use port numbers, so the number of protocol 41 tunnel endpoints you can run behind a NAT device equals its number of external IPv4 addresses (see Section 6.1) 🍓. GRE has this same limit too 🌸.
Tunnels that go through a NAT device or stateful firewall need to send traffic at regular intervals to keep the NAT or firewall mapping fresh ⏰. If the mapping gets lost, tunneled packets coming from outside can't get through until a system behind the NAT or firewall sends a tunneled packet and the mapping gets rebuilt 😤. You can also set up a static mapping manually, often as a "default" or "DMZ" host 👑.
These tunnel mechanisms are incompatible with NAT because their addresses have to come from a globally unique IPv4 address 🙅♀️:
- automatic tunneling (Section 3.2)
- 6to4 (Section 3.5)
- 6rd (Section 3.9)
- LISP (Section 3.11)
Also, it's super common to run 6to4 or 6rd on a home gateway that does IPv4 NAT too 🏠. In that setup NAT doesn't touch the tunneled packets, so NAT and 6to4/6rd can totally coexist 🫶.
These tunnel mechanisms can't work between nodes on opposite sides of a NAT, but they do work if all nodes are behind a NAT (where RFC 1918 addresses are often used) 🧚:
- 6over4 (Section 3.3)
- ISATAP (Section 3.7)
These ones may work through NAT in some situations, but they weren't designed for NAT compatibility 🤷♀️:
- configured tunnels (Section 3.1)
- GRE (Section 3.4)
These tunnel mechanisms were designed for NAT compatibility 🌈:
- AYIYA (Section 3.6)
- Teredo (Section 3.8); but it is unreliable
- 6a44 (Section 3.10)
- SEAL (Section 3.12)
- 6bed4 (Section 3.13)
The LISP spec says locator addresses (the addresses in the outer IPv4 header) are globally routable public addresses 🌍.
A tunnel built over UDP takes up a resource, namely an external UDP port 🎟️. That can affect how well the tunnel scales in an organisation. For example, if every desktop runs its own UDP tunnel client, all those claims on the resource could start to matter 💅.
Also, ISPs might have multiple subscribers share one public IPv4 address by doing NAT (Carrier-Grade NAT in this context) 🏘️. In that case, the subscribers' home gateways may get an address from the 100.64.0.0/10 block [RFC6598]. For tunnel purposes, this block is similar to the RFC 1918 address blocks 🎀. But tunnel implementations that know about NAT and RFC 1918 addresses might not recognise 100.64.0.0/10 as non-public addresses, and then they fail to work 😭. The same problem happens if an ISP decides to use regular global unicast IPv4 address space behind a CGN 🥲.
5.3. MTU Considerations
okay this part is about size limits 📦. Because of the extra IPv4 header, plus any extra headers between the IPv4 and IPv6 headers, tunnels end up with a smaller maximum packet size (MTU) than native IPv6 🦋.
Path MTU discovery (PMTUD) should handle this in almost every case 🙌. But if filtering blocks ICMPv6 "packet too big" messages, senders of large packets can't do PMTUD properly, and then communication can break 💔. Still, when a tunnel ends directly on the host that's using it, the TCP maximum segment size (MSS) option tells the remote endpoint the maximum packet size, so TCP can still work 🎀. If that doesn't happen, the initial TCP SYN/ACK exchange goes fine, but then the session freezes because the bigger packets with data get lost 🥺.
With tunnel mechanisms where the MTU isn't specified, the two endpoints can end up with different MTUs ✌️. Usually one side uses the IPv6 minimum (1280 bytes), while the other uses the physical MTU minus tunnel overhead (often 1480 bytes). In theory this should cause PMTUD failures, since the "big" side unknowingly sends packets the "small" side can't handle 😱. In practice though, implementations handle incoming packets bigger than their own MTU just fine 💖.
Issues are more likely only when the IPv4 MTU drops below 1500 bytes, for example when using PPP over Ethernet (PPPoE, [RFC2516]) 🧐. So if tunneled packets might go over a PPPoE link, it's smart to set the tunnel MTU to no more than 1472 bytes, so the tunneled packets don't have to be fragmented ✨. Also, Section 3.2.1 of [RFC4213] recommends limiting tunnel MTUs to a minimum of 1280 bytes 📏.
SEAL was specifically designed to get around these limits 🦸♀️. It can fragment IPv6 packets before encapsulating them in IPv4, and then reassemble the fragments at the remote tunnel endpoint 🧩. That way, the SEAL tunnel makes sure packets no larger than 1500 bytes reach the far end, even if there are restrictive links along the path 🚀. SEAL can also let larger packets into the tunnel on a best-effort basis, in case the path between the tunnel endpoints can handle that bigger size 👑.
5.4. IPv4 Addresses Embedded in IPv6 Addresses
okay bestie, so a LOT of tunnel mechanisms stuff IPv4 addresses (or other info) right inside the IPv6 addresses they use 🧚✨ and there are two reasons for that. 1st: if the IPv4 address is baked into the IPv6 address, the outer IPv4 header can be worked out automatically, so you don't have to manually configure tunnel endpoints 🫶. Automatic tunneling, 6to4, ISATAP, 6bed4, and Teredo all do this. 2nd reason is 6over4 🌈 it puts the IPv4 address in the Interface Identifier (and therefore in the IPv6 address), because that way you can generate a (presumably) globally unique Interface Identifier. iconic, honestly.
Automatic tunneling uses IPv4-compatible addresses in the prefix ::/96, which means the first 96 bits are all zero 🖤
| 96 bits | 32 |
+------------------------------------------------+-----------------+
| 0:0:0:0:0:0 | IPv4 address |
+------------------------------------------------+-----------------+
The IPv4-Compatible Address StructureSystems running 6to4 live in the 6to4 prefix 2002::/16 🌸
| 16 bits | 32 | 16 | 64 |
+---------+----------------+--------+------------------------------+
| 2002 | IPv4 address | Subnet | Interface ID |
+---------+----------------+--------+------------------------------+
The 6to4 Address StructureBecause a 6rd domain might share a common IPv4 prefix, you don't always need to fit all 32 bits of the IPv4 address into the 6rd delegated prefix 👀 The bits you save from this optimisation can be used to give the user more subnet IDs, and/or to use a smaller address block for the 6rd prefix. Big brain move 🧠
| n bits | o bits | m bits | 128-n-o-m bits |
+---------------+--------------+-----------+-----------------------+
| 6rd prefix | IPv4 prefix | Subnet ID | Interface ID |
+---------------+--------------+-----------+-----------------------+
|<--- 6rd delegated prefix --->|
The 6rd Address Structure6over4 uses the IPv4 address to make a 64-bit Interface Identifier, and then that can turn into a full 128-bit IPv6 address through Stateless Address Autoconfiguration ✨
| 48 bits | 16 | 32 | 32 |
+---------------------+--------+-----------------+-----------------+
| Organisation prefix | Subnet | 0:0 | IPv4 address |
+---------------------+--------+-----------------+-----------------+
The 6over4 Address StructureThe ISATAP address structure is basically the 6over4 one, with one twist 💅 the unique/local (u) bit tells you whether the IPv4 address in the Interface Identifier is unique. Presumably that's the case for any IPv4 address that isn't defined in RFC 1918. The group (g) bit is set to zero, and the remaining bits are set to 0x00005EFE 🦋
| 48 bits | 16 | 32 | 32 |
+---------------------+--------+-----------------+-----------------+
| Organisation prefix | Subnet | ug00:5EFE | IPv4 address |
+---------------------+--------+-----------------+-----------------+
The ISATAP Address StructureTeredo is a whole mood 🎀 it embeds the Teredo server's IPv4 address, a bunch of flags, a UDP port number, AND the Teredo client's IPv4 address, all packed into the IPv6 addresses it creates. For good measure, the UDP port and client IPv4 address get "obfuscated" by flipping their bits 🙈
| 32 bits | 32 | 16 | 16 | 32 |
+----------------+---------------+-------+-------+-----------------+
| 2001:0 | Server IPv4 | Flags | Port | Client IPv4 |
+----------------+---------------+-------+-------+-----------------+
The Teredo Address Structure6a44 is basically a mashup of 6rd and Teredo 💜 The 6a44 prefix comes from an ISP. Both the customer site (home gateway) IPv4 address and the host's or client's RFC 1918 IPv4 address, plus a port number, get embedded in the IPv6 address.
| 48 bits | 32 | 16 | 32 |
+----------------------+-----------------+-------+-----------------+
| 6a44 prefix | Cust. site IPv4 | Port | Client IPv4 |
+----------------------+-----------------+-------+-----------------+
The 6a44 Address Structure6bed4 embeds two combos of an IPv4 address and UDP port (together they act as a "6bed4 address") in the IPv6 address 🧚 The first one is for a tunnel server that everyone is certain to reach. The other is the direct address that most peers should be able to reach directly. Plot twist: the tunnel server is the only one with guaranteed access to the direct address 👀
| 32 bits | 32 | 50 | 14 |
+----------+---------------------+-------------------------+-------+
| prefix |general 6bed4 address| direct 6bed4 address | lanIP |
+----------+---------------------+-------------------------+-------+
The 6bed4 Address StructureThe general 6bed4 address field hides the well-known UDP port for the 6bed4 service 🤫 The direct 6bed4 address field has two extra bits so it follows the EUI-64 address format. And the lanIP bits are free for local stuff, like making a DHCPv6 range 🍓
6. Evaluation of Tunnel Mechanisms
okay now we're getting into the part where we actually compare these tunnel mechanisms so you can pick the right one 💅 The following subsections cover the different aspects of tunnels that guide that selection.
6.1. Efficiency of IPv4 Address Use
so IPv4 space is running out (we all know 😭), and that makes a couple of things super important: whether you can deploy a tunnel mechanism behind NAT, and how many IPv6 subscribers, subnets, and individual hosts you can support behind one single IPv4 address 🔥
These issues don't matter for tunnel mechanisms that give IPv6 connectivity between hosts in the same administrative domain, like ISATAP or 6over4, since they can use private IPv4 addresses 🫶 The same goes for 6rd: it's used between an ISP and its customers' home gateways when the ISP has implemented NAT.
6to4 can't work behind any kind of NAT 💀 Most other mechanisms based on protocol 41 can work behind NAT, at least in principle. In practice the gap isn't as big, because protocol 41 encapsulation doesn't give any fields that let a NAT demultiplex tunneled packets. That means only a single protocol 41 tunnel endpoint can be supported for each public IPv4 address 😩
So configured tunnels (plus 6to4) are incompatible with service-provider-operated NATs, where multiple subscribers share one IPv4 address. Not the vibe 🙅♀️
Teredo, 6a44, 6bed4, AYIYA, SEAL, and TSP are designed to work through NATs and use a UDP header, so you can host multiple tunnel endpoints behind a single IPv4 address 🦋 On the other hand, Teredo only gives IPv6 connectivity to a single host. Ate the design, but it's giving limited 😅
The table below shows how many IPv4 addresses each tunnel mechanism needs and how many IPv6 hosts it can connect. The mechanisms are listed in order of increasing numbers of supported IPv6 hosts per IPv4 address 📊
+------------+-------------+-------------+-------------+------------+
| Mechanism | Tunnels per | IPv6 hosts | Public IPv4 | NAT |
| | IPv4 addr. | per tunnel | address | compatible |
+------------+-------------+-------------+-------------+------------+
| Auto. tun. | one | one | required | no |
| 6to4 | one | multiple | required | no |
| LISP | one | multiple | required | no |
| 6rd | one | multiple | not needed | no |
| Conf. tun. | one | multiple | not needed | limited |
| GRE | one | multiple | not needed | limited |
| Teredo | multiple | one | not needed | yes (*) |
| 6bed4 | multiple | multiple | not needed | yes |
| 6a44 | multiple | multiple | not needed | yes |
| AYIYA | multiple | multiple | not needed | yes |
| SEAL | multiple | multiple | not needed | yes |
+------------+-------------+-------------+-------------+------------+
Tunneled IPv6 Hosts per IPv4 Address(*) Although Teredo is designed for NAT compatibility, it doesn't
work through all existing NATs.6.2. Supported Network Topologies 🗺️
Okay so there are two ways to hook an IPv6-in-IPv4 tunnel up to the IPv6 Internet 🌐: a point-to-point tunnel to a tunnel broker or an ISP-operated gateway, or a Non-Broadcast Multi-Access (NBMA) tunnel that uses anycasted public gateways or relays 💅.
The point-to-point model is giving predictable performance and flexibility about which IPv6 addresses you get 🎀. The NBMA model's big perk is that traffic between two hosts or networks that both use the mechanism can flow directly without passing through a gateway (direct peer-to-peer, bestie 🦋). The NBMA public anycast version also has an extra bonus: automatic configuration with no ISP involvement 🌸.
Unfortunately, those perks come with a price 😭. Both the peer-to-peer connectivity between tunnel users and the connectivity towards the native IPv6 Internet can suffer from reliability and performance issues.
Anycast lets tunnel users reach the nearest gateway by simply giving every gateway the same address ✨. Routing protocols then pick the lowest-cost (and presumably, shortest) path to a gateway. But that makes the path tunneled packets take really hard to predict or influence 🙈. It's common for traffic in the two directions to use different gateways, which makes debugging even messier. Nobody is in charge of or gets paid for running a gateway, so there are fewer public gateways than would be ideal 💀. That pushes the nearest gateway farther away for some users, and gateways might also get more traffic than they can handle.
The upside of a tunnel from an ISP or tunnel broker is that there is a clear responsibility for good service, with well-maintained gateways 👑.
+------------+---------------+--------------------------------+
| Mechanism | Peer-to-peer | Gateway provided by |
+------------+---------------+--------------------------------+
| Conf. tun. | No | ISP or tunnel broker |
| AYIYA | No | ISP or tunnel broker |
| GRE | No | N/A |
| 6a44 | Within domain | ISP |
| 6rd | Within domain | ISP |
| 6over4 | Globally | N/A |
| ISATAP | Within domain | Own organisation |
| Teredo | Globally | Public |
| 6to4 | Globally | Public or ISP |
| 6bed4 | Globally | Public or ISP or tunnel broker |
| Auto. tun. | Globally | N/A |
| LISP | Configurable | ISP or tunnel broker |
| SEAL | Configurable | ISP or tunnel broker |
+------------+---------------+--------------------------------+
Topologies Supported per Tunnel Mechanism6.3. Robustness 🛡️
Tunnels may fail for three main reasons 💔: when tunneled packets are filtered, typically by a firewall; when a tunnel endpoint IPv4 address changes; or when tunneled packets are filtered or because of NAT issues.
If a tunnel endpoint gets a new address, the other side of the tunnel needs to know to send packets to the new address 📬. With mechanisms that derive IPv6 addresses from the IPv4 address, the previous IPv6 addresses become unreachable, and new IPv6 addresses must be configured 😩.
Some tunnel mechanisms don't work through NAT, or they're limited when working through NAT 🚧. NAT mappings can typically only be created by traffic from the "inside" to the "outside", not by traffic from outside the NAT to the network behind it.
Point-to-point tunnel mechanisms either work consistently or they always fail 🎯. So a simple ping to the other side of the tunnel is enough to learn its state. Point-to-point tunnels may also support routing protocols, which can automatically reroute traffic around a failed tunnel 🦋.
Some tunnel mechanisms use a public gateway to reach the native IPv6 Internet. Public gateways may or may not be operational and/or reachable, and they may have limited performance, depending on distance and usage 🥲.
Tunnel mechanisms that use a broadcast or NBMA communication model may experience failures between some combinations of tunnel endpoints and not others 🤷♀️.
The following table lists the tunnel mechanisms that provide connectivity to the IPv6 Internet, in order of decreasing robustness. (However, even the less-robust mechanisms may work well in suitable environments 💖.)
+------------+---------------+--------------------------------------+
| Mechanism | Endpoint | Main issues |
| | address | |
| | change | |
+------------+---------------+--------------------------------------+
| LISP | automatic | None |
| 6rd | interrupt | None |
| AYIYA | automatic | Transient NAT mapping issues |
| Conf. + | interrupt | Proto 41 filtering, competition for |
| Heartbeat | | NAT mappings (1) |
| Conf. tun. | failure | Proto 41 filtering, competition for |
| | | NAT mappings, address change (1) |
| GRE | failure | Proto 47 filtering, address change |
| 6a44 | interrupt | NAT mapping towards peers |
| 6bed4 | interrupt | NAT mapping towards peers |
| 6to4 | interrupt | Enabled out of the box but filtered, |
| | | gateway performance (2) |
| Teredo | interrupt | NAT compatibility, mapping towards |
| | | peers (3) |
+------------+---------------+--------------------------------------+
Susceptibility of Tunnel Mechanisms to ProblemsNotes time 📝:
(1): Only one protocol 41 tunnel endpoint can receive a NAT mapping behind a NAT that uses a single public IPv4 address. Additional endpoints won't receive incoming packets 🙅♀️. When a tunnel endpoint changes its internal address, the old NAT mapping needs to time out before a new one can be created ⏳.
(2): 6to4 implementations automatically disable the mechanism when the system has an RFC 1918 address. However, 6to4 may stay enabled and be non-operational when ISPs apply NAT using addresses that are not as defined in RFC 1918 [RFC6598] 😵💫.
(3): Whether Teredo can obtain an address depends on the type of NAT it detects. Whether Teredo works at such an address depends on how accurate that determination is, which is based on an incomplete model of NAT 🧩.
On some widely used implementations, 6to4 has been enabled by default without checking whether there was connectivity to the anycasted public gateway address. As a result, 6to4-derived connectivity to the IPv6 Internet was often broken because of protocol 41 filtering 💀. Because of this, many operating systems now try to avoid using IPv6 over 6to4. See [RFC6343].
Also see [TERTST] for more information about the robustness of Teredo 📚.
There is not a single tunnel mechanism that is more robust in every possible way than every other one 🌈. In general, though, mechanisms that use public gateways and peer-to-peer tunneling tend to have the most issues. Configured tunnels often work very well, especially if there's no NAT on the path, but they may need administrative intervention when a tunnel endpoint address changes 🔧.
6.4. Gateway State 🧠
There's one more thing that matters a lot to operators of gateways connecting IPv6-in-IPv4 tunnels to the IPv6 Internet: how much state a tunnel mechanism requires 👀.
6to4, 6rd, 6a44 and 6bed4 require no state at all 🙌. When encapsulating an IPv6 packet inside an IPv4 packet, the IPv4 destination address is directly copied from bits in the IPv6 destination address. That makes every possible tunneled destination directly reachable through a single virtual interface, which is so clean 😍.
Teredo relays maintain a list of peers and are intended to service a limited number of hosts. The Teredo server, however, is a stateless gateway component 🧚.
With configured tunnels, GRE, AYIYA and SEAL, there's no direct mapping from (part of) the IPv6 destination address to the IPv4 destination address. A typical implementation of these has a virtual tunnel interface for each tunnel, and packets get forwarded to the correct virtual interface through a routing table lookup. Routing tables can grow very large and still stay fast, so the number of virtual interfaces tends to be the limiting factor for tunnel gateways 🚦. AYIYA and the SixXS Heartbeat Protocol also keep track of the reachability status of each tunnel 💜.
6.5. Performance 🏎️
There are several reasons tunneled connectivity may perform worse than native, untunneled connectivity 🐢. Tunnels inherently add one or more extra headers, which increases overhead. However, for an Ethernet packet of maximum size (1500 bytes), the additional overhead of an IPv4 header is only 1.3% ✨.
Encapsulation isn't inherently slow, but in some implementations it can be 😬. Larger routers that normally forward packets using special-purpose hardware often don't have high-performance CPUs. If tunnel encapsulation has to be done by that relatively slow CPU, performance will be worse than regular hardware-based packet forwarding 💔.
The path tunneled packets take can be longer than the path untunneled packets would take (i.e., increased path stretch can occur) 🛣️. This may or may not lead to decreased performance.
+------------+-----------------+----------------------+-------------+
| Mechanism | Overhead | Increased path | Variability |
| | (bytes) | stretch | |
+------------+-----------------+----------------------+-------------+
| Conf. tun. | 20 | may be large | none |
| Auto. tun. | 20 | none | none |
| 6over4 | 20 | none | none |
| GRE | 28 - 36 | may be large | none |
| 6to4 | 20 | may be large | high |
| AYIYA | 72 | may be large | low |
| ISATAP | 20 | none | none |
| Teredo | 28 - 36 | may be large | high |
| 6rd | 20 | small | low |
| 6a44 | 20 - 28 | small | low |
| 6bed4 | 28 | may be large | high |
| LISP | 36 | small | low |
| SEAL | 24 - variable | small | low |
+------------+-----------------+----------------------+-------------+
Typical Tunnel Performance7. Security Considerations 🔐✨
Okay bestie, security is where things get seriously spicy 🌶️💀, so I need you to actually listen. The big one: through a tunnel, you can end up with connectivity to the IPv6 Internet even when the network admins never meant for that to happen 😱. "Security Concerns with IP Tunneling" [RFC6169] goes deep on this whole mess, so go read it if you want the full tea 🍵.
Ingress filtering (BCP 38, [RFC2827]) is technically possible with tunnels 🧐, but in practice spoofed packets slide through tunnels way too easily 🙈. It's often super easy to spoof the outer IPv4 header so fake IPv6 packets look like they came from a tunnel broker or gateway 👻. And an attacker might also be able to push false IPv6 packets through a legit tunnel broker or gateway 🚨. Some tunneling protocols have ways to detect and reject this stuff, and others have little or nothing for it 🤷♀️. For example, check [RFC3964] to see how this gets handled with 6to4 🎀.
So you have to recognise this: unless you take special measures (like [RFC4301]) 🛡️, both the IPv4 and IPv6 addresses in tunnel packets can be spoofed, which means you CANNOT rely on them for access controls 🚫. Spoofing like this was actually used successfully to discover IPv6-in-IPv4 tunnels in [TUNDISC] 🔍.
Tunnels can also get abused by third parties who want to hide what they're up to or pull off amplification attacks 💀. To avoid being part of that problem, make sure ONLY locally generated packets with legitimate addresses get sent out over tunnels 🫶.
8. Contributors 🎀
Job Snijders contributed text to the points of comparison 💜. Fred Templin provided the text for SEAL and also contributed to the security considerations 🔥. Jeroen Massar, Brian Carpenter, Tina Tsou, John Mann, Suresh Krishnan, Victor Kuarsingh, Dan Jones, Nejc Skoberne, and Fred Baker reviewed the document and/or offered suggestions for improvement 👑.
9. Acknowledgements 🌸
We wanna give a huge shoutout to SURFnet and Rogier Spoor for commissioning this work 🙌. Their initiative and funding are the reason this document got written at all 💖.
10. Informative References 📚
Here's the whole reading list, copied exactly as the original has it so nothing gets lost in translation 🧚:
[6BED4] Van Rein, R., "6bed4: Peer-to-Peer IPv6 on Any
Internetwork", Work in Progress, July 2013.
[AICCU] SixXS, "Automatic IPv6 Connectivity Client Utility
(AICCU)", <http://www.sixxs.net/tools/aiccu/>.
[AYIYA] SixXS, "Anything In Anything (AYIYA)",
<http://www.sixxs.net/tools/ayiya/>.
[GOGO6] gogo6, "Freenet6: Free and Easy IPv6 Connectivity",
<http://www.gogo6.com/freenet6>.
[HEARTBEAT] Massar, J., "SixXS Heartbeat Protocol", Work in Progress,
June 2005.
[LISPBETA] LISP4/LISP6.net, "LISP Beta Network",
<http://www.lisp4.net/beta-network/>.
[MAP] Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, "Mapping of Address and Port
with Encapsulation (MAP)", Work in Progress, August 2013.
[MASSAR] Massar, J., "AYIYA: Anything In Anything", Work in
Progress, July 2004.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 1933, April 1996.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone,
D., and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over
IPv4 Domains without Explicit Tunnels", RFC 2529,
March 1999.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP
Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.
[RFC3964] Savola, P. and C. Patel, "Security Considerations for
6to4", RFC 3964, December 2004.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition
Mechanisms for IPv6 Hosts and Routers", RFC 4213,
October 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H.
Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels",
RFC 4891, May 2007.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the
Tunnel Setup Protocol (TSP)", RFC 5572, February 2010.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
RFC 6343, August 2011.
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C.,
and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared
Address Space", BCP 153, RFC 6598, April 2012.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version
6 (IPv6)", RFC 6724, September 2012.
[RFC6732] Kuarsingh, V., Lee, Y., and O. Vautrin, "6to4 Provider
Managed Tunnels", RFC 6732, September 2012.
[RFC6751] Despres, R., Carpenter, B., Wing, D., and S. Jiang,
"Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises
Equipment (6a44)", RFC 6751, October 2012.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
January 2013.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, January 2013.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833,
January 2013.
[SEAL] Templin, F., "The Subnetwork Encapsulation and Adaptation
Layer (SEAL)", Work in Progress, October 2013.
[SIXXS] Massar, J. and P. van Pelt, "IPv6 Deployment & Tunnel
Broker", <http://www.sixxs.net/>.
[TERTST] Huston, G., "Testing Teredo", April 2011,
<http://www.potaroo.net/ispcol/2011-04/teredo.html>.
[TIC] SixXS, "Tunnel Information and Control protocol (TIC)",
<http://www.sixxs.net/tools/tic/>.
[TR-069] The Broadband Forum, "CPE WAN Management Protocol",
July 2011, <http://www.broadband-forum.org/technical/
download/TR-069_Amendment-4.pdf>.
[TUNBROKER] Hurricane Electric, "Hurricane Electric Free IPv6 Tunnel
Broker", <http://www.tunnelbroker.net/>.
[TUNDISC] Colitti, L., Di Battista, G., and M. Patrignani,
"IPv6-in-IPv4 tunnel discovery: methods and experimental
results", IEEE eTransactions on Network and Service
Management (eTNSM), vol. 1, no. 1, p. 2-10, April 2004.Appendix A. Evaluation Criteria ✨
okay so this is the part where the RFC gives us its scorecard 📋💖 every tunnel gets judged against these criteria, but not every criterion shows up in every protocol section, just the ones that actually matter for that protocol. the list is basically a checklist of "what should I be asking about this tunnel?" 🎀
- Protocol overhead 🌸: how much extra stuff does the tunnel add? two things matter here: how many back-and-forth messages it takes to set the tunnel up, and how big the packet headers are, because big headers can mean a smaller MTU and/or fragmentation 😭
- Automatic configuration 🧚: does the protocol need someone to manually configure the endpoints, or does it set itself up?
- Predictability 🔮: how predictable is it, like, does it behave the same way every time?
- Single host or network 💻: is the protocol meant for one lonely host, or for a router that gives IPv6 connectivity to a whole bunch of hosts behind it? 👑
- Load balancing ⚖️: does the tunnel traffic have enough entropy and/or "hashability" to get load-balanced across multiple links? or do all the tunnel packets have the same outer 5-tuple, which means they all look identical to the load balancer? 🙈
- Path stretch 🛣️: does the tunnel optimise the route, or is there a big chance the path gets way longer when you use the tunnel? we don't want a detour that's giving "scenic road trip" 💀
- NAT traversal 🚪: can the tunnel get through a NAT gateway, and does it need configuration on that NAT gateway? 🫶
- Tunnel endpoint mobility 🚗: are the IPv4 addresses of the tunnel fixed, or do they adjust automatically when an endpoint moves? 🦋
- State 🧠: do the endpoints have to keep state for the tunnel, or is the tunnel stateless? 💜
- Network type 🌐: is the network point-to-point or NBMA? 🍓
- Purpose 🎯: what is the intended purpose of this tunnel protocol? ✨
- Related protocols 👯: which protocols is this one related to? are there alternatives? 🌈
- Implementations 🛠️: is the protocol supported on the major operating systems, routers, and firewalls? 💅
- Limitations ⚠️: what are the known limitations of this protocol? be honest, bestie 🥺
That's the whole scorecard, babe. Every tunnel was judged with these in mind, so when you're comparing them, keep this list handy 🎀
Authors' Addresses 💌
Sander Steffann 🌷 S.J.M. Steffann Consultancy Tienwoningenweg 46 Apeldoorn, Gelderland 7312 DN The Netherlands
EMail: sander@steffann.nl
Iljitsch van Beijnum 🌼 Institute IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes, Madrid 28918 Spain
EMail: iljitsch@muada.com
Rick van Rein 🦄 OpenFortress Haarlebrink 5 Enschede, Overijssel 7544 WP The Netherlands
EMail: rick@openfortress.nl
📦 where this page comes from
- ietf: rfc7059 2013-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms