要約

  • RFC 1293 は 1992 年 1 月の標準化トラック文書であり、既知のハードウェア・アドレスに対応するプロトコル・アドレスを要求するための Inverse Address Resolution Protocol を ARP に加えた。中心例は、確立した PVC に結び付いた DLCI を知りながら対端のプロトコル・アドレスを知らない Frame Relay 局である。
  • InARP 要求は、目的ハードウェア・アドレスが既知なのでブロードキャストしない。受信側は答えることも、答えられない・答えたくないときに無視することもできる。要求側は返答でローカル ARP 表を補完できるが、その情報は老化または無効化されうる。

RFC 1293 の特徴は、回線について知っていることを、対端について知っていることと取り違えない点にある。ネットワークは信号メッセージを通じて新しい仮想回線と DLCI を知らせうる。DLCI は WAN を横切る一つの仮想接続を定め、Frame Relay ではハードウェア・アドレスに相当する。しかしその通知には、反対側の局に向けてプロトコル層で使うアドレスが含まれない。

このため回線は、ある目的にはまだ使えない。RFC がいう unusable は、もう一方の局をアドレス指定することができないという意味である。回線が存在しない、故障している、安全でない、または遠隔局が存在しないという宣言ではない。既知の経路識別子と未知のプロトコル対端の間に残る一つの情報空白を、文書はそのまま残す。

DLCI は仮想経路を指し、対端の住所を指さない

PVC、そして最終的には SVC は DLCI によって識別される。局はその番号を用いてどの仮想接続にフレームを載せるかを知ることができる。だが、上位プロトコルの会話を始めるための相手のアドレスは、この番号から推測できない。信号で新しい接続を学んだ局が、その相手をアドレス指定できないことこそが InARP の動機だった。

ここには少なくとも五つの別の記録がある。回線と DLCI の通知、InARP 要求の送信、遠隔局の返答または沈黙、ローカル表への対応付け、そして後のデータ転送である。通知だけから要求済みを導くことはできない。要求だけから返答済みを導くことはできない。表の行だけからデータが配達されたことを導くことはできない。順序を保つことで、どこに不確実性が残るかが見える。

これは単に古い WAN の注意書きではない。一つの層で精密な識別子が、次の層で必要な名前や権限を運んでいるとは限らない。トンネル、セッション、キュー、接続ハンドルにも同じ誤読が起こりうる。RFC 1293 は、下位層の把手を「隣接先が既知」という結論に昇格させなかった。

Inverse は情報の向きであり、万能な対称性ではない

InARP はハードウェア・アドレスから始め、対応するプロトコル・アドレスを求める。ARP の形式を拡張し、InARP request は操作コード 8、reply は 9 である。ここで近い名前を持つ RARP は検討されたが、必要な答えを返さないため採用されなかった。RARP の返答は要求者自身のプロトコル・アドレスであり、InARP が求めるのは要求を受け取る反対側の局のアドレスであった。

「逆」という言葉だけで二つの手順を同じものにすると、誰についての情報が返るかが失われる。RFC 1293 は IP 専用の仕組みも、複数プロトコルのアドレス解決を望むために退けた。これは IP 所有権の登録簿でも、経路選択の権威でもない。既知の目的ハードウェア・アドレスと、まだ不明なプロトコル・アドレスとの対応を、相手に問い合わせるための手順である。

直接送信は問いを狭め、答えを保証しない

通常の ARP は目的ハードウェア・アドレスを知らないのでブロードキャストする。InARP では目的ハードウェア・アドレスが既知である。要求者は自分のハードウェア・アドレスとプロトコル・アドレス、既知の目的ハードウェア・アドレスを入れ、目的プロトコル・アドレス欄をゼロで埋め、当該ネットワーク用にカプセル化して直接送る。

ゼロの欄は設計上の欠陥ではない。何がまだ分からないかを、相手に届くメッセージの中で明示する境界である。直接の要求は、同じメッセージを複数コピーしてブロードキャストを模倣するより効率的であり、静的構成より柔軟になりうる。それでも遠隔局が InARP を実装していること、適切なアドレスを持つこと、現在返答する意思があること、返答が永続することを示さない。

到達先が特定されていることと、問われた事実が確定していることは別である。正しく残すべきログは「この局が、この既知の目的ハードウェア・アドレスに、この要求を送った」であって、「回線が解決された」ではない。答えが来れば新しい事実を追加できる。来なければ、仕様が与えるのは沈黙だけである。

返答は受信局の条件付きの行為だった

InARP 要求を受けた局は、要求者のプロトコル・アドレスとハードウェア・アドレスの対応を自身の ARP キャッシュに置くことができる。要求の送信元アドレスを返答の目的アドレスとして使い、適切な reply を作ることもできる。しかし返答できない、または返答したくない局は、要求を無視する。

沈黙を成功の不足形として補完してはならない。送信済みの要求は送信の観察であり、返答、構成、許可、到達可能性または原因を観察した記録ではない。RFC 1293 は、沈黙をどの現実の原因に帰すかを決めない。未記録の原因をプロトコル語から推定すると、要求者が知らなかったプロトコル・アドレスを勝手に作るのと同じ種類の飛躍になる。

要求者が reply を受け取れば、そのアドレス情報で ARP 表の項目を完成させ、利用できる。この事実もローカルである。reply を受け、表に置くことを選んだということであり、恒久的な身元、独立認証、認可、安全性またはサービス成果ではない。RFC は InARP から学んだ情報が老化または無効化されうると明記する。

複数アドレスの局は、質問者との関係で選ぶ

一つのインターフェースに複数のプロトコル・アドレスを持つ局は、どれでも返せるわけではない。まず要求者のプロトコル・アドレスを見て、要求者のネットワークに対応するアドレスを選ばなければならない。IP の例では、要求されたサブネットに属するインターフェース・アドレスがなければ、返答すべきではない。

つまり答えは応答者だけの属性ではない。同じ局が複数のアドレスを持っても、この要求者には適切なものを一つも持たない場合がある。複数アドレスのホストはインターフェース上の各アドレスについて InARP を送ることができ、受信側は構成に応じて一部だけ、または何も返さないことがある。

「遠隔局にはアドレスがある」という短い文は、表に書くべき値を決めない。どの質問者が、どのネットワークから、どの目的ハードウェア・アドレスを通じて尋ねたかが必要である。対応付けは文字列の一覧ではなく、関係の中で得られる。

キャッシュは一時の知識であり、身元の権威ではない

InARP で得た対応をキャッシュすることは、局所的な保留方針である。回線または DLCI、要求時刻、送信元、目的ハードウェア・アドレス、返答、表の寿命、無効化の出来事を分けて保存しなければ、後で一行の由来を説明できなくなる。後続のデータ面はさらに別の証拠を要する。目的地、経路、権限、時刻、応答、失敗を含むからである。

Security Considerations では安全性の問題が扱われないと明記される。したがって reply は認証、完全性、認可、攻撃耐性を示さない。既知 DLCI、直接要求、キャッシュされた mapping のどれも、それだけでは現実の Frame Relay 展開、到達可能な対端、正しい対応、IP 配送または利用者結果を証明しない。

出典と証拠の限界

本稿は RFC 1293 — Inverse Address Resolution Protocol を用いる。出典は 1992 年 1 月の標準化トラック地位、DLCI/PVC の動機、遠隔プロトコル・アドレスの欠如、RARP と IP 専用手段を退けた理由、InARP の形式とコード、非ブロードキャストの直接要求、返答または無視、キャッシュ、老化または無効化、複数アドレス選択、安全性未扱いの声明を支える。

特定回線の現在の存在、対端の構成や到達、返答の正しさ・認可・安全性、キャッシュの永続、IP 経路、パケット配送、商用サービス、組織や利用者の結果を支えるものではない。既知 DLCI を限定された協調の事実と読み、使用可能な隣接先の判定としないことは、仕組みからの編集的解釈であって、配備の観察記録ではない。