1. Introduction
Les protocoles établissant des sessions de communication entre pairs impliquent généralement l'échange d'adresses IP et de ports pour les sources et destinations de données. Cependant, cela pose des défis lorsqu'ils fonctionnent à travers des traducteurs d'adresses réseau (Network Address Translator, NAT) [RFC3235]. Ces protocoles cherchent également à créer un flux de données directement entre les participants, de sorte qu'il n'y ait pas d'intermédiaire de couche application entre eux. Cela est fait pour réduire la latence des données, diminuer la perte de paquets et réduire les coûts opérationnels de déploiement de l'application. Cependant, cela est difficile à accomplir à travers les NAT. Un traitement complet des raisons de cela dépasse la portée de cette spécification.
De nombreuses solutions ont été définies pour permettre à ces protocoles de fonctionner à travers les NAT. Celles-ci incluent les passerelles de couche application (Application Layer Gateways, ALG), le protocole de contrôle de middlebox (Middlebox Control Protocol) [RFC3303], la spécification originale de traversée simple d'UDP à travers NAT (Simple Traversal of UDP Through NAT, STUN) [RFC3489] (notez que RFC 3489 a été rendu obsolète par RFC 5389), et l'IP spécifique au domaine (Realm Specific IP) [RFC3102] [RFC3103] ainsi que les extensions de description de session nécessaires pour les faire fonctionner, telles que l'attribut du protocole de description de session (Session Description Protocol, SDP) [RFC4566] pour le protocole de contrôle en temps réel (Real-Time Control Protocol, RTCP) [RFC3605]. Malheureusement, ces techniques ont toutes des avantages et des inconvénients qui rendent chacune optimale dans certaines topologies réseau, mais un mauvais choix dans d'autres. Le résultat est que les administrateurs et les implémenteurs font des hypothèses sur les topologies des réseaux dans lesquels leurs solutions seront déployées. Cela introduit de la complexité et de la fragilité dans le système.
Cette spécification définit l'établissement de connectivité interactive (Interactive Connectivity Establishment, ICE) comme une technique de traversée de NAT pour les flux de données basés sur UDP (bien que ICE ait été étendu pour gérer d'autres protocoles de transport, tels que TCP [RFC6544]). ICE fonctionne en échangeant une multiplicité d'adresses IP et de ports, qui sont ensuite testés pour la connectivité par des vérifications de connectivité peer-to-peer (peer-to-peer connectivity checks). Les adresses IP et les ports sont échangés en utilisant des mécanismes spécifiques à l'utilisation d'ICE (par exemple, dans un échange Offer/Answer), et les vérifications de connectivité sont effectuées en utilisant STUN [RFC5389]. ICE utilise également la traversée utilisant le relais autour de NAT (Traversal Using Relay around NAT, TURN) [RFC5766], une extension de STUN. Parce qu'ICE échange une multiplicité d'adresses IP et de ports pour chaque flux média, il permet également la sélection d'adresses pour les hôtes multi-résident (multihomed hosts) et les hôtes double pile (dual-stack hosts). Pour cette raison, RFC 5245 [RFC5245] a déprécié les solutions précédemment définies dans RFC 4091 [RFC4091] et RFC 4092 [RFC4092].
L'annexe B fournit des informations de contexte et des motivations concernant les décisions de conception qui ont été prises lors de la conception d'ICE.