RFC 6156

Traversal Using Relays around NAT (TURN) Extension for IPv6

📅 published April 2011, from ietf

RFC 6156 🎀 Traversal Using Relays around NAT (TURN) Extension for IPv6

Okay bestie, here's the title block tea 💖:

Stream: Internet Engineering Task Force (IETF), Request for Comments 6156
Authors: G. Camarillo (Ericsson), O. Novo (Ericsson), and S. Perreault, Ed. (Viagenie)
Category: Standards Track
ISSN: 2070-1721
Date: April 2011
Obsoletes / Updates: the title block doesn't name any RFCs this one obsoletes or updates ✨

Abstract

okay so this doc adds IPv6 support to TURN (Traversal Using Relays around NAT) 🦋. TURN now covers IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying, which is literally so iconic 😭. It defines the REQUESTED-ADDRESS-FAMILY attribute, which lets a client explicitly ask for the address type the TURN server will allocate. Think of an IPv4-only node asking the server for an IPv6 address. Main character energy 👑

Status of This Memo

This is an Internet Standards Track document 🌸

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc6156.

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License.

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
3.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  3
4.  Creating an Allocation . . . . . . . . . . . . . . . . . . . .  4
  4.1.  Sending an Allocate Request  . . . . . . . . . . . . . . .  4
    4.1.1.  The REQUESTED-ADDRESS-FAMILY Attribute . . . . . . . .  4
  4.2.  Receiving an Allocate Request  . . . . . . . . . . . . . .  5
    4.2.1.  Unsupported Address Family . . . . . . . . . . . . . .  6
  4.3.  Receiving an Allocate Error Response . . . . . . . . . . .  6
5.  Refreshing an Allocation . . . . . . . . . . . . . . . . . . .  6
  5.1.  Sending a Refresh Request  . . . . . . . . . . . . . . . .  6
  5.2.  Receiving a Refresh Request  . . . . . . . . . . . . . . .  6
6.  CreatePermission . . . . . . . . . . . . . . . . . . . . . . .  6
  6.1.  Sending a CreatePermission Request . . . . . . . . . . . .  6
  6.2.  Receiving a CreatePermission Request . . . . . . . . . . .  7
    6.2.1.  Peer Address Family Mismatch . . . . . . . . . . . . .  7
7.  Channels . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
  7.1.  Sending a ChannelBind Request  . . . . . . . . . . . . . .  7
  7.2.  Receiving a ChannelBind Request  . . . . . . . . . . . . .  7
8.  Packet Translations  . . . . . . . . . . . . . . . . . . . . .  7
  8.1.  IPv4-to-IPv6 Translations  . . . . . . . . . . . . . . . .  8
  8.2.  IPv6-to-IPv6 Translations  . . . . . . . . . . . . . . . .  9
  8.3.  IPv6-to-IPv4 Translations  . . . . . . . . . . . . . . . . 10
9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
  9.1.  Tunnel Amplification Attack  . . . . . . . . . . . . . . . 11
10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
  10.1. New STUN Attribute . . . . . . . . . . . . . . . . . . . . 12
  10.2. New STUN Error Codes . . . . . . . . . . . . . . . . . . . 13
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
  12.1. Normative References . . . . . . . . . . . . . . . . . . . 13
  12.2. Informative References . . . . . . . . . . . . . . . . . . 13

1. Introduction 🧚

TURN [RFC5766] is a protocol that lets an element behind a NAT receive incoming data over UDP or TCP. It's most useful for elements behind NATs without Endpoint-Independent Mapping [RFC4787] that want to be on the receiving end of a connection to a single peer 💅

The base TURN spec [RFC5766] only defines IPv4-to-IPv4 relaying, so this doc adds IPv6 support. That covers IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying 🌈 It also defines the REQUESTED-ADDRESS-FAMILY attribute, an extension that lets a client explicitly request the address type the TURN server will allocate. (Same example again: an IPv4-only node asking for an IPv6 address.) This doc also defines and registers new error response codes 🫶

2. Terminology ✨

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]. 🍓

3. Overview of Operation 🌸

So when a user wants a TURN server to allocate an address of a specific type, the client sends an Allocate request with a REQUESTED-ADDRESS-FAMILY attribute 💖 TURN can run over UDP and TCP, and a client can request address/port pairs for receiving both UDP and TCP. Iconic 🦋

Once the request has been successfully authenticated, the TURN server allocates a transport address of the type indicated in the REQUESTED-ADDRESS-FAMILY attribute. This address is called the relayed transport address 🔥

The TURN server returns the relayed transport address in the response to the Allocate request. That response contains an XOR-RELAYED-ADDRESS attribute showing the IP address and port the server allocated for the client 🎀

Here's a catch 👀: TURN servers allocate a single relayed transport address per allocation request. So Allocate requests can't carry more than one REQUESTED-ADDRESS-FAMILY attribute. If a client wants more than one relayed transport address at a TURN server (say, an IPv4 address and an IPv6 address), it needs to make several allocation requests, one per relayed transport address 💅

A TURN server that supports a set of address families is assumed to be able to relay packets between them. If a server doesn't support the address family a client asked for, the server returns a 440 (Address Family not Supported) error response 😭

4. Creating an Allocation 💜

The behavior specified here affects the processing defined in Section 6 of [RFC5766]. 🧚

4.1. Sending an Allocate Request 🌈

A client that wants a relayed transport address of a specific address type includes a REQUESTED-ADDRESS-FAMILY attribute (defined in Section 4.1.1) in the Allocate request it sends to the TURN server. Clients MUST NOT include more than one REQUESTED-ADDRESS-FAMILY attribute in an Allocate request. The mechanisms for formulating an Allocate request are described in Section 6.1 of [RFC5766]. 📝

Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY attribute in an Allocate request that contains a RESERVATION-TOKEN attribute. 🙈

4.1.1. The REQUESTED-ADDRESS-FAMILY Attribute 🎀

The REQUESTED-ADDRESS-FAMILY attribute is how clients ask a server for a specific address type. Here's the format 👑 Quick heads up: TURN attributes are TLV (Type-Length-Value) encoded, with a 16-bit type, a 16-bit length, and a variable-length value.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Type                  |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Family    |            Reserved                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 1: Format of REQUESTED-ADDRESS-FAMILY Attribute

Here's what each field does 🧚

Type: the type of the REQUESTED-ADDRESS-FAMILY attribute is 0x0017. As specified in [RFC5389], attributes with values between 0x0000 and 0x7FFF are comprehension-required, which means the client or server can't successfully process the message unless it understands the attribute. 🔥
Length: this 16-bit field contains the length of the attribute in bytes. The length of this attribute is 4 bytes. 🍓
Family: there are two values defined for this field, specified in [RFC5389], Section 15.1: 0x01 for IPv4 addresses and 0x02 for IPv6 addresses. 🌸
Reserved: at this point, the 24 bits in the Reserved field MUST be set to zero by the client and MUST be ignored by the server. 💅

The REQUEST-ADDRESS-TYPE attribute MAY only be present in Allocate requests. 🙈

4.2. Receiving an Allocate Request 💖

Once a server has verified that the request is authenticated and hasn't been tampered with, the TURN server processes the Allocate request. If it contains both a RESERVATION-TOKEN and a REQUESTED-ADDRESS-FAMILY, the server replies with a 400 (Bad Request) Allocate error response. Following the rules in [RFC5389], if the server doesn't understand the REQUESTED-ADDRESS-FAMILY attribute, it generates an Allocate error response that includes an ERROR-CODE attribute with the 420 (Unknown Attribute) response code. That response contains an UNKNOWN-ATTRIBUTE attribute listing the unknown REQUESTED-ADDRESS-FAMILY attribute 😭

If the server can successfully process the request, it allocates a transport address for the TURN client, called the relayed transport address, and returns it in the response to the Allocate request ✨

As specified in [RFC5766], the Allocate response contains the same transaction ID as the Allocate request, and the XOR-RELAYED-ADDRESS attribute is set to the relayed transport address 🦋

The XOR-RELAYED-ADDRESS attribute indicates the allocated IP address and port. It's encoded the same way as the XOR-MAPPED-ADDRESS [RFC5389] 🎀

If the REQUESTED-ADDRESS-FAMILY attribute is absent, the server MUST allocate an IPv4-relayed transport address for the TURN client. If allocation of IPv4 addresses is disabled by local policy, the server returns a 440 (Address Family not Supported) Allocate error response 👑

If the server doesn't support the address family the client requested, it MUST generate an Allocate error response, and it MUST include an ERROR-CODE attribute with the 440 (Address Family not Supported) response code, which is defined in Section 4.2.1 🙈

4.2.1. Unsupported Address Family 🌈

This document defines the following new error response code 🍓

440 (Address Family not Supported): The server does not support the address family requested by the client. 💜

4.3. Receiving an Allocate Error Response 🥺

If the client receives an Allocate error response with the 440 (Unsupported Address Family) error code, the client MUST NOT retry its request. 🫶

more TURN deets are coming in the next part, bestie 🧚💖

5. Refreshing an Allocation 💖

okay so this bit is basically a rider on Section 7 of [RFC5766], the TURN spec, so it's changing how refreshes get processed 🎀

5.1. Sending a Refresh Request

when the client wants to refresh an allocation, it builds a Refresh Request the way Section 7.1 of [RFC5766] says 🧚 the important part: the client MUST NOT put any REQUESTED-ADDRESS-FAMILY attribute in that Refresh Request. no family attribute, no exceptions 🙅‍♀️

5.2. Receiving a Refresh Request

if a server gets a Refresh Request that DOES have a REQUESTED-ADDRESS-FAMILY attribute, and the value doesn't match the address family of the allocation, the server MUST reply with a 443 (Peer Address Family Mismatch) Refresh error response 💅 mismatched family = instant 443 energy 💀

6. CreatePermission 🌸

this one touches Section 9 of [RFC5766] and it's all about the peer addresses you hand over 🦋

6.1. Sending a CreatePermission Request

the client MUST only include XOR-PEER-ADDRESS attributes with addresses from the same address family as the relayed transport address for the allocation. keep it consistent bestie ✨

6.2. Receiving a CreatePermission Request

if an XOR-PEER-ADDRESS attribute has an address from a different address family than the relayed transport address for the allocation, the server MUST generate an error response with the 443 (Peer Address Family Mismatch) response code, which is defined in Section 6.2.1 🔥

6.2.1. Peer Address Family Mismatch

this document is adding one brand new error response code 👑

443 (Peer Address Family Mismatch)

and what it means: a peer address was from a different address family than the relayed transport address of the allocation 🫶

7. Channels 🦋

this section changes how Section 11 of [RFC5766] works, so ChannelBind is getting a glow-up 🌈

7.1. Sending a ChannelBind Request

the client MUST only include an XOR-PEER-ADDRESS attribute with an address from the same address family as the relayed transport address for the allocation. same rule, new room 💜

7.2. Receiving a ChannelBind Request

if the XOR-PEER-ADDRESS attribute has an address from a different address family than the relayed transport address for the allocation, the server MUST generate an error response with the 443 (Peer Address Family Mismatch) response code, which is defined in Section 6.2.1 🎀

8. Packet Translations ✨

okay this is the big one lol 😭 TURN relays are originally written for IPv4 packets going to IPv4 (IPv4-to-IPv4 translations). the relay rewrites IP addresses and port numbers based on the allocation's state data, and how to handle the other header fields is also in [RFC5766]. this document covers IPv4-to-IPv6, IPv6-to-IPv4, and IPv6-to-IPv6 translations 🌍

any relay doing a translation MUST translate the IP addresses and port numbers based on the allocation's state information, as specified in [RFC5766]. the sections below cover the other header fields 🧚

fun fact from Section 2.6 of [RFC5766]: TURN is designed so a server can run as a regular "user-land" app on common operating systems, no special privileges needed. the translations in the next sections follow that same vibe 💅

every description has two parts, a preferred behavior and an alternate behavior. the server SHOULD implement the preferred behavior. otherwise, the server MUST implement the alternate behavior and MUST NOT do anything else 🍓

8.1. IPv4-to-IPv6 Translations

Traffic Class

Preferred behavior: as specified in Section 4 of [RFC6145].
Alternate behavior: the relay sets the Traffic Class to the default value for outgoing packets.

Flow Label

Preferred behavior: the relay sets the Flow label to 0. the relay can choose to set the Flow label to a different value if it supports the IPv6 Flow Label field [RFC3697].
Alternate behavior: the relay sets the Flow label to the default value for outgoing packets.

Hop Limit

Preferred behavior: as specified in Section 4 of [RFC6145].
Alternate behavior: the relay sets the Hop Limit to the default value for outgoing packets.

Fragmentation

Preferred behavior: as specified in Section 4 of [RFC6145].
Alternate behavior: the relay assembles incoming fragments. the relay follows its default behavior to send outgoing packets.

for both preferred and alternate behavior, the DONT-FRAGMENT attribute ([RFC5766], Section 14.8) MUST be ignored by the server 🙈

Extension Headers

Preferred behavior: the relay sends the outgoing packet without any IPv6 extension headers, with the exception of the Fragment Header as described above.
Alternate behavior: same as preferred.

8.2. IPv6-to-IPv6 Translations

Flow Label

the relay should consider that it is handling two different IPv6 flows. so the Flow label [RFC3697] SHOULD NOT be copied as part of the translation 👀

Preferred behavior: the relay sets the Flow label to 0. the relay can choose to set the Flow label to a different value if it supports the IPv6 Flow Label field [RFC3697].
Alternate behavior: the relay sets the Flow label to the default value for outgoing packets.

Hop Limit

Preferred behavior: the relay acts as a regular router with respect to decrementing the Hop Limit and generating an ICMPv6 error if it reaches zero.
Alternate behavior: the relay sets the Hop Limit to the default value for outgoing packets.

Fragmentation

Preferred behavior: if the incoming packet did not include a Fragment Header and the outgoing packet size does not exceed the outgoing link's MTU, the relay sends the outgoing packet without a Fragment Header.

if the incoming packet did not include a Fragment Header and the outgoing packet size exceeds the outgoing link's MTU, the relay drops the outgoing packet and sends an ICMP message of Type 2, Code 0 ("Packet too big") to the sender of the incoming packet 📦

if the packet is being sent to the peer, the relay reduces the MTU reported in the ICMP message by 48 bytes to allow room for the overhead of a Data indication 🫧

if the incoming packet included a Fragment Header and the outgoing packet size (with a Fragment Header included) does not exceed the outgoing link's MTU, the relay sends the outgoing packet with a Fragment Header. the relay sets the fields of the Fragment Header as appropriate for a packet originating from the server.

if the incoming packet included a Fragment Header and the outgoing packet size exceeds the outgoing link's MTU, the relay MUST fragment the outgoing packet into fragments of no more than 1280 bytes. the relay sets the fields of the Fragment Header as appropriate for a packet originating from the server 🧩

Alternate behavior: the relay assembles incoming fragments. the relay follows its default behavior to send outgoing packets.

for both preferred and alternate behavior, the DONT-FRAGMENT attribute MUST be ignored by the server 🙈

Extension Headers

Preferred behavior: the relay sends the outgoing packet without any IPv6 extension headers, with the exception of the Fragment Header as described above.
Alternate behavior: same as preferred.

8.3. IPv6-to-IPv4 Translations

Type of Service and Precedence

Preferred behavior: as specified in Section 5 of [RFC6145].
Alternate behavior: the relay sets the Type of Service and Precedence to the default value for outgoing packets.

Time to Live

Preferred behavior: as specified in Section 5 of [RFC6145].
Alternate behavior: the relay sets the Time to Live to the default value for outgoing packets.

Fragmentation

Preferred behavior: as specified in Section 5 of [RFC6145]. additionally, when the outgoing packet's size exceeds the outgoing link's MTU, the relay needs to generate an ICMP error (ICMPv6 Packet Too Big) reporting the MTU size. if the packet is being sent to the peer, the relay SHOULD reduce the MTU reported in the ICMP message by 48 bytes to allow room for the overhead of a Data indication.
Alternate behavior: the relay assembles incoming fragments. the relay follows its default behavior to send outgoing packets.

for both preferred and alternate behavior, the DONT-FRAGMENT attribute MUST be ignored by the server 🙈

9. Security Considerations 🚨

ngl this section is SERIOUS, so read it properly 🥹

translating between IPv4 and IPv6 gives clients a brand new way to get IPv4 or IPv6 access they didn't have before. for example, an IPv4-only client that can reach a TURN server running this spec can now get to the IPv6 Internet 🌐 this needs to be part of your security and monitoring policies, no skipping 🔒

the loop attack described in Section 17.1.7 of [RFC5766] may be easier to pull off when address spoofing is easier over IPv6. mitigation over IPv6 is the same as for IPv4 💀

all the security considerations for STUN [RFC5389] and TURN [RFC5766] apply to this document too 🫶

9.1. Tunnel Amplification Attack

okay this is the scary one 😱 an attacker might try to make data packets loop over and over between a TURN server and a tunnel between IPv4 and IPv6.

here's how it goes. say the attacker knows a tunnel endpoint will forward encapsulated packets from a given IPv6 address (that doesn't have to be the tunnel endpoint's own address). then they spoof these two packets from that address:

An Allocate request asking for a v4 address, and
A ChannelBind request establishing a channel to the IPv4 address of the tunnel endpoint

and boom, they've built an amplification attack 🔥

The TURN relay will re-encapsulate IPv6 UDP data in v4 and send it to the tunnel endpoint.
The tunnel endpoint will decapsulate packets from the v4 interface and send them to v6.

so if the attacker sends a packet of the following form:

  IPv6: src=2001:db9::1 dst=2001:db8::2
  UDP:  <ports>
  TURN: <channel id>
  IPv6: src=2001:db9::1 dst=2001:db8::2
  UDP:  <ports>
  TURN: <channel id>
  IPv6: src=2001:db9::1 dst=2001:db8::2
  UDP:  <ports>
  TURN: <channel id>
  ...

then the TURN relay and the tunnel endpoint keep sending it back and forth until the last TURN header is consumed. at that point the TURN relay sends an empty packet that the tunnel endpoint drops 🌀

the amplification is capped by the MTU, so it's not huge: IPv6+UDP+TURN takes 334 bytes, so you could get a four-to-one amplification out of a 1500-byte packet. but the attacker could still bump up traffic by sending multiple packets, or by setting up multiple channels spoofed from different addresses behind the same tunnel endpoint 📈

the mitigation: it is RECOMMENDED that TURN relays not accept allocation or channel binding requests from addresses known to be tunneled, and that they not forward data to such addresses. in particular, a TURN relay MUST NOT accept Teredo or 6to4 addresses in these requests 🛑

10. IANA Considerations 🎀

IANA registered the following values under the "STUN Attributes" registry and under the "STUN Error Codes" registry 📝

10.1. New STUN Attribute

0x0017: REQUESTED-ADDRESS-FAMILY

10.2. New STUN Error Codes

440  Address Family not Supported
443  Peer Address Family Mismatch

11. Acknowledgements 🙏✨

Okay bestie, shoutout time 📣💖 The authors want to thank Alfred E. Heggestad, Dan Wing, Magnus Westerlund, Marc Petit-Huguenin, Philip Matthews, and Remi Denis-Courmont for giving feedback on this document. Absolute legends 🫶👑

12. References 📚

12.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. This is the one that explains the capital-letter key words, so it's giving foundation 🧱

[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004. The flow label slay 🦋

[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. STUN, the OG 💜

[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. TURN is the relay upgrade we've been talking about this whole time 🌸

[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. The translation algorithm, so iconic 💅

12.2. Informative References

[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. Not required reading, but it's a whole vibe 🍓

Authors' Addresses 💌

The people behind this one, with their contact info 🧚

Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas  02420
Finland

EMail: Gonzalo.Camarillo@ericsson.com


Oscar Novo
Ericsson
Hirsalantie 11
Jorvas  02420
Finland

EMail: Oscar.Novo@ericsson.com


Simon Perreault (editor)
Viagenie
2600 boul. Laurier, suite D2-630
Quebec, QC  G1V 2M2
Canada

Phone: +1 418 656 9254
EMail: simon.perreault@viagenie.ca
URI:   http://www.viagenie.ca

And that's the whole RFC, bestie!! 🌈✨ Thank you for reading, you literally made it to the end 😭🎀

📦 where this page comes from

ietf: rfc6156 2011-04
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms

RFC 6156

RFC 6156 🎀 Traversal Using Relays around NAT (TURN) Extension for IPv6

Abstract

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction 🧚

2. Terminology ✨

3. Overview of Operation 🌸

4. Creating an Allocation 💜

4.1. Sending an Allocate Request 🌈

4.1.1. The REQUESTED-ADDRESS-FAMILY Attribute 🎀

4.2. Receiving an Allocate Request 💖

4.2.1. Unsupported Address Family 🌈

4.3. Receiving an Allocate Error Response 🥺

5. Refreshing an Allocation 💖

5.1. Sending a Refresh Request

5.2. Receiving a Refresh Request

6. CreatePermission 🌸

6.1. Sending a CreatePermission Request

6.2. Receiving a CreatePermission Request

6.2.1. Peer Address Family Mismatch

7. Channels 🦋

7.1. Sending a ChannelBind Request

7.2. Receiving a ChannelBind Request

8. Packet Translations ✨

8.1. IPv4-to-IPv6 Translations

8.2. IPv6-to-IPv6 Translations

8.3. IPv6-to-IPv4 Translations

9. Security Considerations 🚨

9.1. Tunnel Amplification Attack

10. IANA Considerations 🎀

10.1. New STUN Attribute

10.2. New STUN Error Codes

11. Acknowledgements 🙏✨

12. References 📚

12.1. Normative References

12.2. Informative References

Authors' Addresses 💌