Understanding the STUN Header: Key Functions and Error Handling Explained

Hello everyone, nice to meet you again, I am your friend, Full-stack Jun, here to talk about the keyword STUN header.

This article is based on the STUN protocol from the RFC5389 standard. The discovery process of STUN is based on the assumptions of NAT processing for UDP; as new NAT devices are deployed, these assumptions may be proven invalid. When STUN is used to obtain an address to communicate with a peer behind the same NAT, it does not work. STUN will not work if the deployment of STUN servers falls outside the range of publicly shared address domains. If there are any inaccuracies in the article, please point them out, I would be grateful.
1. Terminology Definition
STUN Agent: A STUN agent is an entity that implements the STUN protocol, which can be either a client or a server.
STUN Client: The entity that generates STUN requests and receives STUN responses or sends indication messages; the terms STUN client and client are synonymous.
STUN Server: The entity that receives STUN requests and sends STUN responses or sends indication messages; the terms STUN server and server are synonymous.
Mapped Transport Address: The public transport address mapped through NAT and obtained by a client via STUN, identifying the client as recognized by another host on the public internet (usually a STUN server).
2. NAT Types
There are four types of NAT:
Full-Cone: All STUN requests from the same internal IP address and port can be mapped to the same external IP address and port, and any host outside the NAT can send packets to the mapped external IP and port of the host within the NAT.
Restricted-Cone: All STUN requests from the same internal IP address and port can be mapped to the same external IP address and port. Unlike a full cone, only when a host inside the NAT has previously sent packets to a host with IP address X can the host with IP address X send packets back to the internal host.
Port Restricted-Cone: Similar to restricted cone but includes the port number. A host on an external network with IP address X and port P must have been sent a packet from the internal host to the same IP address X and port P before it can send packets to the internal host.
Symmetric: All requests from the same internal IP and port to a specific destination IP and port are mapped to the same external IP and port. If the same host sends packets using the same source address and port number but to different destinations, NAT will use different mappings. Furthermore, only the external host that received those packets can send packets back to the internal host.
3. Operational Overview

STUN header

Figure 1 represents a typical STUN configuration where the STUN client connects to the private network NET1, which connects through NAT1 to the private network NET2, with NET2 connecting through NAT2 to the public network, and the STUN server deployed in the public network.
STUN is a simple client-server model protocol; the client sends requests to the server, and the server returns responses. There are two types of requests—Binding Request, sent via UDP, and Shared Secret Request, sent via TLS over TCP. The Shared Secret Request requires the server to return a temporary username and password for subsequent Binding Request and Binding Response to ensure authentication and message integrity. The Binding Request is used to determine the binding allocated by NAT. The client sends a Binding Request via UDP to the server, which retrieves the source IP address and port from which it was sent and copies them into the Binding Response to send back to the client. Some parameters in the Binding Request allow the client to request the server to send the Binding Response from different locations or using different IPs and ports. Some attributes provide message integrity and authentication.
These methods use STUN to discover the type of NAT and learn how to use the Binding. Typically, a STUN client is embedded within an application requiring a public IP address and port to receive data, such as an application wanting to receive RTP data via a public IP and port. When the application starts, the built-in STUN client sends a Shared Secret Request to the server to get a username and password, then sends a Binding Request. The STUN server can be discovered through DNS SRV records, assuming the client has already been configured with domains to search for a STUN server. Typically, this will be the domain of the service provider that the application uses (such providers are encouraged to deploy STUN servers to allow their customers to use their applications through NAT). Of course, the client can also determine the address or domain name of the STUN server through other means. STUN servers can even be embedded into endpoint systems.
A Binding Request is used to discover the presence of NAT and the public IP and port assigned by NAT. The Binding Request is transmitted via UDP to the server, and between the STUN client and server, the Binding Request may pass through one or more layers of NAT. The final result is that the source IP address and port of the request message received by the server are the closest public address and port of the NAT layer near the STUN server. The server then copies the mapped IP address and port into the Binding Response message and sends it to the client.
When the client receives the Binding Response, it compares the parsed IP address and port with its local IP address and port. If they do not match, it indicates the STUN client is behind one or more layers of NAT. This only shows that the STUN client is behind NAT and does not determine the type of NAT. To further identify the NAT type, the client sends a second Binding Request to a different IP address. If the IP address and port in the second Binding Response differ from those in the first Binding Response, the STUN client is behind a Symmetric NAT. To determine if it’s a Full-Cone NAT, the client can send a Binding Request requesting the server to send the Binding Response using a different IP and port. If the client can receive the response, it indicates a Full-Cone existence. Clients can also request the server to use the same IP address but a different port to send responses to determine if they are behind Port Restricted-Cone or Restricted-Cone NAT.

4. STUN Message Structure

All STUN messages start with a fixed STUN header, followed by STUN payload, which is a series of attribute values set based on different message types, detailed later. The STUN header contains the STUN message type, class, transaction ID, and length. The STUN message type indicates the type of binding request or indication request, detailed later; the class indicates whether the message is a request, a successful response, an error response, or an indication, etc. The transaction ID manages requests and responses, and the length is the length of the STUN payload, excluding the STUN header.
All STUN messages contain a 20-byte header, structured as follows:

STUN header

As shown in the image, the first two bytes of the STUN header must be 0, serving the purpose of distinguishing STUN protocol data from other protocols when STUN shares the same port with other protocols. The STUN Message Type defines the message class (request, successful response, failure response, or indication) and message method (the main function). Although there are four message classes, only two types of transactions exist in STUN: request/response transactions (comprising request messages and response messages) and indication transactions (consisting of a single indication message). The response classes are divided into error responses and successful responses to facilitate quick processing of STUN messages. The message type field is further structured as follows:

Here, the bits in the message type field are shown from the highest bit (M11) to the lowest bit (M0). M11 to M0 represent a 12-bit encoding method. C0 and C1 represent the two-bit class encoding: class=0x00 indicates a request, class=0x01 indicates an indication, class=0x10 indicates a successful response, and class=0x11 indicates an error response. The specification defines a method: Binding, which is orthogonal to the class. Therefore, for each method, there can be a request, a successful response, an error response, and an indication. For example, a binding request has class=0b00 (request) and method=0b000000000001 (Binding), encoded as the first 16 bits 0x0001. A binding response has class=0b10 (successful response) and method=0b000100000001, encoded as the first 16 bits 0x0101.
The Magic Cookie field must contain the fixed value 0x2112A442 in network byte order. In RFC3489, the field is part of the transaction ID. Placement of the Magic Cookie in this position allows servers to detect whether clients understand certain attributes added in this revised specification. Additionally, it aids in distinguishing STUN packets from packets of other protocols when STUN is multiplexed over the same port with other protocols.
The Transaction ID is a 96-bit identifier used to uniquely identify a STUN transaction. For request/response transactions, the Transaction ID is generated by the client and directly copied by the server, who returns it in the response message to the client. For indication transactions, it is chosen by the agent sending the indication. It mainly associates requests with responses, but it also guards against certain types of attacks. Servers use the Transaction ID as a key to uniquely identify each transaction among all clients. Therefore, the Transaction ID must be unified, ranging from the interval 0 to 2^96 – 1, and should be cryptographically random. Resending the same request reuses the same Transaction ID, but the client must choose a new Transaction ID for new transactions unless the new request is identical to a previous one and sent from the same transport address to the same IP address. Both successful and error responses must carry the same Transaction ID as their corresponding request. When agents serve as both STUN servers and clients on the same port, the Transaction IDs in requests sent and received by the agent are unrelated.
The Message Length is the length of the STUN message excluding the 20-byte STUN header, and because all STUN attributes are aligned to a multiple of 4 bytes, the last 2 bits of this field are always 0. This provides another method to distinguish STUN packets from packets of other protocols. There can be 0 or more attributes following the STUN message header.
5. Protocol Handling Process5.1 Constructing a STUN Request Transaction or Indication Transaction
When determining a request or indication message, the agent must follow the rules in Section 4 when creating the STUN header. Additionally, the message class must be “Request” or “Indication” as required. The method must be Binding or a method defined in another document. Then, add the required attributes for the method. If sending a request transaction message, the SOFTWARE attribute should be added, while for indication transaction messages, whether the SOFTWARE attribute is added depends on the message type. For Binding methods without authentication, no attributes are needed unless otherwise specified. STUN messages must adhere to size rules of UDP or TCP packets. All STUN messages sent over UDP should be smaller than the Maximum Transmission Unit (MTU), if known. If the MTU of the path is unknown, the message length should be less than 576 bytes for IPv4 [RFC1122] and 1280 bytes for IPv6 [RFC2460]. This value corresponds to the total size of an IP packet. Therefore, for IPv4, the actual STUN message must be less than 548 bytes (576 minus the 20-byte IP header and an 8-byte UDP header, assuming no IP options are used). STUN does not provide the ability to handle a situation where the request message length is less than the MTU value, but the response message is greater than the MTU. This limitation is not a problem for STUN; the MTU limitation is recommended to account for cases outside of when STUN itself is used to probe MTU characteristics. These MTU constraints must be followed in this or similar applications.
5.2 Sending a STUN Request Transaction or Indication Transaction5.2.1 UDP Sending a STUN Request Transaction or Indication Transaction
When running STUN on UDP, STUN messages may be discarded by the network. To avoid this issue, the client needs a retransmission mechanism for sending request transactions, but STUN indication transactions do not need retransmission, hence STUN indication transactions are unreliable. The client should retransmit the STUN request message at intervals of RTO (“Retransmission Timeout”), doubling the interval each time. RTO’s value is estimated based on RTT, and the initial value should be greater than or equal to 500ms. RTO’s value should be cached by the client after the transaction is completed and used as the initial RTO for the next transaction with the same server. This value is discarded after 10 minutes. Retransmission stops once a response is received or the maximum number of retransmissions (usually set to 7) is reached. If the final request is sent and no response is received within the RTO time, the client should consider the transaction as having failed. For example, assuming RTO is 500 ms, requests will be sent at 0 ms, 500 ms, 1500 ms, 3500 ms, 7500 ms, 15500 ms, and 31500 ms. If the client has not received a response by 39500 milliseconds, it will consider the transaction timed out.
5.2.2 TCP or TLS over TCP Sending a STUN Request Transaction or Indication Transaction
For TCP protocol and TLS-over-TCP protocol, the client establishes a TCP connection with the server first. In some usages of STUN, STUN is sent as the only protocol over the TCP connection. In such cases, it can be sent without additional framing or demultiplexing aid. The reliability of STUN over TCP and TLS-over-TCP is handled by TCP itself, and the STUN protocol layer has no retransmission. However, for request/response transactions, if the client does not receive a response within Ti seconds after sending SYN to establish a connection, the transaction is considered timed out. Ti defaults to 39.5 seconds, chosen to keep the default initial RTO for TCP and UDP equal. Furthermore, if the client fails to establish a TCP connection, or if the TCP connection is reset or fails before receiving a response, any ongoing request/response transaction is considered a failure. The client can send multiple transactions through a single TCP (or TLS- over-TCP) connection, and it can send another request without waiting for a response to a prior request. The client should keep the connection open and close the TCP connection if any of the following situations occur:
1. No subsequent STUN requests or indications are sent through that connection.
2. No other resources are sent over that connection.
3. If multiplexing other application protocols over that port, the application has completed its usage.
4. If communication connection with the peer is established using the mapped address.
5.3 Receiving STUN Messages
When a STUN agent receives a STUN message, it first checks whether the message conforms to the rules in Section 4. Checks if the first two bytes are 0, if the magic cookie field contains the correct value, if the message length is reasonable, and if the method is supported. Also checks whether the specific method is allowed with the message class. If the message class is “Success Response” or “Error Response,” the agent checks if the transaction ID matches any ongoing transactions. If the FINGERPRINT extension is applied, the agent checks whether a FINGERPRINT attribute exists and contains the correct value. Any detected errors will cause the message to be silently discarded. If STUN is multiplexed with another protocol, the error might indicate that this is not a genuine STUN message, in which case the agent should attempt to parse the message as the other protocol. STUN agents then perform whatever additional checks are required by the authentication mechanism for the current usage. After completing authentication checks, the STUN agent examines the message for any unknown attributes and known but unexpected attributes. Unknown understand-optional attributes must be ignored by the agent. Known but unexpected attributes should be ignored by the agent. Attributes understood as mandatory but unknown depend on the processing of the message class, detailed later.
5.3.1 Processing Requests
If a request contains one or more mandatory unknown attributes, the server will respond with an Error Response with an error code of 420 (Unknown Attribute), and include an unknown-attributes attribute in the response listing those unknown mandatory attributes. Further checks will be made. If all checks pass, the server generates a Success Response.
When operating over UDP, the received request may either be the initial Binding Request of a transaction or a retransmission of a Binding Request. The server must respond to retransmissions of the Binding Request in a manner that retains these attributes: If the client receives a response to a retransmission rather than to the first Binding Request sent, the overall client and server state must be the same as if only the first Binding Request response was received, or if both the response to the first Binding Request and a retransmitted request response were received, the client will use the first one. The simplest way to meet this requirement is for the server to remember all transaction IDs it receives via UDP and their corresponding responses for the last 40 seconds. However, this requires the server to maintain state and is impractical for unauthenticated requests. An alternative is to reprocess the request and recompute the response. This technique should only apply to idempotent requests (requests considered idempotent when the same request can be safely repeated without affecting the overall state of the system) and produce the same successful response for the same request. The Binding method is considered idempotent. Note that some rare network events may change the reflected transport address value, resulting in different mapped addresses in different successful responses. Launch extensions must discuss the effects of request retransmission on servers that do not store transaction state.

 

When constructing responses (Success or Error), the server follows the rules in Section 4. The method for the response is the same as that of the request and the message class is “Success response” or “Error response.” For error responses, the server must add an ERROR-CODE attribute containing the specified error code. The reason phrase is not fixed format but should describe the cause of the error as raised by the error code. Other attributes might also be added for some errors, spelled out in the description of the error code. For example, an error code of 420 (Unknown Attribute) requires the inclusion of an UNKNOWN-ATTRIBUTES attribute. Some authentication errors will also lead to the addition of attributes. If the server uses an authentication mechanism that authenticated the request, the server should add appropriate authentication attributes to the response. The server also adds any attributes needed for specific methods or usages. Additionally, the message should include a SOFTWARE attribute. For the Binding method, no further checks are needed unless otherwise specified. While forming successful responses, the server adds an XOR-MAPPED-ADDRESS attribute, whose contents are the mapped transport address of the public network or the local address of the intranet. For UDP, this is the source IP address and source UDP port of the request message. For TCP and TLS-over-TCP, this is the source IP address and source TCP port of the TCP connection as seen by the server.

Responses (Success or Error) are sent over the same transport that received the request. If the request was received via UDP, the target IP address and port for the response are the source IP address and port of the received request message. The source IP address and port of the response equal the target IP address and port of the received request message. If the request was received via TCP or TLS over TCP, the response is sent over the same TCP connection that received the request.
6. STUN Message Attributes

STUN message headers may contain 0 or more attributes, each of which must be TLV-encoded, consisting of a 16-bit Type, a 16-bit Length, and a variable value. Any attribute type can appear multiple times in a STUN message unless otherwise specified. The order of appearance matters: the receiver processes the first occurrence of each attribute and may ignore any duplicate ones. The structure is as follows:

To allow future revisions of this specification to add new attributes as needed, the attribute space is divided into two ranges. Attributes with type values between 0x0000 and 0x7FFF are mandatory-to-understand attributes; attributes with type values between 0x8000 and 0xFFFF are optional-to-understand attributes, meaning if a STUN agent does not understand these attributes, they can be ignored. The MESSAGE-INTEGRITY attribute must be the last attribute in a message. A known attribute but not appearing in a message must be ignored. For example, the MAPPED-ADDRESS attribute only appears in response messages; if it appears in a request message, the server should directly ignore the attribute. The table below shows which attributes should appear in which messages and which attributes are mandatory, optional, or conditional based on other elements in the message, with N/A indicating that the attribute cannot appear in the message.

M represents this attribute as mandatory, O represents it as optional, C stands for conditional, based on other aspects of the message, and N/A suggests this attribute cannot appear in the message.
In attributes, the Type value has the following:
MAPPED-ADDRESS
MAPPED-ADDRESS carries the source IP address and port of the Binding Request message in the Binding Response, which could be the intranet’s local IP and port or the public IP and port mapped by the NAT. The structure is as follows:

As shown above, the MAPPED-ADDRESS attribute represents the mapped transport address of the client. It comprises an 8-bit address family and a 16-bit port, followed by a fixed-length value representing the IP address. If the address family is IPv4, the address must be 32 bits. If the address family is IPv6, the address must be 128 bits. All fields must be ordered in network byte order. The first 8 bits of the mapped address must be set to 0 and must be ignored by the receiver, used for alignment purposes on natural 32-bit boundaries. The Family has these values:
0x01: IPv4
0x02: IPv6
This attribute is intended for servers to achieve backward compatibility with clients from RFC3489 [RFC3489].
XOR-MAPPED-ADDRESS
The XOR-MAPPED-ADDRESS attribute is similar to the MAPPED-ADDRESS attribute but stores the transport address through the XOR algorithm. The Family indicates the IP address family and encodes the same as the Family in MAPPED-ADDRESS attributes.
The X-Port is calculated by applying the XOR algorithm to the mapped address using the lower 16 bits of the magic cookie from the STUN header in host byte order, then stored in network byte order. If the IP address family is IPv4, X-Address is the mapped IP address in host byte order XORed with the magic cookie from the STUN header and stored in network byte order; if the IP address family is IPv6, X-Address is the mapped IP address in host byte order XORed with the magic cookie from the STUN header and the 96-bits of the Transaction ID, and then stored in network byte order.

Note:
XOR-MAPPED-ADDRESS and MAPPED-ADDRESS differ only in their encoding of the transport address.
RESPONSE-ADDRESS
RESPONSE-ADDRESS conveys an IP address and port in the Binding Request, instructing the server to send the response to that IP and port. This attribute is optional; if omitted in the request, the server sends the response to the source IP and port obtained from the request message. The structure type is similar to MAPPED-ADDRESS.
CHANGE-REQUEST
type=0x0003, the client uses the CHANGE-REQUEST attribute to request the server to use a different address and/or port for sending the response; the attribute is 32-bit and contains two flags. This attribute only appears in requests and helps determine if the client is behind Restricted-Cone NAT or Port Restricted-Cone NAT and is optional as follows:

Flag A: “change IP” flag; if true, requests the server to use a different IP address (keeping the port unchanged) when sending the binding response once a binding request is received.
Flag B: “change port” flag; if true, requests the server to use a different port (keeping the IP unchanged) when sending the binding response once a binding request is received.
CHANGED-ADDRESS
The Binding Response conveys an IP address and port indicating that the change-request attribute changes the IP and port where the response was sent. The structure is similar to MAPPED-ADDRESS.
type=0x0005, appears in Binding Response, notifying the client that the CHANGE-REQUEST attribute is effective.
SOURCE-ADDRESS

The attribute appears in Binding Response and indicates the server’s source IP address and port used for sending the binding response. The structure is similar to MAPPED-ADDRESS.
USERNAME and PASSWORD
USERNAME, type=0x0006, and PASSWORD in Shared Secret Response provide temporary username and password to the client for message integrity detection. USERNAME and PASSWORD frequently appear in Shared Secret Response messages and are optional in Shared Secret Binding. USERNAME is of variable length but must be a multiple of 4 bytes to ensure byte-boundary alignment.
MESSAGE-INTEGRITY

Performs integrity checks for request and response messages. The MESSAGE-INTEGRITY message contains the HMAC-SHA1 of the STUN message and can exist in any STUN message type. Using the SHA1 hash, HMAC occupies 20 bytes. The input text for the HMAC includes the STUN message, up to but not including the message-integrity attribute itself (excluding any attributes following the message-integrity attribute except for the Fingerprint attribute, which must be ignored when attributes follow the message-integrity attribute), and the text is padded to a multiple of 64 bytes. MESSAGE-INTEGRITY must be the last attribute in any STUN message. The key for HMAC depends on whether long-term or short-term credentials are used. For long-term credentials, the key is 16 bytes, calculated as:
key = MD5(username “:” realm “:” SASLprep(password))
In other words, the 16-byte key is derived by calculating an MD5 hash from concatenating these five fields:
(1) Username obtained from the username attribute with any quoting and trailing spaces removed (SASLprep applied);
(2) Colon;
(3) Realm with any quoting and trailing spaces removed;
(4) Colon;
(5) Password with any spaces removed and SASLprep applied.
For example, if the username is “user,” realm is “realm,” and password is “pass,” the HMAC key will be the MD5 hash of the string “user:realm:pass,” resulting in a hash of 0x8493fbc53ba582fb4c044c456bdc40eb.
For short-term credentials, the key is 16 bytes, calculated as:
key = SASLprep(password) (where SASLprep() is defined in RFC4013[RFC4013])
Based on these rules, the length field in the STUN message header must be included when performing the message integrity hash. The length must be set to the message’s length up to and including the message integrity attribute itself before executing the hash, excluding any attributes past the message integrity attribute. The value of the message integrity attribute is filled in after the calculation, and the header length is set to include the entire message. Similarly, when validating the message integrity, the length field should be adjusted to point to the end of the message integrity attribute before calculating the HMAC. When message integrity and attributes occur behind the fingerprint, such adjustments are necessary.
FINGERPRINT
The FINGERPRINT attribute may appear in all STUN messages. The attribute value is calculated from the start of the STUN message up to (but not including) the FINGERPRINT attribute itself, XORed with the 32-bit value 0x5354554e. The FINGERPRINT attribute aids in differentiating STUN packets from packets of other protocols.
Like the MESSAGE-INTEGRITY attribute, the CRC used in the FINGERPRINT attribute covers the length field of the STUN header, so this value must be correct, including the CRC attribute as part of the message length when computing CRC. When using the FINGERPRINT attribute, the attribute should first be placed in the message with a pseudo-value, then calculate the CRC, and update the attribute value. If the MESSAGE-INTEGRITY attribute also exists, the correct message integrity value must be present before calculating the CRC, as CRC is completed over the message integrity attribute.
ERROR-CODE
ERROR-CODE, an attribute in Binding Error Response and Shared Secret Error Response, indicates errors in STUN requests. It comprises a value range between 100 to 699 with a UTF-8 encoded textual reason phrase, consistent in code allocation and semantics with SIP[10] and HTTP[15]. The reason phrase is for user use and can be anything appropriate for the response code. The length of the reason phrase must be a multiple of 4 bytes (in bytes); spaces can be appended if necessary. The recommended reason phrases for defined response codes are listed below:

Class represents the hundreds digit of the response code, ranging from 1 to 6. The Number represents the remainder of the response code modulo 100, with a value between 0 and 99. Response codes and their recommended reason phrases (in parentheses) are defined below:
400 (Bad request): Incorrect request format
401 (Unauthorized): Binding Request lacks a MESSAGE-INTEGRITY attribute
420 (Unknown Attribute): The server does not understand a mandatory attribute in the request
430 (Stale Credentials): Binding Request contains a MESSAGE-INTEGRITY attribute but uses an expired shared secret; the client should obtain a new shared secret and retry.
431 (Integrity Check Failure): Binding Request contains a MESSAGE-INTEGRITY attribute, but HMAC validation failed; this may indicate a possible attack or a client implementation error.
432 (Missing Username): Binding Request contains a MESSAGE-INTEGRITY attribute without a USERNAME attribute; both must be present for integrity checks
433 (Use TLS): Shared secret requests must be sent through TLS and were not received through TLS
500 (Server Error): The server encountered a temporary error; the client should retry.
600 (Global Failure): The server refuses to satisfy the request; the client should not retry.
REALM
The realm attribute may appear in requests and responses, containing text conforming to the “realm value” syntax described in RFC3261 [RFC3261], but without double quotes or surrounding spaces; a realm value without quotes. It must be a UTF-8 [RFC3629] encoded sequence, fewer than 128 characters (up to 763 bytes in length), and must be processed with SASLPrep [RFC4013].
The presence of a REALM attribute in a request indicates that long-term credentials are used for authentication and appears in certain error responses to indicate that the server desires authentication using long-term credentials from the client.
SOFTWARE
The SOFTWARE attribute contains a textual description of the software used to send the message, used by both clients and servers. The value should include the manufacturer and version number. This attribute does not impact protocol operations and is used solely as a diagnostic and debugging tool. SOFTWARE’s value is of variable length; it must be a UTF-8 [RFC3629] encoded sequence of fewer than 128 characters (up to 763 bytes in length).
UNKNOWN-ATTRIBUTES

UNKNOWN-ATTRIBUTES only appear when the error code is 420 in a Binding Error Response or Shared Secret Error Response, indicating the unknown mandatory attributes in the request. The attribute contains a list of 16-bit values, each representing an attribute type unrecognized by the server. If the number of unknown attributes is odd, one attribute must be repeated in the list so that the total length of the list is a multiple of 4 bytes, structured as follows:

REFLECTED-FROM
Appears only in the Binding Response when the RESPONSE-ADDRESS attribute is present in the Binding Request. This attribute contains the identity (based on IP address) of the source from which the request was received. Its purpose is to provide traceability, preventing STUN servers from being used in denial of service attacks.

Published by: Full-Stack Programmer Zhang Long, please indicate the source when reprinting: https://javaforall.cn/160525.html Original link: https://javaforall.cn

ipv6tcp/ipnatNAT GatewayProgramming Algorithm