要約

  • RFC 3573は、V.92モデムが保留に入ったこと、交渉済みの最長保留時間、オンライン復帰をLACからLNSへ伝える。通知は観測された状態であり、LNSの動作や上位サービスの生存を保証しない。
  • 復帰通知と復帰後の最初の有効パケットは別経路を進む。制御メッセージが現実より遅れるため、保存中の「保留」を理由にデータを捨てると、回復そのものを壊しかねない。

ファイルの受信中に電話が鳴る。V.92対応モデムなら、データ通話をいったん保留し、同じ電話線で音声通話を行い、再ダイヤルせずに戻れる。モデムの直近にいる装置には変化が見える。離れた場所でPPPセッションを終端する装置には見えない。

L2TPでは、この二つの役割がLACとLNSに分かれる。サーバーモデムを収容するLACは物理アクセスの変化を知り、LNSはパケットネットワークの向こうでセッション、タイマー、課金を扱う。RFC 3573は両者の間に、必要最小限の状態通知を加えた。

2003年7月に公開され、現在もRFC EditorでProposed Standardとされる文書の価値は、通知の効力を誇張しなかった点にある。能力、保留状態、時間の上限は共通化する。一方、受信後に何を行うかはLNSの実装判断として残す。

受け取れる相手にだけ送る

LNSは制御接続の開始時、SCCRQまたはSCCRPにModem On-Hold Capable AVPを入れて対応能力を示す。LACは、その宣言をしていないLNSへModem-Status（MDMST）を送ってはならない。

ただし能力宣言は、拡張を解釈できるという表明にすぎない。後の状態が必ず届くこと、正しく処理されること、課金やアプリケーションへ一貫して反映されることは証明しない。

MDMSTを送れるのはセッション確立後から終了前までである。LNSがすでにCall-Disconnect-Notifyを送ったなら、その後に届くMDMSTは無視する。遅着したアクセス状態が、終了済みセッションを復活させてはならない。

Holdビットと時間上限

クライアントモデムが保留を求めたとき、LACはH=1と交渉済みの最長保留時間を送る。オンラインへ戻ればH=0を送る。先にH=1を報告していた場合、解除通知は必須である。

状態AVPは16ビットで、Holdに1ビット、V.92のTimeoutに4ビットを使い、残りは予約される。Timeoutには10秒から16分までと「制限なし」があるが、意味を持つのはH=1のときだけだ。H=0なら無視しなければならない。

ここで「最長」を「実績」に読み替えてはいけない。Timeoutは経過時間ではなく、LNSが同じタイマーを実行した証拠でもない。回線が上限まで復帰可能であるという保証でも、パケットや課金を維持したという証明でもない。

監査用の記録には、生のビット列、解釈、トンネルとセッションの識別子、送受信時刻、重複判定、配送結果、切断との前後関係が要る。単一のon_hold列では、判断に必要な因果関係が失われる。

通知を受けた後はローカル方針

RFCはLNSの処置を命令しない。LCP Echo、Link Quality Monitoring、Multilink PPPのポーリングを止める案、クライアント向けパケットを破棄する案、保留時間を別会計にする案、課金を停止する案を例示する。それぞれが別の運用結果を生み、同時には成立しない選択もある。

一方、避けるべき処置は理由まで明示される。パケットを無制限にためれば、復帰時の遅延放出がTCPへ悪影響を与えうる。クライアントの代わりにTCP keepaliveへ応答すれば、不在を隠し、復帰処理を妨げうる。

最も重要なのは、LACから届く正当なクライアントパケットを、保留状態だけを理由に処理停止してはならないという規則だ。復帰を知らせる制御メッセージと最初のデータは独立したチャネルで届く。データが先なら、それこそが端末復帰の直接証拠である。H=0を待つ実装は、証拠を捨てて回復を遅らせる。

正常な通知列と失敗した利用体験は両立する

MDMSTが完全に届いても、TCPは保留中にタイムアウトできる。アプリケーションは転送を断念できる。LNSは下りパケットを捨てられる。会計セッションは続けることも、止めることも、分割することもできる。制御面の成功は、利用者の作業完了を含まない。

反対に、保存状態が保留のままでも、有効データはすでに戻っているかもしれない。状態だけを見る監視は実トラフィックを異常扱いし、パケットだけを見る監視は中断理由を失う。モデム交渉、LAC観測、通知配送、LNS方針、双方向パケット、復帰、PPP、TCP、アプリケーション、課金を別の証跡として持ち、同じセッションに結び付ける必要がある。

保護された通知にも意味の限界がある

RFC 3573は完全性と機密性をL2TPの基盤に依存し、AVPを隠すことも認める。RFC 3193はL2TPをIPsecで保護する方法を規定した。これにより、認証された相手が特定のバイト列を送ったことは強く示せる。

しかし、物理モデムが本当に保留だったこと、LACの観測が正確だったこと、LNSの方針が妥当だったこと、アプリケーションが完了したことまでは証明できない。暗号は配送経路を保護するが、隣接する運用事実を代筆しない。

IANAレジストリには現在もMessage Type 17、AVP Attribute 53と54が残る。番号の存続は名前空間の調整を示すだけで、現役の導入率ではない。付録の初期ベンダー固有番号も、歴史的かつ非規範的だと明記されている。

証拠の境界

本稿はISP、LAC、LNS、モデム企業、加入者、電話事業者、実セッション、障害、請求結果、普及率を特定しない。RFCが定めた契約と、その文書自身が示す限界だけを扱う。

RFC 2661はL2TP、RFC 1661はPPPの基礎、RFC 1989と1990は例示された監視、RFC 2865、2866、2869は認証・会計の周辺、RFC 3193は通信保護の境界を与える。RFC 3931は後年のL2TPv3という文脈に限る。IANAとITU-T V.92の記録も、識別子と参照仕様の存在を示すだけで結果を示さない。

Lu HengのRunning-Code PrimacyとMinimum Initial Specificationは、宣言を稼働結果で検証し、共通仕様をローカル方針より小さく保つための編集上の視点として開示する。RFC著者の意図や導入実績の証拠ではない。

一時状態は、命令でも結果でもないから役に立つ。通知、ローカル判断、その後のパケット、利用者の結果をそれぞれ保存し、前の層に次の層の成功を語らせないことが、RFC 3573から引き出せる現在的な規律である。

出典