要約

  • RFC 1474 の媒体状態は PPP リンクと MAC 種別ごとの行だった。ローカルの accept は自装置が受信して正しく処理するという意味だが、リモートの accept は相手が受信すると自装置が考えているという意味にとどまる。
  • RFC 1220 では、MAC 種別を通知しない相手を広く対応していると仮定できた一方、相手は理解できない種別を捨ててよかった。交渉から得た見立てと、実際の処理結果は一致するとは限らない。

1993 年 6 月の RFC 1474 は、PPP 上でブリッジ用 Network Control Protocol を管理する MIB を定義した。設定、稼働状態、交渉された機能、媒体種別を、少数の管理対象に分けている。

この文書の面白さは、ブリッジを一個の「稼働中」表示にしなかった点にある。とくに相手側については、観測者の位置をオブジェクト定義に残した。

同じ accept でも証人が違う

pppBridgeMediaTable は ifIndex と pppBridgeMediaMacType の組で索引される。したがって、一行が表すのは特定 PPP リンク上の特定 MAC 種別だけである。ある媒体の結果から別の媒体を推測したり、一つの peer の状態をリンク全体へ広げたりはできない。

pppBridgeMediaLocalStatus=accept は、自装置がその種別のパケットを受信し、適切に処理すると定義された。dont-accept なら、届いても適切には処理されない。これは報告主体が自分の能力について述べる欄である。

一方、pppBridgeMediaRemoteStatus は、遠隔エンティティがその種別を受け入れるとローカル側が「believes」と記す。対象は相手でも、判断を生成したのは自分である。

管理画面で二つを同じ緑色にすると、この非対称性が消える。自装置の設定とコード・パスは直接検査できる。相手側は、受け取った option、既定動作、現在の交渉世代を材料にした peer model である。

無言の peer は広く対応しているように見えた

RFC 1220 の MAC Type Selection は、どの種別のトラフィックを受信し処理する用意があるかを通知する仕組みだった。複数種別を示すには、Configure-Request に複数の option を載せる。

通知がない場合、相手はすべての MAC 種別をサポートすると仮定できた。ただし、その相手は理解できない種別を破棄する。ここでの「仮定」は、送信側を前に進める互換規則であり、受信能力そのものではない。

明示的に種別を列挙すれば、列挙されないものは破棄されると隣接 peer に伝わる。それでも rejection は配送停止と同義ではなかった。RFC 1220 は、MAC 種別の通知が Configure-Reject された場合、受信側が破棄すると示したトラフィックでさえリンクに転送され得ると説明した。

つまり remote-status は、通信相手の永続的属性ではない。どのリンクで、どの種別について、どの option が送られ、何が省略され、どの既定値を使ったかに結び付いた判断である。

advisory という後年の明記

後継の RFC 1638 は 1994 年、MAC-Support の交渉を強く推奨した。非対応種別を送らないことで帯域を節約できる一方、option の性質は advisory only だと明記した。

さらに MAC 種別番号が 4 を超える場合、peer から受信意思を示す option を得ない限り送信してはならないという境界を追加した。これは拡張に伴って既定動作を狭めた証拠である。しかし 1993 年の表を、実際の frame 受信記録へ変換するものではない。

古い相手との互換性、不要トラフィックの削減、新しい種別の保護は別の設計課題だった。交渉規則は見立ての質を上げられるが、見立てを直接観測にはできない。

種別対応と宛先転送は別の表だった

相手がある MAC 種別を処理できても、特定宛先への転送先をブリッジが知っているとは限らない。RFC 1493 の forwarding database は、単一 MAC アドレスごとに、学習または設定された転送・フィルタ情報を扱った。

RFC 1474 の媒体表は frame の形式に関する能力を表す。RFC 1493 の FDB は特定アドレスへの伝播判断に使う。後者さえ、終端 host の受領証ではない。

証拠を連結するなら、ローカル設定、その設定が適用された再起動、BNCP の option 交換、remote-status の根拠、送った frame、相手の処理、転送判断、終端観測を別々に残す必要がある。

RFC 1661 によれば、対応 NCP が Opened に達した後で初めて PPP はそのネットワークプロトコルのパケットを運ぶ。Opened 前の受信 packet は破棄される。これは必要条件だが、特定 frame の横断証明ではない。

表示には判断主体を付ける

RFC 1474 は書込み可能な設定表を運用表から分け、PPP の設定・制御に伴うセキュリティリスクを警告した。保護された MIB view は、誰が値を読み書きできるかを制限する。値が語れる範囲までは広げない。

現在の自動化で remote capability を表示するなら、ifIndex、MAC 種別、設定世代、再起動、NCP 状態、option の原文、省略時の規則、peer response、算出時刻を付けるべきだ。裸の緑ランプは、「こちらの peer model が yes」から「相手が受領済み」への誤った昇格を招く。

分散システムは推測なしには動かない。問題は推測を持つことではなく、推測と直接の事実を同じ文法で表示し、誰の推測だったかを消すことである。

RFC 1474 はその主語を消さなかった。

出典