要約

  • RFC 1433は、同じリンク層ネットワークに載る別のIPネットワークの次ホップを解決するため、経路表エントリーにARP Helper Addressを結び付けた。
  • Helper自身はローカル手段で解決できなければならず、Directed ARPを再帰的に使えない。要求の転送にも経路、同一物理インターフェース、洪水・ループ防止の条件があった。
  • リンク層アドレスが返っても経路は保証されない。非推移的または非対称なフィルターにより、第三者次ホップは「解決済みだが通信不能」になり得た。

近く見えるアドレス

RFC 1433が想定したリンクは、一つのIPサブネットだけを運ぶ単純なLANではない。SMDSのような大規模データサービス上に、管理主体の異なる複数のIPネットワークが置かれる。二つのIPネットワークにインターフェースを持つルーターは、両者が同じリンク層ネットワークを共有していると知ることができた。

その事実を経路制御に使えば、パケットをいったん二重所属のルーターへ送り、同じ基盤へ戻してもらう迂回を省ける。別の参加者を直接の次ホップとして広告すればよい。しかし広告を受けたホストやルーターは、その次ホップのIPアドレスを知っても、フレームの宛先をまだ知らない。

アドレス解決手順はIPネットワークごとに独立していた。外国側ネットワークが使うARP要求先を受信者が設定していないかもしれない。そもそもARPではなく管理された対応表を使う場合もある。経路表が選んだIPアドレスを、リンクドライバーが扱える宛先へ変換できなければ、短い経路は実行できない。

ここでDirected ARPが行ったのは、経路選択をやり直すことではない。通常のARP形式を保ったまま、解決の質問を引き受けるルーターを経路状態に追加することだった。

Helperは経路の来歴だった

各経路エントリーにはARP Helper Addressを持たせられた。nullなら、受信者は次ホップまたは直接宛先をローカル手順で解決できる。値があれば、そのアドレスは「外国の次ホップが同じリンク層ネットワーク上にある」と知らせたルーターを指した。

したがってHelperは便利な補助欄ではない。経路を誰から学び、その経路を実行するため誰の支援に依存するかを保存する欄である。距離ベクトル更新で学んだ場合は広告者が、ICMP Redirectで学んだ場合はRedirect送信者が、原則としてこの責任を負った。

解決処理はまずローカル表を見る。対象がなければ、Helperなしの場合は通常のローカル解決を行う。Helperがある場合は、まずHelper自身のリンク層アドレスをローカルに解決し、外国の対象IPを入れたARP RequestをHelperのリンク宛先へ送り、応答を待つ。

Helperを解決するためにDirected ARPを再び使うことは禁止された。この非再帰性は小さな規則だが、責任を有限にする。Helper AがHelper Bを必要とし、BがさらにCを必要とすれば、経路表の一行が見えない依存鎖とループを抱える。最初のHelperは、既存のローカル手段で到達できなければならない。

質問を運ぶ場合と代理回答する場合

自分以外を対象とするARP Requestを受けたホストは破棄する。ルーターがDirected ARPとして扱うには、対象が正当な次ホップ、または直接到達する宛先として経路表に存在し、その経路が要求を受けたのと同じ物理インターフェースを使う必要があった。

対象側ネットワークがARPを使うなら、ルーターはそのネットワークの要求先へパケットを転送する。ARP以外のローカル解決を使うなら、ルーターがその方法で対応を得て、対象に代わる「published ARP」応答を返すことができた。

両方とも受信側にはARP応答として見えるが、根拠は違う。前者は質問が先のネットワークへ運ばれ、そこで誰かが答えた。後者はHelperが別の仕組みの結果をARPへ翻訳して表明した。IPとリンクアドレスだけをキャッシュすれば、この違いは消えてしまう。

応答は装置の運営者、経路を決める権限、将来の受理、逆方向の許可を証明しない。特定時点とインターフェースにおける対応情報である。

質問がトラフィックになる

発見要求の転送は、答えより先に負荷を広げる。RFC 1433は、故障したホストやルーターによるARP floodを抑え、経路変動や誤設定から生じるARP loopを終わらせるフィルターを必須とした。具体値はリンクごとの運用に残し、複数の方法を提示した。

同じ送信元IP・対象IPの要求回数を短い時間窓で制限する。受信フレームが送られていたのと同じリンク宛先へ戻さない。リンク層broadcastとして届いた要求は転送しない。これらはそれぞれ反復、単純反射、拡散範囲を制御する。

どのフィルターもアドレス対応の正しさを判定しない。未解決の質問が共有資源をどこまで消費できるかを決める。最初の要求が失われれば正当な再送が必要なので、制限が厳しすぎても可用性を壊す。NとTは単なる定数ではなく、運用者が説明できる判断だった。

記録には要求の組、インターフェース、受信時のリンク宛先、broadcastフラグ、カウンター、時間窓、許可・拒否、後続応答を残す必要がある。「応答なし」だけでは損失とフィルターとループを区別できない。

解決できない経路は残せない

Redirectで学んだ外国次ホップを解決できなくなった場合、RFC 1433は関連する経路エントリーをflushするよう求めた。Helperのローカル対応が期限切れになれば、そのHelperに依存した近道を永久の経路として扱えない。

相互運用も同じ境界を示す。Directed ARP対応ルーターが、非対応の隣接ルーターへ外国次ホップを広告すると、受信者は値を読めても実行できない。広告者自身を従来型の次ホップとして、より高いコストで併記するか、管理された経路関係で外国次ホップを禁止する必要があった。

能力の違いにより、同じ広告が一方では経路、他方では実行不能な文字列になる。ルーティング更新は、その下に必要な解決手順まで自動的に移植しない。

共通の隣人は推移性を作らない

第三者次ホップでは、広告者が実際のデータ経路から外れる。自分が広告した通常の経路なら、状態の変化を観察して撤回しやすい。R1とR3を直接通信させる提案をR2が行うと、R2は二者間の故障を見られない場合がある。

RFC 1433のSMDS例では、フィルターがR1–R2とR2–R3を許可し、R1–R3を拒否する。R2がR3へ到達できることも、R1がR2へ到達できることも真実である。それでもR1からR3への直接経路は黒穴になる。リンク層の接続性は推移しなかった。

さらにフィルターは方向ごとに異なり得る。R3からR1へ送れても、R1からR3へ送れない。一方向のフレームや応答は逆方向を保証しない。「同じリンク」という名称は、すべての組み合わせが許可された完全な網を意味しない。

迂回できない方法で試す

提案された次ホップのリンク層アドレスへ直接ICMP echoを送り、経路の追加前または初回利用前に接続を試す方法が示された。IPアドレスへ通常どおり送れば、ルーティングが別経路を選び、問題のローカル接続を通らず成功してしまう。

検査は、検査対象の依存関係を実際に通過しなければならない。ただし直接echoの成功も、一時点の交換に限られる。すべてのトラフィック分類、双方向性、宛先への転送、将来の継続を証明しない。後の変化は動的ルーティングの課題として文書の外に残された。

したがって証拠は段階で保存する。経路広告、広告者、Helper、Helperのローカル解決、Directed Request、応答者、対応値、フィルター判断、直接検査、最初のデータ送信、戻りの観察。それぞれが別の問いに答える。

出典と限界

RFC 1433が実験手順を定義し、RFC 826がARP、RFC 1209がSMDS、RFC 1267とRFC 1247が当時のBGP-3とOSPF、RFC 1122とRFC 792がホストとICMPの背景を与える。

これらは現在の実装率、製品の挙動、攻撃頻度、現代の推奨設定を示さない。RFC 1433自身もSecurity Considerationsで安全上の問題を論じていない。歴史的に残るのは、制御面が候補を示しても、リンクが解決・許可・対称性・継続性を別に決めるという構造である。

出典