要約
- RFC 9892 の Ethernet 分類では VID は12ビットであり、
0x000は VID 無視、0xFFFは予約済み、明示値の上限は0xFFEである。 - その処理を必須とする RFC 9895 は管理節で
0x0000、0xFFFF、0x00010xFFFEと記す。公開時点の RFC Editor 検索に対応する errata はなかった。
境界値 0x1000 を設定画面に入れたとき、製品は何をすべきか。受け付けないのか、下位12ビットへ丸めるのか、保存だけして送信時に失敗するのか。この問いに、公開済みの二つの RFC は同じ表現では答えていない。
RFC 9895 は DLEP の IEEE 802.1Q Aware Credit Window Extension、通称 Ethernet Credit を定める。モデムが宛先、VLAN Identifier、Priority Code Point を使ってトラフィックと論理クレジット窓の関係をルータへ示す。窓は複数フローで共有でき、特定フロー専用にもできる。
重要なのは、この文書が分類形式を新設していない点だ。RFC 9892 の Ethernet Traffic Classification Sub-Data Item と、RFC 9893 のクレジット処理を土台にする。拡張タイプ5を通知する実装は、両 RFC の関連メッセージ、Data Item、処理をすべて支えなければならない。
RFC 9892 のビット配置は明瞭である。16ビットのまとまりを NumPCPs の4ビットと VID の12ビットに分ける。VID がゼロなら VLAN を分類条件から外し、0xFFF は予約、使える明示範囲は 0x001 から 0xFFE までだ。
ところが RFC 9895 第3節は、ゼロを 0x0000、予約値を 0xFFFF、利用可能範囲を 0x0001 から 0xFFFE とする。桁数だけの表記差ではない。後半の値は12ビットを超える。RFC Editor の HTML と XML の双方に同じ記述があり、表示側の事故ではない。errata 検索では、調査時点で該当項目が表示されなかった。
ここから先は区別が必要だ。文章の不整合は確認できる。しかし公式訂正が成立したとは言えない。実装障害が起きたとも言えない。既存製品は VLAN の一般的な上限を別の層で知り、正しく拒否している可能性が高い。逆に、設定スキーマだけが16ビットを許している可能性も調査なしには否定できない。
ワイヤ上の判断材料は RFC 9892 にある。RFC 9895 自身がその処理を必須にしており、12ビット以外を格納する場所はない。したがって運用上は 0xFFE を超える明示 VID を入口で拒否し、後段の暗黙変換に委ねない、という解釈が最も検証可能である。ただし、この実装判断を公式 errata の代わりにしてはならない。
事故の種は、プロトコルより管理面に残る。CLI は16ビット整数を受け、データベースもそのまま保持し、シリアライザだけが & 0x0FFF を適用するかもしれない。別の装置は範囲外としてセッションを落とすかもしれない。同じ設定ファイルを配っても、片側では VLAN 1、他方ではエラーになる。
特に危険なのが静かな変換だ。0x1001 が 0x001 になれば、存在しないつもりの値が実在する VLAN 1 を選ぶ。読み戻しが元の値を返せば、監査記録と実行状態は分離する。高位ビットを落とした事実がログに残らなければ、原因追跡はさらに難しくなる。
RFC 9892 の優先順位も効く。Ethernet と Diffserv の両方が一致するとき、VLAN/PCP 側が優先される。RFC 9894 の DSCP 窓を正しく設定していても、誤った Ethernet 分類が先に選ばれれば期待した経路には戻らない。
また RFC 9895 は VID と PCP のワイルドカードに慎重である。設定後に現れた予期しないフローまで拾うため、明確な必要がない限り使わないよう勧告する。明示ルールが不正値で消え、ワイルドカードが代わりに通すと、疎通試験は成功しても分離方針は失敗する。
DLEP の初期化で拡張を相互通知することも、値域の合意ではない。モデムがルータの能力を超える数の窓を示した場合、ルータは一部を使うか、セッションをリセットできる。差異は管理系に報告すべきだと RFC は述べる。この可視化原則を VID の範囲拒否にも適用すべきである。
検証は上限だけで終わらない。0x001 と 0xFFE を受理し、0xFFF、0x1000、0xFFFF、負数、高位ビット付き入力を拒否する。ゼロは「VID を無視する」という特別な意味でのみ扱う。設定投入、永続化、送信バイト、対向解析、インストール済み分類、read-back を一つの往復試験として比較する。
さらに Ethernet と DSCP の同時一致、ワイルドカードへの落下、再接続後の状態、能力の部分採用、拒否ログを試す。成功応答だけでは不十分で、入力意図と出力ビットが同一であることを証明しなければならない。
IANA の DLEP 登録簿は拡張タイプ5を共有するが、製品の入力検査までは観測しない。Lu Heng のRunning-Code Primacyは、実際に検証・送信される状態遷移へ問いを戻す。Minimum Initial Specificationは共通部分を小さく決定的に保ち、Reality Layersは文書の象徴的地位と実行結果を混同させない。
標準への正しい敬意は、矛盾を黙って埋めることではない。12ビットの線形式で入力を拘束し、判断を記録し、負の境界を試し、上流の errata 手続へ提出することだ。運用責任者が確認すべき一文は短い。「13番目のビットは、どこで、誰の責任で拒否されるのか」。
情報源
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加

