6. STUN Message Structure (STUN-Nachrichtenstruktur)
STUN-Nachrichten werden binär unter Verwendung eines netzwerkorientierten Formats kodiert (höchstwertiges Byte oder Oktett zuerst, auch allgemein als Big-Endian bekannt). Die Übertragungsreihenfolge wird detailliert in Anhang B von RFC 791 [RFC0791] beschrieben. Sofern nicht anders angegeben, sind numerische Konstanten dezimal (Basis 10).
Alle STUN-Nachrichten müssen (MUST) mit einem 20-Byte-Header beginnen, gefolgt von null oder mehr Attributen (Attributes). Der STUN-Header enthält einen STUN-Nachrichtentyp, ein Magic Cookie, eine Transaktions-ID (transaction ID) und die Nachrichtenlänge.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0| STUN Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transaction ID (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Abbildung 2: Format des STUN-Nachrichtenheaders
Die 2 höchstwertigen Bits jeder STUN-Nachricht müssen (MUST) Nullen sein. Dies kann verwendet werden, um STUN-Pakete von anderen Protokollen zu unterscheiden, wenn STUN mit anderen Protokollen auf demselben Port gemultiplext wird.
Der Nachrichtentyp (message type) definiert die Nachrichtenklasse (request, success response, failure response oder indication) und die Nachrichtenmethode (message method) (Hauptfunktion) der STUN-Nachricht. Obwohl es vier Nachrichtenklassen gibt, gibt es in STUN nur zwei Arten von Transaktionen: Anfrage/Antwort-Transaktionen (request/response transactions) (die aus einer Anfragenachricht und einer Antwortnachricht bestehen) und Anzeige-Transaktionen (indication transactions) (die aus einer einzelnen Anzeigemeldung bestehen). Die Antwortklassen sind in Fehlerantworten und Erfolgsantworten aufgeteilt, um die schnelle Verarbeitung der STUN-Nachricht zu unterstützen.
Das Nachrichtentypfeld wird weiter in die folgende Struktur unterteilt:
0 1
2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
|M |M |M|M|M|C|M|M|M|C|M|M|M|M|
|11|10|9|8|7|1|6|5|4|0|3|2|1|0|
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
Abbildung 3: Format des STUN-Nachrichtentypfelds
Hier werden die Bits im Nachrichtentypfeld vom höchstwertigen (M11) bis zum niedrigstwertigen (M0) angezeigt. M11 bis M0 repräsentieren eine 12-Bit-Kodierung der Methode. C1 und C0 repräsentieren eine 2-Bit-Kodierung der Klasse. Eine Klasse von 0b00 ist eine Anfrage (request), eine Klasse von 0b01 ist eine Anzeige (indication), eine Klasse von 0b10 ist eine Erfolgsantwort (success response) und eine Klasse von 0b11 ist eine Fehlerantwort (error response). Diese Spezifikation definiert eine einzelne Methode, Binding. Die Methode und die Klasse sind orthogonal, so dass für jede Methode eine Anfrage, Erfolgsantwort, Fehlerantwort und Anzeige für diese Methode möglich sind. Erweiterungen, die neue Methoden definieren, müssen (MUST) angeben, welche Klassen für diese Methode zulässig sind.
Zum Beispiel hat eine Binding-Anfrage (Binding request) class=0b00 (request) und method=0b000000000001 (Binding) und wird in die ersten 16 Bits als 0x0001 kodiert. Eine Binding-Antwort (Binding response) hat class=0b10 (success response) und method=0b000000000001 und wird in die ersten 16 Bits als 0x0101 kodiert.
Das Magic-Cookie-Feld muss (MUST) den festen Wert 0x2112A442 in Netzwerk-Byte-Reihenfolge enthalten. In RFC 3489 [RFC3489] war dieses Feld Teil der Transaktions-ID; das Platzieren des Magic Cookie an dieser Stelle ermöglicht es einem Server zu erkennen, ob der Client bestimmte Attribute verstehen wird, die in dieser überarbeiteten Spezifikation hinzugefügt wurden. Darüber hinaus hilft es, STUN-Pakete von Paketen anderer Protokolle zu unterscheiden, wenn STUN mit diesen anderen Protokollen auf demselben Port gemultiplext wird.
Die Transaktions-ID (transaction ID) ist eine 96-Bit-Kennung, die zur eindeutigen Identifizierung von STUN-Transaktionen verwendet wird. Bei Anfrage/Antwort-Transaktionen wird die Transaktions-ID vom STUN-Client für die Anfrage gewählt und vom Server in der Antwort zurückgegeben. Bei Anzeigen wird sie vom sendenden Agent gewählt. Sie dient hauptsächlich dazu, Anfragen mit Antworten zu korrelieren, spielt aber auch eine kleine Rolle bei der Verhinderung bestimmter Arten von Angriffen. Der Server verwendet die Transaktions-ID auch als Schlüssel, um jede Transaktion über alle Clients hinweg eindeutig zu identifizieren. Daher muss (MUST) die Transaktions-ID gleichmäßig und zufällig aus dem Intervall 0 .. 2**96-1 gewählt werden und sollte (SHOULD) kryptographisch zufällig sein. Wiederübertragungen derselben Anfrage verwenden dieselbe Transaktions-ID wieder, aber der Client muss (MUST) eine neue Transaktions-ID für neue Transaktionen wählen, es sei denn, die neue Anfrage ist bitweise identisch mit der vorherigen Anfrage und wird von derselben Transportadresse an dieselbe IP-Adresse gesendet. Erfolgs- und Fehlerantworten müssen (MUST) dieselbe Transaktions-ID wie ihre entsprechende Anfrage tragen. Wenn ein Agent auf demselben Port als STUN-Server und STUN-Client fungiert, hat die Transaktions-ID in Anfragen, die der Agent sendet, keine Beziehung zur Transaktions-ID in Anfragen, die er empfängt.
Die Nachrichtenlänge (message length) muss (MUST) die Größe der Nachricht in Bytes enthalten, ohne den 20-Byte-STUN-Header. Da alle STUN-Attribute auf ein Vielfaches von 4 Bytes aufgefüllt werden, sind die letzten 2 Bits dieses Feldes immer Null. Dies bietet eine weitere Möglichkeit, STUN-Pakete von Paketen anderer Protokolle zu unterscheiden.
Nach dem festen STUN-Header folgen null oder mehr Attribute. Jedes Attribut ist TLV (Type-Length-Value) kodiert. Die Details der Kodierung und die Attribute selbst werden in Abschnitt 15 angegeben.