12. Backwards Compatibility with RFC 3489 (Compatibilité descendante avec RFC 3489)

Cette section définit des procédures qui permettent un certain degré de compatibilité descendante avec le protocole original défini dans RFC 3489 [RFC3489]. Ce mécanisme est optionnel et n'est utilisé que dans les cas où un nouveau client peut se connecter à un ancien serveur ou vice versa. Une utilisation doit (must) définir si et quand cette procédure est utilisée.

La Section 19 répertorie tous les changements entre cette spécification et RFC 3489 [RFC3489]. Cependant, toutes ces différences ne sont pas importantes, car le "STUN classique" n'était utilisé que de quelques manières spécifiques. Aux fins de cette extension, les changements importants sont les suivants. Dans RFC 3489 :

• UDP était le seul transport supporté.

• Le champ qui est maintenant le champ magic cookie faisait partie du champ d'ID de transaction, rendant l'ID de transaction long de 128 bits.

• L'attribut XOR-MAPPED-ADDRESS n'existait pas, et la méthode Binding utilisait l'attribut MAPPED-ADDRESS à la place.

• Il y avait trois attributs à compréhension obligatoire, RESPONSE-ADDRESS, CHANGE-REQUEST et CHANGED-ADDRESS, qui ont été supprimés de cette spécification.

  • CHANGE-REQUEST et CHANGED-ADDRESS font maintenant partie de l'utilisation NAT Behavior Discovery [BEHAVE-NAT], et l'autre a été déprécié.

12.1. Changes to Client Processing (Modifications du traitement client)

Un client qui souhaite interopérer avec un serveur [RFC3489] devrait (SHOULD) envoyer un message de requête au serveur qui utilise la méthode Binding, ne contient pas d'attributs, et utilise UDP comme protocole de transport. La réponse de succès reçue du serveur contiendra, si elle réussit, un attribut MAPPED-ADDRESS plutôt qu'un attribut XOR-MAPPED-ADDRESS. Un client cherchant à interopérer avec un serveur plus ancien doit (MUST) être préparé à recevoir l'un ou l'autre. De plus, le client doit (MUST) ignorer tous les attributs à compréhension obligatoire réservés qui peuvent apparaître dans la réponse. Parmi les attributs réservés de la Section 18.2, 0x0002, 0x0004, 0x0005 et 0x000B peuvent apparaître dans les réponses Binding d'un serveur conforme à RFC 3489. Mis à part ce changement, le traitement de la réponse est identique aux procédures décrites dans cette spécification.

12.2. Changes to Server Processing (Modifications du traitement serveur)

Un serveur STUN peut détecter quand un message de requête Binding donné a été envoyé depuis un client RFC 3489 [RFC3489] par l'absence de la valeur correcte dans le champ magic cookie. Lorsque le serveur détecte un client RFC 3489, il devrait (SHOULD) copier la valeur vue dans le champ magic cookie dans la requête Binding vers le champ magic cookie dans le message de réponse Binding, et insérer un attribut MAPPED-ADDRESS au lieu d'un attribut XOR-MAPPED-ADDRESS.

Un client peut, dans de rares situations, inclure soit un attribut RESPONSE-ADDRESS soit un attribut CHANGE-REQUEST. Dans ces situations, le serveur considérera ces attributs comme des attributs à compréhension obligatoire inconnus et répondra avec une réponse d'erreur. Étant donné que les mécanismes utilisant ces attributs ne sont plus pris en charge, ce comportement est acceptable.

La version RFC 3489 de STUN manque à la fois du magic cookie et de l'attribut FINGERPRINT qui permettent une très haute probabilité d'identifier correctement les messages STUN lorsqu'ils sont multiplexés avec d'autres protocoles. Par conséquent, les implémentations STUN qui sont compatibles en arrière avec RFC 3489 ne devraient pas (SHOULD NOT) être utilisées dans les cas où STUN sera multiplexé avec un autre protocole. Cependant, cela ne devrait pas être un problème car un tel multiplexage n'était pas disponible dans RFC 3489.