要約

  • IEEE Registration Authority は EtherType と LSAP を割り当て、IANA には OUI 00-00-5E を付与した。IANA の権限は、その委任された空間の内側に限られる。
  • IANA OUI の後ろにある二オクテットのプロトコル番号は EtherType ではない。搬送形式、OUI、内部番号を一体で保存する必要がある。
  • RFC 9542 は、フィールド位置、名前空間、権威ある登録簿、審査手続、仕様、実装、結果を別々の証跡として扱うよう促す。

問題は、パケットを読めなかったことではない。読み取った情報を保存する段階で、権限の文脈を落としたことだった。

88-B7-00-00-5E-00-42 には三つの由来がある。0x88B7 は IEEE RA が割り当てた OUI Extended EtherType である。00-00-5E は IEEE が IANA に割り当てた OUI である。0x0042 は、その OUI の内部で IANA が文書例に予約したプロトコル番号である。最後の二オクテットだけを取り出せば、どの登録簿に属する値か分からなくなる。

RFC 9542 は 2024 年 4 月に BCP 141 として公開され、RFC 7042 を廃止した。新しい IANA 登録簿を作った文書でも、既存割り当てを変更した文書でもない。重要なのは、IEEE の直接割り当てと IANA の下位割り当てが同じフレーム上で接しても、権限は統合されないと明示した点にある。

値の名前より先に、置かれた形式を確定する

EtherType は 0x0600 以上の 16 ビット識別子で、IEEE RA が割り当てる。単純な Ethernet II では宛先・送信元 MAC アドレスの後ろに現れるが、タグが挿入される場合は複数の型フィールドをたどる必要がある。

IEEE 802 LLC は長さフィールドの後ろに一対の 8 ビット LSAP を置く。SNAP では AA-AA-03 の後に三オクテットの OUI と二オクテットのプロトコル番号が続く。最後の番号を管理するのは OUI の所有者である。

もう一つの搬送方法が 0x88B7 である。これ自体は IEEE が割り当てた EtherType であり、後続に OUI とプロトコル番号があることを示す。IANA OUI の場合は 88-B7-00-00-5E-qq-qq となる。外側と内側がともに 16 ビットでも、外側は IEEE、内側は IANA の登録判断である。

SNAP では、全ゼロ OUI の後ろに既存の EtherType を置く形もある。この場合だけ、末尾の二オクテットは EtherType として読む。全ゼロを 00-00-5E に変えれば、同じ位置は IANA のプロトコル番号になる。OUI を捨てるデータモデルは、意味を決める鍵そのものを捨てている。

登録簿を掲載する主体と割り当てる主体

IANA の “IANA OUI Ethernet Numbers” は、IANA が自身の OUI の下で行う割り当てを収録する。SNAP プロトコル番号 0x0042 が文書用として記載されているのは、この権限に基づく。

同じ IANA サイトには “IEEE 802 Numbers” もある。EtherType の節は、値を IANA が割り当てていないこと、一覧が複数の出所から寄せられた未検証情報であることを明記し、IEEE RA の公開情報を案内する。閲覧しやすい場所で一覧を提供する行為と、番号を発行する行為は別である。

自動取り込みでは、この注記が最初に消えやすい。テーブル行だけを収集し、ホスト名から所有者を推定すると、整合性のある誤データが完成する。ハッシュや署名は取得後の改変を検出できるが、権限の読み違いまでは直せない。

セキュリティ制御に使うなら影響は大きい。正式標準、局所実験、文書例を区別できなければ、許可と遮断の根拠が反転しうる。出所 URL だけでなく、その表が自ら宣言する責任範囲を保存すべきである。

IANA 配下の番号には取得条件がある

00-00-5E 配下の新しいプロトコル番号は、IETF 標準または IETF 作業に関係する標準のためでなければならない。Internet-Draft または RFC に記録し、固定位置のバージョンフィールド、もしくは旧版が新版を認識できる同等の印を備える必要がある。

通常は Expert Review を受ける。両端の 0x0000 と 0xFFFF は予約され、割り当てには IESG Ratification が必要である。また、すでに EtherType を持つプロトコルには同じ目的の IANA OUI 番号を割り当てない。その EtherType を直接使うか、SNAP の全ゼロ OUI の後ろで使えるからだ。

この重複禁止は、番号節約以上の意味を持つ。二つの機関が別の手続で同一用途を示す識別子を作れば、更新履歴と責任が分裂する。RFC 9542 は委任を増やすのではなく、必要な範囲に閉じ込めている。

MAC アドレスブロックにも同じ境界がある。IANA OUI 配下の割り当ては標準目的で、二の累乗の大きさと境界に従い、インターフェース製造者が IEEE から自らのブロックを取得する義務を回避するために使ってはならない。下位管理者は、上位権限の代替ではない。

文書用の 42 と実験用 EtherType を混同しない

IANA OUI 配下の 0x0042 は文書例のための値である。OUI に一オクテットを追加する別種の組織固有パラメータでも、0x42 が例示用に使われる。仕様書が具体的なビット列を示しても、運用中の割り当てと衝突しないようにするためだ。

IEEE は別に 0x88B5 と 0x88B6 を局所実験用 EtherType としている。こちらは IEEE の EtherType 空間に属し、文書例ではない。00-00-5E-00-42 を「実験用 EtherType」と呼ぶと、番号体系と用途の両方を取り違える。

文書値をコピーした設定が本番へ入り、実験値が局所ドメインを越えることは珍しくない。値と一緒に適用範囲、責任者、期限を持たせれば、偶然の事実が永続的な依存関係になる前に止められる。

割り当て証跡は動作証跡ではない

登録簿が証明できるのは、特定の名前空間で値が予約または割り当てられたことまでである。機器が仕様どおり解析したこと、ラベルどおりのペイロードが入っていたこと、アプリケーションが結果を受け取ったことは別の証拠を要する。

まず生のバイトとオフセットがフィールドを確定する。次に搬送形式と OUI が名前空間を確定する。権威ある IEEE RA または IANA の記録が割り当てを示し、審査記録と仕様が条件を示す。その先には実装バージョン、設定、パケット観測、エンドポイント結果がある。

この順序を守れば、登録機関に実装保証を背負わせずに済む。実装者も、独自動作を名前空間の権威で正当化できない。調整簿と実行系が互いの役割を奪わないことが、監査可能性を高める。

障害時にも使える識別子台帳

内部台帳には、生バイト、位置、タグ、外側の搬送、完全な OUI 識別子、登録主体、取得日時、審査区分、仕様、解析器の版と結果を保存する。人向け名称は検索に役立つが、唯一の記録にしてはならない。

そうすれば、IANA の情報一覧が IEEE RA より古い、正しい IANA 番号を解析器が EtherType と表示する、文書値が本番で見つかる、といった問題を別々に処理できる。どれも「どちらのサイトを信じるか」という二択ではない。

RFC 9542 が求めるのは、一つの巨大な権威ではない。委任された範囲を消さない台帳である。完全なバイト列が残れば、IEEE の直接権限と IANA の限定権限は両立する。末尾二オクテットだけになれば、表示上の便利さが存在しなかった権限を作り出す。

出典