RFC 4380
Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)
Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs) 🦋
Part 1 of 12 🎀
Okay bestie, this is RFC 4380, the Teredo spec 💅. It was written by C. Huitema at Microsoft and published in February 2006 by the Network Working Group. It's filed as a Standards Track document, and its title block doesn't list anything it obsoletes or updates ✨.
Status of This Memo ✨
So this doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶. For the standardization state and status, 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 (2006).
Abstract 🌈
Here we propose a service that lets nodes sitting behind one or more IPv4 Network Address Translations (NATs) get IPv6 connectivity by tunneling packets over UDP. We call it the Teredo service 🧚. Running it needs help from "Teredo servers" and "Teredo relays." The Teredo servers are stateless and only have to handle a small fraction of the traffic between Teredo clients 🥹. The Teredo relays act as IPv6 routers between the Teredo service and the "native" IPv6 Internet. Relays can also play nicely with hosts using other transition mechanisms, like "6to4" 🫶.
Table of Contents
1. Introduction ....................................................3
2. Definitions .....................................................4
2.1. Teredo Service .............................................4
2.2. Teredo Client ..............................................4
2.3. Teredo Server ..............................................4
2.4. Teredo Relay ...............................................4
2.5. Teredo IPv6 Service Prefix .................................4
2.6. Global Teredo IPv6 Service Prefix ..........................4
2.7. Teredo UDP Port ............................................4
2.8. Teredo Bubble ..............................................4
2.9. Teredo Service Port ........................................5
2.10. Teredo Server Address .....................................5
2.11. Teredo Mapped Address and Teredo Mapped Port ..............5
2.12. Teredo IPv6 Client Prefix .................................5
2.13. Teredo Node Identifier ....................................5
2.14. Teredo IPv6 Address .......................................5
2.15. Teredo Refresh Interval ...................................5
2.16. Teredo Secondary Port .....................................6
2.17. Teredo IPv4 Discovery Address .............................6
3. Design Goals, Requirements, and Model of Operation ..............6
3.1. Hypotheses about NAT Behavior ..............................6
3.2. IPv6 Provider of Last Resort ...............................8
3.3. Operational Requirements ...................................9
3.4. Model of Operation ........................................10
4. Teredo Addresses ...............................................11
5. Specification of Clients, Servers, and Relays ..................13
5.1. Message Formats ...........................................13
5.2. Teredo Client Specification ...............................16
5.3. Teredo Server Specification ...............................31
5.4. Teredo Relay Specification ................................33
5.5. Implementation of Automatic Sunset ........................36
6. Further Study, Use of Teredo to Implement a Tunnel Service .....37
7. Security Considerations ........................................38
7.1. Opening a Hole in the NAT .................................38
7.2. Using the Teredo Service for a Man-in-the-Middle Attack ...39
7.3. Denial of the Teredo service ..............................42
7.4. Denial of Service against Non-Teredo Nodes ................43
8. IAB Considerations .............................................46
8.1. Problem Definition ........................................46
8.2. Exit Strategy .............................................47
8.3. Brittleness Introduced by Teredo ..........................48
8.4. Requirements for a Long-Term Solution .....................50
9. IANA Considerations ............................................50
10. Acknowledgements ..............................................50
11. References ....................................................51
11.1. Normative References .....................................51
11.2. Informative References ...................................521. Introduction ✨
Okay so classic tunneling methods planned for IPv6 transition work by sending IPv6 packets as the payload of IPv4 packets, and the 6to4 proposal [RFC3056] adds automatic discovery in that setup 🧚. The problem is they break when the IPv6 candidate node is stuck behind a Network Address Translator (NAT) device 😭. NATs usually aren't set up to let arbitrary payload types through, and even when they are, the local address can't be used in a 6to4 scheme. 6to4 does work with a NAT if the NAT and the 6to4 router functions live in the same box. But we want to cover the pretty common case where the NAT can't easily be upgraded to provide a 6to4 router function 💅.
One idea is to rely on "tunnel brokers" 🎀. Ngl, brokers have limits. The quality of service may be limited, since traffic follows a dogleg route from the source to the broker and then to the destination. And the broker has to have enough transmission capacity to relay every packet, so it's expensive 💀. For those two reasons, it can be desirable to have solutions that allow for "automatic tunneling," i.e., letting packets follow a direct path to the destination 🦋.
Automatic tunneling is kinda at odds with some NAT quirks 🙈. A direct path means the IPv6 candidate node has to retrieve a "globally routable" address that results from its local address being translated by one or more NATs. We also need a way to get past the various "per destination protections" that many NATs implement. In this memo, we explain how IPv6 candidates behind NATs use "Teredo servers" to learn their "global address" and get connectivity, how they exchange packets with native IPv6 hosts through "Teredo relays," and how clients, servers, and relays can be organized into Teredo networks 🌸.
The spec is organized like this 📋. Section 2 has the definitions of the terms used in the memo. Section 3 presents the hypotheses on NAT behavior used in the design, plus the operational requirements the design should meet. Section 4 presents the IPv6 address format Teredo uses. Section 5 has the message formats and the protocol spec. Section 6 presents guidelines for further work on configured tunnels that would complement the current approach. Section 7 is the security discussion, section 8 covers the Unilateral Self Address Fixing (UNSAF) issues, and section 9 has the IANA considerations.
2. Definitions 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This spec uses the following definitions 📖.
2.1. Teredo Service
Basically, it's the transmission of IPv6 packets over UDP, as defined in this memo 🦋.
2.2. Teredo Client
A node that has some access to the IPv4 Internet and wants to get access to the IPv6 Internet 💖.
2.3. Teredo Server
A node that has access to the IPv4 Internet through a globally routable address, and acts as a helper to provide IPv6 connectivity to Teredo clients 🧚.
2.4. Teredo Relay
An IPv6 router that can receive traffic destined to Teredo clients and forward it using the Teredo service 🌉.
2.5. Teredo IPv6 Service Prefix
An IPv6 addressing prefix that is used to construct the IPv6 address of Teredo clients 🌸.
2.6. Global Teredo IPv6 Service Prefix
An IPv6 addressing prefix whose value is 2001:0000:/32 ✨.
2.7. Teredo UDP Port
The UDP port number at which Teredo servers are waiting for packets. The value of this port is 3544 🍓.
2.8. Teredo Bubble
A Teredo bubble is a minimal IPv6 packet, made of an IPv6 header and a null payload 🫧. The payload type is set to 59, No Next Header, as per [RFC2460]. Teredo clients and relays may send bubbles in order to create a mapping in a NAT 🙌.
2.9. Teredo Service Port
The port from which the Teredo client sends Teredo packets. This port is attached to one of the client's IPv4 addresses. The IPv4 address may or may not be globally routable, since the client may be located behind one or more NATs 🦋.
2.10. Teredo Server Address
The IPv4 address of the Teredo server selected by a particular client 💅.
2.11. Teredo Mapped Address and Teredo Mapped Port
A global IPv4 address and a UDP port that result from translating the IPv4 address and UDP port of a client's Teredo service port through one or more NATs. The client learns these values through the Teredo protocol described in this memo 🗺️.
2.12. Teredo IPv6 Client Prefix
A global scope IPv6 prefix made of the Teredo IPv6 service prefix and the Teredo server address 🎀.
2.13. Teredo Node Identifier
A 64-bit identifier that contains the UDP port and IPv4 address at which a client can be reached through the Teredo service. It also has a flag indicating the type of NAT the client uses to access the IPv4 Internet 🔐.
2.14. Teredo IPv6 Address
A Teredo IPv6 address you get by combining a Teredo IPv6 client prefix and a Teredo node identifier 💜.
2.15. Teredo Refresh Interval
The interval during which a Teredo IPv6 address is expected to stay valid in the absence of "refresh" traffic. For a client behind a NAT, the interval depends on configuration parameters of the local NAT, or on the combination of NATs in the path to the Teredo server. By default, clients assume an interval value of 30 seconds. A longer value may be determined by local tests, as described in section 5 ⏱️.
2.16. Teredo Secondary Port
A UDP port used to send or receive packets in order to figure out the appropriate value of the refresh interval. It's not used to carry any Teredo traffic 🌷.
2.17. Teredo IPv4 Discovery Address
An IPv4 multicast address used to discover other Teredo clients on the same IPv4 subnet. The value of this address is 224.0.0.253 📡.
3. Design Goals, Requirements, and Model of Operation 👑
Okay this part is where the design gets real 🧠. The proposed solution transports IPv6 packets as the payload of UDP packets. This is based on the observation that TCP and UDP are the only protocols guaranteed to cross the majority of NAT devices. Tunneling packets over TCP would be possible, but it would result in a poor quality of service, so encapsulation over UDP is the better choice 🫶.
The design of our solution is based on a set of hypotheses and observations about how NATs behave, our desire to provide an "IPv6 provider of last resort," and a list of operational requirements. It results in a model of operation where the Teredo service is enabled by a set of servers and relays. Part 2 is next, and that's where the NAT hypotheses and the requirements start 👀💜
3.1. Hypotheses about NAT Behavior 🦋
okay so NAT devices usually have some support for UDP, so people behind them can actually use UDP-based apps 💖 The NAT will normally create a "mapping" the moment it sees a UDP packet coming through that doesn't already have one. How NATs handle UDP "sessions" comes down to two big things: the type of the mappings and how long they last ⏳
The type of mapping is analyzed in [RFC3489], which splits NATs into "cone NAT", "restricted cone NAT", "port restricted cone NAT" and "symmetric NAT". Teredo makes sure clients behind cone NATs, restricted cone NATs, or port-restricted cone NATs can connect 🎀
Regular IPv6 packets only start flowing after the two sides swap "bubbles" 🫧 That swap would often fail for clients behind a symmetric NAT, because their peer can't predict the UDP port number the NAT expects. 😭
Clients behind a symmetric NAT can only use Teredo if they somehow program the NAT and reserve a Teredo service port for each client, for example with the DMZ functions of the NAT. ngl that is an onerous requirement and totally at odds with the goal of an automatic solution 🙈 BUT measurement campaigns and studies of documentation showed that, at least in simple "unmanaged" networks, symmetric NATs are a small minority. Plus, new NAT models or firmware upgrades seem to be dropping the "symmetric" design, so it's looking good 🌈
There's also a "port conserving" NAT design that studies of [RFC3489] performance turned up. The NAT tries to keep the same port number inside and outside, unless that "outside" port is already used by another mapping with the same host. Port conserving NATs look like "cone" or "restricted cone NAT" most of the time, but they act like "symmetric NAT" when multiple internal hosts use the same port number to talk to the same server 👀
Teredo lowers the odds of hitting that "symmetric" behaviour by asking multiple hosts behind the same NAT to use different Teredo service ports 💅
Researchers also spotted a "probabilistic rewrite" behaviour ✍️ Some NAT brands look inside every packet for "embedded addresses", meaning IP addresses and port numbers sitting in application payloads. They systematically swap any 32-bit value that matches a local address for the matching mapped address. The Teredo specification includes an "obfuscation" procedure to dodge this 🥷
Regardless of type, UDP mappings aren't kept forever. The typical algorithm is to delete a mapping if no traffic is seen on the specified port for a "lifetime" period. A Teredo client that wants to keep a mapping open in the NAT has to send some "keep alive" traffic before the lifetime runs out ⏰ To do that, it needs an estimate of the "lifetime" parameter the NAT uses, and lifetime control varies between implementations in several ways 🌸
Most NATs have a "minimum lifetime", set as a parameter of the implementation. The boxes we looked at ranged from about 45 seconds to several minutes ⏱️
Lots of NATs keep mappings alive for longer than that minimum, even with no traffic. We suspect many implementations do "garbage collection" of unused mappings during special events, e.g., when the total number of mappings goes over some limit 🗑️
In some cases, like NATs managing ISDN or dial-up connections, mappings get released when the connection is released. That means no traffic on the connection for a few minutes, and poof, gone 💨
Any algorithm used to estimate a mapping's lifetime has to be robust against all these variations 🫶
Sometimes clients sit behind multiple NATs. Teredo procedures make sure communication works between clients behind multiple NATs and clients "on the other side" of those NATs. They also make sure communication works when clients are in a single subnet behind the same NAT 🧚
The procedures don't make any assumptions about the type of IPv4 address used behind a NAT. In particular, they don't assume those addresses are the private ones defined in [RFC1918] 🌟
3.2. IPv6 Provider of Last Resort 🧚
Teredo is built to be the "IPv6 access of last resort" for nodes that need IPv6 connectivity but can't use any of the other IPv6 transition schemes 💖 This design goal has a few consequences: when to use Teredo, how to set up clients, and what to expect from servers. Another consequence is that we expect a point to come when Teredo stops being used at all 🌅
3.2.1. When to Use Teredo 💅
Teredo is designed to get IPv6 traffic through NATs robustly, and the price of that robustness is a reasonable amount of overhead, thanks to UDP encapsulation and bubbles 🫧 Nodes that want to reach the IPv6 Internet SHOULD only use the Teredo service as a "last resort" option. They SHOULD prefer direct IPv6 connectivity if it's available locally, if a 6to4 router sits alongside the local NAT, or if a configured tunnel service provides it. And they SHOULD prefer the less onerous 6to4 encapsulation if they can use a global IPv4 address 🎀
3.2.2. Autonomous Deployment ✨
On an IPv6-enabled network, the IPv6 service gets configured automatically, using things like IPv6 Stateless Address Autoconfiguration [RFC2462] and Neighbor Discovery [RFC2461]. The goal is to configure the Teredo service as automatically as possible too. In practice though, the client has to learn the IPv4 address of a server that's willing to serve it, and some servers may also need some form of access control 🔐
3.2.3. Minimal Load on Servers 🍓
At the peak of the transition, there will be a need to deploy Teredo servers that support a large number of Teredo clients 📈 Keeping the load on each server low is a great way to make that rollout easier. So servers should be as stateless as possible, and they should also not have to carry any more traffic than necessary. We only require that servers enable the packet exchange between clients. We don't require servers to carry the actual data packets. Those packets get exchanged directly between Teredo clients, or through a destination-selected relay for exchanges between Teredo clients and other IPv6 clients 🦋
3.2.4. Automatic Sunset 🌅
Teredo is meant as a short-term fix for one specific problem: giving IPv6 service to nodes behind a NAT 💅 The problem should be solved over time by turning the "IPv4 NAT" into an "IPv6 router". There are two ways to do that. You can upgrade the NAT to provide 6to4 functions, or upgrade the Internet connection the NAT uses to a native IPv6 service and then add IPv6 router functionality to the NAT. Either way, the former NAT can present itself as an IPv6 router to the systems behind it. Those systems start receiving the "router advertisements", notice they have IPv6 connectivity, and stop using Teredo. Iconic exit 👑
3.3. Operational Requirements 📋
3.3.1. Robustness Requirement 💪
Teredo is designed mainly for robustness. Packets ride over UDP so they can cross as many NAT implementations as possible 🌈 The servers are stateless, which means they can be replicated easily, and we expect to find many of them replicated at multiple Internet locations ✨
3.3.2. Minimal Support Cost 💸
The service needs Teredo servers and Teredo relays. To make those easier to deploy, the Teredo procedures are designed to keep the coordination between servers and relays to a minimum 🫶
Reaching that goal means Teredo addresses include the IPv4 address and UDP port a Teredo client can be reached through. That creates an implicit limit on how stable Teredo addresses can be, since they only stay valid as long as that underlying IPv4 address and UDP port stay valid 🥀
3.3.3. Protection against Denial of Service Attacks 🛡️
Teredo clients get mapped addresses and ports from Teredo servers. The service has to be protected against denial of service attacks in which a third party spoofs a Teredo server and sends improper information to the client. This is a serious one, bestie, so don't sleep on it 😭🚨
3.3.4. Protection against Distributed Denial of Service Attacks 🚨
Teredo relays act as relays for IPv6 packets. Badly designed packet relays can be abused by denial of service attackers to hide their address, which makes the attack untraceable 💀 The Teredo service must include adequate protection against that kind of misuse. Non-negotiable 🔥
3.3.5. Compatibility with Ingress Filtering 🧹
Routers may do ingress filtering by checking that the source address of packets received on a given interface is "legitimate". That means it belongs to a network prefix that traffic is expected from on that interface. Ingress filtering is a recommended practice, because it stops malfeasant hackers from using forged source IP addresses, especially to cover their tracks during denial of service attacks 🕵️ The Teredo specification must not force networks to disable ingress filtering. Respect the boundary, periodt 💅🩷
3.4. Model of Operation
okay so Teredo has four kinds of nodes 💅: Teredo clients, Teredo servers, Teredo relays, and "plain" IPv6 nodes. bestie, you need all four to make the magic happen ✨
Teredo clients start by chatting with a Teredo server in a "qualification procedure" 🎀. During this, the client figures out whether it's sitting behind a cone NAT, a restricted cone NAT, or a symmetric NAT. If it's not behind a symmetric NAT, the procedure works out and the client gets to configure a "Teredo address" 🦋
The Teredo IPv6 address stores the "mapped address and port", which is the address and port the client can receive IPv4/UDP packets on, and those packets carry IPv6 packets inside 🌸 If the client is not behind a cone NAT, regular IPv6 packets have to wait for an exchange of "bubbles" first. Bubbles are what install a mapping in the NAT 🫶 This document explains how Teredo clients swap bubbles with each other so the traffic can take a direct path 💜
Teredo clients can also trade IPv6 packets with plain IPv6 nodes (like native nodes or 6to4 nodes) through Teredo relays 🧚 Relays announce that they can reach the Teredo prefix, but only to a certain slice of the IPv6 Internet. An ISP's relay will usually only help that ISP's IPv6 customers, and a relay set up for a site only helps the IPv6 hosts on that site 🍓 Dual-stack hosts can run a "local relay", which lets them talk directly to Teredo hosts by sending IPv6 packets over UDP and IPv4, without advertising a Teredo IPv6 address. so cute, right? 🙈
Teredo clients need to find the relay that's closest to each native IPv6 or 6to4 peer 👑 They have to do this for every native IPv6 or 6to4 peer they talk to. To stop spoofing, the client runs a relay discovery procedure by sending an ICMP echo request to the native host 🛡️ This is a normally formatted IPv6 ICMP packet, wrapped in UDP and sent to the client's Teredo server. The server unwraps the IPv6 message and forwards it to the intended IPv6 destination. The echo request's payload holds a large random number 🎲 The peer sends the echo reply to the client's IPv6 address, and it travels through regular IPv6 routing. It naturally lands at the Teredo relay closest to the native or 6to4 peer, and that relay forwards it using the Teredo mechanisms 🔥 The client picks up the IPv4 address and UDP port the relay used to send the echo reply, and from then on it sends further IPv6 packets to the peer by wrapping them in UDP packets aimed at that IPv4 address and port. To stop spoofing again, the client checks that the echo reply's payload contains the proper random number ✅
The whole setup is designed so the Teredo server only shows up for the qualification procedure, the bubble exchange, and ICMP echo requests 🥹 The Teredo server never carries actual data traffic. There are two reasons for this: it keeps the load on the server low so things can scale 📈, and it avoids privacy problems that could happen if a Teredo server kept copies of the client's data packets 🔒
4. Teredo Addresses ✨
Teredo addresses are built from 5 components 🧩
+-------------+-------------+-------+------+-------------+
| Prefix | Server IPv4 | Flags | Port | Client IPv4 |
+-------------+-------------+-------+------+-------------+- Prefix: the 32-bit Teredo service prefix.
- Server IPv4: the IPv4 address of a Teredo server.
- Flags: a set of 16 bits that document type of address and NAT.
- Port: the obfuscated "mapped UDP port" of the Teredo service at the client.
- Client IPv4: the obfuscated "mapped IPv4 address" of the client.
In this format, both the client's "mapped UDP port" and "mapped IPv4 address" get obfuscated 🕵️♀️ Every bit in the address and port number gets flipped. You can do this with an exclusive OR of the 16-bit port number with the hexadecimal value 0xFFFF, and an exclusive OR of the 32-bit address with the hexadecimal value 0xFFFFFFFF.
The IPv6 addressing rules say that "for all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format". This sets up how the flags get encoded: 16 middle bits that should match valid values for the most significant 16 bits of a Modified EUI-64 ID 🧠
0 0 0 1
|0 7 8 5
+----+----+----+----+
|Czzz|zzUG|zzzz|zzzz|
+----+----+----+----+Here's what those bits mean:
- The bits "UG" should be set to the value "00", indicating a non-global unicast identifier;
- The bit "C" (cone) should be set to 1 if the client believes it is behind a cone NAT, to 0 otherwise; these values determine different server behavior during the qualification procedure, as specified in Section 5.2.1, as well as different bubble processing by clients and relays.
- The bits indicated with "z" must be set to zero and ignored on receipt.
So there are two currently specified values of the Flags field 🎀 They're "0x0000" (all null) if the cone bit is set to 0, and "0x8000" if the cone bit is set to 1. (Future versions of this spec may assign new values to the reserved bits 🔮)
Sometimes Teredo nodes use link-local addresses 🌙 These contain a link-local prefix (FE80::/64) plus a 64-bit identifier, built using the same format as above. The big difference between link-local and global addresses is that identifiers in global addresses MUST include a global scope unicast IPv4 address, while identifiers in link-local addresses MAY include a private IPv4 address. the global ones are strict, the link-local ones are chill 😌
5. Specification of Clients, Servers, and Relays
The Teredo service works because clients talk to Teredo servers through the Teredo service protocol 💬 Clients also receive IPv6 packets through Teredo relays. You'll find the client behavior in Section 5.2.
The Teredo server is designed to be stateless 🫧 It sits and waits for Teredo requests and for IPv6 packets on the Teredo UDP port. It handles requests by sending a response to the right address and port, and it forwards some Teredo IPv6 packets to the appropriate IPv4 address and UDP port, or to native IPv6 peers of Teredo clients. The exact server behavior is in Section 5.3.
The Teredo relay advertises that it can reach the Teredo service prefix over IPv6 📡 That advertisement can cover the whole Internet, or a smaller slice like an ISP network or an IPv6 site. It can even be as small as a single host, in the case of "local relays". The relay forwards Teredo IPv6 packets to the appropriate IPv4 address and UDP port. The relay behavior is in Section 5.4.
Teredo clients, servers, and relays must implement the sunset procedure defined in Section 5.5 🌅
5.1. Message Formats
5.1.1. Teredo IPv6 Packet Encapsulation
Teredo IPv6 packets travel as UDP packets [RFC768] inside IPv4 [RFC791] 📦 The source and destination IP addresses and UDP ports take values specified in this section. Packets come in one of two formats: simple encapsulation, and encapsulation with origin indication.
With simple encapsulation, the packet is basic. The IPv6 packet is just the payload of a UDP datagram 💜
+------+-----+-------------+
| IPv4 | UDP | IPv6 packet |
+------+-----+-------------+When the server relays some packets it got from third parties, it may put an origin indication in the first bytes of the UDP payload 🕊️
+------+-----+-------------------+-------------+
| IPv4 | UDP | Origin indication | IPv6 packet |
+------+-----+-------------------+-------------+The origin indication is an 8-octet element with this content 🔍
+--------+--------+-----------------+
| 0x00 | 0x00 | Origin port # |
+--------+--------+-----------------+
| Origin IPv4 address |
+-----------------------------------+The first two octets of the origin indication are set to a null value. This is how the receiver tells simple encapsulation apart from the origin indication, since in simple encapsulation the first 4 bits of the packet hold the IPv6 protocol indication 🧐
The next 16 bits hold the obfuscated port number the packet was received from, in network byte order. The following 32 bits hold the obfuscated IPv4 address the packet was received from, also in network byte order. Here, both the original "IPv4 address" and "UDP port" of the client get obfuscated. Every bit in the address and port number is reversed. You can do this with an exclusive OR of the 16-bit port number with the hexadecimal value 0xFFFF, and an exclusive OR of the 32-bit address with the hexadecimal value 0xFFFFFFFF 🙃
Here's an example 🍰 Say the original UDP port number was 337 (hexadecimal 0151) and the original IPv4 address was 1.2.3.4 (hexadecimal 01020304). Then the origin indication would contain the value 0000FEAEFEFDFCFB.
When a client and its server swap Router Solicitation (RS) and Router Advertisement (RA) messages, the packets may include an authentication parameter 🔐
+------+-----+----------------+-------------+
| IPv4 | UDP | Authentication | IPv6 packet |
+------+-----+----------------+-------------+The authentication encapsulation is a variable-length element. It holds a client identifier, an authentication value, a nonce value, and a confirmation byte 💅
+--------+--------+--------+--------+
| 0x00 | 0x01 | ID-len | AU-len |
+--------+--------+--------+--------+
| Client identifier (ID-len |
+-----------------+-----------------+
| octets) | Authentication |
+-----------------+--------+--------+
| value (AU-len octets) | Nonce |
+--------------------------+--------+
| value (8 octets) |
+--------------------------+--------+
| | Conf. |
+--------------------------+--------+The first octet of the authentication encapsulation is set to a null value, and the second octet is set to the value 1. This lets it be told apart from IPv6 packets and from the origin information indication encapsulation 👀 The third octet gives the length in bytes of the client identifier, and the fourth octet gives the length in bytes of the authentication value. The authentication value gets computed as specified in Section 5.2.2. After the authentication value comes an 8-octet nonce, and then a confirmation byte.
Both ID-len and AU-len can be set to null values if the server doesn't require explicit authentication of the client 🫶
Authentication and origin indication encapsulations can sometimes be combined, for example in the RA responses the server sends 💫 In that case, the authentication encapsulation MUST be the first element in the UDP payload.
+------+-----+----------------+--------+-------------+
| IPv4 | UDP | Authentication | Origin | IPv6 packet |
+------+-----+----------------+--------+-------------+5.1.2. Maximum Transmission Unit ✨
okay so Teredo rides on UDP 🦋, which means a Teredo MTU could technically be as big as the payload of the largest valid UDP datagram, 65507 bytes 😳. but ngl, Teredo packets wander all over the internet on totally unpredictable paths, so it's giving keep the MTU small 🌸 to shrink the effect of IPv4 fragmentation and reassembly. the default link MTU a host assumes, and the link MTU a Teredo server hands out in its router advertisement, SHOULD normally be the minimum IPv6 MTU of 1280 bytes [RFC2460] 💅
Teredo implementations SHOULD NOT set the Don't Fragment (DF) bit of the encapsulating IPv4 header 🙈
5.2. Teredo Client Specification 🎀
before a client can use the Teredo service, it has to be configured with:
- the IPv4 address of a server.
- a secondary IPv4 address of that server.
if secure discovery is required, the client also has to be configured with:
- a client identifier,
- a secret value, shared with the server,
- an authentication algorithm, shared with the server.
a Teredo client expects to exchange IPv6 packets through a UDP port, the Teredo service port 🦋. so to avoid drama when operating behind a "port conserving" NAT, different clients behind the same NAT should use different service port numbers 💜. this can be done through explicit configuration or, if there's no configuration, by picking the service port number at random 🎲
the client keeps track of the following variables that reflect the state of the Teredo service:
- Teredo connectivity status,
- Mapped address and port number associated with the Teredo service port,
- Teredo IPv6 prefix associated with the Teredo service port,
- Teredo IPv6 address or addresses derived from the prefix,
- Link local address,
- Date and time of the last interaction with the Teredo server,
- Teredo Refresh Interval,
- Randomized Refresh Interval,
- List of recent Teredo peers.
before sending any packets, the client must perform the Teredo qualification procedure 👑, which determines the Teredo connectivity status, the mapped address and port number, and the Teredo IPv6 prefix. then it should perform the cone NAT determination procedure, which determines the cone NAT status and may alter the value of the prefix. if qualification succeeds, the client may use the Teredo service port to transmit and receive IPv6 packets, following the transmission and reception procedures. those procedures use the "list of recent peers" 🧚 and for each peer, the list contains:
- The IPv6 address of the peer,
- The mapped IPv4 address and mapped UDP port of the peer,
- The status of the mapped address, i.e., trusted or not,
- The value of the last nonce sent to the peer,
- The date and time of the last reception from the peer,
- The date and time of the last transmission to the peer,
- The number of bubbles transmitted to the peer.
the peer list is what lets IPv6 packets take a "direct path" 🚀. the list could grow over time, so clients should implement a list management strategy, for example, deleting the least recently used entries 🧹. clients should also make sure the list is a sufficient size, so they don't end up sending unnecessary bubbles 🫧
the client must regularly run the maintenance procedure to make sure the Teredo service port stays usable ⭐. whether it needs to run depends on how long it's been since the last interaction with the Teredo server. the refresh procedure takes the "Teredo refresh interval" as a parameter. that parameter starts at 30 seconds, and it can be updated through the optional "interval determination procedure" 🌈. the randomized refresh interval is set to a value randomly chosen between 75% and 100% of the refresh interval 🎲
to avoid triangle routing for stations sitting behind the same NAT, Teredo clients MAY use the optional local client discovery procedure defined in Section 5.2.8. this procedure also helps connectivity when the NAT can't do "hairpin" routing, meaning it can't redirect a packet sent from one internal host to the mapped address and port of another internal host 🙈
5.2.1. Qualification Procedure 💖
this procedure is all about two things: figuring out the status of the local IPv4 connection, and finding the Teredo IPv6 client prefix of the local Teredo interface 🔍. it kicks off when the service is in the "initial" state, and it ends in a "qualified" state if it works, or an "off-line" state if it doesn't 💀
/---------\
| Initial |
\---------/
|
+----+----------+
| Set ConeBit=1 |
+----+----------+
|
+<-------------------------------------------+
| |
+----+----+ |
| Start |<------+ |
+----+----+ | +----------+----+
| | | Set ConeBit=0 |
| | +----------+----+
v | ^
/---------\ Timer | N ^
|Starting |-------+ attempts /----------------\Yes|
\---------/----------------->| ConeBit == 1 ? |---+
| Response \----------------/
| | No
V V
/---------------\ Yes /----------\
| ConeBit == 1? |-----+ | Off line |
\---------------/ | \----------/
No | v
| /----------\
| | Cone NAT |
+-----+-----+ \----------/
| New Server|
+-----+-----+
|
+----+----+
| Start |<------+
+----+----+ |
| |
v |
/---------\ Timer |
|Starting |-------+ N attempts /----------\
\---------/------------------->| Off line |
| Response \----------/
|
V
/------------\ No /---------------\
| Same port? |-------->| Symmetric NAT |
\------------/ \---------------/
| Yes
V
/----------------------\
| Restricted Cone NAT |
\----------------------/initially, the Teredo connectivity status is set to "Initial" 🌱
when the interface comes up, the system first performs the "start action" by sending a Router Solicitation message, as defined in [RFC2461] 📨. the client picks a link-local address and uses it as the IPv6 source of the message. the cone bit in that address is set to 1 (see Section 4 for the address format). the IPv6 destination of the RS is the all-routers multicast address, and the packet goes over UDP from the service port to the Teredo server's IPv4 address and Teredo UDP port. the connectivity status then moves to "Starting" 🏃♀️
in the starting state, the client waits for a router advertisement from the Teredo server. if no response comes in before a time-out T, the client should repeat the start action and resend the Router Solicitation message. if there's still no response after N repetitions, the client concludes it's not behind a cone NAT 🙅♀️. it sets the cone bit to 0 and repeats the procedure. if after N more timer expirations and retransmissions there's still no response, the client concludes it can't use UDP and that the Teredo service isn't available, so the status is set to "Off-line" 😭. following [RFC2461], the default time-out is T=4 seconds, and the maximum number of repetitions is N=3 ⏱️
if a response arrives, the client checks that it contains an origin indication and a valid router advertisement as defined in [RFC2461]. it also checks that the IPv6 destination address equals the link-local address used in the router solicitation, and that the router advertisement contains exactly one advertised Prefix Information option 🔎. that prefix should be a valid Teredo IPv6 server prefix: the first 32 bits should hold the global Teredo IPv6 service prefix, and the next 32 bits should hold the server's IPv4 address. if all of that checks out, the client learns the Teredo mapped address and Teredo mapped port from the origin indication 🗺️. the IPv6 source address of the Router Advertisement is a link-local server address of the Teredo server. (responses that aren't valid advertisements are simply discarded 🗑️)
if the client received an RA with the cone bit in the IPv6 destination address set to 1, it's behind a cone NAT and is fully qualified 👑. if the RA came back with the cone bit set to 0, the client doesn't know whether the local NAT is restricted or symmetric 🤔. so it selects the secondary IPv4 server address and repeats the procedure, with the cone bit still at zero. if the client gets no response, it detects that the service isn't usable 💔. if it does get a response, it compares the mapped address and mapped port in this second response to the first values it received. if they're different, the client detects a symmetric NAT, and it can't use the Teredo service 🚫. if they're the same, the client detects a port-restricted or restricted cone NAT, and it's qualified to use the service ✅. (Teredo operates the same way for restricted and port-restricted NAT 🫶)
if the client is qualified, it builds a Teredo IPv6 address from the Teredo IPv6 server prefix learned from the RA and the obfuscated values of the UDP port and IPv4 address learned from the origin indication 🎀. the cone bit should be set to the value used to receive the RA, so 1 if the client is behind a cone NAT and 0 otherwise. and that's it, the client can start using the Teredo service 🥳✨
5.2.2. Secure Qualification ✨
okay so the client may be required to do secured qualification 🔐 and honestly it's giving extra security glow-up. It runs exactly the same algorithm from Section 5.2.1, but it also tucks an authentication encapsulation into the UDP packet that carries the router solicitation message. Then it checks that the router advertisement from the sender has a valid authentication parameter in its UDP message. Main character energy 👑
The nonce value gets chosen by the client and the server repeats it back in the response. The client identifier is just a value the client was configured with 🎀
A first level of protection is super simple: the client checks that the nonce in the response matches the one it sent at the start 🫶 If they don't match, the packet MUST be discarded. 💀 If no other protection is used, the authentication payload doesn't carry any identifier or authentication field, and the ID-len and AU-len fields are set to a null value. When you need stronger protection, the authentication payload includes the identifier and location fields, which the next paragraphs explain 🧚
The confirmation byte is set to 0 by the client. If the server sends back a null value, that means the client's key is still valid. A non-null value means the client should go get a new key 🔑
When stronger authentication is in play, the client and the server are both provisioned with a client identifier, a shared secret, and the identification of an authentication algorithm 🤝 Before transmission, the authentication value gets computed with the specified algorithm. On reception, the same algorithm is used to compute a target value from the content of the received packet. The receiver deems the authentication successful if the two values match. If they don't, the packet MUST be discarded. 😭
To keep everything interoperable, this specification defines a default algorithm where the authentication value is computed according to the HMAC specification [RFC2104] and the SHA1 function [FIPS-180]. Clients and servers may agree to use HMAC combined with a different function, or to use a different algorithm altogether, such as AES-XCBC-MAC-96 [RFC3566] 🌈
The default authentication algorithm is based on the HMAC algorithm, following these rules:
- the hash function shall be the SHA1 function [FIPS-180].
- the secret value shall be the shared secret with which the client was configured.
The clear text being protected includes:
- the nonce value,
- the confirmation byte,
- the origin indication encapsulation, if it is present,
- the IPv6 packet.
The HMAC procedure is applied to the concatenation of these four components, without any additional padding. Iconic 💅
5.2.3. Packet Reception 🦋
The Teredo client receives packets over the Teredo interface. Besides receiving packets, the packet reception procedure has a big job: keeping track of the date and time of the last interaction with the Teredo server, plus the "list of recent peers" 📋
When a UDP packet shows up on the Teredo service port, the Teredo client checks two things. First, that it's encoded according to the packet encoding rules in Section 5.1.1. Second, that it contains either a valid IPv6 packet, or a valid origin indication encapsulation combined with a valid IPv6 packet, possibly protected by a valid authentication encapsulation. If that isn't the case, the packet gets silently discarded 🤫
An IPv6 packet counts as valid if it conforms to [RFC2460]. The protocol identifier should indicate an IPv6 packet, and the payload length should be consistent with the length of the UDP datagram it's encapsulated in. The client should also check that the IPv6 destination address corresponds to its own Teredo address ✨
Next, the Teredo client looks at the IPv4 source address and UDP port number the packet came from. If those match the IPv4 address of the server and the Teredo port, the client updates the "date and time of the last interaction with the Teredo server" to the current date and time. If an origin indication is present, the client should run the "direct IPv6 connectivity test" from Section 5.2.9 🔍
If the IPv4 source address and UDP port number are different from the server's IPv4 address and Teredo port, the client looks at the IPv6 source address of the packet instead. Here's how the situations break down:
- If there's an entry for the source IPv6 address in the list of peers whose status is trusted, the client compares the mapped IPv4 address and mapped port in that entry with the source IPv4 address and source port of the packet. If the values match, the packet is accepted, and the date and time of the last reception from the peer gets updated 💜
- If there's an entry for the source IPv6 address in the list of peers whose status is not trusted, the client checks whether the packet is an ICMPv6 echo reply. If it is, and the ICMPv6 data of the reply matches the nonce stored in the peer entry, the packet should be accepted. The status of the entry should change to "trusted", the mapped IPv4 address and mapped port in the entry should be set to the source IPv4 address and source port the packet came from, and the date and time of the last reception from the peer should be updated. Any packet queued for this IPv6 peer (as specified in Section 5.2.4) should be de-queued and forwarded to the newly learned IPv4 address and UDP port 🎉
- If the source IPv6 address is a Teredo address, the client compares the mapped IPv4 address and mapped port in the source address with the source IPv4 address and source port of the packet. If the values match, the client MUST create a peer entry for the IPv6 source address in the list of peers. If one already existed, it should update that entry instead. The mapped IPv4 address and mapped port in the entry should be set to the values the packet came from, and the status should be set to "trusted". If a new entry is created, the last transmission date is set to 30 seconds before the current date, and the number of bubbles is set to zero. If the packet is a bubble, it should be discarded after this processing. Otherwise, the packet should be accepted. In all cases, the client must de-queue and forward any packet queued for that destination 🫧
- If the IPv4 destination address the packet was received through is the Teredo IPv4 Discovery Address, the source address is a valid Teredo address, and the destination address is the "all nodes on link" multicast address, the packet should be treated as a local discovery bubble. If no local entry already existed for the source address, a new one is created, but its status is set to "not trusted". The client SHOULD reply with a unicast Teredo bubble, sent to the source IPv4 address and source port of the local discovery bubble. The IPv6 source address of that bubble is set to the local Teredo IPv6 address, and its IPv6 destination address should be set to the IPv6 source address of the local discovery bubble. (Clients that do not implement the optional local discovery procedure will not process local discovery bubbles.) 🔎
- If the source IPv6 address is a Teredo address, and the mapped IPv4 address and mapped port in the source address do not match the source IPv4 address and source port of the packet, the client checks whether there's an existing "local" entry for that IPv6 address. If there is one, and the local IPv4 address and local port indicated in that entry match the source IPv4 address and source port of the packet, the client updates the "local" entry, whose status should be set to "trusted". If the packet is a bubble, it should be discarded after this processing. Otherwise, the packet should be accepted. In all cases, the client must de-queue and forward any packet queued for that destination 🌸
- In the other cases, the packet may be accepted, but the client should be aware that the source address may be spoofed 👀 Before processing the packet, the client should perform the "direct IPv6 connectivity test" described in Section 5.2.9.
Whatever the IPv4 source address and UDP source port are, a client that receives an IPv6 packet MAY send a Teredo bubble towards that target, as specified in Section 5.2.6 🍓
5.2.4. Packet Transmission ✨
Okay so when a Teredo client has to send a packet out over its Teredo interface, the first thing it does is look at the destination IPv6 address 👀. It checks whether that address already has an entry in its list of recent Teredo peers, and if it does, it checks whether that entry is still valid 💅. For a local peer entry, the entry is valid if the last reception date and time on it is less than 30 seconds from the current time. For a non-local peer entry, it's the exact same rule: last reception less than 30 seconds from now. (Local peer entries can only be there if the client uses the local discovery procedure from Section 5.2.8, so no local discovery means no local entries 🙈)
Then the client does the following:
- If there is an entry for that IPv6 address in the list of peers, and if the status of the entry is set to "trusted", the IPv6 packet should be sent over UDP to the IPv4 address and UDP port specified in the entry. The client updates the date of last transmission in the peer entry. 🎀
- If the destination is not a Teredo IPv6 address, the packet is queued, and the client performs the "direct IPv6 connectivity test" described in Section 5.2.9. The packet will be de-queued and forwarded if this procedure completes successfully. If the direct IPv6 connectivity test fails to complete within a 2-second time-out, it should be repeated up to 3 times. 🔁
- If the destination is the Teredo IPv6 address of a local peer (i.e., a Teredo address from which a local discovery bubble has been received in the last 600 seconds), the packet is queued. The client sends a unicast Teredo bubble to the local IPv4 address and local port specified in the entry, and a local Teredo bubble to the Teredo IPv4 discovery address. 🦋
- If the destination is a Teredo IPv6 address in which the cone bit is set to 1, the packet is sent over UDP to the mapped IPv4 address and mapped UDP port extracted from that IPv6 address. 🌸
- If the destination is a Teredo IPv6 address in which the cone bit is set to 0, the packet is queued. If the client is not located behind a cone NAT, it sends a direct bubble to the Teredo destination, i.e., to the mapped IP address and mapped port of the destination. In all cases, the client sends an indirect bubble to the Teredo destination, sending it over UDP to the server address and to the Teredo port. The packet will be de-queued and forwarded when the client receives a bubble or another packet directly from this Teredo peer. If no bubble is received within a 2-second time-out, the bubble transmission should be repeated up to 3 times. 🧚
In cases 4 and 5, before sending a packet over UDP, the client MUST check that the IPv4 destination address is in the format of a global unicast address. If this is not the case, the packet MUST be silently discarded. (Note that a packet can legitimately be sent to a non-global unicast address in case 1, as a result of the local discovery procedure.) 🫶
The global unicast address check is designed to thwart a number of possible attacks in which an attacker tries to use a Teredo host to attack either a single local IPv4 target or a set of such targets. 🚨 For the purpose of this specification, an IPv4 address is deemed to be a global unicast address if it does not belong to or match:
- the "local" subnet
0.0.0.0/8, - the "loopback" subnet
127.0.0.0/8, - the local addressing ranges
10.0.0.0/8, - the local addressing ranges
172.16.0.0/12, - the local addressing ranges
192.168.0.0/16, - the link local block
169.254.0.0/16, - the block reserved for 6to4 anycast addresses
192.88.99.0/24, - the multicast address block
224.0.0.0/4, - the "limited broadcast" destination address
255.255.255.255, - the directed broadcast addresses corresponding to the subnets to which the host is attached.
A list of special-use IPv4 addresses is provided in [RFC3330].
For reliability reasons, clients MAY decide to ignore the value of the cone bit in the flag, skip the "case 4" test and always perform the "case 5", i.e., treat all Teredo peers as if they were located behind non-cone NAT. This will result in some increase in traffic, but may avoid reliability issues if the determination of the NAT status was for some reason erroneous. For the same reason, clients MAY also decide to always send a direct bubble in case 5, even if they do not believe that they are located behind a non-cone NAT. 🌈
5.2.5. Maintenance 🔧
The Teredo client must ensure that the mappings that it uses remain valid. It does so by checking that packets are regularly received from the Teredo server. 💖
At regular intervals, the client MUST check the "date and time of the last interaction with the Teredo server" to ensure that at least one packet has been received in the last Randomized Teredo Refresh Interval. If this is not the case, the client SHOULD send a router solicitation message to the server, as specified in Section 5.2.1. The client should use the same value of the cone bit that resulted in the reception of an RA during the qualification procedure. 📡
When the router advertisement is received, the client SHOULD check its validity as specified in Section 5.2.1. Invalid advertisements are silently discarded. If the advertisement is valid, the client MUST check that the mapped address and port correspond to the current Teredo address. If this is not the case, the mapping has changed; the client must mark the old address as invalid and start using the new address. 😭
5.2.6. Sending Teredo Bubbles 🫧
The Teredo client may have to send a bubble towards another Teredo client, either after a packet reception or after a transmission attempt, as explained in Sections 5.2.3 and 5.2.4. There are two kinds of bubbles: direct bubbles, which are sent directly to the mapped IPv4 address and mapped UDP port of the peer, and indirect bubbles, which are sent through the Teredo server of the peer. 🍓
When a Teredo client attempts to send a direct bubble, it extracts the mapped IPv4 address and mapped UDP port from the Teredo IPv6 address of the target. It then checks whether there is already an entry for this IPv6 address in the current list of peers. If there is no entry, the client MUST create a new list entry for the address, setting the last reception date and the last transmission date to 30 seconds before the current date, and the number of bubbles to zero. 📝
When a Teredo client attempts to send an indirect bubble, it extracts the Teredo server IPv4 address from the Teredo prefix of the IPv6 address of the target (different clients may be using different servers). The bubble will be sent to that IPv4 address and the Teredo UDP port. 🛰️
Bubbles may be lost in transit, and it is reasonable to enhance the reliability of the Teredo service by allowing multiple transmissions. However, bubbles will also be lost systematically in certain NAT configurations. In order to strike a balance between reliability and unnecessary retransmissions, we specify the following:
- The client MUST NOT send a bubble if the last transmission date and time is less than 2 seconds before the current date and time;
- The client MUST NOT send a bubble if it has already sent 4 bubbles to the peer in the last 300 seconds without receiving a direct response.
In the other cases, the client MAY proceed with the transmission of the bubble. When transmitting the bubble, the client MUST update the last transmission date and time to that peer, and must also increment the number of transmitted bubbles. ⚖️
5.2.7. Optional Refresh Interval Determination Procedure 🕰️
In addition to the regular client resources described in the beginning of this section, the refresh interval determination procedure uses an additional UDP port, the Teredo secondary port, and the following variables:
- Teredo secondary connectivity status,
- Mapped address and port number of the Teredo secondary port,
- Teredo secondary IPv6 prefix associated with the secondary port,
- Teredo secondary IPv6 address derived from this prefix,
- Date and time of the last interaction on the secondary port,
- Maximum Teredo Refresh Interval.
- Candidate Teredo Refresh Interval.
The secondary connectivity status, mapped address and prefix are determined by running the qualification procedure on the secondary port. When the client uses the interval determination procedure, the qualification procedure MUST be run for the secondary port immediately after running it on the service port. If the secondary qualification fails, the interval determination procedure will not be used, and the interval value will remain at the default value, 30 seconds. If the secondary qualification succeeds, the maximum refresh interval is set to 120 seconds, and the candidate Teredo refresh interval is set to 60 seconds, i.e., twice the Teredo refresh interval. 🧮
The procedure is then performed at regular intervals, until it concludes:
- Wait until the candidate refresh interval is elapsed after the last interaction on the secondary port.
- Send a Teredo bubble to the Teredo secondary IPv6 address, through the service port.
- Wait for reception of the bubble on the secondary port. If a timer of 2 seconds elapses without reception, repeat step 2 at most three times. If there is still no reception, the candidate has failed; if there is a reception, the candidate has succeeded. 🎯
- If the candidate has succeeded, set the Teredo refresh interval to the candidate value, and set a new candidate value to the minimum of twice the new refresh interval, or the average of the refresh interval and the maximum refresh interval. ✅
- If the candidate has failed, set the maximum refresh interval to the candidate value. If the current refresh interval is larger than or equal to 75% of the maximum, the determination procedure has concluded; otherwise, set a new candidate value to the average of the refresh interval and the maximum refresh interval. ❌
- If the procedure has not concluded, perform the maintenance procedure on the secondary port, which will reset the date and time of the last interaction on the secondary port, and may result in the allocation of a new Teredo secondary IPv6 address. This would not affect the values of the refresh interval, candidate interval, or maximum refresh interval. 🔄
The secondary port MUST NOT be used for any other purpose than the interval determination procedure. It should be closed when the procedure ends. 🔒
5.2.8. Optional Local Client Discovery Procedure ✨
Okay bestie, so it's desirable for Teredo clients hanging out behind the same NAT to talk to each other directly, instead of getting routed through a Teredo server every single time 💅. It's hard to build a solution that works for everyone, but we can build a partial one when the clients are connected over IPv4 to the same link 🦋.
A Teredo client who wants local discovery SHOULD join the IPv4 multicast group identified by Teredo IPv4 Discovery Address. The client SHOULD wait for discovery bubbles to show up on the Teredo IPv4 Discovery Address. It SHOULD also send local discovery bubbles to that address at random intervals, uniformly distributed between 200 and 300 seconds. A local Teredo bubble has these vibes:
IPv4 source address: the IPv4 address of the senderIPv4 destination address: the Teredo IPv4 Discovery AddressIPv4 ttl:1UDP source port: the Teredo service port of the senderUDP destination port: the Teredo UDP portUDP payload: a minimal IPv6 packet, as followsIPv6 source: the global Teredo IPv6 address of the senderIPv6 destination: the all-nodes on-link multicast addressIPv6 payload type:59(No Next Header, as per [RFC2460])IPv6 payload length:0IPv6 hop limit:1
Real talk, the local discovery procedure has a denial of service risk 😭. Malevolent nodes could send fake bubbles to unsuspecting parties and catch the traffic coming from those parties. The risk gets mitigated by the filtering rules in Section 5.2.5, and also by the "link only" multicast scope of the Teredo IPv4 Discovery Address, which means packets sent to this address will not be forwarded across routers 🛡️.
To get the "link only multicast" protection, clients should silently discard all local discovery bubbles received over a unicast address. To mitigate the denial of service risk even further, the client MUST silently discard all local discovery bubbles whose IPv6 source address is not a well-formed Teredo IPv6 address, or whose IPv4 source address does not belong to the local IPv4 subnet. The client MAY also decide to silently discard all local discovery bubbles whose Teredo IPv6 address does not include the same mapped IPv4 address as its own 🙅♀️.
If the bubble gets accepted, the client checks whether there's an entry in the list of recent peers that matches the mapped IPv4 address and mapped UDP port tied to the source IPv6 address of the bubble. If there is such an entry, the client MUST update the local peer address and local peer port parameters so they reflect the IPv4 source address and UDP source port of the bubble. If there's no entry, the client MUST create one. It sets the local peer address and local peer port parameters to reflect the IPv4 source address and UDP source port of the bubble, sets the last reception date to the current date and time, sets the last transmission date to 30 seconds before the current date, and sets the number of bubbles to zero. The state of the entry is set to "not trusted" 🫶.
When a discovery bubble comes in, clients reply with a unicast bubble as specified in Section 5.2.3 💖.
5.2.9. Direct IPv6 Connectivity Test
The Teredo procedures are designed to enable direct connections between a Teredo host and a Teredo relay 🧚. Teredo hosts behind a cone NAT will receive packets directly from relays. Other Teredo hosts will learn the original addresses and UDP ports of third parties through the local Teredo server. In all of these cases, there's a risk that the IPv6 address of the source gets spoofed by a malevolent party 👀. Teredo hosts must make two decisions: whether to accept the packet for local processing, and whether to transmit further packets to the IPv6 address through the newly learned IPv4 address and UDP port.
The basic rule is that hosts should be generous in what they accept and careful in what they send 🌸. Refusing packets over spoofing concerns would wreck connectivity, so it should only happen when there's a near certainty that the source address is spoofed. On the other hand, sending packets to the wrong address should be avoided, no cap 💅.
When the client wants to send a packet to a native IPv6 node or a 6to4 node, it should check whether a valid peer entry already exists for the IPv6 address of the destination. If it doesn't, the client picks a random number (a nonce) and formats an ICMPv6 Echo Request message. Its source is the local Teredo address, its destination is the address of the IPv6 node, and its Data field is set to the nonce. (It is recommended to use a random number at least 64 bits long 🎀.) The nonce value and the date the packet was sent get documented in a provisional peer entry for the IPV6 destination. The ICMPv6 packet then gets sent encapsulated in a UDP packet destined to the Teredo server IPv4 address and to the Teredo port. The rules of Section 5.2.3 specify how the reply to this packet gets processed 🔥.
5.2.10. Working around symmetric NAT
The client procedures are designed to enable IPv6 connectivity through the most common NAT types, which people often call "cone NAT" and "restricted cone NAT" [RFC3489]. Some NATs have a different design, and those are often called "symmetric NAT". The qualification algorithm in Section 5.2.1 will not succeed when the local NAT is a symmetric NAT 😩.
Good news though: in many cases you can work around these NAT limitations by explicitly reserving a UDP port for Teredo service on a client. This is usually done with a function often called "DMZ" in the NAT's manual 🍓. That port becomes the "service port" used by the Teredo hosts. Implementers of Teredo functions in hosts must make sure the value of the service port can be explicitly provisioned, so the user can put the same value in the host and in the NAT ✨.
The reservation procedure guarantees the port mapping stays the same for all destinations. After the explicit reservation, the qualification algorithm in Section 5.2.1 will succeed, and the Teredo client will behave as if it's behind a "cone NAT" 👑.
When different clients use Teredo behind a single symmetric NAT, each of them must reserve and use a different service port. Don't let them share, it's giving chaos 💀.
5.3. Teredo Server Specification
The Teredo server is designed to be stateless 🦋. It waits for incoming UDP packets at the Teredo Port, using the IPv4 address that has been selected for the service. The server can also receive and transmit some packets using a different IPv4 address and a different port number.
The Teredo server acts as an IPv6 router. As such, it receives Router Solicitation messages, and it responds to them with Router Advertisement messages as explained in Section 5.3.2. It may also receive other packets, for example ICMPv6 messages and Teredo bubbles, which get processed according to the IPv6 specification 🌈.
By default, the routing functions of the Teredo server are limited. Teredo servers are expected to relay Teredo bubbles, ICMPv6 Echo requests, and ICMPv6 Echo replies, but they are not expected to relay other types of IPv6 packets 🙈. Operators may, however, decide to combine the functions of "Teredo server" and "Teredo relay", as explained in Section 5.4.
5.3.1. Processing of Teredo IPv6 Packets
Before processing the packet, the Teredo server MUST check the validity of the encapsulated IPv6 source address, the IPv4 source address, and the UDP source port 🔍:
- If the UDP content is not a well-formed Teredo IPv6 packet, as defined in Section 5.1.1, the packet MUST be silently discarded.
- If the UDP packet is not a Teredo bubble or an ICMPv6 message, it SHOULD be discarded. (The packet may be processed if the Teredo server also operates as a Teredo relay, as explained in Section 5.4.)
- If the IPv4 source address is not in the format of a global unicast address, the packet MUST be silently discarded (see Section 5.2.4 for a definition of global unicast addresses).
- If the IPv6 source address is an IPv6 link-local address, the IPv6 destination address is the link-local scope all routers multicast address (
FF02::2), and the packet contains an ICMPv6 Router Solicitation message, the packet MUST be accepted. It MUST be discarded if the server requires secure qualification and the authentication encapsulation is absent or verification fails 🔐. - If the IPv6 source address is a Teredo IPv6 address, and if the IPv4 address and UDP port embedded in that address match the IPv4 source address and UDP source port, the packet SHOULD be accepted.
- If the IPv6 source address is not a Teredo IPv6 address, and if the IPv6 destination address is a Teredo address allocated through this server, the packet SHOULD be accepted.
- In all other cases, the packet MUST be silently discarded.
Next, the Teredo server checks the IPv6 destination address of the encapsulated IPv6 packet 👀.
If the IPv6 destination address is the link-local scope all routers multicast address (FF02::2), or the link-local address of the server, the Teredo server processes the packet. It may have to process Router Solicitation messages and ICMPv6 Echo Request messages 🧚.
If the destination IPv6 address is not a global scope IPv6 address, the packet MUST NOT be forwarded 🚫.
If the destination address is not a Teredo IPv6 address, the packet should be relayed to the IPv6 Internet using regular IPv6 routing 🌍.
If the IPv6 destination address is a valid Teredo IPv6 address as defined in Section 2.13, the Teredo Server MUST check that the IPv4 address derived from this IPv6 address is in the format of a global unicast address. If this is not the case, the packet MUST be silently discarded 💅.
If the address is valid, the Teredo server encapsulates the IPv6 packet in a new UDP datagram, in which the following parameters are set:
- The destination IPv4 address is derived from the IPv6 destination.
- The source IPv4 address is the Teredo server IPv4 address.
- The destination UDP port is derived from the IPv6 destination.
- The source UDP port is set to the Teredo UDP Port.
If the destination IPv6 address is a Teredo client whose address is serviced by this specific server, the server should insert an origin indication in the first bytes of the UDP payload, as specified in Section 5.1.1. (To verify that the client is served by this server, the server compares bits 32-63 of the client's Teredo IPv6 address to the server's IPv4 address 🫶.)
5.3.2. Processing of Router Solicitations ✨
okay so when the Teredo server gets a Router Solicitation message (RS, [RFC2461]) 🌸, it holds onto the IPv4 address and UDP port the solicitation came from 💖. Those become the client's Teredo mapped address and Teredo mapped port. The router uses these values to build the origin indication encapsulation that gets sent with the response 🎀.
The Teredo server answers the router solicitation by sending a Router Advertisement message [RFC2461] 🦋. The router advertisement MUST advertise the Teredo IPv6 prefix built from the service prefix and the server's IPv4 address 👑. The IPv6 source address should be set to a Teredo link-local server address tied to the local interface ✨. This address is derived from the server's IPv4 address and the Teredo port, as specified in Section 4 🧚, and the cone bit is set to 1. The IPv6 destination address is set to the IPv6 source address of the RS 💅.
The Router Advertisement message must be sent over UDP to the client's Teredo mapped address and Teredo mapped port 🫶. The IPv4 source address and UDP source port should be set to the server's IPv4 address and Teredo Port. If the cone bit of the client's IPv6 address is set to 1, the RA must be sent from a different IPv4 source address than the server address the RS was received on. If the cone bit is set to zero, the response must be sent back from the same address 😭.
Before sending the packet, the Teredo server MUST check that the IPv4 destination address is in the format of a global unicast address. If that's not the case, the packet MUST be silently discarded (see Section 5.2.4 for a definition of global unicast addresses) 💀.
If secure qualification is required, the server MUST insert a valid authentication parameter in the UDP packet carrying the router advertisement 🔥. The client identifier and the nonce value used in the authentication parameter MUST be the same identifier and nonce as received in the router solicitation. The confirmation byte MUST be set to zero if the client identifier is still valid, and a non-null value otherwise. The authentication value SHOULD be computed using the secret that corresponds to the client identifier 🔐.
5.4. Teredo Relay Specification 🌈
Teredo relays are IPv6 routers that advertise reachability of the Teredo service IPv6 prefix through the IPv6 routing protocols. (A minimal Teredo relay may serve just a local host, and would not advertise the prefix beyond this host.) Teredo relays will receive IPv6 packets bound to Teredo clients ✨. Teredo relays should be able to receive packets sent over IPv4 and UDP by Teredo clients. They may apply filtering rules, e.g., only accept packets from Teredo clients if they have previously sent traffic to these Teredo clients 🦋.
The receiving and sending rules used by Teredo relays are very similar to those of Teredo clients. Teredo relays must use a Teredo service port to transmit packets to Teredo clients. They must maintain a "list of peers", identical to the list of peers maintained by Teredo clients 💖.
5.4.1. Transmission by Relays to Teredo Clients ✨
When a Teredo relay has to transmit a packet to a Teredo client, it examines the destination IPv6 address 👀. By definition, the Teredo relays will only send over UDP IPv6 packets whose IPv6 destination address is a valid Teredo IPv6 address.
Before processing these packets, the Teredo Relay MUST check that the IPv4 destination address embedded in the Teredo IPv6 address is in the format of a global unicast address. If that's not the case, the packet MUST be silently discarded (see Section 5.2.4 for a definition of global unicast addresses) 🙈.
The relay then checks if there is an entry for this IPv6 address in the list of recent Teredo peers, and if the entry is still valid. Then it does the following 🫶:
- If there is an entry for that IPv6 address in the list of peers, and if the status of the entry is set to "trusted", the IPv6 packet should be sent over UDP to the mapped IPv4 address and mapped UDP port of the entry. The relay updates the date of last transmission in the peer entry 💅.
- If there is no trusted entry in the list of peers, and if the destination is a Teredo IPv6 address in which the cone bit is set to 1, the packet is sent over UDP to the mapped IPv4 address and mapped UDP port extracted from that IPv6 address 🌸.
- If there is no trusted entry in the list of peers, and if the destination is a Teredo IPv6 address in which the cone bit is set to 0, the Teredo relay creates a bubble whose source address is set to a local IPv6 address, and whose destination address is set to the Teredo IPv6 address of the packet's destination. The bubble is sent to the server address corresponding to the Teredo destination. The entry becomes trusted when a bubble or another packet is received from this IPv6 address. If no such packet is received before a time-out of 2 seconds, the Teredo relay may repeat the bubble, up to three times. If the relay fails to receive a bubble after these repetitions, the entry is removed from the list of peers. The relay MAY queue packets bound to untrusted entries. The queued packets SHOULD be de-queued and forwarded when the entry becomes trusted, and they SHOULD be deleted if the entry is deleted. To avoid denial of service attacks, the relays SHOULD limit the number of packets in such queues 😤.
In cases 2 and 3, the Teredo relay should create a peer entry for the IPv6 address. The entry status is marked as trusted in case 2 (cone NAT) and not trusted in case 3. In case 3, if the Teredo relay happens to be located behind a non-cone NAT, it should also send a bubble directly to the mapped IPv4 address and mapped port number of the Teredo destination. This will "open the path" for the return bubble from the Teredo client 🧚.
For reliability reasons, relays MAY decide to ignore the value of the cone bit in the flag, and always perform the "case 3", i.e., treat all Teredo peers as if they were located behind a non-cone NAT. This will result in some increase in traffic, but may avoid reliability issues if the determination of the NAT status was for some reason erroneous. For the same reason, relays MAY also decide to always send a direct bubble to the mapped IPv4 address and mapped port number of the Teredo destination, even if they do not believe that they are located behind a non-cone NAT 🛡️.
5.4.2. Reception from Teredo Clients ✨
The Teredo relay may receive packets from Teredo clients. The packets should normally only be sent by clients to which the relay previously transmitted packets, i.e., clients whose IPv6 address is present in the list of peers 💜. Relays, like clients, use the packet reception procedure to maintain the date and time of the last interaction with the Teredo server and the "list of recent peers" 🕰️.
When a UDP packet is received over the Teredo service port, the Teredo relay checks that it contains a valid IPv6 packet as specified in [RFC2460]. If that's not the case, the packet is silently discarded 🙅♀️.
Then, the Teredo relay examines whether the IPv6 source address is a valid Teredo address, and whether the mapped IPv4 address and mapped port match the IPv4 source address and port number the packet was received from. If that's not the case, the packet is silently discarded 🚫.
The Teredo relay then examines whether there is an entry for the IPv6 source address in the list of recent peers. If there isn't, the packet may be silently discarded. If there is, the entry status is set to "trusted", and the relay updates the "date and time of the last interaction" to the current date and time ⭐.
Finally, the relay examines the destination IPv6 address. If the destination belongs to a range of IPv6 addresses served by the relay, the packet SHOULD be accepted and forwarded to the destination. In the other cases, the packet SHOULD be silently discarded 🎀.
5.4.3. Difference between Teredo Relays and Teredo Servers ✨
Because Teredo servers can relay Teredo packets over IPv6, all Teredo servers must be capable of behaving as Teredo relays. There is, however, no requirement that Teredo relays behave as Teredo servers 🧚♀️.
The dual role of server and relays adds some complexity to programming servers. The processing of incoming packets should be a combination of the server processing rules defined in Section 5.3.1 and the relay processing rules defined in Section 5.4.2. (Section 5.3 only specifies the rules implemented by a pure server, not a combination relay+server.) 🤓
5.5. Implementation of Automatic Sunset 🌅
Teredo is designed as an interim transition mechanism, and it is important that it should not be used any longer than necessary. The "sunset" procedure will be implemented by Teredo clients, servers, and relays, as specified in this section 🌙.
The Teredo-capable nodes MUST NOT behave as Teredo clients if they already have IPv6 connectivity through any other means, such as native IPv6 connectivity. In particular, nodes that have a global IPv4 address SHOULD obtain connectivity through the 6to4 service rather than through the Teredo service. The classic reason a node that doesn't need connectivity would still enable the Teredo service is to guarantee good performance when interacting with Teredo clients. However, a Teredo-capable node that has IPv4 connectivity and has obtained IPv6 connectivity outside the Teredo service MAY decide to behave as a Teredo relay, and still get good performance when interacting with Teredo clients 💫.
The Teredo servers are expected to take part in the sunset procedure by announcing a date at which they will stop providing the service. This date depends on the availability of alternative solutions for their clients, such as "dual-mode" gateways that behave simultaneously as IPv4 NATs and IPv6 routers. Most Teredo servers won't be expected to operate more than a few years. Teredo relays are expected to have the same life span as Teredo servers 🦋.
6. Further Study, Use of Teredo to Implement a Tunnel Service ✨
okay so this section is a bestie-level "what if??" brainstorm 🧚. Teredo gives NAT traversal with very little resource at the server, and IETF folks have been talking about needing both a Teredo-style solution and a more controlled one that uses configured tunnels to a service provider [RFC3904]. So this section is a tentative look at how Teredo could be extended to also support a configured tunnel service 💅.
It may be possible to design a tunnel server protocol that is compatible with Teredo, which means the same client could be used either in the Teredo service or with a tunnel service 🎀. In fact, this could be done by configuring the client with:
- The IPv4 address of a Teredo server that acts as a tunnel broker
- A client identifier
- A shared secret with that server
- An agreed-upon authentication algorithm
The Teredo client would use the secure qualification procedure, as specified in Section 5.2.2. Instead of handing back a Teredo prefix in the router advertisement, the server would return a globally routable IPv6 prefix 🌈. This prefix could be permanently assigned to the client, which would give the client a stable address (ngl, this is the glow-up). The server would have to keep state, i.e., memorize the association between the prefix assigned to the client and the mapped IPv4 address and mapped UDP port of the client 🧠.
The Teredo server would advertise reachability of the client prefix to the IPv6 Internet. Any packet bound to that prefix would be transmitted to the mapped IPv4 address and mapped UDP port of the client 🦋.
The Teredo client, when it receives the prefix, would notice that this prefix is a global IPv6 prefix, not in the form of a Teredo prefix. At that point the client would recognize that it should operate in tunnel mode. A client that operates in tunnel mode would execute a much simpler transmission procedure: it would forward any packet sent to the Teredo interface to the IPv4 address and Teredo UDP port of the server 🍓.
The Teredo client would have to perform the maintenance procedure described in Section 5.2.5. The server would receive the router solicitation, and could notice a possible change of mapped IPv4 address and mapped UDP port that could result from the reconfiguration of the mappings inside the NAT. The server should continue advertising the same IPv6 prefix to the client, and should update the mapped IPv4 address and mapped UDP port associated to this prefix, if necessary 🔥.
There is as yet no consensus that a tunnel-mode extension to Teredo should be developed. This section is only intended to provide suggestions to the future developers of such services. Many details would probably have to be worked out before a tunnel-mode extension would be agreed upon 🙈.
7. Security Considerations ⚠️
okay this part is SERIOUS, bestie 😭. The main objective of Teredo is to give nodes located behind a NAT a globally routable IPv6 address. Teredo nodes can use IP security (IPsec) services such as Internet Key Exchange (IKE), Authentication Header (AH), or Encapsulation Security Payload (ESP) [RFC4306, RFC4302, RFC4303], without the configuration restrictions still present in "Negotiation of NAT-Traversal in the IKE" [RFC3947]. So we can argue that the service has a positive effect on network security ✨. However, the security analysis must also envisage the negative effects of the Teredo services, which we can group in four categories: security risks of directly connecting a node to the IPv6 Internet, spoofing of Teredo servers to enable a man-in-the-middle attack, potential attacks aimed at denying the Teredo service to a Teredo client, and denial of service attacks against non-Teredo participating nodes that would be enabled by the Teredo service 🚨.
In the following, we review these four types of issues in detail, and we present mitigating strategies for each of them 🛡️.
7.1. Opening a Hole in the NAT
The very purpose of the Teredo service is to make a machine reachable through IPv6. By definition, the machine using the service will give up whatever firewall service was available in the NAT box, however limited this service may be [RFC2993]. The services that listen to the Teredo IPv6 address will become the potential target of attacks from the entire IPv6 Internet. This may sound scary, but there are three mitigating factors 😬.
The first mitigating factor is the possibility to restrict some services to only accept traffic from local neighbors, e.g., using link-local addresses. Teredo does not support communication using link-local addresses. This implies that link-local services will not be accessed through Teredo, and will be restricted to whatever other IPv6 connectivity may be available, e.g., direct traffic with neighbors on the local link, behind the NAT 🧚.
The second mitigating factor is the possible use of a "local firewall" solution, i.e., a piece of software that performs locally the kind of inspection and filtering that is otherwise performed in a perimeter firewall. Using such software is recommended 💜.
The third mitigating factor is the availability of IP security (IPsec) services such as IKE, AH, or ESP [RFC4306, RFC4302, RFC4303]. Using these services in conjunction with Teredo is a good policy, as it will protect the client from possible attacks in intermediate servers such as the NAT, the Teredo server, or the Teredo relay. (However, these services can be used only if the parties in the communication can negotiate a key, which requires agreeing on some credentials; this is known to be a hard problem 😵💫.)
7.2. Using the Teredo Service for a Man-in-the-Middle Attack
The goal of the Teredo service is to provide hosts located behind a NAT with a globally reachable IPv6 address. There is a possible class of attacks against this service in which an attacker somehow intercepts the router solicitation, responds with a spoofed router advertisement, and provides a Teredo client with an incorrect address. The attacker may have one of two objectives: it may try to deny service to the Teredo client by providing it with an address that is in fact unreachable, or it may try to insert itself as a relay for all client communications, effectively enabling a variety of "man-in-the-middle" attacks 👀.
7.2.1. Attacker Spoofing the Teredo Server
The simple nonce verification procedure described in Section 5.2.2 provides a first level of protection against attacks in which a third party tries to spoof the server. In practice, the nonce procedure can be defeated only if the attacker is "on path" 🛤️.
If client and server share a secret and agree on an authentication algorithm, the secure qualification procedure described in Section 5.2.2 provides further protection. To defeat this protection, the attacker could try to obtain a copy of the secret shared between client and server. The most likely way to obtain the shared secret is to listen to the traffic and mount an offline dictionary attack; to protect against this attack, the secret shared between client and server should contain sufficient entropy. (This probably requires some automated procedure for provisioning the shared secret and the algorithm.) 🔐
If the shared secret contains sufficient entropy, the attacker would have to defeat the one-way function used to compute the authentication value. This specification suggests a default algorithm combining HMAC and MD5. If the protection afforded by MD5 was not deemed sufficient, clients and servers can agree to use a different algorithm, e.g., SHA1 🔑.
Another way to defeat the protection afforded by the authentication procedure is to mount a complex attack, as follows:
- Client prepares router solicitation, including authentication encapsulation.
- Attacker intercepts the solicitation, and somehow manages to prevent it from reaching the server, for example, by mounting a short-duration DoS attack against the server.
- Attacker replaces the source IPv4 address and source UDP port of the request by one of its own addresses and port, and forwards the modified request to the server.
- Server dutifully notes the IPv4 address from which the packet is received, verifies that the Authentication encapsulation is correct, prepares a router advertisement, signs it, and sends it back to the incoming address, i.e., the attacker.
- Attacker receives the advertisement, takes note of the mapping, replaces the IPv4 address and UDP port by the original values in the intercepted message, and sends the response to the client.
- Client receives the advertisement, notes that the authentication header is present and is correct, and uses the proposed prefix and the mapped addresses in the origin indication encapsulation.
The root cause of the problem is that the NAT is, in itself, a man-in-the-middle attack. The Authentication encapsulation covers the encapsulated IPv6 packet, but does not cover the encapsulating IPv4 header and UDP header. It is very hard to devise an effective authentication scheme, since the attacker does not do anything else than what the NAT legally does! 😱
However, there are several mitigating factors that lead us to avoid worrying too much about this attack 🌸. In practice, the gain from the attack is either to deny service to the client or to obtain a "man-in-the-middle" position. However, in order to mount the attack, the attacker must be able to suppress traffic originating from the client, i.e., have denial of service capability; the attacker must also be able to observe the traffic exchanged between client and inject its own traffic in the mix, i.e., have man-in-the-middle capacity. In summary, the attack is very hard to mount, and the gain for the attacker in terms of "elevation of privilege" is minimal 🙌.
A similar attack is described in detail in the security section of [RFC3489].
7.2.2. Attacker Spoofing a Teredo Relay
An attacker may try to use Teredo either to pass itself off as another IPv6 host or to place itself as a man-in-the-middle between a Teredo host and a native IPv6 host. The attacker will mount such attacks by spoofing a Teredo relay, i.e., by convincing the Teredo host that packets bound to the native IPv6 host should be relayed to the IPv4 address of the attacker 🕵️♀️.
The possibility of the attack derives from the lack of any algorithmic relation between the IPv4 address of a relay and the native IPv6 addresses served by these relays. A Teredo host cannot decide just by looking at the encapsulating IPv4 and UDP header whether or not a relay is legitimate. If a Teredo host decided to simply trust the incoming traffic, it would easily fall prey to a relay-spoofing attack 🥀.
The attack is mitigated by the "direct IPv6 connectivity test" specified in Section 5.2.9. The test specifies a relay discovery procedure secured by a nonce. The nonce is transmitted from the Teredo host to the destination through the Teredo server, which the client normally trusts. The response arrives through the "natural" relay, i.e., the relay closest to the IPv6 destination. Sending traffic to this relay will place it out of reach of attackers that are not on the direct path between the Teredo host and its IPv6 peer 💖.
End-to-end security protections are required to defend against spoofing attacks if the attacker is on the direct path between the Teredo host and its peer 🫶.
7.2.3. End-to-End Security 🔐
Okay bestie, so the most effective defense a Teredo client has is probably not trying to lock down the Teredo service itself 🙅♀️. Even if the mapping can be securely obtained, an attacker could still listen to the traffic and send spoofed packets 👀. The real move is for the Teredo client to realize that, since it's chilling behind a NAT, it's in a situation of vulnerability 🥺. It should systematically try to encrypt its IPv6 traffic using IPsec 🔒. Even if the IPv4 and UDP headers are vulnerable, IPsec will effectively stop third parties from spoofing and listening to the IPv6 packets 💅. Since every client gets a global IPv6 address, Teredo makes IPsec work without the configuration restrictions still present in "Negotiation of NAT-Traversal in the IKE" [RFC3947], and it ultimately levels up the security of these clients ✨🎀.
7.3. Denial of the Teredo service 🫧
Our analysis outlines five ways to attack the Teredo service 😤. The good news is there are countermeasures for each of them 🛡️.
7.3.1. Denial of Service by a Rogue Relay 🤖
An attacker can go after the IPv6 side of the service by setting up a rogue relay and letting that relay advertise a route to the Teredo IPv6 prefix 🚩. This is an attack against IPv6 routing, which can also be mitigated by the same kind of procedures used to get rid of spurious route advertisements 🧹. Dual-stack nodes that implement "host local" Teredo relays are totally impervious to this attack 💖.
7.3.2. Denial of Service by Server Spoofing 🎭
Back in Section 7.2, we talked about using spoofed router advertisements to insert an attacker in the middle of a Teredo conversation 👀. Those same spoofed router advertisements can also be used to hand a client an incorrect address 😬. That address could point to a non-existing IPv4 address or to the IPv4 address of a third party 🙃.
The Teredo client will notice something's up when it fails to receive traffic through the newly acquired IPv6 address 🚨. The attack can be mitigated by using the authentication encapsulation 🧁.
7.3.3. Denial of Service by Exceeding the Number of Peers 📚
A Teredo client manages a cache of recently used peers, which is what makes it stateful 🧠. An attacker can mess with the client by provoking it to respond to packets that appear to come from a large number of Teredo peers 🌪️. That trashes the cache and effectively denies direct communication between peers 💀. The good news is that the effect only lasts as long as the attack is sustained ⏳.
7.3.4. Attacks against the Local Discovery Procedure 🏘️
There's a possible denial of service attack against the local peer discovery procedure, if attackers can manage to send spoofed local discovery bubbles to a Teredo client 🫧. The checks described in Section 5.2.8 mitigate this attack ✅. Clients who care more about security than performance could decide to disable the local discovery procedure 🔐. Just know that if local discovery is disabled, traffic between local nodes will end up being relayed through a server outside the local network, which has questionable security implications 🤷♀️.
7.3.5. Attacking the Teredo Servers and Relays 🏹
It's possible to mount a brute force denial of service attack against the Teredo servers by sending them a very large number of packets 📦📦📦. This attack has to be brute force, since the servers are stateless and can be designed to process all the packets that are sent on their access line 💪.
The brute force attack against the Teredo servers is mitigated if clients are ready to "failover" to another server 🏃♀️. Bringing down the servers will, however, force the clients that change servers to renumber their Teredo address 😭.
It's also possible to mount a brute force attack against a Teredo relay 🎯. This attack is mitigated if the relay under attack stops announcing the reachability of the Teredo service prefix to the IPv6 network, because then the traffic will be picked up by the next relay 🔁.
An attack similar to the one described in Section 7.3.2 can be mounted against a relay too 🫠. An IPv6 host can send IPv6 packets to a large number of Teredo destinations, forcing the relay to establish state for each of them 📈. Teredo relays can get some protection by limiting the range of IPv6 clients that they serve, and by limiting the amount of state used for "new" peers 🛡️🩷.
7.4. Denial of Service against Non-Teredo Nodes 🌐
There's a widely expressed concern that transition mechanisms like Teredo can be used to mount denial of service attacks, by injecting traffic at locations where it isn't expected 😱. These attacks fall into three categories: using the Teredo servers as a reflector in a denial of service attack, using the Teredo server to carry a denial of service attack against IPv6 nodes, and using the Teredo relays to carry a denial of service attack against IPv4 nodes 🗂️. The analysis of these attacks follows 👇.
A common mitigating factor in all cases is the "regularity" of the Teredo traffic 🌈. It contains highly specific patterns, such as the Teredo UDP port or the Teredo IPv6 prefix 🔍. When attacks happen, those patterns can be used to quickly install filters and remove the offending traffic 🧹✨.
We should also note that none of the listed possibilities offer any noticeable amplification 💤.
7.4.1. Laundering DoS attacks from IPv4 to IPv4 🧺
An attacker can use the Teredo servers as reflectors in a denial of service attack aimed at an IPv4 target 🪞. There are two ways to do this. The first way is to construct a Router Solicitation message and post it to a Teredo server, using the spoofed address of the target as the IPv4 source address 📮. The Teredo server will then send a Router advertisement message to the target 📬. The second way is to construct a Teredo IPv6 address using the Teredo prefix, the address of a selected server, the IPv4 of the target, and an arbitrary UDP port 🧩. Then the attacker sends packets bound to that address to the selected Teredo server 🚀.
Reflector attacks are discussed in [REFLECT], which outlines various mitigating techniques against them 📖. One of these mitigations is to observe that "the traffic generated by the reflectors [has] sufficient regularity and semantics that it can be filtered out near the victim without the filtering itself constituting a denial-of-service to the victim ('collateral damage')". The traffic reflected by the Teredo servers meets this condition 🙌. It's clearly recognizable because it comes from the Teredo UDP port, and it can be filtered out safely if the target itself isn't a Teredo user 🫶. On top of that, the packets relayed by servers carry an Origin indication encapsulation, which helps determine the source of the attack 🕵️♀️🔎.
7.4.2. DoS Attacks from IPv4 to IPv6 🌩️
An attacker may use the Teredo servers to launch a denial of service attack against an arbitrary IPv6 destination 🎯. The attacker builds an IPv6 packet bound for the target, then sends that packet to the IPv4 address and UDP port of a Teredo server, which relays it from there to the target over IPv6 📡.
The address checks specified in Section 5.3.1 give some protection against this attack 🛡️. They make sure the IPv6 source address is consistent with the IPv4 source address and UDP source port the attacker used. So if the attacker can't spoof the IPv4 source address, the target will be able to figure out where the attack came from 🕵️.
The address checks also make sure the IPv6 source address of packets forwarded by servers starts with the IPv6 Teredo prefix 🏷️. That's a mitigating factor, because sites under attack could use it to filter out all packets sourced from that prefix during an attack 🧱. The tradeoff is a partial loss of service, since the target won't be able to communicate with legitimate Teredo hosts that use the same prefix 😔.
Still, communication with other IPv6 hosts will remain unaffected 🙏, and communication with Teredo hosts can resume once the attack has ceased 🌸.
7.4.3. DoS Attacks from IPv6 to IPv4 🌪️
An attacker with IPv6 connectivity may use the Teredo relays to launch a denial of service attack against an arbitrary IPv4 destination 🎯. The attacker composes a Teredo IPv6 address using the Teredo prefix, a "cone" flag set to 1, the IPv4 address of the target, and an arbitrary UDP port 🧵.
In the simplest version of this attack, the attacker sends IPv6 packets to the Teredo destination using regular IPv6 routing 📨. The packets get picked up by the nearest relay, which forwards them to the IPv4 address of the target 🎯. In a more elaborate variant, the attacker tricks a Teredo host into sending packets to the target 😈. They can do that either by sending a first packet with a spoofed IPv6 address and letting the Teredo host reply, or by publishing a spoofed IPv6 address in a name service 📢.
There are three types of IPv4 addresses an attacker may embed in the spoofed Teredo address 🧩. It may embed a multicast or broadcast address, a local unicast address, or a global unicast address 🌍.
With multicast or broadcast addresses, the attacker can use the multiplying effect of multicast routing 🪄. By sending a single packet, it can affect a large number of hosts, kind of like the "smurf" attack 💥.
By using local addresses, the attacker can reach hosts that aren't normally reachable from the Internet, like hosts connected to a Teredo relay by a private subnet 🏠. This creates an exposure for, at a minimum, a denial of service attack against these otherwise protected hosts 🚧. It's similar to attack variants that use source routing to breach a perimeter 🫣.
The address checks specified in Section 5.2.4, 5.3.1, and 5.4.1 verify that packets are relayed only to a global IPv4 address ✅. They're designed to eliminate the possibility of using broadcast, multicast, or local addresses in denial of service or other attacks 🙅♀️. From here on, we'll only consider attacks targeting globally reachable unicast addresses 🔭.
The attacks can be aimed at arbitrary UDP ports, like the DNS port of a server 🎯. The UDP payload has to be a well-formed IPv6 packet, so it's unlikely to be accepted by any well-written UDP service 🙈. In most cases, the only effect of the attack will be to overload the target with random traffic 📉.
There's a special case when the attack is directed at an echo service 🔁. The service echoes the packets back. Since the echo service sees the request coming from the IPv4 address of the relay, the echo replies get sent back to the same relay 🪞. According to the rules in Section 5.4, the Teredo relay will discard those packets 🗑️. This isn't a very efficient attack against Teredo relays, since establishing a legitimate session with an actual Teredo host would create more traffic 🤏.
The IPv6 packets sent to the target contain the IPv6 address the attacker used 📬. If ingress filtering is used in the IPv6 network, that address will be hard to spoof 🧱. If ingress filtering isn't used, the attacker can be traced if the IPv6 routers use a mechanism similar to ICMP Traceback 🔍. The ICMP messages will normally be collected by the same relays that forward the traffic from the attacker, and those relays can use the messages to identify the source of an ongoing attack 🕵️♀️. The details of this solution will have to be developed in further research 🧪🔮.
8. IAB Considerations ✨
Okay bestie, so the IAB has been studying this thing called "Unilateral Self Address Fixing" (UNSAF) 🎀. That's the general process where a client tries to figure out its address in another realm on the other side of a NAT, using a collaborative protocol reflection mechanism [RFC3424]. Teredo is totally an example of this 💅. The IAB said any protocol built for this purpose has to write down a specific set of considerations, and this section is where we do that 🫶.
8.1. Problem Definition
ngl, [RFC3424] says any UNSAF proposal has to give a precise definition of a specific, limited-scope problem that it's solving 🧚. A short-term fix shouldn't get stretched to solve other problems. That's why "short term fixes usually aren't" 🙈.
Teredo's problem is giving IPv6 connectivity to hosts that can't get IPv6 natively and can't use 6to4 either, because there's a NAT between them and the 6to4 relays 💖.
8.2. Exit Strategy
According to [RFC3424], any UNSAF proposal must provide a description of an exit strategy/transition plan. The best short-term fixes are the ones that naturally get used less and less as the right technology gets deployed 🦋.
Teredo comes with its own built-in exit strategy 👑. As soon as a client gets IPv6 connectivity another way, either 6to4 or native IPv6, it can stop using the Teredo service. We expect the next generation of home routers to offer IPv6 service alongside the current IPv4 NAT service, like relaying connectivity obtained from the ISP or using a configured or automatic tunnel service ✨.
As long as Teredo is being used, we'll still need Teredo relays so the remaining Teredo hosts can talk to native IPv6 hosts. As Teredo usage declines, the traffic load on the relays declines too. Over time, managers will notice reduced load on their relays and switch them off, which puts more pressure on the remaining Teredo hosts to upgrade to another form of connectivity 😭.
The exit is smooth because Teredo is an IP-level solution. IPv6-aware applications don't have to be updated to use or not use Teredo, so leaving it is just a matter of network connectivity 🌸.
There would appear to be reasons why a Teredo implementation might keep using the Teredo service even after it has connectivity some other way. For example:
- When a client is dual homed and wants to improve the service when talking to other Teredo hosts that are "nearby" on the IPv4 network. If the client only used its native IPv6 service, the Teredo hosts would only be reached through the relay. By keeping Teredo going, those hosts can be reached by direct transmission over IPv4.
- If, for some reason, the Teredo link gives the client better service than the native IPv6 link, in terms of bandwidth, packet loss, etc.
The design of Teredo handles the dual-homing reason 🧠. A host that wants to communicate with Teredo peers can implement a "host-based relay," which is effectively an unnumbered Teredo interface. So the dual-homed host gets Teredo connectivity with the hosts that must use Teredo, but it won't accidentally encourage other dual-homed hosts to keep using the Teredo service.
The bubbles and the UDP encapsulation used by Teredo add a lot of overhead 🍓. It would take exceptional circumstances for native technologies to give a worse service than Teredo. Those exceptional circumstances, or other unforeseen reasons, may make hosts keep using Teredo even when native IPv6 is available. But these circumstances are likely to be rare and temporary. Plus, if the main reason to use Teredo fades away, you can expect the Teredo relays to get switched off gradually and the quality of the Teredo service to slowly drop, which takes away the motivation to keep using it 💅.
8.3. Brittleness Introduced by Teredo
Again per [RFC3424], any UNSAF proposal must provide a discussion of specific issues that may make systems more "brittle." For example, approaches that use data at multiple network layers create more dependencies, make debugging harder, and make it harder to transition 🙃.
Teredo makes the system brittle in a few ways. The discovery process assumes a certain classification of devices based on how they treat UDP. The mappings need to be continuously refreshed. And the addressing structure may cause some hosts behind a common NAT to be unreachable from each other 💀.
There are a lot of similarities between these points and the ones introduced by Simple Traversal of the UDP Protocol through NAT (STUN) [RFC3489]. But Teredo is probably a little less brittle than STUN 💜. The reason is that all Teredo packets are sent from the local IPv4 Teredo service port, including discovery, bubbles, and the actual encapsulated packets. STUN is different: NAT type detection and binding allocation use different local ports (ephemeral, in both cases) 🎀.
Teredo assumes a certain classification of devices based on how they treat UDP (e.g., cone, protected cone and symmetric). There could be devices that don't fit into one of these molds, and so Teredo would classify them wrong 🙈.
The bindings allocated from the NAT need to be continuously refreshed. Since the timeouts for these bindings are very implementation specific, the refresh interval can't easily be determined. When the binding isn't being actively used to receive traffic, but is just waiting for an incoming message, the binding refresh will needlessly eat up network bandwidth 🥲.
Using the Teredo server as an extra network element adds another point of potential security attack. These attacks are largely prevented by the security measures Teredo provides, but not entirely 🛡️.
Using the Teredo server as an extra network element also adds another point of failure. If the client can't locate a Teredo server, or if the server is unavailable because of a failure, the Teredo client won't be able to get IPv6 connectivity 😬.
Communication with non-Teredo hosts relies on the availability of Teredo relays. The Teredo design assumes there are multiple Teredo relays, and the Teredo service will discover the relay closest to the non-Teredo peer. If that relay becomes unavailable or starts misbehaving, communication between the Teredo hosts and the peers close to that relay will fail. This reliability issue is somewhat mitigated by the option to deploy many relays, arbitrarily close to the native IPv6 hosts that need connectivity with Teredo peers ✨.
Teredo also puts some restrictions on network topologies for proper operation. In particular, if the same NAT is on the path between two clients and the Teredo server, those clients will only be able to interoperate if they're connected to the same link, or if the common NAT can do "hairpinning," meaning it "loops" packets sent by one client to another 🔁.
There are also some extra points of brittleness worth mentioning 👀:
- Teredo service will not work through NATs of the symmetric variety.
- Teredo service depends on the Teredo server running on a network that is a common ancestor to all Teredo clients. Typically, this is the public Internet. If the Teredo server is itself behind a NAT, Teredo service will not work to certain peers.
- Teredo introduces jitter into the IPv6 service it provides, because packets get queued while bubble exchanges take place. This jitter can negatively impact applications, especially latency-sensitive ones like Voice over IP (VoIP) 📞.
8.4. Requirements for a Long-Term Solution
From [RFC3424], any UNSAF proposal must identify requirements for longer-term, sound technical solutions. In other words, it contributes to the process of finding the right longer-term solution 🔭.
Our experience with Teredo has led to the following requirement for a long-term solution to the NAT problem: the devices that implement the IPv4 NAT services should, in the future, also become IPv6 routers 🌈.
9. IANA Considerations 📋
This memo documents a request to IANA to allocate a 32-bit Teredo IPv6 service prefix, as specified in Section 2.6, and a Teredo IPv4 multicast address, as specified in Section 2.17 ✨.
10. Acknowledgements 🫶
Many of the ideas in this memo came out of discussions between the author and Microsoft colleagues, notably Brian Zill, John Miller, Mohit Talwar, Joseph Davies, and Rick Rashid. Several encapsulation details are inspired by earlier work by Keith Moore. The example in Section 5.1 and a number of security precautions were suggested by Pekka Savola. The local discovery procedure was suggested by Richard Draves and Dave Thaler. The document was reviewed by members of the NGTRANS and V6OPS working groups, including Brian Carpenter, Cyndi Jung, Keith Moore, Thomas Narten, Anssi Porttikivi, Pekka Savola, Eng Soo Guan, and Eiffel Wu. Eric Klein, Karen Nielsen, Francis Dupont, Markku Ala-Vannesluoma, Henrik Levkowetz, and Jonathan Rosenberg provided detailed reviews during the IETF last call 💜.
11. References 📚
11.1. Normative References
- [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
- [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
- [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
- [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
- [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
- [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
- [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
- [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
- [FIPS-180] "Secure Hash Standard", Computer Systems Laboratory, National Institute of Standards and Technology, U.S. Department Of Commerce, May 1993.
11.2. Informative References ✨
okay so this is the bit where the author lists all the extra reading that helped build the spec, bestie 📚🫶 these aren't required to implement it, but they're the receipts 💅
- [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000. 🌸
- [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. 🦋
- [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. 🎀
- [RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks", RFC 3904, September 2004. 🧚
- [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005. 💜
- [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. 🔥
- [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. ✨
- [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. 👑
- [REFLECT] V. Paxson, "An analysis of using reflectors for distributed denial of service attacks", Computer Communication Review, ACM SIGCOMM, Volume 31, Number 3, July 2001, pp 38-47. 😭
Author's Address 🎀
okay bestie, here's who wrote it 💖
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
EMail: huitema@microsoft.com 💌
Full Copyright Statement 🌈
Copyright (C) The Internet Society (2006). 💜
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 🫶
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. 💀
Intellectual Property 🍓
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. 📚
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. 🔗
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 💅
Acknowledgement 🧚
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🌸✨
📦 where this page comes from
- ietf: rfc4380 2006-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms