要約

  • RFC 3145 は L2TP の Call-Disconnect-Notify に PPP 固有の理由を加えたが、その AVP を任意・非必須・情報専用に保った。
  • コード、制御プロトコル番号、方向は一つの対向装置の報告範囲を示す。物理的根本原因、責任、利用者への表示、課金確定までは証明しない。
  • 異なる管理主体の間で診断を比較可能にしつつ、登録番号や保護された通信路が運用事実を代行しない構造を選んだ。

終了通知の内側に残った PPP

L2TP は LAC と LNS の間にトンネルを張り、PPP セッションを運んだ。トンネル制御を PPP の細部から切り離すことで、複数の媒体や運用形態に同じ仕組みを使えた。しかし切り離しは、終了時の知識も分けた。

Call-Disconnect-Notify には L2TP の Result Code と Error Code があった。これらはトンネル制御の結果を表す。LCP のタイマーが切れた、認証方式が合意できなかった、利用可能な NCP が一つもなかった、といった PPP の最終観測は別だった。

LAC と LNS が同じ組織なら、内部ログを人間が結び付けられる場合もある。所有者や管理者が異なると、一方は利用者側の現象を、もう一方は PPP 状態を持ち、それぞれの時計と識別子で記録する。共通の受け渡し形式がなければ、「切れた」という一致の先に進めない。

RFC 3145 は PPP Disconnect Cause Code AVP を定義した。Vendor ID は 0、Attribute Type は 46、使える場所は CDN だけである。値には切断コード、PPP Control Protocol Number、Direction、任意の UTF-8 説明が入る。

重要なのは追加より併置だった。この AVP は L2TP の Result/Error Code と一緒に使い、置き換えてはならない。トンネルの結果と PPP の報告は別の証拠である。単一の「最終原因」に正規化すると、どちらが何を語ったのかが消える。

無視できることが互換性を守った

Mandatory ビットは必ず 0 だった。拡張を知らない受信側は AVP を無視しても、終了通知そのものを処理できる。診断機能の導入速度が違っても、基本動作を壊さない。

さらに RFC は、この AVP を情報とログのためだけに用い、トンネルや PPP セッションの機能に影響させないとした。既存の状態機械が終了を実行し、ホストが自分の観測を報告し、後続の調査が結論を組み立てる。報告フィールドが第二の制御面になることを防いだ。

Hidden ビットは 1 にでき、RFC 3193 は IPsec による L2TP 保護を扱った。保護は送信元、完全性、機密性の証拠を強くする。しかし送信元の認識が完全だったことまでは証明しない。話者を認証することと、説明を実証することは違う。

「相手側」は誰から見た相手か

Direction 0 は global、1 は at peer、2 は at local を示す。local は AVP を作ったホストである。中央ログが local を「事業者」、peer を「顧客」と書き換えれば、商業上の役割を後付けする。まして責任の方向へ変換する根拠はない。

方向がなければ解けないコードもある。通常の LCP 終了では、どちらが Terminate-Request を送ったかを示す。強制暗号化やコールバックの拒否では、どちらが要求し、どちらが拒んだかを区別する。認証方式では、ローカルが提案した方式を peer が拒否したのか、peer が要求した方式をローカルが実装していないのかが異なる。

拒否した側が誤っているとは限らない。ポリシーに従った正しい拒否かもしれない。最後のメッセージを送った側が、先行する条件すべての原因とも限らない。Direction は視点を保存するが、非難を割り当てない。

Control Protocol Number は対象を保存する。global は 0、リンク制御なら LCP、認証ならその認証プロトコル、ネットワーク制御なら該当 NCP である。複数 NCP が失敗すれば複数 AVP を送れる。一つだけなら直近の失敗を選ぶ。「直近」は記録選択であり、唯一の原因という意味ではない。

したがって「コード 16」だけを保存してはならない。どの peer が、どのトンネルとセッションの、どの CDN で、いつ、どの保護下で、どのプロトコルと方向について報告したかが必要である。

二十一個の値は症状の共通語だった

初期値 0〜20 は、情報なし、管理上の切断、通常終了、状態機械タイムアウト、認識可能な LCP パケットなし、Magic Number が示す可能性のあるループ、Echo Request のタイムアウト、Multilink PPP の不一致、コールバックや暗号化の拒否、認証失敗、利用可能な NCP なし、アドレス合意失敗などを含んだ。

共通語は装置間比較を可能にする。しかし echo timeout は、損失、混雑、戻り経路の遮断、相手の停止、ローカル処理停止のどれも否定しない。認証失敗はプロトコル結果であって、名前と秘密のどちらが正しかったかを公開する判定ではない。

RFC 3145 は、名前が正しく秘密だけが誤っていると攻撃者に教える拡張を作るべきでないと注意した。診断の細かさは、繰り返し試行する者にとって探索能力になる。最小仕様は、相互運用だけでなく漏えいも境界付ける。

任意の UTF-8 文も同様である。表示可能な文字列は、正確性や安全な公開範囲を保証しない。AVP に入っていたことは、利用者が実際に読んだ証拠でもない。原文、ローカライズ文、構造化コードは別々に来歴を持つべきだ。

旧形式を読めても、旧形式を増やさない

草案は 3Com の Vendor ID 43 を使っていた。RFC 3145 は受信側がそれを同等として受け入れることを許し、送信側には使わないよう求めた。既存実装の証拠を読める状態にしつつ、将来の送信形式を IETF 割当に一本化した。

IANA レジストリの役割は値の意味を安定させることだ。登録は普及率も、個々の報告の正しさも証明しない。peer が報告を作り、レジストリが解読方法を与え、PPP 状態とパケットが反証可能性を与える。

課金には別の時間軸があった

RFC は原因情報が accounting と debug に有用だとした。有用であることと、決済を確定することは違う。RADIUS のトンネル accounting にはセッション相関、Start、Interim、Stop、カウンターという別の記録がある。PPP 原因は Stop の背景を説明できても、Stop 到着、カウンター完全性、請求の妥当性を証明しない。

データ面の受け取りも必要だ。echo timeout はパケットカウンターやアラームと比較し、認証原因は秘密を広げずに状態遷移と比較し、通常終了は実際の LCP 交換と比較する。コードは調査先を示す索引であって、調査結果そのものではない。

利用者表示も、生成、配送、閲覧を分ける。説明文を作れたことから、読者が見たことを推定してはならない。

実装が異議を申し立てられる設計

RFC 3145 は、小さな相互運用仕様に権力の限界を埋め込んだ。コードは共有記号、CDN は記録された行為、PPP 状態とパケットは稼働実態、accounting と利用者体験は結果である。公式な番号を持つ層が、他の層を代理することはできない。

現代の監視基盤も、コンポーネントの reason から話者と方向を落とし、読みやすい一文を作って全体原因に昇格させがちだ。2001 年の設計はそれより慎重だった。理由はトンネルを渡れたが、現実を裁定する権限は渡れなかった。

出典