要約

  • デフォルトルーターだけを知るホストは、到達できる一方で、同じリンク上を二度横切ることがあった。最初のルーターは元のパケットを転送したうえで、次回から別の隣接ルーターへ直接送るようICMP Redirectで知らせた。
  • 助言を受け取っただけでは経路は正当化されない。送信者がその宛先への現在の第一ホップであり、新しいゲートウェイが到着リンク上にいることをホストが確認し、変更するのも宛先別キャッシュに限られた。
  • IPv6はリンクローカル送信元、Hop Limit 255、現在の第一ホップと対象アドレスの検査によって境界を強めた。SENDが署名を加えても、証明されるのは限定されたルーター関係であって、世界最適経路や宛先の所有権ではない。

近道が必要になるまで

ホストに完全な経路表を持たせないことは、初期インターネットの弱点ではなく分業だった。ローカル外の宛先が分からなければ、設定済みのデフォルトゲートウェイへ渡す。ルーターはより広い到達性を知り、次の一歩を決める。ホストは各ルーティングプロトコルを理解しなくても通信できた。

ただし、正しく動く経路が効率的とは限らない。ホストHとルーターG1、G2が同じ共有リンク上にいるとする。HはG1をデフォルトにしているが、遠隔宛先XへのG1の次ホップはG2である。HからG1へ渡ったパケットは、G1から同じリンク上のG2へ戻る。失敗ではないが、ローカル媒体を一往復余計に使う三角形ができる。

RFC 791 は、名前が何を求めるか、アドレスがどこにあるか、経路がどう到達するかを区別した。IPは独立したデータグラムを扱い、各ホストとゲートウェイが次の転送判断を行う。Hに不足しているのはXの身元情報ではなく、いまのローカル実行に関する一段だけ具体的な知識だった。

G1はその知識を持つ。だが、G1が見ているのも経路全体ではない。Hが自分へ渡したこと、自分の表がG2を選んだこと、G2が同じネットワークにいることだけである。この観測に比例した発言権をどう表すかがRedirectの問題だった。

転送を済ませてから話す

RFC 792 の説明では、G1はHから受け取ったデータグラムを調べ、Xへの次ゲートウェイG2を得る。G2と送信元Hが同一ネットワークにいるなら、G1はHへRedirectを送り、以後はG2へ直接送るよう助言する。

同時に、G1は引き金となった元のデータグラムをG2へ転送する。現在の配送を止めて新しい経路の服従を要求するのではない。既知の経路で責任を果たし、次回の反復を減らす情報を返す。パケット転送と将来の状態変更は別の行為だった。

この順序は障害時にも効く。Redirectが失われても、HはG1を使い続けられる。RFC 792が明記したように、ICMPは通信環境の問題や提案を知らせるが、IPを信頼できる配送サービスへ変えない。元のデータグラムにも制御メッセージにも到着保証はない。

したがって無応答は「近道がない」という証明ではない。逆に、一度のRedirectもG2が永久に最善であることを証明しない。機構は、動いている一般経路を残したまま、より狭い例外を学ぶよう作られていた。

元のパケットを添えた理由

Redirectには新しいゲートウェイアドレスだけでなく、元のIPヘッダーとデータの先頭64ビットが入る。当時の配置なら、先頭にあるトランスポート層のポートを含め、どの通信がメッセージを引き起こしたかをホストが対応づけられる。

これは完全な経路証明ではなく、処理した出来事の控えである。G1は「私を一般に信頼せよ」と発言するのではなく、「あなたがこの宛先へ送ったこのデータグラムを、私はこの次ホップへ転送した」と狭く語る。コードはネットワーク、ホスト、当時のサービス種別の違いを表し、Gateway欄は提案先を示した。

引用部分にはG2以降のホップも、G1のルーティング方針も、G2の生存保証もない。Xを誰が所有するかという情報もない。欠けているものを勝手に補わない限り、証拠と権限の範囲は一致する。

ホストに必要なのは、イベント、発言者、提案された実行者を結び付ける材料である。そこから先の正当性は、受信側が自分の現在状態と照合して決める。

現在の第一ホップという資格

次ホップを書き換えるメッセージは、短くても強い制御面になる。形式が正しいだけで採用すれば、ICMPを送れる者が流量を誘導できる。RFC 1122 は、Redirectを処理するホストに送信者と提案先の両方を検査させた。

新しいゲートウェイが、メッセージを受け取った接続サブネット上にいなければ捨てるべきである。ローカルに到達できない実行者を遠隔のメッセージが指名しても、Hはその提案を実行できない。

さらに送信元が、その宛先についてHが現在使っている第一ホップでなければならない。Hがパケットを預けていないルーターは、その経路を観測した立場を持たない。単に同じリンクにいる、あるいはICMPを作れるという理由では資格にならない。

これはG1の善意を証明する検査ではない。侵害された現行ルーターや、共有リンク上のなりすましという問題は残る。それでも「誰でも助言できる」状態から、「すでに検証可能な転送関係にいる者だけが助言できる」状態へ範囲を縮める。

ここで問われるのは組織の肩書ではない。G1がXを代表するか、地域を統治するかではなく、Hが現にG1を第一ホップとして使っているか、G2が同じリンクで実行可能かである。

一件の宛先を越えて広げない

RFC 1122のホストモデルでは、有効なRedirectは適切な経路キャッシュ項目の次ホップを書き換える。以後、その宛先へのデータグラムだけがG2へ直接向かう。

古いメッセージ形式にはNetwork Redirectもあった。しかしHは遠隔宛先に適用されるサブネットマスクを通常知らない。そこでHost Requirementsは、Network RedirectもHost Redirectと同様に扱い、宛先ホスト一件のキャッシュだけを更新するよう求めた。

この縮小は、知識不足を欠陥として隠さない。G1が一個のデータグラムについて正しい次ホップを知っていても、Xを含む広いアドレス集合が同じ経路を共有するとは証明していない。狭い事実から広いプレフィックスを作れば、観測されていない流量まで移動する。

キャッシュは台帳でも権利証でもない。Hが現在の条件で後続パケットをどう送るかという実行記憶である。別のホスト、別のインターフェース、別の時刻では異なる判断が成立する。変更可能であることが、キャッシュを有用にする条件だった。

デフォルトを見つけても地図は得られない

最初のG1を静的ファイルに書く方法は単純だが、管理負担と可用性変化への弱さがある。ルーティングプロトコルを傍受して探すなら、ホストはネットワークごとに異なる制御言語へ依存する。

RFC 1256 はRouter SolicitationとRouter Advertisementによって、ホストが近隣ルーターのアドレスを独立して発見できるようにした。広告には優先度と寿命があり、候補が消える可能性も表現できる。

だが文書は、Router Discoveryがルーティングプロトコルではないと明記する。どのルーターが隣にいるかは分かっても、特定の遠隔宛先にどれが最善かは分からない。Hはより具体的な情報がなければ好ましいデフォルトを選び、選択がXに不向きならG1からRedirectを受ける。

候補の発見と、実際のトラフィックから得る局所修正は異なる層である。広告は広いが目的地判断をしない。Redirectは狭いが、観測した一件についてより具体的である。どちらもHをルーティング話者にはしない。

ルーターが従ってはいけない助言

ホストにとっての小さな例外を、ルーターが経路学習に使えば影響範囲が変わる。RFC 1812 は、ルーティングプロトコルを動かすルーターがICMP Redirectから得た経路を転送に使うことを禁じた。

ルーターは、静的設定やルーティングプロトコルという別の証拠面を持つ。そこには到達性の配布、競合、失効、ループ回避の仕組みがある。一パケットを契機にしたホスト向け助言を混ぜれば、既存情報と矛盾してループを作り得る。

送信条件もローカル三角形に絞られた。受信と送信が同じ物理インターフェースであること、パケットの送信元と次ホップが同じ論理サブネットにいること、IPソースルートがないことが必要である。Redirectの送信元アドレスも受信ホストと同じ論理サブネットに属する。

別インターフェースへ越えるなら、もはや同じ媒体上の無駄を消す話ではない。G2がHから直接届かないなら助言は実行不能である。送信者がソースルートを指定したなら、通常の最短化でその明示的判断を上書きすべきではない。

IPv6が境界を測れる形にした

IPv6 Neighbor DiscoveryはRedirectを残し、よりよい第一ホップの通知と、「宛先自身が実はオンリンクである」という通知の両方に使った。RFC 4861 は受信時の有効性検査を具体化している。

送信元はリンクローカルアドレスでなければならない。Hop Limitは255でなければならない。ルーターを一つでも越えれば値は減るため、255のまま届いたメッセージはオフリンクから転送されていない。チェックサムとコードも正しく、送信元は対象宛先への現在の第一ホップと一致する必要がある。

Destination Addressはマルチキャストではならない。Target Addressは、別ルーターへ向ける場合はリンクローカル、宛先をオンリンクと知らせる場合は宛先自身と同じである。これらを通ったものだけがvalid redirectになる。

255は誠実さの証明ではない。隣人であることの証明に近い。プロトコルはまず「遠方から持ち込まれた権限ではない」ことを機械的に確かめ、その後で現在の第一ホップ関係と対象範囲を調べる。

受信ホストはDestination Cacheを更新し、Target Link-Layer AddressがあればNeighbor Cacheも更新できる。ルーターは受信したRedirectで自分の経路表を更新してはならない。IPv4から残る役割分離が、IPv6でも明文化された。

署名後にも残る判断

リンク上の送信者だから安全とは限らない。ホストは外部と通信する前にルーター情報を必要とするため、悪意あるローカルルーターを正当なものと区別しにくい。RFC 3971 のSENDは、この起動時の弱点に署名、Cryptographically Generated Address、証明書経路を導入した。

ルーターは設定されたトラストアンカーに至る認証経路によって権限を示す。Redirectが宛先自身をオンリンクと主張する場合など、証明書で許可されたアドレス範囲との照合も行われる。保護されたメッセージは、鍵の保持と選択された信頼関係の下でのルーター資格を示せる。

それでも世界最適性は証明されない。署名はG2が最短、最安、最も安全、あるいは恒久的に利用可能だとは言わない。証明書のアドレス範囲も、宛先の法的所有や組織の主権を自動的に生まない。

SENDは保護済みと未保護のNeighbor Discoveryを同時に扱う構成も認める。未保護メッセージを拒否すれば互換性の損失があり、受け入れれば信頼面が広がる。暗号化は選択を消すのではなく、誰がどの根拠で選んだかを明瞭にする。

出典と分からないこと

RFC 791はIPと経路の分業、RFC 792はG1/G2の原型、RFC 1122はホスト検査と宛先別キャッシュ、RFC 1256はルーター発見の限界を示す。RFC 1812は送信条件とルーター不服従、RFC 3971は任意の暗号的認可、RFC 4861はIPv6のローカル検証とキャッシュ効果を定める。

これらの文書から、世界共通の導入日や現在のOS既定値は分からない。全ネットワークで有効か無効か、安全か危険かも証明できない。Redirectが来なかった理由を一つに決めることもできない。確実に言えるのは、経路助言の権限が現在の第一ホップ、同一リンクの対象、受信ホストの検査、宛先別状態に限定されるよう設計されたことである。