要約

  • RFC 3355 は L2TP を ATM AAL5 仮想回線へ写像したが、一つの L2TP PDU を一つの AAL5 PDU に収めるよう要求したため、外側の MTU がトンネルと全 PPP セッションを制約した。
  • カプセル化の選択、VC の確立・消去、保護はベアラ側の事実だった。方式の合意は内側の成功を証明せず、SVC の消去は利用者セッションを終了させた。

トンネルの利用者には、遠隔の相手が一本の単純なリンクの先にいるように見える。その背後で ATM が回線を設定し、AAL5 がメッセージ境界を作っていても、PPP は詳しく知る必要がない。ところが送る単位が外側の開口より大きければ、その抽象化は通り道を広げてはくれない。

2002 年 8 月の RFC 3355 は、Layer Two Tunnelling Protocol を ATM Adaptation Layer 5 上で運ぶ Standards Track 仕様だった。L2TP 基本仕様は媒体の詳細から大きく独立し、パケット指向のポイントツーポイント接続だけを必要とした。LAC と LNS の間の AAL5 仮想回線はそのサービスになり得た。

媒体固有の境界は明快だった。各 L2TP PDU は単一の AAL5 PDU に入らなければならない。AAL5 接続の MTU が L2TP トンネルの MTU を制約し、そのトンネルを使うすべての PPP 接続の MRU にまで制約が伝わった。

内側ではセッションが別々に見えても、外側では一つの包みを共有する。認証やアドレスや利用者が違っても、完全な L2TP 単位は同じ AAL5 境界を越える。媒体を隠す機能は、媒体より大きな容量を生成する機能ではなかった。

実装には 1500 オクテット以上の PPP MRU 対応が必須で、PPP PDU 内に 9180 オクテット以上の IP パケットを収められることが推奨された。これは能力条件と設計推奨である。特定 PVC の設定、SVC の選択値、PPP の交渉結果、実パケットの到達を示す受領記録ではない。

装置仕様に 9180 と書かれていても、あるセッションがその大きさを通せたとは限らない。外側ヘッダー、実際の VC パラメータ、相手の MRU、別の経路制約、断片化や破棄を観測する必要がある。小さな監視パケットの成功は大きな単位を代弁しない。

AAL5 サービスはビット同期、全二重、ポイントツーポイントとして扱われた。VC は設定済みの PVC でも、要求時に確立する SVC でもよい。非保証の message mode を用い、破損配送オプションは使わず、境界ではオクテット単位だけを扱った。

メッセージ境界と CRC があっても、それは信頼できる配送全体ではない。正しい長さと CRC は AAL5 層の枠を確認するが、送信者の認証、機密性、L2TP 制御の受理、アプリケーション到達を確認しない。

中身のプロトコル識別には二方式があった。LLC/SNAP 方式は各 AAL5 PDU に IANA の L2TP 識別子を明示した。VC 多重方式ではヘッダーを省き、回線が L2TP を運ぶという事前合意に意味を置いた。識別がパケット内にあるか、回線文脈にあるかの違いである。

PVC 上の LLC は必須対応だった。SVC 上の LLC と、PVC/SVC 上の VC 多重は任意だった。PVC の両端は同じ方式に設定しなければならない。両装置が L2TP 対応でも、回線文脈が食い違えば同じバイト列を同じものとして読めない。

SVC では ATM 制御面が B-LLI 情報要素で方式を交渉した。発信側は LLC、VC 多重、または両方を希望順に提示できた。両方を提示して呼が受理された場合、着信側は一つだけ選ぶ。非対応方式だけなら拒否する。

選択成功が証明するのは、その接続確立で AAL5 ペイロードの読み方が一つ決まったという事実だけだ。L2TP 制御接続、PPP 認証、サイズ適合、データ配送、アプリケーション結果は別の証拠を要する。

SVC のリセットは抽象化の寿命を露出させる。基本 L2TP 手順で SVC トンネルをリセットすると、両端は SVC を消去し、トンネル上の全利用者セッションが終了した。後のクライアント要求で再確立を試せても、それは旧セッションの透明な継続ではない。

逆に AAL5 SVC の消去通知を受ければ、実装はトンネルを解体して制御接続を idle に戻す必要があった。外側の回線イベントが内側の状態を変えた。ベアラは背景ではなく依存先だった。

接続設定失敗の後、相手をいつ到達不能と見なすか、いつ復帰と判断するかは実装判断だった。利用セッションがなければどちら側も SVC を消去できた。到達不能、idle、clear という表示には、観測層、原因イベント、接続世代を付けなければならない。

QoS も同様だった。異なる利用者品質のため複数 AAL5 接続を使うことは可能だったが、複数 VC に一トンネルを逆多重する方式は将来課題だった。PVC パラメータは合意され、SVC パラメータは要求された。要求値は実測サービスの証明ではない。

セキュリティも正しい枠組みから自動的には得られない。RFC 3355 は ATM 輸送網への攻撃がトンネルを損なう可能性を述べ、認証ヘッダー、暗号化ペイロード、ATM 層の保護を示した。PID、B-LLI、CRC が正しくても、暗号学的な保護とは限らない。

RFC 2661 は L2TP のトンネルとセッション、RFC 1661 は PPP と MRU、RFC 2684 は AAL5 の LLC と VC 多重、RFC 2364 は AAL5 上の直接 PPP、RFC 2331 は ATM 信号方式を扱う。RFC 3070 は Frame Relay という別ベアラの写像である。RFC 3193 は IPsec 状態を追加し、RFC 4459 は後に一般的なトンネル MTU 問題を整理した。

IANA の L2TP レジストリは値を調整するが、実装や通信を証明しない。これらの資料から RFC 3355 の採用、実測性能、障害、復旧を推定してはならない。

RFC 3355 は抽象化の限界を失敗としてではなく契約として示した。上位層は ATM を知らずに動ける。だが AAL5 VC は、一つの包みの大きさ、その識別方法、回線消去時に何が終わるかを決め続けた。隠すことと、支配を失わせることは別だった。

Sources