1. Introduction (Introduzione)
I protocolli che stabiliscono sessioni di comunicazione tra peer tipicamente comportano lo scambio di indirizzi IP e porte per le sorgenti e le destinazioni dei dati. Tuttavia, questo pone sfide quando operano attraverso i Network Address Translator (NAT) [RFC3235]. Questi protocolli cercano anche di creare un flusso di dati direttamente tra i partecipanti, in modo che non ci sia un intermediario a livello applicazione tra loro. Questo viene fatto per ridurre la latenza dei dati, diminuire la perdita di pacchetti e ridurre i costi operativi di distribuzione dell'applicazione. Tuttavia, questo è difficile da realizzare attraverso i NAT. Un trattamento completo delle ragioni di ciò va oltre lo scopo di questa specifica.
Numerose soluzioni sono state definite per consentire a questi protocolli di operare attraverso i NAT. Queste includono i gateway a livello applicazione (Application Layer Gateways, ALG), il protocollo di controllo middlebox (Middlebox Control Protocol) [RFC3303], la specifica originale di attraversamento semplice di UDP attraverso NAT (Simple Traversal of UDP Through NAT, STUN) [RFC3489] (si noti che RFC 3489 è stato reso obsoleto da RFC 5389), e IP specifico del dominio (Realm Specific IP) [RFC3102] [RFC3103] insieme alle estensioni di descrizione della sessione necessarie per farli funzionare, come l'attributo del protocollo di descrizione della sessione (Session Description Protocol, SDP) [RFC4566] per il protocollo di controllo in tempo reale (Real-Time Control Protocol, RTCP) [RFC3605]. Sfortunatamente, queste tecniche hanno tutte pro e contro che rendono ciascuna ottimale in alcune topologie di rete, ma una scelta scadente in altre. Il risultato è che gli amministratori e gli implementatori stanno facendo ipotesi sulle topologie delle reti in cui le loro soluzioni saranno distribuite. Questo introduce complessità e fragilità nel sistema.
Questa specifica definisce l'Interactive Connectivity Establishment (ICE) come una tecnica di attraversamento NAT per flussi di dati basati su UDP (sebbene ICE sia stato esteso per gestire altri protocolli di trasporto, come TCP [RFC6544]). ICE funziona scambiando una molteplicità di indirizzi IP e porte, che vengono poi testati per la connettività tramite controlli di connettività peer-to-peer (peer-to-peer connectivity checks). Gli indirizzi IP e le porte vengono scambiati utilizzando meccanismi specifici dell'uso di ICE (ad esempio, in uno scambio Offer/Answer), e i controlli di connettività vengono eseguiti utilizzando STUN [RFC5389]. ICE fa anche uso di Traversal Using Relay around NAT (TURN) [RFC5766], un'estensione di STUN. Poiché ICE scambia una molteplicità di indirizzi IP e porte per ogni flusso multimediale, consente anche la selezione degli indirizzi per host multi-homed (multihomed hosts) e host dual-stack (dual-stack hosts). Per questo motivo, RFC 5245 [RFC5245] ha deprecato le soluzioni precedentemente definite in RFC 4091 [RFC4091] e RFC 4092 [RFC4092].
L'appendice B fornisce informazioni di background e motivazioni riguardanti le decisioni di progettazione prese durante la progettazione di ICE.