19. IAB Considerations (IAB 考虑)

IAB 研究了"单边自我地址修复 (Unilateral Self Address Fixing, UNSAF)"问题，这是客户端试图通过协作协议反射机制确定其在 NAT 另一侧的另一领域中的地址的一般过程 [RFC3424]。TURN 扩展是执行此类功能的协议的一个示例。IAB 已要求为此目的开发的任何协议记录一组特定的考虑。这些考虑和 TURN 的响应记录在本节中。

考虑 1：对要使用 UNSAF 提案解决的特定、范围有限的问题进行精确定义。短期修复不应被推广以解决其他问题。此类推广会导致对所谓的短期修复的长期依赖和使用 - 这意味着将其称为"短期"不再准确。

响应：TURN 是中继（= TURN 服务器）与其客户端之间通信的协议。该协议允许位于 NAT 后面的客户端在中继上获取并使用公共 IP 地址。为方便客户端，TURN 还允许客户端确定其服务器反射传输地址。

考虑 2：退出策略/过渡计划的描述。更好的短期修复是那些随着适当技术的部署而自然地越来越少使用的修复。

响应：一旦不再有任何 NAT，TURN 将不再需要。不幸的是，截至本文档发布之日，NAT 在任何时候都不太可能消失。但是，随着具有端点独立映射 (Endpoint-Independent Mapping) [RFC4787] 映射属性的 NAT 数量的增加，对 TURN 的需求也会减少。

考虑 3：讨论可能使系统更"脆弱"的特定问题。例如，涉及在多个网络层使用数据的方法会创建更多依赖关系，增加调试挑战，并使过渡更加困难。

响应：TURN 是"脆弱的"，因为它要求客户端和服务器之间的 NAT 绑定在分配的生存期内保持不变。这通常使用保持活动 (Keep-Alives) 来完成。如果不这样做，则客户端将失去其分配，并且不能再与其对等方交换数据。

考虑 4：确定对长期、健全的技术解决方案的要求，为找到正确的长期解决方案的过程做出贡献。

响应：一旦 NAT 实现 [RFC4787] 中记录的 NAT UDP 行为建议，对 TURN 的需求将会减少。还强烈敦促应用程序使用 ICE [RFC5245] 与对等方通信，尽管 ICE 使用 TURN，但它仅将其作为最后手段使用，并以受控方式使用。

考虑 5：讨论现有部署的 NAT 的实际问题的影响和经验报告。

响应：今天部署的一些 NAT 表现出除端点独立映射之外的映射行为。这些 NAT 难以处理，因为它们使 ICE 等协议难以或不可能在这些 NAT 上使用服务器反射传输地址。位于此类 NAT 后面的客户端通常被迫使用 TURN 等中继协议，因为"UDP 打洞"技术 [RFC5128] 不起作用。