12. Backwards Compatibility with RFC 3489 (Rückwärtskompatibilität mit RFC 3489)

Dieser Abschnitt definiert Verfahren, die einen gewissen Grad an Rückwärtskompatibilität mit dem ursprünglichen in RFC 3489 [RFC3489] definierten Protokoll ermöglichen. Dieser Mechanismus ist optional und wird nur in Fällen verwendet, in denen ein neuer Client eine Verbindung zu einem alten Server herstellen kann oder umgekehrt. Eine Verwendung muss (must) definieren, ob und wann dieses Verfahren verwendet wird.

Abschnitt 19 listet alle Änderungen zwischen dieser Spezifikation und RFC 3489 [RFC3489] auf. Allerdings sind nicht alle diese Unterschiede wichtig, da "klassisches STUN" nur auf wenige spezifische Arten verwendet wurde. Für die Zwecke dieser Erweiterung sind die wichtigen Änderungen wie folgt. In RFC 3489:

• UDP war der einzige unterstützte Transport.

• Das Feld, das jetzt das Magic-Cookie-Feld ist, war Teil des Transaktions-ID-Felds, wodurch die Transaktions-ID 128 Bit lang war.

• Das XOR-MAPPED-ADDRESS-Attribut existierte nicht, und die Binding-Methode verwendete stattdessen das MAPPED-ADDRESS-Attribut.

• Es gab drei verständnispflichtige Attribute, RESPONSE-ADDRESS, CHANGE-REQUEST und CHANGED-ADDRESS, die aus dieser Spezifikation entfernt wurden.

  • CHANGE-REQUEST und CHANGED-ADDRESS sind jetzt Teil der NAT Behavior Discovery-Verwendung [BEHAVE-NAT], und das andere wurde veraltet.

12.1. Changes to Client Processing (Änderungen in der Client-Verarbeitung)

Ein Client, der mit einem [RFC3489]-Server interoperieren möchte, sollte (SHOULD) eine Anforderungsnachricht an den Server senden, die die Binding-Methode verwendet, keine Attribute enthält und UDP als Transportprotokoll verwendet. Die vom Server empfangene Erfolgsantwort wird, wenn erfolgreich, ein MAPPED-ADDRESS-Attribut anstelle eines XOR-MAPPED-ADDRESS-Attributs enthalten. Ein Client, der mit einem älteren Server interoperieren möchte, muss (MUST) darauf vorbereitet sein, eines von beiden zu empfangen. Darüber hinaus muss (MUST) der Client alle reservierten verständnispflichtigen Attribute ignorieren, die in der Antwort erscheinen können. Von den reservierten Attributen in Abschnitt 18.2 können 0x0002, 0x0004, 0x0005 und 0x000B in Binding-Antworten von einem RFC 3489-konformen Server erscheinen. Abgesehen von dieser Änderung ist die Verarbeitung der Antwort identisch mit den in dieser Spezifikation beschriebenen Verfahren.

12.2. Changes to Server Processing (Änderungen in der Server-Verarbeitung)

Ein STUN-Server kann durch das Fehlen des korrekten Werts im Magic-Cookie-Feld erkennen, wenn eine gegebene Binding-Anforderungsnachricht von einem RFC 3489 [RFC3489]-Client gesendet wurde. Wenn der Server einen RFC 3489-Client erkennt, sollte (SHOULD) er den im Magic-Cookie-Feld in der Binding-Anforderung gesehenen Wert in das Magic-Cookie-Feld in der Binding-Antwortnachricht kopieren und ein MAPPED-ADDRESS-Attribut anstelle eines XOR-MAPPED-ADDRESS-Attributs einfügen.

Ein Client kann in seltenen Situationen entweder ein RESPONSE-ADDRESS- oder ein CHANGE-REQUEST-Attribut einschließen. In diesen Situationen betrachtet der Server diese als unbekannte verständnispflichtige Attribute und antwortet mit einer Fehlerantwort. Da die Mechanismen, die diese Attribute verwenden, nicht mehr unterstützt werden, ist dieses Verhalten akzeptabel.

Die RFC 3489-Version von STUN fehlt sowohl das Magic Cookie als auch das FINGERPRINT-Attribut, die eine sehr hohe Wahrscheinlichkeit ermöglichen, STUN-Nachrichten korrekt zu identifizieren, wenn sie mit anderen Protokollen multiplexiert werden. Daher sollten (SHOULD NOT) STUN-Implementierungen, die rückwärtskompatibel mit RFC 3489 sind, nicht in Fällen verwendet werden, in denen STUN mit einem anderen Protokoll multiplexiert wird. Dies sollte jedoch kein Problem darstellen, da eine solche Multiplexierung in RFC 3489 nicht verfügbar war.