19. Considerazioni IAB (IAB Considerations)
Lo IAB ha studiato il problema del "Unilateral Self-Address Fixing (UNSAF)", che è il processo generale mediante il quale un client tenta di determinare il proprio indirizzo in un altro reame dall'altra parte di un NAT attraverso un meccanismo di riflessione del protocollo collaborativo [RFC3424]. L'estensione TURN è un esempio di protocollo che esegue questo tipo di funzione. Lo IAB ha imposto che qualsiasi protocollo sviluppato per questo scopo documenti un insieme specifico di considerazioni. Queste considerazioni e le risposte per TURN sono documentate in questa sezione.
Considerazione 1: Definizione precisa di un problema specifico di ambito limitato che deve essere risolto con la proposta UNSAF. Una soluzione a breve termine non dovrebbe essere generalizzata per risolvere altri problemi. Tali generalizzazioni portano a una dipendenza e un utilizzo prolungati della cosiddetta soluzione a breve termine - il che significa che non è più accurato chiamarla "a breve termine".
Risposta: TURN è un protocollo per la comunicazione tra un relay (= il server TURN) e i suoi client. Il protocollo consente a un client dietro un NAT di ottenere e utilizzare un indirizzo IP pubblico sul relay. Per comodità del client, TURN consente anche al client di determinare il proprio indirizzo di trasporto riflesso dal server.
Considerazione 2: Descrizione di una strategia di uscita/piano di transizione. Le migliori soluzioni a breve termine sono quelle che vedranno naturalmente un uso sempre minore man mano che la tecnologia appropriata viene implementata.
Risposta: TURN non sarà più necessario una volta che non ci saranno più NAT. Sfortunatamente, alla data di pubblicazione di questo documento, è improbabile che i NAT scompaiano presto. Tuttavia, con l'aumento del numero di NAT con la proprietà di mappatura Endpoint-Independent Mapping [RFC4787], la necessità di TURN diminuirà.
Considerazione 3: Discussione di problemi specifici che possono rendere i sistemi più "fragili". Ad esempio, gli approcci che coinvolgono l'uso di dati a più livelli di rete creano più dipendenze, aumentano le sfide di debug e rendono la transizione più difficile.
Risposta: TURN è "fragile" nel senso che richiede che le associazioni NAT tra il client e il server rimangano in vigore durante la vita dell'allocazione. Questo viene tipicamente fatto utilizzando keep-alive. Se questo non viene fatto, il client perderà la sua allocazione e non potrà più scambiare dati con i suoi peer.
Considerazione 4: Identificare i requisiti per soluzioni tecniche a lungo termine e solide - contribuire al processo di ricerca della giusta soluzione a lungo termine.
Risposta: La necessità di TURN sarà ridotta una volta che i NAT implementeranno le raccomandazioni sul comportamento NAT UDP documentate in [RFC4787]. Alle applicazioni è anche fortemente consigliato di utilizzare ICE [RFC5245] per comunicare con i peer, e sebbene ICE utilizzi TURN, lo fa solo come ultima risorsa e in modo controllato.
Considerazione 5: Discussione dell'impatto dei problemi pratici rilevati con i NAT esistenti distribuiti e rapporti di esperienza.
Risposta: Alcuni NAT distribuiti oggi presentano un comportamento di mappatura diverso da Endpoint-Independent Mapping. Tali NAT sono difficili da gestire perché rendono difficile o impossibile per protocolli come ICE utilizzare indirizzi di trasporto riflessi dal server su questi NAT. I client dietro tali NAT sono tipicamente costretti a utilizzare un protocollo di relay come TURN perché le tecniche di "foratura UDP" [RFC5128] non funzionano.