2. Evolution from RFC 3489 (Evoluzione da RFC 3489)

STUN è stato originariamente definito in RFC 3489 [RFC3489]. Quella specifica, a volte chiamata "STUN classico (classic STUN)", si presentava come una soluzione completa al problema dell'attraversamento NAT. In quella soluzione, un client scopriva se si trovava dietro un NAT, determinava il suo tipo di NAT, scopriva il suo indirizzo IP e porta sul lato pubblico del NAT più esterno, e quindi utilizzava quell'indirizzo IP e porta all'interno del corpo di protocolli, come il Session Initiation Protocol (SIP) [RFC3261]. Tuttavia, l'esperienza dalla pubblicazione di RFC 3489 ha riscontrato che STUN classico semplicemente non funziona sufficientemente bene per essere una soluzione distribuibile. L'indirizzo e la porta appresi tramite STUN classico sono talvolta utilizzabili per le comunicazioni con un peer, e talvolta no. STUN classico non forniva alcun modo per scoprire se avrebbe effettivamente funzionato o meno, e non forniva alcun rimedio nei casi in cui non funzionava. Inoltre, l'algoritmo di STUN classico per la classificazione dei tipi di NAT si è rivelato difettoso, poiché molti NAT non si adattavano chiaramente ai tipi definiti lì.

STUN classico aveva anche una vulnerabilità di sicurezza: gli attaccanti potevano fornire al client indirizzi mappati errati sotto determinate topologie e vincoli, e questo non era fondamentalmente risolvibile attraverso mezzi crittografici. Sebbene questo problema rimanga con questa specifica, tali attacchi sono ora mitigati attraverso l'uso di soluzioni più complete che utilizzano STUN.

Per questi motivi, questa specifica rende obsoleto RFC 3489 e descrive invece STUN come uno strumento utilizzato come parte di una soluzione completa di attraversamento NAT. ICE [MMUSIC-ICE] è una soluzione completa di attraversamento NAT per protocolli basati sulla metodologia offerta/risposta (offer/answer) [RFC3264], come SIP. SIP Outbound [SIP-OUTBOUND] è una soluzione completa per l'attraversamento della segnalazione SIP e utilizza STUN in un modo molto diverso. Sebbene sia possibile che un protocollo possa utilizzare STUN da solo (STUN classico) come soluzione di attraversamento, tale utilizzo non è descritto qui ed è fortemente sconsigliato per i motivi descritti sopra.

Il protocollo sul filo (on-the-wire protocol) descritto qui è cambiato solo leggermente rispetto a STUN classico. Il protocollo ora funziona su TCP oltre a UDP. L'estensibilità è stata aggiunta al protocollo in modo più strutturato. Un meccanismo di cookie magico (magic cookie) per demultiplexare STUN con protocolli applicativi è stato aggiunto "rubando" 32 bit dall'ID di transazione (transaction ID) a 128 bit definito in RFC 3489, consentendo che la modifica fosse retrocompatibile. Gli indirizzi mappati sono codificati utilizzando un nuovo formato OR esclusivo (exclusive-or). Ci sono altri cambiamenti più minori. Vedere la Sezione 19 per un elenco più completo.

A causa del cambiamento di ambito, STUN è stato anche rinominato da "Simple Traversal of UDP through NAT" a "Session Traversal Utilities for NAT". L'acronimo rimane STUN, che è tutto ciò che chiunque ricorda comunque.