18. IAB Considerations【IAB 注意事项】

原文链接：https://datatracker.ietf.org/doc/html/rfc8445#section-18

18. IAB Considerations【IAB 注意事项】

The IAB has studied the problem of “Unilateral Self-Address Fixing” (UNSAF), which is the general process by which an ICE agent attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol reflection mechanism [RFC3424].
IAB 研究了“单边自地址修复”（UNSAF）问题，这是 ICE 代理尝试通过协作协议反射机制在 NAT 另一侧的另一个领域确定其地址的一般过程 [ RFC3424]。

ICE is an example of a protocol that performs this type of function.
ICE 是执行此类功能的协议的一个示例。

Interestingly, the process for ICE is not unilateral, but bilateral, and the difference has a significant impact on the issues raised by the IAB.
有趣的是，ICE 的流程不是单方面的，而是双边的，并且差异对 IAB 提出的问题有重大影响。

Indeed, ICE can be considered a Bilateral Self-Address Fixing (B-SAF) protocol, rather than an UNSAF protocol.
实际上，ICE 可以被视为双边自地址修复 (B-SAF) 协议，而不是 UNSAF 协议。

Regardless, the IAB has mandated that any protocols developed for this purpose document a specific set of considerations. This section meets those requirements.
无论如何，IAB 已强制要求为此目的开发的任何协议都记录一组特定的注意事项。本节满足这些要求。

18.1. Problem Definition【问题定义】

From RFC 3424, any UNSAF proposal needs to provide:
根据 RFC 3424，任何 UNSAF 方案都需要提供：

Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short term fix should not be generalized to solve other problems.
精确定义将通过 UNSAF 提案解决的特定、范围有限的问题。 不应将短期解决方案推广到解决其他问题。

Such generalizations lead to the the prolonged dependence on and usage of the supposed short term fix – meaning that it is no longer accurate to call it “short term”.
这种概括导致对所谓的短期修复的长期依赖和使用——这意味着将其称为“短期”不再准确。

The specific problems being solved by ICE are:
ICE正在解决的具体问题是：

Providing a means for two peers to determine the set of transport addresses that can be used for communication.
为两个peer提供一种确定可用于通信的传输地址集的方法。

Providing a means for an agent to determine an address that is reachable by another peer with which it wishes to communicate.
为代理提供一种方法来确定它希望与之通信的另一个对等方可到达的地址。

18.2. Exit Strategy【退出策略】

From RFC 3424, any UNSAF proposal needs to provide:
根据 RFC 3424，任何 UNSAF 方案都需要提供：

Description of an exit strategy/transition plan. The better short term fixes are the ones that will naturally see less and less use as the appropriate technology is deployed.
退出策略/过渡计划的描述。更好的短期修复是那些随着适当技术的部署自然会越来越少使用的修复。

ICE itself doesn’t easily get phased out. However, it is useful even in a globally connected Internet, to serve as a means for detecting whether a router failure has temporarily disrupted connectivity, for example.
ICE 本身并不容易被淘汰。但是，即使在全球连接的互联网中，它也很有用，例如，它可以用作检测路由器故障是否暂时中断连接的手段。

ICE also helps prevent certain security attacks that have nothing to do with NAT. However, what ICE does is help phase out other UNSAF mechanisms.
ICE 还有助于防止某些与 NAT 无关的安全攻击。然而，ICE 所做的是帮助逐步淘汰其他 UNSAF 机制。

ICE effectively picks amongst those mechanisms, prioritizing ones that are better and deprioritizing ones that are worse.
ICE 有效地在这些机制中进行挑选，优先考虑更好的机制，而降低更差的机制的优先级。

As NATs begin to dissipate as IPv6 is introduced, server-reflexive and relayed candidates (both forms of UNSAF addresses) simply never get used, because higher-priority connectivity exists to the native host candidates.
随着 IPv6 的引入，NAT 开始消散，server-reflexive和relayed候选（两种形式的 UNSAF 地址）根本不会被使用，因为host主机候选存在更高优先级的连接。

Therefore, the servers get used less and less and can eventually be removed when their usage goes to zero.
因此，服务器的使用越来越少，最终可以在它们的使用量变为零时被删除。

Indeed, ICE can assist in the transition from IPv4 to IPv6. It can be used to determine whether to use IPv6 or IPv4 when two dual-stack hosts communicate with SIP (IPv6 gets used).
事实上，ICE 可以帮助从 IPv4 过渡到 IPv6。当两台双栈主机与 SIP 通信（使用 IPv6）时，它可用于确定是使用 IPv6 还是使用 IPv4。

It can also allow a network with both 6to4 and native v6 connectivity to determine which address to use when communicating with a peer.
它还可以允许具有 6to4 和本机 v6 连接的网络确定在与对等方通信时使用哪个地址。

18.3. Brittleness Introduced by ICE【ICE 带来的脆弱性】

From RFC 3424, any UNSAF proposal needs to provide:
根据 RFC 3424，任何 UNSAF 方案都需要提供：

Discussion of specific issues that may render systems more “brittle”.
讨论可能使系统更加“脆弱”的具体问题。

For example, approaches that involve using data at multiple network layers create more dependencies, increase debugging challenges, and make it harder to transition.
例如，涉及在多个网络层使用数据的方法会产生更多的依赖关系，增加调试挑战，并使其更难转换。

ICE actually removes brittleness from existing UNSAF mechanisms. In particular, classic STUN (as described in RFC 3489 ) has several points of brittleness.
ICE 实际上消除了现有 UNSAF 机制的脆弱性。 特别是经典的 STUN（如 RFC 3489 中所述）有几个脆弱点。

One of them is the discovery process that requires an ICE agent to try to classify the type of NAT it is behind. This process is error prone.
其中之一是发现过程，该过程需要 ICE 代理尝试对其背后的 NAT 类型进行分类。 这个过程很容易出错。

With ICE, that discoveryprocess is simply not used. Rather than unilaterally assessing the validity of the address, its validity is dynamically determined bymeasuring connectivity to a peer.
使用 ICE，根本不使用该发现过程。 不是单方面评估地址的有效性，而是通过测量与对等点的连接性来动态确定其有效性。

The process of determining connectivity is very robust.
确定连通性的过程非常稳健。

Another point of brittleness in classic STUN and any other unilateral mechanism is its absolute reliance on an additional server.
典型的 STUN 和任何其他单边机制的另一个脆弱点是它对附加服务器的绝对依赖。

ICE makes use of a server for allocating unilateral addresses, but it allows agents to directly connect if possible.
ICE 使用服务器来分配单边地址，但如果可能，它允许代理直接连接。

Therefore, in some cases, the failure of a STUN server would still allow for a call to progress when ICE is used.
因此，在某些情况下，STUN 服务器的故障仍然允许在使用 ICE 时进行调用。

Another point of brittleness in classic STUN is that it assumes the STUN server is on the public Internet. Interestingly, with ICE, that is not necessary.
典型 STUN 的另一个脆弱点是它假设 STUN 服务器位于公共 Internet 上。有趣的是，对于 ICE，这是没有必要的。

There can be a multitude of STUN servers in a variety of address realms.
在各种地址领域中可以有大量的 STUN 服务器。

ICE will discover the one that has provided a usable address.
ICE 会发现提供了可用地址的那个。

The most troubling point of brittleness in classic STUN is that it doesn’t work in all network topologies.
典型 STUN 中最令人烦恼的脆弱点是它不适用于所有网络拓扑。

In cases where there is a shared NAT between each agent and the STUN server, traditional STUN may not work. With ICE, that restriction is removed.
在每个代理和 STUN 服务器之间存在共享 NAT 的情况下，传统的 STUN 可能无法工作。有了 ICE，这个限制就被取消了。

Classic STUN also introduces some security considerations. Fortunately, those security considerations are also mitigated by ICE.
Classic STUN 还引入了一些安全注意事项。幸运的是，ICE 也减轻了这些安全考虑。

Consequently, ICE serves to repair the brittleness introduced in classic STUN, and it does not introduce any additional brittleness into the system.
因此，ICE 用于修复典型 STUN 中引入的脆弱性，并且不会在系统中引入任何额外的脆弱性。

The penalty of these improvements is that ICE increases session establishment times.
这些改进的代价是 ICE 增加了会话建立时间。

18.4. Requirements for a Long-Term Solution【长期解决方案的需求】

From RFC 3424, any UNSAF proposal needs to provide the following:
根据 RFC 3424，任何 UNSAF 方案都需要提供以下内容：

Identify requirements for longer term, sound technical solutions; contribute to the process of finding the right longer term solution.Our conclusions from RFC 3489 remain unchanged.
确定长期、健全的技术解决方案的需求； 有助于找到正确的长期解决方案的过程。我们从 RFC 3489 得出的结论保持不变。

However, we feel ICE actually helps because we believe it can be part of the long-term solution.
然而，我们认为 ICE 确实有帮助，因为我们相信它可以成为长期解决方案的一部分。

18.5. Issues with Existing NAPT Boxes【现有 NAPT 盒子的问题】

From RFC 3424, any UNSAF proposal needs to provide:
根据 RFC 3424，任何 UNSAF 方案都需要提供：

Discussion of the impact of the noted practical issues with existing, deployed NA[P]Ts and experience reports.
讨论指出的实际问题对现有、已部署的 NA[P]T 和经验报告的影响。

A number of NAT boxes are now being deployed into the market that try to provide “generic” ALG functionality.
许多 NAT 盒子现在正被部署到市场中，试图提供“通用”ALG 功能。

These generic ALGs hunt for IP addresses, in either text or binary form within a packet, and rewrite them if they match a binding.
这些通用 ALG 在数据包中以文本或二进制形式搜索 IP 地址，并在它们与绑定匹配时重写它们。

This interferes with classic STUN. However, the update to STUN [RFC5389] uses an encoding that hides these binary addresses from generic ALGs.
这会干扰经典的 STUN。然而，对 STUN [RFC5389] 的更新使用了一种编码，该编码对通用 ALG 隐藏了这些二进制地址。

Existing NAPT boxes have non-deterministic and typically short expiration times for UDP-based bindings.
对于基于 UDP 的绑定，现有的 NAPT 框具有不确定性且通常较短的到期时间。

This requires implementations to send periodic keepalives to maintain those bindings.
这需要实现发送周期性的keepalive来维护这些绑定。

ICE uses a default of 15 s, which is a very conservative estimate.
ICE 使用 15 秒的默认值，这是一个非常保守的估计。

Eventually, over time, as NAT boxes become compliant to behave [RFC4787], this minimum keepalive will become deterministic and well known, and the ICE timers can be adjusted.
最终，随着时间的推移，随着 NAT 盒子的行为符合 [RFC4787]，这个最小保活将变得确定性和众所周知，并且可以调整 ICE 计时器。

Having a way to discover and control the minimum keepalive interval would be far better still.
有一种方法来发现和控制最小保活间隔会更好。