ietf-corpus

rfc-4380

Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)

C. Huitema
date2006-02 streamIETF wgnon working group statusPROPOSED STANDARD pages53 canonicalhttps://www.rfc-editor.org/rfc/rfc4380 doi10.17487/RFC4380 errataview
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". [STANDARDS-TRACK]

updated by

Extracted elements (30)

design-rationale §3.4

Teredo servers are stateless and relay only control traffic (bubbles, ICMPv6) rather than data packets, both to enable easy replication for scale and to avoid privacy issues that would arise if a server retained copies of client data packets.

ip, nat, v6ops, privacy

design-rationale §3

Teredo tunnels IPv6 over UDP rather than directly over IPv4 or over TCP because UDP is one of only two protocols guaranteed to cross the majority of NAT devices, and UDP avoids the severe QoS degradation from TCP-over-TCP encapsulation.

ip, nat, udp, v6ops

design-rationale §3.1

The mapped UDP port and mapped IPv4 address embedded in Teredo addresses and origin indications are obfuscated by XOR with 0xFFFF and 0xFFFFFFFF respectively to prevent NATs that perform 'probabilistic rewrite' from replacing embedded addresses and ports in the IPv6 payload.

ip, nat, v6ops

design-rationale §3.1

The Teredo specification requires clients behind the same NAT to use different service ports to minimize the chance of encountering symmetric NAT behavior in 'port conserving' NAT designs, which reuse ports for the same external endpoint but allocate new mappings when multiple internal hosts use the same source port.

ip, nat, v6ops

interoperability-note §3.4

Teredo clients exchange IPv6 packets with 6to4 nodes (RFC 3056) and native IPv6 nodes through Teredo relays, which act as IPv6 routers advertising Teredo prefix reachability. Dual-stack hosts may implement a local relay to communicate directly with Teredo hosts without advertising a Teredo IPv6 address themselves.

ip, nat, v6ops

normative-requirement §5.2.6 MUST NOT

A client MUST NOT send a bubble if the last transmission to that peer was less than 2 seconds ago, and MUST NOT send a bubble if it has already sent 4 bubbles to that peer in the last 300 seconds without receiving a direct response, to balance reliability against unnecessary retransmissions.

ip, nat, v6ops

normative-requirement §5.2.4 MUST

Before forwarding a packet to a Teredo IPv6 destination (cases 4 and 5 of packet transmission), the client MUST verify that the IPv4 destination address embedded in the Teredo address is a global unicast address. Non-global ranges to reject include 0/8, 127/8, 10/8, 172.16/12, 192.168/16, 169.254/16, 192.88.99/24, 224/4, 255.255.255.255, and directed broadcast addresses.

ip, nat, security, v6ops

normative-requirement §5.2.2 MUST

During secure qualification, if the nonce value in the server's Router Advertisement response does not match the nonce sent by the client, the packet MUST be discarded. If stronger HMAC-based authentication is used and the computed authentication values do not match, the packet MUST also be discarded.

ip, nat, security, v6ops, crypto

normative-requirement §5.2.8 MUST

In the local client discovery procedure, clients MUST silently discard 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.

ip, nat, security, v6ops

normative-requirement §3.2.1 SHOULD

Nodes SHOULD use Teredo only as a last resort: they SHOULD prefer direct IPv6 connectivity, then 6to4 co-located with the NAT, then a configured tunnel service, then 6to4 with a global IPv4 address, before falling back to Teredo.

ip, nat, v6ops

normative-requirement §5.5 MUST NOT

Teredo-capable nodes MUST NOT behave as Teredo clients if they already have IPv6 connectivity through any other means. Nodes with a global IPv4 address SHOULD obtain connectivity through 6to4 rather than Teredo.

ip, nat, v6ops

normative-requirement §5.1.2 SHOULD NOT

Teredo implementations SHOULD NOT set the Don't Fragment (DF) bit in the encapsulating IPv4 header, because Teredo packets travel on unpredictable paths over the Internet.

ip, v6ops, nat

normative-requirement §5.2.5 MUST

The client MUST regularly verify that at least one packet has been received from the Teredo server within the Randomized Teredo Refresh Interval (75%–100% of the refresh interval, default 30 seconds); if not, it SHOULD send a Router Solicitation to refresh the NAT mapping.

ip, nat, v6ops

normative-requirement §5.1.2 SHOULD

The default link MTU assumed by Teredo hosts and the MTU supplied by a Teredo server in Router Advertisements SHOULD normally be set to the minimum IPv6 MTU of 1280 bytes to minimize IPv4 fragmentation on unpredictable Internet paths.

ip, v6ops, nat

normative-requirement §5.4.1 MUST

The Teredo relay MUST check that the IPv4 destination address embedded in the Teredo IPv6 destination address is a global unicast address before forwarding; if not, the packet MUST be silently discarded.

ip, nat, security, v6ops

normative-requirement §5.3.1 MUST

The Teredo server MUST silently discard packets with non-global-unicast IPv4 source addresses or malformed Teredo encapsulation, MUST accept Router Solicitations with valid link-local source addresses, and MUST verify authentication when secure qualification is configured.

ip, nat, security, v6ops

normative-requirement §5.1.1 MUST

When authentication encapsulation and origin indication encapsulation are combined in the same UDP payload, the authentication encapsulation MUST be the first element in the UDP payload.

ip, nat, security, v6ops

protocol-element §2.8

A Teredo bubble is a minimal IPv6 packet consisting only of an IPv6 header with Next Header set to 59 (No Next Header, per RFC 2460) and zero payload length. Clients and relays send bubbles to establish or maintain NAT mappings without carrying application data.

ip, nat, v6ops

protocol-element §4

Teredo IPv6 addresses are 128-bit values composed of five fields in order: 32-bit Teredo service prefix, 32-bit server IPv4 address, 16-bit flags, 16-bit obfuscated mapped UDP port (XOR 0xFFFF), and 32-bit obfuscated mapped IPv4 address (XOR 0xFFFFFFFF).

ip, nat, v6ops

protocol-element §4

The 16-bit Flags field in a Teredo IPv6 address has two defined values: 0x0000 (not behind cone NAT) and 0x8000 (cone NAT, bit C set). Bits UG must be 00 (non-global unicast identifier); all remaining bits (z) must be set to zero and ignored on receipt.

ip, nat, v6ops

protocol-element §5.2.8

The optional local client discovery procedure uses IPv4 multicast (224.0.0.253, TTL=1) to detect Teredo peers on the same link. Discovery bubbles are sent at random intervals between 200 and 300 seconds; link-scope multicast ensures they are not forwarded across routers.

ip, nat, multicast, v6ops

protocol-element §5.3

The Teredo server is stateless and participates only in qualification (RS/RA exchange), bubble relay, and ICMPv6 echo relay. The server never relays actual data traffic; data flows directly between clients and through relays selected by the destination.

ip, nat, v6ops

protocol-element §2.6

The Teredo UDP port is 3544. The global Teredo IPv6 service prefix is 2001:0000:/32. The Teredo IPv4 Discovery Address for optional local peer discovery is the multicast address 224.0.0.253.

ip, nat, v6ops, registry

registry §9

IANA assigned UDP port 3544 for the Teredo service and allocated IPv6 prefix 2001:0000:/32 as the global Teredo IPv6 service prefix. The multicast address 224.0.0.253 is designated as the Teredo IPv4 Discovery Address.

registry, ip, nat, v6ops

security-consideration §7.2

An attacker who can spoof a Teredo server response can perform a man-in-the-middle attack by sending a forged Router Advertisement that causes the client to embed the attacker's chosen mapped address and port in its Teredo IPv6 address, redirecting all subsequent traffic through the attacker. Secure qualification with HMAC-SHA1 nonce verification is the specified mitigation.

ip, nat, security, v6ops, crypto

security-consideration §7.1

Teredo punches a hole in the NAT allowing incoming UDP packets from any sender who knows the mapped address and port. Cone NAT clients are directly reachable; restricted/port-restricted NAT clients require a prior bubble exchange, limiting unsolicited exposure but not eliminating it.

ip, nat, security, v6ops

security-consideration §7.4

Teredo relays can be exploited as amplifiers for denial-of-service attacks against non-Teredo IPv4 nodes: an attacker can cause a relay to send UDP packets to a private or infrastructure IPv4 address by embedding it in a crafted Teredo IPv6 destination. The mandatory global unicast address check is the primary countermeasure.

ip, nat, security, v6ops

state-machine §5.2.1

Qualification procedure states: Initial -> Starting (RS sent with cone bit=1). If response arrives with cone bit=1, state is Cone NAT (qualified). If no response after N retries, repeat with cone bit=0; if no response again, Off-line. If response with different mapped port/address, Symmetric NAT (not usable); if same, Restricted Cone NAT (qualified). Default T=4s, N=3.

nat, ip, v6ops

wire-format §5.1.1

Authentication encapsulation is a variable-length header: 0x00 0x01 (type indicator), ID-len (1 octet), AU-len (1 octet), client identifier (ID-len bytes), authentication value (AU-len bytes), 8-octet nonce, and 1-octet confirmation byte. Both ID-len and AU-len may be zero if no explicit authentication is required.

ip, nat, security, v6ops

wire-format §5.1.1

Simple encapsulation places the IPv6 packet directly as the payload of a UDP/IPv4 datagram. When origin indication is needed, an 8-octet prefix precedes the IPv6 packet: two null bytes, 16-bit obfuscated source UDP port (XOR 0xFFFF), and 32-bit obfuscated source IPv4 address (XOR 0xFFFFFFFF), all in network byte order.

ip, nat, udp, v6ops