要約

  • RFC 3518 は PPP BCP に交渉可能な Bridge-Control-Packet-Indicator を追加した。有効時、送信側は認識した BPDU や GARP 系制御フレームに C ビットを立て、廃棄や大幅な遅延を避けなければならなかった。
  • C ビットが示すのは局所分類と隣接ピアの能力である。BPDU の真正性、受信制御処理による採用、スパニングツリーの収束、全体のループ不在は示さない。

データフレームは既にある転送状態に従う。BPDU はその状態を変える判断に関わる。ルートブリッジ、ポートの役割、冗長経路の遮断が更新されるまで、遅れた小さな制御フレームが大量のデータより大きな影響を持ち得る。

LAN フレームを PPP で運ぶ仕組み自体は以前からあった。RFC 1638 が初期仕様を示し、RFC 2878 が Bridging Control Protocol を改訂した。ポイント・ツー・ポイントリンクの両端はブリッジングの特性を交渉し、モジュールを動かせた。2003 年の RFC 3518 は RFC 2878 を廃止したが、スパニングツリーを作り直したわけではない。

変更点として列挙されたのは二つだけだった。Bridge Control Packet Indicator を設定オプションへ加えること、そして flags フィールドの予約ビット一つに意味を与えることだ。既存の搬送形式の中で「これは制御である」というクラスを、キューが使える形にした。

BCP オプションタイプ 10 が対応能力を交渉した。既定では非対応で、合意して初めて有効になる。有効時、送信システムは出力フレームがブリッジ制御である場合に限って C を 1 にする。無効時は全フレームを 0 に保ち、交渉しないシステムは 1 のフレームを送受信してはならない。RFC 2878 の相手との互換性はこの制約で守られた。

分類には IEEE が割り当てた宛先 MAC アドレスを使う。RFC 3518 は STP の Bridge Group Address、ブリッジ管理、GMRP、GVRP のアドレスを挙げた。送信側分類器はフレームの用途を認識し、PPP のブリッジフレームヘッダーに判断を記す。

狙いは処理の差である。実装はブリッジ制御パケットを落としたり、大きく遅らせたりしてはならない。RFC は高い IP precedence を持つルーティング更新になぞらえ、RFC 2474 の差別化サービスを参照した。混雑したリンクでも制御フレームを有利なキューへ置ける。

ただし、有利な処理は証拠の範囲を広げない。分類器は送信実装の判定を示す。オプション交渉は隣の PPP ピアがビットを理解すると示す。受信は一つのリンクを渡ったと示す。それらは内容への暗号署名でも、送信元がツリードメインを変更する権限の証明でも、全ブリッジの観測でもない。

受領証を順に分ける必要がある。IANA 登録はタイプ 10 の割当を証明する。Configure-Request と Configure-Ack はそのセッションでの共有能力を証明する。キャプチャは C の値を証明する。その後に受信側の制御状態、ルートとポート役割の変化、データ面を調べて初めて、冗長経路が本当に遮断されたかを論じられる。

BCP の Opened も局所状態である。RFC 1661 の PPP 状態機械を BCP が利用する。RFC 3518 は、スパニングツリープロトコルの不一致など重大な構成差が解けない場合、Opened へ進むことを禁じた。通過したという事実は二つの端点が許容可能な共通部分を得たことを示すが、その背後の機器を全て検査したことにはならない。

セキュリティ節は残る危険を明記した。悪意あるピアとのブリッジリンクが立ち上がれば、転送 multicast からネットワーク情報を学ばれ得る。さらに、本来検出して分離すべきループを閉じたり、不正な負荷を加えたりしてサービス拒否を起こせる。正しい交渉と危険なトポロジーは同時に存在する。

外国または侵害済み装置につながる可能性があれば、RFC 3518 は LCP 開始時の PPP 認証を勧めた。RFC 1994 の CHAP は challenge-response でピア確認を強める。しかし「相手は誰か」の答えが良くなっても、「相手のブリッジ設定は正しいか」「BPDU は新しいか」「ドメインは収束したか」は別の問いである。

複数リンクの仕組みも境界を変えない。RFC 1990 の Multilink PPP は複数構成リンクで断片化と順序付けを行う。RFC 2686 の Multiclass はクラスごとの遅延を改善できる。制御フレームの到着時間には効くが、到着をアルゴリズムの採用や安全な結果へ変換しない。

古い BCP ブリッジ向けには従来形式の BPDU も残された。通常はブリッジトラフィックと共通の形式を使うが、相手が読める形式を選ぶ必要があった。これは隣接互換性の判断であり、背後のドメインの健全性ではない。

RFC 7042 は後に IETF と IEEE 802 のパラメータ管理境界を記録し、PPP Numbers は今もタイプ 10 を載せる。登録は番号の権威を安定させるが、実セッション、フレームの真正性、遅延、効果を観測しない。

RFC 3518 の歴史的価値は、権限を小さく正確に配置した点にある。インターフェースは重要なクラスをより良く扱う情報を得たが、分散システム全体の真実を宣言する権限までは得なかった。分類と優先は局所、収束とループ不在は別の証拠を要する結果である。

BPDU は正しく認識され早く届いても、古い、侵害されたピア由来、誤ったドメイン向け、あるいは未収束のブリッジ群へ届いたものかもしれない。C ビットはフレームの扱い方を示す。フレームが語る世界の安全までは示さない。

情報源