[要約] RFC 5571は、L2TPv2を使用したソフトワイヤハブアンドスポーク展開フレームワークに関するものであり、その目的は、IPv6ネットワーク上でのIPv4トラフィックのトンネリングをサポートすることです。
Network Working Group B. Storer
Request for Comments: 5571 C. Pignataro, Ed.
Category: Standards Track M. Dos Santos
Cisco Systems
B. Stevant, Ed.
L. Toutain
TELECOM Bretagne
J. Tremblay
Videotron Ltd.
June 2009
Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)
Softwire Hubとレイヤー2トンネリングプロトコルバージョン2（L2TPV2）を使用した展開フレームワーク
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
This document describes the framework of the Softwire "Hub and Spoke" solution with the Layer Two Tunneling Protocol version 2 (L2TPv2). The implementation details specified in this document should be followed to achieve interoperability among different vendor implementations.
このドキュメントでは、レイヤー2トンネリングプロトコルバージョン2（L2TPV2）を使用したソフトワイヤーの「ハブアンドスポーク」ソリューションのフレームワークについて説明します。このドキュメントで指定されている実装の詳細は、さまざまなベンダーの実装間で相互運用性を実現するために従う必要があります。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Abbreviations ..............................................5
1.2. Requirements Language ......................................5
1.3. Considerations .............................................6
2. Applicability of L2TPv2 for Softwire Requirements ...............6
2.1. Traditional Network Address Translation (NAT and NAPT) .....6
2.2. Scalability ................................................7
2.3. Routing ....................................................7
2.4. Multicast ..................................................7
2.5. Authentication, Authorization, and Accounting (AAA) ........7
2.6. Privacy, Integrity, and Replay Protection ..................7
2.7. Operations and Management ..................................8
2.8. Encapsulations .............................................8
3. Deployment Scenarios ............................................8
3.1. IPv6-over-IPv4 Softwires with L2TPv2 .......................9
3.1.1. Host CPE as Softwire Initiator ......................9
3.1.2. Router CPE as Softwire Initiator ...................10
3.1.3. Host behind CPE as Softwire Initiator ..............11
3.1.4. Router behind CPE as Softwire Initiator ............12
3.2. IPv4-over-IPv6 Softwires with L2TPv2 ......................14
3.2.1. Host CPE as Softwire Initiator .....................14
3.2.2. Router CPE as Softwire Initiator ...................15
3.2.3. Host behind CPE as Softwire Initiator ..............16
3.2.4. Router behind CPE as Softwire Initiator ............16
4. References to Standardization Documents ........................17
4.1. L2TPv2 ....................................................18
4.2. Securing the Softwire Transport ...........................18
4.3. Authentication, Authorization, and Accounting .............18
4.4. MIB .......................................................18
4.5. Softwire Payload Related ..................................19
4.5.1. For IPv6 Payloads ..................................19
4.5.2. For IPv4 Payloads ..................................19
5. Softwire Establishment .........................................20
5.1. L2TPv2 Tunnel Setup .......................................22
5.1.1. Tunnel Establishment ...............................22
5.1.1.1. AVPs Required for Softwires ...............25
5.1.1.2. AVPs Optional for Softwires ...............25
5.1.1.3. AVPs Not Relevant for Softwires ...........26
5.1.2. Tunnel Maintenance .................................26
5.1.3. Tunnel Teardown ....................................27
5.1.4. Additional L2TPv2 Considerations ...................27
5.2. PPP Connection ............................................27
5.2.1. MTU ................................................27
5.2.2. LCP ................................................27
5.2.3. Authentication .....................................28
5.2.4. IPCP ...............................................28
5.2.4.1. IPV6CP ....................................28
5.2.4.2. IPv4CP ....................................28
5.3. Global IPv6 Address Assignment to Endpoints ...............28
5.4. DHCP ......................................................29
5.4.1. DHCPv6 .............................................29
5.4.2. DHCPv4 .............................................29
6. Considerations about the Address Provisioning Model ............30
6.1. Softwire Endpoints' Addresses .............................30
6.1.1. IPv6 ...............................................30
6.1.2. IPv4 ...............................................31
6.2. Delegated Prefixes ........................................31
6.2.1. IPv6 Prefixes ......................................31
6.2.2. IPv4 Prefixes ......................................31
6.3. Possible Address Provisioning Scenarios ...................31
6.3.1. Scenarios for IPv6 .................................32
6.3.2. Scenarios for IPv4 .................................32
7. Considerations about Address Stability .........................32
8. Considerations about RADIUS Integration ........................33
8.1. Softwire Endpoints ........................................33
8.1.1. IPv6 Softwires .....................................33
8.1.2. IPv4 Softwires .....................................33
8.2. Delegated Prefixes ........................................34
8.2.1. IPv6 Prefixes ......................................34
8.2.2. IPv4 Prefixes ......................................34
9. Considerations for Maintenance and Statistics ..................34
9.1. RADIUS Accounting .........................................35
9.2. MIBs ......................................................35
10. Security Considerations .......................................35
11. Acknowledgements ..............................................36
12. References ....................................................37
12.1. Normative References .....................................37
12.2. Informative References ...................................38
The Softwires Working Group has selected Layer Two Tunneling Protocol version 2 (L2TPv2) as the phase 1 protocol to be deployed in the Softwire "Hub and Spoke" solution space. This document describes the framework for the L2TPv2 "Hub and Spoke" solution, and the implementation details specified in this document should be followed to achieve interoperability among different vendor implementations.
ソフトワイヤワーキンググループは、ソフトワイヤーの「ハブ」に展開されるフェーズ1プロトコルとして、レイヤー2トンネルプロトコルバージョン2（L2TPV2）を選択しました。このドキュメントでは、L2TPV2「ハブとスポーク」ソリューションのフレームワークについて説明します。このドキュメントで指定された実装の詳細には、さまざまなベンダーの実装間で相互運用性を実現する必要があります。
In the "Hub and Spoke" solution space, a Softwire is established to provide the home network with IPv4 connectivity across an IPv6-only access network, or IPv6 connectivity across an IPv4-only access network. When L2TPv2 is used in the Softwire context, the voluntary tunneling model applies. The Softwire Initiator (SI) at the home network takes the role of the L2TP Access Concentrator (LAC) client (initiating both the L2TP tunnel/session and the PPP link) while the Softwire Concentrator (SC) at the ISP takes the role of the L2TP Network Server (LNS). The terms voluntary tunneling and compulsory tunneling are defined in Section 1.1 of [RFC3193]. Since the L2TPv2 compulsory tunneling model does not apply to Softwires, it SHOULD NOT be requested or honored. This document identifies all the voluntary tunneling related L2TPv2 attributes that apply to Softwires and specifies the handling mechanism for such attributes in order to avoid ambiguities in implementations. This document also identifies the set of L2TPv2 attributes specific to the compulsory tunneling model that does not apply to Softwires and specifies the mechanism to ignore or nullify their effect within the Softwire context.
「ハブとスポーク」ソリューションスペースでは、Softwireが設立され、IPv6のみのアクセスネットワーク全体のIPv4接続、またはIPv4のみのアクセスネットワーク全体のIPv6接続をホームネットワークに提供します。L2TPV2がSoftwireコンテキストで使用される場合、自発的トンネルモデルが適用されます。ホームネットワークのソフトワイヤーイニシエーター（SI）は、L2TPアクセスコンセントレーター（LAC）クライアント（L2TPトンネル/セッションとPPPリンクの両方を開始）の役割を担い、ISPのソフトワイヤーコンセントレーター（SC）はL2TPネットワークサーバー（LNS）。自発的トンネルと強制トンネリングという用語は、[RFC3193]のセクション1.1で定義されています。L2TPV2強制トンネリングモデルはソフトウェアには適用されないため、要求または尊重されるべきではありません。このドキュメントは、ソフトウェアに適用されるすべての自発的トンネル関連のL2TPV2属性を特定し、実装の曖昧さを回避するためにそのような属性の取り扱いメカニズムを指定します。また、このドキュメントは、ソフトウェアに適用されない強制トンネルモデルに固有のL2TPV2属性のセットを識別し、ソフトワイヤのコンテキスト内でそれらの効果を無視または無視するメカニズムを指定します。
The SI and SC MUST follow the L2TPv2 operations described in [RFC2661] when performing Softwire establishment, teardown, and Operations, Administration, and Management (OAM). With L2TPv2, a Softwire consists of an L2TPv2 Control Connection (also referred to as Control Channel), a single L2TPv2 Session, and the PPP link negotiated over the Session. To establish the Softwire, the SI first initiates an L2TPv2 Control Channel to the SC, which accepts the request and terminates the Control Channel. L2TPv2 supports an optional mutual Control Channel authentication that allows both SI and SC to validate each other's identity at the initial phase of hand-shaking before proceeding with Control Channel establishment. After the L2TPv2 Control Channel is established between the SI and SC, the SI initiates an L2TPv2 Session to the SC. Then the PPP/IP link is negotiated over the L2TPv2 Session between the SI and SC. After the PPP/IP link is established, it acts as the Softwire between the SI and SC for tunneling IP traffic of one Address Family (AF) across the access network of another Address Family.
SIおよびSCは、ソフトワイヤの施設、断片、および運用、管理、および管理（OAM）を実行する際に、[RFC2661]に記載されているL2TPV2操作に従う必要があります。L2TPV2を使用すると、ソフトワイヤはL2TPV2制御接続（コントロールチャネルとも呼ばれます）、単一のL2TPV2セッション、およびセッションでネゴシエートされたPPPリンクで構成されています。Softwireを確立するために、SIは最初にL2TPV2制御チャネルをSCに開始します。SCはリクエストを受け入れ、制御チャネルを終了します。L2TPV2は、コントロールチャネルの確立に進む前に、SIとSCの両方がハンドシェーキングの初期段階で互いのアイデンティティを検証できるようにするオプションの相互制御チャネル認証をサポートします。SIとSCの間にL2TPV2制御チャネルが確立された後、SIはSCへのL2TPV2セッションを開始します。次に、PPP/IPリンクは、SIとSCの間のL2TPV2セッションを介してネゴシエートされます。PPP/IPリンクが確立された後、別のアドレスファミリのアクセスネットワーク全体で、あるアドレスファミリー（AF）のトンネルIPトラフィックのために、SIとSCの間のソフトワイヤとして機能します。
During the life of the Softwire, both SI and SC send L2TPv2 keepalive HELLO messages to monitor the health of the Softwire and the peer L2TP Control Connection Endpoint (LCCE), and to potentially refresh the NAT/NAPT (Network Address Translation / Network Address Port Translation) entry at the CPE or at the other end of the access link. Optionally, Link Control Protocol (LCP) ECHO messages can be used as keepalives for the same purposes. In the event of keepalive timeout or administrative shutdown of the Softwire, either the SI or the SC MAY tear down the Softwire by tearing down the L2TPv2 Control Channel and Session as specified in [RFC2661].
Softwireの存続期間中、SIとSCの両方がL2TPV2キープライブのハローメッセージを送信して、SoftwireとPeer L2TP Control Connection Endpoint（LCCE）の健康を監視し、NAT / NAPT（ネットワークアドレス変換 /ネットワークアドレスポートを更新する可能性があります翻訳）CPEまたはアクセスリンクの反対側へのエントリ。オプションで、リンク制御プロトコル（LCP）エコーメッセージは、同じ目的のためにKeepaliveとして使用できます。SoftwireのKeepAlive Timeoutまたは管理上のシャットダウンが発生した場合、SIまたはSCのいずれかが[RFC2661]で指定されているように、L2TPV2制御チャネルとセッションを取り壊すことにより、ソフトワイヤを取り壊す可能性があります。
AF Address Family, IPv4 or IPv6.
AFアドレスファミリー、IPv4またはIPv6。
CPE Customer Premises Equipment.
CPE顧客施設機器。
LCCE L2TP Control Connection Endpoint, an L2TP node that exists at either end of an L2TP Control Connection. (See [RFC3931].)
LCCE L2TP制御接続エンドポイント、L2TP制御接続の両端に存在するL2TPノード。（[RFC3931]を参照してください。）
LNS L2TP Network Server, a node that acts as one side of an L2TP tunnel (Control Connection) endpoint. The LNS is the logical termination point of a PPP session that is being tunneled from the remote system by the peer LCCE. (See [RFC2661].)
LNS L2TPネットワークサーバー、L2TPトンネル（制御接続）エンドポイントの片側として機能するノード。LNSは、PEER LCCEによってリモートシステムからトンネル化されているPPPセッションの論理終了点です。（[RFC2661]を参照してください。）
SC Softwire Concentrator, the node terminating the Softwire in the service provider network. (See [RFC4925].)
SCソフトワイヤーコンセントレーター、サービスプロバイダーネットワークのソフトワイヤーを終了するノード。（[RFC4925]を参照してください。）
SI Softwire Initiator, the node initiating the Softwire within the customer network. (See [RFC4925].)
Si Softwire Initiator、顧客ネットワーク内のソフトワイヤーを開始するノード。（[RFC4925]を参照してください。）
SPH Softwire Payload Header, the IP headers being carried within a Softwire. (See [RFC4925].)
SPHソフトワイヤーペイロードヘッダー、IPヘッダーはソフトワイヤ内で運ばれています。（[RFC4925]を参照してください。）
STH Softwire Transport Header, the outermost IP header of a Softwire. (See [RFC4925].)
Sth Softwire Transport Header、Softwireの最も外側のIPヘッダー。（[RFC4925]を参照してください。）
SW Softwire, a shared-state "tunnel" created between the SC and SI. (See [RFC4925].)
SW Softwire、SCとSIの間に作成された共有状態の「トンネル」。（[RFC4925]を参照してください。）
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
Some sections of this document contain considerations that are not required for interoperability and correct operation of Softwire implementations. These sections' titles are marked beginning with "Considerations".
このドキュメントの一部のセクションには、相互運用性とソフトワイヤーの実装の正しい操作には必要ない考慮事項が含まれています。これらのセクションのタイトルは、「考慮事項」から始まります。
A list of Softwire "Hub and Spoke" requirements has been identified by the Softwire Problem Statement [RFC4925]. The following sub-sections describe how L2TPv2 fulfills each of them.
Softwireの「ハブとスポーク」の要件のリストは、Softwireの問題ステートメント[RFC4925]によって特定されています。次のサブセクションは、L2TPV2がそれぞれをどのように満たすかを説明しています。
A "Hub and Spoke" Softwire must be able to traverse Network Address Translation (NAT) and Network Address Port Translation (NAPT, also referred to as Port Address Translation or PAT) devices [RFC3022] in case the scenario in question involves a non-upgradable, preexisting IPv4 home gateway performing NAT/NAPT or some carrier equipment at the other end of the access link performing NAT/NAPT. The L2TPv2 Softwire (i.e., Control Channel and Session) is capable of NAT/NAPT traversal since L2TPv2 can run over UDP.
「ハブとスポーク」ソフトワイヤーは、ネットワークアドレスの翻訳（NAT）とネットワークアドレスポートの翻訳（NAPT、ポートアドレス変換またはPATとも呼ばれる）デバイス[RFC3022]を通過することができなければなりません。NAT/NAPTを実行するアップグレード可能な既存のIPv4ホームゲートウェイまたはNAT/NAPTを実行するアクセスリンクの反対側にあるキャリア機器を実行します。L2TPV2はUDPを介して実行できるため、L2TPV2ソフトワイヤー（つまり、コントロールチャネルとセッション）はNAT/NAPTトラバーサルが可能です。
Since L2TPv2 does not detect NAT/NAPT along the path, L2TPv2 does not offer the option of disabling UDP. The UDP encapsulation is present regardless of NAT/NAPT presence. Both NAT/NAPT "autodetect" and UDP "bypass" are optional requirements in Section 2.3 of [RFC4925].
L2TPV2はパスに沿ってNAT/NAPTを検出しないため、L2TPV2はUDPを無効にするオプションを提供しません。UDPのカプセル化は、NAT/NAPTの存在に関係なく存在します。NAT/NAPT「AutoDeTect」とUDP「バイパス」の両方は、[RFC4925]のセクション2.3のオプションの要件です。
As mentioned in Section 8.1 of [RFC2661] and Section 4 of [RFC3193], an L2TP Start-Control-Connection-Reply (SCCRP) responder (SC) can chose a different IP address and/or UDP port than those from the initiator's Start-Control-Connection-Request (SCCRQ) (SI). This may or may not traverse a NAT/NAPT depending on the NAT/NAPT's Filtering Behavior (see Section 5 of [RFC4787]). Specifically, any IP address and port combination will work with Endpoint-Independent Filtering, but changing the IP address and port will not work through Address-Dependent or Address-and-Port-Dependent Filtering. Given this, responding from a different IP address and/or UDP port is NOT RECOMMENDED.
[RFC2661]のセクション8.1および[RFC3193]のセクション4で述べたように、L2TP Start-Control-Connection-Reply（SCCRP）Responder（SC）は、開始者の開始からの開始から異なるIPアドレスおよび/またはUDPポートを選択できます。-CONTROL-CONNECTION-REQUEST（SCCRQ）（SI）。これは、NAT/NAPTのフィルタリング挙動に応じてNAT/NAPTを通過する場合と、通過しない場合があります（[RFC4787]のセクション5を参照）。具体的には、IPアドレスとポートの組み合わせはエンドポイントに依存しないフィルタリングで動作しますが、IPアドレスとポートの変更は、アドレス依存またはアドレスとポート依存のフィルタリングを介して機能しません。これを考えると、別のIPアドレスおよび/またはUDPポートから応答することは推奨されません。
In the "Hub and Spoke" model, a carrier must be able to scale the solution to millions of Softwire Initiators by adding more hubs (i.e., Softwire Concentrators). L2TPv2 is a widely deployed protocol in broadband services, and its scalability has been proven in multiple large-scale IPv4 Virtual Private Network deployments, which scale up to millions of subscribers each.
「ハブアンドスポーク」モデルでは、キャリアは、ハブ（つまり、ソフトワイヤーコンセントレーター）を追加することにより、何百万ものソフトワイヤーイニシエーターにソリューションをスケーリングできる必要があります。L2TPV2はブロードバンドサービスで広く展開されているプロトコルであり、そのスケーラビリティは、複数の大規模なIPv4仮想プライベートネットワーク展開で証明されており、それぞれ数百万人のサブスクライバーに拡大しています。
There are no dynamic routing protocols between the SC and SI. A default route from the SI to the SC is used.
SCとSIの間に動的なルーティングプロトコルはありません。SIからSCへのデフォルトルートが使用されます。
Multicast protocols simply run transparently over L2TPv2 Softwires together with other regular IP traffic.
マルチキャストプロトコルは、他の通常のIPトラフィックとともに、L2TPV2ソフトウェアを介して単純に透過的に実行されます。
L2TPv2 supports optional mutual Control Channel authentication and leverages the optional mutual PPP per-session authentication. L2TPv2 is well integrated with AAA solutions (such as RADIUS) for both authentication and authorization. Most L2TPv2 implementations available in the market support the logging of authentication and authorization events.
L2TPV2は、オプションの相互制御チャネル認証をサポートし、オプションの相互PPPセッションごとの認証を活用します。L2TPV2は、認証と承認の両方について、AAAソリューション（RADIUSなど）と十分に統合されています。市場で利用可能なほとんどのL2TPV2実装は、認証と認証イベントの伐採をサポートしています。
L2TPv2 integration with RADIUS accounting (RADIUS Accounting extension for tunnel [RFC2867]) allows the collection and reporting of L2TPv2 Softwire usage statistics.
L2TPV2 RADIUSアカウンティング（トンネルのRADIUSアカウンティング拡張[RFC2867]）との統合により、L2TPV2ソフトワイヤー使用統計の収集と報告が可能になります。
Since L2TPv2 runs over IP/UDP in the Softwire context, IPsec Encapsulating Security Payload (ESP) can be used in conjunction to provide per-packet authentication, integrity, replay protection, and confidentiality for both L2TPv2 control and data traffic [RFC3193] and [RFC3948].
L2TPV2はSoftwireコンテキストでIP/UDPを介して実行されるため、IPSECのセキュリティペイロード（ESP）をカプセル化して、L2TPV2コントロールとデータトラフィックの両方のパケット認証、整合性、リプレイ保護、および機密性を提供するために使用できます[RFC3193]および[RFC3948]。
For Softwire deployments in which full payload security is not required, the L2TPv2 built-in Control Channel authentication and the inherited PPP authentication and PPP Encryption Control Protocol can be considered.
完全なペイロードセキュリティが不要なソフトワイヤーの展開の場合、L2TPV2内蔵コントロールチャネル認証と継承されたPPP認証とPPP暗号化制御プロトコルを考慮することができます。
L2TPv2 supports an optional in-band keepalive mechanism that injects HELLO control messages after a specified period of time has elapsed since the last data or control message was received on a tunnel (see Section 5.5 of [RFC2661]). If the HELLO control message is not reliably delivered, then the Control Channel and its Session will be torn down. In the Softwire context, the L2TPv2 keepalive is used to monitor the connectivity status between the SI and SC and/or as a refresh mechanism for any NAT/NAPT translation entry along the access link.
L2TPV2は、トンネルで最後のデータまたはコントロールメッセージが受信されてから指定された期間が経過した後にHello Controlメッセージを注入するオプションの帯域内キープライブメカニズムをサポートします（[RFC2661]のセクション5.5を参照）。Hello Controlメッセージが確実に配信されない場合、コントロールチャネルとそのセッションは取り壊されます。ソフトワイヤーのコンテキストでは、L2TPV2 KeepAliveを使用して、SIとSC間の接続ステータスを監視し、アクセスリンクに沿ったNAT/NAPT翻訳エントリの更新メカニズムとして監視します。
LCP ECHO offers a similar mechanism to monitor the connectivity status, as described in [RFC1661]. Softwire implementations SHOULD use L2TPv2 Hello keepalives, and in addition MAY use PPP LCP Echo messages to ensure Dead End Detection and/or to refresh NAT/NAPT translation entries. The combination of these two mechanisms can be used as an optimization.
LCP Echoは、[RFC1661]に記載されているように、接続ステータスを監視するための同様のメカニズムを提供します。Softwireの実装では、L2TPV2 Hello Keepalivesを使用する必要があります。さらに、PPP LCPエコーメッセージを使用して、行き止まりの検出を確実にし、NAT/NAPT翻訳エントリを更新する必要があります。これら2つのメカニズムの組み合わせは、最適化として使用できます。
The L2TPv2 MIB [RFC3371] supports the complete suite of management operations such as configuration of Control Channel and Session, polling of Control Channel and Session status and their traffic statistics and notifications of Control Channel and Session UP/DOWN events.
L2TPV2 MIB [RFC3371]は、コントロールチャネルとセッションの構成、制御チャネルとセッションステータスのポーリング、トラフィック統計、およびコントロールチャネルとセッションのアップ/ダウンイベントの通知など、管理操作の完全なスイートをサポートしています。
L2TPv2 supports the following encapsulations:
L2TPV2は次のカプセルをサポートしています。
o IPv6/PPP/L2TPv2/UDP/IPv4
o IPv6/PPP/L2TPV2/UDP/IPv4
o IPv4/PPP/L2TPv2/UDP/IPv6
o IPv4/PPP/L2TPV2/UDP/IPv6
o IPv4/PPP/L2TPv2/UDP/IPv4
o IPv4/PPP/L2TPV2/UDP/IPv4
o IPv6/PPP/L2TPv2/UDP/IPv6
o IPv6/PPP/L2TPV2/UDP/IPv6
Note that UDP bypass is not supported by L2TPv2 since L2TPv2 does not support "autodetect" of NAT/NAPT.
L2TPV2はNAT/NAPTの「AutoDeTect」をサポートしていないため、UDPバイパスはL2TPV2によってサポートされていないことに注意してください。
For the "Hub and Spoke" problem space, four scenarios have been identified. In each of these four scenarios, different home equipment plays the role of the Softwire Initiator. This section elaborates each scenario with L2TPv2 as the Softwire protocol and other possible protocols involved to complete the solution. This section examines the four scenarios for both IPv6-over-IPv4 (Section 3.1) and IPv4-over-IPv6 (Section 3.2) encapsulations.
「ハブとスポーク」の問題スペースについては、4つのシナリオが特定されています。これらの4つのシナリオのそれぞれで、異なるホーム機器がソフトワイヤーイニシエーターの役割を果たします。このセクションでは、ソフトワイヤープロトコルとしてL2TPV2を使用して各シナリオを、ソリューションを完了するために関係する他の可能なプロトコルについて説明します。このセクションでは、IPv6-over-IPv4（セクション3.1）とIPv4-over-IPV6（セクション3.2）の両方のカプセルの両方の4つのシナリオを検証します。
The following sub-sections cover IPv6 connectivity (SPH) across an IPv4-only access network (STH) using a Softwire.
次のサブセクションは、Softwireを使用してIPv4のみのアクセスネットワーク（STH）を介してIPv6接続（SPH）をカバーしています。
The Softwire Initiator (SI) is the host CPE (directly connected to a modem), which is dual-stack. There is no other gateway device. The IPv4 traffic SHOULD NOT traverse the Softwire. See Figure 1.
Softwire Initiator（SI）は、デュアルスタックであるホストCPE（モデムに直接接続されています）です。他のゲートウェイデバイスはありません。IPv4トラフィックは、ソフトワイヤーを横断してはなりません。図1を参照してください。
IPv6 or dual-stack IPv4-only dual-stack
|------------------||-----------------||----------|
I SC SI
N +-----+ +----------+
T | | | v4/v6 |
E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....| host CPE |
R [network] | | [ network ] | |
N | LNS | |LAC Client|
E +-----+ +----------+
T _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _() <-- IPv6 traffic
PPP o L2TPv2 o UDP o IPv4 (SPH)
Softwire
<------------------>
IPV6CP: capable of /64 Intf-Id assignment or
uniqueness check
|------------------>/64 prefix
RA
|------------------>DNS, etc.
DHCPv6
Figure 1: Host CPE as Softwire Initiator
図1：SoftwireイニシエーターとしてCPEをホスト
In this scenario, after the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, the IPv6 Control Protocol (IPV6CP) negotiates IPv6-over-PPP, which also provides the capability for the ISP to assign the 64-bit Interface-Identifier to the host CPE or perform uniqueness validation for the two interface identifiers at the two PPP ends [RFC5072]. After IPv6-over-PPP is up, IPv6 Stateless Address Autoconfiguration / Neighbor Discovery runs over the IPv6-over-PPP link, and the LNS can inform the host CPE of a prefix to use for stateless address autoconfiguration through a Router Advertisement (RA) while other non-address configuration options (such as DNS [RFC3646] or other servers' addresses that might be available) can be conveyed to the host CPE via DHCPv6.
このシナリオでは、L2TPV2制御チャネルとセッションの確立とPPP LCPの交渉（およびオプションではPPP認証）が成功した後、IPv6制御プロトコル（IPv6CP）はIPv6-over-PPPを交渉します。ホストCPEに64ビットインターフェイス識別子または2つのPPPエンドの2つのインターフェイス識別子の一意性検証を実行します[RFC5072]。IPv6-over-PPPが上昇した後、IPv6ステートレスアドレスAutoconfiguration / Neighbor DiscoveryがIPv6-over-PPPリンクを介して実行され、LNSはRouter Autoconfig Hurtersement（RA）を介してStateless Address Autoconfig hurationに使用するプレフィックスをホストCPEに通知できます。他の非アドレス構成オプション（DNS [RFC3646]または利用可能な他のサーバーのアドレスなど）は、DHCPV6を介してホストCPEに伝えることができます。
The Softwire Initiator (SI) is the router CPE, which is a dual-stack device. The IPv4 traffic SHOULD NOT traverse the Softwire. See Figure 2.
Softwire Initiator（SI）は、デュアルスタックデバイスであるルーターCPEです。IPv4トラフィックは、ソフトワイヤーを横断してはなりません。図2を参照してください。
IPv6 or dual-stack IPv4-only dual-stack
|------------------||-----------------||---------------------|
I SC SI
N +-----+ +----------+
T | | | v4/v6 | +-----+
E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....| CPE |----|v4/v6|
R [network] | | [ network ] | | | host|
N | LNS | |LAC Client| +-----+
E +-----+ +----------+
T _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _() <-------- IPv6 traffic
PPP o L2TPv2 o UDP o IPv4 (SPH)
Softwire
<------------------>
IPV6CP: capable of /64 Intf-Id assignment or
uniqueness check
|------------------>/64 prefix
RA
|------------------>/48 prefix,
DHCPv6 DNS, etc.
|------->/64 prefix
RA
|-------> DNS, etc.
DHCPv4/v6
Figure 2: Router CPE as Softwire Initiator
図2：ソフトワイヤーイニシエーターとしてのルーターCPE
In this scenario, after the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, IPV6CP negotiates IPv6-over-PPP, which also provides the capability for the ISP to assign the 64-bit Interface-Identifier to the router CPE or perform uniqueness validation for the two interface identifiers at the two PPP ends [RFC5072]. After IPv6-over-PPP is up, IPv6 Stateless Address Autoconfiguration / Neighbor Discovery runs over the IPv6-over-PPP link, and the LNS can inform the router CPE of a prefix to use for stateless address autoconfiguration through a Router Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g., delegating a prefix to be used within the home network [RFC3633]) and convey other non-address configuration options (such as DNS [RFC3646]) to the router CPE.
このシナリオでは、L2TPV2制御チャネルとセッションの確立とPPP LCPの交渉（およびオプションではPPP認証）が成功した後、IPv6CPはIPv6-over-apppを交渉します。ルーターCPEに、または2つのPPPエンドの2つのインターフェイス識別子の一意性検証を実行します[RFC5072]。IPv6-over-PPPが上昇した後、IPv6ステートレスアドレスAutoconfiguration / Neighbor DiscoveryがIPv6-over-PPPリンクを介して実行され、LNSはルーターCPEにRouter Address Autoconfigurationに使用するプレフィックスのルーターCPEに通知できます。。DHCPV6を使用して、IPv6プレフィックス委任（例えば、ホームネットワーク内で使用するプレフィックスを委任[RFC3633]）を実行し、他の非アドレス構成オプション（DNS [RFC3646]など）をルーターCPEに伝えることができます。
The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack host (behind the IPv4-only CPE), which acts as an IPv6 host CPE. The IPv4 traffic SHOULD NOT traverse the Softwire. See Figure 3.
CPEはIPv4のみです。Softwire Initiator（SI）は、IPv6ホストCPEとして機能するデュアルスタックホスト（IPv4のみのCPEの後ろ）です。IPv4トラフィックは、ソフトワイヤーを横断してはなりません。図3を参照してください。
IPv6 or dual-stack IPv4-only dual-stack
|------------------||----------------------------||----------|
I SC SI
N +-----+ +----------+
T | | +-------+ | v4/v6 |
E <==[ IPv6 ]....|v4/v6|....[IPv4-only]....|v4-only|--| host |
R [network] | | [ network ] | CPE | | |
N | LNS | +-------+ |LAC Client|
E +-----+ +----------+
T _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6
PPP o L2TPv2 o UDP o IPv4 traffic
Softwire (SPH)
<------------------------------>
IPV6CP: capable of /64 Intf-Id assignment or
uniqueness check
|------------------------------>/64 prefix
RA
|------------------------------>DNS, etc.
DHCPv6
Figure 3: Host behind CPE as Softwire Initiator
図3：CPEの背後にあるSoftwire Initiatorとしてホスト
In this scenario, after the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, IPV6CP negotiates IPv6-over-PPP, which also provides the capability for the ISP to assign the 64-bit Interface-Identifier to the host or perform uniqueness validation for the two interface identifiers at the two PPP ends [RFC5072]. After IPv6-over-PPP is up, IPv6 Stateless Address Autoconfiguration / Neighbor Discovery runs over the IPv6-over-PPP link, and the LNS can inform the host of a prefix to use for stateless address autoconfiguration through a Router Advertisement (RA) while other non-address configuration options (such as DNS [RFC3646]) can be conveyed to the host via DHCPv6.
このシナリオでは、L2TPV2制御チャネルとセッションの確立とPPP LCPの交渉（およびオプションではPPP認証）が成功した後、IPv6CPはIPv6-over-apppを交渉します。2つのPPPエンド[RFC5072]の2つのインターフェイス識別子のホストまたは一意性検証を実行します。IPv6-over-PPPが上昇した後、IPv6ステートレスアドレスAutoconfiguration / Neighbor DiscoveryがIPv6-over-PPPリンクを介して実行され、LNSは、ルーター広告（RA）を介したステートレスアドレスAutoconfigurationに使用するプレフィックスをホストに通知することができます。他の非アドレス構成オプション（DNS [RFC3646]など）は、DHCPV6を介してホストに伝達できます。
The CPE is IPv4-only. The Softwire Initiator (SI) is a dual-stack device (behind the IPv4-only CPE) acting as an IPv6 CPE router inside the home network. The IPv4 traffic SHOULD NOT traverse the Softwire. See Figure 4.
CPEはIPv4のみです。Softwire Initiator（SI）は、ホームネットワーク内のIPv6 CPEルーターとして機能するデュアルスタックデバイス（IPv4のみのCPEの後ろ）です。IPv4トラフィックは、ソフトワイヤーを横断してはなりません。図4を参照してください。
IPv6 or dual-stack IPv4-only dual-stack
|------------------||-------------------------||-------------|
I SC SI
N +-----+ +----------+
T | | +-------+ | v4/v6 |
E <==[ IPv6 ]....|v4/v6|..[IPv4-only]..|v4-only|---| router |
R [network] | | [ network ] | CPE | | | |
N | LNS | +-------+ | |LAC Client|
E +-----+ | +----------+
T |
---------+-----+
|v4/v6|
| host|
_ _ _ _ _ _ _ _ _ _ _ _ _ +-----+
()_ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv6
PPP o L2TPv2 o UDP o IPv4 traffic
Softwire (SPH)
<--------------------------->
IPV6CP: capable of /64 Intf-Id assignment or
uniqueness check
|--------------------------->/64 prefix
RA
|--------------------------->/48 prefix,
DHCPv6 DNS, etc.
|----> /64
RA prefix
|----> DNS,
DHCPv6 etc.
Figure 4: Router behind CPE as Softwire Initiator
図4：SoftwireイニシエーターとしてのCPEの背後にあるルーター
In this scenario, after the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, IPV6CP negotiates IPv6-over-PPP, which also provides the capability for the ISP to assign the 64-bit Interface-Identifier to the v4/v6 router or perform uniqueness validation for the two interface identifiers at the two PPP ends [RFC5072]. After IPv6-over-PPP is up, IPv6 Stateless Address Autoconfiguration / Neighbor Discovery runs over the IPv6-over-PPP link, and the LNS can inform the v4/v6 router of a prefix to use for stateless address autoconfiguration through a Router Advertisement (RA). DHCPv6 can be used to perform IPv6 Prefix Delegation (e.g., delegating a prefix to be used within the home network [RFC3633]) and convey other non-address configuration options (such as DNS [RFC3646]) to the v4/v6 router.
このシナリオでは、L2TPV2制御チャネルとセッションの確立とPPP LCPの交渉（およびオプションではPPP認証）が成功した後、IPv6CPはIPv6-over-apppを交渉します。V4/V6ルーターに、または2つのPPPエンドの2つのインターフェイス識別子の一意性検証を実行します[RFC5072]。IPv6-over-PPPがアップした後、IPv6ステートレスアドレスAutoconfiguration / Neighbor DiscoveryがIPv6-over-PPPリンクを介して実行され、LNSは、ルーター広告を介してステートレスアドレスの自動構成に使用するプレフィックスのV4 / V6ルーターに通知することができます（ra）。DHCPV6を使用して、IPv6プレフィックス委任（例えば、ホームネットワーク内で使用するプレフィックスを委任[RFC3633]）を実行し、他の非アドレス構成オプション（DNS [RFC3646]など）をV4/V6ルーターに伝えることができます。
The following sub-sections cover IPv4 connectivity (SPH) across an IPv6-only access network (STH) using a Softwire.
以下のサブセクションは、Softwireを使用してIPv6のみのアクセスネットワーク（STH）を介してIPv4接続（SPH）をカバーしています。
The Softwire Initiator (SI) is the host CPE (directly connected to a modem), which is dual-stack. There is no other gateway device. The IPv6 traffic SHOULD NOT traverse the Softwire. See Figure 5.
Softwire Initiator（SI）は、デュアルスタックであるホストCPE（モデムに直接接続されています）です。他のゲートウェイデバイスはありません。IPv6トラフィックは、ソフトワイヤーを横断してはなりません。図5を参照してください。
IPv4 or dual-stack IPv6-only dual-stack
|------------------||-----------------||----------|
I SC SI
N +-----+ +----------+
T | | | v4/v6 |
E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....| host CPE |
R [network] | | [ network ] | |
N | LNS | |LAC Client|
E +-----+ +----------+
T _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _() <-- IPv4 traffic
PPP o L2TPv2 o UDP o IPv6 (SPH)
Softwire
<------------------>
IPCP: capable of global IP assignment
and DNS, etc.
Figure 5: Host CPE as Softwire Initiator
図5：SoftwireイニシエーターとしてCPEをホスト
In this scenario, after the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, the IP Control Protocol (IPCP) negotiates IPv4-over-PPP, which also provides the capability for the ISP to assign a global IPv4 address to the host CPE. A global IPv4 address can also be assigned via DHCP. Other configuration options (such as DNS) can be conveyed to the host CPE via IPCP [RFC1877] or DHCP [RFC2132].
このシナリオでは、L2TPV2制御チャネルとセッションの確立とPPP LCPの交渉（およびオプションではPPP認証）が成功した後、IPコントロールプロトコル（IPCP）はIPv4-over-PPPを交渉します。ホストCPEへのグローバルIPv4アドレス。グローバルIPv4アドレスは、DHCPを介して割り当てることもできます。その他の構成オプション（DNSなど）は、IPCP [RFC1877]またはDHCP [RFC2132]を介してホストCPEに伝達できます。
The Softwire Initiator (SI) is the router CPE, which is a dual-stack device. The IPv6 traffic SHOULD NOT traverse the Softwire. See Figure 6.
Softwire Initiator（SI）は、デュアルスタックデバイスであるルーターCPEです。IPv6トラフィックは、ソフトワイヤーを横断してはなりません。図6を参照してください。
IPv4 or dual-stack IPv6-only dual-stack Home
|------------------||-----------------||-------------------|
I SC SI
N +-----+ +----------+
T | | | v4/v6 | +-----+
E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....| CPE |--|v4/v6|
R [network] | | [ network ] | | | host|
N | LNS | |LAC Client| +-----+
E +-----+ +----------+
T _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _() <--------- IPv4 traffic
PPP o L2TPv2 o UDP o IPv6 (SPH)
Softwire
<------------------>
IPCP: capable of global IP assignment
and DNS, etc.
|------------------>
DHCPv4: prefix, mask, PD
private/
|------> global
DHCP IP, DNS,
etc.
Figure 6: Router CPE as Softwire Initiator
図6：ソフトワイヤーイニシエーターとしてのルーターCPE
In this scenario, after the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, IPCP negotiates IPv4-over-PPP, which also provides the capability for the ISP to assign a global IPv4 address to the router CPE. A global IPv4 address can also be assigned via DHCP. Other configuration options (such as DNS) can be conveyed to the router CPE via IPCP [RFC1877] or DHCP [RFC2132]. For IPv4 Prefix Delegation for the home network, DHCP [SUBNET-ALL] can be used.
このシナリオでは、L2TPV2制御チャネルとセッションの確立とPPP LCPの交渉（およびオプションではPPP認証）が成功した後、IPCPはIPv4-over-PPPを交渉します。これにより、ISPがグローバルIPv4アドレスをルーターに割り当てる機能も提供します。CPE。グローバルIPv4アドレスは、DHCPを介して割り当てることもできます。その他の構成オプション（DNSなど）は、IPCP [RFC1877]またはDHCP [RFC2132]を介してルーターCPEに伝達できます。ホームネットワーク用のIPv4プレフィックス委任の場合、DHCP [Subnet-All]を使用できます。
The CPE is IPv6-only. The Softwire Initiator (SI) is a dual-stack host (behind the IPv6 CPE), which acts as an IPv4 host CPE. The IPv6 traffic SHOULD NOT traverse the Softwire. See Figure 7.
CPEはIPv6のみです。Softwire Initiator（SI）は、IPv4ホストCPEとして機能するデュアルスタックホスト（IPv6 CPEの後ろ）です。IPv6トラフィックは、ソフトワイヤーを横断してはなりません。図7を参照してください。
IPv4 or dual-stack IPv6-only dual-stack
|------------------||----------------------------||----------|
I SC SI
N +-----+ +----------+
T | | +-------+ | v4/v6 |
E <==[ IPv4 ]....|v4/v6|....[IPv6-only]....|v6-only|--| host |
R [network] | | [ network ] | CPE | | |
N | LNS | +-------+ |LAC Client|
E +-----+ +----------+
T _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _() <-- IPv4
PPP o L2TPv2 o UDP o IPv6 traffic
Softwire (SPH)
<------------------------------>
IPCP: capable of global IP assignment
and DNS, etc.
Figure 7: Host behind CPE as Softwire Initiator
図7：Softwire InitiatorとしてCPEの背後にあるホスト
In this scenario, after the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, IPCP negotiates IPv4-over-PPP, which also provides the capability for the ISP to assign a global IPv4 address to the host. A global IPv4 address can also be assigned via DHCP. Other configuration options (such as DNS) can be conveyed to the host CPE via IPCP [RFC1877] or DHCP [RFC2132].
このシナリオでは、L2TPV2制御チャネルとセッションの確立とPPP LCPの交渉（およびオプションではPPP認証）が成功した後、IPCPはIPv4-over-PPPを交渉します。これにより、ISPがグローバルIPv4アドレスをホストに割り当てる機能も提供します。。グローバルIPv4アドレスは、DHCPを介して割り当てることもできます。その他の構成オプション（DNSなど）は、IPCP [RFC1877]またはDHCP [RFC2132]を介してホストCPEに伝達できます。
The CPE is IPv6-only. The Softwire Initiator (SI) is a dual-stack device (behind the IPv6-only CPE) acting as an IPv4 CPE router inside the home network. The IPv6 traffic SHOULD NOT traverse the Softwire. See Figure 8.
CPEはIPv6のみです。Softwire Initiator（SI）は、ホームネットワーク内のIPv4 CPEルーターとして機能するデュアルスタックデバイス（IPv6のみのCPEの後ろ）です。IPv6トラフィックは、ソフトワイヤーを横断してはなりません。図8を参照してください。
IPv4 or dual-stack IPv6-only dual-stack
|------------------||-------------------------||------------|
I SC SI
N +-----+ +----------+
T | | +-------+ | v4/v6 |
E <==[ IPv4 ]....|v4/v6|..[IPv6-only]..|v6-only|---| router |
R [network] | | [ network ] | CPE | | | |
N | LNS | +-------+ | |LAC Client|
E +-----+ | +----------+
T |
--------+-----+
|v4/v6|
| host|
_ _ _ _ _ _ _ _ _ _ _ _ _ +-----+
()_ _ _ _ _ _ _ _ _ _ _ _ _() <--- IPv4
PPP o L2TPv2 o UDP o IPv4 traffic
Softwire (SPH)
<--------------------------->
IPCP: assigns global IP address and DNS, etc.
|--------------------------->
DHCPv4: prefix, mask, PD
private/
|----> global
DHCP IP, DNS,
etc.
Figure 8: Router behind CPE as Softwire Initiator
図8：SoftwireイニシエーターとしてのCPEの背後にあるルーター
In this scenario, after the L2TPv2 Control Channel and Session establishment and PPP LCP negotiation (and optionally PPP Authentication) are successful, IPCP negotiates IPv4-over-PPP, which also provides the capability for the ISP to assign a global IPv4 address to the v4/v6 router. A global IPv4 address can also be assigned via DHCP. Other configuration options (such as DNS) can be conveyed to the v4/v6 router via IPCP [RFC1877] or DHCP [RFC2132]. For IPv4 Prefix Delegation for the home network, DHCP [SUBNET-ALL] can be used.
このシナリオでは、L2TPV2制御チャネルとセッションの確立とPPP LCPの交渉（およびオプションではPPP認証）が成功した後、IPCPはIPv4-over-PPPを交渉します。/V6ルーター。グローバルIPv4アドレスは、DHCPを介して割り当てることもできます。その他の構成オプション（DNSなど）は、IPCP [RFC1877]またはDHCP [RFC2132]を介してV4/V6ルーターに伝達できます。ホームネットワーク用のIPv4プレフィックス委任の場合、DHCP [Subnet-All]を使用できます。
This section lists and groups documents from the Internet standardization describing technologies used to design the framework of the Softwire "Hub and Spoke" solution. This emphasizes the motivation of Softwire to reuse as many existing standards as possible. This list contains both Standards Track (Proposed Standard, Draft Standard, and Standard) and Informational documents. The list of documents and their status should only be only used for description purposes.
このセクションには、ソフトワイヤーの「ハブとスポーク」ソリューションのフレームワークを設計するために使用されるテクノロジーを説明するインターネット標準化のドキュメントをリストおよびグループ化します。これは、ソフトワイヤーができるだけ多くの既存の基準を再利用する動機を強調しています。このリストには、標準トラック（提案された標準、ドラフト標準、および標準）と情報文書の両方が含まれています。ドキュメントのリストとそのステータスは、説明目的でのみ使用する必要があります。
RFC 2661 "Layer Two Tunneling Protocol 'L2TP'" [RFC2661].
RFC 2661 "レイヤー2トンネリングプロトコル 'L2TP" "[RFC2661]。
* For both IPv4 and IPv6 payloads (SPH), support is complete.
* IPv4とIPv6ペイロード（SPH）の両方で、サポートが完了します。
* For both IPv4 and IPv6 transports (STH), support is complete.
* IPv4とIPv6トランスポート（STH）の両方で、サポートが完了します。
RFC 3193 "Securing L2TP using IPsec" [RFC3193].
RFC 3193「IPSECを使用したL2TPの保護」[RFC3193]。
RFC 3948 "UDP Encapsulation of IPsec ESP Packets" [RFC3948].
RFC 3948「IPSEC ESPパケットのUDPカプセル化」[RFC3948]。
* IPsec supports both IPv4 and IPv6 transports.
* IPSECは、IPv4とIPv6トランスポートの両方をサポートしています。
RFC 2865 "Remote Authentication Dial In User Service (RADIUS)" [RFC2865].
RFC 2865「ユーザーサービス（RADIUS）のリモート認証ダイヤル（RADIUS）」[RFC2865]。
* Updated by [RFC2868], [RFC3575], and [RFC5080].
* [RFC2868]、[RFC3575]、および[RFC5080]によって更新されました。
RFC 2867 "RADIUS Accounting Modifications for Tunnel Protocol Support" [RFC2867].
RFC 2867「トンネルプロトコルサポートのための半径の会計変更」[RFC2867]。
RFC 2868 "RADIUS Attributes for Tunnel Protocol Support" [RFC2868].
RFC 2868「トンネルプロトコルサポートの半径属性」[RFC2868]。
RFC 3162 "RADIUS and IPv6" [RFC3162].
RFC 3162 "半径とIPv6" [RFC3162]。
RFC 1471 "The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol" [RFC1471].
RFC 1471「ポイントツーポイントプロトコルのリンク制御プロトコルの管理されたオブジェクトの定義[RFC1471]。
RFC 1473 "The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol" [RFC1473].
RFC 1473「ポイントツーポイントプロトコルのIPネットワーク制御プロトコルの管理されたオブジェクトの定義」[RFC1473]。
RFC 3371 "Layer Two Tunneling Protocol "L2TP" Management Information Base" [RFC3371].
RFC 3371 "レイヤー2つのトンネリングプロトコル" L2TP "管理情報ベース" [RFC3371]。
RFC 4087 "IP Tunnel MIB" [RFC4087].
RFC 4087 "IPトンネルMIB" [RFC4087]。
* Both IPv4 and IPv6 transports are supported.
* IPv4とIPv6トランスポートの両方がサポートされています。
RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861].
RFC 4861「IPバージョン6（IPv6）の近隣発見」[RFC4861]。
RFC 4862 "IPv6 Stateless Address Autoconfiguration" [RFC4862].
RFC 4862 "IPv6ステートレスアドレスAutoconfiguration" [RFC4862]。
RFC 5072 "IP Version 6 over PPP" [RFC5072].
RFC 5072 "PPP上のIPバージョン6" [RFC5072]。
RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" [RFC3315].
RFC 3315 "IPv6（dhcpv6）の動的ホスト構成プロトコル" [RFC3315]。
RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" [RFC3633].
RFC 3633 "Dynamic Host Configuration Protocol（DHCP）バージョン6" [RFC3633]のIPv6プレフィックスオプション。
RFC 3646 "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" [RFC3646].
RFC 3646 "IPv6（DHCPV6）の動的ホスト構成プロトコルのDNS構成オプション[RFC3646]。
RFC 3736 "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6" [RFC3736].
RFC 3736 "IPv6用のステートレス動的ホスト構成プロトコル（DHCP）サービス[RFC3736]。
RFC 1332 "The PPP Internet Protocol Control Protocol (IPCP)" [RFC1332].
RFC 1332 "PPPインターネットプロトコル制御プロトコル（IPCP）" [RFC1332]。
RFC 1661 "The Point-to-Point Protocol (PPP)" [RFC1661].
RFC 1661「ポイントツーポイントプロトコル（PPP）」[RFC1661]。
RFC 1877 "PPP Internet Protocol Control Protocol Extensions for Name Server Addresses" [RFC1877].
RFC 1877「名前サーバーアドレスのPPPインターネットプロトコル制御プロトコル拡張」[RFC1877]。
RFC 2131 "Dynamic Host Configuration Protocol" [RFC2131].
RFC 2131「動的ホスト構成プロトコル」[RFC2131]。
RFC 2132 "DHCP Options and BOOTP Vendor Extensions" [RFC2132].
RFC 2132「DHCPオプションとBOOTPベンダー拡張機能」[RFC2132]。
DHCP Subnet Allocation "Subnet Allocation Option".
DHCPサブネット割り当て「サブネット割り当てオプション」。
* Work in progress, see [SUBNET-ALL].
* 進行中の作業、[subnet-all]を参照してください。
A Softwire is established in three distinct steps, potentially preceded by an optional IPsec-related step 0 (see Figure 9). First, an L2TPv2 tunnel with a single session is established from the SI to the SC. Second, a PPP session is established over the L2TPv2 session and the SI obtains an address. Third, the SI optionally gets other information through DHCP such as a delegated prefix and DNS servers.
ソフトワイヤーは3つの異なるステップで確立され、オプションのIPSEC関連のステップ0が先行する可能性があります（図9を参照）。まず、SIからSCまでの1回のセッションを備えたL2TPV2トンネルが確立されます。第二に、L2TPV2セッションでPPPセッションが確立され、SIはアドレスを取得します。第三に、SIはオプションで、委任されたプレフィックスやDNSサーバーなどのDHCPを介して他の情報を取得します。
SC SI
| |
|<-------------IKEv1------------->| Step 0
| | IPsec SA establishment
| | (optional)
| |
|<-------------L2TPv2------------>| Step 1
| | L2TPv2 Tunnel establishment
| |
|<--------------PPP-------------->| Step 2
|<-----Endpoint Configuration---->| PPP and Endpoint
| | configuration
| |
|<------Router Configuration----->| Step 3
| | Additional configuration
| | (optional)
Figure 9: Steps for the Establishment of a Softwire
図9：ソフトワイヤの設立の手順
Figure 10 depicts details of each of these steps required to establish a Softwire.
図10は、ソフトワイヤを確立するために必要なこれらの各手順の詳細を示しています。
SC SI
| |
| | Step 0
|<------------IKEv1-------------->| = IKEv1 (Optional)
| |
| | Step 1
|<------------SCCRQ---------------| -
|-------------SCCRP-------------->| |
|<------------SCCCN---------------| |
|<------------ICRQ----------------| | L2TPv2
|-------------ICRP--------------->| |
|<------------ICCN----------------| -
| |
| | Step 2
|<-----Configuration-Request------| -
|------Configuration-Request----->| | PPP
|--------Configuration-Ack------->| | LCP
|<-------Configuration-Ack--------| -
| |
|-----------Challenge------------>| - PPP Authentication
|<----------Response--------------| | (Optional - CHAP)
|------------Success------------->| -
| |
|<-----Configuration-Request------| -
|------Configuration-Request----->| | PPP NCP
|--------Configuration-Ack------->| | (IPV6CP or IPCP)
|<-------Configuration-Ack--------| -
| |
|<------Router-Solicitation-------| - Neighbor Discovery
|-------Router-Advertisement----->| | (IPv6 only)
| | -
| |
| | Step3
| | DHCP (Optional)
|<-----------SOLICIT--------------| -
|-----------ADVERTISE------------>| | DHCPv6
|<---------- REQUEST--------------| | (IPv6 SW, Optional)
|-------------REPLY-------------->| -
| | or
|<---------DHCPDISCOVER-----------| -
|-----------DHCPOFFER------------>| | DHCPv4
|<---------DHCPREQUEST------------| | (IPv4 SW, Optional)
|------------DHCPACK------------->| -
Figure 10: Detailed Steps in the Establishment of a Softwire
図10：ソフトワイヤの確立における詳細な手順
The IPsec-related negotiations in step 0 are optional. The L2TPv2 negotiations in step 1 are described in Section 5.1. The PPP Network Control Protocol (NCP) negotiations in step 2 use IPV6CP for IPv6- over-IPv4 Softwires, and IPCP for IPv4-over-IPv6 Softwires (see Section 5.2.4). The optional DHCP negotiations in step 3 use DHCPv6 for IPv6-over-IPv4 Softwires, and DHCPv4 for IPv4-over-IPv6 Softwires (see Section 5.4). Additionally, for IPv6-over-IPv4 Softwires, the DHCPv6 exchange for non-address configuration (such as DNS) can use Stateless DHCPv6, the two-message exchange with Information-Request and Reply messages (see Section 1.2 of [RFC3315] and [RFC3736]).
ステップ0のIPSEC関連の交渉はオプションです。ステップ1のL2TPV2交渉は、セクション5.1で説明されています。ステップ2のPPPネットワークコントロールプロトコル（NCP）交渉は、IPv6-オーバーIPV4ソフトウェアにIPv6CP、IPv4-over-IPV6ソフトウェアのIPCPを使用します（セクション5.2.4を参照）。ステップ3のオプションのDHCP交渉は、IPv6-over-IPV4ソフトワイヤにDHCPV6、IPv4-over-IPV6ソフトワイヤにはDHCPV4を使用します（セクション5.4を参照）。さらに、IPv6-over-IPV4ソフトウェアの場合、非アドレス構成のDHCPV6交換（DNSなど）は、Stateless DHCPV6、情報の要求と応答メッセージを含む2メッセージの交換を使用できます（[RFC3315]および[[RFC3315]および[RFC3736]）。
L2TPv2 [RFC2661] was originally designed to provide private network access to end users connected to a public network. In the L2TPv2 incoming call model, the end user makes a connection to an L2TP Access Concentrator (LAC). The LAC then initiates an L2TPv2 tunnel to an L2TP Network Server (LNS). The LNS then transfers end-user traffic between the L2TPv2 tunnel and the private network.
L2TPV2 [RFC2661]は、パブリックネットワークに接続されたエンドユーザーへのプライベートネットワークアクセスを提供するように設計されていました。L2TPV2着信コールモデルでは、エンドユーザーがL2TPアクセス濃縮器（LAC）に接続します。LACは、L2TPV2トンネルをL2TPネットワークサーバー（LNS）に開始します。LNSは、L2TPV2トンネルとプライベートネットワークの間にエンドユーザートラフィックを転送します。
In the Softwire "Hub and Spoke" model, the Softwire Initiator (SI) assumes the role of the LAC Client and the Softwire Concentrator (SC) assumes the role of the LNS.
Softwireの「Hub and Spoke」モデルでは、Softwire Initiator（SI）はLACクライアントの役割を引き受け、Softwire Concentor（SC）はLNSの役割を引き受けます。
In the Softwire model, an L2TPv2 packet MUST be carried over UDP. The underlying version of the IP protocol may be IPv4 or IPv6, depending on the Softwire scenario.
Softwireモデルでは、L2TPV2パケットをUDPに携帯する必要があります。IPプロトコルの基礎となるバージョンは、Softwireシナリオに応じて、IPv4またはIPv6です。
In the following sections, the term "Tunnel" follows the definition from Section 1.2 of [RFC2661], namely: "The Tunnel consists of a Control Connection and zero or more L2TP Sessions".
次のセクションでは、「トンネル」という用語は、[RFC2661]のセクション1.2の定義に従います。つまり、「トンネルは制御接続とゼロ以上のL2TPセッションで構成されています」。
Figure 11 describes the messages exchanged and Attribute Value Pairs (AVPs) used to establish a tunnel between an SI (LAC) and an SC (LNS). The messages and AVPs described here are only a subset of those defined in [RFC2661]. This is because Softwires use only a subset of the L2TPv2 functionality. The subset of L2TP Control Connection Management AVPs that is applicable to Softwires is grouped into Required AVPs and Optional AVPs on a per-control-message basis (see Figure 11). For each control message, Required AVPs include all the "MUST be present" AVPs from [RFC2661] for that control message, and Optional AVPs include the "MAY be present" AVPs from [RFC2661] that are used in the Softwire context on that control message. Note that in the Softwire environment, the SI always initiates the tunnel. L2TPv2 AVPs SHOULD NOT be hidden.
図11は、交換されたメッセージと、Si（LAC）とSC（LNS）の間にトンネルを確立するために使用される値ペア（AVP）を属性します。ここで説明するメッセージとAVPは、[RFC2661]で定義されているサブセットのサブセットのみです。これは、ソフトウェアがL2TPV2機能のサブセットのみを使用しているためです。ソフトウェアに適用可能なL2TP制御接続管理AVPのサブセットは、コントロールに基づいて必要なAVPとオプションのAVPにグループ化されます（図11を参照）。各コントロールメッセージについて、必要なAVPには、そのコントロールメッセージの[RFC2661]のすべての「存在する必要があります」AVPが含まれ、オプションのAVPには、そのコントロールのソフトワイヤーコンテキストで使用される[RFC2661]の「存在する可能性があります」AVPが含まれます。メッセージ。Softwire環境では、SIは常にトンネルを開始することに注意してください。L2TPV2 AVPSを非表示にしないでください。
SC SI
|<--------SCCRQ---------|
Required AVPs:
Message Type
Protocol Version
Host Name
Framing Capabilities
Assigned Tunnel ID
Optional AVPs:
Receive Window Size
Challenge
Firmware Revision
Vendor Name
|---------SCCRP-------->|
Required AVPs:
Message Type
Protocol Version
Framing Capabilities
Host Name
Assigned Tunnel ID
Optional AVPs:
Firmware Revision
Vendor Name
Receive Window Size
Challenge
Challenge Response
|<--------SCCCN---------|
Required AVPs:
Message Type
Optional AVPs:
Challenge Response
Figure 11: Control Connection Establishment
図11：制御接続の確立
In L2TPv2, generally, the tunnel between an LAC and LNS may carry the data of multiple users. Each of these users is represented by an L2TPv2 session within the tunnel. In the Softwire environment, the tunnel carries the information of a single user. Consequently, there is only one L2TPv2 session per tunnel. Figure 12 describes the messages exchanged and the AVPs used to establish a session between an SI (LAC) and an SC (LNS). The messages and AVPs described here are only a subset of those defined in [RFC2661]. This is because Softwires use only a subset of the L2TPv2 functionality. The subset of L2TP Call Management (i.e., Session Management) AVPs that is applicable to Softwires is grouped into Required AVPs and Optional AVPs on a per-control-message basis (see Figure 12). For each control message, Required AVPs include all the "MUST be present" AVPs from [RFC2661] for that control message, and Optional AVPs include the "MAY be present" AVPs from [RFC2661] that are used in the Softwire context on that control message. Note that in the Softwire environment, the SI always initiates the session. An L2TPv2 session setup for a Softwire uses only the incoming call model. No outgoing or analog calls (sessions) are permitted. L2TPv2 AVPs SHOULD NOT be hidden.
L2TPV2では、一般的に、LACとLNSの間のトンネルには、複数のユーザーのデータが含まれる場合があります。これらの各ユーザーは、トンネル内のL2TPV2セッションで表されます。ソフトワイヤー環境では、トンネルには単一のユーザーの情報が含まれています。その結果、トンネルごとにL2TPV2セッションは1つだけです。図12は、交換されたメッセージと、SI（LAC）とSC（LNS）の間のセッションを確立するために使用されるAVPを説明しています。ここで説明するメッセージとAVPは、[RFC2661]で定義されているサブセットのサブセットのみです。これは、ソフトウェアがL2TPV2機能のサブセットのみを使用しているためです。L2TPコール管理（つまり、セッション管理）のサブセットは、ソフトワイヤに適用されるAVPSが、コントロールに基づいて必要なAVPとオプションのAVPにグループ化されます（図12を参照）。各コントロールメッセージについて、必要なAVPには、そのコントロールメッセージの[RFC2661]のすべての「存在する必要があります」AVPが含まれ、オプションのAVPには、そのコントロールのソフトワイヤーコンテキストで使用される[RFC2661]の「存在する可能性があります」AVPが含まれます。メッセージ。Softwire環境では、SIは常にセッションを開始することに注意してください。SoftwireのL2TPV2セッションセットアップは、着信コールモデルのみを使用します。発信またはアナログコール（セッション）は許可されていません。L2TPV2 AVPSを非表示にしないでください。
SC SI
|<--------ICRQ---------|
Required AVPs:
Message Type
Assigned Session ID
Call Serial Number
|---------ICRP-------->|
Required AVPs:
Message Type
Assigned Session ID
|<--------ICCN---------|
Required AVPs:
Message Type
(Tx) Connect Speed
Framing Type
Figure 12: Session Establishment
図12：セッションの確立
The following sub-sections (5.1.1.1 through 5.1.1.3) describe in more detail the Control Connection and Session establishment AVPs (see message flows in Figures 11 and 12, respectively) that are required, optional and not relevant for the L2TPv2 Tunnel establishment of a Softwire. Specific L2TPv2 protocol messages and flows that are not explicitly described in these sections are handled as defined in [RFC2661].
次のサブセクション（5.1.1.1〜5.1.1.3）は、必要なコントロール接続とセッションの確立AVP（それぞれ図11と12のメッセージフローを参照）をより詳細に説明しています。ソフトワイヤの。これらのセクションで明示的に説明されていない特定のL2TPV2プロトコルメッセージとフローは、[RFC2661]で定義されているように処理されます。
The mechanism for hiding AVP Attribute values is used, as described in Section 4.3 of [RFC2661], to hide sensitive control message data such as usernames, user passwords, or IDs, instead of sending the AVP contents in the clear. Since AVPs used in L2TP messages for the Softwire establishment do not transport such sensitive data, L2TPv2 AVPs SHOULD NOT be hidden.
[RFC2661]のセクション4.3で説明されているように、AVP属性値を隠すメカニズムが使用され、AVPコンテンツをクリアに送信する代わりに、ユーザー名、ユーザーパスワード、またはIDなどの機密コントロールメッセージデータを非表示にします。Softwireの確立のL2TPメッセージで使用されているAVPは、このような機密データを輸送しないため、L2TPV2 AVPは非表示にすべきではありません。
This section prescribes specific values for AVPs that are required (by [RFC2661]) to be present in one or more of the messages used for the Softwire establishment, as they are used in the Softwire context. It combines all the Required AVPs from all the control messages in Section 5.1.1, and provides Softwire-specific use guidance.
このセクションでは、ソフトワイヤーのコンテキストで使用されているため、ソフトワイヤーの施設に使用される1つ以上のメッセージに存在する必要があるAVPの特定の値を規定しています。セクション5.1.1のすべての制御メッセージから必要なすべてのAVPを組み合わせて、ソフトワイヤー固有の使用ガイダンスを提供します。
Host Name AVP
ホスト名AVP
This AVP is required in SCCRQ and SCCRP messages. This AVP MAY be used to authenticate users, in which case it would contain a user identification. If this AVP is not used to authenticate users, it may be used for logging purposes.
このAVPは、SCCRQおよびSCCRPメッセージで必要です。このAVPは、ユーザーを認証するために使用される場合があります。その場合、ユーザー識別が含まれます。このAVPがユーザーの認証に使用されていない場合、ロギング目的に使用される場合があります。
Framing Capabilities AVP
フレーミング機能AVP
Both the synchronous (S) and asynchronous (A) bits SHOULD be set to 1. This AVP SHOULD be ignored by the receiver.
同期（s）と非同期（a）ビットの両方を1に設定する必要があります。このAVPは、受信機によって無視する必要があります。
Framing Type AVP
フレーミングタイプAVP
The synchronous bit SHOULD be set to 1 and the asynchronous bit to 0. This AVP SHOULD be ignored by the receiver.
同期ビットは1に設定し、非同期ビットを0に設定する必要があります。このAVPは、受信機によって無視する必要があります。
(Tx) Connect Speed AVP
（TX）速度AVPを接続します
(Tx) Connect Speed is a required AVP but is not meaningful in the Softwire context. Its value SHOULD be set to 0 and ignored by the receiver.
（TX）接続速度は必要なAVPですが、ソフトワイヤーのコンテキストでは意味がありません。その値は0に設定し、受信機によって無視する必要があります。
Message Type AVP, Protocol Version AVP, Assigned Tunnel ID AVP, Call Serial Number AVP, and Assigned Session ID AVP
メッセージタイプAVP、プロトコルバージョンAVP、割り当てられたトンネルIDAVP、シリアル番号AVPを呼び出し、セッションID AVPを割り当てました
As defined in [RFC2661].
[RFC2661]で定義されています。
This section prescribes specific values for AVPs that are Optional (not required by [RFC2661]) but used in the Softwire context. It combines all the Optional AVPs from all the control messages in Section 5.1.1, and provides Softwire-specific use guidance.
このセクションでは、オプション（[RFC2661]では要求されていない）がソフトワイヤーのコンテキストで使用されるAVPの特定の値を規定しています。セクション5.1.1のすべての制御メッセージからのすべてのオプションAVPを組み合わせて、ソフトワイヤー固有の使用ガイダンスを提供します。
Challenge AVP and Challenge Response AVP
AVPとチャレンジ対応AVPに挑戦します
These AVPs are not required, but are necessary to implement tunnel authentication. Since tunnel authentication happens at the beginning of L2TPv2 tunnel creation, it can be helpful in preventing denial-of-service (DoS) attacks. See Section 5.1.1 of [RFC2661].
これらのAVPは必須ではありませんが、トンネル認証を実装するために必要です。トンネル認証は、L2TPV2トンネルの作成の開始時に行われるため、サービス拒否（DOS）攻撃の防止に役立ちます。[RFC2661]のセクション5.1.1を参照してください。
The usage of these AVPs in L2TP messages is OPTIONAL, but SHOULD be implemented in the SC.
L2TPメッセージでのこれらのAVPの使用はオプションですが、SCで実装する必要があります。
Receive Window Size AVP, Firmware Revision AVP, and Vendor Name AVP
ウィンドウサイズのAVP、ファームウェアリビジョンAVP、およびベンダー名AVPを受信します
As defined in [RFC2661].
[RFC2661]で定義されています。
L2TPv2 specifies numerous AVPs that, while allowed for a given message, are irrelevant to Softwires. They can be irrelevant to Softwires because they do not apply to the Softwire establishment flow (e.g., they are only used in the Outgoing Call establishment message exchange, while Softwires only use the Incoming Call message flow), or because they are Optional AVPs that are not used. L2TPv2 AVPs that are relevant to Softwires were covered in Sections 5.1.1, 5.1.1.1, and 5.1.1.2. Softwire implementations SHOULD NOT send AVPs that are not relevant to Softwires. However, they SHOULD ignore them when they are received. This will simplify the creation of Softwire applications that build upon existing L2TPv2 implementations.
L2TPV2は、特定のメッセージを許可しますが、ソフトウェアとは無関係である多数のAVPを指定します。ソフトワイヤーの確立フローには適用されないため、ソフトウェアには無関係になります（たとえば、発信コール設立メッセージ交換でのみ使用されますが、ソフトウェアは着信コールメッセージフローのみを使用します）、またはそれらはオプションのAVPであるためです。使用されていない。ソフトウェアに関連するL2TPV2 AVPは、セクション5.1.1、5.1.1.1、および5.1.1.2で覆われています。Softwireの実装は、ソフトワイヤに関連しないAVPを送信しないでください。ただし、受け取ったときにそれらを無視する必要があります。これにより、既存のL2TPV2実装に基づいたSoftwireアプリケーションの作成が簡素化されます。
Periodically, the SI/SC MUST transmit a message to the peer to detect tunnel or peer failure and maintain NAT/NAPT contexts. The L2TPv2 HELLO message provides a simple, low-overhead method of doing this.
定期的に、SI/SCは、トンネルまたはピアの故障を検出し、NAT/NAPTコンテキストを維持するためにピアにメッセージを送信する必要があります。L2TPV2 Helloメッセージは、これを行うシンプルで低オーバーヘッドの方法を提供します。
The default values specified in [RFC2661] for L2TPv2 HELLO messages could result in a dead-end detection time of 83 seconds. Although these retransmission timers and counters SHOULD be configurable (see Section 5.8 of [RFC2661]), these values may not be adapted for all situations, where a quicker dead-end detection is required, or where NAT/NAPT context needs to be refreshed more frequently. In such cases, the SI/SC MAY use, in combination with L2TPv2 HELLO, LCP ECHO messages (Echo-Request and Echo-Reply codes) described in [RFC1661]. When used, LCP ECHO messages SHOULD have a re-emission timer lower than the value for L2TPv2 HELLO messages. The default value recommended in Section 6.5 of [RFC2661] for the HELLO message retransmission interval is 60 seconds. When used, a set of suggested values (included here only for guidance) for the LCP ECHO message request interval is a default of 30 seconds, a minimum of 10 seconds, and a maximum of the lesser of the configured L2TPv2 HELLO retransmission interval and 60 seconds.
L2TPV2 Helloメッセージの[RFC2661]で指定されたデフォルト値は、83秒の行き止まりの検出時間になる可能性があります。これらの再送信タイマーとカウンターは構成可能である必要がありますが（[RFC2661]のセクション5.8を参照）、これらの値はすべての状況、より迅速な行き止まりの検出が必要な場合、またはNAT/NAPTコンテキストをさらに更新する必要がある場合に適合しない場合があります。頻繁に。そのような場合、Si/SCは、[RFC1661]で説明されているL2TPV2 Hello、LCPエコーメッセージ（Echo-RequestおよびEcho-Replyコード）と組み合わせて使用する場合があります。使用する場合、LCPエコーメッセージには、L2TPV2ハローメッセージの値よりも低い再排出タイマーが必要です。Hello Message再送信間隔の[RFC2661]のセクション6.5で推奨されるデフォルト値は60秒です。使用する場合、LCPエコーメッセージ要求インターバルの提案値のセット（ここにはガイダンスのみを含む）は、デフォルトの30秒、最低10秒、構成されたL2TPV2ハロー再送信間隔の最大値と60秒。
Either the SI or SC can tear down the session and tunnel. This is done as specified in Section 5.7 of [RFC2661], by sending a StopCCN control message. There is no action specific to Softwires in this case.
SIまたはSCのいずれかがセッションとトンネルを取り壊すことができます。これは、STOPCCNコントロールメッセージを送信することにより、[RFC2661]のセクション5.7で指定されているとおりに行われます。この場合、ソフトウェアに固有のアクションはありません。
In the Softwire "Hub and Spoke" framework, L2TPv2 is layered on top of UDP, as part of an IP-in-IP tunnel; Section 8.1 of [RFC2661] describes L2TP over UDP/IP. Therefore, the UDP guidelines specified in [RFC5405] apply, as they pertain to the UDP tunneling scenarios carrying IP-based traffic. Section 3.1.3 of [RFC5405] specifies that for this case, specific congestion control mechanisms for the tunnel are not necessary. Additionally, Section 3.2 of [RFC5405] provides message size guidelines for the encapsulating (outer) datagrams, including the recommendation to implement Path MTU Discovery (PMTUD).
ソフトワイヤーの「ハブアンドスポーク」フレームワークでは、IP-in-IPトンネルの一部として、L2TPV2がUDPの上に階層化されています。[RFC2661]のセクション8.1は、UDP/IPよりもL2TPについて説明します。したがって、[RFC5405]で指定されたUDPガイドラインは、IPベースのトラフィックを運ぶUDPトンネルシナリオに関係しているため、適用されます。[RFC5405]のセクション3.1.3は、この場合には、トンネルの特定の輻輳制御メカニズムが必要ないことを指定しています。さらに、[RFC5405]のセクション3.2は、パスMTUディスカバリー（PMTUD）を実装するための推奨事項を含む、カプセル化（外側）データグラムのメッセージサイズガイドラインを提供します。
This section describes the PPP negotiations between the SI and SC in the Softwire context.
このセクションでは、SoftwireコンテキストでのSIとSCの間のPPP交渉について説明します。
The MTU of the PPP link presented to the SPH SHOULD be the link MTU minus the size of the IP, UDP, L2TPv2, and PPP headers together. On an IPv4 link with an MTU equal to 1500 bytes, this could typically mean a PPP MTU of 1460 bytes. When the link is managed by IPsec, this MTU SHOULD be lowered to take into account the ESP encapsulation (see [SW-SEC]). The value for the MTU may also vary according to the size of the L2TP header, as defined by the leading bits of the L2TP message header (see [RFC2661]). Additionally, see [RFC4623] for a detailed discussion of fragmentation issues.
SPHに提示されたPPPリンクのMTUは、IP、UDP、L2TPV2、およびPPPヘッダーのサイズを引いたリンクMTUから一緒にサイズを差し引いている必要があります。1500バイトに等しいMTUを使用したIPv4リンクでは、これは通常、1460バイトのPPP MTUを意味する可能性があります。リンクがIPSECによって管理される場合、このMTUを下げてESPカプセル化を考慮に入れる必要があります（[SW-SEC]を参照）。MTUの値は、L2TPメッセージヘッダーの先行ビットで定義されているように、L2TPヘッダーのサイズによって異なる場合があります（[RFC2661]を参照）。さらに、断片化の問題の詳細については、[RFC4623]を参照してください。
Once the L2TPv2 session is established, the SI and SC initiate the PPP connection by negotiating LCP as described in [RFC1661]. The Address-and-Control-Field-Compression configuration option (ACFC) [RFC1661] MAY be rejected.
L2TPV2セッションが確立されると、[RFC1661]に記載されているようにLCPを交渉することにより、SIとSCがPPP接続を開始します。アドレスとコントロール - フィールド圧縮構成オプション（ACFC）[RFC1661]が拒否される場合があります。
After completing LCP negotiation, the SI and SC MAY optionally perform authentication. If authentication is chosen, Challenge Handshake Authentication Protocol (CHAP) [RFC1994] authentication MUST be supported by both the Softwire Initiator and Softwire Concentrator. Other authentication methods such as Microsoft CHAP version 1 (MS-CHAPv1) [RFC2433] and Extensible Authentication Protocol (EAP) [RFC3748] MAY be supported.
LCP交渉を完了した後、SIとSCはオプションで認証を実行する場合があります。認証が選択されている場合、チャレンジハンドシェイク認証プロトコル（CHAP）[RFC1994]認証は、Softwire InitiatorとSoftwire Concentorの両方でサポートする必要があります。Microsoft Chapバージョン1（MS-Chapv1）[RFC2433）や拡張可能な認証プロトコル（EAP）[RFC3748]などの他の認証方法がサポートされる場合があります。
A detailed discussion of Softwire security is contained in [SW-SEC].
Softwireセキュリティの詳細な議論は[SW-SEC]に含まれています。
The only Network Control Protocol (NCP) negotiated in the Softwire context is IPV6CP (see Section 5.2.4.1) for IPv6 as SPH, and IPCP (see Section 5.2.4.2) for IPv4 as SPH.
Softwireコンテキストで交渉された唯一のネットワーク制御プロトコル（NCP）は、SPHとしてのIPv6のIPv6CP（セクション5.2.4.1を参照）、およびIPV4のIPCP（セクション5.2.4.2を参照）です。
In the IPv6-over-IPv4 scenarios (see Section 3.1), after the optional authentication phase, the Softwire Initiator MUST negotiate IPV6CP as defined in [RFC5072]. IPV6CP provides a way to negotiate a unique 64-bit Interface-Identifier to be used for the address autoconfiguration at the local end of the link.
IPv6-over-IPV4シナリオ（セクション3.1を参照）では、オプションの認証フェーズの後、ソフトワイヤーイニシエーターは[RFC5072]で定義されているようにIPv6CPをネゴシエートする必要があります。IPv6CPは、リンクのローカルエンドでのアドレスの自動構成に使用される一意の64ビットインターフェイス識別子をネゴシエートする方法を提供します。
In the IPv4-over-IPv6 scenarios (see Section 3.2), a Softwire Initiator MUST negotiate IPCP [RFC1332]. The SI uses IPCP to obtain an IPv4 address from the SC. IPCP MAY also be used to obtain DNS information as described in [RFC1877].
IPv4-over-IPV6シナリオ（セクション3.2を参照）では、SoftwireイニシエーターはIPCP [RFC1332]をネゴシエートする必要があります。SIはIPCPを使用して、SCからIPv4アドレスを取得します。[RFC1877]で説明されているように、IPCPを使用してDNS情報を取得することもできます。
In several scenarios defined in Section 3.1, global IPv6 addresses are expected to be allocated to Softwire endpoints (in addition to the Link-Local addresses autoconfigured using the IPV6CP negotiated interface identifier). The Softwire Initiator assigns global IPv6 addresses using the IPV6CP negotiated interface identifier and using Stateless Address Autoconfiguration [RFC4862], and/or using Privacy Extensions for Stateless Address Autoconfiguration [RFC4941], (as described in Section 5 of [RFC5072]), and/or using DHCPv6 [RFC3315].
セクション3.1で定義されているいくつかのシナリオでは、グローバルIPv6アドレスがソフトワイヤーのエンドポイントに割り当てられると予想されます（IPv6CPネゴシエートされたインターフェイス識別子を使用してAutoconfiguredのリンクローカルアドレスに加えて）。Softwire Initiatorは、IPv6CPネゴシエートインターフェイス識別子を使用してGlobal IPv6アドレスを割り当て、Stateless Autoconfiguration [RFC4862]を使用し、Stateless Address Autoconfiguration [RFC4941]のプライバシー拡張機能を使用します（RFC5072]のセクション5に記載されています）、および////////////////またはDHCPV6 [RFC3315]を使用します。
The Softwire Initiator of an IPv6 Softwire MUST send a Router Solicitation message to the Softwire Concentrator after IPV6CP is completed. The Softwire Concentrator MUST answer with a Router Advertisement. This message MUST contain the global IPv6 prefix of the PPP link if Neighbor Discovery is used to configure addresses of Softwire endpoints.
IPv6 SoftwireのSoftwireイニシエーターは、IPv6CPが完了した後、Router SolicitationメッセージをSoftwire Concencitatorに送信する必要があります。Softwire Concentorは、ルーター広告で答える必要があります。このメッセージは、Softwireエンドポイントのアドレスを構成するために近隣発見を使用している場合、PPPリンクのグローバルIPv6プレフィックスを含める必要があります。
If DHCPv6 is available for address delegation, the M bits of the Router Advertisement SHOULD be set. The Softwire Initiator MUST then send a DHCPv6 Request to configure the address of the Softwire endpoint.
DHCPV6がアドレス代表団に利用可能である場合、ルーター広告のMビットを設定する必要があります。Softwireイニシエーターは、DHCPV6リクエストを送信して、Softwireエンドポイントのアドレスを構成する必要があります。
Duplicate Address Detection ([RFC4861]) MUST be performed on the Softwire in both cases.
どちらの場合も、Softwireで重複するアドレス検出（[RFC4861]）を実行する必要があります。
The Softwire Initiator MAY use DHCP to get additional information such as delegated prefix and DNS servers.
Softwireイニシエーターは、DHCPを使用して、委任されたプレフィックスやDNSサーバーなどの追加情報を取得できます。
In the scenarios in Section 3.1, if the SI supports DHCPv6, it SHOULD send a Solicit message to verify if more information is available.
セクション3.1のシナリオでは、SIがDHCPV6をサポートしている場合、詳細情報が利用可能かどうかを確認するために勧誘メッセージを送信する必要があります。
If an SI establishing an IPv6 Softwire acts as a router (i.e., in the scenarios in Sections 3.1.2 and 3.1.4) it MUST include the Identity Association for Prefix Delegation (IA_PD) option [RFC3633] in the DHCPv6 Solicit message [RFC3315] in order to request an IPv6 prefix.
IPv6ソフトワイヤーを確立するSIがルーターとして機能する場合（つまり、セクション3.1.2および3.1.4のシナリオで）、DHCPV6 SOLICITメッセージ[RFC33151565のプレフィックス代表団（IA_PD）オプション[RFC3633]のID協会協会（IA_PD）オプション[RFC3633]を含める必要があります。] IPv6プレフィックスをリクエストするため。
When delegating an IPv6 prefix to the SI by returning a DHCPv6 Advertise message with the IA_PD and IP_PD Prefix options [RFC3633], the SC SHOULD inject a route for this prefix in the IPv6 routing table in order to forward the traffic to the relevant Softwire.
IA_PDおよびIP_PDプレフィックスオプション[RFC3633]を使用してDHCPV6広告メッセージを返すことにより、IPv6プレフィックスをSIに委任する場合、SCは、IPv6ルーティングテーブルのこのプレフィックスのルートを、関連するソフトウェアにトラフィックを転送するために注入する必要があります。
Configuration of DNS MUST be done as specified in [RFC3646] and transmitted according to [RFC3315] and [RFC3736]. In general, all DHCPv6 options MUST be transmitted according to [RFC3315] and [RFC3736].
DNSの構成は、[RFC3646]で指定されたとおりに実行され、[RFC3315]および[RFC3736]に従って送信する必要があります。一般に、すべてのDHCPV6オプションは[RFC3315]および[RFC3736]に従って送信する必要があります。
An SI establishing an IPv4 Softwire MAY send a DHCP request containing the Subnet Allocation option [SUBNET-ALL]. This practice is not common, but it may be used to connect IPv4 subnets using Softwires, as defined in Sections 3.2.2 and 3.2.4.
IPv4ソフトワイヤを確立するSIは、サブネット割り当てオプション[Subnet-All]を含むDHCPリクエストを送信する場合があります。このプラクティスは一般的ではありませんが、セクション3.2.2および3.2.4で定義されているように、ソフトウェアを使用してIPv4サブネットを接続するために使用できます。
One Subnet-Request suboption MUST be configured with the 'h' bit set to '1', as the SI is expected to perform the DHCP server function. The 'i' bit of the Subnet-Request suboption SHOULD be set to '0' the first time a prefix is requested and to '1' on subsequent requests, if a prefix has been allocated. The Prefix length suboption SHOULD be 0 by default. If the SI is configured to support only specific prefix lengths, it SHOULD specify the longest (smallest) prefix length it supports.
SIはDHCPサーバー関数を実行すると予想されるため、1つのサブネットリクエストサブオプションは「H」ビット設定で「1」に設定されて構成する必要があります。Subnet-Request Suboptionの「I」ビットは、プレフィックスが割り当てられている場合は、最初にプレフィックスが要求されるときに「0」に設定し、後続のリクエストで「1」に設定する必要があります。接頭辞の長さのサブオプションは、デフォルトで0である必要があります。SIが特定のプレフィックスの長さのみをサポートするように構成されている場合、サポートする最長（最小）プレフィックス長を指定する必要があります。
If the SI was previously assigned a prefix from that same SC, it SHOULD include the Subnet-Information suboption with the prefix it was previously assigned. The 'c' and 's' bits of the suboption SHOULD be set to '0'.
SIが以前に同じSCの接頭辞を割り当てられた場合、以前に割り当てられたプレフィックスにサブネット情報サブオプションを含める必要があります。サブオプションの「C」および「S」ビットは、「0」に設定する必要があります。
In the scenarios in Section 3.2, when delegating an IPv4 prefix to the SI, the SC SHOULD inject a route for this prefix in the IPv4 routing table in order to forward the traffic to the relevant Softwire.
セクション3.2のシナリオでは、IPv4プレフィックスをSIに委任する場合、SCは、トラフィックを関連するソフトワイヤに転送するために、IPv4ルーティングテーブルにこのプレフィックスのルートを注入する必要があります。
This section describes how a Softwire Concentrator may manage delegated addresses for Softwire endpoints and for subnets behind the Softwire Initiator. One common practice is to aggregate endpoints' addresses and delegated prefixes into one prefix routed to the SC. The main benefit is to ease the routing scheme by isolating on the SC succeeding route injections (when delegating new prefixes for SI).
このセクションでは、Softwire ConcentoratorがソフトワイヤーのエンドポイントおよびSoftwireイニシエーターの背後のサブネットの委任されたアドレスをどのように管理するかについて説明します。1つの一般的な慣行は、エンドポイントのアドレスを集約し、SCにルーティングされた1つのプレフィックスに委任されたプレフィックスを委任することです。主な利点は、SC後続のルートインジェクションで分離することにより、ルーティングスキームを緩和することです（SIの新しいプレフィックスを委任する場合）。
A Softwire Concentrator should provide globally routable addresses to Softwire endpoints. Other types of addresses such as Unique Local Addresses (ULAs) [RFC4193] may be used to address Softwire endpoints in a private network with no global connectivity. A single /64 should be assigned to the Softwire to address both Softwire endpoints.
ソフトワイヤーコンセントレーターは、ソフトワイヤーのエンドポイントにグローバルにルーティング可能なアドレスを提供する必要があります。一意のローカルアドレス（ULAS）[RFC4193]などの他のタイプのアドレスを使用して、グローバル接続のないプライベートネットワークのソフトワイヤーエンドポイントに対処できます。両方のソフトワイヤーエンドポイントに対処するために、シングル /64をソフトワイヤーに割り当てる必要があります。
Global addresses or ULAs must be assigned to endpoints when the scenario "Host CPE as Softwire Initiator" (described in Section 3.1.1) is considered to be deployed. For other scenarios, link-local addresses may also be used.
グローバルアドレスまたはULAは、シナリオ「ホストCPEとしてSoftwire InitiatorとしてCPE」（セクション3.1.1で説明）が展開されると見なされると、エンドポイントに割り当てる必要があります。他のシナリオでは、Link-Localアドレスも使用できます。
A Softwire Concentrator may provide either globally routable or private IPv4 addresses. When using IPv4 private addresses [RFC1918] on the endpoints, it is not recommended to delegate an IPv4 private prefix to the SI, as it can lead to a nested-NAT situation.
Softwire Concentatorは、グローバルにルーティング可能またはプライベートIPv4アドレスを提供する場合があります。エンドポイントでIPv4プライベートアドレス[RFC1918]を使用する場合、IPv4プライベートプレフィックスをSIに委任することはお勧めしません。
The endpoints of the PPP link use host addresses (i.e., /32), negotiated using IPCP.
PPPリンクのエンドポイントは、IPCPを使用してネゴシエートされたホストアドレス（つまり、 /32）を使用します。
Delegated IPv6 prefixes should be of global scope if the IPv6 addresses assigned to endpoints are global. Using ULAs is not recommended when the subnet is connected to the global IPv6 Internet. When using IPv6 ULAs on the endpoints, the delegated IPv6 prefix may be either of global or ULA scope.
委任されたIPv6プレフィックスは、エンドポイントに割り当てられたIPv6アドレスがグローバルである場合、グローバルスコープである必要があります。サブネットがグローバルIPv6インターネットに接続されている場合、ULASを使用することはお勧めしません。エンドポイントでIPv6 ULASを使用する場合、委任されたIPv6プレフィックスはグローバルまたはULAスコープのいずれかである場合があります。
Delegated IPv6 prefixes are between /48 and /64 in length. When an SI receives a prefix shorter than 64, it can assign different /64 prefixes to each of its interfaces. An SI receiving a single /64 is expected to perform bridging if more than one interface is available (e.g., wired and wireless).
委任されたIPv6プレフィックスの長さは /48〜 /64の間です。SIが64より短い接頭辞を受信すると、各インターフェイスに異なる /64プレフィックスを割り当てることができます。単一 /64を受信するSIは、複数のインターフェイスが利用可能である場合（有線およびワイヤレスなど）、ブリッジングを実行すると予想されます。
Delegated IPv4 prefixes should be routable within the address space used by assigned IPv4 addresses. Delegate non-routable IPv4 prefixes (i.e., private IPv4 prefix over public IPv4 addresses or another class of private IPv4 addresses) is not recommended as a practice for provisioning and address translation should be considered in these cases. The prefix length is between /8 and /30.
委任されたIPv4プレフィックスは、割り当てられたIPv4アドレスで使用されるアドレススペース内でルーティング可能である必要があります。代表者ではないIPv4プレフィックス（つまり、パブリックIPv4アドレスまたはプライベートIPv4アドレスの別のクラスのプライベートIPv4プレフィックス）は、プロビジョニングとアドレス翻訳の練習をこれらの場合に考慮する必要があるため、推奨されません。接頭辞の長さは /8と /30の間です。
This section summarizes the different scenarios for address provisioning with the considerations given in the previous sections.
このセクションでは、前のセクションに記載されている考慮事項とともに、アドレスプロビジョニングのさまざまなシナリオをまとめたものです。
This table describes the possible combination of IPv6 address scope for endpoints and delegated prefixes.
この表は、エンドポイントと委任されたプレフィックスのIPv6アドレス範囲の可能な組み合わせについて説明しています。
+------------------+-----------------------+------------------------+
| Endpoint IPv6 | Delegated Global IPv6 | Delegated ULA IPv6 |
| Address | Prefix | Prefix |
+------------------+-----------------------+------------------------+
| Link Local | Possible | Possible |
| | | |
| ULA | Possible | Possible |
| | | |
| Global | Possible | Possible, but Not |
| | | Recommended |
+------------------+-----------------------+------------------------+
Table 1: Scenarios for IPv6
表1：IPv6のシナリオ
This table describes the possible combination of IPv4 address scope for endpoints and delegated prefixes.
この表は、エンドポイントと委任されたプレフィックスのIPv4アドレス範囲の可能な組み合わせについて説明しています。
+-------------+-----------------+-----------------------------------+
| Endpoint | Delegated | Delegated Private IPv4 Prefix |
| IPv4 | Public IPv4 | |
| Address | Prefix | |
+-------------+-----------------+-----------------------------------+
| Private | Possible | Possible, but Not Recommended |
| IPv4 | | when using NAT (cf. |
| | | Section 6.1.2) |
| | | |
| Public IPv4 | Possible | Possible, but NAT usage is |
| | | recommended (cf. Section 6.2.2) |
+-------------+-----------------+-----------------------------------+
Table 2: Scenarios for IPv4
表2：IPv4のシナリオ
A Softwire can provide stable addresses even if the underlying addressing scheme changes, by opposition to automatic tunneling. A Softwire Concentrator should always provide the same address and prefix to a reconnecting user. However, if the goal of the Softwire service is to provide a temporary address for a roaming user, it may be provisioned to provide only a temporary address.
ソフトワイヤーは、自動トンネリングに反対することにより、基礎となるアドレス指定スキームが変更されたとしても、安定したアドレスを提供できます。Softwire concentoratorは、常に同じアドレスと再接続ユーザーに同じアドレスとプレフィックスを提供する必要があります。ただし、Softwireサービスの目標がローミングユーザーに一時的な住所を提供することである場合、一時的な住所のみを提供するようにプロビジョニングされる場合があります。
The address and prefix are expected to change when reconnecting to a different Softwire Concentrator. However, an organization providing a Softwire service may provide the same address and prefix across different Softwire Concentrators at the cost of a more fragmented routing table. The routing fragmentation issue may be limited if the prefixes are aggregated in a location topologically close to the SC. This would be the case, for example, if several SCs are put in parallel for load-balancing purpose.
アドレスとプレフィックスは、別のソフトワイヤーコンセントレーターに再接続するときに変更されると予想されます。ただし、Softwireサービスを提供する組織は、より断片化されたルーティングテーブルを犠牲にして、異なるソフトワイヤーコンセントレーターに同じアドレスとプレフィックスを提供する場合があります。プレフィックスがSCに近い場所に集約されている場合、ルーティングの断片化の問題は制限される場合があります。これは、たとえば、いくつかのSCが負荷分散の目的で並行して配置されている場合に当てはまります。
The Softwire Concentrator is expected to act as a client to a AAA server, for example, a RADIUS server. During the PPP authentication phase, the RADIUS server may return additional information in the form of attributes in the Access-Accept message.
Softwire Concentorは、AAAサーバーのクライアントとして機能することが期待されています。たとえば、RADIUSサーバーなどです。PPP認証フェーズ中、RADIUSサーバーは、アクセスacceptメッセージの属性の形式で追加情報を返すことができます。
The Softwire Concentrator may include the Tunnel-Type and Tunnel-Medium-Type attributes [RFC2868] in the Access-Request messages to provide a hint of the type of Softwire being configured.
ソフトワイヤーコンセントレーターには、アクセスレクエストメッセージにトンネルタイプとトンネルメディウムタイプの属性[RFC2868]を含めることができ、構成されているソフトワイヤのタイプのヒントを提供できます。
If the RADIUS server includes a Framed-Interface-Id attribute [RFC3162], the Softwire Concentrator must send it to the Softwire Initiator in the Interface-Identifier field of its IPV6CP Configuration Request message.
RADIUSサーバーにフレーム付きInterface-ID属性[RFC3162]が含まれている場合、Softwire ConcentorはIPv6CP構成要求メッセージのインターフェイス識別子フィールドのSoftwireイニシエーターに送信する必要があります。
If the Framed-IPv6-Prefix attribute [RFC3162] is included, that prefix must be used in the router advertisements sent to the SI. If Framed-IPv6-Prefix is not present but Framed-IPv6-Pool is, the SC must choose a prefix from that pool to send RAs.
フレーム-IPV6-PREFIX属性[RFC3162]が含まれている場合、そのプレフィックスはSIに送信されるルーター広告で使用する必要があります。フレーム-IPV6-PREFIXが存在しないが、フレーム-IPV6プールが存在しない場合、SCはRASを送信するためにそのプールからプレフィックスを選択する必要があります。
If the Framed-IP-Address attribute [RFC2865] is present, the Softwire Concentrator must provide that address to the Softwire Initiator during IPCP address negotiation. That is, when the Softwire Initiator requests an IP address from the Softwire Concentrator, the address provided should be the Framed-IP-Address.
フレーム-IP-Address属性[RFC2865]が存在する場合、Softwire ConcentatorはIPCPアドレス交渉中にそのアドレスをSoftwireイニシエーターに提供する必要があります。つまり、Softwire InitiatorがSoftwire ConcentoratorからIPアドレスを要求する場合、提供されるアドレスはフレームIPアドレスである必要があります。
If the attribute Delegated-IPv6-Prefix [RFC4818] is present in the RADIUS Access-Accept message, it must be used by the Softwire Concentrator for the delegation of the IPv6 prefix. Since the prefix delegation is performed by DHCPv6 and the attribute is linked to a username, the SC must associate the DHCP Unique Identifier (DUID) of a DHCPv6 request to the tunnel it came from and its user.
属性委任-IPV6-PREFIX [RFC4818]がRADIUS Access-Acceptメッセージに存在する場合、IPv6プレフィックスの委任のためにSoftwire Concentoratorが使用する必要があります。プレフィックス委任はDHCPV6によって実行され、属性はユーザー名にリンクされているため、SCはDHCPV6要求のDHCP一意の識別子（DUID）をそれが来たトンネルとそのユーザーに関連付ける必要があります。
Interaction between RADIUS, PPP, and DHCPv6 server may follow the mechanism proposed in [RELAY-RAD]. In this case, during the Softwire authentication phase, PPP collects the RADIUS attributes for the user such as Delegated-IPv6-Prefix. A specific DHCPv6 relay is assigned to the Softwire. The DHCPv6 relay fills in these attributes in the Relay agent RADIUS Attribute Option (RRAO) DHCPv6 option, before forwarding the DHCPv6 requests to the DHCPv6 server.
RADIUS、PPP、およびDHCPV6サーバー間の相互作用は、[リレーラッド]で提案されているメカニズムに従うことができます。この場合、Softwire認証フェーズ中、PPPは委任-IPv6-PrefixなどのユーザーのRADIUS属性を収集します。特定のDHCPV6リレーがソフトワイヤに割り当てられます。DHCPV6リレーは、DHCPV6リクエストをDHCPV6サーバーに転送する前に、リレーエージェントRADIUS属性オプション（RRAO）DHCPV6オプションのこれらの属性に記入します。
RADIUS does not define an attribute for the delegated IPv4 Prefix. Attributes indicating an IPv4 prefix and its length (for instance the combination of the Framed-IP-Address and Framed-IP-Netmask attributes [RFC2865]) may be used by the Softwire Concentrator to delegate an IPv4 prefix to the Softwire Initiator. The Softwire Concentrator must add a corresponding route with the Softwire Initiator as next-hop.
RADIUSは、委任されたIPv4プレフィックスの属性を定義しません。IPv4プレフィックスとその長さを示す属性（たとえば、フレームIPアドレスとフレーム-IP-NetMask属性の組み合わせ[RFC2865]）は、ソフトワイヤーコンセントレーターによって使用される場合があります。Softwire Concentatorは、Softwireイニシエーターを次のホップとして、対応するルートを追加する必要があります。
As this practice had been used, the inclusion of the Framed-IP-Netmask attribute along with the Framed-IP-Address attribute tells the Softwire Concentrator to delegate an IPv4 prefix to the Softwire Initiator (e.g., in the IPv4-over-IPv6 scenarios where the Softwire Initiator is a router, see Sections 3.2.2 and 3.2.4), as the SC should forward packets destined to any IPv4 address in the prefix to the SI.
このプラクティスが使用されていたため、フレーム付き-IP-NetMask属性とフレーム付きIP-Address属性を含めることは、Softwire濃縮器にSoftwire InitiatorにIPv4プレフィックスを委任するように指示します（例えば、IPv4-Over-IPV6シナリオでソフトワイヤーイニシエーターがルーターである場合、SCはSIのプレフィックスのIPv4アドレスに向けられたパケットを転送する必要があるため、セクション3.2.2および3.2.4を参照してください。
Existing protocol mechanics for conveying adjunct or accessory information for logging purposes, including L2TPv2 and RADIUS methods, can include informational text that the behavior is according to the Softwire "Hub and Spoke" framework (following the implementation details specified in this document).
L2TPV2やRADIUSメソッドを含むロギング目的で付属またはアクセサリ情報を伝えるための既存のプロトコルメカニクスには、動作がソフトワイヤーの「ハブとスポーク」フレームワークに従っての情報テキストを含めることができます（このドキュメントで指定された実装の詳細に従ってください）。
RADIUS Accounting for L2TP and PPP are documented (see Section 4.3).
L2TPおよびPPPの半径会計が記録されています（セクション4.3を参照）。
When deploying Softwire solutions, operators may experience difficulties to differentiate the address family of the traffic reported in accounting information from RADIUS. This problem and some potential solutions are described in [SW-ACCT].
Softwireソリューションを展開するとき、オペレーターは、RADIUSからの会計情報で報告されているトラフィックの住所ファミリを区別するのが難しい場合があります。この問題といくつかの潜在的な解決策は、[SW-ACCT]で説明されています。
MIB support for L2TPv2 and PPP are documented (see Section 4.4). Also, see [RFC4293].
L2TPV2およびPPPのMIBサポートが記録されています（セクション4.4を参照）。また、[RFC4293]を参照してください。
One design goal of the "Hub and Spoke" problem is to very strongly consider the reuse of already deployed protocols (see [RFC4925]). Another design goal is a solution with very high scaling properties. L2TPv2 [RFC2661] is the phase 1 protocol used in the Softwire "Hub and Spoke" solution space, and the L2TPv2 security considerations apply to this document (see Section 9 of [RFC2661]).
「ハブとスポーク」の問題の設計目標の1つは、すでに展開されているプロトコルの再利用を非常に強く検討することです（[RFC4925]を参照）。別の設計目標は、非常に高いスケーリングプロパティを備えたソリューションです。L2TPV2 [RFC2661]は、ソフトワイヤーの「ハブとスポーク」ソリューションスペースで使用されるフェーズ1プロトコルであり、L2TPV2セキュリティに関する考慮事項がこのドキュメントに適用されます（[RFC2661]のセクション9を参照）。
The L2TPv2 Softwire solution adds the following considerations:
L2TPV2ソフトワイヤーソリューションは、次の考慮事項を追加します。
o L2TP Tunnel Authentication (see Sections 5.1.1 and 9.1 of [RFC2661]) provides authentication at tunnel setup. It may be used to limit DoS attacks by authenticating the tunnel before L2TP and PPP resources are allocated.
o L2TPトンネル認証（[RFC2661]のセクション5.1.1および9.1を参照）は、トンネルセットアップで認証を提供します。L2TPおよびPPPリソースが割り当てられる前にトンネルを認証することにより、DOS攻撃を制限するために使用できます。
o In a Softwire environment, L2TPv2 AVPs do not transport sensitive data, and thus the L2TPv2 AVP hiding mechanism is not used (see Section 5.1.1).
o ソフトワイヤー環境では、L2TPV2 AVPは機密データを輸送しないため、L2TPV2 AVP隠蔽メカニズムは使用されません（セクション5.1.1を参照）。
o PPP CHAP [RFC1994] provides basic user authentication. Other authentication protocols may additionally be supported (see Section 5.2.3).
o PPP Chap [RFC1994]は、基本的なユーザー認証を提供します。他の認証プロトコルがさらにサポートされる場合があります（セクション5.2.3を参照）。
L2TPv2 can also be secured with IPsec to provide privacy, integrity, and replay protection. Currently, there are two different solutions for security L2TPv2 with IPsec:
L2TPV2は、プライバシー、整合性、およびリプレイ保護を提供するために、IPSECで保護することもできます。現在、IPSECを使用したセキュリティL2TPV2には2つの異なるソリューションがあります。
o Securing L2TPv2 using IPsec "version 2" (IKEv1) is specified in [RFC3193], [RFC3947], and [RFC3948]. When L2TPv2 is used in the Softwire context, the voluntary tunneling model applies. [RFC3193] describes the interaction between IPsec and L2TPv2, and is deployed. [RFC3193] MUST be supported, given that deployed technology must be very strongly considered [RFC4925] for this 'time-to-market' solution.
o IPSEC "バージョン2"（IKEV1）を使用してL2TPV2を固定することは、[RFC3193]、[RFC3947]、および[RFC3948]で指定されています。L2TPV2がSoftwireコンテキストで使用される場合、自発的トンネルモデルが適用されます。[RFC3193]は、IPSECとL2TPV2の間の相互作用を説明し、展開します。[RFC3193]は、この「市場までの」ソリューションのために展開されたテクノロジーを非常に強く考慮する必要があるため、サポートする必要があります。
o [SW-SEC] also specifies a new (incompatible) solution for securing L2TPv2 with IPsec "version 3" (IKEv2). Section 3.5 of [SW-SEC] describes the advantages of using IKEv2, and this solution needs to be considered for future phases.
o [SW-SEC]は、L2TPV2をIPSEC "バージョン3"（IKEV2）で固定するための新しい（互換性のない）ソリューションも指定しています。[SW-SEC]のセクション3.5は、IKEV2を使用することの利点について説明しており、このソリューションは将来の段階で考慮する必要があります。
Additional discussion of Softwire security is contained in [SW-SEC].
ソフトワイヤーセキュリティの追加の議論は[SW-SEC]に含まれています。
The authors would like to acknowledge the following contributors who provided helpful input on this document: Florent Parent, Jordi Palet Martinez, Ole Troan, Shin Miyakawa, Carl Williams, Mark Townsley, Francis Dupont, Ralph Droms, Hemant Singh, and Alain Durand.
著者は、このドキュメントに関する有益な情報を提供した次の貢献者に、Florent Parent、Jordi Palet Martinez、Ole Troan、Shin Miyakawa、Carl Williams、Mark Townsley、Francis Dupont、Ralph Droms、Hemant Singh、Alain Durand。
The authors would also like to acknowledge the participants in the Softwires interim meetings held in Hong Kong, China, and Barcelona, Spain. The minutes for the interim meeting at the China University - Hong Kong (February 23-24, 2006) are at <http://www.ietf.org/proceedings/06mar/isoftwire.html>. The minutes for the interim meeting at Polytechnic University of Catalonia - Barcelona (September 14-15, 2006) are reachable at <http://www.ietf.org/proceedings/06nov/isoftwire.html>. The Softwires auxiliary page at <http://bgp.nu/~dward/softwires/> contains additional meeting information.
著者はまた、中国の香港とスペインのバルセロナで開催されたソフトウェアの暫定会議の参加者にも承認したいと考えています。中国大学での暫定会議の議事録 - 香港（2006年2月23〜24日）は<http://www.ietf.org/proceedings/06mar/isoftwire.html>にあります。カタロニア大学での暫定会議の議事録 - バルセロナ（2006年9月14〜15日）は、<http://www.ietf.org/proceedings/06nov/isoftwire.html>に到達できます。<http://bgp.nu/~dward/softwires/ <<http://bgp.nu/softwires/のソフトワイヤの補助ページには、追加の会議情報が含まれています。
During and after the IETF Last Call, useful comments and discussion were provided by Jari Arkko, David Black, Lars Eggert, Pasi Eronen, and Dan Romascanu.
IETFの最後の呼び出し中と後の後に、Jari Arkko、David Black、Lars Eggert、Pasi Eronen、およびDan Romascanuによって有用なコメントと議論が提供されました。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332] McGregor、G。、「PPPインターネットプロトコル制御プロトコル（IPCP）」、RFC 1332、1992年5月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W。、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994]シンプソン、W。、「PPPチャレンジハンドシェイク認証プロトコル（CHAP）」、RFC 1994、1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661] Townsley、W.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。、およびB. Palter、 "Layer Two Tunneling Protocol" L2TP ""、RFC 2661、1999年8月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba、B.、Zorn、G。、およびD. Mitton、「Radius and IPv6」、RFC 3162、2001年8月。
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, "Securing L2TP using IPsec", RFC 3193, November 2001.
[RFC3193] Patel、B.、Aboba、B.、Dixon、W.、Zorn、G。、およびS. Booth、「IPSECを使用したL2TPの保護」、RFC 3193、2001年11月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] DROMS、R.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC3371] Caves, E., Calhoun, P., and R. Wheeler, "Layer Two Tunneling Protocol "L2TP" Management Information Base", RFC 3371, August 2002.
[RFC3371] Caves、E.、Calhoun、P。、およびR. Wheeler、「レイヤー2つのトンネルプロトコル「L2TP」管理情報ベース」、RFC 3371、2002年8月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633] Troan、O。およびR. Droms、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736] DROMS、R。、「IPv6のステートレス動的ホスト構成プロトコル（DHCP）サービス」、RFC 3736、2004年4月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947] Kivinen、T.、Swander、B.、Huttunen、A。、およびV. Volpe、「IKEにおけるNat-Traversalの交渉」、RFC 3947、2005年1月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948] Huttunen、A.、Swander、B.、Volpe、V.、Diburro、L。、およびM. Stenberg、「IPSEC ESPパケットのUDPカプセル化」、RFC 3948、2005年1月。
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007.
[RFC4818] Salowey、J。およびR. Droms、「Radius Delegated-IPv6-Prefix属性」、RFC 4818、2007年4月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007.
[RFC5072] S.Varada、Haskins、D。、およびE. Allen、「PPP上のIPバージョン6」、RFC 5072、2007年9月。
[RELAY-RAD] Lau, W., "DHCPv6 Relay agent RADIUS Attribute Option", Work in Progress, February 2006.
[Relay-Rad] Lau、W。、「DHCPV6リレーエージェントRADIUS属性オプション」、2006年2月の作業進行中。
[RFC1471] Kastenholz, F., "The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol", RFC 1471, June 1993.
[RFC1471] Kastenholz、F。、「ポイントツーポイントプロトコルのリンク制御プロトコルの管理されたオブジェクトの定義」、RFC 1471、1993年6月。
[RFC1473] Kastenholz, F., "The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol", RFC 1473, June 1993.
[RFC1473] Kastenholz、F。、「ポイントツーポイントプロトコルのIPネットワーク制御プロトコルの管理オブジェクトの定義」、RFC 1473、1993年6月。
[RFC1877] Cobb, S. and F. Baker, "PPP Internet Protocol Control Protocol Extensions for Name Server Addresses", RFC 1877, December 1995.
[RFC1877] Cobb、S。およびF. Baker、「Name ServerアドレスのPPPインターネットプロトコル制御プロトコル拡張」、RFC 1877、1995年12月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張機能」、RFC 2132、1997年3月。
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, October 1998.
[RFC2433] Zorn、G。およびS. Cobb、「Microsoft PPP Chap Extensions」、RFC 2433、1998年10月。
[RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[RFC2867] Zorn、G.、Aboba、B。、およびD. Mitton、「トンネルプロトコルサポートのための半径会計の修正」、RFC 2867、2000年6月。
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2868] Zorn、G.、Leifer、D.、Rubens、A.、Shriver、J.、Holdrege、M。、およびI. Goyret、「トンネルプロトコルサポートのRadius属性」、RFC 2868、2000年6月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P。およびK. Egevang、「従来のIPネットワークアドレス翻訳者（従来のNAT）」、RFC 3022、2001年1月。
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003.
[RFC3575] Aboba、B。、「RADIUS（ユーザーサービスのリモート認証ダイヤル）のIANAの考慮事項」、RFC 3575、2003年7月。
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3646] DROMS、R。、「IPv6（DHCPV6）の動的ホスト構成プロトコルのDNS構成オプション」、RFC 3646、2003年12月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、「拡張可能な認証プロトコル（EAP）」、RFC 3748、2004年6月。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931] Lau、J.、Townsley、M。、およびI. Goyret、「レイヤー2つのトンネルプロトコル - バージョン3（L2TPV3）」、RFC 3931、2005年3月。
[RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, June 2005.
[RFC4087] Thaler、D。、「IP Tunnel MIB」、RFC 4087、2005年6月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] Hinden、R。およびB. Haberman、「ユニークなローカルIPv6ユニキャストアドレス」、RFC 4193、2005年10月。
[RFC4293] Routhier, S., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006.
[RFC4293] Routhier、S。、「インターネットプロトコルの管理情報ベース（IP）」、RFC 4293、2006年4月。
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly", RFC 4623, August 2006.
[RFC4623] Malis、A。およびM. Townsley、「Pseudowire Emulation Edge-to-Edge（PWE3）の断片化と再組み立て」、RFC 4623、2006年8月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787] Audet、F。およびC. Jennings、「Unicast UDPのネットワークアドレス変換（NAT）行動要件」、BCP 127、RFC 4787、2007年1月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007.
[RFC4925] Li、X.、Dawkins、S.、Ward、D。、およびA. Durand、「Softwire Problem Statement」、RFC 4925、2007年7月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 4941、2007年9月。
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007.
[RFC5080] Nelson、D。およびA. Dekok、「一般的なリモート認証ダイヤルインユーザーサービス（RADIUS）実装の問題と提案された修正」、RFC 5080、2007年12月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405] Eggert、L。およびG. Fairhurst、「アプリケーションデザイナーのユニキャストUDP使用ガイドライン」、BCP 145、RFC 5405、2008年11月。
[SUBNET-ALL] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, "Subnet Allocation Option", Work in Progress, March 2009.
[Subnet-All] Johnson、R.、Kumarasamy、J.、Kinnear、K。、およびM. Stapp、「サブネット割り当てオプション」、2009年3月、進行中の作業。
[SW-ACCT] Stevant, B., Toutain, L., Dupont, F., and D. Binet, "Accounting on Softwires", Work in Progress, April 2009.
[SW-ACCT] Stevant、B.、Toutain、L.、Dupont、F。、およびD. Binet、「Sofxwiresでの会計」、2009年4月、進行中の作業。
[SW-SEC] Yamamoto, S., Williams, C., Parent, F., and H. Yokota, "Softwire Security Analysis and Requirements", Work in Progress, May 2009.
[SW-SEC] Yamamoto、S.、Williams、C.、Parent、F。、およびH. Yokota、「Softwire Security Analysis and Recomations」、2009年5月の作業。
Authors' Addresses
著者のアドレス
Bill Storer Cisco Systems 170 W Tasman Dr San Jose, CA 95134 USA
ビルストーラーシスコシステム170 Wタスマン博士サンノゼ、カリフォルニア95134 USA
EMail: bstorer@cisco.com
Carlos Pignataro (editor) Cisco Systems 7200 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 USA
Carlos Pignataro（編集者）Cisco Systems 7200 Kit Creek Road PO Box 14987 Research Triangle Park、NC 27709 USA
EMail: cpignata@cisco.com
Maria Alice Dos Santos
Cisco Systems
170 W Tasman Dr
San Jose, CA 95134
USA
EMail: mariados@cisco.com
Bruno Stevant (editor) TELECOM Bretagne 2 rue de la Chataigneraie CS17607 Cesson Sevigne, 35576 France
Bruno Stevant（編集者）Telecom Bretagne 2 Rue de la Chataigneraie CS17607 Cesson Sevigne、35576 France
EMail: bruno.stevant@telecom-bretagne.eu
Laurent Toutain TELECOM Bretagne 2 rue de la Chataigneraie CS17607 Cesson Sevigne, 35576 France
ローレント・トゥーテン・テレコム・ブレターニュ2 rue de la chataigneraie cs17607 Cesson Sevigne、35576 France
EMail: laurent.toutain@telecom-bretagne.eu
Jean-Francois Tremblay Videotron Ltd. 612 Saint-Jacques Montreal, QC H3C 4M8 Canada
Jean-Francois Tremblay Videotron Ltd. 612 Saint-Jacques Montreal、QC H3C 4M8カナダ
EMail: jf@jftremblay.com