要約

  • RFC 3378 は、Ethernet フレームの前に 16 ビットのヘッダーを置き、IPv4 のプロトコル番号 97 で運ぶ最小限の EtherIP を記録した。
  • そこには対向認証、内側の完全性検査、順序、トンネル制御、ループ防止がない。正常な取り出しはゲートウェイ到着の証拠であって、一つの安全な LAN が遠方まで伸びた証明ではない。

LAN の性質はフレームだけでは決まらない。配線、スイッチ、管理境界、隣接相手だという前提が、本来弱いローカルプロトコルを成立させる。EtherIP はフレーム形式を保存したが、その場所性までは保存しなかった。

RFC 3378 は 2002 年 9 月の Informational 文書で、1991 年から 1992 年に設計・実装された方式を歴史資料として残し、IANA の IP プロトコル番号 97 の背景を説明した。新しい設計には、後のレイヤー 2 トンネルや疑似回線の標準化成果を使うよう明記している。

形式は驚くほど小さい。IPv4 の Protocol を 97 にし、続く 16 ビットはバージョン三の四ビットとゼロの予約十二ビットだけである。その後に FCS を除いた Ethernet または IEEE 802.3 フレームが来る。受信側は値が違えば破棄し、正しければフレームを取り出し、新しい FCS を計算して遠隔 LAN へ送る。

値の検査は構文検査にすぎない。送信者の身元、MAC の使用権、フレームを越境させる理由は分からない。セッション ID、シーケンス、再送識別、交渉、内側の検査フィールドもない。

元の FCS が消える点は重要である。入口 LAN の検査は入口で終わる。RFC は IPv4 ヘッダーのチェックサムが内側を保護しないため、フレーム内の上位プロトコルに完全性を期待した。出口で作る FCS が正しくても、それは最後のローカル送信を検査するだけで、トンネル全体の不変性を示さない。

端末は自分のフレームの一部を選べる。ブリッジ型の装置は LAN をプロミスキャスに監視し、送信元・宛先 MAC、EtherType、VLAN などで選別する。ローカルに届くものや通常のルータで扱えるものは除外する。この判断は運用環境にあり、16 ビットには記録されない。

宛先 MAC から遠隔 EtherIP 装置の IP を決める仕組みも必要だったが、RFC は普遍的な発見方法を定義しなかった。どのフレームを入れるか、どのゲートウェイが宛先を代表するかは外部設定である。

ブリッジ型では無限ループが生じ得る。複数の装置が同じフレームを捕捉し、カプセル化し、遠隔で再投入すると、ブロードキャストやマルチキャストは往復し続ける。RFC は構成を木に限定するよう求めたが、その木を人間が作るものとした。ホップ数も自動のスパニングツリーもない。

個々の規則が正しくても、組合せが以前のセグメントへ戻せば失敗する。処理成功はループを速め、カウンターの増加は有用な配送を意味しない。

ファイアウォール境界も変わる。EtherIP を通せば任意の通信を許す可能性があり、同一 LAN 内だけなら許容された弱い保護が遠隔地で危険になる。文書は VRRP を例に挙げ、外側の保護として IPsec を提案した。

RFC 2401 と後継の RFC 4301 は IPsec の背景を示す。外側を守っても、選別規則、遠隔投入、ループのない構成、アプリケーション結果までは正しくならない。

RFC 2003 の IP-in-IP、RFC 2784 の GRE は同時代の比較になる。後の RFC 3931 は L2TPv3 の制御接続とセッションを、RFC 3985 は疑似回線の構造を、RFC 4448 は Ethernet 疑似回線を扱う。これらは EtherIP に遡って機能を追加しない。

RFC 2119 の MUST はフィールド設定と破棄を要求するが、通過許可、信頼、普及を証明しない。IANA 登録も解釈を共有するための記録であり、運用結果ではない。

Lu Heng の最小初期仕様は、少ない共通規則で機能を始める価値を説明する。現実の層という視点は、選別、封入、対向許可、経路、完全性、取り出し、FCS、再投入、受信を別々に検証させる。

EtherIP が運んだのは封筒である。LAN はトポロジー、管理、信頼、物理的結果まで含む。十六ビットでフレームは越境できても、遠隔地がローカルになるわけではなかった。

出典