12. Backwards Compatibility with RFC 3489 (Compatibilità con le versioni precedenti con RFC 3489)

Questa sezione definisce procedure che consentono un certo grado di compatibilità con le versioni precedenti del protocollo originale definito in RFC 3489 [RFC3489]. Questo meccanismo è opzionale e viene utilizzato solo nei casi in cui un nuovo client può connettersi a un vecchio server o viceversa. Un utilizzo deve (must) definire se e quando questa procedura viene utilizzata.

La Sezione 19 elenca tutte le modifiche tra questa specifica e RFC 3489 [RFC3489]. Tuttavia, non tutte queste differenze sono importanti, poiché lo "STUN classico" veniva utilizzato solo in alcuni modi specifici. Ai fini di questa estensione, le modifiche importanti sono le seguenti. In RFC 3489:

• UDP era l'unico trasporto supportato.

• Il campo che ora è il campo magic cookie faceva parte del campo ID di transazione, rendendo l'ID di transazione lungo 128 bit.

• L'attributo XOR-MAPPED-ADDRESS non esisteva e il metodo Binding utilizzava invece l'attributo MAPPED-ADDRESS.

• C'erano tre attributi a comprensione obbligatoria, RESPONSE-ADDRESS, CHANGE-REQUEST e CHANGED-ADDRESS, che sono stati rimossi da questa specifica.

  • CHANGE-REQUEST e CHANGED-ADDRESS fanno ora parte dell'utilizzo NAT Behavior Discovery [BEHAVE-NAT], e l'altro è stato deprecato.

12.1. Changes to Client Processing (Modifiche all'elaborazione del client)

Un client che desidera interoperare con un server [RFC3489] dovrebbe (SHOULD) inviare un messaggio di richiesta al server che utilizza il metodo Binding, non contiene attributi e utilizza UDP come protocollo di trasporto. La risposta di successo ricevuta dal server conterrà, se ha successo, un attributo MAPPED-ADDRESS piuttosto che un attributo XOR-MAPPED-ADDRESS. Un client che cerca di interoperare con un server più vecchio deve (MUST) essere preparato a ricevere entrambi. Inoltre, il client deve (MUST) ignorare tutti gli attributi a comprensione obbligatoria riservati che possono apparire nella risposta. Tra gli attributi riservati nella Sezione 18.2, 0x0002, 0x0004, 0x0005 e 0x000B possono apparire nelle risposte Binding da un server conforme a RFC 3489. A parte questa modifica, l'elaborazione della risposta è identica alle procedure descritte in questa specifica.

12.2. Changes to Server Processing (Modifiche all'elaborazione del server)

Un server STUN può rilevare quando un determinato messaggio di richiesta Binding è stato inviato da un client RFC 3489 [RFC3489] dall'assenza del valore corretto nel campo magic cookie. Quando il server rileva un client RFC 3489, dovrebbe (SHOULD) copiare il valore visto nel campo magic cookie nella richiesta Binding nel campo magic cookie nel messaggio di risposta Binding e inserire un attributo MAPPED-ADDRESS invece di un attributo XOR-MAPPED-ADDRESS.

Un client può, in rare situazioni, includere un attributo RESPONSE-ADDRESS o CHANGE-REQUEST. In queste situazioni, il server considererà questi come attributi a comprensione obbligatoria sconosciuti e risponderà con una risposta di errore. Poiché i meccanismi che utilizzano questi attributi non sono più supportati, questo comportamento è accettabile.

La versione RFC 3489 di STUN manca sia del magic cookie che dell'attributo FINGERPRINT che consentono una probabilità molto elevata di identificare correttamente i messaggi STUN quando sono multiplexati con altri protocolli. Pertanto, le implementazioni STUN che sono compatibili con le versioni precedenti di RFC 3489 non dovrebbero (SHOULD NOT) essere utilizzate nei casi in cui STUN sarà multiplexato con un altro protocollo. Tuttavia, questo non dovrebbe essere un problema poiché tale multiplexing non era disponibile in RFC 3489.