要約

  • RFC 3437 では LAC が望ましい LCP オプションと許容可能なオプションを LNS に送り、交渉後に LNS が最後に送受信した Configure-Request を返した。
  • 四つの AVP は知識と証拠を移すが、権限は移さない。希望は許可ではなく、パケットはサービス結果ではなく、必須化は旧装置との接続を失わせ得た。

回線を見られる側がセッションを決めなかった

LAC は物理インターフェースの MRU、ACCM、PFC、ACFC、FCS を知っていた。遠隔の LNS は PPP セッションを終端し LCP を動かした。基本の L2TP が伝えたのは同期・非同期、デジタル・アナログといった粗い情報であり、ローカルのフレーミング条件すべてではなかった。

2002 年 12 月の RFC 3437 はこの非対称性を扱う。本文、RFC Editor、Datatracker、履歴、参照文献、後続文献、正誤表が示すのは文書の記録であり、実装実績ではない。

Proxy LCP は古くなり得た

PPP は Configure-Request と応答でリンクを作り、HDLC 型フレーミングは各選択を媒体に結び付ける。LCP 拡張と CHAPが示すように、認証まで LAC が決めるべきではなかった。

LAC は先に Proxy LCP を行えたが、認証方針は LNS にあり、MRU は両端の制約を受け、PPP 相手は後から LCP を再開できた。そこで LAC は Proxy AVP を省略して LNS に直接交渉させることも、proxy 結果と新 AVP を併用することもできた。

四つを一つの状態にしない

ICCN または OCCN の LCP Want Options（49）は LAC の希望、LCP Allow Options（50）は物理側が耐えられる境界だった。許容は希望ではなく、希望は合意でもない。

LCP 完了後、Set-Link-Info の LNS Last Sent LCP Confreq（51）と LNS Last Received LCP Confreq（52）が、Code フィールドから始まる完全な LCP パケットを返した。前二つはローカル知識を制御側へ、後二つは交渉証拠をエッジへ運ぶ。Want または Allow を送る LAC は帰りの AVP を処理できなければならなかった。

この二つのパケットも認証、ネットワーク層設定、課金、到達性、アプリケーション成功を証明しない。交渉メッセージの受領証であって、利用結果の受領証ではない。

オプション性は可用性の選択だった

四つは既定で非 mandatory だった。M ビットを立てれば、未知の相手はセッションを終了し得る。RFC は拡張なしでは全く運用できない場合を除き、それを勧めなかった。観測性の強制には接続性という費用があった。

既存 Proxy AVP を再利用せず新番号を割り当てたのは、古い実装が「知っている AVP があり得ないメッセージにある」ことをエラーにする恐れがあったからだ。IANA の L2TP と PPP 登録は割当証拠で、運用証拠ではない。

オプションはインターフェース特性やトポロジーを漏らし得たが、類似情報は既に LCP に現れた。RFC 3145、RFC 3193、RFC 3438、RFC 3931は別の L2TP 境界を示すが、サービス成功を補証しない。

証拠を方向付きで残す

Heng Lu の現実レイヤーは、意図、制約、メッセージ、リンク状態、結果を分ける。動くコードの優先は未知 AVP と再交渉の試験を求め、最小初期仕様は四つの記録の節度を読む手掛かりになる。いずれも後世の分析である。

RFC 3437 は遠隔制御を全知に見せなかった。何を望み、何を許し、何が交換されたかを別々に保存したからこそ、制御を検証可能にした。

情報源