Skip to main content

Appendix A. Interaction with Regular ICE (与常规ICE的交互)

🇨🇳 中文​

ICE协议被设计为足够灵活，可以在尽可能多的网络环境中工作和适应。尽管具有这种灵活性，但 [RFC8445] 中指定的ICE本身并不支持Trickle ICE。本节描述候选地址的渐进式交换如何与ICE交互。

[RFC8445] 描述了当ICE代理处于运行 (Running) 状态时更新检查列表和计时器状态所需的条件。这些条件在事务完成时进行验证，其中一个条件规定：

如果与检查列表关联的数据流的每个组件在有效列表中都没有有效候选地址对，则检查列表的状态将设置为失败 (Failed)。

这可能会成为问题，并在许多场景中导致ICE处理过早失败。考虑以下情况：

场景1：相同私有地址块冲突​

  1. Alice和Bob都位于具有网络地址转换 (NAT) 的不同网络中。Alice和Bob本身具有不同的地址，但两个网络都使用相同的私有互联网地址块（例如，[RFC1918] 中指定的"20位块"172.16/12）。
  2. Alice向Bob传达候选地址172.16.0.1，这也恰好对应于Bob网络上的现有主机。
  3. Bob从其主机候选地址和172.16.0.1创建候选地址对，将此候选地址对放入检查列表，并开始检查。
  4. 这些检查到达Bob网络中172.16.0.1的主机，该主机响应ICMP"端口不可达"错误；根据 [RFC8445]，Bob将事务标记为失败。

此时，检查列表仅包含一个失败的候选地址对，有效列表为空。这会导致数据流甚至可能所有ICE处理失败，即使Trickle ICE代理随后可以传达可能成功的候选地址。

场景2：IPv4/IPv6地址族不匹配​

如果来自Alice的初始ICE描述仅包含可以从Bob收集的任何候选地址确定为不可达的候选地址，则会发生类似的竞争条件（例如，如果Bob的候选地址仅包含IPv4地址，而他从Alice接收的第一个候选地址是IPv6地址，就会出现这种情况）。

场景3：非Trickle ICE与Trickle ICE交互​

当非Trickle ICE实现与Trickle ICE实现发起交互时，可能会出现另一个潜在问题。考虑以下情况：

  1. Alice的客户端具有非Trickle ICE实现。
  2. Bob的客户端支持Trickle ICE。
  3. Alice和Bob都在具有地址依赖过滤 [RFC4787] 的NAT后面。
  4. Bob有两个STUN服务器，但其中一个当前不可达。

在Bob的代理收到Alice的初始ICE描述后，它会立即开始连接性检查。它还会开始收集候选地址，由于STUN服务器不可达，这将需要很长时间。当Bob的应答准备好并传达给Alice时，Bob的连接性检查可能已经失败：在Alice得到Bob的应答之前，她将无法开始连接性检查并在她的NAT中打孔。因此，NAT将过滤Bob的检查，因为它们来自未知端点。

🇬🇧 English​

The ICE protocol was designed to be flexible enough to work in and adapt to as many network environments as possible. Despite that flexibility, ICE as specified in [RFC8445] does not by itself support Trickle ICE. This section describes how trickling of candidates interacts with ICE.

[RFC8445] describes the conditions required to update checklists and timer states while an ICE agent is in the Running state. These conditions are verified upon transaction completion, and one of them stipulates that:

if there is not a valid pair in the valid list for each component of the data stream associated with the checklist, the state of the checklist is set to Failed.

This could be a problem and cause ICE processing to fail prematurely in a number of scenarios. Consider the following case:

Scenario 1: Private Address Block Collision​

  1. Alice and Bob are both located in different networks with Network Address Translation (NAT). Alice and Bob themselves have different addresses, but both networks use the same private internet block (e.g., the "20-bit block" 172.16/12 specified in [RFC1918]).
  2. Alice conveys to Bob the candidate 172.16.0.1, which also happens to correspond to an existing host on Bob's network.
  3. Bob creates a candidate pair from his host candidate and 172.16.0.1, puts this one pair into a checklist, and starts checks.
  4. These checks reach the host at 172.16.0.1 in Bob's network, which responds with an ICMP "port unreachable" error; per [RFC8445], Bob marks the transaction as Failed.

At this point, the checklist only contains a Failed pair, and the valid list is empty. This causes the data stream and potentially all ICE processing to fail, even though Trickle ICE agents can subsequently convey candidates that could succeed.

Scenario 2: Address Family Mismatch​

A similar race condition would occur if the initial ICE description from Alice contains only candidates that can be determined as unreachable from any of the candidates that Bob has gathered (e.g., this would be the case if Bob's candidates only contain IPv4 addresses and the first candidate that he receives from Alice is an IPv6 one).

Scenario 3: Non-Trickle ICE Interaction​

Another potential problem could arise when a non-Trickle ICE implementation initiates an interaction with a Trickle ICE implementation. Consider the following case:

  1. Alice's client has a non-Trickle ICE implementation.
  2. Bob's client has support for Trickle ICE.
  3. Alice and Bob are behind NATs with address-dependent filtering [RFC4787].
  4. Bob has two STUN servers, but one of them is currently unreachable.

After Bob's agent receives Alice's initial ICE description, it would immediately start connectivity checks. It would also start gathering candidates, which would take a long time because of the unreachable STUN server. By the time Bob's answer is ready and conveyed to Alice, Bob's connectivity checks might have failed: until Alice gets Bob's answer, she won't be able to start connectivity checks and punch holes in her NAT. The NAT would hence be filtering Bob's checks as originating from an unknown endpoint.

🇯🇵 日本語​

ICEプロトコルは、可能な限り多くのネットワーク環境で動作し適応できるように十分柔軟に設計されています。その柔軟性にもかかわらず、[RFC8445] で指定されているICE自体はTrickle ICEをサポートしていません。このセクションでは、候補のトリクルがICEとどのように相互作用するかについて説明します。

[RFC8445] は、ICEエージェントが実行中 (Running) 状態にある間にチェックリストとタイマー状態を更新するために必要な条件を説明しています。これらの条件はトランザクション完了時に検証され、その1つは次のように規定しています：

チェックリストに関連付けられたデータストリームの各コンポーネントの有効リストに有効なペアがない場合、チェックリストの状態は失敗 (Failed) に設定されます。

これは問題になる可能性があり、多くのシナリオでICE処理が早期に失敗する原因となる可能性があります。（シナリオ詳細は英語版と同様）

🇫🇷 Français​

Le protocole ICE a été conçu pour être suffisamment flexible pour fonctionner et s'adapter à autant d'environnements réseau que possible. Malgré cette flexibilité, ICE tel que spécifié dans [RFC8445] ne prend pas en charge Trickle ICE par lui-même. Cette section décrit comment le trickling des candidats interagit avec ICE.

[RFC8445] décrit les conditions requises pour mettre à jour les listes de vérification et les états de minuterie pendant qu'un agent ICE est dans l'état En cours d'exécution (Running). Ces conditions sont vérifiées lors de l'achèvement de la transaction, et l'une d'elles stipule que :

s'il n'y a pas de paire valide dans la liste valide pour chaque composant du flux de données associé à la liste de vérification, l'état de la liste de vérification est défini sur Échoué (Failed).

（Détails des scénarios similaires à la version anglaise）

🇩🇪 Deutsch​

Das ICE-Protokoll wurde so konzipiert, dass es flexibel genug ist, um in möglichst vielen Netzwerkumgebungen zu funktionieren und sich anzupassen. Trotz dieser Flexibilität unterstützt ICE, wie in [RFC8445] spezifiziert, Trickle ICE nicht von sich aus. Dieser Abschnitt beschreibt, wie das Trickeln von Kandidaten mit ICE interagiert.

[RFC8445] beschreibt die Bedingungen, die erforderlich sind, um Checklisten und Timer-Zustände zu aktualisieren, während sich ein ICE-Agent im Zustand Laufend (Running) befindet. Diese Bedingungen werden bei Transaktionsabschluss überprüft, und eine davon legt fest, dass:

wenn es kein gültiges Paar in der gültigen Liste für jede Komponente des mit der Checkliste verbundenen Datenstroms gibt, wird der Zustand der Checkliste auf Fehlgeschlagen (Failed) gesetzt.

（Szenariodetails ähnlich der englischen Version）

🇮🇹 Italiano​

Il protocollo ICE è stato progettato per essere abbastanza flessibile da funzionare e adattarsi a quanti più ambienti di rete possibili. Nonostante questa flessibilità, ICE come specificato in [RFC8445] non supporta di per sé Trickle ICE. Questa sezione descrive come il trickling dei candidati interagisce con ICE.

[RFC8445] descrive le condizioni richieste per aggiornare le checklist e gli stati dei timer mentre un agente ICE è nello stato In esecuzione (Running). Queste condizioni vengono verificate al completamento della transazione, e una di esse stabilisce che:

se non esiste una coppia valida nell'elenco valido per ciascun componente del flusso di dati associato alla checklist, lo stato della checklist viene impostato su Fallito (Failed).

（Dettagli degli scenari simili alla versione inglese）

Last updated on