要約

  • MASQUE の Internet-Draft 第 15 版は、暗号化された HTTP 上で Ethernet フレームを運ぶ仕組みを定めるが、HTTP 本人確認と各フレームの送信元 MAC の権限は別である。
  • 101 または 2xx はトンネル確立の証拠であり、VLAN の意味、ループ防止、出口への配送、宛先での効果を証明しない。

draft-ietf-masque-connect-ethernet-15 は 2026 年 9 月 30 日に公開された MASQUE ワーキンググループの作業文書で、Proposed Standard が意図されている。Datatracker では IESG Evaluation、サブステート AD Followup にあり、第 15 版の提出後は IANA Review が「Version Changed - Review Needed」に戻った。RFC ではなく、凍結した資料は導入実績、普及、実装適合性、性能、事故を示さない。

この草案は、HTTP クライアントと物理または仮想 Ethernet セグメントにつながるプロキシの間に、概念上のポイント・ツー・ポイントリンクを作る。HTTP/1.1 では Upgrade: connect-ethernet と 101 Switching Protocols、HTTP/2・HTTP/3 では Extended CONNECT と適切な 2xx が成功条件になる。

成功応答が証明する範囲

成功は、プロキシがトンネルを確立し、フレームを中継する意思があることを示す。TLS、QUIC 暗号化または同等の保護は HTTP の関係に機密性、完全性、認証を与える。しかし、内側の Ethernet ヘッダーに書かれたアドレスを本人確認するものではない。

草案は任意の送信元 MAC を含む任意のフレームを送れると明記し、他ホストの偽装、ARP・NDP・CAM テーブルの汚染、サービス妨害を挙げる。つまり、HTTP 利用者が正しく認証されていても、その利用者がゲートウェイや制御装置の MAC を名乗る権限を持つとは限らない。

Context ID 0 と FCS の限界

HTTP Datagram の Context ID 0 は、ペイロードを Ethernet フレームとして解釈するための識別子である。対象は宛先アドレスから FCS 直前までで、FCS は通常インターフェースが入口で除去し出口で再生成するため省略される。

ここで再生成される FCS は、新しい物理リンク上の誤り検出に役立つ。元の送信者の身元や権限を復元するものではない。トンネルの暗号学的完全性も同様で、保護区間内の改ざんに対する証拠と、フレームの送信元主張の真正性を混同してはならない。

0 以外の Context ID は将来の拡張用で、偶数・奇数の割当規則は同期衝突を避ける。登録より先にデータグラムが到着する場合、受信側は短時間待つか破棄できる。同じ数値は別のリクエストで別の意味を持ち得る。これは要求内のプロトコル状態であり、主体 ID でも恒久的な許可証でもない。

MAC 制限は配備側の仕事

点対サイト接続を一つの送信元 MAC に制限する、許可 MAC を設定する、IEEE 802.1X を利用する、認証済み利用者だけにサービスを提供する、レート制限をかける、といった対策を草案は示す。一方、MAC フィルタの動的な交渉は将来拡張に残される。

したがって運用記録には、HTTP 主体、URI、ポリシー版、許可された送信元・宛先・EtherType・VLAN、有効期限、個々のフレームの判定が必要になる。仮想マシン追加や機器交換による MAC 変更は、単なる観測値ではなく権限変更として扱うべきである。

タグを通すことと意味を合意すること

802.1Q タグは既定では透明に転送される。入口または出口がタグを解釈する場合、両端にはシグナルまたは手動設定による一貫した処理の合意が必要だが、その手順は草案の範囲外である。VLAN ごとに URI を分け、タグを除去して出口で再付与することもできる。

この設計では URI と VLAN の対応表が認可面になる。片側だけの変更でも HTTP トンネル自体は正常なまま、フレームを別の管理領域へ送れる。記録すべきなのは受信タグ、変換規則、優先度、出口タグ、担当者、版であり、200 だけではない。

正しいリンクから誤ったループができる

エミュレートされたリンクを外部ネットワークにつなぐと、ブロードキャスト・マルチキャスト、PAUSE フレーム、学習、ループ防止などのブリッジ責務が生じる。これらは CONNECT-ETHERNET の外側にある。個々に正しいトンネルを組み合わせてもループは発生し、ブロードキャストストームが容量とバッファを消費する。

草案は STP/RSTP、別コンポーネントへの委譲、既知の無ループ構成を勧め、トラフィック急増監視や制限も示す。HTTP ストリームが生きていることは、スパニングツリーの役割やトポロジー安全性を証明しない。

配送は別の観測である

QUIC DATAGRAM は分割できない。利用可能な大きさを超えたフレームは破棄し、DATAGRAM capsule に自動退避してはならない。ストリーム上の capsule は大きなフレームを複数パケットにまたがって運べるが、経路中の再符号化によって順序特性が変わり得る。

出口インターフェース、宛先ネットワーク、受信端の最大長を超えたフレームも破棄される。基盤 Ethernet へ渡せなければ同様である。よって「トンネル up」はフレーム配送の十分条件ではない。入口受理、Context、方式、サイズ、MAC/VLAN 判定、キュー、出口、破棄理由、宛先観測を別々に残す必要がある。

Heng Lu の Running-Code Primacy、Minimum Initial Specification、agency problem を本稿の明示的な編集レンズとする。共通仕様がリンクを狭く正確に調整し、地域の実装が追加の権限と結果を証明する、という読み方である。これは IETF の意図を代弁するものではない。

出典