要約

  • RFC 2153 は、ベンダーが通常の PPP Code や Option Type を秘密裏に自己割当てして衝突させないための独自拡張枠を定義した。
  • OUI は意味の管理者を示すだけで、Kind と Values はベンダー固有である。構文が正しくても、未知またはポリシーで禁止され得る。
  • Configure-Ack が記録するのは一つの要求への厳密な受諾であり、有効化、双方向利用、トラフィック、サービス結果は別の証拠である。

デコーダは住所を読めたが、本文を読めなかった

トレースには Code 0、正しい Length、3 オクテットの OUI、1 オクテットの Kind が並ぶ。外枠の分類は成功している。それでも受信側に該当 Kind の実装がなければ Values は不透明であり、管理者が許可していなければ既知の機能でも使えない。

RFC 2153 は1997年に公開された Informational RFC である。目的は独自アルゴリズムの標準化ではなく、ベンダーが LCP/NCP の Code や Configuration Option Type を勝手に選び、将来衝突するのを防ぐことだった。

Vendor Specific 制御パケットは Code 0 を使い、毎回変える Identifier、Magic-Number、OUI、Kind、任意の Values を運ぶ。LCP が Opened に達する前でも送信できる。受信は RXR または RUC を起こすが、応答はベンダー固有である。Code-Reject は許容される RXJ+ になる。これは到着と状態遷移の記録であって、合意ではない。

Vendor-Specific Configuration Option は Type 0 を使う。受諾前に、実装は OUI と Kind が既知の機構を示すこと、さらに独自交渉値を完全に理解することを確認しなければならない。構文、意味、許可は別々の関門である。

OUI は認証情報ではない

OUI は意味を管理する組織を識別する。Kind には OUI をまたぐ標準化がなく、Values は実装固有である。OUI は送信者を認証せず、運用許可も付与しない。RFC 1661 では相手認証はリンク確立後に任意で行われ得る一方、独自パケットは Opened 前に届く。RFC 2153 自身はセキュリティを論じていない。

IEEE OUI を持たないソフトウェアベンダー向けに CF0000 系列も作られた。RFC 5342 が新規割当てを停止し、RFC 7042 が技術形式を変えずにその判断を引き継いだ。現在の IANA PPP 登録簿は番号の由来を示すが、現在の実装一覧ではない。

PPP の Configure-Ack は、全オプションが認識可能で全値が受諾可能な場合に限り、要求と同一の内容を返す。Nak は理解できるが値が受け入れられない場合、Reject は未知または管理上交渉不可の場合である。Ack 後にも、辞書版、許可主体、パラメータ導入、最初の独自パケット、NCP Opened、ネットワーク通信、アプリ結果を順に残す必要がある。

RFC 3772 は後にベンダー固有 PPP プロトコル番号を設けたが、セキュリティは各独自プロトコルに残した。RFC Editor、Datatracker、errata は文書層を示す。Running-Code Primacy、Minimum Initial Specification、Reality Layers は、共通仕様、実行、結果を混同しないための枠組みを与える。

情報源