RFC 2661 - Layer Two Tunneling Protocol (L2TP)

ステータス: Proposed Standard
発行日: August 1999
ストリーム: IETF
エラッタ: エラッタなし

概要 (Abstract)

本文書は、Layer Two Tunneling Protocol (L2TP) について説明します。STD 51、RFC 1661は、PPPによるマルチプロトコルアクセスを規定しています。L2TPは、エンドユーザーとアプリケーションにとって可能な限り透過的な方法で、中間ネットワークを越えてPPPパケットをトンネリングすることを容易にします。

目次 (Contents)

1. Introduction (はじめに)
- 1.1 Specification of Requirements (要件仕様)
- 1.2 Terminology (用語)
2. Topology (トポロジー)
3. Protocol Overview (プロトコル概要)
- 3.1 L2TP Header Format (L2TPヘッダーフォーマット)
- 3.2 Control Message Types (制御メッセージタイプ)
4. Control Message Attribute Value Pairs (制御メッセージ属性値ペア)
- 4.1 AVP Format (AVPフォーマット)
- 4.2 Mandatory AVPs (必須AVP)
- 4.3 Hiding of AVP Attribute Values (AVP属性値の隠蔽)
- 4.4 AVP Summary (AVP要約)
  - 4.4.1 AVPs Applicable To All Control Messages (すべての制御メッセージに適用可能なAVP)
  - 4.4.2 Result and Error Codes (結果およびエラーコード)
  - 4.4.3 Control Connection Management AVPs (制御接続管理AVP)
  - 4.4.4 Call Management AVPs (コール管理AVP)
  - 4.4.5 Proxy LCP and Authentication AVPs (プロキシLCPおよび認証AVP)
  - 4.4.6 Call Status AVPs (コールステータスAVP)
5. Protocol Operation (プロトコル動作)
- 5.1 Control Connection Establishment (制御接続確立)
  - 5.1.1 Tunnel Authentication (トンネル認証)
- 5.2 Session Establishment (セッション確立)
  - 5.2.1 Incoming Call Establishment (着信コール確立)
  - 5.2.2 Outgoing Call Establishment (発信コール確立)
- 5.3 Forwarding PPP Frames (PPPフレームの転送)
- 5.4 Using Sequence Numbers on the Data Channel (データチャネルでのシーケンス番号の使用)
- 5.5 Keepalive (Hello) (キープアライブメカニズム)
- 5.6 Session Teardown (セッション切断)
- 5.7 Control Connection Teardown (制御接続切断)
- 5.8 Reliable Delivery of Control Messages (制御メッセージの信頼性のある配信)
6. Control Connection Protocol Specification (制御接続プロトコル仕様)
- 6.1 Start-Control-Connection-Request (SCCRQ)
- 6.2 Start-Control-Connection-Reply (SCCRP)
- 6.3 Start-Control-Connection-Connected (SCCCN)
- 6.4 Stop-Control-Connection-Notification (StopCCN)
- 6.5 Hello (HELLO)
- 6.6 Incoming-Call-Request (ICRQ)
- 6.7 Incoming-Call-Reply (ICRP)
- 6.8 Incoming-Call-Connected (ICCN)
- 6.9 Outgoing-Call-Request (OCRQ)
- 6.10 Outgoing-Call-Reply (OCRP)
- 6.11 Outgoing-Call-Connected (OCCN)
- 6.12 Call-Disconnect-Notify (CDN)
- 6.13 WAN-Error-Notify (WEN)
- 6.14 Set-Link-Info (SLI)
7. Control Connection State Machines (制御接続状態機械)
- 7.1 Control Connection Protocol Operation (制御接続プロトコル動作)
- 7.2 Control Connection States (制御接続状態)
  - 7.2.1 Control Connection Establishment (制御接続確立)
- 7.3 Timing considerations (タイミングに関する考慮事項)
- 7.4 Incoming calls (着信コール)
  - 7.4.1 LAC Incoming Call States (LAC着信コール状態)
  - 7.4.2 LNS Incoming Call States (LNS着信コール状態)
- 7.5 Outgoing calls (発信コール)
  - 7.5.1 LAC Outgoing Call States (LAC発信コール状態)
  - 7.5.2 LNS Outgoing Call States (LNS発信コール状態)
- 7.6 Tunnel Disconnection (トンネル切断)
8. L2TP Over Specific Media (特定メディア上のL2TP)
- 8.1 L2TP over UDP/IP
- 8.2 IP
9. Security Considerations (セキュリティに関する考慮事項)
- 9.1 Tunnel Endpoint Security (トンネルエンドポイントセキュリティ)
- 9.2 Packet Level Security (パケットレベルセキュリティ)
- 9.3 End to End Security (エンドツーエンドセキュリティ)
- 9.4 L2TP and IPsec
- 9.5 Proxy PPP Authentication (プロキシPPP認証)
10. IANA Considerations (IANAに関する考慮事項)
- 10.1 AVP Attributes
- 10.2 Message Type AVP Values
- 10.3 Result Code AVP Values
  - 10.3.1 Result Code Field Values
  - 10.3.2 Error Code Field Values
- 10.4 Framing Capabilities & Bearer Capabilities
- 10.5 Proxy Authen Type AVP Values
- 10.6 AVP Header Bits
11. References (参考文献)
12. Acknowledgments (謝辞)
13. Authors' Addresses (著者アドレス)

付録 (Appendices)

7. 制御接続状態機械 (Control Connection State Machines)

本章では、L2TP 制御接続とセッションの確立、維持、切断の状態機械を定義します。

7.1 制御接続プロトコル操作 (Control Connection Protocol Operation)

制御接続状態機械は、トンネルの確立と切断の状態遷移を説明します。各状態は受け入れ可能なイベント、対応するアクション、および次の状態を定義します。

7.2 制御接続の状態 (Control Connection States)

制御接続には以下の状態があります。

idle: 初期状態、接続未確立
wait-ctl-reply: ピアからの制御接続応答を待機中
wait-ctl-conn: 制御接続の完了を待機中
established: 制御接続が確立済み
closing: 制御接続を閉じている最中

7.2.1 制御接続の確立 (Control Connection Establishment)

制御接続の確立は 3 ウェイハンドシェイク（SCCRQ、SCCRP、SCCCN）を使用して完了します。状態遷移は以下の通りです。

idle → wait-ctl-reply（SCCRQ を送信）
wait-ctl-reply → wait-ctl-conn（SCCRP を受信）
wait-ctl-conn → established（SCCCN を受信）

7.3 タイミングの考慮事項 (Timing Considerations)

再送タイマー: 信頼性のある転送のための制御メッセージ再送
Hello 間隔: 定期的な Hello メッセージ送信の間隔
タイムアウト検出: トンネル障害を検出するタイムアウトメカニズム

7.4 着信呼 (Incoming Calls)

着信呼の確立には LAC と LNS の協調した状態遷移が含まれます。

7.4.1 LAC 着信呼の状態 (LAC Incoming Call States)

LAC 側の着信呼の状態：

idle: アクティブな呼なし
wait-reply: LNS からの ICRP を待機中
wait-connect: 呼の接続を待機中
established: セッションが確立済み

7.4.2 LNS 着信呼の状態 (LNS Incoming Call States)

LNS 側の着信呼の状態：

idle: アクティブな呼なし
wait-connect: LAC からの ICCN を待機中
established: セッションが確立済み

7.5 発信呼 (Outgoing Calls)

発信呼は LNS によって開始され、LAC が実際の呼操作を実行します。

7.5.1 LAC 発信呼の状態 (LAC Outgoing Call States)

LAC 側の発信呼の状態：

idle: アクティブな呼なし
wait-reply: OCRQ への応答を待機中
wait-cs-answer: 呼の応答を待機中
established: セッションが確立済み

7.5.2 LNS 発信呼の状態 (LNS Outgoing Call States)

LNS 側の発信呼の状態：

idle: アクティブな呼なし
wait-reply: LAC からの OCRP を待機中
wait-connect: OCCN を待機中
established: セッションが確立済み

7.6 トンネルの切断 (Tunnel Disconnection)

トンネルの切断は LAC または LNS が StopCCN メッセージを送信することで開始できます。StopCCN を受信したピアはメッセージを確認し、関連するすべてのリソースをクリーンアップすべきです。

注：完全な状態遷移表と詳細な状態機械図については、RFC 2661 の原文を参照してください。本章では状態機械の概要と主要な状態遷移フローを提供します。

8. L2TP Over Specific Media (特定メディア上の L2TP)

本章では、特定のメディアタイプ上での L2TP の実装詳細について説明します。L2TP は、UDP/IP、フレームリレー、ATM など、さまざまなパケット転送メディア上で動作するように設計されています。

8.1 L2TP over UDP/IP (UDP/IP 上の L2TP)

L2TP は、トンネルエンドポイント間の通信に登録された UDP ポート 1701 を使用します。UDP は、L2TP 制御メッセージとデータメッセージの両方にパケット転送サービスを提供します。

ポート割り当て:

送信元ポート: 送信側は、送信元ポートとして使用可能な任意の UDP ポートを使用できます。
宛先ポート: UDP ポート 1701 を使用する必要があります。

パケットカプセル化:

UDP/IP 上の L2TP パケットのカプセル化形式は次のとおりです:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    IP ヘッダー                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   UDP ヘッダー                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   L2TP ヘッダー                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              L2TP 制御メッセージまたは              |
|                  PPP ペイロード                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

UDP チェックサム:

UDP チェックサムは、すべての L2TP パケットで計算され、含まれる必要があります。受信側は、存在する場合、チェックサムを検証する必要があります。チェックサム検証が失敗した場合、パケットは破棄される必要があります。

MTU に関する考慮事項:

L2TP は追加のカプセル化レイヤー (L2TP ヘッダー + UDP ヘッダー + IP ヘッダー) を追加するため、実装ではパス MTU を考慮する必要があります。典型的なカプセル化オーバーヘッド:

IP ヘッダー: 20 バイト (IPv4) または 40 バイト (IPv6)
UDP ヘッダー: 8 バイト
L2TP ヘッダー: 最低 6 バイト（オプションに応じてそれ以上）

フラグメンテーション:

L2TP 実装では、IP フラグメンテーションを避けることが推奨されます。これは次の方法で実現できます:

パス MTU ディスカバリー
トンネル確立時に MRU (最大受信単位) を交渉する
IP レイヤーではなく PPP レイヤーでフラグメンテーションを実行する

8.2 IP (インターネットプロトコル)

L2TP パケットは、パケット転送プロトコルとして IP を使用します。IP は、L2TP にエンドツーエンドのパケット転送サービスを提供します。

IP バージョンサポート:

L2TP は、IPv4 [RFC791] と IPv6 [RFC2460] の両方で動作するように設計されています。実装は、少なくとも 1 つの IP バージョンをサポートする必要があり、オプションで両方をサポートできます。

IPv4 固有の考慮事項:

プロトコルタイプ: UDP カプセル化を使用する場合、IP プロトコルフィールドは 17 (UDP) に設定されます。
サービスタイプ (TOS): L2TP 実装は、サービス品質要件を示すために IP TOS フィールドを設定できます。制御メッセージは、データメッセージよりも高い優先度を必要とする場合があります。
生存時間 (TTL): パケットがネットワーク内で無限にループしないように、適切な TTL 値を設定する必要があります。

IPv6 固有の考慮事項:

次ヘッダー: UDP カプセル化を使用する場合、17 (UDP) に設定されます。
フローラベル: IPv6 フローラベルを使用して、同じトンネルに属するパケットフローを識別し、QoS 処理を行うことができます。
ホップリミット: IPv4 の TTL に相当します。

アドレス選択:

LAC と LNS は、ピアの IP アドレスを決定できる必要があります。これは次の方法で実現できます:

静的設定
DNS 解決
動的検出メカニズム

マルチホーミングに関する考慮事項:

トンネルエンドポイントに複数の IP アドレス (マルチホーム) がある場合、実装では、トンネルのすべてのパケットが一貫した送信元アドレスを使用することを確認する必要があります。これは、トンネル状態を維持し、混乱を防ぐために重要です。

セキュリティ:

L2TP が IP 上で動作する場合、トンネルトラフィックを保護するために IPsec [RFC2401] を使用することを強く推奨します。IPsec は次を提供できます:

機密性: ESP 暗号化による
完全性: AH または ESP 認証による
エンドポイント認証: IKE による

詳細なセキュリティ考慮事項については、第 9 章を参照してください。

実装上の注意:

ポート多重化: 同じ IP アドレスペア間で複数のトンネルを確立でき、トンネル ID で区別されます。
NAT トラバーサル: L2TP が NAT デバイスを通過する必要がある場合、追加のメカニズム (L2TP/IPsec NAT-T など) が必要になる場合があります。
ファイアウォールに関する考慮事項: ファイアウォールは、L2TP をサポートするために UDP ポート 1701 での双方向通信を許可する必要があります。
QoS マッピング: 実装では、PPP レイヤーからの QoS 要件を IP レイヤーの DSCP または TOS フィールドにマッピングできます。

9. Security Considerations (セキュリティに関する考慮事項)

L2TP プロトコル自体は、暗号化や強力な認証サービスを提供しません。本章では、L2TP 展開におけるセキュリティ考慮事項と利用可能なセキュリティメカニズムについて説明します。

9.1 Tunnel Endpoint Security (トンネルエンドポイントのセキュリティ)

トンネルエンドポイント間の信頼関係は、L2TP セキュリティの基礎です。

エンドポイント認証:

LAC と LNS は、互いの身元を検証できる必要があります。L2TP は、オプションのトンネル認証メカニズムを提供します:

Challenge AVP: 開始側は SCCRQ (制御接続開始要求) でランダムなチャレンジ値を送信します。
Challenge Response AVP: 応答側は共有秘密に基づいて応答を計算し、SCCRP (制御接続開始応答) で返します。
応答計算: MD5 ハッシュ関数を使用: MD5(メッセージタイプ + 共有秘密 + チャレンジ + セッションID)

共有秘密の管理:

共有秘密は十分なエントロピーを持つべきです (少なくとも 128 ビット推奨)。
共有秘密は安全に保存されるべきです (暗号化ストレージ)。
共有秘密は定期的に変更されるべきです。
異なるトンネルペアは異なる共有秘密を使用すべきです。

トンネル認可:

認証に加えて、認可メカニズムを実装すべきです:

ピアがトンネルを確立することを許可されているかを検証します。
ピアが特定のリソースまたはサービスへのアクセス権限を持っているかを確認します。
アクセス制御リスト (ACL) を使用して、どのピアがトンネルを確立できるかを制限します。

脆弱性と緩和策:

中間者攻撃:
- リスク: L2TP トンネル認証は共有秘密に基づいており、中間者攻撃に対して脆弱です。
- 緩和策: IPsec を使用してエンドツーエンドの暗号化と認証を提供します。
リプレイ攻撃:
- リスク: 攻撃者はキャプチャした制御メッセージをリプレイする可能性があります。
- 緩和策: シーケンス番号と ZLB ACK メカニズムを使用してリプレイ攻撃を検出および防止します。
サービス拒否攻撃:
- リスク: 攻撃者は大量のトンネル確立リクエストを送信する可能性があります。
- 緩和策:
  - 送信元アドレスあたりの同時トンネル数を制限します。
  - レート制限を実装します。
  - Cookie メカニズム (TCP SYN Cookie に類似) を使用します。

9.2 Packet Level Security (パケットレベルのセキュリティ)

L2TP 自体はパケット暗号化や完全性保護を提供しません。

平文送信のリスク:

盗聴: 攻撃者は PPP パケットの内容 (ユーザー資格情報やアプリケーションデータを含む) を傍受して読み取ることができます。
改ざん: 攻撃者は送信中のパケットを変更できます。
注入: 攻撃者はトンネルに悪意のあるパケットを注入できます。

AVP 隠蔽メカニズム:

L2TP は、機密性の高い制御情報を保護するための AVP 隠蔽メカニズムを提供します:

隠蔽プロセス:
1. 共有秘密とランダムベクトルを使用して MD5 ハッシュを生成します。
2. ハッシュ値と AVP 値を XOR 演算します。
3. AVP 値の長さが 16 バイトを超える場合、上記のプロセスを繰り返します。
制限事項:
- AVP 隠蔽は難読化であり、真の暗号化ではありません。
- データチャネルを保護せず、制御チャネルの特定の AVP のみを保護します。
- 辞書攻撃に対して脆弱です (共有秘密が弱い場合)。

推奨事項:

AVP 隠蔽を唯一のセキュリティメカニズムとして依存しないでください。
IPsec またはその他のトンネルレベルの暗号化技術を使用してください。

9.3 End to End Security (エンドツーエンドのセキュリティ)

L2TP トンネル自体が保護されている場合でも、エンドツーエンドのセキュリティは重要です。

PPP レベルの認証:

リモートシステムと LNS の間で独立した認証が行われるべきです:

PAP (パスワード認証プロトコル):
- シンプルな平文パスワード認証。
- 推奨されません。パスワードが平文で送信されるため (暗号化された L2TP トンネル内でも避けるべき)。
CHAP (チャレンジハンドシェイク認証プロトコル):
- チャレンジ-レスポンス認証メカニズム。
- パスワードは平文で送信されません。
- リプレイ攻撃を防ぐための定期的な再認証。
EAP (拡張可能認証プロトコル):
- さまざまな認証方法 (EAP-TLS, EAP-TTLS, PEAP など) をサポートします。
- 相互認証と鍵交渉を提供できます。
- EAP-TLS の使用を推奨します 最も強力なセキュリティを提供します。

エンドツーエンドの暗号化:

アプリケーション層の暗号化は追加のセキュリティ層を提供します:

TLS/SSL: アプリケーションデータの保護に使用 (例: HTTPS)。
VPN クライアントソフトウェア: PPP の上に追加の暗号化層を提供します。

多層防御戦略:

リモートシステム &lt;--PPP認証/暗号化--> LNS
    |                                    |
    +--&lt;L2TPトンネル>--LAC--------------+
              |
         &lt;IPsec保護>

レイヤー 1: PPP レベルの認証 (CHAP/EAP)
レイヤー 2: L2TP トンネル認証
レイヤー 3: IPsec 暗号化と認証
レイヤー 4: アプリケーション層の暗号化 (TLS/SSL)

9.4 L2TP and IPsec (L2TP と IPsec)

L2TP と IPsec を組み合わせて使用することを強く推奨します。この組み合わせは一般的に L2TP/IPsec と呼ばれます。

IPsec が提供するセキュリティサービス:

機密性:
- ESP (カプセル化セキュリティペイロード) 暗号化によって提供されます。
- 複数の暗号化アルゴリズムをサポート: AES, 3DES, ChaCha20 など。
完全性:
- AH (認証ヘッダー) または ESP 認証によって提供されます。
- HMAC (例: HMAC-SHA256) を使用してデータの完全性を検証します。
送信元認証:
- パケットソースの真正性を検証します。
- IP スプーフィング攻撃を防ぎます。
アンチリプレイ:
- シーケンス番号を使用してリプレイ攻撃を防ぎます。

L2TP/IPsec アーキテクチャ:

+-------------------+
|   PPP ペイロード  |
+-------------------+
|   L2TP ヘッダー   |
+-------------------+
|   UDP ヘッダー    |
+-------------------+
|   ESP ヘッダー    | &lt;-- IPsec 暗号化と認証
+-------------------+
|   IP ヘッダー     |
+-------------------+

IPsec 設定オプション:

トランスポートモード:
- IP ペイロードのみを暗号化および認証します。
- エンドツーエンド通信に適しています。
- L2TP/IPsec に推奨されます。
トンネルモード:
- IP パケット全体を暗号化および認証します。
- 新しい外部 IP ヘッダーを追加します。
- ゲートウェイ間通信に適しています。

鍵管理:

IKE (インターネット鍵交換):
- IKEv1: 元のバージョン、2 段階交渉。
- IKEv2: 改良版、より効率的で簡潔。
- IKEv2 の使用を推奨します 鍵交渉用。
事前共有鍵 vs 証明書:
- 事前共有鍵 (PSK): 設定が簡単ですが、鍵の配布が困難。
- 証明書: より安全で、大規模な展開をサポート、強く推奨されます。

NAT トラバーサル (NAT-T):

L2TP/IPsec が NAT デバイスを通過する必要がある場合:

ESP の UDP カプセル化を使用 (UDP ポート 4500)。
定期的に NAT キープアライブパケットを送信します。
IKEv2 には NAT-T サポートが組み込まれています。

パフォーマンスに関する考慮事項:

IPsec 暗号化は CPU オーバーヘッドを増加させます。
ハードウェアアクセラレーション (AES-NI など) の使用を検討してください。
MTU の減少を考慮する必要があります (ESP ヘッダー + ESP トレーラー + 認証データ)。

9.5 Proxy PPP Authentication (プロキシ PPP 認証)

L2TP は、LAC が LNS に代わって初期 PPP 認証を実行することを許可します。

プロキシ認証メカニズム:

LAC は、LNS に呼び出しを転送する前に、リモートシステムと LCP を交渉し、認証を実行できます:

LAC が PPP 認証を実行:
- LAC がリモートシステムと LCP を交渉します。
- LAC が PAP または CHAP 認証を実行します。
- LAC が認証情報 (ユーザー名、パスワードハッシュなど) を収集します。
LAC が認証情報を LNS に転送:
- プロキシ AVP を使用して認証情報を渡します:
  - Proxy Authen Type AVP (29): 認証タイプ (PAP, CHAP など)
  - Proxy Authen Name AVP (30): ユーザー名
  - Proxy Authen Challenge AVP (31): CHAP チャレンジ値
  - Proxy Authen Response AVP (33): 認証応答
LNS が認証情報を検証:
- LNS は LAC が提供した情報に基づいてユーザーを検証します。
- LNS はセッションを受け入れるか拒否できます。

セキュリティリスク:

LAC の侵害:
- LAC が侵害されると、攻撃者はユーザー資格情報を取得できます。
- 緩和策: IPsec を使用して LAC と LNS 間の通信を保護します。
平文パスワード送信:
- PAP パスワードは LAC から LNS へ平文で送信されます (AVP 内)。
- 緩和策: AVP 隠蔽メカニズムまたは IPsec 暗号化を使用します。
信頼境界:
- LNS は LAC が提供する認証情報を完全に信頼する必要があります。
- 悪意のある LAC は認証情報を偽造できます。
- 緩和策:
  - 信頼できる管理ドメイン間でのみプロキシ認証を使用します。
  - エンドツーエンドの再認証を要求することを検討してください。

ベストプラクティス:

プロキシ PAP 認証を避ける:
- PAP パスワードは隠蔽されていても攻撃に対して脆弱です。
- 使用する必要がある場合は、IPsec 保護を確保してください。
エンドツーエンド認証を優先する:
- リモートシステムが LNS と直接認証できるようにします (プロキシなし)。
- より強力なセキュリティのために EAP メソッドを使用します。
プロキシ認証の使用シナリオを制限する:
- 必要な場合にのみ使用します (例: 高速呼び出し確立)。
- 信頼できるネットワーク環境で使用します。
複数の認証方法を組み合わせて使用する:
- LAC が予備認証を実行します (迅速なフィルタリング用)。
- LNS が二次認証を実行します (エンドツーエンド検証)。

RADIUS 統合によるプロキシ認証:

リモートシステム &lt;--PAP/CHAP--> LAC &lt;--RADIUS--> RADIUSサーバー
                                  |
                                  |
                                  v
                            (認証情報転送)
                                  |
                                  v
                                 LNS &lt;--RADIUS--> RADIUSサーバー

LAC は RADIUS を使用してユーザー資格情報を検証できます。
LNS も RADIUS を使用して独立して検証できます。
二重検証により追加のセキュリティ層が提供されます。

セキュリティ設定チェックリスト:

10. IANA Considerations (IANA に関する考慮事項)

本章では、L2TP プロトコルに対して IANA (Internet Assigned Numbers Authority、インターネット割り当て番号機関) による割り当てと管理が必要なさまざまなパラメータを定義します。

10.1 AVP Attributes (AVP 属性)

IANA は L2TP AVP 属性タイプレジストリの維持を担当します。AVP 属性タイプは 16 ビットフィールドです。

登録要件:

値範囲 0-1023: IETF コンセンサスによって割り当てられます (RFC の公開が必要)。
値範囲 1024-65535: 「先着順」ポリシーを使用して割り当てられます。

割り当てられた標準 AVP 属性タイプ:

属性タイプ	AVP 名	参照
0	メッセージタイプ (Message Type)	RFC 2661 Section 4.4.1
1	結果コード (Result Code)	RFC 2661 Section 4.4.2
2	プロトコルバージョン (Protocol Version)	RFC 2661 Section 4.4.3
3	フレーミング機能 (Framing Capabilities)	RFC 2661 Section 4.4.3
4	ベアラ機能 (Bearer Capabilities)	RFC 2661 Section 4.4.3
5	タイブレーカー (Tie Breaker)	RFC 2661 Section 4.4.3
6	ファームウェアリビジョン (Firmware Revision)	RFC 2661 Section 4.4.3
7	ホスト名 (Host Name)	RFC 2661 Section 4.4.3
8	ベンダー名 (Vendor Name)	RFC 2661 Section 4.4.3
9	割り当てられたトンネル ID	RFC 2661 Section 4.4.3
10	受信ウィンドウサイズ	RFC 2661 Section 4.4.3
11	チャレンジ (Challenge)	RFC 2661 Section 4.4.3
12	Q.931 原因コード	RFC 2661 Section 4.4.4
13	チャレンジレスポンス	RFC 2661 Section 4.4.3
14	割り当てられたセッション ID	RFC 2661 Section 4.4.4
15	呼び出しシリアル番号	RFC 2661 Section 4.4.4
16	最小 BPS	RFC 2661 Section 4.4.4
17	最大 BPS	RFC 2661 Section 4.4.4
18	ベアラタイプ	RFC 2661 Section 4.4.4
19	フレーミングタイプ	RFC 2661 Section 4.4.4
20	パケット処理遅延	RFC 2661 Section 4.4.6
21	着信番号	RFC 2661 Section 4.4.4
22	発信番号	RFC 2661 Section 4.4.4
23	サブアドレス	RFC 2661 Section 4.4.4
24	送信接続速度	RFC 2661 Section 4.4.4
25	物理チャネル ID	RFC 2661 Section 4.4.4
26	初期受信 LCP CONFREQ	RFC 2661 Section 4.4.5
27	最後に送信した LCP CONFREQ	RFC 2661 Section 4.4.5
28	最後に受信した LCP CONFREQ	RFC 2661 Section 4.4.5
29	プロキシ認証タイプ	RFC 2661 Section 4.4.5
30	プロキシ認証名	RFC 2661 Section 4.4.5
31	プロキシ認証チャレンジ	RFC 2661 Section 4.4.5
32	プロキシ認証 ID	RFC 2661 Section 4.4.5
33	プロキシ認証レスポンス	RFC 2661 Section 4.4.5
34	呼び出しエラー	RFC 2661 Section 4.4.6
35	ACCM	RFC 2661 Section 4.4.6
36	ランダムベクトル	RFC 2661 Section 4.3
37	プライベートグループ ID	RFC 2661 Section 4.4.4
38	受信接続速度	RFC 2661 Section 4.4.4
39	シーケンシング必須	RFC 2661 Section 4.4.4

ベンダー固有 AVP:

ベンダー固有の AVP は、ベンダー ID フィールド (SMI ネットワーク管理プライベートエンタープライズコードに基づく) を使用して、異なるベンダーの拡張を区別します。

10.2 Message Type AVP Values (メッセージタイプ AVP 値)

メッセージタイプ AVP (属性タイプ 0) の値は、L2TP 制御メッセージのタイプを識別するために使用されます。

割り当てられたメッセージタイプ値:

値	メッセージタイプ	略語	参照
0	(予約済み)
1	制御接続開始要求	SCCRQ	RFC 2661 Section 6.1
2	制御接続開始応答	SCCRP	RFC 2661 Section 6.2
3	制御接続開始完了	SCCCN	RFC 2661 Section 6.3
4	制御接続停止通知	StopCCN	RFC 2661 Section 6.4
5	(予約済み)
6	Hello メッセージ	HELLO	RFC 2661 Section 6.5
7	発信呼び出し要求	OCRQ	RFC 2661 Section 6.9
8	発信呼び出し応答	OCRP	RFC 2661 Section 6.10
9	発信呼び出し接続完了	OCCN	RFC 2661 Section 6.11
10	着信呼び出し要求	ICRQ	RFC 2661 Section 6.6
11	着信呼び出し応答	ICRP	RFC 2661 Section 6.7
12	着信呼び出し接続完了	ICCN	RFC 2661 Section 6.8
13	(予約済み)
14	呼び出し切断通知	CDN	RFC 2661 Section 6.12
15	WAN エラー通知	WEN	RFC 2661 Section 6.13
16	リンク情報設定	SLI	RFC 2661 Section 6.14

登録ポリシー:

新しいメッセージタイプ値の割り当てには、IETF 標準トラック RFC の公開、または IESG が承認した情報 RFC が必要です。

10.3 Result Code AVP Values (結果コード AVP 値)

Result Code AVP (属性タイプ 1) は、制御接続またはセッション終了の理由を示すために使用されます。

10.3.1 Result Code Field Values (結果コードフィールド値)

一般的な結果コード:

値	意味	適用範囲
0	予約済み
1	制御接続をクリアする一般的な要求	StopCCN
2	一般的なエラー	StopCCN, CDN
3	制御チャネルは既に存在します	StopCCN
4	リクエスタは認証されていません	StopCCN
5	プロトコルバージョンはサポートされていません	StopCCN
6	リクエスタはシャットダウン中です	StopCCN
7	有限状態マシンエラー	StopCCN

呼び出し切断結果コード:

値	意味	適用範囲
1	キャリア喪失	CDN
2	一般的なエラー	CDN
3	管理上の理由	CDN
4	適切な設備の一時的な不足	CDN
5	適切な設備の永続的な不足	CDN
6	無効な宛先	CDN
7	キャリアが検出されません	CDN
8	ビジー信号	CDN
9	ダイヤルトーンがありません	CDN
10	キャリア待機タイムアウト	CDN
11	フレーミングが検出されません	CDN

10.3.2 Error Code Field Values (エラーコードフィールド値)

エラーコードフィールドは、エラーに関する追加の詳細情報を提供します。

値	エラーメッセージ
0	一般的なエラーはありません
1	このペアにはまだ制御接続が存在しません
2	長さが間違っています
3	フィールド値の 1 つが範囲外でした
4	この操作を処理するためのリソースが不足しています
5	無効なセッション ID
6	一般的なベンダー固有のエラーが発生しました
7	別の (LNS/LAC) を試してください
8	M ビットが設定された未知の AVP を受信したため、セッションまたはトンネルがシャットダウンされました

登録ポリシー:

新しい結果コード値とエラーコード値の割り当てには、IETF コンセンサス (RFC の公開が必要) が必要です。

10.4 Framing Capabilities & Bearer Capabilities (フレーミング機能とベアラ機能)

Framing Capabilities AVP (属性タイプ 3) と Bearer Capabilities AVP (属性タイプ 4) は、サポートされる機能を示すためにビットマスクを使用します。

フレーミング機能ビット定義:

ビット	意味
0	非同期フレーミングがサポートされています
1	同期フレーミングがサポートされています
2-31	予約済み

ベアラ機能ビット定義:

ビット	意味
0	アナログアクセスがサポートされています
1	デジタルアクセスがサポートされています
2-31	予約済み

登録ポリシー:

新しい機能ビットの割り当てには、IETF コンセンサス (RFC の公開が必要) が必要です。

10.5 Proxy Authen Type AVP Values (プロキシ認証タイプ AVP 値)

Proxy Authen Type AVP (属性タイプ 29) は、LAC が使用する認証タイプを示すために使用されます。

割り当てられた認証タイプ値:

値	認証タイプ	参照
0	予約済み
1	テキストユーザー名/パスワード交換	RFC 1334 (PAP)
2	PPP CHAP	RFC 1994
3	PPP PAP	RFC 1334
4	認証なし
5	Microsoft CHAP バージョン 1	RFC 2433
6	予約済み
7	Microsoft CHAP バージョン 2	RFC 2759

登録ポリシー:

新しい認証タイプ値の割り当ては、「先着順」ポリシーを使用します。

10.6 AVP Header Bits (AVP ヘッダービット)

AVP ヘッダーの最初の 6 ビットは、AVP の動作を制御するためのビットマスクとして使用されます。

定義された AVP ヘッダービット:

ビット	名前	意味	参照
0	M (必須)	この AVP は理解されなければなりません	RFC 2661 Section 4.1
1	H (非表示)	AVP 値は非表示です	RFC 2661 Section 4.3
2-5	予約済み	予約済み、0 に設定する必要があります	RFC 2661 Section 4.1

登録ポリシー:

予約ビットの割り当てには、標準アクション - すなわち IETF 標準トラック RFC の公開が必要です。

10.7 L2TP UDP Port (L2TP UDP ポート)

割り当てられたポート:

ポート番号: 1701
プロトコル: UDP
用途: L2TP
参照: RFC 2661

IANA は、制御接続とデータセッションの両方に L2TP 用の UDP ポート 1701 を割り当てています。

10.8 L2TP Protocol Number (L2TP プロトコル番号)

現在の仕様では L2TP は UDP 上で動作すると定義されていますが、L2TP は他のパケット転送プロトコル上で直接動作することもできます。

IP プロトコル番号:

L2TP プロトコル番号: 115
名前: L2TP
参照: RFC 3931 (L2TPv3、IP 上で直接)

IANA レジストリの維持:

IANA は、次の L2TP 関連レジストリを維持しています:

L2TP AVP 属性レジストリ
- URL: https://www.iana.org/assignments/l2tp-parameters/
L2TP メッセージタイプレジストリ
- すべての制御メッセージタイプを含みます
L2TP 結果コードレジストリ
- 結果コードとエラーコードを含みます
L2TP プロキシ認証タイプレジストリ
- 認証タイプ値を含みます
L2TP ポートとプロトコル番号
- UDP ポートと IP プロトコル番号の割り当て

更新と拡張:

後続の RFC は、新しい AVP、メッセージタイプ、またはその他のパラメータを定義する可能性があります。すべての新しい割り当ては、このセクションで定義された登録ポリシーに従う必要があります。

重要な拡張には次のものがあります:

RFC 3931: Layer Two Tunneling Protocol - Version 3 (L2TPv3)
RFC 4591: Frame Relay over L2TP
RFC 5515: Layer Two Tunneling Protocol (L2TP) Access Concentrator Configuration

11. References (参考文献)

本節は RFC 2661 で引用されているすべての規定・参考文書を列挙します。

11.1 Normative References (引用規格)

引用規格とは、L2TP プロトコルの実装に必須の文書です。

[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.

日本語タイトル： Point-to-Point Protocol (PPP)
説明： L2TP がトンネリングする PPP フレームの基本形式とネゴシエーション手順を定義。

[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.

日本語タイトル： HDLC 様フレーミングを用いた PPP
説明： HDLC 様回線上での PPP フレームのカプセル化方式を定義。

[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.

日本語タイトル： 割り当て番号
説明： IANA 番号割り当ての参照（オンライン IANA レジストリに置き換え）。

[RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.

日本語タイトル： PPP Multilink Protocol (MP)
説明： 複数の物理回線を単一の論理回線に束ねる仕組みを定義。

[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.

日本語タイトル： PPP Challenge Handshake Authentication Protocol (CHAP)
説明： L2TP プロキシ認証で使用される認証プロトコル。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

日本語タイトル： RFC で要件レベルを示すためのキーワード
説明： "MUST"、"SHOULD"、"MAY" などのキーワードの意味を定義。

[RFC2341] Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two Forwarding (Protocol) 'L2F'", RFC 2341, May 1998.

日本語タイトル： Cisco Layer Two Forwarding (Protocol) (L2F)
説明： L2TP の前身プロトコル。バージョン判別に使用される。

11.2 Informative References (参考文書)

参考文書は、関連プロトコルの背景情報と解説を提供します。

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

日本語タイトル： Internet Protocol (IPv4)
説明： L2TP が動作可能な IPv4 プロトコルを定義。

[RFC1334] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC 1334, October 1992.

日本語タイトル： PPP 認証プロトコル
説明： PAP (Password Authentication Protocol) を定義。

[RFC2138] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.

日本語タイトル： Remote Authentication Dial In User Service (RADIUS)
説明： 集中認証・認可・アカウンティングのプロトコル。

[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.

日本語タイトル： 文字セットと言語に関する IETF ポリシー
説明： 国際化されたテキストの扱いに関するガイドライン。

[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

日本語タイトル： インターネットプロトコルのためのセキュリティアーキテクチャ
説明： L2TP と組み合わせて推奨される IPsec アーキテクチャを定義。

[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998.

日本語タイトル： Microsoft PPP CHAP 拡張
説明： MS-CHAPv1 プロトコルの定義。

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

日本語タイトル： Internet Protocol, Version 6 (IPv6) Specification
説明： L2TP が動作可能な IPv6 プロトコルを定義。

[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000.

日本語タイトル： Microsoft PPP CHAP Extensions, Version 2
説明： MS-CHAPv2 プロトコルの定義。

[KPS] Kaufman, C., Perlman, R., and M. Speciner, "Network Security: Private Communication in a Public World", Prentice Hall, March 1995, ISBN 0-13-061466-1.

日本語タイトル： Network Security: Private Communication in a Public World
説明： AVP 秘匿メカニズムの暗号論的基礎の参考書。

L2TP と関連するが直接引用されていない重要な標準を以下に示します。

L2TP の発展版：

RFC 3931： Layer Two Tunneling Protocol - Version 3 (L2TPv3)
- 非 PPP データフレームのトンネリングをサポートする L2TP 第 3 版。
RFC 5515： Layer Two Tunneling Protocol (L2TP) Access Concentrator Configuration
- L2TP アクセスコンセントレータの構成プロトコル。

IPsec 関連：

RFC 2407： The Internet IP Security Domain of Interpretation for ISAKMP
RFC 2408： Internet Security Association and Key Management Protocol (ISAKMP)
RFC 2409： The Internet Key Exchange (IKE)
RFC 4306： Internet Key Exchange (IKEv2) Protocol
RFC 4555： IKEv2 Mobility and Multihoming Protocol (MOBIKE)

PPP 拡張：

RFC 2637： Point-to-Point Tunneling Protocol (PPTP)
RFC 3748： Extensible Authentication Protocol (EAP)
RFC 5281： Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)

QoS とトラフィック管理：

RFC 2474： Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
RFC 2475： An Architecture for Differentiated Services

11.4 Standards Organizations (標準化団体)

IETF (Internet Engineering Task Force)

ウェブサイト： https://www.ietf.org/
L2TP ワーキンググループアーカイブ： https://datatracker.ietf.org/wg/l2tpext/

IANA (Internet Assigned Numbers Authority)

ウェブサイト： https://www.iana.org/
L2TP パラメータレジストリ： https://www.iana.org/assignments/l2tp-parameters/

IEEE (Institute of Electrical and Electronics Engineers)

レイヤ 2 技術に関する各種標準

ITU-T (国際電気通信連合電気通信標準化部門)

Q.931： ISDN シグナリング（Q.931 Cause Code AVP で参照）

11.5 Historical Context (沿革)

L2TP プロトコルは、以下の 2 つのプロトコルを統合したものです。

L2F (Layer 2 Forwarding Protocol) - Cisco Systems により開発
- RFC 2341
PPTP (Point-to-Point Tunneling Protocol) - Microsoft 他により開発
- RFC 2637

L2TP はこれら 2 つのプロトコルの長所を組み合わせ、IETF 標準トラックのプロトコルとなりました。

11.6 Further Reading (参考図書)

専門書：

"VPN and NAT Traversal"（Gurdeep Singh Pall, Glen Zorn 著）
"Understanding Virtual Private Networks"（Rod Rhoton 著）
"Virtual Private Networks: Technologies and Solutions"（Ruixi Yuan, W. Timothy Strayer 著）

オンラインリソース：

IETF L2TP Charter： https://datatracker.ietf.org/wg/l2tpext/charter/
L2TP/IPsec 構成ガイド（ベンダー固有）
ネットワークセキュリティのベストプラクティス文書

引用書式に関する注意 (Citation Format Notes)：

本ドキュメントでは RFC を [RFCXXXX] の形式で引用します（XXXX は RFC 番号）。その他の文書は角括弧内の短い識別子（例：[KPS]）で参照します。

完全な RFC 文書は以下のソースから入手可能です：

IETF RFC Editor： https://www.rfc-editor.org/
IETF Datatracker： https://datatracker.ietf.org/

12. Acknowledgments (謝辞)

RFC 2661 の著者は、本仕様の策定に貢献した IETF L2TP ワーキンググループのすべてのメンバーに感謝します。

Major Contributors (主な貢献者)

本プロトコルの開発は、多くの個人および組織からの技術的貢献によって支えられました。特に以下の貢献者に感謝します：

Cisco Systems のエンジニアリングチーム、特に L2F プロトコルの当初の開発者
Microsoft Corporation のエンジニアリングチーム、特に PPTP プロトコルの貢献者
Ascend Communications および Redback Networks の技術専門家

Working Group Members (ワーキンググループメンバー)

L2TP ワーキンググループでの議論と技術レビューは、本仕様の品質に不可欠でした。メーリングリストでの議論、実装フィードバック、相互運用性テストに参加したすべてのメンバーに感謝します。

Technical Review (技術レビュー)

草案の詳細な技術レビューと建設的なコメントをいただいた以下の方々に感謝します：

セキュリティ章のレビューを行ったセキュリティ専門家
プロトコル設計への提言を行った PPP およびトンネルプロトコル専門家
パラメータ割り当て章に関する助言を行った IANA 代表

Editorial Support (編集支援)

文書のフォーマット、用語の一貫性、技術表現の明確さについて専門的な支援を提供いただいた RFC Editor チームに感謝します。

注：貢献者および組織の完全なリストは、RFC 2661 原本の謝辞章を参照してください。

13. Authors' Addresses (著者の連絡先)

本節は RFC 2661 の主な著者とその連絡先（公開時点）を列挙します。

W. Mark Townsley

Cisco Systems

Email: [email protected]
Website: https://www.townsley.net/

貢献： チーフエディタおよび技術的調整

Allan Valencia

Cisco Systems

Email: [email protected]

貢献： プロトコル設計および L2F 統合

Ascend Communications 代表

Andrew Rubens

Email: [email protected]

貢献： 制御プロトコルおよび AVP 設計

Microsoft Corporation 代表

Gurdeep Singh Pall

Email: [email protected]

貢献： PPTP プロトコル統合およびセキュリティメカニズム

Microsoft Corporation 代表

Glen Zorn

Email: [email protected]

貢献： 認証プロトコルおよびセキュリティ設計

Redback Networks 代表

Bernard Palter

Email: [email protected]

貢献： プロトコル実装および相互運用性テスト

注意事項 (Notes)：

上記の連絡先は公開時点（1999 年 8 月）のものです。
一部のメールアドレスは無効になっている可能性があります。
L2TP プロトコルに関する最新の質問や議論は、IETF L2TP ワーキンググループのメーリングリストへお願いします。
L2TP 標準の継続的な保守および拡張は、引き続き IETF が行っています。

連絡先の更新：

L2TP プロトコルに関する最新情報や問題の報告は以下を参照してください：

IETF Datatracker: https://datatracker.ietf.org/doc/rfc2661/
L2TP ワーキンググループ: https://datatracker.ietf.org/wg/l2tpext/

Appendix A: Control Channel Slow Start and Congestion Avoidance

A.1 概要 (Overview)

L2TP 制御チャネルは信頼性のあるメッセージ転送メカニズムを使用します。ネットワークの輻輳を防ぐため、TCP と同様の Slow Start および Congestion Avoidance アルゴリズムの実装が推奨されます。

A.2 Slow Start アルゴリズム (Slow Start Algorithm)

初期パラメータ：

初期輻輳ウィンドウ (cwnd)： 1 メッセージ
Slow Start しきい値 (ssthresh)：受信ウィンドウサイズ

アルゴリズムの手順：

受信した ACK ごとに cwnd を 1 増加
cwnd >= ssthresh となったら Congestion Avoidance フェーズへ移行
未確認で送信されるメッセージ数は min(cwnd, 受信ウィンドウ) を超えない

A.3 輻輳回避 (Congestion Avoidance)

バックオフ戦略：

タイムアウト検出時： ssthresh = max(cwnd/2, 2)
cwnd を 1 にリセットし Slow Start を再開

RTT 推定 (RTT Estimation)：

Jacobson/Karels アルゴリズムを用いて再送タイムアウト (RTO) を計算
平滑化 RTT = (1-α) × 平滑化 RTT + α × 測定 RTT
RTO = 平滑化 RTT + 4 × RTT 偏差

Appendix C: Intellectual Property Notice

C.1 IP 声明 (IP Statement)

IETF は、本書に記述された技術に関するいかなる知的財産権その他の権利の有効性や範囲についても、またそのような権利に基づくライセンスが利用可能であるか否かについても、一切の立場を表明せず、そのような権利の特定に努めたことも表明しません。

C.2 特許の開示 (Patent Disclosure)

RFC 2026 セクション 10.4 の要件に従い、本仕様に関連して開示された知的財産権の情報は IETF のウェブサイトで閲覧できます。

C.3 ライセンス情報 (Licensing Information)

実装者は、一部の L2TP 機能が特許によって保護されている可能性があることに留意すべきです。IETF はそのような特許の特定や、特許請求の範囲の有効性・範囲の評価について責任を負いません。

関連リンク：

IETF IPR Disclosures: https://datatracker.ietf.org/ipr/
RFC 2026 Section 10: https://www.rfc-editor.org/rfc/rfc2026.html

概要 (Abstract)​

目次 (Contents)​

付録 (Appendices)​

関連リソース​

7. 制御接続状態機械 (Control Connection State Machines)​

7.1 制御接続プロトコル操作 (Control Connection Protocol Operation)​

7.2 制御接続の状態 (Control Connection States)​

7.2.1 制御接続の確立 (Control Connection Establishment)​

7.3 タイミングの考慮事項 (Timing Considerations)​

7.4 着信呼 (Incoming Calls)​

7.4.1 LAC 着信呼の状態 (LAC Incoming Call States)​

7.4.2 LNS 着信呼の状態 (LNS Incoming Call States)​

7.5 発信呼 (Outgoing Calls)​

7.5.1 LAC 発信呼の状態 (LAC Outgoing Call States)​

7.5.2 LNS 発信呼の状態 (LNS Outgoing Call States)​

7.6 トンネルの切断 (Tunnel Disconnection)​

8. L2TP Over Specific Media (特定メディア上の L2TP)​

8.1 L2TP over UDP/IP (UDP/IP 上の L2TP)​

8.2 IP (インターネットプロトコル)​

9. Security Considerations (セキュリティに関する考慮事項)​

9.1 Tunnel Endpoint Security (トンネルエンドポイントのセキュリティ)​

9.2 Packet Level Security (パケットレベルのセキュリティ)​

9.3 End to End Security (エンドツーエンドのセキュリティ)​

9.4 L2TP and IPsec (L2TP と IPsec)​

9.5 Proxy PPP Authentication (プロキシ PPP 認証)​

10. IANA Considerations (IANA に関する考慮事項)​

10.1 AVP Attributes (AVP 属性)​

10.2 Message Type AVP Values (メッセージタイプ AVP 値)​

10.3 Result Code AVP Values (結果コード AVP 値)​

10.3.1 Result Code Field Values (結果コードフィールド値)​

10.3.2 Error Code Field Values (エラーコードフィールド値)​

10.4 Framing Capabilities & Bearer Capabilities (フレーミング機能とベアラ機能)​

10.5 Proxy Authen Type AVP Values (プロキシ認証タイプ AVP 値)​

10.6 AVP Header Bits (AVP ヘッダービット)​

10.7 L2TP UDP Port (L2TP UDP ポート)​

10.8 L2TP Protocol Number (L2TP プロトコル番号)​

11. References (参考文献)​

11.1 Normative References (引用規格)​

11.2 Informative References (参考文書)​

11.3 Related Standards (関連標準)​

11.4 Standards Organizations (標準化団体)​

11.5 Historical Context (沿革)​

11.6 Further Reading (参考図書)​

12. Acknowledgments (謝辞)​

Major Contributors (主な貢献者)​

Working Group Members (ワーキンググループメンバー)​

Technical Review (技術レビュー)​

Editorial Support (編集支援)​

13. Authors' Addresses (著者の連絡先)​

W. Mark Townsley​

Allan Valencia​

Ascend Communications 代表​

Microsoft Corporation 代表​

Microsoft Corporation 代表​

Redback Networks 代表​

Appendix A: Control Channel Slow Start and Congestion Avoidance​

A.1 概要 (Overview)​

A.2 Slow Start アルゴリズム (Slow Start Algorithm)​

A.3 輻輳回避 (Congestion Avoidance)​

Appendix C: Intellectual Property Notice​

C.1 IP 声明 (IP Statement)​

C.2 特許の開示 (Patent Disclosure)​

C.3 ライセンス情報 (Licensing Information)​

概要 (Abstract)

目次 (Contents)

付録 (Appendices)

関連リソース

7. 制御接続状態機械 (Control Connection State Machines)

7.1 制御接続プロトコル操作 (Control Connection Protocol Operation)

7.2 制御接続の状態 (Control Connection States)

7.2.1 制御接続の確立 (Control Connection Establishment)

7.3 タイミングの考慮事項 (Timing Considerations)

7.4 着信呼 (Incoming Calls)

7.4.1 LAC 着信呼の状態 (LAC Incoming Call States)

7.4.2 LNS 着信呼の状態 (LNS Incoming Call States)

7.5 発信呼 (Outgoing Calls)

7.5.1 LAC 発信呼の状態 (LAC Outgoing Call States)

7.5.2 LNS 発信呼の状態 (LNS Outgoing Call States)

7.6 トンネルの切断 (Tunnel Disconnection)

8. L2TP Over Specific Media (特定メディア上の L2TP)

8.1 L2TP over UDP/IP (UDP/IP 上の L2TP)

8.2 IP (インターネットプロトコル)

9. Security Considerations (セキュリティに関する考慮事項)

9.1 Tunnel Endpoint Security (トンネルエンドポイントのセキュリティ)

9.2 Packet Level Security (パケットレベルのセキュリティ)

9.3 End to End Security (エンドツーエンドのセキュリティ)

9.4 L2TP and IPsec (L2TP と IPsec)

9.5 Proxy PPP Authentication (プロキシ PPP 認証)

10. IANA Considerations (IANA に関する考慮事項)

10.1 AVP Attributes (AVP 属性)

10.2 Message Type AVP Values (メッセージタイプ AVP 値)

10.3 Result Code AVP Values (結果コード AVP 値)

10.3.1 Result Code Field Values (結果コードフィールド値)

10.3.2 Error Code Field Values (エラーコードフィールド値)

10.4 Framing Capabilities & Bearer Capabilities (フレーミング機能とベアラ機能)

10.5 Proxy Authen Type AVP Values (プロキシ認証タイプ AVP 値)

10.6 AVP Header Bits (AVP ヘッダービット)

10.7 L2TP UDP Port (L2TP UDP ポート)

10.8 L2TP Protocol Number (L2TP プロトコル番号)

11. References (参考文献)

11.1 Normative References (引用規格)

11.2 Informative References (参考文書)

11.3 Related Standards (関連標準)

11.4 Standards Organizations (標準化団体)

11.5 Historical Context (沿革)

11.6 Further Reading (参考図書)

12. Acknowledgments (謝辞)

Major Contributors (主な貢献者)

Working Group Members (ワーキンググループメンバー)

Technical Review (技術レビュー)

Editorial Support (編集支援)

13. Authors' Addresses (著者の連絡先)

W. Mark Townsley

Allan Valencia

Ascend Communications 代表

Microsoft Corporation 代表

Microsoft Corporation 代表

Redback Networks 代表

Appendix A: Control Channel Slow Start and Congestion Avoidance

A.1 概要 (Overview)

A.2 Slow Start アルゴリズム (Slow Start Algorithm)

A.3 輻輳回避 (Congestion Avoidance)

Appendix C: Intellectual Property Notice

C.1 IP 声明 (IP Statement)

C.2 特許の開示 (Patent Disclosure)

C.3 ライセンス情報 (Licensing Information)