Traversal Using Relays around NAT (TURN) Extension for IPv6
obsoleted by
- rfc-8656 — Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
Extracted elements (28)
A client wishing to allocate both an IPv4 and an IPv6 relayed transport address must perform two separate Allocate requests, one per address family. This is because TURN allocates a single relayed transport address per allocation request, and Allocate requests cannot carry more than one REQUESTED-ADDRESS-FAMILY attribute.
The packet translation behaviors are designed so that a TURN server can be implemented as a user-land application without special OS privileges, consistent with the principle stated in RFC 5766 Section 2.6. Both preferred and alternate translation behaviors follow this constraint.
If a TURN server does not understand the REQUESTED-ADDRESS-FAMILY attribute (e.g., a legacy server), it generates a 420 (Unknown Attribute) Allocate error response containing an UNKNOWN-ATTRIBUTE attribute, per RFC 5389 comprehension-required attribute rules.
Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY attribute in an Allocate request that also contains a RESERVATION-TOKEN attribute. If a server receives a request with both, it replies with a 400 (Bad Request) error.
Clients MUST NOT include more than one REQUESTED-ADDRESS-FAMILY attribute in an Allocate request.
For both preferred and alternate behavior in all translation directions (IPv4-to-IPv6, IPv6-to-IPv6, IPv6-to-IPv4), the DONT-FRAGMENT attribute MUST be ignored by the server.
If a server receives a Refresh Request with a REQUESTED-ADDRESS-FAMILY attribute whose value does not match the address family of the allocation, the server MUST reply with a 443 (Peer Address Family Mismatch) Refresh error response.
If an XOR-PEER-ADDRESS attribute in a CreatePermission request contains an address of a different family than the allocation's relayed transport address, the server MUST generate an error response with the 443 (Peer Address Family Mismatch) code.
If the client receives an Allocate error response with the 440 (Address Family not Supported) error code, the client MUST NOT retry its request.
If the REQUESTED-ADDRESS-FAMILY attribute is absent from an Allocate request, the server MUST allocate an IPv4 relayed transport address. If local policy disables IPv4 allocation, the server returns a 440 (Address Family not Supported) error.
If the server does not support the address family requested by the client, it MUST generate an Allocate error response including an ERROR-CODE attribute with the 440 (Address Family not Supported) response code.
In a ChannelBind request, the client MUST only include an XOR-PEER-ADDRESS attribute with an address of the same address family as the allocation's relayed transport address; if mismatched, the server MUST return a 443 error.
In a CreatePermission request, the client MUST only include XOR-PEER-ADDRESS attributes with addresses of the same address family as that of the allocation's relayed transport address.
The client MUST NOT include any REQUESTED-ADDRESS-FAMILY attribute in a Refresh Request; the address family of an existing allocation cannot be changed via refresh.
To mitigate the tunnel amplification attack, a TURN relay MUST NOT accept Teredo or 6to4 addresses in allocation or channel binding requests, and it is RECOMMENDED that relays not accept requests from or forward data to addresses known to be tunneled.
TURN relays performing any IPv4/IPv6 translation MUST translate the IP addresses and port numbers of packets based on the allocation's state information as specified in RFC 5766.
Error code 440 (Address Family not Supported) is defined for cases where the TURN server does not support the address family requested by the client in an Allocate request.
Error code 443 (Peer Address Family Mismatch) is defined for cases where a peer address in a CreatePermission or ChannelBind request is of a different address family than the relayed transport address of the allocation.
For IPv4-to-IPv6 translations, the relay translates Traffic Class, Flow Label (preferred: set to 0), Hop Limit, and Fragmentation per RFC 6145. Extension headers are stripped except for the Fragment Header. The DONT-FRAGMENT attribute MUST be ignored.
For IPv6-to-IPv4 translations, the relay translates Type of Service, Time to Live, and Fragmentation per RFC 6145. When outgoing size exceeds MTU, the relay generates an ICMPv6 Packet Too Big error. The DONT-FRAGMENT attribute MUST be ignored.
For IPv6-to-IPv6 translations, the relay treats the two flows independently: Flow Label SHOULD NOT be copied, Hop Limit is decremented as a router, and fragmentation logic preserves or regenerates Fragment Headers based on MTU. Outgoing fragments exceeding MTU must be no more than 1280 bytes.
The REQUESTED-ADDRESS-FAMILY attribute (type 0x0017) is a new comprehension-required STUN attribute allowing a client to request a specific address family (IPv4 or IPv6) for a TURN allocation. It is encoded as a TLV with a 1-byte Family field (0x01 for IPv4, 0x02 for IPv6) and 24 bits of reserved zero padding, for a total value length of 4 bytes.
This document registers STUN attribute type 0x0017 (REQUESTED-ADDRESS-FAMILY) in the IANA STUN Attributes registry. The attribute is comprehension-required (value < 0x8000).
This document registers two new STUN error codes in the IANA STUN Error Codes registry: 440 (Address Family not Supported) and 443 (Peer Address Family Mismatch).
A tunnel amplification attack is possible when an attacker spoofs Allocate and ChannelBind requests to establish a loop between a TURN relay (doing IPv6-to-IPv4 translation) and an IPv4-IPv6 tunnel endpoint. The attacker sends nested TURN-channeled IPv6 packets that bounce between the relay and the tunnel, amplifying traffic up to roughly 4:1 within a 1500-byte MTU.
Enabling IPv4-to-IPv6 and IPv6-to-IPv4 translation via TURN creates new paths for clients to reach address families they would not otherwise access (e.g., an IPv4-only client gaining IPv6 Internet access). Security and monitoring policies must account for this new capability.
The loop attack described in RFC 5766 Section 17.1.7 may be more easily executed over IPv6 where address spoofing is simpler. Mitigation is the same as for IPv4.
REQUESTED-ADDRESS-FAMILY attribute wire format: 16-bit Type (0x0017), 16-bit Length (4), 8-bit Family (0x01=IPv4, 0x02=IPv6), 24-bit Reserved (must be zero on send, ignored on receive). Total attribute size is 8 bytes including the TLV header.