19. IAB 考量

IAB 研究过 "单边自地址修复 (Unilateral Self-Address Fixing, UNSAF)" 问题, 这是指客户端通过协作式协议反射机制, 尝试确定自己在 NAT 另一侧另一个域中的地址这一通用过程 [RFC3424]. TURN 扩展就是执行这类功能的协议示例. IAB 要求为此目的开发的任何协议都必须记录一组特定考量. 本节记录这些考量以及 TURN 的回应.

考量 1: 精确定义 UNSAF 提案要解决的一个具体且范围有限的问题. 不应将短期修复方案泛化为解决其他问题的方案. 这种泛化会导致对所谓短期修复方案的长期依赖和使用, 也就意味着再称其为 "短期" 已不准确.

回应: TURN 是用于中继 (= TURN 服务器) 与其客户端之间通信的协议. 该协议允许 NAT 后的客户端在中继上获取并使用一个公共 IP 地址. 为方便客户端, TURN 还允许客户端确定其服务器反射传输地址 (server-reflexive transport address).

考量 2: 描述退出策略/过渡计划. 更好的短期修复方案, 会随着适当技术的部署而自然地越来越少被使用.

回应: 一旦不再存在 NAT, 就不再需要 TURN. 遗憾的是, 截至本文档发布之日, NAT 不太可能很快消失. 不过, 随着具备 Endpoint-Independent Mapping [RFC4787] 映射属性的 NAT 数量增加, 对 TURN 的需求将会下降.

考量 3: 讨论可能使系统更加 "脆弱" 的具体问题. 例如, 涉及使用多个网络层数据的方法会产生更多依赖, 增加调试难度, 并使过渡更加困难.

回应: TURN 的 "脆弱" 之处在于, 它要求客户端与服务器之间的 NAT 绑定在分配的生命周期内保持存在. 这通常通过保活 (keep-alive) 完成. 如果不这样做, 客户端将失去其分配, 并且无法再与对等端交换数据.

考量 4: 识别长期且稳健的技术解决方案所需满足的要求, 为寻找合适的长期解决方案这一过程作出贡献.

回应: 一旦 NAT 实现 [RFC4787] 中记录的 NAT UDP Behavior 建议, 对 TURN 的需求将会降低. 也强烈建议应用使用 ICE [RFC5245] 与对等端通信. 尽管 ICE 会使用 TURN, 但它只会将 TURN 作为最后手段, 并以受控方式使用.

考量 5: 讨论现有已部署 NAT 的已知实际问题及经验报告所产生的影响.

回应: 当前部署的一些 NAT 表现出不同于 Endpoint-Independent Mapping 的映射行为. 这类 NAT 很难处理, 因为它们使 ICE 等协议难以或无法在这些 NAT 上使用服务器反射传输地址. 位于这类 NAT 后的客户端通常被迫使用 TURN 这样的中继协议, 因为 "UDP 打洞 (UDP hole punching)" 技术 [RFC5128] 无法工作.