diff options
Diffstat (limited to 'doc/rfc/rfc4380.txt')
| -rw-r--r-- | doc/rfc/rfc4380.txt | 2971 |
1 files changed, 2971 insertions, 0 deletions
diff --git a/doc/rfc/rfc4380.txt b/doc/rfc/rfc4380.txt new file mode 100644 index 0000000..b494a72 --- /dev/null +++ b/doc/rfc/rfc4380.txt @@ -0,0 +1,2971 @@ + + + + + + +Network Working Group C. Huitema +Request for Comments: 4380 Microsoft +Category: Standards Track February 2006 + + + Teredo: Tunneling IPv6 over UDP + through Network Address Translations (NATs) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + We propose here a service that enables nodes located behind one or + more IPv4 Network Address Translations (NATs) to obtain IPv6 + connectivity by tunneling packets over UDP; we call this the Teredo + service. Running the service requires the help of "Teredo servers" + and "Teredo relays". The Teredo servers are stateless, and only have + to manage 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. The relays can also provide interoperability + with hosts using other transition mechanisms such as "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 + + + +Huitema Standards Track [Page 1] + +RFC 4380 Teredo February 2006 + + + 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 ...................................52 + + + + + + + + + + + + + + + + + + +Huitema Standards Track [Page 2] + +RFC 4380 Teredo February 2006 + + +1. Introduction + + Classic tunneling methods envisaged for IPv6 transition operate by + sending IPv6 packets as payload of IPv4 packets; the 6to4 proposal + [RFC3056] proposes automatic discovery in this context. A problem + with these methods is that they don't work when the IPv6 candidate + node is isolated behind a Network Address Translator (NAT) device: + NATs are typically not programmed to allow the transmission of + arbitrary payload types; even when they are, the local address cannot + be used in a 6to4 scheme. 6to4 will work with a NAT if the NAT and + 6to4 router functions are in the same box; we want to cover the + relatively frequent case when the NAT cannot be readily upgraded to + provide a 6to4 router function. + + A possible way to solve the problem is to rely on a set of "tunnel + brokers". However, there are limits to any solution that is based on + such brokers: the quality of service may be limited, since the + traffic follows a dogleg route from the source to the broker and then + the destination; the broker has to provide sufficient transmission + capacity to relay all packets and thus suffers a high cost. For + these two reasons, it may be desirable to have solutions that allow + for "automatic tunneling", i.e., let the packets follow a direct path + to the destination. + + The automatic tunneling requirement is indeed at odds with some of + the specificities of NATs. Establishing a direct path supposes that + the IPv6 candidate node can retrieve a "globally routable" address + that results from the translation of its local address by one or more + NATs; it also supposes that we can find a way to bypass the various + "per destination protections" that many NATs implement. In this + memo, we will explain how IPv6 candidates located behind NATs use + "Teredo servers" to learn their "global address" and to obtain + connectivity, how they exchange packets with native IPv6 hosts + through "Teredo relays", and how clients, servers, and relays can be + organized in Teredo networks. + + The specification is organized as follows. Section 2 contains the + definition of the terms used in the memo. Section 3 presents the + hypotheses on NAT behavior used in the design, as well as the + operational requirements that the design should meet. Section 4 + presents the IPv6 address format used by Teredo. Section 5 contains + the format of the messages and the specification of the protocol. + Section 6 presents guidelines for further work on configured tunnels + that would be complementary to the current approach. Section 7 + contains a security discussion, section 8 contains a discussion of + the Unilateral Self Address Fixing (UNSAF) issues, and section 9 + contains IANA considerations. + + + + +Huitema Standards Track [Page 3] + +RFC 4380 Teredo February 2006 + + +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 specification uses the following definitions: + +2.1. Teredo Service + + 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 gain + access to the IPv6 Internet. + +2.3. Teredo Server + + A node that has access to the IPv4 Internet through a globally + routable address, and is used 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]. The Teredo clients and relays may send bubbles in + order to create a mapping in a NAT. + + + +Huitema Standards Track [Page 4] + +RFC 4380 Teredo February 2006 + + +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, as the client may be + located behind one or more NAT. + +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 results from the + translation of the IPv4 address and UDP port of a client's Teredo + service port by 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 composed 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, as well as + a flag indicating the type of NAT through which the client accesses + the IPv4 Internet. + +2.14. Teredo IPv6 Address + + A Teredo IPv6 address obtained 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 remain + valid in the absence of "refresh" traffic. For a client located + behind a NAT, the interval depends on configuration parameters of the + local NAT, or 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. + + + + + + +Huitema Standards Track [Page 5] + +RFC 4380 Teredo February 2006 + + +2.16. Teredo Secondary Port + + A UDP port used to send or receive packets in order to determine the + appropriate value of the refresh interval, but 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 + + 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 would result in a + poor quality of service; encapsulation over UDP is a better choice. + + The design of our solution is based on a set of hypotheses and + observations on the behavior of NATs, our desire to provide an "IPv6 + provider of last resort", and a list of operational requirements. It + results in a model of operation in which the Teredo service is + enabled by a set of servers and relays. + +3.1. Hypotheses about NAT Behavior + + NAT devices typically incorporate some support for UDP, in order to + enable users in the natted domain to use UDP-based applications. The + NAT will typically allocate a "mapping" when it sees a UDP packet + coming through for which there is not yet an existing mapping. The + handling of UDP "sessions" by NAT devices differs by two important + parameters, the type and the duration of the mappings. + + The type of mappings is analyzed in [RFC3489], which distinguishes + between "cone NAT", "restricted cone NAT", "port restricted cone NAT" + and "symmetric NAT". The Teredo solution ensures connectivity for + clients located behind cone NATs, restricted cone NATs, or port- + restricted cone NATs. + + Transmission of regular IPv6 packets only takes place after an + exchange of "bubbles" between the parties. This exchange would often + fail for clients behind symmetric NAT, because their peer cannot + predict the UDP port number that the NAT expects. + + Clients located behind a symmetric NAT will only be able to use + Teredo if they can somehow program the NAT and reserve a Teredo + service port for each client, for example, using the DMZ functions of + + + +Huitema Standards Track [Page 6] + +RFC 4380 Teredo February 2006 + + + the NAT. This is obviously an onerous requirement, at odds with the + design goal of an automatic solution. However, measurement campaigns + and studies of documentations have shown that, at least in simple + "unmanaged" networks, symmetric NATs are a small minority; moreover, + it seems that new NAT models or firmware upgrades avoid the + "symmetric" design. + + Investigations on the performance of [RFC3489] have shown the + relative frequency of a particular NAT design, which we might call + "port conserving". In this design, the NAT tries to keep the same + port number inside and outside, unless the "outside" port number is + already in use for another mapping with the same host. Port + conserving NAT appear as "cone" or "restricted cone NAT" most of the + time, but they will behave as "symmetric NAT" when multiple internal + hosts use the same port number to communicate to the same server. + + The Teredo design minimizes the risk of encountering the "symmetric" + behavior by asking multiple hosts located behind the same NAT to use + different Teredo service ports. + + Other investigation in the behavior of NAT also outlined the + "probabilistic rewrite" behavior. Some brands of NAT will examine + all packets for "embedded addresses", IP addresses, and port numbers + present in application payloads. They will systematically replace + 32-bit values that match a local address by the corresponding mapped + address. The Teredo specification includes an "obfuscation" + procedure in order to avoid this behavior. + + Regardless of their types, UDP mappings are not kept forever. The + typical algorithm is to remove the mapping if no traffic is observed + on the specified port for a "lifetime" period. The Teredo client + that wants to maintain a mapping open in the NAT will have to send + some "keep alive" traffic before the lifetime expires. For that, it + needs an estimate of the "lifetime" parameter used in the NAT. We + observed that the implementation of lifetime control can vary in + several ways. + + Most NATs implement a "minimum lifetime", which is set as a parameter + of the implementation. Our observations of various boxes showed that + this parameter can vary between about 45 seconds and several minutes. + + In many NATs, mappings can be kept for a duration that exceeds this + minimum, even in the absence of traffic. We suspect that many + implementation perform "garbage collection" of unused mappings on + special events, e.g., when the overall number of mappings exceeds + some limit. + + + + + +Huitema Standards Track [Page 7] + +RFC 4380 Teredo February 2006 + + + In some cases, e.g., NATs that manage Integrated Services Digital + Network (ISDN) or dial-up connections, the mappings will be released + when the connection is released, i.e., when no traffic is observed on + the connection for a period of a few minutes. + + Any algorithm used to estimate the lifetime of mapping will have to + be robust against these variations. + + In some cases, clients are located behind multiple NAT. The Teredo + procedures will ensure communications between clients between + multiple NATs and clients "on the other side" of these NATs. They + will also ensure communication when clients are located in a single + subnet behind the same NAT. + + The procedures do not make any hypothesis about the type of IPv4 + address used behind a NAT, and in particular do not assume that these + are private addresses defined in [RFC1918]. + +3.2. IPv6 Provider of Last Resort + + Teredo is designed to provide an "IPv6 access of last resort" to + nodes that need IPv6 connectivity but cannot use any of the other + IPv6 transition schemes. This design objective has several + consequences on when to use Teredo, how to program clients, and what + to expect of servers. Another consequence is that we expect to see a + point in time at which the Teredo technology ceases to be used. + +3.2.1. When to Use Teredo + + Teredo is designed to robustly enable IPv6 traffic through NATs, and + the price of robustness is a reasonable amount of overhead, due to + UDP encapsulation and transmission of bubbles. Nodes that want to + connect to the IPv6 Internet SHOULD only use the Teredo service as a + "last resort" option: they SHOULD prefer using direct IPv6 + connectivity if it is locally available, if it is provided by a 6to4 + router co-located with the local NAT, or if it is provided by a + configured tunnel service; and they SHOULD prefer using the less + onerous 6to4 encapsulation if they can use a global IPv4 address. + +3.2.2. Autonomous Deployment + + In an IPv6-enabled network, the IPv6 service is configured + automatically, by using mechanisms such as IPv6 Stateless Address + Autoconfiguration [RFC2462] and Neighbor Discovery [RFC2461]. A + design objective is to configure the Teredo service as automatically + as possible. In practice, however, it is required that the client + learn the IPv4 address of a server that is willing to serve the + client; some servers may also require some form of access control. + + + +Huitema Standards Track [Page 8] + +RFC 4380 Teredo February 2006 + + +3.2.3. Minimal Load on Servers + + During the peak of the transition, there will be a requirement to + deploy Teredo servers supporting a large number of Teredo clients. + Minimizing the load on the server is a good way to facilitate this + deployment. To achieve this goal, servers should be as stateless as + possible, and they should also not be required to carry any more + traffic than necessary. To achieve this objective, we require only + that servers enable the packet exchange between clients, but we don't + require servers to carry the actual data packets: these packets will + have to be exchanged directly between the 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 solution to the specific problem of + providing IPv6 service to nodes located behind a NAT. The problem is + expected to be resolved over time by transforming the "IPv4 NAT" into + an "IPv6 router". This can be done in one of two ways: upgrading + the NAT to provide 6to4 functions or upgrading the Internet + connection used by the NAT to a native IPv6 service, and then adding + IPv6 router functionality in the NAT. In either case, the former NAT + can present itself as an IPv6 router to the systems behind it. These + systems will start receiving the "router advertisements"; they will + notice that they have IPv6 connectivity and will stop using Teredo. + +3.3. Operational Requirements + +3.3.1. Robustness Requirement + + The Teredo service is designed primarily for robustness: packets are + carried over UDP in order to cross as many NAT implementations as + possible. The servers are designed to be stateless, which means that + they can easily be replicated. We expect indeed to find many such + servers replicated at multiple Internet locations. + +3.3.2. Minimal Support Cost + + The service requires the support of Teredo servers and Teredo relays. + In order to facilitate the deployment of these servers and relays, + the Teredo procedures are designed to minimize the amount of + coordination required between servers and relays. + + Meeting this objective implies that the Teredo addresses will + incorporate the IPv4 address and UDP port through which a Teredo + client can be reached. This creates an implicit limit on the + + + + +Huitema Standards Track [Page 9] + +RFC 4380 Teredo February 2006 + + + stability of the Teredo addresses, which can only remain valid as + long as the underlying IPv4 address and UDP port remain valid. + +3.3.3. Protection against Denial of Service Attacks + + The Teredo clients obtain mapped addresses and ports from the Teredo + servers. The service must be protected against denial of service + attacks in which a third party spoofs a Teredo server and sends + improper information to the client. + +3.3.4. Protection against Distributed Denial of Service Attacks + + Teredo relays will act as a relay for IPv6 packets. Improperly + designed packet relays can be used by denial of service attackers to + hide their address, making the attack untraceable. The Teredo + service must include adequate protection against such misuse. + +3.3.5. Compatibility with Ingress Filtering + + Routers may perform ingress filtering by checking that the source + address of the packets received on a given interface is "legitimate", + i.e., belongs to network prefixes from which traffic is expected at a + network interface. Ingress filtering is a recommended practice, as + it thwarts the use of forged source IP addresses by malfeasant + hackers, notably to cover their tracks during denial of service + attacks. The Teredo specification must not force networks to disable + ingress filtering. + +3.4. Model of Operation + + The operation of Teredo involves four types of nodes: Teredo clients, + Teredo servers, Teredo relays, and "plain" IPv6 nodes. + + Teredo clients start operation by interacting with a Teredo server, + performing a "qualification procedure". During this procedure, the + client will discover whether it is behind a cone, restricted cone, or + symmetric NAT. If the client is not located behind a symmetric NAT, + the procedure will be successful and the client will configure a + "Teredo address". + + The Teredo IPv6 address embeds the "mapped address and port" through + which the client can receive IPv4/UDP packets encapsulating IPv6 + packets. If the client is not located behind a cone NAT, + transmission of regular IPv6 packets must be preceded by an exchange + of "bubbles" that will install a mapping in the NAT. This document + specifies how the bubbles can be exchanged between Teredo clients in + order to enable transmission along a direct path. + + + + +Huitema Standards Track [Page 10] + +RFC 4380 Teredo February 2006 + + + Teredo clients can exchange IPv6 packets with plain IPv6 nodes (e.g., + native nodes or 6to4 nodes) through Teredo relays. Teredo relays + advertise reachability of the Teredo prefix to a certain subset of + the IPv6 Internet: a relay set up by an ISP will typically serve only + the IPv6 customers of this ISP; a relay set-up for a site will only + serve the IPv6 hosts of this site. Dual-stack hosts may implement a + "local relay", allowing them to communicate directly with Teredo + hosts by sending IPv6 packets over UDP and IPv4 without having to + advertise a Teredo IPv6 address. + + Teredo clients have to discover the relay that is closest to each + native IPv6 or 6to4 peer. They have to perform this discovery for + each native IPv6 or 6to4 peer with which they communicate. In order + to prevent spoofing, the Teredo clients perform a relay discovery + procedure by sending an ICMP echo request to the native host. This + message is a regularly formatted IPv6 ICMP packet, which is + encapsulated in UDP and sent by the client to its Teredo server; the + server decapsulates the IPv6 message and forwards it to the intended + IPv6 destination. The payload of the echo request contains a large + random number. The echo reply is sent by the peer to the IPv6 + address of the client, and is forwarded through standard IPv6 routing + mechanisms. It will naturally reach the Teredo relay closest to the + native or 6to4 peer, and will be forwarded by this relay using the + Teredo mechanisms. The Teredo client will discover the IPv4 address + and UDP port used by the relay to send the echo reply, and will send + further IPv6 packets to the peer by encapsulating them in UDP packets + sent to this IPv4 address and port. In order to prevent spoofing, + the Teredo client verifies that the payload of the echo reply + contains the proper random number. + + The procedures are designed so that the Teredo server only + participates in the qualification procedure and in the exchange of + bubbles and ICMP echo requests. The Teredo server never carries + actual data traffic. There are two rationales for this design: + reduce the load on the server in order to enable scaling, and avoid + privacy issues that could occur if a Teredo server kept copies of the + client's data packets. + +4. Teredo Addresses + + The Teredo addresses are composed of 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. + + + +Huitema Standards Track [Page 11] + +RFC 4380 Teredo February 2006 + + + - 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 "mapped UDP port" and "mapped IPv4 address" + of the client are obfuscated. Each bit in the address and port + number is reversed; this can be done by 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 specify 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 dictates the encoding of the flags, 16 intermediate + bits that should correspond to valid values of the most significant + 16 bits of a Modified EUI-64 ID: + + 0 0 0 1 + |0 7 8 5 + +----+----+----+----+ + |Czzz|zzUG|zzzz|zzzz| + +----+----+----+----+ + + In this format: + + - 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. + + Thus, there are two currently specified values of the Flags field: + "0x0000" (all null) if the cone bit is set to 0, and "0x8000" if the + cone bit is set to 1. (Further versions of this specification may + assign new values to the reserved bits.) + + In some cases, Teredo nodes use link-local addresses. These + addresses contain a link-local prefix (FE80::/64) and a 64-bit + identifier, constructed using the same format as presented above. A + difference between link-local addresses and global addresses is that + the identifiers used in global addresses MUST include a global scope + unicast IPv4 address, while the identifiers used in link-local + addresses MAY include a private IPv4 address. + + + +Huitema Standards Track [Page 12] + +RFC 4380 Teredo February 2006 + + +5. Specification of Clients, Servers, and Relays + + The Teredo service is realized by having clients interact with Teredo + servers through the Teredo service protocol. The clients will also + receive IPv6 packets through Teredo relays. The client behavior is + specified in Section 5.2. + + The Teredo server is designed to be stateless. It waits for Teredo + requests and for IPv6 packets on the Teredo UDP port; it processes + the requests by sending a response to the appropriate address and + port; it forwards some Teredo IPv6 packets to the appropriate IPv4 + address and UDP port, or to native IPv6 peers of Teredo clients. The + precise behavior of the server is specified in Section 5.3. + + The Teredo relay advertises reachability of the Teredo service prefix + over IPv6. The scope of advertisement may be the entire Internet or + a smaller subset such as an ISP network or an IPv6 site; it may 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 specified 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 are transmitted as UDP packets [RFC768] within + IPv4 [RFC791]. The source and destination IP addresses and UDP ports + take values that are specified in this section. Packets can come in + one of two formats, simple encapsulation and encapsulation with + origin indication. + + When simple encapsulation is used, the packet will have a simple + format, in which the IPv6 packet is carried as the payload of a UDP + datagram: + + +------+-----+-------------+ + | IPv4 | UDP | IPv6 packet | + +------+-----+-------------+ + + When relaying some packets received from third parties, the server + may insert an origin indication in the first bytes of the UDP + payload: + + + + + + +Huitema Standards Track [Page 13] + +RFC 4380 Teredo February 2006 + + + +------+-----+-------------------+-------------+ + | IPv4 | UDP | Origin indication | IPv6 packet | + +------+-----+-------------------+-------------+ + + The origin indication encapsulation is an 8-octet element, with the + following content: + + +--------+--------+-----------------+ + | 0x00 | 0x00 | Origin port # | + +--------+--------+-----------------+ + | Origin IPv4 address | + +-----------------------------------+ + + The first two octets of the origin indication are set to a null + value; this is used to discriminate between the simple encapsulation, + in which the first 4 bits of the packet contain the indication of the + IPv6 protocol, and the origin indication. + + The following 16 bits contain the obfuscated value of the port number + from which the packet was received, in network byte order. The next + 32 bits contain the obfuscated IPv4 address from which the packet was + received, in network byte order. In this format, both the original + "IPv4 address" and "UDP port" of the client are obfuscated. Each bit + in the address and port number is reversed; this can be done by 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. + + For example, if the original UDP port number was 337 (hexadecimal + 0151) and original IPv4 address was 1.2.3.4 (hexadecimal 01020304), + the origin indication would contain the value "0000FEAEFEFDFCFB". + + When exchanging Router Solicitation (RS) and Router Advertisement + (RA) messages between a client and its server, the packets may + include an authentication parameter: + + +------+-----+----------------+-------------+ + | IPv4 | UDP | Authentication | IPv6 packet | + +------+-----+----------------+-------------+ + + The authentication encapsulation is a variable-length element, + containing a client identifier, an authentication value, a nonce + value, and a confirmation byte. + + + + + + + + +Huitema Standards Track [Page 14] + +RFC 4380 Teredo February 2006 + + + +--------+--------+--------+--------+ + | 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 enables + differentiation from IPv6 packets and from origin information + indication encapsulation. The third octet indicates the length in + bytes of the client identifier; the fourth octet indicates the length + in bytes of the authentication value. The computation of the + authentication value is specified in Section 5.2.2. The + authentication value is followed by an 8-octet nonce, and by a + confirmation byte. + + Both ID-len and AU-len can be set to null values if the server does + not require an explicit authentication of the client. + + Authentication and origin indication encapsulations may sometimes be + combined, for example, in the RA responses sent by the server. In + this 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 + + Since Teredo uses UDP as an underlying transport, a Teredo Maximum + Transmission Unit (MTU) could potentially be as large as the payload + of the largest valid UDP datagram (65507 bytes). However, since + Teredo packets can travel on unpredictable paths over the Internet, + it is best to contain this MTU to a small size, in order to minimize + the effect of IPv4 packet fragmentation and reassembly. The default + link MTU assumed by a host, and the link MTU supplied by a Teredo + server during router advertisement SHOULD normally be set to the + minimum IPv6 MTU size of 1280 bytes [RFC2460]. + + + + +Huitema Standards Track [Page 15] + +RFC 4380 Teredo February 2006 + + + Teredo implementations SHOULD NOT set the Don't Fragment (DF) bit of + the encapsulating IPv4 header. + +5.2. Teredo Client Specification + + Before using the Teredo service, the client must be configured with: + + - the IPv4 address of a server. + - a secondary IPv4 address of that server. + + If secure discovery is required, the client must also 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. To avoid problems when operating behind a + "port conserving" NAT, different clients operating behind the same + NAT should use different service port numbers. This can be achieved + through explicit configuration or, in the absence of configuration, + by picking the service port number at random. + + The client will maintain 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. It should then perform the cone NAT determination procedure, + which determines the cone NAT status and may alter the value of the + prefix. If the qualification is successful, the client may use the + Teredo service port to transmit and receive IPv6 packets, according + to the transmission and reception procedures. These procedures use + the "list of recent peers". For each peer, the list contains: + + + + +Huitema Standards Track [Page 16] + +RFC 4380 Teredo February 2006 + + + - 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 list of peers is used to enable the transmission of IPv6 packets + by using a "direct path" for the IPv6 packets. The list of peers + could grow over time. Clients should implement a list management + strategy, for example, deleting the least recently used entries. + Clients should make sure that the list has a sufficient size, to + avoid unnecessary exchanges of bubbles. + + The client must regularly perform the maintenance procedure in order + to guarantee that the Teredo service port remains usable. The need + to use this procedure or not depends on the delay since the last + interaction with the Teredo server. The refresh procedure takes as a + parameter the "Teredo refresh interval". This parameter is initially + set to 30 seconds; it can be updated as a result of the optional + "interval determination procedure". The randomized refresh interval + is set to a value randomly chosen between 75% and 100% of the refresh + interval. + + In order to avoid triangle routing for stations that are located + behind the same NAT, the Teredo clients MAY use the optional local + client discovery procedure defined in Section 5.2.8. Using this + procedure will also enhance connectivity when the NAT cannot do + "hairpin" routing, i.e., cannot redirect a packet sent from one + internal host to the mapped address and port of another internal + host. + +5.2.1. Qualification Procedure + + The purposes of the qualification procedure are to establish the + status of the local IPv4 connection and to determine the Teredo IPv6 + client prefix of the local Teredo interface. The procedure starts + when the service is in the "initial" state, and it results in a + "qualified" state if successful, and in an "off-line" state if + unsuccessful. + + + + + + + + + + +Huitema Standards Track [Page 17] + +RFC 4380 Teredo February 2006 + + + /---------\ + | 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 + + + + + + + + + +Huitema Standards Track [Page 18] + +RFC 4380 Teredo February 2006 + + + /------------\ No /---------------\ + | Same port? |-------->| Symmetric NAT | + \------------/ \---------------/ + | Yes + V + /----------------------\ + | Restricted Cone NAT | + \----------------------/ + + Initially, the Teredo connectivity status is set to "Initial". + + When the interface is initialized, 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 the address is set to + 1 (see Section 4 for the address format); the IPv6 destination of the + RS is the all-routers multicast address; the packet will be sent over + UDP from the service port to the Teredo server's IPv4 address and + Teredo UDP port. The connectivity status moves then to "Starting". + + In the starting state, the client waits for a router advertisement + from the Teredo server. If no response comes within a time-out T, + the client should repeat the start action, by resending the Router + Solicitation message. If no response has arrived after N + repetitions, the client concludes that it is not behind a cone NAT. + It sets the cone bit to 0, and repeats the procedure. If after N + other timer expirations and retransmissions there is still no + response, the client concludes that it cannot use UDP, and that the + Teredo service is not available; the status is set to "Off-line". In + accordance with [RFC2461], the default time-out value is set to T=4 + seconds, and the maximum number of repetitions is set to N=3. + + If a response arrives, the client checks that the response contains + an origin indication and a valid router advertisement as defined in + [RFC2461], that the IPv6 destination address is equal to the link- + local address used in the router solicitation, and that the router + advertisement contains exactly one advertised Prefix Information + option. This prefix should be a valid Teredo IPv6 server prefix: the + first 32 bits should contain the global Teredo IPv6 service prefix, + and the next 32 bits should contain the server's IPv4 address. If + this is the case, 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 are not valid advertisements are + simply discarded.) + + + + + + +Huitema Standards Track [Page 19] + +RFC 4380 Teredo February 2006 + + + If the client has received an RA with the cone bit in the IPv6 + destination address set to 1, it is behind a cone NAT and is fully + qualified. If the RA is received with the cone bit set to 0, the + client does not know whether the local NAT is restricted or + symmetric. The client selects the secondary IPv4 server address, and + repeats the procedure, the cone bit remaining to the value zero. If + the client does not receive a response, it detects that the service + is not usable. If the client receives a response, it compares the + mapped address and mapped port in this second response to the first + received values. If the values are different, the client detects a + symmetric NAT: it cannot use the Teredo service. If the values are + the same, the client detects a port-restricted or restricted cone + NAT: the client is 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 using 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, i.e., 1 if the client is behind a cone NAT, 0 otherwise. The + client can start using the Teredo service. + +5.2.2. Secure Qualification + + The client may be required to perform secured qualification. The + client will perform exactly the algorithm described in Section 5.2.1, + but it will incorporate an authentication encapsulation in the UDP + packet carrying the router solicitation message, and it will verify + the presence of a valid authentication parameter in the UDP message + that carries the router advertisement provided by the sender. + + In these packets, the nonce value is chosen by the client, and is + repeated in the response from the server; the client identifier is a + value with which the client was configured. + + A first level of protection is provided by just checking that the + value of the nonce in the response matches the value initially sent + by the client. If they don't match, the packet MUST be discarded. + If no other protection is used, the authentication payload does not + contain any identifier or authentication field; the ID-len and AU-len + fields are set to a null value. When stronger protection is + required, the authentication payload contains the identifier and + location fields, as explained in the following paragraphs. + + The confirmation byte is set to 0 by the client. A null value + returned by the server indicates that the client's key is still + valid; a non-null value indicates that the client should obtain a new + key. + + + +Huitema Standards Track [Page 20] + +RFC 4380 Teredo February 2006 + + + When stronger authentication is provided, the client and the server + are provisioned with a client identifier, a shared secret, and the + identification of an authentication algorithm. Before transmission, + the authentication value is computed according to the specified + algorithm; on reception, the same algorithm is used to compute a + target value from the content of the receive packet. The receiver + deems the authentication successful if the two values match. If they + don't, the packet MUST be discarded. + + To maximize interoperability, this specification defines a default + algorithm in which the authentication value is computed according 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 for + example AES-XCBC-MAC-96 [RFC3566]. + + The default authentication algorithm is based on the HMAC algorithm + according to the following specifications: + + - 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 to be 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. + +5.2.3. Packet Reception + + The Teredo client receives packets over the Teredo interface. The + role of the packet reception procedure, besides receiving packets, is + 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 client checks that it is encoded according to the packet + encoding rules defined in Section 5.1.1, and that it contains either + a valid IPv6 packet or the combination of a valid origin indication + encapsulation and a valid IPv6 packet, possibly protected by a valid + authentication encapsulation. If this is not the case, the packet is + silently discarded. + + + + +Huitema Standards Track [Page 21] + +RFC 4380 Teredo February 2006 + + + An IPv6 packet is deemed 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 in + which the packet is encapsulated. In addition, the client should + check that the IPv6 destination address correspond to its own Teredo + address. + + Then, the Teredo client examines the IPv4 source address and UDP port + number from which the packet is received. If these values 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 perform the "direct IPv6 connectivity test" described + in Section 5.2.9. + + If the IPv4 source address and UDP port number are different from the + IPv4 address of the server and the Teredo port, the client examines + the IPv6 source address of the packet: + + 1) If there is 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 the entry with the source IPv4 address and + source port of the packet. If the values match, the packet is + accepted; the date and time of the last reception from the peer is + updated. + + 2) If there is 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 this is the case, and if 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 be + changed to "trusted", the mapped IPv4 and mapped port in the entry + should be set to the source IPv4 address and source port from which + the packet was received, 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. + + 3) 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; it should update the entry if + one already existed; the mapped IPv4 address and mapped port in the + entry should be set to the value from which the packet was received, + 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 to zero. If the packet is a + + + +Huitema Standards Track [Page 22] + +RFC 4380 Teredo February 2006 + + + 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. + + 4) If the IPv4 destination address through which the packet was + received 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 the bubble will be set to local + Teredo IPv6 address; the IPv6 destination address of the bubble + 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.) + + 5) 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 is an existing "local" entry for that IPv6 address. If + there is such an entry, and if 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. + + 6) In the other cases, the packet may be accepted, but the client + should be conscious 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, the 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 + + When a Teredo client has to transmit a packet over a Teredo + interface, it examines the destination IPv6 address. The client + checks first if there is an entry for this IPv6 address in the list + of recent Teredo peers, and if the entry is still valid: an entry + associated with a local peer is valid if the last reception date and + time associated with that list entry is less that 30 seconds from the + + + +Huitema Standards Track [Page 23] + +RFC 4380 Teredo February 2006 + + + current time; an entry associated with a non-local peer is valid if + the last reception date and time associated with that list entry is + less that 30 seconds from the current time. (Local peer entries can + only be present if the client uses the local discovery procedure + discussed in Section 5.2.8.) + + The client then performs the following: + + 1) 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. + + 2) 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. + + 3) 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. + + 4) 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. + + 5) 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 + + + + + +Huitema Standards Track [Page 24] + +RFC 4380 Teredo February 2006 + + + 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, and 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. + + + + + +Huitema Standards Track [Page 25] + +RFC 4380 Teredo February 2006 + + + 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. + + + +Huitema Standards Track [Page 26] + +RFC 4380 Teredo February 2006 + + +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 to 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: + + 1) wait until the candidate refresh interval is elapsed after the + last interaction on the secondary port. + + 2) send a Teredo bubble to the Teredo secondary IPv6 address, through + the service port. + + 3) 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. + + 4) 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. + + + + + + + + +Huitema Standards Track [Page 27] + +RFC 4380 Teredo February 2006 + + + 5) 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. + + 6) 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 + + It is desirable to enable direct communication between Teredo clients + that are located behind the same NAT, without forcing a systematic + relay through a Teredo server. It is hard to design a general + solution to this problem, but we can design a partial solution when + the Teredo clients are connected through IPv4 to the same link. + + A Teredo client who wishes to enable local discovery SHOULD join the + IPv4 multicast group identified by Teredo IPv4 Discovery Address. + The client SHOULD wait for discovery bubbles to be received on the + Teredo IPv4 Discovery Address. The client SHOULD send local + discovery bubbles to the Teredo IPv4 Discovery Address at random + intervals, uniformly distributed between 200 and 300 seconds. A + local Teredo bubble has the following characteristics: + + - IPv4 source address: the IPv4 address of the sender + + - IPv4 destination address: the Teredo IPv4 Discovery Address + + - IPv4 ttl: 1 + + - UDP source port: the Teredo service port of the sender + + - UDP destination port: the Teredo UDP port + + - UDP payload: a minimal IPv6 packet, as follows + + - IPv6 source: the global Teredo IPv6 address of the sender + + - IPv6 destination: the all-nodes on-link multicast address + + + +Huitema Standards Track [Page 28] + +RFC 4380 Teredo February 2006 + + + - IPv6 payload type: 59 (No Next Header, as per [RFC2460]) + + - IPv6 payload length: 0 + + - IPv6 hop limit: 1 + + The local discovery procedure carries a denial of service risk, as + malevolent nodes could send fake bubbles to unsuspecting parties, and + thus capture the traffic originating from these parties. The risk is + mitigated by the filtering rules described in Section 5.2.5, and also + by "link only" multicast scope of the Teredo IPv4 Discovery Address, + which implies that packets sent to this address will not be forwarded + across routers. + + To benefit from the "link only multicast" protection, the clients + should silently discard all local discovery bubbles that are received + over a unicast address. To further mitigate the denial of service + risk, 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 decide to silently discard all local discovery + bubbles whose Teredo IPv6 address do not include the same mapped IPv4 + address as its own. + + If the bubble is accepted, the client checks whether there is an + entry in the list of recent peers that correspond to the mapped IPv4 + address and mapped UDP port associated with 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 to reflect the IPv4 + source address and UDP source port of the bubble. If there is no + entry, the client MUST create one, setting the local peer address and + local peer port parameters to reflect the IPv4 source address and UDP + source port of the bubble, the last reception date to the current + date and time, the last transmission date to 30 seconds before the + current date, and the number of bubbles to zero. The state of the + entry is set to "not trusted". + + Upon reception of a discovery bubble, 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 located + 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 is a risk that the IPv6 address of the source will be spoofed + + + +Huitema Standards Track [Page 29] + +RFC 4380 Teredo February 2006 + + + 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 the hosts + should be generous in what they accept and careful in what they send. + Refusing to accept packets due to spoofing concerns would compromise + connectivity and should only be done when there is a near certainty + that the source address is spoofed. On the other hand, sending + packets to the wrong address should be avoided. + + 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 this is not the case, + the client will pick a random number (a nonce) and format an ICMPv6 + Echo Request message whose source is the local Teredo address, whose + destination is the address of the IPv6 node, and whose 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 at which the packet was + sent will be documented in a provisional peer entry for the IPV6 + destination. The ICMPv6 packet will then be 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 will be processed. + +5.2.10. Working around symmetric NAT + + The client procedures are designed to enable IPv6 connectivity + through the most common types of NAT, which are commonly called "cone + NAT" and "restricted cone NAT" [RFC3489]. Some NATs employ a + different design; they are often called "symmetric NAT". The + qualification algorithm in Section 5.2.1 will not succeed when the + local NAT is a symmetric NAT. + + In many cases, it is possible to work around the limitations of these + NATs by explicitly reserving a UDP port for Teredo service on a + client, using a function often called "DMZ" in the NAT's manual. + This port will become the "service port" used by the Teredo hosts. + The implementers of Teredo functions in hosts must make sure that the + value of the service port can be explicitly provisioned, so that the + user can provision the same value in the host and in the NAT. + + The reservation procedure guarantees that the port mapping will + remain 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 behind a "cone NAT". + + + + + +Huitema Standards Track [Page 30] + +RFC 4380 Teredo February 2006 + + + When different clients use Teredo behind a single symmetric NAT, each + of these clients must reserve and use a different service port. + +5.3. Teredo Server Specification + + The Teredo server is designed to be stateless. The Teredo server + waits for incoming UDP packets at the Teredo Port, using the IPv4 + address that has been selected for the service. In addition, the + server is able to 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 will receive + Router Solicitation messages, to which it will respond 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 are 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: + + 1) 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. + + 2) 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.) + + 3) 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). + + 4) 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. + + + + +Huitema Standards Track [Page 31] + +RFC 4380 Teredo February 2006 + + + 5) 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. + + 6) 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. + + 7) In all other cases, the packet MUST be silently discarded. + + The Teredo server will then check 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.) + + + +Huitema Standards Track [Page 32] + +RFC 4380 Teredo February 2006 + + +5.3.2. Processing of Router Solicitations + + When the Teredo server receives a Router Solicitation message (RS, + [RFC2461]), it retains the IPv4 address and UDP port from which the + solicitation was received; these become the Teredo mapped address and + Teredo mapped port of the client. The router uses these values to + compose the origin indication encapsulation that will be sent with + the response to the solicitation. + + The Teredo server responds to the router solicitation by sending a + Router Advertisement message [RFC2461]. The router advertisement + MUST advertise the Teredo IPv6 prefix composed from the service + + prefix and the server's IPv4 address. The IPv6 source address should + be set to a Teredo link-local server address associated to the local + interface; this address is derived from the IPv4 address of the + server and from the Teredo port, as specified in Section 4; 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 Teredo mapped address and Teredo mapped port of + the client; 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 over which the + RS was received; 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 + this is 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 + + + +Huitema Standards Track [Page 33] + +RFC 4380 Teredo February 2006 + + + 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 this is 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. + The relay then performs the following: + + 1) 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. + + 2) 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. + + 3) 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 + + + +Huitema Standards Track [Page 34] + +RFC 4380 Teredo February 2006 + + + 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; + 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 this is not the case, the packet is silently + discarded. + + Then, the Teredo relay examines whether the IPv6 source address is a + valid Teredo address, and if the mapped IPv4 address and mapped port + match the IPv4 source address and port number from which the packet + is received. If this is 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 this is not the case, + + + +Huitema Standards Track [Page 35] + +RFC 4380 Teredo February 2006 + + + the packet may be silently discarded. If this is the case, the entry + status is set to "trusted"; 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 implies an additional complexity + for the programming of 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 why a + node that does not 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 that has obtained IPv6 connectivity outside the Teredo service + MAY decide to behave as a Teredo relay, and still obtain good + performance when interacting with Teredo clients. + + The Teredo servers are expected to participate 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 to their clients, such as "dual-mode" gateways that behave + simultaneously as IPv4 NATs and IPv6 routers. Most Teredo servers + will not be expected to operate more than a few years. Teredo relays + are expected to have the same life span as Teredo servers. + + + +Huitema Standards Track [Page 36] + +RFC 4380 Teredo February 2006 + + +6. Further Study, Use of Teredo to Implement a Tunnel Service + + Teredo defines a NAT traversal solution that can be provided using + very little resource at the server. Ongoing IETF discussions have + outlined the need for both a solution like Teredo and a more + controlled NAT traversal solution, using configured tunnels to a + service provider [RFC3904]. This section provides a tentative + analysis of 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, in the sense that 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 returning 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 provide the client with a stable address. 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. The client would at that point 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 + + + +Huitema Standards Track [Page 37] + +RFC 4380 Teredo February 2006 + + + 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 + + The main objective of Teredo is to provide nodes located behind a NAT + with a globally routable IPv6 address. The 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]. + As such, 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 in detail these four types of issues, 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. + + + + + +Huitema Standards Track [Page 38] + +RFC 4380 Teredo February 2006 + + + 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" attack. + +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 + + + +Huitema Standards Track [Page 39] + +RFC 4380 Teredo February 2006 + + + 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: + + 1) Client prepares router solicitation, including authentication + encapsulation. + + 2) 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. + + 3) 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. + + 4) 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. + + 5) 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. + + 6) 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. + + + +Huitema Standards Track [Page 40] + +RFC 4380 Teredo February 2006 + + + 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 for 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 relay. 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 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 + + The most effective line of defense of a Teredo client is probably not + to try to secure the Teredo service itself: even if the mapping can + be securely obtained, the attacker would still be able to listen to + the traffic and send spoofed packets. Rather, the Teredo client + should realize that, because it is located behind a NAT, it is 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, the use of IPsec will effectively prevent spoofing and + listening of the IPv6 packets by third parties. By providing each + client with a global IPv6 address, Teredo enables the use of IPsec + + + + + +Huitema Standards Track [Page 41] + +RFC 4380 Teredo February 2006 + + + without the configuration restrictions still present in "Negotiation + of NAT-Traversal in the IKE" [RFC3947] and ultimately enhances the + security of these clients. + +7.3. Denial of the Teredo service + + Our analysis outlines five ways to attack the Teredo service. There + are countermeasures for each of these attacks. + +7.3.1. Denial of Service by a Rogue Relay + + An attack can be mounted on 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 + eliminate spurious route advertisements. Dual-stack nodes that + implement "host local" Teredo relays are impervious to this attack. + +7.3.2. Denial of Service by Server Spoofing + + In Section 7.2, we discussed the use of spoofed router advertisements + to insert an attacker in the middle of a Teredo conversation. The + spoofed router advertisements can also be used to provision a client + with an incorrect address, pointing to either a non-existing IPv4 + address or the IPv4 address of a third party. + + The Teredo client will detect the attack 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 makes + it stateful. It is possible to mount an attack against the client by + provoking it to respond to packets that appear to come from a large + number of Teredo peers, thus trashing the cache and effectively + denying the use of direct communication between peers. The effect + will last only as long as the attack is sustained. + +7.3.4. Attacks against the Local Discovery Procedure + + There is 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 are more interested + in security than in performance could decide to disable the local + discovery procedure; however, if local discovery is disabled, traffic + between local nodes will end up being relayed through a server + + + +Huitema Standards Track [Page 42] + +RFC 4380 Teredo February 2006 + + + external to the local network, which has questionable security + implications. + +7.3.5. Attacking the Teredo Servers and Relays + + It is 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 will have 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 is 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: the traffic will be picked up by the next relay. + + An attack similar to that described in Section 7.3.2 can be mounted + against a relay. An IPv6 host can send IPv6 packets to a large + number of Teredo destinations, forcing the relay to establish state + for each of these destinations. Teredo relays can obtain 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 is a widely expressed concern that transition mechanisms such + as Teredo can be used to mount denial of service attacks, by + injecting traffic at locations where it is not expected. These + attacks fall in 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, which contains + highly specific patterns such as the Teredo UDP port, or the Teredo + IPv6 prefix. In case of attacks, these 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. + + + + + + +Huitema Standards Track [Page 43] + +RFC 4380 Teredo February 2006 + + +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. The attacker can do this in + one of two ways. The first way is to construct a Router Solicitation + + message and post it to a Teredo server, using as IPv4 source address + the spoofed address of the target; 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, and to then send packets bound to that address to the selected + Teredo server. + + Reflector attacks are discussed in [REFLECT], which outlines various + mitigating techniques against such attacks. 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 is clearly + recognizable, since it originates from the Teredo UDP port; it can be + filtered out safely if the target itself is not a Teredo user. In + addition, the packets relayed by servers will carry an Origin + indication encapsulation, which will help 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 will + build an IPv6 packet bound for the target and will send that packet + to the IPv4 address and UDP port of a Teredo server, to be relayed + from there to the target over IPv6. + + The address checks specified in Section 5.3.1 provide some protection + against this attack, as they ensure that the IPv6 source address will + be consistent with the IPv4 source address and UDP source port used + by the attacker: if the attacker cannot spoof the IPv4 source + address, the target will be able to determine the origin of the + attack. + + The address checks ensure that the IPv6 source address of packets + forwarded by servers will start with the IPv6 Teredo prefix. This is + a mitigating factor, as sites under attack could use this to filter + out all packets sourced from that prefix during an attack. This will + result in a partial loss of service, as the target will not be able + to communicate with legitimate Teredo hosts that use the same prefix. + + + +Huitema Standards Track [Page 44] + +RFC 4380 Teredo February 2006 + + + However, the communication with other IPv6 hosts will remain + unaffected, and the communication with Teredo hosts will be able to + resume when 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 will compose 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 variation of this attack, the attacker sends IPv6 + packets to the Teredo destination using regular IPv6 routing. The + packets are picked by the nearest relay, which will forward them to + the IPv4 address of the target. In a more elaborate variant, the + attacker tricks a Teredo into sending packets to the target, 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 that an attacker may embed in + the spoofed Teredo address. It may embed a multicast or broadcast + address, an 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, in a way reminiscent of the + "smurf" attack. + + By using local addresses, the attacker can reach hosts that are not + normally reachable from the Internet, for example, hosts connected to + the 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. This is similar to attack variants using 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 + are designed to eliminate the possibility of using broadcast, + multicast or local addresses in denial of service or other attacks. + In what follows, we will only consider attacks targeting globally + reachable unicast addresses. + + + + + + + + +Huitema Standards Track [Page 45] + +RFC 4380 Teredo February 2006 + + + The attacks can be targeted at arbitrary UDP ports, such as, for + example, the DNS port of a server. The UDP payload must be a well- + formed IPv6 packet, and is thus unlikely to be accepted by any well- + written UDP service; in most case, the only effect of the attack will + be to overload the target with random traffic. + + A special case occurs if the attack is directed to an echo service. + The service will echo the packets. Since the echo service sees the + request coming from the IPv4 address of the relay, the echo replies + will be sent back to the same relay. According to the rules + specified in Section 5.4, these packets will be discarded by the + Teredo relay. This is not a very efficient attack against the Teredo + relays -- establishing a legitimate session with an actual Teredo + host would create more traffic. + + The IPv6 packets sent to the target contain the IPv6 address used by + the attacker. If ingress filtering is used in the IPv6 network, this + + address will be hard to spoof. If ingress filtering is not 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; the relays + can use these 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 + + The IAB has studied the problem of "Unilateral Self Address Fixing" + (UNSAF), which is the general process by which a client attempts to + determine its address in another realm on the other side of a NAT + through a collaborative protocol reflection mechanism [RFC3424]. + Teredo is an example of a protocol that performs this type of + function. The IAB has mandated that any protocols developed for this + purpose document a specific set of considerations. This section + meets those requirements. + +8.1. Problem Definition + + From [RFC3424], any UNSAF proposal must provide a precise definition + of a specific, limited-scope problem that is to be solved with the + UNSAF proposal. A short-term fix should not be generalized to solve + other problems; this is why "short term fixes usually aren't". + + The specific problem being solved by Teredo is the provision of IPv6 + connectivity for hosts that cannot obtain IPv6 connectivity natively + and cannot make use of 6to4 because of the presence of a NAT between + them and the 6to4 relays. + + + +Huitema Standards Track [Page 46] + +RFC 4380 Teredo February 2006 + + +8.2. Exit Strategy + + From [RFC3424], any UNSAF proposal must provide the description of an + exit strategy/transition plan. The better short term fixes are the + ones that will naturally see less and less use as the appropriate + technology is deployed. + + Teredo comes with its own built-in exit strategy: as soon as a client + obtains IPv6 connectivity by other means, either 6to4 or native IPv6, + it can cease using the Teredo service. In particular, we expect that + the next generation of home routers will provide an IPv6 service in + complement to the current IPv4 NAT service, e.g., by relaying + connectivity obtained from the ISP, or by using a configured or + automatic tunnel service. + + As long as Teredo is used, there will be a need to support Teredo + relays so that the remaining Teredo hosts can communicate with native + IPv6 hosts. As Teredo usage declines, the traffic load on the relays + will decline. Over time, managers will observe a reduced traffic + load on their relays and will turn them off, effectively increasing + the pressure on the remaining Teredo hosts to upgrade to another form + of connectivity. + + The exit strategy is facilitated by the nature of Teredo, which + provides an IP-level solution. IPv6-aware applications do not have + to be updated to use or not use Teredo. The absence of impact on the + applications makes it easier to migrate out of Teredo: network + connectivity suffices. + + There would appear to be reasons why a Teredo implementation might + decide to continue usage of the Teredo service even if it already has + obtained connectivity by some other means, for example: + + 1. When a client is dual homed, and it wishes to improve the service + when communicating with other Teredo hosts that are "nearby" on the + IPv4 network. If the client only used its native IPv6 service, the + Teredo hosts would be reached only through the relay. By maintaining + Teredo, the Teredo hosts can be reached by direct transmission over + IPv4. + + 2. If, for some reason, the Teredo link is providing the client with + better service than the native IPv6 link, in terms of bandwidth, + packet loss, etc. + + The design of Teredo mitigates the dual-homing reason. A host that + wishes to communicate with Teredo peers can implement a "host-based + relay", which is effectively an unnumbered Teredo interface. As + such, the dual-homed host will obtain Teredo connectivity with those + + + +Huitema Standards Track [Page 47] + +RFC 4380 Teredo February 2006 + + + hosts that must use Teredo, but will not inadvertently encourage + other dual-homed hosts to keep using the Teredo service. + + The bubbles and the UDP encapsulation used by Teredo introduce a + significant overhead. It would take exceptional circumstances for + native technologies to provide a lesser service than Teredo. These + exceptional circumstances, or other unforeseen reasons, may induce + hosts to keep using the Teredo service despite the availability of + native IPv6 connectivity. However, these circumstances are likely to + be rare and transient. Moreover, if the primary reason to use Teredo + fades away, one can expect that Teredo relays will be progressively + turned off and that the quality of the Teredo service will + progressively degrade, reducing the motivation to use the Teredo + service. + +8.3. Brittleness Introduced by Teredo + + From [RFC3424], any UNSAF proposal must provide a discussion of + specific issues that may render systems more "brittle". For example, + approaches that involve using data at multiple network layers create + more dependencies, increase debugging challenges, and make it harder + to transition. + + Teredo introduces brittleness into the system in several ways: the + discovery process assumes a certain classification of devices based + on their treatment of UDP; the mappings need to be continuously + refreshed; and addressing structure may cause some hosts located + behind a common NAT to be unreachable from each other. + + There are many similarities between these points and those introduced + by Simple Traversal of the UDP Protocol through NAT (STUN) [RFC3489]; + however, Teredo is probably somewhat less brittle than STUN. The + reason is that all Teredo packets are sent from the local IPv4 Teredo + service port, including discovery, bubbles, and actual encapsulated + packets. This is different from STUN, where NAT type detection and + binding allocation use different local ports (ephemeral, in both + cases). + + Teredo assumes a certain classification of devices based on their + treatment of UDP (e.g., cone, protected cone and symmetric). There + could be devices that would not fit into one of these molds, and + hence would be improperly classified by Teredo. + + The bindings allocated from the NAT need to be continuously + refreshed. Since the timeouts for these bindings are very + implementation specific, the refresh interval cannot easily be + + + + + +Huitema Standards Track [Page 48] + +RFC 4380 Teredo February 2006 + + + determined. When the binding is not being actively used to receive + traffic, but to wait for an incoming message, the binding refresh + will needlessly consume network bandwidth. + + The use of the Teredo server as an additional network element + introduces another point of potential security attack. These attacks + are largely prevented by the security measures provided by Teredo, + but not entirely. + + The use of the Teredo server as an additional network element + introduces another point of failure. If the client cannot locate a + Teredo server, or if the server should be unavailable due to failure, + the Teredo client will not be able to obtain IPv6 connectivity. + + The communication with non-Teredo hosts relies on the availability of + Teredo relays. The Teredo design assumes that there are multiple + Teredo relays; the Teredo service will discover the relay closest to + the non-Teredo peer. If that relay becomes unavailable, or is + misbehaving, communication between the Teredo hosts and the peers + close to that relay will fail. This reliability issue is somewhat + mitigated by the possibility to deploy many relays, arbitrarily close + from the native IPv6 hosts that require connectivity with Teredo + peers. + + Teredo imposes some restrictions on the network topologies for proper + operation. In particular, if the same NAT is on the path between two + clients and the Teredo server, these clients will only be able to + interoperate if they are connected to the same link, or if the common + NAT is capable of "hairpinning", i.e., "looping" packets sent by one + client to another. + + There are also additional points of brittleness that are 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, due to + the queuing of packets while bubble exchanges take place. This + jitter can negatively impact applications, particularly latency + sensitive ones, such as Voice over IP (VoIP). + + + + + + +Huitema Standards Track [Page 49] + +RFC 4380 Teredo February 2006 + + +8.4. Requirements for a Long-Term Solution + + From [RFC3424], any UNSAF proposal must identify requirements for + longer-term, sound technical solutions -- contribute to the process + of finding the right longer-term solution. + + Our experience with Teredo has led to the following requirements 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 are the result 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 from 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. + + + + + + + + + + + + + + + + + + + + + +Huitema Standards Track [Page 50] + +RFC 4380 Teredo February 2006 + + +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. + + + + + + + +Huitema Standards Track [Page 51] + +RFC 4380 Teredo February 2006 + + +11.2. Informative References + + [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 + + Christian Huitema + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052-6399 + + EMail: huitema@microsoft.com + + + + + + + + +Huitema Standards Track [Page 52] + +RFC 4380 Teredo February 2006 + + +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). + + + + + + + +Huitema Standards Track [Page 53] + |