Teredo Extensions
updates
- rfc-4380 — Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)
Extracted elements (28)
RFC 4380 recommended going offline when a symmetric NAT is detected because peers see a different mapped address/port than what is embedded in the Teredo IPv6 address, causing incoming packets to be dropped. The Symmetric NAT Support Extension overrides this by using nonces to authenticate the actual mapped address/port seen by the peer, enabling connectivity despite the mismatch.
The Sequential Port-Symmetric NAT Extension defaults to assuming a symmetric NAT is sequential (rather than requiring explicit detection) because there is no perfect discovery method and these NATs are known to change behavior. This is described as a 'last resort' for symmetric NAT traversal.
Trailers are placed after the IPv6 packet (not before) and the RFC 4380 definition of 'consistent' payload length is updated to mean the IPv6 packet length is less than or equal to the UDP payload length, allowing extra bytes after the IPv6 packet without violating the original validity check.
For symmetric-to-symmetric NAT pairs without UPnP, and for address-symmetric NATs communicating with anything other than cone NATs, no connectivity is achievable even with all extensions defined in this document. Failed connectivity tests complete within a finite time, allowing fallback to native IPv4 addresses.
The UPnP-Enabled Symmetric NAT Extension and the Port-Preserving Symmetric NAT Extension both depend on the Symmetric NAT Support Extension. The Sequential Port-Symmetric NAT Extension additionally depends on the Port-Preserving NAT Extension. All other extensions are independent of each other.
A Teredo client MUST process trailers in order. If an unrecognized trailer type has highest-order bits '01', the client MUST discard the packet; otherwise it MUST skip past the trailer. Processing MUST stop immediately upon encountering a malformed trailer.
Any node implementing the UPnP-Enabled Symmetric NAT Extension or the Port-Preserving Symmetric NAT Extension MUST also implement the Symmetric NAT Support Extension.
During UPnP initialization, if AddPortMapping fails the Teredo client MUST continue without the extension. On shutdown, the client MUST call DeletePortMapping to release the reserved external port.
The Alternate Address Trailer MUST NOT be present in any packets other than indirect bubbles sent by a Teredo client. Each entry in the Alternate Address/Port List MUST contain a valid unicast IPv4 address, and the Port field MUST NOT be zero.
The Sequential Port-Symmetric NAT Extension requires the Symmetric NAT Support Extension AND the Port-Preserving NAT Extension. Any node implementing it MUST implement both dependencies.
The Teredo refresh interval initial parameter SHOULD be configurable and the default MUST be 30 seconds. The randomized refresh interval MUST fall within 50% to 150% of the refresh interval (relaxing RFC 4380's 75%–100% range).
When receiving a direct bubble, if the mapped address/port does not match the address embedded in the source Teredo IPv6 address but the bubble contains a Nonce Trailer whose nonce matches the Nonce Sent field for that peer, the direct bubble MUST be accepted. Otherwise it MUST be dropped.
When sending an indirect bubble, a Teredo client MUST generate a random 4-byte nonce, include it in a Nonce Trailer, and store it in the Nonce Sent field of the Peer Entry. When sending a direct bubble in response to an indirect bubble that carried a Nonce Trailer, the client MUST include a Nonce Trailer with the same nonce value.
When the Port-Preserving NAT flag is TRUE and the Symmetric NAT flag is set, and the peer is not trusted and the Random Port is zero, the client MUST select a random port and begin listening on it. If the Random Port is non-zero, the client MUST append a Random Port Trailer to indirect bubbles.
Teredo extensions add TLV-encoded trailers appended after the IPv6 packet in a UDP datagram. Each trailer has a 1-byte Type, 1-byte Length, and variable Value field. The highest-order two bits of the Type field specify the action when the type is unrecognized: '01' means discard the packet; '00', '10', '11' mean skip.
The Hairpinning Extension enables two Teredo clients behind the same non-hairpinning NAT to communicate by including the sender's local address/port (and optionally UPnP-mapped address/port) in the Alternate Address Trailer of an indirect bubble. The receiver then attempts direct bubbles to all advertised addresses.
The Port-Preserving Symmetric NAT Extension enables traversal between port-preserving symmetric NATs and port-restricted NATs by having clients listen on a randomly chosen local port, predict the same port will be used externally, and exchange the random port number via the Random Port Trailer in indirect bubbles.
The Sequential Port-Symmetric NAT Extension uses an Echo Test: the client sends a router solicitation to the Teredo server, a direct bubble to the peer, and a router solicitation to the secondary server from a random port. The external port for the direct bubble is estimated as the midpoint of the ports reported by the two server responses.
The Server Load Reduction Extension reduces Teredo server load by using direct bubbles with a Neighbor Discovery Option Trailer (DiscoveryType=TeredoDiscoverySolicitation) to solicit responses from peers, falling back to indirect bubbles only when direct-bubble refresh attempts fail.
The Symmetric NAT Support Extension allows Teredo clients behind symmetric NATs to obtain a Teredo IPv6 address and communicate with peers behind cone or address-restricted NATs, overriding RFC 4380's guidance to go offline when a symmetric NAT is detected.
The UPnP-Enabled Symmetric NAT Extension uses UPnP AddPortMapping to reserve an external port before qualification, embedding it in the Teredo IPv6 address so any peer can reach the client regardless of symmetric NAT behavior. It depends on the Symmetric NAT Support Extension.
No new IANA registries are created by this document. The trailer Type values (0x01 Nonce, 0x03 Alternate Address, 0x04 Neighbor Discovery Option, 0x05 Random Port) are defined within the document but no IANA registry action is specified in Section 9.
The nonce mechanism in the Nonce Trailer authenticates the actual mapped address/port of a peer behind a symmetric NAT, preventing spoofed address/port injection. A direct bubble with a non-matching mapped address is accepted only if its nonce matches the value sent in the most recent indirect bubble to that peer, providing replay protection equivalent to RFC 4380's ICMPv6-based connectivity test.
Port-Preserving Extension peer state transitions: initial 'not-trusted' state moves to 'trusted' on first accepted direct bubble on either primary or random port. If mappings change after >30 seconds of inactivity, state reverts to 'not-trusted' and an indirect bubble is sent to re-establish. Direct Receive on Primary Port and Direct Receive on Random Port flags track which port received successful communication.
Alternate Address Trailer (Type=0x03): used by the Hairpinning Extension in indirect bubbles only. Contains a 2-byte Reserved field (must be 0x0000) followed by an Alternate Address/Port List of 1–4 entries, each 6 bytes (4-byte IPv4 address + 2-byte port). Length field MUST be 8–26 and SHOULD be at most 14.
Neighbor Discovery Option Trailer (Type=0x04, Length=0x04): enables direct bubbles to solicit a response, replacing the need for indirect bubbles in the Server Load Reduction Extension. The DiscoveryType byte is 0x00 (solicitation) or 0x01 (advertisement); 3 bytes Reserved MUST be 0x000000.
Nonce Trailer (Type=0x01, Length=0x04): carries a 4-byte nonce value used to authenticate Teredo clients behind symmetric NATs. Present in indirect and direct bubbles when the Symmetric NAT Support Extension is active.
Random Port Trailer (Type=0x05, Length=0x02): carries a 2-byte network-byte-order port number representing the external port a port-preserving symmetric NAT client predicts its NAT has assigned for communication with the peer.