要約

  • RFC 2390のFrame Relay例では、一つの仮想回線をAはDLCI 50、BはDLCI 70として扱った。DLCIは原則として各インターフェース内だけで意味を持ったからだ。
  • ネットワークが外側の番号を書き換えるため、到着時のInARP本文にあるハードウェアアドレスはすべて無効だった。受信側はフレームヘッダーのQ.922アドレスを内側の送信元欄へ移した。
  • 復元値が示すのは、その受信インターフェースで観測したローカル座標だけである。相手の本人性、権限、プロトコルアドレスの正しさ、通信結果までは証明しない。

回線は同じでも番号空間は違った

Inverse ARPの出発点はRFC 2390より古い。RFC 1293は、確立済みの仮想回線とそのリンク識別子は分かるが、反対側のプロトコルアドレスが分からない状況を定義していた。1998年9月のRFC 2390は、その仕組み自体を新発明とはしていない。変更点として挙げたのは、規範語の整備、パケット図、7.2節の具体例、そしてセキュリティ節だった。

重要なのは具体例が見せた「ローカル」の重みである。RFC 2427によれば、仮想回線は各Frame RelayインターフェースでDLCIにより識別され、多くの場合、そのDLCIはそのインターフェースにしか意味を持たない。

したがってAからBへの回線は、A側では50、B側では70になり得る。Aは外側ヘッダーに50を入れて送る。ネットワークが途中で番号を書き換え、Bは70として受け取る。どちらかが誤記なのではない。同じ関係を異なる境界から記述した二つの座標だった。

送信側には書けない欄があった

ARP型のメッセージには、送信元と宛先それぞれのハードウェアアドレスとプロトコルアドレスがある。Ethernetなら、送信者は通常、自分のハードウェアアドレスを書ける。ところがFrame Relay端末には、どの受信者からも同じに見える自己DLCIがない。

RFC 2390の例で、AはローカルなDLCI 50へInARP要求を送る。ar$shaはunknownのままだ。宛先ハードウェア欄には、Aが知る50のQ.922表現0x0C21が入る。しかしBへの到着時、外側ヘッダーは70を示している。C/R、FECN、BECN、DEをゼロとして扱うと、そのQ.922表現は0x1061になる。

仕様は、この時点で本文内のハードウェアアドレスはすべて無効だと明記した。一方、フレームヘッダー内のアドレスは正しい。配送のために更新された事実は外側にあり、内側の整った書式は送信側の古い視点を残していた。

受信インターフェースが一項目だけを直した

Bはヘッダーから0x1061を取り出し、InARPの送信元ハードウェア欄へ置く。これによりBの処理系は、自分の番号空間で意味を持つ送信元座標を得る。応答方向でも同様である。Bは自分の到着側番号を予測できないまま応答し、Aが受信した時点で外側からDLCI 50、すなわち0x0C21を復元する。

RFCは、この処理がレイヤーの純粋さに反すると認めている。しかし、正しい値を観測できるのは下位層だけだった。図式を守って無効値を上位へ渡すより、観測できた事実を限定的に投影する方が正確だった。

介入は受信パケットだけに限られる。送信側は受信側のローカル名前空間を所有しないからだ。また、宛先ハードウェア欄は直さない。要求でも応答でも無効であり、InARPはその欄に依存しない。実装はゼロで埋めるか無視できた。空欄があるからといって、証拠のない値を作らなかったのである。

復元は認証ではなく来歴の付与だった

復元後のパケットを見ると、送信元欄は正規の値で埋まっている。その見た目が、値の権威を大きく見せる。実際に分かるのは「このフレームは、このインターフェースに、このQ.922座標で到着した」ということだけだ。

RFC 2390が追加したセキュリティ節は、ARP系に認証がなく、ホストのなりすましが既知の問題であり、新たな保護機構も追加していないと述べた。ヘッダーから値を転記しても、パケットに署名は付かない。相手が申告するプロトコルアドレスも検証されない。許可も発生しない。

証拠は段階ごとに分ける必要がある。外側ヘッダーは到着位置の観測、InARP応答は相手が述べたプロトコルアドレス、ローカルポリシーはその対応を採用するかの判断、キャッシュ寿命は時間的な有効性、後続トラフィックは到達性、アプリケーション応答は最終結果である。一つの欄に全段階を代表させることはできない。

割り当て番号は局所的現実を支配しない

IANAのARP Parametersには、Frame Relayのハードウェア種別15と、InARP要求・応答のオペコード8・9が今も記録されている。この台帳は共通番号の衝突を防ぐ。しかし、あるネットワークでInARPが動作していることも、特定の応答が真正であることも、DLCIが世界共通名であることも保証しない。

役割は分割されている。RFCは変換規則を定める。IANAはコードポイントを整理する。ネットワークは境界ごとのラベルを提示する。受信インターフェースは観測値を送信元欄へ投影する。相手は応答とプロトコルアドレスを選ぶ。ローカルシステムはその後の利用を決める。

未修正の本文を信じれば、遠隔側のローカル視点を自分の現実と誤認する。修正後の値を身元と信じれば、自分のローカル視点を普遍的権威へ膨らませる。どちらも作用域の消去である。

「小さな変更」が残した設計規律

RFC 2390の図は、回線そのもの、Aの50、Bの70、Bが受信事実から作った内側フィールドを分離した。四つは関連するが同一ではない。

この考え方は、Frame Relayが主役でなくなった後も有効だ。ポート番号、トンネルラベル、セッションハンドル、キャッシュキーなど、分散システムには観測者ごとの識別子が多い。堅牢な設計は、名前空間と導出元を記録し、座標を本人性へ昇格させない。

共通ルールは薄くてよかった。どの観測からどの欄を直すかだけを標準化し、信頼や利用判断は証拠を持つローカル側へ残す。RFC 2390の教訓は、きれいに埋まったパケット欄より、実際に到着したフレームの方が現実をよく知る場合がある、ということだった。

出典