6. STUN Message Structure (Struttura dei messaggi STUN)
I messaggi STUN sono codificati in binario utilizzando un formato orientato alla rete (byte o ottetto più significativo per primo, comunemente noto anche come big-endian). L'ordine di trasmissione è descritto in dettaglio nell'Appendice B di RFC 791 [RFC0791]. Salvo diversa indicazione, le costanti numeriche sono in decimale (base 10).
Tutti i messaggi STUN devono (MUST) iniziare con un'intestazione di 20 byte seguita da zero o più attributi (Attributes). L'intestazione STUN contiene un tipo di messaggio STUN, un cookie magico (magic cookie), un ID di transazione (transaction ID) e la lunghezza del messaggio.
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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 2: Formato dell'intestazione del messaggio STUN
I 2 bit più significativi di ogni messaggio STUN devono (MUST) essere zeri. Questo può essere utilizzato per differenziare i pacchetti STUN da altri protocolli quando STUN è multiplexato con altri protocolli sulla stessa porta.
Il tipo di messaggio (message type) definisce la classe di messaggio (request, success response, failure response o indication) e il metodo di messaggio (message method) (funzione principale) del messaggio STUN. Sebbene ci siano quattro classi di messaggi, ci sono solo due tipi di transazioni in STUN: transazioni richiesta/risposta (request/response transactions) (che consistono in un messaggio di richiesta e un messaggio di risposta) e transazioni di indicazione (indication transactions) (che consistono in un singolo messaggio di indicazione). Le classi di risposta sono divise in risposte di errore e risposte di successo per facilitare l'elaborazione rapida del messaggio STUN.
Il campo del tipo di messaggio è ulteriormente suddiviso nella seguente struttura:
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|
+--+--+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 3: Formato del campo tipo di messaggio STUN
Qui i bit nel campo del tipo di messaggio sono mostrati dal più significativo (M11) al meno significativo (M0). M11 attraverso M0 rappresentano una codifica a 12 bit del metodo. C1 e C0 rappresentano una codifica a 2 bit della classe. Una classe di 0b00 è una richiesta (request), una classe di 0b01 è un'indicazione (indication), una classe di 0b10 è una risposta di successo (success response) e una classe di 0b11 è una risposta di errore (error response). Questa specifica definisce un singolo metodo, Binding. Il metodo e la classe sono ortogonali, in modo che per ogni metodo siano possibili una richiesta, una risposta di successo, una risposta di errore e un'indicazione per quel metodo. Le estensioni che definiscono nuovi metodi devono (MUST) indicare quali classi sono consentite per quel metodo.
Ad esempio, una richiesta di binding (Binding request) ha class=0b00 (request) e method=0b000000000001 (Binding) ed è codificata nei primi 16 bit come 0x0001. Una risposta di binding (Binding response) ha class=0b10 (success response) e method=0b000000000001, ed è codificata nei primi 16 bit come 0x0101.
Il campo cookie magico deve (MUST) contenere il valore fisso 0x2112A442 in ordine di byte di rete. In RFC 3489 [RFC3489], questo campo faceva parte dell'ID di transazione; posizionare il cookie magico in questa posizione consente a un server di rilevare se il client comprenderà determinati attributi che sono stati aggiunti in questa specifica rivista. Inoltre, aiuta a distinguere i pacchetti STUN dai pacchetti di altri protocolli quando STUN è multiplexato con quegli altri protocolli sulla stessa porta.
L'ID di transazione (transaction ID) è un identificatore a 96 bit, utilizzato per identificare univocamente le transazioni STUN. Per le transazioni richiesta/risposta, l'ID di transazione è scelto dal client STUN per la richiesta ed echeggiato dal server nella risposta. Per le indicazioni, è scelto dall'agente che invia l'indicazione. Serve principalmente a correlare le richieste con le risposte, anche se svolge anche un piccolo ruolo nell'aiutare a prevenire determinati tipi di attacchi. Il server utilizza anche l'ID di transazione come chiave per identificare ogni transazione in modo univoco tra tutti i client. Pertanto, l'ID di transazione deve (MUST) essere scelto uniformemente e casualmente dall'intervallo 0 .. 2**96-1, e dovrebbe (SHOULD) essere crittograficamente casuale. Le ritrasmissioni della stessa richiesta riutilizzano lo stesso ID di transazione, ma il client deve (MUST) scegliere un nuovo ID di transazione per nuove transazioni a meno che la nuova richiesta non sia identica bit per bit alla richiesta precedente e inviata dallo stesso indirizzo di trasporto allo stesso indirizzo IP. Le risposte di successo ed errore devono (MUST) portare lo stesso ID di transazione della loro richiesta corrispondente. Quando un agente agisce come server STUN e client STUN sulla stessa porta, l'ID di transazione nelle richieste che l'agente invia non ha alcuna relazione con l'ID di transazione nelle richieste che riceve.
La lunghezza del messaggio (message length) deve (MUST) contenere la dimensione, in byte, del messaggio senza includere l'intestazione STUN di 20 byte. Poiché tutti gli attributi STUN sono riempiti a un multiplo di 4 byte, gli ultimi 2 bit di questo campo sono sempre zero. Questo fornisce un altro modo per distinguere i pacchetti STUN dai pacchetti di altri protocolli.
Dopo l'intestazione fissa STUN seguono zero o più attributi. Ogni attributo è codificato TLV (Type-Length-Value). I dettagli della codifica e gli attributi stessi sono forniti nella Sezione 15.