Skip to main content

12. Backwards Compatibility with RFC 3489

This section defines procedures that allow for a degree of backwards compatibility with the original protocol defined in RFC 3489 [RFC3489]. This mechanism is optional and is only used in cases where a new client can connect to an old server or vice versa. A usage must define if and when this procedure is used.

Section 19 lists all of the changes between this specification and RFC 3489 [RFC3489]. However, not all of these differences are important, since "classic STUN" was only used in a few specific ways. For the purposes of this extension, the important changes are as follows. In RFC 3489:

  • UDP was the only supported transport.

  • The field that is now the magic cookie field was part of the transaction ID field, making the transaction ID 128 bits long.

  • The XOR-MAPPED-ADDRESS attribute did not exist, and the Binding method used the MAPPED-ADDRESS attribute instead.

  • There were three comprehension-required attributes, RESPONSE-ADDRESS, CHANGE-REQUEST, and CHANGED-ADDRESS, that have been removed from this specification.

    • CHANGE-REQUEST and CHANGED-ADDRESS are now part of the NAT Behavior Discovery usage [BEHAVE-NAT], and the other has been deprecated.

12.1. Changes to Client Processing​

A client that wishes to interoperate with an [RFC3489] server SHOULD send a request message to the server that uses the Binding method, contains no attributes, and uses UDP as the transport protocol. The successful response received from the server will, if successful, contain a MAPPED-ADDRESS attribute rather than an XOR-MAPPED-ADDRESS attribute. A client seeking to interoperate with an older server MUST be prepared to receive either. Furthermore, the client MUST ignore any reserved comprehension-required attributes that may appear in the response. Of the reserved attributes in Section 18.2, 0x0002, 0x0004, 0x0005, and 0x000B may appear in Binding responses from a server compliant to RFC 3489. Aside from this change, the processing of the response is identical to the procedures described in this specification.

12.2. Changes to Server Processing​

A STUN server can detect when a given Binding request message was sent from an RFC 3489 [RFC3489] client by the absence of the correct value in the magic cookie field. When the server detects an RFC 3489 client, it SHOULD copy the value seen in the magic cookie field in the Binding request to the magic cookie field in the Binding response message, and insert a MAPPED-ADDRESS attribute instead of an XOR-MAPPED-ADDRESS attribute.

A client may, in rare situations, include either a RESPONSE-ADDRESS or CHANGE-REQUEST attribute. In these situations, the server will view these as unknown comprehension-required attributes and reply with an error response. Since the mechanisms utilizing these attributes are no longer supported, this behavior is acceptable.

The RFC 3489 version of STUN lacks both the magic cookie and the FINGERPRINT attribute that allow for a very high probability of correctly identifying STUN messages when they are multiplexed with other protocols. Therefore, STUN implementations that are backwards compatible with RFC 3489 SHOULD NOT be used in cases where STUN will be multiplexed with another protocol. However, this should not be an issue as such multiplexing was not available in RFC 3489.

Last updated on