1. Introduction

Protocols establishing communication sessions between peers typically involve exchanging IP addresses and ports for the data sources and sinks. However, this poses challenges when operated through Network Address Translators (NATs) [RFC3235]. These protocols also seek to create a data flow directly between participants, so that there is no application-layer intermediary between them. This is done to reduce data latency, decrease packet loss, and reduce the operational costs of deploying the application. However, this is difficult to accomplish through NATs. A full treatment of the reasons for this is beyond the scope of this specification.

Numerous solutions have been defined for allowing these protocols to operate through NATs. These include Application Layer Gateways (ALGs), the Middlebox Control Protocol [RFC3303], the original Simple Traversal of UDP Through NAT (STUN) specification [RFC3489] (note that RFC 3489 has been obsoleted by RFC 5389), and Realm Specific IP [RFC3102] [RFC3103] along with session description extensions needed to make them work, such as the Session Description Protocol (SDP) attribute [RFC4566] for the Real-Time Control Protocol (RTCP) [RFC3605]. Unfortunately, these techniques all have pros and cons that make each one optimal in some network topologies, but a poor choice in others. The result is that administrators and implementers are making assumptions about the topologies of the networks in which their solutions will be deployed. This introduces complexity and brittleness into the system.

This specification defines Interactive Connectivity Establishment (ICE) as a technique for NAT traversal for UDP-based data streams (though ICE has been extended to handle other transport protocols, such as TCP [RFC6544]). ICE works by exchanging a multiplicity of IP addresses and ports, which are then tested for connectivity by peer-to-peer connectivity checks. The IP addresses and ports are exchanged using ICE-usage-specific mechanisms (e.g., in an Offer/Answer exchange), and the connectivity checks are performed using STUN [RFC5389]. ICE also makes use of Traversal Using Relay around NAT (TURN) [RFC5766], an extension to STUN. Because ICE exchanges a multiplicity of IP addresses and ports for each media stream, it also allows for address selection for multihomed and dual-stack hosts. For this reason, RFC 5245 [RFC5245] deprecated the solutions previously defined in RFC 4091 [RFC4091] and RFC 4092 [RFC4092].

Appendix B provides background information and motivations regarding the design decisions that were made when designing ICE.

---