要約

  • PPP セッションを Frame Relay 上で運ぶには、L2TP の識別、トンネルと PVC／SVC の対応、回線端点、必要なフレーム長を RFC 3070 が明示しなければならなかった。
  • 仕様は可搬なトンネル／セッションと、それを実際に支える回線を分けて扱った。開通、QoS、セキュリティ、利用者の結果は別々の権限領域に残った。

短い文書が示した「独立」の条件

2001 年 2 月に発行された RFC 3070 は、Layer Two Tunneling Protocol を Frame Relay 上で運ぶ方法を定めた。ダイヤルアップ接続とキャリアの仮想回線網が身近だった時代の、小さなカプセル化仕様に見える。しかし、そこで扱われた問いは今も古びていない。プロトコルが「媒体非依存」であるとは、何からどこまで独立したことを指すのか。

L2TP では、利用者に近い L2TP Access Concentrator（LAC）から始まる PPP セッションを、L2TP Network Server（LNS）で論理的に終端できた。トンネルはセッションを中間媒体の細部から切り離す。とはいえ、上位層が非依存を宣言しただけで、パケットが Frame Relay を渡れるわけではない。仮想回線を設け、両端を指定し、運ばれるプロトコルを識別し、十分なフレーム長を用意する作業がなお必要だった。

RFC 3070 が記述したのは媒体の消滅ではなく、媒体が抽象化を支えるための接続契約だった。

セッションと仮想回線は別の実体だった

RFC 2661 は、L2TP の制御接続と、トンネル内で多重化される個々のセッションをすでに区別していた。トンネル ID とセッション ID は LAC と LNS の関係に属する。一方、Frame Relay には固有の対象がある。Permanent Virtual Circuit（PVC）は通常、局所的な Data Link Connection Identifier（DLCI）で識別される。Switched Virtual Circuit（SVC）はシグナリングで設定され、端点には X.121 または E.164 の情報が使われ得る。

双方の識別子は関連付けられても、同じものではない。L2TP のトンネル ID はキャリア回線を開通させない。DLCI は、どの利用者の PPP セッションが流れるかを説明しない。SVC を呼び出せる宛先が分かっても、遠端 LNS にそのトラフィックを受け取る権限があるとは限らない。

RFC 3070 が示す二つの対応方法に、この違いがよく表れている。SVC の場合、L2TP トンネルの生成が Frame Relay 回線の設定を引き起こす。ただし、具体的なトリガーは実装依存で、既存の Frame Relay シグナリング手順は変更されない。PVC の場合、L2TP 端点間の回線を管理者があらかじめ設定する。DLCI はローカル設定だけでなく、RFC 2868 の RADIUS トンネル属性を含む認可系から与えることもできた。

「トンネルが上がった」という一言には、制御イベント、認可判断、伝送回線という異なる事実の対応付けが折り畳まれていた。

媒体非依存を作った媒体固有の番号

L2TP は他のプロトコルと同じ Frame Relay 仮想回線を共有できなければならない。受信側には到着したものを曖昧なく見分ける手掛かりが必要だった。規定されたフレームは Q.922 アドレスに続いて SNAP ヘッダーを置き、NLPID 0x80、IANA の組織識別子 0x00-00-5E、L2TP のプロトコル識別子 0x0007 を使う。

これらは単なるレジストリ上の細目ではない。二つの仕組みをつなぐ公開された継ぎ目である。番号がなければ回線はバイト列を運べても、同居する別プロトコルから L2TP を確実に区別できない。上位層の可搬性は、下位媒体に固有の精密な印を設けることで成立した。

RFC 1490 と、その後継 RFC 2427 は、より広いマルチプロトコル・カプセル化の枠組みを提供していた。RFC 3070 はその機構を置き換えず、登録された場所を一つ占めた。インターネットの抽象化にはこの構造が繰り返し現れる。上位層は、狭く安定した下位インターフェースに依存することで自由を得る。依存は限定され、検証しやすくなるが、消滅はしない。

取り除かれた外枠は証拠としても残らない

PPP フレームを L2TP に入れる際、物理リンクのフレーミング、透過化処理、Frame Check Sequence は除かれ、PPP の内容がカプセル化される。遠端がアクセス回線の電気的・リンク固有の印をすべて再現する必要はない。その代わり、後段のパケットは物理的な来歴を完全には保存しない。

運用者は残されたトンネル状態とセッション情報を確かめられる。しかし、L2TP ペイロードだけから元の回線品質、具体的なフレーミング、カプセル化前に起きた異常を復元することはできない。抽象化の境界は、実行だけでなく観測可能な証拠も変えた。

MTU も媒体の存在を露呈した。Frame Relay 側で分割しないなら、最低条件を満たす L2TP データグラムのために少なくとも 1,526 オクテットが必要であり、PPP ピアが一般的な 1,500 オクテットの MRU を使う場合は 1,564 オクテットが推奨された。制限をどのように交渉・強制するかは実装に委ねられた。

制御面が成功を示していても、利用者のパケットは具体的な MTU で落ち得る。設計上の媒体非依存は、エンドツーエンド配送の証明ではなかった。

品質と信頼は標準番号から生まれない

RFC 3070 はこの対応の QoS を標準化しなかった。ベンダー独自の仕組みがあることを記し、将来の共通標準が適用される可能性を示すにとどめた。Frame Relay にこの用途の標準セキュリティ機構がないことも認め、L2TP 本体のセキュリティ考慮事項を参照した。

これは重要性の否定ではなく、権限の境界である。遅延、損失、輻輳、分離、機密性は依然として運用品質を左右する。キャリアは回線を開通し、機器ベンダーは優先制御を提供し、L2TP 運用者は認証や IP 層の保護を選び、サービス担当者は結果を計測できる。しかし SNAP のプロトコル値は、それらの能力を自動的に一つの主体へ与えない。

制御は分散していた。IANA は登録値を管理し、IETF は相互運用可能な振る舞いを定める。Frame Relay の事業者や管理者は回線を、LAC／LNS の管理者はトンネルを扱う。認可サービスは属性を渡し、実装は発呼トリガーや制限適用を決める。サービスを体験する利用者は、経路も診断証拠の大半も支配しない。

後継 RFC は旧回線を自動移行しない

RFC 3931 は後に L2TPv3 を一般化し、より多様なレイヤー 2 サービスを疑似回線で運べるようにした。この発展は、エミュレートするサービスと下位パケット網を分離する価値を示す。だが RFC 3070 の実装が自動的に移行したことや、旧来の依存がすべて新設計へ吸収されたことの証拠にはならない。

文書の世代交代とインフラの世代交代は別である。RFC が歴史文書になっても回線は稼働し続け得る。逆に、キャリア網が廃止された後に RADIUS 属性、設定バックアップ、障害対応の前提だけが残ることもある。歴史を確かめるには、その時点の現行 RFC だけでなく、どの実行上・管理上の依存が個別サービスを支配していたかを問う必要がある。

Lu Heng の running code 原則は証明の限界を見定める助けになる。動作する実装は、定義されたインターフェースを実現できることを示す。回線が正しく開通したこと、端点が正当に認可されたこと、MTU が全通信を満たすこと、利用者が約束された結果を得たことまでは証明しない。現実を層に分ける視点も、トンネル ID、設定済み DLCI、成功したシグナリング、配送された一個のパケット、実用になる接続を、関係はあっても別の事実として扱うよう求める。

RFC 3070 の歴史的な強さは、この差を隠さなかった点にある。Frame Relay がなお果たすべき仕事を具体的に記したからこそ、L2TP は媒体非依存になれた。トンネルは回線を借りていた。その借用関係を見える状態に保つことが、抽象化の信頼性だった。

出典