2. Evolution from RFC 3489 (Évolution depuis RFC 3489)
STUN a été initialement défini dans RFC 3489 [RFC3489]. Cette spécification, parfois appelée "STUN classique (classic STUN)", se présentait comme une solution complète au problème de traversée NAT. Dans cette solution, un client découvrait s'il était derrière un NAT, déterminait son type de NAT, découvrait son adresse IP et son port du côté public du NAT le plus externe, puis utilisait cette adresse IP et ce port dans le corps de protocoles, tels que le Session Initiation Protocol (SIP) [RFC3261]. Cependant, l'expérience depuis la publication de RFC 3489 a révélé que le STUN classique ne fonctionne tout simplement pas suffisamment bien pour être une solution déployable. L'adresse et le port appris via le STUN classique sont parfois utilisables pour les communications avec un pair, et parfois non. Le STUN classique ne fournissait aucun moyen de découvrir s'il fonctionnerait ou non en réalité, et il ne fournissait aucun remède dans les cas où il ne fonctionnait pas. De plus, l'algorithme du STUN classique pour la classification des types de NAT s'est révélé défectueux, car de nombreux NAT ne correspondaient pas clairement aux types définis.
Le STUN classique présentait également une vulnérabilité de sécurité : les attaquants pouvaient fournir au client des adresses mappées incorrectes sous certaines topologies et contraintes, et cela n'était fondamentalement pas résoluble par des moyens cryptographiques. Bien que ce problème subsiste avec cette spécification, ces attaques sont maintenant atténuées grâce à l'utilisation de solutions plus complètes qui utilisent STUN.
Pour ces raisons, cette spécification rend obsolète RFC 3489 et décrit plutôt STUN comme un outil utilisé dans le cadre d'une solution complète de traversée NAT. ICE [MMUSIC-ICE] est une solution complète de traversée NAT pour les protocoles basés sur la méthodologie offre/réponse (offer/answer) [RFC3264], tels que SIP. SIP Outbound [SIP-OUTBOUND] est une solution complète pour la traversée de la signalisation SIP, et elle utilise STUN d'une manière très différente. Bien qu'il soit possible qu'un protocole puisse utiliser STUN seul (STUN classique) comme solution de traversée, une telle utilisation n'est pas décrite ici et est fortement déconseillée pour les raisons décrites ci-dessus.
Le protocole sur le fil (on-the-wire protocol) décrit ici n'a été que légèrement modifié par rapport au STUN classique. Le protocole fonctionne maintenant sur TCP en plus de UDP. L'extensibilité a été ajoutée au protocole de manière plus structurée. Un mécanisme de cookie magique (magic cookie) pour démultiplexer STUN avec les protocoles d'application a été ajouté en « volant » 32 bits de l'ID de transaction (transaction ID) de 128 bits défini dans RFC 3489, permettant à la modification d'être rétrocompatible. Les adresses mappées sont encodées en utilisant un nouveau format OU exclusif (exclusive-or). Il existe d'autres changements plus mineurs. Voir la Section 19 pour une liste plus complète.
En raison du changement de portée, STUN a également été renommé de "Simple Traversal of UDP through NAT" à "Session Traversal Utilities for NAT". L'acronyme reste STUN, qui est tout ce dont tout le monde se souvient de toute façon.