2. Evolution from RFC 3489 (Entwicklung seit RFC 3489)

STUN wurde ursprünglich in RFC 3489 [RFC3489] definiert. Diese Spezifikation, manchmal als "klassisches STUN (classic STUN)" bezeichnet, stellte sich als vollständige Lösung für das NAT-Durchquerungsproblem dar. In dieser Lösung würde ein Client entdecken, ob er sich hinter einem NAT befindet, seinen NAT-Typ bestimmen, seine IP-Adresse und seinen Port auf der öffentlichen Seite des äußersten NAT entdecken und dann diese IP-Adresse und diesen Port im Körper von Protokollen wie dem Session Initiation Protocol (SIP) [RFC3261] verwenden. Die Erfahrung seit der Veröffentlichung von RFC 3489 hat jedoch gezeigt, dass klassisches STUN einfach nicht ausreichend gut funktioniert, um eine einsetzbare Lösung zu sein. Die über klassisches STUN gelernte Adresse und der Port sind manchmal für die Kommunikation mit einem Peer verwendbar und manchmal nicht. Klassisches STUN bot keine Möglichkeit zu entdecken, ob es tatsächlich funktionieren würde oder nicht, und es bot keine Abhilfe in Fällen, in denen es nicht funktionierte. Darüber hinaus erwies sich der Algorithmus des klassischen STUN zur Klassifizierung von NAT-Typen als fehlerhaft, da viele NATs nicht sauber in die dort definierten Typen passten.

Klassisches STUN hatte auch eine Sicherheitslücke: Angreifer konnten dem Client unter bestimmten Topologien und Einschränkungen falsche gemappte Adressen bereitstellen, und dies war grundsätzlich nicht durch kryptografische Mittel lösbar. Obwohl dieses Problem mit dieser Spezifikation bestehen bleibt, werden diese Angriffe jetzt durch die Verwendung vollständigerer Lösungen, die STUN nutzen, abgemildert.

Aus diesen Gründen ersetzt diese Spezifikation RFC 3489 und beschreibt stattdessen STUN als ein Werkzeug, das als Teil einer vollständigen NAT-Durchquerungslösung verwendet wird. ICE [MMUSIC-ICE] ist eine vollständige NAT-Durchquerungslösung für Protokolle, die auf der Angebot/Antwort-Methodik (offer/answer) [RFC3264] basieren, wie z.B. SIP. SIP Outbound [SIP-OUTBOUND] ist eine vollständige Lösung für die Durchquerung von SIP-Signalisierung und verwendet STUN auf sehr unterschiedliche Weise. Obwohl es möglich ist, dass ein Protokoll STUN allein (klassisches STUN) als Durchquerungslösung verwenden kann, wird eine solche Verwendung hier nicht beschrieben und aus den oben genannten Gründen nachdrücklich abgeraten.

Das hier beschriebene Leitungsprotokoll (on-the-wire protocol) wurde gegenüber klassischem STUN nur geringfügig geändert. Das Protokoll läuft jetzt zusätzlich zu UDP auch über TCP. Die Erweiterbarkeit wurde dem Protokoll auf strukturiertere Weise hinzugefügt. Ein Magic-Cookie-Mechanismus (magic cookie) zum Demultiplexen von STUN mit Anwendungsprotokollen wurde hinzugefügt, indem 32 Bits von der in RFC 3489 definierten 128-Bit-Transaktions-ID (transaction ID) „gestohlen" wurden, wodurch die Änderung rückwärtskompatibel wurde. Gemappte Adressen werden unter Verwendung eines neuen Exklusiv-ODER-Formats (exclusive-or) codiert. Es gibt weitere, kleinere Änderungen. Siehe Abschnitt 19 für eine vollständigere Auflistung.

Aufgrund der Änderung des Umfangs wurde STUN auch von "Simple Traversal of UDP through NAT" in "Session Traversal Utilities for NAT" umbenannt. Das Akronym bleibt STUN, was ohnehin alles ist, woran sich jeder erinnert.