Appendix A. Interaction with Regular ICE (通常のICEとの相互作用)
ICEプロトコルは、できるだけ多くのネットワーク環境で動作し、適応できるように十分に柔軟に設計されています。この柔軟性にもかかわらず、[RFC8445]で指定されているICE単体ではTrickle ICEをサポートしていません。このセクションでは、候補のトリクリングがICEとどのように相互作用するかを説明します。
[RFC8445]は、ICEエージェントが実行中 (Running)状態にある間にチェックリストとタイマー状態を更新するために必要な条件を説明しています。これらの条件はトランザクション完了時にチェックされ、その1つは次のように規定しています:
チェックリストに関連付けられたデータストリームの各コンポーネントに対して、有効なリストに有効なペアがない場合、チェックリストの状態は失敗 (Failed)に設定されます。
これは問題となり、多くのシナリオでICE処理が早期に失敗する可能性があります。以下のケースを考えてみましょう:
シナリオ1: プライベートアドレスブロックの衝突
- アリスとボブは両方とも、ネットワークアドレス変換 (NAT)を備えた異なるネットワークに位置しています。アリスとボブ自体は異なるアドレスを持っていますが、両方のネットワークは同じプライベートインターネットブロック(例えば、[RFC1918]で指定されている「20ビットブロック」172.16/12)を使用しています。
- アリスはボブに候補172.16.0.1を送信しますが、これはボブのネットワーク上の既存のホストにも対応しています。
- ボブは自分のホスト候補と172.16.0.1から候補ペアを作成し、このペアをチェックリストに配置してチェックを開始します。
- これらのチェックは、ボブのネットワーク上の172.16.0.1のホストに到達し、ICMPエラー「ポート到達不能」で応答します。[RFC8445]によると、ボブはトランザクションを失敗としてマークします。
この時点で、チェックリストには失敗したペアのみが含まれており、有効なリストは空です。これにより、データストリームおよび潜在的にICE処理全体が失敗しますが、Trickle ICEエージェントが後で成功する可能性のある候補を送信する可能性があります。
シナリオ2: アドレスファミリーの不一致
アリスの初期ICE記述に、ボブが収集した候補のいずれからも到達不能であると判断できる候補のみが含まれている場合、同様の競合状態が発生します(たとえば、ボブの候補にIPv4アドレスのみが含まれ、アリスから受信した最初の候補がIPv6アドレスである場合)。
シナリオ3: 非Trickle ICE相互作用
非Trickle ICE実装がTrickle ICE実装とのインタラクションを開始する場合、別の潜在的な問題が発生する可能性があります。以下のケースを考えてみましょう:
- アリスのクライアントは非Trickle ICE実装を持っています。
- ボブのクライアントはTrickle ICEをサポートしています。
- アリスとボブはアドレス依存フィルタリング [RFC4787]を備えたNATの背後にいます。
- ボブには2つのSTUNサーバーがありますが、そのうちの1つは現在到達不能です。
ボブのエージェントがアリスの初期ICE記述を受信した後、接続性チェックを即座に開始します。候補の収集も開始しますが、到達不能なSTUNサーバーのために時間がかかります。ボブの応答が準備されてアリスに送信されるまでに、ボブの接続性チェックが失敗している可能性があります:アリスがボブの応答を取得するまで、接続性チェックを開始してNATに穴を開けることができません。したがって、NATは、ボブのチェックを未知のエンドポイントからのものとしてフィルタリングします。