1. 引言

在对等方之间建立通信会话的协议通常需要交换数据源和数据接收端的 IP 地址与端口. 但是, 当这些协议通过 Network Address Translator (NAT) [RFC3235] 运行时, 会遇到挑战. 这些协议还希望直接在参与者之间建立数据流, 使其间不存在应用层中介. 这样做是为了降低数据时延, 减少丢包, 并降低部署应用的运营成本. 但是, 通过 NAT 实现这一点很困难. 对其原因的完整讨论超出了本规范的范围.

已经定义了许多方案来允许这些协议通过 NAT 工作. 这些方案包括 Application Layer Gateway (ALG), Middlebox Control Protocol [RFC3303], 最初的 Simple Traversal of UDP Through NAT (STUN) 规范 [RFC3489] (注意 RFC 3489 已被 RFC 5389 废止), 以及 Realm Specific IP [RFC3102] [RFC3103], 并配合使其工作所需的会话描述扩展, 例如用于 Real-Time Control Protocol (RTCP) [RFC3605] 的 Session Description Protocol (SDP) 属性 [RFC4566]. 遗憾的是, 这些技术各有优缺点, 使得每种技术在某些网络拓扑中是最优选择, 在另一些拓扑中却并不适合. 结果是, 管理员和实现者会对其方案将部署到的网络拓扑作出假设. 这会给系统引入复杂性和脆弱性.

本规范定义 Interactive Connectivity Establishment (ICE), 它是一种面向基于 UDP 的数据流的 NAT 穿越技术 (不过 ICE 已扩展为可处理其他传输协议, 例如 TCP [RFC6544]). ICE 通过交换多组 IP 地址和端口工作, 随后使用点到点连接性检查 (connectivity check) 测试这些地址和端口的连接性. IP 地址和端口通过特定 ICE 用法的机制交换 (例如在 Offer/Answer 交换中), 连接性检查则使用 STUN [RFC5389] 执行. ICE 还使用 Traversal Using Relay around NAT (TURN) [RFC5766], 它是 STUN 的一个扩展. 由于 ICE 会为每个媒体流交换多组 IP 地址和端口, 它也支持多宿主和双栈主机的地址选择. 因此, RFC 5245 [RFC5245] 废止了 RFC 4091 [RFC4091] 和 RFC 4092 [RFC4092] 中先前定义的方案.

附录 B 提供了 ICE 设计决策的背景信息和动机.

---